Building Snort and Nessus – Ubuntu IDS Part 3

by on May.20, 2011, under Hardware, How-To's, Linux, Security, Software


In this final article in the three part Ubuntu IDS series, we will go over installing, compiling and configuring Snort and Nessus on our new IDS device.  We will use Snort to analyze traffic as seen by the IDS and we will use Nessus to perform vulnerability testing on the network. The process for installing Snort will also cover installing SnortReport provided by Symmetrix Technologies so we can translate Snort’s cryptic messages into a more readable format that we can take action on.  Read on as we wrap up the installation and finish our IDS device.

This article is divided into three sections. The first section will cover installing Snort, then we will move on to customizing Snort beyond the steps covered in the first section for our specific installation.  Finally we will end with installing Nessus.

1:  Installing Snort

Admittedly, this was the longest part in the series. I had tried manually to compile and install Snort from sources over and over again and wasn’t getting anywhere fast.  I had performed research over and over again on what options to use and was no further along than when I had unzipped the sources.  Luckily my research finally turned up a complete HOWTO article written by Symmetrix Technologies which provided instructions on how to compile and set up Snort.  You can download their HOWTO from this site:

There are some discrepancies that you must take note of: If you are using the bonded interface as described in the prior articles, you will need to use the interface “bond0” instead of the document’s provided eth1 interface for monitoring.  If you monitor an ethX interface, you will only get half of the conversation, and since most of Snort’s ability to detect traffic relies on analyzing stimulus and the responses to that stimulus, you will be severely cutting down on Snort’s effectiveness.

2: Snort Tuning

If you’re this far in, then it’s safe to assume that you have already downloaded Snort, the associated ruleset and have SnortReport installed and running.  There are some things that the Snort installation howto did not entirely touch on and these are things that we will cover here.

Adding BPF to /etc/init.d/rc.local

One of the things missing from the Installation HOWTO was to add a BPF expression to the snort command line. BPF stands for “Berkeley Packet Filter” and is used by Snort and tcpdump to control what traffic is being analyzed by the respective tool.  In our configuration, we need to add an exception for the IDS’s management traffic otherwise when we install and run Nessus, we will end up triggering a ton of alerts.

Edit the /etc/rc.local file and locate the snort line.  Add ” not host″ to the end of the snort line. Replace with that of the IP of the management interface of your IDS.  This is the BPF syntax that tells it to monitor your network but not the IP of your IDS device. By adding it to the end of the snort command, we are effectively telling Snort to not listen to the traffic generated by Nessus when we decide to fire it off.

Password Protect SnortReport:

Regardless of whether or not your IDS device can be reached from the Internet, there exists several vulnerabilities in SnortReport including one that allows potential code execution.  This could allow someone that knows you run SnortReport to execute code on your IDS and would be counterproductive to our efforts.  Until SnortReport has been fixed by SymmetrixTech, we will have to use a more basic method of securing it.  In order to provide minimal protection for SnortReport, we will add .htaccess protection to the directory that SnortReport was installed in so that way only authorized people will have access to SnortReport.

As root, we will use htpasswd to create the password file.  If you forget it later on, you can recreate the file easily using the below steps. Use the below command to make the password file and replace “joe” with that of your desired username.

# htpasswd -c /var/snortreportpasswd joe

Now, we need to create a .htaccess file in /var/www/snortreport-1.3.1 to reference it.  Copy the below code and enter it into /var/www/snortreport-1.3.1/.htaccess and don’t forget the . in the filename.

AuthName "SnortReport"
AuthType Basic
AuthUserFile /var/snortreportpasswd
Require valid-user

Finally, there is one more change we need to make to Apache2 to get the .htaccess protection working.  Edit /etc/apache2/sites-available/default and look for the clause that looks like the one below:

<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all

Change the “AllowOverride None” to “AllowOverride All” and then restart apache2 via /etc/init.d/apache2 restart . Now try it out by going to http://(your IDS IP address)/snortreport-1.3.1/alerts.php. You should  get a password prompt. Type in the password that you created using the htpasswd command earlier and you should see a green page that says SnortReport.

