VPN-Anmeldewarnungen: Welches Ereignis sollte sie eigentlich auslösen?
Erfolgreiche Authentifizierung, ein aufgebauter Tunnel und ein RADIUS accounting Start sind drei verschiedene Aussagen. Wählen Sie die, auf die Ihr Empfänger reagieren kann, und korrelieren Sie dann.
Erfolgreiche Authentifizierung, ein aufgebauter Tunnel und ein RADIUS accounting Start sind drei verschiedene Aussagen, und eine Anmelde-E-Mail bedeutet erst etwas, wenn Sie sich für eine davon entscheiden. Die meisten Designs für VPN-Warnungen vermischen alle drei und erzeugen ein Postfach, dem niemand traut. Die Entscheidung hängt davon ab, wer die Warnung liest und was er in den nächsten fünf Minuten tun kann. Machen Sie das falsch, wird die Warnung zu Rauschen, das genau das eine Ereignis verbirgt, das Sie gebraucht hätten.
Drei Fragen entscheiden über den Auslöser
Fragen Sie, wer sie erhält, was er tun wird und wie schnell die Aktion erfolgen muss. Ein Sicherheitsteam, das auf Missbrauch von Zugangsdaten achtet, will ein Muster aus Fehlschlag und anschließendem Erfolg von einem Konto innerhalb von Minuten. Ein Betriebsteam, das die Kapazität beobachtet, will Sitzungsdauer und Trennungsgründe, keine Anmeldungen. Ein Helpdesk will die Sitzungsidentität, um sie einem Ticket zuordnen zu können.
Diese Antworten zeigen auf verschiedene Ereignisse, und keine einzelne Regel erfüllt alle drei. Wenn die Aktion des Empfängers „ruf den Nutzer an“ lautet, reicht die Authentifizierung. Wenn die Aktion „gib eine Lizenz frei“ oder „prüfe, ob der Tunnel Verkehr trug“ lautet, hilft nur der Aufbau oder der accounting Start. Wenn die Aktion „stell die Zeit in Rechnung“ lautet, brauchen Sie Stop-Datensätze statt einer Anmeldung.
Schreiben Sie die Antwort als einen Satz, bevor Sie irgendetwas konfigurieren. „Diese E-Mail sagt dem Bereitschaftsingenieur, dass Konto X um Zeit Z einen Tunnel aus Netzwerk Y geöffnet hat, damit er prüfen kann, ob das Wartungsfenster genutzt wurde.“ Wenn Sie nicht jeden Platz füllen können, ist der Auslöser noch nicht gewählt.
Passen Sie das Ereignis zu der Aussage, die Sie treffen
| Record | What it proves | What it leaves open |
|---|---|---|
| Rejected credentials | The attempt failed at the credential step | Whether it was a stale client or a real person |
| Access-Accept | Credentials passed for this attempt | Anything about tunnel state or policy |
| Policy match record | A rule matched the request | Whether later steps completed |
| Tunnel established | The gateway accepted a session | Whether traffic flowed or the user got an address |
| Accounting Start | User service began at the accounting layer | Whether the application behind it worked |
| Accounting Stop | That session was closed, with a reason field | Whether the reason is meaningful on your release |
Die Tabelle verbirgt eine Abhängigkeit: Jede Zeile ist nur dann vertrauenswürdig, wenn das Gateway sie zuverlässig ausgibt und Ihr Collector das benötigte Feld behält. Lesen Sie die Ereignisdefinition für genau die Version, die Sie betreiben, denn der Name „Sitzung aufgebaut“ ändert sich zwischen Versionen, und die Bedeutung ändert sich häufiger als der Name. Wenn eine Definition vage ist, fordern Sie eine Sitzungsaufzeichnung an, statt aus dem Etikett zu raten.
Ein Access-Accept als Abschluss von allem danach zu behandeln, ist der häufigste Fehler. Es ist ein Urteil über Zugangsdaten, keine Sitzung. Der spiegelbildliche Fehler ist, einen Richtlinientreffer als Beweis für Autorisierung zu lesen, obwohl eine Regel treffen kann und der nächste Schritt trotzdem scheitern kann.
Eine Sitzung, eine Benachrichtigung
Ein Konto, mehrere Geräte, Wiederholungen und Wiederverbindungen: eine E-Mail pro Ereignis wird in beide Richtungen falsch sein, die eine Sitzung duplizieren und die andere aufspalten. Legen Sie die Benachrichtigung auf das Gateway plus eine Sitzungskennung fest, und behandeln Sie den Kontonamen als Attribut statt als Schlüssel. Ein Nutzer mit Laptop und Telefon kann zwei Tunnel gleichzeitig halten, und beide verdienen ihre eigene Zeile.
Erneut übertragene Abrechnungsdatensätze sind normal, daher entfernen Sie Duplikate anhand der Sitzungs-ID und des Zeitstempels, bevor Sie die Nachricht rendern. Aufeinanderfolgende Sitzungen vom selben Gerät sollten getrennt bleiben, und eine Wiederverbindung während eines Wartungsfensters sollte sichtbar bleiben, statt in die vorherige zu fallen. Wenn Ihr Collector Zeitstempel bei der Aufnahme umschreibt, entfernen Sie Duplikate anhand der Felder des Originaldatensatzes, nicht der gespeicherten.
Ein fehlender Stop-Datensatz ist Ungewissheit, keine dauerhafte Sitzung. Gateway-Neustarts, Collector-Ausfälle und UDP-Verlust hinterlassen alle Lücken, daher braucht die Warnung einen Abgleichpfad, der die Live-Sitzungstabelle abfragt, bevor jemand schließt, dass ein Tunnel noch steht.
Halten Sie Audit und Benachrichtigung getrennt
Der Audit-Stream und der Warn-Stream haben unterschiedliche Aufgaben. Behalten Sie die Rohdatensätze, einschließlich Konto, Gateway, Sitzungs-ID, Zeitstempel und Beendigungsgrund, auch wenn Routine-E-Mails gruppiert, unterdrückt oder an eine kleine Bereitschaftsliste gesendet werden. Eine Schweregradschwelle ist ein Zustellfilter, keine Auswahl des Lebenszyklusereignisses, das Sie ankündigen wollten.
Senden Sie den minimalen Kontext, den der Empfänger braucht, um den geschützten Datensatz zu finden. Kontonamen, interne Adressen und Sitzungsdetails sind sensibel, und eine E-Mail, die sich gut weiterleiten lässt, ist eine E-Mail, die gut leckt.
Beweisen Sie es dann von Anfang bis Ende. Führen Sie eine normale Anmeldung und Abmeldung, eine Wiederverbindung, zwei gleichzeitige Sitzungen und einen erzwungenen Zustellfehler aus, und verfolgen Sie ein Ereignis vom Gateway über den Collector bis zur zugestellten Nachricht. Wenn die E-Mail ohne Sitzungs-ID ankommt, ist der Vertrag unvollständig. Wenn zwei E-Mails eine Sitzung beschreiben, ist die Korrelation kaputt. Keines der beiden Probleme zeigt sich, wenn das Einzige, was Sie testen, ist, dass die Mailzustellung funktioniert.