Firewalls and Access Control¶

Overview¶

Firewalls are the first line of defense between your infrastructure and the internet. They enforce access control — deciding which packets may enter, leave, or traverse a network boundary based on IP addresses, ports, protocols, and connection state. Every production environment uses firewalls at multiple layers: host-based rules on Linux servers, perimeter appliances, and cloud-native controls like AWS Security Groups and Network ACLs.

Misconfigured firewalls cause more production outages than malicious attacks. A rule that blocks health-check traffic takes down a load-balanced fleet; an overly permissive rule exposes databases to the public internet. This tutorial teaches you how firewalls actually work, how to manage them on Linux, and how to design least-privilege policies that balance security with operability.

This is Tutorial 11 in Module 4: Application Layer of the REBASH Academy Networking series. It follows our documentation standards with theory, hands-on labs, and interview preparation.

Prerequisites¶

• Complete HTTP, HTTPS, and the Application Layer or understand ports 80/443 and TCP connection basics
• Familiarity with IP addresses, CIDR notation, and TCP/UDP from IP Addressing and Subnetting
• A Linux VM (Ubuntu 22.04+ recommended) or cloud instance with sudo access
• Optional: AWS/GCP/Azure account for security group exercises (free tier is sufficient)

Learning Objectives¶

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

• Explain the difference between stateful and stateless packet filtering
• Describe how iptables chains and tables work, and why nftables is replacing them
• Configure host firewalls with UFW on Ubuntu/Debian systems
• Differentiate cloud Security Groups from Network ACLs and apply least privilege
• Design firewall rules that allow required traffic without opening unnecessary ports
• Troubleshoot connectivity failures caused by firewall misconfiguration

Architecture Diagram¶

Firewalls operate at multiple enforcement points. Defense in depth means layering controls — never relying on a single rule set.

flowchart TB
    subgraph Internet
        ATT[External Clients]
    end

    subgraph Perimeter
        NACL["Network ACL<br/>stateless · subnet boundary"]
        SG["Security Group<br/>stateful · instance ENI"]
    end

    subgraph Host
        UFW["UFW / nftables<br/>host firewall"]
        APP["Application<br/>nginx · postgres"]
    end

    ATT --> NACL
    NACL --> SG
    SG --> UFW
    UFW --> APP
    APP -->|response| UFW
    UFW --> SG
    SG --> NACL
    NACL --> ATT```

## Theory

### What a Firewall Does

A **firewall** inspects network packets and applies a policy: **allow**, **deny**, or **drop** (silently discard). Policies are expressed as **rules** matched in order until a decision is reached. Rules typically filter on:

- **Source/destination IP** — which hosts or subnets
- **Protocol** — TCP, UDP, ICMP
- **Port** — for TCP/UDP (e.g., 22, 443)
- **Connection state** — new, established, related (stateful firewalls only)
- **Interface** — which NIC the packet arrives on

Firewalls can be **network-based** (between subnets, at the edge) or **host-based** (on each server). In cloud environments, you typically have both.

### Stateful vs Stateless Filtering

**Stateless** firewalls evaluate each packet independently. They do not remember prior packets. A rule allowing inbound TCP port 443 does not automatically allow the return traffic — you must explicitly permit outbound ephemeral ports or bidirectional rules. Network ACLs in AWS are stateless by default.

**Stateful** firewalls track **connections** (flows). When a client initiates a TCP SYN to your web server on port 443, the firewall creates a session entry. Return packets matching that session are automatically permitted without a separate inbound rule. Linux `iptables`/`nftables` with `conntrack`, UFW, and AWS Security Groups are stateful.

| Aspect | Stateless | Stateful |
|--------|-----------|----------|
| Memory of sessions | No | Yes (conntrack table) |
| Return traffic | Must be explicitly allowed | Automatically allowed for established sessions |
| Performance | Lower overhead | Slightly higher (session tracking) |
| Complexity | More rules for bidirectional flows | Simpler for client-initiated connections |
| Example | AWS NACL, early packet filters | UFW, Security Groups, modern iptables |

**Production implication:** When debugging "connection timeout" vs "connection refused," stateful firewalls often drop packets silently if return path rules are missing — the symptom looks like a black hole, not an explicit rejection.

### iptables: Chains, Tables, and Rules

**iptables** is the legacy userspace tool for configuring the Linux kernel's **netfilter** framework. Packets traverse **tables** containing **chains** of rules:

| Table | Purpose |
|-------|---------|
| `filter` | Allow/deny forwarding and local delivery (most common) |
| `nat` | Network Address Translation (SNAT/DNAT) |
| `mangle` | Packet marking, TTL modification |
| `raw` | Connection tracking exemptions |

Common **chains** in the `filter` table:

- **INPUT** — packets destined for this host
- **OUTPUT** — packets originating from this host
- **FORWARD** — packets routed through this host (routers, Docker, K8s nodes)

Rule matching is **first-match-wins**. The default policy on a chain applies if no rule matches. A typical secure baseline sets INPUT default to DROP and explicitly allows SSH, established connections, and loopback.

Example rule semantics:

```bash
# Allow established and related connections
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow SSH from admin subnet only
iptables -A INPUT -p tcp -s 10.0.1.0/24 --dport 22 -j ACCEPT

nftables Overview¶

nftables consolidates IPv4, IPv6, ARP, and bridge filtering into one framework with a cleaner syntax:

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 ip saddr 10.0.1.0/24 accept
    tcp dport { 80, 443 } accept
  }
}

Key advantages over legacy iptables:

• Single rule set for IPv4 and IPv6 (inet family)
• Atomic rule replacement (no flush-and-rebuild race)
• Better performance on large rule sets
• Native sets and maps for IP/port grouping

On systems running UFW, nftables rules are managed indirectly — UFW generates nftables/iptables rules under the hood.

UFW: Uncomplicated Firewall¶

UFW (Uncomplicated Firewall) is Ubuntu's user-friendly front end to iptables/nftables. It is ideal for single-server hardening and learning firewall concepts without memorizing netfilter syntax.

Default UFW behavior:

• Denies all incoming, allows all outgoing
• Rules are numbered and processed in order
• Supports application profiles in /etc/ufw/applications.d/

Common operations:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

UFW is not a replacement for cloud Security Groups in AWS — use both. Security Groups protect the instance ENI; UFW protects against lateral movement if an attacker reaches the host.

Cloud Security Groups vs Network ACLs¶

In AWS (similar concepts exist in GCP/Azure):

Security Groups (SG) — stateful, attached to ENIs (instances, load balancers). Rules reference other SGs by ID (e.g., "allow PostgreSQL from app-tier SG"). Default: deny all inbound, allow all outbound. Changes apply immediately.

Network ACLs (NACL) — stateless, attached to subnets. Ordered rule numbers (100, 200, …); first match wins. Explicit allow/deny for inbound and outbound. Default NACL allows all; custom NACLs often deny by default.

Defense in depth example: Public subnet NACL allows 80/443 from 0.0.0.0/0. Web-tier SG allows 80/443 from ALB SG only. App-tier SG allows 8080 from web-tier SG only. Database SG allows 5432 from app-tier SG only. No rule anywhere allows 5432 from the internet.

Least Privilege in Network Design¶

Least privilege means granting the minimum network access required for a function — no wider CIDRs, no unnecessary ports, no "allow all" staging rules left in production.

Principles:

1. Default deny — start with no inbound access; add rules with justification
2. Segment by tier — web, app, data layers in separate subnets/SGs
3. Use SG references over CIDR — source-group: app-sg beats 10.0.2.0/24 when instances scale
4. Restrict outbound — egress filtering prevents data exfiltration (often overlooked)
5. Document every rule — tag SG rules with ticket IDs; review quarterly
6. Separate admin access — SSH/bastion from known IPs or VPN, never 0.0.0.0/0

Hands-on Lab¶

Complete these exercises on an Ubuntu VM. Use a disposable lab instance — incorrect rules can lock you out of SSH.

Step 1 – Inspect current firewall status¶

Command:

sudo ufw status verbose
sudo nft list ruleset 2>/dev/null | head -40

Explanation: UFW shows enabled/disabled state and active rules. nft list ruleset reveals the underlying nftables rules UFW generated (may be empty if UFW is inactive).

Expected output:

Status: inactive

Or, if enabled:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere

Step 2 – Enable UFW with SSH protection first¶

Command:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 443/tcp comment 'HTTPS web traffic'
sudo ufw enable

Explanation: Always allow SSH before ufw enable on remote systems. The comment flag documents rule purpose in ufw status.

Expected output:

Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

Step 3 – Verify connectivity and list numbered rules¶

