🔬 02-05: Reading Packets — Wireshark & tcpdump¶
📌 Why Learn to Read Raw Packets?¶
Every concept so far — encapsulation, TCP flags, sequence numbers, ports — has been described on paper. Packet capture tools let you actually see this stuff happening on a live network. This is one of the single most important practical skills in network security: you cannot detect, analyze, or defend against an attack you can't recognize in a capture.
Two tools dominate this space:
| Tool | Interface | Best For |
|---|---|---|
| tcpdump | Command line | Servers, containers, remote boxes with no GUI — lightweight and scriptable |
| Wireshark | Graphical | Deep visual inspection, following streams, color-coded analysis, teaching/learning |
💡 Many practitioners use both: tcpdump to capture traffic on a headless server (saving it to a file), then transfer that file to a desktop and open it in Wireshark for detailed visual analysis.
🖥️ Getting Started with tcpdump¶
tcpdump captures packets directly from a network interface and prints a summary line per packet (or writes them to a file for later analysis).
Basic Usage¶
# Capture on interface eth0, don't resolve IPs to hostnames (-n keeps output fast and readable)
sudo tcpdump -n -i eth0
# Add more verbosity (-vvv) and a filter for a specific port
sudo tcpdump -n -i eth0 -vvv "tcp port 179"
# Save captured packets to a file instead of printing them, for later analysis in Wireshark
sudo tcpdump -i eth0 -w /tmp/packets.pcap
-i <interface>— which network interface to listen on (e.g.,eth0,wlan0)-n— skip DNS reverse lookups on addresses (faster, avoids extra noise/traffic)-w <file>— write raw captured packets to a.pcapfile instead of printing a summary-vvv— increase verbosity for more header detail per packet
Filter Examples (BPF Syntax)¶
tcpdump filters use Berkeley Packet Filter (BPF) syntax — the same filter language Scapy uses for its own sniffing filters:
# Only capture DNS traffic (port 53)
sudo tcpdump -i eth0 port 53
# Only capture traffic to/from a specific host
sudo tcpdump -i eth0 host 10.0.0.5
# Combine conditions: HTTP traffic to a specific host
sudo tcpdump -i eth0 host 10.0.0.5 and port 80
🦈 Getting Started with Wireshark¶
Wireshark provides the same packet capture capability as tcpdump, but displays every packet in a structured, expandable, color-coded interface — and lets you apply much richer display filters after capturing (as opposed to capture filters, which use BPF syntax and are applied before/during capture).
Wireshark Display Filter Examples¶
tcp.port == 80 # Show only traffic to/from TCP port 80 (HTTP)
ip.addr == 10.0.0.5 # Show only traffic to/from a specific IP
dns # Show only DNS packets
tcp.flags.syn == 1 # Show only segments with the SYN flag set
http.request # Show only HTTP request packets
💡 Note the syntax difference: Wireshark's display filters (tcp.port == 80) use a dotted field-name syntax and are far more expressive than tcpdump's capture filters (port 80), because display filters run against packets Wireshark has already fully parsed and stored, not against a live, resource-constrained capture stream.
Reading the Wireshark Window¶
Wireshark's main view has three stacked panes:
- Packet list — one row per captured packet, with a quick summary (source, destination, protocol, info).
- Packet details — the selected packet's headers shown as collapsible layers, exactly mirroring the encapsulation stack from 01-03: Frame → Ethernet → IP → TCP/UDP → Application protocol.
- Packet bytes — the raw hex/ASCII bytes of the packet, with the currently selected field highlighted.
🕵️ Identifying a TCP Handshake in a Capture¶
Once you filter to a single conversation (e.g., tcp.port == 443 or host 10.0.0.5), a normal connection setup shows a very recognizable three-packet pattern at the start:
No. Time Source Destination Protocol Info
1 0.000 10.0.0.5 93.184.216.34 TCP 51000 → 443 [SYN] Seq=0
2 0.021 93.184.216.34 10.0.0.5 TCP 443 → 51000 [SYN, ACK] Seq=0 Ack=1
3 0.021 10.0.0.5 93.184.216.34 TCP 51000 → 443 [ACK] Seq=1 Ack=1
A practitioner scanning a capture learns to recognize this [SYN] → [SYN, ACK] → [ACK] sequence instantly — it's the visual fingerprint of 02-01's three-way handshake actually happening. If you only ever see a lone [SYN] with no reply, that's a strong sign the destination port is closed/filtered, or (in an attack scenario) a sign of a SYN flood in progress.
🔍 Identifying a DNS Query in a Capture¶
Filtering to dns (Wireshark) or port 53 (tcpdump) isolates DNS traffic. A simple lookup looks like this:
No. Time Source Destination Protocol Info
1 0.000 10.0.0.5 8.8.8.8 DNS Standard query 0x1a2b A example.com
2 0.015 8.8.8.8 10.0.0.5 DNS Standard query response 0x1a2b A 93.184.216.34
Notice this is UDP, not TCP — there's no handshake before the query, matching what you learned in 02-03: UDP & Connectionless Protocols. A practitioner examining a suspicious capture would check things like:
- Does the response's transaction ID (
0x1a2b) match the query? (Mismatched or unexpected IDs can indicate a spoofed response — see 06-05: DNS Cache Poisoning.) - Did multiple responses arrive for a single query? (A strong indicator of a race-condition-based spoofing attempt, like the Kaminsky attack.)
- Does the source IP of the response actually match a legitimate, expected DNS server?
🧰 Practical Workflow Tips¶
- Always filter before you scroll. A busy interface can capture thousands of packets per second; use capture filters (tcpdump) or apply a display filter immediately (Wireshark) rather than scrolling through unfiltered noise.
- Follow the stream. Wireshark's "Follow → TCP Stream" feature reconstructs the full back-and-forth of one conversation as readable text — invaluable for reading an HTTP request/response pair in full.
- Save captures for later. A
.pcapfile is a permanent record — useful for incident response, teaching, or replaying traffic through analysis tools later. - Practice on your own traffic first. Capturing your own browser's traffic while you load a familiar site is the fastest way to build pattern recognition before analyzing something unfamiliar or malicious.
📌 Key Takeaways¶
- tcpdump is a lightweight, scriptable, command-line capture tool, ideal for servers and containers; Wireshark is a graphical tool ideal for deep visual analysis.
- tcpdump capture filters and Wireshark capture filters both use BPF syntax (
port 53,host 10.0.0.5); Wireshark display filters use a richer dotted syntax (tcp.port == 80,dns). - Wireshark's packet details pane mirrors the encapsulation stack directly: Frame → Ethernet → IP → TCP/UDP → Application.
- A TCP handshake is recognizable in a capture as the
[SYN]→[SYN, ACK]→[ACK]three-packet pattern. - DNS queries appear as UDP traffic on port 53 with no handshake — a lookup is just one query packet and one response packet under normal conditions.
- Anomalies worth watching for in a DNS capture include mismatched transaction IDs and multiple responses to a single query — both signs of possible spoofing.
- Filtering aggressively and using "Follow Stream" are the two habits that turn an overwhelming raw capture into something actually readable.