hack3rs.ca network-security

/learning/network-security-monitoring-zeek-suricata :: module-5

student@hack3rs:~/learning$ open network-security-monitoring-zeek-suricata

Network Security Monitoring with Zeek and Suricata

Learn how Zeek and Suricata complement each other in a monitoring stack: Zeek for rich telemetry and protocol logs, Suricata for signatures and protocol-aware detections.

Teams that only deploy signatures miss context, and teams that only collect telemetry often delay actionable alerts. Combining both improves visibility, triage speed, and detection quality.

learning-objectives

$Explain the different roles of Zeek and Suricata in a network monitoring architecture.
$Identify the most useful logs/outputs for triage and hunting.
$Design a basic sensor placement strategy for meaningful coverage.
$Use findings from one tool to validate or enrich the other.

example-dataflow-and-observation-paths

Use these example dataflows to trace how activity moves through systems and where a defender can observe evidence. This is how learners move from memorizing terms to thinking like investigators.

$Traffic traverses sensor -> Suricata generates alert/flow metadata -> Zeek logs protocol context -> SIEM correlates by IP/time -> analyst validates with host telemetry.
$New suspicious domain observed -> Zeek dns.log finds queries -> conn.log reveals connections -> Suricata confirms signature hits or lack thereof -> triage path adapts accordingly.
$Detection engineering loop: network telemetry -> alert review -> tuning -> retest with PCAP -> redeploy -> monitor noise/coverage.

baseline-normal-before-debugging

$Zeek and Suricata timestamps and host pairs align closely for the same event window.
$Sensor output volumes are stable for baseline traffic and change predictably with load.
$Alerts can be traced to supporting telemetry rather than appearing in isolation.

Expert tip: Baseline normal behavior before writing detections or escalating anomalies. Most tuning and triage errors come from skipping this step.

concept-breakdown-and-mastery

1. Zeek as a Network Telemetry Engine

$ core idea: Zeek excels at producing structured protocol logs (DNS, HTTP, SSL/TLS, conn, files, notices, and more) that support hunting and retrospective analysis. It helps answer “what happened?” at the session and protocol level.

$ defender angle: Zeek logs are especially powerful when correlated across time and hosts. Analysts can pivot on domains, IPs, JA3-like metadata (if available in your pipeline), user agents, and connection histories to build context around suspicious events.

$ prove understanding: Explain the different roles of Zeek and Suricata in a network monitoring architecture.

2. Suricata as a Detection and Inspection Engine

$ core idea: Suricata is widely used for signature-based and protocol-aware detection. It can run in IDS or IPS modes and produces alerts plus metadata logs depending on configuration (for example eve.json outputs).

$ defender angle: Suricata rules are useful, but operational quality depends on tuning, rule sources, policy scope, and performance planning. Blindly enabling everything often creates alert fatigue and missed priorities.

$ prove understanding: Identify the most useful logs/outputs for triage and hunting.

3. Sensor Placement, Coverage, and Correlation

$ core idea: Monitoring quality starts with placement. Place sensors where they can see meaningful traffic: north-south boundaries, critical server segments, remote access aggregation points, and east-west choke points when possible.

$ defender angle: Encrypted traffic limits payload inspection, so metadata and protocol behavior become more important. Zeek and Suricata can still provide valuable visibility even when payloads are not readable.

$ prove understanding: Design a basic sensor placement strategy for meaningful coverage.

deep-dive-notes-expanded

Work through the sections in order. For each section, learn the theory, identify normal behavior, identify failure patterns, then validate with packet/log/CLI evidence.

1. Zeek as a Network Telemetry Engine

Zeek excels at producing structured protocol logs (DNS, HTTP, SSL/TLS, conn, files, notices, and more) that support hunting and retrospective analysis. It helps answer “what happened?” at the session and protocol level.

Zeek logs are especially powerful when correlated across time and hosts. Analysts can pivot on domains, IPs, JA3-like metadata (if available in your pipeline), user agents, and connection histories to build context around suspicious events.

Zeek is not a drop-in replacement for IDS signatures. It provides rich observability and event scripting, which is ideal for custom detections and investigative workflows.

Normal Behavior

