How to use packet captures safely and deliberately
By the end of this module you will be able to:
- Write tcpdump commands using BPF (Berkeley Packet Filter) syntax to capture only the traffic relevant to a specific question
- Explain the difference between capture filters and display filters in Wireshark and when to use each
- Describe the pcap and pcapng file formats and what each captures beyond raw packet bytes
- State the privacy and legal constraints that must be considered before capturing traffic on a production network
Real-world vulnerability · April 2014
Heartbleed: packet captures as the evidence standard for a world-changing bug
On April 7, 2014, the Heartbleed vulnerability (CVE-2014-0160) was publicly disclosed. A missing bounds check in OpenSSL's heartbeat extension meant that an attacker could send a crafted request and receive up to 64 kilobytes of the server's process memory in response, potentially including private keys, session tokens, and user credentials.
The theoretical description was alarming. What made it immediately credible to the security community was that researchers published packet captures demonstrating the attack. A Wireshark capture showing a heartbeat request with an inflated length field, followed by a server response containing memory content, was precise, reproducible evidence. Engineers could load the pcap file, examine the exact bytes, and verify the attack mechanics for themselves without running code.
Those captures also guided the initial triage question: "Is my server actually sending memory content in heartbeat responses?" A targeted tcpdump capturing only port 443 traffic with a heartbeat record type could answer that question in minutes. Packet capture was not the only tool; it was the most specific tool for the specific question of whether bytes were leaving the server that should not be. Specificity is what makes packet capture valuable.
When researchers claimed OpenSSL was leaking private key material, how did they prove it was actually happening in live traffic, not just in theory?
A packet capture starts with a question and ends with deletion
Capture discipline protects users while preserving the evidence needed for diagnosis.
Capture is a discipline. Write the question, then derive the smallest filter that answers it; capture in a ring buffer, stop when the question is answered, store or delete per policy.
A capture point only sees traffic that crosses it
Client, gateway, proxy, server, and span-port captures answer different questions.
A capture point sees only the bytes that cross it. Pick the point closest to the boundary the question is about; otherwise the pcap cannot answer it.
19.1 What packet capture does and does not reveal
Module 18 established that different signal types answer different questions. Packet capture sits at the most detailed end of the spectrum: it records the actual bytes on the wire. For unencrypted protocols, this includes headers and payload content. For TLS-encrypted traffic, it captures the handshake and the encrypted ciphertext; without the session keys, the payload content is opaque.
What packet capture usually reveals, regardless of encryption: source and destination IP addresses, source and destination port numbers, packet timing, sizes, and visible transport behaviour such as TCP flags and sequence numbers. TLS 1.3 encrypts the server certificate after the early handshake. SNI is still visible in many deployments, but Encrypted Client Hello can hide the real ClientHello and SNI where it is deployed. QUIC goes further by encrypting most transport control information that TCP exposes. Capture is still highly informative for connectivity and performance questions, but its visibility boundary is narrower on modern encrypted protocols.
Packet capture does not reveal application semantics from encrypted traffic. It cannot tell you what an HTTPS response contained, only that a response arrived and how large it was. For questions about application-level correctness on encrypted traffic, you need application-level logging, not packet capture.
With the scope and limits of capture understood, the practical question is how to capture only the traffic you need without overwhelming the analysis tool.
19.2 tcpdump and BPF filter syntax
tcpdump is the standard command-line packet capture tool on Linux and macOS. It uses the Berkeley Packet Filter (BPF) engine to apply filters at the kernel level, before packets are passed to userspace. This is the capture filter: it determines which packets are collected at all. A precise capture filter reduces the volume of data written to disk and minimises performance impact on the host.
BPF filter expressions combine primitives with boolean operators. The primitive host 192.168.1.1 matches any packet where either source or destination is that address. tcp port 443 matches TCP traffic on port 443 in either direction. tcp port 443 and host 192.168.1.1 combines them. The not operator excludes traffic: not port 22 avoids capturing the SSH session running tcpdump, which would otherwise create recursive capture noise.
Saving to a file uses the -w flag: tcpdump -i eth0 -w capture.pcap tcp port 443. Reading a saved file for inspection uses -r. Limiting capture size prevents disk exhaustion on busy links: -C 100 rotates to a new file every 100 MB, and -W 5 limits it to five rotation files (a ring buffer).
A capture filter that is too broad collects everything and creates noise. A capture filter that is too narrow misses the packet that answers your question. Start by writing down the specific question in one sentence, then derive the minimum filter expression that captures only the traffic needed to answer it.
tcpdump is the command-line tool for capture. Wireshark adds a graphical layer for dissecting protocol details, and introduces an important distinction between the two filter types.
19.3 Wireshark: capture filters versus display filters
Wireshark is a graphical packet analyser that uses the same libpcap engine as tcpdump for capture. It introduces a second filtering layer that tcpdump does not have: the display filter. Understanding the distinction between them prevents a common mistake.
A capture filter in Wireshark uses BPF syntax and is applied at capture time. Only packets matching the filter are recorded. If you apply a capture filter and then decide you needed different traffic, you must start a new capture. The syntax is the same as tcpdump: tcp port 443, host 10.0.0.1.
A display filter is applied after capture. It hides or shows packets already recorded without discarding them. Display filters use Wireshark's own protocol-aware syntax, which is richer: http.response.code == 200, tcp.flags.syn == 1,dns.qry.name contains "example.com". Changing a display filter is instant and reversible; all packets remain in the capture buffer.
The practical workflow is: use a broad capture filter to minimise volume, capture for a defined time window, then use display filters to explore the captured data. Do not try to make the capture filter so narrow that it answers your question; that is what display filters are for.
With both filter types understood, the remaining practical concern is the file format that stores the captured packets for later analysis or sharing with a colleague.
19.4 pcap and pcapng file formats
The pcap format (libpcap format) is the original packet capture file format. It stores a global header with link-layer type and snapshot length, followed by per-packet records containing a timestamp, captured length, original length, and packet bytes. Every tool in the network analysis ecosystem can read pcap files, making them the universal exchange format for captured traffic.
pcapng (pcap Next Generation) extends pcap with richer metadata. A pcapng file can record multiple capture interfaces in a single file, include interface descriptions, record interface statistics, embed comments on individual packets, and store custom application blocks. When Wireshark saves a capture, it uses pcapng by default. When tcpdump saves a capture, it produces pcap. Both formats are readable by both tools.
The snapshot length (snaplen) controls how many bytes of each packet are captured. The default is typically 262,144 bytes (enough for any Ethernet MTU). Reducing snaplen to 96 bytes captures headers only, which is sufficient for connectivity and routing questions while significantly reducing file size and avoiding inadvertent capture of payload data.
The file format determines what you capture and store. That stored data carries real obligations: the final section addresses who authorises the capture and how the data must be handled afterwards.
19.5 Privacy, legal, and operational safety
Packet capture on a production network is not a routine debugging step. It creates a record of all network activity within its scope, which may include credentials, session tokens, personal data, and privileged business communications. In many jurisdictions, intercepting network communications without authorisation is a criminal offence. In the UK, the Computer Misuse Act 1990 and the Investigatory Powers Act 2016 are relevant; in the EU, GDPR Article 5 governs the principle of data minimisation.
Before capturing traffic on any production or shared network, confirm: you have written authorisation from the system or network owner; the capture scope is limited to the minimum necessary to answer the question; the capture duration is defined and bounded; captured files are handled according to data classification policy and deleted when no longer needed. On shared infrastructure such as cloud environments, the authorisation question extends to the cloud provider's acceptable use policy.
Operationally, running tcpdump on a busy interface consumes CPU and can affect latency on high-traffic hosts. Wireshark running in promiscuous mode on a production host with high packet rates can cause packet loss in the capture itself. Use the -s 96snaplen limit and precise capture filters to reduce this impact. For links above 1 Gbps, hardware-assisted capture (network TAPs, SPAN ports with dedicated capture hardware) is the safer approach.
Common misconception
“Running tcpdump will show me what is wrong with my network.”
Packet capture shows you what bytes were sent and received at the capture point. What is wrong with your network depends on interpreting those bytes in the context of a specific question. Starting a capture without a defined question produces a large file with no clear analysis path. State the question first, then design a capture filter that collects only the packets needed to answer it. Capture is evidence collection, not discovery.
You need to investigate why a specific server (192.168.5.10) cannot establish TLS connections to external servers. You want to capture only the relevant traffic and avoid recording unrelated sessions. Which tcpdump command is most appropriate?
A colleague opens a Wireshark capture and applies the display filter 'tcp.flags.syn == 1 and tcp.flags.ack == 0' to find initial SYN packets. Then they apply 'http.response.code == 404' to find HTTP errors. After reviewing both, they want to see all packets again. What do they do?
Your organisation's security policy requires that packet captures be authorised in writing before collection. You start a capture without authorisation because you are in the middle of diagnosing a critical production incident. What is the correct framing of this situation?
You want to capture only TCP headers without payload data to analyse connection patterns without recording sensitive application content. Which tcpdump option limits the capture to headers only?
Core distinctions
- Packet capture records bytes on the wire. For unencrypted traffic this includes payload; for TLS and QUIC it captures visible headers, timing, sizes, and ciphertext, with SNI and transport details depending on TLS version, ECH deployment, and protocol.
- BPF (Berkeley Packet Filter) capture filters run in the kernel and determine which packets are recorded. They use the same syntax in tcpdump and Wireshark capture mode.
- Wireshark display filters are protocol-aware, reversible, and applied after capture. They hide non-matching packets without deleting them. Use broad capture filters and narrow display filters.
- pcap is the universal exchange format; pcapng extends it with multi-interface support, per-packet comments, and richer metadata. Both are readable by all major analysis tools.
- Packet capture requires explicit authorisation on production and shared networks. Limit scope with BPF filters, bound the duration, and delete captures according to data classification policy.
- State the question before starting a capture. Capture is evidence collection for a specific question, not a general discovery exercise.
Standards and sources cited in this module
tcpdump/libpcap, pcap-filter(7) manual page
Filter Expression overview; Primitives
The authoritative reference for BPF filter syntax used by tcpdump and Wireshark capture filters. Defines the primitive types (host, net, port, proto) and boolean combination rules described in section 19.2.
RFC 9849, TLS Encrypted Client Hello
Abstract and protocol overview
Defines ECH, which changes what passive packet captures can learn from the TLS ClientHello. Referenced in section 19.1.
RFC 9312, Manageability of the QUIC Transport Protocol
Wire image and manageability discussion
Explains QUIC's intentionally limited visible wire image and its implications for packet analysis. Referenced in section 19.1.
Wireshark User's Guide, Chapter 6: Working with Captured Packets
Section 6.3, Filtering Packets while Viewing; Section 4.10, Capture Filters
The official Wireshark documentation that defines the distinction between capture filters (BPF, permanent) and display filters (protocol-aware, reversible). Referenced throughout section 19.3.
IETF PCAP File Format, draft-gharris-opsawg-pcap
Section 3, File Header; Section 4, Packet Record
The IETF specification documenting the pcap file format structure, including the global header, per-packet record layout, and snaplen field. Referenced in section 19.4.
Synacktiv / OpenSSL, Heartbleed CVE-2014-0160 technical analysis
Published April 2014
Technical analysis of the Heartbleed vulnerability including packet capture demonstrations. Provides the technical basis for the opening case study on using pcap evidence to prove memory disclosure.
UK Information Commissioner's Office, Guide to the UK GDPR
Principle (c): Data minimisation
The data minimisation principle is the legal basis for limiting packet capture scope and duration. Referenced in section 19.5 on privacy and legal constraints.
You can now capture evidence safely. Module 20 applies layer knowledge to segmentation: how to constrain blast radius so that one compromised host does not own the entire network, using VLANs, firewalls, and cloud security groups.
Module 19 of 21 · Practice-Strategy