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,...

By submitting your personal information, you agree to receive emails regarding relevant products and special offers from TechTarget and its partners. You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

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.

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.

E-Handbook

E-Handbook

0 comments

E-Mail

Username / Password

Password

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy