Suricata rule categories — what the Emerging Threats rulesets cover and how to choose · OPNsense

The Emerging Threats rulesets cover tens of thousands of signatures across dozens of categories. The operator who enables every category ships a noisy deployment that produces alerts on traffic the operator does not care about; the operator who enables too few categories misses attacks the engine could have detected. The discipline is to choose the categories that match the network’s threat model, start narrow, grow based on observed traffic, and write custom rules for site-specific threats. This lesson covers the ET Open and ET Pro rulesets, the major categories, the discipline of choosing, and the custom rule workflow.

ET Open versus ET Pro

Emerging Threats maintains two rulesets:

ET Open — a free, community-maintained ruleset covering common threats. Updated daily. Included with OPNsense by default. Coverage is broad but not deep — common malware, common exploits, common C2.
ET Pro — a paid, Proofpoint-curated ruleset with deeper coverage (more specific signatures, more malware families, faster updates). Subscription required. Coverage includes zero-day exploits within hours of disclosure.

A typical production deployment runs ET Open. A network that needs faster or deeper coverage adds ET Pro. The two are not mutually exclusive — Suricata can load both rulesets in the same instance.

The major rule categories

The Emerging Threats Open ruleset organises signatures into files by category. The major categories and what they detect:

Category	What it detects	Typical rule count
`emerging-attack_response.rules`	Outbound traffic that suggests a compromise — C2 callbacks, suspicious DNS resolutions, known-bad IP destinations	~5,000
`emerging-botcc.rules`	Known botnet command-and-control destinations (IPs and domains)	~2,000
`emerging-compromised.rules`	Traffic to/from known-compromised hosts (per ET’s reputation feeds)	~1,500
`emerging-dns.rules`	DNS-based attacks and C2 — known-malware DGA domains, DNS tunneling, suspicious TXT records	~2,500
`emerging-exploit.rules`	Known exploits against specific CVEs (server-side and client-side)	~6,000
`emerging-malware.rules`	Known malware patterns in HTTP, TLS, SMTP, and other protocols	~400
`emerging-mobile_malware.rules`	Mobile-platform malware (Android, iOS)	~300
`emerging-scan.rules`	Reconnaissance — port scans, vulnerability scans	~500
`emerging-trojan.rules`	Trojan patterns — backdoors, RATs, droppers	~1,500
`emerging-web_server.rules`	Attacks against web servers — SQL injection, XSS, path traversal	~3,500
`emerging-web_client.rules`	Attacks from web clients — browser exploits, malicious JavaScript	~2,000
`emerging-policy.rules`	Policy violations — P2P, anonymisers (Tor), known-bad countries	~1,000

The full ET Open deployment has 25,000+ rules. The operator who enables every category has 25,000 signatures evaluated against every packet — at the cost of CPU and memory.

Choosing categories that match the threat model

The choice of categories should follow the threat model of the network:

A network serving web applications — enable emerging-web_server (attacks against the web apps), emerging-exploit (CVEs against the web stack), emerging-dns (C2 callbacks), emerging-malware (uploads of malware via HTTP).
A network with internal hosts — enable emerging-botcc (botnet C2 from compromised hosts), emerging-compromised (reputation-based blocking), emerging-trojan (RATs and backdoors), emerging-attack_response (responses to attacks).
A network with regulated compliance (PCI-DSS) — enable the above plus emerging-policy (anonymisers, P2P).
A research or lab network — enable everything because the operator wants visibility into all traffic.

The discipline: choose based on what the network does and what threats it faces, not based on what is available.

Starting narrow and growing

The recommended deployment pattern:

Start with the foundational categories — emerging-attack_response, emerging-botcc, emerging-dns, emerging-malware, emerging-trojan. This is roughly 11,000 rules — meaningful coverage without overwhelming the operator.
Run for one week in IDS mode. Observe the alert volume in the GUI and the EVE log. Triage the alerts into true positives, false positives, and unknown.
Tune the false positives — disable the rules that produce false positives the operator cannot accept. The GUI per-rule toggle is in Services → Intrusion Detection → Rules → click on a rule.
Add categories based on gaps — if the operator sees attacks that should have fired on emerging-exploit rules, enable that category. If the network starts hosting web apps, enable emerging-web_server.
Re-tune after each addition — every rule addition produces new false positives. Repeat the tuning cycle.

Read-only / Saferule category sizes— The full ET Open ruleset is ~2,861 rules in this snapshot. Different snapshots have different counts as ET adds and removes rules. The malware category (417 rules) is small but high-value — every rule is a known-malware pattern. The exploit category (412 rules) is also small but high-value. The web categories (378 + 312) are larger and noisier. The operator who enables the high-value categories first and the noisier categories later is following the discipline. The total count is what Suricata reports in configctl suricata status.

