"Paul D. Robertson" wrote: > > [on pseudo-reassembly] > Ah, but with "never allow overlaps," do you take the first thing, or > reject the packet? If you've already let the first frag go, IMO you're > skating a fine line. I've always preferred to see reassembly before > passing with a complete drop if anything overlaps.
Depends. If the overlap occurs before the first fragment is seen, the entire reassembly gets invalidated and no packets get through. If, on the other hand, we see one or a few well-behaved, ordered fragments before an overlapping one, the first ones will get through. However, the effect on the target host is the same as for packet loss, so I'm not sure I agree with "skating a fine line". (But, yeah, a "stop reassembling this you dummy" ICMP error that one could send would be nice ;)) I must admit that I've been pondering on the benefits of letting users enable full reassembly before delivery. It may, theoretically speaking, offer a little extra protection. On the other hand, it becomes much more susceptible to DoS. Then AGAIN, linux machines deliver all fragments "backwards", so anything fragmented that goes out from a linux box and passes a pseudo-reassembling firewall is always susceptible to DoS. Not to mention increased round trip times since the firewall ALWAYS has to wait for the first fragment to arrive. But as it stands now, that's SEP, as far as I'm concerned. > One correct implementation does not an architecture prove :-P Well, as I said: "Hey! If you get to assume 'set up correctly', I get to assume 'not brain-damaged'." :) > Not everyone was asked- a lot of OSen weren't used for Web > servers back then, and some of those that were aren't used > much at all anymore. By the way, did you know that you can DoS fragment reassembly on an entire LAN of NT4SP0--5 machines (I believe Win2K without servicepacks too) through the bandwidth equivalent of a 300bps modem and still have enough bandwidth for a (laggy) IRC session? :) However, I guess I must admit that this got better in NT4SP6 and W2KSP[n]. > That's true of anything that may see duress, however your "if" isn't even > close to the norm. It'd be interesting if all the firewall vendors > published known bugs/kloc specs for their development teams. "For their development teams to see" or "for anyone to see"? (And what's a "kloc"? :)) > > 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) > > Nothing wrong with it (the capability is a requirement in our > certification criteria AFAIR)- I'm just going to wait for you to > accurately log a 20m flood attack at 1Gb/s ;) Don't hold your breath :P However, I'd also like to see that stream cross more than two routers without losing packets, thus making it impossible to log it accurately. ... but now we're crossing into IDS territory. Hrm... I believe I started out attacking the proxy architecture. How on earth did you manage to turn this around and put me in a defensive position? I must be getting slow. Let's see now, what more mud slinging can I do.. Oh yeah, Barbie(tm) software with buffer overruns in it, pre-installed on proxies! And sendmail used as mail proxy! And BIND as DNS proxy! Oooo now _there's_ a whole ocean of possible shin-kicking that I haven't even begun to explore in this discussion! :) -- 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 "Senex semper diu dormit" _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
