nftables: Migration von iptables auf das moderne Firewall Framework

1. Warum iptables bei großen Regelsätzen an Grenzen stößt

iptables arbeitet regelbasiert und wertet jede Regel einer Chain sequenziell von oben nach unten aus. Bei wenigen Dutzend Regeln fällt das kaum ins Gewicht, doch sobald ein Server hunderte oder tausende Regeln verwaltet, etwa für IP-basierte Zugriffskontrollen oder Portfreigaben pro Kunde, wächst die Auswertungszeit linear mit der Anzahl der Regeln. Jedes Paket muss im schlimmsten Fall die gesamte Kette durchlaufen, bevor eine Entscheidung fällt.

Ein weiteres strukturelles Problem ist die fehlende Atomarität klassischer iptables Aufrufe: Wer mehrere Regeln nacheinander mit einzelnen iptables Befehlen ändert, riskiert ein kurzes Zeitfenster mit inkonsistentem Regelwerk, in dem Pakete entweder zu großzügig durchgelassen oder fälschlich verworfen werden. Zusätzlich verwalten iptables und ip6tables getrennte Regelwerke für IPv4 und IPv6, was doppelte Pflege bedeutet und Inkonsistenzen zwischen beiden Protokollversionen begünstigt.

2. Die Architektur von nftables: Tables, Chains und der Kernel Interpreter

nftables wurde als Nachfolger für iptables, ip6tables, arptables und ebtables entwickelt und bündelt alle vier Frameworks in einer gemeinsamen Kernel Infrastruktur. Statt für jede Regel einen eigenen Kernel Modul Aufruf abzusetzen, kompiliert nftables Regelsätze in einen kompakten Bytecode, der von einer virtuellen Maschine im Kernel ausgeführt wird, vergleichbar mit dem BPF Ansatz, den auch andere moderne Linux Subsysteme nutzen.

Die Grundstruktur besteht aus Tables, die eine Adressfamilie wie ip, ip6 oder das kombinierte inet festlegen, aus Chains, die an Netfilter Hooks wie input, output oder forward angebunden werden, und aus Regeln innerhalb dieser Chains. Anders als bei iptables lassen sich mit der Adressfamilie inet IPv4 und IPv6 Regeln in derselben Chain gemeinsam pflegen, was doppelte Regelsätze überflüssig macht und die Konsistenz zwischen beiden Protokollversionen strukturell erzwingt.

# Neue Table für die kombinierte IPv4/IPv6 Filterung anlegen
nft add table inet filter

# Input Chain mit Standardrichtlinie drop an den Netfilter Hook haengen
nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; }

# Aktuelles Regelwerk vollstaendig anzeigen
nft list ruleset

3. Syntax-Unterschiede zwischen iptables und nftables im direkten Vergleich

Die auffälligste Änderung ist die deklarative, an eine eigene Grammatik angelehnte Syntax von nftables gegenüber den vielen Einzelflags von iptables. Wo iptables für jede Bedingung ein eigenes Flag wie -p, --dport oder -s verlangt, formuliert nftables Bedingungen als lesbare Ausdrücke, die Protokoll, Feld und Wert in einer Zeile verbinden, was die Regeln für Menschen deutlich leichter nachvollziehbar macht.

Ein SSH-Zugriff, der in iptables als iptables -A INPUT -p tcp --dport 22 -j ACCEPT formuliert wird, liest sich in nftables als nft add rule inet filter input tcp dport 22 accept. Für die eigentliche Migration einzelner Regeln bietet das Paket nftables die Werkzeuge iptables-translate und ip6tables-translate, die einen bestehenden iptables Befehl direkt in die passende nft Syntax übersetzen und damit den manuellen Übersetzungsaufwand erheblich reduzieren.

# Einzelne iptables Regel in nftables Syntax uebersetzen lassen
iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT

# Ergebnis, direkt als nft Kommando verwendbar
# nft add rule ip filter INPUT tcp dport 22 counter accept

4. Sets und Maps: Effiziente Verwaltung großer Regelmengen

Sets sind eine der größten strukturellen Verbesserungen gegenüber iptables. Statt für jede erlaubte IP-Adresse eine eigene Regel anzulegen, fasst ein Set beliebig viele Werte in einer einzigen Datenstruktur zusammen, die der Kernel intern als Hashtabelle oder, bei Intervallen wie IP-Bereichen, als balancierten Baum verwaltet. Die Prüfung gegen ein Set mit tausend Einträgen kostet dabei kaum mehr Rechenzeit als die Prüfung gegen ein Set mit zehn Einträgen, während dieselbe Logik in iptables tausend einzelne, sequenziell ausgewertete Regeln bedeuten würde.

