In this module

NF1.6 Capture Interfaces and BPF Filters

10 hours · Module 1 · Free

What you already know

You know what promiscuous mode is and why the capture interface shouldn't have an IP. This sub covers the practical configuration — setting up the interface, writing BPF filters to focus capture on relevant traffic, and the AF_PACKET mechanism that lets Zeek and Suricata share the same interface.

Operational Objective

The capture interface is where raw network traffic enters the sensor. Misconfiguring it — wrong interface, checksum offload enabled, IP address assigned — produces corrupted or incomplete evidence. BPF (Berkeley Packet Filter) filters control which traffic the sensor processes. A well-designed BPF filter reduces sensor load and storage requirements. A poorly designed filter silently excludes evidence you need.

This sub covers interface configuration for both live capture (optional in the lab) and the AF_PACKET sharing mechanism that lets Zeek and Suricata process the same traffic simultaneously.

Deliverable: A properly configured capture interface (or understanding of the configuration for when you deploy to live traffic) and the BPF filter syntax for common capture scenarios.

Estimated completion: 25 minutes

Figure NF1.6 — The four capture interface requirements. All four must be configured correctly for live capture. For PCAP replay (the primary lab workflow), interface configuration is unnecessary — the tools process files from disk.

Interface Configuration for Live Capture

This section is for optional live capture on your lab network. If you're only using PCAP replay (recommended for the course), read this for understanding and skip the configuration steps.

If you added a second network adapter to your VM (bridged mode, as mentioned in NF1.1), configure it for capture. First, identify the interface name:

ip link show

The management interface (NAT) has an IP address. The capture interface (bridged) either has no IP or has one assigned by DHCP. You need to remove the IP and set the interface to promiscuous mode with no IP.

# Replace ens38 with your capture interface name
sudo ip addr flush dev ens38
sudo ip link set ens38 promisc on
sudo ip link set ens38 up

Disable checksum offload — virtual NICs calculate checksums in software and report incorrect values to the kernel, which confuses Zeek and Suricata's protocol parsers:

sudo ethtool -K ens38 rx off tx off gro off lro off

Verify the configuration:

ip addr show ens38    # Should show no inet address
ip link show ens38    # Should show PROMISC flag
ethtool -k ens38 | grep -E "rx-checksumming|tx-checksumming|generic-receive-offload"

BPF Filter Syntax

BPF filters control which packets the sensor processes. The right filter reduces load without losing evidence. The wrong filter silently drops traffic you need.

BPF (Berkeley Packet Filter) is a kernel-level packet filter that operates before packets reach Zeek or Suricata. BPF filters use a simple syntax:

host 10.0.1.15                    # Traffic to/from a specific host
net 10.0.0.0/8                    # Traffic to/from a network
port 443                          # Traffic on a specific port
not port 53                       # Exclude DNS traffic
tcp and port 445                  # SMB traffic only
host 10.0.1.15 and not port 123  # Host traffic excluding NTP

Filters combine with and, or, not, and parentheses. The filter is applied at capture time — filtered packets are never seen by the processing engines.

Common sensor BPF filters for production:

# Exclude sensor management traffic (SSH, NTP, DNS to resolver)
not (host SENSOR_IP and (port 22 or port 123 or port 53))

# Capture only traffic to/from the internet (exclude internal-only)
not (net 10.0.0.0/8 and net 10.0.0.0/8)

# Focus on a specific investigation target
host 203.0.113.88 or host 10.0.1.15

For the lab, don't apply a BPF filter. You want to see all traffic in the PCAP files. BPF filters are used in production to manage sensor load on high-throughput links.

When you apply a BPF filter to Zeek:

zeek -r file.pcap -f "host 10.0.1.15"

When you apply a BPF filter to Suricata, add it to suricata.yaml under the af-packet section, or pass it on the command line:

suricata -r file.pcap -l /opt/sensor/suricata-logs/ -- "host 10.0.1.15"

In production, Zeek and Suricata both need to see the same traffic. AF_PACKET with cluster/fanout mode distributes packets to both tools without duplication.

AF_PACKET is a Linux kernel mechanism for high-performance packet capture. When configured with fanout mode, the kernel creates a group that distributes copies of every packet to all members. Zeek joins the group as one member, Suricata as another. Both see every packet. Neither interferes with the other.

For the lab, AF_PACKET sharing isn't needed — you run Zeek and Suricata separately against the same PCAP file. The output is identical to what live AF_PACKET sharing would produce. The configuration details for AF_PACKET live deployment are covered in NF13 (NSM Architecture for Production).

Guided Procedure — Test BPF Filter Syntax

Step 1. Run Zeek against a test PCAP without a BPF filter and count the connections.

Expected output: `zeek -r test.pcap && grep -v '^#' conn.log | wc -l` gives the total connection count (e.g., 5,000).

If the count is zero: Verify the PCAP file path and that Zeek completed without errors.

Step 2. Run Zeek with a BPF filter that selects only port 443 traffic.

Expected output: `zeek -r test.pcap -f "port 443" && grep -v '^#' conn.log | wc -l` gives a smaller count — only HTTPS connections. The count should be less than the total from Step 1.

