Recipe 9.23 Decoding Snort Alert Messages

9.23.1 Problem

You want to understand a Snort alert message.

9.23.2 Solution

Consult the Snort signature database at http://www.snort.org/snort-db, using the signature ID as an index, or searching based on the text message. Most alerts are described in detail, and many include links to other NIDS databases with even more information, such as the arachNIDS database at http://www.whitehats.com.

9.23.3 Discussion

Let's decode an alert message produced when Snort detects a port scan by nmap [Recipe 9.13]:

Mar 18 19:40:52 whimsy snort[3115]: [1:469:1] ICMP PING NMAP [Classification: 
Attempted Information Leak] [Priority: 2]: <eth1> {ICMP} 10.120.66.1 -> 10.22.33.106

Breaking apart this single line, we first have the usual syslog information:

Mar 18 19:40:52 whimsy snort[3115]:

which includes a timestamp, the hostname where Snort was running, and the Snort identifier with its process ID. Next we have:

[1:469:1] ICMP PING NMAP

In this portion of the alert, the first number, 1, is a generator ID, and identifies the Snort subsystem that produced the alert. The value 1 means Snort itself. The next number, 469, is a signature ID that identifies the alert, and corresponds to the subsequent text message (ICMP PING NMAP). The final number, 1, is a version for the alert.

If the alert were produced by a Snort preprocessor, it would have a higher value for the generator ID, and the name of the preprocessor would be listed in parentheses before the text message. For example:

[111:10:1] (spp_stream4) STEALTH ACTIVITY (XMAS scan) detection

Signature IDs are assigned by each preprocessor: to learn more about these alerts, see the snort.conf file, and the Snort User's Manual. Continuing our example, we see the classification of the alert:

[Classification: Attempted Information Leak] [Priority: 2]:

Each alert is classified into one of a set of broad categories: see the file classification.config in the rules directory. Alerts are also assigned priority levels, with lower values meaning more severe events. Finally, the alert identifies the receiving network interface and lists the IP protocol, source address, and destination address:

<eth1> {ICMP} 10.120.66.1 -> 10.22.33.106

It's optional to identify the receiving network interface: use the -I option to enable this feature, say, if your system is connected to multiple networks. Finally, even though the source address is listed, you cannot trust it in general: attackers often use spoofed addresses to implicate innocent third parties.

If you are replaying a network trace using snort -r, you probably don't want to send alerts to the system logger: use the -A fast or -A full options to write the alerts to a file called alert in the logging directory. The fast alert format is very similar to syslog's. Full alerts provide more protocol details, as well as cross-references like:

[Xref => arachnids 162]

These usually correspond to links in the Snort signature database. See the file reference.config in the rules directory to convert the ID numbers to URLs to obtain more information for each alert.

Use the -A console option to write alerts (in the fast alert format) to the standard output instead of the alert file.

9.23.4 See Also

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