Networking Fundamentals

Every attack and every defense rides on top of the same packet flows. If you cannot read a tcpdump trace and predict what a firewall will do with it, you are operating blind at every layer above. This module covers the OSI/TCP/IP model, the three-way handshake, state tracking, fragmentation, and the exact bytes a defender sees in a Suricata alert.

The Core Concept

Network communication is a stack of encapsulated headers. Each layer adds metadata the next layer down uses to deliver the payload.

┌─────────────────────────────────────────────┐
│  Application   HTTP / DNS / SSH / TLS        │  L7
├─────────────────────────────────────────────┤
│  Transport     TCP / UDP  (port, seq, flags) │  L4
├─────────────────────────────────────────────┤
│  Network       IPv4 / IPv6 (src, dst, ttl)   │  L3
├─────────────────────────────────────────────┤
│  Data-link      Ethernet (MAC, EtherType)     │  L2
├─────────────────────────────────────────────┤
│  Physical       bits on the wire              │  L1
└─────────────────────────────────────────────┘

A single HTTPS request becomes: TLS record → TCP segment (L4) → IP packet (L3) → Ethernet frame (L2). Each header is a detection surface: defenders write rules on flags, TTLs, ports, and option strings; attackers manipulate the same fields to evade or fingerprint.

How It Works

DNS resolution — the client queries a resolver for target.com. The recursive resolver walks from root → TLD → authoritative. Responses carry a TTL (default 300s for many CDN frontends) and are cached by the OS stub resolver (/etc/resolv.conf on Linux, ipconfig /displaydns on Windows).
ARP / neighbor discovery — on the local segment, the host resolves the next-hop gateway MAC. On IPv6 this is Neighbor Solicitation (ICMPv6 type 133/135); on IPv4 it is ARP.
TCP three-way handshake:
```
Client → SYN         seq=1000, win=64240
Server → SYN/ACK     seq=5000, ack=1001, win=65535
Client → ACK         seq=1001, ack=5001
```
The win field is the receive window. Modern stacks use window scaling (RFC 7323, option kind 3) so the real window is win << scale.
Data exchange — each byte has a sequence number. Acknowledgements are cumulative: ACK=5001 means “I have received everything up to byte 5000”.
Teardown — FIN/ACK/FIN/ACK, or a single RST for an abort.

Stateful firewalls (iptables conntrack, Suricata flow, Palo Alto) track this sequence. A SYN with no prior handshake triggers an “invalid state” drop. A RST to a non-existent flow is logged as a scan.

Common Techniques

Technique	Description	Detection Difficulty
SYN scan (`-sS`)	Send SYN, read SYN/ACK (open) or RST (closed); never complete handshake	Easy — half-open flows
Idle scan (`-sI`)	Bounce SYN off a zombie host, observe its IP-ID counter change	Medium — needs the zombie
Fragmentation scan	Split probe across IP fragments to evade pattern matchers	Medium — Suricata `frag3` reassembles
Decoy scan (`-D`)	Mix real source with spoofed decoys in the SYN flood	Hard — must correlate responses
Window scan (`-sW`)	Read RST window value as open/closed oracle on non-RST-reset stacks	Medium — OS-specific

Hands-On Commands

# SYN scan of top 1000 ports, slow timing, fragmented packets, randomized order
nmap -sS -T2 -f --randomize-hosts scanme.nmap.org

# Capture port 80 traffic to a pcap file for offline analysis
tcpdump -i eth0 -w capture.pcap 'tcp port 80'

# Print a readable conversation with sequence numbers and ACKs
tcpdump -nnr capture.pcap -S 'tcp port 80'

# Inspect the TCP options (MSS, window scaling, SACK, timestamps)
tshark -r capture.pcap -Y 'tcp.flags.syn==1' -O tcp -V | head -80

Detection — Defender View

Suricata SID 2010935 — ET SCAN Nmap NSE Scan (generated by NSE UA strings) [verify]

Suricata SID 2002910 — ET SCAN Potential VNC Scan 5900-5920 [verify]

ModSecurity CRS 942100 — application-level SQLi feature, not relevant at L3/L4 but the same nf_conntrack state feeds both layers.

Sysmon Event ID 3 — NetworkConnect — logs process → destination IP/port on Windows endpoints. Combine with Event ID 22 (DNSEvent) to correlate “process X resolved evil.tld then connected to 1.2.3.4”.

MITRE ATT&CK T1046 — Network Service Discovery (nmap, masscan).

MITRE ATT&CK T1049 — System Network Connections (netstat, Get-NetTCPConnection).

Wazuh rule 31103 — Nmap scan detected (rate-based on SYN without ACK completion) [verify].

Evasion Techniques

Source-port forgery. Many stateful firewalls allow inbound return traffic from port 53/80/443 because “DNS replies and HTTP must work”. A scanner can source SYN from port 53 to slip past a poorly-ordered ACL:

nmap -sS --source-port 53 scanme.nmap.org

Defense: default-deny inbound; explicitly allow return traffic only for established (-m state --state ESTABLISHED,RELATED).

Timing jitter. --scan-delay 500ms --max-retries 0 defeats rate-based IDS counters that key on packets-per-second. Counter by also tracking per-destination-port flow volume over a 1-minute sliding window.

Fragmentation overlap. First fragment carries a benign TCP header, second fragment overwrites it with the real probe. Suricata stream.midstream and stream.depth plus frag3 reassembly neutralize this. Watch for ip.id gaps and fragments without a following full packet.

⚠️ What caught me: A -sS scan of a target that had a Palo Alto in tap mode produced zero alerts — until I checked the PA’s “Application” column. It had classified my SYN flood as nmap (via heuristics on the TCP options order: MSS,SACK,TS,WinScale vs Linux’s MSS,SACK,TS,WinScale,NOP,NOP). I had set --data-length 24 to look more like a real client, which actually changed the option order and tripped the heuristic. The lesson: option order is a stronger signature than port choice.

Lab Practice

Build a two-VM lab:

VM A: Ubuntu 22.04 with nmap, tcpdump, Suricata 6 (with Emerging Threats OPEN ruleset).
VM B: Metasploitable2 as the target.

Objective: produce three distinct Suricata alerts (one per scan type) and one conntrack “invalid” drop log entry.

Expected flag format: flag{sid:2010935:src_port_53_evasion_works}.

Detection that should fire: Suricata alert entries in /var/log/suricata/fast.log, plus dmesg | grep conntrack showing the invalid drop.

Interview Questions

Explain the difference between a connection at L4 (conntrack) and a flow at L7 (Suricata flow). When can they disagree?

Scenario: you see 50 SYN packets to one host, all with ACK=0, varying source ports. What is happening and what is the attacker trying to learn?

Technical: why does a RST scan (-sA against a stateful firewall) sometimes reveal ACL holes, and what is the kernel state that makes this work?

What is the significance of the TCP option kind=8 (Timestamps), and how does it defeat the IP-ID idle scan on modern Linux?

Conceptual: if an attacker sources SYNs from port 53, why might a mis-configured iptables rule allow the traffic, and what is the correct rule structure?

→ F2 (Linux Internals) · R2 (Scanning) · R8 (Stealth Recon)