On Mon, 4 Dec 2000, mouss wrote:
> > > 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:)
If it's *that* important, then you should be using an application layer
gateway, not a packet filter, state or not.
>
> >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.
Normal IOS filtering with extended access lists on the border router is
the best first line of defense. Firewalls should worry about what's able
to get through that line, not everything possible.
> >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.
It must function correctly to benefit customers, and in that way how
complex it is becomes important.
>
>
> >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).
The gain on that versus the local state machine isn't very high (i.e. the
difference between a filter keeping state and not performing based on ACK
bits and seen packets and a stack isn't large.) The gain for UDP or ICMP,
where either there is no state, or where each implmentation of the
application must keep state is a much larger gain. By using the term
"gain" I explicitly meant the delta between having state and not having
state on a packet filter for a particular transport.
> 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.
Sometimes you can distinguish, sometimes you can't, but that depends on
the type of attack you're trying to defeat.
>
> >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.
1. That doesn't address DNS tunneling in all environments.
2. BIND is the sendmail of the 90's/00's.
> >Stateful rules are added in the next revision of Linux filtering, which
> >will replace IPChains.
>
> so, this is enough proof that stateful is good:)
No, it's proof that people want state. Reading anything else into it is
a poor choice.
>
> >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.
IPFilter on a NetBSD box running full-duplex 100bT puts less than 1ms of
delay in the chain and adds a further point of control, as well as getting
you another box to play with. Swtiching production OS' isn't always as
good an idea.
> >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.
You're not allowing SYNs in though, so the level of risk is quite shallow
and the total window seems to be about the same as if you had state, that
is DoS of a legitimate session.
> > 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.
The point is that people shouldn't pass any crap in the world through
firewalls just because they think that adding state to a packet filter
increases the level of protection anything more than incrementally.
> > 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.
There's always a point at which you shouldn't pass a protocol, the
question is just how much compromise you're willing to live with.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
