Suricata Rules & EveBox

Rules Are the Heart of Detection

In the previous lesson you learned how a Network Intrusion Detection System watches traffic — sniffing packets on the wire, reassembling streams, and comparing what it sees against a library of known-bad patterns. That library is a ruleset, and without it Suricata is nothing more than an expensive packet sniffer.

Rules are what turn raw network data into actionable intelligence. Every alert that appears in your dashboard exists because a rule matched. Every threat that goes undetected slipped past because no rule covered it. Understanding how rules work — how they're structured, where they come from, and how they're tuned — is the single most important skill for a network detection analyst.

This lesson breaks down Suricata's rule language piece by piece, walks through the major rule sources, explains the severity classification system, and then shows you how to navigate alerts in EveBox, the management interface you'll use in every network detection lab going forward.

Anatomy of a Suricata Rule

Every Suricata rule is a single line of text with two major sections: the header (what traffic to inspect) and the options (what to look for and how to report it). Let's start with a real rule from the lab environment:

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"CYBERBLUE EXPLOIT - SQL Injection sqlmap User-Agent"; flow:to_server,established; content:"sqlmap"; http_user_agent; classtype:web-application-attack; sid:9000010; rev:1;)

This rule fires when Suricata sees an HTTP request from an external address to an internal server where the User-Agent header contains the string "sqlmap" — the default fingerprint of the popular SQL injection tool. Let's dissect it.

Click to enlarge

The Action

The first word in every rule tells Suricata what to do when the rule matches:

In the CyberBlueSOC lab, Suricata runs in IDS mode, so every matching rule uses alert. In production environments running IPS (Inline Prevention), security engineers may promote high-confidence rules to drop so malicious traffic is blocked automatically.

The Header

The header specifies the protocol, source address and port, direction, and destination address and port:

alert http $EXTERNAL_NET any -> $HOME_NET any
      ^^^^ ^^^^^^^^^^^^^ ^^^    ^^^^^^^^^ ^^^
      proto  src_addr   src_port  dst_addr dst_port

• Protocol: http, tcp, udp, icmp, tls, dns, smtp, ftp, or the generic ip. Using application-layer protocols like http unlocks protocol-specific keywords (sticky buffers).
• Source/Destination: Variables like $HOME_NET (your internal network) and $EXTERNAL_NET (everything else) are defined in suricata.yaml. Using variables instead of hard-coded IPs means the same ruleset works across different network configurations.
• Direction: -> means source-to-destination. <> means bidirectional (match traffic in either direction).
• Ports: any matches all ports. You can specify single ports (443), ranges (1024:65535), or lists ([80,443,8080]).

The Options

Everything inside the parentheses is a semicolon-delimited list of keywords that define the detection logic and metadata. This is where the real intelligence lives.

Here's a detailed reference for the keywords you'll encounter most:

A few keywords deserve extra attention:

content is the workhorse. Most rules match specific strings or byte sequences in the traffic. You can have multiple content matches in a single rule, and they're evaluated in order. The nocase modifier makes the match case-insensitive. The depth, offset, distance, and within modifiers constrain where in the payload the content must appear — this reduces false positives and improves performance.

Sticky buffers like http_user_agent, http_uri, http_header, and http_method tell Suricata to apply the preceding content match only against a specific part of the parsed HTTP request rather than the entire payload. The rule above uses http_user_agent so that "sqlmap" is matched only in the User-Agent header — not anywhere else in the HTTP stream.

flow ensures Suricata only checks traffic in the right direction and state. to_server,established means "match packets going from the client to the server in an already-established TCP session." This prevents false positives on SYN packets, retransmissions, and server responses.

Rule Sources — ET Rules vs Custom Rules

No SOC writes every rule from scratch. The Suricata ecosystem provides massive community-maintained rulesets that cover known threats, plus the ability to add your own.

ET (Emerging Threats) Community Rules

The Emerging Threats (ET) Community ruleset is the backbone of most Suricata deployments. Maintained by Proofpoint, it includes:

