Week 11: NSM and Display Filters

Network Security Monitoring (NSM) is the practice of capturing, storing, and analyzing network traffic to detect anomalies, incidents, and intrusions. This week you work with the full toolkit: Wireshark display filters as precise surgical instruments, the pcap-tools workbench as your analysis environment, and Snort 3 and Suricata rule syntax as the formalization of what "looks bad" at the packet level.

Theme

A packet capture is a record of everything that happened on a network segment during a window of time. The challenge is not capturing the packets -- that is easy. The challenge is finding the one packet in ten thousand that tells you something important. Display filters are the instrument for that search: they let you ask "show me only DNS queries that returned NXDOMAIN" or "show me only TLS ClientHellos where the SNI is not the host's expected domain" or "show me only TCP connections that never completed the three-way handshake." This week you write filters, interpret results, and map defensive rules to the CVEs that motivated them.

Reading (~45 minutes)

1. Wireshark User's Guide, Ch 6 ("Working With Captured Packets"): display filters; the filter expression syntax; coloring rules; follow-stream -- available free at https://www.wireshark.org/docs/wsug_html_chunked/
2. The academy handout: handouts/cve-snort3-rules-reference-wireshark-quartet-2026-05.md -- §1-2 (overview and CVE summary table): familiarize yourself with the four rules before the lab
3. The academy handout: handouts/cve-suricata-rules-reference-wireshark-quartet-2026-05.md -- §1 (overview): same four rules in Suricata syntax

Lecture outline (~2 hours)

Section 1: Display filter syntax

Wireshark display filters are expressions that evaluate to true or false for each packet. Packets for which the expression evaluates to false are hidden.

Basic syntax:

protocol.field == value          # equality
protocol.field != value          # inequality
protocol.field > value           # greater than
protocol.field contains "string" # substring match
protocol.field matches "regex"   # regular expression match

Logical operators:

filter1 and filter2     # both must be true
filter1 or filter2      # either must be true
not filter1             # negation
(filter1) or (filter2)  # grouping with parentheses

Useful filters by protocol:

Section 2: Analytical techniques

Conversation analysis:

• Statistics > Conversations: shows all IP pairs that exchanged traffic, sorted by bytes or packets. Useful for finding the most active talkers.
• Statistics > Endpoints: shows all unique IP addresses; sorted by bytes. Useful for finding external IPs that received a lot of data (potential exfiltration).

Protocol hierarchy:

• Statistics > Protocol Hierarchy: shows what percentage of traffic is each protocol. A capture with 80% HTTP and 15% DNS is very different from one with 40% unknown UDP.

Follow TCP/UDP Stream:

• Right-click a packet > Follow > TCP Stream: reassembles the full conversation and shows it as text. For unencrypted HTTP, this shows the complete request and response in plain text.
• Works for UDP too: Follow > UDP Stream for DNS, DHCP, etc.

Expert Information:

• Analyze > Expert Information: Wireshark's built-in anomaly detector; lists retransmissions, duplicate ACKs, malformed packets, zero-window events, and other notable conditions.

Section 3: Intrusion detection rule engines -- Snort and Suricata

Snort 3 and Suricata are network intrusion detection/prevention systems (IDS/IPS). They apply rules to live traffic (or to pcap files offline) and alert when a packet matches a rule.

A Snort 3 rule has this structure:

action proto srcip srcport direction dstip dstport ( options ; )

Example (from cve-snort3-rules-reference-wireshark-quartet-2026-05.md):

alert tcp any any -> any 443 (
  msg:"CVE-2026-5402 TLS ECH integer-truncation shape";
  flow:established,to_server;
  content:"|16 03|"; depth:2;
  content:"|fe 0d|"; within:512;
  threshold:type limit,track by_src,count 1,seconds 60;
  classtype:attempted-user;
  reference:cve,2026-5402;
  sid:9265402; rev:1;
)

A Suricata rule uses the same underlying syntax with some Suricata-specific extensions (like filemagic, ja3, tls.sni).

What the rule says: Alert on TCP traffic to port 443. The content is established (post-handshake); the traffic goes from client to server. Match packets that contain the TLS record header bytes \x16\x03 within the first 2 bytes, followed by the ECH extension type \xfe\x0d within 512 bytes. Rate-limit to one alert per source IP per 60 seconds.

Section 4: The five analytical questions

When you open an unfamiliar packet capture, work through these in order:

1. Who is talking to whom? Statistics > Conversations. What are the top IP pairs by bytes?
2. What protocols are present? Statistics > Protocol Hierarchy. Any unexpected protocols?
3. What is the timeline? Is traffic distributed evenly, or does it spike at a specific time?
4. Is there anything that looks wrong? Analyze > Expert Information. Are there retransmissions, malformed packets, RST floods?
5. Follow the most interesting conversation. Right-click > Follow > TCP Stream on the conversation with the most unexpected bytes.

Labs (~90 minutes)

Lab 11-1: Display Filters (labs/lab-11-1-display-filters.md) Lab 11-2: Snort and Suricata Rules (labs/lab-11-2-snort-suricata-rules.md)

Independent practice (~7 hours)

1. Read Wireshark User's Guide Ch 6 fully; bookmark the filter expression syntax reference
2. Work through all four CVE sections in handouts/cve-lab-wireshark-rce-quartet-2026-05.md; for each CVE, write a one-paragraph explanation of the bug class in your own words
3. Load arp-storm.pcap in pcap-tools. Apply arp.opcode == 1. Calculate the average time between ARP requests. Is this rate consistent with a normal host? What would you alert on?
4. Use Statistics > Conversations on tall-100-frames.pcap. What are the top two IP pairs by packet count? What protocols are they using?
5. Write a Wireshark display filter that finds only packets matching ALL of these: TCP, destination port 443, SYN flag set (new connection attempts). How many packets in tall-100-frames.pcap match?

Reflection prompts (~30 minutes)

1. A Snort rule for CVE-2026-5402 matches on a byte pattern in the TLS extension. An attacker who knows the rule exists might modify the crafted packet to avoid matching. What does this tell you about the limitations of signature-based detection?
2. Wireshark's Expert Information is useful for finding anomalies but generates a lot of output on a busy network. How would a SOC analyst decide which expert-information items to investigate and which to ignore?
3. The pcap-tools workbench lets you analyze captures in a browser. Who owns the captured traffic you upload? What are the privacy implications of analyzing production captures in a third-party browser tool?
4. Suricata can run in inline mode as an IPS (intrusion prevention system) that drops matching packets. What is the risk of an incorrectly tuned rule in IPS mode versus IDS mode?
5. NSM requires storing network captures. How long should you retain captures? What privacy and legal constraints apply to storing captures that may contain user data?

What comes next

Week 12 is the capstone week. You capture traffic from a controlled lab network, annotate it by protocol and conversation, identify at least one anomaly, and write a structured Network Snapshot report committed to Git. The closing lecture maps every NET-101 topic to the downstream courses that build on it.