Date: Sun, 3 Sep 2000 09:57:35 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Dragos Ruiu <dr@kyx.net> Cc: cjclark@alum.mit.edu, "Crist J . Clark" <cjclark@reflexnet.net>, Bill Fumerola <billf@chimesnet.com>, Nicolas <list@rachinsky.de>, freebsd-security@FreeBSD.ORG Subject: Re: ipfw and fragments Message-ID: <Pine.NEB.3.96L.1000903094614.69440A-100000@fledge.watson.org> In-Reply-To: <0009030256211M.20066@smp.kyx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 3 Sep 2000, Dragos Ruiu wrote:
> 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.... :-(
And I believe there are even tools available to do this, encapsulating IP
in fragments to allow a tunnel to be created.
> > 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...
However, reassembly does fit more into the application-layer environment,
as for stateless IP-layer firewalls, there are few reasons to perform
reassembly.
> 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.
My recollection was that fragments can be created that do not contain all
of the transport-layer headers. For example, although it should not
occur, ``naturally,'' it is possible to fragment a packet immediately
after the IP header but before the TCP-level port information is include.
Similarly, later fragments may begin at arbitrary points in the datagram,
based on how the PMTU caused the fragmentation at various points on the
path. Therefore, incoming fragments may not have the port information you
refer to in this paragraph: the only information available will be {IP
source, destination, IP ID} plus some offset information, although due to
multi-path routing, it is entirely possible to end up with overlapping
fragments later in the packet.
In fact, a number of spiffy firewall traversal techniques take advantage
of this. ipfw does not currently drop packets with a first fragment
smaller than the minimum IP MTU, or later fragments that overlap the first
minimum IP MTU. It should do so to thwart a number of overlapping
reassembly attacks. The check for a fragment beginning at offset "1" is
cute, but in practice wouldn't stop an attacker writing their own tools.
> 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....
Introducing state on a high-speed firewall hurts. If it can be avoided,
you want to do that. If not.. well, you accept the consequences, but
remember that any storage of state is an opportunity for denial of
service, both due to the lookup performance hit, and the potential for
state exhaustion. Agressive dropping of questionable fragments helps
thwart a number of attacks, and should be used. Fundamentally, I think
you'll find that blocking trojan horse communication is impossible if you
allow any communication through at all. IP tunneling via DNS queries,
SMTP mail service, fragments, and TCP negotiation options have all been
demonstrated; preventing information leaking is effectively impossible,
although you can lower the bandwidth. Instead, concentrate on limiting
the opportunities for placing trojans within your infrastructure, and
detecting when they do happen.
> Does the same behaviour apply to ipf?
Darren Reed will be able to best answer this question, and presumably will
do so.
Robert N M Watson
robert@fledge.watson.org http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services
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?Pine.NEB.3.96L.1000903094614.69440A-100000>