Alertas de inicio de sesión de VPN: que evento debería activalas en realidade?
O éxito de autenticación, un túnel establecido e un RADIUS accounting Start son tres afirmacións distintas. Escolla a que o seu destinatario poida aproveitar e despois correlación eas.
O éxito de autenticación, un túnel establecido e un RADIUS accounting Start son tres afirmacións distintas, e un correo de inicio de sesión só significa algo cando escolle unha delas. A maioría dos deseños de alertas de VPN mesturan as tres e producen unha caixa de entrada na que ninguén confía. A decisión depende de quen le a alerta e que pode facer nos seguintes cinco minutos. Se se equivoca, a alerta convértese en ruído que oculta o único evento que necesitaba.
Tres preguntas deciden o disparador
Pregunte quen a recibe, que fará e con que rapidez debe ocorrer a acción. Un equipo de seguridade que vixía o uso indebido de credenciais quere un patrón de fallo e despois éxito desde unha conta en cuestión de minutos. Un equipo de operacións que vixía a capacidade quere a duración da sesión e os motivos de desconexión, non os inicios de sesión. Un servizo de axuda quere a identidade da sesión para poder emparellala cun tícket.
Eses respostas apuntan a eventos distintos, e ningunha regra única satisfai as tres. Se a acción do destinatario é «chama o usuario», a autenticación abonda. Se a acción é «libera unha licenza» ou «verifica que o túnel transportou tráfico», só serven o establecemento ou o accounting Start. Se a acción é «factura o tempo», necesita rexistros Stop en lugar dun inicio de sesión.
Escriba a resposta nunha soa frase antes de configurar algo. «Este correo dille ao enxeñeiro de garda que a conta X abriu un túnel desde a rede Y á hora Z, para que poida comprobar se se usou a xanela de mantemento.» Se non pode encher cada casilla, o disparador aínda non está elixido.
Axuste o evento á afirmación que fai
| 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áboa esconde unha dependencia: cada fila só é fiable se a pasarela a emite de forma fiable e o seu colector conserva o campo que necesita. Lea a definición do evento para a versión exacta que executa, porque o nome de «sesión establecida» cambia entre versións e o significado cambia máis a miúdo que o nome. Cando unha definición é vaga, pida unha captura de sesión en lugar de adiviñar pola etiqueta.
Tratar un Access-Accept como a finalización de todo o que vén despois é o erro máis común. É un veredicto sobre as credenciais, non unha sesión. O erro espello é ler unha coincidencia de política como proba de autorización, cando unha regra pode coincidir e o seguinte paso aínda pode fallar.
Unha sesión, unha notificación
Unha conta, varios dispositivos, retransmisións e reconexións: un correo por evento será incorrecto en ambas direccións, duplicando unha sesión mentres divide outra. Fixe a notificación na pasarela máis un identificador de sesión, e trate o nome da conta como un atributo en lugar de como a clave. Un usuario con portátil e teléfono pode manter dous túneles á vez, e ambos merecen a súa propia liña.
Os rexistros contables retransmitidos son normais, así que deduplique polo id de sesión e a marca de tempo antes de representar a mensaxe. As sesións consecutivas do mesmo dispositivo deben permanecer separadas, e unha reconexión durante unha xanela de mantemento debe seguir visible en lugar de colapsar na anterior. Se o seu colector reescribe as marcas de tempo na inxestión, deduplique polos campos do rexistro orixinal, non polos almacenados.
Un rexistro Stop ausente é incerteza, non unha sesión permanente. Os reinicios da pasarela, as caídas do colector e a perda de UDP deixan ocos, así que a alerta necesita unha ruta de reconciliación que consulte a táboa de sesións activas antes de que alguén conclúa que un túnel segue en pé.
Manteña a auditoría e a notificación separadas
O fluxo de auditoría e o fluxo de alertas teñen traballos diferentes. Conserve os rexistros en bruto, incluídos conta, pasarela, id de sesión, marcas de tempo e motivo de terminación, mesmo cando os correos rutineiros se agrupan, se suprimen ou se envían a unha lista de garda pequena. Un limiar de gravidade é un filtro de entrega, non unha selección do evento do ciclo de vida que quería anunciar.
Envíe o contexto mínimo que o destinatario necesita para atopar o rexistro protexido. Os nomes de conta, os enderezos internos e os detalles de sesión son sensibles, e un correo que se reenvía ben é un correo que se filtra ben.
Despois demostreo de principio a fin. Execute un inicio e peche de sesión normais, unha reconexión, dúas sesións simultáneas e un fallo de entrega forzado, e rastrexee un evento desde a pasarela a través do colector ata a mensaxe entregada. Se o correo chega sen un id de sesión, o contrato está incompleto. Se dous correos describen unha sesión, a correlación está rota. Ningún dos dous problemas aparece cando o único que proba é que a entrega de correo funciona.