On Thu, 3 Aug 2000, mouss wrote:
> At 16:14 02/08/00 -0400, Paul D. Robertson wrote:
> >If you're filtering, you really don't want that to hit your kernel- that's
> >expensive context-switch wise. Also, different stacks reassemble
> >differently (hence the "fool the IDS" games that have been swelling up for
> >a while.)
>
> The argument is somewhat misleading. it implies that proxy based firewalls
> are stupid beats that destroy performance, and I don't think you were
> meaning this.
Context switches are indeed expensive, and going from a driver that's
filtering non-frags into the OS' TCP stack and back out is more expensive
than staying in the driver (I'm still trying to figure out if it would
even be possible to do it with generic syscalls anyway.)
Having run large expensive machines with proxy servers to protect
thousands of users, and small inexpensive packet filters to also protect
those same users, I think the performance issues inherent with proxies are
pretty obvious. I *don't* think they're as bad as people would have you
believe, but the scale points are significantly different under normal
load. If you want a good parallel, look at the Web server work that's
been going on (since you'll need to proxy HTTP.)
There's a good reason that a major proxy vendor also offers some sort of
packet filtering for the http protocol they already suport with a
traditional proxy.
I'm certinaly not implying that proxies are stupid, and indeed at my last
company my company-wide mandate was that sites would install proxy-based
firewalls. However, the question was about frag reassembly in packet
filters, and those vendors seem to be at the head of the performance
marketing wars.
> yes, if you're _just_ filtering, you'd like to avoid perf reduction, so you
> avoid
> reassembling packets (this is an IP spec after all, only the final host
> should reassemble) and put some more or less effective checks.
>
> However, there are so many traps as you said that many vendors should
> simply consider the "stupid" reassembly and take more time to implement
> an efficient way. get fast if you can, be get safe.
Unfortunately, it'svery difficult to quantify a "safe" firewall, but it's
easy to quantify packets per second. That's why we get marketing selling
firewalls and defining features instead of security engineers.
Consider the fact that many people make firewalll purchase decisions based
on how the GUI is.
> Note that when you do not reassemble, you are considering that unless a bad
> fragment
> is detected, you let frags go through. This is safe if the "protected"
> hosts react correctly
> to incomplete frags. I mean, if a stupid OS decides to panic if a fragment
> with offset XX
> is received and contains some specific data, then you'd better reduce the
> perf by reassembly.
> if all OSes used to handle fragments correctly, then there are far less
> things to check
> on a firewall, but unfortunately, OSes are not (all) that kind (I won't
> cite microsoft as we've seen
> stupid frag attacks succeed on more unixy systems).
Fragment reassembly has proven to be a weak point in stacks. In this
specific point, Checkpoint was trying to do some virtual fragment
reassembly and messed it up. Reassembling fragments at the border is
probably a good protective measure, but may break some things. Like ICMP
blocking breaking PMTU, it's difficult for a novice administrator to
determine how or what got broken when it's implemented.
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.]
