Azure Virtual Desktop: utilizando AppLocker y NSG para securizar tus sesiones remotas

Con el auge del teletrabajo, cada día tenemos más usuarios teletrabajando y conectándose remotamente para acceder a los datos corporativos. Cada día para el equipo de IT se vuelve un reto más complejo el securizar dichos accesos, aunque ya tenemos y utilizamos múltiples configuraciones de seguridad:

• VPN
• MFA
• Azure Virtual Desktop  / Citrix, etc…

Casi todo va asociado a cifrar el tráfico de red (VPN, TLS), asegurar la identidad del usuario que se conecta (MFA) u ofrecer un sistemas de acceso remoto a entornos con sesiones completas de nuestros usuarios (AVD, Citrix). Hasta aquí, todo correcto, pero… ¿Qué ocurre con la seguridad de las sesiones de usuarios? Al fin y al cabo, los usuarios utilizan diferentes herramientas/aplicaciones las cuales también debemos preocuparnos por proteger. Además, claramente, de que los usuarios tengan acceso única y exclusivamente a la información en función de su rol dentro de cada empresa y no más allá de sus límites. Desde acceso a carpetas de red hasta aplicaciones de negocio, las cuales, muchas de ellas no tienen soporte para funcionar adecuadamente en entornos WAN (por seguridad o rendimiento) y nos vemos obligados a ejecutarlas localmente en las sesiones remotas.

Hoy me gustaría ver algunas configuraciones las cuales podemos aplicar para tratar de minimizar el riesgo en nuestros AVD, en donde tendremos a nuestros usuarios conectados y debemos tratar de proteger sus sesiones. La idea es aplicar diferentes configuraciones:

• Red: aplicar NSG a la subred donde tengamos nuestros AVD evitando accesos a nivel de red innecesarios, tanto a nivel de ADDS como de acceso a otros servicios/servidores de nuestro entorno de Azure.
• Aplicaciones: definiremos la protección de aplicaciones mediante AppLocker a nivel de firma y ubicación de los ejecutables, evitando que los usuarios puedan hacer ejecución de de aplicaciones no permitidas.

La idea es que los usuarios puedan iniciar sesión en nuestros AVD, que solo tengan tráfico de red expresamente definido en nuestros NSG a nivel de subred, evitando accesos de red innecesarios. Además, evitar que puedan ejecutar aplicaciones que no sean explícitamente permitidas. Por último, una configuración de GPO que permita definir un entorno de escritorio simplificado y blindando ciertos accesos por parte de los usuarios a la modificación  de su sesión.

Antes de iniciar las configuraciones oportunas, os muestro una infografía de un entorno de AVD con los NSG y las reglas sencillas:

Vamos a detallar algo más el entorno en cuanto a nuestras vNet:

• vNet de Hub: vNet donde tenemos los servicios corporativos centralizados: Firewall, ADDS, Bastion, etc… desde ahí controlamos y damos servicios comunes a todas las vNet emparejadas
• vNet de Spoke: vNets donde tenemos los diferente servicios, desde servidores de ficheros, aplicaciones y nuestros AVD. Los AVD los hemos puesto en diferentes vNet, lo que nos permite definir diferentes emparejamientos de red y NSG.

Lo primero que mostraré será la configuración de las NSG para filtrar el acceso desde los AVD hacia las vNet donde tenemos nuestros controladores de dominio,  que en este caso será el único tráfico que vamos a permitir desde los AVD. Pero antes de esto, os voy a dejar algunos artículos sobre emparejamiento de redes, firewall de Azure y otros artículos que creo que os serán de utilidad para comprender mejor el escenario desplegado y las diferentes configuraciones:

• Azure: Balanceador de carga interno y Azure Firewall
• Redes Azure: Emparejamiento de redes virtuales globales
• Azure Firewall: Instalación y Configuración
• Azure Firewall: Internet Centralizado por Hub, Emparejamiento y Conexión vía VPN con On-Premises
• Azure Firewall: Centralizar la salida a Internet de las vNet
• Redes Azure: Emparejamiento de redes virtuales globales
• Redes Azure: Emparejamiento de redes virtuales ubicadas en diferentes suscripciones
• Azure MFA: Acceso Condicional
• Bloquear aplicaciones desde AzureAD
• Azure AD: reglas de acceso condicional (Ubicación + Azure AD Híbrido)
• Moviendo nuestros servicios y máquinas virtuales a Azure (Parte IX)
• Conexión VPN + RADIUS + AzureMFA + Enrutamiento IP
• Conexión VPN con autenticación RADIUS + AzureMFA
• Acceso Remoto: Topología y Servicios

