iptables vs nftables: was sich geändert hat und wie Sie migrieren

Die Antwort vorweg: Sie betreiben wahrscheinlich schon nftables

Die Gegenüberstellung "iptables vs nftables" suggeriert eine Wahl zwischen zwei lebendigen Optionen. Für die meisten Server war diese Wahl 2026 bereits von Ihrer Distribution getroffen worden:

• Auf Debian 10+ und Ubuntu 20.10+ ist der iptables-Befehl standardmäßig iptables-nft, eine Kompatibilitätsschicht, die iptables-Syntax akzeptiert, aber das nf_tables-Subsystem des Kernels programmiert. Ihre iptables-Regeln laufen bereits auf der nftables-Engine.
• Bei der RHEL-Familie (RHEL/AlmaLinux/Rocky 9 und 10) ist das gesamte iptables-Framework veraltet, firewalld spricht nativ nftables, und RHEL 10 liefert das Legacy-Kernelmodul ip_tables überhaupt nicht mehr aus.
• Upstream befindet sich iptables im Maintenance Mode: Es erhält weiterhin Releases (1.8.13 erschien im März 2026), aber die gesamte Feature-Entwicklung findet in nftables statt.

Die praktische Empfehlung ist also kurz: bestehende, funktionierende iptables-Regelwerke sind kein Notfall; die Kompatibilitätsschicht ist gut und stabil. Aber neue Regeln und neue Automatisierung sollten in nativem nftables geschrieben werden: eine Syntax für IPv4 und IPv6, skalierende Sets und Maps, atomare Reloads, und keine Abhängigkeit von einem Shim, dessen zugrunde liegendes Tooling die Distributionen für die endgültige Entfernung vorgesehen haben. Der Rest dieses Artikels liefert die Details hinter diesem Rat sowie die Migrationsmechanik.

Wie wir hierher gekommen sind

netfilter, das Paketfilter-Subsystem des Kernels, hat drei nutzerseitige Generationen durchlaufen: ipchains (Kernel 2.2), iptables (Kernel 2.4, 2001) und nftables (zusammengeführt in Kernel 3.13, 2014). nftables wurde vom selben netfilter-Team geschrieben, um die strukturellen Probleme von iptables zu beheben, statt sie zu umgehen.

Das entscheidende Release war iptables 1.8 (2018), das den Befehl in zwei Varianten aufteilte: iptables-legacy (die klassische Implementierung) und iptables-nft (dieselbe Kommandozeilen-Syntax, aber die Regeln werden von der nf_tables-Kernel-Engine ausgeführt). Die Distributionen stellten ihren Standard-Alias fast sofort auf die nft-Variante um, und so migrierten Millionen Server die Engine, ohne dass ihre Betreiber es bemerkten:

Prüfen Sie, was eine gegebene Maschine tatsächlich verwendet; die Antwort steht in Klammern:

$ iptables -V
iptables v1.8.10 (nf_tables)   # ← the shim, executing on nftables
iptables v1.8.10 (legacy)      # ← the classic engine

Was sich tatsächlich geändert hat

Die Unterschiede, die operativ zählen, nicht die Marketingliste:

Ein Tool, beide Adressfamilien

Die Erbsünde von iptables: iptables, ip6tables, arptables und ebtables waren vier getrennte Tools mit vier getrennten Regelwerken, und jeder Dual-Stack-Server musste seine Policy zweimal geschrieben (und gepflegt, und auditiert) haben. Die IPv6-Hälfte zu vergessen war das klassische Loch. Die inet-Familie von nftables wendet eine Tabelle auf sowohl IPv4 als auch IPv6 an. Die ganze Klasse von „v4 abgesichert, v6 vergessen"-Bugs verschwindet strukturell.

Sets und Maps sind erstklassig

In iptables bedeutete das Matching von 500 Adressen 500 Regeln (linear ausgewertet), oder das Anflanschen des separaten ipset-Tools. In nftables sind Sets nativ:

nft add set inet filter blocklist '{ type ipv4_addr; flags interval; }'
nft add element inet filter blocklist '{ 203.0.113.0/24, 198.51.100.7 }'
nft add rule inet filter input ip saddr @blocklist drop

