El presente caso de estudio detalla la configuración inicial, desde cero, de un cortafuegos FortiGate. Para esta implementación utilizaremos un appliance virtual (FortiGate-VM) desplegado sobre un hipervisor Proxmox VE.

• Appliance FortiGate, asignación de interfaces de red.
• Configuración inicial de FortiGate, asignación de direccionamiento para acceso de gestión.
• Configuración de las interfaces/puertos LAN, WAN, DMZ.
• Crear política para permitir salida a Internet en FortiGate.
• Políticas para red DMZ.
• Usuarios de acceso administrativo de gestión a FortiGate.
• Configuración de hora y de envío de emails en FortiGate.

Appliance FortiGate, asignación de interfaces de red

Aunque en entornos de producción críticos el estándar de la industria es desplegar appliances físicos en clústeres de Alta Disponibilidad (HA) para evitar puntos únicos de fallo, las versiones virtualizadas son el estándar para laboratorios, validación de topologías y entornos de nube privada (SDDC).

En entornos KVM/Proxmox, se recomienda utilizar el modelo de dispositivo VirtIO para maximizar el rendimiento de red (paravirtualización). La correlación entre los adaptadores de Proxmox y los puertos internos de FortiOS queda definida de la siguiente manera:

• net0 (Corresponde a port1 en FortiOS) – LAN: destinado a la red local de la organización. Aunque inicialmente se despliegue como una red plana, la buena práctica recomendada es que este puerto actúe como un enlace troncal (trunk) para segmentar el tráfico en múltiples VLAN internas.
• net1 (Corresponde a port2 en FortiOS) – WAN: interfaz de acceso externo o salida a Internet. Para aislar este tráfico a nivel del hipervisor, se puede etiquetar la interfaz virtual (por ejemplo, con un VLAN tag, como se aprecia en el dispositivo asociado a vmbr0), o asociarla a un puente de red físico dedicado.
• net2 (Corresponde a port3 en FortiOS) – DMZ: zona desmilitarizada. Interfaz aislada destinada a alojar servicios expuestos al exterior (servidores web, correo, balanceadores, etc.), mitigando el riesgo de compromiso hacia la LAN.

Partimos de un cortafuegos virtualizado en un entorno de laboratorio. En un entorno de producción, lo habitual es tener appliances físicos, no dependientes del entorno de virtualización y, normalmente, en cluster para alta disponibilidad (al menos dos nodos).

Configuración inicial de FortiGate, asignación de direccionamiento para acceso de gestión

Tanto si se trata de un equipo virtual como un appliance físico, en primer lugar, deberemos acceder por consola para configurar el puerto de gestión. Usaremos como puerto de gestión el mismo que el puerto de la red LAN (net0). En un entorno de produción, la buena práctica es separar en red aislada el acceso de gestión, limitando la superficie de exposición.

Desde la consola de Fortigate, ejecutaremos el siguiente comando para obtener los adaptadores de red (puertos) detectados:

Si tenemos DHCP en la red LAN Fortigate configurará automáticamente el puerto para acceso de gestión, asignándole una IP. Pero esto NO debemos mantenerlo así, es una autoconfiguración para el primer acceso y solo disponible si tenemos DHCP. Hay que modificar la configuración del puerto a estático y a una IP que será la de gestión y de puerta de enlace (gateway), por lo que NUNCA debe estar en modo de asignación dinámica DHCP.

Tras identificar el puerto de la LAN (port1), lo configuraremos asignándole una IP, que en este estudio de caso será la IP de gestión del Fortigate y también la IP de puerta de enlace para los equipos de la LAN (como veremos más adelante). Para asignar la configuración de puerto de gestión al puerto xxx identificado anteriormente, ejecutaremos los siguientes comandos:

NOTA: en el inicio, tendremos que añadir http al allowaccess anterior para permitir acceso HTTP.

Una vez establecida esta configuración en el port1, desde un equipo de la red LAN deberemos poder hacer ping a la IP establecida al Fortigate:

A partir de ahora podremos acceder vía web, desde un equipo de la red, abriendo un navegador e introduciendo la IP de gestión:

En esta confirmación, de momento, pulsaremos en «Later»:

Tendremos acceso a la consola de gestión de FortiGate:

Configuración de las interfaces/puertos LAN, WAN, DMZ

Aunque el puerto port1 de acceso de gestión y LAN ya lo hemos configurado desde la consola, conviene revisar que está correcto. Para ello, desde «Network» – «Interfaces», haremos doble clic o botón derecho «Edit» en la interfaz port1:

Configuraremos el puerto WAN (salida a Internet), desde «Network» – «Interfaces», haremos doble clic o botón derecho «Edit» en la interfaz port2 (la WAN):

Estableceremos los siguientes valores para el puerto WAN:

• Alias: WAN.
• Role: seleccionaremos «WAN».
• Addressing mode: si en el router disponemos de DHCP y queremos usarlo, marcaremos «DHCP».
• Administrative Access: es importante desmarcar todas las opciones en este puerto. Por seguridad no se debería permitir acceso a gestión en puertos expuestos a Internet.
• Status: Enabled.

Para el puerto de la DMZ, en principio, no hay que configurar nada, únicamente verificar que aparece su puerto correspondiente (port3), podemos asignarle un alias para tenerlo identificado y, al igual que en el puerto de la WAN, no es recomendable activar opciones de acceso de gestión:

Crear política para permitir salida a Internet en FortiGate

Por defecto, FortiGate crea una política para denegar todo. Para realizar una primera prueba de acceso desde los equipos de la LAN a Internet pasando por el FortiGate, crearemos una política que permita este tráfico. Desde «Policy & Objects» – «Firewall Policy», botón «Create New»:

