VPN-påloggingsvarsler: hvilken hendelse bør egentlig utløse dem?
Vellykket autentisering, en etablert tunnel og en RADIUS accounting Start er tre forskjellige påstander. Velg den mottakeren din kan handle på, og korreler deretter.
Vellykket autentisering, en etablert tunnel og en RADIUS accounting Start er tre forskjellige påstander, og en påloggings-e-post betyr først noe når du velger én av dem. De fleste design for VPN-varsler blander alle tre og lager en innboks ingen stoler på. Beslutningen avhenger av hvem som leser varselet og hva de kan gjøre de neste fem minuttene. Går det galt, blir varselet støy som skjuler den ene hendelsen du trengte.
Tre spørsmål avgjør utløseren
Spør hvem som mottar det, hva de vil gjøre og hvor raskt handlingen må skje. Et sikkerhetsteam som overvåker misbruk av påloggingsinformasjon vil ha et mønster med feil og deretter suksess fra én konto innen få minutter. Et driftsteam som overvåker kapasitet vil ha sesjonsvarighet og årsaker til frakobling, ikke pålogginger. En helpdesk vil ha sesjonens identitet for å kunne matche en sak.
Disse svarene peker på ulike hendelser, og ingen enkelt regel tilfredsstiller alle tre. Hvis mottakerens handling er «ring brukeren», er autentisering nok. Hvis handlingen er «frigjør en lisens» eller «bekreft at tunnelen bar trafikk», duger bare etablering eller accounting Start. Hvis handlingen er «fakturer tiden», trenger du Stop-poster i stedet for en pålogging.
Skriv svaret som én setning før du konfigurerer noe. «Denne e-posten forteller vaktende ingeniør at konto X åpnet en tunnel fra nettverk Y på tidspunkt Z, slik at de kan sjekke om vedlikeholdsvinduet ble brukt.» Hvis du ikke kan fylle hvert felt, er utløseren ikke valgt ennå.
Tilpass hendelsen til påstanden du fremsetter
| 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 avhengighet: hver rad er bare pålitelig hvis gatewayen sender den ut pålitelig og innsamleren din beholder feltet du trenger. Les hendelsesdefinisjonen for nøyaktig den versjonen du kjører, fordi navnet «sesjon etablert» endres mellom versjoner, og betydningen endres oftere enn navnet. Når en definisjon er vag, be om en sesjonsopptak i stedet for å gjette fra etiketten.
Å behandle en Access-Accept som fullføringen av alt som følger, er den vanligste feilen. Det er en dom over påloggingsinformasjon, ikke en sesjon. Speilfeilen er å lese en policytreff som bevis på autorisasjon, når en regel kan treffe og neste steg fortsatt kan feile.
Én sesjon, én varsling
Én konto, flere enheter, gjentatte sendinger og gjenoppkoblinger: én e-post per hendelse vil være feil i begge retninger, duplisere én sesjon mens den deler en annen. Nøkle varselet på gatewayen pluss en sesjons-ID, og behandle kontonavnet som et attributt i stedet for nøkkelen. En bruker med laptop og telefon kan ha to tunneler samtidig, og begge fortjener sin egen linje.
Gjensendte regnskapsposter er normale, så fjern duplikater på sesjons-ID og tidsstempel før du gjengir meldingen. Påfølgende sesjoner fra samme enhet bør holdes atskilt, og en gjenoppkobling i et vedlikeholdsvindu bør forbli synlig i stedet for å falle sammen med den forrige. Hvis innsamleren din skriver om tidsstempler ved inntak, fjern duplikater på feltene i den opprinnelige posten, ikke de lagrede.
En manglende Stop-post er usikkerhet, ikke en permanent sesjon. Gateway-omstarter, innsamlerutfall og UDP-tap etterlater alle hull, så varselet trenger en avstemmingsvei som spør den levende sesjonstabellen før noen konkluderer med at en tunnel fortsatt er oppe.
Hold revisjon og varsling atskilt
Revisjonsstrømmen og varselstrømmen har forskjellige oppgaver. Behold råpostene, inkludert konto, gateway, sesjons-ID, tidsstempler og avslutningsårsak, selv når rutine-e-poster grupperes, undertrykkes eller sendes til en liten vaktliste. En alvorlighetsterskel er et leveringsfilter, ikke et valg av livssyklushendelsen du mente å kunngjøre.
Send den minimale konteksten mottakeren trenger for å finne den beskyttede posten. Kontonavn, interne adresser og sesjonsdetaljer er sensitive, og en e-post som videresendes godt, er en e-post som lekker godt.
Bevis det deretter ende til ende. Kjør en vanlig pålogging og utlogging, en gjenoppkobling, to samtidige sesjoner og en tvungen leveringsfeil, og spor én hendelse fra gatewayen gjennom innsamleren til den leverte meldingen. Hvis e-posten kommer uten sesjons-ID, er kontrakten ufullstendig. Hvis to e-poster beskriver én sesjon, er korrelasjonen brutt. Ingen av problemene vises når det eneste du tester er at e-postlevering fungerer.