Chapter 40 — Hands-on: seeing the network

Why this chapter exists

Every claim in Parts 7–9 is checkable with a packet capture. Being able to capture, filter, and read traffic — and to run a safe attack in your own lab — turns theory into intuition.

tcpdump — capture anywhere

# interfaces
sudo tcpdump -D

# basic: interface, no name resolution, snap full packets
sudo tcpdump -i any -n -s0

# write to a file for Wireshark; rotate to keep size sane
sudo tcpdump -i any -n -w /tmp/cap.pcap -C 100 -W 5   # 5 x 100MB ring

# read back with a display filter
tcpdump -n -r /tmp/cap.pcap 'tcp port 443'

# --- filters you'll actually use (BPF syntax) ---
sudo tcpdump -i any -n 'host 10.0.0.5'
sudo tcpdump -i any -n 'tcp port 443 and host example.com'
sudo tcpdump -i any -n 'udp port 53'                       # DNS
sudo tcpdump -i any -n 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0'   # conn setup/teardown
sudo tcpdump -i any -n 'icmp'
sudo tcpdump -i any -nA 'tcp port 80'                      # ASCII payload (plaintext HTTP)
sudo tcpdump -i any -n 'not port 22'                       # exclude your ssh session
sudo tcpdump -i any -n 'net 10.0.0.0/8 and not net 10.0.20.0/24'

Wireshark / tshark — read deeply

# terminal Wireshark
tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1'   # ClientHellos
tshark -r /tmp/cap.pcap -Y 'http.request' -T fields \
       -e ip.src -e http.request.method -e http.host -e http.request.uri
tshark -r /tmp/cap.pcap -q -z conv,tcp        # conversation summary
tshark -r /tmp/cap.pcap -q -z io,phs          # protocol hierarchy

# decrypt YOUR OWN TLS with a key log
SSLKEYLOGFILE=/tmp/keys.log curl -s https://example.com -o /dev/null
tshark -r /tmp/cap.pcap -o tls.keylog_file:/tmp/keys.log -Y http2

# Wireshark GUI display filters worth memorising:
#   tls.handshake            ip.addr == 10.0.0.5
#   http.response.code >= 400 dns.flags.rcode != 0
#   tcp.analysis.retransmission   tcp.flags.reset == 1
#   tls.record.version == 0x0301  (probes for old TLS)

nmap — discovery and service inspection (your hosts / lab only)

nmap -sn 10.0.20.0/24                      # host discovery (ping sweep)
nmap -sS -T4 --top-ports 1000 10.0.20.5    # SYN scan, common ports
nmap -sV -sC -p 22,80,443 10.0.20.5        # version + default scripts
nmap --script ssl-enum-ciphers,ssl-cert -p 443 shop.securesh.op
nmap --script ssh2-enum-algos,ssh-auth-methods -p 22 app-01.internal
nmap -sU --top-ports 50 10.0.20.5          # UDP (slow)
nmap -A -oA scan_result 10.0.20.5          # everything; save 3 formats

Chapter 0.6, restated: nmap against systems you don't own or have written permission to test can be a criminal offence. Lab, HTB/THM, and your own infrastructure only.

A safe MITM lab (isolated, VMs you own)

   Setup: two VMs (victim, gateway-sim) + one attacker VM on a HOST-ONLY
   network with no route to anything real.

   1. On attacker: enable IP forwarding, then:
        sudo bettercap -iface eth1
        > set arp.spoof.targets 192.168.56.10
        > arp.spoof on
        > net.sniff on
   2. On victim: browse to the plaintext test app you host on gateway-sim.
      Watch credentials appear in bettercap's log.
   3. Now serve the app over HTTPS with a cert from your Ch 29 mini-CA
      (trusted on the victim). Repeat -- bettercap sees only TLS records.
   4. Try `set https.proxy on` (sslstrip-style). It works UNTIL you add an
      HSTS header (Ch 31) -- then the browser refuses the downgrade.
   5. On gateway-sim's switch/bridge, add static ARP entries (or enable
      DAI on a real managed switch) and watch step 1 stop working.

   Deliverable: ~/sec-lab/reports/part9-mitm.md -- what each layer of
   defence (TLS, cert validation, HSTS, DAI) removed from the attacker.