Azure Firewall: Instalación y Configuración

Siguiendo con el último artículo sobre el emparejamiento de redes virtuales globalmente en Azure, me parecía oportuno introducir un artículo exclusivo sobre un Firewall en Azure. En este caso, voy a elegir del marketplace de Azure el Firewall de Microsoft y ver como podemos desplegarlo en nuestra red virtual.

Lo primero, veamos la topología con la que contamos y donde vamos a situar nuestro Azure Firewall:

Objetivo principal: implementar una solución de Firewall virtual para controlar el tráfico entre vNets emparejadas. Además, una vez conectadas crearemos algunos filtros para denegar ciertos servicios entre vNets.

Antes de creación de nuestro Azure Firewall, lo primero que debemos hacer (aunque podemos hacerlo en el momento de la creación del Firewall) es crear una subred para el Firewall, la cual tiene que llamarse AzureFirewallSubnet, para ello desde la vNet donde vayamos a situar el Firewall (en mi caso en la vNet que hará de Hub) tenemos que ir a la sección de Subredes y pulsar en + Subred:

Escribimos el nombre para esta subred, recordad que se tiene que llamar AzureFirewallSubnet, escribimos la subred donde vamos a situar el Firewall y pulsamos en Aceptar:

Y ahora ya tenemos nuestra subred preparada a la espera de ubicar nuestro Azure Firewall.

Con esto ya podemos iniciar el proceso de creación de nuestro Azure Firewall, el cual, podemos empezar desde la sección de Firewall dentro de la vNet, para ello pulsamos en Haga clic aquí para agregar un firewall

Una vez iniciemos el asistente de creación de nuestro firewall, únicamente debemos cubrir los datos que nos va solicitando:

• Nombre: nombre del firewall, algo sencillo y descriptivo
• Región: región de Azure donde vamos a situar nuestro firewall
• Red Virtual: elegimos donde ya hemos creado nuestra subred AzureFirewallSubnet
• Dirección IP Pública: sino tenemos ninguna creada y/o libre, podemos crearla pulsando en Crear nuevo

Nos solicitará un nombre para la IP Pública y una vez asignado ya tenemos nuestra IP, ahora pulsamos en Revisar y Crear para continuar:

Nos muestra un resumen de la configuración del Firewall que vamos a crear, si todo está correcto pulsamos en Crear

Ahora debemos esperar, en unos 5 minutos el proceso se habrá completado: 

Y una vez finalizada la implementación, pulsamos en Ir al recurso para iniciar su configuración inicial:

Una vez dentro de la configuración del Firewall, lo primero que nos muestra es un resumen de su configuración, en este caso tenemos a simple vista la IP Privada  y “oculta” la IP Pública.

Si pulsamos en la sección de Configuración de una IP Pública, podemos ver la IP que habíamos creado en el inicio del proceso, pero también tenemos la posibilidad de crear más de una dirección IP Pública.

Como ya estoy dentro del Firewall y, la primera configuración que quiero realizar es ofrecer conectividad entre las vNet que tenemos emparejadas con la vNet del Hub donde está el Firewall (revisad esquema inicial), pues vamos a ello. Desde la sección de reglas, nos vamos a la pestaña de Recopilaciones de reglas de red, que es el apartado donde vamos definir las reglas para permitir o denegar tráfico de red. Dicho esto, pulsamos en Agregar una colección de reglas de red:

La regla que yo quiero es permitir, como os he comentado, el tráfico entre las vNet de Spoke (172.17.0.0/16 y 172.18.0.0/16) pasando por el Hub que es con quien se han emparejado. Mi configuración es muy sencilla, porque quiero inicialmente permitir todo el tráfico de red en ambos sentidos desde el punto de vista del que origina el tráfico y que pasará por el Firewall.

Algo importante a tener en cuenta, es la Prioridad, como sabéis la reglas se “leen” de arriba a abajo, vamos, de menor a mayor prioridad, por lo que poner un número lo suficientemente alto que nos permita ir añadiendo reglas si así lo necesitamos:

