So, you’ve set up your Snort IDS exactly as described in David Gullet’s guide on Symmetrix.com and it still won’t work… Well, you’re not alone. I had the same issue. In fact, I reinstalled the operating system and followed the guide a second time – making absolutely sure I didn’t miss a single step – and it still wouldn’t work. I am not exactly sure why the guide seems to work for some and not for others. I know several other people that have set up a Snort IDS using this guide and for some it worked perfectly while others encountered a range of different issues. This blog post describes the issues that I personally encountered and how I was able to resolve them.
Wrong ELF Class
This is an easy one. Under “Download the latest Snort rules” the guide tells you to execute the following command:
sudo cp /usr/local/snort/so_rules/precompiled/Ubuntu-10-4/x86-64/188.8.131.52/* \ /usr/local/snort/lib/snort_dynamicrule
If you’re like me and you’re following the guide exactly, maybe even copying and pasting commands as you go, then you might have executed this command without realizing it didn’t fit your system. “Ubuntu-10-4” refers to the OS that is used, “x86-64” refers to your CPU architecture, and “184.108.40.206” refers to the version of Snort that you’ve installed. Make sure all of these match to your setup. Specifically, the “wrong ELF class” error message is caused by using rules for the wrong CPU architecture, so chances are that you have to substitute “i386” for “x86-64” or vice versa.
Empty Snort.u2 files
This one in particular drove me insane for a while. After realizing that the MySQL database wasn’t being populated by Barnyard2 I started troubleshooting the issue, eventually finding out that all the snort.u2 files in the /var/log/snort directory were 0 bytes in size. Snort would create a new file every time it was run, but the files would not increase in size even when I fired up an nmap Xmas tree scan against the IDS. Several hours of using Google showed me that other people had encountered the same issue, but none of the solutions (changing file or folder permissions) worked for me.
In the end, the solution was offered to me at the first place that I really should have visited: Snort.org. Specifically, in their FAQ section they offer the following advice:
“This is most likely the result of a checksum offloading issue. Try adding ‘-k none’ to your Snort command line and see if it works”.
Turns out, that is exactly what did the trick for me. Although I have reviewed the documentation I still don’t fully understand that checksum offloading issue. I also don’t know if the ‘-k none’ flag has any negative side-effects while running Snort, but I do know that it is the only thing that made Snort work for me in the first place.
One more suggestion on this issue; when Snort rules are downloaded and added, many of them are commented out. This is done on purpose because Snort rules have to be customized to each and every networking environment in which Snort is deployed. Without commented out rules, Snort would provide way too many false alerts. Make sure that you’re not trying something very specific to generate an alert. If you are and the rule for that network traffic is commented out, then Snort will not issue an alert. Open up the rule files and verify that the rule for your network traffic is not commented out.
Snort Report only shows PHP code
After going through the installation process, I opened up http://localhost/snortreport-1.3.4/alerts.php only to be greeted by this:
$db->setinst($server); $db->setuser($user); $db->setpass($pass); $db->dbname($dbname); $db->persist(); $conn = $db->connect(); define(“FULL_DATETIME_FORMAT”, “Y-m-d H:i:s”); set_time_limit(1800); require_once(“info-retrieval.php”);
At first I thought that this meant that Snort could not contact the MySQL database server and therefore I was seeing the query that was supposed to be received by the database. However, I soon realized that these strings do not make up MySQL code. Additionally, I later learned that if Snort Report cannot reach the database it would simply show 0 alerts. It would still display the correct Snort Report website, just without any relevant information.
Instead, what was going on was that the srconf.php file was not recognized as PHP, resulting in part of the contents of the file being output literally. Opening up the ‘srconf.php’ file shows that the file opens with “<?”, and it closes with “?>”. These are called ‘short open tags’, and they are a shorter version of the complete “<?php” and “?>” tags.
Your ‘php.ini’ file might not be configured to recognize these short open tags as PHP tags. First, find your php.ini file by using the command “find / -name php.ini”. My php.ini file was located at /etc/php5/apache2/php.ini. Scrolling down in this file will eventually bring you to a line that says “short_open_tag = Off”. Change this to “short_open_tag = On”.
If you see the page below, that means that Snort Report is now loading correctly.
Hopefully it will also show alert data. If it doesn’t – like in the image – then you might have one or more of the following issues:
- Snort Report cannot contact the MySQL database
- Make sure that your database has been created and it has data in it. If it does, then make sure the srconf.php file for Snort Report has the correct login information.
- Barnyard2 is not putting information in the database
- If the srconf.php is definitely correct but the MySQL database only contains empty tables, make sure that Barnyard2 is running correctly and not erroring out. Run it in the foreground and pay attention to its output.
- Snort is not generating alerts
- If Barnyard2 is running without errors but still on events are put into the MySQL database then either Barnyard2 doesn’t have the correct database information (check the barnyard2.conf file) or Snort is not generating alerts. Verify that the snort.u2 files are not 0 bytes. Also run Snort in the foreground and pay attention to its output.
I hope that I was able to help you with any Snort configuration issues you might have been having. Please post a comment for any feedback.