Command:

sudo ufw status numbered
curl -sI https://example.com | head -3

Explanation: Numbered rules are required for deletion (ufw delete 3). Outbound HTTPS should succeed under default allow-outgoing policy.

Expected output:

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    Anywhere
[ 2] 443/tcp                    ALLOW IN    Anywhere

Step 4 – Add a restrictive source IP rule¶

Command:

# Replace with your admin IP or lab subnet
sudo ufw allow from 10.0.1.0/24 to any port 22 proto tcp comment 'Admin SSH subnet'
sudo ufw status verbose

Explanation: Source-restricted rules implement least privilege for administrative access. In production, combine with bastion hosts or SSM Session Manager to avoid exposing SSH broadly.

Step 5 – Inspect raw iptables/nftables counters¶

Command:

sudo iptables -L INPUT -v -n --line-numbers 2>/dev/null | head -20
# Or on nftables-native systems:
sudo nft list chain inet filter input 2>/dev/null

Explanation: Packet and byte counters show which rules are actually hit — essential when debugging "rule exists but traffic still blocked."

Expected output:

Chain INPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1      142  8520 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
...

Step 6 – Simulate a blocked port¶

Command:

# Start a test listener (in one terminal)
python3 -m http.server 8888 &

# Deny inbound 8888
sudo ufw deny 8888/tcp
curl -v --connect-timeout 3 http://127.0.0.1:8888/

Explanation: UFW inserts deny rules. From localhost, traffic may bypass INPUT chain depending on configuration — test from a remote host for accurate results.

Cleanup:

sudo ufw delete deny 8888/tcp
kill %1 2>/dev/null

Step 7 – Document a Security Group policy (AWS CLI or console)¶

If you have AWS access:

aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0 \
  --query 'SecurityGroups[0].IpPermissions' --output table

Explanation: Practice reading SG rules: protocol, port range, source SG vs CIDR. Map each rule to a tier in your architecture diagram.

Commands & Code¶

Infrastructure-as-Code: Security Group example (Terraform)¶

resource "aws_security_group" "web" {
  name        = "web-tier"
  description = "Allow HTTP/HTTPS from ALB only"
  vpc_id      = aws_vpc.main.id

  ingress {
    description     = "HTTP from ALB"
    from_port       = 80
    to_port         = 80
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
  }

  ingress {
    description     = "HTTPS from ALB"
    from_port       = 443
    to_port         = 443
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name    = "web-tier-sg"
    Tier    = "web"
    Managed = "terraform"
  }
}

Common Mistakes¶

Best Practices¶

Troubleshooting¶

Summary¶

• Stateful firewalls track connections and automatically permit return traffic; stateless firewalls evaluate each packet independently
• iptables/nftables implement Linux netfilter; UFW provides a manageable front end for host hardening
• Security Groups are stateful, instance-scoped; NACLs are stateless, subnet-scoped — both are required for complete cloud network policy
• Least privilege means default deny, tier segmentation, SG references over broad CIDRs, and regular rule audits
• Always allow administrative access before enabling host firewalls on remote systems
• Use packet counters, flow logs, and layered testing to distinguish firewall drops from application errors

Interview Questions¶

1. What is the difference between a stateful and stateless firewall?
2. Explain the purpose of iptables chains INPUT, OUTPUT, and FORWARD.
3. Why is nftables replacing iptables, and what problems does it solve?
4. How do AWS Security Groups differ from Network ACLs?
5. What is least privilege in network access control, and how do you implement it in a three-tier web application?
6. A user reports SSH works but HTTPS times out. Walk through your firewall troubleshooting steps.
7. Can you add a deny rule to an AWS Security Group? Why or why not?
8. What happens to return traffic in a stateful firewall when the initial outbound connection is allowed?
9. Why should UFW and Security Groups both be configured rather than choosing one?
10. How would you audit a fleet of servers for overly permissive firewall rules?

Related Tutorials¶

• Networking – Category Overview
• HTTP, HTTPS, and the Application Layer (previous in Module 4)
• Load Balancing Fundamentals (next in Module 4)
• Linux Networking Essentials
• Network Security Hardening

References¶

• Linux netfilter/iptables documentation
• nftables wiki
• Ubuntu UFW community documentation
• AWS Security Groups
• AWS Network ACLs
• NIST SP 800-41 — Guidelines on Firewalls and Firewall Policy