Monday, February 4, 2008

ArcSight / CEF Patch for Snort / Barnyard

Last week Colin Grady released a patch to the Snort output tool, Barnyard 0.20, that allows you to output in ArcSight CEF format. I was going to post something here about it last week because of its sheer coolness, but then decided to hold off until I had a chance to play with it myself.

It built flawlessly, and it was easy enough to set up. It creates a new module in Barnyard named "alert_cef" that shovels CEF format messages to a syslog server (like ArcSight Logger). An example barnyard.conf might look something like this:

config daemon
config localtime
config hostname: arnold:eth1
config interface: eth1
config sid-msg-map: /opt/snort/rules/sid-msg.map
config gen-msg-map: /opt/snort/rules/gen-msg.map
config class-file: /opt/snort/rules/classification.config
output alert_cef arnold arcsight_logger.mydomain.local 16 1 514

Those arguments to the 'output alert_cef' line are, in order:
hostname
syslog server
syslog facility (integer format 16=local0)
syslog severity (integer format 1=alert)
syslog server port (UDP)

So here are my thoughts on Colin's patch. On the plus side, Barnyard is fast and lightweight, especially in comparison to the ArcSight Connector bundle which is several hundred MB on disk and in memory because it's Java. On the neutral side, its use case is pretty specific - you have ArcSight Logger collecting syslog data and forwarding to ESM. (Or you do your own thing with CEF and not ArcSight.) And on the down side, bypassing the ArcSight Connector means that you lose the categorization/prioritization stuff that ArcSight does for you with its AUP updates. And it also means no packet payload. For that you need to be running the ArcSight SnortDB Connector and logging Snort to a SQL database (preferably via Barnyard).

So that's still the architecture that I recommend for an enterprise Snort-to-ArcSight deployment. Snort doing unified logging, Barnyard shoveling logs into a SQL server on another host, ArcSight SnortDB Connector (also not on the Snort sensor host) querying that data from SQL and handing it directly to ESM. That gets you maximum scalability and functionality.

Nonetheless, Colin's patch is pretty cool, and definitely on the table for folks that have Logger and ESM. Additionally, if you use Snort and Barnyard, you should look at some of the other patches Colin has on his site. In particular, I think we will be testing and deploying his schema patch for Barnyard. Wish I had known about it 2 years ago.

5 comments:

Colin Grady said...

Paul,

Glad you find value in the patch! I wrote it on a whim about a week ago. I don't even use ArcSight.

Let me know if you've got features or changes you'd like to see.

Thanks,
Colin

Anonymous said...

Hmmmm, I agree that lack of payload is the biggest negative to this solution.... so.....

If the Barnyard CEF output had what ArcSight calls the "payload ID" (The eventID that indicates the location of the actual payload or session data in Snort) as a field it probably wouldn't be all that difficult to have an ArcSight Tool written to "right-click" in ArcSight Active Channel and on-demand go and retrieve the payload (via SSH Script) and open it up in Wireshark (if pcap session data) or another tool for further analysis.

Just a thought. If I get a chance to play with this perhaps I'll post the actual method of accomplishing this.

PaulM said...

The issue of retrieving payload after the fact is really two issues. First, storing the payload somewhere and second, retrieving it on demand. An ArcSight tool could be built for retrieval like you describe, but using the CEF-to-syslog Barnyard method doesn't seem to put the payload anywhere you can retrieve it.

Colin Grady said...

Again, I don't use ArcSight. So I'm not very familiar with the mechanisms used for it's log collection. My output plugin was more of a tool coming out of some free time, than really to address a need. Syslog is not a very good mechanism for transporting payloads -- there are definitely better ways of doing this. The output plugin is really just a transport for the alarm and not intended to provide a context (just like the standard syslog output plugins in Snort and Barnyard).

Alby said...

Hey Paul,

Late comment!

Don't know if you use the commercial side of Snort, but they provide 'estreamer' for event output which is real nice and since it comes API documentation its easily integrated to OSS snort. With the addition of Intrusion Agent, I can just have it from the DC.