Con esta regla de red, ya le indicamos al Firewall que permita las conexiones en ambos sentidos entre las vNets de Spokes:

Antes de poder tener tráfico entre las vNet debemos crear las diferentes Tablas de Rutas, en donde configuraremos como las diferentes subredes IP de cada vNet pueden ser alcanzables por cada una de las mismas. El proceso es muy simple:

• Crearemos una tabla de rutas (si las vNets están en diferentes regiones de Azure debemos crear una tabla para cada vNet)
• Crear las rutas
• Asignar la tabla de rutas a las diferentes subredes de cada vNet

Como he comentado, lo primero, crear la tabla de rutas, por lo que, desde el Marketplace de Azure buscamos Tabla de rutas y ahora pulsamos en Crear:

Una vez creada ya podemos ir a la sección de Rutas y pulsamos en +Agregar

Escribimos el nombre de la regla, la subred a la que queremos llegar y el host que nos puede llevar, en nuestro caso será el Dispositivo Virtual (Azure Firewall):

Y la Dirección del próximo salto es la IP privada del Firewall (la que hemos visto en la configuración inicial del Firewall) y pulsamos en Aceptar:

Y ya tenemos lista nuestra primera ruta

Una vez creadas las rutas, lo siguiente que tenemos que hacer es asociarla a una subred, para ello en la sección Subredes pulsamos en + Asociar

Elegimos la vNet donde estará la(s) subredes IP a la que queremos aplicar nuestra ruta

Y ahora elegimos la subred sobre la que aplicar dicha ruta, sólo podemos escoger una subred por solicitud, por lo que tenemos que ir asociando una a una las subredes:

Pulsamos en Aceptar

Como os comentaba, como yo tengo las vNet en diferentes regiones, no puedo una ruta a ambas vNet y aquí tengo mis dos tablas de rutas:

Y aquí os muestro la configuración de cada una de las tablas de rutas:

Como se puede apreciar, cada una de las rutas tienen como destino la subred IP de la vNet de destino y la IP del próximo salto la IP Privada de nuestro Firewall.

Pues ahora mismo ya tenemos conexión entre las diferentes vNet, para probarlo simplemente nos conectamos a alguno de los servidores de alguna de las vNet y tratamos de lanzar una conexión RDP hacia otro servidor. Como tengo los servidores apagados, lo primero, encender los que os muestro seleccionados y ahí tenéis las direcciones IP Privadas de cada servidor, se puede ver que están en las subredes IP de cada una de las vNet:

Imaginaros que estamos montando nuestro entorno, que no tenemos VPN para llegar a las máquinas virtuales mediante las dirección privadas y que no queremos asignar direcciones IP públicas en ningún caso. La solución que nos queda es publicar el puerto del RDP (sólo a modo prueba) de alguno de los servidores mediante reglas de NAT en nuestro Firewall.

La configuración es muy sencilla, en la configuración del Firewall en la sección de Reglas, debemos pulsar en Agregar una conexión de reglas de NAT desde la pestaña de Colección de reglas de NAT:

Como vemos, es muy sencillo configurar una regla:

• Nombre: escribimos un nombre para este grupo de reglas, como la idea es agrupar las diferentes reglas, yo voy a utilizar esta para las conexiones RDP
• Prioridad: lo de siempre, menor número mayor prioridad, dejar margen por encima y por debajo para crear reglas

Ahora debemos cubrir los datos de la publicación de uno de los servidores vía RDP, aqui los campos a cubrir:

• Nombre:  yo voy a escribir el nombre del servidor al que le haré la publicación
• Protocolo: en función del servicio debemos elegir el protocolo a utilizar, en el caso del RPD es TCP
• Direcciones de Origen: podemos especificar la dirección IP de origen de la conexión, por lo que podríamos filtrar por IP de origen de la conexión
• Direcciones de Destino: aquí debemos escribir la dirección IP Pública por la que vamos a realizar la publicación y tiene que ser una de las IP Públicas que tenemos asociadas al Firewall
• Puertos de destino: puerto a la escucha en la IP Pública, en mi caso dejaré el por defecto: 3389
• Dirección traducida: dirección IP Privada del servidor al que nos queremos conectar desde Internet
• Puerto traducido: puerto al que enviaremos la conexión al servidor publicado, en mi caso el RDP por defecto: 3389

