This plugin has two roles, the first is the de-fragmentation of fragmented IP datagrams and the second is to statefully detect IP fragmentation based attacks (such as teardop, boink, etc.). To enable this module you will need to add the 'ipfrag' preprocesser using a configuration line similar to the following:
preprocessor ipfrag mem_hi=4096k mem_lo=3072k minttl=1 timeout=30
In order to prevent denial-of-service attacks, the ipfrag module requires specifying an upper boundary on the amount of memory used to remember fragmented packets. Firestorm will allocate up to 'mem_hi' bytes of memory, when this threshold is hit, Firestorm will prune the oldest packets until only 'mem_lo' bytes are used. This strategy is identical to that used in the BSD/Linux derived IP stacks. The default values are 1MB and 768KB respectively. These are very conservative values, on a hot network you may want to use much more memory.
If Firestorm is not sniffing directly from the same network as your protected hosts then it is possible for an attacker to send IP fragments with low TTLs which the IDS will see but the target system will not (as the packet gets dropped when the TTL expires). Setting this value will make ipfrag ignore packets with TTLs lower than the value. You will usually want to keep this as 0 (the default).
The ipfrag modules can timeout fragment reassembly after a given amount of time (in seconds). For best security you should set this value to be the same as your target OS. The default is 60 seconds, Linux is 30 seconds by default (/proc/sys/net/ipv4/ipfrag_time).
Firestorm can perform stateful inspection of TCP packets to avoid DoS attacks such as stick and snot. When enabled Firestorm tracks TCP sessions and maintains state information (including support for window tracking, PAWS, window-scaling, and many other TCP protocol options).
TCP stream reassembly is still a work in progress so regard it as an experimental feature.
preprocessor tcpstream num_streams=1k minttl=1 reassemble=yes num_flows=1k
There is an upper bound on the number of connections tracked to prevent denial-of-service attacks. When the limit is reached the oldest connections are evicted from the connection tracking table. The default is 2048 which is very conservative. On a hot network this should be much higher.
Sets the minimum ttl value for which Firestorm will examine TCP segments. See the discussion in Section 2.2.1> for more information. By default this value is 0, don't fiddle with it unless you understand what your are doing.
Enables/disables TCP stream reassembly. Can be either 'yes' or 'no'. You should probably keep this enabled at all times, the overhead is pretty minimal.
The tcpstream module also keeps track of application layer state information (termed 'flows'). This setting controls the upper bound on application layer state objects. Set to the same as num_streams for guaranteed 100% coverage. It is set to 1024 by default.
The output directives in your firestorm.conf can make a massive impact on performance if applied well. You should be able to log almost anything and not worry about destroying sensor performance. The Firestorm analysts approach should be to log anything that might matter and just use the console to filter away the chaff. This goal is a long way off yet, but one component is already in place, world-class alert spooling performance. To configure this correctly you must first pay attention to the 'buf' parameter.
The buf parameter sets how large the output buffer should be in bytes. The higher this value, the higher the throughput of alerts, and the less susceptible to denial-of-service attacks you become. The cost of a high value however is reliability, there is a longer period of time where the logs are not written to disk and are lost if Firestorm crashes or is killed forcefully. However, the relatively small detriment to reliability can be amortised by setting log rotation size or time limit.
With Firestorm it is possible to scale your alerting throughput right up to 'enterprise level' with very little hardware investment. Simply place one alert spool on each hard disk in your sensor - alerts will be balanced between them meaning that you only need add a couple of fast SCSI disks to log alerts at full gigabit rate.