Snort Rules: Syntax, Examples, and Where They Still Fit

Snort rules are detection signatures that tell the Snort intrusion detection and prevention engine which network traffic to inspect and what to do when a packet matches. A traditional rule has a header that sets the action, protocol, addresses, ports, and direction, and an options section that holds the conditions the traffic has to meet before the rule fires.

The header-plus-options model has held since Snort's early releases, but Snort 3 changed much of the syntax and the engine around it. Cisco Talos announced on October 21, 2026, that every open-source Snort 2 version has reached end of life and will get no further rule support, alongside the release of Snort 3.12.4.0. Open-source deployments still on Snort 2 now run an engine Talos no longer supports.

Attacks have moved as well. 82% of CrowdStrike detections in 2025 were malware-free, as adversaries moved through valid credentials, trusted identity flows, and approved SaaS integrations. Those intrusions still cross networks, but the record of what the attacker did increasingly sits in identity, SaaS, and cloud audit logs that a packet signature can't read.

TL;DR:

• A Snort rule is a header that scopes the traffic plus parenthesized options that define what has to match, and Snort 3 adds service rules and file rules that drop the addresses and ports entirely.
• Open-source Snort 2 is end of life, so new rules and migrations belong on Snort 3.
• Snort rules do real work on OT segments, at single inline choke points, and where a compliance control names network intrusion detection.
• Network signatures rarely reveal cloud control plane abuse, SaaS session hijacking, or identity attacks, where a growing share of intrusions now land.
• The practical call is to keep Snort narrow, replace blanket signature coverage with targeted rules and protocol logs, and retire duplicate rules only after testing that the remaining controls hold.

How a Snort Rule Is Structured

A Snort rule has two parts. The rule header is everything up to the first parenthesis, and the body is everything inside the parentheses. Snort evaluates the header first to decide whether a packet is even a candidate, then checks the options, and the rule's action fires only when every option is true.

The Rule Header

A traditional header reads left to right as action, protocol, source address, source port, direction, destination address, and destination port:

‍

Snort 3 supports eight rule actions: alert, block, drop, log, and pass, plus the active responses react, reject, and rewrite. Drop discards the current packet and block discards the rest of the flow, and both need Snort running inline. The <> operator matches traffic in both directions, and variables such as $HOME_NET come from the Snort configuration, letting a rule follow the network definition as it changes.

Rule Options

Each rule option ends with a semicolon, and Snort groups the options by purpose:

• General options mostly describe the rule: msg for the alert text, sid and rev for the rule ID and revision, classtype for the category and default priority, and reference for a CVE or advisory. The exception is service, which does affect matching: a rule applies when either the traffic's detected service or the header ports match.
• Payload options inspect the data itself: content for a byte or string match, pcre for a regular expression, and modifiers such as nocase, offset, depth, distance, and within that control where a match can occur.
• Non-payload options check packet and session properties such as flow, TCP flags, and ICMP type.
• Post-detection options govern what happens once the other options match, including detection_filter. Snort evaluates it last, and it holds back the event until a source exceeds a set match rate.

Two conventions matter in practice. Snort reserves sid values below 1,000,000 for official rules, so local rules should start at 1,000,000 to avoid collisions. And in Snort 3, most HTTP options are sticky buffers: http_uri; points every following content match at the URI until another buffer is set, where Snort 2 used per-match modifiers.

An Annotated Example

A complete rule, followed by each of its parts:

alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"Repeated SSH connection attempts"; flow:established,to_server; content:"SSH",nocase,offset 0,depth 4; detection_filter:track by_src,count 30,seconds 60; sid:1000001; rev:1;)


• alert tcp $EXTERNAL_NET any -> $HOME_NET 22 is the header: alert on TCP traffic from any external address and port to SSH on internal hosts.
• flow:established,to_server limits matching to established sessions, client to server.
• content:"SSH",nocase,offset 0,depth 4 looks for the SSH identification string in the first four bytes of the payload.
• detection_filter:track by_src,count 30,seconds 60 holds the event until a single source has matched more than 30 times in 60 seconds.
• sid:1000001; rev:1 gives the rule a local ID and its first revision.

