firestorm-doc.xml

Firestorm NIDS是一个性能非常高的网络入侵检测系统 (NIDS)。目前

 packet socket support. This plugin takes two options 'if' and 'blocks'
 where 'if' is an interface to listen on and blocks is a number
 specifying how many blocks to use in the ringbuffer. Generally the
 higher this number the more memory is used and the less packets will
 be dropped - you can look in the firestorm log output to get an idea
 of how much memory (in kilobytes) it translates to. (eg: if='any'
 blocks=128).
</para>
</sect3>
<sect3>
<title>tcpdump</title>
<para>
 This plugin is a hi-speed alternative to the pcapfile plugin and
 doesn't depend on libpcap. This plugin is recommended over and above
 pcapfile, although your mileage may vary. It takes the same arguments
 as pcapfile (eg: file='./myfile.cap').
</para>
<para>
 Actually most operating systems (including Linux) don't actually do
 readahead on mmap() accesses so if the data isn't being served up from
 your page cache (ie: actually being read in from disk) this will be
 slower.
</para>
</sect3>
</sect2>

<sect2>
<title>effective_uid / effective_gid</title>
<para>
 These directives are ignored unless firestorm is run as root, their
 purpose is to prevent firestorm from actually processing any data
 while running with a privileged EUID (effective user id). They take
 precisely one argument which is a numeric UID or GID respectively.
</para>
<screen>
	effective_uid 303
	effective_gid 303
</screen>
</sect2>

<sect2>
<title>load_plugins</title>
<para>
 Firestorm is totally plugin based and cannot function without loading
 the required plugins. This directive allows you to specify paths to
 directories full of plugins to load. Note that you can load plugins
 from outside the chroot. For each directory specified firestorm will
 attempt to load all plugin files contained therein, directories are NOT
 recursed.
</para>
<screen>
	load_plugins /usr/lib/firestorm/capture
	load_plugins /usr/lib/firestorm/protocols
	load_plugins /usr/lib/firestorm/detection
</screen>
</sect2>

<sect2>
<title>load_plugin</title>
<para>
 This directive is similar to load_plugins except that it loads a single
 plugin file. Firestorm will fail if the plugin specified cannot be
 loaded.
</para>
<screen>
	load_plugin /usr/lib/another-plugin.so
</screen>
</sect2>

<sect2>
<title>preprocessor</title>
<para>
 The preprocessor directive instructs firestorm-nids to activate any
 optional modules. Currently the only additional modules available are
 'tcpstream' and 'ipfrag'. See the specific sections on these modules
 for more information.
</para>
<screen>
	preprocessor name &lt;args&gt;...
</screen>
</sect2>

<sect2>
<title>logfile</title>
<para>
 This directive is perhaps a misnomer. It essentially tells firestorm
 to daemonize and send all diagnostic messages to a logfile. The single
 argument is the path to the logfile. You will nearly always want to
 set this directive. Note that the logfile is overwritten every time
 that firestorm is run. It is only intended as a record of what happened
 last time firestorm was run for diagnostic purposes. If you do not set
 this directive, firestorm will not daemonize and output messages to
 standard out (screen).
</para>
<screen>
	logfile firestorm.log
</screen>
</sect2>

<sect2>
<title>output</title>
<para>
 Firestorm outputs alerts in elog format to a spool directory whose path
 is specified by the output directive. Firestorm can do automatic log
 rotation when the logs reach a specified filesize, or a certian amount
 of time has elapsed. Firestorm never rotates empty logs. Logfiles that
 have been successfully spooled have names beginning with '@', they are
 guaranteed to be written to disk, and not-corrupt. The current logfile
 takes the name 'alert.elog'. You should not read from or use this file
 it is not guaranteed to be in any particular state.
</para>
<para>
 The arguments for this directive are pretty self explanatory from the
 example below. One thing to take note of is that if the 'minutes'
 parameter is set to 0, firestorm won't rotate by time and if the 'size'
 directive is set to 0, firestorm won't rotate by size. If both are set
 firestorm rotates on whichever comes first. The buf parameter is more
 thoroughly explained in the 'high performance alert spooling' section.
</para>
<screen>
	output dir='log' minutes=60 size=512K stormwall=none buf=16k
</screen>
</sect2>

<sect2>
<title>signatures</title>
<para>
 The signatures directive tells firestorm where to load signatures from,
 you may load as many signature files as you wish. Currently the only
 supported signature format is snort. You can't put signatures, variables
 or anything snort related directly in to firestorm.conf.
</para>
<screen>
	signatures snort ./snort-rules/classification.config
	signatures snort ./snort-rules/shellcode.rules
</screen>
</sect2>

</sect1>

<sect1 id="advanced-config">
<title>Advanced Configuration</title>

<sect2>
<title>IP Defragmentation</title>
<para>
 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:
</para>
<screen>
	preprocessor ipfrag mem_hi=4096k mem_lo=3072k minttl=1 timeout=30
</screen>
<sect3>
<title>mem_hi / mem_lo</title>
<para>
 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.
</para>
</sect3>

<sect3>
<title>minttl</title>
<para>
 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 sytem
 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).
</para>
</sect3>

<sect3>
<title>timeout</title>
<para>
 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).
</para>
</sect3>

</sect2>

<sect2>
<title>TCP Stateful Inspection and Stream Reassembly</title>
<para>
 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).
</para>
<para>
 TCP stream reassembly is a work in progress.
</para>
<screen>
	preprocessor tcpstream num_streams=1k minttl=1 reassemble=yes num_flows=1k
</screen>
<sect3>
<title>num_streams</title>
<para>
 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.
</para>
</sect3>

<sect3>
<title>minttl</title>
<para>
 Sets the minimum ttl value for which firestorm will examine TCP
 segments. See the discussion above for more information. By default
 this value is 0, don't fiddle with it unless you understand what your
 are doing.
</para>
</sect3>

<sect3>
<title>reassemble</title>
<para>
 NOT IMPLEMENTED. Enables/disables TCP stream reassembly. Can be either
 'yes' or 'no'.
</para>
</sect3>

<sect3>
<title>num_flows</title>
<para>
 NOT IMPLEMENTED. The tcpstream module also keeps track of application
 layer state information (termed 'flows'). This sets the upper bound on
 application layer state objects. Set to the same as num_streams for now.
 It is set to 1024 by default.
</para>
</sect3>

</sect2>

<sect2>
<title>High Performance Alert Spooling</title>
<para>
 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.
</para>
<para>
 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 succeptible 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
 detrement to reliability can be amortized by setting log rotation size
 or time limit.
</para>
<para>
 For now it is only possible to set one spool directory. Future releases
 will allow you to use multiple spools on different disks and alerts
 will be balanced between them. This will allow you to achive massive
 throughput even under a concerted DoS attack.
</para>
</sect2>

</sect1>

</chapter>

</book>