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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 07 2002 - 21:00:25 EST