Alerta entrante en un servidor VPN: lea el punto de observación
Una captura, un descarte del cortafuegos y un inicio de sesión fallido registran tres eventos distintos. Correlacione la tupla y la marca de tiempo antes de decidir si alguien entró.
Un servidor detrás de una VPN conserva sus entradas públicas de servicio, y la gente sigue encontrándolas. Lo que llega a la cola de alertas no es un hallazgo, sino tres posibles, y significan cosas distintas. La primera tarea es separar un servicio expuesto de una credencial expuesta.
Recorra los puntos de observación en orden. Deténgase cuando la evidencia cambie de categoría, porque la etapa siguiente responde a otra pregunta.
Primera etapa: qué vio realmente la captura
Una captura de paquetes registra lo que era visible en su propio punto del camino. Ese punto puede estar antes de una decisión de filtrado posterior. Un paquete capturado demuestra que el tráfico llegó allí. No demuestra nada sobre lo que ocurrió después.
Fíjese también en la interfaz. Una captura en el adaptador público y una captura dentro del túnel describen puntos de llegada distintos, y una alerta que cita el equivocado lleva a la conclusión equivocada.
Windows también filtra en varias capas de la pila, así que el modelo ordenado en el que la herramienta de captura está en la capa dos y el cortafuegos en la capa tres no sobrevive al contacto con un producto real. La descripción general de Windows Filtering Platform describe el filtrado entre capas de la pila, y por eso el orden de observación debe establecerse en lugar de suponerse.
Segunda etapa: qué establece el registro de descarte
Un registro de descarte dice que un límite de política rechazó ese paquete. Es una evidencia sólida. También es una evidencia estrecha, porque cubre una decisión en un límite. Nada más de la pila queda descrito por él.
Correlacione por la tupla y la marca de tiempo. Misma fuente, mismo destino, mismo puerto, dentro del mismo segundo. Sin esa coincidencia, un evento de aspecto similar en otro registro es simplemente otro evento, y emparejarlos produce una historia que nadie puede defender.
# what did the firewall actually drop, and when?
Get-NetFirewallProfile -PolicyStore ActiveStore | Select-Object Name, LogAllowed, LogBlocked
Get-Content "$env:systemroot\System32\LogFiles\Firewall\pfirewall.log" | Select-String 'DROP'
# correlate with a listening service on the same port
Get-NetTCPConnection -LocalPort 3389 -State Listen | Select-Object LocalAddress, OwningProcess
Un puerto cerrado y un paquete descartado parecen idénticos desde fuera y completamente distintos en estas dos salidas. Esa diferencia es toda la razón para leer el registro local.
Tercera etapa: qué demuestra el evento de autenticación
Un evento de autenticación dice que un componente procesó la solicitud lo suficiente como para registrar un resultado. Es el único de las tres etapas que habla de identidad, y no dice nada sobre cuántos paquetes llegaron antes.
Lea el contexto real del evento. Un inicio de sesión fallido para una cuenta que no existe es ruido de escaneo. Un inicio de sesión fallido para una cuenta real desde una fuente plausible es otra prioridad. Una sesión correcta es una categoría de incidente completamente distinta.
Vigile también los nombres de los protocolos. RPC y RDP son servicios separados con puertos separados. Un detector que vigila uno de los dos no cubre el otro. Las herramientas que resumen la actividad de red no siempre dicen cuál de los dos produjo el evento.
Una muestra correlacionada vale más que un panel
Elija una prueba autorizada, ejecútela a propósito y recórrala de principio a fin: dirección de destino e interfaz, dirección de origen real, puerto del servicio, perfil y regla efectivos del cortafuegos, y el resultado correspondiente del servicio. Incluya en esa cadena cualquier asignación intermedia o cortafuegos en la nube, porque una regla permisiva allí puede anular una regla local bien ordenada.
Después separe las dos obligaciones. Si la administración debe ser solo por VPN, impóngalo tanto en la ruta pública como en la del túnel mientras mantiene una ruta de recuperación aprobada. Vigilar un intento rechazado no es la misma tarea que decidir qué debe aceptar el servidor.
Una regla de geografía o un protocolo no relacionado bloqueado no sustituyen encontrar la entrada observada y la decisión que recibió. Tampoco lo hace una VPN: enrutar el tráfico saliente por un túnel no documenta nada sobre la autorización entrante.