Guía completa para configurar y diagnosticar políticas Firewall en Fortinet FortiGate

Las políticas de firewall en dispositivos Fortinet FortiGate son el núcleo fundamental para controlar el flujo de tráfico entre diferentes zonas dentro de una red. Entender cómo configurarlas, interpretarlas y diagnosticarlas correctamente es vital para garantizar la seguridad y el óptimo funcionamiento de la infraestructura TI. En este artículo se explica de forma detallada una configuración típica de política firewall que permite la comunicación desde una zona desmilitarizada (DMZ) hacia la red LAN interna.

Contexto y objetivo de la configuración

El propósito de esta política es autorizar el tráfico procedente de un servidor ubicado en la zona DMZ (zona neutral donde se ubican sistemas accesibles desde redes externas) hacia un servidor destino ubicado en la LAN. Se busca que el servidor web de la DMZ (identificado como weserverFiol) pueda comunicarse con la base de datos interna (ServerDB) utilizando cualquier tipo de servicio o protocolo (definido como ALL) de forma ininterrumpida (schedule siempre activa). La política se configura para que acepte el tráfico y utilice inspección de paquetes basada en flujo (Flow-based), optimizando el rendimiento y permitiendo aplicar reglas de seguridad actualizadas.

Arquitectura y flujo de tráfico

En una arquitectura típica de FortiGate, la DMZ se configura como una interfaz lógica o física separada de la LAN y WAN con reglas restrictivas para limitar el acceso. El tráfico desde la DMZ hacia la LAN, especialmente el que involucra servidores críticos, debe controlarse estrictamente para evitar movimientos laterales de posibles ataques.

En este caso, el tráfico fluye desde la interfaz dmz (interface de origen) hacia la interfaz lan (interface de destino). Se aplican controles mediante listas de direcciones IP (objetos como weserverFiol y ServerDB) que representan respectivamente el origen y destino de la comunicación. La política está habilitada para todos los servicios, permitiendo así cualquier puerto o protocolo necesario para la completa comunicación del software entre ambos servidores.

Campos principales y parámetros críticos

  • ID: Número identificador de la política (en este caso 14), usado para operaciones CLI o referencias rápidas.
  • Name: Identificador amigable DMZtoLan_SRV, que describe el propósito de la regla.
  • Incoming Interface: Interface de entrada es DMZ, configurada para aceptar el tráfico desde la zona desmilitarizada.
  • Outgoing Interface: Interface de salida es Lan, dirección destino típica para servidores internos.
  • Source y Destination: Direcciones definidas por objetos (wsererFiol para origen y ServerDB para destino) que representan hosts o redes específicas.
  • Schedule: Establecido en always para habilitar la política sin restricción horaria.
  • Service: ALL para permitir todos los servicios/protocolos.
  • Action: ACCEPT, clave para permitir el paso del tráfico.
  • Inspection Mode: Flow-based, que optimiza el rendimiento al inspeccionar los paquetes en tiempo real sin generación de sesiones adicionales.

Compatibilidad de versiones y modelos

Esta configuración es comúnmente soportada en la mayoría de modelos FortiGate con firmware FortiOS 5.x en adelante, incluyendo la serie 60E,F,G. Sin embargo, algunas funcionalidades como Inspection Mode pueden variar en opciones o rendimiento según el modelo o la versión específica del firmware. Se recomienda verificar la compatibilidad concreta en el fortinet.com o mediante los comandos CLI que indiquen la versión de FortiOS.

Escenarios de uso recomendados

  • Implementación de un entorno seguro de servidor web en DMZ que requiere acceso a backend en LAN (bases de datos, servidores de aplicaciones).
  • Entornos donde se precise una separación clara de segmentos con control granular por políticas de firewall.
  • Casos donde se requiere auditoría y monitoreo detallado del tráfico entre zonas de red con revisión por inspección en modo flow-based para minimizar impacto en rendimiento.

Riesgos, errores frecuentes y cómo evitarlos

  • Uso indiscriminado del servicio ALL: Si bien útil en pruebas, activar todos los servicios puede exponer la LAN a tráfico innecesario o malicioso. Se recomienda restringir a puertos esenciales en producción.
  • Negación no aplicada: Olvidar definir políticas explícitas de DENY puede permitir tráfico indeseado implícito por defecto o comportamientos inesperados según política de firewall.
  • Falta de segmentación de origen y destino: No definir correctamente los objetos fuente y destino puede abrir un rango demasiado amplio, vulnerando aislamiento de red.
  • No actualizar firmware: Versiones antiguas pueden tener bugs o falta de soporte para tipos de inspección avanzada.

Comandos de CLI útiles para diagnóstico

config firewall policy
    edit 14
        set srcintf "dmz"
        set dstintf "lan"
        set srcaddr "weserverFiol"
        set dstaddr "ServerDB"
        set action accept
        set schedule "always"
        set service "ALL"
        set inspection-mode flow
    next
end
# Mostrar el estado y contador de la política
diag firewall policy list | grep -A 10 "id=14"

# Revisar sesiones activas relacionadas con la política
diag sys session filter policy 14
diag sys session list

# Ver tráfico en tiempo real por interfaz y evaluar logs
diag sniff packet any 'host 192.168.X.X' 4 100

# Ver versión de firmware para compatibilidad
get system status | grep Version

Interpretar la salida de estos comandos permite verificar que la política está activa, cuántas conexiones está gestionando y si el tráfico esperado circula correctamente. El filtro de sesiones por política facilita identificar problemas específicos en el flujo desde origen a destino. Los comandos de sniffing ayudan a inspeccionar en detalle los paquetes para confirmar el correcto paso del tráfico y detectar anomalías a nivel de capa de red y aplicación.

Buenas prácticas y checklist final

  • Utilizar objetos definidos para origen y destino para mantener facilidad de gestión y claridad.
  • Restringir servicios a los realmente necesarios en la política para minimizar exposición.
  • Preferir el modo flow-based para inspección salvo que se requieran funcionalidades específicas de proxy.
  • Implementar schedules para controlar horarios de acceso cuando sea necesario.
  • Documentar y nombrar claramente las políticas para facilitar mantenimiento y auditorías.
  • Revisar periódicamente logs y contadores de políticas para detectar tráfico anómalo o no autorizado.
  • Actualizar FortiOS y firmware de dispositivos para asegurarse de contar con parches y mejoras de seguridad.
  • Probar las políticas en entorno controlado antes de producción para validar funcionamiento y evitar bloqueos involuntarios.