In part 2 of a behind the scenes look at Sort, we shall begin by looking at barnyard. Barnyard can best be described as the middle man between Snort and it’s database. You are probably saying … Snort has native database support built in (if you compiled it as such), why do I need another application to handle this task?!
The answer is rather simple, alert queuing. In almost every production environment, the database for Snort alerts, are not stored locally on the Snort box. So, if there is a loss of transport, or hardware/database issues, what happens to Snort? It will just stop logging alerts, leaving you with no IDS data for the timespan of the outage. Forensically speaking, this is a horrendously bad idea. This is where barnyard will be your savior; as Snort logs alerts to the local unified files, barnyard will keep track of what has or has not been inserted into the database. Barnyard will continue to store alerts in its queue while checking for database availability, ultimately inserting the queued alerts when the correct resources are available.
Let’s get ready to barnyard it up: