VPN-Anmeldewarnungen sind keine Einbruchswarnungen: Beobachte die Sitzung

Eine VPN-Warnung, die bei einem neuen Land auslöst, wirkt abschließend, und meistens ist sie es nicht. Die Authentifizierung sagt, dass ein Versuch angenommen wurde; die Sitzung sagt, welche Verbindung ihn trug; Ressourcendatensätze sagen, was innerhalb dieser Verbindung geschah. Jede beantwortet eine andere Frage. Eine Regel, die alle drei zusammenwirft, erzeugt dreißig Tickets am Montag und übersieht den echten Fall am Freitag.

Eine ausländische Adresse ist eine Frage, keine Antwort

Reisen, Mobilfunkanbieter mit Ausgang in einem anderen Land, ein Unternehmens-Webproxy und ein neu zugewiesener Carrier-Grade-NAT-Pool verschieben die scheinbare Quelle, ohne den Angreifer zu verschieben. Der Anmeldedatensatz spiegelt wider, wo die Verbindung ins Netz eintrat, nicht wer das Gerät hielt.

Der umgekehrte Fehler ist schlimmer, weil er leise ist. Ein gestohlenes Passwort, das aus der Stadt des Nutzers selbst verwendet wird, erzeugt eine Anmeldung, die bei der Geografieprüfung zu jeder früheren Anmeldung passt.

Geografie als Urteil zu behandeln hat messbare Kosten. Reiselaptops erzeugen einen steten Strom von Prüfungen, Prüfer lernen, sie ohne Lesen zu schließen, und die Gewohnheit bleibt, bis ein echter Fall in derselben Warteschlange landet.

Drei Datensatztypen beantworten drei verschiedene Fragen

Beginne bei dem, was die eingesetzten Produkte tatsächlich ausgeben, nicht bei dem, was eine Produktbroschüre andeutet. Die Authentifizierungsentscheidung nennt die behauptete Identität, die Methode und das Ergebnis. Der Sitzungslebenszyklus nennt die Verbindung, das Gateway und die zugewiesene Adresse, von Beginn bis Stopp.

Eine leere Zelle ist eine Erfassungslücke, kein Freispruch. Kommen Ressourcenereignisse nie an, bedeutet das Fehlen eines verdächtigen Lesezugriffs, dass die Pipeline nichts zu melden hat, und ein stilles Dashboard beschreibt die Pipeline statt das Netz. Schreibe auf, welche Datensätze der Einsatz tatsächlich erzeugt, bevor du eine Regel versprichst, die von ihnen abhängt, und benenne den Verantwortlichen für jeden fehlenden Feed.

Abrechnungsdetails sind der Punkt, an dem Sitzungen prüfbar werden. RADIUS-Abrechnung nach RFC 2866 trägt Start-, Stopp- und Zwischenaktualisierungen, die an eine Sitzungskennung gebunden sind, sodass eine Sitzung mit Start und ohne Stopp eine Lücke ist, die du benennen kannst, statt eines Rätsels.

Verknüpfe über die Sitzung, nicht über den Benutzernamen

Ein Konto hält rechtmäßig mehrere Sitzungen gleichzeitig: ein Laptop, ein Telefon, eine über Nacht verbunden gelassene Labormaschine. Jedes Ereignis für diesen Benutzernamen zu verbinden verschmilzt drei Geräte zu einer Geschichte und liest die Kombination dann als Kompromittierung. Zugewiesene Adressen werden ebenfalls wiederverwendet, sodass eine Verknüpfung, die nach dem Sitzungsende weiterhin eine Adresse trifft, das Gerät des letzten Monats in den heutigen Vorfall zieht. Halte den Sitzungsschlüssel neben der Adresse und begrenze die Übereinstimmung auf das Zeitfenster, das die Sitzung tatsächlich abdeckte.

Wo eine Übersetzung die ursprüngliche Quelle entfernt, bevor ein Dienst sie sieht, nutze die Identität, die an dieser Grenze überlebt, etwa ein Mutual-TLS-Subjekt oder eine Single-Sign-on-Aussage. Eine Eins-zu-eins-Zuordnung zwischen einer Adresse und einer Person zu erfinden ist derselbe Fehler mit zusätzlichen Schritten.

Eine Warnung ohne Verantwortlichen ist ein Dashboard

Jede Regel braucht eine Bedingung, die harmlosen Erklärungen, die sie erzeugen, die zu holenden Belege und die Person, die handelt. Eine wiederholte verweigerte Verwaltungsoperation, ein Schwall fehlgeschlagener Passwörter und ein stummer Collector sind drei verschiedene Vorfälle mit drei verschiedenen Uhren.

Benachrichtigung ist keine Eindämmung, und eine Verteilerliste beschränkt nichts. Eine laufende Sitzung zu ändern erfordert die Komponente, die das kann, sei es das Gateway, das die Verbindung trennt, oder der Identitätsanbieter, der die Sitzung widerruft. Veraltete Feeds und fehlende Stopp-Datensätze gehören ebenfalls in den Regeltext, denn ein Collector, der einen Tag lang nichts gesendet hat, sieht vom Dashboard aus genau wie ein stilles Netz aus. Der Unterschied ist nur in der Pipeline selbst sichtbar.

Prüfe den Erfassungspfad, bevor du einer stillen Woche traust

Beweise die Pipeline von Ende zu Ende, bevor du eine einzige Regel abstimmst. Die folgenden Befehle bestätigen, dass die Listener für Authentifizierung und Abrechnung laufen, dass ein Testnachweis aus dem richtigen Grund abgelehnt wird und dass Sitzungsereignisse weiterhin eintreffen:

ss -uanp | grep -E ':(1812|1813)\b'
radtest alice 'not-the-password' 127.0.0.1 0 testing123
journalctl -u openvpn-server@server --since '-30 min' | grep -c 'Peer Connection Initiated'
timedatectl | grep -E 'System clock|synchronized'

Ein Access-Reject aus dem Test beweist, dass die Anfrage den Server erreichte und das gemeinsame Geheimnis passte, und genau diesen Teil überspringen die Leute. Ein Timeout zeigt stattdessen auf das Geheimnis, den Listener oder einen Filter davor, und jede Warnung weiter unten ist nicht überprüfbar, bis das behoben ist.

Der Uhrzustand zählt, weil Korrelationsfenster Übereinstimmung voraussetzen. Ein Gateway, das Minuten daneben liegt, lässt eine sonst saubere Sitzungsverknüpfung unmöglich erscheinen, und Prüfer kompensieren, indem sie das Fenster weiten, bis die Verknüpfung nicht mehr unterscheidet. Prüfe den Versatz, bevor du die Regel bearbeitest.

Führe dann eine Regel in einem harmlosen Test aus: erzeuge eine Anmeldung von einer unerwarteten Adresse, bestätige, dass die Warnung auslöst, bestätige, dass der Reagierende die Sitzung und ihre Ressourcenereignisse abrufen kann, und bestätige, dass das Ticket die Sitzungskennung trägt. Eine Regel, die eine zusammenhängende Geschichte erzeugt, besteht. Eine Regel, die einen Haufen Logzeilen erzeugt, ist immer noch ein Dashboard. Halte das Ergebnis neben der Regel fest, damit die nächste Prüfung mit Belegen statt mit Bauchgefühl beginnt.