Even the smartest security tools are only as powerful as the experts who use them. This is particularly true in network security analysis, where the power of a tool like Suricata is directly tied to the quality and accuracy of its configuration.
Suricata stands as a versatile open-source engine, operating as an Intrusion Detection System (IDS), Intrusion Prevention System (IPS), and Network Security Monitoring (NSM) platform. While its potential to identify and block malicious network activity is significant, its actual effectiveness hinges on the strength of the rules that guide it. Poorly designed rules can lead to overlooked threats or an overwhelming number of false alarms, diminishing the system’s value.
This exploration delves into the fundamental principles of creating robust Suricata rules. We will dissect their essential components—actions, headers, and options—to understand how each element contributes to a rule’s functionality and its overall impact on safeguarding networks.
A Suricata rule is built upon three key elements: the action, the header, and the options. Each of these plays a vital role in defining how network traffic is evaluated and how the system responds to what it observes.
The action dictates what Suricata should do when network traffic matches the criteria of a rule. The behavior of these actions varies depending on whether Suricata is operating in IDS or IPS mode:
Keyword | Behavior |
alert | Commonly used in IDS mode, this action generates a log entry when traffic matches the rule but does not block the traffic. |
pass | Allows matching traffic to proceed without further inspection or generating an alert. |
drop | Available in IPS mode, this action immediately stops the processing of the matching traffic and discards the packet. |
reject | Also for IPS mode, it discards the packet and sends a notification to the sender, typically a TCP reset or an ICMP unreachable message. |
rejectsrc | Sends a notification only to the source of the traffic. |
rejectdst | Sends a notification only to the destination of the traffic. |
rejectboth | Sends notifications to both the source and the destination of the traffic. |
Each action serves different security objectives, ranging from passive observation and logging to active intervention against potential threats.
The header itself also has specific sections that further detail what the rule itself will apply to. Headers consist of protocols, IP addresses or IP ranges, source or destination ports, and the direction of traffic to which the rule should be applied.
The header identifies the specific type of network traffic that the rule should examine. It includes details such as the network protocol, IP addresses, port numbers, and the direction of the traffic flow:
By precisely defining the traffic characteristics in the header, you can target specific communication patterns and significantly reduce the occurrence of false positives.
Suricata supports a wide range of network and application layer protocols, including TCP, UDP, HTTP, DNS, and SSH.
“Basic” Protocols | Application Protocols | ||||||
tcp | http | ftp | Tls (ssl) | smb | dns | dcerpic | ssh |
udp | smtp | imap | modbus(*) | dnp3(*) | enip(*) | nfs | ikev2 |
icmp | krb5 | ntp | dhcp | rfb | rdp | snmp | tftp |
ip | sip | http2 | (*) protocols must be enabled in config file | ||||
It’s important to note that in addition to basic protocols, you can also use application protocols and industrial protocols (though some of the latter may need to be enabled in the config file as indicated in the table above).
IP addresses can refer to single addresses, subnets, or the home/external net variable. Below are some examples:
1.2.3.4192.168.0.0/24$HOME_NET, $EXTERNAL_NET!192.168.1.5) and grouping (using []).Type | Example |
Single IP | 1.2.3.4 |
CIDR Range | 192.168.0.0/24 |
$HOME_NET | Defined home network in config |
$EXTERNAL_NET | Defined external network in config |
Negation Operator | !HOME_NET |
Grouping Operator | [HOME_NET, 192.168.0.0/24] |
Any IP | any |
The same logic can be applied when working with ports, which can also be provided as single ports, in groups, or negated. Examples below:
Type | Example |
Single Port | 80 |
Any Port | any |
Port Range | 100.102 |
Negation | !80 |
Grouping Operator | [100:120,!101] |
As shown with the grouping operator example, you can get pretty detailed with the logic in these rules.
Finally, the header will indicate the directionality of the traffic it applies to, which can be unidirectional or bidirectional.
-><>Type | Example |
-> | Unidirectional Match |
<-> | Bidirectional Match |
By precisely defining the traffic characteristics in the header, you can target specific communication patterns and significantly reduce the occurrence of false positives.
This is where the rule’s edge gets honed into a blade. Options can include metadata, specific identifiable bytes, and everything in between. There are some important things to keep in mind:
Each of the key value pairs is either going to be metadata or it will define matching action. Let’s see what this looks like in a specific Suricata rule:
Keyword | Value | Description |
msg | “ET TROJAN Likely Bot Nick in IRC (USA +..)” | Text information sent when alert fires |
flow | established,to_server; | Match on established connections to the server |
flowbits | isset,is_proto_irc | Only run rule when is_proto_irc bit is set to true |
content | “NICK “ | Content for the signature to match |
pcre | “/NICK . *USA.*[0-0]{3,}/i” | Perl compatible regular expression to match packet body against |
reference | url,doc.emergingthreats.net/2008124 | Reference source to learn more when alert fires |
classtype | trojan-activity | Signature classification metadata |
sid | 2008124 | Signature ID metadata |
rev | 2 | Signature revision metadata |
Options provide the granular detail and context for Suricata rules. Enclosed in parentheses following the header, they allow for:
msg:"Detected suspicious URL access";
flow:established,to_server;
flowbits:set,suspicious_behavior;
flowbits:isset,suspicious_behavior;
content:"/login"; http_uri;
pcre:"/\bselect.+from\b/i";
reference:url,www.example.com;
Each option keyword adds a layer of sophistication to the detection logic, enabling the creation of highly specific and context-aware security rules.
On a more practical level, signature IDs and signature revisions are important for version control and tracking. In addition to this article, you can dig a little deeper into writing Suricata rules in this previous Tech Talk Tuesday video from our CEO & Founder, Dan Gunter: Writing Suricata Rules: Understanding The Basic Rule Format
Although the main structure of a Suricata rule is simple, writing Suricata rules can initially feel complicated. This is especially true when one begins to truly leverage the key values; writing these rules can become quite complex. The best way to gain mastery of Suricata rules is to be curious.
Download some sample PCAP files and really play around with the rules to see what you’re able to find (You’ll find some sample PCAP files here: https://github.com/automayt/ICS-pcap).
Really dive into the different protocols and their keywords, and examine the impacts of utilizing Suricata’s ability to be very generalized or specific. And if you ever have questions or need someone to do some additional threat hunting, triage, or incident response, we’re just a Contact Us form away.
Developing mastery in crafting Suricata rules goes beyond mere technical proficiency; it necessitates strategic thinking and a thorough grasp of typical and anomalous network behavior. When thoughtfully constructed, these rules serve as a formidable line of defense, capable of identifying and mitigating intricate cyber threats. This guide lays the groundwork for creating rules that not only detect malicious activity but also do so with accuracy and clarity, aligning with both operational security objectives and the ever-evolving landscape of cyber threats.
What are the primary applications of Suricata? Suricata is primarily used as an Intrusion Detection System (IDS), Intrusion Prevention System (IPS), and Network Security Monitoring (NSM) tool to observe and secure network traffic.
Can Suricata function as a replacement for a traditional firewall? No. While Suricata offers detection and prevention capabilities, it operates at a different layer and complements rather than substitutes the fundamental access control functions of a firewall.
What are effective strategies for minimizing false positives in Suricata alerts? Minimizing false positives involves crafting precise rule headers to target specific traffic patterns and utilizing flow and context-aware options to refine the matching criteria.
Does Suricata offer support for industrial control system protocols? Yes, with appropriate configuration and rule sets, Suricata can be used to monitor and analyze industrial protocols such as Modbus and DNP3.
Is Suricata capable of detecting threats within encrypted network traffic? Suricata can analyze certain metadata and behavioral patterns associated with encrypted traffic. However, deep packet inspection of encrypted content typically requires TLS decryption or the use of indirect detection techniques based on observable characteristics.
Our products are designed to work with
you and keep your network protected.
Insane Cyber © All Rights Reserved 2025