In this module

NF1.5 Suricata Installation and Rule Management

10 hours · Module 1 · Free

What you already know

You understand IDS concepts from NF0 — signature matching, alert generation, rule management. If you've deployed Suricata before, the installation will be familiar. This sub covers installation from the OISF PPA, initial configuration, rule management with suricata-update, and your first alert generation against a test PCAP.

Operational Objective

Zeek tells you what happened on the network. Suricata tells you when something bad happened. Together, they form a detection and investigation pair — Suricata fires the alert, Zeek provides the context. But Suricata with stale rules is a false sense of security. And Suricata without Zeek is a detection engine with no investigation capability.

This sub installs Suricata, configures it for EVE JSON output (for structured alert data), sets up suricata-update for automated rule management, and validates the installation against a PCAP that contains known malicious traffic.

Deliverable: A working Suricata installation with the ET Open ruleset loaded, EVE JSON output configured, Community ID enabled, and a validated alert against test traffic.

Estimated completion: 35 minutes

Figure NF1.5 — Suricata setup pipeline. Community ID in the EVE output is the critical configuration — it enables correlation between Suricata alerts and Zeek metadata for the same network flow.

Step 1 — Install Suricata

Add the OISF (Open Information Security Foundation) PPA and install:

sudo add-apt-repository ppa:oisf/suricata-stable -y
sudo apt update
sudo apt install -y suricata suricata-update

Verify the installation:

suricata --build-info | head -5
suricata -V

The version should be 7.0+ (current stable). The build info confirms features like AF_PACKET, Rust, and EVE output are compiled in.

Step 2 — Configure Suricata

Suricata's configuration file is /etc/suricata/suricata.yaml. The file is large (2000+ lines) — you only need to change a few settings for the lab.

Enable Community ID in the EVE output. This is the critical configuration that links Suricata alerts to Zeek logs:

sudo nano /etc/suricata/suricata.yaml

Find the community-id section (search for community-id:) and set it to true:

community-id:
  enabled: true

Find the eve-log section and verify it's enabled with the alert type included. The default configuration usually has this correct, but verify:

outputs:
  - eve-log:
      enabled: yes
      filename: eve.json
      types:
        - alert:
            payload: yes
            payload-printable: yes
            http-body: yes
            http-body-printable: yes

Set the log directory to your sensor's log path:

default-log-dir: /opt/sensor/suricata-logs/

Set the HOME_NET variable to match NE's internal ranges (and your lab network):

vars:
  address-groups:
    HOME_NET: "[10.0.0.0/8,172.16.0.0/12,192.168.0.0/16]"

Step 3 — Install and Update Rules

suricata-update manages rule downloads and installation. Run the initial update:

sudo suricata-update

This downloads the Emerging Threats (ET) Open ruleset — approximately 40,000 rules covering malware, C2, exploit kits, and attack patterns. The rules are installed to /var/lib/suricata/rules/suricata.rules.

Verify rules loaded:

sudo suricata-update list-sources
wc -l /var/lib/suricata/rules/suricata.rules

The rule count should be 30,000-50,000 active rules.

Step 4 — Test Against a PCAP

Run Suricata against a test PCAP that contains known malicious traffic. The malware-traffic-analysis.net site provides excellent test PCAPs with known C2 traffic that will trigger ET rules:

sudo suricata -r /opt/sensor/pcap/test-capture.pcap \
  -l /opt/sensor/suricata-logs/ \
  --set classification-file=/etc/suricata/classification.config \
  --set reference-config-file=/etc/suricata/reference.config

Check for alerts in the EVE JSON output:

cat /opt/sensor/suricata-logs/eve.json | jq 'select(.event_type=="alert")' | head -30

If the PCAP contains malicious traffic, you should see alert entries with fields including alert.signature, alert.category, alert.severity, and community_id.

Verify Community ID is present in alerts:

cat /opt/sensor/suricata-logs/eve.json | jq 'select(.event_type=="alert") | .community_id' | head -5

Each alert should show a Community ID hash. Take one of these hashes and search for it in the Zeek conn.log you generated from the same PCAP:

grep "THE_COMMUNITY_ID" /opt/sensor/zeek-logs/test-run/conn.log

If you find a match, the Zeek-Suricata correlation is working. The same network flow appears in both tools, linked by Community ID.

Step 5 — Automate Rule Updates

Create a daily cron job to update rules automatically:

echo "0 4 * * * root suricata-update && systemctl reload suricata" | \
  sudo tee /etc/cron.d/suricata-update

This runs suricata-update at 04:00 daily and reloads Suricata to pick up new rules. For live sensor deployments, the reload is important — new rules only take effect after Suricata reloads its rule file.

For the lab, the cron job ensures your rules stay current when you use the sensor over the course of multiple modules.

Guided Procedure — Verify Suricata-Zeek Correlation

Step 1. Run both Zeek and Suricata against the same PCAP file.

Expected output: Zeek produces log files in one directory. Suricata produces eve.json in another. Both have processed the same traffic.

