Posted by Volvemos de vacaciones y continuamos con esta serie que esperamos os este gustando.
Para refrescar la memoria os dejo lo que hemos visto en esta serie hasta ahora:
NSX-T – Introducción y preparar el Laboratorio – Parte 0
NSX-T – Despliegue NSX Manager – Parte 1
NSX-T – Validación con VMware Identity Manager – Parte 2
NSX-T – Preparando la infraestructura – Parte 3
NSX-T – Creando segmentos, conectividad L2 – Parte 4
NSX-T – Desplegando EDGE – Parte 5
NSX-T – Configurando T1 y T0 Gateways – Parte 6
En esta parte 7 vamos a hablar de seguridad en concreto del Distributed Firewall.
En el apartado «Security» -> «East West Security» encontraremos el firewall distribuido, la detección de intrusión distribuida y servicios de network introspection Este-Oeste y en el apartado «Security» -> «North South Security» podemos configurar reglas de firewall, análisis de URL y servicios de network introspection Norte-Sur.
Vamos a analizar el Distributed Firewall.
El Distributed Firewall (DFW) se ejecuta en el kernel de todos los hypervisores que están preparados para NSX-T. La preparación del hypervisor activa automáticamente DFW.
El DFW proporciona visibilidad y control para redes y cargas de trabajo virtualizadas. Puede crear políticas de control de acceso basadas en objetos de vCenter, tales como Data Center, clúster, nombres y tags de máquinas virtuales, elementos de red tales como direcciones IP, VLAN, etc. También podemos usar grupos de Active Directory.
El Distributed Firewall monitoriza todo el trafico Este-Oeste de nuestras VM y nos aporta micro segmentación y aislamiento.
Aunque la VM se mueva entre hypervisores con vMotion las políticas de acceso se siguen aplicando sin la necesidad de reescribir las reglas del firewall, dado que el DFW está integrado en el hipervisor, esto ademas ofrece un mejor rendimiento al procesarse estas reglas a nivel de hypervisor, de manera que si un trafico de VM A en hypervisor A hacia VM B en hypervisor B no esta permitido directamente el trafico no saldrá del hypervisor origen.
La siguiente imagen muestra la diferencia entre un entorno sin DFW y uno con DFW.
Como hemos visto al configurar el T1 y asociarlo a nuestros 3 segmentos ya tenemos conectividad entre ellos 3.
Si queremos que solo se permita cierta conectividad entre Web y DB por ejemplo, ¿como lo hacemos?
Vamos a usar como ejemplo el servicio ssh (podríamos hacerlo con cualquier puerto o servicio), vamos a cortar toda conectividad entre Web y DB excepto el ssh.
Como vemos en la imagen, llegamos desde Web a DB por ping y por ssh.
Vamos a «Security» -> «East West Security» -> «Distributed Firewall» -> «ADD POLICY» .
Le damos el nombre JUST2KLOUD.
Vemos en la parte superior derecha que nos indica que tenemos cambios sin publicar, mientras no publiquemos no se distribuirá a los kernel de los nodos de transporte las políticas/reglas que definamos. Añadimos una regla.
Le ponemos como nombre STOP-WEB-DB.
Pinchamos en «Sources».
Añadimos los grupos necesarios ya que no teníamos ninguno creado. Empezamos con el grupo DB.
En «Compute Members» añadimos un «Criteria» para filtrar que VM formaran parte del grupo. Como vemos en la imagen nosotros hemos filtrado que el nombre de la VM contenga DB, pero os muestro mas opciones en el «Criteria 2» . Una forma muy útil a mi entender seria crear estos grupos en base a tags de vCenter.
Para el grupo Web hacemos lo mismo pero filtrando que el nombre contenga Web.
Ya tenemos creados los grupos y vemos que los miembros de los grupos son correctos.
Creados los grupos ya podemos seleccionar como «Source» el grupo Web.
En «Destination» el grupo DB.
Dejamos «Services» a «Any», y no seleccionamos ningún «Profile», «Applied to» lo dejamos en «DFW», como «Action» marcamos «Reject» y dejamos la regla habilitada.
Para que se distribuya la regla y se corte el trafico tenemos que publicar los cambios.
Volvemos a la VM Web y vemos que inmediatamente ya no se puede hacer ping o ssh a la VM DB.
Creamos una nueva regla en la política JUST2KLOUD para permitir el ssh, «Source» Web, «Destination» DB.
En «Services» filtramos por ssh y lo seleccionamos (si no viene predefinido el servicio podemos añadir uno nuevo).
No seleccionamos ningún «Profile», pero como veis se puede seleccionar un «Profile» que no es mas que aplicaciones con sus puertos necesarios predefinidos, por ejemplo CITRIX, DHCP, etc.
Ya tenemos definida la regla para habilitar el ssh desde Web a DB y la que corta el resto de comunicaciones. No olvidemos que ante cualquier cambia hemos de publicarlo.
Desde la VM Web vemos como el ping sigue sin funcionar pero el ssh ya esta permitido.
Las reglas se procesan de la siguiente forma:
- Se comprueban las reglas de arriba a abajo.
- Cada paquete se comprueba con la regla mas alta antes de seguir con las siguientes reglas en orden descendente.
- La primera regla que hace «match» con los parámetros de trafico es aplicada.
En esta parte 7 hemos visto con un ejemplo sencillo como crear políticas de acceso a nivel de DFW, en la parte 8 veremos como configurar un servidor DHCP.
Comparte si te gusta 🙂