Perched | Security Education, Consulting, and Support
Security Solutions

Perched Blog

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.

Enabling Feeds

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.

Example Noisy Suricata Rule

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:

  • update.yaml The suricata-update config file

  • enable.conf Config to enable rules that are usually disabled

  • disable.conf Config to disable rules that are usually enabled

  • modify.conf Use regex to modify rules

  • drop.conf Change rules from alert to drop, not used in RockNSM

  • threshold.in Set 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. alert.signature_id). Open 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.

Automating It

RockNSM automatically will run your suricata-update process once per day. This is done using crond in/etc/cron.d/rocknsm_suricata-update every day at noon UTC (which is the default and recommended RockNSM sensor time zone).

Conclusion

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!

1*eA3iCSnDHDWCRntgPnlc3w.gif