Getting Barnyard working with Snort databases

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 www.testmyids.com, sensor_agent.tcl reports the following:

Sguil invokes Barnyard using syntax like the following:

barnyard -c barnyard.conf -d /nsm/$SENSOR/ -g gen-msg.map -s 
sid-msg.map -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 gen-msg.map and sid-msg.map help Barnyard translate generators and Snort IDs into human-readable formats.

For example, here is the entry for SID 498 in sid-msg.map:

498 || ATTACK-RESPONSES id check returned root

In gen-msg.map 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

 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.