Re: Network Security hole (was -> Re: arp bug )

[David Ford <david+cert@blue-labs.org>]

[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]

erich@uruk.org wrote:

>Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
>>I strongly disagree. The RFCs _are_ expected behaviour (with the odd
>>exception like URG which BSD redefined by force)
>>
>
>Hmm.
>
>My general contention is that the system should, by default, behave as
>non-experts would expect, but this might be a point where we can't
>agree.
>

Microsoft has done this and we see where that has gone...

>I'll give up on this one relatively easily (though it was a switch,
>so this is relevant)...  but a more pertinent example would be
>if you have IP aliasing going on with 2 cards on the same network
>for failover capability, and they might be asymmetric.  Again,
>the expectation is that the "primary" one would be what is mainly
>used.
>

All of your givens can be tightly controlled using specific routing 
combined with a routing daemon.  Add a touch of correct firewalling and 
all is constrained just like you please.

>>If you want a firewall use firewall rules. If an end user is not sure
>>how to set up a basic firewall they can run tools like gnome-lokkit
>>and answer simple questions.
>>
>
>The firewall rules aren't as fine-grained as you're implying.  They
>only accept packets or not, with the assumption that all programs
>on the box are equally untrusted.
>
>A good example is, you want a trivial high-security firewall, but
>you want it to be a DNS and email server, knowing you only have
>to be really careful about those 2 programs.
>
>If the TCP/IP stack filters itself by what you've assigned it, then
>you have the flexibility of using things like tcp wrappers (for
>example) to allow one program but not another to accept things
>from particular ports as well.   Though tcp wrappers have their
>own host of problems.
>

Netfilter (iptables) is very extendable, it is certainly not limited to 
if(src=1.2.3.4) pass();  By configuring your DNS server suitably right 
off the start, you eliminate a large group of possible threats.  Email 
is simple, inbound is one port and security for that is entirely 
userland.  You don't have to be psychotic paranoid about either email or 
DNS if you apply some of the basic tenents of security; configuration, 
ownership, and permissions.  Add chroot if applicable.

Firewall rules can be very fine grained.  What's left can be dealt with 
in userland.  If it can't be handled, drop it.  In the event of 
overload, it's always better to drop packets than to pass ambiguous data.

David


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3254 bytes --]