Eine Regel, O(1)-artiger Lookup, zur Laufzeit aktualisierbar, ohne das Regelwerk anzufassen. Maps gehen weiter und ordnen Match-Kriterien Aktionen oder Zielen zu (Konstrukte im Stil von dnat to tcp dport map { 80 : 10.0.0.10, 443 : 10.0.0.11 } verdichten ganze Regelfamilien zu einem Lookup). Dynamische Sets treiben außerdem das Rate Limiting pro Quelle an, das wir in unserer Baseline für Firewall-Regeln verwenden.

Atomarer Regelwerk-Austausch

nft -f ruleset.conf validiert und wendet die gesamte Datei atomar an: Sie lädt entweder vollständig, oder das alte Regelwerk bleibt unangetastet. iptables-Skripte wendeten Regeln einen Befehl nach dem anderen an, sodass ein Fehler auf halbem Weg die Firewall in einem halb konfigurierten Zustand zurückließ (gelegentlich, denkwürdig, in dem Zustand, in dem der Default-Drop bereits angewendet war und das SSH-Allow noch nicht). iptables-restore milderte dies pro Tabelle; bei nftables ist das der einzige Betriebsmodus. Zusätzlich gibt Ihnen nft -c eine Dry-Run-Syntaxprüfung.

Keine eingebauten Chains, keine feste Pipeline

iptables gab jeder Tabelle feste Chains (INPUT, FORWARD, OUTPUT...), die existieren, ob genutzt oder nicht, jede mit eigenen Kosten pro Paket. In nftables erstellen Sie nur die Chains, die Sie brauchen, und hängen sie mit expliziten Prioritäten an Kernel-Hooks. Der Overhead einer leeren Firewall ist tatsächlich null, und das Regelwerk, das Sie lesen, ist die ganze Wahrheit, nichts Implizites.

Bessere Introspektion und Automatisierung

