Network Hunting with Zeek and Suricata: Deployment, Rule Tuning, TLS Parsing and Alert-to-Case Processes

Network hunting with Zeek and Suricata is most effective when it is not treated as „yet another sensor“ but as an operational discipline: clean capture architecture, controlled rule tuning, reliable TLS metadata and a process that converts alerts into traceable cases. Zeek (Network Security Monitor, produces structured protocol and flow metadata) and Suricata (IDS/IPS engine, checks traffic against signatures and protocol rules) complement each other very well — but only when deployment and the data path are correct.

This article is aimed at administrators and operators who want a pragmatic start: which sensor topology works in practice? How do you prevent 10,000 alerts a day from paralyzing teams? What is still possible with TLS parsing even though contents are encrypted? And how do you build an alert-to-case process that holds up in audit, incident response and everyday operations?

Network hunting with Zeek and Suricata in practice

Zeek is strong when you want to produce quickly usable metadata from raw packets: connection data (5-tuple, duration, bytes), protocol events (e.g. DNS queries, HTTP headers, TLS handshake data) and file metadata. Suricata is strong when you want to detect known patterns: signatures (classical „rules“), protocol decoders, anomaly detection and — depending on operating mode — inline blocking as an IPS.

In hunting setups Suricata is usually used as an IDS (passive), because inline IPS quickly introduces availability risks: false-positive drops, asymmetric routing, session reassembly issues. Zeek remains passive and is often „more honest“ in data quality — provided capture and timestamps are clean.

Expectation management is important: with TLS you generally do not see contents, but you do see many signals from the handshake and from connection behavior. That is sufficient for many questions (C2 indicators, unusual destination chains, suspicious SNI, certificate anomalies), but it does not replace host telemetry.

Deployment architecture: TAP vs. SPAN, sensor placement and fallback strategy

The biggest source of errors in sensor deployment is not the software but network access. For Zeek/Suricata you need packet capture (PCAP) or AF_PACKET/DPDK-based capture. Crucial are: full visibility, no packet loss and correct time synchronization.

TAP or SPAN?

A TAP (Test Access Point) is a physical split that is typically more stable: it mirrors bits without the switch’s „interpretation.“ A SPAN/mirror port on switches is often available faster, but it brings typical pitfalls: oversubscription (more traffic than the mirror port can carry), incomplete VLAN visibility, packet bursting and — depending on the platform — subtle filtering effects.

• TAP: better for reliable forensics, higher hardware costs, but more reproducible operation.
• SPAN: fast, inexpensive, but you must actively verify drop risk and completeness.

Where to place?

For starting out, three locations are pragmatic:

• Internet edge / perimeter: a good overview of ingress and egress (egress is often more important for Hunting than ingress).
• Data center aggregation: east–west traffic between server networks – relevant for lateral movement.
• Segment with “crown jewels”: databases, ERP/CRM backends, central file services – ideal for focused hunting.

Typical compromise: start with a perimeter sensor (maximum coverage) and later add targeted segment sensors once you know where the main hypotheses lie.

Fallback strategy (Rollback) already in the design

Even passive sensors can disrupt production: mirror configurations can be set incorrectly, sensor NICs can flood switch ports (e.g. in loops), storage can fill up and monitoring systems can fail under log storms. Plan for:

• Mirror/TAP quickly switchable (change plan, clearly labeled ports).
• Operate sensors as “fail-open” (passive); IPS only with separate approval.
• Rate limits and backpressure in the log pipeline (queue, batch, drop policy).
• Capacity limits: PCAP ring buffer, log rotation, storage warning thresholds.

Hardware and performance baseline: avoid drops before tuning rules

Rule tuning is worthless if your sensors lose packets. Packet loss creates artifacts: fragmented TLS handshakes, missing HTTP transactions, incorrect stream reassembly – resulting in ghost alerts and blind spots.

Minimal checklist for sensor hosts

