D-Link DFL-260E User Manual page 528

13.7. Fragmentation Settings
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.
• NetDefendOS 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
NetDefendOS 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:
528
Chapter 13. Advanced Settings