Tutoriel Linux

Nftables unter Linux, überprüfen Sie die Regeln, bevor Sie einen Port öffnen

Débutant6 min de lecture

Ein Port scheint von außen geschlossen zu sein, dann fängt man an, die Anwendung oder den Router zu überprüfen. Bevor Sie etwas ändern, schauen Sie sich die tatsächlich von nftables geladenen Regeln an. Die Datei /etc/nftables.conf kann vom aktiven Zustand abweichen, und eine lokale Firewall erklärt nicht allein den gesamten Netzwerkpfad.

Diese Methode ermöglicht es, das Ruleset zu lesen, die Kette zu identifizieren, die den eingehenden Verkehr behandelt, und eine Änderung zu testen, ohne eine SSH-Session zu verlieren. Halten Sie eine zweite Verbindung offen, wenn Sie remote arbeiten.

Beginnen Sie mit dem Lesen der geladenen Firewall

Der folgende Befehl ändert nichts. Er zeigt die Tabellen, Ketten, Regeln und eventuelle Zähler, die derzeit im Kernel vorhanden sind:

sudo nft list ruleset

Wenn die Ausgabe lang ist, listen Sie zuerst die Tabellen auf und konzentrieren Sie sich dann auf die, die Sie interessiert:

sudo nft list tables
sudo nft list table inet filter

Die Familie inet kann sowohl IPv4- als auch IPv6-Regeln enthalten. Eine Tabelle kann auch zu ip, ip6, bridge oder netdev gehören. Ersetzen Sie ein IPv6-Regel nicht einfach durch eine IPv4-Regel in der Annahme, dass das Problem damit gelöst ist.

In einer Filtertabelle suchen Sie besonders nach einer Basis-Kette mit type filter hook input. Diese empfängt den Verkehr, der für die Maschine bestimmt ist. Ihre Zeile policy drop bedeutet, dass Pakete, die keine accept-Regel finden, abgelehnt werden.

Um die Regel-IDs zu sehen, die nützlich sind, falls Sie später eine bestimmte Regel entfernen müssen, fügen Sie -a hinzu:

sudo nft -a list chain inet filter input

Verwechseln Sie nicht input, forward und output. Ein Server, der eine SSH-Verbindung empfängt, verwendet normalerweise input. Eine Maschine, die Verkehr an einen anderen Host routet, kann das Paket in forward blockieren. Eine Anwendung, die ins Internet sendet, läuft über output.

Überprüfen Sie den Port und die Reihenfolge der Regeln

Die Regeln einer Kette werden in der Reihenfolge bewertet. Eine Ablehnungsregel, die vor der Erlaubnis des Ports platziert wird, hat Priorität. Suchen Sie nach dem Protokoll, dem Port und dem Verbindungsstatus:

sudo nft list chain inet filter input
sudo ss -lntup

Für SSH sieht eine erwartete Regel oft so aus: tcp dport 22 accept. Der Port kann anders sein, wenn der Daemon woanders lauscht. Die Ausgabe von ss -lntup zeigt, ob ein Programm tatsächlich auf dem erwarteten Port und der Adresse hört. Eine offene Firewall macht einen gestoppten Dienst nicht verfügbar.

Beachten Sie auch die Regeln ct state established,related accept und das Loopback-Interface iif lo accept. Sie verhindern, dass Antworten auf bereits etablierte Verbindungen und lokale Austauschunterbrochen werden. Wenn das Ruleset Zähler enthält, vergleichen Sie diese vor und nach einem Verbindungstest, um herauszufinden, welche Regel den Verkehr sieht.

Eine Ablehnung kann außerhalb der Maschine liegen: Cloud-Sicherheitsgruppe, Router, NAT-Weiterleitung, VLAN, Unternehmensfirewall oder Dienst, der nur mit 127.0.0.1 verbunden ist. Testen Sie den Port von einem anderen Host aus mit nc -vz adresse_du_serveur 22 oder mit Ihrem SSH-Client. Überprüfen Sie auf dem Server, ob es lauscht mit ss, bevor Sie Änderungen an nftables vornehmen.

Identifizieren Sie die Regel, die wirklich blockiert

Eine Kette kann eine andere Kette mit jump oder goto aufrufen. Die Erlaubnis des Ports ist also nicht unbedingt in der zuerst angezeigten Kette sichtbar. Überprüfen Sie die Aufrufe von Ketten, benannten Mengen und Regeln, die ein Protokollierungssuffix haben. Eine Regel vom Typ counter drop oder reject, die vor dem Port platziert ist, erklärt oft das Ergebnis.

