IP fragmentation has always been a serious headach, but while in the past it
was a perf killer for destination servers only, it is today a problem for FWs
(and any filtering gateways or the like).
TCP tries to avoid IP fragmentation in favour of TCP "fragmentation". To this
end, things like PMTU discovery are the solution.
so if the end systems implement PMTU discovery, they set the DF (Don't
Fragment)
bit in their packets. This way, when a router finds that the packet is too
large,
it returns an ICMP error ("unreachable/frag needed but DF bit set" message).
This message contains the MTU that should be used. so the sending host can
adapt to this MTU (with multiple routers with silly MTUs, this might happen
multiple times, but it should not as internet routers are generally
"better" than
our silly modems and Ethernet cards...).
But why am I taking about PMTU discovery? the fact is that without it, one can
generate frags just by using a gateway with a small MTU (on BSD, you can
use the ifconfig/route commands to set the MTU or an interface or to a route).
so you can't use this method reliably. But you can then code! You then need
to write IP packets, not just TCP or UDP data as one usually does. To do this,
you open a raw socket (socket(PF_INET, SOCK_RAW, yourprotocolhere)). This
allows you to generate the IP packets you want. On "respectable" systems, this
requires root privileges (but this is possible on _your_ machine:).
to do that, you might refer to all those hackery progs that ping to death
and so,
but you can only check code by Stevens (search unpv1 or unpv2 on google.
unpv=Unix Network Programming, Volume 1 and 2), or you can get a copy of
libnet, a lib to write IP packets!
So what a FW is doing here? well, there are mainly 3 kind of problems with IP
frags (there are others, but 3 is a magic number:):
- When filtering TCP/UDP ports, only the first frag contains the ports. And
worst,
the first frag is not necessarily the first to come! In particular, Linux has
a misfeature (no, not on my head, linuxers!) and sends frags in reverse order
(this is legal after all, but they should really rewrite their list mgmt
[someone to
convince Allan?]). so, a FW that needs to do that must queue the fragments
(Linux proposes to reassemble'em, but this is too much), and this introduces
a perf problem.
- some stacks used to crash when receiving "badly" formatted frags (such as
overlapping frags) The BSD code was always there to explain how to manage
frags,
but coding is not an easy thing (don't go after MS here, honorable OSes
failed too,
including Linux, the difference is that you generally get the patch for
Linux before
you hear of the bug, but you still need to wait some weeks for an MS fix).
- the possiblity of overlapping may induce a filter to allow a packet but
the end
system may have a bad code and manages overlapping differently. so one
just sends a first frag with an authorized port, but sends a second frag that
specifies another port. The second should be ignored (see Stevens "TCP/IP
Illustrated",
vol 2, which documents the BSD code), but developpers have been known to
use the editor much more than the specs/standards:)
now what do FWs do? the classical solution was to check the first frag only,
and hope the end system will reject incomplete sets. but after the crash
stories,
this proved insufficient. so "serious" FWs queue frags (ipf does so but you
need
to configure it to do so).
cheers,
mouss
At 12:25 07/06/01 -0400, Zachary Uram wrote:
>In the GRC.COM article he talked about how the malicious intruder
>was generating "bad" packets which fragmented en route to their
>destination and this produced some cascade effect of millions of
>badly formed packets? How does one generate their own packets? Is
>it very difficult or length code wise? I am just curious what is
>going on under these DDoS attacks. Does firewalls have rules that
>can say "I won't allow any packets of type TCP/IP that have
>packet size great than <FOO>?" What is the solution(s) to
>stopping these DDoS attacks and making it harder for them to be
>successful. Does root problem originate at ISP (ie they see one
>of their networks/subnet/host getting hit with suspicious traffic
>so they stop that inbound traffic?) or where?
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