Maps gehen noch einen Schritt weiter und verknüpfen einen Schlüssel mit einem Wert, etwa eine Ziel-Portnummer mit einer Verdict-Aktion wie accept oder drop. Damit lassen sich komplexe Entscheidungstabellen, die in iptables mehrere separate Chains mit Sprungregeln erfordert hätten, in nftables als eine einzige, kompakte Map abbilden, die sich zudem zur Laufzeit ohne Neuladen des gesamten Regelwerks aktualisieren lässt.

# Set für erlaubte Admin IP Adressen anlegen und befuellen
nft add set inet filter admin_ips { type ipv4_addr \; flags interval \; }
nft add element inet filter admin_ips { 203.0.113.10, 203.0.113.0/28 }

# Regel, die das Set für SSH Zugriff referenziert
nft add rule inet filter input tcp dport 22 ip saddr @admin_ips accept

# Map von Zielport auf Verdict für mehrere Dienste gleichzeitig
nft add map inet filter port_verdict { type inet_service : verdict \; }
nft add element inet filter port_verdict { 80 : accept, 443 : accept, 3306 : drop }
nft add rule inet filter input tcp dport vmap @port_verdict

5. Migrationsstrategie: Vom bestehenden iptables Regelwerk zu nftables

Für eine kontrollierte Migration empfiehlt sich ein zweistufiges Vorgehen. Zunächst wird das aktuelle Regelwerk mit iptables-save gesichert und anschließend mit iptables-restore-translate vollständig in nftables Syntax überführt, was im Gegensatz zur Einzelregel-Übersetzung mit iptables-translate den kompletten Regelsatz inklusive Chains und Policies in einem Durchgang umwandelt. Das erzeugte nft Skript sollte danach manuell durchgesehen werden, um Regeln, die von der Übersetzung nicht vollständig automatisch abgedeckt werden, wie bestimmte Match Module oder komplexe Zielaktionen, gezielt nachzubessern.

In der Praxis bewährt sich ein Parallelbetrieb: Das übersetzte nft Regelwerk wird zunächst auf einem Testsystem oder in einer separaten Netzwerknamespace geladen und dort gegen reale Testfälle geprüft, bevor es auf produktiven Servern das bestehende iptables Regelwerk ersetzt. Wichtig ist, dass alle Regeln vor dem produktiven Umschalten aus einer einzigen Datei mit nft -f geladen werden, weil nftables dadurch das komplette Regelwerk atomar aktiviert, statt wie bei iptables Regel für Regel mit potenziellen Zwischenzuständen.

# Bestehendes iptables Regelwerk sichern
iptables-save > /root/iptables-backup.rules

# Vollstaendiges Regelwerk in nftables Syntax uebersetzen
iptables-restore-translate -f /root/iptables-backup.rules -o /root/nftables-migrated.nft

# Uebersetztes Regelwerk atomar laden und testen
nft -f /root/nftables-migrated.nft
nft list ruleset

6. Der Kompatibilitäts-Layer iptables-nft für schrittweise Umstellungen

Für Umgebungen, in denen bestehende Automatisierung, Konfigurationsmanagement oder Monitoring-Skripte fest auf das iptables Kommando ausgerichtet sind, bietet der iptables-nft Kompatibilitäts-Layer einen sanften Übergang. Dabei handelt es sich um alternative iptables, ip6tables, ebtables und arptables Binaries, die dieselbe vertraute Kommandozeilensyntax annehmen, ihre Regeln intern jedoch nicht mehr über das klassische x_tables Kernel Modul, sondern direkt über die nftables Kernel Infrastruktur umsetzen.

Auf den meisten modernen Distributionen wie Debian, Ubuntu und RHEL ist dieser Layer bereits standardmäßig aktiv, was sich mit iptables --version überprüfen lässt, da die Ausgabe dann den Zusatz nf_tables statt legacy enthält. Der große Vorteil ist, dass mit iptables-nft erstellte Regeln über nft list ruleset sichtbar sind und sich problemlos mit nativ geschriebenen nft Regeln in derselben Table kombinieren lassen, was einen fließenden, risikoarmen Übergang von reinen iptables Skripten zu nativer nftables Syntax erlaubt, ohne den Betrieb zu unterbrechen.

# Pruefen, ob der iptables Befehl bereits über nf_tables läuft
iptables --version
# iptables v1.8.9 (nf_tables)

