InfoSec 3001 — Information Security from the Offensive Perspective

Step 83. Wireshark 1 — Capture and Filters, the Microscope of Networks

Step 83. Wireshark 1 — Capture and Filters, the Microscope of Networks

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

Prerequisites: Step 80 complete. You know that a packet is a structure of Ethernet/IP/TCP stacked together. You have your own lab environment (Linux or Windows).

  • What you need: Wireshark installed and your lab network. If you have the terminal version tshark, you can practice the same principles without a GUI.
  • 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 every capture is always your own equipment, your own lab. GUI screen descriptions are "Screen examples," and the tshark command outputs were measured on 2026-09-09 against the loopback of WSL Linux (TShark 4.2.2).

In Step 80 we crafted packets and snatched a few. But there’s a 25-year-old microscope dedicated to exactly this job: Wireshark. It’s a tool that catches every packet passing through your network card in real time, unfolds it layer by layer, and reassembles it into conversations. Today has two goals. First, how not to get lost in the flood of packets (filters). Second, internalizing the difference between the two filters — capture filters and display filters — with your body.

1. Learning Objectives

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

  • Pick a network interface and start and stop a capture
  • Write display filter syntax (dns, tcp.port == 80, ip.addr == ...)
  • Explain the difference between capture filters (BPF syntax) and display filters, and use each
  • Save capture results to a pcap file and reopen it
  • Reproduce the same principles on the command line with tshark

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category Details
Language/environment Wireshark (GUI) or tshark (command line) — same on Linux/Windows
Today’s tools Capture interface selection, display filter input bar, capture filter field, File → Save As
Concepts needed Interface (network card), loopback, the layered structure of packets, pcap files
Today’s artifact first_capture.pcap — my first packet recording file

2-1. Capture — The Network Card’s Sideways Glance

Your network card normally hands only packets that are "yours" to the operating system. Wireshark switches this card to promiscuous mode, telling it to "bring everything you see." This is called a capture. Because you may end up seeing parts of other devices’ traffic on the same network, capturing must be done only in your own lab — peeking at others’ communications is a legal problem in itself.

2-2. The Three Panes of the Screen

The Wireshark window has three layers.

  1. Top — packet list: captured packets are listed one per line in time order.
  2. Middle — Packet Details: unfolds the selected packet layer by layer. The same structure as Step 80’s pkt.show().
  3. Bottom — Packet Bytes: the raw hexadecimal dump.

2-3. The Two Filters — Before Catching and After Catching

This is the point where Wireshark beginners get most commonly confused.

  • Capture filter: decided before starting the capture — "what should we catch in the first place." Uses concise BPF (Berkeley Packet Filter) syntax like port 53. Filtered-out packets are never saved at all.
  • Display filter: chooses, among packets already caught, "what to show on screen." Uses a rich syntax like udp.port == 53, and each time you change the filter only the screen redraws — the original data stays intact.

One-line rule: capture filter before catching, display filter after catching.

3. Follow Along

3-1. Installation and Interface Selection

Input: install from wireshark.org, or on Linux, sudo apt install wireshark. When you run it, the first screen shows a list of network interfaces (network cards).

Screen example: next to each card in the list is a small waveform. A card with data flowing right now has a wiggling waveform. Usually it’s "Wi-Fi" or "eth0." Loopback (dedicated to talking with yourself) shows no outside traffic, so pick it only when doing an inside-my-computer experiment (127.0.0.1) like today. Double-click to start the capture.

How to read it: once the capture starts, packets pour in even when you do nothing — because your computer is quietly holding countless conversations (syncing the clock, checking for updates, and so on). Seeing this "quiet noise" itself is the first lesson. The red square button at the top stops the capture.

3-2. Display Filter Practice — Turning a Flood into a Stream

Input: try entering these into the filter bar one by one.

dns
tcp.port == 80
ip.addr == 8.8.8.8

