Firewall configuration with iptables and firewalld. If you manage a Linux server, you absolutely must be able to decide which network traffic is allowed in and out—because without a firewall, your server is wide open to anyone on the internet. For the LFCS exam, you need to know both the old-school command-line approach (iptables) and the modern, service-based approach (firewalld), because real-world Linux systems still use both.
Jump to a section
A simple way to picture Firewall Configuration with iptables and firewalld
How does an apartment building manage who gets in, who is turned away, and what residents are allowed to do after hours?
Imagine you are the night manager of a large apartment building. The building has a single front door (the network interface), and every resident has an apartment number (an IP address). Your job at the reception desk (the firewall) is to enforce the building's rules:
Which visitors are allowed to enter the building and which are turned away
What services they can use once inside (like the gym or the laundry room)
Whether a resident can access their own apartment from a remote location
The rules you follow are written in a policy book (the firewall rules). A resident might tell you, "Let my mother visit every Saturday between 2 PM and 4 PM." This is like a rule allowing traffic from a specific source IP during a specific time window.
But here's where it gets clever: you have two ways to manage this policy book.
First, there's a paper ledger (iptables) where you write each rule by hand with a pencil, one line at a time. It works, but it's tedious, and if you need to rearrange the rules you have to rewrite pages. Every time you change a rule, you immediately enforce it.
Second, there's a computer system (firewalld) where you define "zones" (like residential zone, commercial zone, maintenance zone) and assign rules to each zone. You can change rules in the computer system without touching the front desk, and then you "activate" the new rules during a quiet moment. This is safer and easier for large buildings.
Both systems do the same job—control who and what goes through the front door—but they differ in how you manage them.
A firewall is a piece of software that inspects network traffic and decides whether to allow it, block it, or modify it. Think of it as a security guard for your computer that checks every packet—a packet is a small chunk of data sent over a network—and compares it against a set of rules. In Linux, two main tools help you create and manage these rules: iptables and firewalld.
Both tools work with the same underlying system in the Linux kernel called netfilter. Netfilter is the engine that actually inspects packets. iptables and firewalld are just two different user interfaces—two different ways to tell netfilter what to do.
Let's start with iptables, which is the older tool and has been around since the early 2000s. ipt organises rules into chains. A chain is a sequence of rules that a packet passes through. The three built-in chains are:
INPUT: for packets coming into the system (e.g., someone tries to SSH into your server)
OUTPUT: for packets leaving the system (e.g., your server sends a web page to a browser)
FORWARD: for packets passing through the system (e.g., your server is acting as a router)
Each rule in a chain has a match condition (e.g., source IP address, destination port, protocol) and a target action (e.g., ACCEPT, DROP, REJECT). ACCEPT means let the packet through. DROP means silently ignore the packet. REJECT means send back an error message.
For example, to allow SSH (port 22) from a specific IP address using iptables, you would type: sudo iptables -A INPUT -p tcp --dport 22 -s 192.168.1.100 -j ACCEPT
This command appends (-A) a rule to the INPUT chain: match TCP packets destined for port 22 from source 192.168.1.100, and jump to the ACCEPT target.
The major downside of iptables is that changes take effect immediately, and the rules are not persistent by default—they disappear when you reboot unless you save them with a separate command like 'iptables-save'. Also, the syntax is quite complex and unforgiving; one wrong character can lock you out of your server.
Now enter firewalld, which was introduced to simplify things. firewalld is a service that runs in the background and provides a more structured way to manage rules. Instead of dealing with raw chains, firewalld uses zones. A zone is a set of rules that apply to a specific trust level or network interface. For example:
public zone: for untrusted networks (like the internet)
internal zone: for trusted networks (like your office LAN)
dmz zone: for servers that must be accessible from the internet but isolated from the internal network
You assign a network interface (like eth0 or wlan0) to a zone, and then you add services or ports to that zone. A service is a predefined set of ports and protocols—for example, 'ssh' opens port 22/tcp, 'http' opens port 80/tcp.
To allow SSH in the public zone using firewalld, you would type: sudo firewall-cmd --zone=public --add-service=ssh --permanent sudo firewall-cmd --reload
The '--permanent' flag means the change is saved in the configuration files, and it won't take effect until you reload. If you don't use '--permanent', the change is immediate but temporary—good for testing.
firewalld also supports rich rules, which are more complex conditions like limiting the rate of connections or logging dropped packets. Behind the scenes, firewalld still configures netfilter using iptables rules—it just does it in a more organised, less error-prone way.
Both tools are still common in the real world. Older Linux distributions like RHEL 6 use iptables by default. RHEL 7 and later use firewalld, but iptables commands still work because they are translated to the new nftables system (the successor to iptables). The LFCS exam tests both because you need to be ready for any system you encounter.
Check Current Zone Assignments
Run 'firewall-cmd --get-active-zones' to see which network interface belongs to which zone. This is your starting point—without knowing the zone, you cannot know which rules currently apply to your server's network.
List Allowed Services
Run 'firewall-cmd --zone=public --list-services' to see what services are currently allowed in the zone. This tells you whether HTTP, HTTPS, SSH, or other services are already open, so you do not duplicate rules.
Add a Service Temporarily
Execute 'firewall-cmd --zone=public --add-service=https' to allow HTTPS traffic immediately. Without '--permanent', this rule is runtime-only, which is safe for testing because if you make a mistake, a reload will clear it.
Add a Port Permanently
For custom ports not defined as a service, run 'firewall-cmd --zone=public --add-port=8080/tcp --permanent'. This saves the rule to disk, then run 'firewall-cmd --reload' to apply it. The reload does not drop existing connections, so users remain connected.
Remove a Service
To close a service, use 'firewall-cmd --zone=public --remove-service=ssh --permanent' followed by 'firewall-cmd --reload'. This is safer than changing the default zone policy because you only affect one service at a time.
Save iptables Rules for Persistence
If you are using iptables, run 'iptables-save > /etc/sysconfig/iptables' to write the current rules to the system configuration file. Without this step, a reboot clears all your changes.
Set Default Policy in iptables
Run 'iptables -P INPUT DROP' to change the default behaviour of the INPUT chain to drop packets that do not match any rule. Always ensure you have an ACCEPT rule for SSH before changing the policy, or you will lock yourself out.
Imagine you are the sole IT administrator for a small e-commerce company that runs its website on a Linux server in a data centre. The server runs RHEL 8 and uses firewalld. Your boss tells you that the website is getting a lot of traffic but also some suspicious connection attempts.
Here is what you actually do step by step:
First, you check which firewall zone is currently active on the server's public network interface. You run: sudo firewall-cmd --get-active-zones
The output might show that the interface 'eth0' is assigned to the 'public' zone. That is good: public zone is the most restrictive by default, which means no incoming traffic is allowed except what you explicitly enable.
Second, you list the services currently allowed in the public zone: sudo firewall-cmd --zone=public --list-services
You see http, https, and ssh. That makes sense for a web server—you need SSH to manage the server, and HTTP/HTTPS for the website.
Third, you notice that the log files show many repeated SSH login attempts from various IP addresses. To block them, you add a rich rule that drops packets from any IP that tries to connect more than five times per minute: sudo firewall-cmd --zone=public --add-rich-rule='rule family=ipv4 source address=0.0.0.0/0 service name=ssh limit value=5/m drop' --permanent sudo firewall-cmd --reload
This uses firewalld's rich rule syntax to set a rate limit on SSH connections.
Fourth, you need to temporarily allow a developer to test a new API endpoint on port 3000. You add the port as a temporary rule (not permanent) so it automatically disappears after a reload or reboot: sudo firewall-cmd --zone=public --add-port=3000/tcp
The developer can now access the API. After testing, you remove the port: sudo firewall-cmd --zone=public --remove-port=3000/tcp
Now suppose you migrate to an older RHEL 6 server that only uses iptables. You need to replicate the same rules. You would save the current iptables rules: sudo iptables-save > /root/iptables-backup.txt
Then add an SSH allowed rule: sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
And block brute-force attempts with a rate limit: sudo iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set sudo iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 5 -j DROP
This is more complex but exactly the same outcome.
Finally, you set default policies. The default policy for INPUT should be DROP, meaning unless a rule explicitly allows it, the packet is dropped: sudo iptables -P INPUT DROP
If you forgot to add the SSH rule before changing the default policy, you would be locked out of the server. That is why you always test with temporary rules first.
The LFCS exam tests your ability to configure both iptables and firewalld from the command line. You will not be asked to design a complex firewall architecture; instead, you need to show that you can add, remove, list, and save firewall rules.
Here are the specific concepts the exam loves to test:
The difference between permanent and runtime rules in firewalld. A common trap: a candidate adds a rule without '--permanent', reloads the firewall, and the rule disappears. The exam expects you to know that non-permanent rules are lost after reload or reboot.
The '--reload' vs '--complete-reload' distinction. '--reload' applies permanent rules without disrupting existing connections. '--complete-reload' drops all runtime changes and existing connections. The exam might ask which command to use if you want to keep active sessions alive.
Default zones and how to assign an interface to a zone. You must remember that the default zone is 'public' unless you change it. Commands: 'firewall-cmd --set-default-zone=dmz', 'firewall-cmd --zone=internal --add-interface=eth1 --permanent'.
iptables chain traversal order: packets go through PREROUTING, then INPUT (or FORWARD or OUTPUT), then POSTROUTING. The exam sometimes asks which chain is used for packets destined for the local system (INPUT) versus packets that are routed through the system (FORWARD).
Policy rules vs regular rules. In iptables, the default policy (-P) applies when no rule matches. The exam might ask: 'What happens to a packet that does not match any rule in the INPUT chain?' The answer: the default policy is applied (either ACCEPT or DROP).
Saving and restoring rules. For iptables: 'iptables-save' and 'iptables-restore'. For firewalld: 'firewall-cmd --runtime-to-permanent' saves runtime rules permanently. The exam expects you to know that iptables rules are not persistent by default.
Common port numbers: ssh (22), http (80), https (443), DNS (53). The exam often asks you to 'allow HTTPS traffic' without telling you the port number.
The '--add-rich-rule' syntax. The exam may present a scenario where you need to allow traffic from only a specific IP address to a specific port. Rich rules are the way to do that in firewalld.
Traps to watch out for:
The exam might use 'iptables -A INPUT -j DROP' as the last rule, then ask whether a packet that matches an earlier rule is dropped. The answer is no—the first matching rule wins.
The exam might state 'the server currently uses iptables' and then ask about firewalld commands. The correct answer is: you must not confuse the two tools—iptables commands only work with iptables, and firewalld commands only work with firewalld (though firewalld can call iptables behind the scenes, the commands are different).
The exam sometimes tests that the '--permanent' flag must be used with '--add-service' or '--add-port' only when you want the change to survive a reload. The default behaviour (no flag) is immediate but temporary.
firewalld and iptables both use the Linux kernel's netfilter framework; firewalld is the newer, more user-friendly interface.
In firewalld, rules added without the '--permanent' flag are lost after a reload or reboot.
Each network interface in firewalld is assigned to exactly one zone, which determines the default set of allowed services and ports.
The default policy in iptables (ACCEPT or DROP) applies to any packet that does not match an explicit rule.
The DROP target silently discards packets, while REJECT sends back a 'connection refused' error.
Always test firewall changes with temporary rules first to avoid locking yourself out of the server.
The iptables command affects only the running configuration; use 'iptables-save' to make changes permanent across reboots.
Rich rules in firewalld allow complex conditions like source IP restrictions and rate limiting.
These come up on the exam all the time. Here's how to tell them apart.
iptables
Commands affect rules immediately without a reload step.
Rules are not persistent unless explicitly saved using 'iptables-save'.
Uses raw chains (INPUT, OUTPUT, FORWARD) where order of rules matters strictly.
firewalld
Changes are runtime-only unless '--permanent' flag is used; requires reload to apply permanent changes.
Permanent rules are automatically saved in XML configuration files.
Uses zones and services, abstracting away chain management; rules are managed per zone.
DROP target
Silently discards the packet, making it appear the host does not exist.
Does not send any response to the sender; connection will time out.
Useful for stealth (hiding that the port is filtered).
REJECT target
Sends back an ICMP 'port unreachable' or TCP RST packet, informing the sender the port is closed.
Sender immediately knows the connection was refused, so no timeout wait.
Useful for polite refusal or to clearly indicate a policy.
Runtime rule (firewalld)
Added without '--permanent' flag.
Takes effect immediately.
Lost after reload or reboot.
Permanent rule (firewalld)
Added with '--permanent' flag.
Does not take effect until you reload the firewall.
Survives reloads and reboots.
INPUT chain (iptables)
Processes packets destined for the local system (the server itself).
Typically used for allowing inbound services like SSH, HTTP.
If default policy is DROP, you must explicitly allow incoming connections.
FORWARD chain (iptables)
Processes packets that are routed through the system (not destined for the local system).
Used when the server acts as a router or NAT gateway.
If default policy is DROP, routing functionality will break unless you allow forwarding.
Mistake
I can use iptables commands on a system running firewalld and they will conflict or break everything.
Correct
You can normally use iptables commands on a system running firewalld because firewalld uses iptables under the hood. However, changes made directly with iptables are not tracked by firewalld and may be overwritten when firewalld reloads. The best practice is to use only firewalld commands if firewalld is active.
Beginners often think the two tools are completely incompatible, but they actually share the same kernel subsystem. The confusion arises because the tools have different interfaces, making it appear they are separate systems.
Mistake
Adding a service with firewalld opens the port for everyone automatically.
Correct
Adding a service opens the port only on the zone it is added to. If you add 'ssh' to the 'public' zone, it is only open on interfaces assigned to 'public'. Other zones remain unaffected.
The term 'zone' is new to many beginners, so they assume all services apply globally. The mental model of a global firewall is easier to grasp but incorrect.
Mistake
Once I add a firewall rule, it stays forever until I remove it.
Correct
In firewalld, rules added without the '--permanent' flag are temporary and are lost after a reload or reboot. In iptables, rules are not saved to disk unless you explicitly run 'iptables-save'. Many beginners reboot their server for testing and are shocked that their rules are gone.
The idea of a 'temporary' firewall rule feels counterintuitive because in everyday life, rules are written down and persist. The concept of runtime vs persistent configuration is unfamiliar.
Mistake
The DROP and REJECT targets in iptables do the same thing.
Correct
DROP silently discards the packet, making the connection time out. REJECT sends back an error packet (like 'connection refused'), informing the sender that the destination is unreachable. The exam tests the difference because each is appropriate in different scenarios (DROP for stealth, REJECT for polite refusal).
Both targets block traffic, so beginners assume they are synonyms. The subtle difference in behaviour is not obvious without reading documentation.
Mistake
I only need to configure the INPUT chain and I am fully protected.
Correct
You also need to consider the OUTPUT chain (outgoing traffic) and the FORWARD chain (routed traffic). If your server is a router, forward rules matter. Even for a simple server, you might want to limit which services can initiate outgoing connections (e.g., prevent malware from phoning home).
Most attacks come from outside, so beginners fixate on incoming traffic. The idea that outgoing traffic could be dangerous is less intuitive.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Both tools manage the same kernel firewall (netfilter), but they have different interfaces. iptables is the older, command-line tool where you manipulate raw chains. firewalld is a newer service that uses zones and services to simplify configuration, and changes can be made permanent or temporary.
You must run 'iptables-save' and redirect the output to a file like '/etc/sysconfig/iptables' (the exact path depends on the distribution). Then configure the system to load that file on boot using 'iptables-restore' from an init script or systemd unit.
You likely did not use the '--permanent' flag when adding the rules, or you forgot to run 'firewall-cmd --runtime-to-permanent' to save runtime changes. Without that, rules are only in memory and lost on reboot.
Technically yes, but it is strongly discouraged. firewalld uses iptables under the hood, so direct iptables changes can conflict and be overwritten. Always use only one tool to manage the firewall.
The FORWARD chain handles packets that are not destined for the local system but are being routed through it. It is important when your Linux server is acting as a router or a NAT gateway.
Use a rich rule: 'firewall-cmd --zone=public --add-rich-rule='rule family=ipv4 source address=192.168.1.100 drop' --permanent', then reload. This adds a rule that drops all traffic from that specific source IP.
The default zone is called 'public'. When you first install firewalld, all network interfaces are assigned to the public zone unless you change it. You can check with 'firewall-cmd --get-default-zone'.
You've finished Firewall Configuration with iptables and firewalld. Continue through the LFCS study guide to build a complete picture of the exam.
Done with this chapter?