Antes de comenzar con el resto de artículo, comentar que esto es para entornos más humildes en cuanto a infraestructura. Realizaremos configuraciones utilizando los servicios “básicos de Azure”, por ejemplo, no utilizamos un NVA o Firewall de Azure, sino que para controlar los flujos de tráfico de red entre vNets lo haremos configurando NSG específicas aplicadas a diferentes subredes.

Pues ahora sí, lo primero que haremos será configurar un NSG la cual asociaremos a la subred donde están nuestros AVD y permitir únicamente el acceso a nuestro ADDS. Es importante que tengamos claro que puertos son necesarios que permitamos para conectarnos a nuestro ADDS: https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/config-firewall-for-ad-domains-and-trusts:

Client Port(s)	Server Port	Service
49152-65535/UDP	123/UDP	W32Time
49152-65535/TCP	135/TCP	RPC Endpoint Mapper
49152-65535/TCP	464/TCP/UDP	Kerberos password change
49152-65535/TCP	49152-65535/TCP	RPC for LSA, SAM, NetLogon (*)
49152-65535/TCP/UDP	389/TCP/UDP	LDAP
49152-65535/TCP	636/TCP	LDAP SSL
49152-65535/TCP	3268/TCP	LDAP GC
49152-65535/TCP	3269/TCP	LDAP GC SSL
53, 49152-65535/TCP/UDP	53/TCP/UDP	DNS
49152-65535/TCP	49152-65535/TCP	FRS RPC (*)
49152-65535/TCP/UDP	88/TCP/UDP	Kerberos
49152-65535/TCP/UDP	445/TCP	SMB (**)

Como nuestro NSG la voy a aplicar a la subred de la vNet donde tengo los AVD, las reglas serán de salida de la subred:

A continuación, os explico las reglas de salida en función de su prioridad:

• 100: permitimos el tráfico de ADDS hacia los Controladores de Dominio (172.17.10.4 y 172.17.10.5)
• 110: permitir tráfico SMB (445/TCP) hacia un servidor de ficheros específico (172.16.14.4)
• 120: como no contamos con un firewall avanzado (que sería lo suyo), esta regla permite el tráfico web (http y https) y SMTP (cliente) hacia Internet (destino)
• 500: denegamos el resto de tráfico hacia el resto de subredes locales y remotas (VPN)

Con estas reglas aplicadas a la subred AVD, permitimos exclusivamente el tráfico de red que hemos definido en la reglas:

Con esto, sin ser nada top a nivel de configuración de firewall, por lo menos evitamos que si tenemos algún problema en alguna de las MV de AVD genere tráfico de red hacia otras subredes emparejadas a las que no deberíamos tenerlo. Solo permitimos que los usuarios conectados a los AVD protegidos, tienen acceso al ADDS para iniciar sesión, acceso al servidor de ficheros e Internet. Aquí, lo suyo sería que, la navegación a Internet la tuviéramos controlada mediante firewalls que lleguen a capa 7 y así definir reglas específicas permitiendo solo acceso a determinados sitios web (Office 365, etc..). Pero bueno, sino lo tenemos, por lo menos evitar conexiones a otros puertos, que si bien no es la panacea (porque al final el malware, etc.. va por el puerto 443 sin problema .. pero sino tenemos otra cosa ..). Si tenemos la posibilidad de configura un Firewall  que llegue a capa 7, puesto perfecto, tanto a nivel de inspección como de control sería lo suyo.

 Una vez que, a nivel de red tenemos el “trabajo hecho”, tenemos que empezar con la securización de las sesiones remotas ya dentro nuestros Windows 10 Enterprise (100% actualizados). Vamos a realizar varias configuraciones vía GPO:

