"Paul D. Robertson" wrote:
>
> On Wed, 10 Apr 2002, Mikael Olsson wrote:
>
> > (unless specifically asked to do so, of course)
>
> You're not getting off that easy!
I'll take that as specifically asking me to be specific.
> > Isn't it fairly common for (commercial) proxy firewalls to apply
> > packet filtering on traffic to the firewall itself?
>
> Now it's very common. But even without that, it's difficult to see a
> scenerio where a proxy-based firewall that's set up correctly has any
> different exposure than a packet filter
Hey! If you get to assume "set up correctly" (especially for turnkey
boxes), I get to assume "not brain-damaged". I reclaim all the points
I've given away on account of miscellaneous such SPFs so far in this
topic! :)
> > If you're refering to simply filling up the available reassembly
> > slots, that will DoS fragment reassembly on a proxy equally well.
>
> It depends on how much checking is done- there was a point in time where
> at least one major PF wouldn't check sequence numbers before reassembling
> or rejecting TCP frags!
The proper way to do pseudo-reassembly (I'm not talking additional
consistency checks here) is:
- Queue non-first fragments until the first fragment is seen
- If the first fragment doesn't contain a complete L4 header,
reject the reassembly
(Yes, somewhat evil, but then again I've never ever seen this
cause problems for anything but fragrouter.)
- Do state lookup / rule decision on first fragment
- Start passing stored and subsequent fragments. Only pass the
"next expected" fragment. Never allow overlaps.
Get this rather simple job done right, and you won't see
fragmentation problems. The problem, generally speaking,
would seem to be getting it right, however.
In our case, the fragment handler algorithm hasn't needed to be
changed since uhm... '98 i believe (although some of the hash
lookups and stuff have been optimized over time). Every time
there's been a new fragmentation attack, we've been over it to
verify that it's doing what it should be doing, and.. well..
it has. (Actually to the point where I'm starting to worry about
"lulled into thinking we're safe", so I'm re-verifying it again
just now.)
Now, as to how this translates to a point to SPFs I can't
really say. Stacks should behave this way in general.
I guess what I'm saying is that I refuse to give this away
as a point to proxies :)
> [on general-purpose OS stacks]
> Right after we got them all fixing SYN floods, we
> asked for frag handling to work the same way.
It would appear that not everyone was listening. ;)
> fixing the stack isn't something that generally happens correctly
> on the first patch.
(Flame bait coming up :))
No, but if you write it from scratch with the assumption that
it will be constantly overloaded, it is actually entirely
possible to get it right on the first run, and perform well
when it's NOT overloaded.
> > Now, you either need to stop dropping points that we (I? ;)) haven't
> > finished arguing, or tell me where to pick up my cigar :)
>
> I've only dropped the ones that will spiral into their own multi-megabyte
> threads (Firewall as an IDS indeed!)
What's wrong with having the firewall actually _LOG_ what it's
dropping? (For packet/fragment consistency checks; not just
log clauses specified in the ruleset)
> Fortunately for you, I don't smoke, so you'll just
> be forwarding beers ;)
Given what you guys brew over there, I see why you'd
want me to do that ;)
--
Mikael Olsson, Clavister AB
Storgatan 12, Box 393, SE-891 28 �RNSK�LDSVIK, Sweden
Phone: +46 (0)660 29 92 00 Mobile: +46 (0)70 26 222 05
Fax: +46 (0)660 122 50 WWW: http://www.clavister.com
Ynlre 8 frphevgl fbyhgvbaf: uggc://yneg.onqs00q.bet
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
http://lists.gnac.net/mailman/listinfo/firewalls
