Recording and Analysing Network Traffic

As Security Education Lead at ISKRA Protect, I turn technical concepts into practical exercises. I designed this lab for my students to explore network traffic hands-on: capture it, inspect it, and understand what the packets actually tell us.

Now I’m sharing it with you. Two terminals, a few tools, and a little curiosity. Let’s start.

What We Will Explore

This exercise introduces packet capture and analysis on Debian. We will use tcpdump to record traffic, TShark to inspect it from the command line, and Wireshark to explore it visually.

The focus is on:

• Observing conventional DNS and unencrypted HTTP traffic.
• Understanding the structure and contents of capture files.
• Extracting IP addresses, DNS query names and HTTP request details.
• Rewriting IP addresses in a working copy.
• Inspecting capture file information.

These skills provide a starting point for incident response, network troubleshooting and further analysis scripts.

Run the exercise on your own lab system or within an explicitly authorized environment. Generate ordinary test traffic and keep the capture focused on the exercise.

Step 1: Prepare Your Tools

The required tools are:

• tcpdump
• TShark
• Wireshark
• tcprewrite, provided by the tcpreplay package
• curl
• dig
• capinfos, provided by the Wireshark tool suite

On Debian, dig is available through the dnsutils package. Its presence depends on how the system was installed.

Step 2: Identify the Network Interface

Display the available interfaces:

ip a

For this exercise, I use enp0s3. Replace it in the following commands with the interface your system uses for the test traffic.

A VPN or local DNS resolver can change where packets appear. If a capture stays empty, check the traffic path before changing the capture filter.

Step 3: Capture DNS Traffic

In Terminal 1, start recording:

sudo tcpdump -i enp0s3 port 53 -w dns_test.pcap

In Terminal 2, generate DNS requests:

dig debian.org
dig google.com
dig openai.com

Return to Terminal 1 and stop the capture with Ctrl + C.

The filter selects traffic using port 53. This exercise covers conventional DNS over UDP or TCP. Encrypted DNS using other ports falls outside this filter.

Depending on your resolver configuration, you may see requests to a local resolver or upstream traffic. Cached answers can also affect what appears in the recording.

Step 4: Capture HTTP Traffic

In Terminal 1:

sudo tcpdump -i enp0s3 port 80 -w http_test.pcap

In Terminal 2:

curl neverssl.com

Stop the capture with Ctrl + C.

I chose neverssl.com because it provides a straightforward HTTP endpoint without automatically redirecting the request to HTTPS.

In a successful capture, we can inspect information such as the request method, Host header, request path and response content.

An HTTPS capture still contains useful network metadata, but the HTTP headers and body are normally protected by TLS.

Step 5: Rewrite IP Addresses in a Working Copy

Captured traffic can contain identifying information. Before sharing a recording, inspect what it actually contains.

For this demonstration, I use tcprewrite to modify IPv4 addresses in a copy of the DNS recording:

sudo tcprewrite --infile=dns_test.pcap --outfile=anon_dns.pcap \
  --srcipmap=0.0.0.0/0:192.0.2.1 --dstipmap=0.0.0.0/0:198.51.100.1 \
  --fixcsum

The command rewrites source and destination IPv4 addresses using the specified mappings. --fixcsum recalculates the relevant checksums.

This broad mapping demonstrates header rewriting. Because source and destination addresses are rewritten separately, it can obscure the original relationships between hosts and the direction of an exchange.

The same approach can be applied to the HTTP recording.

The filename anon_dns.pcap is only a label. It does not establish that the recording is fully anonymized. DNS names, HTTP headers, payload content, MAC addresses and IPv6 addresses require separate consideration.

Keep the original recordings and document changes made to working copies.

Step 6: Analyse DNS with TShark

Display DNS packets:

tshark -r anon_dns.pcap -Y "dns"

-r reads the saved capture. -Y applies a display filter, so TShark shows packets identified as DNS.

Look for the requested names, query types and responses. Where possible, follow a query and its corresponding reply.

Keep the previous rewriting step in mind: the displayed IP addresses have been modified and the original host relationships may have been obscured.

Step 7: Inspect the Recording in Wireshark

Open the DNS recording:

wireshark anon_dns.pcap

Select a packet and inspect the packet list, decoded protocol fields and raw bytes.

Expand the DNS section and compare a query with its response.

Remember the difference: a capture filter controls what you record; a display filter controls what you see from an existing recording.

Step 8: Inspect Capture File Information

Before working with several recordings:

capinfos anon*

The shell expands anon* to matching filenames in the current directory. Capinfos then reports information about those capture files, such as their format, packet count and recording times.

This is useful for checking what you have collected before further analysis.

Capinfos inspects files; it does not combine them into a new recording.

Step 9: A Little Extra from Irina

Packets tell stories. Sometimes I want the raw version: hex, ASCII, and nowhere for an ordinary plaintext request to hide.

My original capture command is:

sudo tcpdump -w anon_http.pcap -nn -X

Here is what the options do:

• -w anon_http.pcap saves packets to a capture file.
• -nn keeps addresses and ports numeric when packet details are printed.
• -X requests a hex and ASCII view when packets are decoded for display.

With -w, tcpdump normally writes the packets instead of displaying their decoded contents. We inspect the saved recording in the next command.

This command contains neither an explicit interface nor a capture filter. Tcpdump selects an interface automatically, and the recording can contain traffic beyond HTTP. Use it within your authorized lab and check which interface tcpdump reports.

Also, the filename does not anonymize the captured data.

Stop the recording with Ctrl + C, then read it back:

tcpdump -r anon_http.pcap -nn -X

-r means “read”. Now -X gives us the hex and ASCII view of the saved packets.

Think of it as packet X-ray vision. Plaintext may become readable, while encrypted content remains encrypted.

Capture first, inspect second. Your future self will appreciate the saved file.

Before You Finish

Check that you can:

• Explain which interface and filters you used.
• Identify a DNS query and its response.
• Recognize information contained in unencrypted HTTP traffic.
• Distinguish a capture filter from a display filter.
• Explain what the IP rewriting step changes.
• Explain why rewriting IP headers alone leaves other identifying information.
• Inspect the metadata of your capture files.

Network traffic always tells a story. The interesting part is learning what the packets support—and where your assumptions begin.

Have fun :)

You can find the illustrated version of this article with screenshots here.