Sie können ein gezieltes Paket mit nft monitor trace verfolgen, aber dieser Befehl erzeugt viele Daten auf einer aktiven Maschine. Reservieren Sie es für ein kurzes Diagnosetool und filtern Sie den Verkehr nach Adresse oder Port in einer temporären Regel. Entfernen Sie dann diese Regel mit ihrem Handle, das von nft -a list ruleset angezeigt wird.

Überlassen Sie keine breite Trace- oder Protokollierungsregel auf einem exponierten Server. Dies kann die Protokolle füllen oder Rauschen in die Diagnose einfügen. Für eine erste Kontrolle sind die Zähler der Kette und ein Test von einem anderen Host aus oft ausreichend.

Das aktive Ruleset und die persistente Datei können abweichen

nft list ruleset liest den aktiven Zustand. Es sagt nichts darüber aus, welcher Dienst die Regeln geladen hat, noch welche Datei beim Neustart wiederaufnahme wird. Bei Debian und Ubuntu schauen Sie normalerweise in /etc/nftables.conf und den Status des Dienstes:

sudo systemctl status nftables
sudo systemctl is-enabled nftables
sudo grep -nE '^(table|include|flush)' /etc/nftables.conf

Bei einer Distribution, die firewalld, UFW, Docker oder ein Hosting-Tool verwendet, können mehrere Komponenten Regeln schreiben. Kopieren Sie kein Ruleset, das Sie in einem Tutorial gesehen haben, in /etc/nftables.conf, wenn bereits ein anderer Dienst es verwaltet. Identifizieren Sie zuerst den von Ihrer Maschine deklarierten Manager und sehen Sie sich die Regeln nach dessen Neuladung erneut an.

Regeln, die über die Kommandozeile hinzugefügt werden, verschwinden oft beim nächsten Neustart oder der nächsten Neuladung des Dienstes. Umgekehrt ändert sich nichts, wenn die persistente Datei nicht geladen wird. Das ist genau der Grund, warum Sie beide Seiten überprüfen sollten, bevor Sie zu dem Schluss kommen, dass ein Port offen ist.

Sichern Sie sich und testen Sie, bevor Sie eine Regel anwenden

Bewahren Sie den aktuellen Zustand vor jeder Änderung auf. Die Sicherungsdatei sollte nur für den Administrator lesbar bleiben:

sudo install -m 600 /dev/null /root/nftables-before-change.nft
sudo nft list ruleset | sudo tee /root/nftables-before-change.nft > /dev/null

Bereiten Sie dann die Änderung in einer temporären Datei vor. nft -c prüft die Syntax, ohne die Regeln zu laden:

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

Diese Überprüfung beweist nicht, dass das neue Ruleset Ihnen den Zugang gewährt. Halten Sie eine zweite SSH-Session verbunden, wenden Sie die Datei in der ersten an, und versuchen Sie dann, sich von einem anderen Terminal aus erneut zu verbinden. Wenn Sie den Zugang verlieren, ermöglicht die Sicherungssitzung die Wiederherstellung der Sicherung:

sudo nft -f /etc/nftables.conf
sudo nft list ruleset
# Im Falle eines Abbruchs oder einer fehlerhaften Regel:
sudo nft -f /root/nftables-before-change.nft

Vermeiden Sie es, flush ruleset allein auf einem entfernten Server auszuführen. Es entfernt alle aktuellen Regeln, bevor Sie die Ersatzdatei bestätigt haben. Laden Sie eine vollständige und geprüfte Datei und überprüfen Sie dann das aktive Ruleset sofort danach.

Kontrollen nach der Änderung

  • Starten Sie sudo nft list ruleset und überprüfen Sie, ob die erwartete Tabelle und Kette weiterhin vorhanden sind.
  • Testen Sie den Dienst von einem anderen Rechner aus mit dem tatsächlich verwendeten Port.
  • Überprüfen Sie sudo ss -lntup, wenn der Port nicht zugänglich bleibt.
  • Überprüfen Sie das Kernelprotokoll mit sudo journalctl -k -b, wenn Ihre Regeln abgelehnten Pakete protokollieren.
  • Nach einem Neustart überprüfen Sie, ob der Dienst nftables die persistente Datei Ihrer Distribution richtig lädt.

Für einfache Fälle ist der Artikel zu UFW unter Linux geeigneter. Wenn Sie die Verfügbarkeit eines Dienstes diagnostizieren müssen, bevor Sie die Firewall ändern, prüfen Sie auch die offenen Ports mit ss. Die Dokumentation nft(8) beschreibt die Familien, Ketten und die Option -c.

Tux inspiziert eine Netzwerkfirewall mit einer Lupe
Überprüfung der aktiven Regeln einer nftables-Firewall unter Linux.
sudo apt update && sudo apt upgrade