The options mirror the documented SSH example for detection_filter. Treat the rule as a connection-rate signal: the SSH identification string travels in plaintext before encryption starts. The rule therefore counts connections from a source, and failed logins show up in the SSH server's authentication logs.

Service Rules and File Rules in Snort 3

Snort 3 added header forms that skip addresses and ports. A service rule has only an action and an application service, such as alert http, and it fires on HTTP traffic wherever Snort's service detection finds it, on any port. File rules use alert file and match files carried over HTTP, SMTP, POP3, IMAP, SMB, and FTP. Both forms suit detections that care about what the traffic is more than where it travels.

Snort Rule Examples

The rules below are written for Snort 3, use local sids, and are starting points to adapt before they touch production traffic.

Inbound Ping From Outside the Network

A simple non-payload rule that flags ICMP echo requests (type 8) from external hosts, useful as a reconnaissance signal on networks that shouldn't answer pings:

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP echo request from external host"; itype:8; classtype:attempted-recon; sid:1000002; rev:1;)


Web Shell Command in a URI

A service rule adapted from the Snort documentation's own example. It matches requests to admin.php whose cmd= parameter contains a semicolon, a common way to chain commands:

alert http (msg:"Possible web shell cmd parameter"; flow:to_server,established; http_uri; content:"/admin.php",fast_pattern,nocase; content:"cmd=",nocase; pcre:"/[?&]cmd=[^&]*?\x3b/i"; sid:1000003; rev:1;)


Repeated WordPress Login POSTs

A service rule that combines the http_method and http_uri buffers with a rate threshold, firing once a single source sends more than 10 login POSTs in 60 seconds. WordPress posts password resets and other actions to the same wp-login.php file, so those count too. Treat a hit as possible brute force, since the rule can't confirm failed logins:

alert http (msg:"Repeated WordPress wp-login.php POSTs, possible brute force"; flow:to_server,established; http_method; content:"POST"; http_uri; content:"/wp-login.php",fast_pattern,nocase; detection_filter:track by_src,count 10,seconds 60; classtype:attempted-user; sid:1000004; rev:1;)


Modbus Write From an Unexpected Host

An OT rule using Snort 3's Modbus inspector. Here 192.168.10.5 stands in for the authorized engineering workstation, and a Write Single Coil command from any other source fires:

alert tcp !192.168.10.5 any -> 192.168.20.0/24 502 (msg:"Modbus Write Single Coil from non-engineering host"; flow:to_server,established; modbus_func:write_single_coil; service:modbus; classtype:policy-violation; sid:1000005; rev:1;)


DNP3 Direct Operate From an Unexpected Host

The same pattern for DNP3, where a Direct Operate command from anything other than the authorized master is worth an alert:

alert tcp !192.168.10.5 any -> 192.168.20.0/24 20000 (msg:"DNP3 Direct Operate from unauthorized host"; flow:to_server,established; dnp3_func:direct_operate; service:dnp3; classtype:policy-violation; sid:1000006; rev:1;)


The Modbus and DNP3 rules only work when the matching inspectors and binder entries are configured in snort.lua for the monitored traffic, so confirm that configuration first. To test any rule offline, Snort can load a rules file with -R, replay a packet capture with -r, and print each alert with the packet that triggered it using -A cmg.

Where Snort Rule Sets Come From

Most deployments run a vendor rule set and add local rules on top, and Talos publishes three official rule sets. The Community rule set is free, GPLv2-licensed, updated daily, and a subset of the full set. The Registered rule set is free with an account but runs 30 days behind, and the Subscriber rule set carries every rule without delay, listed at $399 per sensor per year for business use as of October 2026.

Outside Talos, Proofpoint's Emerging Threats Open rule set is the other widely used free source, published in Snort and Suricata builds.

On Cisco Secure Firewall, the rule set arrives through managed base policies that trade coverage against false positives. Cisco's Connectivity over Security policy runs roughly 600 active rules, Balanced about 10,000, and Security over Connectivity about 23,000, so the policy choice largely decides how many rules someone has to own. Snort 3 has been the default for new FTD deployments since version 7.0, and Cisco deprecated Snort 2 for devices upgrading to 7.7 and later.

Where Snort Rules Still Earn Their Place

