On Mon, 6 Oct 2008, Mark Madsen wrote:
[color=blue][color=green][color=darkred]
>>>>> Is there any evidence to support that assertion?
>>>>
>>>> Scott Kitterman <sp?> debian/ubuntu team.[/color]
>>
>> I'd take his word that the debian devs also do ubuntus over yours any
>> day sport, why should I think you know more then him, you, a completely
>> unknown troll, now kiddie, go try pull a fast one elsewhere where
>> someone might give a **** and be dumb enough to listen to you.[/color]
>
> Cool. An ad hominem attack. That's an excellent way to demonstrate that
> you don't actually have any evidence to support your wilder assertions.[/color]

Already stated my proof, not my problem it doesnt fit in with your
fantasy, I also note you cant state why I should accept your word
over a debian team members, but I thought as much, troll. Now
**** off back to whatever rock you climbed from out of troll boi.

--
Cheers
Res

"The hopes we had, were much to high, way out of reach, but we have to
try, no need to hide, no need to run, cause all the answers come one by
one" -Freiheit

10-06-2008, 02:48 PM

unix

Re: This is why I use slackware

On Mon, 06 Oct 2008 21:12:41 +1000, Res wrote:
[color=blue]
> On Mon, 6 Oct 2008, Mark Madsen wrote:
>[color=green][color=darkred]
>>>>>> Is there any evidence to support that assertion?
>>>>>
>>>>> Scott Kitterman <sp?> debian/ubuntu team.
>>>
>>> I'd take his word that the debian devs also do ubuntus over yours any
>>> day sport, why should I think you know more then him, you, a
>>> completely unknown troll, now kiddie, go try pull a fast one elsewhere
>>> where someone might give a **** and be dumb enough to listen to you.[/color]
>>
>> Cool. An ad hominem attack. That's an excellent way to demonstrate
>> that you don't actually have any evidence to support your wilder
>> assertions.[/color]
>
> Already stated my proof, not my problem it doesnt fit in with your
> fantasy, I also note you cant state why I should accept your word over a
> debian team members, but I thought as much, troll. Now **** off back to
> whatever rock you climbed from out of troll boi.[/color]

BTW - not a dig, I was just finding a good natured part of this thread to
add my bit. :-)

Personally I avoid the advocacy arguments. If its not linux v Windows its
Windows v Mac and Linux v Mac, and then once people start talking linux is
Ubuntu v Slackware etc. Little of it is constructive, to the point that
logic leaves the discussion and we are left with dogma and insults.

Seams reasonable. I know people will say this is stupid, but I am
considering here a single PC that is not forwarding other computers to the
internet. If nothing is getting in, is there a realistic chance of a
trojan trying to send stuff out?
[color=blue]
> 3. default policy of ACCEPT for incoming (configurable)[/color]

Confused here. Surely accept all on loopback as in 1. and maybe accept all
on local network. But surely we want to REJECT all connections coming in
from the internet side.
[color=blue]
> 4. LOG all dropped packets (perhaps use --limit 3/min
> --limit-burst 10 or similar)[/color]

Whilst I can see they want an easy life surely it should enabled? Perhaps
some sort of wizard / config programme, given the target audience?

Surely with 3. and 5. in place you have a firewall that does nothing? I
would have thought, given the target audience, that on installation Ubuntu
would ask the user to nominate which interface was the internet connection
and block all incoming from there. In fact, though Slackware is not
intended to nanny you along, it seems like a reasonable step in Slackware
as it is likely, when installing Slack that you will be running services.
I'd go further and say all linux or other OS installs. It would reduce the
number of completely unfirewalled machines in the wild.

Pete

--
[url]http://www.petezilla.co.uk[/url]

10-06-2008, 06:29 PM

unix

Re: This is why I use slackware

Peter Chant wrote:
[color=blue]
> If nothing is getting in, is there a realistic chance of a trojan
> trying to send stuff out?[/color]