Si queremos publicar más servidores, debemos ir agregándolos en las filas que vamos creando hacia abajo. OJO, nada que decir que sí solo tenemos una IP Pública en el Firewall no podemos publicar otra conexión RDP escuchando (parte pública) en el mismo puerto que otro servicio publicado.

Una vez creada la regla, ya la tenemos disponible en la sección de reglas del Firewall

Ahora toca probarlo, iniciamos una conexión RDP (mstsc) y escribimos la dirección IP Pública como servidor de destino y pulsamos en conectar:

Y ahora desde dentro del servidor publicado, vamos a intentar conectar vía RDP hacia otro servidor de otra vNet atravesando para ello el Firewall que hemos creado. Como podemos apreciar, podemos conectarnos sin problema!! Pero sin embargo no tenemos tráfico ICMP (ahora os lo cuento)

Como vemos, estamos dentro del servidor de la otra vNet

Como os comentaba en el punto anterior, no tenemos tráfico ICMP, pero eso es por “culpa” del Firewall de Windows que nos lo está bloqueado, para permitir el tráfiico ICMP tenemos el siguiente cmdlet: Enable-NetFirewallRule -Name FPS-ICMP4-ERQ-In

Y aquí os muestro dos muestreos con paquetes icmp, como vemos una vez habilitado en los servidores ya responden sin problema

Por último y para completar esta iniciación sobre la configuración del Firewall, crearé una regla de red que deniega la conexión RDP desde una subred (172.17.0.0/16) hasta un host (172.18.2.4). La regla es sencilla, como las anteriores pero en este caso quiero denegar un tráfico específico y ojo, mirad la prioridad, he puesto 100 para que sea la primera red que se aplique para que tenga efecto y no sea invalidad por la otra regla que permite el tráfico completo entre subredes:

Aquí vemos ambas reglas, como vemos la prioridad es 100 con respecto a la de 1000  que permite todo el tráfico entre vNets

Si ahora lanzamos un test de conexión vía PowerShell (Test-NetConnection -Computername 172.18.2.4 -Port 3389)

Y como vemos, el Firewall está haciendo su trabajo y está bloqueado la conexión RDP que antes nos funcionaba sin problema!

Por último, como todos sabemos, casi todos los servicios de Azure son pagoXuso, vamos, que si tenemos el servicio activo nos cobran (coste Firewall 744 horas (un mes entero) unos 700€) por ello. En en este caso, para realizar diferentes pruebas, lo que podemos hacer es desconectarlo, esto sólo podemos hacerlo vía PowerShell:

Deallocate (desconectar):
$azfw = Get-AzureRmFirewall -Name “Nombre-Firewall” -ResourceGroupName “Nombre-Grupo-Recursos”
$azfw.Deallocate()
Set-AzureRmFirewall -AzureFirewall $azfw

Allocate (iniciarlo):

$azfw = Get-AzFirewall -Name “Nombre-Firewall” -ResourceGroupName “Nombre-Grupo-Recursos”
$vnet= Get-AzureRmVirtualNetwork -ResourceGroupName “Nombre-Grupo-Recursos” -Name “Nombre-Red”
$publicip= Get-AzureRmPublicIpAddress -Name “Nombre-IPPublica” -ResourceGroupName “Nombre-Grupo-Recursos”
$azfw.Allocate($vnet,$publicip)
Set-AzureRmFirewall -AzureFirewall $azfw

Esto es súper interesante tenerlo en cuenta, claramente, para entornos de prueba donde no queremos llevarnos una sorpresita a final de mes.

Pues hasta aquí ha llegado la primera configuración de nuestro Azure Firewall, en próximos artículos iremos viendo más configuraciones.

Espero que os sirva de ayuda, ahora os toca a vosotros probarlo!!