Posted inSecurity

Moving from iptables to nftables: Why It’s a Mandatory Step for SysAdmins

Security tutorial - IT technology blog
Security tutorial - IT technology blog

Why I Decided to Retire iptables After Years of Use

I once managed a server cluster with over 2,000 iptables rules. Every time the configuration was updated, the system had to reload the entire list, causing bottlenecks and consuming significant CPU resources. The fragmentation between iptables (IPv4) and ip6tables (IPv6) also turned management into a total nightmare, especially when you are trying to follow a comprehensive security checklist.

Since Debian 11 and Ubuntu 22.04, I have completely switched to nftables. This isn’t just about following new trends. Nftables thoroughly solves fragmentation by grouping all protocols into a single management framework. Thanks to a virtual machine (VM) mechanism running directly in the kernel, its packet processing speed is significantly faster than its predecessor.

Practical Differences: Iptables vs. Nftables

If you’re still wondering whether it’s worth the change, look at these figures and structures:

  • Search Performance: Iptables scans rules linearly (O(n)). If a matching rule is at the end of a 1,000-line list, the packet has to wait. Nftables uses dictionaries and sets, allowing lookups with O(1) or O(log n) complexity for blazing-fast speeds.
  • Syntax: Instead of the messy -A INPUT -p tcp --dport 22 -j ACCEPT, nftables uses a clear hierarchical structure. It looks exactly like how you write Nginx or Juniper configs.
  • Centralized Management: You no longer need to run 2-3 different tools for IPv4 and IPv6. A single inet table handles everything.
  • Atomicity: You can apply hundreds of changes at once. The system ensures that either everything is applied or nothing changes, completely eliminating the risk of being “exposed” during updates.

Safe Migration Roadmap

Don’t rush to tear everything down on a production server. My process usually consists of 4 steps, often starting with a thorough security audit:

  1. Use automated tools to translate logic from iptables to nftables.
  2. Optimize configuration files (grouping ports, using sets).
  3. Test thoroughly in a Lab or Staging environment.
  4. Replace the service and monitor logs.

Hands-on Nftables Deployment Guide

1. Simple Installation

Most modern distros come with nftables pre-installed. If your server doesn’t have it yet, install it using the command:

# Debian/Ubuntu
sudo apt update && sudo apt install nftables -y

# RHEL/CentOS/AlmaLinux
sudo dnf install nftables -y

Type sudo nft list ruleset to check. If nothing appears, your server is either completely “open” or still using the old firewall.

2. Quick Rule Translation Tip

The iptables-translate tool is a lifesaver for those accustomed to iptables. For example, to translate a rule that opens port 80:

iptables-translate -A INPUT -p tcp --dport 80 -j ACCEPT
# Result: nft add rule ip filter INPUT tcp dport 80 counter accept

3. Building a Standard Ruleset (Template)

I recommend writing directly into the /etc/nftables.conf file instead of typing individual commands. Here is the configuration I often use for modern web servers, similar to how one might configure Nginx for traffic throttling:

#!/usr/sbin/nft -f

flush ruleset

table inet server_firewall {
    chain inbound {
        type filter hook input priority 0; policy drop;

        # Maintain existing connections (Crucial to avoid SSH disconnection)
        ct state established,related accept

        # Accept loopback
        iif "lo" accept

        # Allow Ping (Limit to 10 packets/sec to prevent flooding)
        ip protocol icmp limit rate 10/second accept
        ip6 nexthdr icmpv6 accept

        # Centralized Port Management
        tcp dport 22 accept
        tcp dport { 80, 443, 8080 } accept

        # Log and Drop suspicious access
        limit rate 5/minute log prefix "FIREWALL_DROP: "
    }
}

The highlights of this configuration:

  • flush ruleset: Ensures a clean table every time it’s loaded, avoiding overlapping old rules.
  • tcp dport { 80, 443 }: This is the power of nftables. You group multiple ports into a single rule, helping the kernel process much faster than separate lines.
  • ct state established,related: This rule ensures active connections aren’t interrupted when you reload the firewall.

4. Activation and Verification

To apply the new configuration, run:

sudo nft -f /etc/nftables.conf

If there are no syntax errors, enable the firewall to run automatically on boot and monitor your security audit logs:

sudo systemctl enable --now nftables

Hard-earned Experience: Don’t Lock Yourself Out

The most common mistake is applying a drop rule without allowing the SSH port (22), which is a key part of enhancing SSH security. I once had to scramble into the provider’s KVM Console just because of a moment of carelessness.

Pro tip: Before testing a new configuration, set a self-destruct command for the firewall after 5 minutes:

echo "systemctl stop nftables" | at now + 5 minutes

If you accidentally lock SSH, just wait 5 minutes and the system will automatically open it back up. If everything is fine, use atrm to delete that command.

Conclusion

Switching to nftables might take you an afternoon to get used to the syntax. However, the long-term benefits are huge: the server runs smoother, and configuration files are cleaner and more secure. If you are deploying a new server, don’t hesitate to choose nftables as your standard from the start.

Share:
Tags: