Chapter 2. Firestorm NIDS Sensor

2.1. Configuration File

The firestorm-nids program has one optional command line argument to specify the path to the configuration file. If firestorm-nids is run with no arguments it will default to /etc/firestorm.conf. The Firestorm configuration file is an ASCII text file with UNIX line terminators. If a line is empty of begins with a hash (#) character it is ignored. It consists of zero or more lines of the format:

	directive <parameters>...

Arguments to various directives are usually quite consistent and look something like this:

	directive string="hello" str='foobar' int=23 size=48K bigsize=12MB

The notational convention '<args>...' will be used from now on to denote this style of arguments. All configuration directives are enumerated in detail below.

2.1.1. firestorm_root

This directive tells Firestorm which directory to move to when run. All paths mentioned in the config file are relative to this path. You shouldn't run Firestorm inside some directory which you later hope to unmount ;)

	firestorm_root /var/lib/firestorm

2.1.2. chroot

Firestorm can run inside a so-called "chroot jail", this prevents Firestorm from being able to read files located outside the jail. You will usually want to say yes to this for security reasons. Note that technically it is actually possible for a skilled attacker to break out of a chroot jail, nothing can replace code audit...

	chroot yes
	chroot no

2.1.3. capture

The capture directive instructs firestorm-nids where to capture network traffic from. Firestorm is quite unique in the sense that it can capture from a variety of sources and a programmer can quite easily write extensions to capture from new data sources. Only one capture can be used at once.

	capture type <args>...

I will briefly enumerate the capture types currently supported by Firestorm, and the usage of each. Note that although filenames are relative to the firestorm_root, you can still access files outside of the chroot. Also note that none of these plugins set promiscuous mode by themselves. You must enable promisucous mode yourself if you require it. This may be as simple as 'ifconfig ifname up promisc', see your OS vendors documentation for more details.

2.1.3.1. pcap

Most people will want to capture from the live network with libpcap. This plugin has only one option 'if' which is used to specify which interface to listen on. (e.g: if='eth0' or if='any' to listen on all interfaces).

2.1.3.2. pcapfile

Firestorm can also capture from libpcap files, such as those created by tcpdump or ethereal. This plugin also has only one argument 'file' to specify the filename. (e.g: file='./captures/mynetwork.cap').

2.1.3.3. linux

Firestorm has the ability to support high-speed OS specific capture plugins. Use this plugin if you run a recent Linux kernel with mmap() 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. (e.g: if='any' blocks=128).

2.1.3.4. tcpdump

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 (e.g: file='./myfile.cap').

2.1.3.5. fagrouter

This plugin is for simulating TCP traffic which has been randomly packetized to evade NIDS which do not perform TCP stream reassembly. It's purpose is for testing and validation of application layer decodes running atop the TCP protocol. You can set files containing the client and server sides of the stream and also set a maximum segment size (eg: cl='client' sv='server' maxseg='512').

2.1.4. effective_uid / effective_gid

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.

	effective_uid 303
	effective_gid 303

2.1.5. load_plugins

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.

	load_plugins /usr/lib/firestorm/capture
	load_plugins /usr/lib/firestorm/protocols
	load_plugins /usr/lib/firestorm/detection

2.1.6. load_plugin

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.

	load_plugin /usr/lib/another-plugin.so

2.1.7. preprocessor

The preprocessor directive instructs firestorm-nids to activate any optional modules. Currently the only additional modules available are tcpstream and ipfrag.

	preprocessor name <args>...

2.1.8. logfile

This directive is perhaps a misnomer. It essentially tells Firestorm to daemonize and send all diagnostic messages to a log file. The single argument is the path to the log file. You will nearly always want to set this directive. Note that the log file 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).

	logfile firestorm.log

2.1.9. output

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 file size, or a certain amount of time has elapsed. Firestorm never rotates empty logs. Log files that have been successfully spooled have names beginning with '@', they are guaranteed to be written to disk, and not-corrupt. The current log file takes the name 'alert.elog'. You should not read from or use this file it is not guaranteed to be in any particular state.

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 Section 2.2.3>.

	output dir='log' minutes=60 size=512K stormwall=none buf=16k

2.1.10. signatures

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.

	signatures snort ./snort-rules/classification.config
	signatures snort ./snort-rules/shellcode.rules