Upozornění na přihlášení VPN: která událost je má vlastně spouštět?
Úspěšná autentizace, navázaný tunel a RADIUS accounting Start jsou tři různá tvrzení. Vyberte to, se kterým váš příjemce může něco dělat, a pak je propojte.
Úspěšná autentizace, navázaný tunel a RADIUS accounting Start jsou tři různá tvrzení a e-mail o přihlášení něco znamená teprve tehdy, když si jedno z nich vyberete. Většina návrhů VPN upozornění míchá všechna tři a vytváří schránku, které nikdo nevěří. Rozhodnutí závisí na tom, kdo upozornění čte a co může udělat v následujících pěti minutách. Když to pokazíte, upozornění se stane šumem, který skrývá jedinou událost, kterou jste potřebovali.
O spouštěči rozhodují tři otázky
Zeptejte se, kdo ho dostane, co udělá a jak rychle musí akce nastat. Bezpečnostní tým sledující zneužití pověření chce vzor selhání a pak úspěchu z jednoho účtu v řádu minut. Provozní tým sledující kapacitu chce délku relace a důvody odpojení, ne přihlášení. Helpdesk chce identitu relace, aby ji mohl spárovat s tiketem.
Tyto odpovědi ukazují na různé události a žádné jediné pravidlo neuspokojí všechny tři. Pokud je akcí příjemce „zavolej uživateli“, autentizace stačí. Pokud je akcí „uvolni licenci“ nebo „ověř, že tunel přenášel provoz“, poslouží jen navázání nebo accounting Start. Pokud je akcí „vyfakturuj čas“, potřebujete záznamy Stop, ne přihlášení.
Napište odpověď jako jednu větu, než cokoli nakonfigurujete. „Tento e-mail říká pohotovostnímu inženýrovi, že účet X otevřel tunel ze sítě Y v čase Z, aby mohl zkontrolovat, zda bylo využito okno údržby.“ Pokud nedokážete vyplnit každé pole, spouštěč ještě není zvolen.
Slaďte událost s tvrzením, které činíte
| 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 |
Tabulka skrývá závislost: každý řádek je důvěryhodný jen tehdy, když ho brána spolehlivě vydává a váš kolektor uchovává pole, které potřebujete. Čtěte definici události pro přesnou verzi, kterou provozujete, protože název „relace navázána“ se mezi verzemi mění a význam se mění častěji než název. Když je definice vágní, požádejte o zachycení relace, místo abyste hádali podle štítku.
Považovat Access-Accept za dokončení všeho, co po něm následuje, je nejčastější chyba. Je to verdikt o pověřeních, ne relace. Zrcadlovou chybou je číst shodu se zásadou jako důkaz autorizace, když pravidlo může odpovídat a další krok přesto může selhat.
Jedna relace, jedno oznámení
Jeden účet, několik zařízení, opakovaná odeslání a opětovná připojení: e-mail na každou událost bude chybný v obou směrech, jednu relaci zduplikuje a jinou rozdělí. Klíčujte oznámení na bránu plus identifikátor relace a s názvem účtu zacházejte jako s atributem, nikoli jako s klíčem. Uživatel s notebookem a telefonem může držet dva tunely současně a oba si zaslouží vlastní řádek.
Opakovaně odesílané účetní záznamy jsou normální, proto před vykreslením zprávy odstraňte duplicity podle id relace a časového razítka. Následné relace ze stejného zařízení by měly zůstat oddělené a opětovné připojení během okna údržby by mělo zůstat viditelné, místo aby se sloučilo s předchozí. Pokud váš kolektor při příjmu přepisuje časová razítka, odstraňujte duplicity podle polí původního záznamu, ne podle uložených.
Chybějící záznam Stop je nejistota, ne trvalá relace. Restarty brány, výpadky kolektoru a ztráta UDP zanechávají mezery, takže upozornění potřebuje cestu pro usmíření, která se dotáže tabulky živých relací, než kdokoli usoudí, že tunel stále běží.
Držte audit a oznámení oddělené
Tok auditu a tok upozornění mají různé úkoly. Uchovávejte surové záznamy včetně účtu, brány, id relace, časových razítek a důvodu ukončení, i když se rutinní e-maily seskupují, potlačují nebo posílají na malý pohotovostní seznam. Prahová hodnota závažnosti je filtr doručení, ne výběr události životního cyklu, kterou jste chtěli oznámit.
Pošlete minimální kontext, který příjemce potřebuje k nalezení chráněného záznamu. Názvy účtů, interní adresy a podrobnosti relace jsou citlivé a e-mail, který se dobře přeposílá, je e-mail, který dobře uniká.
Pak to dokažte od začátku do konce. Projděte běžné přihlášení a odhlášení, opětovné připojení, dvě souběžné relace a vynucené selhání doručení a vystopujte jednu událost od brány přes kolektor až k doručené zprávě. Pokud e-mail dorazí bez id relace, smlouva je neúplná. Pokud dva e-maily popisují jednu relaci, korelace je rozbitá. Ani jeden z těchto problémů se neukáže, když jediné, co testujete, je to, že doručování pošty funguje.