Home > SOC Analysis

Suricata/Snort Rules

Suricata and Snort are signature-based intrusion detection and prevention systems that analyze network traffic in real time.
Their detections rely on rules that define patterns, conditions, and behaviors to identify malicious activity such as malware communication, exploit attempts, scanning, and command-and-control traffic.

This chapter explains Suricata/Snort rules in full-scale SOC depth, including rule structure, packet inspection, writing custom rules, tuning methodology, practical detection logic, and investigation examples.

What Suricata/Snort Rules Do

Suricata/Snort rules inspect network packets and raise alerts when conditions match.

They detect:

  • Exploit payloads

  • Malware signatures

  • Suspicious HTTP requests

  • DNS tunneling

  • Port scanning

  • C2 traffic

  • Protocol abuse

  • Data exfiltration patterns

  • Indicators of compromise (IPs, domains)

Rules turn raw packet data into actionable alerts.

How Suricata/Snort Rule Engines Work

Both engines inspect packet components:

  • IP headers

  • TCP/UDP headers

  • Flags

  • HTTP headers

  • DNS payloads

  • TLS metadata

  • File signatures

  • Byte sequences

Rules match these elements to detect threats.

Example:

alert tcp any any -> any 80 (content:"/shell"; msg:"Webshell attempt";)

Suricata vs Snort (SOC View)

Snort

  • Industry-standard IDS

  • Signature based

  • Lightweight

Suricata

  • Multi-threaded

  • Faster

  • Supports:

    • TLS detection

    • HTTP2

    • File extraction

    • JSON logging

Both use very similar rule syntax.

Suricata/Snort Rule Structure

A rule has four major parts:

1. Action

What the IDS should do:

alert  
drop  
reject  
pass

2. Header

Traffic direction, protocol, ports, and IPs:

alert tcp $HOME_NET any -> $EXTERNAL_NET 443

3. Rule Options

Conditions to match:

content:"/admin";
http_method;  
dsize:>200;
flow:to_server,established;

4. Metadata

Extra info:

msg:"Suspicious admin access";
sid:10001;
rev:1;

Detailed Breakdown of Rule Components

Action

Defines rule behavior:

  • alert → generate alert

  • drop → block packet (IPS mode)

  • reject → block + send reset

  • pass → ignore

Header

Contains:

  • Protocol (tcp, udp, icmp)

  • Source IP

  • Source port

  • Direction (-> or <->)

  • Destination IP

  • Destination port

Example:

alert tcp $EXTERNAL_NET any -> $HOME_NET 445

Rule Options

This is the core of detection.

1. msg

Human-readable alert:

msg:"Possible SMB exploitation";

2. content

Match bytes or strings:

content:"/login";
nocase;

3. pcre

Regex-based pattern matching:

pcre:"/cmd\.exe/i";

4. flow

Control direction/state:

flow:to_server,established;

5. dsize

Match payload size:

dsize:>500;

Useful for data exfiltration.

6. threshold

Limit alert rate:

threshold:type limit, track by_src, count 1, seconds 60;

Prevents alert storms.

7. http_ keywords*

Suricata supports HTTP-specific keywords:

  • http_uri

  • http_header

  • http_method

  • http_cookie

  • http_user_agent

Example:

content:"/wp-admin"; http_uri;

8. tls_ keywords*

Used for encrypted traffic metadata:

  • tls_sni

  • tls_subject

  • tls_issuerdn

Example:

tls_sni; content:"discord.com";

9. byte_test / byte_jump

Used for advanced exploits:

byte_test:4,>,1024,0;

Writing Custom Suricata/Snort Rules (Step-by-Step)

Below is the exact workflow used by SOC detection engineers.

Step 1 — Identify Detection Goal

Examples:

  • Detect encoded PowerShell downloads

  • Detect SQL injection

  • Detect reverse shell traffic

  • Detect C2 beaconing

Step 2 — Capture Packet Sample

Use tcpdump or Wireshark:

tcpdump -i eth0 -w sample.pcap

Step 3 — Analyze Packet

Check:

  • URI

  • Headers

  • Payload

  • Encoded patterns

  • Ports

Step 4 — Choose Correct Keywords

Examples:

  • Matching URI → http_uri

  • Matching header → http_header

  • Matching binary → content

Step 5 — Build Rule

Example detecting SQL injection:

alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (
    msg:"SQL Injection Attempt";
    content:"' OR 1=1 --";
    http_uri;
    nocase;
    sid:20001;
    rev:1;
)

Step 6 — Test Rule

Load rule:

suricata -T -c /etc/suricata/suricata.yaml

Snort test:

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

Step 7 — Deploy and Tune

Monitor:

  • False positives

  • Alert frequency

  • Coverage gaps

Tune rule options if:

  • too sensitive → add flow or context

  • too weak → add more content conditions

Common SOC Detection Rules

Detect Cobalt Strike Beaconing (TLS SNI)

alert tls $HOME_NET any -> $EXTERNAL_NET any (
    msg:"Possible Cobalt Strike Beacon";
    tls_sni; content:"microsoft.com"; nocase;
    sid:40001;
    rev:1;
)

Many Cobalt Strike configs impersonate Microsoft services.

Detect Reverse Shell

alert tcp $HOME_NET any -> $EXTERNAL_NET 4444 (
    msg:"Possible Reverse Shell";
    flow:to_server,established;
    sid:40002;
    rev:1;
)

Detect Base64 Encoded Payload Download

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"Base64 Payload Download";
    content:"powershell -enc";
    http_header;
    sid:40003;
    rev:1;
)

Detect DNS Tunneling

alert udp any any -> any 53 (
    msg:"Potential DNS Tunneling";
    dsize:>200;
    sid:40004;
    rev:1;
)

Detect PHP Webshell Access

alert http $HOME_NET any -> $EXTERNAL_NET 80 (
    msg:"Possible PHP Webshell Access";
    content:"cmd=";
    http_uri;
    sid:40005;
    rev:1;
)

Tuning Suricata/Snort Rules (SOC Techniques)

Tuning is required to reduce noise.

Add Flow Direction

flow:to_server,established;

Restrict Ports

-> $HOME_NET 80

Add Content Depth

content:"POST"; depth:10;

Add Thresholding

threshold:type limit, track by_src, count 5, seconds 60;

Validate Context

Use:

  • HTTP keywords

  • TLS keywords

  • DNS keywords

  • Protocol keywords

Investigation Workflow Using IDS Alerts

  1. Check packet context

  2. Validate rule accuracy

  3. Extract IOCs (domains, URLs, IPs)

  4. Enrich IOCs

  5. Check for related alerts (EDR, firewall)

  6. Reconstruct kill chain

  7. Apply containment

  8. Tune rule if needed

Practical Case Study

Alert: DNS Tunneling Suspicion

dsize:>300  
frequent queries  
random-looking subdomains

Investigation:

  • Extract domain

  • Check entropy

  • Compare to DGA patterns

  • Enrich with VirusTotal

  • Inspect outbound connections

Conclusion:

  • Malware data exfiltration

  • Isolate host → escalate to IR

Intel Dump

  • Suricata/Snort rules detect malicious patterns in network packets using signatures.

  • Core components: action, header, rule options, metadata.

  • Analysts use content, pcre, flow, http/tls/dns keywords, and byte tests to build rules.

  • Custom rule writing requires packet analysis and precise tuning.

  • SOC workflows include testing, tuning, and correlating IDS alerts with SIEM/EDR.

  • IDS rules detect malware, exploits, C2 traffic, tunneling, and suspicious behavior across the network.

HOME LEARN COMMUNITY DASHBOARD