That's handy, especially when fronted by Snorby, a powerful interface that makes analysis a snap and which makes a Snort-specific alternative to using Splunk's GUI:
We need to work in superuser mode so take root:
Installing the packages
Install Snorby with Ruby on Rails to power it, Snort's MySQL version and dependencies:
Snort's installation options
During Snort's install you'll be prompted twice.
Specifying the network
Snort wants the IP address range of your local network, in CIDR notation which formats along the lines of 192.168.1.0/24. If you're unsure of your address then leave the default, clarify the value with your web host and later edit the var HOME_NET variable in the configuration file /etc/snort/snort.conf.
Point to the database
Say No to this. Due to the bundled installation with Snorby we'll set this manually.
Ruby on Rails dependencies
Ruby needs these gems, or packages, for Snorby.
Be patient, they can take a while to install. We'll symlink them with the ln -s command:
Creating the web interface
We'll use Git, the version control system rather like Subversion but with a better name, to clone Snorby. Then we move Snorby into its own folder in the web root. Setting an export value to your web root path, likely /var/www or /home/USER/ public_html, will help a bit, so play along and change /your/web-root/path to something accurate:
Jolly good. Paste this lot:
Creating a sub-domain using an A record
With this method, you call up Snorby at http://snorby.somesite.com. There are other ways to locate the front-end, but this is terribly tidy.
Create an A record for one of your domains in your DNS manager, else using a tool such as Bind. It may take a little while for the record to resolve, so allow for that.
Setting up the virtual host file
You'll need a virtual host file to clue in Apache. Crack open a fresh blank:
Furnish that with an edited version of this skeletal syntax:
That web root path must retain /snorby/public, so leave that.
Creating the database
Snort will write to a MySQL db, so call the application:
Provide your MySQL password and, swapping the snortDB, snortUSER, and snortPASS values for secure alternatives, paste this lot:
And, again changing for your values, import the database scheme into Snort:
You'll be prompted for your shiny new password, in this example snortPASS. Meanwhile, Snort needs those database details, so crack open its configuration file:
And run a search, that's CTRL-W, for this #commented line:
Uncomment it by losing the # and change the values so it looks something like this:
As for Snorby, it needs details both for that database and your system e-mail connection. We'll rename the files, then you can edit them:
Deploying Ruby on Rails with Passenger
Passenger is a boon in assisting us to set up RoR. Execute it:
The wizard may flag missing dependencies and, if so, do as it says and install those before again running the previous passenger-.. command. A system update can help too.
Head into the Snorby web files and use rake to set it up with cronjobs and the database:
Or if you cocked up somehow, you may need to reset the setup. In that case, use this instruction instead, but do know that this deletes existing data:
Browsing to Snorby
Cruise to the Snorby panel at something like http://snorby.somesite.com, logging in with the default username and password, respectively snorby and admin. snorby and admin? Save our sites! Let's change that immediately…
At the dashboard, click on Settings, then My Settings, and change your credentials for something safer and, while you're about it, add an e-mail address.
Well, by way of a test, a portscan is somewhat less drastic. Run a scan or two from your local machine to assess the remote machine's ports:
And refresh Snorby's dashboard to see the first results:
Have a play. From the panel, you can click through to live as well as archived threats, reference them, their sources via WHOIS, and the ports they targeted. You can up or downgrade event importance, make case notes, and export or e-mail reports, study packet payloads, and much more. Most importantly, given the power of Snort combined with the usability of Snorby, you can unearth potential weaknesses, nipping problems in the bud.
Or if you prefer headaches, swapping your database credentials, try this:
That's why we installed Snorby.
Configuring the network
- var HOME_NET This is the variable mentioned already, where we specify our network, whether one or more IPs. When you've set this..
- var EXTERNAL_NET … Change any for !$HOME_NET to exclude your network
Updating Snort's rule-base
Sourcefire Vulnerability Research Team™ (VRT)
The official rules. Pay up for fresh rules or wait thirty days and get them for free:
A mature open source community sharing threat intelligence and fresh rules:
As far as the updating process is concerned, the best thing to do is to set up cron to do that daily. You could use one of a couple of updater scripts, Oinkmaster or pulledpork:
They're documented well enough. I use the former, Oinkmaster. For that, basically, you grab a code from Snort which you add to the app's configuration file, run a test, and set up the cronjob. This is no big deal, as I tend to say, so I'll leave you to it. No slacking now.