• Gestionar entorno del usuario:
  • OneDrive
  • Escritorio
  • Menú Inicio y Barra de Tareas
  • Panel de Control
  • Etc…
• Gestión de aplicaciones vía AppLocker: permitir únicamente las aplicaciones de Office que queramos utilicen los usuarios y las aplicaciones de negocio y/o adicionales que queremos que ejecuten los usuarios.

En cuanto a las configuraciones de usuarios, yo siempre busco un equilibro entre el “automatismo” (configuración automática de aplicaciones y entorno), la seguridad (ejecución de sesiones) y las configuraciones monolíticas (evitar que el usuario modifique su entorno). Aquí os dejo algunas de las configuraciones de entorno aplicadas a los usuarios:

Hay muchísimas configuraciones más, pero bueno, es porque tengáis alguna referencia de alguna de ellas. A continuación, os muestro el entorno de sesión de los usuarios:

1.  Menú de inicio 100% personalizado, bloqueado evitando que los usuarios puedan añadir o quitar los iconos que les presentamos
2. Barra de tareas personalizada
3. Acceso directo creado mediante una GPO, en función del grupo de seguridad al que sea miembro cada usuario.

El resto de configuraciones son:

• Autoconfiguración de OneDrive: inicio de sesión automático, bloqueo de cuentas que no sean del dominio de AzureAD de la empresa, configuración de “backup” de las carpetas de OneDrive de forma silenciosa, etc..
• Panel de Control: acceso exclusivo a 4 iconos (Configuración regional, teclado, ratón y Outlook)
• Bloqueo de acceso ejecutar aplicaciones con sesiones secundarias
• Bloqueo CMD y Registro
• Etc…

Con esto, tenemos un entorno común para los usuarios que inician sesión en nuestros AVD, además de cierto control sobre la gestión de sus entornos.

Ahora, por “último” vamos a aplicar ciertas configuraciones de AppLocker (+info sobre AppLocker AppLocker (Windows) – Windows security | Microsoft Docs), donde configuraremos las aplicaciones que vamos a permitir explícitamente para los usuarios que inician sesión en los AVD y son miembros de ciertos grupos de seguridad de nuestro ADDS. Antes de nada, comentar que, para implementar AppLocker las versiones de Windows deben ser las Enteprise. Esto con los AVD es viable, puesto que son versiones de Windows 10 Enterprise. Dicho esto, voy a tratar de resumir lo importante de la configuración de AppLocker para evitar posible problemas de configuración (que he ido sufriendo).

Insisto, sin entregar en grandes detalles sobre AppLocker porque sino sería un artículo enorme, me voy a centrar en las configuraciones que os recomiendo. Lo primero, habilitar  las reglas que vamos a configurar en modo Enforce Rules, de tal forma que se apliquen las configuremos que luego iremos configurando:

Ahora, configuraremos una regla de Packaged app Rules:

Con las opciones por defecto, no tenemos ni debemos tocar nada más inicialmente:

Se puede hacer excepciones, pero ahora mismo, no las configuraremos.

Esta configuración es la necesaria para que pueda funcionar el botón de inicio de Windows, sin ella, los usuarios no tendrán posibilidad de activar el botón de inicio de Windows. Ahora, os voy a mostrar una serie de reglas esenciales para proteger las sesiones de nuestro usuarios.  Pero antes de mostraros el detalle de cada una de ellas, veamos como crear una regla:

Si queremos aplicar la regla solo a un grupo determinado del ADDS, pues aquí lo añadiremos, pulsamos en Select y añadimos el grupo en cuestión, una vez seleccionado pulsamos en Next:

Aquí estamos en la parte clave, debemos elegir la condición a definir:

• Publisher: muchas aplicaciones (no todas ni mucho menos), tienen información sobre la empresa que ha creado el software
• Path: definimos la ruta que vamos a permitir o no ejecutar las aplicaciones que estén dentro de dicha ruta
• File hash: en función del hash del archivo

Yo voy a elegir Publisher y pulsamos en Next:

Para este artículo, voy a mostraros esta configuración con las aplicaciones de Office. Como veis, he elegido Outlook.exe y vemos la información de publicador que contienen la aplicación:

