Microsoft Azure: Instalación y Configuración de un Firewall Fortinet (Parte IV)

En este artículo vamos a ver como configurar la autenticación de los clientes VPN con AzureAD, además, de una configuración de No Split-Tunneling. Esto suele ser muy útil cuando queréis aplicar filtrados e inspección de tráfico del tráfico de los clientes VPN, tanto el que va hacia la red privada como el tráfico que va hacia internet porque todo pasará por el firewall.

Como añadido veremos como proteger el acceso a los servicios de O365 con reglas de acceso condicional, donde solo permitiremos la conexión a servicios de O365 desde una IP Pública de confianza (la de nuestro Firewall). Vamos a partir de las última configuraciones que ya tenemos implementadas:

• Microsoft Azure: Instalación y Configuración de un Firewall Fortinet (Parte I)
• Microsoft Azure: Instalación y Configuración de un Firewall Fortinet (Parte II)
• Microsoft Azure: Instalación y Configuración de un Firewall Fortinet (Parte III)

De tal forma que solo tendremos que realizar las siguientes configuraciones:

• Configuración aplicación en AzureAD para la autenticación de los clientes VPN
• Portal VPN sin Split-Tunneling
• Políticas de firewall para filtrado de contenido web e inspección de tráfico
• Políticas de ancho de banda para diferentes aplicaciones
• Regla de Acceso Condicional para securizar el acceso a servicios de O365

Como siempre, aquí os dejo la topología que vamos a desplegar:

Como había comentado anteriormente, no voy a comentar el paso a paso de la configuración de los clientes VPN porque ya lo he documentado en las anteriores partes de este artículo (arriba los enlaces), de ahí que me voy a en las nuevas configuraciones, empezamos:

1. Configuración aplicación en AzureAD para la autenticación de los clientes VPN

Para que los clientes VPN se autentiquen contra AzureAD primero debemos registrar la aplicación de FortiGate SSL VPN desde el Portal de Azure, nos vamos a la sección de Aplicaciones empresariales y buscamos FortiGate SSL VPN:

Una vez que la tenemos desplegada la tenemos que configurar, para ello vamos a la sección de Single sign-on y pulsamos en SAML:

Pulsamos en Edit

Cubrimos la URL con el nombre DNS del registro DNS que apunta a la IP Pública del firewall (esto ya lo habíamos hecho en el artículo anterior: Microsoft Azure: Instalación y Configuración de un Firewall Fortinet (Parte III)) y cuyos patrones son expuestos en la configuración:

Lo siguiente que debemos hacer es editar los atributos para que el firewall pueda identificar correctamente las consultas a realizar sobre usuarios y grupos, para ello en el sección de Attributes & Claims pulsamos en Edit:

pulsamos en Add new claim:

Debemos editar el atributo username para que quede como os muestro: user.userprincipalname, una vez completado pulsamos en Add a group claim:

Seleccionamos All Groups, marcamos la casilla Customize the name ot the groups claim y escribimos group o grupos, como vosotros queráis. Esto lo utilizará el firewall para mapear las diferentes consultas en el proceso de autenticación, una vez hayamos completado el proceso pulsamos en Save para continuar con la configuración.

Lo siguientes es descargarnos el certificado Certificate (Base64) y nos vamos copiando las URL de Login y Logout, además del Azure AD Identifier las cuales utilizaremos para completar la configuración del firewall:

Yo antes de salir del Portal de Azure me creará un nuevo grupo de seguridad, el cual utilizaré para definir quien podrá utilizar la aplicación que acabamos de registrar y por lo tanto definir que usuarios se podrán autenticar la conexión VPN.

Una vez crea del grupo volvemos a la aplicación registrada, vamos a la sección Users and groups y pulsamos en Add user/group:

Buscamos y seleccionamos el grupo que previamente hemos creado y lo agregamos:

En cuanto a la configuración en AzureAD esto sería todo lo que debemos hacer, se puede hacer más complejo, pero inicialmente es suficiente.