• 40,000+ signatures covering malware, exploits, botnets, C2 infrastructure, policy violations, and more
• Daily updates reflecting the latest threat intelligence
• Free for any use — commercial or non-commercial
• Categorized by threat type with standardized naming: ET MALWARE, ET EXPLOIT, ET SCAN, ET POLICY, ET TROJAN, ET CNC (command and control)

When you see an alert like "ET SCAN Sqlmap SQL Injection Scan" in EveBox, the "ET" prefix tells you the signature came from the Emerging Threats community ruleset. The naming convention immediately communicates the threat category.

ET Pro Rules

ET Pro is the commercial tier from Proofpoint. It includes everything in the community set plus:

• Faster release cycle (signatures for zero-days within hours)
• More signatures for advanced threats, targeted attacks, and APT infrastructure
• Commercial support and SLA guarantees

Most enterprise SOCs pay for ET Pro. For training and smaller deployments, the community set is more than sufficient.

Custom Rules

Every organization has unique detection needs. Custom rules cover:

• Internal policy enforcement — detecting unauthorized VPN clients, unapproved cloud storage services, or protocol violations
• Organization-specific IOCs — rules built from your own threat intelligence or incident investigations
• Gap-filling — covering threats that community rules haven't addressed yet

In the CyberBlueSOC lab environment, custom rules use the CYBERBLUE prefix and SID range 9000xxx. These sit alongside ET community rules in the same ruleset.

Severity and Classification

Not all alerts are equal. A port scan from a known scanner is noise. A confirmed C2 beacon from an internal host is a five-alarm fire. Suricata uses the classtype keyword to categorize alerts by severity, and EveBox uses these classifications to help you prioritize your queue.

Priority Levels

The priority assignment comes from the classification.config file that ships with Suricata. When a rule specifies classtype:web-application-attack, Suricata looks up that classtype in the config and assigns priority 1. Rule authors can also override the default priority with an explicit priority keyword.

Severity in Context

Raw severity is a starting point, not the final word. Context transforms a medium-severity alert into a critical incident:

• A port scan (priority 3) from an external IP is routine. A port scan from an internal server that shouldn't be scanning is priority 1 — it suggests lateral movement.
• A policy violation (priority 2) for TLS to a crypto-mining pool is annoying. The same violation from a domain controller means it's compromised.
• A single C2 beacon (priority 1) is bad. The same beacon firing every 60 seconds for 6 hours means the attacker has persistent, reliable access.

Alert count and source context always modify the baseline severity. This is a judgment call that no rule engine can make for you — it's why organizations hire SOC analysts.

EveBox — Your Alert Management Dashboard

EveBox is a web-based interface purpose-built for managing Suricata alerts. While Suricata writes detection events to eve.json (its unified log format), EveBox reads that data and presents it in a clean, searchable, analyst-friendly dashboard. In the CyberBlueSOC lab, EveBox is your primary tool for network alert investigation.

Click to enlarge

The Inbox

The Inbox is your starting point. It displays alerts grouped by signature — rather than showing 200 individual C2 beacon alerts, EveBox groups them under a single entry with a count badge showing how many times that signature fired. This grouping prevents alert fatigue and lets you focus on the unique threats.

Each inbox entry shows:

• Signature name — the msg field from the rule
• Alert count — how many times this signature fired in the selected time range
• Severity indicator — color-coded by priority
• Latest timestamp — when the most recent instance fired
• Source and destination IPs — the most common pairs

Alert Details

Clicking into an alert group reveals the individual events. For each event, EveBox shows:

• Full timestamp with microsecond precision
• Source IP and port → Destination IP and port
• Protocol and any parsed application-layer data (HTTP headers, DNS queries, TLS SNI)
• Rule metadata — SID, classtype, the full rule text
• Packet payload — the actual bytes that matched the rule (when available)

Actions

EveBox provides three workflow actions for managing alerts:

