Highlighted
reswob4 Honored Contributor.
Honored Contributor.
425 views

Anyone else having problems parsing Barnyard logs sent via syslog?

Jump to solution

So we have multiple snort instances running and we were originally sending the alerts into a smartconnector on the connapp via syslog as snort alerts.  This worked just fine.  However to increase performance and make better use of resources in our environment, we started processing the alerts through Barnyard and having the alerts sent to a smartconnector on the connapp via syslog in Barnyard format.  However, the parsing isn't working. 

When we receive native Barnyard via syslog, many times the entire alert is jammed into the name and message.

I turned on preserver raw event and here is and example of what the ESM sees:

     <25>Aug 22 09:02:32 HOSTNAME barnyard2[3740]: [1:92000:1] Snort Alert [1:92000:1] <barnyard1> {TCP} 1.1.1.1:12345 -> 2.2.2.2:54321

From this, the ESM sets the following:

DeviceVendor and DeviceProduct = UNIX

name and message = [1:92000:1] Snort Alert [1:92000:1] <barnyard1> {TCP} 1.1.1.1:12345 -> 2.2.2.2:54321

Destination Address = 2.2.2.2 (sometimes this is blank as well)

Source Address is blank

We tried changing the output for Barnyard to CEF, but they have a '.' where there should be a '|' and so that isn't parsing right either.

So what happens here is that the raw event looks like this:

CEF:0|snort|barnyard2|1.13129:5:1|Snort Alert|9|src=1.1.1.1 dst=2.2.2.2 spt=12345 dpt=54321 proto=TCP

The field that is 1.13129:5:1 SHOULD read 1|13129:5:1 and so while DeviceVendor and DeviceProduct are correct, DeviceVersion is 1.13129:5:1 and everything after is off by one.  (i.e. name=9, DeviceEventClassID=Snort Alert, etc)

Anyone else seeing these problems with Barnyard and/or have any suggestions?

Thanks.

Labels (2)
0 Likes
1 Solution

Accepted Solutions
reswob4 Honored Contributor.
Honored Contributor.

Re: Anyone else having problems parsing Barnyard logs sent via syslog?

Jump to solution

Thanks JP.

Forgot to mention I ended up writing a syslog subagent parser.  located here:  Barnyard Syslog subagent parser

Works well.

0 Likes
4 Replies
seniorj@bennett Absent Member.
Absent Member.

Re: Anyone else having problems parsing Barnyard logs sent via syslog?

Jump to solution

Hey Craig, I don't mean to completely derail what you are doing with Barnyard, but I found it pretty difficult to support myself.  I ended up switching to alert_fast [maybe in conjunction with barnyard?] and local arcsight connectors to scrape the filesystem directly.  This worked pretty excellently for payload retreival as well with connector 7.0.4+.

I found BarnYard was a bit 'off' for many alerts.

I also thought that the Arcsight connector barnyard is based on version 1 or earlier, not the current 2.

0 Likes
reswob4 Honored Contributor.
Honored Contributor.

Re: Anyone else having problems parsing Barnyard logs sent via syslog?

Jump to solution

JP, thanks.  It turns out Barnyard in on version 2.x and as noted, the Connector is compatible up to version 0.2 .

I will take you suggestion and see what I can do.  I will also see what I can do with a flexconnector.

0 Likes
seniorj@bennett Absent Member.
Absent Member.

Re: Anyone else having problems parsing Barnyard logs sent via syslog?

Jump to solution

I did a bit of legwork in this post: that you might find helpful.

0 Likes
reswob4 Honored Contributor.
Honored Contributor.

Re: Anyone else having problems parsing Barnyard logs sent via syslog?

Jump to solution

Thanks JP.

Forgot to mention I ended up writing a syslog subagent parser.  located here:  Barnyard Syslog subagent parser

Works well.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.