VPN-inloggningslarm: vilken händelse bör egentligen utlösa dem?
Lyckad autentisering, en upprättad tunnel och en RADIUS accounting Start är tre olika påståenden. Välj den som din mottagare kan agera på och korrelera dem sedan.
Lyckad autentisering, en upprättad tunnel och en RADIUS accounting Start är tre olika påståenden, och ett inloggningsmejl betyder något först när du väljer ett av dem. De flesta larmdesigner för VPN blandar alla tre och skapar en inkorg som ingen litar på. Beslutet hänger på vem som läser larmet och vad den personen kan göra under de närmaste fem minuterna. Går det fel blir larmet brus som döljer just den händelse du behövde.
Tre frågor avgör utlösaren
Fråga vem som tar emot det, vad den personen ska göra och hur snabbt åtgärden måste ske. Ett säkerhetsteam som bevakar missbruk av inloggningsuppgifter vill se ett mönster av misslyckande och sedan framgång från ett konto inom några minuter. Ett driftsteam som bevakar kapacitet vill ha sessionslängd och orsaker till frånkoppling, inte inloggningar. En helpdesk vill ha sessionens identitet för att kunna matcha ett ärende.
De svaren pekar på olika händelser, och ingen enskild regel uppfyller alla tre. Om mottagarens åtgärd är ”ring användaren” räcker autentisering. Om åtgärden är ”frigör en licens” eller ”verifiera att tunneln bar trafik” fungerar bara upprättandet eller accounting Start. Om åtgärden är ”fakturera tiden” behöver du Stop-poster i stället för en inloggning.
Skriv svaret som en enda mening innan du konfigurerar något. ”Det här mejlet talar om för jourhavande ingenjör att kontot X öppnade en tunnel från nätverket Y vid tidpunkten Z, så att hen kan kontrollera om underhållsfönstret användes.” Om du inte kan fylla varje fält är utlösaren inte vald än.
Anpassa händelsen till det påstående du gör
| 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 döljer ett beroende: varje rad är bara pålitlig om gatewayen skickar den pålitligt och din insamlare behåller fältet du behöver. Läs händelsedefinitionen för exakt den version du kör, eftersom namnet ”session upprättad” ändras mellan versioner och betydelsen ändras oftare än namnet. När en definition är vag, begär en sessionsinspelning i stället för att gissa utifrån etiketten.
Att behandla en Access-Accept som slutförandet av allt som följer är det vanligaste misstaget. Det är en dom om inloggningsuppgifter, inte en session. Spegelmisstaget är att läsa en policyträff som bevis på auktorisering, när en regel kan matcha och nästa steg ändå kan misslyckas.
En session, ett meddelande
Ett konto, flera enheter, omsändningar och återanslutningar: ett mejl per händelse blir fel åt båda hållen, det duplicerar en session samtidigt som det delar en annan. Nyckla meddelandet på gatewayen plus en sessionsidentifierare, och behandla kontonamnet som ett attribut i stället för som nyckeln. En användare med laptop och telefon kan ha två tunnlar samtidigt, och båda förtjänar sin egen rad.
Omsända redovisningsposter är normala, så ta bort dubbletter på sessions-id och tidsstämpel innan meddelandet renderas. På varandra följande sessioner från samma enhet bör hållas åtskilda, och en återanslutning under ett underhållsfönster bör förbli synlig i stället för att smälta samman med den föregående. Om din insamlare skriver om tidsstämplar vid intag, ta bort dubbletter på den ursprungliga postens fält, inte på de lagrade.
En saknad Stop-post är osäkerhet, inte en permanent session. Omstarter av gatewayen, insamlarbortfall och UDP-förlust lämnar alla luckor, så larmet behöver en avstämningsväg som frågar den levande sessionstabellen innan någon drar slutsatsen att en tunnel fortfarande är uppe.
Håll revision och meddelanden åtskilda
Revisionsströmmen och larmströmmen har olika uppgifter. Behåll råposterna, inklusive konto, gateway, sessions-id, tidsstämplar och avslutningsorsak, även när rutinmejl grupperas, undertrycks eller skickas till en liten jourlista. En allvarlighetsgräns är ett leveransfilter, inte ett urval av den livscykelhändelse du ville annonsera.
Skicka det minimala sammanhang som mottagaren behöver för att hitta den skyddade posten. Kontonamn, interna adresser och sessionsdetaljer är känsliga, och ett mejl som vidarebefordras bra är ett mejl som läcker bra.
Bevisa det sedan från början till slut. Kör en vanlig in- och utloggning, en återanslutning, två samtidiga sessioner och ett påtvingat leveransfel, och spåra en händelse från gatewayen genom insamlaren till det levererade meddelandet. Om mejlet kommer utan sessions-id är avtalet ofullständigt. Om två mejl beskriver en session är korrelationen trasig. Inget av problemen visar sig när det enda du testar är att mejlleveransen fungerar.