Firewall mit nftables — Direktes Tooling

Wann nftables direkt — und nicht ufw oder firewalld?

ufw und firewalld sind beides Wrapper-Tools — sie übersetzen einfache Befehle wie ufw allow 22/tcp oder firewall-cmd --add-service=http in komplexere Kernel-Regeln. Im Hintergrund landet alles in nftables (oder, bei älteren Kernels, in iptables). Für die meisten Setups ist diese Abstraktion ein Gewinn: weniger zu lernen, weniger Fehlerquellen, schnell konfigurierbar.

Direktes Arbeiten mit nftables lohnt sich aber in mehreren Situationen:

• Die Distribution bringt kein ufw mit. RHEL, AlmaLinux und Rocky liefern stattdessen firewalld. Wer dort weder firewalld noch ufw nachinstallieren möchte, kommt direkt mit nftables in Berührung — und das Tool ist ohnehin bereits Teil des Basis-Systems.
• Die nötige Logik geht über das Standard-Repertoire hinaus. ufw kann Ports öffnen und Quell-IPs filtern. Sobald NAT, Forwarding zwischen Interfaces, Rate-Limiting auf Paketebene, fortgeschrittenes Connection-Tracking oder interface-spezifische Regeln ins Spiel kommen, wird die Konfiguration mit ufw umständlich oder unmöglich — mit nftables ist das in wenigen Zeilen erledigt.
• Konfiguration soll als Datei im Repo liegen. ufw wird mit Befehlen aufgebaut, die hintereinander ausgeführt werden — der Endzustand ist nirgendwo als zentrales Dokument. Bei nftables steht das gesamte Regelwerk in einer einzigen Datei (/etc/nftables.conf), die sich versionieren, reviewen und reproduzierbar deployen lässt — wichtig, sobald mehrere Server identisch konfiguriert werden sollen.
• Atomares Reload nötig. ufw setzt Regeln einzeln nacheinander — zwischen zwei Befehlen kann ein Paket noch nach der alten Logik durchschlüpfen. nftables lädt die komplette Konfiguration in einer Kernel-Transaktion: Entweder das gesamte neue Regelwerk wird aktiv, oder das alte bleibt unverändert. Bei produktiven Systemen mit hoher Last ist das ein relevanter Unterschied.

In den meisten Fällen reicht ufw vollkommen aus, und der Aufwand, sich nftables-Syntax anzueignen, lohnt sich nicht. Wer ufw schon nutzt und damit zufrieden ist, sollte nicht wechseln. Dieser Artikel ist die Alternative für die Fälle, in denen ufw an seine Grenzen kommt — oder wenn die Distribution ohnehin auf nftables-Direkt-Arbeit ausgelegt ist.

Koexistenz vermeiden. Auf einem System läuft entweder ufw, firewalld oder nftables direkt — niemals zwei davon gleichzeitig. Beide Dienste schreiben in dieselben Kernel-Strukturen, beide laden ihre Regeln beim Start, beide löschen ggf. die Regeln des anderen. Das Resultat sind unvorhersehbare Zustände nach jedem Reboot oder Reload. Vor dem Umstieg den jeweils anderen Dienst zwingend stoppen und mit systemctl disable aus dem Boot-Lauf nehmen.

Modell: Family, Table, Chain, Rule

nftables strukturiert Regeln in einer klaren Hierarchie aus vier Ebenen. Wer das Modell einmal verstanden hat, liest jede nftables-Konfiguration ohne Überraschungen.

Im Detail:

• Family entscheidet, welche Pakettypen die Tabelle überhaupt sieht. ip behandelt nur IPv4, ip6 nur IPv6. Die inet-Family ist der pragmatische Mittelweg: eine Tabelle, beide Stacks abgedeckt — keine doppelten Regelwerke. bridge ist relevant für Layer-2-Filterung in Bridge-Konfigurationen (z. B. KVM-Hosts), netdev für sehr früh greifende Filter direkt am Interface (z. B. für DDoS-Abwehr, bevor irgendetwas anderes greift). Für eine normale Host-Firewall: immer inet.
• Table ist nur ein Container — der Name ist frei wählbar. Konvention: die Haupt-Tabelle einer Host-Firewall heißt filter. Du könntest sie auch meine_firewall nennen, aber jedes Tutorial geht von filter aus, also bleibt man beim Standard.
• Chain ist die eigentliche Regelliste. Eine Chain wird über einen Hook an einer bestimmten Stelle des Kernel-Netzwerk-Stacks aufgehängt: input greift bei Paketen, die für den Server selbst bestimmt sind, output bei ausgehenden Paketen, forward bei Paketen, die der Server weiterleitet (Routing), prerouting/postrouting für NAT vor und nach der Routing-Entscheidung. Welche Chain ein Paket trifft, entscheidet der Kernel automatisch anhand des Hook-Typs.
• Rule ist eine einzelne Zeile mit zwei Teilen: einer Bedingung (welche Pakete sind gemeint? z. B. „TCP-Port 22”) und einer Aktion (was passiert mit ihnen? accept, drop, reject, log, …).

Der entscheidende konzeptionelle Unterschied zu iptables: In iptables existieren feste, vorgegebene Tabellen (filter, nat, mangle) und Chains (INPUT, OUTPUT, FORWARD). Sie sind immer da, du kannst nur Regeln hinzufügen. In nftables ist eine frische Installation komplett leer — keine vorgegebenen Tabellen, keine Default-Chains. Du legst die gesamte Struktur explizit selbst an. Das wirkt auf den ersten Blick wie Mehrarbeit, ist aber ein Vorteil: das Regelwerk steht vollständig in deiner Konfigurationsdatei, ohne versteckte Defaults, die irgendwo greifen.

Installation und Vorbereitung

Auf Debian/Ubuntu ist nftables als Paket vorhanden, aber der Service ist nicht zwingend aktiv:

sudo apt install nftables -y
sudo systemctl enable --now nftables

enable --now macht in einem Schritt zwei Dinge: aktiviert den Service so, dass er bei jedem Boot startet (enable), und startet ihn sofort (now). Der Service liest beim Start /etc/nftables.conf ein und lädt das dort definierte Regelwerk in den Kernel.

Auf AlmaLinux/Rocky ist meistens firewalld aktiv — ein paralleles Firewall-Tool, das nftables im Hintergrund nutzt. Wer direkt mit nftables arbeiten möchte, muss firewalld erst stoppen und ausschalten, sonst überschreiben sich die Regeln gegenseitig:

sudo dnf install nftables -y
sudo systemctl disable --now firewalld
sudo systemctl enable --now nftables

Wer firewalld lieber behalten möchte, sollte diesen Artikel überspringen und in Sektion 9 zu firewalld zurückkehren.

Den aktuellen Regelstand anzeigen:

sudo nft list ruleset

Bei einer frischen Installation ist die Ausgabe leer. Wichtige Konsequenz, die sich grundlegend von ufw unterscheidet: Ein leerer nftables-Stand bedeutet alles ist erlaubt — kein Default-Deny, keine Schutzfunktion. Während ufw nach ufw enable automatisch eine Deny-Policy aktiviert, ist nftables erst dann eine Firewall, wenn du selbst eine entsprechende Policy in deine Chains schreibst. Bis dahin filtert nichts. Im nächsten Schritt definieren wir die Konfiguration vollständig in einer Datei.

Eine sinnvolle Basis-Konfiguration

Die Datei /etc/nftables.conf ist der Standard-Ladepfad bei systemctl start nftables. Inhalt:

#!/usr/sbin/nft -f

# Bestehenden Ruleset komplett leeren — sauber neu aufbauen
flush ruleset

