Once data starts flowing through the sniffing interfaces you are going to be presented with a lot of false positives. It’s essential to reduce the number of false positives because the identification of real indicators can become next to impossible and your hardware will thank you. When I fired up Security Onion on Ubuntu 16.04 for the first time, it was generating around 26 alerts a second using Emerging Threats and Snort rulesets. Now that my installation is tuned it’s generating .023 alerts a second which is far more manageable than 26 a second.
There are two ways to tune alerts, and that’s by disabling a rule or configuring a threshold (rate limiting). Disabling a rule should be done only when you are confident, through investigation, that the rule doesn’t apply to your environment or you have a better way of identifying the indicator as a confirmed positive such as antivirus or a firewall. Adding a rule to the threshold file allows you to track the event by source OR destination IP address, CIDR, and set the rate of alert generation by specifying the number of alerts per seconds. You can also suppress rules which means they’re still active but the data matching them is ignored as opposed to disabling rules which mean data isn’t compared against the rule for a match to generate an alert.
This guidance is version agnostic.
The command to find the rules that are generating a lot of alerts for your starting point is “sudo sostat.” You will have to scroll up a little to find the Top 50 All-time Sguil Events.
Here are the locations of the disablesid and threshold files:
- /etc/nsm/rules/threshold.conf
- /etc/nsm/pulledpork/disablesid.conf
My text editor of choice is vi so the commands to access and edit the files are as follows.
- sudo vi /etc/nsm/rules/threshold.conf
- Press “i” to insert text
- Comment out the description of the rule you’re adding by using “#”
- Add the rules by using gen_id (generator id) and sig_id (signature id)
- Suppression – suppress gen_id 119, sig_id 34, track by_src or by_dst, ip <IP address or IP block\CIDR>
- Suppression – suppress gen_id 119, sig_id 34
- Rate limiting – event_filter gen_id 3, sig_id 30881, type limit, track by_dst, count 1, seconds 60
- Once you’ve added the rules press escape then “:” followed by wq (write, quit)
- Run “sudo nsm_sensor_ps-restart –only-snort-alert” adding suppression entries
- sudo vi /etc/nsm/pulledpork/disablesid.conf
- Press “i” to insert text
- Add a description of the rule you’re disabling by using “#” to comment out the text, so the IDS engine doesn’t try to process it
- Add rules to the file, e.g., 1:2009702 (generator id:signature id)
- Once you’ve added your rules press escape then “:” followed by wq (write, quit)
- Run sudo rule-update
If you enter the vi editor without making any changes you must use “:q!” if you pressed “i”; use “:q” if you didn’t use the insert command.
If you’ve spent any time searching Google to tune Security Onion you’ve probably come across a few forum threads that insist on getting your total signature count to under 8000 which assumes you’ve invested time that most people don’t have into looking into the 30000 to 60000 total signatures between Snort and Emerging Threats (configuration dependent). Aiming for a threshold of the overall signature count isn’t the best way to go about tuning Security Onion because you’ll never know every signature you’ll need, so it’s best to rate or disabled signatures based on operational need.
In the next section, I’ll be talking about PCRE which stands for Perl-compatible regular expression. PCRE can be used with simple keywords such as “sensitive_data” without converting it into a regular expression.
Here are signatures that I’ve found to be common false positives across many environments:
- All sensitive_data signatures using “pcre:”
- All http_inspect using “pcre:” unless you have a web server
- SMTP: attempted command buffer overflow (124:1)
- All stream5 using “pcre:” unless you have a web server
- TMG Firewall
Worth noting, Security Onion doesn’t always process PCRE entries so you’ll have to resort to “gen_id:sig_id.”