VPN-loginadvarsler: hvilken hændelse skal egentlig udløse dem?
Vellykket godkendelse, en etableret tunnel og en RADIUS accounting Start er tre forskellige påstande. Vælg den, din modtager kan handle på, og korrelér derefter.
Vellykket godkendelse, en etableret tunnel og en RADIUS accounting Start er tre forskellige påstande, og en login-e-mail betyder først noget, når du vælger én af dem. De fleste designs til VPN-advarsler blander alle tre og skaber en indbakke, som ingen stoler på. Beslutningen handler om, hvem der læser advarslen, og hvad de kan gøre i de næste fem minutter. Går det galt, bliver advarslen støj, der skjuler den ene hændelse, du havde brug for.
Tre spørgsmål afgør udløseren
Spørg, hvem der modtager den, hvad de vil gøre, og hvor hurtigt handlingen skal ske. Et sikkerhedsteam, der overvåger misbrug af legitimationsoplysninger, vil have et mønster med fejl og derefter succes fra én konto inden for få minutter. Et driftsteam, der overvåger kapacitet, vil have sessionsvarighed og årsager til afbrydelse, ikke logins. En helpdesk vil have sessionens identitet, så den kan matche en sag.
Disse svar peger på forskellige hændelser, og ingen enkelt regel opfylder alle tre. Hvis modtagerens handling er »ring til brugeren«, er godkendelse nok. Hvis handlingen er »frigiv en licens« eller »bekræft, at tunnelen bar trafik«, duer kun etablering eller accounting Start. Hvis handlingen er »fakturér tiden«, har du brug for Stop-poster i stedet for et login.
Skriv svaret som én sætning, før du konfigurerer noget. »Denne e-mail fortæller den vagthavende ingeniør, at konto X åbnede en tunnel fra netværk Y på tidspunkt Z, så de kan kontrollere, om vedligeholdelsesvinduet blev brugt.« Hvis du ikke kan udfylde hver plads, er udløseren ikke valgt endnu.
Tilpas hændelsen til den påstand, du fremsætter
| 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 |
Tabellen skjuler en afhængighed: hver række er kun troværdig, hvis gatewayen udsender den pålideligt, og din indsamler beholder det felt, du har brug for. Læs hændelsesdefinitionen for præcis den version, du kører, fordi navnet »session etableret« ændrer sig mellem versioner, og betydningen ændrer sig oftere end navnet. Når en definition er vag, så bed om en sessionsoptagelse i stedet for at gætte ud fra etiketten.
At behandle et Access-Accept som afslutningen på alt efter det er den mest almindelige fejl. Det er en dom over legitimationsoplysninger, ikke en session. Den spejlede fejl er at læse et policymatch som bevis på autorisation, når en regel kan matche, og det næste trin stadig kan fejle.
Én session, én notifikation
Én konto, flere enheder, gensendelser og genforbindelser: en e-mail per hændelse vil være forkert i begge retninger og duplikere den ene session, mens den splitter den anden. Nøgl notifikationen på gatewayen plus en session-id, og behandl kontonavnet som et attribut i stedet for nøglen. En bruger med en bærbar og en telefon kan have to tunneler på én gang, og begge fortjener deres egen linje.
Gensendte regnskabsposter er normale, så fjern dubletter på session-id og tidsstempel, før du gengiver meddelelsen. På hinanden følgende sessioner fra samme enhed bør forblive adskilte, og en genforbindelse i et vedligeholdelsesvindue bør forblive synlig i stedet for at kollapse i den foregående. Hvis din indsamler omskriver tidsstempler ved indtag, skal du fjerne dubletter på de oprindelige postfelter, ikke de lagrede.
En manglende Stop-post er usikkerhed, ikke en permanent session. Gateway-genstarter, indsamlerudfald og UDP-tab efterlader alle huller, så advarslen har brug for en afstemningsvej, der forespørger den levende sessionstabel, før nogen konkluderer, at en tunnel stadig er oppe.
Hold revision og notifikation adskilt
Revisionsstrømmen og advarselsstrømmen har forskellige opgaver. Behold de rå poster, inklusive konto, gateway, session-id, tidsstempler og afslutningsårsag, selv når rutine-e-mails grupperes, undertrykkes eller sendes til en lille vagtliste. En alvorlighedstærskel er et leveringsfilter, ikke en udvælgelse af den livscyklushændelse, du ville annoncere.
Send den minimale kontekst, modtageren har brug for for at finde den beskyttede post. Kontonavne, interne adresser og sessionsdetaljer er følsomme, og en e-mail, der videresendes godt, er en e-mail, der lækker godt.
Bevis det derefter fra ende til anden. Kør et normalt login og logout, en genforbindelse, to samtidige sessioner og en tvungen leveringsfejl, og spor én hændelse fra gatewayen gennem indsamleren til den leverede meddelelse. Hvis e-mailen ankommer uden et session-id, er kontrakten ufuldstændig. Hvis to e-mails beskriver én session, er korrelationen brudt. Ingen af problemerne viser sig, når det eneste, du tester, er, at maillevering virker.