Writing and Loading Rules

Rules tell Snort what network conditions are significant and what action to take when they are detected.

Rule structure

Every rule follows this format:

action proto source dir dest ( body )

Field	Description
`action`	What Snort does when the rule fires: `alert`, `block`, `drop`, `pass`, `reject`, etc.
`proto`	Protocol: `ip`, `icmp`, `tcp`, `udp`, or a service name like `http`
`source`	Sending IP address and port. Use `any` as a wildcard.
`dir`	Direction: `->` (unidirectional) or `<>` (bidirectional)
`dest`	Receiving IP address and port.
`body`	Detection options and metadata inside parentheses.

Basic example

alert tcp any any -> 192.168.1.1 80 ( msg:"A ha!"; content:"attack"; sid:1; )

This fires on any TCP packet to 192.168.1.1:80 that contains the string attack.

Port-based vs service-based rules

Snort 3 supports two rule styles that differ in how traffic matching works.

Port-based
Service-based

The protocol and ports in the rule header are always evaluated:

# All header fields (proto, source, dest, ports) are checked
alert tcp any 90 -> any 5321 ( msg:"Port group rule"; )

Port-based rules are grouped into multipattern search engines keyed on protocol and port.

Header evaluation is skipped once the service is identified on the flow. A rule becomes service-based when:

A service IPS option appears in the rule body
A service-specific option is present (e.g., http_uri, file_data, dnp3_data)
A service protocol appears in the rule header

# Service protocol in header — port 90 has no effect
alert http
(
    msg:"Gotcha!";
    flow:established, to_server;
    http_uri:"attack";
    sid:2;
)

# service option puts the rule in both SMTP and port groups.
# When SMTP is identified on the flow, port 90 is not checked.
alert tcp any 90 -> any any ( service:smtp; msg:"SMTP and port group"; )

To match a service-based rule against a specific IP protocol, use the ip_proto IPS option:

alert ip ( ip_proto:2; content:"foo"; service:igmp; )

This guards against false positives from the rule also appearing in the “any” port group.

Common rule options

Identification options

Option	Description
`msg`	Human-readable description of the alert
`sid`	Signature ID (unique within a GID)
`gid`	Generator ID. Text rules default to GID 1; SO rules to GID 3
`rev`	Revision number of the rule

Flow and detection options

Option	Description
`flow`	Constrain to flow state, e.g. `established, to_server`
`content`	Match a literal byte string
`nocase`	Make the preceding content match case-insensitive
`fast_pattern`	Mark this content as the fast pattern for the rule
`pcre`	Match a Perl-compatible regular expression
`http_uri`	Match in the HTTP URI buffer
`file_data`	Match in the file data buffer
`pkt_data`	Match in raw packet/TCP stream bytes

Metadata options

Option	Description
`classtype`	Alert classification (maps to a priority)
`reference`	External vulnerability reference, e.g. `reference:cve,2023-1234`
`service`	Force assignment to a service group
`metadata`	Arbitrary key-value pairs

Rule identification: gid:sid:rev

Rules are uniquely identified by the triplet gid:sid:rev.

GID 1 — text rules (the default)
GID 3 — shared-object (SO) rules
GID 1xx — internal Snort components (decoder is GID 116, etc.)

To list all internal GIDs and their built-in SIDs:

snort --list-gids
snort --list-builtin

Rule comments

Snort rules files support several commenting styles:

# Single-line comment

#begin
Every line in here is ignored by the rule parser.
#end

alert tcp any any -> any any ( msg:"test"; rem:"this is an inline comment"; sid:999; )

/* C-style block comment */

Fast patterns and rule groups

At startup, Snort compiles rules into multipattern search engines (MPSE). Rules are grouped by protocol, port, and service so that a single parallel search covers all patterns in a group.

Selecting the search algorithm

Configure via search_engine.search_method:

Method	Trade-off
`ac_bnfa`	Default. Balanced speed and memory.
`ac_full`	Fastest search, significantly more memory.
Hyperscan	Best performance and reasonable memory. Requires Intel Hyperscan library.

Fast pattern selection

Snort automatically selects the longest content in a rule as its fast pattern. Add fast_pattern explicitly to override this choice:

alert tcp any any -> any any
(
    msg:"Targeted pattern";
    content:"common";             -- long but matches frequently
    content:"rare_marker"; fast_pattern;  -- short but highly specific
    sid:100;
)

Snort 3 automatically skips the fast pattern re-check during rule evaluation when it is redundant. You do not need the old fast_pattern:only Snort 2 option.

Certain contents are not eligible for fast pattern selection:

Negated contents that are also relative, case-sensitive, or have a non-zero offset/depth.

Rule group summary

At startup, Snort prints a summary under port rule counts and service rule counts. Use this to verify that rules land in the expected groups.

Stateful evaluation

When a match spans multiple packets (e.g., a file transferred over TCP), Snort pauses rule evaluation at the packet boundary and resumes when more data arrives. This is supported for:

Buffer	Description
`pkt_data`	Contiguous TCP session bytes, split by direction (client→server, server→client)
`file_data`	Bytes from the same file transfer, across packets

Loading rules

ips.include in the config file

ips =
{
    include = 'rules.txt',          -- path to your rules file
    variables = default_variables   -- makes $HOME_NET etc. available
}

Rules files can themselves contain include statements to pull in additional files.

-R on the command line

snort -c snort.lua -R cool.rules

You can combine -R with ips.include; both sets of rules are loaded.

Inline with --lua

# Enable built-in decoder and inspector rules
snort -c snort.lua --lua 'ips = { enable_builtin_rules = true }'

From stdin

Pass rules through standard input using the --stdin-rules flag:

cat local.rules | snort -c snort.lua --stdin-rules

You can only specify one ips.include file directly, but that file can include others. Use the -R flag for additional top-level files.

Get Started

Configuration

Inspectors & Detection

Running Snort

Migration from Snort 2

Writing and Loading Rules

Rule structure

Basic example

Port-based vs service-based rules

Common rule options

Rule identification: gid:sid:rev

Rule comments

Fast patterns and rule groups

Selecting the search algorithm

Fast pattern selection

Rule group summary

Stateful evaluation

Loading rules

Build docs developers (and LLMs) love

Get Started

Configuration

Inspectors & Detection

Running Snort

Migration from Snort 2

​Rule structure

​Basic example

​Port-based vs service-based rules

​Common rule options

​Rule identification: gid:sid:rev

​Rule comments

​Fast patterns and rule groups

​Selecting the search algorithm

​Fast pattern selection

​Rule group summary

​Stateful evaluation

​Loading rules

Build docs developers (and LLMs) love

Rule structure

Basic example

Port-based vs service-based rules

Common rule options

Rule identification: gid:sid:rev

Rule comments

Fast patterns and rule groups

Selecting the search algorithm

Fast pattern selection

Rule group summary

Stateful evaluation

Loading rules