Yes there is. Even with no *services* responding on the local machine,
if the user is using it as a client to services on other machines, there
is a non-zero chance of unintended traffic leaving. However, the user
needs to decide for him/herself whether a policy that would require
explicit rules for all expected services is appropriate for a personal
computer.
[color=blue]
> But surely we want to REJECT all connections coming in from the
> internet side.[/color]

A policy based on "default deny" would certainly be an improvement, but
has the drawback that the user needs to learn how to configure the
firewall to permit desired services. This is, of course, the same thing
as an OS distribution that does not include any firewalling rules by
default. I'm not about to defend the Ubuntu installation's approach, as
I don't agree with it (my reaction, though, is simply that I have no
intention to use it), but I suspect that the reasoning behind it is to
provide a system that works by default as though there were no firewall
in place, with the possibility of the user easily being able to add in
some firewalling.
[color=blue][color=green]
>> 5. Firewall is disabled on installation[/color]
>
> Whilst I can see they want an easy life surely it should enabled?
> Perhaps some sort of wizard / config programme, given the target
> audience?[/color]

See my speculation above. In most cases of a personal computer (with no
services running on it anyway), a "firewall" adds no protection anyway.
[color=blue]
> ... it is likely, when installing Slack that you will be running
> services.[/color]

I don't think that necessarily follows. Slackware is just as likely to
be installed on personal computers offering no services, as it is to be
installed on organizational servers. Anyone running services on a
system (regardless of OS distribution) needs to learn how to properly
protect those services. That may or may not involve firewalling rules.
[color=blue]
> It would reduce the number of completely unfirewalled machines in the
> wild.[/color]

I manage several systems that have no firewalling rules applied to them.
That's not to say that there is no access-control applied to the
services running on them, but rather that there isn't any form of
"firewall" (whether hardware or by iptables/ipchains) providing that
access-control. The mistake people make is to turn too quickly to a
"firewall" solution when more often than not (at least for the more
common services), there exist access-control solutions that function at
the application layer and therefore are more straightforward (and less
potentially disruptive) to manage, but just as effective.

The trick is to understand the available options, and to decide on a
case-by-case basis which one(s) are more suitable for a given system.
On some systems, I've done the exact opposite from what I describe
above, and turned to IPTables for a host-side (default-deny) firewall,
but that isn't my usual way of operating.

On Mon, 06 Oct 2008 18:53:48 +0100, Peter Chant <REMpeteOVE@CAPpetezilla.ITALSco.uk> wrote:
[color=blue]
>notbob wrote:
>
>OK, for the purposes of my enlightenment. I'm not a firewall guru.
>[color=green]
>>
>> Policy
>>
>> (Completed: Hardy)
>>
>> The default firewall policy will be:
>>
>> 1. ACCEPT all on loopback[/color]
>
>Seems reasonable
>[color=green]
>> 2. ACCEPT all outgoing[/color]
>
>Seams reasonable. I know people will say this is stupid, but I am
>considering here a single PC that is not forwarding other computers to the
>internet. If nothing is getting in, is there a realistic chance of a
>trojan trying to send stuff out?[/color]

Stuff getting out on a router firewall box goes via the FORWARD chain in any
case, not the OUTPUT chain.[color=blue]
>[color=green]
>> 3. default policy of ACCEPT for incoming (configurable)[/color]
>
>Confused here. Surely accept all on loopback as in 1. and maybe accept all
>on local network. But surely we want to REJECT all connections coming in
>from the internet side.[/color]

Well DROP, is better here. REJECT advertises each port as being there but
closed. DROP leaves the remote in the dark...[color=blue]
>[color=green]
>> 4. LOG all dropped packets (perhaps use --limit 3/min
>> --limit-burst 10 or similar)[/color]
>
>Seems logical.
>[color=green]
>> 5. Firewall is disabled on installation[/color][/color]

This is the odd one, they claim firewall not needed because no services
are offered. While true for a single machine right after an install, it's
perhaps too easy to turn external access to a web (or other) server and
not many steps for accidentally providing a transparent proxy or login
service that can allow the machine to be r00ted or subverted into a botnet.

