Date: Mon, 9 Feb 1998 00:27:11 -0700 (MST) From: Marc Slemko <marcs@znep.com> To: Archie Cobbs <archie@whistle.com> Cc: jonny@coppe.ufrj.br, freebsd-hackers@freebsd.org Subject: Re: ipfw logs ports for fragments Message-ID: <Pine.BSF.3.95.980209002024.18733a-100000@alive.znep.com> In-Reply-To: <199802090716.XAA06954@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 8 Feb 1998, Archie Cobbs wrote: > After looking at the code, you're exactly right.. and this is a bug. > > The way it works now is that the port range tests are simply not > applied to packets that have non-zero offsets. This means a rule > with a port range can possibly match fragments of packets it's not > intended for -- independently of whether it's an accept rule, deny > rule, divert rule, or whatever. In other words, port range rules > match non-zero offset fragments too liberally. Ok, yes, that would be a bug then. I had assumed that it was designed the way I mentioned. > If it's an accept rule, this is OK -- because if the packet is > really supposed to be rejected, then the first fragement always > will be, so the entire packet is lost, even if you accidentally > pass other fragments of it. Matching too liberally here is OK. > > However, if it's a deny rule, then you may be unexpectedly blocking > some framgents of packets (and therefore the entire packet), even > if these packets' ports don't fall in the range specified by > the deny rule. Oops. What you want to do here instead is match too > conservatively and NOT match questionable fragments. Possibly. > > In the case of divert, count, skipto, etc. rules... what's the > right answer?? There isn't one unless the kernel keeps track of > all the fragments flying by, and matches them up with their > corresponding initial fragments, and whether that initial fragment > matched or not.. i.e., keeping a lot of extra information around. Even if it did that, it can't do it right. > > Recommendation: > > - At the least, a note should be added to the man page for this. > > - Going further: for accept and deny rules we can special case > the rule and do (very close to) the right thing as discussed above. Yes. This should be done in the short term to make it consistent; either fragments are denied if they could match a non-accept rule just to be safe or they are only denied if they are known to match a non-accept rule just to be sure we don't block things we shouldn't. I have reservations about passing fragments, but that is the normal way most filters do it in my experience so it is probably ok for a default. > > - Going still further: for divert rules, if the packet matches we > have to assemble all the fragments anyway, so we're keeping > most of the state we need to keep already. Once we get the whole > packet, we determine whether or not to divert it or forward it. > > - Going all the way: extend above divert approach to all rules that > match port ranges: for any fragments of packets that *might* match > a port range rule, reassemble the entire packet before applying > the rule. > > Come to think of it, the latter approach would not be that hard > since the kernel is doing this already for locally routed packets, > that is, reassembling packet fragments in a fragment queue. Moreover, > "most" packets don't get fragmentized. It would spread more ugliness > into ip_input.c, but at least the behavoir of the ipfw code would > then be semantically correct... Reassembly sucks. If you have different parts of the fragment following different paths, you lose bigtime. It probably violates any number of TCP specs. I would have to think about it to decide if I hate it enough to say it shouldn't be implemented at all or if there should just be a knob to disable it. I think some of the Linux firewall code does reassembly, and there have been numerous problems with it because of this. OTOH, some people also like it because of this. How about just waiting for IPv6 and not worrying about any of this? <g> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980209002024.18733a-100000>