Network signatures remain the right detection layer where endpoint agents can't run, where traffic stays readable, where a control explicitly asks for network intrusion detection, or where cost rules out heavier tooling.

OT and Industrial Segments

PLCs and distributed control systems often can't run endpoint protection, and some have no anti-malware option. Network monitoring can fill that gap, and some IDS vendors ship signatures for OT protocols such as Modbus and DNP3.

Snort 3 includes ICS protocol inspectors for Modbus, DNP3, IEC 104, MMS, ENIP/CIP, and S7CommPlus, and rules can match on function codes like the write commands above. Much of this traffic also travels unencrypted, so payload matching often works here, while on IT networks most web payloads are encrypted.

Single Inline Choke Points

Where all traffic crosses one ingress and egress point and the requirement is to block on match, Snort inline does the job directly, and a single choke point is the natural home for the block and drop actions.

Compliance-Driven Monitoring

Some controls name network intrusion detection outright. PCI DSS v4.0.1, the current version, requires intrusion-detection or intrusion-prevention techniques at the perimeter and critical points of the cardholder data environment under Requirement 11.5.1, with engines and signatures kept up to date.

For the electric sector, NERC CIP-005-7 requires methods for detecting malicious communications at the access points of high-impact systems and medium-impact control centers. CIP-015-1 adds internal network security monitoring, with initial obligations for control center environments starting October 1, 2028, and CIP-015-2, approved by FERC in August 2026, phases in a wider scope from October 1, 2029. A properly scoped and maintained Snort deployment can support these monitoring requirements, though compliance also depends on coverage, alert handling, documentation, and the rest of each standard.

Budget-Constrained and MSSP Edge Sensors

The free Community and Emerging Threats Open rule sets, plus per-sensor subscription pricing, keep a small Snort footprint inexpensive for a lean team or a managed provider running edge sensors across many clients.

These cases are real but narrow. None of them makes Snort the primary detection layer for a modern enterprise IT environment.

What Snort Rules Can't See

Snort rules are signatures, so they carry the usual trade-offs between signature and behavioral detection. They also have a constraint of their own: a rule can only match what crosses a sensor in a form it can read. The attacks that matter most to cloud-first organizations increasingly fail both tests, and no amount of tuning closes a gap in what the sensor sees.

The incident data shows why. Red Canary's 2026 report ranks Cloud Accounts first among the techniques it detected, with identity threats accounting for more than half of its confirmed threats after a sharp year-over-year rise in detections. Voice phishing rose to second place among initial infection vectors in Mandiant's 2025 investigations. In both patterns, the attacker's follow-on actions land in identity, SaaS, and cloud audit logs.

Cloud Control Plane Activity

An attacker who calls AssumeRole with stolen keys usually does it from infrastructure they control, so the request rarely crosses the customer's sensor. Even when it does, the sensor sees a TLS session to an AWS address and nothing of the IAM abuse behind it. The evidence lives in CloudTrail, Azure Activity Log, and GCP audit logs, which is why cloud security monitoring starts there.

Identity and SaaS Attacks

Adversary-in-the-middle phishing services such as VoidProxy relay a victim's login through attacker-controlled infrastructure to the real Microsoft or Google sign-in, capturing credentials and session cookies in real time. Microsoft's 2026 Digital Defense Report puts adversary-in-the-middle at 44.6% of identified phishing techniques. Phishing domains and that infrastructure can yield network indicators, but encryption hides the authentication itself, and the account takeover typically becomes clear in identity provider logs. Token theft, OAuth consent abuse, and MFA manipulation show up there too, the territory of identity threat detection.

Encrypted Traffic

HTTPS covers most web traffic: since around 2020, 95-99% of Chrome page loads have used it, with some variation by platform. Without decryption, Snort reads network headers and the parts of the TLS handshake left in the clear, while the HTTP payload stays hidden, and under TLS 1.3 even the server certificate is encrypted.

How to Decide Which Snort Rules to Keep, Replace, or De-Scope

Many rule sets grow from a base policy plus years of local additions, with little pruning along the way. A rule is worth keeping when the incident it watches for still crosses the wire you're watching.

