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:
13.7. Fragmentation Settings
Chapter 13. Advanced Settings
528
Summary of Contents for DFL-1600 - Security Appliance
Page 27: ...1 3 NetDefendOS State Engine Packet Flow Chapter 1 NetDefendOS Overview 27 ...
Page 79: ...2 7 3 Restore to Factory Defaults Chapter 2 Management and Maintenance 79 ...
Page 146: ...3 9 DNS Chapter 3 Fundamentals 146 ...
Page 227: ...4 7 5 Advanced Settings for Transparent Mode Chapter 4 Routing 227 ...
Page 241: ...5 4 IP Pools Chapter 5 DHCP Services 241 ...
Page 339: ...6 7 Blacklisting Hosts and Networks Chapter 6 Security Mechanisms 339 ...
Page 360: ...7 4 7 SAT and FwdFast Rules Chapter 7 Address Translation 360 ...
Page 382: ...8 3 Customizing HTML Pages Chapter 8 User Authentication 382 ...
Page 386: ... The TLS ALG 9 1 5 The TLS Alternative for VPN Chapter 9 VPN 386 ...
Page 439: ...Figure 9 3 PPTP Client Usage 9 5 4 PPTP L2TP Clients Chapter 9 VPN 439 ...
Page 450: ...9 7 6 Specific Symptoms Chapter 9 VPN 450 ...
Page 488: ...10 4 6 Setting Up SLB_SAT Rules Chapter 10 Traffic Management 488 ...
Page 503: ...11 6 HA Advanced Settings Chapter 11 High Availability 503 ...
Page 510: ...12 3 5 Limitations Chapter 12 ZoneDefense 510 ...
Page 533: ...13 9 Miscellaneous Settings Chapter 13 Advanced Settings 533 ...