 |
|
| Security Channel Tips: |
|
|
|
SNORT REPORT
Working with Snort's unified output
Richard Bejtlich
07.11.2007
Rating: --- (out of 5)
|
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.
Alert records
Signature generator ID (e.g., 1 for the rules subsystem)
Signature ID (e.g., 498 for the rule ATTACK-RESPONSES id check returned root)
Signature revision (e.g., 6 for rule 498 in a recent signature set)
Classification ID
Priority
To continue reading for free, register below or login
To read more you must become a member of SearchSecurityChannel.com
Event ID (assigned by Snort as events are logged)
Event timestamp
Event reference ID (not used, equals event ID)
Event reference timestamp (not used, equals 0)
Source IP
Destination IP
Source port
Destination port
Protocol
Flags (hints about packet-like fragmentation issues, etc.)
Log records
Signature generator ID (e.g., 1 for the rules subsystem)
Signature ID (e.g., 498 for the rule ATTACK-RESPONSES id check returned root)
Signature revision (e.g., 6 for rule 498 in a recent signature set)
Classification ID
Priority
Event ID (assigned by Snort as events are logged)
Event reference ID (event ID of the original event causing this packet to be logged)
Event reference timestamp (timestamp of the original event causing this packet to be logged)
Flags (hints about packet like fragmentation issues, etc.)
Packet timestamp
Packet capture length (size of the packet data field)
Packet length (total packet length)
Packet data (the actual packet, from layer 2 to layer 7)
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.
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.
|
|
|
|
|
|
|
|
|
| TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations' technology projects - with its network of . |
|
| |
All Rights Reserved, , TechTarget |
|
|
|
|
|
