Wireshark and Packet Capture: Principles and First Filters

Reading about layers and protocols is useful, but nothing beats seeing a real packet. In this lesson you will meet Wireshark, the most widely used network analyser in the world, and you will capture and read traffic from your own computer. This is the moment where the abstract vocabulary of chapter 1 becomes concrete, and it is a skill you will use as an administrator, a defender and an ethical hacker alike.

Remember the encapsulation idea from the first lesson: every packet is a set of nested envelopes. Wireshark opens those envelopes one by one and shows you what is inside.

What packet capture is, and what it is not

A packet capture is a recording of the frames that pass through a network interface. A tool that does this is called a sniffer or packet analyser. Wireshark is free and open source, and it understands hundreds of protocols, so it can decode a capture into readable fields.

Capturing is a normal diagnostic technique: network engineers use it every day to find out why an application is slow or why a connection fails. But it touches on privacy. A capture can contain passwords, cookies, messages and personal data, especially when traffic is not encrypted. That leads to a clear rule, which you should treat as non-negotiable:

Installing Wireshark and choosing an interface

Download Wireshark from its official project website, and let the installer add its capture component. On Linux, installation usually goes through the package manager of your distribution, and you may need to give your user the right to capture rather than running everything as the administrator. On first launch you will see a list of network interfaces with a small activity graph next to each: Ethernet, Wi-Fi, loopback, and, once you have a lab, virtual adapters.

Double-click an interface to start capturing. A busy list of lines appears immediately. Press the red square to stop.

Reading the three panes

The main window has three areas that you read from top to bottom:

1. The packet list: one line per packet, with a number, a time, source, destination, protocol and a short summary.
2. The packet details: the selected packet displayed as a tree, one branch per layer (Frame, Ethernet, Internet Protocol, TCP, and the application protocol). Expand each branch to see the fields.
3. The packet bytes: the raw bytes in hexadecimal with their text equivalent.

Click on a packet and expand the layers in the middle pane. You will find the MAC addresses in the Ethernet branch, the IP addresses and the TTL in the Internet Protocol branch, and the ports and flags in the TCP branch. It is exactly the model of lesson 1, now visible.

Capture filters and display filters

A busy network produces far too many packets to read. Wireshark offers two kinds of filters, and beginners often confuse them:

• Capture filters are set before the capture starts and decide what is recorded at all. They use a compact syntax, such as port 53 or host 192.168.56.10. Packets that do not match are lost.
• Display filters are typed in the bar at the top after or during capture and only hide packets from the list. Nothing is deleted. They use Wireshark's own, more expressive syntax.

Display filters are the ones you will use most. The bar turns green when the syntax is valid and red when it is not. Here are the essential ones:

ip.addr == 192.168.56.10
ip.src == 192.168.56.10 && tcp.dstport == 80
tcp.port == 443
dns
http
arp
tcp.flags.syn == 1 && tcp.flags.ack == 0
!(arp || dns)

The operators are what you expect: == for equality, && or and, || or or, and ! or not. The filter tcp.flags.syn == 1 && tcp.flags.ack == 0 shows only the first packet of each new TCP connection, which is a nice way to see who is starting conversations.

Following a conversation

Individual packets are fragments of a story. Right-click a TCP packet and choose Follow > TCP Stream: Wireshark reassembles the whole exchange and shows it as text, with one colour for each direction. For an unencrypted protocol, you can read the actual request and response. For HTTPS, you will only see unreadable data, which is precisely the point of encryption. Seeing both cases side by side is one of the most convincing demonstrations of why HTTPS matters.

The Statistics menu is also worth exploring: Conversations lists pairs of machines that talked, Protocol Hierarchy shows the share of each protocol, and I/O Graph draws traffic over time. Anomalies often jump out of these views before you read a single packet.

What you can and cannot see

On a modern switched network, your network card receives mainly the traffic addressed to it, plus broadcasts. Wireshark can enable promiscuous mode, asking the card to pass up frames that are not addressed to it, but on a switched network there are few such frames to catch. On Wi-Fi, capturing other devices' traffic requires a special "monitor mode" that not all adapters support, and even then, modern encryption protects the content. In your virtual lab, you will use virtual switches and, when needed, mirror the traffic of one machine to another on purpose.

Also keep in mind: encrypted traffic still leaks metadata: who talks to whom, when, how much, and often the server name. Metadata analysis is a field of its own.

Saving and sharing captures

Captures can be saved as .pcapng files. Treat them like sensitive documents, because they may hold credentials and personal data. If you publish a capture for a question or a write-up, anonymise it first or generate it from a lab. Command-line users also have tcpdump (and Wireshark's text-mode companion tshark) for capturing on machines that have no screen:

tcpdump -i eth0 -c 20 port 53
tshark -i eth0 -c 20 -Y dns

The option -c 20 stops after 20 packets, and -i selects the interface. Names of interfaces vary from one system to another, so list yours first.

Your turn: capture a DNS lookup and a web request

On your own computer, start a Wireshark capture on your active interface. In a terminal, run nslookup example.com and then curl -I http://example.com. Stop the capture and apply the display filter dns. Then apply http. Answer these questions in your lab notebook: which transport protocol and port did the DNS query use? What were the source and destination addresses of the query? In the HTTP request, what was the value of the Host header and the method? Finally, use Follow TCP Stream on the HTTP request.

See a solution

The DNS query is carried in UDP, with destination port 53 and a random high source port; the destination address is your DNS resolver (often your router, or a resolver set by your provider or company). The response comes back from the same address and port. The HTTP request shows the method HEAD, because curl -I asks only for headers, and a Host: example.com header. In the followed stream you can read the request and the response in clear text, because plain HTTP is not encrypted. Repeat with https://example.com: you will find a TLS handshake, but the stream content is unreadable. If you see nothing at all, check you selected the right interface.