Working with Snort's unified output

In the last Snort Report we looked at output methods for Snort. These included several ways to write data

    Requires Free Membership to View

    Login

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


    Working with unified output

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

    This was first published in July 2007

    • Join the conversationComment

    Share
    Comments

      Results

      Contribute to the conversation

      All fields are required. Comments will appear at the bottom of the article.

      Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

      Back to top