-----Original Message-----
From: Martin Mačok [mailto:martin.macok@underground.cz]
Sent: Thursday, August 19, 2004 3:21 AM
To: firewalls@securityfocus.com
Subject: fragment filtering
On Tue, Aug 17, 2004 at 04:08:05PM -0700, David Gillett wrote:
Personally, I don't recommend fragmentation at the IP layer. It's
a massive security hole, and the safest thing to do is to simply
drop all fragmented traffic.
Unfortunately, many of us can't afford to break TCP/IP (fragments are
legal, legitimate and sometimes needed) and deny access from all users
behind obscure links (fragmentation happens) and broken firewalls
(PMTUD does not work).
Legal? Certainly.
Legitimate? Hardly ever, in my experience. (You may have encountered
a different range of cases.)
Needed? In the handful of cases I've encountered where PMTUD failed, a
manual MTU setting fixed the problem. It hasn't failed often enough (again,
in my experience) to become an intolerable burden.
I recommend reading through
RFC 1858 - Security Considerations for IP Fragment Filtering
I'll review this, but I seem to recall that it focussed on the difficulty
of
*inspecting* fragmented traffic for malicious payloads. There's a whole
other order of attacks where the fragmentation itself constitutes the
threat, and the payload is entirely benign. Open discussion of these
appears to be no more than a year old.
[Okay, I've just re-read it, and it's as I feared. While it describes
various
forms of tiny fragment and overlapping fragment attack, it is totally blind
to
inherent vulnerabilities in the fragment reassembly process -- which is
blithely assumed to be someone else's responsibility.]
RFC 3128 - Protection Against a Variant of the Tiny Fragment Attack
I don't think I've seen this one, but I doubt there's a better defence
than
"drop fragmented traffic". I will be surprised and fascinated if it
demonstrates
otherwise.
[Okay, I've read it now, and it basically just pokes a hole in one of the
defences suggested in RFC 1858 -- it does nothing to extend the scope to
include additional vulnerabilities inherent in packet reassembly.]
Martin Mačok
IT Security Consultant
