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

Network security monitoring with Zeek and Suricata gives defenders two complementary layers: Zeek produces rich protocol logs for hunting and retrospective analysis, while Suricata fires signatures and protocol-aware alerts. Neither alone is sufficient.

Signature-only shops get blindsided when attacks use legitimate tools or novel techniques — the signature never fires. Telemetry-only shops have data but no timely alerts, so investigations happen after the damage is done. Combining Zeek and Suricata gives you both the early warning and the contextual evidence to act on it.

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

Trace each step and identify which log or capture point gives you evidence at that stage. Most triage mistakes happen when someone skips a hop and draws conclusions from an incomplete picture.

$Packet hits the sensor NIC -> Suricata inspects against loaded rules, writes alert to eve.json, writes flow metadata -> Zeek logs the same connection to conn.log with protocol context, writes DNS queries to dns.log -> SIEM ingests both -> analyst correlates the alert IP against Zeek's conn.log duration and byte counts.
$A Suricata alert fires on an outbound connection -> grab dest IP and timestamp -> filter Zeek conn.log for that IP in the same window -> check dns.log to see if the host queried a domain just before the connection -> correlate with endpoint logs to find the originating process.
$New detection rule deployed -> replay a known-bad PCAP against Suricata with `-r sample.pcap` -> confirm the expected SID fires -> run the same PCAP against Zeek -> verify conn.log and dns.log have the expected entries for correlation.

baseline-normal-before-debugging

$Zeek conn.log and Suricata flow events for the same connection share the same source IP, dest IP, dest port, and overlap in timestamp within a few milliseconds.
$Sensor packet drop counters in Suricata stats events stay at zero during normal load; any non-zero drop count means the sensor is losing evidence.
$Every Suricata alert has a corresponding Zeek conn.log entry for the same flow; an alert without a conn.log entry suggests a sensor gap.

Expert tip: Record what normal looks like in your actual environment before you test any edge case. A baseline you measured beats a baseline you assumed every time.

concept-breakdown-and-mastery

1. Zeek as a Network Telemetry Engine

$ core idea: Zeek parses protocols and writes structured logs: conn.log for connection metadata, dns.log for query and response details, http.log for request and response headers, ssl.log for TLS certificate and handshake data, files.log for file transfers, and notice.log for policy-triggered events. Each log type answers different investigative questions.

$ defender angle: The value of Zeek logs compounds when you pivot across them. A suspicious domain in dns.log connects to an IP in conn.log, which connects to a certificate in ssl.log and a user-agent in http.log. That chain builds investigative context that no single alert can provide.

$ 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 built for signature-based and protocol-aware detection. It runs in IDS mode (alert only) or IPS mode (block and alert), and its eve.json output format makes it easy to ingest into log pipelines and SIEMs. Rules can match on payload content, protocol fields, thresholds, and behavioral patterns.

$ defender angle: Rule quality and tuning define operational value. Blindly enabling every available ruleset produces alert fatigue within days. Start with a focused ruleset tied to your threat model, then tune based on false positive patterns and asset context. A smaller, well-tuned ruleset is more actionable than a large noisy one.

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

3. Sensor Placement, Coverage, and Correlation

$ core idea: Sensor placement determines what you can see. North-south chokepoints catch traffic crossing network boundaries. East-west coverage catches lateral movement inside the environment. Remote access aggregation points capture VPN and remote session traffic. Place sensors where traffic is dense and meaningful, not just where it is convenient.

$ defender angle: Encrypted traffic removes payload visibility but leaves metadata and protocol behavior intact. Zeek and Suricata can still detect anomalous connection patterns, unexpected certificate issuers, unusual DNS behavior, and volume-based indicators even when they cannot read the payload.

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

deep-dive-notes-expanded

Read each section, then immediately test the concept in your lab. Theory that you have not verified with a real command or log line does not stick.

1. Zeek as a Network Telemetry Engine

Zeek parses protocols and writes structured logs: conn.log for connection metadata, dns.log for query and response details, http.log for request and response headers, ssl.log for TLS certificate and handshake data, files.log for file transfers, and notice.log for policy-triggered events. Each log type answers different investigative questions.

The value of Zeek logs compounds when you pivot across them. A suspicious domain in dns.log connects to an IP in conn.log, which connects to a certificate in ssl.log and a user-agent in http.log. That chain builds investigative context that no single alert can provide.

Zeek is not a drop-in IDS. It does not alert on signatures by default. It provides structured observability and a scripting interface for custom detection logic — which is ideal for hunting workflows and bespoke detections, but it requires a separate approach than signature-based tools.

Normal Behavior

Zeek conn.log and Suricata flow events for the same connection share the same source IP, dest IP, dest port, and overlap in timestamp within a few milliseconds.

Failure / Abuse Pattern

Suricata drops 3% of packets during a traffic spike — the stats.json event shows `capture.kernel_drops > 0`; detections during that window are unreliable.

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 built for signature-based and protocol-aware detection. It runs in IDS mode (alert only) or IPS mode (block and alert), and its eve.json output format makes it easy to ingest into log pipelines and SIEMs. Rules can match on payload content, protocol fields, thresholds, and behavioral patterns.

Rule quality and tuning define operational value. Blindly enabling every available ruleset produces alert fatigue within days. Start with a focused ruleset tied to your threat model, then tune based on false positive patterns and asset context. A smaller, well-tuned ruleset is more actionable than a large noisy one.

