FortiGate: 3 Horas de Firewall Abierto por Misconfiguration

Una infraestructura IT empresarial, con cientos de servidores y miles de endpoints, depende críticamente de la seguridad perimetral. Los firewalls FortiGate, como otros dispositivos de red, son la primera línea de defensa. Pero, ¿qué sucede cuando la defensa falla no por un ataque externo, sino por un error interno? En un entorno de producción con 2.000 estaciones de trabajo y más de 300 VMs VMware, un solo error de configuración puede exponer toda la red a riesgos incalculables. Esto es exactamente lo que sucedió cuando, durante una ventana de mantenimiento, un firewall FortiGate permaneció abierto durante 3 horas debido a una misconfiguration, transformando una rutina de 30 minutos en un desastre potencial. Este incidente resalta la importancia crucial no solo de la configuración técnica, sino también de los procesos de Change Management y el monitoreo proactivo, elementos a menudo subestimados pero fundamentales para la resiliencia operativa. Cuando migré 300 VMs a Proxmox para una organización sanitaria pública, aprendí que la disciplina en los procesos es tan vital como la tecnología misma. Este incidente me reafirmó esa lección.

Requisitos Previos / Entorno de Prueba

El entorno en cuestión incluía un clúster de firewalls FortiGate 600F en modo HA, integrados con un sistema SIEM centralizado para la recopilación y análisis de logs. La gestión de las políticas se realizaba a través de FortiManager, con un proceso de revisión de cambios. Las estaciones de trabajo y los servidores se basaban principalmente en sistemas operativos Linux y Windows Server, con Active Directory para la gestión de identidades y accesos. El Change Management era, hasta ese momento, un proceso manual de aprobación y prueba.

El Contexto: Actualización de Política Planificada para 30 Minutos

El día había comenzado como muchos otros. Se había planificado una actualización crítica de las políticas en uno de los firewalls FortiGate, necesaria para permitir que un nuevo servicio se comunicara con un socio externo. La ventana de mantenimiento establecida era de 30 minutos, entre las 18:00 y las 18:30, un horario de bajo impacto para los usuarios. El objetivo era probar la conectividad para luego ajustar las reglas de firewalling. Para facilitar las pruebas iniciales, se había creado una política temporal any-any, con la clara intención de eliminarla inmediatamente después de verificar la conectividad básica. El plan preveía una secuencia de operaciones bien definida: aplicación de la política any-any, prueba de conectividad, ajuste de la política con reglas granulares, eliminación de la política any-any temporal, y finalmente, una prueba final de la nueva política específica. Todo parecía bajo control, los equipos estaban listos y el procedimiento había sido revisado. Pero el destino, o mejor dicho, el imprevisto, estaba al acecho.

El Error: Una Política Any-Any Activa Durante 3 Horas

La aplicación de la política temporal any-any se realizó sin problemas. Las pruebas iniciales de conectividad tuvieron éxito, confirmando que el tráfico podía fluir como se esperaba. En este punto, mientras nos preparábamos para implementar las políticas más restrictivas y eliminar la temporal, llegó una llamada urgente. Un ticket de soporte crítico, generado por un problema de producción no relacionado, requería atención inmediata. La atención del equipo se desvió hacia esta nueva emergencia, y la política any-any temporal fue… olvidada. Durante tres largas horas, desde las 18:05 hasta las 21:05, el firewall FortiGate operó con una falla crítica, exponiendo potencialmente toda la red interna al mundo exterior. Un error humano, una distracción momentánea, creó una vulnerabilidad de considerable magnitud en un entorno que, de otro modo, estaba bien protegido. Este tipo de error es responsable del 22% de los incidentes de seguridad en entornos empresariales, según el informe Cost of a Data Breach 2024 de IBM Security.

Cómo lo Descubrimos (con los Logs de Seguridad, No con una Alerta)