Podemos ir ajustando la configuración en función de nuestras necesidades, porque podemos querer que se ejecuta una versión en concreto de Outlook y el resto se denegaría.

Para este caso, voy a llegar hasta el nombre de aplicación y la versión de Publisher (obviando la versión de la aplicación y el nombre del ejecutable)

Pues esta configuración es la que podemos ir configurando con el resto de aplicaciones de Office,, las cuales veis en la siguiente captura:

• Microsoft OneDrive (Firma)
• Microsoft Teams (Firma)
• Microsoft Office (Firma)

Ahora he creado una regla por ruta de ficheros:

• Acción: denegar
• Usuarios: grupos de usuarios que iniciarán sesión en el AVD
• Condición: ruta (%osdrive%\Users\*)

Esta regla evitará que el usuario inicie ejecutables en cualquier ruta de su perfil local (muy importante):

Una de las dos reglas creadas por defecto, la que permite la ejecución de aplicaciones en %WINDIR%\* he creado una excepción (se permite todo menos las aplicaciones definidas en las excepciones), de tal forma que bloqueamos la ejecución de las aplicaciones que queramos, en mi caso las líneas de comandos en CMD y Powershell, además del acceso al registro de Windows:

Ahora, otra regla por defecto e importante, es la ejecución de aplicaciones en %PROGRAMFILES%\*, he cambiado la acción por defecto a bloquear:

Y en las excepciones añado las aplicaciones que si quiero que los usuarios puedan ejecutar:

• 7Zip por ejecutable
• Office por firma

A continuación, os muestro la configuración de las reglas que permiten la ejecución de las aplicaciones de Office, Teams, OneDrive, etc…

Ahora, para que todo esto funcione, debemos configurar en la misma GPO (u otra) que se inicie el servicio de Application Identity, sino, las directivas no se aplicarán. Para ello, editamos la GPO en cuestión y configuramos que el servicio de Application Identity se inicie automáticamente:

Las directivas de AppLocker son a  nivel de equipo, por lo que todos los usuarios que inicien sesión en los AVD se verán condicionados por la GPO [importante filtrar las reglas por grupos de seguridad]

Ahora si, con esta última configuración ya lo tenemos todo, ya podemos probar  que todo funciona según lo esperando con alguna sesión de usuario. Aunque las aplicaciones las tenía como excepción en la regla que prohibía la ejecución de las aplicaciones en %PROGRAMFILES%\*, he tenido que crear reglas específicas por aplicación sino no había manera de que el usuario las pudiese ejecutar. Con estas reglas, el usuario puede acceder a las aplicaciones permitas y el resto son denegadas:

• Se deniega el acceso a PowerShell

• Se permite la ejecución de Word

Como vemos, es muy potente (nada es 100% infalible, pero os ayudará muchísimo) y sencillo de configurar. Debéis tener algunas cosas claras:

• Permitir la ejecución de Packaged app Rules para disponer del Menú Inicio
• Permitir la ejecución de aplicaciones con la regla por defecto [All files located in the Windows folder] que permite la ejecución de aplicaciones en la ruta %WINDIR%\* y luego jugar con las excepciones, que serán las aplicaciones que vas a denegar. Sino lo haces así, tendrás problemas con las sesiones de los usuarios, porque muchos ejecutables de la gestión de sesiones está en %WINDIR%\*.
• Prohibir la ejecución de aplicaciones en la regla All files located in the Program Files folder, de esta forma evitamos que pueda ejecutar alguna aplicación instalada, luego, tendrás que jugar con las excepciones para permitir las aplicaciones que quieras que los usuarios puedan ejeuctar.
• En las reglas en las cuales permites la ejecución de aplicaciones, siempre que puedas, define como condición de la regla que sea por publicador de la aplicación.

Con estas premisas yo no he tenido problema con la definición de AppLocker, pero hasta que he dado con la combinación “ideal”, he tenido múltiples permisos de ejecución, entorno, etc…

En siguientes artículos iremos detallando más configuraciones de AppLocker, ahora, mientras tanto, os toca probarlo a vosotros!!!