A Snort 3 rule consists of a header and options. Compared to Snort 2, some keyword positions and syntax have changed.

action proto src_ip src_port direction dst_ip dst_port (options;)

# Example
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (
    msg:"My Custom Rule";
    flow:to_server,established;
    content:"/attack", depth 20, fast_pattern;
    service:http;
    sid:1000001; rev:1;
)

• action: alert, drop, block, pass, log, rewrite
• proto: tcp, udp, icmp, ip, http, dns, smb, etc.
• direction: -> (unidirectional) or <> (bidirectional)
• Options must be wrapped in parentheses ( ) and each item separated by ;
• gid, sid, rev must always appear at the end of the options block

Local rule SIDs must be 1,000,000 or higher. Conflicting with the Talos-managed SID range can cause rules to be overwritten.

• 1 – 999,999: Reserved for official Snort/Talos rules — do not use
• 1,000,000 – 1,999,999: Recommended range for local/custom rules
• 2,000,000+: Third-party rulesets or additional local rules
• If duplicate SIDs exist in FMC, the last loaded rule takes effect
• rev: is optional, but always increment by 1 when modifying a rule

sid:1000001; rev:1;   # ✓ correct — local rule range
sid:1001;             # ✗ dangerous — reserved by Talos

Rules without flow are evaluated against every packet, causing severe performance impact. Nearly every rule should specify flow.

# TCP traffic to server (web attack detection, etc.)
flow:to_server,established;

# TCP traffic from server (response detection)
flow:from_server,established;

# Bidirectional without connection tracking
flow:stateless;

# UDP (no established state)
flow:to_server;

• to_server / from_server: restrict traffic direction
• established: inspect only packets after TCP 3-way handshake — major performance gain
• not_established: detect initial connection packets (SYN scans, etc.)
• no_stream: inspect individual packets before reassembly

In Snort 3, content modifiers are inline — they are not written as separate options like in Snort 2.

# Snort 2 style (incorrect for Snort 3)
content:"/admin"; depth:20; nocase; distance:0;

# Snort 3 correct style — modifiers inline
content:"/admin", depth 20, nocase, distance 0;

# Hex pattern (binary protocol detection)
content:"|0d 0a 0d 0a|";

# fast_pattern — designate the most unique pattern among multiple contents
content:"X-Trigger-Pattern", fast_pattern;
content:"/other", distance 0;

• Content patterns shorter than 4 characters increase false positives and hurt performance — use at least 4 characters
• With multiple content options, assign fast_pattern to the longest and most unique pattern
• nocase enables case-insensitive matching — has a performance cost, use only when necessary
• Limiting search range with depth/offset improves performance
• Negated content: content:!"unwanted" — matches only when the pattern is absent

In Snort 3, HTTP inspection uses sticky buffers. The buffer keyword must be placed immediately before content or pcre.

# URI-based detection
http_uri; content:"/cgi-bin/.%2e/", fast_pattern;

# HTTP header inspection
http_header; content:"Host: malicious.com";

# POST body inspection
http_client_body; content:"payload=exploit";

# HTTP method restriction
http_method; content:"POST";

# Status code detection (response detection)
http_stat_code; content:"200";

# service keyword required — activates the HTTP inspector
service:http;

PCRE is powerful but has very high CPU cost. Always precede PCRE with a content anchor to reduce evaluation frequency.

# ✗ Bad — PCRE alone with no content anchor (applied to every packet)
pcre:"/union\s+select/i";

# ✓ Good — pre-filter with content, then PCRE
content:"union", fast_pattern, nocase;
pcre:"/union\s+select\s+/i";

# HTTP URI PCRE (Snort 3 sticky buffer style)
http_uri; pcre:"/\/\.\.\/etc\/passwd/i";

# Snort 2 HTTP flags → Snort 3 conversion
# ✗ Snort 2: pcre:"/pattern/Ui"  (U = http_uri, i = case-insensitive)
# ✓ Snort 3: http_uri; pcre:"/pattern/i"

• Snort 2 uppercase HTTP flags (U, I, H, D, P, C, M, S, Y, K) → all replaced by sticky buffers in Snort 3
• Lowercase flags (i, s, m, x) — standard PCRE flags, unchanged
• Using fast_pattern alongside PCRE dramatically reduces the number of PCRE evaluations
• Patterns with heavy backtracking (e.g. .*, .+) risk ReDoS

Snort 2's flowbits is replaced by xbits in Snort 3. xbits provides host-based state tracking with finer-grained control.

# Snort 2 (flowbits)
flowbits:set,malware.stage1;
flowbits:isset,malware.stage1;