Establecemos los siguientes valores:

• Name: LAN_a_Internet.
• Incoming Interface: port1 (el puerto de la LAN).
• Outgoing Interface: port2 (el puerto de la WAN).
• Source: all. Como estamos en un entorno de pruebas, de momento, dejamos «all», pero en un entorno de producción debemos restringir/acotar el acceso a Internet por redes, grupos o equipos.
• Destination: all. En este caso, al igual que en Source, tal vez deberíamos restringir salida a Internet a países determinados. El «all» tiene que evitarse por seguridad.
• Service: all. Como en los casos anteriores, lo ideal es acotar los puertos permitidos HTTPS (443), SMTP (si tenemos clientes de correo electrónico instalados en los equipos, etc.).
• Action: ACCEPT.
• NAT: debe estar marcado para que FortiGate haga el NAT automático desde la red LAN a Internet y viceversa.
• Security Profiles: de momento, no marcamos ninguno pero, evidentemente, en un entorno de producción debemos asignar perfiles de antivirus, filtrado web, filtrado DNS, control de aplicaciones, inspección SSL, etc.
• Log Allowed Traffic: sería conveniente marcar «All Sessions», dado que estamos realizando pruebas, para poder consultar tanto el tráfico permitido como el bloqueado.
• Enable this policy: marcaremos para habilitar la política.

Para «pasar» tráfico desde un equipo de la red a través del FortiGate, estableceremos la puerta de enlace del equipo de la LAN a la IP del FortiGate (192.168.10.6):

Si accedemos a «Log & Report» – «Forward Traffic» podremos comprobar que FortiGate ya está recibiendo, analizando y filtrando el tráfico desde los equipos en los que hayamos configurado la puerta de enlace:

Una vez verificado que el tráfico pasa por FortiGate, es muy conveniente reconfigurar la política y limitar los accesos, tanto origen, como destino y servicios, así como asignar los perfiles de seguridad:

• Source: limitamos solo a los equipos de la red LAN.
• Destination: creamos un grupo de países permitidos de salida a Internet (algunos países de Europa, algunos países de otros continentes necesarios para software y sistemas operativos).
• Service: creamos un grupo de puertos permitidos de salida a Internet (HTTPS, SMTPS, DNS, NTP).
• Security Profiles: activamos todos los perfiles de seguridad (antivirus, web filter, DNS filter, Application Control, IPS, inspección SSL, etc.). Para la inspección SSL, en este tutorial, explicamos cómo activarla de forma correcta, dado que requiere de un certificado instalado en los equipos:

Políticas para red DMZ

Dado que la red DMZ es una zona expuesta a Internet (por su naturaleza), aplicamos las políticas de forma minuciosa y lo más restrictivas posible. Crearemos la política de la DMZ a Internet, limitando sólo a los equipos de la DMZ que requieran de acceso a Internet, únicamente los puertos necesarios, y a ser posible limitaremos por países de destino. Por supuesto, aplicaremos todos los perfiles de seguridad:

• Incoming Interface: DMZ (port3).
• Outgoing Interface: WAN (port2).
• Source: intentamos limitar solo a los servidores de la DMZ que requieran acceso a Internet.
• Destination: intentamos limitar por países de destino.
• Service: indicaremos los puertos que abriremos para acceso a Internet desde la DMZ: DNS, NTP, HTTPS.
• Activaremos todos los perfiles de seguridad.

Si necesitamos acceso desde Internet a un servidor de la DMZ (es lo habitual), crearemos la regla específica para este propósito:

• Incoming Interface: WAN (port2).
• Outgoing Interface: DMZ (port3).
• Source: como siempre, intentamos limitar por países (al menos).
• Destination: indicaremos el servidor al que permitiremos el acceso.
• Service: indicaremos los puertos que abriremos para este servidor.
• Activaremos todos los perfiles de seguridad.

Usuarios de acceso administrativo de gestión a FortiGate

Es muy recomendable establecer restricciones de acceso a los usuarios administradores de FortiGate. Seguiremos las siguientes medidas:

• Crearemos usuarios con los permisos estrictamente necesarios, evitando crear todos como usuarios administradores de FortiGate. Para ello, FortiGate cuenta con los perfiles de usuarios (Admin Profiles), donde podemos indicar qué privilegios tendrá cada grupo de usuarios:

• Asignaremos contraseñas de fortaleza alta a todos los usuarios.
• Activaremos el doble factor en todos los usuarios.
• Habilitaremos la restricción de acceso por host a la gestión de Fortigate.

Para ello, desde «System» – «Administrators», editaremos cada usuario y le aplicaremos la siguiente configuración:

• Contraseña: conviene establecer una contraseña de fortaleza alta, evitaremos evidentemente contraseñas por defecto, tipo «admin1234» y similares.
• Activaremos el doble factor de autenticación (Two-factor Authentication). Desde la consola web FortiGate únicamente admite activar el doble factor mediante FortiToken. Aunque, si no disponemos de FortiToken, podemos acceder a la consola y activar el doble factor por email.
• Restringir acceso a hosts específicos: en la opción Restrict login to trusted hosts, indicaremos únicamente las IP o rangos de IP que tendrán acceso a la gestión de FortiGate. Así reducimos considerablemente la superfice de exposición.

Configuración de hora y de envío de emails en FortiGate

Para tener la hora correcta en las consultas de log, configuraremos la zona horaria y el método de actualización de hora. Desde «System» – «Settings», estableceremos el Time zone y el tipo de actualización de la hora (normalmente NTP):

Si hemos optado por activar el doble factor por email y para recibir notificaciones, deberemos configurar el servicio de email. Para ello, desde «System» – «Settings», en «Email Service», configuraremos nuestro servidor SMTP: