On Tue, 5 Dec 2000, Ben Nagy wrote:
> Which is an interesting point, and kind of flies in the face of "current
> opinion", but the arguments you make are all reasonable and logical.
It's interesting when a great many people put more weight in some things
than perhaps should be.
> In my opnion, though, I'd still rather have a simple stateful filter. The
I've deployed *BSD-based IPFilter boxen before when I thought state was
appropriate, but I don't think the extra value they added was huge, or
totally necessary to the overall posture of the site. In fact, the
biggest value use for them was what a co-worker defined the other day as
"Spiteful Inspection"- that is to toy with users or attackers based on
traffic. Return-RST in reply to a port scan is kinda fun when you've got
a /16's worth of address space. Dropping high percentages of packets to
www.nekkid-disk-drives.com can also bring much joy to an otherwise boring
day.
Adding state isn't a bad thing, I just don't think it's earthshatteringly
good.
> extra overhead to do TCP and UDP state-matching is not that extreme and
> should not be all that hard to code. You throw away a line about bugs in
> current stateful filters, but it seems to me that they've all been based on
> application / control channel hackery - which is not strictly a part of a
> stateful _packet_ filter (FTP control channel bugs, the PIX mailguard oops
> etc). Has there been anything anyone has noticed that has been a "pure"
> state-keeping error?
I've seen a few state errors over time, but I don't think I've got good
documentation of them.
> To be "market competitive" now an SPF has to virtually be a proxy, judging
> by the amount of application knowledge required. This is not good. It seems
> to me that the Cisco reflexive ACLs and IPFilter are both good "simple"
> stateful solutions that don't try too hard. I like 'em as front-line
> solutions.
I prefer good old extended access lists out front, but then I expect my
border routers to be spending a lot of CPU on BGP and not to have to keep
anything more in memory than basic filter rules. Do reflexive ACLs go to
the VIP cards or use the main router CPU? Can you limit the state table's
size?
> Overall, I guess I can't really think of a nasty attack scenario with a
> two-layer system where the outer firewall is a static filter instead of a
> stateful filter - as long as the inner one is an SPF or an ALG, so I suppose
> to that extent I agree with you. I'm possibly just not as paranoid about the
> risks of code complexity in some solutions. ;)
Darren does a wonderful and mostly thankless job, but the complexity is
there and especially if you're trying to tune for as best of an anti-DoS
or extreme peak as possible it's not all that fun. I still follow the
IPFilter mailing list daily, and it's still not a cakewalk.
> > [So this level is mouss] > [...]
> >
> > >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.
>
> No way. The static filtering in the IOS is the most mature simple packet
> filter around. The reflexive ACLs (which ARE part of the basic IOS and ARE
> stateful - sorry Paul) are, in my opinion, just as good. IPFilter / IPfw
I've touched a grand total of once production router in the last 6 months
and helped someone else out with two more, and none of them have had
reflexive access lists on them- is it included in a base IOS that people
are running in production, or is it "bleeding edge?"
> > (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.
>
> I would argue that for firewalls that's exactly what one should do. It's all
> moot, anyway, since it's not like IPFilter doesn't run on Linux.
It's not moot in that IPFilter doesn't run on Linux on any reasonably new
kernel (2.0.30 was the last if I recall correctly- that rules out 2.2 and
2.4 kernels *and* that was an old version of IPFilter that I wouldn't
recommend running in a production environment.)
> Yes, there's always a security / utility tradeoff, and you make whatever
> decisions are right for your environement, but part of planning for
> intrusion is working out risk / damage control if someone _does_ get in.
Or more imporantly if they're already in.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
