Firewall Configuration: nftables Instead of iptables

01. Introduction: Why Modern Firewall Design Matters

In the world of Linux system administration, a firewall is not just a 'port blocker'. It's a craft that determines the stability and security of the entire ecosystem. In an era of mass brute-force attacks and real-time vulnerability scanning, a passive approach to network security is a death sentence.

As administrators, we must strive for precision. Every packet that enters the kernel's network stack must be processed with minimal performance overhead, while maintaining maximum rule clarity.

02. Changing of the Guard: From iptables to nftables

For years, iptables was the standard. However, its architecture — built on separate tools for IPv4, IPv6 (ip6tables), ARP (arptables), and bridges (ebtables) — has become inefficient.

nftables brings a revolution:

check_circle A unified framework for all protocols.
check_circle A much simpler and more readable syntax modelled on tcpdump.
check_circle Better performance through atomic rule updates without the need to reload the entire stack.

03. Practical nftables Configuration

Below I present a base configuration template for a public-facing server that implements a secure "Default Drop" approach.

# /etc/nftables.conf

flush ruleset

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

        # Allow loopback
        iif "lo" accept

        # Established and related connections
        ct state established,related accept

        # ICMP (Ping) with rate limit
        icmp type echo-request limit rate 5/second accept

        # SSH - restrict to trusted IP or use port knocking
        tcp dport 22 accept

        # HTTP/HTTPS for web server
        tcp dport { 80, 443 } accept

        # Log dropped packets (optional for debugging)
        limit rate 3/minute log prefix "NFT_INPUT_DROP: "
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

04. Rule Hardening: Rate Limiting & Logging

Opening ports is just the beginning. Real hardening involves rate-limiting excessive traffic that may indicate a DoS or brute-force attack attempt.

speed Rate Limiting

Use sets to dynamically ban IPs that generate too many connections in a short time on the SSH port.

description Logging Strategy

Log only what matters. Excessive logging can lead to disk space exhaustion and system slowdown.

Summary

Switching to nftables at first feels a bit like learning to drive all over again. I'd been typing iptables rules in my sleep for over a decade, so changing habits was a little painful. But I'll say it plainly: it was worth it. nftables is not just a new, cleaner syntax. Above all, it's the end of the nightmare of debugging IPv4 vs IPv6 conflicts, the end of guessing why the NAT table is ignoring our packets, and the end of resetting all connections every time you reload the firewall during a deployment.

For me, the biggest value isn't even the performance gains everyone raves about (though during gigabyte-scale DDoS attacks, it definitely delivers). The most important thing is peace of mind. Sets and maps let me reduce hundreds of sprawling configuration lines into a single, readable file that I can finally manage properly in version control. That's clean sysadmin hygiene and an investment in making sure your pager doesn't wake you at 3am. Treat it as a foundation — without it, you simply should not put machines into production on the open internet.

LINUX ADMIN7