Given that the target audience for *buntu are crying out for help on any
forum out there, it would be expected that many will blindly follow bad
scripts / install procedures as good ones, no?[color=blue][color=green]
>>[/color]
>
>Whilst I can see they want an easy life surely it should enabled? Perhaps
>some sort of wizard / config programme, given the target audience?[/color]

Yes, or just the basic firewall a lowly modem / router has these days, in
fact this is probably why firewalls are less important now -- to gain access
to a service offered on the box one has to punch a hole through the DSL
modem's firewall. In that sense the firewall on a linux box is less important
than it used to be.

How ever some users will run pppoe and/or firewall/router box with the modem
in bridge mode, I do ;) Even windoze offers pppoe -> bridged modem connection
(not that I'd be mad enough to trust their firewall with one).[color=blue]
>
>Surely with 3. and 5. in place you have a firewall that does nothing? I
>would have thought, given the target audience, that on installation Ubuntu
>would ask the user to nominate which interface was the internet connection
>and block all incoming from there. In fact, though Slackware is not
>intended to nanny you along, it seems like a reasonable step in Slackware
>as it is likely, when installing Slack that you will be running services.
>I'd go further and say all linux or other OS installs. It would reduce the
>number of completely unfirewalled machines in the wild.[/color]

Yeah well, as I stated above -- the only saving is most access via an (A)DSL
modem with firewall -- on the other hand there are many stories of people
getting their bandwidth / quota stolen by war-drivers or neighbours... One
I heard last week cost a company (windoze site) $600/month in excess fees,
and for them, ISP charging $150/GB over the plan limit, only 4GB over. Yup,
over $600 to download a DVD image in some circumstances? Dunno why people
use those plans...

So lack of decent firewall / security can lead to expensive side effects --
and it is common for people to use a wireless modem / router -- ignoring
security from the outset tends to setup the user for a fall, sort of like
how one doesn't really pay attention to backups until some disaster strikes
and either there's noting to restore, or one finds the last backup is
suddenly months way to old to bother with.

Encourage the right mindset? I tried slackware and stayed with it because
slackware encourages one to learn, to discover :o)

Grant.
--
[url]http://bugsplatter.id.au/[/url]

10-06-2008, 08:58 PM

unix

Re: This is why I use slackware

Sylvain Robitaille wrote:

[color=blue][color=green]
>> If nothing is getting in, is there a realistic chance of a trojan
>> trying to send stuff out?[/color]
>
> Yes there is. Even with no *services* responding on the local machine,
> if the user is using it as a client to services on other machines, there
> is a non-zero chance of unintended traffic leaving. However, the user
> needs to decide for him/herself whether a policy that would require
> explicit rules for all expected services is appropriate for a personal
> computer.
>[/color]

I don't follow here. Any examples as I can't think of one. Surely any
traffic leaving would have to be initialted by the user and therefore the
user be aware?

[color=blue][color=green]
>> But surely we want to REJECT all connections coming in from the
>> internet side.[/color]
>
> A policy based on "default deny" would certainly be an improvement, but
> has the drawback that the user needs to learn how to configure the
> firewall to permit desired services. This is, of course, the same thing
> as an OS distribution that does not include any firewalling rules by
> default. I'm not about to defend the Ubuntu installation's approach, as
> I don't agree with it (my reaction, though, is simply that I have no
> intention to use it), but I suspect that the reasoning behind it is to
> provide a system that works by default as though there were no firewall
> in place, with the possibility of the user easily being able to add in
> some firewalling.
>[/color]

Surely though were the internet is conconcerned it is better to block access
and then make holes only where needed. With a suitably commented file or
tool that ought to be fairly easy.
[color=blue][color=green][color=darkred]
>>> 5. Firewall is disabled on installation[/color]
>>
>> Whilst I can see they want an easy life surely it should enabled?
>> Perhaps some sort of wizard / config programme, given the target
>> audience?[/color]
>
> See my speculation above. In most cases of a personal computer (with no
> services running on it anyway), a "firewall" adds no protection anyway.
>[/color]

Just thinking that, for a nedwbie who installs apache locally for web
development, or enables samba to share with windows having a deny incoming
firewall by default would potentially save a lot of embarisment.

