Step 161. Firewalls and iptables — Designing the Gatekeeper’s Rules

Level 2 — Network Attacks and MITM | Difficulty ★★★☆☆ | Estimated time: 3 hours

Prerequisites: Step 28 (port scanning) and Step 29 (remote SSH access) complete. You need a Linux machine for iptables practice (VM or WSL) and Windows PowerShell.

What you need: a Linux environment (iptables) and Windows PowerShell (reading the firewall). Reading rules is safe anywhere; adding or deleting rules is for a dedicated lab VM only.
⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime. Caution: changing firewall rules is a system configuration change that takes effect immediately — on a remote server, the mistake of switching the default policy to DROP cuts your own connection. The iptables -L outputs and Windows firewall status in this chapter were measured on 2026-09-09; the outputs of rule-adding commands are environment-dependent and marked as output examples.

Until now you’ve been the one knocking on doors — finding open ports with nmap, getting in with SSH, intercepting traffic. Today you stand on the other side. A firewall is a gatekeeper that decides "which packets to let in and which to throw out" through rules, and iptables is the language for handing those rules to Linux’s gatekeeper. Today, flip your perspective: the nmap output an attacker reads was really "the list the firewall allowed" all along. Only someone who has designed the gatekeeper’s rules can see the gaps in them.

1. Learning Objectives

By the end of this chapter, you will be able to:

Explain the meaning of chains (INPUT/OUTPUT/FORWARD) and targets (ACCEPT/DROP/REJECT)
Explain that iptables rules are checked "in order, from the top"
Read and interpret the current rules (iptables -L -n -v)
Know the order of whitelist design (default DROP + ACCEPT only what’s needed)
Read and interpret the Windows firewall’s profiles and default policies
Explain firewall bypass paths from an attacker’s perspective

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	Linux terminal (iptables) + Windows PowerShell (netsh, Get-NetFirewallRule)
Today’s commands	`iptables -L -n -v` (read rules), `iptables -A INPUT ...` (add rule), `iptables -P INPUT DROP` (default policy), `iptables-save` (save), `netsh advfirewall show currentprofile` (Windows status)
Concepts needed	chains, rules, targets, default policy, state tracking (conntrack), whitelist/blacklist
Today’s artifact	an interpretive memo of current rules + a whitelist design + a bypass-perspective summary

2-1. Chains — The Three Gates a Packet Passes Through

In iptables, a packet passes through one of three gates (chains) depending on its purpose.

INPUT: packets coming into this computer. The main stage of server defense.
OUTPUT: packets leaving this computer.
FORWARD: packets passing through this computer on their way elsewhere. Meaningful only when the machine acts as a router.

Each gate has rules attached top to bottom, and a packet meets the rules one by one until it follows the target of the first rule whose conditions match. There are three targets — ACCEPT (let through), DROP (silently discard — the sender waits until timeout), REJECT (reply that it was refused). If no rule matches, the default policy applies at the end.

2-2. Whitelist Design — "Close Everything, Open Only What’s Needed"

The iron rule of firewall design is whitelisting: set the default policy to DROP and open only the necessary doors with rules. The opposite design (default ACCEPT + DROP only the bad ones — a blacklist) requires "knowing everything to block in advance," which is practically impossible.

But order is life. Before switching the default policy to DROP, you must open two things first. ① Responses to connections I initiated (ESTABLISHED) — without this, even my SSH session’s reply packets get DROPped. ② The services to admit (e.g., SSH port 22). Reverse the order on a remote server and you cut your own ankle.

2-3. conntrack — "This Is a Follow-Up to That Earlier Conversation"

A firewall can track not just individual packets but the state of connections. The conntrack (connection tracking) module recognizes "this packet is part of an already-established connection." -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT means "let follow-up packets of conversations already started through," and it is effectively the first rule of whitelist design. Thanks to it, "outgoing goes freely; only incoming new connections get checked" becomes possible.

2-4. The Windows Firewall — Same Philosophy, Different Words

Windows also has a built-in firewall (Windows Defender Firewall) doing the same job. Instead of iptables chains, it’s organized into profiles (Domain/Private/Public — policies per the kind of network the computer is on) and inbound/outbound rules, read and written with PowerShell’s Get-NetFirewallRule or netsh advfirewall. The basic philosophy is the same — inbound blocked by default, outbound allowed by default.

3. Follow Along

3-1. Reading the Current Rules — The Gatekeeper’s Attendance Sheet

Input (Linux):

sudo iptables -L -n -v

Output (measured 2026-09-09, WSL Ubuntu — an environment with Docker installed):

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DOCKER-USER  0    --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 DOCKER-FORWARD  0 --  *      *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain DOCKER-USER (1 references)
 ...

