Alerte de autentificare VPN: care eveniment ar trebui să le declanșeze de fapt?
Autentificarea reușită, un tunel stabilit și un RADIUS accounting Start sunt trei afirmații diferite. Alegeți-o pe cea pe care destinatarul poate acționa, apoi corelați-le.
Autentificarea reușită, un tunel stabilit și un RADIUS accounting Start sunt trei afirmații diferite, iar un e-mail de autentificare înseamnă ceva abia după ce alegeți una dintre ele. Majoritatea proiectelor de alerte VPN le amestecă pe toate trei și produc o căsuță de e-mail în care nimeni nu are încredere. Decizia depinde de cine citește alerta și ce poate face în următoarele cinci minute. Dacă greșiți, alerta devine zgomot care ascunde singurul eveniment de care aveați nevoie.
Trei întrebări decid declanșatorul
Întrebați cine o primește, ce va face și cât de repede trebuie să aibă loc acțiunea. O echipă de securitate care urmărește abuzul de acreditări vrea un model de eșec și apoi succes de la un cont în câteva minute. O echipă de operațiuni care urmărește capacitatea vrea durata sesiunii și motivele deconectării, nu autentificările. Un helpdesk vrea identitatea sesiunii ca să o poată potrivi cu un tichet.
Acele răspunsuri indică evenimente diferite, iar nicio regulă unică nu le satisface pe toate trei. Dacă acțiunea destinatarului este «sună utilizatorul», autentificarea este suficientă. Dacă acțiunea este «eliberează o licență» sau «verifică dacă tunelul a transportat trafic», doar stabilirea sau accounting Start funcționează. Dacă acțiunea este «facturează timpul», aveți nevoie de înregistrări Stop, nu de o autentificare.
Scrieți răspunsul într-o singură propoziție înainte de a configura ceva. „Acest e-mail îi spune inginerului de gardă că contul X a deschis un tunel din rețeaua Y la momentul Z, ca să poată verifica dacă fereastra de mentenanță a fost folosită.” Dacă nu puteți completa fiecare câmp, declanșatorul nu este încă ales.
Potriviți evenimentul cu afirmația pe care o faceți
| 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 |
Tabelul ascunde o dependență: fiecare rând este de încredere doar dacă gateway-ul îl emite în mod fiabil și colectorul dumneavoastră păstrează câmpul de care aveți nevoie. Citiți definiția evenimentului pentru versiunea exactă pe care o rulați, pentru că numele „sesiune stabilită” se schimbă între versiuni, iar semnificația se schimbă mai des decât numele. Când o definiție este vagă, cereți o captură de sesiune în loc să ghiciți după etichetă.
A trata un Access-Accept ca finalizare a tot ce urmează este cea mai frecventă greșeală. Este un verdict despre acreditări, nu o sesiune. Greșeala în oglindă este să citiți o potrivire de politică drept dovadă de autorizare, când o regulă poate potrivi și pasul următor poate eșua oricum.
O sesiune, o notificare
Un cont, mai multe dispozitive, retransmisii și reconectări: un e-mail pe eveniment va fi greșit în ambele direcții, duplicând o sesiune în timp ce o desparte pe alta. Cheia notificării să fie gateway-ul plus un identificator de sesiune, iar numele contului să fie tratat ca atribut, nu ca cheie. Un utilizator cu laptop și telefon poate avea două tuneluri simultan, iar ambele merită propria linie.
Înregistrările contabile retransmise sunt normale, așa că eliminați duplicatele după id-ul sesiunii și marcajul de timp înainte de a reda mesajul. Sesiunile consecutive de pe același dispozitiv ar trebui să rămână separate, iar o reconectare în timpul unei ferestre de mentenanță ar trebui să rămână vizibilă în loc să se contopească cu cea anterioară. Dacă colectorul dumneavoastră rescrie marcajele de timp la ingestie, eliminați duplicatele după câmpurile înregistrării originale, nu după cele stocate.
O înregistrare Stop lipsă este incertitudine, nu o sesiune permanentă. Repornirile gateway-ului, căderile colectorului și pierderea UDP lasă goluri, așa că alerta are nevoie de o cale de reconciliere care să interogheze tabelul sesiunilor active înainte ca cineva să concluzioneze că un tunel este încă activ.
Țineți auditul și notificarea separate
Fluxul de audit și fluxul de alerte au sarcini diferite. Păstrați înregistrările brute, inclusiv cont, gateway, id de sesiune, marcaje de timp și motiv de terminare, chiar și când e-mailurile de rutină sunt grupate, suprimate sau trimise către o listă mică de gardă. Un prag de severitate este un filtru de livrare, nu o selecție a evenimentului din ciclul de viață pe care voiați să îl anunțați.
Trimiteți contextul minim de care destinatarul are nevoie pentru a găsi înregistrarea protejată. Numele conturilor, adresele interne și detaliile sesiunii sunt sensibile, iar un e-mail care se redirecționează bine este un e-mail care scurge bine.
Apoi demonstrați-o de la un capăt la altul. Rulați o autentificare și o deconectare normale, o reconectare, două sesiuni simultane și o eroare de livrare forțată, și urmăriți un eveniment de la gateway prin colector până la mesajul livrat. Dacă e-mailul ajunge fără un id de sesiune, contractul este incomplet. Dacă două e-mailuri descriu o sesiune, corelația este ruptă. Niciuna dintre probleme nu apare când singurul lucru pe care îl testați este că livrarea poștei funcționează.