How do you stop unauthorised people and malicious software from breaking into your Linux server over the internet? This problem is what the LPIC-2 exam objective 202.4, System Security, addresses by teaching you how to configure a firewall, which acts as a gatekeeper between your server and the internet, using tools like `iptables` and its modern replacement `nftables`.
Jump to a section
A simple way to picture System Security, Firewalls, and iptables/nftables
Securing a server against unwanted network traffic first requires knowing who is trying to get in, and that leads to the need for a system that can make split-second decisions based on rules you set. Imagine your Linux server is a private concert venue you are hosting for a band and their fans. The venue has a single front door (the network interface). When someone arrives, they knock with a request, like "I am here to see the band" (a data packet arriving). You, as the organiser, have hired a bouncer (the firewall application, like iptables or nftables) to manage the door. You give the bouncer a strict list of rules printed on a clipboard (the firewall rule set). The first rule might say, "If anyone says they are selling something, do not let them in" (block advertising or malicious packets). Another rule might say, "If anyone claims to be a VIP member with a backstage pass, let them through to a specific area" (allow secure shell (SSH) connections from a specific IP address).
The bouncer does not think about the rules; he just checks each person against the list in order. If a person matches a rule that says "Let them in," they enter. If they match a rule that says "Turn them away," they are stopped. If no rule matches, the final rule on the clipboard says "Turn everyone else away" (the default deny policy). This process of checking data packets against a sequence of rules until a match is found is the core of how iptables and nftables work. The bouncer keeps a log of suspicious characters (system logs) so you can review who tried to cause trouble later.
System security on a Linux server is a broad topic, but for the LPIC-2 exam, it focuses heavily on the firewall. A firewall is a piece of software or hardware that controls what network traffic is allowed to enter or leave a computer or network. You can think of it as a filter that examines every piece of data trying to cross a network boundary. The older tool for this job is iptables, while the newer, more efficient tool is nftables. The LPIC-2 exam covers both, but you need to understand that nftables is the successor designed to replace iptables.
When data travels across a network, it is broken into small chunks called packets. Each packet has a source IP address (where it came from), a destination IP address (where it is going), and a port number (which service it is trying to access, like port 80 for web traffic or port 22 for secure shell (SSH)). The firewall examines these packet headers and then decides what to do with the packet based on your rules. This decision is called a target. The most common targets are ACCEPT (let the packet through), DROP (ignore the packet as if it never arrived), and REJECT (send a message back saying the connection was refused). The difference between DROP and REJECT is important for security: DROP makes it look like your server does not even exist, while REJECT tells the sender there is a server there, which can be useful but gives away information.
Now, let us look at how iptables organises its rules. It uses a system of tables and chains. A table is a collection of related rules. The main tables are the filter table (for basic firewalling, deciding which packets to allow or block), the nat table (for Network Address Translation, which changes IP addresses of packets, often used for routing traffic), and the mangle table (for special modifications to packet headers). Inside each table, there are chains. A chain is a sequence of rules that are checked in order. The default chains in the filter table are INPUT (for packets destined for the server itself), OUTPUT (for packets leaving the server), and FORWARD (for packets passing through the server to another network, like a router). For LPIC-2, you must understand the basic anatomy of an iptables command: iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT. This command appends (-A) a rule to the INPUT chain that says: if the protocol (-p) is TCP, the destination port (--dport) is 22 (SSH), and the source IP address (-s) is from the network 192.168.1.0/24 (a range of addresses), then jump (-j) to the target ACCEPT.
The newer tool nftables simplifies this. Instead of having separate tools for tables and chains, nftables uses a single framework. You still have tables and chains, but the command structure is different and more consistent. For example, a simple rule in nftables might look like this: nft add rule inet filter input tcp dport 22 accept. Here, inet is the address family (IPv4 and IPv6 combined), filter is the table name, input is the chain name, and tcp dport 22 accept is the rule. nftables also uses a single tool (nft) instead of the multiple tools iptables, ip6tables, arptables, and ebtables that iptables required. This makes nftables easier to script and manage. A key difference for the exam is that nftables rules are transactional: you can define a whole set of rules and apply them atomically (all at once or not at all), whereas iptables applies each rule one by one, which can leave your firewall in an inconsistent state if a rule fails.
Finally, both tools rely on rules being checked in order. This is called a chain. When a packet arrives, the firewall checks it against the first rule in the chain. If the rule matches criteria (like the port and source), the firewall executes the target (like ACCEPT or DROP) and stops checking subsequent rules. If the rule does not match, the firewall moves to the next rule. This process continues until either a rule matches, or the firewall reaches the end of the chain. If no rule matches, the default policy for that chain is applied. Typically, the default policy is set to DROP, meaning anything not explicitly allowed is blocked. This is the most secure setup, known as a whitelist approach. For LPIC-2, you need to know how to add, delete, insert, and list rules in both iptables and nftables, and how to make these rules persistent (save them so they survive a reboot).
Assess the Current Firewall State
Before making any changes, you must understand what rules are already active. On a system using `iptables`, you would run `sudo iptables -L -n -v` to list the rules in the filter table. On a system using `nftables`, you would run `sudo nft list ruleset`. This step identifies the default policy on each chain and any existing rules. It prevents you from accidentally duplicating or conflicting with existing configurations.
Set a Secure Default Policy
You set a secure default policy on the INPUT chain to DROP. This means any packet that does not match an explicit rule will be discarded. The command for `iptables` is `sudo iptables -P INPUT DROP`. For `nftables`, you would define the policy within the chain definition, for example, when creating the chain: `nft add chain inet filter input { type filter hook input priority 0; policy drop; }`. This step is fundamental to the principle of least privilege.
Allow Essential Loopback and State Traffic
You must allow traffic from your own machine (loopback interface, `lo`) because many internal services (like a database communicating with a web server) use it. You also need to allow established connection packets so that replies to outgoing requests (like a server fetching updates) are accepted. In `iptables`, you add rules: `sudo iptables -A INPUT -i lo -j ACCEPT` and `sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT`. These are safety nets that prevent you from breaking your own system.
Add Application-Specific Allow Rules
Now, you add rules for the specific services you intend to run. For a web server, you allow TCP traffic on ports 80 (HTTP) and 443 (HTTPS). For example: `sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT` and `sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT`. If you need SSH access from a specific location, you add a more restrictive rule, like `sudo iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT`. Each rule should be as specific as possible to minimise the attack surface.
Persist and Test the Rules
Once the rules are applied, you must save them so they load again after a reboot. For `iptables` on a Debian system, you run `sudo iptables-save > /etc/iptables/rules.v4`. For `nftables`, you run `sudo nft list ruleset > /etc/nftables.conf`. Then, test the configuration by attempting to connect to the allowed services from an authorised and an unauthorised location. Also, test that essential local services still work. This ensures the firewall is both secure and functional.
Consider a small business with a single Linux web server hosting an e-commerce site. The server is connected to the internet and must be accessible to customers. The IT professional managing this server is responsible for ensuring that only legitimate web traffic (port 80 for HTTP and port 443 for HTTPS) can reach the web server, and that no unauthorised access is possible.
The first step the IT professional takes is to check the current firewall rules. On an older system, this might be done with iptables -L -n -v (list rules with numeric addresses and packet counts). On a newer system, the command might be nft list ruleset. The professional sees that the default policy on the INPUT chain is ACCEPT, meaning all traffic is allowed by default. This is a massive security risk. They immediately change the default policy to DROP using iptables -P INPUT DROP or the equivalent in nftables.
Next, they need to allow specific traffic. They know they need to let in HTTP (port 80) and HTTPS (port 443) traffic from anywhere. They add rules like: iptables -A INPUT -p tcp --dport 80 -j ACCEPT and iptables -A INPUT -p tcp --dport 443 -j ACCEPT. They also remember that they need to allow traffic from the server itself (loopback traffic, which is critical for local processes to communicate) and established connections (so that when a customer visits the site, the server can send data back to them; otherwise, the server would block its own outgoing responses). For established connections, they add a state rule: iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT.
The IT professional also needs to provide SSH access (port 22) for remote management, but they do not want to leave it open to the whole internet. They decide to only allow SSH from the company's office IP address. They add a rule: iptables -A INPUT -p tcp --dport 22 -s 203.0.113.0/24 -j ACCEPT, where 203.0.113.0/24 is the office network range.
To ensure these rules persist after a reboot, they save the rules using iptables-save > /etc/iptables/rules.v4 (on a Debian-based system) or by installing the iptables-persistent package. For nftables, they save with nft list ruleset > /etc/nftables.conf and enable the nftables service.
Finally, they test the firewall. They try to SSH into the server from a different IP address than the office and confirm they get a timeout (meaning the packet was dropped). They visit the website from a browser and confirm it loads correctly. They check the log files (/var/log/kern.log or /var/log/messages) to see if any drops are logged, which helps them detect potential attacks. This whole process of planning, testing, and persisting firewall rules is what a Linux system administrator does daily to maintain system security.
The LPIC-2 exam 202.4 requires you to demonstrate hands-on knowledge of configuring iptables and nftables firewalls. You will not be asked to write a 50-rule script from scratch, but you must know the syntax and structure of common commands. The exam is heavily focused on practical application, not just theory.
The exam loves to test your understanding of the basic building blocks: tables, chains, rules, and targets. For iptables, they expect you to know the three main tables (filter, nat, mangle) and their primary chains (INPUT, OUTPUT, FORWARD for filter; PREROUTING, POSTROUTING, OUTPUT for nat). Be prepared for questions that mix up these concepts. For example, a trap question might ask, "Which chain would you use to filter incoming packets destined for the local system?" The correct answer is the INPUT chain in the filter table. A common trap is offering the PREROUTING chain (which is for NAT, not filtering) as a distractor.
Another key area is the difference between iptables and nftables. The exam reflects that nftables is the modern replacement, but iptables is still widely used. You need to know at least how to list rules (nft list ruleset) and add a simple rule (nft add rule inet filter input tcp dport 22 accept) in nftables. They will test the concept of atomic rule updates in nftables versus iterative updates in iptables.
State tracking is another favourite. You must understand the meaning of the states: NEW (a new connection), ESTABLISHED (packets belonging to an existing connection), RELATED (packets related to an existing connection, like an FTP data connection), and INVALID (packets that are malformed or cannot be identified). The exam often asks how to allow only established connection replies, which requires the -m state --state ESTABLISHED,RELATED match.
Traps are set around the default policy. A question might describe a server with a default policy of ACCEPT and ask what the risk is. The answer is that it allows all traffic by default, which is insecure. They may also ask what happens when a packet does not match any rule in a chain whose default policy is DROP — the answer is the packet is dropped.
You must also know how to make rules persistent. The exam will ask about the correct way to save iptables rules for different distributions. For Debian/Ubuntu, the file is often /etc/iptables/rules.v4, and the command is iptables-save. For Red Hat/CentOS, the command is also iptables-save, but the file might be /etc/sysconfig/iptables. For nftables, the ruleset is saved with nft list ruleset > /etc/nftables.conf and loaded with nft -f /etc/nftables.conf.
Finally, the exam expects you to know how to insert a rule at a specific position (using -I with a number, like iptables -I INPUT 3 ...) and delete a rule by specification (-D) or by number (iptables -D INPUT 3). Understanding the order of rules is critical, as an incorrectly placed rule can accidentally block the administrator's own access.
A firewall's primary function is to control incoming and outgoing network packets based on a defined set of rules.
The `iptables` command uses tables (filter, nat, mangle) and chains (INPUT, OUTPUT, FORWARD) to organise rules.
The `nftables` command is the modern replacement for `iptables`, offering a simpler, unified syntax and atomic rule updates.
The default policy on a firewall chain should almost always be DROP to block all traffic not explicitly allowed.
Rules are processed in order until a match is found; placing a broad allow rule before a specific block rule will bypass the block.
Firewall rules are volatile and must be saved to a file (e.g., using `iptables-save` or `nft list ruleset > file`) to persist across reboots.
State tracking allows the firewall to recognise packets belonging to an existing connection using states like NEW, ESTABLISHED, and RELATED.
The `REJECT` target sends an error packet back to the sender, while `DROP` silently discards the packet, making `DROP` more secure for concealing your server.
Always test firewall rules from a separate session or terminal to avoid accidentally locking yourself out of the server.
These come up on the exam all the time. Here's how to tell them apart.
iptables
Uses multiple commands: iptables, ip6tables, arptables, ebtables
Applies rules one-by-one, not atomically (risk of inconsistent state)
Syntax is more complex and differs for each table (filter, nat, mangle)
nftables
Uses a single command: nft
Supports atomic rule updates (all or nothing) for consistency
Has a unified, consistent syntax across all tables and address families
DROP target
Silently discards the packet without any response
Hides the existence of the server from the sender
More secure for preventing reconnaissance
REJECT target
Sends an error packet back to the sender (e.g., 'connection refused')
Informs the sender that a host is reachable but the port is blocked
Can be useful for debugging but reveals information
Default policy ACCEPT
Allows all traffic that does not match a specific rule
You must manually block malicious traffic, increasing the chance of missing something
Highly insecure; any overlooked port is automatically accessible
Default policy DROP
Blocks all traffic that does not match a specific allow rule
You must manually allow only necessary traffic (least privilege)
Highly secure; unknown traffic is automatically denied
INPUT chain
Filters packets destined for the local server itself
Used to protect the host machine from incoming attacks
The most commonly secured chain for a standalone server
FORWARD chain
Filters packets passing through the server destined for another network (router scenario)
Used to protect other machines behind the firewall
Critical when the server acts as a router or gateway
State NEW
Matches the very first packet of a new connection
Used in allow rules to permit new inbound requests (like a web visitor)
Often restricted by source IP to limit who can initiate a connection
State ESTABLISHED
Matches packets belonging to an already established connection
Used to allow return traffic from the server to the client
Essential for most network services to function correctly
Mistake
Setting the default policy to ACCEPT and then adding rules to block specific things is more secure.
Correct
The default policy should be DROP (deny all), and you only add rules to allow specific, necessary traffic. This is the principle of least privilege.
It feels safer to block bad things explicitly, but you cannot think of everything a bad actor might try. With a default-allow, if you forget a block rule, you are open. With a default-deny, if you forget an allow rule, you just temporarily block a service.
Mistake
The `REJECT` target is more secure than `DROP` because it tells the sender to go away.
Correct
`DROP` is generally more secure because it does not inform the sender that a server exists at that address, making reconnaissance harder.
People intuitively think responding politely is better. But in security, you want to minimise the information you leak. A dropped packet times out; a rejected packet immediately tells the attacker your firewall is active.
Mistake
Once you write a firewall rule with `iptables`, it stays there forever.
Correct
Rules are stored in memory and are lost after a reboot unless you explicitly save them to a configuration file using `iptables-save` or a similar tool.
Beginners often forget the persistence step because the `iptables` command runs silently and the rule works immediately. They assume it is written to disk, but it is only living in the kernel's memory.
Mistake
`nftables` and `iptables` are two completely separate firewall systems that cannot coexist.
Correct
They can coexist on the same system, but it is discouraged because it can cause confusion and double processing of packets. On many modern distributions, installing `nftables` replaces the `iptables` command with a wrapper that uses the `nftables` kernel API.
The tools look different and have different commands, so it is easy to assume they conflict. In reality, they both manipulate the same Netfilter framework in the Linux kernel, but `nftables` is the newer interface.
Mistake
I only need to secure the INPUT chain because that is where incoming threats come from.
Correct
The OUTPUT chain is also important. It controls traffic leaving the server, which can prevent malware from phoning home or limit data exfiltration.
Security is often seen as protecting against outsiders. But an infected server can be used to attack other systems, so restricting outbound traffic is a critical part of a defence-in-depth strategy.
Mistake
The order of rules in a firewall chain does not matter because the firewall checks all rules before making a decision.
Correct
Order is critical. The firewall stops processing rules as soon as the first match is found. If a broad 'ACCEPT all' rule is placed at the top, subsequent 'DROP' rules will never be checked.
This is a classic programming logic error. Beginners often add a blanket allow rule first, thinking they can then refine it with other rules, but the blanket rule matches everything and ends the check.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
`nftables` is the modern replacement for `iptables`. It uses a single command-line tool (`nft`) instead of multiple tools (`iptables`, `ip6tables`, etc.), has a more consistent syntax, and supports atomic rule updates (applying all changes at once) to avoid leaving the firewall in an inconsistent state.
You save `iptables` rules by running `sudo iptables-save > /path/to/file`. The exact path varies by distribution (Debian often uses `/etc/iptables/rules.v4`, Red Hat uses `/etc/sysconfig/iptables`). You then need to install a package (like `iptables-persistent` on Debian) or enable a service to load the file on boot.
You likely have no rule allowing SSH (port 22) from your IP address, or your default policy on the INPUT chain is set to DROP and you forgot to add a rule to allow SSH. Always test from a separate terminal or session so you do not get locked out permanently.
This rule allows packets that are part of an already established connection (like the server's reply to a web request) or are related to an existing connection (like an FTP data channel). Without this rule, your server would block its own outgoing responses, breaking most network services.
`DROP` silently discards the packet, giving no indication to the sender that a server exists. `REJECT` sends an error packet (like 'connection refused') back to the sender. `DROP` is generally more secure because it does not leak information about your system's existence.
You run the command `sudo nft list ruleset`. This displays all tables, chains, and rules currently loaded in the `nftables` framework. If the system uses `iptables` under the hood, `sudo iptables -L` is the equivalent command.
It means you can define a complete set of `nftables` rules in a file and apply them all at once with `nft -f file`. If any single rule has an error, the entire set is rejected, and the firewall remains in its previous state. In contrast, `iptables` applies rules one by one, so a failed rule in the middle can leave the firewall partially updated.
You've finished System Security, Firewalls, and iptables/nftables. Continue through the LPIC-2 study guide to build a complete picture of the exam.
Done with this chapter?