If the count is the same: The BPF filter may not have been applied. Check for error messages in Zeek's output. Ensure the `-f` flag is before the filter string.

Step 3. Run Zeek with a BPF filter excluding DNS (port 53) and compare the dns.log output.

Expected output: `zeek -r test.pcap -f "not port 53"` should produce no dns.log file (or an empty one). The filter excluded all DNS traffic, so Zeek's DNS analyzer had nothing to parse.

If dns.log still has entries: Some DNS traffic may use non-standard ports. The BPF filter `not port 53` only excludes traffic on port 53 — DNS-over-HTTPS on port 443 isn't filtered by this rule.

Decision point

Your production sensor monitors a 2 Gbps internet link, but the sensor hardware can only handle 1 Gbps of processing. You need a BPF filter to reduce the load.

Option A: not port 80 and not port 443 — exclude all HTTP and HTTPS traffic (the bulk of web browsing), keeping DNS, SMB, SSH, and other protocols. This reduces volume dramatically but blinds you to web-based C2, malware downloads over HTTP, and HTTPS exfiltration.

Option B: not (net 10.0.0.0/8 and net 10.0.0.0/8) — exclude internal-only traffic, keeping all traffic that crosses the network boundary. This keeps all external-facing traffic (C2, exfiltration, initial access) while dropping internal lateral movement.

Option C: host CRITICAL_SERVER_1 or host CRITICAL_SERVER_2 or net SENSITIVE_VLAN — focus only on traffic to/from specific high-value targets. Maximum load reduction but misses anything not on the target list.

The right answer depends on your threat model. For most organizations, Option B is the best balance — it keeps the highest-priority evidence (external communications) while reducing load from internal traffic that's better monitored by a core switch sensor. Option A drops too much valuable evidence. Option C is useful for targeted investigation but too narrow for continuous monitoring.

Compliance Myth: "BPF filters only matter for live capture — they don't affect PCAP analysis"

