Managing Suricata on RockNSM 2.3
RockNSM 2.3 was recently released and it includes a whole host of upgrades and new features. One that I’m excited about is Suricata 4.1.2, which now comes bundled with
suricata-update for managing rules. Previously Suricata required manual curating or using legacy tools designed for Snort such as pulledpork.
Suricata Update is a Python module and is automatically bundled with Suricata starting with version 4.1. While it does have documentation, it’s helpful to have a practical example. One of the awesome features with Suricata Update is it comes with a pre-configured list of signature feeds out of the box, both free and paid. It makes it very simple to enabled paid feeds.
To view the list of available feeds, login to your RockNSM system and run:
sudo suricata-update list-sources
This will return something similar to the following:
Name: oisf/trafficid Vendor: OISF Summary: Suricata Traffic ID ruleset License: MIT Name: et/open Vendor: Proofpoint Summary: Emerging Threats Open Ruleset License: MIT Name: scwx/security Vendor: Secureworks Summary: Secureworks suricata-security ruleset. License: Commercial Parameters: secret-code Subscription: https://www.secureworks.com/contact/ (Please reference CTU Countermeasures) Name: scwx/malware Vendor: Secureworks Summary: Secureworks suricata-malware ruleset. License: Commercial Parameters: secret-code Subscription: https://www.secureworks.com/contact/ (Please reference CTU Countermeasures) Name: et/pro Vendor: Proofpoint Summary: Emerging Threats Pro Ruleset License: Commercial Replaces: et/open Parameters: secret-code Subscription: https://www.proofpoint.com/us/threat-insight/et-pro-ruleset Name: ptresearch/attackdetection Vendor: Positive Technologies Summary: Positive Technologies Attack Detection Team ruleset License: Custom Name: sslbl/ssl-fp-blacklist Vendor: Abuse.ch Summary: Abuse.ch SSL Blacklist License: Non-Commercial Name: tgreen/hunting Vendor: tgreen Summary: Heuristic ruleset for hunting. Focus on anomaly detection and showcasing latest engine features, not performance. License: GPLv3 Name: etnetera/aggressive Vendor: Etnetera a.s. Summary: Etnetera aggressive IP blacklist License: MIT
Without any additional configuration,
suricata-update will automatically pull in the
et/open ruleset. You can disable this ruleset if you desire. Now, if you are a subscriber to
et/pro or another included ruleset that requires an access code (sometimes referred to as an “oinkcode” in Snort parlance), you can pass that on the command line or
suricata-update will prompt you.
suricata-update enable-source et/pro secret-code=xxxxxxxxxxxxxxxx
Manipulating Individual Rules
Often times, we want to turn off specific rules — maybe they’re too noisy for our network, or maybe our corporate policy doesn’t concern with browser extensions on BYOD systems. Again,
suricata-update makes our life easy on our RockNSM sensors.
Take for example the following screenshot from Kibana.
In this example, there’s an HTTP POST that allegedly has an invalid timestamp on the packet. In this case, it’s an artifact of this sensor running under VMware ESXi and time synchronization issues. We could ensure that all the systems in the environment are sync’d to a reliable NTP source, but this is just a lab, so meh. It’s definitely not an indicator of something crazy malicious. To turn this off, first we need to generate the default configuration (in the next release of RockNSM slated for next month, we’ll do this by default, watch issue #372 for those of you following along).
# Elevate to a root shell and go to Suricata dir sudo -s cd /etc/suricata # Generate default suricata-update configs suricata-update --dump-sample-configs
This command will generate six default files:
enable.confConfig to enable rules that are usually disabled
disable.confConfig to disable rules that are usually enabled
modify.confUse regex to modify rules
drop.confChange rules from alert to drop, not used in RockNSM
threshold.inSet thresholds to limit too frequent firing of any given alert
To disable the noisy rule above, we just need to specify its signature ID (e.g.
disable.conf and add the following line:
# Disable invalid timestamp rule (sid: 2210044) 2210044
We could alternatively specify the rule using regular expressions:
# Disable all SURICATA STREAM alert rules re:^alert.*SURICATA STREAM
Next, just run
suricata-update. Note, you want to ensure that
suricata-update runs as the same user as the
suricata service. On RockNSM, this is the
suricata system user. This should really only be necessary the first time
suricata-update is run, to ensure that when Suricata runs it can read the rules. Near the end of the run, you’ll see a summary how many rules were loaded, disabled, enabled, modified, dropped, and some other stats.
sudo -u suricata -g suricata suricata-update ... 27/2/2019 -- 00:08:39 - <Info> -- Loaded 29733 rules. 27/2/2019 -- 00:08:40 - <Info> -- Disabled 68 rules. 27/2/2019 -- 00:08:40 - <Info> -- Enabled 0 rules. 27/2/2019 -- 00:08:40 - <Info> -- Modified 0 rules. 27/2/2019 -- 00:08:40 - <Info> -- Dropped 0 rules. 27/2/2019 -- 00:08:41 - <Info> -- Enabled 188 rules for flowbit dependencies. 27/2/2019 -- 00:08:41 - <Info> -- Backing up current rules. 27/2/2019 -- 00:08:45 - <Info> -- Writing rules to /var/lib/suricata/rules/suricata.rules: total: 29733; enabled: 22272; added: 4; removed 19; modified: 1215
You can sanity check that it worked by checking the output for the signature you disabled with grep. You could also search using the same regex as before! If you want to match the regex pattern, be sure to search for a line starting with a
# followed by a single space, as this is how the rule is commented out. If the disable configuration worked, you’ll see the rule, but it will be commented out.
sudo grep 2210044 /var/lib/suricata/rules/suricata.rules # alert tcp any any -> any any (msg:"SURICATA STREAM Packet with invalid timestamp"; stream-event:pkt_invalid_timestamp; classtype:protocol-command-decode; sid:2210044; rev:2;)
To check for a regex you could do this.
sudo grep '^# alert.*SURICATA STREAM' /var/lib/suricata/rules/suricata.rules ... (a whole bunch of rules match this)
Local Rule Management
Suricata Update lets you manage local rules using the same process above. In the
update.yaml it defaults to loading all rules in the
/etc/suricata/rules directory. You could add some local site-specific directory, as well. Suricata Update will parse each of these rules and apply the same operations that you configured, as detailed above.
RockNSM automatically will run your suricata-update process once per day. This is done using
/etc/cron.d/rocknsm_suricata-update every day at noon UTC (which is the default and recommended RockNSM sensor time zone).
RockNSM 2.3 includes Suricata 4.1 and therefore ships with suricata-update. This provides a powerful mechanism to manage rules on your sensor. In future RockNSM releases, some of the boilerplate demonstrated above will be done for you. In a future blog post, we’ll discuss an approach to managing several sensors with organization-generated rules using the basics discussed here.
Rock On, Hunters!