How to read it: the three basic chains are visible. Chain INPUT (policy ACCEPT ...) — this lab’s inbound door has a default policy of ACCEPT, meaning it’s effectively undefended. The rule rows are empty too. FORWARD, on the other hand, is policy DROP with Docker-created chains (DOCKER-USER, etc.) attached — Docker automatically wrote rules for container networking. "Being empty" is also information: this computer currently accepts every incoming connection. If your environment isn’t WSL, you may see only three totally empty chains with no Docker chains — that’s actually the standard initial state.

How to read the options: -L lists, -n shows addresses numerically (skipping name resolution for speed), -v adds packet and byte counters. Rising counters tell you "is the rule actually catching packets?"

3-2. Whitelist Design — The Order of Commands

Now the design procedure on a dedicated lab VM. The commands below change system settings — run them only on a lab VM. Outputs are environment-dependent and shown as examples.

Input:

# 1. Let responses to conversations already started through (this must be the first rule)
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# 2. Trust the loopback (communication between local services)
sudo iptables -A INPUT -i lo -j ACCEPT
# 3. Open only SSH for new connections
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# 4. Close everything else (default policy)
sudo iptables -P INPUT DROP
# Verify
sudo iptables -L INPUT -n -v

Output example:

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     0    --  *      *       0.0.0.0/0    0.0.0.0/0   ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     0    --  lo     *       0.0.0.0/0    0.0.0.0/0
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0    0.0.0.0/0   tcp dpt:22

How to read it: the default policy changed to DROP, with three exception lines above it. Packets are compared from the top — "already-started conversation?" → "local traffic?" → "coming to SSH?" → if none of the three, policy DROP. That’s the whitelist.

Why order matters: the moment you run #4 first, with no allow rules yet, your reply packets drop instantly if you’re connected remotely. #1 (allow ESTABLISHED) must exist first for the current session to survive. Firewall work always "secures the exit first."

3-3. Verification — Checking with an Attacker’s Eyes

Once the design is in place, knock on it from outside with nmap (from Kali or another lab machine).

nmap 192.168.56.103

Output example:

PORT   STATE SERVICE
22/tcp open  ssh

How to read it: only port 22 shows in the scan results. DROPped ports give no response, so nmap marks them "filtered" (firewall presumed), while ports with no rule but no service listening are marked "closed" — the difference between these two is the firewall’s fingerprint. If you want to open a web server, add a --dport 80 rule after the port-22 rule and scan again.

3-4. Saving and Resetting — Managing Rule Lifetimes

iptables rules vanish on reboot. Know how to save, restore, and reset in an emergency.

sudo iptables-save > rules.v4        # save current rules to a file
sudo iptables-restore < rules.v4     # restore from the file
sudo iptables -F                     # ⚠️ delete all rules (policy stays — if it's DROP, still closed)

How to read it: -F (flush) deletes only the rules and leaves the default policy untouched. Deleting rules while the policy is DROP closes every door, so when resetting, the safe order is to restore the policy first with sudo iptables -P INPUT ACCEPT.

3-5. Reading the Windows Firewall — My PC’s Gatekeeper

Even without Linux, your Windows machine has a firewall running right now. Check it with read-only commands.

Input (PowerShell):

netsh advfirewall show currentprofile
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction

Output (measured 2026-09-09, Korean Windows):

상태                                  사용
방화벽 정책                           BlockInbound,AllowOutbound
...

Name    Enabled DefaultInboundAction DefaultOutboundAction
----    ------- -------------------- ---------------------
Domain     True        NotConfigured         NotConfigured
Private    True        NotConfigured         NotConfigured
Public     True        NotConfigured         NotConfigured

How to read it: BlockInbound,AllowOutbound — new inbound connections blocked by default, outbound allowed by default. The whitelist philosophy of 2-2 is already implemented as Windows’s default. The three profiles’ NotConfigured means "no explicit setting, so the defaults (inbound block / outbound allow) apply." This computer’s rule count, checked with (Get-NetFirewallRule | Measure-Object).Count, was 727 (measured 2026-09-09) — most are exceptions registered when programs were installed. Since an attacker who plants malware tries to quietly add their own rule here, auditing the rule list is a basic incident-investigation item.

3-6. The Bypass Perspective — A Gatekeeper Who Knows How Gatekeepers Are Avoided

If the firewall says "only port 22 open," what does an attacker do? Here are the representative paths.

