2013

Gerben Kleijn

NTS 415

11/12/2013

Snort Installation Guide

Contents Introduction .................................................................................................................................................. 3

Installation and Preparation of the OS ......................................................................................................... 3

Installing Snort .............................................................................................................................................. 4

Installing the Data Acquisition API (DAQ). ............................................................................................ 4

Installing libdnet.................................................................................................................................... 4

Installing Snort ...................................................................................................................................... 4

Installing Snort Rules ..................................................................................................................................... 5

Configuring Snort .......................................................................................................................................... 6

Installing Barnyard2 ...................................................................................................................................... 7

Configuring Barnyard2 .......................................................................................................................... 7

Configuring the mysql database ................................................................................................................... 8

Installing Snort Report .................................................................................................................................. 8

Running Snort, Barnyard2, and Snort Report ............................................................................................... 9

Snort’s Place in the Network Infrastructure ................................................................................................. 9

Creating a Custom Rule ............................................................................................................................... 11

Testing the Rule .................................................................................................................................. 11

Managing Snort Rule Sets ........................................................................................................................... 12

Installing Pulled Pork ................................................................................................................................... 12

Troubleshooting .......................................................................................................................................... 15

Introduction The current document describes how to install, configure, and manage the installation of Snort on Ubuntu 12.04. The installation is done from scratch, with a fresh operating system, and without the use of a packet manager such as ‘apt-get’ - with the exception for installing pre-requisite packages - to ensure that the latest version of Snort is installed and so that it can be completely customized. Additionally, installing Snort manually will be a valuable experience in a situation where an Internet connection is not available and Snort needs to be installed off-line.

In addition to Snort, the programs ‘Snort Report’ and ‘Barnyard2’ will also be installed. Snort Report provides a web-based front-end interface to Snort, and Barnyard2 is an open source interpreter for Snort unified2 binary output files. Its main use is to take over the task of parsing binary data into various formats so that the Snort process can write to disk in an efficient manner. Barnyard2 reduces the workload for the Snort process so that a minimal amount of network traffic will be missed.

Installation and Preparation of the OS The first step is to install the base operating system on which Snort will run. Ubuntu 12.04 was chosen because it provides a stable and fairly lightweight environment, so that no resources are taken away from Snort to perform its function. Only the necessary packages for Snort, Snort Report, and Barnyard2 to perform will be installed.

After Ubuntu was installed, vmware-tools was installed on the system. Installing vmware-tools is a best practice whenever working with virtual machines, as it is designed to enhance the performance of the virtual machine’s guest operating system and it improves management of the device.

Several pre-requisite packages for Snort, Snort Report, and Barnyard2 were installed. Without the presence of these packages on the system, the aforementioned programs might experience issues during installation or in their performance. The list of prerequisite packages was created using available documentation on Snort, Snort Report, and Barnyard2. The packages were installed with the command “sudo apt-get install nmap nbtscan apache2 php5 php5-mysql php5-gd libpcap0.8-dev libpcre3-dev g++ bison flex libpcap-ruby make autoconf libtool mysql-server libmysqlclient-dev -y”. The ‘-y’ flag automates the process by automatically answering ‘yes’ to the question if the user is sure they want to install these packakges.

The last package that was installed, which was not technically required as a pre-requisite for the aforementioned programs, was OpenSSH-server. The reason this was installed is so that the virtual machine can be easily accessed through SSH for management purposes. Additionally, having an SSH connection will prove handy later on while testing Snort’s performance.

Finally, the commands “sudo apt-get update” and “sudo apt-get upgrade” were issues to ensure that all installed packages on the operating system are up-to-date. At this point it is recommended to create a snapshot of the virtual machine. If anything goes wrong later on in the installation and configuration process for Snort, Snort Report, or Barnyard2, then the virtual machine can be easily reset to a prior state from which the user can quickly retry the installation process.

Installing Snort

Installing the Data Acquisition API (DAQ). Before installing Snort, the installation of the Data Acquisition API (DAQ) is recommended. The DAQ was introduced with Snort 2.9.0 and it replaces direct calls into packet capture libraries. It adds an abstraction layer and a suite of pluggable modules that can be selected at run-time, making it easy to change how Snort operates without having to recompile the source code.

