I recently setup a Snort sensor on a dedicated box and initially had it all running and happy. Then I stumbled across Snorby, and thought “that looks pretty mint, I might try that out” as BASE just wasn’t doing it for me on its own. In this article I’ll try and piece together a little about what the initial set-up was and how I managed to get Snorby up and running (and how I managed to get stuck several times along the way).
Before I looked at installing Snorby I’d setup Snort, Barnyard2 and Apache2 with BASE. Snort was logging to a unified2 log file, which Barnyard2 was parsing and storing in a database as well as logging to syslog so I could get a rapid view that things were actually working prior to BASE being setup. Then BASE came in and grabbed info from the database to display in its standard fashion.
While this setup was pretty good and while BASE was able to generate some interesting stats, it wasn’t the most slick thing I’ve seen and its links to rule info and IP lookups etc seemed to have been invalidated due to updates in the websites or subscription requirements of the websites.
So then I stumbled across Snorby. It looked much more user friendly and appeared to generally just be a nicer system than BASE, so I thought why not. Initially I had intended to run both BASE and Snorby in different folders of the web root… that of course turned out to be a bust due to the nature of Ruby on Rails; a language I know nothing about and gave no thought to at the time.
While Snorby can run all on its lonesome using Webrick (never done it but the interwebz told me so!), I had Apache running already and as I mentioned was still thinking that other stuff would be running along side. So, on the Snorby website I found the wiki page “http://wiki.github.com/mephux/Snorby/snorby-recipe-with-barnyard2-unified2-and-apache-jjc” which after some later googling appears to just be an excerpt from “http://global-security.blogspot.com/2009/07/snorby-for-snort-recipe-with-barnyard2.html“.
Now that recipe was aimed at FreeBSD, which while I used to use, was somewhat different in it’s operation to Debian. That aside i thought I’d use it as my guide and just wing the differences between the ports of FreeBSD and Apt from Debian.
My first attempt (and failure) involved installing ruby and a few other packages from Apt. Never having dealt with it before all the references to “gem” and “rake” etc were foreign to me, so I installed a few other packages that looked related too. Short version; this all ended up in a nauseating mess of version incompatibilities, file path issues, and multiple versions of the same program floating around the system with different ones being used by different commands.
So I purged all those packages and grabbed ruby and rubygems tarballs. Installed those, and tried again. This time got closer, and actually got Snorby running, however with one issue… Any time I tried to view the detail of an event, I got an error. This was linked to their being no sensor info even though all the events were logging fine.
This could have possibly been resolved easily enough, had I been able to get into the command line debug console for Snorby. I’d jumped onto IRC and found Dustin Webber (aka “mephux”); the author of Snorby. Working with him we tried a pile of things and found that there was a hugely messed up mix of files and stuff. The most annoying error while trying to access the debug console was “Rails requires RubyGems >= . Please install RubyGems and try again: http://rubygems.rubyforge.org” which given Snorby was installed and running seemed to indicate that Rails and RubyGems were there and playing together prior to this to get things going at all.
Everything was looking completely snotted so after around an hour of getting nowhere, I decided to start from scratch again. I de-installed anything vaguely resembling ruby, rails, gems etc. I also located and forcibly deleted any cached files, directories etc that bared any resemblance. I wanted to make sure it was REALLY cleared out!
The following is how I got things to work (or as near as I can remember) after that.
I grabbed ruby-1.8.7-p174.tar.gz and rubygems-1.3.5.tgz from their appropriate websites. While the recipie I was using as a guide didn’t mention the specific install of ruby itself, gems required it to install (I assume the ruby-gems port installs it as a dependency maybe).
Installing ruby was a stock standard untar, ./configure, make, make install. I did run configure with the ‘–enable-shared’ flag this time which I hadn’t earlier, although I’m not sure if that made any difference at all. once that’s done, rubygems was a bit different, needing to run “ruby setup.rb” after untarring as the method to set it up.
Once that was done, things became a bit more standard. I’d already grabbed Snorby using git and placed it in /var/www/snorby/ (I made it lower case because I was expecting to have the “snorby” in a url, however the folder was named with a capital S when first grabbed.
The command sequence from there (I’m not listing the output to keep it brief) was…
$ gem install prawn
$ gem install rake
$ gem install rails
$ gem install dbd-mysql
$ gem install passenger
At first I accidentally missed the rails one and dbd-mysql gave an error, but after I corrected my mistake it installed fine.
The passenger-install-apache2-module is one of a few scripts that passenger seems to have for getting things setup with different web servers. It is pretty helpful and takes you through a couple of steps to get things setup. It will tell you if you are missing anything it needs, and even gave the correct apt command to get anything it needed. At the end, it tells you three lines you need to add to your Apache config.
After that, it was time to get Snorby sorted again.
Setup database.yml and email.yml as per the normal docs. In my case I cut email.yml down to remove the authentication stuff.
As per the doco “rake gems:install” was next.
Next was the database.
$ rake snorby:reset RAILS_ENV=production
$ rake snorby:setup RAILS_ENV=production
$ rake snorby:update RAILS_ENV=production
Now, I’m not 100% convinced that I ether needed all three of these commands or any of them actually. I had the database setup already with barnyard logging to it. This process dropped the entire db and re-created the tables, but I can’t spot anything specific schema wise that Snorby added that wasn’t there before. However, while debugging these three command were given to me by Dustin as what was needed and I didn’t have the patience at the time to test different combinations or the knowledge of ruby to check the code for exactly what each did.
After that, restart Barnyard and Apache. Id also made the changes to the Apache DocumentRoot by now to work as per the global-security version of the recipe, these were left out of the one on the Snorby Wiki but seem essential to getting the ruby stuff working rather than just showing as files.
Browsing to the appropriate url it now all seemed go. I found I’d missed the iconv install but an “apt-get install libiconv-ruby” fixed that. I could see alerts being logged, the sensor showed fine, and now 16 hours later Snorby is running happily!
The two other things I did come across that I didn’t spot in the doco’s but that showed in the Apache logs were changing permissions on snorby/log/production.log and the snorby/tmp/ folder to allow the application logging and the generation of email attached PDF’s respectively. The log snippet that showed this up was:
Rails Error: Unable to access log file. Please ensure that /var/www/snorby/log/production.log exists and is chmod 0666. The log level has been raised to WARN and the output directed to STDERR until the problem is fixed.
spawn> Exception in child - Errno::EACCES: Permission denied - /var/www/snorby/tmp/tmp-event.pdf
A huge thanks to Dustin for not only writing the thing, but for several hours of assistance in trying to track down the problems to get it working under my particular config.
Reflecting I think the first problem with lack of a sensor was because the Snorby install had blown away a perfectly good database, combined with barnyard2 not restarting properly causing it to manage to keep logging events when it reconnected to the db, but not recreating the sensor info in the db as that seems to be done on barnyard loading.
You may ask why barnyard didn’t reload properly… I “think” that may have been do to with the load the server was under: this sensor is in a very high traffic network so snort and barnyard were working their butts off to keep up with the traffic that was being sniffed – so even though barnyard was told to restart, I think it was still trying to finish the records it was working on inserting into the database, which was in the tens of thousands. I actually fully “kill -9″ed it at the last restart but previously I hand just told it to restart without checking process id’s etc.
I’ll try and update this post to clarify anything if I get questioned or if I feel motivated to expand anything into more detail. Feel free to post any questions you have on the install process of Snorby or the other components here or go checkout the Snorby website for places to get help if you’re having trouble with Snorby itself. As I said, I know nothing of Ruby so my ability to assist with a lot of Snorby specific problems is probably pretty limited.
Edit [2009-09-10 13:09]: Ok, so not everything was perfect. Turns out the cron jobs to do the daily/weekly/monthly reporting weren’t installed for some reason (apparently I’m not the only person to have this happen). To fix it:
$ gem sources -a http://gems.github.com
$ gem install javan-whenever
$ whenever --update-crontab snorby --set environment=production
and it should be all setup to run. =]
- Snorby Homepage: http://www.snorby.org/
- Snorby Wiki: http://wiki.github.com/mephux/Snorby (has contact info and install doco)
- Snort Homepage: http://www.snort.org/
- Snort Additional Downloads: http://www.snort.org/downloads/additional-downloads/ (where I found BASE, Snorby, Barnyard2 and has a pile of other tools as well)