Firewalls as Policy, Not Magic

On a wire, a packet arrives with addresses and ports. A firewall is software or an appliance that compares that packet to a written policy and then allows, drops, or rejects it. “Written” is the whole point. If you cannot say who may speak to which port, the device is guessing, and guessing is how leftover SSH faces the café. In Cyberlium wording, you treat a firewall as a policy engine you configure on a host or network YOU administer — the same ownership line Module 1 drew. It is not a costume that makes unauthorized scanning quiet. It is not a puzzle you are assigned to defeat on a school edge. Skill does not create consent. A catalog module named “evading” does not create consent.

Packet filters look at each datagram in isolation: source, destination, protocol, port. That is enough to say “inbound TCP/22 from the world is denied.” It is not enough to say “this inbound packet is the reply to a web request I started.” Stateful inspection keeps a table of conversations it already allowed, so return traffic for YOUR outbound HTTPS can come back without you publishing a hole for every ephemeral port. That memory is why “allow established” is a defender sentence, not an attacker cheat. This lesson names the memory so you can turn it on for a lab you own. It does not teach you to forge state, fragment past the table, or ride an allowed port as a tunnel through someone else’s policy.

cat >> "$NOTES" << 'EOF'
firewall_means: policy decided, then packets compared
not_magic: a wide allow still fails closed
EOF

An allow list (sometimes called a default-deny posture) says: only these sources, destinations, and ports may pass; everything else is refused. A deny list (default-allow with exceptions) says: block these known-bad things; everything else may pass. Deny lists feel busy and still leak: you cannot name every future abuse. Allow lists feel strict and match how production edges actually survive. For a lab VM you own, default deny inbound is the adult setting. Then you add the two or three inbound services you truly need — often SSH for you, HTTP or HTTPS if you run a teaching listener you started — and you write why each line exists. “I might need it later” is not a why. Module 4 already stopped leftover listeners. This module stops leftover holes.

Direction matters. Inbound is traffic someone sends toward a port on YOUR box. Outbound is traffic YOUR box starts. Many host firewalls allow outbound by default so your browser works, and still default-deny inbound so the café cannot knock on 22. That split is literacy. It is not a recipe for sneaking outbound callbacks past someone else’s wall. If you administer a VM, write inbound and outbound as separate columns. If you do not own a VM today, you still complete this lesson with a labeled hypothetical you own: “lab-vm-01 I would create,” ports you would allow, default deny. Do not “borrow” a campus edge because a hypothetical felt too small.

Stateless filtering is a bouncer who checks each guest’s badge and forgets them at the next door. Stateful inspection is a bouncer with a clipboard of who already came in with a ticket. After you (the host) start an outbound TCP handshake that the policy allows, the reply packets belong to that flow. The engine should not require you to publish inbound “any high port” just so HTTPS can complete. UDP and ICMP have shorter or different memory; the exact timers are vendor details you read in YOUR product’s docs when you own the box — not a timing-evasion lab. The teaching sentence is: state exists so legitimate replies can return without a wide inbound hole.

Host firewalls (Windows Defender Firewall, nftables/ufw on a Linux VM you created, pf on a BSD lab you own) and network firewalls (a hypervisor virtual switch ACL, a home-lab router you administer) both implement some mix of packet filter plus state. Application-layer gateways and web application firewalls sit higher and are named so you know they exist — Topic 10 and later web modules own app input. This lesson stays on ports and conversations. You will not get a “bypass stateful inspection with fragmented overlapping TCP” cookbook. If a sentence would help someone hide from a wall they do not own, it does not belong in your notes.

Allowed surface for Module 12: a computer you own, a VM you created, a home-lab router whose admin you are, or a hypothetical labeled as yours. You may read the current host-firewall status on THAT box (Windows firewall profiles, ufw status, nft list on a machine you administer) as inventory — the same “settings you may change” rule as Module 6 hardening. You may write intended rules before you apply them. Lesson 4 is where you document the inbound allow list. You may not reconfigure a school firewall, a café gateway, a cloud tenant you do not own, or a roommate’s router “because they probably would not mind.” Written RoE from Module 1 still wins.

Binding and firewalling are cousins. Module 4 bound python http.server to 127.0.0.1 so the café could not enum you by accident. A host firewall that default-denies inbound is the same idea at the packet layer: even if a daemon binds 0.0.0.0, the policy can still refuse WAN clients. Prefer both: bind loopback or a lab LAN when you can, and still default-deny inbound from untrusted networks. Publishing SSH to 0.0.0.0/0 “so Discord can grade my lab” is how teaching VMs become botnets (Module 10). If you need SSH, name the source: your admin IP, a VPN you run, or a host-only hypervisor network. Needless any-source allow is the failure this heading exists to kill.

A firewall-policy note is boring on purpose. Date (UTC). Legal line: original Cyberlium teaching mapped to the CEH v13 IDS/firewall/honeypot domain — not official EC-Council training, not a cert, not exam dumps. Definitions in your words: allow list, deny list, default deny, stateful inspection. Surface: machine you own or hypothetical you own. Intended inbound services (names, not a bypass). Ethics: no IDS evasion steps, no nmap decoys/fragments/timing to hide, no firewall punch of others, no attacking someone else’s honeypot. Path: $HOME/cyberlium-lab/firewall-policy-notes.txt, chmod 600. Empty files fail. Files that list campus rule IDs or café gateway tricks fail even if you “only planned.” World-readable 777 fails.

A useful feeling: the lesson is “too small” because you did not sneak a packet past a filter. That feeling is how people graduate into unauthorized access dressed as CEH homework. The skill is stopping at policy. Lesson 4 will let you write inbound allow for SSH/HTTP you need on a box you own — still default deny, still no 0.0.0.0 theater. Until then, a filled definition file is a complete Lesson 1. Do not add nmap -D, -f, or timing templates as “research.” Do not paste fragmentation one-liners into the notes.

On a computer you own, create cyberlium-lab if needed. Fill the template in your own words. Run the checker; it only reads YOUR file. chmod 600. Do not add a campus firewall because the file felt short. Windows without chmod: WSL/Git Bash, or restrict the files in your profile.

cat >> "$NOTES" << 'EOF'
stateful: remember established conversations
why_it_matters: inbound replies without opening all ports
EOF

You now treat a firewall as a written policy — allow lists, deny lists, default deny, stateful memory of conversations — that you configure on a lab you own. Punch recipes, decoys, fragments, and “evade the school edge” drills are out of this course. Notes are locked in cyberlium-lab. This is original Cyberlium teaching mapped to the CEH v13 IDS/firewall/honeypot domain — not official EC-Council training, not a cert, not exam dumps. Next — IDS/IPS: Signatures vs Anomalies — names how sensors fire, why alerts are clues, and why tuning beats turning detection off.