What Are Snort Rules? Types, Syntax, and Examples

Networks generate more activity than analysts can review packet by packet, so they use Snort rules to help them recognize traffic patterns that deserve attention.

Snort is an open-source network intrusion detection and prevention system (IDPS), with Its rules defining what the engine should look for and how to handle a match. Well-maintained rules can typically help teams:

• Spot recognizable threats: Detect traffic associated with a known attack technique or suspicious payload.
• Create actionable alerts: Provide a description and rule identifier that analysts can use during investigation.
• Enforce network controls: In a correctly configured inline deployment, drop or block matching traffic.

Rules have limits, though, as they only evaluate visible traffic. Broad conditions can create false positives, while encryption may hide content a rule needs to match. Effective detection requires testing and updates.

How Snort rules work

Snort compares network traffic against enabled rules, checking traffic scope and then specific match criteria. The basic process follows four steps:

1. Observe traffic: A Snort sensor receives packets from a monitored network path or interface.
2. Check the header: Snort considers the protocol, source, destination, ports, and traffic direction specified in the rule.
3. Evaluate rule options: Relevant packets are checked against additional conditions, such as a content pattern.
4. Apply the action: When the rule's matching criteria are satisfied, Snort alerts, logs, passes, or blocks traffic according to its configuration.

This is one way network traffic analysis (NTA) turns raw communications into information that security teams can investigate.

Key components of a Snort rule

A traditional Snort rule has two parts: a header and options enclosed in parentheses. The header sets the scope and action; the options add the details needed to recognize a match or describe the event. The main elements usually include:

• Action: The first keyword, such as alert, specifies what Snort should do when conditions match.
• Protocol: A value such as tcp, udp, or icmp identifies the traffic type.
• Source and destination: IP addresses, network variables, and port numbers define the endpoints being considered.
• Direction: The operator -> indicates the direction of traffic evaluated by the rule.
• Match options: Keywords such as content specify bytes or text to find in inspected data.
• Identification options: msg describes the event, sid gives the rule a unique signature ID, and rev tracks revisions.

Matching only a port or protocol may produce too many alerts, and precise conditions can improve relevance.

Common Snort rule actions

The action determines what happens when the rule matches. Snort 3 supports these five basic actions:

• Alert: Generate an alert for matching traffic.
• Log: Record the matching packet.
• Pass: Mark the packet as passed.
• Drop: Discard the matching packet.
• Block: Block the matching packet and subsequent packets in that flow.

Alert and log support visibility, while drop and block support prevention. Blocking requires a correctly positioned, configured inline sensor.

Snort rules examples and use cases

A simple example makes the structure easier to understand. The following test rule looks for a specific text marker in TCP traffic headed toward port 80 on the protected network.

Example of a Snort rule

alert tcp any any -> $HOME_NET 80 (msg:"Test pattern in TCP payload"; content:"demo-marker"; sid:1000001; rev:1;)

Here, alert tells Snort to generate an event when the rule matches. tcp identifies the protocol, any any allows any source address and port, and $HOME_NET 80 selects destinations in the configured home network on port 80. The content option looks for demo-marker in inspected data, while msg, sid, and rev describe and identify the rule.

This is a teaching example, not a malicious-traffic signature. The marker could appear in harmless traffic, and the rule doesn’t establish that a security incident occurred. Custom rule IDs should follow Snort's allocation guidance to avoid conflicts with distributed signatures.

Common use cases

Snort rules can support different kinds of network detection.

Known threat signatures

Match a recognizable network pattern associated with malware or exploit traffic, when that pattern is visible to the sensor.

Suspicious application requests

Flag an unusual request string or other packet content that warrants investigation.

Local monitoring needs

Write a custom rule for a specific traffic pattern found during troubleshooting, lab testing, or an internal investigation.

A match isn’t proof of compromise, as analysts can compare the event with indicators of compromise (IOCs) and other available evidence before deciding what it means.

How Snort rules fit into security operations

Snort rules are one layer of a broader detection program. They help identify activity at the network level, but analysts still need to validate alerts, determine impact, and decide whether to respond.

In detection engineering, teams create or adapt detection logic, test it against representative traffic, review false positives, and update rules as attacker behavior changes. Threat intelligence solutions can provide context about emerging indicators and techniques that inform those decisions.

Snort events can also contribute to security information and event management (SIEM), where analysts examine network alerts alongside endpoint, identity, and other event data. This wider perspective helps distinguish an isolated rule match from a sequence of suspicious activity.

Snort applies configured rules; network detection and response (NDR) may also use broader traffic analytics and investigation context. Network traffic analysis solutions address the wider challenge of understanding network activity.

Snort can flag traffic, but confirming and containing an incident requires additional investigation and action, with incident detection and response solutions able to address that broader operational challenge.