[Courses] [Security] Firewall theory -- ICMP

[coldfire]

> 	Yeah.  [grin]  I dig protocol headers.  And Path MTU discovery
> is something that a lot of people don't know that they shouldn't
> firewall out, and I've seen it break things in weird and seemingly
> inexplicable ways.  So I figured it was good to save y'all some pain.

very good point .. this would be impossible to troubleshoot without the
intricate knowledge ;p

> 	On some backbone Internet links, the MTU can be pushed up to
> 9000 bytes or so.  (Weird SONET stuff.)  But 1500 is far and away the
> most common.

there's always hyperlink ... it's like 65000 or something :)

> > when a packet is fragmented, it isn't put back together until it reaches
> > it's destination host.
> 
> 	Usually.  This is what's supposed to happen.  But some firewalls
> will reassemble fragmented packets for you and then forward them to the
> destination host.  I dislike this; I think following the standards is a
> better idea.
> 
> 	The reason that some firewalls do this is because when you're
> filtering based on TCP headers, and your TCP segment has been
> fragmented, you don't have the header information in all fragments to
> filter on.  Take this, for example.
> 
>            |TCP header|-------TCP payload---------|
> 
> When this gets encapsulated into an IP packet, you'll have:
> 
>            ||IP header||TCP header|-------TCP payload---------|
> 
> The TCP header and the TCP payload are the entire payload for the IP
> packet.  So we could also represent the above packet as:
> 
>            ||IP header||---------------IP payload-------------|
> 
> Now, when this IP packet gets fragmented (say it was sent over a FDDI
> link, but the next hop is over an Ethernet link), we get
> 
>   |New IP header|IP payload, part 1|
>   |New IP header|IP payload, part 2|
>   |New IP header|IP payload, part 3|
> 
> which could just as well be represented
> 
>   |New IP header|TCP header|-----TC|
>   |New IP header|P payload---------|
>   |New IP header|------------------|
> 
> So the TCP header information is only in the first fragment.  If your
> firewall is filtering based on TCP header information (like port number,
> for example), it will correctly handle the first fragment, but won't
> really know what to do with the rest.  You can specify what you want
> done with fragments if you like, but there is no easy way to
> differentiate FTP fragments from SSH fragments if they don't have the
> header in there.  So some firewalls reassemble the packets so that they
> can then drop or allow the whole thing.

yeah ... when a datagram gets fragmented, any fragment other than the
first lacks even basic information .. like which protocol the fragmented
datagram was (UDP, TCP, etc.).  however, they're all tied together through
the IP header (in case anyone's wondering now how they get put back
together).  there's an 'identification' field which is a unique value for
a particular IP datagram.  when it's fragmented, the same 'id' is assigned
to each new datagram.  there's a flag which is interpreted as "more
fragments" which can be set so it knows to expect more.  this is used,
because each fragmented datagram only contains it's own size, and it's
offset from the beginning of the original datagram.  with this
information, it can be reconstructed (id, size, offset, more fragments).

now that fragmentation and firewalls was mentioned ... there are a few
attacks that are possible using fragmentation.  the "tiny fragment attack"
is a case where the attacker forces small TCP datagrams to be fragmented
.. so small that some of the TCP header is actually forced into subsequent
datagrams with the hope that the firewall will only examine the header in
the first datagram.  this can be prevented by enforcing a minimum size for
the first fragment.

another neat one is the "overlapping fragment attack."  in this case, the
attacker modifies the offsets of the fragmented datagrams in order to
"overlap" some of the TCP header information.  the first datagram could
pass firewall rules, but then upon reassembly, the port number could be
overwritten, TCP flags could be changed, etc.  enforcing a minimum offset
should fix this.

ftp://ftp.isi.edu/in-notes/rfc1858.txt
ftp://ftp.isi.edu/in-notes/rfc3128.txt

two RFCs reguarding fragmentation security for those who are really
interested now :)

> 	I generally block ICMP message types 9 (Router Advertisement),
> 10 (Router Solicitation), 13 (Timestamp Request), 14 (Timestamp Reply),
> 17 (Address Mask Request), 18 (Address Mask Reply), and 5 (Redirects) to
> the external world, even on my non-paranoid firewalls.  I guess paranoid
> is a relative term.  [grin]

yeah, i block em all anyway ... the average computer on the net shouldn't
require the use of most if not all of those.