Linux Firewall Configuration with iptables and ufw
Objective. Students write and apply firewall rules using ufw and iptables to control inbound and outbound traffic based on a defined security policy.
This lesson, its worked examples and its practice questions has not yet been verified by an industry-certified professional or by a certification or approval body. It is a study draft and may contain errors. Do not use it as instructions for work on a job site or on live equipment. Always follow your instructor, your supervising professional, and current official references and regulations.
VoTechWorks program approval and accreditation are still in progress. Credentials are issued only by the certifying bodies named in each program, after their own exams.
Linux Firewall Configuration with iptables and ufw
Why Firewalls Matter in a Security Policy
A firewall enforces a written security policy by deciding which network traffic is allowed and which is blocked. Without a firewall, every port a service listens on is reachable by any host on the network. In cybersecurity, the principle of least privilege applies to network access just as it does to user accounts: open only the ports that are explicitly required, and deny everything else. NIST SP 800-41 Rev 1 provides federal guidance on firewall policy design and is a standard reference for this topic.
Linux provides two main tools for host-based firewall management: iptables, the traditional low-level interface to the kernel's netfilter subsystem, and ufw (Uncomplicated Firewall), a higher-level front end designed to make common tasks easier. Both tools write rules into the same kernel subsystem, but they differ in syntax and abstraction level.
---
Understanding iptables Chains and Tables
iptables organizes rules into tables (filter, nat, mangle, raw) and chains within each table. For basic host firewall work, the filter table is what you use. It contains three default chains:
- INPUT — traffic destined for the local machine
- OUTPUT — traffic originating from the local machine
- FORWARD — traffic passing through the machine to another host
Each chain has a default policy (ACCEPT or DROP). Best practice is to set default policies to DROP and then explicitly permit what is needed. Rules are evaluated top to bottom; the first matching rule wins.
iptables can operate in two modes of matching:
- Stateless matching — each packet is evaluated independently based on its header fields (source IP, destination port, protocol). This is simpler but cannot distinguish between legitimate reply traffic and unsolicited inbound packets.
- Stateful (conntrack) matching — the kernel tracks connection state (NEW, ESTABLISHED, RELATED, INVALID). A rule such as `-m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT` allows reply packets for connections that were initiated by the local machine, without opening broad port ranges. Stateful rules are almost always preferred for host firewalls because they are more precise and harder to abuse.
---
Using ufw for Policy-Based Rules
ufw translates plain-language commands into iptables rules. Before writing rules, enable ufw with `sudo ufw enable`. The default posture should be:
```
sudo ufw default deny incoming
sudo ufw default allow outgoing
```
To allow SSH only from a specific management subnet (for example, 10.0.1.0/24):
```
sudo ufw allow from 10.0.1.0/24 to any port 22 proto tcp
```
To allow HTTPS from anywhere:
```
sudo ufw allow 443/tcp
```
Check the full ruleset with:
```
sudo ufw status verbose
```
To delete a rule, use `sudo ufw delete` followed by the original rule syntax, or reference rules by number from `sudo ufw status numbered`.
---
Working Directly with iptables
Before using raw iptables alongside ufw, disable ufw with `sudo ufw disable`; running both simultaneously creates unpredictable rule ordering.
Flush existing rules first:
```
sudo iptables -F
sudo iptables -X
```
Set restrictive default policies:
```
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT
```
Allow loopback traffic (always required):
```
sudo iptables -A INPUT -i lo -j ACCEPT
```
Allow established/related sessions (stateful):
```
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
```
Allow SSH from management subnet only:
```
sudo iptables -A INPUT -p tcp -s 10.0.1.0/24 --dport 22 -j ACCEPT
```
Allow HTTPS from anywhere:
```
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
```
Save the ruleset so it survives a reboot:
```
sudo iptables-save > /etc/iptables/rules.v4
```
Restore it on boot with `iptables-restore < /etc/iptables/rules.v4`, or install the `iptables-persistent` package to automate this.
---
Auditing and Listing Rules
To review the current ruleset with line numbers and packet counts:
```
sudo iptables -L -v -n --line-numbers
```
The `-n` flag suppresses DNS lookups, which speeds up output and avoids misleading hostname resolution. When auditing a partner's configuration, read each rule against the written security policy and flag any rule that permits traffic not explicitly authorized.
---
Lab Safety and Best Practices
- Always work on virtual machines in an isolated lab network. Never practice firewall flushing or default-DROP policies on production systems or shared infrastructure.
- Keep a console connection open to each VM before applying restrictive rules. If you lock yourself out over SSH, the console is your recovery path.
- Document every change before applying it. If a rule causes an outage, you need a clear record to roll back.
- nmap is a legitimate audit tool in a lab environment. Never run nmap against systems you do not own or have explicit written permission to scan.
- When a lab exercise is complete, restore a known-good snapshot or flush rules to avoid leaving an insecure configuration running.
---
Verifying with nmap
From the second VM, run a targeted scan against the firewall host:
```
nmap -sV -p 22,23,80,443 <target-IP>
```
Expected output under a correct policy: port 22 open only when the scanning VM is in the management subnet, port 443 open, all others filtered or closed. Any deviation indicates a policy violation.
Key terms9
Materials: Two Linux VMs, ufw, iptables, iptables-save/restore, nmap, CompTIA Security+ Study Guide (Network Security domain), NIST SP 800-41 Rev 1 (Guidelines on Firewalls)
Check: nmap scan results from the second VM must match only the allowed ports; partner must identify and correct both violations; pass = nmap output matches policy exactly and both violations documented and remediated.
Practice check8
Answer each question, then check it. Nothing is recorded; this is your own practice.
