In the last Snort Report we looked at output methods for Snort. These included several ways to write data directly
to disk, along with techniques for sending alerts via Syslog and even performing direct database inserts. I recommended not configuring Snort to log directly to a database because Snort is prone to drop packets while performing database inserts. In this edition of the Snort Report I demonstrate how to use unified output, the preferred method for high performance Snort operation.
Before continuing I should mention that the definitive reference on unified output is the chapter Mucking Around with Barnyard in the Syngress books Snort 2.1 (2004) and Snort Intrusion Detection and Prevention Toolkit (2007) by Barnyard author Andrew Baker. Reviewing the table of contents for each book shows the material to be identical.
Support for unified output first appeared in Snort 1.8.0, released in July 2001. Unified output is essentially a means for Snort to write sets of data to the hard drive of a sensor. Writing to the hard drive, instead of performing database inserts, allows Snort to operate much faster and minimize packet loss.
Snort provides two forms of unified output: alert and log. At one point Snort offered two additional forms, namely stream-stat and an experimental version. The first two forms exist today, and the second two are no longer available. (Code to process the stream-stat form can still be found in some unified spool readers like Barnyard, however.)
It's important to understand the data present in unified alert and log records, which I list below. Where necessary I explain the meaning of the field.
Consider the important differences between these two formats. Generally, when you want access to alert details, you want to see the packet that triggered the alert. Unified alert output provides easy access to key packet elements like source and destination IP addresses and ports, plus protocol (TCP, UDP, ICMP, etc.), but nothing else. This isn't sufficient for most investigations. (Actually, an alert even with full packet data is almost never sufficient for investigation, but that's a story for another article.)
Unified log output might solve this problem. Unified log output includes the important non-packet details (like Signature information and so on) present in unified alert data. Unified log output also contains the entire packet that triggered the alert. That would seem to solve the problem, right? Unfortunately for those who want to see packets in human-readable form, unified log format records the packet in hexadecimal format. This means elements must be parsed by a program that understands this format. Unified log format is most likely going to be the unified form used in production environments.
Working with unified output
Examining unified output
Unified output readers
Barnyard processing alerts
Barnyard processing logs
Barnyard working with databases
About the author
Richard Bejtlich is founder of TaoSecurity, author of several books on network security monitoring, including Extrusion Detection: Security Monitoring for Internal Intrusions, and operator of the TaoSecurity blog.