Tools · Network tools · 06 / 24
tcpdump: keep the file small, private, and ready to hand off
A useful capture is bounded, flushed to disk, and stored like any other sensitive note. tcpdump is the wrong place to hunt for an application field once you know which conversation matters.
Bounds that keep a capture usable
-c stops after a number of frames. -s 0 keeps the default snapshot so you do not chop headers. -U writes each frame through to the file, so a capture you stop with Ctrl-C is still readable. Without -U, a file or a pipe can sit empty in the reader until the buffer fills.
Name the file for the case, not capture.pcap in a home directory you share. Record the interface, the filter, the clock, and who was allowed to copy it. Delete it when the engagement says to. A pcap from the lab is still full of whatever the lab protocols exposed.
- Write the filter into the ticket next to the filename.
- Prefer a host and a port over a whole NIC when the question names them.
- Checksum warnings on -v are often offload artifacts. -K skips the check so you can read the frame. Keep the file either way.
- Hand the same file to tshark or Zeek when you need fields or logs. Do not recapture just to change tools.
When to stop using tcpdump
tcpdump is the right tool to prove a conversation existed, to show flags, and to slice a file down to two hosts. It is a poor tool for a table of every DNS name, for HTTP methods across thousands of requests, or for joining a connection to a later log line. That is tshark's field output and Zeek's logs.
It is also the wrong tool for a reconstructed file or a host inventory. NetworkMiner does that from the same pcap. Stay in tcpdump until the question is about frames. Leave when the question is about a column, a count, or a carved object.
A worked defensive case
You have /lab/evidence.pcap, filtered to the files conversation, flushed with -U, and copied into the case directory. The ticket says: interface eth0, filter host 10.8.0.20 and host 10.8.0.40 and tcp port 443, start 10:14:01, handshake completed, client RST at 10:14:06, file retained until Friday.
The application owner asks which HTTP path returned 500. Port 443 is TLS, so tcpdump's ASCII will not show a path. You hand them the same file and move to tshark for handshake metadata, or to the server log for the status code. You do not start a second, wider capture because a column was hard to read.
Where this is documented
tcpdump(1) documents -c, -U, -K, and -w. The retention rule comes from the engagement, not from the tool.
Use a host-only lab network, or a capture the owner already handed you. These commands read that file or record a single lab host. They are not a scan of the public internet.
Commands
sudo tcpdump -i eth0 -s 0 -U -w /lab/evidence.pcap -c 200 'host 10.8.0.20 and host 10.8.0.40 and tcp port 443'
tcpdump -nn -r /lab/evidence.pcap -c 3
Diagram
Where a tcpdump file goes next
Pick the tool that matches the question
- Stay with tcpdump
You still need flags, direction, or a tighter host and port slice.
- Move to tshark
You need a column: SNI, a count of conversations, or a display filter across the file.
- Move to Zeek or NetworkMiner
You need logs you can join, or a host and file inventory of cleartext objects.
Check yourself
1. You stop a capture with Ctrl-C and tshark says the file is truncated. Which flag makes a short lab capture more likely to be complete on disk?
2. The owner wants the HTTP path that returned 500, and the only frames are TLS on port 443. What do you hand them?
3. What belongs next to the filename in the ticket?