VPN-bejelentkezési riasztások: melyik esemény indítsa el őket valójában?
A sikeres hitelesítés, a felépült alagút és a RADIUS accounting Start három különböző állítás. Válassza azt, amelyre a címzettje tud cselekedni, majd korrelálja őket.
A sikeres hitelesítés, a felépült alagút és a RADIUS accounting Start három különböző állítás, és egy bejelentkezési e-mail csak akkor jelent valamit, ha ezek közül választ egyet. A VPN-riasztások legtöbb terve mindhármat összekeveri, és olyan postafiókot hoz létre, amelyben senki nem bízik. A döntés azon múlik, ki olvassa a riasztást, és mit tehet a következő öt percben. Ha ezt elrontja, a riasztás zajjá válik, amely elrejti az egyetlen eseményt, amelyre szüksége volt.
Három kérdés dönti el az indítót
Kérdezze meg, ki kapja meg, mit fog tenni, és milyen gyorsan kell a műveletnek megtörténnie. A hitelesítő adatok visszaélését figyelő biztonsági csapat egy fiókból perceken belül sikertelen, majd sikeres mintát akar. A kapacitást figyelő üzemeltetési csapat a munkamenet hosszát és a bontás okait akarja, nem a bejelentkezéseket. Az ügyfélszolgálat a munkamenet identitását akarja, hogy jegyhez tudja párosítani.
Ezek a válaszok különböző eseményekre mutatnak, és egyetlen szabály sem elégíti ki mindhármat. Ha a címzett művelete „hívd fel a felhasználót”, a hitelesítés elég. Ha a művelet „szabadíts fel egy licencet” vagy „ellenőrizd, hogy az alagút vitt-e forgalmat”, csak a felépülés vagy az accounting Start felel meg. Ha a művelet „számlázd az időt”, Stop-rekordokra van szüksége bejelentkezés helyett.
Írja le a választ egyetlen mondatban, mielőtt bármit beállítana. „Ez az e-mail elmondja az ügyeletes mérnöknek, hogy az X fiók Z időpontban alagutat nyitott az Y hálózatból, hogy ellenőrizhesse, használták-e a karbantartási ablakot.” Ha nem tud minden helyet kitölteni, az indító még nincs kiválasztva.
Illessze az eseményt ahhoz az állításhoz, amelyet tesz
| 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 |
A táblázat függőséget rejt: minden sor csak akkor megbízható, ha az átjáró megbízhatóan kibocsátja, és a gyűjtője megtartja a szükséges mezőt. Olvassa el az esemény definícióját a pontosan futtatott verzióhoz, mert a „munkamenet felépült” név verziók között változik, és a jelentés gyakrabban változik, mint a név. Ha egy definíció homályos, kérjen munkamenet-rögzítést ahelyett, hogy a címkéből találgatna.
Az Access-Acceptet minden utána következő dolog befejezéseként kezelni a leggyakoribb hiba. Ez a hitelesítő adatokról szóló ítélet, nem munkamenet. A tükörhiba az, hogy egy házirend-egyezést engedélyezési bizonyítékként olvasunk, miközben egy szabály egyezhet, és a következő lépés mégis meghiúsulhat.
Egy munkamenet, egy értesítés
Egy fiók, több eszköz, újraküldések és újracsatlakozások: eseményenként egy e-mail mindkét irányban hibás lesz, megkettőz egy munkamenetet, miközben szétválaszt egy másikat. Az értesítés kulcsa az átjáró plusz egy munkamenet-azonosító legyen, és a fióknevet attribútumként, ne kulcsként kezelje. Egy laptopos és telefonos felhasználónak egyszerre két alagútja lehet, és mindkettő megérdemli a saját sorát.
Az újraküldött könyvelési rekordok normálisak, ezért az üzenet megjelenítése előtt távolítsa el a duplikátumokat a munkamenet-azonosító és az időbélyeg alapján. Az ugyanarról az eszközről induló egymást követő munkamenetek maradjanak külön, és a karbantartási ablak alatti újracsatlakozás maradjon látható, ne olvadjon össze az előzővel. Ha a gyűjtője begyűjtéskor átírja az időbélyegeket, az eredeti rekord mezői alapján távolítsa el a duplikátumokat, nem a tároltak alapján.
A hiányzó Stop-rekord bizonytalanság, nem állandó munkamenet. Az átjáró újraindításai, a gyűjtő kiesései és az UDP-veszteség mind hézagokat hagynak, ezért a riasztásnak olyan egyeztetési útra van szüksége, amely az élő munkamenet-táblát kérdezi, mielőtt bárki arra jut, hogy egy alagút még mindig fut.
Tartsa külön az auditot és az értesítést
Az auditfolyamnak és a riasztási folyamnak különböző feladatai vannak. Őrizze meg a nyers rekordokat, beleértve a fiókot, az átjárót, a munkamenet-azonosítót, az időbélyegeket és a megszűnés okát, akkor is, ha a rutin e-maileket csoportosítják, elnyomják vagy egy kis ügyeleti listára küldik. A súlyossági küszöb kézbesítési szűrő, nem az általa bejelenteni kívánt életciklus-esemény kiválasztása.
Küldje el a minimális kontextust, amelyre a címzettnek a védett rekord megtalálásához szüksége van. A fióknevek, a belső címek és a munkamenet részletei érzékenyek, és az az e-mail, amely jól továbbítható, az az e-mail, amely jól szivárog.
Aztán bizonyítsa végig. Futtasson normál be- és kijelentkezést, újracsatlakozást, két egyidejű munkamenetet és kényszerített kézbesítési hibát, és kövessen egy eseményt az átjárótól a gyűjtőn át a kézbesített üzenetig. Ha az e-mail munkamenet-azonosító nélkül érkezik, a szerződés hiányos. Ha két e-mail egy munkamenetet ír le, a korreláció elromlott. Egyik probléma sem mutatkozik meg, ha az egyetlen dolog, amit tesztel, hogy a levélkézbesítés működik.