Writing Suricata and Snort Rules
When to Use
- You need to author IDS rules to detect C2 traffic, malware downloads, or exploit attempts from
observed network indicators.
- You want to validate rule syntax and avoid the patterns that cause false positives or silent
non-matching.
Do not use broad content matches on common substrings that will flood alerts — anchor with
flow direction, ports, offsets, and uniqueness. This skill builds and lints rules; deploy them
through your IDS change process.
Prerequisites
- The indicators to detect (URI, host header, TLS SNI/JA3, byte pattern) and a target IDS
(Suricata or Snort).
Workflow
Step 1: Draft the rule
Choose action, protocol, addresses/ports, direction, and a unique msg, sid, and rev. Add
content/pcre matches anchored with http.uri, tls.sni, flow:established,to_server, and
offsets/depths.
Step 2: Lint the rule
python scripts/analyst.py lint rules.rules
Checks for required fields (msg, sid, rev, classtype), balanced quotes/parentheses,
non-anchored overly short content, and duplicate SIDs.
Step 3: Tune to reduce noise
Add threshold/detection_filter, flowbits, and specific buffers (http.host, dns.query)
to scope matches.
Step 4: Document and stage
Record what each rule detects and stage it for testing against a pcap before production.
Validation
- Every rule has
msg, a unique sid, and a rev.
content matches are anchored (buffer/offset/flow) rather than free-floating short strings.
- Rules parse without unbalanced quotes/parentheses.
Pitfalls
- Free-floating
content:"GET" style matches creating massive false positives.
- Duplicate or reused SIDs causing rule-load conflicts.
- Forgetting
flow:established and matching on unrelated traffic directions.
References