Working with Snort's unified output

In this edition of the Snort Report, IDS expert Richard Bejtlich demonstrates how to use unified output, the preferred method for high-performance Snort operation.

This Content Component encountered an error

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

    Dig deeper on Network security products, technologies, services

    Pro+

    Features

    Enjoy the benefits of Pro+ membership, learn more and join.

    0 comments

    Oldest 

    Forgot Password?

    No problem! Submit your e-mail address below. We'll send you an email containing your password.

    Your password has been sent to:

    -ADS BY GOOGLE

    MicroscopeUK

    SearchCloudProvider

    SearchSecurity

    SearchStorage

    SearchNetworking

    SearchCloudComputing

    SearchConsumerization

    SearchDataManagement

    SearchBusinessAnalytics

    Close