Module 5 · Firewall and ACL Design 🔒

Firewalls are everywhere. On your laptop, on every server, at every network boundary, in every cloud subnet. But the craft isn’t running a firewall — it’s designing rules that actually achieve least-privilege without being a blocker for legitimate work. This module covers firewall concepts, ACL design patterns, and the common mistakes that turn firewalls from security control into security theatre.

Firewall types

• Stateless packet filters — evaluate each packet independently. Fast, crude. (Modern firewalls don’t work this way.)
• Stateful firewalls — track connections; allow return traffic for established sessions. The default modern pattern.
• Next-Gen Firewalls (NGFW) — Palo Alto, Fortinet, Cisco Firepower. Add app-layer inspection (identify Dropbox vs BitTorrent vs Office 365), IDS/IPS, TLS decrypt, threat intel feeds.
• Web Application Firewalls (WAF) — Cloudflare, AWS WAF, ModSecurity. HTTP-layer; block SQLi, XSS, known attack patterns.
• Host-based — iptables, nftables, Windows Firewall. Last line of defence.
• Cloud-native — AWS Security Groups (stateful, instance-level) + NACLs (stateless, subnet-level); Azure NSGs; GCP Firewall Rules.

ACL design principles

1. Default deny — start by denying everything. Explicit allows only for required flows.
2. Scope by source — allow from specific IP ranges, not 0.0.0.0/0. VPN IP space, office IP, partner ranges.
3. Specific ports — not “allow any TCP”. Allow 443 specifically.
4. Document every rule — what it does, why it exists, who owns it, when to review.
5. Review quarterly — rules accumulate. Delete what’s no longer needed.
6. Log denies — for investigation. Log allows sparingly (volume).

iptables / nftables quick reference

# Default-deny baseline (iptables)
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Allow established sessions
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow loopback
iptables -A INPUT -i lo -j ACCEPT

# Allow SSH from office IP only
iptables -A INPUT -s 203.0.113.0/24 -p tcp --dport 22 -j ACCEPT

# Allow HTTPS from anywhere
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Log + drop everything else
iptables -A INPUT -j LOG --log-prefix "DROP-IN: " --log-level 4
iptables -A INPUT -j DROP

# Persist (depends on distro)
iptables-save > /etc/iptables/rules.v4

AWS Security Groups vs NACLs

Common ACL mistakes

• “0.0.0.0/0 → tcp:22” — SSH open to internet. Immediate brute-force target. Scope to VPN / office.
• “Allow all outbound” — default in AWS. Compromised workload freely exfiltrates + calls C2.
• Overly-broad “admin” source ranges — “10.0.0.0/8” when only 10.1.2.0/24 is needed.
• Rules with no documentation — nobody knows why it exists; nobody will ever remove it.
• Unmonitored denies — denies that never fire might mean the rule is redundant. Denies that fire often might mean a service is broken.
• Shadow rules — Rule 50 is “deny all” but Rule 1 is “allow all” → Rule 50 never matches.

Zero-trust network architecture

Traditional perimeter firewall is insufficient. Zero-trust principles at the network layer:

• Every service requires authentication (mTLS, identity-aware proxy)
• Network location doesn’t imply trust (“inside” traffic must still authenticate)
• Micro-segmentation: per-workload rules, not per-subnet
• Continuous validation: re-verify identity periodically, not just at connect

Tools: Istio/Linkerd service mesh (mTLS), Cilium CiliumNetworkPolicy (L7-aware), AWS VPC Lattice, Google Cloud Identity-Aware Proxy.