--
[url]http://www.petezilla.co.uk[/url]

10-06-2008, 09:14 PM

unix

Re: This is why I use slackware

Peter Chant wrote:
[color=blue][color=green]
>> Yes there is. Even with no *services* responding on the local machine,
>> if the user is using it as a client to services on other machines, there
>> is a non-zero chance of unintended traffic leaving. ...[/color]
>
> I don't follow here. Any examples as I can't think of one. Surely any
> traffic leaving would have to be initialted by the user and therefore the
> user be aware?[/color]

What things are possible with, for simple examples, flash, javascript, or
more likely, java? Is it possible for a user to visit a website where a
java applet is then run on the user's computer, and that applet creates
connections back to the same (or different) remote site? I'm quite
certain that it is. Or, it launches a local program that makes remote
network access? I don't know if Javascript and flash have the same
possibilities, but I'm raising them as potential examples. I'm not a
web programmer, so I don't know the details of these possibilities.

Consider also the (perhaps extreme, in the case of a Linux personal
computer) example of a user clicking on an email attachment that results
in a script running locally on the user's behalf. We know that users of
other systems have encountered this, and we know the same possibility
exists on Linux, despite it being a significantly smaller target,
with a smaller potential impact. If we're examining the possibility,
though, we need to take this into account.
[color=blue]
> Just thinking that, for a nedwbie who installs apache locally for web
> development, or enables samba to share with windows having a deny
> incoming firewall by default would potentially save a lot of
> embarisment.[/color]

I'm not disagreeing with you. I was simply proposing the sorts of
explanations I've received for similar scenarios in the past. I don't
claim to defend these arguments. Their validity, in my opinion, is
site-specific. Most users unfortunately don't have enough knowledge
(it seems) to make a suitably informed decision. :-(

Grant wrote:
[color=blue]
> On Mon, 06 Oct 2008 18:53:48 +0100, Peter Chant
> <REMpeteOVE@CAPpetezilla.ITALSco.uk> wrote:
>[color=green]
>>notbob wrote:
>>
>>OK, for the purposes of my enlightenment. I'm not a firewall guru.
>>[color=darkred]
>>>
>>> Policy
>>>
>>> (Completed: Hardy)
>>>
>>> The default firewall policy will be:
>>>
>>> 1. ACCEPT all on loopback[/color]
>>
>>Seems reasonable
>>[color=darkred]
>>> 2. ACCEPT all outgoing[/color]
>>
>>Seams reasonable. I know people will say this is stupid, but I am
>>considering here a single PC that is not forwarding other computers to the
>>internet. If nothing is getting in, is there a realistic chance of a
>>trojan trying to send stuff out?[/color]
>
> Stuff getting out on a router firewall box goes via the FORWARD chain in
> any case, not the OUTPUT chain.[color=green]
>>[/color][/color]

The example I used was a single PC connected directly to an ASDL / cable
modem, not being used as a router. So OUTPUT is correct (even if you did
make me think about that one...)

[color=blue][color=green][color=darkred]
>>> 3. default policy of ACCEPT for incoming (configurable)[/color]
>>
>>Confused here. Surely accept all on loopback as in 1. and maybe accept
>>all
>>on local network. But surely we want to REJECT all connections coming in
>>from the internet side.[/color]
>
> Well DROP, is better here. REJECT advertises each port as being there but
> closed. DROP leaves the remote in the dark...[/color]

Fair cop!
[color=blue][color=green]
>>[color=darkred]
>>> 4. LOG all dropped packets (perhaps use --limit 3/min
>>> --limit-burst 10 or similar)[/color]
>>
>>Seems logical.
>>[color=darkred]
>>> 5. Firewall is disabled on installation[/color][/color]
>
> This is the odd one, they claim firewall not needed because no services
> are offered. While true for a single machine right after an install, it's
> perhaps too easy to turn external access to a web (or other) server and
> not many steps for accidentally providing a transparent proxy or login
> service that can allow the machine to be r00ted or subverted into a
> botnet.
>
> Given that the target audience for *buntu are crying out for help on any
> forum out there, it would be expected that many will blindly follow bad
> scripts / install procedures as good ones, no?[/color]

Yes, I thought that was the plus point. I have installed stuff on Ubuntu to
see what it was like as it was easier than slack. Mostly I just lost
interested and went back the slack box - but automagick one click
installation is Ubuntu's big plus. I espect a lot of people are running
services that they clicked on in synaptic, had a quick look at, got bored
and forgot.

[color=blue][color=green][color=darkred]
>>>[/color]
>>
>>Whilst I can see they want an easy life surely it should enabled? Perhaps
>>some sort of wizard / config programme, given the target audience?[/color]
>
> Yes, or just the basic firewall a lowly modem / router has these days, in
> fact this is probably why firewalls are less important now -- to gain
> access to a service offered on the box one has to punch a hole through the
> DSL
> modem's firewall. In that sense the firewall on a linux box is less
> important than it used to be.
>
> How ever some users will run pppoe and/or firewall/router box with the
> modem
> in bridge mode, I do ;) Even windoze offers pppoe -> bridged modem
> connection (not that I'd be mad enough to trust their firewall with one).[/color]

Agree with the router thing. I've been running slack since 3.4 and always
connected my windows machine to the internet via the slack machine using
NAT. Once I went broadband I just popped the router in front the linux
box. Rarely seen anything get as far as the linux box. I once, after
about four years, of running NT behind the linux box with no antivirus ran
a scan (with some online scanner). Nothing. Mind you, I read all my mail
in linux and with windows softward that I have downloaded I only touch
reputable stuff (Povray, Irfanview etc).

My limited experience of Windows security software is that it causes as much
trouble as it solves. I don't think its a windows thing, I suspect that if
linux software was written along the same lines it would be just as much of
a pain.
[color=blue][color=green]
>>
>>Surely with 3. and 5. in place you have a firewall that does nothing? I
>>would have thought, given the target audience, that on installation Ubuntu
>>would ask the user to nominate which interface was the internet connection
>>and block all incoming from there. In fact, though Slackware is not
>>intended to nanny you along, it seems like a reasonable step in Slackware
>>as it is likely, when installing Slack that you will be running services.
>>I'd go further and say all linux or other OS installs. It would reduce
>>the number of completely unfirewalled machines in the wild.[/color]
>
> Yeah well, as I stated above -- the only saving is most access via an
> (A)DSL modem with firewall -- on the other hand there are many stories of
> people
> getting their bandwidth / quota stolen by war-drivers or neighbours...
> One I heard last week cost a company (windoze site) $600/month in excess
> fees,
> and for them, ISP charging $150/GB over the plan limit, only 4GB over.
> Yup,
> over $600 to download a DVD image in some circumstances? Dunno why people
> use those plans...
>[/color]

Just went wireless.4 Had WPA up and working almost immediately! (as least
on the router end, eee end took a little bit more fiddling).
[color=blue]
> So lack of decent firewall / security can lead to expensive side effects
> -- and it is common for people to use a wireless modem / router --
> ignoring security from the outset tends to setup the user for a fall, sort
> of like how one doesn't really pay attention to backups until some
> disaster strikes and either there's noting to restore, or one finds the
> last backup is suddenly months way to old to bother with.
>[/color]

Hmm, yes. Tried tape once and ran away. I now backup nightly to my slug
and have another disk that I copy to every time I feel like it (probally
monthly). Never say never, but I've rescued myself from a few disk
failures without too much hastle.
[color=blue]
> Encourage the right mindset? I tried slackware and stayed with it because
> slackware encourages one to learn, to discover :o)[/color]

Why not go for linux from scratch... ;-)

--
[url]http://www.petezilla.co.uk[/url]

10-06-2008, 09:21 PM

unix

Re: This is why I use slackware

Grant wrote:
[color=blue]
> Stuff getting out on a router firewall box goes via the FORWARD chain
> in any case, not the OUTPUT chain.[/color]

I believe the package in question is intended to be run on the end-user
system, not a router/firewall system. Think "personal firewall" in the
Windows-world.
[color=blue]
> Well DROP, is better here. REJECT advertises each port as being there
> but closed. DROP leaves the remote in the dark...[/color]

Which leads me to argue that REJECT is better: send them away believing
there's nothing at that port, rather than letting them know the port is
"filtered". DROP doesn't leave the scanner in the dark, it makes it
quite clear that some firewall device is between them and the target
system.
[color=blue]
> Given that the target audience for *buntu are crying out for help on any
> forum out there, it would be expected that many will blindly follow bad
> scripts / install procedures as good ones, no?[/color]

On Mon, 06 Oct 2008 22:16:00 +0100, Peter Chant <REMpeteOVE@CAPpetezilla.ITALSco.uk> wrote:
[color=blue]
>Grant wrote:[/color]
....[color=blue][color=green]
>> Stuff getting out on a router firewall box goes via the FORWARD chain in
>> any case, not the OUTPUT chain.[color=darkred]
>>>[/color][/color]
>
>The example I used was a single PC connected directly to an ASDL / cable
>modem, not being used as a router. So OUTPUT is correct (even if you did
>make me think about that one...)[/color]

Oops, sorry :)
....[color=blue]
>Hmm, yes. Tried tape once and ran away. I now backup nightly to my slug
>and have another disk that I copy to every time I feel like it (probally
>monthly). Never say never, but I've rescued myself from a few disk
>failures without too much hastle.[/color]

I run a 1/2 hour rsync/hardlink style backup on some development areas,
so other day when I 'rm index.html' instead of 'rm index.html.gz' I just
pulled the index.html file out of the /opt/backup area -- works for me :)

What did piss me off was discovering last September that I'd broken the
backup system the previous May -- months went by with the backup
overwriting old stuff, until I needed to restore a file :( Funnier was
when I setup and started sendmail couple weeks back there was ~10k messages
queued from cron telling me about the backup problem :o)

Other stuff I tarball to another box when I think of it.[color=blue]
>[color=green]
>> Encourage the right mindset? I tried slackware and stayed with it because
>> slackware encourages one to learn, to discover :o)[/color]
>
>Why not go for linux from scratch... ;-)[/color]

Slackware is as close to that as I like :) I can maintain a two year
old slack-11 quite nicely -- at the moment I'm starting to update
packages in the slack-11.0 Internet facing machine to stay current.

I've had to update netfilter iptables userspace (1.4.1.1) to match the
latest kernels -- now there's a trap for young players -- old 'man
iptables' no longer matched what the latest kernel accepted, leading
to confusing errors.

I had the latest dnsmasq in a few days before slack-11 issued the
security update. Latest git, and a few other things as required.

So what advantage going to linux from scratch from here? None as far
as I can see.

Grant.
--
[url]http://bugsplatter.id.au/[/url]

10-06-2008, 09:51 PM

unix

Re: This is why I use slackware

On Mon, 6 Oct 2008 21:21:41 +0000 (UTC), Sylvain Robitaille <syl@alcor.concordia.ca> wrote:
[color=blue]
>Grant wrote:
>[color=green]
>> Stuff getting out on a router firewall box goes via the FORWARD chain
>> in any case, not the OUTPUT chain.[/color]
>
>I believe the package in question is intended to be run on the end-user
>system, not a router/firewall system. Think "personal firewall" in the
>Windows-world.
>[color=green]
>> Well DROP, is better here. REJECT advertises each port as being there
>> but closed. DROP leaves the remote in the dark...[/color]
>
>Which leads me to argue that REJECT is better: send them away believing
>there's nothing at that port, rather than letting them know the port is
>"filtered". DROP doesn't leave the scanner in the dark, it makes it
>quite clear that some firewall device is between them and the target
>system.[/color]

Now you confuse me -- at the moment my firewall cannot be OS profiled
by nmap (a friend tried this recently) precisely because it does not
do the default or expected response to port scans.

On the other hand dropping traffic increases hits for TCP as the sender
tries a couple more times in case the SYN packet was lost.[color=blue]
>[color=green]
>> Given that the target audience for *buntu are crying out for help on any
>> forum out there, it would be expected that many will blindly follow bad
>> scripts / install procedures as good ones, no?[/color]
>
>Yes, of course. That's part of the problem ...[/color]

