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

Category	Details
Language/environment	Wireshark (GUI) or tshark (command line), Linux terminal
Today’s tools	Display filter combinations (`and`/`or`), packet details pane, `tshark -Y`/`-T fields`, traffic generators `curl`/Python/nmap
Concepts needed	TCP flags (SYN/ACK/RST), DNS query-response, HTTP request/response, the packet layers from Step 80
Today’s artifact	A "protocol normality file" — notes organizing the normal appearance and warning signs of the three protocols

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

The discriminating principle common to the three protocols is one: do questions and answers pair up? Normal communication always comes in pairs. An answer without a question, a flood of questions without answers, an answer whose content defies common sense — these three are the representative faces of anomaly. With this one principle you can read all of today’s experiments.

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), 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 desk; on regular Linux it appears as my IP → router.

Why: every journey on the internet begins with this little query-response. And DNS is plaintext — remember too the fact that who asked which name is visible to everyone along the path.

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.

Why: a confirmation that the abstract (protocol specification) and the measured (capture) interlock as one. The pairing rule — every request is followed by a response — shows again too.

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
    ...

How to read it: a single source port (48622) fires only [SYN] while changing destination ports through 21, 25, 22, 23, …, and every answer is [RST, ACK] (closed). Not one conversation completes the three handshakes. This is the face of a scan — normal conversations never look like this.

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.

Answer with no pair: a DNS response when no question was asked, a flood of ARP replies saying "I’m the router" (the face of ARP spoofing — dissected with a lab reproduction in Level 2 of this book).
Abnormal frequency: a density that would never appear in normal traffic, like the SYN barrage in 3-4.
Content beyond common sense: the address of a name never asked, a response of impossible size.

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

For each of TCP, DNS, and HTTP, find "one normal pair" in a capture and copy down the packet numbers and key fields.
Define each protocol’s warning sign in one line (whichever applies among answer with no pair / flood / content beyond common sense).
Trigger an nmap scan, capture its pattern, and summarize "the signature of a scan" in three characteristics.
Build one combination filter yourself, and annotate what it picks out.
Final paragraph: write "why knowing normal is the entirety of the eye that sees anomaly," citing today’s experiments.

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"?

5. Model Answers & Completion Criteria

Mission Model Answer

Example record of normal pairs (values measured 2026-09-09):

[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 (same number is proof of the pair).
[HTTP] raw.pcap 4+8: GET / ↔ 200 OK. 16+20: POST /login ↔ 501.

The scan’s three signatures (derived from the 2026-09-09 measurement): ① a single source port fires SYN repeatedly while changing only destination ports. ② no conversation completes the three handshakes — every answer is RST-ACK (closed). ③ the density of first greetings per unit time is dozens of times normal (SYN-only: 30 in the scan file vs. 2 in the normal file).

Example combination filter: tcp.flags.syn == 1 and tcp.flags.ack == 0 and ip.src == 10.0.0.5 — a filter that picks out "only the first greetings sprayed by 10.0.0.5."

How to verify: ① are the three protocols’ "normal pairs" recorded with packet numbers? ② is the scan signature summarized in three points? ③ does the combination filter you built yourself carry an annotation?

Exercise Answers

Answer 1. A situation where the target isn’t responding — it’s off, or a firewall is silently dropping the packets (filtered), or that port doesn’t exist. In nmap terms it’s the "no response" state, and retransmitting the same SYN a few times is also normal TCP behavior.

Answer 2. The transaction ID (query number). In the measurement, both question and answer were stamped 0x68b3. This number must match for a pair of the same conversation — if an answer arrives with a number never asked, that itself is an anomaly.

Answer 3. From one source, only SYNs (first greetings) fire repeatedly while destination ports change, not one conversation completes the three handshakes, and the responses are mostly RST-ACK (closed). A normal conversation runs deep on a handful of ports; a scan brushes shallowly across many ports.

Answer 4. It picks out packets that are "SYN and not ACK" — that is, only a conversation’s first greeting (SYN-ACK is excluded because it also has ACK set). Since both scans and normal connections start with a first greeting, counting by source and per-hour on top of this filter reveals density anomalies immediately (measured: 30 in the scan file vs. 2 in the normal file). That’s why this one line is the seed of a detection rule.

Completion Criteria Checklist

[ ] I can find the three handshake packets in a capture
[ ] I can verify a DNS question-answer pair by transaction ID
[ ] I can pair HTTP requests and responses with field extraction
[ ] I can summarize the signature of scan traffic in three points
[ ] I can build and/or combination filters myself
[ ] Mission: I completed the protocol normality file

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 desk — 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

Concept	One-line explanation
3-way handshake	SYN → SYN-ACK → ACK. Words come after the handshake
Transaction ID	The pairing tag of DNS question-answer — numbers must match for a pair
The three faces of anomaly	Answer with no pair / abnormal frequency / content beyond common sense
Scan signature	One source + SYN barrage with changing ports + RST responses + incomplete conversations
Signature	A list of known attack patterns — today’s "three signatures" is a handmade signature

Today’s Commands and Filters

Command/Filter	What it does
`tshark -i lo -f "tcp port 8000"`	Capture only the port-8000 conversation
`tshark -r file -Y dns`	View DNS packets only
`tshark -r file -T fields -e ...`	Extract only the fields you want into a table
`tcp.flags.syn == 1 and tcp.flags.ack == 0`	Pick out only first greetings of conversations
`tcp.flags.reset == 1`	Pick out only closed responses
`filter	wc -l`

An Instinct More Important Than Commands

Today’s principle of "pairs of question and answer" is the basic logic that expensive security appliances use too. A great many intrusion detection system rules ultimately find "answers with no pair," "abnormal frequencies," "content beyond common sense" — and today you internalized the mind of those rules with your hands, verifying them even with scan footprints you stamped yourself.

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.