This is why I use slackware
notbob
https://wiki.ubuntu.com/UbuntuFirewall
-----
Policy
(Completed: Hardy)
The default firewall policy will be:
1. ACCEPT all on loopback
2. ACCEPT all outgoing
3. default policy of ACCEPT for incoming (configurable)
4. LOG all dropped packets (perhaps use --limit 3/min
--limit-burst 10 or similar)
5. Firewall is disabled on installation
-----
Granted, Slack comes with no ipchains packet filter utility, but at least it
doesn't offer bogus claims to lull users into a false sense of security.
Even linux.com would have you believe this is a good thing:
http://www.linux.com/feature/148629
"The Uncomplicated Firewall (UFW) is a new tool from Ubuntu whose goal is to
make configuration of the built-in Linux packet filter less complicated and
more secure for novice users."
Oh yeah? Look at the default settings above.
This has to be insanely confusing to the new user. Do I have a firewall?
Ubuntu says yes. DOH!
"With UFW, enabling and disabling packet filtering is a simple matter of
issuing the sudo ufw enable and sudo ufw disable commands."
Yeah, like Windows XP users hava a clue what sudo is. Lordy! Is it me or
is this whole ubuntu phenomema just a scam?
nb
SINNER
> Yeah, like Windows XP users hava a clue what sudo is.
So?
> Lordy! Is it me or
> is this whole ubuntu phenomema just a scam?
Works great for thousands of other users, isnt choice grand?
--
David | Fight Back! <http://improve-usenet.org/>
Optimism is the content of small men in high places.
-- F. Scott Fitzgerald, "The Crack Up"
Grant
>Can there be any more proof that ubuntu is aimed at the braindead?:
>
>https://wiki.ubuntu.com/UbuntuFirewall
>
>-----
>
>Policy
>
>(Completed: Hardy)
>
>The default firewall policy will be:
>
> 1. ACCEPT all on loopback
> 2. ACCEPT all outgoing
> 3. default policy of ACCEPT for incoming (configurable)
> 4. LOG all dropped packets (perhaps use --limit 3/min
> --limit-burst 10 or similar)
> 5. Firewall is disabled on installation
>
>-----
>
>Granted, Slack comes with no ipchains packet filter utility, but at least it
^^^^^^^^--> iptables anyone?
>doesn't offer bogus claims to lull users into a false sense of security.
Slack-11 offers something to do with iptables in /etc/rc.d/rc.modules-2.4.33.3
Slamd64-12.1 has iptables statements in /etc/rc.d/rc.modules-2.6.24.5 too, so
I assume slack-12.1 does.
I just did a quick grep from /etc. Both are comments on setting up firewall
and direct user to 'man iptables' in the usual 'teach a man to fish...'
fashion.
>Even linux.com would have you believe this is a good thing:
>
>http://www.linux.com/feature/148629
>
>"The Uncomplicated Firewall (UFW) is a new tool from Ubuntu whose goal is to
>make configuration of the built-in Linux packet filter less complicated and
>more secure for novice users."
>
>Oh yeah? Look at the default settings above.
It's crap...
>
>This has to be insanely confusing to the new user. Do I have a firewall?
>Ubuntu says yes. DOH!
'Tis bad, another generation of linux 'botnets?
>
>"With UFW, enabling and disabling packet filtering is a simple matter of
>issuing the sudo ufw enable and sudo ufw disable commands."
>
>Yeah, like Windows XP users hava a clue what sudo is. Lordy! Is it me or
>is this whole ubuntu phenomema just a scam?
Scary how this sudo crap fad whatever now permeates the linux 'guidance'
for beginners. Okay, I've set sudoers to let me as 'wheel' member sudo
a 'make install' for example without have to enter root's password, but
*buntu take it to ridiculous lengths, pages of commands, each prefixed
with sudo -- erm root login, anyone?
Scam? Other day I notice 'how do it remove grub?' thread, bagging
linux because brainless *buntu install mode wipes the MBR -- but some
'doze users too stupid to think in terms on 'how do I rewrite MBR?'
with 'doze FIXMBR and/or FIXBOOT tools on the recovery console (the
what??) that's been around I think since Win2k.
UFW? Why put another layer between users and the basic tools?
Or id this the only way to appeal to 'dozing Drag'n'Droolers?
Grant.
--
http://bugsplatter.id.au/
notbob
>>Granted, Slack comes with no ipchains packet filter utility, but at least it
> ^^^^^^^^--> iptables anyone?
DOH!
...and I know better.
nb ...braindead slack user ;)
Keith Keller
A perfect candidate for Ubuntu! ;-O
--keith
--
kkeller...@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
Peter Chant
> Scary how this sudo crap fad whatever now permeates the linux 'guidance'
> for beginners. Okay, I've set sudoers to let me as 'wheel' member sudo
> a 'make install' for example without have to enter root's password, but
> *buntu take it to ridiculous lengths, pages of commands, each prefixed
> with sudo -- erm root login, anyone?
>
If you really want to get flamed go over to alt.os.linux.ubuntu and ask (or
explain) how to enable the root account.
Pete
--
http://www.petezilla.co.uk
enos76
> [...] default policy of ACCEPT for incoming [...]
Ubuntu by default offers no services at all, thus has no open doors
anyway.
--
enos76
Grant
Whaddya mean offers no services? Soon as some *ubuntu luser does a
sudo apt-crap some_daemon install they're wide open and no thought
given to limiting resource access or DoS. And the social engineering
behind this means that these same lusers will be the ones exploited
'cos they'll likely do anything without thinking, just as long as the
instructions or scriptlet starts with a 'sudo' it must be okay :o)
Grant.
--
http://bugsplatter.id.au/
Henrik Carlqvist
> Grant wrote:
>> *buntu take it to ridiculous lengths, pages of commands, each prefixed
>> with sudo -- erm root login, anyone?
> If you really want to get flamed go over to alt.os.linux.ubuntu and ask
> (or explain) how to enable the root account.
My father uses ubuntu. Life got a lot easier for him once I told him that
he could do "sudo bash".
Being an oldfashioned Slackware user myself I prefer to have a root
login, but I can also understand the good points of sudo. A few years back
at work we used to have a root aliases for different people which should
have different administrative priveleges. Today those root aliases are
replaced with the usage of sudo.
Still in a networked environment I find a real root login necessary for
administrative tasks those times when a normal user is unable to login.
Things that could make it impossible for normal users to login is when the
NFS server which exports the users home directory is down or if the NIS or
ldap server which serves user login data is down. At those occasions you
really need a root account to login to.
regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost
»Q«
Res <r...@ausics.net> wrote:
> sudo is far less secure in its default configuration on most OS's
>
> sudo -i
> do foo
> do bar
> exit
> ...get up, go for a coffee
> ...2 mins later someone types sudo -i oh lookie in like flyn with
> no password :)
>
> rm -rf /
>
> ..you come back and find a totally borked system
>
> Yes, you can disable the time cache, but it SHOULD be disbled in the
> FIRST place, therefor sudo is less secure than a root login.
Is it really any harder to remember to type `sudo -k` than it is to
remember to log out of a root session? I guess it just depends on what
you're in the habit of doing.
--
»Q«
Kleeneness is next to Gödelness.
enos76
> Is it really any harder to remember to type `sudo -k` than it is to
> remember to log out of a root session? I guess it just depends on what
> you're in the habit of doing.
I'd lock a non-root session anyway!
...especially if I was my workmate ;-)
--
enos76
Mark Madsen
> sudo is insecure by default, as you
> quoted me saying it can be avoided/disabled, but remember 90% of users
> conned into using it, like debians
Debian creates a root account by default, and sudo for user accounts is
disabled by default.
> (this include *buntu since they are
> all maintained by the debian devs)
Is there any evidence to support that assertion?
One can be a big Slackware fan, but if one is going to knock other people
and distros one should base one's statements and criticisms on verifiable
fact. Anything else is merely silly.
Mark Madsen
> On Sun, 5 Oct 2008, Mark Madsen wrote:
>
>> On Sun, 05 Oct 2008 10:19:18 +1000, Res wrote:
>>
>>> sudo is insecure by default, as you
>>> quoted me saying it can be avoided/disabled, but remember 90% of users
>>> conned into using it, like debians
>>
>> Debian creates a root account by default, and sudo for user accounts is
>> disabled by default.
>
> ubuntu does not create a root account with a root password therefore
> root a/c as such is not usable until you sudo passwd root
I said "Debian", not Ubuntu. Despite your assertions to the contrary,
they are different.
> debian itself
> ive not used in years and never will again.
Then why do you think you know anything about it?
>>> (this include *buntu since they are
>>> all maintained by the debian devs)
>>
>> Is there any evidence to support that assertion?
>
> Scott Kitterman <sp?> debian/ubuntu team.
Nice try, but you score a zero on the test.
Your assertion was "...all....", so showing that one Debian maintainer
out of over a thousand works on both teams demonstrates exactly nothing
to back up your assertion.
Your claim is that you can show that all the *buntu are "maintained by
the Debian devs". Even a single non-Debian dev working on Xubuntu, say,
would disprove your assertion.
Logic. It gets us all in the end.
Mark Madsen
> On Mon, 5 Oct 2008, Mark Madsen wrote:
>
>>>> Debian creates a root account by default, and sudo for user accounts
>>>> is disabled by default.
>>>
>>> ubuntu does not create a root account with a root password therefore
>>> root a/c as such is not usable until you sudo passwd root
>>
>> I said "Debian", not Ubuntu. Despite your assertions to the contrary,
>> they are different.
>
> by name and cosmetics only
OK, so you don't know the difference. That's fine. But then don't set
yourself up as an expert on other distros.
>>>> 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 fuck and be dumb enough to listen to you.
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.
Mark Madsen
> On Mon, 6 Oct 2008, Mark Madsen wrote:
>
>>>>>> 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 fuck and be dumb enough to listen to you.
>>
>> 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.
>
> 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 fuck off back to
> whatever rock you climbed from out of troll boi.
Fascinating.
Mark Madsen
> On Mon, 06 Oct 2008 16:48:55 +0200, Mark Madsen wrote:
>
>> Fascinating.
>
> This is alt.os.linux.slackware, it is always fascinating. If you hang
> around long enough you'll discover just how fascinating.
Thanks for the encouragement :-)
I have been reading this group for ages. Even when there isn't much
useful knowledge about Slackware, there is always new invective to
appreciate.
Peter Chant
> On 2008-10-04, notbob <not...@nothome.com> wrote:
>>
>> nb ...braindead slack user ;)
>
> A perfect candidate for Ubuntu! ;-O
>
> --keith
>
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.
Pete
Peter Chant
OK, for the purposes of my enlightenment. I'm not a firewall guru.
>
> Policy
>
> (Completed: Hardy)
>
> The default firewall policy will be:
>
> 1. ACCEPT all on loopback
Seems reasonable
> 2. ACCEPT all outgoing
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?
> 3. default policy of ACCEPT for incoming (configurable)
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.
> 4. LOG all dropped packets (perhaps use --limit 3/min
> --limit-burst 10 or similar)
Seems logical.
> 5. Firewall is disabled on installation
>
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
Sylvain Robitaille
> If nothing is getting in, is there a realistic chance of a trojan
> trying to send stuff out?
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.
> But surely we want to REJECT all connections coming in from the
> internet side.
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.
>> 5. Firewall is disabled on installation
>
> Whilst I can see they want an easy life surely it should enabled?
> Perhaps some sort of wizard / config programme, given the target
> audience?
See my speculation above. In most cases of a personal computer (with no
services running on it anyway), a "firewall" adds no protection anyway.
> ... it is likely, when installing Slack that you will be running
> services.
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.
> It would reduce the number of completely unfirewalled machines in the
> wild.
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.
--
----------------------------------------------------------------------
Sylvain Robitaille s...@alcor.concordia.ca
Network and Systems analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------
Grant
>notbob wrote:
>
>OK, for the purposes of my enlightenment. I'm not a firewall guru.
>
>>
>> Policy
>>
>> (Completed: Hardy)
>>
>> The default firewall policy will be:
>>
>> 1. ACCEPT all on loopback
>
>Seems reasonable
>
>> 2. ACCEPT all outgoing
>
>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?
Stuff getting out on a router firewall box goes via the FORWARD chain in any
case, not the OUTPUT chain.
>
>> 3. default policy of ACCEPT for incoming (configurable)
>
>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.
Well DROP, is better here. REJECT advertises each port as being there but
closed. DROP leaves the remote in the dark...
>
>> 4. LOG all dropped packets (perhaps use --limit 3/min
>> --limit-burst 10 or similar)
>
>Seems logical.
>
>> 5. Firewall is disabled on installation
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?
>>
>
>Whilst I can see they want an easy life surely it should enabled? Perhaps
>some sort of wizard / config programme, given the target audience?
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).
>
>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.
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.
--
http://bugsplatter.id.au/
Peter Chant
>> If nothing is getting in, is there a realistic chance of a trojan
>> trying to send stuff out?
>
> 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.
>
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?
>> But surely we want to REJECT all connections coming in from the
>> internet side.
>
> 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.
>
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.
>>> 5. Firewall is disabled on installation
>>
>> Whilst I can see they want an easy life surely it should enabled?
>> Perhaps some sort of wizard / config programme, given the target
>> audience?
>
> See my speculation above. In most cases of a personal computer (with no
> services running on it anyway), a "firewall" adds no protection anyway.
>
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.
Sylvain Robitaille
>> 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. ...
>
> 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?
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.
> 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.
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. :-(
Peter Chant
> On Mon, 06 Oct 2008 18:53:48 +0100, Peter Chant
> <REMpe...@CAPpetezilla.ITALSco.uk> wrote:
>
>>notbob wrote:
>>
>>OK, for the purposes of my enlightenment. I'm not a firewall guru.
>>
>>>
>>> Policy
>>>
>>> (Completed: Hardy)
>>>
>>> The default firewall policy will be:
>>>
>>> 1. ACCEPT all on loopback
>>
>>Seems reasonable
>>
>>> 2. ACCEPT all outgoing
>>
>>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?
>
> Stuff getting out on a router firewall box goes via the FORWARD chain in
> any case, not the OUTPUT chain.
>>
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...)
>>> 3. default policy of ACCEPT for incoming (configurable)
>>
>>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.
>
> Well DROP, is better here. REJECT advertises each port as being there but
> closed. DROP leaves the remote in the dark...
Fair cop!
>>
>>> 4. LOG all dropped packets (perhaps use --limit 3/min
>>> --limit-burst 10 or similar)
>>
>>Seems logical.
>>
>>> 5. Firewall is disabled on installation
>
> 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?
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.
>>>
>>
>>Whilst I can see they want an easy life surely it should enabled? Perhaps
>>some sort of wizard / config programme, given the target audience?
>
> 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).
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.
>>
>>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.
>
> 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...
>
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).
> 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.
>
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.
> Encourage the right mindset? I tried slackware and stayed with it because
> slackware encourages one to learn, to discover :o)
Why not go for linux from scratch... ;-)
Sylvain Robitaille
> Stuff getting out on a router firewall box goes via the FORWARD chain
> in any case, not the OUTPUT chain.
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.
> Well DROP, is better here. REJECT advertises each port as being there
> but closed. DROP leaves the remote in the dark...
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.
> 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?
Yes, of course. That's part of the problem ...
Grant
>Grant wrote:
...
>> Stuff getting out on a router firewall box goes via the FORWARD chain in
>> any case, not the OUTPUT chain.
>>>
>
>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...)
Oops, sorry :)
...
>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.
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.
>
>> Encourage the right mindset? I tried slackware and stayed with it because
>> slackware encourages one to learn, to discover :o)
>
>Why not go for linux from scratch... ;-)
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.
--
http://bugsplatter.id.au/
Grant
>Grant wrote:
>
>> Stuff getting out on a router firewall box goes via the FORWARD chain
>> in any case, not the OUTPUT chain.
>
>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.
>
>> Well DROP, is better here. REJECT advertises each port as being there
>> but closed. DROP leaves the remote in the dark...
>
>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.
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.
>
>> 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?
>
>Yes, of course. That's part of the problem ...
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.
Grant.
--
http://bugsplatter.id.au/
Grant
...
>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.
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.
--
http://bugsplatter.id.au/
Peter Chant
> 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.
>
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?
> 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.
>
I don't think that would work with kmail, but I am not familiar with many
other linux news clients.
>> 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.
>
> 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. :-(
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)
Peter Chant
> 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.
Suspect they are from windows boxes looking for other machines on the same
network rather than anything malicious, but I could be wrong!
Grant
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.
--
http://bugsplatter.id.au/
+Alan Hicks+
Hash: SHA1
On 2008-10-06, Sylvain Robitaille <s...@alcor.concordia.ca> wrote:
> 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.
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.
>> 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?
>
> Yes, of course. That's part of the problem ...
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)
iEYEARECAAYFAkjqvp8ACgkQkT+yo0QBUBubNwCeJDs895k6Ok+jLQu36c7aCdYs
98AAn0IgNIeIWV0oLTYt5KXD5VX2yml5
=ijEC
-----END PGP SIGNATURE-----
Grant
>On 2008-10-06, Sylvain Robitaille <s...@alcor.concordia.ca> wrote:
>> 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.
>
>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.
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.
> 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.
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.
Grant.
--
http://bugsplatter.id.au/
Helmut Hullen
Du meintest am 07.10.08:
> 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
From
ecatel.net
or from another dutch ISP?
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Grant
>Hallo, Grant,
>
>Du meintest am 07.10.08:
>
>> 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
>
>
>From
> ecatel.net
Yes.
>Viele Gruesse
>Helmut
>
You do need "-- " at the start of this line to mark start of .signature
>"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Grant.
--
http://bugsplatter.id.au/
Helmut Hullen
Du meintest am 07.10.08:
>>> 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
>> From
>> ecatel.net
> Yes.
That provider seems to be ignorant.
One server calls my FAQ (phpMyFAQ) every 3 minutes, it always gets a
"500" answer. Since more than 2 weeks.
I have informed the provider every 3 days - no reaction. Now I have
blocked it via ".htaccess".
Viele Gruesse
Helmut
Sylvain Robitaille
> Who'd run a telnet server these days?
Not everything on the 'net is a personal computer. Some network devices
still provide administrative access only via telnet.
Loki Harfagr
> On 07 Oct 2008 08:15:00 +0200, hel...@hullen.de (Helmut Hullen) wrote:
...
>>Viele Gruesse
>>Helmut
>>
> You do need "-- " at the start of this line to mark start of .signature
>>"Ubuntu" - an African word, meaning "Slackware is too hard for me".
>
> Grant.
Grant, you should by now know that it is not his .sig, there's no
"-- " nor b0rken "--" prefix, it is just that he still believes that's the
modern germ-am-english to say goodbye...
...or, maybe does he just mean "signware's too hard for me" ?-)
Grant
>Grant, you should by now know that it is not his .sig, there's no
>"-- " nor b0rken "--" prefix, it is just that he still believes that's the
>modern germ-am-english to say goodbye...
>
>...or, maybe does he just mean "signware's too hard for me" ?-)
Yup, I like "signware's too hard for me" :o)
Grant.
--
http://bugsplatter.id.au/
Sylvain Robitaille
> ... 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.
This matters because ... ?
(Nmap gets the OS of my home gateway system wrong, probably because the
systems it's natting and port-forwarding for aren't all the same ...)
Remember, above all, obscurity != security. Someone who wants to break
into your system may want to prioritze exploits to try, but giving them
less information doesn't mean they won't still try; it means they'll
try harder. It means they'll try stuff that isn't likely to work as
well as the stuff that might (assuming you have a service available that
might be subverted). At best, you buy yourself some time, but automated
exploits have all the time in the world.
If you take measures to properly secure your systems, however, including
appropriate access control, you won't worry about whether the scanners
can tell whether you're running Linux or not. You'll worry only when
they set-off some form of intrusion detection you have.
I'm not saying that you should publish your system's information in a
readily accessible location, of course, but you might want to consider
whether any true value is gained by attempting to hide information that
can normally be detected programmatically.
Sylvain Robitaille
> 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.
Agreed. Ironically, both tend to be considered too "expensive", or not
considered at all by the upper layer of many organizations. :-(
Grant
>Grant wrote:
>
>> Who'd run a telnet server these days?
>
>Not everything on the 'net is a personal computer. Some network devices
>still provide administrative access only via telnet.
I've led a sheltered computing life, biggest machine I played on was
SGI IRIX-64 box at uni. In final year I was on the thing from home
hours/day as it was my (text) gateway to the world.
On the other hand I used to work with microcontrollers with 1kB ROM
and 32 bytes RAM (8048 family), and that RAM included registers and
call stack (all of two levels). Fun stuff.
Grant.
--
http://bugsplatter.id.au/
Grant
>Hallo, Grant,
>
>Du meintest am 07.10.08:
>
>>>> 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
>
>>> From
>>> ecatel.net
>
>> Yes.
>
>That provider seems to be ignorant.
>One server calls my FAQ (phpMyFAQ) every 3 minutes, it always gets a
>"500" answer. Since more than 2 weeks.
>
>I have informed the provider every 3 days - no reaction. Now I have
>blocked it via ".htaccess".
Well this morning my favourite script-kiddie from NL is back hitting
http again, but their IP is in the deny list -- so they're not accessing
the web server, I may let it in to see if the script has changed. After
all, in response to the web form misuse by this s-k, I put in place some
query validation stuff so I don't have the server wasting it's time
building a response to an idiot script. Only one valid looking query
turned away 'cos his local time was way off.
Grant.
--
http://bugsplatter.id.au/
Grant
>Grant wrote:
>
>> ... 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.
>
>This matters because ... ?
It doesn't :o)
>I'm not saying that you should publish your system's information in a
>readily accessible location, of course, but you might want to consider
>whether any true value is gained by attempting to hide information that
>can normally be detected programmatically.
Ah, but I do publish site's information :)
http://bugsplatter.id.au/kernel/boxen/deltree/
This discussion is good 'cos it clears the cobwebs from my thinking.
I've changed from DROPs to (this is tail end of INPUT processing):
# send any repeat offenders to jail
iptables -A INPUT -p all -m recent --rsource --rcheck --name junk \
--seconds $junk_limit_secs \
--hitcount $junk_limit_hits \
-m recent --rsource --name junk --remove -g gotojail
iptables -A INPUT -p all -m recent --rsource --name junk --set
# log and reject / drop junk
iptables -A INPUT -p tcp -m conntrack --ctstate INVALID \
$limit_rate_log "JLE:inp:drop invalid "
iptables -A INPUT -p tcp -m conntrack --ctstate INVALID -j DROP
iptables -A INPUT -p all $limit_rate_log "JLE:inp:drop junk "
iptables -A INPUT -p tcp -m conntrack --ctstate NEW -j REJECT
iptables -A INPUT -p all -j DROP
Grant.
--
http://bugsplatter.id.au/
Sylvain Robitaille
>> .... Some network devices still provide administrative access only
>> via telnet.
>
> Yes, but who in their sane mind doesnt run ACL's on those devices :)
Of course, but my point was simply in response to Grant's question.
Keep in mind, though, that it seems some folks don't really know how to
use access-control. If they could move the telnet server on their
switches to a non-standard port, they likely would sooner do that than
learn how to properly secure the devices ... ;-)
Sylvain Robitaille
>> If they could move the telnet server on their switches to a
>> non-standard port, they likely would sooner do that than learn how to
>> properly secure the devices ...
>
> Seen that a few times myself, kinda funny, one was moved from 25 to,
> get this, 80 ! ...
My point exactly. I guess the thought process is along the lines of
"no one will think to telnet there, and their web browsers won't find
anything ..." Hrmmm... even 25 would be a bit of a disaster, of course