Couple decades of windoze dumbing down the PC community led to it, and
too many want to pop in an install CD/DVD for a free alternate windoze
and *ubuntu has successfully targeted that audience.

....[color=blue]
>Just thinking that, for a nedwbie who installs apache locally for web
>development, or enables samba to share with windows having a deny incoming
>firewall by default would potentially save a lot of embarisment.[/color]

Yes, that's the type of thing I was thinking of too. I get lots
of hits from windoze file sharing protocol, more 150 hits/day
on ports 135, 139, 445 and 1433 -- mostly from my ISP's
123.2.0.0/15 block that I'm on.

Grant.
--
[url]http://bugsplatter.id.au/[/url]

10-07-2008, 12:24 AM

unix

Re: This is why I use slackware

Sylvain Robitaille wrote:

[color=blue]
> What things are possible with, for simple examples, flash, javascript, or
> more likely, java? Is it possible for a user to visit a website where a
> java applet is then run on the user's computer, and that applet creates
> connections back to the same (or different) remote site? I'm quite
> certain that it is. Or, it launches a local program that makes remote
> network access? I don't know if Javascript and flash have the same
> possibilities, but I'm raising them as potential examples. I'm not a
> web programmer, so I don't know the details of these possibilities.
>[/color]

Not too sure about the scripting languages you mention, most of the web
development stuff I do is server end. However, I would suspect that anyone
writing a malicious script would use a common port like 80 that has a good
chance of passing outwards through a firewall. In this circumstance is
there any point in blocking any other outgoing port if 80 is open?

[color=blue]
> Consider also the (perhaps extreme, in the case of a Linux personal
> computer) example of a user clicking on an email attachment that results
> in a script running locally on the user's behalf. We know that users of
> other systems have encountered this, and we know the same possibility
> exists on Linux, despite it being a significantly smaller target,
> with a smaller potential impact. If we're examining the possibility,
> though, we need to take this into account.
>[/color]

I don't think that would work with kmail, but I am not familiar with many
other linux news clients.
[color=blue][color=green]
>> Just thinking that, for a nedwbie who installs apache locally for web
>> development, or enables samba to share with windows having a deny
>> incoming firewall by default would potentially save a lot of
>> embarisment.[/color]
>
> I'm not disagreeing with you. I was simply proposing the sorts of
> explanations I've received for similar scenarios in the past. I don't
> claim to defend these arguments. Their validity, in my opinion, is
> site-specific. Most users unfortunately don't have enough knowledge
> (it seems) to make a suitably informed decision. :-([/color]

Sorry if my tone sounded combative. Trouble is, you & i can receive trojans
and virii all day and not click on them, it's second nature.

hmm - should I try opening one under wine to see what happens...
(noting wine having access to $HOME perhaps not)

--
[url]http://www.petezilla.co.uk[/url]

10-07-2008, 12:26 AM

unix

Re: This is why I use slackware

Grant wrote:

[color=blue]
> Yes, that's the type of thing I was thinking of too. I get lots
> of hits from windoze file sharing protocol, more 150 hits/day
> on ports 135, 139, 445 and 1433 -- mostly from my ISP's
> 123.2.0.0/15 block that I'm on.[/color]

Suspect they are from windows boxes looking for other machines on the same
network rather than anything malicious, but I could be wrong!

--
[url]http://www.petezilla.co.uk[/url]

10-07-2008, 01:42 AM

unix

Re: This is why I use slackware

On Tue, 07 Oct 2008 01:26:02 +0100, Peter Chant <REMpeteOVE@CAPpetezilla.ITALSco.uk> wrote:
[color=blue]
>Grant wrote:
>
>[color=green]
>> Yes, that's the type of thing I was thinking of too. I get lots
>> of hits from windoze file sharing protocol, more 150 hits/day
>> on ports 135, 139, 445 and 1433 -- mostly from my ISP's
>> 123.2.0.0/15 block that I'm on.[/color]
>
>Suspect they are from windows boxes looking for other machines on the same
>network rather than anything malicious, but I could be wrong![/color]

Well, not malicious, but the ISP could refuse to carry the stuff,
but they account for two-way dataflow towards user quota so I suppose
there's no incentive to reduce traffic.

The other thing lately is an enormous increase in telnet hits, must
some new kiddie-script out there? Who'd run a telnet server these days?

Grant.
--
[url]http://bugsplatter.id.au/[/url]

10-07-2008, 01:42 AM

unix

Re: This is why I use slackware

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2008-10-06, Sylvain Robitaille <syl@alcor.concordia.ca> wrote:[color=blue]
> Which leads me to argue that REJECT is better: send them away believing
> there's nothing at that port, rather than letting them know the port is
> "filtered". DROP doesn't leave the scanner in the dark, it makes it
> quite clear that some firewall device is between them and the target
> system.[/color]

Unless of course you also DROP all other things that might let them
know you exist and avoid sending any traffic they might intercept.
This is plain bad practice though. Certain ICMP types need to be
allowed through. And really, there is no practicle benefit to using
DROP unless you find a particular port is constantly being hammered by
illegitimate traffic. You could conceivably save some bandwith this
way.
[color=blue][color=green]
>> Given that the target audience for *buntu are crying out for help on any
>> forum out there, it would be expected that many will blindly follow bad
>> scripts / install procedures as good ones, no?[/color]
>
> Yes, of course. That's part of the problem ...[/color]

It's the same sort of problem you see in the Windows world. The answers
generally boil down to "install this" or "run that" and "all your
problems will go away". It's never that simple. The only real
solutions to any computer problem are personal education, and/or hiring
some one who knows more than you do to fix it.

- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

On Tue, 07 Oct 2008 01:42:55 +0000, +Alan Hicks+ <alan@lizella.netWORK> wrote:
[color=blue]
>On 2008-10-06, Sylvain Robitaille <syl@alcor.concordia.ca> wrote:[color=green]
>> Which leads me to argue that REJECT is better: send them away believing
>> there's nothing at that port, rather than letting them know the port is
>> "filtered". DROP doesn't leave the scanner in the dark, it makes it
>> quite clear that some firewall device is between them and the target
>> system.[/color]
>
>Unless of course you also DROP all other things that might let them
>know you exist and avoid sending any traffic they might intercept.
>This is plain bad practice though. Certain ICMP types need to be
>allowed through.[/color]

Only one: ping request, is mandated. Other ICMPs that matter will be
accepted via the ESTABLISHED,RELATED rule that must be part of accepting
expected return traffic.
[color=blue]
> And really, there is no practicle benefit to using
>DROP unless you find a particular port is constantly being hammered by
>illegitimate traffic. You could conceivably save some bandwith this
>way.[/color]

Well, considering I'm on 512/128kbps ADSL somebody could hammer the box
four times faster than the firewall can scream Ouch! :)

Most abuse traffic I see here is more annoying than fending off attacks,
like: my web site has one form, so some script kiddies in NL decide to
hit the thing every few minutes for days on end -- until the usual ISP
warning / whatever stops them -- but one persistent kiddie reappeared
on a different IP from same ISP, apparently the same script going by
the url-encoded response, by then I had them tagged and ignored. They
didn't even notice the form now has validation timestamps in it -- so
at least the server didn't have to waste effort generating a report
the form produces.

I do wonder whether being more 'correct', sending REJECT (port unreachable)
for 'normal' TCP hits (useless responding to UDP spam, it's sent open loop --
nobody's listening), then dropping offenders when they hit closed ports
(the so-called adaptive firewall algorithm) too often is possibly better.

I'm in the process of rewriting firewall rules at the moments and am
watching the performance closely as I try different strategies. I've
not it pays not to be too creative, doing anything too far from the
like sending admin-prohibited can tweak a kiddies' curiosity and actually
increase traffic. So reject, reset and drop are the options I fiddle
with.

I do like that default dropping results in nmap being unable to
fingerprint the OS. And that's before playing with esoteric tricky
stuff like chaostables.