Section 11.1 Fragmentation Attacks

   


11.1 Fragmentation Attacks

graphics/fivedangerlevel.gif

The reason TCP and UDP are more formally referred to as TCP/IP and UDP/IP is that the TCP and UDP protocols sit "on top" of the IP protocol. The IP level worries about such mundane things as breaking up packets larger than the hardware's packet size (approximately 1500 bytes for Ethernet and varying for PPP) and then reassembling them into a single TCP or UDP packet on the recipient system. The TCP or UDP header containing port numbers and IP addresses is just data to the IP level. Thus, this very important header is only in the first IP packet when a large packet is broken up for transport.

So what happens normally to all those carefully constructed firewall rules as they apply to the subsequent packets of a TCP or UDP message? Recall that the firewall cannot know what port number or IP address is involved in these subsequent IP packets. Well, because dropping them would cause blocking of all large packets, the subsequent packets are let through unchallenged. (It is possible to use ipchain's -f flag to specify rules that apply only to subsequent partial packets so that a rule to drop them may be added.) This allows a number of attacks. Typically these are DoS attacks because of the kernel on the recipient system buffering up all these packets and running out of buffer space because the attacker deliberately generated packets that do not reassemble correctly.

However, attacks exist that allow the attacker to bypass firewall security and send any data of the attacker's choosing to ports on the "protected" systems beyond the firewall. These typically involve creating such a tiny first packet that the port number and IP address are in a subsequent packet.

In the typical configuration where a perfect firewall is assumed but not present and where systems beyond the firewall are vulnerable in the event of a firewall breach this could be disastrous. (See "Intracompany Firewalls to Contain Fires" on page 84 for suggestions on preparing for this.) The best solution is to build the Linux kernel on the firewall system with the

 
 CONFIG_IP_ALWAYS_DEFRAG 

defined constant. Then, on system startup, activate defragging by giving the bash shell command

 
 echo 1 > /proc/sys/net/ipv4/ip_always_defrag 

or the tcsh shell command

 
 echo 1 >! /proc/sys/net/ipv4/ip_always_defrag 

This will cause the firewall system to reassemble all packets that the sender is intending to transmit. Then, the reassembled packet will be subject to the firewall rules properly. This also has the substantial advantage that corrupted fragments will not be passed on to possibly vulnerable systems inside the firewall. Although IP Chains has the capability to block all subsequent fragments, this will both block legitimate traffic and inflict corrupt packets on "inside" systems that are vulnerable to these attacks.


   
Top


Real World Linux Security Prentice Hall Ptr Open Source Technology Series
Real World Linux Security Prentice Hall Ptr Open Source Technology Series
ISBN: N/A
EAN: N/A
Year: 2002
Pages: 260

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net