Snort alerts – passing through the Onion

Snort is a pretty interesting piece of software, with multiple features. Understanding the Snort architecture might help better understand this post. It is also the de-facto standard when it comes to IDS and the default sensor used in Security Onion. The present article will present the overview of how Snort and additional programs are being used in Security Onion. The purpose of Snort in Security Onion is to provide IDS data which will be analyzed by the user in one of the user-interfaces available in the operating system. The following is also an example of a network security monitoring system.



  • small rectangles – configuration files
  • circles – data formats
  • squares – main programs
  • big rectangles – barnyard output formats


  • snort can either process live network traffic or pcap files with traffic information
  • the way snort processes the data is defined in the snort.conf file (/etc/nsm/HOSTNAME_IFACE/snort.conf), which must be tunned accordingly to the monitored environment so that it outputs with (some sort of) accuracy
  • the threshold.conf (/etc/nsm/HOSTNAME_IFACE/threshold.conf) file is included in the snort.conf file and handles the frequency of alerts
  • the rules (detection rules) (/etc/nsm/rules/NAME.rules) are included in the snort.conf file and they determine what will snort do in case something will match the provided condition written in the rule (provide an alert, drop the package etc)
  • Pulledpork downloads the rules based on the instructions in the pulledpork.conf (/etc/nsm/pulledpork/pulledpork.conf) file and disablesid.conf  file (/etc/nsm/pulledpork/disablesid.conf)
  • the pulledpork.conf file holds the specific online sources from which it can download the rules (e.g. )
  • the disablesid.conf file holds information on which rules should be disabled on Pulledpork is providing rule files to snort
  • snort saves its alert information in unified2 log files (/nsm/sensor_data/HOSTNAME_IFACE/snort/snort.unified2.TIMESTAMP)
  • Barnyard2 processes the unified2 log files into formats accepted by other programs. Example of running barnyard in Security Onion:

barnyard2 -c /etc/nsm/HOSTNAME_IFACE/barnyard2.conf -d /nsm/sensor_data/HOSTNAME_IFACE/snort -f snort.unified2 -w /etc/nsm/HOSTNAME_IFACE/barnyard2.waldo-1 -i 1 -U -D

-c – specifies the configuration file

-d specifies the unified2 log file location

-f specifies the base filename pattern

-w specifies a bookmark (keeping track of what file is being processed)

-i specifies the interface

-U specifies that it should use UTC for timestamps

-D runs it in daemon mode (in the background)

  • Barnyard2 processed results are being sent to destinations specified in the barnyard2.conf file (/etc/nsm/HOSTNAME_IFACE/barnyard2.conf). Example of outputing results to syslog:

output alert_syslog: LOG_LOCAL6 LOG_ALERT

  • the default output destinations specified in the barnyard2.conf file are the Snorby database, syslog and Sguil
  • after and while the destinations are receiving the information, the user-interfaces in Security Onion can present the analyst with the overview of the alerts.

The Snort alert data passes through several intermediate programs before ending up on a user interface where the user can further analyze and classify the data. Some might argue that there are too many steps, but this is the prefered method because the unified2 format is the fastest format to output for Snort.