Snort am VPN-Rand: wo die Pakete sichtbar sind

Verfolgen Sie eine einzelne Anfrage von einem entfernten Laptop, und sie überquert mehrere Grenzen, bevor irgendetwas sie prüfen kann. Der äußere Tunnel endet im VPN-Prozess, das innere Paket erscheint auf einer Schnittstelle, und die HTTPS-Sitzung im Inneren führt weiter zur Anwendung. Ein Prüfwerkzeug sieht nur, was an dem Punkt sichtbar ist, an dem die Pakete es erreichen. Installieren Sie eines, ohne diesen Punkt zu bestimmen, und die Protokolle beschreiben die falsche Ebene.

Ein Paket überquert mehrere Grenzen

Vor der VPN-Terminierung sieht der Beobachter eine äußere Verbindung, typischerweise zum VPN-Port, mit Adressen und Größen, aber ohne innere Struktur. Nach der Terminierung sind die inneren Adressen, Ports und Protokolle an dem Verarbeitungspunkt verfügbar, der sie übergibt. Das eigene TLS der Anwendung bleibt verschlüsselt, sofern kein separates Design es terminiert. Das sind drei Sichtbarkeitsebenen, und ein Paketname sagt Ihnen nicht, welche Sie gekauft haben.

Zeichnen Sie den Pfad mit markierten Grenzen und platzieren Sie den Sensor dann auf der Linie, auf der die Frage beantwortet werden kann, denn der Ort ist Teil der Antwort. Eine Grenze, die Sie nicht benennen können, ist eine Grenze, die Sie nicht testen können.

Sehen Sie, was an jedem Punkt lesbar ist

Prüfen Sie die Schnittstelle und eine kurze Aufzeichnung, bevor Sie einer Beschreibung der Architektur vertrauen.

ip -br link
tcpdump -ni tun0 -c 10 'tcp port 443'

Die Linkliste zeigt die vorhandenen Tunnel- und physischen Schnittstellen, und die Aufzeichnung zeigt genau, was ein dort angeschlossener Sensor empfangen würde. Wenn sie innere Adressen, aber keine HTTP-Anfragezeilen zeigt, befinden Sie sich nach der VPN-Terminierung und noch außerhalb des TLS der Anwendung. Das ist der normale Ort für Netzwerkerkennung und der falsche Ort für Inhaltsprüfung. Wiederholen Sie die Aufzeichnung auf der äußeren Schnittstelle, um zu vergleichen, was die andere Grenze offenlegt.

Passive Erkennung kann nicht allein blockieren

Die Inspektionsdokumentation von Snort trennt passive Beobachtung vom Inline-Betrieb. Der passive Modus kann vor Verkehr warnen, ohne ihn auf diesem Pfad zu stoppen.

snort -T -c /etc/snort/snort.lua

Der Testmodus validiert die Konfiguration, ohne den Sensor auszuführen, was der richtige erste Schritt vor jeder Bereitstellung ist. Inline-Betrieb erfordert eine kompatible Paketerfassung und eine passende Durchsetzungskonfiguration, nicht nur ein zusätzliches Flag. Ein Protokolleintrag ist daher kein Beweis dafür, dass eine Anfrage verhindert wurde, und ein Prozess, der mit einer inline-artigen Option gestartet wurde, beweist nicht, dass der tatsächliche weitergeleitete Fluss durch ihn läuft. Bestätigen Sie, wo die Implementierung die Pakete tatsächlich übergibt.

Wählen Sie den Durchsetzungsmodus vor der Bereitstellung

Entscheiden Sie, ob die Anforderung Sichtbarkeit oder Verhinderung ist, denn beide haben unterschiedliches Fehlerverhalten. Ein passiver Sensor, der ausfällt, lässt den Verkehr weiterlaufen und erzeugt eine Überwachungslücke; ein Inline-Gerät, das ausfällt, kann Verkehr durchlassen oder stoppen, und diese Wahl muss bewusst getroffen werden. Einigen Sie sich auf einen erlaubten Fluss, einen Fluss, der abgelehnt werden muss, und das Verhalten, das Sie bei einem Sensorausfall wünschen. Halten Sie die Verwaltungswiederherstellung getrennt vom geprüften Pfad, damit ein Fehler im Sensor nicht auch Ihren Zugang entfernt.

Zeichnen Sie dann den sichtbaren Verkehr, den Verarbeitungspunkt und das Durchsetzungsverhalten auf. Diese drei Fakten, nicht das installierte Paket, beschreiben, was die Bereitstellung tatsächlich tut.