Zeek and Suricata timestamps and host pairs align closely for the same event window.

Failure / Abuse Pattern

Alerts fire without enough supporting telemetry because sensors are misplaced or overloaded.

Evidence To Collect

Explain the different roles of Zeek and Suricata in a network monitoring architecture.

2. Suricata as a Detection and Inspection Engine

Suricata is widely used for signature-based and protocol-aware detection. It can run in IDS or IPS modes and produces alerts plus metadata logs depending on configuration (for example eve.json outputs).

Suricata rules are useful, but operational quality depends on tuning, rule sources, policy scope, and performance planning. Blindly enabling everything often creates alert fatigue and missed priorities.

Use Suricata alerts as an entry point, not the end of analysis. Confirm with surrounding network context and host telemetry before escalating severity.

Normal Behavior

Sensor output volumes are stable for baseline traffic and change predictably with load.

Failure / Abuse Pattern

Logs are present but not correlated, causing slow triage and duplicate work.

Evidence To Collect

Identify the most useful logs/outputs for triage and hunting.

3. Sensor Placement, Coverage, and Correlation

Monitoring quality starts with placement. Place sensors where they can see meaningful traffic: north-south boundaries, critical server segments, remote access aggregation points, and east-west choke points when possible.

Encrypted traffic limits payload inspection, so metadata and protocol behavior become more important. Zeek and Suricata can still provide valuable visibility even when payloads are not readable.

A practical workflow is: Suricata alert -> validate with Zeek conn/DNS/HTTP/TLS logs -> pivot to host logs -> decide containment, tuning, or closure.

Normal Behavior

Alerts can be traced to supporting telemetry rather than appearing in isolation.

Failure / Abuse Pattern

Rule or parsing drift causes noise spikes and reduced analyst trust.

Evidence To Collect

Design a basic sensor placement strategy for meaningful coverage.

terminal-walkthroughs-with-example-output

These walkthroughs show representative commands plus example output so learners know what success and useful evidence look like. Treat the output as a pattern guide, not a fixed transcript.

Zeek Basics (Lab Sensor)

Beginner

Command

zeek -r sample.pcap

Example Output

reading sample.pcap ...
writing conn.log dns.log http.log ssl.log

$ why this matters: Use this step to validate zeek basics (lab sensor) before moving on to more advanced commands in the same block. Focus on interpreting the output, not just running the command.

Suricata Basics (Lab Sensor)

Intermediate

Command

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

Example Output

Info: Configuration provided was successfully loaded.
Info: rule files processed successfully.

$ why this matters: Use this step to validate suricata basics (lab sensor) before moving on to more advanced commands in the same block. Focus on interpreting the output, not just running the command.

Correlation First Steps

Advanced

Command

jq 'select(.event_type=="alert") | {ts:.timestamp, src:.src_ip, dst:.dest_ip, sig:.alert.signature}' eve.json

Example Output

# command executed in lab
# review output for expected fields, errors, and anomalies

$ why this matters: Use this step to validate correlation first steps before moving on to more advanced commands in the same block. Focus on interpreting the output, not just running the command.

cli-labs-and-workflow

Run these commands only in environments you own or are explicitly authorized to test. Use a lab VM, sandbox network, or approved internal test segment for practice.

Zeek Basics (Lab Sensor)

Beginner

zeek -r sample.pcap
ls *.log
head -20 conn.log
head -20 dns.log

Run in a lab or authorized environment. Record what fields change when you alter the test conditions.

Suricata Basics (Lab Sensor)

Intermediate

sudo suricata -T -c /etc/suricata/suricata.yaml
sudo suricata -r sample.pcap -c /etc/suricata/suricata.yaml
jq '.event_type' eve.json | sort | uniq -c

Run in a lab or authorized environment. Record what fields change when you alter the test conditions.

Correlation First Steps

Advanced

jq 'select(.event_type=="alert") | {ts:.timestamp, src:.src_ip, dst:.dest_ip, sig:.alert.signature}' eve.json
grep <DEST_IP> conn.log

Run in a lab or authorized environment. Record what fields change when you alter the test conditions.

expert-mode-study-loop

