13.7. Fragmentation Settings

Home Prev	cOS Core 14.00.17 Administration Guide	Next

IP is able to transport up to 65536 bytes of data. However, most media, such as Ethernet, cannot carry such huge packets. To compensate, the IP stack fragments the data to be sent into separate packets, each one given their own IP header and information that will help the recipient reassemble the original packet correctly.

Many IP stacks, however, are unable to handle incorrectly fragmented packets, a fact that can be exploited by intruders to crash such systems. cOS Core provides protection against fragmentation attacks in a number of ways.

Pseudo Reass Max Concurrent

Maximum number of concurrent fragment reassemblies. To drop all fragmented packets, set PseudoReass_MaxConcurrent to 0.

Default: 1024

Illegal Fragments

Determines how cOS Core will handle incorrectly constructed fragments. The term "incorrectly constructed" refers to overlapping fragments, duplicate fragments with different data, incorrect fragment sizes and so on. Possible settings include:

Drop - Discards the illegal fragment without logging it. Also remembers that the packet that is being reassembled is "suspect", which can be used for logging further down the track.
DropLog - Discards and logs the illegal fragment. Also remembers that the packet that is being reassembled is "suspect", which can be used for logging further down the track.
DropPacket - Discards the illegal fragment and all previously stored fragments. Will not allow further fragments of this packet to pass through during ReassIllegalLinger seconds.
DropLogPacket - As DropPacket, but also logs the event.
DropLogAll - As DropLogPacket, but also logs further fragments belonging to this packet that arrive during ReassIllegalLinger seconds.

The choice of whether to discard individual fragments or disallow the entire packet is governed by two factors:

It is safer to discard the whole packet.
If, as the result of receiving an illegal fragment, it is chosen to discard the whole packet, attackers will be able to disrupt communication by sending illegal fragments during a reassembly, and in this way block almost all communication.

Default: DropLog - discards individual fragments and remembers that the reassembly attempt is "suspect".

Duplicated Fragment Data

If the same fragment arrives more than once, this can mean either that it has been duplicated at some point on its journey to the recipient or that an attacker is trying to disrupt the reassembly of the packet. In order to determine which is more likely, cOS Core compares the data components of the fragment. The comparison can be made in 2 to 512 random locations in the fragment, four bytes of each location being sampled. If the comparison is made in a larger number of samples, it is more likely to find mismatching duplicates. However, more comparisons result in higher CPU load.

Default: Check8 - compare 8 random locations, a total of 32 bytes

Failed Fragment Reassembly

Reassemblies may fail due to one of the following causes:

Some of the fragments did not arrive within the time stipulated by the ReassTimeout or ReassTimeLimit settings. This may mean that one or more fragments were lost on their way across the Internet, which is a quite common occurrence.
cOS Core was forced to interrupt the reassembly procedure due to new fragmented packets arriving and the system temporarily running out of resources. In situations such as these, old reassembly attempts are either discarded or marked as "failed".
An attacker has attempted to send an incorrectly fragmented packet.

Under normal circumstances, it is not desirable to log failures as they occur frequently. However, it may be useful to log failures involving "suspect" fragments. Such failures may arise if, for example, the IllegalFrags setting has been set to Drop rather than DropPacket.

The following settings are available for FragReassemblyFail:

NoLog - No logging is done when a reassembly attempt fails.
LogSuspect - Logs failed reassembly attempts only if "suspect" fragments have been involved.
LogSuspectSubseq - As LogSuspect, but also logs subsequent fragments of the packet as and when they arrive
LogAll - Logs all failed reassembly attempts.
LogAllSubseq - As LogAll, but also logs subsequent fragments of the packet as and when they arrive.

Default: LogSuspectSubseq

Dropped Fragments

If a packet is denied entry to the system as the result of the settings in the Rules section, it may also be worth logging individual fragments of that packet. The DroppedFrags setting specifies how cOS Core will act. Possible settings for this rule are as follows:

NoLog - No logging is carried out over and above that which is stipulated in the rule set.
LogSuspect - Logs individual dropped fragments of reassembly attempts affected by "suspect" fragments.
LogAll - Always logs individual dropped fragments.

Default: LogSuspect

Duplicate Fragments

If the same fragment arrives more than once, this can mean either that it has been duplicated at some point on its journey to the recipient or that an attacker is trying to disrupt the reassembly of the packet. DuplicateFrags determines whether such a fragment should be logged. Note that DuplicateFragData can also cause such fragments to be logged if the data contained in them does not match up. Possible settings are as follows:

NoLog - No logging is carried out under normal circumstances.
LogSuspect - Logs duplicated fragments if the reassembly procedure has been affected by "suspect" fragments.
LogAll - Always logs duplicated fragments.

Default: LogSuspect

Fragmented ICMP

Other than ICMP ECHO (Ping), ICMP messages should not normally be fragmented as they contain so little data that fragmentation should never be necessary. FragmentedICMP determines the action taken when cOS Core receives fragmented ICMP messages that are not either ICMP ECHO or ECHOREPLY.

Default: DropLog

Minimum Fragment Length

Minimum Fragment Length determines how small all fragments of a packet can be (with the exception of the final fragment), expressed in bytes.

Although the arrival of too many fragments that are too small may cause problems for IP stacks, it is usually not possible to set this limit too high. It is rarely the case that senders create very small fragments. However, a sender may send 1480 byte fragments and a router or VPN tunnel on the route to the recipient subsequently reduce the effective MTU to 1440 bytes. This would result in the creation of a number of 1440 byte fragments and an equal number of 40 byte fragments. Because of potential problems this can cause, the default settings in cOS Core has been designed to allow the smallest possible fragments, 8 bytes, to pass. For internal use, where all media sizes are known, this value can be raised to 200 bytes or more.

Default: 8

Reassembly Timeout

A reassembly attempt will be interrupted if no further fragments arrive within Reassembly Timeout seconds of receipt of the previous fragment.

Default: 65

Max Reassembly Time Limit

A reassembly attempt will always be interrupted Reassembly Time Limit seconds after the first received fragment arrived.

Default: 90

Reassembly Done Limit

Once a packet has been reassembled, cOS Core is able to remember reassembly for this number of seconds in order to prevent further fragments, for example old duplicate fragments, of that packet from arriving.

Default: 20

Reassembly Illegal Limit

Once a whole packet has been marked as illegal, cOS Core is able to retain this in memory for this number of seconds in order to prevent further fragments of that packet from arriving.

Default: 60