At 07:54 04/12/00 -0500, Paul D. Robertson wrote:
>On Mon, 4 Dec 2000, Dane Balia wrote:
>
> > Hi
> >
> > I was wondering, and in cheer ignorance would like to know, if ipchains
> > has no stateful inspection written into it, why is it supported so much
> > and why hasn't it been included?
>
>TCP-based systems keep their own state, and other than some DoS stuff
>(which should be tuned on Internet-accessable hosts anyway), there's no a
>great deal of value from the filter keeping state.
uhuh?
on a filtering gateway, the TCP-based systems that will keep their own
state are
the target hosts, which are normally weak, otherwise you don't need a firewall.
so yes, there is always someone to keep state, but it's on who you want:)
>Cisco router filtering
>on a normal IOS image isn't stateful either, but it's still the best
>first-line of defense.
normal IOS is for routing, not for filtering. next generation firewall stuff
from cisco and others is probably to come with stateful filtering if they
don't have proxies.
>Adding mechanisms to keep state increase the complexity of the code, and
>if current state-keeping commercial firewalls are anything to go by, it's
>not easy to get right.
The question isnt whether something is hard for programmers, the real question
is whether it benefits customers. also, ipchains code is not pure simplicity.
>Since the biggest gain for keeping state is UDP or ICMP,
that's obviously wrong. the first place for stateful filtering is TCP,
so that holes are only opened when necessary and closed when no more
needed (by followig the TCP state).
Also, if you keep state, you can distinguish if an ICMP error is legitimate or
not. if you keep state, you don't need to open all those ports, ...
the only time you don't need state is when you have a proxy.
>and other than
>DNS, there's more likelyhood of people just blocking those where they're
>not necessary if they're security-clued, why place a state requirement on
>the filtering mechanism? DNS should go to a controlled machine or
>two running a local resolver, no reason to allow anything else to talk UDP
>if you're really worried about security.
I've never needed state for DNS.
just run BIND on the FW, in which case it acts as a proxy, or run it outside.
> > I've used BSD and other Unix's, and seen the wonders of the likes of:
> > IPFW
> > IP Filters
> > and seen the beauty of stateful inspection. I know this question should be
> > directed @ a more Linux orientated list, but I'd like to know why, it come
> > so well recommended. So, someone tell me, is there something I'm missing
> > ????
(Caution: these are not Paul's words).
That's because one doesn't chose his OS based on the software he needs, but
the opposite. and until lately, ipchains was the best solution on linux. It
has been outperformed by solutions on *BSD, but it itlself outperforms many
other solutions. in other words, state is good, but you can live without!
so one isn't gonna switch to an OS just because of a lack of feature.
>Stateful rules are added in the next revision of Linux filtering, which
>will replace IPChains.
so, this is enough proof that stateful is good:)
>Personally, I'd just add an *BSD box using
>IPFilter up front if I thought state was important to filter on, given
>that any software should be given some time to stablize prior to
>mission-critical security deployments.
why so? that would reduce the perfs. if he doesn't need the state, he can
keep ipchains, otherwise, he can just switch to BSD. both systems can
live together.
>I thought I saw some stateful filtering stuff for 2.2 kernels somewhere
>too, but it was a while back and I don't know what sort of state the
>project was in ;)
>
>For security, blocking a protocol is *always* preferable to passing it
>when talking to the Internet at large, so state would only really play a
>part in mission-critical protocols that absolutely must be supported and
>don't contain any state information themselves.
nop' with a non staeful filter, to allow outgoing telnet (for example), you
need to allow incoming requests from port 23 to high ports, which is
less secure than allowing those only if they correspond to an outgoing
request. while it is hard to perform an attack based on this, it is still
theoritically possible, and many practical attacks were only theoritical some
years ago.
> Typically, that's limited
>to DNS, which has query IDs and can be limited to say a box running
>dnscache for external interaction. Given that, for most sites, I don't
>think that state in filtering is all that much of a gain, unless you're
>trying to protect buggy stacks, untunable stacks, or protocols that you
>really shouldn't be passing if they're that bad.
we don't only protect hosts because they have buggy stack. we also protect
them so that we can configure'em the way we want. yes, if all my internal hosts
are protected, then I won't need a FW, but then each host would need its own
servers, as it can trust no other hots. bye NIS, samba, dns, ...
so for me a firewall is that thing that allows me to put funny .rhosts, share
passwords and files, ... in the internal network, install a host without
needing
to sniff all traffic for an attack, ... otherwise, I don't need one.
> Certianly the value of
>state is only incremental when compared with the base value of filtering
>in any reasonably paranoid environment.
the real solution is a specific proxy, but it ain't always available.
regards,
mouss
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
