Date: Sun, 3 Sep 2000 02:22:52 -0700 From: Dragos Ruiu <dr@kyx.net> To: cjclark@alum.mit.edu, "Crist J . Clark" <cjclark@reflexnet.net> Cc: Bill Fumerola <billf@chimesnet.com>, Nicolas <list@rachinsky.de>, freebsd-security@FreeBSD.ORG Subject: Re: ipfw and fragments Message-ID: <0009030256211M.20066@smp.kyx.net> In-Reply-To: <20000903014453.H62475@149.211.6.64.reflexcom.com> References: <007a01c01457$3b9eff80$e4aa603e@gottt> <0009022351571F.20066@smp.kyx.net> <20000903014453.H62475@149.211.6.64.reflexcom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 03 Sep 2000, Crist J . Clark wrote: > > Or am I missing something here in what you're trying to do? > > To pass all fragments, > > # ipfw add pass ip from any to any frag So I can enble fragmented communications like my UDP video monstergrams through the firewall...ok. There are many reasons why fragments can occur naturally too, like an MTU mismatch along a path, oddball phy links, route changes, or flaps, etc... But this means that to support these packets any fragmented packet can get past your fw. So if I wanted to communicate with my trojan/backdoor on the inside I would just send middle fragments to wake it up and they go through your firewall like ghosts.... :-( > Incoming packet fragments diverted by divert or tee are reassembled be- > fore delivery to the socket. This is good to know... and handy quick and dirty way to get reassembly. Thanks. > > Reassembling packets in general is only really needed for an > application-layer level firewall, which ipfw is not. But as that last > point eludes, that kind of blury once you NAT. Actually IP level fragmentation is definitely not an application layer thing. (I'm not talking about TCP fragmentation.) But I'm quibbling with semantics... My point is just that if you want to really do this appropriately you should tag fragmented head packets that are allowed through and allow subsequent fragments on that dest, port, and id #, and then you should close that hole when you see the end fragment go by, or a timeout occurs. The firewall should not let through any other fragments except those belonging to same datagram(dest,port,id) as allowed head fragment packets. Otherwise, it is either very easy to set up covert channels through your firewalls, or you have to break some spec compliant applications. It is not very difficult to code a packet filter so that it works correctly even for fragments, but you incurr a performance hit, particularly for fragments (lookup), while maybe not much or a negligible overhead for normal traffic. Ok.... now I'm curious, time to look at the ipf and ipfw code.... Does the same behaviour apply to ipf? cheers, --dr -- dursec.com ltd. / kyx.net - we're from the future pgp fingerprint: 18C7 E37C 2F94 E251 F18E B7DC 2B71 A73E D2E8 A56D pgp key: http://www.dursec.com/drkey.asc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0009030256211M.20066>