Over the last few days I've reviewed several add-ons for Snort. First, everyone using Snort knows about Barnyard. Barnyard processes the output from the spo_unified plugin, which Marty first described in June 2001. spo-unified creates two log files.
To paraphrase Marty, the alert file contains event data (generator, sid, rev, classification, priority, event_reference), timestamp, source IP, destination IP, source port, destination port, protocol, and TCP flags (if applicable). The log file contains the event data, flags that indicate the nature of the stored packet (reassembled fragment, etc.) and the raw binary packet.
Barnyard reads unified output and sends the results to other plugins. In most cases those are database plugins.
MudPit is an alternative to Barnyard. Mudpit was written to overcome the fact that receiving either alert or log data can be insufficient to validate an event, but receiving both simultaneously is wasteful.
At the Sguil project we use our own version of unified output with a modified Barnyard process and new database schema.
Dragos Ruiu wrote Cerebus to read unified output and displays the results in a text-based GUI.
I learned today via this post of the Fast LOgging Project for Snort (Freshmeat site). FLoP doesn't use unified logging at all. It sends Snort output via UNIX domain sockets.
On a slightly different note, I've noticed a few more ambitious projects. For several years CERT has maintained the AirCERT project as a means to share alert data among sensors. I read about the Open Source Security Information Management (OSSIM), Monitoring, Intrusion Detection, Administration System (MIDAS), and Crusoe IDS (announced here) projects, which each bring together data from multiple tools to improve event detection. This is different from Sguil's approach, where we let Snort provide alert data and we provide context using sessions, full content, and eventually statistical data. I know of at least one vendor, Endace, who sells a product featuring data from multiple open source tools.
To paraphrase Marty, the alert file contains event data (generator, sid, rev, classification, priority, event_reference), timestamp, source IP, destination IP, source port, destination port, protocol, and TCP flags (if applicable). The log file contains the event data, flags that indicate the nature of the stored packet (reassembled fragment, etc.) and the raw binary packet.
Barnyard reads unified output and sends the results to other plugins. In most cases those are database plugins.
MudPit is an alternative to Barnyard. Mudpit was written to overcome the fact that receiving either alert or log data can be insufficient to validate an event, but receiving both simultaneously is wasteful.
At the Sguil project we use our own version of unified output with a modified Barnyard process and new database schema.
Dragos Ruiu wrote Cerebus to read unified output and displays the results in a text-based GUI.
I learned today via this post of the Fast LOgging Project for Snort (Freshmeat site). FLoP doesn't use unified logging at all. It sends Snort output via UNIX domain sockets.
On a slightly different note, I've noticed a few more ambitious projects. For several years CERT has maintained the AirCERT project as a means to share alert data among sensors. I read about the Open Source Security Information Management (OSSIM), Monitoring, Intrusion Detection, Administration System (MIDAS), and Crusoe IDS (announced here) projects, which each bring together data from multiple tools to improve event detection. This is different from Sguil's approach, where we let Snort provide alert data and we provide context using sessions, full content, and eventually statistical data. I know of at least one vendor, Endace, who sells a product featuring data from multiple open source tools.
Long-time readers of this blog know I subscribe to a security theory called network security monitoring. Two of NSM's principles are "some intruders are smarter than you" and "intruders are unpredictable." Believing these principles changes the way defenders look at watching their networks. If you assume a smart, unpredictable enemy, you have to take as many defensive actions as possible in the remote hope of catching a bad guy.
Do you know the game of "Life"? The game was created by mathematician John Conway and described in this 
Thanks to a 
Amazon.com just publishes three new reviews. First, from the five star review of 
Next are two more controversial reviews. Although I gave each book four stars, I make specific critiques of each book. From my four star review of 
Finally, from my four star review of 
