UPDATE: Snort 2.9.9.x has been released. Please see the updated series of articles here or my quick install guide here.
I am leaving this older guide online for anyone who wants to install this older version of Snort on Ubuntu, but you really should be using the updated guide for the 2.9.9.x version of Snort, since support for older versions of Snort are set to expire, and the updated guide is kept more up to date and includes BASE instead of Snorby for a Web GUI.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I hope this series of articles has been helpful to you. Please feel free to provide feedback, both issues you experienced and recommendations that you have. The goal of this guide was not just for you to create a Snort NIDS, but to understand how all the parts work together, and get a deeper understanding of all the components, so that you can troubleshoot and modify your Snort NIDS with confidence.
You will probably want to configure your network infrastructure to mirror traffic meant for other hosts to your Snort sensor. This configuration is dependent on what network equipment you are using. If you are running Snort as a Virtual Machine on a VMware ESXi server, you can configure promiscuous mode for ESXi by following my instructions in this article: configure promiscuous mode for ESXi.
For different network infrastrucutre, you will need to do a little research to configure network mirroring for your Snort server. Cisco calls this a span port, but most other vendors call this Port Mirroring. Instructions for Mikrotik (a linux based switch and router product that I like). If you run DD-WRT, it can be configured with iptables, like any linux based system. If you have network equipment not listed above, any search engine should point you towards a solution, if one exists. Note that many consumer switches will not have the ability to mirror ports.
Snort has the ability to do much more than we’ve covered in this set of articles. Hopefully you’ve learned enough through this setup that you will be able to implement more advanced configurations and make Snort work for you. Some things that Snort is capable of:
I would love to get feedback from you about this guide. Recommendations, issues, or ideas, please contact me here.
UPDATE: Snort 2.9.9.x has been released. Please see the updated series of articles here or my quick install guide here.
I am leaving this older guide online for anyone who wants to install this older version of Snort on Ubuntu, but you really should be using the updated guide for the 2.9.9.x version of Snort, since support for older versions of Snort are set to expire, and the updated guide is kept more up to date and includes BASE instead of Snorby for a Web GUI.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Snorby is a web GUI for managing your Snort system. The Snort daemon created in the last section will write all alerts to a Unified2 file, and Barnyard2 will process those alerts into a MySQL database. Snorby will let you browse, search, and profile those alerts from the database in a easy to view way. Snorby is a ruby on rails application, which we will launch with Phusion Passenger on Apache server. An alternative to Snorby is BASE, which is a simpler (less web-2.0) interface that still has a lot of popularity. You can read my article on BASE here (note that that guide hasn’t been updated in a few months, so you should be able to find newer versions of some of the supporting software, like ADOdb).
The bad news is that neither Snorby or BASE are still actively developed. They will work just fine for a hobby or small business setup, but you may want to look at other alternatives if you have more stringent requirements, or need to be able to view more complex visualizations of your data. One option is sguil, and another popular one is Splunk Enterprise (a commercial product, but free for up to 500 MB of log data per day). Splunk has a great interface for Snort alert data. An example of this can be seen in this video from DerbyCon starting at the 43:40 minute mark (this video is also an excellent overview of OpenAppID).
On Ubuntu 15, ruby 1.9 is not available in the repositories, so we need to download and install from source. We need some pre-requisites for Ruby 1.9:
sudo apt-get install -y libgdbm-dev libncurses5-dev git-core curl zlib1g-dev build-essential \ libssl-dev libreadline-dev libyaml-dev libsqlite3-dev sqlite3 libxml2-dev libxslt1-dev \ libcurl4-openssl-dev python-software-properties libffi-dev
Next, let’s install the Ruby Gem pre-requisites:
sudo apt-get install -y imagemagick apache2 libyaml-dev libxml2-dev libxslt-dev git libssl-dev
Snorby installs a number of Ruby gems. To speed up their installation, run the following two commands to prevent the install of documentation when gems are installed:
echo "gem: --no-rdoc --no-ri" > ~/.gemrc sudo sh -c "echo gem: --no-rdoc --no-ri > /etc/gemrc"
Download the ruby 1.9.3 source and install:
cd ~/snort_src/ wget https://cache.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-p551.tar.gz tar -xvzf ruby-1.9.3-p551.tar.gz cd ruby-1.9.3-p551 ./configure make sudo make install
Install the gems required for management and installation:
# These gems will also install other required gems sudo gem install wkhtmltopdf sudo gem install bundler sudo gem install rails sudo gem install rake --version=0.9.2
Download the 2.6.2 version of Snorby and move it to your web root directory:
cd ~/snort_src/ wget https://github.com/Snorby/snorby/archive/v2.6.2.tar.gz -O snorby-2.6.2.tar.gz tar xzvf snorby-2.6.2.tar.gz sudo cp -r ./snorby-2.6.2/ /var/www/html/snorby/
Install all of the Snorby pre-requisites. Ignore warnings about running bundle as root. If you get connection errors when trying to download gems, just re-run the command until it succeeds.
cd /var/www/html/snorby sudo bundle install
Snorby uses database.yml to tell it how to connect to the MySQL server. We will copy the example file to the correct location and edit it with our MySQL root credentials (Snorby will need to create a database):
sudo cp /var/www/html/snorby/config/database.yml.example /var/www/html/snorby/config/database.yml sudo vi /var/www/html/snorby/config/database.yml
You need to change the password field in this database.yml file to reflect the MySQL root password you set when installing MySQL (MySqlROOTpassword if you are following this guide exactly). Note that we will change this later after Snorby has setup the database it needs to use a lower-priviledged MySQL account. The beginning of the file should look like this after editing:
# Snorby Database Configuration # # Please set your database password/user below # NOTE: Indentation is important. # snorby: &snorby adapter: mysql username: root password: "MySqlROOTpassword" # Example: password: "s3cr3tsauce" host: localhost ... and so on
Now we need to create the Snorby configuration file (copied from it’s example file), and update it to point to the correct version of wkhtmlpdf (we use sed to make this change):
sudo cp /var/www/html/snorby/config/snorby_config.yml.example /var/www/html/snorby/config/snorby_config.yml sudo sed -i s/"\/usr\/local\/bin\/wkhtmltopdf"/"\/usr\/bin\/wkhtmltopdf"/g /var/www/html/snorby/config/snorby_config.yml
Now we want to install Snorby. The below command will download the necessary gems and will create a new database called Snorby for use. This can take some time to complete. You can ignore errors about ”Jammit Warning: Asset compression disabled – Java unavailable.”.
cd /var/www/html/snorby sudo bundle exec rake snorby:setup
Now we want to edit the MySQL Snorby database to grant access to a lower privilidged user (we don’t want the Snorby application using the root password to interface with the database). Run the following commands to create a new MySQL user named snorby with password PASSWORD123. You will be prompted for your MySQL root password (MySqlROOTpassword) after the first command:
$ mysql -u root -p myslq> create user 'snorby'@'localhost' IDENTIFIED BY 'PASSWORD123'; myslq> grant all privileges on snorby.* to 'snorby'@'localhost' with grant option; myslq> flush privileges; myslq> exit
Now that we’ve created a new MySQL snorby user and password, edit Snorby’s database.yml to tell Snorby to use the new account rather than the root MySQL account:
sudo vi /var/www/html/snorby/config/database.yml
The file should now look like this (note the changes to lines 8 and 9):
# Snorby Database Configuration # # Please set your database password/user below # NOTE: Indentation is important. # snorby: &snorby adapter: mysql username: snorby password: "PASSWORD123" # Example: password: "s3cr3tsauce" host: localhost development: database: snorby <<: *snorby test: database: snorby <<: *snorby production: database: snorby <<: *snorby
Now we are ready to test Snorby. Run Snorby with:
cd /var/www/html/snorby/ sudo bundle exec rails server -e production
This will start Snorby listening on port 3000. Navigate to http://ip_of_snorby_server:3000 and you should see the logon screen. Don’t log in at this time as we are only testing that the software runs. Use ctrl-c at the command prompt to stop the Snorby server.
We will use Phusion Passenger, an application server module for Apache to launch Snorby. First install pre-requisites:
sudo apt-get install -y libcurl4-openssl-dev apache2-threaded-dev libaprutil1-dev libapr1-dev
Next, install the Passenger gem and the Apache module (we don’t install the Ubuntu repository version of Phusion Passenger because it doesn’t work well).
sudo gem install passenger sudo passenger-install-apache2-module
The Phusion Passenger install wizard will start. Un-check the Python language support (we only need Ruby support) using the arrows and space bar, then use enter to continue through the menu options. After compiling software, the wizard will finally tell you to copy some text to your Apache configuration file. We don’t want to copy the entire output to the Apache configuration file, because Apache now uses separate files for modules (one for the path to the .so file for the module, and one for configuration for the module). We do want the information that is printed, we will just use it slightly differently. Copy the five lines of text that are shown on the screen, as you’ll need them. Hit enter twice to exit the wizard.
My install showed the following 5 lines of text that are needed (yours may be different):
LoadModule passenger_module /usr/local/lib/ruby/gems/1.9.1/gems/passenger-5.0.21/buildout/apache2/mod_passenger.so <IfModule mod_passenger.c> PassengerRoot /usr/local/lib/ruby/gems/1.9.1/gems/passenger-5.0.21 PassengerDefaultRuby /usr/local/bin/ruby </IfModule>
The first line tells Apache the path to the shared object library to load the Phusion passenger module. We want to create a new file for this line. Create this file:
sudo vi /etc/apache2/mods-available/passenger.load
And paste the first line into that file. In my case, I pasted:
LoadModule passenger_module /usr/local/lib/ruby/gems/1.9.1/gems/passenger-5.0.21/buildout/apache2/mod_passenger.so
The final 4 lines specify the configuration for Phusion Passenger. Create the configuration file as follows:
sudo vi /etc/apache2/mods-available/passenger.conf
And paste the two content lines in. You do not need the <ifmodule> tags In my case, I pasted:
PassengerRoot /usr/local/lib/ruby/gems/1.9.1/gems/passenger-5.0.21 PassengerDefaultRuby /usr/local/bin/ruby
Note: yes, the lines above say ruby1.9.1, and we did install ruby 1.9.3. Ubuntu 12 does some file system redirection that makes this happen, but it doesn’t cause any issues.
Next, enable the Passenger module:
sudo a2enmod passenger sudo service apache2 restart
and then verify that it loaded by running the following command (look for Passenger in the output):
apache2ctl -t -D DUMP_MODULES
Now we need to create an Apache website for Snorby:
sudo vi /etc/apache2/sites-available/snorby.conf
with the following content:
<virtualhost *:80> ServerAdmin webmaster@localhost ServerName snorby.sublimerobots.com DocumentRoot /var/www/html/snorby/public <directory "/var/www/html/snorby/public"> AllowOverride all Order deny,allow Allow from all Options -MultiViews </directory> </virtualhost>
Now enable the new site, disable the default site, and reload Apache to see the new configurations:
cd /etc/apache2/sites-available/ sudo a2ensite snorby.conf sudo service apache2 reload cd /etc/apache2/sites-enabled sudo a2dissite 000-default sudo service apache2 reload
Now we need to tell Barnyard2 to output events to the Snorby database that we created above.
sudo vi /etc/snort/barnyard2.conf
Append at the end off the file:
output database: log, mysql, user=snorby password=PASSWORD123 dbname=snorby host=localhost sensor_name=sensor1
We can disable the other output file that you created during the Barnyard2 testing by deleting the previous line (or putting a hash in front of it to disable it), so that it looks like the following:
# output database: log, mysql, user=snort password=MySqlSNORTpassword dbname=snort host=localhost)
Restart Barnyard2 to load the new configuration:
sudo service barnyard2 restart
Snorby needs one service running for database maintenance (a Snorby worker daemon). We will create an systemD daemon for this task. First we need to create the daemon service file:
sudo vi /lib/systemd/system/snorby_worker.service
with the following content:
[Unit] Description=Snorby Worker Daemon Requires=apache2.service After=syslog.target network.target apache2.service [Service] Type=forking WorkingDirectory=/var/www/html/snorby ExecStart=/usr/local/bin/ruby script/delayed_job start [Install] WantedBy=multi-user.target
Now tell systemD that the script exists, and then verify that it installed correctly:
sudo systemctl enable snorby_worker systemctl status snorby_worker.service
Note that this daemon will often list as stop/waiting, and that is ok, because of how it works. You can check the worker job status use the web interface (look under Administration –> Worker and Job Queue). You may need to restart the server once at this stage because a differernt version of the worker service may be running from earlier testing. Verify that the worker process is running from the web interface after a reboot.
To log into the web interface: open a web browser and navigate to http://ip_of_snorby_server. You don’t need to enter the port number, as it is listening on port 80 now. The default login information is:
E-mail: snorby@snorby.org
Password: snorby
(current Snorby documentation lists the email as example.com, not snorby.org. That is incorrect for the 2.6.2 version of Snorby, where the username remains snorby@snorby.org)
If you are logged into the Snorby web interface, then congratulations, your system is fully setup. Continue on to the last part of this guide to see where to go from here: Conclusion.
UPDATE: Snort 2.9.9.x has been released. Please see the updated series of articles here or my quick install guide here.
I am leaving this older guide online for anyone who wants to install this older version of Snort on Ubuntu, but you really should be using the updated guide for the 2.9.9.x version of Snort, since support for older versions of Snort are set to expire, and the updated guide is kept more up to date and includes BASE instead of Snorby for a Web GUI.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Snorby is a web GUI for managing your Snort system. The Snort daemon created in the last section will write all alerts to a Unified2 file, and Barnyard2 will process those alerts into a MySQL database. Snorby will let you browse, search, and profile those alerts from the database in a easy to view way. Snorby is a ruby on rails application, which we will launch with Phusion Passenger on Apache server. An alternative to Snorby is BASE, which is a simpler (less web-2.0) interface that still has a lot of popularity. You can read my article on BASE here (note that that guide hasn’t been updated in a few months, so you should be able to find newer versions of some of the supporting software, like ADOdb).
The bad news is that neither Snorby or BASE are still actively developed. They will work just fine for a hobby or small business setup, but you may want to look at other alternatives if you have more stringent requirements, or need to be able to view more complex visualizations of your data. One option is sguil, and another popular one is Splunk Enterprise (a commercial product, but free for up to 500 MB of log data per day). Splunk has a great interface for Snort alert data. An example of this can be seen in this video from DerbyCon starting at the 43:40 minute mark (this video is also an excellent overview of OpenAppID).
First, let’s install the pre-requisites:
sudo apt-get install -y imagemagick apache2 libyaml-dev libxml2-dev libxslt-dev git ruby1.9.3
Snorby installs a number of Ruby gems. To speed up their installation, run the following two commands to prevent the install of documentation when gems are installed:
echo "gem: --no-rdoc --no-ri" > ~/.gemrc sudo sh -c "echo gem: --no-rdoc --no-ri > /etc/gemrc"
Install the gems required for management and installation:
# These gems will also install other required gems sudo gem install wkhtmltopdf sudo gem install bundler sudo gem install rails sudo gem install rake --version=0.9.2
Download the 2.6.2 version of Snorby and move it to your web root directory:
cd ~/snort_src/ wget https://github.com/Snorby/snorby/archive/v2.6.2.tar.gz -O snorby-2.6.2.tar.gz tar xzvf snorby-2.6.2.tar.gz sudo cp -r ./snorby-2.6.2/ /var/www/html/snorby/
Install all of the Snorby pre-requisites. Ignore warnings about running bundle as root. If you get connection errors when trying to download gems, just re-run the command until it succeeds.
cd /var/www/html/snorby sudo bundle install
Snorby uses database.yml to tell it how to connect to the MySQL server. We will copy the example file to the correct location and edit it with our MySQL root credentials (Snorby will need to create a database):
sudo cp /var/www/html/snorby/config/database.yml.example /var/www/html/snorby/config/database.yml sudo vi /var/www/html/snorby/config/database.yml
You need to change the password field in this database.yml file to reflect the MySQL root password you set when installing MySQL (MySqlROOTpassword if you are following this guide exactly). Note that we will change this later after Snorby has setup the database it needs to use a lower-priviledged MySQL account. The beginning of the file should look like this after editing:
# Snorby Database Configuration # # Please set your database password/user below # NOTE: Indentation is important. # snorby: &snorby adapter: mysql username: root password: "MySqlROOTpassword" # Example: password: "s3cr3tsauce" host: localhost ... and so on
Now we need to create the Snorby configuration file (copied from it’s example file), and update it to point to the correct version of wkhtmlpdf (we use sed to make this change):
sudo cp /var/www/html/snorby/config/snorby_config.yml.example /var/www/html/snorby/config/snorby_config.yml sudo sed -i s/"\/usr\/local\/bin\/wkhtmltopdf"/"\/usr\/bin\/wkhtmltopdf"/g /var/www/html/snorby/config/snorby_config.yml
Now we want to install Snorby. The below command will download the necessary gems and will create a new database called Snorby for use. This can take some time to complete. You can ignore errors about ”Jammit Warning: Asset compression disabled – Java unavailable.”.
cd /var/www/html/snorby sudo bundle exec rake snorby:setup
Now we want to edit the MySQL Snorby database to grant access to a lower privilidged user (we don’t want the Snorby application using the root password to interface with the database). Run the following commands to create a new MySQL user named snorby with password PASSWORD123. You will be prompted for your MySQL root password (MySqlROOTpassword) after the first command:
$ mysql -u root -p myslq> create user 'snorby'@'localhost' IDENTIFIED BY 'PASSWORD123'; myslq> grant all privileges on snorby.* to 'snorby'@'localhost' with grant option; myslq> flush privileges; myslq> exit
Now that we’ve created a new MySQL snorby user and password, edit Snorby’s database.yml to tell Snorby to use the new account rather than the root MySQL account:
sudo vi /var/www/html/snorby/config/database.yml
The file should now look like this (note the changes to lines 8 and 9):
# Snorby Database Configuration # # Please set your database password/user below # NOTE: Indentation is important. # snorby: &snorby adapter: mysql username: snorby password: "PASSWORD123" # Example: password: "s3cr3tsauce" host: localhost development: database: snorby <<: *snorby test: database: snorby <<: *snorby production: database: snorby <<: *snorby
Now we are ready to test Snorby. Run Snorby with:
cd /var/www/html/snorby/ sudo bundle exec rails server -e production
This will start Snorby listening on port 3000. Navigate to http://ip_of_snorby_server:3000 and you should see the logon screen. Don’t log in at this time as we are only testing that the software runs. Use ctrl-c at the command prompt to stop the Snorby server.
We will use Phusion Passenger, an application server module for Apache to launch Snorby. First install pre-requisites:
sudo apt-get install -y libcurl4-openssl-dev apache2-threaded-dev libaprutil1-dev libapr1-dev
Next, install the Passenger gem and the Apache module (we don’t install the Ubuntu repository version of Phusion Passenger because it doesn’t work well).
sudo gem install passenger sudo passenger-install-apache2-module
The Phusion Passenger install wizard will start. Un-check the Python language support (we only need Ruby support) using the arrows and space bar, then use enter to continue through the menu options. After compiling software, the wizard will finally tell you to copy some text to your Apache configuration file. We don’t want to copy the entire output to the Apache configuration file, because Apache now uses separate files for modules (one for the path to the .so file for the module, and one for configuration for the module). We do want the information that is printed, we will just use it slightly differently. Copy the five lines of text that are shown on the screen, as you’ll need them. Hit enter twice to exit the wizard.
My install showed the following 5 lines of text that are needed (yours may be different):
LoadModule passenger_module /var/lib/gems/1.9.1/gems/passenger-5.0.21/buildout/apache2/mod_passenger.so <IfModule mod_passenger.c> PassengerRoot /var/lib/gems/1.9.1/gems/passenger-5.0.21 PassengerDefaultRuby /usr/bin/ruby1.9.1 </IfModule>
The first line tells Apache the path to the shared object library to load the Phusion passenger module. We want to create a new file for this line. Create this file:
sudo vi /etc/apache2/mods-available/passenger.load
And paste the first line into that file. In my case, I pasted:
LoadModule passenger_module /var/lib/gems/1.9.1/gems/passenger-5.0.21/buildout/apache2/mod_passenger.so
The final 4 lines specify the configuration for Phusion Passenger. Create the configuration file as follows:
sudo vi /etc/apache2/mods-available/passenger.conf
And paste the two content lines in. You do not need the <ifmodule> tags In my case, I pasted:
PassengerRoot /var/lib/gems/1.9.1/gems/passenger-5.0.21 PassengerDefaultRuby /usr/bin/ruby1.9.1
Note: yes, the lines above say ruby1.9.1, and we did install ruby 1.9.3. Ubuntu 12 does some file system redirection that makes this happen, but it doesn’t cause any issues.
Next, enable the Passenger module:
sudo a2enmod passenger sudo service apache2 restart
and then verify that it loaded by running the following command (look for Passenger in the output):
apache2ctl -t -D DUMP_MODULES
Now we need to create an Apache website for Snorby:
sudo vi /etc/apache2/sites-available/snorby.conf
with the following content:
<virtualhost *:80> ServerAdmin webmaster@localhost ServerName snorby.sublimerobots.com DocumentRoot /var/www/html/snorby/public <directory "/var/www/html/snorby/public"> AllowOverride all Order deny,allow Allow from all Options -MultiViews </directory> </virtualhost>
Now enable the new site, disable the default site, and reload Apache to see the new configurations:
cd /etc/apache2/sites-available/ sudo a2ensite snorby.conf sudo service apache2 reload cd /etc/apache2/sites-enabled sudo a2dissite 000-default sudo service apache2 reload
Now we need to tell Barnyard2 to output events to the Snorby database that we created above.
sudo vi /etc/snort/barnyard2.conf
Append at the end off the file:
output database: log, mysql, user=snorby password=PASSWORD123 dbname=snorby host=localhost sensor_name=sensor1
We can disable the other output file that you created during the Barnyard2 testing by deleting the previous line (or putting a hash in front of it to disable it), so that it looks like the following:
# output database: log, mysql, user=snort password=MySqlSNORTpassword dbname=snort host=localhost)
Restart Barnyard2 to load the new configuration:
sudo service barnyard2 restart
Snorby needs one service running for database maintenance (a Snorby worker daemon). We will create an Upstart daemon for this task. First we need to create the startup script:
sudo vi /etc/init/snorby_worker.conf
with the following content:
description "Snorby Delayed Job" stop on runlevel [!2345] start on runlevel [2345] chdir /var/www/html/snorby script exec /usr/bin/ruby script/delayed_job start end script
Now make the script executable, and tell Upstart that the script exists, and then verify that it installed correctly:
user@snortserver:~$ sudo chmod +x /etc/init/snorby_worker.conf user@snortserver:~$ initctl list | grep snorby_worker snorby_worker stop/waiting user@snortserver:~$
Note that this daemon will often list as stop/waiting, and that is ok, because of how it works. You can check the worker job status use the web interface (look under Administration –> Worker and Job Queue). You may need to restart the server once at this stage because a differernt version of the worker service may be running from earlier testing. Verify that the worker process is running from the web interface after a reboot.
To log into the web interface: open a web browser and navigate to http://ip_of_snorby_server. You don’t need to enter the port number, as it is listening on port 80 now. The default login information is:
E-mail: snorby@snorby.org
Password: snorby
(current Snorby documentation lists the email as example.com, not snorby.org. That is incorrect for the 2.6.2 version of Snorby, where the username remains snorby@snorby.org)
If you are logged into the Snorby web interface, then congratulations, your system is fully setup. Continue on to the last part of this guide to see where to go from here: Conclusion.
UPDATE: Snort 2.9.9.x has been released. Please see the updated series of articles here or my quick install guide here.
I am leaving this older guide online for anyone who wants to install this older version of Snort on Ubuntu, but you really should be using the updated guide for the 2.9.9.x version of Snort, since support for older versions of Snort are set to expire, and the updated guide is kept more up to date and includes BASE instead of Snorby for a Web GUI.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Snorby is a web GUI for managing your Snort system. The Snort daemon created in the last section will write all alerts to a Unified2 file, and Barnyard2 will process those alerts into a MySQL database. Snorby will let you browse, search, and profile those alerts from the database in a easy to view way. Snorby is a ruby on rails application, which we will launch with Phusion Passenger on Apache server. An alternative to Snorby is BASE, which is a simpler (less web-2.0) interface that still has a lot of popularity. You can read my article on BASE here (note that that guide hasn’t been updated in a few months, so you should be able to find newer versions of some of the supporting software, like ADOdb).
The bad news is that neither Snorby or BASE are still actively developed. They will work just fine for a hobby or small business setup, but you may want to look at other alternatives if you have more stringent requirements, or need to be able to view more complex visualizations of your data. One option is sguil, and another popular one is Splunk Enterprise (a commercial product, but free for up to 500 MB of log data per day). Splunk has a great interface for Snort alert data. An example of this can be seen in this video from DerbyCon starting at the 43:40 minute mark (this video is also an excellent overview of OpenAppID).
First, let’s install the pre-requisites:
sudo apt-get install -y imagemagick apache2 libyaml-dev libxml2-dev libxslt-dev git ruby1.9.3
Snorby installs a number of Ruby gems. To speed up their installation, run the following two commands to prevent the install of documentation when gems are installed:
echo "gem: --no-rdoc --no-ri" > ~/.gemrc sudo sh -c "echo gem: --no-rdoc --no-ri > /etc/gemrc"
Install the gems required for management and installation:
# These gems will also install other required gems sudo gem install wkhtmltopdf sudo gem install bundler sudo gem install rails sudo gem install rake --version=0.9.2
Download the 2.6.2 version of Snorby and move it to your web root directory:
cd ~/snort_src/ wget https://github.com/Snorby/snorby/archive/v2.6.2.tar.gz -O snorby-2.6.2.tar.gz tar xzvf snorby-2.6.2.tar.gz sudo cp -r ./snorby-2.6.2/ /var/www/snorby/
Install all of the Snorby pre-requisites. Ignore warnings about running bundle as root. If you get connection errors when trying to download gems, just re-run the command until it succeeds.
cd /var/www/snorby sudo bundle install
Snorby uses database.yml to tell it how to connect to the MySQL server. We will copy the example file to the correct location and edit it with our MySQL root credentials (Snorby will need to create a database):
sudo cp /var/www/snorby/config/database.yml.example /var/www/snorby/config/database.yml sudo vi /var/www/snorby/config/database.yml
You need to change the password field in this database.yml file to reflect the MySQL root password you set when installing MySQL (MySqlROOTpassword if you are following this guide exactly). Note that we will change this later after Snorby has setup the database it needs to use a lower-priviledged MySQL account. The beginning of the file should look like this after editing:
# Snorby Database Configuration # # Please set your database password/user below # NOTE: Indentation is important. # snorby: &snorby adapter: mysql username: root password: "MySqlROOTpassword" # Example: password: "s3cr3tsauce" host: localhost ... and so on
Now we need to create the Snorby configuration file (copied from it’s example file), and update it to point to the correct version of wkhtmlpdf (we use sed to make this change):
sudo cp /var/www/snorby/config/snorby_config.yml.example /var/www/snorby/config/snorby_config.yml sudo sed -i s/"\/usr\/local\/bin\/wkhtmltopdf"/"\/usr\/bin\/wkhtmltopdf"/g /var/www/snorby/config/snorby_config.yml
Now we want to install Snorby. The below command will download the necessary gems and will create a new database called Snorby for use. This can take some time to complete. You can ignore errors about ”Jammit Warning: Asset compression disabled – Java unavailable.”.
cd /var/www/snorby sudo bundle exec rake snorby:setup
Now we want to edit the MySQL Snorby database to grant access to a lower privilidged user (we don’t want the Snorby application using the root password to interface with the database). Run the following commands to create a new MySQL user named snorby with password PASSWORD123. You will be prompted for your MySQL root password (MySqlROOTpassword) after the first command:
$ mysql -u root -p myslq> create user 'snorby'@'localhost' IDENTIFIED BY 'PASSWORD123'; myslq> grant all privileges on snorby.* to 'snorby'@'localhost' with grant option; myslq> flush privileges; myslq> exit
Now that we’ve created a new MySQL snorby user and password, edit Snorby’s database.yml to tell Snorby to use the new account rather than the root MySQL account:
sudo vi /var/www/snorby/config/database.yml
The file should now look like this (note the changes to lines 8 and 9):
# Snorby Database Configuration # # Please set your database password/user below # NOTE: Indentation is important. # snorby: &snorby adapter: mysql username: snorby password: "PASSWORD123" # Example: password: "s3cr3tsauce" host: localhost development: database: snorby <<: *snorby test: database: snorby <<: *snorby production: database: snorby <<: *snorby
Now we are ready to test Snorby. Run Snorby with:
cd /var/www/snorby/ sudo bundle exec rails server -e production
This will start Snorby listening on port 3000. Navigate to http://ip_of_snorby_server:3000 and you should see the logon screen. Don’t log in at this time as we are only testing that the software runs. Use ctrl-c at the command prompt to stop the Snorby server.
We will use Phusion Passenger, an application server module for Apache to launch Snorby. First install pre-requisites:
sudo apt-get install -y libcurl4-openssl-dev apache2-threaded-dev libaprutil1-dev libapr1-dev
Next, install the Passenger gem and the Apache module (we don’t install the Ubuntu repository version of Phusion Passenger because it doesn’t work well).
sudo gem install passenger sudo passenger-install-apache2-module
The Phusion Passenger install wizard will start. Un-check the Python language support (we only need Ruby support) using the arrows and space bar, then use enter to continue through the menu options. After compiling software, the wizard will finally tell you to copy some text to your Apache configuration file. We don’t want to copy the entire output to the Apache configuration file, because Apache now uses separate files for modules (one for the path to the .so file for the module, and one for configuration for the module). We do want the information that is printed, we will just use it slightly differently. Copy the five lines of text that are shown on the screen, as you’ll need them. Hit enter twice to exit the wizard.
My install showed the following 5 lines of text that are needed (yours may be different):
LoadModule passenger_module /var/lib/gems/1.9.1/gems/passenger-5.0.21/buildout/apache2/mod_passenger.so <IfModule mod_passenger.c> PassengerRoot /var/lib/gems/1.9.1/gems/passenger-5.0.21 PassengerDefaultRuby /usr/bin/ruby1.9.1 </IfModule>
The first line tells Apache the path to the shared object library to load the Phusion passenger module. We want to create a new file for this line. Create this file:
sudo vi /etc/apache2/mods-available/passenger.load
And paste the first line into that file. In my case, I pasted:
LoadModule passenger_module /var/lib/gems/1.9.1/gems/passenger-5.0.21/buildout/apache2/mod_passenger.so
The final 4 lines specify the configuration for Phusion Passenger. Create the configuration file as follows:
sudo vi /etc/apache2/mods-available/passenger.conf
And paste the two content lines in. You do not need the <ifmodule> tags In my case, I pasted:
PassengerRoot /var/lib/gems/1.9.1/gems/passenger-5.0.21 PassengerDefaultRuby /usr/bin/ruby1.9.1
Note: yes, the lines above say ruby1.9.1, and we did install ruby 1.9.3. Ubuntu 12 does some file system redirection that makes this happen, but it doesn’t cause any issues.
Next, enable the Passenger module:
sudo a2enmod passenger sudo service apache2 restart
and then verify that it loaded by running the following command (look for Passenger in the output):
apache2ctl -t -D DUMP_MODULES
Now we need to create an Apache website for Snorby:
sudo vi /etc/apache2/sites-available/snorby.conf
with the following content:
<virtualhost *:80> ServerAdmin webmaster@localhost ServerName snorby.sublimerobots.com DocumentRoot /var/www/snorby/public <directory "/var/www/snorby/public"> AllowOverride all Order deny,allow Allow from all Options -MultiViews </directory> </virtualhost>
Now enable the new site, disable the default site, and reload Apache to see the new configurations:
cd /etc/apache2/sites-available/ sudo a2ensite snorby.conf sudo service apache2 reload cd /etc/apache2/sites-enabled sudo a2dissite 000-default sudo service apache2 reload
Now we need to tell Barnyard2 to output events to the Snorby database that we created above.
sudo vi /etc/snort/barnyard2.conf
Append at the end off the file:
output database: log, mysql, user=snorby password=PASSWORD123 dbname=snorby host=localhost sensor_name=sensor1
We can disable the other output file that you created during the Barnyard2 testing by deleting the previous line (or putting a hash in front of it to disable it), so that it looks like the following:
# output database: log, mysql, user=snort password=MySqlSNORTpassword dbname=snort host=localhost)
Restart Barnyard2 to load the new configuration:
sudo service barnyard2 restart
Snorby needs one service running for database maintenance (a Snorby worker daemon). We will create an Upstart daemon for this task. First we need to create the startup script:
sudo vi /etc/init/snorby_worker.conf
with the following content:
description "Snorby Delayed Job" stop on runlevel [!2345] start on runlevel [2345] chdir /var/www/snorby script exec /usr/bin/ruby script/delayed_job start end script
Now make the script executable, and tell Upstart that the script exists, and then verify that it installed correctly:
user@snortserver:~$ sudo chmod +x /etc/init/snorby_worker.conf user@snortserver:~$ initctl list | grep snorby_worker snorby_worker stop/waiting user@snortserver:~$
Note that this daemon will often list as stop/waiting, and that is ok, because of how it works. You can check the worker job status use the web interface (look under Administration –> Worker and Job Queue).
To log into the web interface: open a web browser and navigate to http://ip_of_snorby_server. You don’t need to enter the port number, as it is listening on port 80 now. The default login information is:
E-mail: snorby@snorby.org
Password: snorby
(current Snorby documentation lists the email as example.com, not snorby.org. That is incorrect for the 2.6.2 version of Snorby, where the username remains snorby@snorby.org)
If you are logged into the Snorby web interface, then congratulations, your system is fully setup. Continue on to the last part of this guide to see where to go from here: Conclusion.
UPDATE: Snort 2.9.9.x has been released. Please see the updated series of articles here or my quick install guide here.
I am leaving this older guide online for anyone who wants to install this older version of Snort on Ubuntu, but you really should be using the updated guide for the 2.9.9.x version of Snort, since support for older versions of Snort are set to expire, and the updated guide is kept more up to date and includes BASE instead of Snorby for a Web GUI.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is the second in a set of articles will guide you through the steps of installing and configuring Snort as a Network Intrusion Detection System (NIDS). In the previous article we installed the Snort binary and verified that it correctly executed. In this section, we will configure Snort to run as a NIDS by creating the files and folders that Snort expects when running as a NIDS, and we will learn about the Snort configuration file: snort.conf.
First off, for security reasons we want Snort to run as an unprivileged user. We create a snort user and group for this purpose:
sudo groupadd snort sudo useradd snort -r -s /sbin/nologin -c SNORT_IDS -g snort
Next, we need to create a number of files and folders that Snort expects when running in NIDS mode. We will then change the ownership of those files to our new snort user. Snort stores configuration files in /etc/snort, rules in /etc/snort/rules, /usr/local/lib/snort_dynamicrules, and stores its logs in /var/log/snort:
# Create the Snort directories: sudo mkdir /etc/snort sudo mkdir /etc/snort/rules sudo mkdir /etc/snort/rules/iplists sudo mkdir /etc/snort/preproc_rules sudo mkdir /usr/local/lib/snort_dynamicrules sudo mkdir /etc/snort/so_rules # Create some files that stores rules and ip lists sudo touch /etc/snort/rules/iplists/black_list.rules sudo touch /etc/snort/rules/iplists/white_list.rules sudo touch /etc/snort/rules/local.rules sudo touch /etc/snort/sid-msg.map # Create our logging directories: sudo mkdir /var/log/snort sudo mkdir /var/log/snort/archived_logs # Adjust permissions: sudo chmod -R 5775 /etc/snort sudo chmod -R 5775 /var/log/snort sudo chmod -R 5775 /var/log/snort/archived_logs sudo chmod -R 5775 /etc/snort/so_rules sudo chmod -R 5775 /usr/local/lib/snort_dynamicrules # Change Ownership on folders: sudo chown -R snort:snort /etc/snort sudo chown -R snort:snort /var/log/snort sudo chown -R snort:snort /usr/local/lib/snort_dynamicrules
We now need to move the following files from the extracted Snort tarball to the snort configuration folder:
Run the commands below to move the files listed above to the /etc/snort folder:
cd ~/snort_src/snort-2.9.8.0/etc/ sudo cp *.conf* /etc/snort sudo cp *.map /etc/snort sudo cp *.dtd /etc/snort cd ~/snort_src/snort-2.9.8.0/src/dynamic-preprocessors/build/usr/local/lib/snort_dynamicpreprocessor/ sudo cp * /usr/local/lib/snort_dynamicpreprocessor/
The Snort configuration folder and file structure should now look like the following:
user@snortserver:~$ tree /etc/snort /etc/snort ├── attribute_table.dtd ├── classification.config ├── file_magic.conf ├── gen-msg.map ├── preproc_rules ├── reference.config ├── rules │.. ├── local.rules │.. ├── iplists │ .. ├── black_list.rules │ .. ├── white_list.rules ├── snort.conf ├── so_rules ├── threshold.conf └── unicode.map
The Snort configuration file is stored at /etc/snort/snort.conf, and contains all the settings that Snort will use when it is run in NIDS mode. This is a large file (well over 500 lines), and contains a number of options for the configuration of Snort. We are interested in only a few settings at this time.
First, we need to comment out the lines that causes Snort to import the default set of rule files. We do this because we will be using PulledPork to manage our rulesets, which saves all the rules into a single file. The easy way to comment out all these lines is to use sed to append the “#” (hash) character to those lines. This is accomplished by running the following command:
sudo sed -i 's/include \$RULE\_PATH/#include \$RULE\_PATH/' /etc/snort/snort.conf
The result of this command is that lines 547 to 651 in snort.conf will now be commented out, which will prevent Snort from loading those rule files on start-up. These rule files do not exist, and will cause Snort to generate an error if it tries to load a file that doesn’t exist. If you were to manually download the rule files from the snort website and extract them to the /etc/snort/rules folder, then you would want those rules to be un-commented out. We will use PulledPork (configured later) to manage all our rules and save them into a single file, which is why we need all those rule files to be commented out.
Next, we need to manually edit a few lines in the snort.conf file. Use vi (or your favorite editor) to edit /etc/snort/snort.conf:
sudo vi /etc/snort/snort.conf
First, we need to let Snort know the network range of your home network (the assets you are trying to protect) and all other external networks. We do this by editing lines 45 and 48 of snort.conf to tell it the IP ranges of these two networks. In the example below, our home network is 10.0.0.0 with a 24 bit subnet mask (255.255.255.0), and our external networks are all other networks.
ipvar HOME_NET 10.0.0.0/24 # (line 45) make this match your internal (friendly) network
Note: it is not recommended to set EXTERNAL_NET to !$HOME NET as recommended in some guides, since it can cause Snort to miss alerts.
Next we need to tell Snort about the locations of all the folders we created earlier. These settings are also part of the snort.conf file. I have included the line numbers after the hash so you can more easily find the setting (do not write the line number, just change the path to match what is below):
var RULE_PATH /etc/snort/rules # line 104 var SO_RULE_PATH /etc/snort/so_rules # line 105 var PREPROC_RULE_PATH /etc/snort/preproc_rules # line 106 var WHITE_LIST_PATH /etc/snort/rules/iplists # line 113 var BLACK_LIST_PATH /etc/snort/rules/iplists # line 114
Finally, we want to enable one included rule file: /etc/snort/rules/local.rules. We will use this file to store our own rules, including one rule that we will write in the next article in this series that will allow us to easily check that Snort is correctly generating alerts. Un-comment the following line (line 545) by deleting the hash from the beginning of the line:
include $RULE_PATH/local.rules
Snort has the ability to validate the configuration file, and you should do this whenever you make modifications to snort.conf. Run the following command to have Snort test the configuration file:
sudo snort -T -c /etc/snort/snort.conf -i eth0
The -T tells snort to test, and -c tells snort the path to the configuration file, and you are required to specify an interface you want to listen to with -i (this is a new requirement for the 2.9.8.x version of snort). You should see some output, with the following lines at the end:
... Snort successfully validated the configuration! Snort exiting
Congratulations, if you have output similar to the above then you have successfully Configured Snort to run as a NIDS. Continue to the next section: Writing and Testing a Single Rule With Snort.
In this article, we are going to look at Snort’s Reputation Preprocessor. We will look at how this preprocessor is used to use IP blacklists and IP whitelists (known together as IP lists) to either block, alert, or allow traffic based on the sender’s and/or recipient’s IP address. I will show you how to configure, test, and troubleshoot the reputation preprocessor and associated IP lists. Finally we will look at how PulledPork can be configured to download blacklists automatically.
Before the reputation preprocessor was developed, if you wanted to block or alert on traffic to or from a specific IP address or range, you had to create a rule for that IP address or range of IP addresses. This works well for a very small set of addresses that do not change often. Unfortunately, in today’s environment IP addresses for malicious hosts change rapidly, and there are a very large number of malicious addresses. The administrative overhead of creating and maintaining rules specifically for these addresses became difficult, as well as the problem of the additional processor load on the Snort detection engine with the addition of so many extra rules. The current Talos blacklist has over 40,000 entries, so you can imagine that the effort of using regular Snort rules to block that many IP addresses was difficult, to say the least.
The solution to these difficulties was the reputation preprocessor, first included in the Snort 2.9.1.x release of Snort.
The reputation preprocessor was created to allow Snort to use a file full of just IP addresses to identify bad hosts and trusted hosts. Malicious IP addresses are stored in blacklists, and trusted IP addresses are stored in whitelists. The reputation preprocessor loads these lists when Snort starts, and compares all traffic against those lists. Snort checks both the sending and receiving IP address in each packet against every entry in the IP lists, and if the IP addresses in the packet matches an IP address on the blacklist, whitelist, or both lists, Snort can take a few different actions: Snort can either generate an alert, block the packet, allow the packet without any other processing (skipping all other rules), or let the packet continue through the rest of the regular rule checks. The action that Snort takes depends on how you have the reputation preprocessor configured, and if Snort is running in IDS or IPS mode (Snort can only drop packets when running in IPS mode, for obvious reasons).
The reputation preprocessor is the first preprocessor that a packet encounters in Snort (after being assembled by the decoder). The reason for this is that since the reputation preprocessor can mark trusted packets to skip the rest of the preprocessors and rule engine, or can drop the packet, it can help to reduce the load on the Snort system.
You can manually create whitelists and blacklists, although you are probably better off using PulledPork to automatically download blacklist files. The good news is that if you are using PulledPork and you’ve got the reputation preprocessor configured correctly, all this just works for you. If you want to change the way things work, are doing something special, or just want to understand Snort better, then the rest this guide is for you.
Assuming your reputation preprocessor is configured correctly, and you have entries in your whitelist and blacklist files: the reputation preprocessor is the first processor that a packet encounters in Snort after being assembled by the decoder. The reputation preprocessor compares the source and destination IP addresses in the packet against the IP addresses in both the whitelist and blacklist files. If one of the IP addresses (sender or recipient) for the packet is on the blacklist, then an alert is generated (with GID:136, and SID:1) and no further processing is done on the packet (it skips all other processors and the rule engine). If you are running in NIDS mode, only an alert is generated. If you are running inline in IPS mode, then the packet is dropped. If one of the IP addresses is on a whitelist: the packet can either bypass all other preprocessors and the rule engine and continue on, or it can be “unblacked”. When a packet is unblocked, it is treated like a regular packet, being processed by the other preprocessors and rules, even if the address is on the blacklist.
If your Snort server is running as a NIDS (network intrusion detection system) then alerts are generated (we are detecting) for packets that match one of the IP lists. If you are running Snort as a NIPS (network intrusion prevention system), then traffic can be dropped instead of generating alerts when the packet IP address matches an IP in the blacklist . If one IP address is on the whitelist, and the other address is on the blacklist, the action taken will depend on your configuration, namely the priority and white reputation preprocessor options described below.
The reputation preprocessor is configured in your snort.conf. Many standard Snort installations place this file at /etc/snort/snort.conf. Open this snort configuration file and find the section for the reputation preprocessor. This should be around line number 506 if you haven’t changed your snort.conf much. If the preprocessor is disabled with the hash symbol (#) at the beginning of each line for the preprocessor, you can enable it by removing the hash symbol from the beginning of each line. The preprocessor configuration should look similar to the following when enabled:
# Reputation preprocessor. For more information see README.reputation preprocessor reputation: \ memcap 500, \ priority whitelist, \ nested_ip inner, \ whitelist $WHITE_LIST_PATH/white_list.rules, \ blacklist $BLACK_LIST_PATH/black_list.rules
There are a few other lines in your snort.conf that relate to IP lists as well. The following two lines tell Snort where the folder is that stores the whitelists and blacklists:
var WHITE_LIST_PATH /etc/snort/rules/iplists # line 113 in snort.conf var BLACK_LIST_PATH /etc/snort/rules/iplists # line 114 in snort.conf
note that you could just use an absolute path for WHITE_LIST_PATH and BLACK_LIST_PATH rater than using the $BLACK_LIST_PATH/filename as in the above two examples.
We also need a folder to hold your IP lists, and the empty whitelist and blacklist. These three items are what we told Snort to use in the above two sections of the snort.conf (create these if they don’t exist, based on your preprocessor configuration):
# these commands will create your whitelist and blacklist files as configured in the above example sudo mkdir /etc/snort/rules/iplists sudo touch /etc/snort/rules/iplists/black_list.rules sudo touch /etc/snort/rules/iplists/white_list.rules
Since you’ve edited your snort.conf, it’s always a good idea to test that you didn’t create any errors. A simple test (change for your system as needed) and make sure no issues are reported:
sudo snort -T -c /etc/snort/snort.conf -i eth0
If you want to build your own whitelists and blacklists, this is easy. Snort can easily load multiple whitelists and blacklists (see the section below for instructions). The list should be a text document with either plain IP addresses (specifying a single host), or IP addresses in CIDR format, with one entry per line. You can have full-line and inline comments by using the hash (#) symbol. An example of all these options is below:
# This is a full-line comment # This list could be a whitelist or a blacklist, it only depends on what you tell Snort to treat it as # Add these single hosts to this list: 10.0.0.120 10.0.0.222 # This is an inline comment. # Add these entire subnets (in CIDR format) to the list: 10.2.0.0/24 224.0.0.0/4 # add the entire multicast subnet to this list
If you want the reputation preprocessor to recognize (not ignore) private network addresses (the ones on your home or internal network) which all fall in the local ranges:
then add the scan_local option to the reputation preprocessor, as show below in line 6:
# Reputation preprocessor. For more information see README.reputation preprocessor reputation: \ memcap 500, \ priority whitelist, \ nested_ip inner, \ scan_local, \ whitelist $WHITE_LIST_PATH/white_list.rules, \ blacklist $BLACK_LIST_PATH/black_list.rules
This option allows you to test the reputation preprocessor with private addresses (alert on traffic from the 10.0.0.0/24 subnet for example). Without this option, all IP addresses in your IP lists from a private address will be not be compared against the IP lists.
The two reputation preprocessor configuration options that determine how IP lists affect the processing of packets are priority and white.
priority: When a packet has one IP on a blacklist and the other IP on a whitelist (sender IP address and receiver IP address), this option determines which is more important. If this is set to blacklist, then the packet will generate an alert. If this is set to whitelist, then the process will be allowed to pass. An example of this setting (truncated for simplicity):
preprocessor reputation: \ priority whitelist, \ ...
white: this option can be set to either unblack or trust. When set to unblack, if the packet also has an address that is in the IP blacklist (say the source IP address is in the whitelist and the destination ip address of that same packet is in the blacklist), then the packet will continue to process through the other preprocessors as if it was not on the blacklist. Note that for the packet to continue to be processed, the priority must be set to whitelist. When white is set to trust, then the packet is implicitly trusted and bypasses all further processing. An example of this:
preprocessor reputation: \ white unblack, \ ...
If you are not using PulledPork to manage your rulesets, and have manually configured your whitelists and / or blacklists, you need to tell Snort to generate an alert when it sees packets that match these IP lists.
You need a local.rules file loaded by Snort with the following rules (if you need help setting this up, please see my article here):
alert ( msg: "REPUTATION_EVENT_BLACKLIST"; sid: 1; gid: 136; rev: 1; metadata: rule-type preproc ; classtype:bad-unknown; ) alert ( msg: "REPUTATION_EVENT_WHITELIST"; sid: 2; gid: 136; rev: 1; metadata: rule-type preproc ; classtype:bad-unknown; )
NOTE: if you are using PulledPork to manage rules, you don’t need the above lines, it will add these rules automatically.
Rules with GID 136 are rules triggered by the reputation preprocessor. There are 3 SID’s for that processor:
We don’t want to create a rule with a SID of 3 because that would be a lot of alerts (essentially all packets).
There is an easy way to test the reputation processor works. First, make sure your reputation preprocessor is properly configured, and you have the two rules listed above in your local.rules file (and make sure that Snort is loading your local.rules).
Next, add the IP address of a second host on your network (other than your snort host) to your black_list.rules file. This IP address will be the address that Snort generates alerts on, due to the IP address being in the blacklist file.
Start Snort with the following command (change for your specific system settings). This will generate alerts to the console:
sudo /usr/local/bin/snort -A console -q -c /etc/snort/snort.conf -i eth0
If you now ping your Snort server from the system that is in your blacklist, you should see alerts display on the console. Use Ctrl-C to stop Snort from running. In the example below, the first alert is from me ssh-ing into the Snort server from the blacklisted computer. Next I pinged the Snort server 8 times, then used wget to try to pull a webpage from the Snort server:
12/09-20:25:10.423907 [**] [136:1:1] (spp_reputation) packets blacklisted [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 10.0.0.72:51312 -> 10.0.0.101:22 12/09-20:25:15.355331 [**] [136:1:1] (spp_reputation) packets blacklisted [**] [Classification: Potentially Bad Traffic] [Priority: 2] {ICMP} 10.0.0.101 -> 10.0.0.105 12/09-20:25:15.355375 [**] [136:1:1] (spp_reputation) packets blacklisted [**] [Classification: Potentially Bad Traffic] [Priority: 2] {ICMP} 10.0.0.105 -> 10.0.0.101 12/09-20:25:16.355231 [**] [136:1:1] (spp_reputation) packets blacklisted [**] [Classification: Potentially Bad Traffic] [Priority: 2] {ICMP} 10.0.0.101 -> 10.0.0.105 12/09-20:25:16.355270 [**] [136:1:1] (spp_reputation) packets blacklisted [**] [Classification: Potentially Bad Traffic] [Priority: 2] {ICMP} 10.0.0.105 -> 10.0.0.101 12/09-20:25:17.355272 [**] [136:1:1] (spp_reputation) packets blacklisted [**] [Classification: Potentially Bad Traffic] [Priority: 2] {ICMP} 10.0.0.101 -> 10.0.0.105 12/09-20:25:17.355310 [**] [136:1:1] (spp_reputation) packets blacklisted [**] [Classification: Potentially Bad Traffic] [Priority: 2] {ICMP} 10.0.0.105 -> 10.0.0.101 12/09-20:25:18.355293 [**] [136:1:1] (spp_reputation) packets blacklisted [**] [Classification: Potentially Bad Traffic] [Priority: 2] {ICMP} 10.0.0.101 -> 10.0.0.105 12/09-20:25:18.355319 [**] [136:1:1] (spp_reputation) packets blacklisted [**] [Classification: Potentially Bad Traffic] [Priority: 2] {ICMP} 10.0.0.105 -> 10.0.0.101 12/09-20:25:26.194898 [**] [136:1:1] (spp_reputation) packets blacklisted [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 10.0.0.101:52671 -> 10.0.0.105:80 ^C*** Caught Int-Signal
If you are wondering how I’m able to remote into the server from a blacklisted host, remember that we have configured Snort as an IDS (intrusion detection system), it only detects and alerts for malicious traffic. We have not configured Snort as an IPS (intrusion prevention system). More information on running Snort as an IPS here.
If you don’t see any alerts like above, run the below command to test your snort.conf,
sudo snort -T -c /etc/snort/snort.conf -i eth0
If Snort verifies the configuration file successfully (indicated in the final few lines of output), then scroll up through the output up to see if any IP addresses show in the reputation portion of the output (see line 6 below for our one IP address loaded from the blacklist file):
Reputation config: WARNING: /etc/snort/snort.conf(512) => Keyword priority for whitelist is not applied when white action is unblack. Processing whitelist file /etc/snort/rules/iplists/default.whitelist Reputation entries loaded: 0, invalid: 0, re-defined: 0 (from file /etc/snort/rules/iplists/default.whitelist) Processing blacklist file /etc/snort/rules/iplists/default.blacklist Reputation entries loaded: 1, invalid: 0, re-defined: 0 (from file /etc/snort/rules/iplists/default.blacklist) Reputation total memory usage: 329636 bytes Reputation total entries loaded: 1, invalid: 0, re-defined: 0 Memcap: 500 (Default) M bytes Scan local network: DISABLED (Default) Reputation priority: whitelist(Default) Nested IP: inner (Default) White action: unblack (Default) Shared memory is Not supported.
You will also want to verify that our two rules (from local.rules) have loaded in the rules section of the output (note that they are recognized as preprocessor rules):
+++++++++++++++++++++++++++++++++++++++++++++++++++ Initializing rule chains... 2 Snort rules read 0 detection rules 0 decoder rules 2 preprocessor rules 2 Option Chains linked into 1 Chain Headers 0 Dynamic rules +++++++++++++++++++++++++++++++++++++++++++++++++++ +-------------------[Rule Port Counts]--------------------------------------- | tcp udp icmp ip | src 0 0 0 0 | dst 0 0 0 0 | any 2 0 0 0 | nc 2 0 0 0 | s+d 0 0 0 0 +----------------------------------------------------------------------------
if both of those are correct, start looking at your IP addresses to verify that you have everything correct. If you are using private IP addresses (like 10.x.x.x) then remember that you need to enable scan_local in the reputation preprocessor.
Packets are often encapsulated in other packets, such as GRE or IP in IP tunnels. If Snort can see the IP header information of the encapsulated (internal) packet, you can choose to compare the inner packet, outer packet, or both inner and outer IP headers against your IP lists, by setting the nested_ip option to one of the following: inner, outer, or both, which tells the reputation preprocessor to check the inner IP address, the outer IP address, or to check both IP addresses (both inner and outer). One example is below:
preprocessor reputation: \ nested_ip inner, \ ...
PulledPork can automatically download blacklists (but not whitelists), and is configured to do so by default. When configuring pulledpork.conf (usually located in /etc/snort/), you will need to have the following lines configured correctly.
First we need to tell PulledPork which IP blacklist to download. By default we download the Talos blacklist, which is found at line 24 of pulledpork.conf. No changes are required to this line, since it’s enabled by default:
# pulledpork.conf - Line 24 rule_url=http://talosintel.com/feeds/ip-filter.blf|IPBLACKLIST|open
Line 141 in PulledPork.conf points to local file where you will save the blacklist that you download. This will be the same file you configured in the reputation preprocessor with the directive: BLACK_LIST_PATH in your snort.conf. This is the where PulledPork will write the blacklists to:
# pulledpork.conf - Line 141 black_list=/etc/snort/rules/iplists/black_list.rules
The other configuration item in PulledPork.conf that is related to blacklists is line 150. This is used to have Snort reload the IP lists without a reboot (although that requires a lot more configuration, and re-compiling snort with -enable-shared-rep and –enable-control-socket, which isn’t covered here). You just need to make sure this folder path points to your iplists folder so there are no errors, although we won’t be using this feature:
# pulledpork.conf - Line 150 IPRVersion=/etc/snort/rules/iplists
after running PulledPork, you should see the black_list.rules file be populated with a number of IP addresses (over 40,000 at this time from the Talos blacklist).
You can have the reputation preprocessor load multiple whitelists and blacklists. This is good if you have a personal blacklist that you don’t want overwritten by PulledPork. An example or the reputation preprocessor configured with two whitelists and two blacklists:
preprocessor reputation: \ memcap 500, \ priority whitelist, \ nested_ip inner, \ whitelist $WHITE_LIST_PATH/white_list.rules, \ whitelist etc/snort/rules/iplists/some_whitelist.rules, \ blacklist /etc/snort/rules/iplists/some_blacklist.rules, \ blacklist $BLACK_LIST_PATH/black_list.rules
Snort’s guide on the reputation preprocessor is here. This explains every option for the preprocessor in detail.
README.reputation: the Snort overview of the reputation preprocessor.
I hope this has been a good overview of the reputation preprocessor in Snort. I wrote this article because I found most of the information on the web to be scattered, incomplete, and sometimes contradictory (as things tend to often be on the internet). I am hoping this article helps to explain the reputation preprocessor at a high-enough level as to make you wiser, as well as deeply enough that you can bend it to your will. If you have any questions or recommendations, please contact me. I can’t always answer questions right away, but I will do my best to get back to you. I welcome all recommendations and corrections.
UPDATE: Snort 2.9.9.x has been released. Please see the updated series of articles here or my quick install guide here.
I am leaving this older guide online for anyone who wants to install this older version of Snort on Ubuntu, but you really should be using the updated guide for the 2.9.9.x version of Snort, since support for older versions of Snort are set to expire, and the updated guide is kept more up to date and includes BASE instead of Snorby for a Web GUI.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the previous articles in this series, we have created a complete Snort NIDS with a web interface and rulesets that automatically update. In this article, we will finalize the configuration of our Snort service by creating systemD scripts for the Snort and Barnyard2 daemons. If you are running Ubuntu 12 or 14, you should go see my Upstart article instead of this article.
Ubuntu 15 has moved to systemD for services / daemons. For more information about creating and managing systemD servcies, please see this excellent article.
To create the Snort systemD service, use an editor to create a service file:
sudo vi /lib/systemd/system/snort.service
with the following content (change eth0 if different on your system):
[Unit] Description=Snort NIDS Daemon After=syslog.target network.target [Service] Type=simple ExecStart=/usr/local/bin/snort -q -u snort -g snort -c /etc/snort/snort.conf -i eth0 [Install] WantedBy=multi-user.target
Now we tell systemD that the service should be started at boot:
sudo systemctl enable snort
And start the Snort service:
sudo systemctl start snort
Verify the service is running
systemctl status snort
Next, create the Barnyard2 systemd service. We will add two flags here: -D to run as a daemon, and -a /var/log/snort/archived logs, this will move logs that Barnyard2 has processed to the /var/log/snort/archived/ folder. Use an editor to create a service file:
sudo vi /lib/systemd/system/barnyard2.service
With the following content:
[Unit] Description=Barnyard2 Daemon After=syslog.target network.target [Service] Type=simple ExecStart=/usr/local/bin/barnyard2 -c /etc/snort/barnyard2.conf -d /var/log/snort -f snort.u2 -q -w /var/log/snort/barnyard2.waldo -g snort -u snort -D -a /var/log/snort/archived_logs [Install] WantedBy=multi-user.target
Now we tell systemD that the service should be started at boot:
sudo systemctl enable barnyard2
And start the barnyard2 service:
sudo systemctl start barnyard2
Verify the service is running
systemctl status barnyard2
Reboot the computer and check that both services are started
user@snortserver:~$ service snort status snort start/running, process 1116 user@snortserver:~$ service barnyard2 status barnyard2 start/running, process 1109 user@snortserver:~$
If both services are running, you are ready to move to the next section, where you will install Snorby, a web-based GUI to view and profile alert data. The instructions are broken up into three different versions, based on the version of Ubuntu you are running.
Choose one of the following:
Ubuntu 12: Installing Snorby on Ubuntu 12
Ubuntu 14: Installing Snorby on Ubuntu 14
Ubuntu 15: Installing Snorby on Ubuntu 15
UPDATE: Snort 2.9.9.x has been released. Please see the updated series of articles here or my quick install guide here.
I am leaving this older guide online for anyone who wants to install this older version of Snort on Ubuntu, but you really should be using the updated guide for the 2.9.9.x version of Snort, since support for older versions of Snort are set to expire, and the updated guide is kept more up to date and includes BASE instead of Snorby for a Web GUI.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the previous articles in this series, we have created a complete Snort NIDS with a web interface and rulesets that automatically update. In this article, we will finalize the configuration of our Snort service by creating Upstart scripts for the Snort and Barnyard2 daemons. If you are running Ubuntu 15, you should go see my systemD article instead of this article.
First create the Snort Upstart script:
sudo vi /etc/init/snort.conf
We will insert the below content into this Upstart script. Note that we are using the same flags that we used in earlier articles, so if Snort ran correctly for you earlier, then you shouldn’t need to change any of these flags:
description "Snort NIDS service" stop on runlevel [!2345] start on runlevel [2345] script exec /usr/sbin/snort -q -u snort -g snort -c /etc/snort/snort.conf -i eth0 -D end script
Now make the script executable, and tell Upstart that the script exists:
sudo chmod +x /etc/init/snort.conf initctl list | grep snort snort stop/waiting
do the same for our Barnyard2 script:
sudo vi /etc/init/barnyard2.conf
with the following content:
description "barnyard2 service" stop on runlevel [!2345] start on runlevel [2345] script exec /usr/local/bin/barnyard2 -c /etc/snort/barnyard2.conf -d /var/log/snort -f snort.u2 -w /var/log/snort/barnyard2.waldo -g snort -u snort -D -a /var/log/snort/archived_logs end script
Note that we have added a new flag here that we didn’t use before: -a /var/log/snort/archived_logs, this will move logs that Barnyard2 has processed to the /var/log/snort/archived_logs/ folder.
Now make the script executable, and tell Upstart that the script exists:
sudo chmod +x /etc/init/barnyard2.conf initctl list | grep barnyard barnyard2 stop/waiting
Reboot the computer and check that both services are started:
user@snortserver:~$ service snort status snort start/running, process 1116 user@snortserver:~$ service barnyard2 status barnyard2 start/running, process 1109 user@snortserver:~$
If both services are running, you are ready to move to the next section, where you will install Snorby, a web-based GUI to view and profile alert data. The instructions are broken up into three different versions, based on the version of Ubuntu you are running.
Choose one of the following:
Ubuntu 12: Installing Snorby on Ubuntu 12
Ubuntu 14: Installing Snorby on Ubuntu 14
Ubuntu 15: Installing Snorby on Ubuntu 15
UPDATE: Snort 2.9.9.x has been released. Please see the updated series of articles here or my quick install guide here.
I am leaving this older guide online for anyone who wants to install this older version of Snort on Ubuntu, but you really should be using the updated guide for the 2.9.9.x version of Snort, since support for older versions of Snort are set to expire, and the updated guide is kept more up to date and includes BASE instead of Snorby for a Web GUI.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the previous two sections of this article, we installed Snort and configured it to work as a NIDS with Barnyard2 processing packets that generated alerts based on a rule. In this article, we are going to install a Perl script called PulledPork, which will automatically download the latest rulesets from the Snort website.
To download the main free ruleset from Snort, you need an oinkcode. Register on the Snort website and save your oinkcode before continuing, as the oinkcode is required for the most popular free ruleset.
Install the PulledPork pre-requisites:
sudo apt-get install -y libcrypt-ssleay-perl liblwp-useragent-determined-perl
Note on PulledPork Version: The command below installs the 0.7.2 version of PulledPork as it was on November 12, 2015 (fixing issue #194). There are issues with the base 0.7.2 version of PulledPork that are fixed with later patches, but a version release (0.7.3) hasn’t been created that includes those patches yet. I don’t want to use the 0.7.2 version of PulledPork because of the issues, and I don’t want to install the current Master version of PulledPork because it may change after the release of this guide (breaking this guide), so I’ve compromised by linking to a current (as of the time of this writing) version that works well and won’t change. As newer releases come out, they should work, but you will need to test if you choose something different. If you have issues running PulledPork, you may need to install newer versions than what I’m using, as they are actively working on the code at this time.
Download PulledPork and install. Here we copy the actual perl file to /usr/local/bin and the needed configuration files to /etc/snort:
cd ~/snort_src wget https://github.com/finchy/pulledpork/archive/66241690356d54faa509625a78f80f326b75c339.tar.gz -O pulledpork-0.7.2-194.tar.gz tar xvfvz pulledpork-0.7.2-194.tar.gz mv pulledpork-66241690356d54faa509625a78f80f326b75c339 pulledpork-0.7.2-194 cd pulledpork-0.7.2-194/ sudo cp pulledpork.pl /usr/local/bin sudo chmod +x /usr/local/bin/pulledpork.pl sudo cp etc/*.conf /etc/snort
Test that PulledPork runs by running the following command, looking for the output below:
user@snortserver:~$ /usr/local/bin/pulledpork.pl -V PulledPork v0.7.2 - E.Coli in your water bottle! user@snortserver:~$
Now that we are sure that PulledPork works, we need to configure it:
sudo vi /etc/snort/pulledpork.conf
Make the following changes to the pulledpork.conf file. Anywhere you see ‹oinkcode› enter your oinkcode from the Snort website. I have included line numbers to help you identify the location of these lines in the configuration file.
Line 19 & 26: enter your oinkcode where appropriate (or comment out if no oinkcode) Line 29: Un-comment for Emerging threats ruleset (not tested with this guide) Line 74: change to: rule_path=/etc/snort/rules/snort.rules Line 89: change to: local_rules=/etc/snort/rules/local.rules Line 92: change to: sid_msg=/etc/snort/sid-msg.map Line 96: change to: sid_msg_version=2 Line 119: change to: config_path=/etc/snort/snort.conf Line 133: change to: distro=Ubuntu-12-04 Line 141: change to: black_list=/etc/snort/rules/iplists/black_list.rules Line 150: change to: IPRVersion=/etc/snort/rules/iplists
We want to run PulledPork once manually to make sure it works. We use the following flags:
-c /etc/snort/pulledpork.conf the location of the snort.conf file -l Write detailed logs to /var/log
Run the following command:
sudo /usr/local/bin/pulledpork.pl -c /etc/snort/pulledpork.conf -l
After this command runs (it takes some time), you should now see snort.rules in /etc/snort/rules, and .so rules in /usr/local/lib/snort_dynamicrules. Pulled Pork combines all the rulesets that it downloads into these two files. You need to make sure to add the line: include $RULE_PATH/snort.rules to the snort.conf file, or the pulled pork rules will never be read into memory when Snort starts:
sudo vi /etc/snort/snort.conf
Add the following line to enable snort to use the rules that PulledPork downloaded (line 547), after the line for local.rules:
include $RULE_PATH/snort.rules
Since we have modified snort.conf, we should test that Snort loads correctly in NIDS mode with the PulledPork rules included:
sudo snort -T -c /etc/snort/snort.conf -i eth0
Once that is successful, we want to test that Snort and Barnyard2 load correctly when run manually as daemons:
sudo /usr/local/bin/snort -u snort -g snort -c /etc/snort/snort.conf -i eth0 -D sudo barnyard2 -c /etc/snort/barnyard2.conf -d /var/log/snort -f snort.u2 -w /var/log/snort/barnyard2.waldo -g snort -u snort -D
As before, ping the IP address of the Snort eth0 interface, and then check the database for more events (remember to use the MYSQLSNORTPASSWORD):
mysql -u snort -p -D snort -e "select count(*) from event"
The number of events reported should be greater than what you saw the last time you ran this command. Now that we are sure that PulledPork runs correctly, we want to add PulledPork to root’s crontab to run daily:
sudo crontab -e
Choose any editor if prompted, then add the following line and save:
01 04 * * * /usr/local/bin/pulledpork.pl -c /etc/snort/pulledpork.conf -l
Stop the running daemons from earlier testing:
user@snortserver:~$ ps aux | grep snort snort 1296 0.0 2.1 297572 43988 ? Ssl 03:15 0:00 /usr/local/bin/snort -q -u snort -g snort -c /etc/snort/snort.conf -i eth0 -D user 1314 0.0 0.0 4444 824 pts/0 S+ 03:17 0:00 grep --color=auto snort user@snortserver:~$ sudo kill 1296 user@snortserver:~$ ps aux | grep barnyard2 snort 1298 0.0 2.1 297572 43988 ? Ssl 03:15 0:00 barnyard2 -c /etc/snort/barnyard2.conf -d /var/log/snort -f snort.u2 -w /var/log/snort/barnyard2.waldo -g snort -u snort -D user 1316 0.0 0.0 4444 824 pts/0 S+ 03:17 0:00 grep --color=auto barnyard2 user@snortserver:~$ sudo kill 1298
Note: Snort needs to be reloaded to see the new rules. This can be done with kill -SIGHUP snort-pid, or you can restart the snort service (once that’s created in a later part of this guide).
Additional note about shared object rules: In addition to regular rules, The above section will download Shared object rules. Shared object rules are also known as ”Shared Object rules”, ”SO rules”, ”pre-compiled rules”, or ”Shared Objects”. These are detection rules that are written in the Shared Object rule language, which is similar to C.
These rules are pre-compiled by the provider of the rules, and allow for more complicated rules, and allow for obfuscation of rules (say to detect attacks that haven’t been patched yet, but the vendor wants to allow detection without revealing the vulnerability). These rules are compiled by the vendor for specific systems. One of these systems is Ubuntu 12, and luckily these rules also work on Ubuntu 14 and 15.
Congratulations, if you have output similar to the above then you have successfully Configured PulledPork. Continue to the next section to install startup scripts for Snort and Barnyard2. Choose one of the two following links, depending on your version of Ubuntu. You will create an Upstart scripts for Ubuntu 12 and 14, and a systemD scripts for Ubuntu 15.
Choose One of the following to continue:
Ubuntu 12 and 14: Creating Upstart Scripts for Snort and Barnyard2
Ubuntu 15: Creating systemD Scripts for Snort