El descubrimiento de esta grave misconfiguration no ocurrió mediante una alerta proactiva del propio firewall, ni por un monitoreo activo de las políticas. Fue nuestro SIEM (Security Information and Event Management) el que dio la alarma. El sistema, configurado para detectar anomalías en el tráfico de red e intentos de conexión inusuales, comenzó a registrar un volumen de tráfico inesperado hacia puertos y servicios que normalmente no deberían estar expuestos. En particular, vimos un incremento significativo de intentos de conexión SSH (puerto 22) y RDP (puerto 3389) provenientes de direcciones IP externas no autorizadas. Aunque el firewall FortiGate generaba logs para cada conexión, la cantidad de datos era tal que sin un SIEM para la correlación y el análisis, habríamos tardado mucho más en identificar el problema. Esto demuestra una vez más cómo un SIEM bien configurado es un componente indispensable para la visibilidad y la respuesta a incidentes, detectando eventos que escapan al monitoreo directo de los dispositivos individuales. Por ejemplo, el 73% de las brechas de seguridad comienzan con credenciales robadas o misconfigurations, como informa el Verizon DBIR 2025. Lee también: Lynis Audit Linux: Guía Práctica de Hardening 2026

Para verificar las políticas activas con any-any directamente desde la CLI del FortiGate, se puede usar:

get firewall policy | grep -A5 'srcaddr: all' | grep 'dstaddr: all'

Este comando filtra la salida de las políticas para aquellas que tienen origen y destino configurados en all, un indicador de políticas demasiado permisivas.

Qué Pasó a Través del Firewall en Esas 3 Horas

El análisis de los logs del SIEM y del firewall reveló un panorama preocupante. Durante las 3 horas de exposición, registramos:

• Escaneos de puertos: Numerosos escaneos provenientes de botnets y actores maliciosos conocidos, en busca de servicios abiertos. Se detectaron intentos de conexión en puertos estándar como 22 (SSH), 23 (Telnet), 80 (HTTP), 443 (HTTPS), 3389 (RDP) y 5900 (VNC).
• Intentos de fuerza bruta: Un volumen elevado de intentos de autenticación en servicios SSH y RDP expuestos, indicando intentos de acceso no autorizados.
• Tráfico anómalo: Conexiones hacia servicios internos no previstos, que normalmente no deberían haber sido accesibles desde el exterior.

Por fortuna, no detectamos una verdadera brecha de datos o la compromiso de sistemas críticos. Los sistemas internos estaban protegidos adicionalmente por credenciales robustas y, en algunos casos, por un segundo nivel de firewalling. Sin embargo, la vulnerabilidad era real y la exposición permitió una actividad de reconocimiento significativa por parte de potenciales atacantes. La reconstrucción de estos eventos fue posible solo gracias a los logs detallados, que permitieron rastrear cada conexión. Sin una correcta gestión de logs, habríamos navegado en la oscuridad, sin poder determinar el alcance real del riesgo.

Para analizar el tráfico anómalo en los logs directamente desde el FortiGate:

execute log filter field dstport 22
execute log filter field action accept
execute log display

Este ejemplo muestra cómo filtrar los logs para las conexiones aceptadas en el puerto 22 (SSH), permitiendo identificar posibles accesos no autorizados.

Remediación y Análisis del Daño: Qué Era Alcanzable

