[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: hurd does NOT need /hurd



On Mon, May 20, 2002 at 12:57:05PM -0700, Thomas Bushnell, BSG wrote:
> "Joel Baker" <lucifer@lightbearer.com> writes:
> 
> > Firewalling is *not* automatically a benefit, any more than having locks on
> > your car is a benefit to prevent theft. You also need a key, and you need
> > to *use* the locks... but if you're really trying to claim that the use of
> > configured firewalling (even 'configured to defaults') is not useful to
> > network security, then you are making an assertion that runs counter to the
> > vast majority of both research and field experience on the topic.
> 
> Host-based firewalling is not a network firewall.

This is true by definition. I presume you mean to imply "network firewalls
are better", which I would agree with, but you seem to have a very strong
habit of assuming that such statements are automatically implicit.

> I would be interested in reading the research you refer to; can you
> give me pointers?

For the research portion, I will need to find you citations; I'll look
when I get to work. For the field portion, go read the NANOG archives.

> I have never seen a firewall administered in a way which actually
> improved security.  For example, where I am, there is a firewall that
> blocks incoming TCP port 23 connections, on the grounds that this
> improves security.  Of course, it does no such thing; telnetd can run
> on any port you like.

You are confusing "security against random remote attacks against a
machine with an inexperienced admin" (Joe Debian User) with "security
against a local user trying to bypass the firewall".

And if you think that putting a server on a port other than 23 will
help you bypass any firewall you've seen, then you've never seen any
of the firewalls I've written with the intent of being significantly
secure (as opposed to the intent of being marginally more secure than
a wide-open network).

Any firewall with more than marginal security blocks all ports that
it does not explicitly know about needing to permit, inbound. Most
of them, for sane user convenience, allow connections to arbitrary
ports > 1023, at least with outbound TCP, so that people can connect
to the vast majority of user-run servers.

Further discussion is probably off-topic for the -devel list, but I
would be happy to continue it in private with interested parties.

> However, I'm happy to agree that this is a feature some people want,
> and therefore it's a good thing to provide.

At least we agree on that. :)

> John Robinson went further, however, saying that if it isn't provided,
> the system can't be said to have any security at all.

I wouldn't say "no security". I would say "less security than I would
personally like to see Debian release with". However, it isn't Policy,
and my personal opinion doesn't determine release requirements. :)

> Network firewalls in theory help with the problem of badly configured
> hosts.  Host-based firewalls don't help that at all.

Default to blocking anything outside the local network to portmapper, and
you just blocked a large number of attacks that have frequently had periods
of high success rates (IE, 'lots of compromise bugs have appeared over the
life of the software').

Granted, blocking UDP port 53 will also help, but it tends to do more harm
than good for most folks. What would really be needed, to make such a beast
work correctly, is some way for daemons to tell the firewall config "Hey!
I need you to open <X> for me", and then ask the user to confirm that they
want that to be opened (which is probably 'yes', if they're installing the
software, but it's a good way to catch things people didn't know about;
maybe something akin to a 'low' priority Debconf question?)
-- 
***************************************************************************
Joel Baker                           System Administrator - lightbearer.com
lucifer@lightbearer.com              http://users.lightbearer.com/lucifer/


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: