# Nftables Mastery: Die Zukunft der Linux-Firewall

TL;DR / Management Summary nftables ist der offizielle Nachfolger von iptables. Es räumt mit dem Chaos der verschiedenen Werkzeuge (iptables, ip6tables, arptables) auf und bündelt alles in einem einzigen Framework. Ein Senior Admin nutzt nftables wegen der atomaren Transaktionen (Regelsätze werden als Ganzes geladen) und der deutlich lesbareren, skriptähnlichen Syntax. Wer heute neue Systeme auf SLES oder Arch aufsetzt, nutzt ausschließlich nftables.

# 1. Einführung & Architektur

Die Vereinheitlichung.

In nftables gibt es keine vordefinierten Tables oder Chains mehr. Wir erstellen sie nach Bedarf. Ein entscheidender Vorteil sind die Adressfamilien.

# Adressfamilien (Mermaid)

graph TD
    A[nftables] --> B[ip: Only IPv4]
    A --> C[ip6: Only IPv6]
    A --> D[inet: Unified IPv4 & IPv6]
    A --> E[arp: ARP Filtering]
    A --> F[bridge: Layer 2 Filtering]
    D --> G[Tables & Chains]
    G --> H[Rules & Actions]

# 2. Der moderne Regelsatz (nftables.conf)

Variablen und Strukturen.

Datei: /etc/nftables.conf

#!/usr/sbin/nft -f

# 1. Tabellen leeren (Atomarer Reset)
flush ruleset

# 2. Variablen definieren
define LAN_IF = "eth0"
define TRUSTED_NETS = { 10.0.0.0/24, 192.168.1.0/24 }

# 3. Das Regelwerk (inet deckt v4 und v6 ab)
table inet my_firewall {
    chain inbound {
        type filter hook input priority 0; policy drop;

        # Alles auf Loopback erlauben
        iif lo accept

        # Bestehende Verbindungen (Stateful)
        ct state established,related accept

        # ICMP (Ping) erlauben
        icmp type echo-request accept
        icmpv6 type echo-request accept

        # SSH nur für das Team
        ip saddr $TRUSTED_NETS tcp dport 22 accept
    }
}

# 3. Sets: Performance bei vielen IPs

Suchen in O(1).

Anstatt 100 Regeln für 100 IPs zu schreiben, nutzen wir ein Set. Dies ist im Kernel hochoptimiert (Hash-Table).

# Erstellt ein Set zur Laufzeit
sudo nft add set inet my_firewall blacklist { type ipv4_addr \; }

# IP hinzufügen
sudo nft add element inet my_firewall blacklist { 1.2.3.4, 5.6.7.8 }

# Regel, die das Set nutzt
sudo nft add rule inet my_firewall inbound ip saddr @blacklist drop

# 4. Day-2 Operations: Atomare Updates

Keine Sicherheitslücken beim Laden.

In iptables mussten Regeln nacheinander gelöscht und hinzugefügt werden. In nftables laden wir die gesamte Konfiguration in einer Transaktion.

# Lädt die Datei. Schlägt sie fehl, bleibt der alte Regelsatz unverändert!
sudo nft -f /etc/nftables.conf

# 5. Troubleshooting & “War Stories”

Wenn die Logik neu gedacht werden muss.

# Story 1: “Der doppelte Port-Fail”

Symptom: Ein Admin will Port 80 öffnen und schreibt nft add rule ... tcp dport 80 accept. Aber das Paket wird trotzdem verworfen. Ursache: Er hat die Regel in eine Tabelle vom Typ ip (nur IPv4) geschrieben, der Client kam aber via IPv6. Lösung: Nutzen Sie immer die inet Familie. Sie spart Zeit und verhindert solche Inkonsistenzen.

# Story 2: “Das Problem mit der Priorität”

Symptom: Der Admin hat eine drop Regel hinzugefügt, aber der Traffic fliest weiter. Ursache: Es existiert eine andere Tabelle (vielleicht von Docker oder Libvirt), deren Hook eine höhere Priorität hat und accept sagt. Lösung: In nftables gewinnt die letzte Entscheidung im Hook-Pfad nicht zwingend. Wenn eine Chain drop sagt, ist das Paket weg. Schauen Sie sich den Gesamtstatus an: nft list ruleset.

# 6. Fazit & Empfehlung

• Wahl: Nutzen Sie inet für alle Standard-Firewalls.
• Wartung: Dokumentieren Sie Ihre Sets und Variablen. Sie machen das Regelwerk für andere Admins lesbar.
• Performance: Sets sind der Schlüssel zu High-Performance Firewalls bei vielen Whitelist/Blacklist-Einträgen.

# Anhang: Cheatsheet