As of writing, the current version of DAQ is 2.0.1. Installation of the package file daq-2.0.1.tar.gz can be done with the following commands

Sudo tar zxvf daq-2.0.1.tar.gz

Cd daq-2.0.1

Sudo ./configure

Sudo make

Sudo make install

Installing libdnet Another installation that needs to be done before installing Snort is that of libdnet. Libdnet provides a simplified, portable interface to several low-level networking routines. As of writing, the current version of libdnet is 1.12. Installation of the package file libdnet-1.12.tgz can be done with the following commands:

sudo tar zxvf libdnet-1.12.tgz

cd libdnet-1.12/

sudo ./configure

sudo make

sudo make install

sudo ln -s /usr/local/lib/libdnet.1.0.1 /usr/lib/libdnet.1

The last command creates a symbolic link to libdnet and places it in the appropriate directory.

Installing Snort Once the DAQ and libdnet are installed, the Snort core packages can be installed on the system. As of writing, the current version of Snort is 2.9.5.5. Installation of the package snort-2.9.5.5.tar.gz can be done with the following commands:

sudo tar zxvf snort-2.9.5.5.tar.gz

cd snort-2.9.5.5

sudo ./configure --prefix=/usr/local/snort --enable-sourcefire

sudo make

sudo make install

sudo mkdir /var/log/snort

sudo mkdir /var/snort

sudo groupadd snort

sudo useradd -g snort snort

sudo chown snort:snort /var/log/snort

The ‘--prefix=’ flag for the ‘./configure’ command defines where Snort will be installed. This can be changed according to the user’s preferences. The ‘--enable-sourcefire’ flag enables sourcefire specific build options.

After Snort finishes installing, the other commands create directories for Snort’s log files, as well as adding the group ‘snort’ and adding a new user ‘snort’ to that group. Finally, ownership of the ‘/var/log/snort’ directory is transferred to user and group ‘snort’.

Installing Snort Rules In order to generate alerts for suspicious or malicious traffic, Snort uses rules. These rules specify what types of network traffic are suspicious and Snort matches live traffic against them. If any traffic matches a rule, an alert is generated in Snort’s log file. A set of Snort rules can be downloaded at www.snort.org/snort-rules. Paid subscribers can get the latest rules instantly, whereas Snort users without a paid subscription can get these rules 30 days later.

Once the latest rules have been downloaded, the following commands can be used to unpack them to the correct directory:

sudo tar zxvf snortrules-snapshot-2955.tar.gz -C /usr/local/snort

sudo mkdir /usr/local/snort/lib/snort_dynamicrules

