Write Custom Snort Rules Like a Pro With Examples

Introduction

In this post, we will learn about creating custom rules in Snort. The main question is, what is snort? Snort is an open-source intrusion detection and prevention system (IDS/IPS) used by security experts worldwide.

The tool has a vast library of preconfigured rules. However, the true magic begins with the ability to create custom Snort rules. This gives the tool the power to detect specific threats with generic signatures.

Whether you want to prevent freshly found malware, monitor suspicious user activity, or fine-tune warnings for internal policy, Snort allows you to create your own rules and have total control over your network’s security mechanisms. It’s equivalent to adding a customized firewall language to your security stack that speaks your organization’s own language.

This article will walk you through creating custom Snort rules, from understanding syntax to building practical examples. And don’t worry if you’re just starting — we’ll break things down step-by-step with plenty of hands-on insights. You can write and optimize your rules like a pro.

Getting Started with Snort Rule Basics

Comprehending the fundamentals of Snort rules before creating your own is crucial. At first, Snort’s rule language could appear confusing. Still, after you understand its structure, you’ll discover that it’s both logical and powerful. This section covers the fundamentals, including syntax and the roles played by each rule component.

Snort Rule Syntax Explained

Every Snort rule follows a structured format:

Let’s break this down:

• Action – What Snort should do when the rule is triggered (alert, log, pass, drop, etc.)
• Protocol – Layer 3/4 protocol like tcp, udp, icmp, etc.
• Source/Destination IPs and Ports – Define the traffic origin and destination.
• Direction Operator – Indicates the traffic direction (-> , <- or <>).
• Rule Options – A set of rule conditions inside parentheses.

Here’s a sample rule:

alert tcp any any -> 192.168.1.100 80 (msg:"Web server access"; sid:1000001; rev:1;)

This rule alerts when any TCP traffic goes to IP 192.168.1.100 on port 80 and logs the message “Web server access”.

Understanding Rule Headers and Options

The rule header defines the traffic characteristics, while the rule options handle the logic and behavior when a rule matches.

Key header components:

• alert – tells Snort to generate an alert
• tcp – matches TCP traffic
• any any – matches traffic from any source IP and port
• -> – defines direction
• 192.168.1.100 80 – destination IP and port

Key options inside the parentheses include:

• msg – describes the rule’s purpose
• sid – Snort ID, must be unique
• rev – rule revision number

Other useful options include:

• content – looks for specific payload strings
• nocase – case-insensitive content match
• depth and offset – limit where in the payload Snort looks
• classtype – classifies rule type (e.g., attempted-admin, policy-violation)

Understanding rule syntax is foundational. If you misplace an operator or omit an option, your rule might fail silently — or worse, generate false positives. A strong command of Snort’s language gives you not just the ability to write rules, but also to fine-tune them for precision detection.

Building Your First Custom Snort Rules

Once you’ve got the hang of the basic syntax and structure, it’s time to roll up your sleeves and write your first custom Snort rule. This is where theory meets practice — and you’ll quickly see how powerful and flexible Snort can be when tailored to your specific needs.

Step-by-Step Rule Creation

Let’s walk through creating a simple Snort rule to detect HTTP traffic going to a specific IP address.

Goal: Alert when someone accesses a web server at IP 192.168.1.100 on port 80 using TCP.

Rule:

alert tcp any any -> 192.168.1.100 80 (msg:"Access to web server detected"; sid:1000001; rev:1;)

Explanation:

• alert – Generates an alert
• tcp any any – Matches any TCP source IP and port
• -> 192.168.1.100 80 – Targets the destination IP and port (web server)
• msg – Message that will appear in Snort alerts
• sid – Snort rule ID (must be unique)
• rev – Rule revision

Once this rule is written, save it in your local rule file. Typically, you can do this by editing:

/etc/snort/rules/local.rules

Append your new rule at the bottom. Be sure to maintain proper formatting and avoid using a duplicate sid.

Testing Your Snort Rules Locally

Before deploying your rule in a production environment, testing it in a controlled lab or test environment is required. Here’s how:

Step 1: Enable Local Rule Set

In your snort.conf file, ensure the following line is uncommented:

include $RULE_PATH/local.rules

Step 2: Run Snort in IDS Mode

Use Snort to listen to traffic and test the rule:

snort -A console -q -c /etc/snort/snort.conf -i eth0

This command tells Snort to:

• -A console – Display alerts in the console
• -q – Be quiet (suppress banner/log spam)
• -c – Load your config file
• -i – Specify the interface

Step 3: Generate Traffic