If Suricata produces no alerts: The test PCAP may not contain traffic that matches ET rules. Use a PCAP from malware-traffic-analysis.net that is known to contain C2 traffic (the site labels them with the malware family).

Step 2. Extract a Community ID from a Suricata alert and find it in Zeek conn.log.

Expected output: The same Community ID appears in both the Suricata alert and the Zeek conn.log entry. The conn.log entry shows the connection duration, byte counts, and other metadata that the Suricata alert doesn't include.

If the Community ID from Suricata doesn't appear in Zeek: Verify both tools processed the same PCAP. Verify Zeek has Community ID logging enabled (`grep community_id conn.log`). If Zeek's Community ID format differs from Suricata's, check versions — the hash algorithm must match.

Step 3. From the Zeek conn.log entry, pivot to dns.log and ssl.log using the uid.

Expected output: The conn.log uid appears in dns.log (showing the domain that was resolved before the connection) and/or ssl.log (showing the TLS certificate of the C2 server). This three-log correlation — Suricata alert → conn.log → dns.log + ssl.log — is the investigation pattern you'll use throughout the course.

If no matching uid in dns.log or ssl.log: The connection may have been direct-to-IP (no DNS resolution) or unencrypted (no TLS handshake). Not all connections produce entries in all logs — the uid pivot finds what exists.

Decision point

The ET Open ruleset has approximately 40,000 rules. Running all 40,000 against high-throughput traffic requires significant CPU. Should you disable rules you don't need to improve performance?

For the lab: no. Run all rules. You want maximum detection coverage because you're learning what the rules detect, and disabled rules produce no learning opportunities.

For production: yes, carefully. Disable rule categories that don't apply to your environment (ET INFO rules if you don't want informational alerts, ET GAMES if you don't care about gaming traffic, ET P2P for peer-to-peer protocols). But never disable a category without understanding what's in it — ET MALWARE and ET TROJAN contain high-value detections you don't want to lose.

Module NF8 covers rule management in depth — writing custom rules, tuning false positives, and building a rule management workflow.

Compliance Myth: "Suricata replaces the need for Zeek — they both monitor the network"

Suricata detects known threats. Zeek records what happened. These are different capabilities. Suricata without Zeek tells you "Cobalt Strike detected" but can't tell you which other hosts are also compromised, how much data was exfiltrated, or what the attack timeline looks like. Zeek without Suricata records everything but doesn't alert you when something known-bad happens.

The pair works like this: Suricata fires the alert (something bad matched). You take the Community ID from the alert and find the same session in Zeek logs. Zeek tells you the session duration, byte counts, DNS resolution, TLS certificate, and other context. Then you query Zeek for the same destination IP across all hosts — finding other compromised systems that Suricata may not have alerted on (because the attacker used a slightly different technique that dodged the signature).

Run both. They serve different functions.

NF1.6 — Capture Interfaces and BPF Filters. Zeek and Suricata are installed. NF1.6 covers how to configure the capture interface for live traffic (optional for the lab) and how BPF filters control what traffic the sensor processes.

cat /opt/sensor/suricata-logs/eve.json | \
  jq -r 'select(.event_type=="alert") | .alert.category' | \
  sort | uniq -c | sort -rn

Try it: Count alerts by category

Setup. Your Suricata installation with EVE JSON output from a test PCAP analysis.

Task. Count the Suricata alerts by category:

Expected result. A sorted list of alert categories with counts. Common categories: "A Network Trojan was detected," "Potentially Bad Traffic," "Misc activity." The specific categories depend on what traffic was in your PCAP.

Debugging branch. If no alerts appear: try a different PCAP known to contain malicious traffic. If jq errors: verify eve.json is valid JSON with head -1 /opt/sensor/suricata-logs/eve.json | jq .

Checkpoint — before moving on

1. Run `suricata -V` and verify the version is 7.0 or later. (§ Step 1)

2. Demonstrate the Suricata-Zeek correlation: extract a Community ID from a Suricata alert and find the same flow in Zeek conn.log. (§ Guided Procedure)

3. Explain why running both Zeek and Suricata on the same traffic provides more investigation value than either alone. (§ Compliance Myth)

suricata -V
suricata --build-info | grep -E "AF_PACKET|Rust|EVE"
systemctl status suricata    # (live deployment only)

sudo suricata-update                    # Download and install latest rules
sudo suricata-update list-sources       # Show available rule sources
wc -l /var/lib/suricata/rules/suricata.rules  # Count active rules

sudo suricata -r file.pcap -l /opt/sensor/suricata-logs/
cat eve.json | jq 'select(.event_type=="alert")' | head -20
cat eve.json | jq -r 'select(.event_type=="alert") | "\(.timestamp) \(.alert.signature)"'

# Get CID from Suricata alert
CID=$(cat eve.json | jq -r 'select(.event_type=="alert") | .community_id' | head -1)
# Find same flow in Zeek
grep "$CID" conn.log

# All alerts
cat eve.json | jq 'select(.event_type=="alert")'

# All flow records
cat eve.json | jq 'select(.event_type=="flow")'