sudo cp /usr/local/snort/so_rules/precompiled/Ubuntu-12-04/x86-64/2.9.5.5/* \

/usr/local/snort/lib/snort_dynamicrules

sudo touch /usr/local/snort/rules/white_list.rules

sudo touch /usr/local/snort/rules/black_list.rules

sudo ldconfig

The second command creates a directory for Snort pre-compiled rules, and the next command copies a set of pre-compiled rules for Ubuntu 12.04 64bit into this directory. Pre-compiled rules are Snort rules that are written in the ‘C’ programming language, which allows for a much greater set of conditions to match traffic against than the regular Snort rule language. The last two commands create files for white-list and black-list rules in the Snort rule directory.

Configuring Snort When Snort is run as an IDPS, it uses information from a configuration file to determine what network(s) to protect, where to find network traffic rules, where to write alerts to, and much more. The configuration file is ‘snort.conf’ and since we installed Snort to /usr/local/snort this file is located at ‘/usr/local/snort/etc/snort.conf’. Several entries in this file need to be verified for accuracy and/or changed:

Perhaps most importantly, the configuration file should point at the correct location for Snort’s rules. Verify that the following lines point at the correct paths:

var RULE_PATH /usr/local/snort/rules

var SO_RULE_PATH /usr/local/snort/so_rules

var PREPROC_RULE_PATH /usr/local/snort/preproc_rules

Additionally, if reputation preprocessing is used, then the following lines also need to point at the correct paths for the ‘white_list.rules’ and ‘black_list.rules’ files:

var WHITE_LIST_PATH /usr/local/snort/rules

var BLACK_LIST_PATH /usr/local/snort/rules

The configuration file also points at the directories for the dynamic preprocessors, the dynamic engine, and the dynamic detection directory. The dynamic detection directory contains the pre-compiled Snort rules that we previously extracted, and the dynamic preprocessor and the dynamic engine are used to process these rules. Verify that the following lines point at the correct paths:

dynamicpreprocessor directory /usr/local/snort/lib/snort_dynamicpreprocessor/

dynamicengine /usr/local/snort/lib/snort_dynamicengine/libsf_engine.so

dynamicdetection directory /usr/local/snort/lib/snort_dynamicrules

Lastly, the configuration file will specify where Snort alert logs are to be stored, and in what format. If the program Barnyard2 is used then these alert logs need to be in the unified2 (.u2) format. Barnyard2 reduces the load on the main detection engine by reading the alert logs and entering them into a database. Find the following line in the configuration file:

#output unified2: filename merged.log, limit 128, nostamp, mpls_event_types, vlan_event_types

Below this line, enter the following:

Output unified2: filename snort.u2, limit 128

These are all the changes that need to be made to the Snort configuration file right now. Save the file and exit.

Installing Barnyard2 As was mentioned previously, Barnyard2 reads Snort alert logs, parses them, and enters the information into a database. The current version as of writing is 2.1.13. Installation of the package v2-2.1.13.tar.gz can be done with the following commands:

sudo tar zxvf v2-2.1.13.tar.gz

cd barnyard2-2-1.13

sudo autoreconf -fvi -I ./m4

sudo ./configure --with-mysql --with-mysql-libraries=/usr/lib/x86_64-linux-gnu

sudo make

sudo make install

The ‘autoreconf’ command is issued to update generated configuration files. The ‘–f’ flag forces the command to consider all files obsolete, the ‘-i’ flag installs missing auxiliary files, and the ‘-v’ flag delivers verbose output. The flag ‘-I’ is used to append a directory to the search path, in this case the ‘m4’ directory. The ‘--with-mysql’ flag for the ‘configure’ command specifies that Barnyard2 will output to a mysql database, and the ‘--with-mysql-libraries’ flag specifies the location for the mysql client libraries.

After Barnyard2 has been installed, issue the following commands:

sudo cp etc/barnyard2.conf /usr/local/snort/etc

sudo mkdir /var/log/barnyard2

sudo chmod 666 /var/log/barnyard2

sudo touch /var/log/snort/barnyard2.waldo

sudo chown snort.snort /var/log/snort/barnyard2.waldo

The barnyard2.conf file is the configuration file for Barnyard2. It’s convenient to have this in the same general directory as where Snort is installed. A directory also needs to be made for Barnyard2 log files, and the ‘chmod’ command makes this directory readable and writeable to everyone. The next command creates a ‘barnyard2.waldo’ file, which is used as a bookmark in the event that Barnyard2 is interrupted. Finally, the ownership of the ‘barnyard2.waldo’ file is assigned to the user and group ‘snort’.

Configuring Barnyard2 Just like Snort, Barnyard2 uses a configuration file to read information on how to perform its function. This is the barnyard2.conf file, located in /usr/local/snort/etc/barnyard2.conf. To make sure Barnyard2 is configured correctly a few lines in barnyard2.conf need to be verified and/or changed. The following lines all need to point to the correct paths in the Snort installation directories:

config reference_file: /usr/local/snort/etc/reference.config

config classification_file: /usr/local/snort/etc/classification.config

config gen_file: /usr/local/snort/etc/gen-msg.map

config sid_file: /usr/local/snort/etc/sid-msg.map

Additionally, the following lines need to be changed from this:

#config hostname: thor

#config interface: eth0

#output database: log, mysql, user=root password=test dbname=db host=localhost

To this (substitute appropriate hostname, interface, and password):

config hostname: localhost

config interface: eth1

output database: log, mysql, user=snort password=YOURPASSWORD dbname=snort host=localhost

Note that not only were the lines changed, but they were also uncommented.

Configuring the mysql database Barnyard2 will read and parse the Snort alert log files and enter them into a mysql database. In order to do so, the database needs to be prepared and ready to receive Barnyard2’s input. The first thing that needs to be done is for a database to be created. This can be done with the following commands:

echo "create database snort;" | mysql -u root -p

mysql -u root -p -D snort < ./schemas/create_mysql

Next, a mysql user has to be created for Snort, because running the Snort and Barnyard2 processes as root is unsafe. The user can be created with the following command, where ‘YOURPASSWORD’ is replaced with an actual password:

echo "grant create, insert, select, delete, update on snort.* to snort@localhost identified by 'YOURPASSWORD'" | mysql -u root –p

Mysql and the Snort database are now ready for use.

Installing Snort Report Snort Report provides a web-based front-end interface to view Snort alert logs. It pulls information from the mysql database and displays it to the user in an easy-to-read format. As of writing, the current version of Snort Report is 1.3.4. The file snortreport-1.3.4.tar.gz can be installed with the following command:

Sudo tar zxvf snortreport-1.3.4.tar.gz –C /var/www

This extracts Snort Report into the directory where web pages are located for the Apache2 webserver that was installed at the beginning of this installation process. However, before the program becomes useable, a single modification has to be made in its configuration file located at /var/www/snortreport-1.3.4/srconf.php. The value of the following line needs to be changed from:

$pass = “PASSWORD”;

To the user’s actual password. Then save the file and exit to the command prompt.

Running Snort, Barnyard2, and Snort Report Everything is installed, configured, and ready to be executed. The first program to run will be Snort, which we can execute with the following command:

/usr/local/snort/bin/snort -D -u snort -g snort -c /usr/local/snort/etc/snort.conf -i eth0

This command starts snort as a daemon (-D), as user snort (-u) of group snort (-g), using the snort.conf configuration file (-c), and gathering network traffic from interface eth0 (-i).

Next, Barnyard2 can be started using the following command:

/usr/local/bin/barnyard2 -c /usr/local/snort/etc/barnyard2.conf -d /var/log/snort -f snort.u2 –w /var/log/snort/barnyard2.waldo –D

This command starts Barnyard2 with the use of the barnyard2.conf file (-c), using Snort log files from /var/log/snort (-d), using files that start with ‘snort.u2’ (-f), using the barnyard2.waldo file as a bookmark (-w), and Barnyard2 will run as a daemon (-D).

The user can verify that both commands started successfully and are running in the background by using this command:

Ps –ef | grep snort

This command should return processes for Snort and for Barnyard2, the first running as user ‘snort’ and the second running as the user.

To see the alerts generated by Snort and entered into the database by Barnyard2, Snort Report can be opened by going to http://localhost/snortreport-1.3.4/alerts.php. This website should give an overview of alerts, organized by type or signature, and the user can ask for more specific details such as the origin and target of the traffic as well as what type of traffic was observed.

The installation and configuration process should now be complete, and Snort is basically operational. However, that doesn’t mean it’s ready to be used in a production environment just yet. Every organization has different needs for their network, and different types of network traffic. Seeing FTP traffic on the internal subnet might be normal for one organization, whereas somewhere else it would be a violation of policy. Therefore, it cannot be expected that Snort is ready to be used immediately after installation – the rule set it uses for alerts has to be customized to the organization. Additionally, Snort’s network settings need to be configured for how Snort is to be placed in the network infrastructure. The next sections will show an example of how Snort can be placed in the network, and how Snort rules can be written and managed.

Snort’s Place in the Network Infrastructure Snort needs to be customized for how it will be used in the network infrastructure. An IDS uses sensors to gather information on network traffic, because in larger and more distributed networks it’s impossible to gather all network traffic at any single point. Sensors are placed distributed over the

network, and they all send their alert reports to a centralized database where they are analyzed and processed. A Snort sensor will have different rules depending on where it is placed on the network, and of course its network configuration will vary as well. Customization of Snort for deployment is very important to get the most out of the software.

The current section will describe how Snort can be used on a simple, flat network with only a single subnet. Figure 1 shows the logical layout of the virtual network that was used to test Snort. All virtual devices were hosted on a personal laptop. Vyatta virtual routing software was used to set up a virtual router between the virtual machines. Vyatta was set up with a bridged network connection on eth0, meaning it connected directly to a physical home router to get out to the Internet. Additionally, the eth0 interface was set up to mirror all incoming traffic to eth2 – to Snort. Vyatta’s eth1 interface was set up with a custom virtual subnet in the 192.168.133.0/24 range. The only other device on this subnet was a virtual machine running Windows XP SP2, which functioned as the device that Snort had to monitor. Vyatta’s eth2 interface was also set up with a custom virtual subnet, and the only other device on this subnet was the virtual machine running Snort. Neither Vyatta’s eth2 interface nor the Snort box were assigned an IP address to make it more difficult for the Snort box to be compromised. To keep the setup relatively simple, Vyatta did not perform any NAT, DHCP, or Firewall functions.

Snort’s configuration file was altered to specify that the $HOME_NET variable was equal to 192.168.133.0/24, meaning Snort would generate alerts for any suspicious or malicious traffic going to this subnet. A virtual machine running Kali Linux was set up as the system to provoke Snort alerts. Kali was set up with a bridged network connection, just like Vyatta. However, the default gateway was set to be Vyatta (192.168.1.10) rather than the physical home router. This allowed it to connect to the virtual machine running Windows XP. OpenSSH v3.8.1 was installed on the Windows XP virtual machine, to provide a service for Kali to connect to.

Internet

192.168.133.100

Personal Laptop

Vyatta

Windows XP

Eth0192.168.1.20

Eth1192.168.133.1/24

Virtual Environment

SnortNo IP address

Eth2Mirror eth0

No IP address

Kali VM192.168.1.20

Figure 1. Topology of the virtual network used to test Snort

Creating a Custom Rule To really customize Snort to the organization in which it will function, one may have to modify existing rules or write completely new ones. Although it is likely that Snort already has a version of the sought-after rule in its rule set, it is still important to know how to write a Snort rule in case an incident occurs that needs to be responded to quickly, perhaps without time or access to browse Snort’s rule documentation. This section will focus on how to write a custom Snort rule. Specifically, the Snort rule will create an alert if any system tries to SSH into any machine on the network that Snort is protecting.

A simple Snort rule consists of a rule header and rule options. The header contains the rule’s action, protocol, source and destination IP addresses and netmasks, and the source and destination ports information, in that order. The rule option section contains alert messages and information on which parts of the packet should be inspected to determine if the rule action should be taken. Rule options are enclosed in parentheses. An example of a simple Snort rule is as follows:

alert tcp any any -> 192.168.1.0/24 111 (content:”|00 01 86 a5|”; msg:”mountd access”;)

This rule will generate an alert with the message “mountd access” if any host from any port establishes a tcp connection with a host on the subnet 192.168.1.0/24 on destination port 111, and the packet contains the hexadecimal string “00 01 86 a5”. However, there are two elements missing from this rule that are needed by Snort, namely the SID and REV, which are the Snort Rule ID and the Revision number. The SID uniquely identifies each Snort rule, and the REV indicates revisions of specific rules. For custom made rules, the SID should be equal to or greater than 1,000,000. Adding these two elements to the rule, it now looks like this:

alert tcp any any -> 192.168.1.0/24 111 (content:”|00 01 86 a5|”; msg:”mountd access”; sid:1000000; rev:1)

Any of the elements in this simple Snort rule can be substituted for a wide range of options – including variables – which allows for the creation of very specific and customized Snort rules. For specifics on the types of actions, protocols, and rule options that are available the best source would be Snort’s manual on writing customized rules, located at manual.snort.org/node27.html. However, knowledge of the Snort rule syntax now allows for the creation of a Snort rule that will generate an alert if any host tries to SSH into any machine on the network that Snort is protecting. An example of such a rule would be:

alert tcp any any -> $HOME_NET 22 (msg:"SSH attempt"; sid:1000001; rev:1;)

This rules specifies that Snort should generate an alert with the message “SSH attempt” if any host from any port tries to establish a connection with any host that is part of the home network on port 22.

Testing the Rule To test the rule, Snort was started using the command:

Sudo /usr/local/snort/bin/snort –u snort –g snort –c /usr/local/snort/etc/snort.conf –D

Barnyard2 was started using the command:

Sudo /usr/local/bin/barnyard2 –c /usr/local/snort/etc/barnyard2.conf –d /var/log/snort –f snort.u2 \

-w /var/log/snort/barnyard2.waldo –D

The Kali Linux virtual machine was then used to establish an SSH session to the Windows XP virtual machine, using the command:

Ssh –l Administrator 192.168.133.100

The attempt to SSH into the Windows XP virtual machine was successful. Opening up Snort Report on the Snort virtual machine confirmed that Snort had picked up the SSH connection and generated an alert as a result.

Managing Snort Rule Sets Getting Snort to work on a simple, flat network and with only a single Snort rule is easy. However, getting the desired results when using numerous sensors distributed across subnets, with thousands of rules and different rules for each sensor is a lot more difficult. Again, customization is the key to getting the most out of Snort. Fortunately, some of this task can be automated.

Manually reviewing all Snort rules and determining which ones apply to the organization’s network is a task beyond the time and resources of most network security administrators. There are over 4,000 rules that are enabled by default when Snort is started, and there are many others that are delivered commented out. Fortunately, there are programs that automate the customization process to some extent – Oinkmaster and Pulled Pork are two examples. These programs are basically scripts that download the latest rules and also provide management functionality. For instance, Oinkmaster can download the latest rules for Snort, compare them to the customized rule set that is already in place, and add only those rules that match certain pre-determined requirements. It even works on multiple sensors that might each have their own customized rule set.

Pulled Pork does basically the same thing but provides even more functionality. It supports the previously discussed shared object or pre-compiled rules, and it enables the user to take advantage of Snort’s policies. Snort uses four states that rules are placed in when they are released; (1) connectivity, (2) balanced, (3) security, and (4) no state. The connectivity rules will generally only provide alerts for well-known threats and will provide few false positives. The balanced rules will provide a good starter rule set for most organizations but will probably need a little tuning along the way. The security rules provide much more coverage but also a lot more false positives and this rule set needs to be finely tuned. Finally, the no state rules absolutely require review individually before being included, as they are likely to provide a lot of false positives or are only applicable for specific and non-prevalent pieces of software. By using Pulled Pork, users are provided an automated way to deal with these Snort policies and to apply the correct one to the IDPS system. In fact, Snort strongly encourages anyone that uses their program to also use Pulled Pork, or “you are going to have a gigantic deprecation in functionality” (Snort.org, 2012).

Installing Pulled Pork This section will describe how to install and configure Pulled Pork. During the installation and configuration, the previously specified directory where Snort is installed will be used. For another Snort installation directory, those would have to be changed.

To use Pulled Pork it is required to be a registered user on Snort.org, and an Oinkcode is needed. An oinkcode can be generated for registered users here: https://snort.org/account/oinkcode. This Oinkcode will be used later.

As of writing, the current version of Pulled Pork is 0.7.0, and can be downloaded from http://pulledpork.googlecode.com/files/pulledpork-0.7.0.tar.gz. After downloading the file, unpack it using the following command:

Sudo tar zxvf pulledpork-0.7.0.tar.gz

Then move the Pulled Pork configuration file to the directory where the other Snort related configuration files are stored:

Sudo mv pulledpork-0.7.0/etc/pulledpork.conf /usr/local/snort/etc/

In the pulledpork.conf file, there are several lines that need to be changed. There are also several options that the user can customize, so it is recommended to read through the entire configuration file carefully. It is not too long and generally the options are well commented. The following line needs to be changed with your Oinkcode:

rule_url=https://www.snort.org/reg-rules/|snortrules- snapshot.tar.gz|\ <enter oinkcode>

If you want the rule documentation as well, with explanations of every single rule, then also enter your oinkcode for the following line. Otherwise comment it out.

rule_url=https://www.snort.org/reg-rules/|opensource.gz|<enter oinkcode>

Other lines that need modifications:

rule_path=/usr/local/snort/rules/snort.rules

local_rules=/usr/local/snort/rules/local.rules

sid_msg=/usr/local/snort/etc/sid-msg.map

If you are using Barnyard2 version 2.2 or higher:

sid_msg_version=2

sorule_path=/usr/local/snort/lib/snort_dynamicrules/

config_path=/usr/local/snort/etc/snort.conf

distro=Ubuntu-12-04

The pulledpork.conf file should now be ready for use. It just needs to be made executable:

Sudo chmod 755 /usr/local/snort/etc/pulledpork.conf

Next, some changes need to be made to the snort.conf file. All the ‘include $RULE_PATH’ entries from the file need to be removed, which can easily be done with the following sed command:

Sudo sed -i '/^include $RULE_PATH/d' /usr/local/snort/etc/snort.conf

Then, open up the snort.conf file and append the following two lines at the end:

Include $RULE_PATH/snort.rules

Include $RULE_PATH/local.rules

Pulled Pork doesn’t use inidivual rule files like Snort does by default. Instead, it puts all the rules into a single file called snort.rules, which is what the Snort configuration file will now read because of the last two commands.

Next, the individual rule files need to be deleted from the rules directory. However, if you have any custom rules in the local.rules file you’ll want to back them up first. We also want to back up the white_list.rules and the black_list.rules files:

Cd /usr/local/snort/rules

Sudo mv local.rules white_list.rules black_list.rules /tmp

Sudo rm /usr/local/snort/rules/*.rules

Cd /tmp

Sudo mv local.rules white_list.rules black_list.rules /usr/local/snort/rules

Additionally, a directory need to be created that will be used by Pulled Pork:

Sudo mkdir /usr/local/snort/rules/iplists

Pulled Pork should now be ready for use! Run it with the command:

Sudo Pulledpork.pl –c /usr/local/snort/etc/pulledpork.conf

The output should look like this:

...

Rule Stats...

New:-------185

Deleted:---3

Enabled Rules:----16662

Dropped Rules:----0

Disabled Rules:---15312

Total Rules:------31974

No IP Blacklist Changes

Done

Please review /var/log/sid_changes.log for additional details

Fly Piggy Fly!

If Pulled Pork gives an error message and needs to be troubleshooted, make sure to delete any rule downloads from the /tmp directory before running Pulled Pork again. Any issues with running Snort after updating the rules with Pulled Pork are likely due to errors in the Snort configuration file.

Finally, to automate the process of updating Snort rules with Pulled Pork, a cron task can be made for it by adding a line to the contab. Open up the crontab with this command:

Sudo crontab –e

Then add this line:

0 3 * * * /usr/local/bin/pulledpork.pl –c /usr/local/snort/etc/pulledpork.conf –o /usr/local/snort/rules/snort.rules.

This will run Pulled Pork every day at 3:00 am and output the downloaded generic rules to the snort.rules file.

Troubleshooting This section will describe several issues that were encountered while setting up Snort, Snort Report, Barnyard2, and Pulled Pork, and how they were solved.

Wrong ELF Class Initially, when Snort was run, an error message would appear saying that the dynamic rules library was not correct, and that the ELF class was wrong. Snort would exit with a fatal error. The issue, as it turned out, was that for the installation of Snort a guide was followed that installed Snort on a 32-bit operating system. However, I installed Snort on a 64-bit operating system. The dynamic rules library is created specifically for a 32 or 64-bit operating system, so the user has to be careful to extract and install the right ones. The error message disappeared after I extracted the 64-bit dynamic rules to the appropriate directory.

0 Bytes Snort.u2 Files When Snort executed successfully for the first time, I pulled up Snort Report to look at alerts. Snort Report wasn’t working (discussed more in the next section) and I (wrongfully) assumed it was because it wasn’t getting any data. Since Snort Report pulls data from the mysql database, I logged into the database to look at the entries directly. None of the database tables had any information in them. This suggested that the problem was with Barnyard2. However, inspection of the Barnyard configuration suggested that it should be functioning fine. Going one more step down the line I decided to look at Snort’s alert logs. As it turned out, Snort was creating the correct snort.u2 files in /var/log/snort, but they were all 0 bytes in size.

Several possible solutions were explored before the correct one was found. These included:

Verifying the permissions on the /var/log/snort directory and files

Verifying the information in the snort.conf file

Verifying that the network traffic is seen by using tcpdump

Uncommenting out specific rules in the snort rule files

Completely reinstalling the operating system and programs

However, the problem would persist. Snort would see the network traffic as indicated by report that Snort prints out when the user exits the program, but no traffic generated alerts and therefore nothing was written to the snort.u2 files. In the end, the solution turned out to be running snort with the ‘-k none’ flag. The -k flag tunes the internal checksum verification functionality with alert-mode. Setting it to 'none' turns it off entirely. It possible that this has negative side-effects on Snort's functionality, but it is the only way in which I was able to make Snort generate alerts and write them to the snort.u2 files.

Snort Report With Snort working and writing alerts to log files, Barnyard2 was able to use these log files to write data to the mysql database. However, Snort Report was still not working. Going to the webpage http://localhost/snortreport-1.3.4/alerts.php would pull up the following:

$db->setinst($server);

$db->setuser($user);

$db->setpass($pass);

$db->dbname($dbname);

$db->persist();

$conn = $db->connect();

define("FULL_DATETIME_FORMAT", "Y-m-d H:i:s");

set_time_limit(1800);

require_once("info-retrieval.php");

At first I thought that Snort Report was not able to pull any data from the mysql database, but all the settings in its configuration file were set correctly. Also, the output seems to be a database query string rather than an error message, suggesting that Snort Report is not even able to reach the database. The output was also equivalent to several lines at the end of the Snort Report configuration file.

A Google search revealed that a few other people had encountered the same issue, but no clear solutions to the problem were provided. Browsing around the /var/www/snortreport-1.3.4/ directory revealed that several of the webpages were marked with ‘>?php’ at the top, indicating that the document is a php page. However, the srcvonfig.php file – Snort Report’s configuration file – was only marked with ‘<?’ at the top. It occurred to me that the page might not be recognized as a php webpage, which might be the reason that the lines at the end of the file appeared verbatim when the page was viewed in a web browser.

As it turns out, this was indeed the issue. Several changed had to be made in the /etc/php5/ \ apache2/php.ini file. Specifically, the following line had to be changed:

short_open_tag = Off

This line had to be changed to:

short_open_tag = On

Doing so made http://localhost/snortreport-1.3.4/alerts.php load successfully, and the Snort alerts were displayed successfully.

Snort Alert However, the alert showed up as ‘Snort Alert’, instead of the message that was specified; ‘SSH attempt’. The SID of the alert confirmed that it was generated by the custom rule. Repeating the process described above except without starting Barnyard2 as a daemon revealed the following error message provided by Barnyard2:

[1:1000000:1] Snort Alert [1:1000000:1] [**] [Classification ID: 0] [Priority ID: 0] {TCP} 192.168.1.20:60265 -> 192.168.133.100:22

INFO [dbProcessSignatureInformation()]: [Event: 1] with [gid: 1] [sid: 1000000] [rev: 1] [classification: 0] [priority: 0] was not found in barnyard2 signature cache, this could lead to display inconsistency. To prevent this warning, make sure that your sid-msg.map and gen-msg.map file are up to date with the snort process logging to the spool file. The new inserted signature will not have its information present in the sig_reference table. Note that the message inserted in the signature table will be snort default message "Snort Alert [gid:sid:revision]". You can allways update the message via a SQL query if you want it to be displayed correctly by your favorite interface.

The error message suggests that the cause of the issue is related to the sid-msg.map and gen-msg.map files. A Google search revealed that other users have encountered the error as well, but no clear solution could be found. This is something that I will continue to work on, because the message is an important indicator of what occurred. In this case there was only one custom Snort rule, so it is easy to figure out which rule the alert belongs to. However, if there were many custom Snort rules then the message would be the main indication of what occurred and having them all say ‘Snort Alert’ would be confusing.