erich@uruk.org wrote: >Alan Cox 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