Fragment handling in PIX for traffic passing through the PIX is done in line with most accepted practices of how to deal with fragments in the networking community. However, with the advent of virtual reassembly PIX can do more than what most internet devices can do in this regard. In general, for most internet devices, the access control mechanisms on the networking device are applied to the first initial fragment of a stream of fragments (F0=0). The rest of the fragments are allowed to pass through without being subjected to additional checks as long as they pass the Layer 3 access control parameters. However, since the PIX does virtual reassembly of packets (please see section on 'Frag Guard' for more details of how virtual reassembly works), it is able to look for further information in the fragments it collects for reassembly. Since the flow information is tagged with each fragment during virtual re-assembly, atleast the layer 4 information is looked at while processing fragments in PIX.
PIX also provides additional protection against certain DOS fragment attacks by using the state information it stores for each connection to validate whether a fragment is to be allowed through. Fragments received for hosts without xlates built for them are discarded. Matching is performed using IP source and destination address and protocol type.
PIX collects all the fragments reaching it, whether it is doing complete reassembly or virtual reassembly on the fragments. It collects fragments until it has verified the fragments' integrity, has checked for common fragment attack patterns (see the following discussion of two such attacks), and has ascertained from the initial fragment that the packet does indeed deserve to be allowed through the PIX based on the stored state information. This allows for a fair amount of security for the hosts sitting behind the firewall. They are protected from the burden of allocating resources for the reassembly of the fragments part of a fragment DoS attack reaching them. PIX does not forward any fragments to the end host if it suspects a fragment attack based on the information in the fragments, if it does not receive all the packet's fragments, or if it does not have a state built for the packet of which the fragments are a part to go through the PIX.
Two types of fragment attacks described in RFC 1858 can be significant threats to a network:
• Tiny fragment attack
• Overlapping fragment attack
The tiny fragment attack is staged by sending an IP packet with the first fragment so small that it contains only the source and destination port information for TCP, not the TCP flags. These are sent in the next fragment. If the access lists were set up to drop or allow packets based on the TCP flags, such as SYN=0 or 1 or ACK=0 or 1, they cannot test the first fragment for this information. Also, since most network devices do not do reassembly of packets passing through them, they do not check the rest of the fragments and let them pass through. This way, an attacker can get an illegitimate packet through to an end host sitting behind these devices.
Newer versions of PIX protect against this type of an attack through the use of virtual reassembly. Virtual re-assembly insures that the flag information whether it is in the first fragment or other fragments is looked at before the packet is forwarded.
Older versions of PIX, protects against this type of attack by using the following algorithm to test packets:
IF FO=1 and PROTOCOL=TCP THEN
FO=1 refers to the second fragment of the tiny fragment attack packet. FO is 1 only if the first fragment (the initial fragment) is so small that the second fragment has an offset of only eight octets, or FO=1. This forces the PIX to drop this fragment, thereby stopping any reassembly at the end host because now one of the IP packet fragments is missing. The "interesting" fields (meaning the fields containing the port information and the flags of the common transport protocols, except TCP) lie in the first eight octets of the transport header, so it isn't possible to push them into a nonzero offset fragment. So the threat of this attack does not exist for these protocols.
The overlapping fragment attack makes use of the conditions set out in RFC 791 for reassembly of IP fragments for end hosts. It describes a reassembly algorithm that results in new fragments overwriting any overlapped portions of previously received fragments. This behavior allows an attacker to send the TCP flags in two fragments of the IP packet. The first fragment contains flags that are allowed to pass through the configured access list (SYN=0). However, the same flags are repeated in the second fragment and this time are set to a different value (SYN=1). The access list allows the first fragment to go through because it matches the requirements. The access list does not run any tests on the remaining fragments. Therefore, when an end host receives the two fragments, it overwrites the first fragment's flags with the ones in the second fragment, defeating the purpose of the access list. This type of attack can be stopped using the same algorithm used for the tiny fragment attack. For all the relevant TCP header information to be contained in the first fragment and to not overlap with another fragment, the second fragment's minimum offset must be 2 (meaning that the first fragment contains at least 16 octets). Therefore, dropping fragments with FO=1, PIX eliminates the possibility of this type of attack as well.
Was this article helpful?