Recipe 9.22 Detecting Intrusions with Snort

9.22.1 Problem

You want to notice if your system is under attack from the network.

9.22.2 Solution

To run as a network intrusion detection system, with binary logging, and alerts sent to the system logger:

# snort -c /usr/local/share/rules/snort.conf -b -s

To run Snort in the background, as a daemon:

# snort -D [-u user] [-g group] [-m umask] -c ...

9.22.3 Discussion

Snort is most valuable when run as a full-fledged NIDS:

# snort -c /etc/snort/snort.conf ...                   SuSE installation
# snort -c /usr/local/share/rules/snort.conf ...       Manual installation

The configuration file includes a large number of pattern matching rules that control logging and alerts.

In this mode of operation, packets are recorded (logged) when they match known signatures indicating a possible intrusion. Use the -b option for efficient logging to binary libpcap-format files. [Recipe 9.24] The -N option disables logging if you want alerts only, but we don't recommend this: the logs provide valuable context about the events that triggered the alerts.

Alerts can be directed to a wide range of destinations. We recommend the system logger [Recipe 9.27] because:

• It's efficient.

• It's convenient (and enlightening) to correlate Snort's messages with those of other daemons, your firewall, and the kernel—these are all recorded in the system log.

• Tools like logwatch [Recipe 9.36] can scan the log files effectively and provide notification by email, which works well with high-priority alerts.

Use the -s option to direct alerts to the system logger. By default, alerts are sent using the auth facility and info priority. This can be changed by uncommenting and changing a line in snort.conf, e.g.:

output alert_syslog: LOG_LOCAL3 LOG_WARNING

At press time, the latest version of Snort (1.9.1) has an unfortunate bug: it incorrectly requires an extra argument after the -s option. If you are experiencing confusing command-line syntax errors, try providing this extra argument (which will be ignored). The Snort documentation also erroneously claims that the default facility and priority are authpriv and alert, respectively. If you are not seeing alert messages in /var/log/secure (typically used for authpriv), check /var/log/messages (which is used for auth) instead.

To disable alerts entirely (e.g., for rules-based logging only), use the -A none option. We don't recommend this for routine operation, unless you have some other special mechanism for producing alerts by examining the logs.

To run Snort in the background, as a daemon, use the -D option. This is the recommended way to launch Snort for continuous, long-term operation. Also, Snort is best run on a dedicated monitoring system, ideally sniffing traffic on an unconfigured, "stealth" interface. [Recipe 9.16]

On SuSE systems, you can enable Snort to start automatically at boot time with the chkconfig command:

# chkconfig snort on

Edit /var/adm/fillup-templates/sysconfig.snort to specify the desired snort command-line options.

On Red Hat systems, the simplest way to start Snort at boot time is to add a command to /etc/rc.d/rc.local. Alternately, you can copy one of the other scripts in /etc/init.d to create your own snort script, and then use chkconfig.

Snort must be run as root initially to set the network interfaces to promiscuous mode for sniffing, but it can run subsequently as a less privileged user—this is always a good idea for added security. Use the -u and -g options to designate this lesser user and group ID, respectively. The permissions of the logging directory need to allow only write access for this user or group. If you want to allow a set of other authorized users to analyze the logging data (without root access), add the users to Snort's group, make the logging directory group readable, and use -m 007 to set Snort's umask so that all of the files created by Snort will be group readable as well. [Recipe 5.10]

You can ask Snort to dump statistics to the system logger (the same report that is produced before Snort exits) by sending it a SIGUSR1 signal:

# kill -USR1 `pidof snort`

Snort writes its process ID to the file /var/run/snort_<interface>.pid. If you are running multiple copies of snort, with each listening on a separate interface, these files can be handy for signaling specific invocations, e.g.:

# kill -USR1 `cat /var/run/snort_eth2.pid`

9.22.4 See Also

snort(8). The Snort home page is http://www.snort.org.