# Snort 3 (xbits) — track clause is required
xbits:set,malware.stage1,track ip_src;
xbits:isset,malware.stage1,track ip_src;
xbits:unset,malware.stage1,track ip_src;

# expire recommended — prevents memory leaks
xbits:set,malware.stage1,track ip_src,expire 3600;

# Rule 1: detect stage 1 and set bit
alert tcp ... (content:"stage1"; xbits:set,attack.stage1,track ip_src,expire 60; sid:1000001;)

# Rule 2: detect stage 2 only from IPs with bit set
alert tcp ... (xbits:isset,attack.stage1,track ip_src; content:"stage2"; sid:1000002;)

• Choose between track ip_src, track ip_dst, or track ip_pair
• Without expire, a default timeout applies — always set it explicitly
• flowbits:noalert → use the standalone noalert; option in Snort 3
• flowbits:reset → no equivalent in Snort 3 (removed)

service declares which application-layer protocol the rule targets. This ensures Snort 3's inspector is correctly invoked to parse HTTP, DNS, and other protocols.

service:http;           # Activate HTTP inspector (required when using sticky buffers)
service:https;          # HTTPS (HTTP inspection after TLS decryption)
service:dns;            # DNS inspector
service:smtp;           # SMTP inspector
service:ftp;            # FTP inspector
service:ssh;            # SSH
service:http,dns;       # Multiple services can be specified

• HTTP sticky buffers (http_uri, http_header, etc.) may not function without service:http
• Snort 2's metadata:service http → replaced by the standalone service:http option in Snort 3
• Works based on automatic traffic classification (AppID), not port numbers

Snort 2's threshold has been removed in Snort 3. Use detection_filter for inline rate limiting.

# Snort 2 (threshold — removed in Snort 3)
threshold: type limit, track by_src, count 5, seconds 60;

# Snort 3 (detection_filter — inline as a rule option)
detection_filter:track by_src, count 5, seconds 60;

# Example: alert if same source triggers 5+ times within 60 seconds
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (
    msg:"Brute Force Attempt";
    flow:to_server,established;
    content:"POST /login", fast_pattern;
    service:http;
    detection_filter:track by_src, count 5, seconds 60;
    sid:1000010; rev:1;
)

• track by_src: based on source IP; track by_dst: based on destination IP
• Global event filters are configured via the event_filter module in snort.lua

The following Snort 2 keywords have been removed or changed in Snort 3. Rules containing these keywords will fail to load or behave incorrectly.

Rules to follow when uploading local rule files to Cisco FMC (Firepower Management Center).

• File naming: Must start with a letter or underscore (_); only letters, digits, ., _, -, + are allowed (no spaces, non-ASCII, or special characters)
• File extension: .rules or .txt
• No duplicate SIDs: Conflicting SIDs across rulesets will cause errors — always use 1,000,000 or higher
• GID: Local rules use GID 1 (write gid:1; explicitly or omit it)
• Policy deployment: After uploading, enable the rules in the Intrusion Policy, then Deploy
• Check Snort version: FTD version determines whether Snort 2 or Snort 3 engine is used — verify in FMC > Devices
• Test environment: Always validate rule behavior in a test environment before production deployment

# Valid filename examples
snort3_local_rules_20260408.rules   ✓
local_rules_v2.rules                ✓
my rules.rules                      ✗ (spaces not allowed)
한글룰.rules                        ✗ (non-ASCII not allowed)
123rules.rules                      ✗ (cannot start with a digit)

As the number of local rules grows, the performance impact increases. Following these guidelines ensures both detection accuracy and performance.

• Always use flow: Use flow:to_server,established to narrow the scope of packets evaluated
• Avoid short content patterns: Patterns of 3 characters or fewer increase false positives and hurt performance
• Assign fast_pattern: Explicitly set it on the most unique pattern in multi-content rules
• Always anchor PCRE with content: Never use PCRE alone
• Use dsize: Limit payload size to skip unnecessary inspections
• Specify ports: Use actual service ports (e.g. $HTTP_PORTS) instead of any
• Set classtype: Helps with alert priority management and classification filtering

# ✓ Optimized rule example
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (
    msg:"ET WEB Possible SQL Injection";
    flow:to_server,established;          # direction + state restriction
    http_uri;                            # HTTP URI sticky buffer
    content:"UNION", fast_pattern, nocase;  # most unique pattern + fast_pattern
    content:"SELECT", distance 0, nocase;
    pcre:"/union\s+select/i";            # PCRE after content pre-filter
    dsize:>10;                           # payload size filter
    service:http;
    classtype:web-application-attack;
    sid:1000020; rev:1;
)