Chapter 55

Rule Sets

Commercial and free Suricata rule sets provide coverage of known threats without requiring you to write every rule yourself. The major sources are Emerging Threats (ET Open / Pro), Proofpoint, CISA, and community projects. Understanding what each covers, how to maintain them with suricata-update, and when to write custom rules on top of them is how a detection engineering team scales coverage without scaling headcount linearly.

Scenario

A new SOC deploys Suricata and enables ET Open rules. On day 1, they get 500 alerts. 450 are informational (ET INFO, low priority). They tune these out by filtering all classtype:bad-unknown rules with priority 3. The remaining 50 are actionable. Over the next two weeks, they track which rules fire the most, suppress known-false-positives with threshold.conf, and add 5 custom rules for their specific environment (VPN client behavior, internal tools) to eliminate the remaining noise.

Rule Set Comparison

Rule Set	Source	Cost	Coverage	Update Frequency
ET Open	Proofpoint	Free	~40,000 rules; broad malware/C2/exploit	Daily
ET Pro	Proofpoint	$	ET Open + 1-2 weeks faster updates + extra coverage	Daily (faster access)
OISF Community	Suricata project	Free	Curated, minimal false positives	Weekly
CISA AIS	CISA	Free (signup)	Federal threat intel; APT, ICS/SCADA	As-available
Abuse.ch SSL BL	Abuse.ch	Free	Known C2 JA3 + certificate hashes	Near real-time
Custom/internal	Your team	Time	Environment-specific, highest relevance	As needed

Managing Rules with suricata-update

bashsuricata-update-mgmt.sh

#!/bin/bash

echo "=== Bootstrap suricata-update ==="
suricata-update update-sources        # Fetch available source index

echo ""
echo "=== Enable free sources ==="
suricata-update enable-source et/open           # Emerging Threats Open
suricata-update enable-source oisf/trafficid    # App detection rules
suricata-update enable-source abuse.ch/sslbl    # SSL blacklist (JA3 + certs)
suricata-update enable-source stamus/nids       # Stamus community rules

echo ""
echo "=== List enabled sources ==="
suricata-update list-enabled-sources

echo ""
echo "=== Update all enabled sources ==="
suricata-update

echo ""
echo "=== Create a disable list to suppress noisy rules ==="
cat > /etc/suricata/disable.conf << 'CONF'
# Suppress specific SIDs (noisy / not applicable)
2019401  # ET POLICY Internal-to-External IP Proto 41 (too broad)
2100366  # GPL POLICY Peer to Peer Software (VPN false positives)

# Suppress entire categories
group:et/open.rules/emerging-games.rules
group:et/open.rules/emerging-p2p.rules
group:et/open.rules/emerging-policy.rules
CONF

echo ""
echo "=== Create a threshold file for high-volume rules ==="
cat > /etc/suricata/threshold.conf << 'CONF'
# Threshold: SID 2024218 — limit to 1 alert per source per 10 minutes
threshold gen_id 1, sig_id 2024218, type threshold, track by_src, count 1, seconds 600

# Suppress: known scanner, not a threat
suppress gen_id 1, sig_id 2024792, track by_src, ip 10.0.0.5

# Suppress: internal monitoring tool triggers this rule
suppress gen_id 1, sig_id 2100498, track by_dst, ip 10.0.0.10
CONF

echo ""
echo "=== Apply disable list in update ==="
suricata-update --disable-conf /etc/suricata/disable.conf

echo ""
echo "=== Add custom rules directory ==="
cat >> /etc/suricata/suricata.yaml << 'YAML'
rule-files:
  - /etc/suricata/rules/suricata.rules  # Generated by suricata-update
  - /etc/suricata/rules/custom.rules    # Your custom rules
YAML

echo ""
echo "=== Reload rules without restarting Suricata ==="
kill -USR2 $(cat /var/run/suricata.pid)
# This triggers Suricata to reload its rules file without dropping traffic

Why custom rules matter even with commercial feeds

Commercial rule sets like ET Pro are written for the broadest possible applicability — they must work for every environment, from a single-site SMB to a Fortune 500. This means they're tuned conservatively: they catch attacks that work against "typical" environments but miss attacks specifically designed for your environment, your technology stack, your internal tools. Custom rules fill two gaps: (1) Environment-specific indicators: your VPN client makes API calls that look like C2 beaconing to generic rules. Write a pass rule to explicitly allow it so other rules can fire cleanly. (2) Threat intelligence operationalization: when a threat report drops about a new malware that uses a specific HTTP header or JA3 fingerprint, your team can write a Suricata rule and deploy it within hours — faster than any commercial feed updates its database. The general rule feeds cover the 90% well-known threats; custom rules cover the 10% that's specific to your threat model. Both are necessary for a mature detection program.

Q & A

Q: How do I test that suricata-update is actually deploying new rules and Suricata is using them?

Three verification steps: (1) Rule count check: before and after update, run grep -c "^alert" /etc/suricata/rules/suricata.rules — the count should increase after adding new sources. (2) Specific rule check: pick a SID from the ET Open release notes (check the Proofpoint/ET Open GitHub or changelog), and verify: grep "sid:2024218" /etc/suricata/rules/suricata.rules. If the rule appears, it's in the rule file. (3) Verify Suricata loaded it: after killing with USR2 (live reload) or restarting Suricata, check grep "rule" /var/log/suricata/suricata.log | tail -5 — Suricata logs how many rules were loaded: "N rules successfully loaded from X files." Compare to the previous load count. If you added 1000 rules and the count went up by only 10, your disable.conf is suppressing most of them (check the update output for "disabled N rules"). For a full audit: suricata-update --no-merge --output /tmp/test-rules/ produces a flat file showing which rules are enabled, disabled, and why, without affecting the running instance.