Barnyard processing alerts for Snort

Next I run Barnyard, replacing the -R switch with the -v switch to enable verbose operation.

cel433:/usr/local/snort-2.6.1.4# barnyard -c barnyard.conf -v -L /tmp/so/by -g gen-msg.map -s sid-msg.map -o /tmp/so/unified/snort.alert.1180727255 Barnyard Version 0.2.0 (Build 32) Parsing alert_syslog2 arguments: (null) Processing: /tmp/so/unified/snort.alert.1180727255 Number of records: 1 Exiting

We now have two new files in the /tmp/so/by directory.

cel433:/tmp/so/by# ls -al total 8 drwxr-xr-x 2 root wheel 512 Jun 1 16:14 . drwxr-xr-x 12 root wheel 512 Jun 1 16:09 .. -rw-r--r-- 1 root wheel 68 Jun 1 16:14 alert_csv.by -rw-r--r-- 1 root wheel 260 Jun 1 16:14 alert_fast.by

The first has CSV output, and the second has FAST output.

cel433:/tmp/so/by# cat alert_csv.by
1,498,6,3,2,1,1177444229,236253,1386558070,
1167051292,80,80,39929,6
cel433:/tmp/so/by# cat alert_fast.by
04/24/07-19:50:29.236253 {TCP} 82.165.50.118:80 -> 
69.143.202.28:39929
[**] [1:498:6] ATTACK-RESPONSES 
id check returned root [**]
[Classification: Potentially Bad Traffic] [
Priority: 2]
------------------------------------------------------------------

A check of /var/log/auth.log shows a Syslog record generated by the alert_syslog directive.

Jun  1 16:14:57 cel433 barnyard: [1:498:6] ATTACK-RESPONSES
 id check returned root
[Classification: Potentially Bad Traffic] [Priority: 2] 
{TCP} 82.165.50.118:80 ->
69.143.202.28:39929

Syslog2 is recommended if you wish to enable Syslog reporting. Where is the alert from Syslog2? It turns out Syslog2 requires enabling some options like the following.

output alert_syslog2: severity: ALERT; syslog_host: localhost;

Second, the Syslog daemon must be configured to accept Syslog messages from machines other than localhost. This may sound odd, but Syslog2 doesn't use the native Syslog mechanism on the host. Therefore, if you are running syslogd with the -s switch (for example, the default on FreeBSD), you need to restart syslogd without the -d switch.

Running Barnyard again will produce an alert now.

cel433:/usr/local/snort-2.6.1.4# barnyard -c barnyard.conf 
-v -L /tmp/so/by -g gen-msg.map -s sid-msg.map -o 

/tmp/so/unified/snort.alert.1180727255
Barnyard Version 0.2.0 (Build 32)
Parsing alert_syslog2 arguments: severity: ALERT; syslog_host: 
localhost; Processing: /tmp/so/unified/snort.alert.1180727255
Number of records:  1
Exiting

Notice this alert in /var/log/messages has a different timestamp:

Apr 24 19:50:29 localhost cel433 barnyard: [1:498:6] 
ATTACK-RESPONSES id check returned root [Classification: 

Potentially Bad Traffic] [Priority: 2] {TCP} 82.165.50.118:80 ->
 69.143.202.28:39929

Here the timestamp is the timestamp of the packet in UTC format, not the time at which the alert was processed by Barnyard.


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.
    Back to top