Step 84. Wireshark 2 — Dissecting Protocols and Detecting Anomalies

Level 1 — Programming and the Inside of a Computer | Difficulty ★★★☆☆ | Estimated time: 3 hours

Prerequisites: Step 83 complete. You can capture and apply filters with Wireshark (or tshark). You can run the nmap scans from Step 81.

• What you need: Wireshark and your lab. With tshark, everything reproduces on the command line too.
• Caution: ⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime. The target of the scan experiments is also only 127.0.0.1. Every packet output in this chapter was measured on 2026-09-09 on WSL Linux (TShark 4.2.2), and GUI screen descriptions are “Screen examples.”

For a doctor to recognize illness, they must first know a healthy body. Networks are the same. To find “strange packets,” you must first know what “normal packets” look like. Today we dissect the normal appearance of TCP, DNS, and HTTP one by one under the microscope, and at the end we deliberately trigger the nmap scan from Step 81 to confirm what face it wears in a packet list. An experiment where you stamp the footprints of an attack with your own hands and see them with your own eyes.

1. Learning Objectives

By the end of this chapter, you will be able to:

• Find the TCP 3-way handshake as three packets in a real capture
• Explain the normal shape of a DNS question-answer pair
• Read the fields of an HTTP request-response in packet details
• Identify the “signature” of scan traffic in a packet list
• Apply the three faces of anomaly — an answer with no pair, abnormal frequency, content beyond common sense

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

2-1. TCP — A Conversation That Begins with a Handshake

Every TCP conversation begins with the 3-way handshake. SYN (let’s begin) → SYN-ACK (very well, let’s) → ACK (confirmed). The very ritual you built by hand in Step 80. The normal shape: three packets fire in rapid succession, then data flows.

2-2. DNS — The Phone Book Lookup

DNS (Domain Name System) converts names like example.com into numeric addresses. The normal shape is one clean pair — one Query (question), one Response (answer). Examples of warning signs: an answer arriving when no question was asked (the shadow of DNS poisoning), or traffic asking the same name over and over like mad.

2-3. HTTP — A Pair of Request and Response

A pair of request (GET /) and response (200 OK). In plaintext, headers and body are all readable. Today we pair up this conversation in a capture.

2-4. How to Think About Anomaly Detection

Request-and-response pairing is a useful heuristic for the protocols shown here. Missing partners can result from the capture point, packet loss, timing, or protocol behavior; legitimate unsolicited traffic also exists. A missing pair alone is not proof of an attack.

3. Follow Along

3-1. Finding the Three Handshakes — Seeing the Book’s Diagram in Real Life

Open a practice server inside your computer (python3 -m http.server 8000 --bind 127.0.0.1), and connect while capturing.

Input

tshark -i lo -f "tcp port 8000" -c 6 -w handshake.pcap
# in another terminal:
curl -s http://127.0.0.1:8000/ > /dev/null

Output (measured 2026-09-09):

    1 0.000000000    127.0.0.1 → 127.0.0.1    TCP 74 52398 → 8000 [SYN] Seq=0 Win=65495 Len=0
    2 0.000022753    127.0.0.1 → 127.0.0.1    TCP 74 8000 → 52398 [SYN, ACK] Seq=0 Ack=1
    3 0.000031640    127.0.0.1 → 127.0.0.1    TCP 66 52398 → 8000 [ACK] Seq=1 Ack=1
    4 0.000140725    127.0.0.1 → 127.0.0.1    HTTP 143 GET / HTTP/1.1
    5 0.000144004    127.0.0.1 → 127.0.0.1    TCP 66 8000 → 52398 [ACK] Seq=1 Ack=78
    6 0.001643067    127.0.0.1 → 127.0.0.1    TCP 251 HTTP/1.0 200 OK  [TCP segment of a reassembled PDU]

How to read it: packets 1–3 are the three handshakes. From the ephemeral port (52398) to port 8000, [SYN], the server replies [SYN, ACK], then [ACK]. Look at the Time column — the whole handshake finishes in 0.03 milliseconds. And only at packet 4 does the “word” GET finally appear. The ritual’s order — words come only after the handshake — is confirmed in real life.

Why: this step is about witnessing the order of what happens beneath a single act of “connecting.” Once this picture is familiar to your eyes, strange traffic that handshakes hundreds of times without a word (the scan in 3-4) pops right out.

3-2. Catching One DNS Pair

Input

tshark -i any -f "udp port 53" -a duration:8 -w dns.pcap
# in another terminal:
python3 -c "import socket; print(socket.gethostbyname('www.khan.co.kr'))"

Output (measured 2026-09-09):

    1 0.000000000 10.255.255.254 → 10.255.255.254 DNS 76 Standard query 0x68b3 A www.khan.co.kr
    2 0.007112111 10.255.255.254 → 10.255.255.254 DNS 184 Standard query response 0x68b3 A www.khan.co.kr CNAME ... A 23.216.159.194 A 23.216.159.203

