VPN-aanmeldwaarschuwingen: welke gebeurtenis moet ze eigenlijk activeren?
Geslaagde authenticatie, een opgezette tunnel en een RADIUS accounting Start zijn drie verschillende beweringen. Kies degene waarop uw ontvanger kan handelen en correleer ze daarna.
Geslaagde authenticatie, een opgezette tunnel en een RADIUS accounting Start zijn drie verschillende beweringen, en een aanmeldingsmail betekent pas iets als u er één van kiest. De meeste ontwerpen voor VPN-waarschuwingen mengen alle drie en produceren een inbox die niemand vertrouwt. De beslissing hangt af van wie de waarschuwing leest en wat diegene in de volgende vijf minuten kan doen. Gaat dat mis, dan wordt de waarschuwing ruis die juist de ene gebeurtenis verbergt die u nodig had.
Drie vragen bepalen de trigger
Vraag wie hem ontvangt, wat diegene gaat doen en hoe snel de actie moet plaatsvinden. Een beveiligingsteam dat misbruik van inloggegevens volgt, wil binnen enkele minuten een patroon van mislukking en daarna succes vanaf één account. Een operatieteam dat capaciteit volgt, wil sessieduur en redenen voor verbreking, geen aanmeldingen. Een helpdesk wil de sessie-identiteit om die aan een ticket te koppelen.
Die antwoorden wijzen naar verschillende gebeurtenissen, en geen enkele regel voldoet aan alle drie. Als de actie van de ontvanger «bel de gebruiker» is, volstaat authenticatie. Als de actie «geef een licentie vrij» of «controleer of de tunnel verkeer droeg» is, werken alleen opzet of accounting Start. Als de actie «factureer de tijd» is, hebt u Stop-records nodig in plaats van een aanmelding.
Schrijf het antwoord als één zin voordat u iets configureert. «Deze mail vertelt de dienstdoende ingenieur dat account X om tijd Z een tunnel vanuit netwerk Y heeft geopend, zodat hij kan controleren of het onderhoudsvenster is gebruikt.» Als u niet elk veld kunt vullen, is de trigger nog niet gekozen.
Laat de gebeurtenis passen bij de bewering die u doet
| 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 |
De tabel verbergt een afhankelijkheid: elke rij is alleen betrouwbaar als de gateway hem betrouwbaar uitzendt en uw collector het veld bewaart dat u nodig hebt. Lees de gebeurtenisdefinitie voor precies de versie die u draait, want de naam «sessie opgezet» verandert tussen versies en de betekenis verandert vaker dan de naam. Als een definitie vaag is, vraag dan om een sessie-opname in plaats van te gokken op basis van het label.
Een Access-Accept behandelen als de voltooiing van alles wat erna komt, is de meest voorkomende fout. Het is een oordeel over inloggegevens, geen sessie. De spiegelbeeldige fout is een beleidsmatch lezen als bewijs van autorisatie, terwijl een regel kan matchen en de volgende stap alsnog kan mislukken.
Eén sessie, één melding
Eén account, meerdere apparaten, hertransmissies en herverbindingen: één mail per gebeurtenis is in beide richtingen fout, dupliceert de ene sessie en splitst de andere. Maak de melding als sleutel op de gateway plus een sessie-identificatie, en behandel de accountnaam als attribuut in plaats van als sleutel. Een gebruiker met een laptop en een telefoon kan twee tunnels tegelijk hebben, en beide verdienen hun eigen regel.
Opnieuw verzonden boekhoudrecords zijn normaal, dus dedupliceer op de sessie-id en tijdstempel voordat u het bericht weergeeft. Opeenvolgende sessies vanaf hetzelfde apparaat moeten gescheiden blijven, en een herverbinding tijdens een onderhoudsvenster moet zichtbaar blijven in plaats van samen te vallen met de vorige. Als uw collector tijdstempels herschrijft bij inname, dedupliceer dan op de velden van het oorspronkelijke record, niet op de opgeslagen velden.
Een ontbrekend Stop-record is onzekerheid, geen permanente sessie. Herstarts van de gateway, uitval van de collector en UDP-verlies laten allemaal gaten, dus de waarschuwing heeft een verzoeningspad nodig dat de live sessietabel bevraagt voordat iemand concludeert dat een tunnel nog open is.
Houd audit en melding gescheiden
De audittrail en de waarschuwingsstroom hebben verschillende taken. Bewaar de ruwe records, inclusief account, gateway, sessie-id, tijdstempels en beëindigingsreden, ook wanneer routinemails worden gegroepeerd, onderdrukt of naar een kleine oproeplijst gestuurd. Een ernstgrens is een bezorgfilter, niet een selectie van de levenscyclusgebeurtenis die u wilde aankondigen.
Stuur de minimale context die de ontvanger nodig heeft om het beschermde record te vinden. Accountnamen, interne adressen en sessiedetails zijn gevoelig, en een mail die goed doorgestuurd wordt, is een mail die goed lekt.
Bewijs het daarna van begin tot eind. Voer een normale aanmelding en afmelding uit, een herverbinding, twee gelijktijdige sessies en een geforceerde bezorgfout, en volg één gebeurtenis van de gateway via de collector tot het bezorgde bericht. Als de mail aankomt zonder sessie-id, is het contract onvolledig. Als twee mails één sessie beschrijven, is de correlatie stuk. Geen van beide problemen verschijnt wanneer het enige dat u test is of mailbezorging werkt.