Bleeding Snort Starts snort.conf Collection
I read an announcement yesterday that the Bleeding Snort project has started recommending snort.conf files. I posted the following comment at Bleeding Snort:
Hello,
I think this sample snort.conf project is a great idea.
One concern I have is the general reliance on output_database to insert Snort alerts into databases. output log_unified and output alert_unified have been available for around four years, but many snort.conf files and configuration guides still insist on using output database.
For example, the snort.conf addition that I recommend in my Sguil installation guide uses
Not using Barnyard can be a real performance killer. If the Snort process and the database are on separate systems, especially across Internet space, Snort will definitely drop packets as it tries to insert alerts.
Thank you,
Richard
I do not understand why people insist on deploying Snort without Barnyard, FLoP, the recently resurrected Mudpit, or another output spool reader. When Snort processes a packet, and needs to insert an alert into the database, Snort blocks while processing the insert. Snort is not multi-threaded. If your database inserts are slower than the ability of Snort to keep up with packet processing, you will drop packets. If your Snort process and DB are different boxes, and the link goes down, Snort will have major problems.
Barnyard and other spool readers make a huge difference. Snort writes its output to disk. Barnyard reads the output and takes care of the inserts to the DB.
Decoupling that process allows Snort to run as fast as possible, and the system becomes more tolerant of delays or breaks in the line between the sensor and DB.
Only in late 2004 did the SHADOW Snort distribution make Barnyard the default output processing system. This guide still avoids Barnyard. I won't name any other installation guides that rely on output_database, but there are plenty others out there.
Hello,
I think this sample snort.conf project is a great idea.
One concern I have is the general reliance on output_database to insert Snort alerts into databases. output log_unified and output alert_unified have been available for around four years, but many snort.conf files and configuration guides still insist on using output database.
For example, the snort.conf addition that I recommend in my Sguil installation guide uses
output log_unified: filename snort.log, limit 128
Not using Barnyard can be a real performance killer. If the Snort process and the database are on separate systems, especially across Internet space, Snort will definitely drop packets as it tries to insert alerts.
Thank you,
Richard
I do not understand why people insist on deploying Snort without Barnyard, FLoP, the recently resurrected Mudpit, or another output spool reader. When Snort processes a packet, and needs to insert an alert into the database, Snort blocks while processing the insert. Snort is not multi-threaded. If your database inserts are slower than the ability of Snort to keep up with packet processing, you will drop packets. If your Snort process and DB are different boxes, and the link goes down, Snort will have major problems.
Barnyard and other spool readers make a huge difference. Snort writes its output to disk. Barnyard reads the output and takes care of the inserts to the DB.
Decoupling that process allows Snort to run as fast as possible, and the system becomes more tolerant of delays or breaks in the line between the sensor and DB.
Only in late 2004 did the SHADOW Snort distribution make Barnyard the default output processing system. This guide still avoids Barnyard. I won't name any other installation guides that rely on output_database, but there are plenty others out there.
Comments