Alertes d'inici de sessió de VPN: quin esdeveniment les ha de desencadenar realment?
L'èxit d'autenticació, un túnel establert i un RADIUS accounting Start són tres afirmacions diferents. Trieu la que el destinatari pugui aprofitar i després correleu-les.
L'èxit d'autenticació, un túnel establert i un RADIUS accounting Start són tres afirmacions diferents, i un correu d'inici de sessió només significa alguna cosa quan trieu una d'elles. La majoria de dissenys d'alertes de VPN barregen les tres i produeixen una safata que ningú no es creu. La decisió depèn de qui llegeix l'alerta i què pot fer en els cinc minuts següents. Si això falla, l'alerta es converteix en soroll que amaga l'únic esdeveniment que necessitàveu.
Tres preguntes decideixen el desencadenant
Pregunteu qui el rebrà, què farà i amb quina rapidesa ha d'actuar. Un equip de seguretat que vigila l'ús indegut de credencials vol un patró de fallada i després èxit d'un compte en qüestió de minuts. Un equip d'operacions que vigila la capacitat vol la durada de la sessió i els motius de desconnexió, no els inicis de sessió. Un servei d'ajuda vol la identitat de la sessió per poder-la aparellar amb un tiquet.
Aquestes respostes apunten a esdeveniments diferents, i cap regla única no satisfà les tres. Si l'acció del destinatari és «truca l'usuari», l'autenticació n'hi ha prou. Si l'acció és «allibera una llicència» o «verifica que el túnel ha portat trànsit», només serveixen l'establiment o l'accounting Start. Si l'acció és «factura el temps», necessiteu registres Stop en lloc d'un inici de sessió.
Escriviu la resposta en una sola frase abans de configurar res. «Aquest correu diu a l'enginyer de guàrdia que el compte X ha obert un túnel des de la xarxa Y a l'hora Z, perquè pugui comprovar si s'ha fet servir la finestra de manteniment.» Si no podeu omplir cada casella, el desencadenant encara no està triat.
Feu coincidir l'esdeveniment amb l'afirmació que feu
| 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 |
La taula amaga una dependència: cada fila només és fiable si la passarel·la l'emet de manera fiable i el vostre col·lector conserva el camp que necessiteu. Llegiu la definició de l'esdeveniment per a la versió exacta que executeu, perquè el nom de «sessió establerta» canvia entre versions i el significat canvia més sovint que el nom. Quan una definició és vaga, demaneu una captura de sessió en lloc d'endevinar per l'etiqueta.
Tractar un Access-Accept com la compleció de tot el que ve després és l'error més habitual. És un veredicte sobre credencials, no una sessió. L'error mirall és llegir una coincidència de política com a prova d'autorització, quan una regla pot coincidir i el pas següent encara pot fallar.
Una sessió, una notificació
Un compte, diversos dispositius, retransmissions i reconnexions: un correu per esdeveniment serà incorrecte en totes dues direccions, duplicant una sessió mentre en parteix una altra. Claveu la notificació a la passarel·la més un identificador de sessió, i tracteu el nom del compte com un atribut i no com la clau. Un usuari amb portàtil i telèfon pot mantenir dos túnels alhora, i tots dos mereixen la seva pròpia línia.
Els registres comptables retransmesos són normals, així que deduplicau per l'id de sessió i la marca de temps abans de renderitzar el missatge. Les sessions consecutives del mateix dispositiu han de romandre separades, i una reconnexió durant una finestra de manteniment ha de continuar visible en lloc de col·lapsar-se en l'anterior. Si el vostre col·lector reescriu les marques de temps en la ingesta, deduplicau pels camps del registre original, no pels emmagatzemats.
Un registre Stop absent és incertesa, no una sessió permanent. Les reinicies de la passarel·la, les caigudes del col·lector i la pèrdua d'UDP deixen forats, així que l'alerta necessita un camí de reconciliació que consulti la taula de sessions vives abans que algú conclogui que un túnel encara és obert.
Manteniu l'auditoria i la notificació separades
El flux d'auditoria i el flux d'alertes tenen feines diferents. Conserveu els registres en brut, incloent-hi compte, passarel·la, id de sessió, marques de temps i motiu de terminació, fins i tot quan els correus rutinaris s'agrupen, se suprimeixen o s'envien a una llista de guàrdia petita. Un llindar de gravetat és un filtre de lliurament, no una selecció de l'esdeveniment del cicle de vida que volíeu anunciar.
Envieu el context mínim que el destinatari necessita per trobar el registre protegit. Els noms de compte, les adreces internes i els detalls de sessió són sensibles, i un correu que es reenvia bé és un correu que es filtra bé.
Després demostreu-ho d'un extrem a l'altre. Feu un inici i tancament de sessió normals, una reconnexió, dues sessions simultànies i una fallada de lliurament forçada, i resseguiu un esdeveniment des de la passarel·la a través del col·lector fins al missatge lliurat. Si el correu arriba sense un id de sessió, el contracte és incomplet. Si dos correus descriuen una sessió, la correlació està trencada. Cap dels dos problemes no apareix quan l'única cosa que proveu és que el lliurament de correu funciona.