# Explizit zwischen legacy und nft Backend wechseln, Debian/Ubuntu
update-alternatives --set iptables /usr/sbin/iptables-nft
update-alternatives --set ip6tables /usr/sbin/ip6tables-nft

7. Praxisbeispiel: Vollständige Server-Firewall mit Rate Limiting

Ein realistisches Firewall Setup für einen Magento Hosting-Server kombiniert Standardregeln, ein Admin-IP-Set und Rate Limiting gegen SSH-Brute-Force-Versuche in einer einzigen, übersichtlichen Konfigurationsdatei. Die Reihenfolge der Regeln bleibt dabei relevant, da nftables Chains weiterhin sequenziell ausgewertet werden, nur eben effizienter, wenn Sets und Maps statt vieler Einzelregeln zum Einsatz kommen.

Besonders wertvoll ist die native limit rate Ausdruckssprache, mit der sich Verbindungsraten direkt in der Regel begrenzen lassen, ohne wie bei iptables auf ein separates hashlimit Modul mit komplexer Parameterliste zurückgreifen zu müssen. Damit lässt sich eine robuste, gut lesbare Firewall Konfiguration bauen, die HTTP, HTTPS und SSH gezielt freigibt und alles andere standardmäßig verwirft.

table inet filter {
  set admin_ips {
    type ipv4_addr
    flags interval
    elements = { 203.0.113.10, 198.51.100.0/28 }
  }

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

    ct state established,related accept
    iifname lo accept

    tcp dport { 80, 443 } accept
    tcp dport 22 ip saddr @admin_ips accept

    tcp dport 22 ct state new limit rate 5/minute accept
    tcp dport 22 ct state new counter drop
  }
}

8. Monitoring und Debugging von nftables Regelwerken im laufenden Betrieb

Für die Fehlersuche im laufenden Betrieb liefert nft list ruleset -a nicht nur die aktive Konfiguration, sondern zeigt zusätzlich interne Handle-IDs an, über die sich einzelne Regeln gezielt löschen oder ersetzen lassen, ohne das gesamte Regelwerk neu laden zu müssen. Counter innerhalb einer Regel, wie im obigen Beispiel bei der SSH-Drop-Regel verwendet, protokollieren fortlaufend Paket- und Byte-Zahlen und lassen sich mit nft list counters auswerten, um verdächtige Muster frühzeitig zu erkennen.

Für tiefergehende Analysen bietet nftables zudem native Logging-Ausdrücke, die anders als bei iptables direkt in die Regelsyntax integriert sind und sich gezielt mit einem Präfix versehen lassen, um verworfene Pakete im Kernel-Log eindeutig zuzuordnen. In Kombination mit journalctl -k oder einem zentralen Log-Aggregator lässt sich so nachvollziehen, welche Regel für welches Paket ausgelöst hat, was insbesondere bei komplexeren Set- und Map-basierten Regelwerken die Fehlersuche erheblich beschleunigt.

# Regelwerk mit Handle IDs für gezielte Änderungen anzeigen
nft list ruleset -a

# Verworfene SSH Pakete zusätzlich protokollieren
nft add rule inet filter input tcp dport 22 ct state new \
  log prefix \"ssh-drop: \" drop

# Kernel Log nach den protokollierten Eintraegen durchsuchen
journalctl -k -g ssh-drop

9. Best Practices und typische Fallstricke bei der Migration

Der häufigste Fehler bei der Migration ist, weiterhin für IPv4 und IPv6 getrennte Tables zu pflegen, obwohl die inet Adressfamilie genau dieses Problem lösen soll. Wer neue Regelwerke von Grund auf schreibt, sollte konsequent inet Tables verwenden und nur dort auf ip oder ip6 zurückgreifen, wo tatsächlich protokollspezifische Logik notwendig ist, etwa bei ICMP-spezifischen Regeln, die zwischen ICMPv4 und ICMPv6 unterschiedliche Nachrichtentypen verwenden.

Ein weiterer Fallstrick betrifft persistente Konfiguration: Anders als bei iptables, wo Distributionen häufig ein eigenes Persistenz-Paket wie iptables-persistent mitbringen, lädt nftables sein Regelwerk in der Regel direkt aus einer Datei wie /etc/nftables.conf über den systemd Dienst nftables.service. Änderungen, die nur interaktiv mit nft Befehlen vorgenommen werden, gehen beim nächsten Neustart verloren, sofern sie nicht zusätzlich in diese Konfigurationsdatei übernommen werden, weshalb produktive Regelwerke immer aus einer versionierten Datei geladen werden sollten.

10. Zusammenfassung

11. FAQ: nftables Migration