How to read it: one line of question, one line of answer. Standard query 0x68b3 A www.khan.co.kr means “please tell me this name’s A record (IPv4 address),” and the answer came back with two addresses. The question and answer share the same number (0x68b3) — that number is the tag that pairs them. The addresses being both 10.255.255.254 is because it goes through WSL’s internal DNS relay; on regular Linux it appears as my IP → router.

This example uses ordinary DNS messages visible in the capture. A connection may reuse a cached answer or an IP address, and DNS can also use encrypted transports such as DoH or DoT. Do not expect every connection to expose a DNS query.

If you’re stuck: when the operating system stores DNS results (caching), the question never goes out. Try a name you haven’t asked before.

3-3. The HTTP Field Comparison Experiment

Input (from a capture file)

tshark -r raw.pcap -Y http -T fields -e frame.number -e http.request.method -e http.host -e http.request.uri -e http.response.code

Output (measured 2026-09-09):

4	GET	127.0.0.1:8000	/	
8				200
16	POST	127.0.0.1:8000	/login	
20				501

How to read it: 4 (GET /) and 8 (200) are one pair; 16 (POST /login) and 20 (501) are another. In the GUI, click packet 4 and expand the Hypertext Transfer Protocol layer in the details pane — there are Host and User-Agent lines, with the TCP and IP layers in order below them (Screen example). The envelope you sent with curl is carried inside the packet, letter for letter.

The illustrated capture contains these request/response pairs. Record the protocol fields and timing that support each match; missing replies in another capture require explanation, not an automatic abnormal verdict.

3-4. Make a Prediction — What Does Scan Traffic Look Like?

Here’s a prediction. If you run an nmap SYN scan (-sS, ports 1–30) toward 127.0.0.1 on this computer, what picture will appear in the packet list? Imagine the colors, spacing, and pattern, and write it down.

Check for yourself

tshark -i lo -a duration:10 -w scan.pcap
# in another terminal:
sudo nmap -sS -p 1-30 127.0.0.1

Output (measured 2026-09-09, beginning):

    1 0.000000000    127.0.0.1 → 127.0.0.1    TCP 58 48622 → 21 [SYN] Seq=0 Win=1024 Len=0
    2 0.000017080    127.0.0.1 → 127.0.0.1    TCP 54 21 → 48622 [RST, ACK] Seq=1 Ack=1
    3 0.000025431    127.0.0.1 → 127.0.0.1    TCP 58 48622 → 25 [SYN] Seq=0 Win=1024 Len=0
    4 0.000026888    127.0.0.1 → 127.0.0.1    TCP 54 25 → 48622 [RST, ACK] Seq=1 Ack=1
    5 0.000030221    127.0.0.1 → 127.0.0.1    TCP 58 48622 → 22 [SYN] Seq=0 Win=1024 Len=0
    6 0.000031494    127.0.0.1 → 127.0.0.1    TCP 54 22 → 48622 [RST, ACK] Seq=1 Ack=1
    ...

This trace is consistent with the controlled scan that produced it. Repeated SYNs or changed destination ports alone do not establish hostile intent: retries, health checks, capture loss, and other activity need to be considered.

Why: these are footprints you stamped yourself. Once you know how an attack tool’s traffic looks on a defender’s screen, “anomaly detection” stops being an abstraction and becomes pattern recognition. Compare with your prediction.

3-5. Filter Combinations — Counting Only First Greetings

Let’s translate the scan’s signature into a filter sentence.

Input

tshark -r scan.pcap -Y "tcp.flags.syn == 1 and tcp.flags.ack == 0" | wc -l
tshark -r raw.pcap  -Y "tcp.flags.syn == 1 and tcp.flags.ack == 0" | wc -l
tshark -r scan.pcap -Y "tcp.flags.reset == 1" | wc -l

Output (measured 2026-09-09):

30    # SYN-only (first greeting) count in scan.pcap
2     # SYN-only count in raw.pcap (two normal curls)
30    # RST (closed response) count in scan.pcap

How to read it: the filter combined with and — “packets that are SYN and not ACK” — picks out only a conversation’s first greeting. The 30-port scan file has 30 first greetings; the file of two normal connections has 2. And all 30 of those greetings were rejected with RST. A pattern of first greetings pouring onto the same destination — that is a scan.

Why: filter syntax is more than a search term. It’s the skill of translating “what pattern is anomalous” into a sentence, and it becomes, as-is, the foundation of writing intrusion detection rules.

3-6. Organizing the Three Faces of Anomaly

Let’s bundle today’s experiments by the discriminating principle.

