Snort Syslog Support

Snort supports numerous alert output options, flat file, database and one option I like using, Syslog. Syslog is one technology that is often overlooked; however, I have found Syslog complements Snort beautifully. Snort is super-fast and unfortunately Snort newbies make the mistake of implementing Snort with a slow motion partner like SQL database server (local or remote). DB writes updates or even queries take time and to Snort it must seem like an eternity. Networks are lightning fast and Intrusion Detection is even faster. If you ask Snort to wait for SQL you’ll drop packets, which in my mind defeats the purpose of Intrusion Detection.

Therefore I’ll show you how to configure Snort with Syslog. Since Snort is best served on your favourite *nix flavor; I’ll step you through a Linux configuration (sorry Windows fans)

I’ll assume you’ve installed Snort and Syslog (most Linux distros come with Syslog preinstalled as the default logging daemon)

Since I’m an Ubuntu fan, I’ll be using RSyslog, but before I jump there, let’s take a step back and look at Snort’s configuration.

Locate the following section in Snort’s configuration file (usually found in /etc/snort/snort.conf)

###################################################

# Step #4: Configure output plugins

#

In this section, you choose which output method best suits your needs. In our case we’ll enable syslog.

Locate the following lines

#

# [Unix flavours should use this format…]

# output alert_syslog: LOG_AUTH LOG_ALERT

#

To activate syslog alert output, remove ‘#’ in front of ‘output alert_syslog’ parameter like this;

#

# [Unix flavours should use this format…]

output alert_syslog: LOG_AUTH LOG_ALERT

#

By the way LOG_AUTH is the syslog facility and LOG_ALERT is the severity level. We can customize above settings and specify the following; (Let’s send Snort Syslog Alerts to the LOCAL5 facility)

output alert_syslog: LOG_LOCAL5 LOG_ALERT

Make sure to save your changes, restart Snort daemon and viola! Snort should now be logging alerts to a local syslog server.

Ok, at this point half the battle is done.

Next we have to configure rsyslog to do something with Snort’s alerts. Here we have many choices.

1. We can store alerts to a flat file (local) i.e. /var/log/somefile

2. We can ship alerts to a remote syslog server

3. We can write snort alerts to database (WHAT??? I thought you said that’s slow) ~Wait put away those pitch forks let me explain keep reading.

4. We can even email alerts

Let’s look at each option:

1. Store Snort Alerts to local syslog file

To store Snort alerts to local file we edit local rsyslog configuration file /etc/rsyslog.conf and add the following line

local5.*                                /var/log/snort.alerts

I would not recommend this option because Snort has native support for local alert files. Instead I would choose option 2 and send Snort sensor alerts to an aggregate Syslog server.

2. Ship Snort Alerts to Central Aggregate Syslog Server

Two steps required;  (1)edit local rsyslog configuration and (2) edit remote syslog server configuration

(1)[local syslog server] Edit /etc/rsyslog.conf and add the following line

Local5.* @192.168.1.1        {Remote Syslog Server IP address – Your IP will be different}

(2)[remote syslog server] Edit /etc/rsyslog.conf and add the following line (I’m using Linux and rsyslog on both Servers)

If $fromip ==’192.168.1.1’ then /var/log/snort.alerts

Above line will store received Snort Alerts to a local file called snort.alerts found in /var/log/

3. We can write snort alerts to database

I know I said database is slow. But listen… At this point in the game it doesn’t matter because it’s no longer Snort that has to wait…wait…wait… for transactions to complete. Snort has done its job and handed the alert to syslog, IT has to wait…wait…wait… get it?

I would not recommend this option but if you really must use a database the option is there. Best of all rsyslog has native MySQL support built in.

Edit /etc/rsyslog.conf and add the following lines

$ModLoad ommysql                      <this enables MySQL Support>

Local5.* : ommysql:localhost,Snort-DB,root,password                  <writes alerts to Snort DB>

4. Email Snort Alert from Syslog

I love using rsyslog because it has native SMTP support which makes email actions super easy. (one drawback) it does not support SMTP authentication yet. Until then you have to allow ‘relay’ from Snort’s IP.

Edit /etc/rsyslog.conf and add the following lines; 

#

# Email Messages

#

$ActionMailSMTPServer <Server IP or hostname>

$ActionMailFrom <Sender Address>

$ActionMailTo <Recipient Address>

$template mailSubject,”Syslog Alert Message from %hostname%”

$template mailBody,”RSYSLOG Alert\r\nmsg=’%msg%’”

$ActionMailSubject mailSubject

*.* : ommail:;mailBody

Don’t forget to adjust above settings for your specific mail server, recipient and sender details.

Personally I prefer option 2 – centralized syslog server. Configure Snort sensors on your network segments and have all report to a central location. Then with rsyslog email notification send select alerts to your inbox. That of course requires rsyslog filtering… I’ll show you how to do that next time.  That’s it for this week, if anyone has any comments please share them.