$ ls -la /usr/local/etc/suricata/rules/ | head -20; echo '---'; wc -l /usr/local/etc/suricata/rules/emerging-*.rules | tail -15

-rw-r--r--  1 root  wheel  12845 Aug 14 12:34 emerging-attack_response.rules
-rw-r--r--  1 root  wheel   7823 Aug 14 12:34 emerging-botcc.portgrouped.rules
-rw-r--r--  1 root  wheel   4521 Aug 14 12:34 emerging-botcc.rules
-rw-r--r--  1 root  wheel   3214 Aug 14 12:34 emerging-compromised.rules
-rw-r--r--  1 root  wheel   9123 Aug 14 12:34 emerging-dns.rules
-rw-r--r--  1 root  wheel  18234 Aug 14 12:34 emerging-exploit.rules
-rw-r--r--  1 root  wheel   1290 Aug 14 12:34 emerging-malware.rules
-rw-r--r--  1 root  wheel   1982 Aug 14 12:34 emerging-mobile_malware.rules
-rw-r--r--  1 root  wheel  11342 Aug 14 12:34 emerging-scan.rules
-rw-r--r--  1 root  wheel   5823 Aug 14 12:34 emerging-trojan.rules
-rw-r--r--  1 root  wheel  12834 Aug 14 12:34 emerging-web_client.rules
-rw-r--r--  1 root  wheel  16234 Aug 14 12:34 emerging-web_server.rules
---
 247 emerging-attack_response.rules
 178 emerging-botcc.portgrouped.rules
 103 emerging-botcc.rules
  87 emerging-compromised.rules
 234 emerging-dns.rules
 412 emerging-exploit.rules
 417 emerging-malware.rules
   89 emerging-mobile_malware.rules
 256 emerging-scan.rules
 148 emerging-trojan.rules
 312 emerging-web_client.rules
 378 emerging-web_server.rules
2861 total

Illustrative output

Custom rules

OPNsense lets the operator write custom rules through Services → Intrusion Detection → Rules → Custom rules. The custom rules file lives at /usr/local/etc/suricata/rules/custom.rules and is loaded alongside the ET Open rules.

A custom rule example:

alert http any any -> $HOME_NET any (msg:"CUSTOM my-org login attempt"; flow:established,to_server; http.uri; content:"/admin/login"; sid:1000001; rev:1;)

The custom rule:

Fires on HTTP requests to /admin/login on any host in the operator’s network.
Logs an alert with the operator’s message.
Has sid 1000001 (the convention is to use a high number to avoid colliding with ET’s sids, which are typically < 3,000,000).

The discipline for custom rules:

Use a clear msg that identifies the rule as custom (the “CUSTOM” prefix).
Use a high sid range to avoid collisions.
Test the rule by sending the expected traffic and verifying the alert fires.
Document why the rule exists in a comment (Suricata supports # comments).

How Suricata loads and evaluates multiple rulesets

When Suricata loads the ruleset, it reads every rule from every file in the rules directory. The files are merged into a single in-memory representation; the operator does not see which file a rule came from when looking at the alert — the alert shows the sid and msg, not the file.

The evaluation order is determined by the rule’s header (action, protocol, source, destination) and the multi-pattern optimiser, not by the order in the file. A rule in custom.rules and a rule in emerging-malware.rules with the same sid will conflict — Suricata loads one and ignores the other, with a warning at startup. The convention of high sids for custom rules prevents this.

The implication: custom rules are first-class citizens in the rule set, evaluated alongside the ET rules. The operator’s custom rules are not “less real” than the ET rules; they are equally part of the detection engine.

The failure modes

A too-broad or poorly-tuned rule set produces:

Alert fatigue. Thousands of alerts per day, of which the operator can triage only dozens. The real threats are buried in the noise. The discipline: tune aggressively; disable rules that produce false positives the operator cannot accept.
CPU saturation. A rule set of 50,000 rules is more expensive than a set of 10,000. The detection thread saturates; packet drops appear. The discipline: tune before scaling the rule set.
False-positive blocking in IPS mode. A signature that fires on legitimate traffic in IPS mode breaks customer-facing services. The discipline: tune in IDS mode first; only switch to IPS when the false-positive rate is acceptable.

Summary

ET Open is free and community-maintained; ET Pro is paid and Proofpoint-curated. Start with ET Open.
The categories cover attack response, botnet C2, compromised hosts, DNS attacks, exploits, malware, mobile malware, scans, trojans, web attacks, and policy violations.
Choose categories that match the threat model. Start narrow (5,000–10,000 rules), grow based on observed gaps.
Custom rules are first-class citizens; use a high sid range and a “CUSTOM” prefix.
The failure modes of too-broad rulesets: alert fatigue, CPU saturation, false-positive blocking in IPS.