Sign In
In this module

NF1.13 Check My Knowledge

10 hours · Module 1 · Free
Test your understanding of sensor deployment and operation. Each question targets a specific concept from NF1.
1. You've installed Zeek and processed a PCAP. The conn.log has 5,000 entries but ssl.log has zero entries. What is the most likely explanation?
Zeek's SSL analyzer failed to load — reinstall Zeek
The PCAP doesn't contain TLS traffic — all connections used unencrypted protocols
ssl.log requires a separate Zeek configuration that wasn't enabled
The PCAP is corrupted — re-download and reprocess
Answer: B. Zeek only creates protocol-specific logs when it observes that protocol. No TLS traffic means no ssl.log. The SSL analyzer is loaded by default — no separate configuration needed. Verify with `cat conn.log | zeek-cut service | sort | uniq -c` to see which protocols Zeek detected. Review NF1.4 § Tier 1 — ssl.log.
2. What is the purpose of Community ID in the sensor configuration?
It identifies the sensor in a multi-sensor deployment
It encrypts log data for secure storage
It generates a standardized hash for each network flow, enabling correlation between Zeek and Suricata for the same session
It assigns a unique ID to each alert for SIEM ingestion
Answer: C. Community ID is a standardized flow hash calculated from the 5-tuple. Both Zeek and Suricata generate the same hash for the same flow, letting you pivot from a Suricata alert to the corresponding Zeek conn.log, dns.log, and ssl.log entries. Review NF1.3 § Step 3 and NF1.5 § Step 2.
3. Why should the capture interface have no IP address assigned?
An interface with an IP generates its own traffic (ARP, DHCP, NTP), which contaminates the capture with sensor-generated packets
An IP address enables the interface to route traffic, which would disrupt the network
Without an IP, the interface captures packets faster because the TCP/IP stack isn't processing them
IP addresses are limited resources and shouldn't be wasted on monitoring interfaces
Answer: A. An interface with an IP participates in the network — sending ARP requests, responding to ICMP, potentially running DHCP. This traffic appears in Zeek logs as sensor-generated connections, contaminating the evidence. A capture interface should be invisible on the network. Review NF1.6 § Interface Configuration.
4. You run `zeek -r test.pcap -f "not port 53"` and the resulting dns.log is empty. Why?
The test PCAP doesn't contain DNS traffic
Zeek's DNS analyzer doesn't work in offline mode
The `-f` flag disables all protocol analyzers
The BPF filter excluded port 53 traffic, so Zeek's DNS analyzer had no packets to parse
Answer: D. The BPF filter `not port 53` excludes all DNS traffic (standard DNS uses port 53). Zeek's DNS analyzer requires packets on port 53 to parse. No packets means no dns.log entries. This demonstrates both BPF power and risk — a filter can silently exclude evidence. Check packet_filter.log to verify what filter was applied. Review NF1.6 § BPF Filter Syntax.
5. Which Zeek log field serves as the universal join key across all Zeek log files for the same network session?
community_id — the standardized flow hash
uid — the unique connection identifier
ts — the timestamp
id.orig_h — the source IP address
Answer: B. The `uid` field is generated by Zeek for each connection and appears in conn.log, ssl.log, http.log, files.log, and other protocol-specific logs for the same session. Community ID (A) links Zeek and Suricata, but doesn't appear in all Zeek logs. Timestamp (C) isn't unique. Source IP (D) identifies the host, not the specific session. Review NF1.4 § conn.log.
6. Your sensor's chrony NTP shows no synchronised sources. What is the most critical impact on your investigation capability?
Zeek will not start without NTP synchronisation
Suricata rules will not load without accurate time
All timestamps in Zeek logs and Suricata alerts are unreliable, preventing correlation with endpoint evidence
The sensor will not capture packets without accurate time
Answer: C. Both tools run without NTP, and the sensor captures packets regardless. But every timestamp in every log is derived from the system clock. If the clock is wrong, a conn.log entry that should correlate with an endpoint event at 14:22:15 might show 14:25:15. Desynchronised timestamps make cross-source correlation unreliable. Review NF1.2 § Step 2 and NF0.9 § Timestamp Integrity.
7. You need to find all internal hosts that communicated with a known C2 IP (203.0.113.88). Which investigation query pattern is most efficient?
Pattern 9: grep the C2 IP in conn.log, extract unique originator IPs — each unique IP is a potentially compromised host
Pattern 7: use UID pivot to find the connection in dns.log and ssl.log
Pattern 4: find the largest outbound transfers and check if any go to the C2 IP
Pattern 10: search for the JA3 hash of the C2 connection across all TLS sessions
Answer: A. Pattern 9 directly answers the scoping question: how many hosts are compromised? `grep "203.0.113.88" conn.log | zeek-cut id.orig_h | sort -u` gives the unique internal IPs. Pattern 7 (B) gives detail on a single connection, not scope. Pattern 4 (C) finds exfiltration, not C2 hosts. Pattern 10 (D) is useful after you have the fingerprint, but scope comes first. Review NF1.8 § Correlate Patterns.
8. Suricata has been running for 3 weeks with zero alerts. What should you verify?
Nothing — zero alerts means your network is clean
Reinstall Suricata — the alert engine is broken
Replace Suricata with a commercial IDS that produces more alerts
Verify suricata-update is running, rules are loaded (check rule count), and the sensor is actually receiving traffic (check EVE stats for processed packets)
Answer: D. Zero alerts for 3 weeks could mean a clean network, but it's far more likely that something is wrong: stale rules, failed rule loading, or the sensor isn't receiving traffic. Verify the rule count (`wc -l suricata.rules`), check that suricata-update cron is running, and check the EVE JSON stats for packets processed. A working sensor on a busy network should produce at least informational alerts. Review NF1.9 § Troubleshooting.
💬

How was this module?

Your feedback helps us improve the course. One click is enough — comments are optional.

Thank you — your feedback has been received.
© 2026 Ridgeline Cyber Defence™ Ltd. Content may not be reproduced or redistributed. Worked artifacts may be adapted for use within your organization.

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 →