Chapter 4.1 Quiz - Firewall Architecture, Segmentation & Zero Trust

Quiz Mode - All answers are hidden under collapsible sections. Attempt each question before revealing the answer.

---

Question 1

A junior engineer adds the following iptables rules to a production web server in this order:

iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 192.168.1.0/24 -j DROP
iptables -A INPUT -j DROP

The intent was to block the 192.168.1.0/24 subnet from accessing HTTPS. Why does this ruleset fail, what is the correct order, and what additional rule is missing for a complete hardened configuration?

Reveal Answer

Answer: The ruleset fails because of first-match evaluation - the broad ACCEPT rule on line 1 matches all TCP/443 traffic, including traffic from 192.168.1.0/24. The DROP rule on line 2 is never reached for that subnet.

Why it fails: iptables evaluates rules top-to-bottom and stops at the first match. Any packet destined for port 443 matches rule 1 and is immediately accepted - the source IP check in rule 2 is irrelevant because evaluation already terminated.

Correct order - specific rules before general rules:

# Flush and rebuild
iptables -F INPUT

# 1. Allow established/related first (performance + correctness)
iptables -A INPUT -m conntrack \
  --ctstate ESTABLISHED,RELATED -j ACCEPT

# 2. Drop invalid state (prevents ACK scans, out-of-window packets)
iptables -A INPUT -m conntrack \
  --ctstate INVALID -j DROP

# 3. Block specific subnet BEFORE the general accept rule
iptables -A INPUT \
  -p tcp --dport 443 \
  -s 192.168.1.0/24 \
  -j DROP                            # Specific subnet blocked first

# 4. General accept for all other sources
iptables -A INPUT \
  -p tcp --dport 443 \
  -m conntrack --ctstate NEW \
  -j ACCEPT

# 5. Allow loopback (should be first in practice)
iptables -I INPUT 1 -i lo -j ACCEPT

# 6. Default deny (final catch-all)
iptables -A INPUT -j DROP

Additional missing rule: The ESTABLISHED,RELATED rule is absent. Without it, return traffic for outbound connections initiated by the server (e.g., apt updates, API calls) would be blocked, breaking all server-initiated connections.

Also missing: logging before the final DROP to give visibility into blocked traffic, and rate limiting on SSH to prevent brute-force.

MITRE ATT&CK: This misconfiguration is relevant to T1562.004 (Impair Defenses: Disable or Modify System Firewall) - not in the attack sense, but in the outcome: the intended block never fires, leaving an unintended access path.

---

Question 2

Your network has three segments: Internet (eth0), DMZ (eth1: 192.168.10.0/24), and Internal LAN (eth2: 10.0.0.0/24). An attacker compromises the web server at 192.168.10.50. Describe the three firewall rules that structurally prevent them from reaching the Internal LAN, even with full control of the DMZ host, and explain what each rule blocks.

Reveal Answer

Answer: Three rules that enforce DMZ isolation:

Rule 1 - Block DMZ to Internal (primary isolation)

iptables -A FORWARD \
  -i eth1 \                          # Traffic arriving from DMZ interface
  -o eth2 \                          # Attempting to leave toward Internal
  -j DROP
# Blocks: all traffic from any DMZ host (including compromised 192.168.10.50)
# to any Internal host. This is the primary containment rule.
# Defeats: lateral movement via SMB relay, pass-the-hash, port scanning internal hosts

Rule 2 - Block DMZ to Internal via state (belt-and-suspenders)

iptables -A FORWARD \
  -i eth1 -o eth2 \
  -m conntrack --ctstate NEW \
  -j LOG --log-prefix "DMZ_TO_INTERNAL: "
iptables -A FORWARD \
  -i eth1 -o eth2 \
  -m conntrack --ctstate NEW \
  -j DROP
# Even if Rule 1 were somehow bypassed, this explicitly drops NEW connections
# from DMZ to Internal and logs them - the log entry alerts on the attempt.

Rule 3 - Restrict DMZ egress to Internet (limit C2 channels)

iptables -A FORWARD \
  -i eth1 -o eth0 \                  # DMZ to Internet
  -p tcp -m multiport \
  --dports 80,443 \                  # Only HTTP/HTTPS outbound
  -m conntrack --ctstate NEW \
  -j ACCEPT
iptables -A FORWARD \
  -i eth1 -o eth0 \
  -j DROP                            # Block all other DMZ outbound
# Blocks: reverse shells on non-standard ports, DNS tunneling (port 53 blocked),
# direct outbound SMB/RDP. Forces attacker to use HTTP/HTTPS C2 only -
# which TLS inspection (Chapter 2.4) can detect.

What a compromised DMZ host CAN still do even with these rules:

• Communicate with the Internet on 80/443 (C2 over HTTPS)
• Attack other DMZ hosts (east-west within DMZ)
• Exploit any services the firewall explicitly allows from Internet to DMZ

What it cannot do: directly reach Internal hosts on any port, regardless of what credentials or tools the attacker has on the compromised DMZ host.

---

Question 3

Explain the architectural difference between a perimeter firewall and a Zero Trust enforcement model when an attacker has compromised valid domain credentials. Why does the perimeter model fail, and what specific Zero Trust controls mitigate the threat?

Reveal Answer

Answer:

Perimeter model failure: The perimeter model grants implicit trust based on network location. An attacker with valid credentials who is inside the network perimeter (via VPN, phishing, or compromised host) receives the same trust level as a legitimate employee. The firewall controls are:

• North-south: enforced (Internet to Internal is blocked)
• East-west: minimal or absent (Internal to Internal is largely unrestricted)

Valid credentials defeat authentication controls. Combined with flat east-west access, the attacker can:

• Query LDAP freely (domain enumeration)
• Authenticate to any host where the credential is valid
• Perform pass-the-hash, Kerberoasting, DCSync
• Access file shares, databases, administrative interfaces

The perimeter firewall has no visibility into what an authenticated user does inside the perimeter.

Zero Trust controls that specifically address valid credential compromise:

1. Device posture verification
   --------------------------
   Access requires: valid credential AND managed device with healthy posture
   (EDR running, disk encrypted, OS patched, no known IOCs)

   An attacker with stolen credentials but on an unmanaged device is denied.

   Implementation: Okta + CrowdStrike device trust, Intune compliance policy,
   Google BeyondCorp certificate-based device identity

# 2. Per-session, per-resource access tokens
# ------------------------------------------
# Access to each resource requires a fresh policy decision
# No persistent "you're in, go anywhere" sessions

# JWT with short expiry + audience claim
# Example: token valid only for api.internal.corp, expires in 15 minutes
{
  "sub": "jsmith@corp.com",
  "aud": "api.internal.corp",        # Specific resource
  "exp": 1700000900,                 # 15 minutes from now
  "device_trust": "managed",
  "iat": 1700000000
}
# Even if stolen, token works only for one resource, for 15 minutes

3. Behavioral anomaly detection
   ----------------------------
   Baseline: jsmith normally accesses 3 systems between 9-5 EST
   Alert: jsmith authenticates to 47 systems at 2AM from an unusual IP

   Implementation: Microsoft Defender for Identity, Splunk UBA, Vectra
   Even valid credentials trigger an alert when used anomalously

4. Least-privilege access + just-in-time elevation
   ------------------------------------------------
   jsmith's normal account has no access to the DC, finance systems, or MSSQL
   Admin access is granted for a specific ticket/window only, then revoked

   Implementation: CyberArk, Azure PIM (Privileged Identity Management)
   Kerberoasting is ineffective if service accounts have 240-char managed passwords (gMSA)

MITRE ATT&CK: T1078 (Valid Accounts) - Zero Trust's device posture + behavioral detection specifically targets this technique, which perimeter firewalls cannot address at all.

---

Question 4

You are auditing a firewall ruleset and find the following rule near the top of the INPUT chain: iptables -A INPUT -p tcp -s 10.0.0.0/8 --dport 22 -j ACCEPT. List three specific security problems with this rule and provide the corrected version.

Reveal Answer

Answer:

Problem 1 - Overly broad source range (entire RFC 1918 /8) 10.0.0.0/8 covers 16 million IP addresses - including every host in every 10.x.x.x subnet the organization has, plus any future subnet. If any host in that range is compromised, it has unrestricted SSH access to this server. The rule should specify only the specific management subnet (e.g., 10.0.100.0/24).

Problem 2 - No connection state restriction The rule allows ALL TCP packets to port 22, including ESTABLISHED and INVALID state packets. Without --ctstate NEW, this rule is redundant with the ESTABLISHED,RELATED rule and also accepts invalid state packets (which may indicate ACK scans or port knocking attacks). New connections should be explicitly scoped.

Problem 3 - No rate limiting (brute-force exposure) Any of the 16 million in-range IPs can make unlimited new SSH connections per second. Without rate limiting, a compromised internal host can brute-force SSH credentials at full network speed.

Corrected ruleset:

# Remove the original overly permissive rule
iptables -D INPUT -p tcp -s 10.0.0.0/8 --dport 22 -j ACCEPT

# Replace with hardened SSH rule

# Step 1: Log excessive connection attempts before dropping them
iptables -A INPUT \
  -p tcp --dport 22 \
  -m conntrack --ctstate NEW \
  -s 10.0.100.0/24 \                 # Only management subnet
  -m recent --set --name SSH_MGMT    # Track connection attempts

iptables -A INPUT \
  -p tcp --dport 22 \
  -m conntrack --ctstate NEW \
  -s 10.0.100.0/24 \
  -m recent --update --name SSH_MGMT \
  --seconds 60 --hitcount 5 \        # > 5 new connections in 60s = block
  -j LOG --log-prefix "SSH_BRUTE: "

iptables -A INPUT \
  -p tcp --dport 22 \
  -m conntrack --ctstate NEW \
  -s 10.0.100.0/24 \
  -m recent --update --name SSH_MGMT \
  --seconds 60 --hitcount 5 \
  -j DROP

# Step 2: Allow new SSH only from management subnet, under rate limit
iptables -A INPUT \
  -p tcp --dport 22 \
  -s 10.0.100.0/24 \                 # Specific management CIDR only
  -m conntrack --ctstate NEW \       # New connections only (ESTABLISHED handled separately)
  -j ACCEPT

# Block SSH from everything else
iptables -A INPUT -p tcp --dport 22 -j DROP

# Also ensure this host is reachable only from a jump/bastion host
# (Zero Trust: don't expose SSH to any internal subnet - use a jump host)

Additional hardening beyond the firewall rule:

• sshd_config: PermitRootLogin no, PasswordAuthentication no (keys only), AllowUsers whitelist
• Consider restricting SSH to a bastion host only - no direct SSH from workstations
• Use fail2ban for application-layer rate limiting as a complement to iptables

---

End of Chapter 4.1 Quiz