• Unmatched messages: consider capture loss, vantage point, and legitimate unsolicited traffic before diagnosing abuse.
• Unusual rate: compare against a relevant baseline; retries and health checks can raise counts.
• Unexpected content: check protocol state and endpoint evidence before assigning cause.

Try it: open the capture files you made today (handshake.pcap, dns.pcap, scan.pcap) in the Wireshark GUI too. The same file becomes a color-tinted list in the GUI, and clicking a packet unfolds its layers (Screen example). The tool differs; the pattern is the same.

4. Missions & Exercises

Mission — Writing the Protocol Normality File

1. For each of TCP, DNS, and HTTP, find “one normal pair” in a capture and copy down the packet numbers and key fields.
2. Define each protocol’s warning sign in one line (whichever applies among answer with no pair / flood / content beyond common sense).
3. Trigger an nmap scan, capture its pattern, and summarize “the signature of a scan” in three characteristics.
4. Build one combination filter yourself, and annotate what it picks out.
5. Explain how a relevant baseline helps interpretation and what uncertainty remains in this capture.

Exercises

Exercise 1. In a TCP conversation, if three [SYN]s appear in a row without a single [SYN, ACK], what’s the situation?

Exercise 2. To check whether a DNS question and answer are one pair, which value in the packets should you compare?

Exercise 3. State the scan’s three signatures (source, destination ports, whether conversations complete) in a sentence.

Exercise 4. What does the display filter tcp.flags.syn == 1 and tcp.flags.ack == 0 pick out, and why is this filter “the seed of scan detection”?

[TCP] handshake.pcap packets 1-3: [SYN] → [SYN, ACK] → [ACK], 0.03 milliseconds total. GET follows at packet 4.
[DNS] dns.pcap packets 1-2: query 0x68b3 A www.khan.co.kr → response 0x68b3 (matching ID is one clue; also compare endpoints, question, transport and timing).
[HTTP] raw.pcap 4+8: GET / ↔ 200 OK. 16+20: POST /login ↔ 501.

6. Common Pitfalls & Fixes

Wall 1. DNS doesn’t get captured

Symptom: you resolved a name but nothing shows under the dns filter.

Cause: when the operating system stores DNS results (caching), the question never goes out. Or the environment may use encrypted DNS (DoH). Even in the measurement environment (WSL), the first attempt wasn’t caught on eth0 because of caching and the internal DNS relay — we had to clear the cache and capture with -i any (2026-09-09).
Fix: try a name you haven’t asked before, and widen the interface (-i any). In a DoH environment, “encrypted DNS doesn’t appear in the list” is itself an observation result.

Wall 2. The capture never ends

Symptom (measured 2026-09-09): I set tshark -i lo -c 30 -w raw.pcap, but 30 packets never accumulate and tshark keeps waiting. Loopback is quiet, so packets don’t occur easily.

Cause: the -c count condition ends only when that count is filled.
Fix: use a time condition — -a duration:6 (auto-stop after 6 seconds). Or align the order of traffic generation (curl) and capture.

Wall 3. All the packets are black

Symptom: the GUI list is full of black lines (Screen example).

Cause: black usually marks attention items like retransmissions (TCP Retransmission). In virtual network environments they can also arise from the environment’s characteristics.
Fix: no need to panic. Just remember that asking “why so many retransmissions” is the start of analysis. You can check what colors mean in View → Coloring Rules.

Wall 4. I can’t tell scan patterns from normal ones

Symptom: lots of SYNs means a scan, but a browser seems to open many connections too.

Cause: normal programs also open multiple connections. The core of the distinction is “ports changing against the same destination.”
Fix: sort by destination port. In a scan the ports change sequentially (21, 22, 23…); in normal traffic, conversations run deep on a handful of ports. The first-greeting counting filter from 3-5 helps with quantitative judgment.

Wall 5. The handshake is only two lines

Symptom: data comes right after [SYN].

Cause: the capture started mid-conversation and missed the handshake, or a filter hid part of it.
Fix: start the capture first, then connect. Clear the filter for a moment and look at that connection in full — check first whether the handshake is even in the file.

7. Summary

Today’s Concepts

Today’s Commands and Filters

An Instinct More Important Than Commands

Pairing and rates are some of the signals used in traffic analysis. They are not a complete model of security detection. Correlate them with protocol state, capture limits, endpoint evidence, and the authorized activity you actually performed.

In an era where HTTPS is the default, content-reading detection gets harder, and instead behavioral analysis is growing — finding anomalies from “what’s visible without content”: the peer’s address, the size and rhythm of communication, frequency. Today’s pattern reading is foundational fitness that applies unchanged in that era too. And engrave once more the fact that all of this observation happened only on my lab’s traffic — that boundary line is the usage license for this skill.

Once every box is checked, Step 84 is complete.