Getting Barnyard working with Snort databases

Having Snort write output to the hard drive and letting a tool like Barnyard handle database inserts, as explored here, considerably improves Snort performance.

The advantages of Snort writing to unified output and then having Barnyard process it aren't very clear when using the formats listed earlier. One advantage involves sending output to multiple places, say Syslog and a local file. Having Snort natively perform those functions wastes cycles better spent inspecting packets.

Unified output is most effective when working with databases. Having Snort write output to the hard drive and letting a tool like Barnyard handle database inserts considerably improves Snort performance.

Two popular means of database support are available. First, Barnyard can work with the ACID/BASE database schema with the following configuration options.

output alert_acid_db: mysql, sensor_id 1, database snort, 
server localhost, user snort, password snort
output log_acid_db: mysql, sensor_id 1, database snort, 
server localhost, user snort, password snort

In this example a database on localhost will accept inserts from Barnyard for storing data in alert and log formats.

The second popular database output format is used by Sguil.

output sguil: sensor_name cel433

Here, all that's required is the name of the sensor. Sguil offers an application called sensor_agent.tcl that listens for connections from Barnyard on localhost, port 7735 TCP. For example, when a Sguil sensor sees an event like a visit to, sensor_agent.tcl reports the following:

Sguil invokes Barnyard using syntax like the following:

barnyard -c barnyard.conf -d /nsm/$SENSOR/ -g -s -f snort.log -w /nsm/$SENSOR/waldo.file

Here we tell Barnyard to run in continual mode (as opposed to batch mode, signified by the -o switch in previous examples). Barnyard will keep watching the /nsm/$SENSOR directory for files named snort.log.TIMESTAMP, which are unified output files created by this snort.conf directive:

output log_unified: filename snort.log, limit 128

The waldo.file helps Barnyard keep a checkpoint of what data it has processed. The references to and help Barnyard translate generators and Snort IDs into human-readable formats.

For example, here is the entry for SID 498 in

498 || ATTACK-RESPONSES id check returned root

In we can see generator 1 is the Snort alert mechanism.

1 || 1 || snort general alert

The bottom line is that anyone who wants Snort data in a database should write data to unified output, and then use a spool reader like Barnyard to process it.

Working with unified output

  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 last published in July 2007

Dig Deeper on Managed network security services

Start the conversation

Send me notifications when other members comment.

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

Please create a username to comment.