What are Snort rules?
Snort rules are the detection logic that powers Snort, an open-source intrusion detection and prevention system. Think of them as a set of instructions that tell Snort what to look for in network traffic. When Snort captures a network packet, it compares that packet against its ruleset to decide if the traffic is normal or suspicious.
These rules serve two main purposes. First, they detect known attack signatures—specific patterns that match documented exploits or malware. Second, they identify suspicious behaviors that might indicate a new or evolving threat, like unusual port scanning or abnormal protocol usage.
Cloud Attack Retrospective
In this report, we examine how threat actors approached cloud environments. We highlight eight commonly observed MITRE ATT&CK techniques and offer practical guidance on how Wiz can help to detect and mitigate them.
How Snort rules work
Snort captures network packets as they flow across your network. For each packet, Snort first filters by the rule header (protocol, ports, IP addresses) and then uses fast pattern matching engines like Aho-Corasick to evaluate applicable rules. Evaluation isn't a simple top-to-bottom file order—Snort groups rules by header fields and uses optimized pattern engines to check thousands of rules efficiently.
The process starts with a quick check of the rule header. This header contains basic information like the protocol type and IP addresses. If a packet doesn't match these basics, Snort moves on immediately. This keeps the system fast.
When a packet does match a rule's header, Snort digs deeper into the rule options. These options examine the packet's actual content—the data inside. If everything matches, Snort takes the action specified in the rule, like generating an alert or blocking the traffic entirely.
Snort operates in four common modes:
Sniffer mode: Displays live packets on screen
Packet logger mode: Saves packets to disk as pcap files
NIDS mode: Detects and alerts on threats in passive monitoring
Inline IPS mode: Prevents and blocks malicious traffic when deployed inline using NFQ (Netfilter Queue), AFPacket, or DAQ (Data Acquisition) modules
Anatomy of a Snort rule
Every Snort rule splits into two sections: the rule header and the rule options.
The rule header comes first and defines the basics. It tells Snort what action to take, which protocol to watch, and which network endpoints matter. Here's what each part means:
Action: What Snort should do when it finds a match. Common actions include alert (generate a warning), log (save the packet), pass (allow it through), drop (block it), and reject (block it and notify the sender)
Protocol: The network protocol to inspect—tcp, udp, icmp, or ip
Source and destination: The IP addresses and ports where traffic originates and where it's headed. You can specify exact IPs, network ranges, or use any for everything
Direction: The arrow -> means traffic flows from source to destination, while <> means bidirectional
The rule options section comes after the header, wrapped in parentheses. This is where you define the specific detection criteria. You'll use keywords like content to match strings, msg for alert text, sid for a unique rule ID, rev for rule revision tracking, classtype to categorize the threat (e.g., web-application-attack, trojan-activity), and reference or metadata fields to link to CVE numbers, vendor advisories, or internal ticket systems for traceability.
Here's a simple example that alerts when it sees the word "malicious" in web traffic:
alert tcp any any -> any 80 (msg:"Malicious content detected"; content:"malicious"; sid:1000001;)Types of Snort rules and when to use them
Snort rules fall into different categories based on what they're designed to catch.
Protocol rules focus on how network protocols should behave. They catch violations like malformed HTTP requests or invalid TCP flags. Use these when you need to enforce strict protocol standards and catch reconnaissance attempts.
Content rules inspect the actual data inside packets. These are your go-to for detecting known malware signatures, command-and-control traffic, or SQL injection attempts. They're the most common type because they catch specific, documented threats.
Preprocessor rules work with Snort's preprocessors. Preprocessors in Snort 2 (called inspectors in Snort 3) handle normalization, stream reassembly, and protocol parsing before rules evaluate packets. These components can generate their own alerts for protocol violations and enable rule buffers like http_uri, http_header, and file_data that let rules inspect specific protocol fields. This catches evasion techniques that span multiple packets, such as HTTP request smuggling or TCP fragmentation attacks.
You'll also encounter two detection approaches. Stateless rules examine each packet independently, while stateful rules track entire network sessions. Stateful detection catches attacks that unfold over time, like a slow port scan or a multi-stage exploit.
Get a personalized demo
In your 30 minute personal demo, you will learn how Wiz connects to your environment and gives complete visibility, maps out resources and reveals attack vectors, prioritizes critical risks using actionable insights
Get a demo
Common Snort rule use cases
Snort rules address a wide range of security threats across different attack vectors. Here are the most common scenarios where organizations deploy detection rules.
SQL injection detection
Rules in this category catch attempts to manipulate databases through web forms by identifying SQL keywords and command patterns in HTTP requests. These rules monitor for common injection techniques like UNION-based queries, boolean-based blind injection, and time-based attacks that target application databases.
Port scanning detection
These rules identify reconnaissance activity when attackers probe your network for open ports and available services. They track connection patterns from single source IPs attempting to reach multiple ports within short timeframes, helping you spot the early stages of an attack before exploitation begins.
Note: For production environments, the sfPortscan preprocessor (Snort 2) or port_scan inspector (Snort 3) provides more accurate scan detection by tracking connection states and distinguishing legitimate traffic from reconnaissance.
Malware communication
Command-and-control detection rules identify when compromised systems attempt to communicate with attacker infrastructure. These rules match known malware signatures, suspicious user-agent strings, and communication patterns that indicate an infected host calling home to its controller.
Data exfiltration
Rules designed to catch data theft monitor for unusually large file transfers, suspicious upload activity, and unauthorized data movement to external destinations. They help identify when attackers attempt to steal sensitive information after gaining initial access to your environment.
Web application attacks
These rules protect web applications from common exploits like directory traversal, cross-site scripting (XSS), and remote file inclusion. They examine HTTP requests for malicious patterns that attempt to access unauthorized files, inject client-side scripts, or manipulate application logic.
Best practices for writing and managing Snort rules
Creating effective Snort rules requires a methodical approach. Here's how to build and maintain a ruleset that protects without overwhelming your team.
Start with built-in rulesets. Don't write everything from scratch. Use the Snort Community Ruleset or the paid Snort Subscriber Ruleset from Cisco Talos. These professionally maintained collections cover most common threats and receive regular updates.
Optimize rule performance. Put your most specific detection criteria first in the rule options. If you're looking for a unique text string, place that content match early. Use the fast_pattern keyword to help Snort's pattern matcher work more efficiently.
Maintain clear documentation. Every custom rule needs a descriptive msg field and should reference external information like CVE numbers or internal ticket IDs. Link alerts to asset ownership and service metadata so findings route to the right team quickly—security teams shouldn't waste time hunting down who owns a flagged resource or what data it protects.
Test before deploying. Never push a new rule straight to production. Run it in a test environment first or deploy it in passive mode on a monitoring sensor. Verify it catches the intended threat without generating false positives or slowing down your network.
Update rules regularly. New threats emerge daily. Set up a schedule to pull the latest vendor rulesets—ideally daily or weekly. Review your custom rules quarterly to ensure they're still relevant.
Fine-tune to reduce false positives. Use suppression lists to ignore alerts from known-good traffic. Adjust detection thresholds based on your network's normal behavior. Use context like public exposure, asset criticality, and data sensitivity to suppress low-impact matches and focus on exploitable paths—a SQL injection alert against an internal dev database matters less than the same alert against a public-facing production database with customer PII.
Snort rules in modern cloud-native environments
Snort was built for traditional networks, and the cloud breaks many of its assumptions. The challenges start with encrypted traffic—when most enterprise traffic uses TLS/SSL, Snort can't inspect payloads without decryption, limiting it to metadata like IP addresses, SNI (Server Name Indication), and TLS handshake parameters. But the deeper problem is lack of context: signature-only detection doesn't know who owns the service, which identities can pivot laterally, whether sensitive data sits behind that endpoint, or if the resource is publicly exposed. Teams need visibility that correlates runtime behavior with configuration, identity, exposure, and data sensitivity to prioritize real risk.
Cloud workloads create another problem. Containers and serverless functions spin up and down in seconds. By the time Snort detects suspicious traffic from a container, that container might already be gone. Traditional network monitoring can't keep pace with this level of change.
The biggest blind spot is east-west traffic—communication between services inside your cloud environment. Most network intrusion detection systems sit at the perimeter and never see this internal traffic. Attackers who breach the perimeter can move laterally between services without triggering any alerts.
Cloud environments also use dynamic IP addresses assigned by the provider. Unless these IPs tie to known DNS entries, traditional external scanning misses them entirely. These become shadow assets that exist outside your security visibility.
The 13 Must-Follow Threat Intel Feeds
A threat intel feed, or threat intelligence feed, provides a continuous incoming flow of data related to cyber threats and risks.
En savoir plus
How Wiz Defend provides context-aware threat detection for cloud environments
Cloud security needs a different approach—one that understands how cloud resources connect and what they protect. Wiz Defend replaces signature-based detection with behavioral analytics designed for cloud-native architectures.
Wiz uses the Wiz Security Graph to correlate runtime detections with cloud posture data. When Wiz detects suspicious activity, it doesn't just alert you. It shows you why it matters by connecting that activity to misconfigurations, excessive permissions, public exposure, and sensitive data. This eliminates the flood of contextless alerts that traditional tools generate.
Wiz's lightweight eBPF sensor captures more than network packets. It monitors process execution, file access, and system calls directly from inside your workloads. This gives you visibility even when traffic is encrypted or running in containers.
Attack path analysis takes this further. Wiz doesn't just tell you a threat exists—it maps the potential blast radius. You see exactly how an attacker could move from their initial foothold to your sensitive data or critical systems.
By providing unified visibility from code to runtime across all your cloud environments, Wiz breaks down the silos that plague traditional security tools. You get one platform that understands your entire cloud infrastructure and prioritizes threats based on actual business impact.
Ready to move beyond reactive signature detection? Get a demo and see how Wiz transforms threat detection with complete cloud visibility.
See Wiz in action
In your 30 minute personal demo, you will learn how Wiz connects to your environment and gives complete visibility, maps out resources and reveals attack vectors, prioritizes critical risks using actionable insights
Get a demo