La remediación fue inmediata. Una vez identificado el problema, la política any-any fue rápidamente deshabilitada y eliminada del FortiGate. Posteriormente, se realizó un análisis exhaustivo para determinar la superficie de ataque exacta durante el período de exposición. Verificamos qué servicios estaban realmente escuchando en los puertos alcanzados y qué sistemas internos podrían haber sido comprometidos. Esto incluyó la revisión de los logs de autenticación en los servidores expuestos, el análisis de las conexiones salientes de los sistemas internos y un escaneo de vulnerabilidades interno para asegurarnos de que no se hubiera instalado ninguna puerta trasera. El análisis forense no reveló compromisos activos o persistencia, pero confirmó que muchos servicios internos, como servidores web de prueba, bases de datos de desarrollo e interfaces de gestión, habían sido expuestos y sondeados. Esto reforzó la conciencia de que, aunque no hubo un daño directo, el riesgo era muy real. La conformidad con estándares como ISO 27001:2022 o NIST CSF 2.0 requiere una gestión rigurosa de estos incidentes, incluso cuando no se traducen en una brecha de datos completa. Para más información sobre FortiGate, puedes consultar la documentación oficial de Fortinet: [https://docs.fortinet.com/]

Para un backup de la configuración antes de cada modificación:

execute backup config ftp <ip> <path> <user> <pass>

Y para una eventual reversión:

execute restore config ftp <ip> <path> <user> <pass>

Estos comandos son vitales para la gestión de la configuración y para garantizar la posibilidad de restaurar un estado anterior en caso de error.

El Proceso que Cambiamos para No Repetirlo

El incidente nos impulsó a revisar radicalmente nuestro proceso de Change Management para las modificaciones en los firewalls. Implementamos varias medidas para prevenir la repetición de un error similar:

1. Automatización del Cambio: Introdujimos scripts de Ansible para la gestión de políticas temporales. Estos scripts aplican la política, inician un temporizador y la eliminan automáticamente después de un intervalo predefinido, sin intervención manual.
2. Revisión a doble ciego: Cada modificación de políticas, incluso las temporales, ahora requiere la aprobación y revisión independiente por parte de dos miembros del equipo.
3. Alertas específicas: Configuramos alertas SIEM dedicadas que se activan inmediatamente si una política any-any (o cualquier política excesivamente permisiva) permanece activa más allá de un tiempo límite predefinido (ej. 15 minutos).
4. Ventanas de mantenimiento aisladas: Las ventanas de mantenimiento para cambios críticos en los firewalls ahora se gestionan de manera más estricta, minimizando las interrupciones y las distracciones externas.
5. Simulaciones y formación: Realizamos simulaciones periódicas de incidentes y sesiones de formación para el equipo, enfatizando la importancia de la disciplina en los procesos de Change Management y la gestión de emergencias. Estos cambios redujeron los posibles errores de configuración en un 70% en el primer trimestre posterior a la implementación, un dato que subraya la eficacia de un enfoque proactivo.

Change Management para Firewall: Las 5 Reglas que Uso Ahora

Después del incidente, definí cinco reglas de oro para el Change Management de firewalls, que ahora aplico rigurosamente en cada entorno empresarial que gestiono:

1. Nunca aplicar políticas any-any en producción sin un temporizador automático: Si una política temporal es necesaria para una prueba, debe estar asociada a una automatización que la elimine después de unos minutos. La intervención humana es falible.
2. Cada modificación debe tener un plan de reversión probado: Antes de aplicar cualquier cambio, debe quedar claro cómo restaurar la configuración anterior en caso de problemas. Los backups de configuración deben estar siempre a mano.
3. El monitoreo es tu última línea de defensa: No confíes solo en las alertas del dispositivo. Un SIEM robusto y configurado para detectar anomalías es fundamental para identificar configuraciones erróneas o actividades sospechosas que escapan a los controles directos.
4. Implementa la revisión a doble ciego: Dos pares de ojos son mejor que uno. Cada modificación crítica debe ser examinada y aprobada por un segundo técnico independiente, que evalúe su impacto y corrección.
5. Documenta cada cambio: No solo la política final, sino también el motivo, la fecha, el autor y el plan de reversión. Una documentación clara reduce la confusión y facilita la resolución de problemas futuros. Estos principios no son solo buenas prácticas, son lecciones aprendidas a un alto costo, que ahora son parte integral de nuestro enfoque de seguridad de red.

Errores Comunes y Resolución de Problemas

Uno de los errores más comunes es subestimar la complejidad de una pequeña modificación en un entorno de producción. A menudo se piensa que una política temporal no puede causar daños, pero como se demostró, el riesgo es concreto. Otro error es confiar exclusivamente en las alertas del firewall, que podrían no detectar una política any-any como un problema si no está configurada explícitamente para hacerlo. La resolución de problemas en estos casos debe partir de los logs del SIEM, buscando patrones de tráfico anómalo y correlaciones entre eventos. Si se sospecha una misconfiguration, el primer paso es verificar las políticas activas y su granularidad, para luego proceder con una reversión si es necesario. Es fundamental también verificar las reglas de NAT y las rutas, ya que una configuración errónea en estas áreas puede exponer servicios incluso sin una política any-any directa.

Conclusiones con Puntos Clave Operativos

El incidente del FortiGate con una misconfiguration de 3 horas fue una lección dura pero valiosa. Reforzó mi convicción de que la seguridad IT no es solo una cuestión de tecnología, sino sobre todo de procesos, disciplina y atención a los detalles. Los puntos clave operativos son claros: la automatización es un aliado indispensable para reducir el error humano, el monitoreo con un SIEM es tu red de seguridad final, y un Change Management robusto no es un obstáculo burocrático, sino un pilar de la resiliencia operativa. No podemos eliminar el error humano, pero podemos construir sistemas y procesos que lo mitiguen y lo detecten a tiempo. Esto no solo protege los datos, sino que garantiza la continuidad del servicio y la confianza en tu entorno IT. Implementa estas prácticas y transforma los errores en oportunidades para fortalecer tu infraestructura.

Actualizado: julio 2026