Ein minimales nftables-Regelwerk für einen einzelnen Server

Ziel

Nur die Ports offenlegen, die ein Server bedienen soll, für IPv4 und IPv6 gleichermassen, in einem Regelwerk, das auf einen Bildschirm passt und sich sicher neu laden lässt.

Voraussetzungen

Root-Zugriff, das Binary nft und eine Liste der Ports, die der Host bedient.

Schritte

1. /etc/nftables.conf nach der Struktur des Server-Beispiels aus dem nftables-Wiki schreiben: flush ruleset, dann eine einzige table inet filter, damit ein einziges Regelwerk beide Adressfamilien abdeckt.
2. chain input { type filter hook input priority 0; policy drop; ... } definieren und der Reihe nach: ct state vmap { established : accept, related : accept, invalid : drop }, iifname lo accept, meta l4proto { icmp, ipv6-icmp } accept (ICMPv6 trägt die Neighbour Discovery; sie zu blockieren bricht IPv6, weshalb das Wiki-Beispiel zumindest die nd-*-Typen zulässt), dann tcp dport { 22, 80, 443 } accept.
3. chain forward { type filter hook forward priority 0; policy drop; } nur hinzufügen, wenn der Host weder routet noch Container betreibt: nft(8) besagt, dass ein Paket nur akzeptiert wird, wenn keine Basis-Chain es verwirft, sodass eine verwerfende Forward-Chain auch den Bridge-Verkehr einer Container-Laufzeit blockiert. Output undefiniert lassen, was accept bedeutet.
4. Während der Fehlersuche die Input-Chain mit log prefix "nft-drop " counter drop beenden.
5. Syntax prüfen, ohne sie anzuwenden: nft -c -f /etc/nftables.conf.
6. Vor dem Laden einen Rollback scharf schalten: systemd-run --on-active=120 nft flush ruleset plant einen Flush in zwei Minuten (--on-active ist in systemd-run(1) dokumentiert). Mit nft -f /etc/nftables.conf laden, bestätigen, dass eine neue SSH-Sitzung funktioniert, und dann den transienten Timer stoppen, dessen Unit-Namen systemd-run ausgegeben hat.
7. Den laufenden Zustand mit nft list ruleset prüfen; nft(8) besagt, dass diese Ausgabe als Eingabe für nft -f verwendet werden kann, sodass sie zugleich als Backup dient.
8. Den nftables-Dienst der Distribution aktivieren, damit die Datei beim Booten geladen wird.

Erwartetes Ergebnis

nft list ruleset zeigt genau die beabsichtigten Chains; ein Portscan von aussen zeigt nur die aufgeführten Ports; ein Neuladen mit nft -f tauscht das alte Regelwerk in einer einzigen Operation gegen das neue aus (der „atomare Regelersatz“ des Wikis), sodass es keinen Moment ohne Regeln gibt, und bestehende Verbindungen weiterhin auf ct state established passen.

Grenzen und Prüfbasis

Das Regelwerk weiss nicht, welcher Prozess an einem Port lauscht. Container-Laufzeiten fügen eigene Tabellen und Prioritäten ein; bei Bridge-Networking wird Verkehr zu veröffentlichten Container-Ports typischerweise übersetzt und weitergeleitet statt lokal zugestellt, sodass er diese Input-Chain umgeht und stattdessen auf den Forward-Hook trifft. Vor dem Hinzufügen von Forward-Regeln die Firewall-Dokumentation der Laufzeit konsultieren und altes iptables nicht mit nft mischen. Die Syntax folgt dem zitierten Wiki und Handbuch; es wird keine Durchsatz- oder Sicherheitsmessung behauptet.

Rollback zum vorherigen Regelwerk, nicht ins Leere

Ein geplantes flush ruleset lässt den Host ohne jegliche Regeln zurück und entfernt Tabellen, auf die andere Software angewiesen ist. Stattdessen zuerst den aktuellen Zustand sichern und eine Wiederherstellung scharf schalten:

nft list ruleset > /root/nft-before.conf
systemd-run --on-active=120 nft -f /root/nft-before.conf
nft -f /etc/nftables.conf

Eine neue SSH-Sitzung bestätigen, dann den transienten Timer stoppen. Aus demselben Grund flush ruleset in der Konfigurationsdatei auf Hosts mit einer Container-Laufzeit vermeiden: Es löscht die ip nat- und ip filter-Tabellen der Laufzeit, und veröffentlichte Ports funktionieren nicht mehr, bis die Laufzeit neu startet. Nur die eigene Tabelle flushen (table inet filter {} gefolgt von flush table inet filter), was für diese Tabelle weiterhin atomar ist.