Treat a Suricata alert as an entry point, not a conclusion. Confirm with surrounding network context from Zeek logs and relevant host telemetry before deciding severity and response action.

Normal Behavior

Sensor packet drop counters in Suricata stats events stay at zero during normal load; any non-zero drop count means the sensor is losing evidence.

Failure / Abuse Pattern

Zeek conn.log has entries for the alert window but nobody checked them — the alert and the logs were in separate dashboards and the analyst only looked at the alert queue.

Evidence To Collect

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

3. Sensor Placement, Coverage, and Correlation

Sensor placement determines what you can see. North-south chokepoints catch traffic crossing network boundaries. East-west coverage catches lateral movement inside the environment. Remote access aggregation points capture VPN and remote session traffic. Place sensors where traffic is dense and meaningful, not just where it is convenient.

Encrypted traffic removes payload visibility but leaves metadata and protocol behavior intact. Zeek and Suricata can still detect anomalous connection patterns, unexpected certificate issuers, unusual DNS behavior, and volume-based indicators even when they cannot read the payload.

A repeatable triage workflow: a Suricata alert fires, you validate it against Zeek conn.log and dns.log to build context, you pivot to host logs to identify process and account, then you decide whether to contain, tune, or close.

Normal Behavior

Every Suricata alert has a corresponding Zeek conn.log entry for the same flow; an alert without a conn.log entry suggests a sensor gap.

Failure / Abuse Pattern

A Suricata rule fires 2,000 times per day on one signature — without checking whether the volume is new, analysts stop trusting it; verify with a before/after count on the signature ID.

Evidence To Collect

Design a basic sensor placement strategy for meaningful coverage.

terminal-walkthroughs-with-example-output

Each walkthrough shows a command and what useful output looks like. Your lab output will differ — focus on which fields to read, not on matching the exact values shown here.

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: Run this against your lab environment and read the output field by field before moving on to the next command in this block. If you cannot explain what you see, re-read the section on zeek basics (lab sensor).

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.

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

cli-labs-and-workflow

Run these in a lab VM or network segment you own or are authorized to test against. After each command, write down one thing the output told you that you did not already know.

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 out loud as if briefing a colleague — no notes.
$Pick one CLI command and walk through exactly what the output means field by field.
$Name a specific failure mode and the log line or packet flag that reveals it.
$Write down what normal looks like for your lab before you introduce any anomaly.

Progress marker: Move on when you can brief the topic to someone else, run the commands from memory, and explain what a bad result looks like.

knowledge-check-and-answer-key

Answer each question out loud or in writing before you look at the hints. If you cannot answer it, go back to the section that covers it — do not just read the hint and move on.

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 conn.log and Suricata flow events for the same connection share the same source IP, dest IP, dest port, and overlap in timestamp within a few milliseconds.
#zeek -r sample.pcap
#Suricata drops 3% of packets during a traffic spike — the stats.json event shows `capture.kernel_drops > 0`; detections during that window are unreliable.

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 packet drop counters in Suricata stats events stay at zero during normal load; any non-zero drop count means the sensor is losing evidence.
#sudo suricata -T -c /etc/suricata/suricata.yaml
#Zeek conn.log has entries for the alert window but nobody checked them — the alert and the logs were in separate dashboards and the analyst only looked at the alert queue.

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.
#Every Suricata alert has a corresponding Zeek conn.log entry for the same flow; an alert without a conn.log entry suggests a sensor gap.
#jq 'select(.event_type=="alert") | {ts:.timestamp, src:.src_ip, dst:.dest_ip, sig:.alert.signature}' eve.json
#A Suricata rule fires 2,000 times per day on one signature — without checking whether the volume is new, analysts stop trusting it; verify with a before/after count on the signature ID.

lab-answer-key-expected-findings

These are reference answers for a generic environment. Replace them with observations from your own lab — what you measured yourself is more useful than what is written here.

Expected Normal Findings

+Zeek conn.log and Suricata flow events for the same connection share the same source IP, dest IP, dest port, and overlap in timestamp within a few milliseconds.
+Sensor packet drop counters in Suricata stats events stay at zero during normal load; any non-zero drop count means the sensor is losing evidence.
+Every Suricata alert has a corresponding Zeek conn.log entry for the same flow; an alert without a conn.log entry suggests a sensor gap.

Expected Failure / Anomaly Clues

!Suricata drops 3% of packets during a traffic spike — the stats.json event shows `capture.kernel_drops > 0`; detections during that window are unreliable.
!Zeek conn.log has entries for the alert window but nobody checked them — the alert and the logs were in separate dashboards and the analyst only looked at the alert queue.
!A Suricata rule fires 2,000 times per day on one signature — without checking whether the volume is new, analysts stop trusting it; verify with a before/after count on the signature ID.

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)

related-tool-guides

Each of these tools is directly relevant to the evidence collection or validation steps in this topic. Use them to close the gap between reading a concept and running it.

open /learning/tools/zeek Zeek open /learning/tools/suricata Suricata open /learning/tools/security-onion Security Onion

related-threat-pages

See where these fundamentals appear in real attack scenarios and what evidence defenders look for during triage.

open /threats/lateral-movement-after-initial-access Lateral movement after initial access open /threats/dns-abuse-tunneling-and-command-control DNS abuse, tunneling, and command-and-control

<- 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