• NIC: server NIC with stable driver; RSS (Receive Side Scaling) enabled, appropriate ring buffer size.
• CPU: sufficient cores, appropriate pinning/worker model; avoid putting everything on core 0.
• Storage: separate volumes for logs/PCAP; IOPS reserve for peaks; test logrotate.
• Time: NTP/Chrony stable; clock drift destroys correlation and case timelines.

Checks: Dropped packets, queue overflow, capture health

Check not only “is the service running”, but “are we processing traffic completely”. Metrics differ by capture backend. Two practical basic tests are: interface statistics (kernel) and sensor statistics (application).

# Interface-Statistiken (Drops, Errors) – Ausgangspunkt
ip -s link show dev eth1

# Kernel- und Treiberzähler (je nach Treiber aussagekräftig)
ethtool -S eth1 | egrep -i 'drop|dropped|miss|error|fifo'

# Ringbuffer/RX-Tuning prüfen
ethtool -g eth1

# CPU/Softirq-Last im Blick: wenn ksoftirqd hoch geht, drohen Drops
top -H

If you already see drops here, typical countermeasures are: reduce mirror load (selective SPAN), change the capture backend (AF_PACKET vs. DPDK), increase the RX ring, set IRQ balancing correctly, or use dedicated sensor hardware.

Suricata Deployment: EVE JSON, Rule-Sets and disciplined update practices

Suricata typically outputs its results as EVE JSON (structured events in JSON format). For operations and integrations this is ideal: SIEM, log management, message bus, or case-management systems can parse events robustly.

Configuration principles that help in daily operations

• Separate the operational and analysis paths: Suricata writes locally; a forwarder (e.g., Filebeat/Fluent Bit/Vector) forwards them onward.
• Version your rules: Git repo or artifact registry; do not perform updates directly on the sensor.
• Update windows: Rule updates are effectively code changes — with a change record and rollback.

Perform rule updates in a controlled manner (example procedure)

# Beispiel: Regeln aktualisieren (Distribution/Tooling variiert je nach Setup)
# 1) Vorher: aktuelle Regeln sichern
sudo tar -C /etc/suricata -czf /var/backups/suricata-rules_$(date +%F).tar.gz rules

# 2) Update aus kontrollierter Quelle (z. B. internes Repo / signiertes Paket)
# (Hier als Platzhalter – in der Praxis per Paketmanager oder suricata-update)
# sudo suricata-update --no-test --reload-command 'systemctl reload suricata'

# 3) Syntax-/Ladeprüfung und anschließend Reload
sudo suricata -T -c /etc/suricata/suricata.yaml
sudo systemctl reload suricata

# 4) Rückfall: falls Alarmflut oder Fehler
# sudo tar -C /etc/suricata -xzf /var/backups/suricata-rules_YYYY-MM-DD.tar.gz
# sudo systemctl reload suricata

Why this procedure works: you separate testing (config/rule check) from activation. And you have a quick rollback option before the pipeline is flooded with incorrect signatures.

Zeek Deployment: metadata as a hunting basis and sensible log selection

Zeek generates many log types (e.g., conn, dns, http, ssl/tls). For operations, less is often more: if you enable ‚everything‘, storage and parsing load increase, and teams lose oversight. Start with a core set that covers typical hypotheses:

• conn: basic connections (who talks to whom, when, how much).
• dns: name resolution (C2 domains, suspected DGA, exfiltration via DNS).
• tls/ssl: handshake metadata (SNI, certificate, versions, ALPN).
• files (optional): file metadata (hashes) — only if you can handle the I/O load.

A common pitfall is correlation across sensors: if you operate multiple sensors, you need unique sensor IDs and consistent time sources. Otherwise two events can become ‚two truths‘.

Checks: Zeek health and log rotation

# Läuft Zeek und schreibt Logs?
sudo systemctl status zeek
ls -lh /opt/zeek/logs/current/

# Rotation/Archive prüfen (Pfad je nach Installation)
find /opt/zeek/logs -maxdepth 2 -type d -name "20*" | tail

# Grober Plausibilitätscheck: wächst conn.log, dns.log, tls/ssl.log?
for f in conn.log dns.log ssl.log tls.log; do
  test -f "/opt/zeek/logs/current/$f" && echo "OK: $f" || echo "MISS: $f";
