Tools · Network tools · 05 / 24
tcpdump: who sent the bytes, and how many
The arrow shows direction. length shows application bytes in that frame. A lab host that suddenly sends a long run of large frames to an unexpected address is a data-movement question, even when TLS hides the contents.
Direction and length
Each line is source > destination. Summing length in one direction is a rough count of application bytes. It skips ACKs with length 0, and it is not the on-wire total, because headers sit outside length. For a ticket, the rough count is enough: a few hundred bytes is a request, and tens of megabytes is a transfer.
You can see the transfer without reading it. A long run of Flags [P.] from 10.8.0.40 to 10.8.0.20 with length 1460, while the other direction is mostly length 0, means the files VM is sending and the web tier is acknowledging. If the service is supposed to accept uploads, the arrow is backwards and the timestamp goes in the ticket.
When the bytes are readable
-A prints the application bytes as ASCII. -X adds a hex dump. Use them on a lab protocol you already know is cleartext, such as the lab's HTTP health check on port 80. They will also print any secret that protocol carried. Prefer a field summary in tshark when you only need the method and the path. If you do print ASCII, do it in a private terminal, and do not paste the scrollback into chat.
On port 443, -A shows ciphertext that looks like noise, plus maybe a little handshake text. Garbage on the screen is what TLS is for. The finding, if you expected cleartext, would be the opposite situation: readable HTTP on a service the owner said was encrypted.
- length 0 with Flags [.] is an ACK, not a transfer.
- Many length 1460 lines in one direction are a bulk send. 1460 is a common MSS payload.
- -A is a display flag. It does not change the pcap.
- Stop the printout with -c when you only needed to confirm the direction.
A worked defensive case
The lab backup account should pull a small status file from 10.8.0.40 each hour. The 10:00 capture instead shows about a minute of length 1460 frames from 10.8.0.40 port 443 to 10.8.0.27, a workstation that is not the backup host. The return frames are ACKs. You record source, destination, port, start time, and the fact of a large send. You do not try to turn the TLS bytes into a document.
The owner checks the workstation and the backup token. The change they can make today is to restrict which lab addresses may open that service, and to alert when this host sends a volume it has never sent. The pcap stays in the case folder.
Where this is documented
tcpdump(1) documents length in the TCP summary, and -A and -X for ASCII and hex. Byte counts in a ticket should say they are tcpdump's length field, summed in one direction.
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
tcpdump -nn -tttt -r /lab/evidence.pcap 'src host 10.8.0.40 and dst host 10.8.0.27 and tcp port 443'
tcpdump -nn -A -r /lab/evidence.pcap -c 5 'host 10.8.0.20 and tcp port 80'
Diagram
What the arrow says about a long transfer
Same frames, two write-ups
Observation. A minute of large frames from the files VM to a workstation.
Write-up. The ticket quotes a document that TLS never showed.
Risk. The case now claims evidence the capture does not contain.
Observation. 10.8.0.40 sent, 10.8.0.27 acknowledged, port 443, starting at 10:00.
Write-up. Unexpected volume to an address that is not the backup host.
Change. Restrict the service and alert on that volume. Keep the pcap sealed.
Check yourself
1. Most matching lines look like IP 10.8.0.40.443 > 10.8.0.27.51500: Flags [P.], length 1460. Who is sending the bulk of the application bytes?
2. The return path is mostly Flags [.] and length 0. What is that path doing?
3. You add -A on a cleartext lab port and recognize a session token in the ASCII. What do you do with it?