It is basically useless to run great pieces of software if they are not configured according to user/system needs. An out of the box deployment of Snort will most likely be something that you don’t want. What you do want is to configure your deployment like you need to. Baisc Snort deployment issues:
- outdated rules
- “noisy” logs and alerts
1. Outdated rules – this is exactly like an outdated antivirus – it gives you a false and wrong sensation of security.
- get the latest rules – 3 very known source are Snort.org (but in order to get them you need an oinkmaster code), EmergingThreats and BleedingEdge
- use a rule management system – like pulledpork (check my blogpost about installing snorby for snort to see how i set it up)
2. “Noisy”/Unwanted logs and alerts. These can be categorized in:
- false-positive alerts
- duplicate alerts
False-positive alerts are simply alerts generated by legitimate/normal traffic, that do not pose any threat. For instance, i get a lot of events named “ET POLICY Dropbox Client Broadcasting”. This is Dropbox sending broadcast packets over the network.
There are 3 ways to get rid of false-positives:
- pro: traffic is processed against a rule in minus – if you are disabling many rules there might be a slight improvement in processing power
- cons: you might loose interesting packets
- how: identify the rule location and comment it from the ruleset file
- con: extra cpu usage by processing more traffic and making a match only to decide if to ignore it at the end
- pro: easy to later edit and to keep track of
- how: edit the /etc/snort/threshold.conf file and add lines with the following format, where X is the generator id, Y is the signature id and Z is the IP from which you want to supress the rule from. (“suppress gen_id X , sig_id Y” or “suppress gen_id X , sig_id Y, track by_src, ip Z”)
- pro: saves cpu usage – if pass rules are ran first, and a match is found in the packet, it is discarded and not tested against other rules
- con: you might lose interesting packets
- how: instead of creating rule that will generate an alert, create a rule that will leave the packet pass when matched.
Some might argue that supressing rules is not the correct way to get rid of false-positives. I personally think there is no “correct” way – it is only the “appropriate” way for your systems or users requirements/needs. On your average small network nobody would stress about too much traffic, therefore even suppresing rules would not overload your server.
Duplicate alerts are the same alerts for events happening over and over again. That can be a problem because the logs can be filled with hundreds of events. A single source IP address can generate hundreds of alerts related to the same activity (e.g. brute force attempts). This can also be useful, but generaly if you would see more than 5 login attempts on a certain service, coming from an unkown IP it’s deductable that it’s a brute force attempt, so hundreds of logs would not be of use here.
You can limit the amount of event reported per rule, triggered either by source or destination IP in a defined time period. This can be done by adding a line like the following to your /etc/snort/threshold.conf file:
threshold gen_id 0, sig_id 0, type limit, track by_src, count 5, seconds 60
This example will stop logging the events after 5 are generated in a period of 60 seconds. More on how to to tweak snort in the manual.