Una vez que hemos completado la configuración en AzureAD, tenemos acceder a la configuración del Firewall para importar el certificado que nos hemos descargado anteriormente. Para esto, nos vamos a System – Certificates y pulsamos en Create/Import y pulsamos en Remote Certificate:

pulsamos en Upload:

una vez seleccionado pulsamos en Ok:

Listo, ya tenemos nuestro certificado de AzureAD importado en el firewall

Ahora vamos a configurar la parte de autenticación vía cmd, aquí os dejo las líneas de código:

config user saml
edit azure
set cert “nombre-certificado-público-instalado-en-el-firewall”
set entity-id “https://sslvpn.dominio.como/remote/saml/metadata”
set single-sign-on-url “https://sslvpn.dominio.como/remote/saml/login”
set single-logout-url “https://sslvpn.dominio.como/remote/saml/logout”
set idp-entity-id “https://sts.windows.net/4ec76588-xxxx-xxxx-xxxx-1a1ff2523adf”
set idp-single-sign-on-url “https://login.microsoftonline.com/4ec76588-xxxx-xxxx-xxxx-1a1ff2523adf/saml2”
set idp-single-logout-url “https://login.microsoftonline.com/4ec76588-xxxx-xxxx-xxxx-1a1ff2523adf/saml2”
set idp-cert “Nombre-Certificado-Importado”
set user-name “username”
set group-name “group”
next
end

Pero esto mismo se puede hacer desde la interface gráfica del firewall desde la sección Single Sign-On desde User & Authentication:

Ahora nos vamos a crear un grupo que incluya esta configuración de autenticación, para ello vamos a User groups y pulsamos en Create New:

Escribimos el nombre para este grupo, seleccionamos Firewall en Type y luego en Add para añadir el remote server que nos habíamos creado anteriormente, en mi caso le he llamado Azure:

Esto que os voy a mostrar es opcional, porque podemos configurar diferentes grupos de usuarios utilizando el filtrado por grupos, para ello buscamos el object ID del grupo que he creado antes en AzureAD:

En en la configuración del grupo en el Firewall lo añadimos en la configuración del remote server:

Una vez que lo tengamos todo listo, pulsamos en Ok para crear nuestro grupo:

Ya tenemos nuestro grupo creado, el siguiente paso ya será agregarle un portal de autenticación y las diferentes políticas para definir que tráfico vamos a permitirle a los clientes VPN. 

En la sección SSL-VPN Settings es donde vamos a mapear el grupo con el portal al que queremos conectar:

Listo, otra parte de la configuración finalizada, solo nos quedaría las políticas de firewall donde queramos agregar a dicho grupo.

El detalle de su configuración lo he explicado en el artículo anterior (Microsoft Azure: Instalación y Configuración de un Firewall Fortinet (Parte III)), así que únicamente os muestro las reglas básicas que yo necesito para que los clientes VPN autenticados con AzureAD se puedan conectar:

Y ya por último nos queda configurar el cliente VPN y probarlo, aquí la configuración del cliente VPN:

Luego simplemente ese pulsar en SAML Login:

Nos mostrará una pantalla como la que muestro pero si hemos iniciado sesión previamente en el equipo con una cuenta del dominio o de AzureAD ya estaremos autenticandos:

Y listo, conectados autenticados vía AzureAD:

Si vemos los registros de inicio de sesión del usuario en cuestión, lo podemos ver claramente:

2. Portal VPN sin Split-Tunneling y políticas de firewall para filtrado de contenido web e inspección de tráfico

Con esta configuración, tenemos configurado Split-Tunneling, pero si ahora queremos monitorizar todo el tráfico de red de nuestros equipos estén o no dentro de las oficinas, también lo podemos hacer. Para esto, crearemos un portal VPN sin Split-Tunneling y así todo el tráfico de red pasará por nuestro firewall, para ello lo primero será crear un nuevo portal y deshabilitar el Split-Tunneling:

