Las alertas de inicio de sesión VPN no son alertas de intrusión: vigila la sesión

Una alerta de VPN que salta por un país nuevo parece concluyente, y normalmente no lo es. La autenticación dice que se aceptó un intento; la sesión dice qué conexión lo llevó; los registros de recursos dicen qué ocurrió dentro de esa conexión. Cada uno responde a una pregunta distinta. Una regla que fusiona los tres produce treinta tickets un lunes y deja pasar el caso real un viernes.

Una dirección extranjera es una pregunta, no una respuesta

Los viajes, los operadores móviles que salen por otro país, un proxy web corporativo y un grupo de NAT de operador reasignado mueven todos el origen aparente sin mover al atacante. El registro de inicio de sesión refleja por dónde entró la conexión a la red, no quién sostenía el dispositivo.

El fallo inverso es peor porque es silencioso. Una contraseña robada usada desde la ciudad del propio usuario produce un inicio de sesión que coincide con todos los anteriores en la comprobación geográfica.

Tratar la geografía como el veredicto tiene un coste medible. Los portátiles que viajan generan un flujo constante de revisiones, los revisores aprenden a cerrarlas sin leerlas, y el hábito sobrevive hasta que un caso real llega a la misma cola.

Tres tipos de registro responden a tres preguntas distintas

Empieza por lo que emiten los productos desplegados, no por lo que sugiere un folleto que podrían emitir. La decisión de autenticación nombra la identidad afirmada, el método y el resultado. El ciclo de vida de la sesión nombra la conexión, la puerta de enlace y la dirección asignada, desde el inicio hasta la detención.

Una celda vacía es un hueco de recogida, no una absolución. Si los eventos de recursos nunca llegan, la ausencia de una lectura sospechosa significa que la tubería no tiene nada que informar, y un panel silencioso describe la tubería y no la red. Anota qué registros produce realmente el despliegue antes de prometer una regla que dependa de ellos, y nombra al dueño de cada flujo que falte.

El detalle contable es donde las sesiones se vuelven comprobables. La contabilidad RADIUS descrita en RFC 2866 lleva actualizaciones de inicio, parada e intermedias ligadas a un identificador de sesión, así que una sesión con inicio y sin parada es un hueco que puedes nombrar en lugar de un misterio.

Une por la sesión, no por el nombre de usuario

Una cuenta mantiene legítimamente varias sesiones a la vez: un portátil, un teléfono, una máquina de laboratorio dejada conectada toda la noche. Unir cada evento de ese nombre de usuario fusiona tres dispositivos en una historia y luego lee la combinación como compromiso. Las direcciones asignadas también se reciclan, así que una unión que sigue coincidiendo con una dirección después de que la sesión termine arrastra el dispositivo del mes pasado al incidente de hoy. Conserva la clave de sesión junto a la dirección y limita la coincidencia a la ventana temporal que la sesión cubrió realmente.

Donde la traducción elimina el origen original antes de que un servicio lo vea, usa la identidad que sobrevive en esa frontera, como un sujeto de TLS mutuo o una aserción de inicio de sesión único. Inventar una correspondencia uno a uno entre una dirección y una persona es el mismo error con pasos extra.

Una alerta sin dueño es un panel

Cada regla necesita una condición, las explicaciones benignas que la producen, la evidencia que hay que reunir y la persona que actúa. Una operación administrativa denegada repetida, una ráfaga de contraseñas fallidas y un recolector silencioso son tres incidentes distintos con tres relojes distintos.

La notificación no es la contención, y una lista de distribución no restringe nada. Cambiar una sesión viva requiere el componente que puede hacerlo, sea la puerta de enlace que corta la conexión o el proveedor de identidad que revoca la sesión. Los flujos obsoletos y los registros de parada ausentes también pertenecen al texto de la regla, porque un recolector que no ha enviado nada durante un día se ve exactamente como una red silenciosa desde el panel. La diferencia solo se ve en la propia tubería.

Comprueba la ruta de recogida antes de fiarte de una semana tranquila

Demuestra la tubería de extremo a extremo antes de ajustar una sola regla. Los comandos siguientes confirman que los escuchadores de autenticación y contabilidad están activos, que una credencial de prueba se rechaza por el motivo correcto y que los eventos de sesión siguen llegando:

ss -uanp | grep -E ':(1812|1813)\b'
radtest alice 'not-the-password' 127.0.0.1 0 testing123
journalctl -u openvpn-server@server --since '-30 min' | grep -c 'Peer Connection Initiated'
timedatectl | grep -E 'System clock|synchronized'

Un Access-Reject de la prueba demuestra que la petición llegó al servidor y que el secreto compartido coincidió, y esa es la parte que la gente se salta. Un tiempo de espera, en cambio, apunta al secreto, al escuchador o a un filtro delante de él, y cada alerta posterior es inverificable hasta que eso se corrija.

El estado del reloj importa porque las ventanas de correlación presuponen acuerdo. Una puerta de enlace desviada unos minutos hace que una unión de sesión limpia parezca imposible, y los revisores compensan ampliando la ventana hasta que la unión deja de discriminar. Comprueba la desviación antes de editar la regla.

Después pon una regla a prueba con un test inofensivo: genera un inicio de sesión desde una dirección inesperada, confirma que la alerta salta, confirma que el respondedor puede extraer la sesión y sus eventos de recursos, y confirma que el ticket lleva el identificador de sesión. Una regla que produce una historia coherente pasa. Una regla que produce un montón de líneas de registro sigue siendo un panel. Anota el resultado junto a la regla para que la próxima revisión empiece con evidencia y no con intuición.