To enable Network Intrusion Detection System (NIDS) mode so that you don't record every single packet sent down the wire, try this:
./snort -dev -l ./log -h 192.168.1.0/24 -c snort.conf
where snort.conf is the name of your snort configuration file. This will
apply the rules configured in the
snort.conf file to each packet to decide
if an action based upon the rule type in the file should be taken. If you don't
specify an output directory for the program, it will default to
One thing to note about the last command line is that if Snort is going to be used in a long term way as an IDS, the -v switch should be left off the command line for the sake of speed. The screen is a slow place to write data to, and packets can be dropped while writing to the display.
It's also not necessary to record the data link headers for most applications, so you can usually omit the -e switch, too.
./snort -d -h 192.168.1.0/24 -l ./log -c snort.conf
This will configure Snort to run in its most basic NIDS form, logging packets that trigger rules specified in the snort.conf in plain ASCII to disk using a hierarchical directory structure (just like packet logger mode).
There are a number of ways to configure the output of Snort in NIDS mode. The default logging and alerting mechanisms are to log in decoded ASCII format and use full alerts. The full alert mechanism prints out the alert message in addition to the full packet headers. There are several other alert output modes available at the command line, as well as two logging facilities.
Alert modes are somewhat more complex. There are seven alert modes available at the command line: full, fast, socket, syslog, console, cmg, and none. Six of these modes are accessed with the -A command line switch. These options are:
Fast alert mode. Writes the alert in a simple format with a timestamp, alert message, source and destination IPs/ports.
Full alert mode. This is the default alert mode and will be used automatically if you do not specify a mode.
Sends alerts to a UNIX socket that another program can listen on.
Turns off alerting.
Sends ``fast-style'' alerts to the console (screen).
Generates ``cmg style'' alerts.
Packets can be logged to their default decoded ASCII format or to a binary log file via the -b command line switch. To disable packet logging altogether, use the -N command line switch.
For output modes available through the configuration file, see Section .
Command line logging options override any output options specified in the configuration file. This allows debugging of configuration issues quickly via the command line.
To send alerts to syslog, use the -s switch. The default facilities for the syslog alerting mechanism are LOG_AUTHPRIV and LOG_ALERT. If you want to configure other facilities for syslog output, use the output plugin directives in snort.conf. See Section for more details on configuring syslog output.
For example, use the following command line to log to default (decoded ASCII) facility and send alerts to syslog:
./snort -c snort.conf -l ./log -h 192.168.1.0/24 -s
As another example, use the following command line to log to the default facility in /var/log/snort and send alerts to a fast alert file:
./snort -c snort.conf -A fast -h 192.168.1.0/24
When Snort generates an alert message, it will usually look like the following:
[**] [116:56:1] (snort_decoder): T/TCP Detected [**]
The first number is the Generator ID, this tells the user what component of Snort generated this alert. For a list of GIDs, please read etc/generators in the Snort source. In this case, we know that this event came from the ``decode'' (116) component of Snort.
The second number is the Snort ID (sometimes referred to as Signature ID). For a list of preprocessor SIDs, please see etc/gen-msg.map. Rule-based SIDs are written directly into the rules with the sid option. In this case, 56 represents a T/TCP event.
The third number is the revision ID. This number is primarily used when writing signatures, as each rendition of the rule should increment this number with the rev option.
If you want Snort to go fast (like keep up with a 1000 Mbps connection), you need to use unified2 logging and a unified2 log reader such as barnyard2. This allows Snort to log alerts in a binary form as fast as possible while another program performs the slow actions, such as writing to a database.
If you want a text file that's easily parsed, but still somewhat fast, try using binary logging with the ``fast'' output mechanism.
This will log packets in tcpdump format and produce minimal alerts. For example:
./snort -b -A fast -c snort.conf
The default way in which Snort applies its rules to packets may not be appropriate for all installations. The Pass rules are applied first, then the Drop rules, then the Alert rules and finally, Log rules are applied.
|Note: Sometimes an errant pass rule could cause alerts to not show up, in which case you can change the default ordering to allow Alert rules to be applied before Pass rules. For more information, please refer to the -alert-before-pass option.|
Several command line options are available to change the order in which rule actions are taken.
Pass rules are special cases here, in that the event processing is terminated when a pass rule is encountered, regardless of the use of -process-all-events.