nft monitor streamt Regelwerk-Änderungen live (hervorragend für das Debugging von „was hat gerade meine Firewall verändert?"), Counter sind pro Regel opt-in, und nft -j spricht JSON in beide Richtungen, die moderne Antwort auf eine Generation brüchiger iptables-save-Parser. Wenn Sie Firewall-Konfiguration mit Ansible oder Terraform templaten, ist natives nftables merklich weniger schmerzhaft.

Syntax im direkten Vergleich

Die Aufgaben, die Sie tatsächlich erledigen, in beiden Sprachen:

Die nftables-Spalte liest sich wie eine Sprache statt wie die Flag-Suppe eines Befehls, weil sie auch eine ist: Ausdrücke kombinieren sich frei (ip saddr @admins tcp dport 22 ct state new accept), statt für jedes Feature ein maßgeschneidertes Match-Modul zu erfordern.

Performance: die ehrliche Version

Behauptungen, dass nftables weit schneller (oder langsamer) sei, sind beide leicht zu finden und meist unbelegt. Die glaubwürdigen öffentlichen Daten:

• Red Hats netfilter-Entwickler haben die beiden 2017 verglichen: Bei kleinen, linearen Regelwerken war iptables tatsächlich etwas schneller; das Bild kehrt sich um, sobald Sets ins Spiel kommen: Beim Matching über ~120+ Ports oder große Adressgruppen degradiert iptables linear, während nftables flach bleibt. Ihre Schlussfolgerung war, dass die Architekturen vergleichbar sind und der Gewinn bei Sets/Maps liegt, nicht bei der reinen Geschwindigkeit pro Regel. (Daten von 2017: Die Grundaussage der Schlussfolgerung hat sich gehalten, aber behandeln Sie die absoluten Zahlen als historisch.)
• Im Orchestrierungsmaßstab wird der Unterschied sichtbar: Kubernetes' kube-proxy erhielt in 1.33 einen GA-nftables-Modus, hauptsächlich weil die lineare Regelauswertung und die vollständigen Tabellen-Reloads von iptables bei Zehntausenden von Services schmerzen. Bei ~30,000 Services schlug die Tail-Latenz des nftables-Modus die beste Latenz des iptables-Modus. Bemerkenswerterweise bleibt der iptables-Modus aus Kompatibilitätsgründen der Standard von Kubernetes.

Bei einem einzelnen Server mit Dutzenden Regeln werden Sie keinen Unterschied messen. Entscheiden Sie sich für nftables wegen der Ausdrucksstärke, der Atomarität und der Tatsache, dass dorthin nun aller Wartungs- und Entwicklungsaufwand fließt, nicht wegen des Durchsatzes.

Migrieren

Schritt 1: herausfinden, was Sie einsetzen

iptables -V (siehe oben). Prüfen Sie auch auf Regeln in beiden Engines, ein überraschend häufiges Durcheinander nach teilweisen Migrationen:

iptables-legacy -L -n 2>/dev/null   # anything here runs on the old engine
nft list ruleset                    # the full truth, including iptables-nft rules

nft list ruleset zeigt alles in nf_tables, einschließlich Regeln, die über den Shim erstellt wurden; es ist der eine Befehl, der Sie nie über den wahren Zustand der Firewall belügt.

Schritt 2: mechanische Übersetzung

Das iptables-Paket liefert Übersetzer mit. Dieselbe Syntax rein, nft-Syntax raus:

$ iptables-translate -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
nft 'add rule ip filter INPUT tcp dport 22 ct state new counter accept'

# whole ruleset at once:
iptables-save > current.rules
iptables-restore-translate -f current.rules > ruleset.nft
nft -c -f ruleset.nft   # syntax-check before applying

(ip6tables-restore-translate für die v6-Hälfte.) Die Ausgabe ist korrekt, aber wörtlich: Sie reproduziert Ihre v4/v6-Duplizierung und Pro-Regel-Struktur unverändert.

Schritt 3: das Modell tatsächlich übernehmen

Behandeln Sie die übersetzte Datei als Gerüst und strukturieren Sie dann um: Führen Sie die v4/v6-Regelwerke in einer inet-Tabelle zusammen, verdichten Sie wiederholte Port-/Adressregeln zu Sets, und fügen Sie Kommentare hinzu. Aus einem 100-zeiligen iptables-Regelwerk werden routinemäßig 30 lesbare nftables-Zeilen. Unser Artikel zur Firewall-Baseline ist ein vernünftiges Grundgerüst, auf das Sie migrieren können. Wenden Sie es mit einem geplanten Rollback und einer offenen zweiten SSH-Sitzung an (die Mechanik zur Aussperrungsvermeidung wird dort ebenfalls behandelt).

Die Fallstricke

• Lassen Sie keine Regeln in beiden Engines laufen. Legacy-iptables- und nftables-Regeln werden beide unabhängig voneinander ausgewertet. Ein Paket muss beide überstehen. Das „funktioniert", bis es undebugbares Verhalten erzeugt. Migrieren, verifizieren, dann die Legacy-Seite flushen.
• Docker spricht noch immer iptables. Docker programmiert sein NAT/Forwarding standardmäßig über die iptables-Schnittstelle (kein Problem: Auf modernen Systemen ist das der nft-Shim; entfernen Sie das iptables-Paket nicht auf einem Docker-Host). Sein natives nftables-Backend erschien experimentell in Engine 29, ist aber opt-in. Praktische Konsequenz: Platzieren Sie auf einem Docker-Host Ihre Policy in der DOCKER-USER-Chain oder in Ihren eigenen Tabellen, und führen Sie nicht blind flush ruleset aus. Das räumt auch die Regeln von Docker weg. (Dieselbe Geschichte für Kubernetes-Nodes: Prüfen Sie Ihr CNI und Ihren kube-proxy-Modus, bevor Sie die Firewall anfassen.)
• Frontends sind in Ordnung. Wählen Sie eine Schicht. ufw (iptables-Syntax über den Shim) und firewalld (natives nftables-Backend seit 2018) funktionieren heute beide korrekt. Das Antipattern ist, nft-Tabellen von Hand auf einer Maschine zu bearbeiten, die von einem Frontend verwaltet wird; das Frontend gewinnt beim nächsten Reload.

Wann es sinnvoll ist, bei iptables zu bleiben

Ehrlichkeit über die andere Seite: Ein stabiler, appliance-artiger Server mit einem funktionierenden, auditierten iptables-nft-Regelwerk und ohne aktive Regelentwicklung hat wenig zu gewinnen von einer Neufassung. Tooling, das nur iptables ausgibt (ältere fail2ban-Actions, Legacy-Orchestrierung), ist ebenfalls ein legitimer Grund zum Aufschieben; genau dafür existiert der Shim. Die Linie, die Sie halten sollten, ist richtungsweisend: Schreiben Sie keine neuen Systeme, Rollen oder Dokumentationen gegen die Legacy-Syntax, denn die RHEL-Familie hat deren Entfernung bereits eingeplant, und der Rest des Ökosystems folgt dem netfilter-Team von Red Hat.

Häufig gestellte Fragen

Ist iptables veraltet?

Genau genommen: von den Distributionen als veraltet erklärt, upstream weiterhin gepflegt. Das netfilter-Projekt veröffentlicht weiterhin iptables-Releases (1.8.13, März 2026) und hat kein End-of-Life angekündigt. Aber Red Hat hat das gesamte iptables-Framework in RHEL 9 als veraltet erklärt, das Legacy-Kernelmodul in RHEL 10 entfernt, und der Standard jeder großen Distro ist seit Jahren die nftables-Engine. „Tot" ist falsch; „Legacy-Schnittstelle auf geliehener Zeit" ist richtig.

Verwenden ufw und firewalld nftables?

firewalld: ja, nativ. nftables ist seit 2018 sein Standard-Backend. ufw: indirekt. Es generiert iptables-Regeln und führt sie über die iptables-Binary des Systems aus, die auf jedem modernen Ubuntu der nft-basierte Shim ist, sodass die Regeln in nf_tables landen; ufw selbst hat keinen nativen nftables-Modus. So oder so landen Ihre Regeln im selben Kernel-Subsystem.

Hören meine iptables-Regeln auf zu funktionieren, wenn ich wechsle?

Die Logik Ihrer Regeln überträgt sich sauber; iptables-restore-translate wandelt ein gespeichertes Regelwerk mechanisch um, und die nftables-Engine unterstützt alles, was der grundlegende iptables-Funktionsumfang auch tut. Was nicht automatisch übernommen wird: ipset-Definitionen (als native Sets neu anlegen), jedes Skript, das die Ausgabe von iptables -L parst, und Annahmen über eingebaute Chains. Übersetzen, mit nft -c einen Dry-Run machen, atomar anwenden, einen Rollback eingeplant halten.

Ist nftables schneller als iptables?

Im kleinen Maßstab: nein. Red Hats eigene Benchmarks zeigten, dass einfache lineare Regelwerke iptables leicht bevorzugten. nftables gewinnt, wo Struktur zählt: große Port-/Adress-Sets (flach statt linear durchsucht), sehr große Regelwerke und häufige Regeländerungen (atomare inkrementelle Updates statt vollständiger Tabellen-Reloads, der Grund, warum Kubernetes einen nftables-kube-proxy gebaut hat). Für eine typische Server-Firewall entscheiden Sie nach Wartbarkeit; bei der Performance gleicht es sich aus.

Bereitstellung auf Serverside

Welche Syntax Sie auch schreiben, die Firewall auf dem Host ist eine von zwei Schichten in unserem Netzwerk: Jeder Dedicated Server enthält eine Self-Service-Edge-Firewall (Nicht-Service-Traffic wird upstream verworfen, bevor er Ihren Port erreicht) plus dauerhaft aktive DDoS-Mitigation in unserem ASN-55285-Netzwerk, mit Provisioning in unter einer Minute auf jeder gängigen Linux-Distribution.

Bauen Sie auf diesem Artikel auf mit dem vollständigen Standard-Firewall-Regelwerk für einen Linux-Server, dem größeren Bedrohungsbild in DDoS-Angriffe erklärt, und praktischer Traffic-Forensik in einen DDoS-Angriff mit Wireshark erfassen und analysieren.