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:

Today I am performing some maintenance on my Snort IDS, and also practicing for my upcoming Snort CP exam. We shall examine some scripts and applications that can be used to make Snort a little more automated and transparent to the administrator, as well as increase Snort’s overall performance. What I’d like to focus on today is oinkmaster and crontab.

The scope of this post, however, assumes that you have snort installed already, and are advanced enough to understand your IDS system. I am not going to cover the installation of snort at this time. Today I am just going to cover some automation and performance.

Let’s get ready to Snort it up.