Bypass	Principle
Reverse connection through an open port	The victim connects outward (OUTPUT is usually free) → ride that connection back in
Attack the allowed service itself	If 22 is open, SSH brute force — which is why key authentication is essential
DNS/ICMP tunneling	Hide and exfiltrate data inside DNS queries, which firewalls usually allow
Via the web	If 80/443 are open, get in through a web vulnerability and move around inside

How to read it: notice the common thread — every one of them uses "a path the firewall allowed." A firewall is a tool for reducing the number of doors, not a tool for guarding open ones. Managing the services behind open doors (patching, authentication) comes as a set with the firewall.

4. Missions & Exercises

Mission — A Whitelist Design Document for My Lab

Read the current state with iptables -L -n -v (or Windows’s netsh advfirewall show currentprofile) and write an interpretive memo: what the default policy is, which chains/rules exist.
On a lab VM, run the four lines of 3-2 and paste the before/after iptables -L outputs side by side. Annotate what each line does.
Scan before/after with nmap and record the difference. (If you have no VM, substitute this: pick three inbound-block Windows firewall rules with Get-NetFirewallRule -Enabled True -Direction Inbound -Action Block and interpret them.)
When the request "we also need to open the web server (80)" comes in, write the one rule to add and where (at which position) to put it, with reasons.

Exercises

Exercise 1. DROP and REJECT both block packets. From an attacker’s (nmap user’s) standpoint, what’s the difference, and why do server admins prefer DROP?

Exercise 2. Explain, in the context of remote SSH work, why you must add -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT before switching the default policy to DROP.

Exercise 3. Explain why a whitelist (default DROP) is safer than a blacklist (default ACCEPT) using the concept of "not knowing."

Exercise 4. Given the Windows firewall defaults (BlockInbound, AllowOutbound), explain why malware chooses to "connect outward first" instead of "waiting for incoming connections" to talk to its command server (C2).

5. Model Answers & Completion Criteria

Mission Model Answer

Interpretation for #1 (per the lab measured 2026-09-09): "INPUT has policy ACCEPT with no rules — an open state accepting every incoming connection. FORWARD has policy DROP with Docker-managed chains attached — this machine acts as a bridge for containers. OUTPUT is open."

Annotation example for #2:

Rule 1: ESTABLISHED,RELATED ACCEPT — pass follow-up packets of conversations already started. Without this, even my SSH replies get DROPped
Rule 2: lo ACCEPT — local traffic between 127.0.0.1 addresses is exempt from firewall checks
Rule 3: tcp dpt:22 ACCEPT — allow only new incoming SSH connections
Policy: INPUT DROP — discard every inbound packet not covered by the three above

#4: place sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT after the port-22 rule (since -A appends to the end, it lands there naturally). The policy (DROP) isn’t a rule but the chain’s default, always applied last, so rules added with -A are automatically checked before DROP. There’s also the method of inserting at a position, like -I INPUT 1.

How to verify: ① Did the policy change from ACCEPT→DROP in the before/after outputs? ② Is the ESTABLISHED rule the first line of the list? ③ Did the nmap result shrink to "only 22 open" (or, for the Windows substitute task, is the block-rule interpretation correct)? ④ Did you explain the position of the port-80 rule in terms of "check order"?

Exercise Answers

Answer 1. REJECT sends back a "refused" response (ICMP or TCP RST), so the attacker immediately knows "the port is closed and a firewall told me right away"; DROP gives no response at all, so they only know "the packet vanished." DROP slows scanning (a timeout wait every time) and gives less information. That said, nmap infers "filtered" from the very absence of a response, so it’s not perfect concealment.

Answer 2. An SSH session is ultimately a sequence of packets going in and out. If the default policy DROP applies first, even the follow-up packets of my already-connected session (the responses the server sends) get discarded at the INPUT check, and the connection drops instantly. If ESTABLISHED allow comes first, "conversations already started" survive regardless of the policy.

Answer 3. A blacklist stands on the assumption "we already know everything that must be blocked," but new threats are by definition not on the list — you can’t block what you don’t know. A whitelist assumes the opposite — "we only know what to allow" — so the unknown is blocked automatically. It’s a design where the safe side becomes the default.

Answer 4. Because of AllowOutbound, new outbound connections are allowed by default. If malware on the victim PC connects out to the C2 server first, the communication channel opens without piercing the firewall head-on, and responses over the established connection can come back in as ESTABLISHED traffic. That’s why defense needs not just inbound monitoring but outbound monitoring too (detecting anomalous external connections).

Completion Criteria Checklist