table inet filter {

    # ─── INPUT ────────────────────────────────────────────────
    chain input {
        type filter hook input priority filter; policy drop;

        # Loopback durchlassen
        iif "lo" accept

        # Bestehende und verwandte Verbindungen erlauben
        ct state established,related accept

        # Ungültige Pakete verwerfen
        ct state invalid drop

        # ICMP / ICMPv6 (Ping, Path-MTU, Neighbor Discovery) erlauben
        ip protocol icmp accept
        ip6 nexthdr icmpv6 accept

        # SSH — Anpassen, falls Port geändert ist
        tcp dport 22 accept

        # HTTP/HTTPS für Webserver
        tcp dport { 80, 443 } accept

        # Nicht passende Pakete: durch Policy "drop" verworfen.
        # Logging des letzten Drops für Debugging:
        # log prefix "nft drop: " limit rate 5/minute
    }

    # ─── FORWARD ──────────────────────────────────────────────
    chain forward {
        type filter hook forward priority filter; policy drop;
    }

    # ─── OUTPUT ───────────────────────────────────────────────
    chain output {
        type filter hook output priority filter; policy accept;
    }
}

Was die wichtigsten Zeilen tun:

• flush ruleset ganz am Anfang sorgt für einen sauberen Reload. Wenn die Datei mehrfach geladen wird, würden ohne flush die neuen Regeln zusätzlich zu den bestehenden landen — Duplikate, unklarer Endzustand. Mit flush wird der gesamte Regelstand verworfen, bevor die neuen Regeln geladen werden, alles in einer einzigen Transaktion.
• table inet filter { definiert die Haupt-Tabelle. inet heißt: deckt IPv4 und IPv6 gemeinsam ab. Eine einzige Tabelle für beide Stacks — kein doppelter Aufwand, keine Gefahr, IPv6-Regeln zu vergessen.
• type filter hook input priority filter; policy drop; ist die Definition einer Chain mit drei Eigenschaften: Sie ist eine Filter-Chain (Typ filter, im Gegensatz zu NAT-Chains), wird am Hook input aufgehängt (also bei eingehenden Paketen, die für den Server bestimmt sind), die Priorität bestimmt die Reihenfolge bei mehreren Chains am selben Hook (filter ist der Standardwert dafür), und die policy drop greift, wenn keine Regel der Chain matcht — dann wird das Paket verworfen.
• policy drop bei input und forward — der Sicherheits-Default. Pakete, die keine explizite Erlaubnis bekommen, werden verworfen. Bei forward betrifft das Pakete, die der Server weiterleiten soll — auf einem normalen Server gibt es davon ohnehin keine.
• policy accept bei output — der pragmatische Default für ausgehenden Verkehr. Outbound-Filterung wäre theoretisch eine zusätzliche Sicherheitsschicht, ist in der Praxis aber kaum sinnvoll zu pflegen, weil moderne Anwendungen mit vielen Hosts kommunizieren.
• iif "lo" accept — Loopback-Verkehr (Pakete, die der Server an sich selbst schickt, z. B. localhost-Verbindungen) wird ausnahmslos durchgelassen. Ohne diese Regel würden Dienste, die intern miteinander reden (z. B. eine App, die auf einem lokalen Redis lauscht), nicht funktionieren.
• ct state established,related accept — der Conntrack-Trick. „Connection Tracking” merkt sich, welche Verbindungen vom Server selbst aufgemacht wurden. Wenn der Server eine HTTPS-Anfrage zu https://api.example.com stellt, kommt die Antwort als eingehendes Paket zurück — und genau das soll erlaubt sein, ohne pauschal jeden eingehenden Port zu öffnen. established markiert „gehört zu einer bekannten Verbindung”, related markiert verwandten Verkehr (z. B. ICMP-Fehlermeldungen zu einer bestehenden Verbindung). Ohne diese Regel funktioniert auf dem Server praktisch nichts — apt update, DNS-Lookups, Web-Requests laufen ins Leere, weil die Antworten geblockt werden.
• ct state invalid drop verwirft Pakete, die der Conntrack-Logik widersprechen — kaputte oder gespoofte Pakete, die zu keiner bestehenden Verbindung passen und auch keinen neuen Verbindungsaufbau darstellen.
• ip protocol icmp accept / ip6 nexthdr icmpv6 accept — ICMP (Ping, Path-MTU-Discovery, Unreachable-Meldungen) und ICMPv6 (zusätzlich Neighbor Discovery, das IPv6 zwingend braucht) werden zugelassen. Vor allem ICMPv6 ist nicht optional: Wer es blockiert, bricht IPv6 in subtilen Weisen — DNS scheint zu funktionieren, aber Verbindungen hängen oder sind sehr langsam.
• tcp dport 22 accept — die SSH-Regel. dport heißt „destination port” (Zielport, also auf welchem Port der Server lauscht). Anpassen, falls SSH auf einem anderen Port läuft.
• tcp dport { 80, 443 } accept — Set-Syntax: mehrere Ports in einer Regel zusammenfassen. Auch tcp dport { 80, 443, 8080 } oder Bereiche wie tcp dport 8000-8100 sind möglich. Das ist deutlich lesbarer als drei einzelne Regeln.

Atomar laden und prüfen

Vor dem Laden die Syntax prüfen:

sudo nft -c -f /etc/nftables.conf

-c (check) parst die Datei, lädt aber nichts. Bei Fehlern wird die Zeile gemeldet, ohne dass der laufende Regelstand verändert wird.

Wenn alles passt, real laden:

sudo nft -f /etc/nftables.conf

Oder über systemd, was beim Boot ohnehin geschieht:

sudo systemctl reload nftables

Atomar laden — was heißt das? nftables wendet die komplette neue Konfiguration in einer Kernel-Transaktion an. Während des Wechsels werden keine Pakete „zwischen alten und neuen Regeln” verloren — entweder die alte oder die neue Konfiguration ist aktiv, nie ein Mix. Bei iptables-Befehlen war das anders: jede Regel wurde einzeln geschoben, mit Mikropausen dazwischen.

Den aktiven Stand kontrollieren:

sudo nft list ruleset

Quell-IP und Subnetz-Filterung

Bisher haben wir Ports global geöffnet — tcp dport 22 accept lässt jede Quelladresse zu. Für administrative Dienste (Datenbanken, Webmin, phpMyAdmin, Monitoring-Backends) ist das nicht akzeptabel: Solche Ports sollten nur von vertrauenswürdigen Quellen erreichbar sein. nftables filtert Quell-Adressen mit saddr (source address), für IPv4 und IPv6 jeweils separat:

# PostgreSQL nur vom App-Server
ip saddr 203.0.113.50 tcp dport 5432 accept

# Webmin nur aus dem Büro-Subnetz (IPv4 und IPv6)
ip saddr 198.51.100.0/24 tcp dport 10000 accept
ip6 saddr 2001:db8:1::/48 tcp dport 10000 accept

Diese Regeln gehören in die input-Chain, vor die generischen accept-Regeln. nftables wertet Regeln von oben nach unten aus — die erste passende greift. Eine zu generische Regel weiter oben würde die spezifische unten überschatten.

Bei mehreren vertrauenswürdigen Quellen lohnt sich ein Set: eine benannte Liste, die in mehreren Regeln referenziert werden kann. Das macht das Regelwerk deutlich übersichtlicher als viele Einzelregeln, und Erweiterungen müssen nur an einer Stelle gepflegt werden:

set trusted_v4 {
    type ipv4_addr
    flags interval
    elements = { 203.0.113.50, 198.51.100.0/24 }
}

chain input {
    type filter hook input priority filter; policy drop;
    # ... vorherige Regeln (Loopback, Conntrack, ICMP) ...

    ip saddr @trusted_v4 tcp dport 10000 accept
}

Erläuterungen zur Set-Syntax:

• type ipv4_addr definiert, welcher Datentyp im Set steht — hier IPv4-Adressen. Für IPv6 wäre es ipv6_addr, für Ports inet_service.
• flags interval ist nötig, damit das Set sowohl einzelne IPs als auch ganze Subnetze (CIDR-Bereiche) speichern kann. Ohne dieses Flag dürfen nur einzelne Adressen drin stehen.
• elements = { ... } ist die Liste der Werte. Im Beispiel eine einzelne IP plus ein /24-Subnetz mit 256 Adressen.
• @trusted_v4 ist die Set-Referenz in einer Regel — das @ zeigt nftables an, dass es einen Set-Namen auflösen soll, keinen wörtlichen Wert.

Sets können auch zur Laufzeit dynamisch ergänzt werden (nft add element inet filter trusted_v4 { 192.0.2.5 }) — praktisch für Skripte, die VPN-Clients automatisch eintragen.

Rate-Limiting und SSH-Brute-Force-Schutz

fail2ban ist der bekannte Weg, wiederholte SSH-Fehlversuche zu sperren — er wertet Logs aus und schreibt iptables-/nftables-Regeln, die die Quell-IP für eine Weile blockieren. Das funktioniert gut, hat aber zwei Schritte: Versuch passiert, fail2ban liest das Log, schreibt eine Regel. Bei massiven Angriffen kommen viele Versuche durch, bis die Sperre greift.

nftables kann Rate-Limiting bereits auf Paket-Ebene umsetzen — also bevor sshd das Paket überhaupt sieht, ohne Logs lesen zu müssen, ohne externe Tools. Das ist eine zusätzliche Schicht, kein Ersatz für fail2ban (die zeitlich gesteuerte Sperre, die fail2ban macht, ist mit nftables-Bordmitteln umständlicher abbildbar).

chain input {
    type filter hook input priority filter; policy drop;
    iif "lo" accept
    ct state established,related accept
    ct state invalid drop
    ip protocol icmp accept
    ip6 nexthdr icmpv6 accept

    # SSH mit Rate-Limit
    tcp dport 22 ct state new \
        meter ssh_meter { ip saddr limit rate 4/minute } \
        accept

    tcp dport { 80, 443 } accept
}

Die Rate-Limit-Regel funktioniert in mehreren Schritten:

• tcp dport 22 ct state new — wir matchen nur neue TCP-Verbindungen auf Port 22. Bestehende Verbindungen sind durch die Conntrack-Regel oben bereits abgedeckt und sollen nicht limitiert werden.
• meter ssh_meter { ip saddr limit rate 4/minute } — meter legt einen dynamischen, in-Memory-Tracker an, der pro Quell-IP (ip saddr) zählt. Die Schwelle: max. 4 Verbindungen pro Minute. Die ersten 4 Verbindungen einer IP gehen durch — die fünfte und alle weiteren innerhalb desselben Minuten-Fensters werden nicht durchgelassen, weil die Regel nicht mehr matcht und die policy drop der Chain greift.
• accept — wenn die IP unter dem Limit ist, wird das Paket durchgelassen.

Effektiv heißt das: ein Bot, der hundert Logins pro Sekunde durchprobieren möchte, kommt mit den ersten 4 Versuchen durch — danach werden alle weiteren auf Paket-Ebene verworfen, bevor sshd überhaupt einen Krypto-Handshake starten muss. Das spart CPU und reduziert die Log-Last drastisch.

Anpassen kann man die Werte je nach Use Case: rate 10/minute für eine relaxere Variante, rate 1/second ist deutlich aggressiver. Die Tracking-Daten halten ca. eine Minute (durch das Limit-Fenster), danach wird die Quelle wieder „neu” gezählt.

Persistenz über Reboots

Eine wichtige Eigenschaft von nftables: Regeln existieren nur im Kernel-Speicher. Mit einem Reboot ist der Stand weg, der Server bootet ohne Filterung — sofern niemand dafür sorgt, dass die Datei /etc/nftables.conf beim Start geladen wird. Das übernimmt nftables.service:

sudo systemctl enable --now nftables
systemctl status nftables

enable --now aktiviert den Service für den nächsten Boot und startet ihn sofort. systemctl status zeigt anschließend, ob alles geladen ist und ob die Service-Datei auf den richtigen Konfigurationspfad zeigt. Auf manchen Distros — insbesondere Ubuntu — ist der Service installiert, aber nicht automatisch aktiviert; ohne enable werden die Regeln nach jedem Reboot nicht geladen, der Server steht ungeschützt da. Diesen Schritt nicht überspringen.

Eine alternative Methode: den aktuellen Live-Zustand in eine Datei schreiben, sodass beim nächsten Reload genau dieser Stand wiederhergestellt wird:

sudo nft list ruleset > /etc/nftables.conf

Praktisch, wenn man interaktiv Regeln getestet hat (sudo nft add rule ...) und den finalen Zustand persistieren möchte — aber nicht der empfohlene Workflow. Die exportierte Datei enthält den Live-Stand mit allen aktuellen Counter-Werten und ist nicht so gut lesbar wie eine handgepflegte Konfiguration. Sauberer: die /etc/nftables.conf als versionierte Quelle der Wahrheit pflegen, Änderungen dort eintragen und mit nft -f /etc/nftables.conf neu laden. So ist die Datei immer das verbindliche Dokument, und der Live-Stand ist eine Folge daraus — nicht umgekehrt.

firewalld als Alternative auf RHEL-Familie

Wer mit der RHEL-Familie arbeitet und kein Bedürfnis nach direktem nftables hat, kann firewalld als Wrapper nutzen — dort heißt das Konzept Zones:

sudo systemctl enable --now firewalld

# Aktuelle Zone und ihre Regeln zeigen
sudo firewall-cmd --list-all

# Service freigeben (über Service-Definitionen, nicht Portnummern)
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https

# Eigener Port
sudo firewall-cmd --permanent --add-port=47823/tcp

# Aktiv schalten
sudo firewall-cmd --reload

firewalld arbeitet im Hintergrund mit nftables — die Trennung ist nur in der Bedienoberfläche. Für einfache Server ist firewalld bequemer, für komplexe Konfigurationen lohnt der Schritt zu nftables direkt.

Sicherheits-Checkliste

• Genau ein Firewall-Frontend aktiv: ufw oder firewalld oder nftables direkt — nie mehrere parallel
• nftables.service per systemctl enable aktiviert, persistiert über Reboots
• Default-Policy für input und forward auf drop gesetzt
• SSH-Regel vor dem ersten Reload getestet; bei Port-Wechsel angepasst
• Connection-Tracking (ct state established,related accept) als zweite Regel — sonst antwortet niemand auf ausgehende Verbindungen
• nft -c -f /etc/nftables.conf vor jedem Laden — fängt Tippfehler ab, ohne den Live-Stand zu beschädigen
• Regelwerk in einer Datei versioniert, nicht über interaktive Befehle aufgebaut
• Bei IPv6: ip6 nexthdr icmpv6 accept nicht vergessen, sonst bricht IPv6 sehr subtil

Verwandte Artikel

• Firewall-Grundausstattung mit ufw — die einfachere Alternative für Debian/Ubuntu
• SSH-Hardening — fail2ban + nftables ergänzen sich bei SSH-Schutz
• Eigenen Benutzer anlegen und sudo einrichten — sudo wird beim nftables-Editieren ständig gebraucht
• Linux-Doku: systemd-Übersicht — systemctl status nftables zur Diagnose

Externe Quellen

• nftables Wiki — offizielle Doku mit Beispielen
• nft Manpage — vollständige Befehlsreferenz
• Red Hat: Getting started with nftables — RHEL-fokussierte Einführung
• iptables-to-nftables Migration Guide — wenn ein Altsystem auf nftables überführt wird