IP is able to transport up to 65,536 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. Protection against fragmentation attacks is provided 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.System:/>
set Settings FragSettings PseudoReass_MaxConcurrent=1024
Default: 1024
Illegal Fragments
Determines how cOS Stream will handle incorrectly constructed fragments. The term "incorrectly constructed" refers to overlapping fragments, duplicate fragments with different data, incorrect fragment sizes, etc. 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.
It is safer to discard the whole packet.
If, as the result of receiving an illegal fragment, you choose 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.
System:/>
set Settings FragSettings IllegalFrags=Drop
Default: DropLog – discards individual fragments and remembers that the reassembly attempt is "suspect".
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 Stream 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.
System:/>
set Settings FragSettings DuplicateFragData=Check8
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 Stream 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.
The following settings are available for FragReassemblyFail:
System:/>
set Settings FragSettings FragReassemblyFail=LogSuspectSubseq
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 Stream will behave. Possible settings for this rule are as follows:System:/>
set Settings FragSettings DroppedFrags=LogSuspect
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:System:/>
set Settings FragSettings DuplicateFrags=LogSuspect
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 Stream receives fragmented ICMP messages that are not either ICMP ECHO or ECHOREPLY.System:/>
set Settings FragSettings FragmentedICMP=DropLog
Default: DropLog
Minimum Fragment Length
Minimum Fragment Length determines how small all fragments (with the exception of the final fragment) of a packet can be 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 the potential problems this can cause, the default settings are 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.
System:/>
set Settings FragSettings MinimumFragLength=8
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.System:/>
set Settings FragSettings ReassTimeout=65
Default: 65
Max Reassembly Time Limit
A reassembly attempt will always be interrupted Reassembly Time Limit seconds after the first received fragment arrived.System:/>
set Settings FragSettings ReassTimeLimit=90
Default: 90
Reassembly Done Linger Limit
Once a packet has been reassembled, cOS Stream 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.System:/>
set Settings FragSettings ReassDoneLinger=20
Default: 20
Reassembly Illegal Linger Limit
Once a whole packet has been marked as illegal, cOS Stream is able to retain this in memory for this number of seconds in order to prevent further fragments of that packet from arriving.System:/>
set Settings FragSettings ReassIllegalLinger=60
Default: 60
Reject Minimal Fragment
Send an ICMP parameter problem message when the non-last fragment is smaller than the minimum allowed length which is specified by IPv6MinNonFinalFragment.System:/>
set Settings FragSettings RejectMinimalFrag=No
Default: No
IPv6 Minimum Non-final Fragment
This is the minimum allowed length of non-last IPv6 fragments.System:/>
set Settings FragSettings IPv6MinNonFinalFragment=640
Default: 640
IPv6 Nop Fragments
The packet is the first and last fragment at the same time (and by definition not a fragment, though it has got a fragment header). Note that these packets are legal, and serves a purpose as an non-IPv6 to IPv6 connection mechanism (see RFC2460 for more details).System:/>
set Settings FragSettings IPv6NopFrags=Ignore
Default: Ignore