Now, simulate traffic that matches your rule. For instance, use a browser or curl to access: http://192.168.1.100

If your rule is working, Snort will display the alert in the terminal:

[**] [1:1000001:1] Access to web server detected [**]

Congratulations — you’ve just created and tested your first custom Snort rule!

Once you’re comfortable with this, you can start writing more specific rules — using content, flags, flow, and other options to refine how and when alerts trigger. You’re not just creating custom snort rules… you’re customizing a digital sentry that defends your network, byte by byte.

Tips to Write Better, Smarter Custom Snort Rules

Writing a rule that works is good, but writing one that works well in a live network is where true mastery begins. This section will explore the art and science of building smarter Snort rules that reduce noise, avoid false positives, and remain easy to maintain.

Avoiding False Positives

False positives are the enemy of efficient threat detection. They waste analyst time and can cause real alerts to be missed. Here’s how to avoid them:

• Use content filters wisely: Be specific. Avoid short, standard strings that might appear in regular traffic.
• Add depth and offset: These options tell Snort where in the packet to look. That can dramatically reduce incorrect matches.
• Pair conditions: Combine multiple content, flow, or flag options to narrow the match window.
• Whitelist trusted IPs: Use negation in IP fields (e.g., !192.168.1.1) to exclude known safe traffic.

Optimizing Rule Performance

Inefficient rules can slow down your IDS and bog down alert logs. To avoid that:

• Avoid excessive use of PRCE: regex is powerful but computationally expensive unless necessary.
• Use fast pattern matches first: Place content options more likely to occur before rare ones.
• Group rules logically: Organize by use case (e.g., malware, reconnaissance, internal policy) for easier management.
• Choose the right action: Use the alert separately. Consider the log instead for benign but interesting traffic.

Rule Maintenance Best Practices

Your environment changes, and so should your rules. Here’s how to keep your ruleset healthy:

• Assign unique SIDs: Use a private SID range (typically 1000000 and up) to avoid conflicts with Snort’s official rules.
• Use comments generously: Describe what each rule is for and where it applies.
• Version your rules: Bump the (rev: value) when you modify a rule — it helps track changes.
• Test regularly: Always test using safe traffic generators or isolated labs after updates.

Rule Writing DOs and DON’Ts

Building a Ruleset That Scales

As your rule count grows, you’ll want structure. Use folders, naming conventions, and descriptive files like README.md to document rule categories. Automation tools like PulledPork or Snort’s rule management utilities can help manage the rule lifecycle.

Advanced Snort Rule Tuning Techniques

Once you’re comfortable with writing basic rules, it’s time to unlock Snort’s advanced features. These tools let you track state, manage complex conditions, and dig deeper into packet payloads. The more granular your detection capabilities, the better you can isolate real threats from background noise.

Using Flowbits for Stateful Detection

Flowbits allow you to track and correlate multiple packets or sessions, making your rules “stateful.” This is incredibly useful for detecting multi-stage attacks or sequences that require context.

Example:

alert tcp any any -> any 80 (content:"Set-Cookie:"; flowbits:set,has_cookie; msg:"Cookie Set Detected"; sid:1000012; rev:1;)

alert tcp any any -> any 80 (content:"/admin"; flowbits:isset,has_cookie; msg:"Admin Page Accessed with Cookie"; sid:1000013; rev:1;)

Here, the first rule sets a flow bit when a cookie is detected. The second rule only triggers if the flowbit is active, indicating that a session with a cookie has been accessed on an admin page.

🧠 Pro Tip: Flowbits are ideal for detecting session hijacks, application abuse, and staged attacks.

Leveraging PCRE (Perl-Compatible Regular Expressions)

For more complex matching, Snort supports PCRE to create advanced pattern recognition logic.

Example:

alert tcp any any -> any 80 (pcre:"/\/login\?user=\w{3,10}/"; msg:"Regex Match on Login URL"; sid:1000014; rev:1;)

This rule matches login URLs with 3 to 10 characters long usernames.

⚠️ Note: PCREs are powerful but processor-intensive — use them sparingly and wisely.

Tapping into Snort Preprocessors

Snort has a range of preprocessors that enhance detection by decoding or reassembling traffic before rules evaluate it.

Key ones to know:

• Frag3 – Reassembles IP fragments.
• Stream5 – Reassembles TCP streams and manages session states.
• HTTP Inspect – Normalizes HTTP traffic for accurate rule matching.

Usage:

Make sure these are enabled in your snort.conf:

preprocessor stream5_global: track_tcp yes, ...

