What is packet capture?
Packet capture is recording network traffic packet by packet, with every header and the full payload, so it can be decoded, searched and replayed later. The saved result, also called a packet capture or pcap, is usually stored in the pcap or newer pcapng file format, which nearly every analysis tool reads. Captures are taken with tools such as tcpdump, dumpcap and tshark, Wireshark, the pktmon utility built into Windows, and full packet capture appliances that record a link around the clock. A protocol analyzer is the tool that decodes captured packets; the capture is the evidence it works on.
Where captures are taken
- On the host: shows only that machine's traffic, but includes traffic that never crosses a monitored link.
- From a mirror port: a switch copies chosen ports or VLANs to the sensor's port. It is cheap and flexible but can drop packets when the mirrored traffic exceeds the destination port's speed.
- From a tap: a hardware device installed in a link copies every frame, including errors, to monitor ports.
- In the cloud: virtual traffic mirroring sends copies of a virtual machine's traffic to a capture instance.
The capturing interface normally runs in promiscuous mode so it accepts frames addressed to other devices. Capture filters, written in Berkeley Packet Filter syntax, decide what gets recorded, while Wireshark display filters decide what is shown from a file already saved.
Example: pulling answers out of a capture
An IDS alert says a laptop downloaded a suspicious file over HTTP. The sensor's rolling capture covers the time, so the analyst extracts that window and lists every web request in it:
tshark -r lt0419-alert.pcapng -Y "http.request" -T fields -e frame.time -e ip.src -e http.host -e http.request.uri
One line shows the laptop requesting /invoice_8841.js from an unfamiliar host seconds before the alert, and Wireshark's object export recovers the script for analysis. Before passing the file on, the analyst records its hash with sha256sum lt0419-alert.pcapng, so anyone can later confirm the evidence was not changed.
Limits and handling
Full captures are large. A 10 Gbps link averaging 30 percent utilization produces about 1.35 TB per hour, more than 32 TB a day, so most organizations keep full packets for hours or days and flow records for months. Encryption limits what a capture can show: TLS traffic still reveals addresses, ports, sizes, timing and usually the server name in the handshake, but not the content unless the session keys are available or the traffic was decrypted at an inspection point. Captures also contain whatever crossed the wire, including passwords sent over cleartext protocols and personal data, so restrict access, store them encrypted, and handle them as evidence, with hashes and a chain of custody, whenever an investigation may depend on them.
Packet capture vs. flow data
| Packet capture | NetFlow or IPFIX | |
|---|---|---|
| Contents | Everything, including payload | Metadata only |
| Size | Very large | Small |
| Usual retention | Hours to days | Weeks to months |
| Best question | What exactly was sent? | Who talked to whom, when and how much? |
Packet capture on the CompTIA Security+ exam
Packet capture appears in two SY0-801 objectives. In objective 4.4, packet analyzers fed by port mirroring or taps are monitoring tools; in objective 4.8, packet captures are a data source for investigations. Wording that needs the contents of traffic, such as "which file was transferred," "what DNS names were queried," "the exact commands sent" or "how the exploit was delivered," points to a packet capture. Wording about volume or patterns over weeks points to NetFlow or IPFIX instead. Remember too that a sensor fed by a mirror port or tap can see and alert but cannot block, because the original traffic has already been delivered.