Start with hit data. Pull 12 months of rule firings from the management console or alert store, then separate rules that never fired, rules that fire mostly on benign traffic, and rules that catch activity another tool already alerts on. A silent rule needs a check before it goes: whether the attack remains relevant, whether the sensor sees the traffic, and whether the rule and its alert retention are configured correctly.

Each rule then lands in one of the decisions below, depending on where it runs and what else already covers the same activity:

‍

Keep Narrow

Choose the base policy by the environment's risk and availability requirements, validate it in detection mode before enabling prevention, and on Cisco Secure Firewall use the Recommended Rules feature to disable rules for vulnerabilities absent from the network. On OT segments, the protocols present set the floor: a Modbus and DNP3 network has little use for web application rules.

Replace Broad

Across general enterprise IT, keep the signatures that match real risks and add protocol logs, which often serve investigations better than more rules. Suricata, like Snort 3, detects protocols independent of port, and it writes structured EVE JSON.

Zeek records connection, DNS, HTTP, and TLS activity as investigation context. Detection for cloud, identity, and SaaS moves to the SIEM, where Sigma rules run against CloudTrail, Entra ID, and Okta logs and can be mapped to ATT&CK coverage that has actually been tested.

De-Scope

Overlapping alerts don't prove overlapping coverage, since another tool may differ in timing, prevention, or what it can see. Consider retiring a Snort rule that duplicates EDR or CASB coverage only after testing that the remaining controls preserve detection, response timing, and any blocking the rule provided. Keep network detection where the endpoint layer doesn't exist, such as printers, cameras, building systems, and VPNs and routers, which typically lack EDR telemetry.

The subscription is rarely the expensive part of a large rule set. The larger cost is the team's triage time on alerts from rules nobody has tuned, and the engineering hours spent maintaining signatures that no longer match where incidents happen. AI can speed up drafting, yet as with any AI-assisted detection engineering, a syntactically valid rule still has to be tested, tuned, and owned.

Detection Effort Belongs Where Incidents Land

A large Snort rule set can look like broad coverage while the intrusions that matter run through identity providers, cloud control planes, and SaaS sessions whose malicious steps rarely show up in a matchable payload. Pruning the rule set to the places where packets still tell the story frees the detection hours that cloud and identity logs need.

Daylight's security experts build custom detection rules on each customer's cloud, identity, and SaaS logs together with the customer's team, and the alerts those rules raise feed investigations that run through to a verdict.

Frequently Asked Questions About Snort Rules

Can Suricata Run Snort Rules?

Partly. The syntax is close and Suricata can load many Snort rules, but keywords and options differ between the engines. Suricata documents its differences from Snort against the Snort 2.9 branch, and Snort 3 has diverged further. Its service-rule syntax and Snort's shared object rules aren't directly portable, so a rule set moving between the engines needs retesting.

How Do You Get Snort to Inspect HTTPS Payloads?

Payload options such as content match only plaintext, so HTTPS inspection depends on decryption. The common approaches are a decrypting proxy or firewall in front of the sensor, or access to session keys inside a controlled enterprise environment, as NIST's TLS 1.3 visibility guidance describes. Either approach brings privacy, performance, and key management trade-offs, and teams often limit decryption to the traffic where payload inspection justifies it.

Can Snort Run in AWS or Azure?

Yes, but a cloud network doesn't hand a sensor its traffic by default. In AWS, VPC Traffic Mirroring copies traffic from network interfaces to inspection appliances, including fleets behind a load balancer. Azure's virtual network TAP mirrors traffic from VM network interfaces, though as of October 2026 it remains in public preview in select regions.

Mirroring adds cost and covers only the interfaces you configure, so teams typically mirror the subnets where payload inspection matters most and use mirror filters to drop traffic the rules don't need.

How Do You Convert Snort 2 Rules to Snort 3?

Snort 3 ships a converter, snort2lua, that translates Snort 2 rules into Snort 3 syntax and writes anything it can't convert to a reject file. Work through that file first, then replay the converted rules against packet captures before they replace the originals, since a rule can convert cleanly and still match differently in the new engine.

Where Are Snort 3 Rules Stored?

Production rules usually load through the ips table in snort.lua, as include lines that point at rules files, and --rule-path can load a whole directory from the command line. Keeping local rules in their own file means a vendor rule update doesn't overwrite them, and it keeps local sids easy to audit.