$Explain the concept in plain language without reading notes.
$Show how to validate the concept with logs, packets, or commands.
$Name at least one common failure mode and how to detect it.
$Document what 'normal' looks like before testing edge cases.

Progress marker: You are ready to move on when you can explain the topic, run the commands, and interpret the output without guessing.

knowledge-check-and-answer-key

Try answering these from memory before looking at the hints. These questions are designed to test understanding of concepts, dataflow, and evidence collection.

1. Zeek as a Network Telemetry Engine

Questions

?How would you explain "Zeek as a Network Telemetry Engine" to a new defender in plain language?
?What does normal behavior look like for zeek as a network telemetry engine in your lab or environment?
?Which logs, packets, or commands would you use to validate zeek as a network telemetry engine?
?What failure mode or attacker abuse pattern matters most for zeek as a network telemetry engine?

Show answer key / hints

Answer Key / Hints

#Explain the different roles of Zeek and Suricata in a network monitoring architecture.
#Zeek and Suricata timestamps and host pairs align closely for the same event window.
#zeek -r sample.pcap
#Alerts fire without enough supporting telemetry because sensors are misplaced or overloaded.

2. Suricata as a Detection and Inspection Engine

Questions

?How would you explain "Suricata as a Detection and Inspection Engine" to a new defender in plain language?
?What does normal behavior look like for suricata as a detection and inspection engine in your lab or environment?
?Which logs, packets, or commands would you use to validate suricata as a detection and inspection engine?
?What failure mode or attacker abuse pattern matters most for suricata as a detection and inspection engine?

Show answer key / hints

Answer Key / Hints

#Identify the most useful logs/outputs for triage and hunting.
#Sensor output volumes are stable for baseline traffic and change predictably with load.
#sudo suricata -T -c /etc/suricata/suricata.yaml
#Logs are present but not correlated, causing slow triage and duplicate work.

3. Sensor Placement, Coverage, and Correlation

Questions

?How would you explain "Sensor Placement, Coverage, and Correlation" to a new defender in plain language?
?What does normal behavior look like for sensor placement, coverage, and correlation in your lab or environment?
?Which logs, packets, or commands would you use to validate sensor placement, coverage, and correlation?
?What failure mode or attacker abuse pattern matters most for sensor placement, coverage, and correlation?

Show answer key / hints

Answer Key / Hints

#Design a basic sensor placement strategy for meaningful coverage.
#Alerts can be traced to supporting telemetry rather than appearing in isolation.
#jq 'select(.event_type=="alert") | {ts:.timestamp, src:.src_ip, dst:.dest_ip, sig:.alert.signature}' eve.json
#Rule or parsing drift causes noise spikes and reduced analyst trust.

lab-answer-key-expected-findings

Use this as a baseline answer key for labs and walkthroughs. Replace these with environment-specific observations as you practice in real or simulated networks.

Expected Normal Findings

+Zeek and Suricata timestamps and host pairs align closely for the same event window.
+Sensor output volumes are stable for baseline traffic and change predictably with load.
+Alerts can be traced to supporting telemetry rather than appearing in isolation.

Expected Failure / Anomaly Clues

!Alerts fire without enough supporting telemetry because sensors are misplaced or overloaded.
!Logs are present but not correlated, causing slow triage and duplicate work.
!Rule or parsing drift causes noise spikes and reduced analyst trust.

hands-on-labs

$Install Zeek and Suricata in a lab and inspect their output for the same set of web and DNS transactions.
$Trigger a test Suricata alert and correlate it with Zeek conn.log and dns.log entries.
$Map your current network and propose three sensor placements with clear coverage rationale.

common-pitfalls

$Treating sensor deployment as “set and forget” with no health checks.
$No rule tuning process for Suricata alerts.
$No retention/search strategy for Zeek logs, making investigations slow.

tools-and-references

completion-outputs

# A Zeek + Suricata correlation playbook
# A sensor placement plan with coverage assumptions
# An alert tuning backlog (high-noise to high-value)

<- previous page Packet Capture and Protocol Analysis with Wireshark / TShark -> next page Alert Triage, False Positives, and Detection Tuning

learning-path-position

Detection & Monitoring / Weeks 3-6 · Module 5 of 12