• Escalate — flag the alert for deeper investigation. Escalated alerts move to a separate view so they don't get lost in the noise.
• Archive — acknowledge the alert and remove it from the active inbox. Use this for confirmed false positives, tuned-out signatures, or alerts you've fully investigated.
• Comment (in some deployments) — add analyst notes directly to the alert for team communication.

Filters and Search

The filter bar at the top of EveBox lets you narrow results by:

• Time range — last hour, last 24 hours, last 7 days, or custom
• Severity — show only critical, or filter out low/informational
• Source or destination IP — focus on a specific host
• Signature text — search for keywords in the alert message
• Event type — EveBox doesn't just show alerts. Suricata's eve.json also contains HTTP logs, DNS logs, TLS logs, and flow records. You can switch between these event types to get full protocol visibility.

Reading an Alert in EveBox

Let's walk through a specific alert from the Operation Wire Tap lab scenario to practice the skill of extracting actionable intelligence from an EveBox entry.

The Alert

Signature:   CYBERBLUE C2 - HTTP Beacon to Known C2 Server 203.0.113.66
Source:      10.0.0.50:49821
Destination: 203.0.113.66:80
Protocol:    HTTP
Category:    trojan-activity (Priority 1)
Count:       14

Breaking It Down

Signature name: The "CYBERBLUE" prefix tells you this is a custom rule (not an ET community rule). "C2" categorizes the threat. "HTTP Beacon" describes the behavior — the compromised host is periodically checking in with the C2 server over HTTP. The rule author embedded the destination IP in the message for quick identification.

Source: 10.0.0.50 is an internal host (RFC 1918 address space). This is a workstation or server inside your network that is communicating outbound to a known-bad IP. The ephemeral source port (49821) confirms this is a client-initiated connection.

Destination: 203.0.113.66 on port 80 — an external IP address that the rule author has identified as C2 infrastructure. Port 80 is standard HTTP, which is a common choice for C2 traffic because it blends in with normal web browsing.

Category and Priority: trojan-activity is priority 1 — this is critical. The classification system is telling you that this signature indicates confirmed malicious activity, not just suspicious behavior.

Count: 14 instances. The compromised host beaconed 14 times during the capture window. Regular, repeated communication to a C2 server indicates the attacker has reliable remote access and the implant is actively checking in for commands.

What This Tells the Analyst

This single alert gives you an entire narrative: an internal host (10.0.0.50) has been compromised and is communicating with attacker-controlled infrastructure (203.0.113.66) over HTTP. The beacon is periodic (14 times), indicating an active implant. Your next steps:

1. Isolate 10.0.0.50 from the network to prevent further C2 communication
2. Check EveBox for other signatures involving 10.0.0.50 — look for lateral movement, data exfiltration, or additional tool downloads
3. Query 203.0.113.66 in your threat intel platform (MISP) for related infrastructure
4. Pivot to endpoint investigation (Velociraptor in later modules) to identify the malware process

Putting It All Together: From Rule to Alert to Action

The workflow you'll follow in every network detection lab is:

1. Suricata processes traffic — packets are inspected against thousands of rules
2. Matching rules fire alerts — written to eve.json with full metadata
3. EveBox ingests the alerts — groups them by signature, displays severity
4. You triage in EveBox — sort by priority, read alert details, assess context
5. You investigate — pivot to packet captures, threat intel, or endpoint tools
6. You take action — escalate, document, or archive based on your assessment

This is the same workflow that network security analysts follow in production SOCs worldwide. The tools may have different names at different organizations, but the process — rule match, alert triage, investigation, action — is universal.

What's Next

You can now read any Suricata rule and understand exactly what it detects, and you know how to navigate EveBox to find, prioritize, and manage alerts. In the next lesson — Protocol Analysis — you'll go deeper into the actual traffic data. You'll learn to analyze HTTP headers, TLS fingerprints, DNS queries, and SMB commands to distinguish normal protocol behavior from malicious abuse. Where this lesson taught you to understand the rules, the next teaches you to understand the traffic itself.