On Thu, 11 Apr 2002, Mikael Olsson wrote: > I'll take that as specifically asking me to be specific.
Noooo, you should take that as specifically not specifically asking you to specificly be specific. > 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! :) Actually, most "turn key" installations don't expose things that aren't proxies to all interfaces anymore. Also, since most are hybrids, they normally also packet filter everything on OSen where you can't just rip out all the non-proxy stuff (Solaris anyone?.) > 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. 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. > 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 :) One correct implementation does not an architecture prove :-P > > [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. ;) 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. > > 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. 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. > > 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) > 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 ;) > > 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 ;) Because I mostly drink Guinness[1] :-P Paul [1] There are *lots* of GOOD American breweries, they're just not the large ones, but Guinness is the best mass-produced beer so .ie wins- desplite having an innavigable and ugly Web site. ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions [EMAIL PROTECTED] which may have no basis whatsoever in fact." _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
