search
LinkedinTryHackme

Suricata Rule Development Part 1

Suricata rules are used to monitor network traffic for specific patterns or markers, often indicative of malicious behavior. These rules can provide critical insights into network activity, aid in threat detection, and contribute to proactive network security strategies.

hashtag
Suricata Rule Anatomy

Here's an example of a basic Suricata rule:

action protocol from_ip port -> to_ip port (msg:"Known malicious behavior, possible X malware infection"; content:"some thing"; content:"some other thing"; sid:10000001; rev:1;)

hashtag
Components of the Rule:

  1. Header (action protocol from_ip port -> to_ip port):

    • Action: Tells Suricata what to do when the rule matches:

      • alert: Generate an alert.

      • log: Log the packet without an alert.

      • drop: Block the packet (IPS mode).

    • Protocol: Specifies the network protocol (tcp, udp, icmp, etc.).

    • Traffic Direction:

      • -> for outbound, <- for inbound, and <-> for bidirectional.

    • Ports: Define source and destination ports for evaluation.

  2. Rule Message and Content:

    • msg: Description shown when the rule triggers, often including malware info.

    • content: Specific strings or values that Suricata searches for in the packet payload.

      • Example:

        content:"User-Agent|3a 20|Go-http-client/1.1|0d 0a|Accept-Encoding|3a 20|gzip";

      • Content can be optimized with rule buffers, such as http.accept for matching only HTTP Accept headers.

  3. Additional Options:

    • nocase: Makes the rule case-insensitive.

    • offset: Sets the starting position in the packet for matching.

    • distance: Specifies the byte distance from the previous match.

    • dsize: Matches on packet payload size (e.g., dsize:>10000 for large packets).

  4. Metadata:

    • sid: Signature ID for uniquely identifying each rule.

    • rev: Revision number indicating rule updates.

    • reference: A URL or identifier providing context or sources for the rule.

hashtag
Example Rule Usage with PCRE

Perl Compatible Regular Expressions (PCRE) enhance detection flexibility. Here’s an example:

  • PCRE: Allows complex pattern matching using regular expressions. It is wrapped in /.../ and can use flags like i for case insensitivity and RP for relative positioning.

hashtag
IDS/IPS Rule Development Approaches

  • Signature-Based Detection: Matches known patterns (e.g., malware strings or packet structures). It’s precise for known threats but limited in detecting new ones.

  • Anomaly-Based Detection: Focuses on unusual network behaviors (e.g., data transfer patterns). It helps detect zero-day attacks but may yield false positives.

  • Stateful Protocol Analysis: Tracks protocol states to identify unusual transitions or behaviors, suitable for identifying protocol misuse.

hashtag
Suricata Rule Development Examples

hashtag
Example 1: Detecting PowerShell Empire

  • Detects HTTP GET requests from PowerShell Empire with specific URI patterns and base64-encoded cookies.

  • Matches on User-Agent and excludes headers like Referer.

hashtag
Example 2: Detecting Covenant

  • Triggers on HTTP responses containing <title>Hello World!</title> at least four times within 10 seconds from the same source.

hashtag
Example 3: Covenant Detection by Size and Counter

  • Detects payloads of exactly 312 bytes sent at least three times within a 10-second window.

hashtag
Example 4: Detecting Sliver C2 Implant

  • Detects HTTP POST requests to URIs associated with Sliver, a C2 framework, using specific directory and PHP file patterns.

Additional Rule for Sliver Detection via Cookies

  • Detects cookies set with names like PHPSESSID or APISID and values matching a 32-character alphanumeric pattern, often associated with Sliver.

For further reference and advanced rule development techniques, explore Suricata’s official rule documentationarrow-up-right.

PreviousQuestionNextSuricata Rule Development Part 2 (Encrypted Traffic)

Last updated