done

If logs do not rotate or archives are not cleaned up, this is not a cosmetic issue: full filesystems lead to data loss and, at worst, unstable sensors.

Rule-Tuning in Suricata: From Alarm Flood to Reliable Signals

Rule tuning does not mean “disable everything until it is quiet”, but: define expectations, establish baselines, add context and then iteratively refine. The goal is a signal-to-noise ratio a team can actually handle.

Typical Causes for False Positives

• Incompatible networks: Rules fire on internal monitoring, backups, vulnerability scanners or proxy traffic.
• TLS everywhere: Many signatures targeting cleartext protocols are only “half” matched by TLS (SNI/handshake), without real evidence.
• Protocol normalization: Reverse proxies, NAT and load balancers change visibility and lead to „odd“ flows.
• Incomplete reassembly: Packet loss or asymmetric routing generate misleading decoder events.

Practical Tuning Workflow (3 Stages)

1. Stage 1: Cut the noise – clear exceptions for known scanners, internal update servers and management networks. This is not “filtering out attacks”, but removing continuous fire that nobody triages.
2. Stage 2: Enforce context – only alert when multiple conditions match (e.g. target zone + protocol + uncommon destination + unusual port).
3. Stage 3: Integrate with process – each remaining rule is assigned ownership (who maintains it?) and a review cadence.

Important: Tuning should always be data-driven. If you disable rules, document the reason and set a re-evaluation date. Otherwise legacy clutter accumulates and later creates blind spots.

TLS-Parsing: What You Can Reliably Use Without Decryption

TLS parsing means evaluating the unencrypted part of the TLS handshake. This includes, among other things, SNI (Server Name Indication – the requested hostname), certificate chain, version/cipher selection and extensions. Zeek and Suricata can provide valuable metadata here, even when the payload is encrypted.

Which TLS Signals Are Useful in Practice?

• SNI: Often the strongest indicator for destination relationships. Fails for IP-only, ESNI/ECH (obfuscated SNI) or TLS tunnels.
• Certificate: Issuer, subject, validity, self-signed, unusual SAN patterns. Caution: Let’s Encrypt is not „malicious“, but a good baseline is required.
• JA3/JA3S: Fingerprints derived from client/server handshake parameters. Useful for clustering, but not as sole „malware proof“, because fingerprints collide and change.
• ALPN: Negotiation of HTTP/2, HTTP/1.1 etc. Helps with protocol profiling.

When TLS parsing fails: With ECH (Encrypted ClientHello) the classic SNI benefit is reduced. In addition, middleboxes (proxies) can “uniformize” the observable TLS behavior, so you are more likely to fingerprint the proxy than the client.

Pitfalls: Proxy environments and certificate interception

In many organizations a proxy terminates TLS and establishes a new connection to the destination. Then you do not see the real client fingerprint at the perimeter, but the proxy. That is not „bad“, but you must adjust your hypotheses: hunting for „endpoint speaks directly to X“ will not work; hunting for „proxy establishes unusual connections“ can work very well.

Alert-to-Case: From events to actionable cases

An alert is a technical event. A case is a workflow with context, responsibility, timeline and decision. Without this transition, network hunting often ends up as an unmanageable heap of alerts or as a one-off project.

Minimal case dataset that has proven effective

• Identity: Case ID, sensor, time window, affected assets (IP, hostname, user if present).
• Rationale: Which rule/heuristic triggered, which evidence is attached (Zeek log lines, Suricata alert, PCAP reference).
• Context: Asset criticality, known change tickets, maintenance windows, scanner IP list.
• Decision: True/false positive, severity, next action (contain, observe, close).
• Aftercare: Tuning task yes/no, rule owner, follow-up.

Pragmatic correlation design

In practice you do not correlate „everything with everything“, but build a few robust bridges:

• Suricata Alert → Zeek context: same 5-tuple (source/destination/ports/proto) + time window.
• Zeek TLS/DNS → asset DB: IP/hostname to CMDB/inventory (which server is that?).
• PCAP on demand: only for escalated cases; otherwise metadata is sufficient.