BPF filters work identically on PCAP files and live traffic. When you run zeek -r file.pcap -f "host 10.0.1.15", Zeek only processes packets matching the filter — everything else in the PCAP is skipped. This is useful for targeted investigation (processing only the suspicious host's traffic from a large PCAP) but dangerous if you forget the filter is applied.

The risk: you run Zeek with a filter, see zero connections to the C2 IP, and conclude the host didn't communicate with the attacker. But the filter excluded the relevant traffic. Always verify whether a BPF filter is applied before drawing conclusions from Zeek output. Check packet_filter.log — it records the active filter.

NF1.7 — Sensor Validation. Your sensor is built. NF1.7 validates that everything works — Zeek produces complete logs, Suricata fires alerts, Community ID correlation succeeds, and no evidence gaps exist.

Try it: Write a BPF filter for an investigation scenario

Setup. Your sensor VM with Zeek installed and a test PCAP.

Task. Write BPF filters for three scenarios: (1) Capture only traffic involving a specific C2 IP (203.0.113.88). (2) Capture all traffic except DNS and NTP. (3) Capture only SMB traffic (port 445) between two specific hosts. Test each filter against your PCAP with zeek -r test.pcap -f "YOUR_FILTER" and verify the output matches expectations.

Expected result. (1) host 203.0.113.88 — conn.log contains only connections to/from that IP. (2) not port 53 and not port 123 — dns.log is empty, all other logs populated. (3) host 10.0.1.15 and host 10.0.2.10 and port 445 — conn.log shows only SMB between those hosts.

Debugging branch. If the filter produces syntax errors: BPF uses and, or, not — not &&, ||, !. Parentheses group conditions: (host A or host B) and port 445.

Checkpoint — before moving on

1. List the four capture interface requirements for live deployment and explain why each matters. (§ Interface Configuration)

2. Write a BPF filter that captures traffic to/from a specific host while excluding DNS. (§ BPF Filter Syntax)

3. Explain why you don't need capture interface configuration for PCAP replay and when AF_PACKET sharing becomes necessary. (§ AF_PACKET Interface Sharing)

Operational Artifact — BPF Filter Reference

Common BPF primitives: host IP (traffic to/from IP), net CIDR (traffic to/from network), port N (traffic on port), proto PROTOCOL (tcp, udp, icmp), src host IP (from IP only), dst host IP (to IP only).

Operators: and (both conditions), or (either condition), not (exclude). Parentheses for grouping.

Production filters: Exclude sensor self-traffic: not host SENSOR_IP. Exclude internal-only: not (net 10.0.0.0/8 and net 10.0.0.0/8). Investigation focus: host TARGET_IP or host C2_IP.

Verification: Always check packet_filter.log after applying a filter. Verify conn.log entries match expectations. An unexpected zero count may mean the filter excluded the target traffic.

Extended reference — advanced BPF patterns, filter optimization, and capture-interface architectures

Advanced BPF patterns for investigation. Beyond the common primitives, several patterns come up repeatedly in investigation work.

Byte-offset matching. BPF can match specific byte values at specific offsets in the packet. Useful for protocol-level filtering beyond ports. Example — capture only TCP SYN packets (connection starts): tcp[tcpflags] == tcp-syn. Capture TLS client hellos specifically: tcp[((tcp[12:1] & 0xf0) >> 2)+5:1] = 0x01 and tcp dst port 443 — matches the handshake type byte at the right offset in the TCP payload.

Multi-port expressions. For capturing across a range of ports: portrange 1024-65535. For multiple specific ports: port 53 or port 5353 or port 443. BPF optimizer handles the chain efficiently.

Combining with VLAN tags. If the sensor sees VLAN-tagged traffic, default BPF primitives don't see through the VLAN header. Use the vlan keyword: vlan and host 10.0.1.50. Multiple VLAN tags (QinQ): vlan and vlan and host 10.0.1.50. The vlan keyword shifts the offset before the rest of the filter applies.

Fragmented packet handling. Fragmented IP packets have the MF (more fragments) flag set or a non-zero fragment offset. To capture only fragmented traffic: ip[6:2] & 0x3fff != 0. To exclude fragmented traffic (focus on fully-reassembled flows in downstream analysis): ip[6:2] & 0x3fff = 0.

Filter optimization and complexity limits. BPF filters are compiled to in-kernel bytecode with size and complexity limits. Very long expressions (hundreds of clauses) may hit limits or degrade performance.

Three optimization patterns. One, use network-level filters rather than host-level when possible — net 10.0.1.0/24 is faster than host 10.0.1.50 or host 10.0.1.51 or .... Two, place the most-selective clauses first in and expressions — short-circuit evaluation means the first failing clause ends the evaluation. Three, avoid double negation — not (not A) is slower than A even though they mean the same thing.

For filters with many exclusions, consider the alternative: capture everything, filter in post-processing. Disk is cheaper than the CPU overhead of complex kernel filters, especially at high traffic rates.

Capture-interface architectures. The interface that feeds the sensor determines what traffic it sees; different architectures have different evidence implications.

SPAN port (port mirroring). The switch duplicates traffic from specified ports to the SPAN destination. Pros: simple, no additional hardware. Cons: SPAN ports are oversubscribable — if mirroring 10Gbps of traffic to a 1Gbps SPAN destination, packets drop silently at the switch. Validate SPAN capacity before relying on it as the sole evidence source.

Network TAP. A physical device inline with the network that duplicates traffic to two output ports (one for each direction). Pros: can't be oversubscribed (TAP has dedicated capacity), fail-open or fail-closed behaviour depending on model. Cons: requires hardware, requires downtime to install, adds a link in the cable path.

SPAN vs TAP trade-off. For test environments, SPAN is fine. For production evidence collection at scale, TAPs are the standard — the evidence integrity guarantee is much stronger.

Packet broker. Between the SPAN/TAP and the sensor, a packet broker can deduplicate, filter, and load-balance traffic to multiple sensors. Common brokers: Gigamon, Ixia, Arista. For large-scale deployments, brokers offload filtering from sensors (better performance) and enable horizontal scaling (multiple sensors behind one broker). Overkill for a single-sensor deployment.

Asymmetric routing and its consequences. If the sensor sees only one direction of a conversation (inbound or outbound but not both), protocol reassembly breaks. Zeek can't reconstruct TCP streams; TLS handshake analysis fails; HTTP request/response correlation fails.

Check for asymmetric routing by examining conn.log entries with history fields missing either the uppercase (originator) or lowercase (responder) characters for a given protocol. A healthy bi-directional TCP flow's history includes ShAdDaFf or similar (both sides visible); asymmetric flows show only half of this.

Fix: work with network team to ensure the SPAN or TAP sees both directions. For TAPs, this means both output ports wired into the sensor; for SPAN, the mirror configuration must specify both direction or equivalent.

Promiscuous mode mechanics. Ethernet interfaces by default drop frames not addressed to their MAC. Promiscuous mode (ip link set promisc on) disables this filter, allowing the interface to receive all frames on the wire. For a capture interface connected to a SPAN or TAP, promiscuous mode is required — the mirrored traffic has source/destination MACs that don't match the sensor's MAC.

Verify promiscuous mode is on: ip link show | grep PROMISC. Note that many modern NICs in some virtualization environments silently drop promiscuous mode on; if the sensor sees only its own traffic, check this first.

Sizing the capture pipeline. Three bottleneck points. One, the NIC — must be able to receive wire-speed traffic without hardware drops (check ethtool -S | grep drop). Two, the kernel — AF_PACKET ring buffer must be large enough for bursts; default is usually small. Three, the userspace tools — Zeek and Suricata must process packets faster than they arrive on average; transient bursts are absorbed by the ring buffer, sustained overload produces drops.

For a 1Gbps monitored link, a modern x86 server with 4-8 CPU cores and 16GB RAM usually suffices. For 10Gbps, expect 16+ cores and 32-64GB RAM, plus careful tuning of CPU pinning and ring buffer sizing. For 40Gbps and above, dedicated capture hardware (Napatech, Endace) is usually necessary.

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 →