Understanding and Writing Suricata IDS Rules

Suricata is a powerful open-source Intrusion Detection System (IDS) that helps monitor network traffic for suspicious activities. One of its key features is the ability to write custom rules to detect specific patterns or behaviors. In this post, we’ll explore how to write effective Suricata rules with practical examples.

Basic Rule Structure

A Suricata rule follows this basic structure:

action protocol source_ip source_port -> destination_ip destination_port (rule options)

Let’s break down each component:

  • Action: Determines what Suricata should do when a match is found (alert, drop, pass, reject)
  • Protocol: The protocol to match (tcp, udp, icmp, ip, http, ftp, etc.)
  • Source IP/Port: The origin of the traffic
  • Destination IP/Port: The target of the traffic
  • Rule Options: Additional criteria and metadata enclosed in parentheses

Common Rule Examples

1. Basic TCP Alert Rule

alert tcp any any -> $HOME_NET 22 (msg:"Potential SSH Scan"; flags:S; threshold:type both,track by_src,count 5,seconds 60; classtype:attempted-recon; sid:1000001; rev:1;)

This rule alerts on potential SSH scanning by detecting multiple SYN packets to port 22 within a minute.

2. HTTP Traffic Detection

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"Suspicious User-Agent Detected"; flow:established,to_server; http.user_agent; content:"suspicious-agent"; nocase; classtype:trojan-activity; sid:1000002; rev:1;)

This rule detects HTTP traffic with a specific suspicious User-Agent string.

3. File Download Detection

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Executable Download Detected"; flow:established,to_client; http.response_body; content:"|4D 5A|"; startswith; filename:"*.exe"; classtype:policy-violation; sid:1000003; rev:1;)

This rule alerts when an executable file (starting with MZ header) is downloaded.

Rule Options Explained

Common Options

  1. msg: Human-readable message for the alert
msg:"Alert Description";
  1. content: Match specific content in the payload
content:"malicious string";
content:"|4D 5A|";  # Hex format
  1. pcre: Use regular expressions for pattern matching
pcre:"/pattern/iU";
  1. flow: Specify direction and state of traffic
flow:established,to_server;

Modifiers

  • nocase: Case-insensitive matching
  • depth: Search only first N bytes
  • offset: Start search N bytes into payload
  • distance: Relative offset from previous match
  • within: Match must occur within N bytes

Best Practices

  1. Use Meaningful SIDs

    • Reserve 1000000-1999999 for local rules
    • Keep track of your rule IDs
    • Include revision numbers

  2. Optimize Performance

    • Use fast_pattern for most unique content
    • Minimize use of pcre when possible
    • Use appropriate thresholds

  3. Document Your Rules

    • Include descriptive messages
    • Add reference information
    • Comment complex rules

Example Rule Set

Here’s a practical set of rules for common security monitoring:

# Web Shell Detection
alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"Potential Web Shell Upload"; flow:established,to_server; http.uri; content:".php"; http.request_body; content:"eval("; content:"base64_decode"; distance:0; within:100; classtype:web-application-attack; sid:1000004; rev:1;)

# SQL Injection Attempt
alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"SQL Injection Attempt"; flow:established,to_server; http.uri; content:"union"; nocase; pcre:"/union[\s]+select/i"; classtype:web-application-attack; sid:1000005; rev:1;)

# Large ICMP Packet (Potential Tunnel)
alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"Large ICMP Packet Detected"; dsize:>800; classtype:bad-unknown; sid:1000006; rev:1;)

Testing Your Rules

Before deploying rules in production:

  1. Test in a development environment
  2. Use suricata-verify for rule validation
  3. Monitor false positives
  4. Adjust thresholds as needed

Security Monitoring Examples

Here are practical examples for monitoring various security aspects of your network:

TLS Protocol Analysis

These rules help monitor SSL/TLS versions and detect usage of obsolete or insecure versions:

# TLS Version Detection
alert tls any any -> any any (msg:"matched obsolete ssl/tls version"; ssl_version:sslv2,sslv3,tls1.0,tls1.1; sid:1000001; rev:1;)
alert tls any any -> any any (msg:"matched TLSV1.2"; ssl_version:tls1.2; sid:1000002; rev:1;)
alert tls any any -> any any (msg:"matched TLSV1.3"; ssl_version:tls1.3; sid:1000003; rev:1;)

# Insecure Cipher Suite Detection
alert tls any any -> any any (msg:"TLS Insecure cipher suite TLS_RSA_WITH_RC4_128_SHA";
    flow:established;
    ssl_state:server_hello;
    content:"|00 05|";
    offset:44;
    depth:2;
    sid:1000011;
    rev:1;
)

Unencrypted Protocol Detection

Monitor usage of potentially dangerous unencrypted protocols:

# Unencrypted Protocol Monitoring
alert http any any -> any any (msg:"matched HTTP"; sid:1000021; rev:1;)
alert ftp any any -> any any (msg:"matched FTP"; sid:1000023; rev:1;)
alert smtp any any -> any any (msg:"matched SMTP"; sid:1000024; rev:1;)
alert smb any any -> any any (msg:"matched SMB"; sid:1000025; rev:1;)
alert snmp any any -> any any (msg:"matched SNMP"; sid:1000026; rev:1;)

Web Attack Detection

Rules for detecting common web-based attacks:

# SQL Injection Detection
alert http any any -> any any (
    msg:"Possible SQL Injection attack (Contains UNION)";
    flow:established,to_server;
    content:"union";
    nocase;
    http_uri;
    sid:1000041;
    rev:1;
)

# XSS Attack Detection
alert http any any -> any any (
    msg:"Possible XSS attack detected";
    flow:established,to_server;
    content:"<script>";
    nocase;
    http_client_body;
    sid:1000043;
    rev:1;
)

DDoS and Network Scanning Detection

Detect potential DDoS attacks and network scanning activities:

# DDoS Detection
alert ip any any -> $HOME_NET any (
    msg:"Possible DoS attack detected";
    threshold: type threshold, track by_src, count 100, seconds 10;
    sid:1000061;
    rev:1;
)

# Port Scanning Detection
alert tcp any any -> $HOME_NET any (
    msg:"Possible TCP scan detected";
    flags:S;
    threshold: type threshold, track by_src, count 100, seconds 10;
    sid:1000062;
    rev:1;
)

Important Notes on These Rules

  1. TLS Monitoring:

    • The TLS version rules help identify outdated protocols
    • Cipher suite detection requires precise offset matching
    • Consider your compliance requirements (PCI-DSS, HIPAA, etc.)

  2. Unencrypted Protocols:

    • These rules can generate high volumes of alerts
    • Consider using them for inventory rather than alerting
    • Useful for identifying policy violations

  3. Web Attack Detection:

    • These are basic examples and should be tuned
    • Consider adding whitelist rules for known good traffic
    • Monitor false positives carefully

  4. DDoS Detection:

    • Adjust threshold values based on your network
    • Consider adding additional indicators (packet size, flags, etc.)
    • May need different thresholds for different services

Conclusion

Writing effective Suricata rules requires understanding both network protocols and potential attack patterns. Start with basic rules and gradually build more complex ones as you understand your network’s needs. Remember to regularly update and tune your rules based on false positives and emerging threats.

Additional Resources

Remember that IDS rules are just one part of a comprehensive security strategy. Combine them with other security measures like firewalls, access controls, and regular system updates for better protection.