Tips and Tricks: Troubleshooting Snort

Whether you’re tuning an existing Snort instance or just finished a new installation, there’s a common question that may soon follow: “Why I aren’t I seeing any events?

If this is the case with your Snort instance, there are a few basics to check.

Starting Snort
In many cases Snort is started with a script as opposed to a manual command that includes “-D” to start it in daemon mode, but such scripts don’t help in the troubleshooting process. 

1. Check if Snort is running or if the script has been executed with a simple grep command:

ps aux | grep snort

2. If Snort is running, take note of the command displayed that was either executed manually or by a script, and then stop or kill the process.

3. Enter that long-hand command to start Snort (snort -c /etc/snort/snort.conf -i eth1, for example) in the foreground or continuous mode, making sure to omit the -D so the process is not started in daemon mode.

If there are any issues with Snort, they will be specifically noted and generally Snort will fail to start because of a fatal error. 

If Snort successfully starts, you’ll see its final line stating “Commencing packet processing (pid=xxxxxxx).” If this is the case, kill the process and move on to Log Files. If you get an error, resolve it and start Snort again in the same manner until there are no errors. Errors generally revolve around signatures (bad or incompatible signatures that kill Snort), missing file or rules directories, or something related to the snort.conf. Once your error is resolved and Snort starts successfully, kill the process and move on to Log Files.

Log Files
Every time Snort starts it will or should create a new log file. These files are generally named merged.log or snort.alert, and are located in /var/log/snort, but of course precise names and locations will differ depending on your setup.

You can confirm Snort successfully created its log file when you just started it in the last step, and also check for previous log files and their sizes with a simple list command:

ls -la /var/log/snort

You should see at least one log file, and more than likely its size (or at least the most recent log file) will be zero, and that’s fine since Snort only ran for a few moments. But checking this directory with that command is very helpful in first ensuring log files are being created, and secondly determining if those log files are growing in size. 

If log files are being created and not growing in size after Snort has been running in daemon mode for some time, there could be issues with the configuration file, the signatures, or the traffic feed.

Configuration File
While Snort can be a complex tool, we aim to keep things simple. With a new installation of Snort, we make the following changes to its configuration file:

Provide the paths to the rules:

var RULE_PATH /etc/snort/rules

var SO_RULE_PATH /etc/snort/so_rules

var PREPROC_RULE_PATH /etc/snort/preproc_rules

var WHITE_LIST_PATH /etc/snort/rules

var BLACK_LIST_PATH /etc/snort/rules

2. Uncomment the “output unified2” line and remove “nostamp”:

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

3. In “Step #7” of the configuration file you’ll find a listing of rule categories that will be enabled when Snort starts:

###################################################
# Step #7: Customize your rule set
# For more information, see Snort Manual, Writing Snort Rules
#
# NOTE: All categories are enabled in this conf file
###################################################

# site specific rules

include $RULE_PATH/app-detect.rules
include $RULE_PATH/local.rules
include $RULE_PATH/browser-chrome.rules
include $RULE_PATH/browser-other.rules

These categories may be missing or commented out, in which case when Snort starts it will run with few or no signatures, resulting in few to no events and small to zero log file sizes. Make and save any necessary changes to the configuration file, and move on to Signatures.

Signatures
Being a signature-based IDS tool, Snort will require enabled and current signatures to generate events. While too few signatures may result in few to no events, too many signatures enabled can result in not only too many events but an overloaded Snort sensor, an overcrowded Aanval dashboard—consisting of largely informational/nuisance events—and perhaps overworked database and/or hardware running the sensor.

Investigate the various rule categories in your /rules directory and make sure standard and especially critical signatures are enabled. For testing purposes, you can enable the signatures found in the protocol-icmp.rules directory, start Snort in daemon mode, and then ping the Snort box from an alternate IP. Keep in mind that these ICMP signatures aren’t generally kept enabled in active or production environments, and once tests are concluded it’s recommended to disable these signatures.

Traffic Feed
It’s lastly critical that the interface Snort is monitoring is actually generating real traffic. Snort commonly monitors the span/mirror port of a switch. Confirming the interface to be monitored from the long-hand command to start Snort (snort -c /etc/snort/snort.conf -i eth1, for example) and that the interface is active (ifconfig), you can use tcpdump to scan the interface for traffic with a basic command:

tcpdump -nn -i eth1 (or the interface to be scanned)

If you aren’t seeing anything or simply ARP or basic traffic, you may need to check the feed and interface. But once confirmed that there is more happening than basics and ARP, the interface Snort is to monitor should be solid.

Having completed this list of basic steps and checks, and making any necessary changes, you should be good to start your Snort instance(s) in daemon mode and begin to see log files created and growing, and events flowing into Aanval.

“I can’t log in to Aanval”

“I can’t log in to the console. I entered the correct username and password and even received the ‘Authentication success’ message, yet I’m directed back to the login page.”

Prognosis and Remedy: Login issues like this are database/MySQL related. Generally when this occurs MySQL is not running. If MySQL is running, then the database tables are missing or corrupt, or more often the disk is full.

For more Aanval Tips, Tricks, and Troubleshooting assistance, visit our wiki.

Did you know? Aanval is the longest running and most refined Snort front-end, and has been in continual development since 2003. To take Aanval for a Test Drive, visit www.aanval.com/download.