Neue UFW-Regel, alte Verbindung: Der Established-Zustand gewinnt

Eine Deny-Regel hinzuzufügen und einen offenen Download weiterlaufen zu sehen, ist kein UFW-Fehler. Die Regel, die Sie angehängt haben, steht hinter Regeln, die den Fluss bereits akzeptiert haben, und eine früher aufgebaute Verbindung passt weiterhin auf sie. Die Korrektur bedeutet, an der richtigen Stelle einzufügen und zu verstehen, was die früheren Regeln versprechen. Die enge Variante dieser Änderung folgt.

Die Reihenfolge entscheidet, nicht die Existenz der Regel

UFW ist eine Oberfläche, die netfilter-Regeln in Stufen schreibt: einen Rahmenabschnitt, der vor den Benutzerregeln läuft, dann die Benutzerregeln selbst, dann einen Abschnitt, der nach ihnen läuft. Die mitgelieferten Vorregeln akzeptieren Traffic etablierter und verwandter Verbindungen, und diese Regeln werden ausgewertet, bevor irgendetwas greift, das Sie mit einem normalen allow oder deny hinzufügen. Die UFW-Befehlsreferenz dokumentiert die Einfügesyntax und die nummerierte Statusansicht, auf denen diese Änderung beruht.

Diese Reihenfolge erklärt die Überraschung. Ihre neue Regel ist real und steht in der richtigen Tabelle, aber sie ist nicht die erste Entscheidung, auf die das Paket trifft. Eine Verbindung, die bereits als etabliert verfolgt wird, erreicht sie nie.

Verwenden Sie für diese Aufgabe route-Regeln, weil das Paket durch das Gateway weitergeleitet und nicht an dessen eigene Dienste adressiert wird. Eine Input-Regel würde den falschen Traffic filtern und so aussehen, als täte sie nichts.

Oberhalb der pauschalen Erlaubnis einfügen

Zeigen Sie die Einfügung als Vorschau an, bevor Sie sie anwenden, und prüfen Sie, ob die Regel nicht bereits an anderer Stelle in der Liste steht. Eine identische Richtlinie zu duplizieren macht das spätere Entfernen mehrdeutig, und wer die falsche Kopie entfernt, merkt es wochenlang nicht.

sudo ufw --dry-run route insert 1 deny in on tun0 proto tcp from 10.88.0.55/32 to 192.0.2.88/32

Wenn die Vorschau genau eine Regel an der erwarteten Position zeigt, wenden Sie denselben Befehl ohne das dry-run-Flag an. Position 1 setzt sie über die breiteren Benutzerfreigaben, nicht über die zuvor besprochenen Rahmenregeln. Prüfen Sie, ob der Schnittstellenname zum Tunnelgerät auf diesem Gateway passt, denn eine Regel, die an eine nicht mehr vorhandene Schnittstelle gebunden ist, steht in der Liste und sieht korrekt aus, während sie auf nichts passt. Benennen Sie die Gerätereferenz vor dem Anwenden um, nicht nachdem der Test fehlgeschlagen ist.

In dieser Regel steht kein Zielport, sie lehnt also jeden TCP-Port an dieser Adresse ab und nicht nur HTTPS. Wenn die Absicht ein einzelner Dienst ist, nennen Sie den Port; eine Regel, die breiter als die Richtlinie ist, ist ein künftiger Vorfall, der auf seinen ersten Leser wartet.

Beschränken Sie die Quelle nur dann auf eine einzelne Adresse, wenn diese Adresse an die beabsichtigte Identität gebunden ist. Ein VPN-Pool mit dynamischer Zuweisung kann dieselbe Adresse morgen einem anderen Client geben, und die Ablehnung würde der Adresse folgen statt der Person.

Etablierte Flüsse überleben die neue Regel

Die Verbindungsverfolgung ist der Grund, warum die bestehende Sitzung weiterläuft. Sobald ein Fluss als etabliert verzeichnet ist, akzeptieren die Vorregeln seine Pakete, bevor Ihre Ablehnung überhaupt geprüft wird, und die Übertragung endet, als hätte sich nichts geändert. Ein Test mit einem Browser, der eine offene Verbindung wiederverwendet, sagt Ihnen daher nichts über die neue Richtlinie. Eine Ablehnung kann Minuten nach dem Rollout nutzlos wirken und für den nächsten Benutzer, der sich verbindet, völlig wirksam sein.

Wenn die Anforderung das Kappen laufenden Traffics einschließt, kann diese Benutzerregel-Änderung das nicht leisten. Das Zurückziehen verfolgten Zustands ist eine eigene Aktion mit eigenem Wirkungsradius und gehört dem Firewall-Eigentümer, nicht dem, der die Regel hinzugefügt hat. Alle Verbindungen auf einem Gateway zu leeren, damit eine Sitzung verschwindet, ist die Art von Korrektur, die einen zweiten Vorfall erzeugt.

Denken Sie auch an die Grenzen. Diese Regel sagt nichts über ICMP, UDP oder IPv6, ein erfolgreicher Ping ist also kein Beweis, dass die Ablehnung versagt hat. Eine einzelne IPv4-Adresse ist auch keine Website: Ein Name kann zu mehreren Adressen auflösen, und nur die von Ihnen genannte ist abgedeckt.

Mit einem frischen Fluss testen

Lesen Sie die nummerierten Benutzerregeln und die wirksame Rohansicht und öffnen Sie dann eine neue Verbindung vom ausgewählten Client:

sudo ufw status numbered
sudo ufw show raw
# from 10.88.0.55, a new TCP connection to 192.0.2.88 should fail

Die Rohansicht ist wichtig, weil status handgeschriebene Rahmenregeln auslässt und die Reihenfolge dadurch anders aussehen kann als das, was der Kernel durchsetzt. Vergleichen Sie beides, bevor Sie schließen, dass eine Regel an der falschen Stelle steht.

Prüfen Sie dann die beiden Kontrollen, die belegen, dass die Regel eng und nicht breit ist: Ein erlaubtes Ziel von demselben Client funktioniert weiterhin, und ein zweiter Client erreicht das abgelehnte Ziel weiterhin, wenn seine Richtlinie es zulässt. Eine Ablehnung, die beide Tests bricht, ist eine Richtlinienänderung, keine gezielte.

Wenn der Test vorbei ist, entfernen Sie nur die von Ihnen hinzugefügte Regel, indem Sie sie exakt wiederholen. Ist die Richtlinie dauerhaft, übergeben Sie sie mit der Client-Identität, dem Eigentümer des Ziels und einem Prüfdatum an den Firewall-Eigentümer, damit eine neu zugewiesene Tunneladresse keine veraltete Ablehnung hinterlässt.