Screen example: each time you change the filter, the list shrinks dramatically. If there’s a typo, the input box turns red; if the syntax is valid, it’s green.

Frequently used display filters:

Filter Meaning
dns DNS packets only
http HTTP packets only
tcp.port == 80 Only TCP involving port 80
ip.addr == 8.8.8.8 Everything to and from that address
tcp.flags.syn == 1 Only packets with the SYN flag set

Why: a capture without filters is a microscope without a lens. The habit of deciding "what to look at" first determines your analysis time.

3-3. Reproducing with tshark — The Before-Catch Filter

An experiment that needs no GUI — and where the difference between the two filters becomes sharpest. Open a practice server inside your computer (python3 -m http.server 8000), and capture with a capture filter attached.

Input (terminal 1, using a capture filter)

tshark -i lo -f "tcp port 8000" -c 6 -w cap_filter.pcap

Input (terminal 2, once the capture has started)

curl -s http://127.0.0.1:8000/ > /dev/null

Output — opening the whole saved file (measured 2026-09-09):

$ tshark -r cap_filter.pcap
    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: since we applied the capture filter -f "tcp port 8000", the file contains only the port-8000 conversation. Other packets were never caught in the first place. And look closely at these six lines — a single entire web connection is melted into them, starting with the three handshakes [SYN], [SYN, ACK], [ACK] and continuing to GET, 200 OK.

3-4. Filtering Again with a Display Filter

This time, from a file captured without any filter, let’s pick after catching.

Input

tshark -i lo -a duration:6 -w raw.pcap     # run curl a couple of times in the meantime
tshark -r raw.pcap -Y http

Output (measured 2026-09-09 — same file, before/after filter):

# No filter: 12 lines — HTTP buried among TCP handshakes and acknowledgments
    1 ... TCP 74 39840 → 8000 [SYN] ...
    4 ... HTTP 143 GET / HTTP/1.1
    8 ... HTTP 93 HTTP/1.0 200 OK  (text/html)
   16 ... HTTP 250 POST /login HTTP/1.1  (application/x-www-form-urlencoded)
   20 ... HTTP 423 HTTP/1.0 501 Unsupported method ('POST')  (text/html)

# After applying -Y http: only the four HTTP lines remain
    4 ... GET / HTTP/1.1
    8 ... HTTP/1.0 200 OK  (text/html)
   16 ... POST /login HTTP/1.1  (application/x-www-form-urlencoded)
   20 ... HTTP/1.0 501 Unsupported method ('POST')  (text/html)

How to read it: the original file (raw.pcap) is untouched, and -Y http only picked what to show on screen. Change the filter and you can look at the original again — that’s the power of the "after-catch filter." By contrast, the capture filter in 3-3 produced a file that was itself already a filtered result.

3-5. Extracting Only the Values You Want into a Table — Field Extraction

A display filter picks "rows"; field extraction picks "columns."

Input

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: a table extracting only number, request method, host, address, and response code. Line 4 is a GET / request, line 8 its response (200), line 16 a POST /login, line 20 its response (501). You can also see requests and responses paired by number.

Why: this is the skill of turning tens of thousands of capture lines into an Excel-like table. It’s the first step of log analysis and automation, and your parsing skills from Step 82 carry straight over.

3-6. Saving and Reopening — The pcap Archive

Input: in Wireshark, File → Save As → save as first_capture.pcap. Close Wireshark, then double-click that file to open it again.

Screen example: the exact list from before closing reappears. You can reapply filters and stream reconstruction.

How to read it: a pcap is "a recording file of the network at that moment." Time has passed, but the packets inside remain exactly as they were that day. The pcapng extension is the next-generation format, holding even comments and interface information — at the beginner stage, it’s enough to know it as "Wireshark’s default save format."

Why: analysis doesn’t end at the scene. Real work is preserving the scene (pcap) and revisiting it later, with other tools, together with other people. The CTF forensics challenge "find the culprit’s communication in this pcap" is exactly this file.