# All TLS events
cat eve.json | jq 'select(.event_type=="tls")'

# Disable all ET INFO rules (informational noise for most SOCs)
echo 'group:emerging-info.rules' | sudo tee -a /etc/suricata/disable.conf
sudo suricata-update

Operational Artifact — Suricata Operational Commands

Version and status:

Rule management:

PCAP analysis:

Community ID correlation:

Extended reference — ruleset management, EVE log structure, and performance tuning

ET Open vs ET Pro vs commercial rulesets. Suricata supports multiple rule sources. ET Open is the free, community-maintained set — roughly 40,000 rules covering malware, exploits, C2, and policy violations. ET Pro (paid, subscription) adds earlier access to new rules plus vendor-contributed detections. Commercial rulesets from security vendors add their proprietary detections. For a self-built sensor, ET Open is usually enough — the delta from ET Pro matters most for organizations that receive threat intelligence on same-day new campaigns.

suricata-update list-sources shows all registered sources. suricata-update enable-source et/open registers ET Open (usually enabled by default). Additional sources are added by name; suricata-update update-sources refreshes the list of available sources.

EVE log structure. Suricata writes eve.json in newline-delimited JSON. Each line is one event — alert, flow record, HTTP, DNS, TLS, or other protocol log. Filter by event type:

Key fields across event types: timestamp, flow_id (Suricata's flow identifier, different from Community ID), src_ip, src_port, dest_ip, dest_port, proto, community_id. Alert-specific fields: alert.signature, alert.signature_id, alert.category, alert.severity, alert.metadata.

Rule categorisation and tuning. Rules carry metadata describing their purpose. Common categories: ET MALWARE (confirmed malware), ET TROJAN (trojan families), ET CNC (command-and-control), ET EXPLOIT (exploit attempts), ET SCAN (scanning), ET POLICY (policy violations), ET INFO (informational observations), ET DOS (denial of service), ET HUNTING (threat-hunting queries).

For tuning, disable entire categories rather than individual rules where possible — easier to reason about, easier to re-enable:

False-positive tuning. Specific rules that fire too often get suppressed with either disablesid.conf (stop the rule from running) or threshold.conf (limit how often the alert fires per hour/per source). Use threshold.conf when you want to see the signal but not be overwhelmed by volume; use disablesid.conf when the rule is broken for your environment.

Performance at live-capture rate. Offline PCAP replay processes packets as fast as it can read from disk; live capture processes packets at wire speed. Wire speed exposes different bottlenecks. Three tunables matter most. Runmode — autofp (auto-flow-pinned) is the default; workers mode gives each CPU its own capture thread for very high rates. Ring buffer size — AF_PACKET ring buffer configurable in suricata.yaml under af-packet; default 32MB often under-sized for 10Gbps. CPU pinning — pin Suricata threads to specific CPUs that aren't also handling IRQ for the capture NIC; reduces context-switching overhead.

Monitoring Suricata's own performance. Suricata writes stats.log showing internal metrics — packets processed, packets dropped, alert count, rule evaluation time. The counter that matters for evidence integrity: capture.kernel_drops (non-zero means packets were missed). Monitor this continuously; any increase indicates the sensor is undersized for current traffic.

Multi-tenancy and instance isolation. A single Suricata process can monitor multiple interfaces but shares resources across them. For environments that monitor multiple networks with different policies (e.g., guest network with broad detection plus corp network with tighter rules), run separate Suricata instances with separate rule files rather than mixing policies in one instance. Makes rule management and performance tuning much cleaner.

Integration with the broader SIEM. Suricata's eve.json is the integration surface. Most SIEMs (Splunk, Elastic, Sentinel) have native Suricata log parsers. Ship eve.json via Filebeat, rsyslog, or the SIEM's native forwarder. Field mappings should preserve community_id as a searchable field — it's the primary correlation key with Zeek data and with any other tool that emits Community ID.

You've built the sensor and mapped the evidence landscape.

NF0 established why network evidence matters when every other source is compromised. NF1 built your Zeek + Suricata sensor with the 10 investigation query patterns. From here, every module teaches protocol-specific investigation against real attack scenarios.

DNS deep dive (NF3) — tunnelling detection, DGA analysis, passive DNS infrastructure mapping, and the INC-NE-2026-0227 AiTM phishing DNS trail
Protocol analysis (NF4–NF7) — HTTP/HTTPS, SMB lateral movement, SSH tunnelling, and email protocol investigation with Zeek metadata and PCAP
Detection and hunting (NF8–NF11) — Suricata rule writing, C2 beacon detection with JA3, NetFlow analytics, and proactive network threat hunting
NSM architecture (NF13) — production sensor deployment at 1–10 Gbps with Arkime, Security Onion, and enterprise storage planning
INC-NE-2026-0830 capstone (NF14) — multi-stage investigation using only network evidence: phishing → domain-fronted C2 → lateral movement → DNS tunnel exfiltration

Unlock the full course with Premium See Full Syllabus

Cancel anytime

← Previous Next →