The course opened (chapter 1) with the proliferation of middleboxes — firewall, NAT, proxy, IDS, traffic profilers — as one of the causes of network ossification. This closing chapter studies those middleboxes properly: what a firewall can and cannot do, how the Linux kernel implements it (iptables and nftables), and how the network watches itself (IDS/IPS/SIEM, with Suricata as the worked example).
A firewall is a device that joins two networks and filters the traffic crossing the boundary, according to a security policy. The classical image is the perimeter defence: all traffic between the internal network and the outside must pass through the firewall, only the traffic authorized by the policy may pass, and the firewall itself must be immune to compromise. Three basic principles follow:
The lecture distinguishes three control techniques, which operate at different layers:
| Technique | Layer / object inspected | Decision |
|---|---|---|
| Packet filter | Network and transport headers of each packet, in isolation: IP addresses, protocol, TCP/UDP ports, flags. | Fast, stateless by default; cannot see the application, cannot reassemble streams. The classic router ACL. |
| Application Level Gateway (ALG) — proxy | The application protocol itself: the firewall terminates the connection and re-originates it, inspecting and rewriting the application payload (FTP commands, HTTP, SMTP…). | Deepest control, per-protocol logic; expensive and protocol-specific. Each application needs its own proxy. |
| Circuit Level Gateway (CLG) | The TCP connection as a whole, not the individual packets: the gateway relays the session between the client and the server (e.g. SOCKS). | Middle ground: no application knowledge, but the connection is established, tracked and torn down explicitly. |
Know the three control techniques and where each one looks: packet filter (single packets, L3/L4 headers), ALG (application data, protocol-aware proxy), CLG (the whole circuit/connection, relayed without application knowledge). A modern firewall combines them: a packet filter for speed, state tracking to make it stateful, and ALGs where the protocol demands it.
The pure packet filter has well-known vulnerabilities, all of which amount to the same weakness: it judges each packet in isolation, so it can be fooled about what a stream of packets means:
The stateless packet filter has a second, subtler limitation: directionality is a lie. A rule allowing outbound HTTP must also let the responses come back — but a stateless filter cannot tell a response from an unsolicited inbound connection, so it must open the return ports completely or break the service. The answer is the stateful packet filter, which keeps a state table of active connections: only the first packet of a connection is checked against the rules; the following packets are matched against the state table and admitted if they belong to an established connection. Directionality is recovered, because the table knows which side initiated.
The bastion host is the hardened machine that implements the policy — the machine an attacker would have to compromise first, and the one that must survive an attack on the perimeter. A personal firewall is the same idea reduced to a single host: a software filter on the endpoint that controls what that host accepts and originates, the last line of defence once the perimeter has been crossed (and the first, for mobile hosts that leave the perimeter entirely).
A famous case shows why state matters beyond the headers: FTP. In active mode the client connects to the server's port 21, but the server then opens the data connection back to the client — an inbound connection the perimeter never asked for. A stateless filter must choose between blocking FTP data entirely and opening a huge port range. The stateful filter can do better, but the port is negotiated inside the application protocol: only an FTP ALG (or an nftables/iptables ftp helper) can read the PORT command, open exactly the negotiated port, and close it when the transfer ends. This is the standard example of why application awareness still matters on top of state tracking.
On Linux, all of this is Netfilter: the packet-processing framework in the kernel, exposed to the administrator through iptables. The mental model is a pipeline of five hooks — fixed points in the kernel's journey of a packet where registered chains are consulted:
Rules are organized in tables by purpose — filter (allow/deny decisions), nat (address translation), mangle (packet alteration: TOS, TTL, marks), raw (exemption from connection tracking) — and each table has built-in chains corresponding to the hooks it cares about. A rule is a set of match conditions and a target: ACCEPT, DROP, REJECT (like DROP but answers with an error packet), LOG (log and continue), JUMP to a custom chain, or the NAT targets SNAT, MASQUERADE, DNAT, REDIRECT. Rules are evaluated in order; the first matching target decides, and each chain has a policy (default target) for packets that match nothing.
The stateful heart is connection tracking (conntrack), which the course has been promising since chapter 4's NAT lab: the kernel keeps a table of active flows and labels each packet with a state — NEW (first packet of a connection), ESTABLISHED (part of a connection that has been seen in both directions), RELATED (a new connection started by an established one, e.g. the FTP data channel), INVALID (packet that matches no connection and cannot be classified). A stateful filter needs only a handful of rules: allow ESTABLISHED,RELATED back in, and apply the policy to NEW only.
The classic stateful ruleset for a router/firewall is short, and every line is a decision about the course's own continuum (chapters 2–4): the firewall is a namespace with forwarding enabled, and iptables is how its kernel treats the packets that cross it. The widget below is that ruleset, annotated line by line.
Two iptables details complete the picture. Custom chains exist because a chain is just a list of rules: by jumping into a named chain you factor a policy into reusable, readable units (the widget's LAN_NEW). And counters are the firewall's built-in observability: iptables -L -v shows per-rule packet and byte counters, -Z zeroes them — the cheapest monitoring instrument in the course, and the one that tells you whether a rule is ever matched (a drop rule with zero hits is a rule nobody asked for).
Chapter 4's lab left two questions open: when to remove NAT entries? and what if both ends are behind NAT? The answers live here. Entries are removed when the tracked connection expires or closes — the state table drives the NAT table, not the other way round. And both-ends-behind-NAT is exactly the problem of the NAT traversal techniques (STUN/TURN, hole punching) that the course's mobile chapters assume, and that no firewall rule alone can solve: the stateful firewall knows a flow exists, not where the peer is. That is why MASQUERADE — SNAT with the output interface's address, per the firewall deck — is the natural gateway rule, and why it is configured at POSTROUTING.
nftables is Netfilter's successor framework, the native replacement for iptables (the iptables-nft compatibility layer translates old commands onto it). The model is the same hooks and tables, but the language is a single coherent ruleset instead of a pile of per-table commands:
ip, ip6, inet for both at once, arp, bridge) and contain the chains.filter, nat, route…), the hook they attach to, and a priority — hook ordering is explicit, not implied by table names.accept, drop, reject, jump/goto (to a chain), return, queue, or continue.Both frameworks expose the same Netfilter hooks (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING), the same tables by purpose (filter, nat, mangle, raw), the same connection tracking, and the same NAT operations. The difference is expression: iptables is a command language — one command per rule, tables implied by -t; nftables is a ruleset language — one file, tables and chains declared explicitly, hooks and priorities visible.
iptables: iptables -t filter -A FORWARD -i eth0 -m conntrack --ctstate NEW -j LAN_NEW. The table is a flag, the chain is a positional argument, matches are extensions (-m), and every change is a separate command executed in order. Reading a policy means replaying a shell history; there is no single document that says what the firewall does.
nftables: the same intent is a line inside a declared table and chain — chain forward { type filter hook forward priority filter; policy drop; iifname "eth0" ct state new jump lan_new }. The whole firewall is one nft -f file, reloadable atomically, with set/map lookups replacing rule repetition and nft list ruleset printing the entire effective policy.
NAT in nftables lives in nat-type chains on the same hooks as iptables — masquerade at postrouting, dnat at prerouting — and notrack is the explicit counterpart of iptables' raw table: a statement that tells conntrack to leave a flow alone (used when connection tracking itself is the cost, or the traffic is known-safe). Two final properties make nftables the better citizen for this course: the ruleset is data — it can be generated, versioned and validated like the YANG configs of chapter 13 — and it is available inside every network namespace, which means the entire lab world of chapters 2–4 can carry a real firewall in a few lines.
Do not memorize nftables as a new firewall. It is the same Netfilter pipeline (hooks, tables, conntrack) with a better language: declarative tables and chains, explicit hook priorities, sets/maps instead of rule repetition, atomic reloads. Every concept of section 2 — states, NAT, custom chains, counters — survives unchanged; only the syntax is new. And iptables-nft means old commands keep working on the new engine.
A firewall decides what may cross; monitoring decides what the network is actually doing. The lecture's stack has three instruments with different jobs:
Detection is a statistical decision, and the lecture is explicit about its two failure modes. A false positive (FP) is an alert when there is no attack — noise that exhausts the analyst; a false negative (FN) is an attack that produces no alert — the failure that actually hurts. The two trade off against each other: push sensitivity up and the FP flood drowns the real signals; push it down and attacks pass silently. A good rule set is measured on both numbers, not on "alerts fired".
The instruments split by what they watch. A NIDS (network-based) watches the wire — signature and anomaly detection over traffic; a HIDS (host-based) watches a single machine — files, processes, system calls, logs; EDR (Endpoint Detection and Response) is the modern HIDS: an endpoint agent that detects, and also responds (isolating a host, killing a process) under the SOC's control. Complementary, not competing: the NIDS sees the attack crossing the network; the HIDS/EDR sees what it did once it arrived.
Integrity checkers (AIDE, AFICK, Tripwire) are the HIDS's oldest trick: a baseline snapshot of file hashes (and metadata) is computed in a trusted state; later scans compare the live filesystem against the baseline and report changes — the file that was modified when nobody should have modified it. AIDE and AFICK are both Tripwire-style tools, AIDE being the widely deployed one (e.g. on Linux distributions and network appliances). Logging is the raw material of everything else: syslog (the traditional facility/severity log stream over UDP/TCP, or the journald binary journal on systemd systems) carries application and kernel events; auditd records security-relevant actions (who opened which file, which syscall, from which process). Log analysis is what turns that stream into knowledge; a SIEM is the analysis at fleet scale.
The lecture's concrete stack is the open-source mainstream: the Elastic Stack (Elasticsearch, Logstash/Beats, Kibana) as the collection/storage/visualization platform, Wazuh as the open-source HIDS/SIEM built on it (file integrity, log analysis, vulnerability detection, active response), and OSSEC as the classical agent-based HIDS that Wazuh derives from. The architecture is exactly plate 14.8: agents on the hosts, rules on the collection layer, correlation in the engine, dashboards for the humans.
Every instrument in this section has a price. The NIDS costs a mirror port and CPU per packet; the HIDS/EDR costs an agent on every host; the SIEM costs storage for every log, and analyst time for every alert. The FP/FN trade-off of plate 14.7 is an economic decision: a rule set tuned to zero false positives is usually tuned to blindness. Chapter 10's cyber range exists precisely to test IDS rules and detection coverage in a safe replica before the policy hits production — the monitoring of this chapter and the testing of chapter 10 are one workflow.
Suricata is the course's worked NIDS: an open-source, multi-threaded engine that performs intrusion detection (and prevention, inline) and network security monitoring. Its rule language descends from Snort's, and reading a rule is the fastest way to understand what an NIDS rule set actually says. A rule is one line with three parts: the action (alert, drop, reject, pass), the header (protocol, source address/port, direction, destination address/port), and the options in parentheses: content matches, metadata, and the rule's identity.
The meta settings are the rule's paperwork: msg (the human-readable alert text), sid (a globally unique rule ID — the community convention reserves ranges, and your own rules start at 2000000+ to avoid collisions), rev (revision, incremented on every edit), classtype (the attack category, mapped to priority), priority (1–4 severity) and metadata (free-form tags for filtering). The content options are the detection itself: literal byte sequences, hex escapes, PCRE, case-insensitive modifiers — matched against the payload (or, with the right keywords, against the headers).
Suricata's CLI is built for exactly the workflow the course's labs need — testing rules against captured traffic without touching a live network:
suricata -T -c suricata.yaml -S local.rules — test mode: validates the configuration and every rule, printing errors for rules that do not compile. Always run this before anything else.suricata -r capture.pcap -l out/ -S local.rules — offline mode: replays a pcap through the detection engine; no interfaces touched, fully reproducible. The companion of the Wireshark captures of chapters 4 and 11.suricata -i eth0 — live mode on an interface (or with --af-packet on a mirror port) for real deployment.out/eve.json, one JSON object per event (alert, flow, http, dns…), consumable by jq, Elasticsearch, or any SIEM — the machine-readable counterpart of the log streams of section 4.The lab exercises follow one loop: capture → write a rule → test → replay → read the alert. Capture a suspicious exchange in Wireshark (or use a supplied pcap), write a rule that matches its signature (the content bytes, the right ports, the right sid), validate with -T, replay with -r, then confirm the alert in eve.json — checking that your sid fired and the msg says what you intended. A rule that never fires in the pcap is a rule whose signature does not match the traffic: the FP/FN lesson of section 4, experienced directly. Iterate: widen or narrow the content match, bump rev, re-run.
(1) Choke point — all traffic between inside and outside passes through the firewall, and there is no alternative route; (2) default deny — what is not explicitly allowed is denied; (3) self-protection — the firewall itself must be immune to compromise (a hardened bastion).
Packet filter — inspects each packet's L3/L4 headers (addresses, protocol, ports) in isolation; fast and stateless. Application Level Gateway (ALG) — a protocol-aware proxy that terminates and re-originates connections, inspecting application data (FTP, HTTP…); deepest control, most expensive. Circuit Level Gateway (CLG) — relays whole connections without application knowledge (e.g. SOCKS); middle ground.
Because it judges each packet in isolation. Fragmentation: the filter sees fragments, not the reassembled datagram, and overlapping fragments can hide a payload. Spoofing: the source address is not authenticated, so a filter must block internal-looking source addresses at the perimeter — and nothing more can be done statelessly. Source routing: the IP source-route option dictates the return path, bypassing the choke point — such packets should be dropped at the perimeter.
The state table remembers active connections, so only the first packet of a connection is judged against the rules; the rest are admitted if they belong to an established connection. This recovers directionality: a filter can allow outbound HTTP and admit only the responses, without opening the return ports to everyone. It is the difference between judging packets and judging connections.
Active FTP opens the data connection from the server back to the client, on a port negotiated inside the PORT command. A stateless filter cannot handle the inbound connection safely; a stateful filter knows the connection exists but cannot see the negotiated port, because it is inside the application payload. The fix is an FTP ALG (or the kernel's ftp helper): it reads the PORT command, opens exactly the negotiated port, and closes it when the transfer ends.
PREROUTING — first stop on arrival, before routing (DNAT lives here); INPUT — traffic addressed to the local machine; FORWARD — traffic routed through the machine (the router/firewall path); OUTPUT — locally generated traffic; POSTROUTING — after routing, before leaving (SNAT/MASQUERADE live here).
filter — the allow/deny decisions; nat — address translation (SNAT/MASQUERADE/DNAT/REDIRECT); mangle — packet alteration (TOS, TTL, marks); raw — exemption from connection tracking. Each table has built-in chains on the hooks it uses; rules are evaluated in order and each chain ends with a policy (default target).
NEW — first packet of a connection, not seen before: the only state the security policy really judges. ESTABLISHED — the connection has been seen in both directions. RELATED — a new connection started by an established one (FTP data channel, ICMP errors), admitted like its parent. INVALID — unclassifiable, to be dropped. A stateful filter needs rules for ESTABLISHED,RELATED inbound and a policy for NEW.
Connection tracking drives NAT: the first packet is rewritten by the nat table (SNAT/MASQUERADE at POSTROUTING, DNAT at PREROUTING) and its translation is recorded in the state table; the rest of the flow is rewritten automatically from that record, replies are restored to the original address, and entries are removed when the tracked connection closes or expires. This answers chapter 4's question of when to remove NAT entries: when the flow ends.
Same Netfilter hooks and tables, different language. iptables is a command language — one command per rule, table as a flag, matches as extensions, no single view of the policy. nftables is a ruleset language: tables and chains declared per family (ip/ip6/inet), hooks and priorities explicit, verdicts (accept/drop/reject/jump/return/queue/continue), sets, maps and vmaps replacing repeated rules, atomic reloads with nft -f, and notrack as the explicit counterpart of the raw table. iptables-nft provides compatibility.
IDS — detection and reporting only, passive (e.g. on a mirror port). IPS — the same detection placed inline, able to drop or reset the offending traffic. SIEM — the aggregation and correlation layer: it collects logs and alerts from all sources, normalizes and correlates them, and drives dashboards and incident workflows.
A false positive is an alert when there is no attack (noise that burns analyst time); a false negative is an attack that produces no alert. The false negative is the dangerous failure — the attack the defenders never see — but they trade off against each other: higher sensitivity means more FPs, lower sensitivity means more FNs.
NIDS — network-based, watches traffic (signature/anomaly detection). HIDS — host-based, watches one machine: files, processes, system calls, logs (integrity checkers like AIDE/AFICK are its classic tool). EDR — the modern endpoint agent that detects and responds (isolating a host, killing a process) under the SOC's control. Complementary: the NIDS sees the attack cross the network, the endpoint agent sees what it did.
AIDE/AFICK are Tripwire-style integrity checkers: a baseline of file hashes and metadata is compared against later scans to reveal unauthorized changes. syslog/journald carry the application and kernel log streams (journald being systemd's binary journal). auditd records security-relevant actions — which process performed which syscall on which file. Together they are the raw material the SIEM normalizes and correlates.
One line: action (alert/drop/reject/pass), header (protocol, source address/port, direction arrow, destination address/port), and options in parentheses — content matches (byte sequences, hex escapes, PCRE) plus meta settings: msg (alert text), sid (globally unique rule ID; local rules start at 2000000+), rev (revision), classtype (category mapped to priority), priority (severity 1–4) and metadata (free-form tags).
Validate the ruleset and config with suricata -T -c suricata.yaml -S local.rules; replay the capture offline with suricata -r capture.pcap -l out/ -S local.rules; then read the alerts from out/eve.json (one JSON object per event), checking that the intended sid fired. A rule that never fires in the pcap means the signature does not match the traffic — iterate, bump rev, re-run. Live deployment uses suricata -i on an interface (or af-packet on a mirror port).