[ ] I can explain the roles of the three chains INPUT/OUTPUT/FORWARD
[ ] I can explain the differences between ACCEPT/DROP/REJECT
[ ] I can read the policy and rules in iptables -L -n -v output
[ ] I know the correct order for adding whitelist rules (ESTABLISHED → lo → service → policy)
[ ] I know the roles and caveats of iptables-save and -F
[ ] I can read the Windows firewall’s default policy (BlockInbound, AllowOutbound)
[ ] I can explain two or more firewall bypass paths from an attacker’s perspective

6. Common Pitfalls & Fixes

Wall 1. "I set the policy to DROP and SSH cut off"

Symptom: the remote session freezes right after running iptables -P INPUT DROP.
Cause: you changed the policy before adding the ESTABLISHED allow rule. A classic ordering mistake.
Fix: get in through the VM console (the physical screen), restore with sudo iptables -P INPUT ACCEPT, and redo it in 3-2’s order (exceptions first, policy last). For remote work, the habit of using iptables-apply (automatic rollback without confirmation within a time limit) is a safe one.

Wall 2. "I added a rule but it’s not taking effect"

Symptom: you opened port 80 but nmap doesn’t show it.
Cause: one of three. ① The rule went in but the service (web server) isn’t running — the firewall opens the door, but someone must be inside to answer. ② The rule you added with -A is trapped behind an earlier DROP-flavored rule. ③ You added it to a different chain or table.
Fix: on the server, first confirm the service is alive with ss -tlnp | grep 80, and look at the rule order with iptables -L INPUT -n -v --line-numbers.

Wall 3. "I rebooted and all my rules are gone"

Symptom: the rules you made yesterday aren’t in iptables -L.
Cause: iptables rules exist only in memory.
Fix: save with sudo iptables-save > /etc/iptables/rules.v4 and set up restore at boot (per distro, the iptables-persistent package or a systemd service). In a lab where you only experiment without saving, vanishing is actually cleaner.

Wall 4. "iptables is completely empty on WSL"

Symptom: like the measured environment, only Docker chains or nothing at all.
Cause: WSL’s firewall effectively sits behind the Windows host’s firewall. iptables inside WSL is not a complete boundary.
Fix: concept practice works fine (adding rules and reading them with -L), but do the "real gatekeeper" practice on a dedicated Linux lab VM. On WSL, never touch the host firewall.

Wall 5. "Get-NetFirewallRule returns way too much in PowerShell"

Symptom: hundreds of lines pour out.
Cause: that’s normal — the measured machine had 727 too.
Fix: narrow it down. Limit conditions and count like Get-NetFirewallRule -Enabled True -Direction Inbound -Action Allow | Select-Object -First 10 DisplayName. In incident investigation, a tip is to look at "recently created rules" first.

7. Summary

Today’s Concepts

Concept	One-line explanation
Firewall	A gatekeeper that decides packet passage by rules
Chain (INPUT/OUTPUT/FORWARD)	The three gates for incoming / outgoing / transiting packets
Target (ACCEPT/DROP/REJECT)	Pass / silently discard / refuse with a reply
Default policy	The final disposition of packets that matched no rule
Whitelist	Default DROP + ACCEPT only what’s needed — the unknown is blocked automatically
conntrack / ESTABLISHED	Connection state tracking — the device that recognizes "conversations already started"
iptables-save / -F	Save rules / delete all (note: the policy remains)
Profile (Windows)	Policy bundle per Domain/Private/Public network — default BlockInbound

Today’s Commands

Command	What it does
`sudo iptables -L -n -v`	Read current rules and policy (with counters)
`sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT`	Pass conversations already started — the first rule
`sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT`	Allow new SSH connections
`sudo iptables -P INPUT DROP`	Set the default policy to DROP — always last
`sudo iptables-save > rules.v4` / `sudo iptables-restore < rules.v4`	Save / restore rules
`sudo iptables -F`	Delete all rules (⚠️ policy is kept)
`netsh advfirewall show currentprofile`	Current Windows firewall profile status
`Get-NetFirewallRule -Enabled True -Direction Inbound -Action Block`	Read Windows block rules

An Instinct More Important Than Commands

The essence of a firewall is not "blocking technology" but "ordered judgment." Rules read from the top, a policy waiting at the end — once you understand this structure, nmap output starts to look not like "a list of open doors" but like "the result of judgments someone designed."

And remember that attack and defense read the same table. The door you open with -A INPUT is the door an intruder looks for, and the door you close with DROP becomes the intruder’s motive to bypass. Today’s experience of designing the gatekeeper becomes the eye that reads "the designer’s intent" the next time you diagnose someone’s firewall.

Once every box is checked, Step 161 is complete. Click the checkbox in the sidebar to save your progress.