This reduces cost: continuous PCAP is expensive (storage, data protection, operations). A „PCAP ring buffer for 2–6 hours“ is often a good compromise to be able to look backwards in an incident without retaining everything constantly.

Log pipeline and data retention: robustness before a „pretty dashboard“

Most failures occur between sensor and analysis: log forwarder blocked, queue fills up, indexer overloaded, timestamps are wrong, fields change after updates. Treat the pipeline like a production system.

Best practices for forwarding and backpressure

• Local spooling: forwarder must be able to buffer (disk queue), otherwise you lose events during short outages.
• Schema control: version EVE JSON/Zeek logs; test parser changes before they go into production.
• Separation of „hot“ and „cold“: active search in the fast index, long-term retention as compressed archives.

Verification steps: time correlation and field stability

When you run hunting, „time“ is a core function. Check regularly:

• Drift between sensor, log collector, SIEM indexer (NTP status).
• Time zones (UTC vs. local time) at all stages.
• Field names/types after updates (e.g., Suricata EVE fields, Zeek log formats).

Troubleshooting: when results do not match your reality

It is normal that the first weeks look „strange.“ The crucial point is to systematically check whether the problem lies in the network, the capture, the parsing, or the process.

Symptom: Many TLS alerts but no corresponding DNS traces

• Cause: DNS is cached/resolved internally (resolver), clients use DoH/DoT (DNS over HTTPS/TLS) or a proxy performs resolution.
• Check: Do you see port 53/853? Are there DoH connections to known resolvers? Is everything going through a proxy?
• Mitigation: Place the sensor closer to clients/resolvers or formulate hypotheses at the proxy level.

Symptom: Rules trigger on „everything“, especially for backups/scans

• Cause: Scanners and backup tools generate patterns similar to exploit scans (many targets/ports/requests).
• Check: Identify the source IP, correlate maintenance windows and the list of tools.
• Mitigation: Create exceptions with clear documentation; use a separate „noise“ policy for management networks.

Symptom: Missing or unstable protocol logs

• Cause: Packet drops, asymmetric routing, incorrect VLAN mirroring, MTU/fragmentation.
• Check: Drops/errors as above, SPAN configuration, compare with NetFlow/firewall logs.
• Mitigation: Use a TAP, select SPAN carefully, adjust sensor NIC/CPU/backend.

Implementation proposal: A usable hunting operation in 14 days

A practical plan is better than „we’ll install it and see.“ The following sequence has proven realistic without overwhelming teams:

Phase 1 (Day 1–3): Visibility and stability

• Deploy a sensor at the perimeter or at an aggregation point (passive).
• Ensure NTP/Chrony is correct, define storage and rotation policies.
• Verify drop-free processing (test during peak times).

Phase 2 (Day 4–7): Make data usable

• Ingest Suricata EVE JSON and Zeek core logs into central logging.
• Initial dashboards/queries: top destinations, new domains, rare SNI, unusual ports.
• Measure alert volume: top-10 rules, top-10 sources, top-10 destinations.

Phase 3 (Day 8–14): Tuning and case process

• Noise reduction with documented exceptions.
• Define a case template (fields, ownership, small-scale SLAs).
• Weekly review: which rules provide value, which do not, which hypotheses are missing.

Conclusion: Hunting is operations — and Zeek/Suricata are your sensors

Zeek and Suricata together provide a very robust foundation for network hunting if you first secure capture quality, then iteratively tune rules and correctly interpret TLS metadata. The greatest leverage is not in „more rules“ but in the alert-to-case process: clear responsibilities, reproducible evidence, and a feedback loop that continuously improves tuning and data quality.

If you want to deepen this topic around API security, centralized secrets management or remote access logging, the next step should always be the same: increase visibility purposefully, but only where you can operationalize the findings.

For this topic, IDS/NSM architecture and Suricata rule tuning are also important. This article places these aspects in context and shows what matters in day-to-day operations.