IDS Evasion Part II

  Another form of IDS evasion uses fragmentation to to evade the pattern matching function of the sensor. When a packet has to traverse a network with a smaller MTU than the network it originated from, the packet must be broken down into smaller chunks. In order for the destination host to be able to reassemble those fragments, IP uses an ID field to identify all of the packets that are part of the fragmentation train. Each packet will also have a fragmentation offset, which is it's order in the original packet.
Ethernet has an MTU of 1500 bytes. If the packet traverses a network with an MTU smaller than this, say 576 bytes, the maximum amount of data that could be carried in the first packet would be 576 bytes, minus 20 bytes for the IP header (assuming no IP options) and the size of the layer 4 header. If this were TCP, that would anywhere from 20 bytes (minimum) to 60 bytes (maximum).
   Let's say the TCP header is also 20 bytes for simplicity. The data in that packet would be 536 bytes. When reassembling that stream, the data in the first packet would have an offset (order) of 0 (counting begins at 0, not 1). The next packet's data offset would start at 536 (the previous packet would be contained in the first 0-535 bytes) and so forth. But what if the second packet gave a fragmentation offset of 516, instead of 536. This would produce fragmentation overlap, that is, the second packets data overlaps the first packets last 20 bytes. What does the network stack do with this data? Does it overwrite the last 20 bytes of the first packet, or, does it discard the first 20 (0-19) bytes of the second packet and start writing byte 20 at the 536 byte offset?
   What a network stack does here is identified by one of two methods, called favor old or favor new (or first or last). Not all network implementations use the same method. For example, Windows hosts use the favor old method. Linux uses favor new. In order for your IDS to properly reassemble fragments the same way as the destination host will, it needs to know whether the hosts it's protecting use favor old or favor new. Why is this an issue? Say an attacker sends a fragmented attack to a server. Withing those frag packets, he crafts one packet with some bytes of extra data that are not part of the attack, but sends the next packet with an overlapping offset to overwrite those packets, because the server is Linux based (favor new). As long as your IDS is set to favor new, it will correctly overwrite the bogus data as well, correctly detecting the attack. But if your sensor is set to keep the original data in the first packet, it will miss the exploit because it will use the bogus data in it's reassembled stream, which will not match the signature.
If you have a targeted sensor near the assets it's protecting and they are all on the same platform, like a Web farm of servers running Apache/Linux, you can set your IDS correctly to reassemble fragments the same way they servers do. But an edge sensor may be protecting assets of differing operating systems that use different methods for dealing with overlapping fragments. That's why targeted sensors that protect a subset of assets and are physically situated close to those assets on the network are preferable.