How to Implement Firewall Rules with iptables: A Step-by-Step Linux Security Guide
If you’re running any sort of server – a home Linux box, a Kali Linux pentesting lab, or a production computer – an unprotected network interface is an open door. Every service you run, whether it’s SSH or a web server, is a possible attack vector for internet scanners probing for open ports.
iptables is the traditional, battle-tested firewall program that is incorporated into the Netfilter framework of the Linux kernel. It enables you decide, rule by rule, exactly what traffic can enter, leave, or be relayed throughout your system. In this post we will lead you through a full hands-on iptables setup: from inspecting your current rules, to locking down your computer using a default-deny policy, only allowing the services you actually need (SSH and HTTP), and validating that the rules function.
What is iptables and why should I care?
iptables is the command-line firewall tool for Linux that filters network traffic based on source/destination IP address, port number, and protocol. It's like a security gate placed between your network interface and your operating system. Every packet that comes and goes has to pass via the rules you set up.
Firewalls, such as iptables, are important for:
- Preventing unauthorized access to your machine by unknown or malicious IPs
- You can allow only certain services you trust (SSH for remote administration, or HTTP for a web server, for example)
- Preventing network threats such as port scans, unsolicited ping sweeps and illegal remote logins
- Managing Traffic Flow Between Network Interfaces on Multi-homed or Gateway Systems.
Objective of This Guide
By the end of this guide, you'll know how to:
- Inspect existing firewall rules on a Linux system
- Reset iptables to a clean slate
- Set a default-deny (DROP) policy and explicitly allow only trusted traffic
- Test that your rules actually work against real services (Apache, SSH, ping)
- Make your rules persistent across reboots
- Safely reset everything back to an open state when you're done testing
Step 1: View Your Current Firewall Rules
- Before changing anything, always check what's already configured. Run:
sudo iptables -L
On a fresh system, you'll typically see three empty chains — INPUT, FORWARD, and OUTPUT — all set to an
ACCEPT policy, meaning nothing is currently being blocked:
These three chains map to the three points where a packet can be filtered:
Step 2: Flush Existing Rules
- Start with a clean slate so old rules don't conflict with the ones you're about to add:
sudo iptables -F
- This clears all existing rules but does not change the default chain policies — you'll set those next.
Step 3: Set a Default-Deny Policy (The Core of a Real Firewall)
This is the most important security decision in the whole setup. Instead of trying to blacklist every bad actor individually (an impossible task), you deny everything by default and then explicitly allow only what you trust.
Run these commands one at a time:
Then allow the specific traffic you need:
Here's what each rule does:
- INPUT → DROP: block all incoming traffic by default
- FORWARD → DROP: block all traffic being routed through this machine
-i lo(loopback): allow internal traffic on127.0.0.1— critical, since many local services depend on this- Port 22 (SSH): allow inbound remote administration access
Step 4: Verify the Rules Were Applied
- Check that everything took effect, including packet/byte counters and rule order:
sudo iptables -L -v --line-numbers
Sample output:
The
-v flag shows traffic counters (useful for confirming which rules are actually being hit), and --line-numbers helps you reference specific rules if you need to delete or reorder them later.Step 5: Test the HTTP Rule
- To confirm port 80 is genuinely open, spin up a real web server.
- Install and start Apache:
sudo apt update
sudo apt install apache2 -y
sudo systemctl start apache2
sudo systemctl enable apache2
- Confirm it's running:
sudo systemctl status apache2
Test from another device on the same network by opening a browser and navigating to your machine's IP address, e.g.:
http://192.168.40.10
If your firewall rule is correctly configured, you'll see the Apache default index page load successfully — proof that port 80 traffic is passing through your DROP-by-default firewall exactly as intended.
Step 6: Test the SSH Rule
- Install and start the SSH server:
sudo apt update
sudo apt install openssh-server -y
sudo systemctl start ssh
sudo systemctl enable ssh
- Verify it's active:
sudo systemctl status ssh
- Connect remotely from another machine (Windows, macOS, or Linux):
ssh username@<your_machine_ip>
A successful login confirms port 22 is correctly allowed through the firewall while everything else stays locked down.
Step 7: Confirm Blocked Services Are Actually Blocked
A firewall is only as good as what it refuses. Test this by trying to ping the machine from another device:
ping 192.168.10.40
Since ICMP (ping) traffic was never explicitly allowed, you should see 100% packet loss / request timed out — solid confirmation that the default DROP policy is working as expected.
If you want to allow ping temporarily (useful for network troubleshooting), add:
sudo iptables -A INPUT -p icmp -j ACCEPT
Step 8: Make Your Rules Persistent
By default, iptables rules disappear on reboot. To keep them permanently:
sudo apt install iptables-persistent
sudo netfilter-persistent save
This saves your current rule set so it's automatically reloaded every time the system boots — turning your one-off configuration into a durable part of your system's security posture.
Step 9: Reset iptables to Allow Everything (Cleanup)
When you're done testing or need to start over, restore an open configuration:
sudo iptables -F
sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT
Use this with caution on any machine exposed to the internet — an open firewall means no protection at all.
Best Practices for Real-World iptables Firewalls
sudo iptables -A INPUT -j LOG --log-prefix "IPTABLES-DROPPED: "iptables -L -v --line-numbers and remove ones you no longer needFrequently Asked Questions
Q1) Is iptables still relevant, or should I use nftables instead?
However , many modern distributions have switched to nftables as the underlying packet-filtering framework . iptables commands are still widely supported ( often thru a compatibility layer ) and are the standard for learning firewall fundamentals .
Q2) What's the difference between the INPUT, OUTPUT, and FORWARD chains?
INPUT filters traffic destined for your machine, OUTPUT filters traffic your machine sends out, and FORWARD filters traffic passing through your machine to another destination (relevant for routers and gateways).
Q3) Why allow loopback (lo) traffic?
Many local services and applications communicate with themselves over
127.0.0.1. Blocking loopback traffic can break basic system functionality, so it's almost always allowed explicitly.Q4) Can iptables rules survive a reboot without iptables-persistent?
No — without saving your rules (via
iptables-persistent/netfilter-persistent or a similar method), all custom rules reset to default on reboot.Conclusion
One of the most useful and practical core skills in network security is to implement firewall rules using iptables . Flushing defaults , having a strict default deny policy , and explicitly allowing only trusted services such as ssh , http etc. drastically reduces your system attack surface - while still allowing the access you actually need . Test all the rules you write. Save your configuration so it persists thru reboots. Always double check remote access before locking things down.
Whether you are going through a cybersecurity lab exercise or hardening a production server, mastering iptables gives you direct, granular control over exactly what talks to your machine — and that is the essence of good network security.
