Cerrar
InicioAzureMicrosoft Azure: Instalación y Configuración de un Firewall Fortinet (Parte Final)

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

Para empezar el año que mejor que terminar los artículos sobre la implementación de un firewall Fortinet en Azure. Este será un artículo sencillo sobre las reglas “por defecto” que podemos crear para darle salida a la red pública a nuestras vNet, todo ello en función de los servicios que tengamos en cada una de ellas. Antes de continuar, os dejo los artículos anteriores a este donde he ido explicando paso a paso el proceso de implementación de distintos servicios:

Será un artículo muy sencillo, rápido y directo, el cual creo que os permitirá haceros una idea de por donde empezar cuando despleguéis vuestro firewall en Azure (o cualquier otro entorno). Aquí os dejo la última infografía de esta serie de 5 artículos:

Como os he comentado, será un artículo breve y sencillo, simplemente será una pequeña introducción a las reglas “por defecto” que creo que deberíamos aplicar para controlar la salida a Internet de nuestro entorno. En función de cada topología será más o menos complejo, aquí la idea es:

  • Segmentar nuestras redes: crear vNet (virtual networks) o sNets (subnets) por servicio a implementar, como serían servidores de bases de datos, de correo, aplicaciones web, servidores de ficheros. Esto nos permitirá, luego de forma sencillo crear reglas de firewall más sencillas.
  • Confianza 0: permitir exclusivamente los servicios y/o protocolos que permitan el funcionamiento de nuestro entorno, nunca exponernos a riesgos innecesarios por el hecho de “facilitarnos los accesos”. Aplicar los servicios de seguridad disponibles para cada regla de vuestro firewall:
    • Control de aplicaciones
    • Filtrado Web
    • IPS
    • AV
    • DNS Filter
    • Etc..

Hay más configuraciones que deberíamos tener en cuenta, pero creo que para empezar, esto sería lo básico. Si segmentamos bien nuestro entorno, tendremos diferentes capas nos permitirán aislar las cargas de trabajo de forma sencilla. Al disponer de diferentes subredes, las reglas en nuestro firewall serán más fáciles de gestionar al poder crear objetos con subredes completas (esto es básico).

Luego, en función de los servicios que tengamos en cada vNet o sNet, tendremos que crear nuestra reglas para permitir únicamente el tráfico de red necesario para que el funcionamiento sea óptimo. Esto permite tener los servicios más controlados y poder realizar reglas “sumarizadas” (si, si, al estilo de la creación de subredes), esto minimizará la cantidad de reglas a crear y tendremos menos errores su definición.

Voy a “mostraros” un ejemplo al respecto, imaginaros que vuestra red tenéis desplegado un Active Directory, si queréis que vuestros equipos tengan conexión a internet, ¿Quién debería tener permitido el acceso a consultas DNS de fuera de nuestra red? tic, toc, tic, toc, tic, toc .. pues únicamente a vuestros controladores de dominio!!! Además, solo permitiendo la consultas a los root que tienen configurados por defecto o si utilizáis los reenviadores pues solo consultas a dichos reenviadores.  Como tenemos a todos nuestros controladores de dominio en la misma sNet, simplemente con una regla muy sencilla tendréis súper controlado dicho servicios:

  • Origen: sNet de controladores de dominio
  • Destino: vuestros roots DNS o reenviados
  • Servicio: DNS

Esto que parece una chorrada, pero evitará que si por cualquier motivo vuestros controladores de dominio se ven comprometidos, lancen consultas DNS a servidores maliciosos y que pueda generaros un problema importante. Entiendo que tenéis claro que vuestros equipos unidos al dominio, los únicos servidores DNS que tienen que tener configurados son vuestros controladores de dominio, tanto para las consultas internas al dominio como para consultas a internet. 

Pues bien, al igual que esta regla, tendremos que ir creando tantas como vayamos necesitando en función de lo que queramos ir securizando. Imaginad que vuestro esquema es como el que os he puesto al principio del artículo, con las siguientes vNets (el número que muestro es el número que coincide con el del esquema):

  1. Servidores bases de datos y ficheros: NO necesitan acceso a internet más que para actualizar su software (sistema operativo y aplicaciones)
  2. Aquí tenemos diferentes sNets: aquí tendríamos una regla para permitir las consultas DNS a la sNet1
    1. sNet 1: controladores de dominio los cuales necesitan únicamente poder realizar consultas DNS a sus reenviadores
    2. sNet 2: servidores de Radius los cuales NO necesitan acceso a internet
    3. sNet 3: servidores web los cuales NO necesitan acceso a internet 
  3. Usuarios de AVD “para aplicación securizada”: podrían ser usuarios que tienen que tener acceso a una aplicación de escritorio con un nivel de seguridad mayor, por lo que decidimos no darle acceso a internet a esas máquinas fuera de los límites de los servicios de O365.
  4. Usuarios de AVD:  si tenemos usuarios que  se conectan a nuestra organización y queremos únicamente darle acceso a Internet pero con filtrado Web fortificado

Para poder llevar a cabo esta configuración, pensad que tenemos que hacer tres reglas, puesto que para no permitir acceso a Internet a una subred no debemos hacer nada. Por defecto, los firewall tienen una regla por defecto que bloquea todo, por lo que, sino tenemos regla que permita algo de forma explícita, no tendremos acceso :-).

Pues poco más la verdad, ya os había comentado que sería un artículo muy sencillo y rápido. Espero que por lo menos os quedéis con la idea de lo que quiero expresar, sobre todo en el ejemplo del DNS que me parece muy ilustrativo de lo que a veces los técnicos obvian y no debería ser así. Pero al igual que el DNS, el resto de servicios, pero el DNS tiene esa particularidad de su propio funcionamiento y por eso siempre lo pongo como ejemplo.

Espero que os haya gustado y os sirva para poder empezar a replantearos muchas cosas, al final todos hemos tenido un inicio para todo :-).

 

 

Microsoft Azure: Ins
Microsoft Intune: In
NO HAY COMENTARIOS

DEJA UN COMENTARIO

Este sitio web utiliza cookies. Si continúas navegando, consideramos que aceptas su uso. Puedes obtener más información en nuestra política de cookies. ACEPTAR

Aviso de cookies
Share This