Even in the age of advanced technology, the adage that a tool is only as good as the person using it remains true. Few cyber forensic activities exemplify this more than writing Suricata rules.
Suricata can both detect and defend, but its capability to do either will be inversely related to how well rules are structured.
In this article, we’ll break down the basics of Suricata rules and offer key insights into how a well-crafted, thoughtful rule can do a better job of preventing and detecting cyberattacks.
Suricata rules have three main components: actions, headers, and options. These three parts are essentially the DNA of any rule, dictating how the rule will function and what effect it will have.
For a rule to have maximum efficacy, each section must be carefully constructed with the end objective in mind.
This part determines what occurs when the rule synchronizes a match. Importantly, actions will behave differently depending on whether Suricata is in prevention or detection mode. For example, in detection mode, you may not be able to stop network traffic, whereas you may have that capability in prevention mode.
Keyword | Behavior |
alert | Generate alert and let packet through |
pass | Stop further inspection and let packet through |
drop | Drop packet (if in IPS mode) and generate alert |
reject | Set RST/ICMP unreachable message to sender |
rejectsrc | Same action as reject |
rejectdst | Set RST/ICMP error message to receiver |
rejectboth | Set RST/ICMP error message to sender and receiver |
Actions use colloquial words that sometimes indicate what will happen when there’s a match. “Alert,” for example, does exactly that – the packet will get through, but an alert is generated. Similarly, “Reject” can send a RST/ICMP message to the sender.
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 section of the rule defines the major settings for the rule.
Protocol select might include a transport layer, network layer, or application layer.
“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:
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 |
The unidirectional match goes from source to destination. Suricata doesn’t offer the other direction (from destination to source), so you would need to change the logic of the rule to be unidirectional in the left-to-right syntax.
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 |
Metadata can be glossed over in rule creation, but when thoughtfully crafted, it can bolster how effective a rule is. It is the last part of a rule but also offers the greatest potential to leverage specificity and creativity.
One example is regular expressions. Since some IDS and IPS evasions are based on deducing regular expressions, sometimes switching around words until they find the combination that matches, putting a bit more consideration into them can change a decent rule into one that is far more effective at preventing evasions.
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.
Our products are designed to work with
you and keep your network protected.
Insane Cyber © All Rights Reserved 2025