preprocessor http_inspect: global iis_unicode_map unicode.map 1252

💡 Why It Matters: Preprocessors ensure that obfuscated traffic doesn’t bypass your detection rules.

Thresholding and Rate Limiting Alerts

Are there too many alerts from noisy traffic? To reduce false positives, you can limit alerts per source or time frame using threshold, suppress, or limit.

Example:

alert tcp any any -> any 22 (msg:"SSH Connection Attempt"; threshold: type threshold, track by_src, count 5, seconds 60; sid:1000015; rev:1;)

This rule will only trigger once per 5 attempts from the same source within a minute.

Streamlining with Variables

Use variables in the snort to make your rules reusable and easy to update.conf file:

var HTTP_SERVERS [192.168.1.10,192.168.1.20]

Then in your rule:

alert tcp any any -> $HTTP_SERVERS 80 (msg:"Access to HTTP Server"; sid:1000016; rev:

Troubleshooting and Debugging Your Custom Snort Rules

No matter how skilled you are, some Snort rules will misbehave. They may be too broad, too specific, or improperly formatted. The key is learning to debug systematically to identify and resolve issues without breaking your entire detection system.

Common Pitfalls and How to Fix Them

❌ Rule Doesn’t Trigger

• Check traffic direction – Are you using -> correctly? If traffic comes from the target IP, the rule won’t match if your direction is reversed.
• Review protocol and ports – The rule fails if you match on TCP port 80, but the app uses port 8080.
• Verify sid is unique – Duplicate SIDs can cause rules to be ignored.
• Use specific, not vague, content – Overly general content strings often lead to no matches or too many.

✅ Fix Tip:

Use tools like tcpdump or Wireshark to capture traffic and confirm whether packets match the conditions you’ve written into your rule.

Reading Snort Logs and Console Output

When you run Snort in console mode:

snort -A console -q -c /etc/snort/snort.conf -i eth0

It shows matched alerts directly in your terminal. But for deeper diagnostics:

Look at these files:

• /var/log/snort/alert – Main log of triggered rules
• /var/log/snort/snort.log.X – Binary pcap logs of packets
• /var/log/syslog – Logs that might include Snort service errors

💡 Tip: Use barnyard2 or PulledPork for enhanced log parsing and rule management in production.

Tools to Debug Custom Rules

Step 1: Snort in PCAP mode Feed Snort a .pcap file for offline analysis:

snort -r sample.pcap -c /etc/snort/snort.conf

Step 2: Rule-by-Rule Testing Comment out all rules in local.rules and test only the one you’re working on. This isolates the behavior and eliminates interference.

Step 3: Use the -T Flag To test your configuration without running Snort:

snort -T -c /etc/snort/snort.conf

Step 4: This checks your rule syntax and shows config load success/fail status.

Fine-Tuning Rule Accuracy

Rules too broad?

• Add depth, offset, or within modifiers to narrow the content search.

Rules too noisy?

• Use threshold, suppress, or limit to reduce alert frequency.

Conflicting rules?

• Keep a naming and SID convention to avoid overlap. Consider modular rule files by category: web.rules, malware.rules, scan.rules, etc.

Real-World Debugging Example

Scenario: You wrote a rule to detect .exe downloads, but it’s not alerting.

Step-by-step diagnosis:

1. Check if the traffic is actually HTTP and not HTTPS.
2. Use Wireshark to inspect payload for .exe visibility.
3. Refine the rule with:

alert tcp any any -> any 80 (content:".exe"; http_uri; msg:"EXE download"; sid:1000020; rev:2;)

4. Retest using a known .exe download over HTTP (e.g., via a local web server).

Mastering these techniques ensures your custom Snort rules do what they’re supposed to — detect threats clearly, accurately, and efficiently.

Summary

Learning to write custom Snort rules is like giving your IDS a personal playbook — one tailored to your environment, your risks, and your defensive goals. While Snort’s default rules are a solid start, it’s the ability to create and customize rules that transforms you from a user into a true defender of your network.

By now, you’ve gone from understanding basic syntax to writing real-world detection rules, optimizing for performance, exploring advanced techniques, and troubleshooting with precision. Whether stopping a brute-force attacker or tracking a stealthy data leak, your rules can distinguish between being caught off guard or staying ahead of threats.

Keep experimenting, keep tweaking, and keep pushing your Snort setup further. The more you practice, the more intuitive it becomes — and the more protected your digital world will be.

And that’s how you can create custom rules in Snort! Please comment below if you have any questions or ideas for future articles.

Frequently Asked Questions