Installing Snort and Barnyard2

Date: 2015-10-05 14:19:27

Snort is a widely used packet sniffer and IDS. The Installation of the Snort IDS from sources is quite straight forward with only minor obstacles however the configuration might need a little more effort.

Of course it is possible to use the Snort packages from distributions such as Debian or Ubuntu, however that's often not the latest version, and we want to get our pork as fresh as possible.

Installation of Snort

To compile Snort from source, which is the best method to get the latest copy, we will be using either a Debian system, which of course needs all the tools to configure, compile and install stuff, or Arch-Linux where the following are included in the base-devel package and usually installed already with the system.

Additionally, we need some more stuff in order to compile everything, so we install that too from the official repository.

For Arch-Linux, bison and flex should be installed with base-devel, libpcap-dev is included in libpcap-Package

Snort needs daq, so we download this one first.

Then Snort itself...

... which we unpack.

Next change into daq's directory to compile it...

After daq is successfully installed, we can proceed with Snort. Snort itself needs more libraries, so let's get those too.

We also need libdnet1 (not the "libdnet" from the official debian repository, this is not the libdnet we need) which can be installed using:

Or on Arch-Linux we use libdnet:

Then change into Snort's directory, configure and compile. This configuration works with most setups. If you are using a non-ethernet interface (some Virtual Machines may have this), Snort might complain with an "ERROR: Cannot decode data link type 113". In this case, add --enable-non-ether-decoders to your configure options.

Now we can test whether the piggy runs:

When we start Snort like above, it basically runs like tcpdump -i eth0 -; just sniffing packets and displaying them without any rule processing. For processing rules we need a proper configuration file which we setup later.

Installing Barnyard2

Barnyard2 is a dedicated spooler for Snort unified2 binary file format. It relieves Snort from the task of writing and processing their alerts so it can focus on its main task: Sniffing the network for suspicious activities without bothering a connection to a database or similar.

Barnyard2 monitors Snort's log directory and catches alerts from the spool file as they appear and send them somewhere else, in our case a MySQL database.

Barnyard2 can be obtained from its git repository, so we install git quickly if we haven't done it before...

Since we use MySQL as our alert database, we need to install the required packages in the same run.

Note: The setup of your MySQL server might vary on different distributions and will not be covered here. This tutorial only explains the creation of a user for barnyard2 and the required tables. Please refer to your MySQL documentation if you need help installing the server.

Or for Arch-Linux

We clone barnyard2 to our local harddrive and change into its dicrectory.

To compile Barnyard2 with MySQL support, we first need to locate the libmysqlclient libraries and use this information to configure our makefile.

Configuring Snort so it can be read by Barnyard2

As said above, Barnyard2 reads Snort's unified2 output (and only in the unified2 format). Therefore we have to get Snort using u2 as its log output.

We use the example configuration of Snort, which we can get from the official site or simply copy from the source directory.

Furthermore we create a directory in /var/log for Snort to write its log files.

We also create directories and files for the rules.

The example configuration comes with a list of includes to various rule files. We don´t use them here so we comment them out and just leave our local.rules in the includes.

Using vim or any other text editor, we finally edit snort.conf and set the correct paths and files and also set the $HOME_NET variable to your local network (which we want to protect), assuming we are sitting in a 192.168.1.0/24.

Now we have configured Snort to report in a format that can be read by Barnyard2.

To test if there are any typos in snort.conf or included files, Snort comes with a handy option -T which Tests the config and quits without further packet processing.

Finally we create a user and a group for Snort to run as and set the file permissions:

In a next step we tell Barnyard2 where it can find the spool u2-files to report alerts.

For that purpose, we copy the Barynard2 default config, which comes with handy examples, into a suitable place of our choice and edit it. In the same run, we will also create a directory for Barnyard2 logs.

You can have the database running on a different system, centralize it, having a WebGUI for monitoring (Snorby, BASE or similar) or use other output plugins like syslog or Sguil. But let's stick with MySQL for this tutorial.

Setting up the MySQL database

In this step we create the database for Barnyard2 and the user that we specified in the barnyard2.conf.

Now we can test if everything looks cosy in our barnyard with the following command:

No serious complains and our Barnyard2 seems ready to run. It is possible that barnyard2 complains about a missing or truncated waldo file in the first run, however, this is no big concern since Barnyard2 will simply create the file once alerts occur.

If you are bothered about the sensor name of "localhost:NULL", you can edit the config in the following lines to your personal needs. This comes in handy when you are collecting events from multiple sensors on one server and want some organisation in your database:

Finalizing

To test our installation as a whole, we now create a test rule to see if Snort notices it so we can see it appearing in our database.

Snort rules basically follow this pattern:

To test our installation, we create a rule that applies when a packet with a certain content was send to an Ip number on a HTTP port in our internal network. The content of the packet shall be "donoevil" and the IP number of the attacked can be any server in our HOME_NET while the attacker can sit everywhere, outside or inside.

So we open /etc/snort/rules/local.rules and edit it:

This will rise an alert of the highest priority as soon as Snort spots a packet containing the string "donoevil" (not case sensitive) sent to any Ip on any port. For simplicity we just use any to any. The "sid:" gives our alert a unique ID. It is conventional to use a high number like sid:1000001 for custom rules, even if you have no third party rules in the directory.

Barnyard2 reads the sid-msg.map file we created before to map sids to messages about the attack. This file is normally generated by a script that keeps the rules up to date. For this test case we could leave the file blank or create one for the single rule. If we leave it blank, barnyard2 will only report the sid but won't display any custom messages. This might be enough for a test case but doesn't look very beautiful. For our test rule the following entry in sid-msg.map shall be enough:

Now lets start Snort and Barnyard2 as daemons before we test the setup. Please note that the interface you specify with the -i option must be able to "hear" the packets in promiscuous mode. So if the pig is running on a dedicated box on a switch and not directly on the router you might need to use a network tap, a switch with a monitor port or in the simplest case a dumb hub, because in a switched network your sniffer might not get all the traffic that's not directed to its MAC address.

For this test run, we will run Snort with the option -A console, that outputs all alerts on console.

To test our rule, we can use nc to connect to a HTTP server and request a string containing our trigger phrase. As the victim HTTP server of our mocked attack, we can simply use our router's WebGUI, as long as it is in our protected $HOME_NET.

Snort should now give an output similar to this:

And if everything works with Barnyard2, select * from data; in our snort database something like this should show up:

This is a hex representation of the packet payload data "GET donoevil HTTP/1.1" that went over the network. Snort catched it up and Barnyard2 sent it into our MySQL database.

Since we have seen that our rule works, we can now stop Snort with ^C and start it in daemon mode using -D instead of -A console.

Snort knows many more sophisticated options to detect malicious packets however for this tutorial this simple rule should be enough to test if our setup works at all. It is advised to subscribe to Snort, to get an Oinkcode and to use something like pulledpork to get at least the latest community rule compilation for your IDS.

The setup of pulledpork will be issued in a later article.