El grupo de autenticación cambiarlo de portal a este sin Split-Tunneling:

Y muy importante, como ahora todo el tráfico de red de los clientes VPN pasará por el Firewall tendremos que crear una regla que permite tener Internet a los clientes VPN. Aquí os muestro una regla sencilla, básica total pero que podáis entenderla de forma sencilla. Lo que tiene de particular es que si tenemos que habilitar NAT sobre esta regla y que la interface de salida de la regla ese la WAN no como hasta al momento que era la LAN.

Con esta configuración ahora los clientes VPN navegarán en Internet mediante nuestro firewall centralizado y claro, ahora se la aplicarán nuestros perfiles de seguridad (Web, Antivirus, Apps, etc..), así tendremos control sobre la navegación hacia Internet de nuestros usuarios.

3. Políticas de ancho de banda para diferentes aplicaciones

Una cosa que debemos tener en cuanta si tenemos a nuestros clientes saliendo a Internet mediante nuestro firewall es controlar el ancho de banda que utilizarán, porque claro, ahora todo sale por la conexión de Internet que tiene nuestro firewall. Si lo tenemos en algún Cloud público cuidado con esta configuración, porque si os cobran por el tráfico de salida (Azure, Amazon, etc..) vais a incurrir en un coste importante si tenéis muchos usuarios. Ahora bien, si es vuestra conexión de la oficina, pues es importante que controlemos que % de nuestro anchoa de banda utilizarán, sino tendremos el problema que agotaremos la conexión y tendremos problemas de rendimiento.

Teniendo claro el escenario en el que nos vemos, os voy a mostrar algo sencillo como es configurar una regla de Traffic Shaper para mantener un control sobre el flujo de datos en las aplicaciones que utilizarán nuestros usuarios. Yo únicamente os voy a mostrar una configuración sobre OneDrive, para ello desde la sección de Traffic Shaping de Policy & Objetcs nos creamos una nueva regla:

Ajustamos los parámetros en función de nuestras necesidades:

Ahora nos creamos una política sobre la cual aplicaremos la regla anterior, para esto, yo ya tengo creada una política pero os voy a mostrar su configuración:

Es muy sencilla, especificamos la interface de salida (WAN porque vamos a controlar OneDrive), el origen serán los clientes VPN, destino todos  y aplicación OneDrive. Por último, en la sección de Shared Shapper elegimos la configuración que hemos creado previamente:

Pues listo, ahora tenemos que ver como funciona, para ello nos ponemos a descargar algo de OneDrive desde un cliente VPN sin Splint-Tunneling…

Y desde el FortiView Traffic Shaping podemos ver que la regla se está ejecutando correctamente, como veis es muy sencillo mantener controlado el ancho de banda que utilizarán nuestros usuarios cuando estén fuera de la oficina.

4. Regla de Acceso Condicional para securizar el acceso a servicios de O365 (opcional)

Por último (en este artículo, pero opciones tenéis las que queráis), ya que tenemos el control sobre las conexiones de nuestros usuarios, podemos apretar un poquito más nuestro nivel de seguridad. Como todos los usuarios navegan de forma segura mediante nuestro firewall, o por lo menos de forma centralizada y monitorizada, podemos crear reglas de Acceso Condicional en Azure AD para que solo se puedan conectar a los servicios de O365 desde la IP Pública de nuestra oficina. Esto no lo voy a explicar con detalle, aquí os dejo un artículo en donde lo explico con todo nivel de detalle: Azure AD: reglas de acceso condicional (Ubicación + Azure AD Híbrido)

Pensad que ahora tenéis el control del tráfico de vuestros equipos, podéis manejarlo como queráis, además de inspeccionarlo y ayudar a proteger las conexiones de vuestros usuarios. Esta última configuración del Acceso Condicional también obligará si o si a los usuarios a conectarse a la VPN siempre, por lo que ya los tenéis administrados siempre sino no podrán acceder a los recursos corporativos internos y de O365.