When you first load the page, you will see two dropdowns for Timeframe and Day.  If your IDS has received any incidents, you will see it show the incidents here.   Clicking on the incident summary will show more details including the source and destination IP addresses. Clicking on the IP will return correlated events that include the source or destination IP you clicked on and will show packet payloads and IP addressing information.

Now that you have a way to read the incidents that the IDS receives, it’s up to you to decide whether or not the incidents generated are something to take action against. However, installing an IDS is only one half of the solution.  In order to be aware of the effect an attack may have on your network, you first must know what vulnerabilities exist on your network.  For that, we turn to the free vulnerability scanner, Nessus.

3: Installing Nessus

Nessus is widely used as a professional commercial-grade vulnerability scanner. It can generate reports that indicate per host what vulnerabilities exist and can provide information on where to go to learn more about patching or mitigating the threat.  Keep in mind that while Nessus is often used on Linux, it is a commercial product.  It does have a home version which we will be using in our installation however the home version can not be used in a commercial environment.

The Nessus HomeFeed provides your Nessus installation with the most up-to-date vulnerability detection methods and signatures.  Access to the HomeFeed does come at a cost, however the benefits of having a vulnerability scanner outweigh the loss of a couple of features. Most notably, a feature that is only available to their commercial feed is that you can not set up recurring scans of you home network, e.g. you can’t tell the IDS to automatically scan your network and generate reports on a regular schedule.  The only other limitation that I have been able to find is that the scans are limited to 16 active hosts per report so if you have 32 hosts, you will need to run two scans. Despite the two limitations mentioned above, Nessus is still a great scanner, and will work quite well for identifying vulnerabilities on your network.

All that being said, let’s get started.

First off, head to Tenable Security’s website at and register to receive your activation code. Keep your email handy, you will need it later.

Next, head to and agree to the license, then download the Ubuntu debian package that is appropriate for your distribution.  Since this tutorial is based on using Ubuntu 10.04, I downloaded the Ubuntu 10.04 32 bit version. Although the filename says “ubuntu910”, this version was recommended by Tenable as the version to use for 10.04.

Now, SCP the installation package to the IDS and then use dpkg -i Nessus-4.4.1-ubuntu910_i386.deb to install it into the server. Please note: If your Ubuntu Server is running a 64 bit kernel, please download the 64bit version of Nessus.

Once installed, you will need to add a Nessus user to the service so you can login.  Nessus users are seperate from OS users, so you can have multiple users without having to add multiple users to the system.  To start this process, run /sbin/nessus-adduser and follow the prompts.  For the first user that you add, you will want to add an administrative user. This user will be able to adjust Nessus’s scan policies, behaviors and other settings within Nessus.

Now that you’ve added a user, you will need to register your Nessus installation using the HomeFeed code in your email.  Run the command /opt/nessus/bin/nessus-fetch –register <Activation Code> and allow it to complete the installation. Substitute <Activation Code> with the HomeFeed code in the email.  Please note: This step may take a considerable amount of time due to the fact that Nessus will download and update itself according to the HomeFeed subscription.  This only took about an hour on my system, your mileage may vary depending on Internet connectivity speeds.

Now that the Nessus service is installed, registered and updated, it’s time to test the installation.  Open a web browser and go to https://your-ids-ip-address:8834 .  If you are running Firefox and are using Noscript, AdblockPlus or Flashblock, you will need to add exceptions for Javascript and Flash for the IDS IP.  This is required as the Nessus UI relies entirely on Javascript and Flash.

Now that you have Nessus installed, it is highly recommended to take a read through the Nessus User’s Guide: While Nessus is a vulnerability scanner, some of the tests it performs can cause unpredictable results. It is recommended to set up a “safe” scan that performs basic testing and then set up a “full” scan for aggressive testing.

How to read the scan results:

Once you have made it through the User’s Guide and have performed your first scan, you can download or view the report.  The report is listed according to IP address, then service name, then vulnerability. Each vulnerability will include the service name, port, protocol, related CVE information (links to the CVE database for more information), as well as common fixes for the vulnerability.

I recommend taking a look at the vulnerability list in this order:

  1. Externally accessible services: A vulnerability in Apache that listens to the outside world threatens your internal network.  Address this first!
  2. Internally accessible services on the same server as external services:  Should the external service be compromised, internal services could be used to further compromise the network.
  3. Internally accessible services: A service listening internally may not pose much of a threat, but may be a possible point of compromise should another host get infected.  ( A common example is a weakness in older versions of Samba that would allow for remote code execution.)

Generally speaking, it is a good idea to keep up to date with all service packs, updates and patches as this will prevent any known exploits from turning into full-blown worms.  Remember, it only takes one vulnerability to get compromised.

Final thoughts:

This has definitely been quite a project. I have learned a whole lot about network security in the course of my GCIA training and in building this project. I honestly think that building an IDS device from scratch is a great way to get acquainted with network security and how to perform vulnerability assessments.  Using Snort Report to analyze suspicious traffic and incoming threats and using Nessus to identify vulnerabilities in your system will help your home network stay secure against the ever evolving threats going around the Internet.

Always remember that security is no use if the warnings go unheeded.  While you don’t have to turn into a complete security nut, make it a good habit to take a look at Snort Report once a week at least.  Personally, I record the number of events logged and if it changes, I then investigate further however I haven’t picked up any incidents in the last month so for me it’s a pretty easy check.  If you find yourself with tons of IRC events and you don’t use IRC, it’s very possible that you have an active trojan on your hands and may warrant further investigation.

I hope you had fun and learned a lot from this project. I had a lot of fun building it and working out the kinks to make it all work together.  If you have any comments or questions, please leave me a comment and I’ll do my best to answer.





:, , ,

4 Comments for this entry

  • spuder

    Firestorm_v1, I love blogs like this, and think that there should be more of them. I started my own to help get information like this spread around, though not quite the quality or technicality shown here.

    I am trying to setup my own IDS for my security class, and also for personal use.

    Here are some stabling blocks I have run into.

    1. What kind of hardware do I need to setup a pfsense/snort router IPS for a home or small businesses? I am thinking of building my own proxmox virtual server, but don’t know if I should run pfsense and snort inside virtual machines or if I should put them in their own physical box running an old p4 I have laying around. What are your thoughts?

    2. How do you manage the snort physical interfaces. I have one interface on the inside network for management with an ip address, and 2 interfaces acting as the pass through for all traffic on my dmz. I want it to drop any packets that meet a specific requirement, but can’t find information on how to setup the bridging for those 2 interfaces.

    I am sure I will keep referring back to your blog

  • firestorm_v1

    Hello Spuder:

    Thank you for the kind comments. In regards to the hardware required for Snort to be effective, it depends on your network throughput. The snort device has to be fast enough to be able to read and interpret all of the traffic coming through the link and be able to act. For my network running off of a shared line at an apartment complex, I used a Pentium 4 with Hyperthreading, 3GHZ processor, 2GB RAM and an 80GB HD. Even when I’m streaming netflix and downloading updates, the box sits at 0.1 load.

    In regards to your second concern, this will depend on how you have the traffic coming in. Are you using a switch with a monitor port (or a Cisco switch and a span session) or are you using the Ethernet Bridge and Passive Tap method (link here).

    If you’re using an ethernet tap, then you will need to bridge the two interfaces in order to hear both sides of the conversation on-wire.
    If you’re using a span session or a monitor port, you will want to ensure that you’re hearing both sides of the conversation via the ICMP test in the linked bridging article.

    If you want to ignore specific traffic from a specific IP address, you can use a BPF filter statement in /etc/rc.local on your snort command like the one below:
    /usr/local/snort/bin/snort -D {other snort options go here} not host and not host

    In this example, “not host and not host” tell snort to ignore any traffic from the IP addresses provided. Snort uses the same bpf filters as tcpdump, so if you can use tcpdump to identify the traffic you don’t want, you can specify in snort to not pay attention to it.

    Good luck!


  • David Gullett

    The new version of SnortReport (1.3.3) fixes the remote code execution (SQL injections, etc):

  • firestorm_v1

    Hello David:

    Thanks for the update. I haven’t messed with SnortReport in a while so I’ll have to download it again and check it out.