4. Missions & Exercises

Mission — Capture Exploration Journal

  1. Run a capture for 5 minutes and write down every kind of protocol that appears (the Protocol column).
  2. With the dns filter, find a question-answer pair and record which name was asked and which address came back.
  3. Start a new capture with the capture filter tcp port 80, visit a plaintext site (e.g., http://neverssl.com), and confirm that only the web conversation is caught cleanly, without DNS/noise.
  4. Filter the same visit with the display filter http too, and write a comparison sentence on how the result differs from step 3 (file contents vs. screen).
  5. Save the capture as exploration_journal.pcap, and at the end of the journal write, in your own words, three sentences on "the difference between a capture filter and a display filter."

Exercises

Exercise 1. Explain the difference between a capture filter and a display filter along two axes: "before catching / after catching" and syntax (BPF vs. Wireshark syntax).

Exercise 2. When planning a multi-hour capture, explain from a file-size perspective why using a capture filter is a good idea.

Exercise 3. What does the display filter ip.addr == 8.8.8.8 show? How is it different from ip.src == 8.8.8.8?

Exercise 4. Between the loopback (lo) interface and a regular network card (eth0), which should you pick to catch the 127.0.0.1:8000 experiment traffic? Why?

5. Model Answers & Completion Criteria

Mission Model Answer

The comparison experiment of steps 3–4 reproduces as-is with tshark (measured 2026-09-09):

# Capture filter: the file itself is a filtered result
tshark -i lo -f "tcp port 8000" -c 6 -w cap_filter.pcap
tshark -r cap_filter.pcap            # → only 6 lines of the port-8000 conversation

# Display filter: the file holds everything, only the screen is filtered
tshark -i lo -a duration:6 -w raw.pcap
tshark -r raw.pcap -Y http           # → only the 4 HTTP lines shown, all 12 original lines preserved

Example comparison sentence: "The file caught with a capture filter contained only port-8000 packets from the start, so other protocols could never be recovered later. The file using a display filter showed only HTTP on screen, but TCP and other packets all remained in the original, so I could change the filter and look again from a different angle."

How to verify: ① are five or more kinds of protocols written down? ② are the name and address of the DNS pair recorded? ③ is the difference between a capture-filter capture and a display-filter capture described precisely as "file contents vs. screen"? ④ is the pcap file saved and does it reopen?

Exercise Answers

Answer 1. A capture filter is a filter set before the capture starts that decides "what to catch in the first place"; it uses BPF syntax (port 53), and filtered-out packets are never saved. A display filter is a filter that chooses, after catching, "what to show"; it uses Wireshark syntax (udp.port == 53), and the original is preserved intact.

Answer 2. If you capture for hours without a filter, every useless packet is saved too, the file balloons to gigabytes, and it becomes heavy to open and analyze later. Capturing only what you need with a capture filter keeps the file small and fast. The trade-off is that "oh, I should have looked at that too" becomes impossible later.

Answer 3. It shows all packets to and from 8.8.8.8 (where that address is the source or the destination). ip.src is limited to packets that came from that address — the direction is restricted to one side. If you want only questions, use ip.dst; only answers, ip.src.

Answer 4. The loopback (lo). 127.0.0.1 traffic doesn’t go through a network card — it circulates only inside the operating system — so it can’t be caught on a regular network card (confirmed by measurement on 2026-09-09 — every experiment was captured on lo). On Windows, pick Npcap Loopback Adapter.

Completion Criteria Checklist

  • [ ] I can pick an interface and start and stop a capture
  • [ ] I can use three or more display filters
  • [ ] I can explain the difference between a capture filter and a display filter
  • [ ] I have used tshark’s -f, -Y, and -T fields each
  • [ ] I can save a pcap file and reopen it
  • [ ] Mission: I completed the capture exploration journal

6. Common Pitfalls & Fixes

Wall 1. The capture catches nothing

Symptom: you started a capture but the list is completely empty.

Cause: you picked the loopback or an unused interface, or you lack privileges. Capturing a 127.0.0.1 experiment on a regular network card also falls here.
Fix: check on the first screen whether you picked a card with a moving waveform. Inside-my-computer experiments can only be caught on loopback. On Linux you need capture privileges (sudo or the wireshark group).

Wall 2. I put a display filter in the capture filter spot

Symptom (measured 2026-09-09, tshark):

tshark: Invalid capture filter "tcp.port == 8000" for interface 'Loopback'.

That string looks like a valid display filter; however, it isn't a valid
capture filter (can't parse filter expression: syntax error).

Cause: tcp.port == 8000 is display filter syntax, but you put it in the capture filter (-f) spot.
Fix: change the capture filter to BPF syntax, tcp port 8000. Kindly enough, the error message tells you "that looks like a display filter."

Wall 3. Conversely, I put a capture filter in the display filter spot

Symptom (measured 2026-09-09, tshark):

tshark: "8000" was unexpected in this context.
    port 8000
         ^~~~
  Note: That read filter code looks like a valid capture filter;
        maybe you mixed them up?

Cause: the mirror image of Wall 2. You put port 8000 (BPF syntax) in the display filter (-Y) spot.
Fix: change the display filter to tcp.port == 8000. In the GUI the same confusion shows up as a red input box — the answer is the habit of checking first, "which filter spot am I in right now."

Wall 4. There are too many packets to find what I want

Symptom: the packet you want is buried among tens of thousands of lines.

Cause: you’re looking without a filter.
Fix: even after capturing, entering a display filter trims the list. And from now on, make "decide what to look at before looking" a habit. In a hurry, look at the conversation pairs first via Statistics → Conversations.

Wall 5. A warning appears when I run as root

Symptom (measured 2026-09-09, tshark):

Running as user "root" and group "root". This could be dangerous.

Cause: capturing is work that handles raw packets, so it needs administrator privileges — but a program running as administrator also pays dearly for mistakes.
Fix: in a lab environment like WSL, it’s fine to proceed as-is. On a full Linux system, the standard setup is to add your user to the wireshark group and capture with regular privileges.

7. Summary

Today’s Concepts

Concept One-line explanation
Capture Recording whole packets as they brush past the network card
Promiscuous mode "Bring even packets that aren’t mine" — which is why it’s lab-only
Capture filter A filter applied before catching (BPF syntax, port 53) — keeps files small
Display filter A filter for picking after catching (udp.port == 53) — preserves the original
pcap A packet recording file — a format that cages an unrepeatable scene
Loopback The 127.0.0.1-only passage — inside-my-computer experiments are caught only here

Today’s Commands and Operations

Command/Operation What it does
Double-click an interface / red square Start / stop a capture
dns, http, etc. in the filter bar Apply a display filter
tshark -i lo -f "tcp port 8000" Catch with a capture filter (before-catch filter)
tshark -r file -Y http View with a display filter (after-catch filter)
tshark -r file -T fields -e fieldname Extract only the columns you want into a table
File → Save As Preserve the scene as a pcap

An Instinct More Important Than Commands

Beginners think of Wireshark as "a tool you open when an incident happens"; experts open it on ordinary days. Only someone who has watched a lot of what their computer talks about when it’s quiet recognizes anomalies instantly. Like the story that a counterfeit-bill examiner handles only real bills tens of thousands of times, the data of normal must soak deep into your eyes for anomalies to pop out.

And the distinction between the two filters is a way of thinking that carries beyond Wireshark to every observation tool — "do you filter at the collection stage, or at the analysis stage?" Filtering at collection is light but unrecoverable; filtering at analysis is heavy but flexible. Lastly, archive your capture files with dates attached. As the archive piles up, you start to see even "the seasonal changes of my home network."

Once every box is checked, Step 83 is complete.

← 이전 스텝
다음 스텝 →