SEC401 - Data Security Technologies
Lab 4.3 - Intrusion Detection and Network Security Monitoring with Snort3 and Zeek
Solo, Lab
Focus: Intrusion Detection
Level: SEC401
Date: Apr 2026
Artifacts: Sanitized terminal screenshots of Snort3 config validation, PCAP replay alerts, BPF-filtered runs, and Zeek log review
TL;DR
- •Validated Snort 3.1.73 config, scoped HOME_NET to the lab /16, replayed investigate.pcap through community rules
- •Triaged 294 INDICATOR-SHELLCODE ssh CRC32 overflow alerts from 20.106.124.93 hitting 10.130.8.94:22
- •Re-ran Snort with BPF focus and processed the same PCAP with Zeek + extract-all-files policy
Skills demonstrated
Note: Course-provided PCAPs and lab instructions are not shared. Only my own captures and sanitized notes are published.
Why this matters
Signature-based IDS (Snort) and protocol-aware NSM (Zeek) are the two workhorses of mid-market network monitoring. Knowing how to tune rules, scope HOME_NET, filter noise with BPF, and pivot into Zeek logs for file extraction is the day-to-day job of a SOC analyst triaging a detection.
Context
This lab runs two IDS/NSM tools against the same investigation PCAP: Snort3 for signature-based detection and Zeek for protocol-aware logging and file extraction. The goal is to understand what each tool tells you, and where they overlap vs. complement each other.
Tools used
Steps taken
1Validate the Snort3 config
Ran Snort in test mode to confirm the lab's snort.lua loads cleanly. The output shows Snort 3.1.73.0 enumerating every compiled-in inspector: HTTP, HTTP2, TLS/SSL, SMTP, SSH, FTP, DCE-RPC variants, DNS, IEC104, Modbus, NetFlow, port_scan, the wizard (protocol auto-id), and stream reassembly for TCP/UDP/ICMP. Good baseline view of what Snort3 actually inspects out of the box.
$ snort -T -c /sec401/labs/4.3/etc/snort.lua-Ttest configuration and exit-cpath to snort.lua2Scope HOME_NET to the lab /16
Replaced HOME_NET = 'any' with HOME_NET = '[10.130.0.0/16]' via sed. HOME_NET = any is the default but defeats most rules that pivot on direction ($HOME_NET vs. $EXTERNAL_NET). Setting a real CIDR makes rules meaningful.
$ sed -i 's/HOME_NET = \'any\'/HOME_NET = \'[10.130.0.0/16]\'/' /sec401/labs/4.3/etc/snort.lua3Quiet re-validation
Re-ran config test with -q to suppress startup noise. Clean exit means the HOME_NET edit is syntactically valid.
$ snort -T -c /sec401/labs/4.3/etc/snort.lua -q-qquiet mode (suppress banners)4PCAP replay with community rules: summary view
Replayed investigate.pcap through Snort with the community rules and alert_talos output. The summary groups alerts by SID and signature: SERVER-WEBAPP robots.txt access (14), backup access (15), POLICY-OTHER Microsoft Windows Terminal server request attempt (218), INDICATOR-SHELLCODE ssh CRC32 overflow filler (294), PROTOCOL-ICMP Unusual PING (15). The 294-alert ssh CRC32 row is the obvious thing to pivot on — that's a classic 2001-era exploit signature.
$ snort -c etc/snort.lua -q -r investigate.pcap -A alert_talos -R rules/snort3-community.rules-rread from PCAP-A alert_talosTalos-style summary (grouped)-Rruleset to load5Per-alert detail with alert_fast
Switched output mode to alert_fast for one-line-per-alert detail. Clearly shows [1:1325:14] INDICATOR-SHELLCODE ssh CRC32 overflow filler — Classification: Executable code was detected, Priority 1 — TCP 20.106.124.93 → 10.130.8.94:22. Every alert traces to the same source IP hammering the same host's SSH port with what Snort identifies as exploit shellcode fillers.
$ snort -c etc/snort.lua -q -r investigate.pcap -A alert_fast -R rules/snort3-community.rules-A alert_fastone alert per line (best for piping to grep/awk)6BPF filter to focus the attacker
Re-ran with --bpf 'host 20.106.124.93' to scope the analysis to one attacker IP. In a real PCAP triage, --bpf is how you drop the haystack size by 99% so the analyst can work on a specific host/port/flow without the ruleset processing noise.
$ snort -c etc/snort.lua -q -r investigate.pcap -A alert_fast -R rules/snort3-community.rules --bpf 'host 20.106.124.93'--bpfBerkeley Packet Filter expression; same syntax as tcpdump7Zeek: protocol-aware log + file extraction
Switched to Zeek on the same PCAP with the extract-all-files policy. Zeek produces per-protocol logs (conn.log, http.log, ssh.log, files.log) and can reconstruct files out of flows. The directory listing shows packet_filter.log as the first artifact; after a longer run Zeek emits the full protocol-log set.
$ zeek -C -r ../investigate.pcap -f 'host 20.206.124.93' /opt/zeek/share/zeek/policy/frameworks/files/extract-all-files.zeek-Cskip checksum validation (PCAP checksums often broken)-rread from PCAP-fBPF filterextract-all-files.zeekreconstruct files from HTTP/FTP/SMB flows8Inspect Zeek log schema
Pulled the field list from packet_filter.log using sed. The #fields header lists ts, node, filter, init, success, failure_reason — Zeek's self-describing tab-separated format. Every Zeek log carries this header, which makes downstream parsing (zeek-cut, awk, Splunk) trivial.
$ sed -n 7p packet_filter.log | sed 's/\t/\n/g'sed -n 7pprint line 7 (the #fields header)sed 's/\t/\n/g'convert tabs to newlines for readabilityKey findings
Outcome / Lessons learned
Reproduced the full Snort3 tuning and detection workflow, identified an SSH CRC32 overflow exploit attempt with 294 Priority-1 alerts from a single attacker IP, then processed the same PCAP with Zeek to demonstrate how NSM complements signature IDS with protocol context and file extraction.
Ship Snort alerts and Zeek logs into the SIEM (Splunk/Elastic) with source-IP correlation. Tune HOME_NET and suppress chatty low-fidelity rules (PROTOCOL-ICMP Unusual PING) so analysts aren't drowning in noise. Write a custom Snort rule for the specific CRC32 overflow pattern if the community rule is too broad, and pipe Zeek extracted files into a sandbox for automated detonation.
Security controls relevant
- Network IDS (Snort, Suricata)
- Network security monitoring (Zeek)
- Alert tuning and HOME_NET scoping
- SOC playbooks for Priority-1 exploit signatures
- Retention of PCAP + Zeek logs for retrospective hunting
- File extraction + sandbox detonation pipelines
What I took away from this
Snort and Zeek solve different halves of the problem and most teams pick only one. Snort tells you a known-bad pattern matched; Zeek tells you what actually happened on the wire, in context, regardless of whether a signature exists. Running them side by side on the same traffic is how you catch signatures for known attacks and still have log fidelity when a novel one shows up.
HOME_NET = 'any' is the configuration bug nobody talks about. Many rules are written with directional context ($EXTERNAL_NET -> $HOME_NET), so leaving HOME_NET at the default means those rules either over-trigger or never trigger at all. On a new Snort deployment, fixing HOME_NET is step zero before you evaluate any ruleset quality.
The 294-alert SSH shellcode result is a good reminder that signature IDS is still useful — the CRC32 exploit is old, but the same pattern shows up in modern scanner tooling that hasn't been updated. Pairing that signal with Zeek's ssh.log (client software, auth success/failure counts, session duration) is how you go from 'IDS says exploit' to 'here's exactly what the attacker did next.' That's the pivot analysts get paid for.