Source: http://docs.hol.vmware.com/HOL-2019/localization/manuals/es/hol-1903-02-net_html_es/
Timestamp: 2019-06-26 04:40:40+00:00

Document:
Hands-on Labs de VMware - HOL-1903-02-NET
Descripción general del laboratorio HOL-1903-02-NET: Firewall distribuido y microsegmentación de VMware NSX
Módulo 1: Descripción general de Service Composer y del firewall distribuido (45 minutos)
Descripción general de firewall distribuido con microsegmentación
Descripción general de grupos de seguridad
Descripción general de políticas de seguridad
Módulo 2: Revisión de la función de contracción de aplicaciones de 3 niveles (15 minutos)
Protección de arquitecturas contraídas con la competencia de firewall distribuido de NSX
Inicio de sesión en las máquinas virtuales con finalización del soporte técnico
Límite del acceso de VM
Verificación del acceso limitado desde VM con Windows XP
Módulo 4: Seguridad basada en el usuario con un servidor de seguridad (45 minutos)
Seguridad basada en el usuario en un escenario de servidor de seguridad
Servicio de introspección de invitados de NSX
Uso de objetos de seguridad basado en grupos de AD
Definición de reglas de firewall para aplicaciones internas
Módulo 5: NSX Application Rule Manager (30 minutos)
Introducción a Application Rule Manager
Módulo 6: Resolución de problemas y mantenimiento de NSX (30 minutos)
Descripción general de la resolución de problemas y la creación de respaldos con vRealize Network Insight en NSX
Práctica en laboratorio: resolución de problemas y creación de respaldos con vRealize Network Insight en NSX
Descripción general de NSX Data Center con NSX-PowerOps
Práctica en laboratorio: NSX Data Center con NSX-PowerOps
Conclusión del módulo 6
En este laboratorio, exploraremos casos de uso de VMware NSX y microsegmentación, incluidas revisiones más detalladas del firewall distribuido y de la interfaz de usuario (User Interface, UI) de Service Composer. Los casos de uso incluyen soluciones de contracción de redes segmentadas, agrupación inteligente de servidores y seguridad basada en el usuario.
(45 minutos). Básico. En este módulo, se analizarán los conceptos de firewall distribuido y la creación de reglas de firewall en una aplicación de tres niveles con Service Composer.
(15 minutos). Básico. En este módulo, se revisarán los aspectos principales sobre la migración de una aplicación de 3 niveles a una arquitectura contraída de un solo nivel.
(30 minutos). Básico. Con este módulo aprenderá cómo NSX puede ayudarlo a proteger aplicaciones y máquinas virtuales por medio de una inclusión dinámica con grupos de seguridad.
(45 minutos). Básico. En este módulo, se mostrarán las competencias de la función Identity Based Firewall y cómo puede proteger la integración con Active Directory.
(45 minutos). Básico. En este módulo, se mostrará cómo usar la microsegmentación de aplicaciones con Application Rule Manager.
(30 minutos). Básico. En este módulo, se analizarán la resolución de problemas y los respaldos de NSX con vRNI, además de ejemplos de tareas de NSX Power OPs.
Módulos 1 a 6: James Emmons, Staff Technical Account Manager, NSX Technical Account Specialist, Estados Unidos
El firewall distribuido (Distributed Firewall, DFW) de NSX es un firewall incorporado en el kernel del hipervisor que proporciona visibilidad y control de las cargas de trabajo y las redes virtualizadas. Puede crear políticas de control de acceso según los objetos de VMware vCenter como los centros de datos, clústeres y nombres de las máquinas virtuales; estructuras de red como protocolo de Internet (Internet Protocol, IP) o conjuntos de IP, VLAN (grupos de puertos del switch virtual distribuido [Distributed Virtual Switch, DVS]), VXLAN (switches lógicos), grupos de seguridad e identidad de grupos de usuarios desde Active Directory. Las reglas de firewall se cumplen en el nivel de la tarjeta de interfaz de la red virtual (Virtual Network Interface Card, vNIC) de cada máquina virtual para proporcionar un control de acceso coherente incluso cuando la máquina virtual se desplaza con vMotion. La naturaleza integrada en el hipervisor del firewall ofrece una tasa de transferencia aproximada a la tasa lineal para posibilitar una mayor consolidación de las cargas de trabajo en los servidores físicos. La naturaleza distribuida del firewall proporciona una arquitectura de escalabilidad horizontal que automáticamente extiende la capacidad del firewall cuando se incorporan hosts adicionales a un centro de datos.
La microsegmentación cuenta con tecnología del componente del firewall distribuido (DFW) de NSX. El DFW opera en la capa del kernel del hipervisor ESXi y procesa paquetes a una velocidad casi de línea. Cada VM tiene sus propias reglas de firewall y su propio contexto. La movilidad de las cargas de trabajo (vMotion) es completamente compatible con el DFW, y las conexiones activas permanecen intactas durante el traslado. Esta competencia de seguridad avanzada protege aún más la red del centro de datos, ya que aísla cada grupo relacionado de máquinas virtuales en un segmento de red lógica diferente, lo que permite al administrador aplicar el firewall al tráfico que se traslada desde un segmento del centro de datos a otro (tráfico horizontal). Esto le impide al atacante moverse en sentido lateral en el centro de datos.
Seguridad lógica con Service Composer
Revise y cree un grupo de seguridad para máquinas virtuales (Virtual Machines, VM) que esté definido por membresía dinámica.
Revise, cree y aplique una regla de firewall al grupo de seguridad por medio de una política de seguridad.
Service Composer Canvas ya no está disponible en las versiones 6.4.x de NSX. Visite el siguiente enlace para obtener más información: https://tinyurl.com/y9fe6w8v.
En NSX 6.4, se agregó una nueva funcionalidad de capa 7 mediante la incorporación en los hosts de ESXi de un nuevo paquete de instalación de VMware (VMware Installation Bundle, VIB) que analiza los flujos de tráfico. Con este nuevo cambio, se puede reconocer el número de ID de la aplicación desde dentro del tráfico de red. Por ejemplo, versiones de TLS, SMB, SSH, RDP, DNS, KMS y AD entre otros.
Comience el módulo desde el escritorio. El escritorio es el servidor de seguridad del centro de control en el entorno virtual. Desde este escritorio, podrá acceder a vCenter Server Appliance que se implementó en el centro de datos virtual. Otra tarea importante es guardar los cambios cada vez que se cree una regla de firewall.
Nota especial: En el escritorio, encontrará un archivo con el nombre README.txt. Aquí se encuentran las cuentas y las contraseñas de usuario que se usan en todos los dispositivos virtuales y VM del laboratorio.
Nota para el usuario sobre la sección de firewall distribuido con microsegmentación
Si ha completado el Módulo 6: Firewall distribuido del HOL-1903-01-NET, es importante que tenga en cuenta que la sección titulada "Firewall distribuido" de este laboratorio es una repetición de dicho módulo y, por lo tanto, no es necesario que continúe con este laboratorio. Si desea omitir esta sección del laboratorio y continuar con la siguiente, a continuación incluimos un enlace para que lo haga.
Abra vSphere Web Client (Flash) con el ícono de Google Chrome que se encuentra en el escritorio.
Ahora configurará el acceso del firewall distribuido a una aplicación de tres niveles. La aplicación tiene dos servidores web: un servidor de base de datos y uno de aplicación. Además, posee un balanceador de carga que respalda los dos servidores web.
Gracias a Service Composer, se define un modelo nuevo para el consumo de servicios de redes y seguridad en entornos virtuales y de nube. Las políticas son ejecutables mediante la simple visualización y el consumo de servicios que se integran o mejoran mediante soluciones de terceros. Estas mismas políticas pueden hacerse repetibles mediante las capacidades de exportación e importación, que podrían facilitar la implementación y recuperación de un entorno cuando surge un problema. Uno de esos objetos para uso repetible es un grupo de seguridad. Profundizaremos en Service Composer y en los grupos de seguridad más adelante en el módulo llamado "Descripción general de Service Composer y del firewall distribuido".
Haga clic en el ícono Session en la esquina superior izquierda.
En este diagrama, se muestra el punto de cumplimiento relativo del firewall en el nivel de la vNIC. Aunque el DFW es un módulo cargable del kernel (Kernel Loadable Module, KLM) del host de vSphere ESXi, el cumplimiento de las reglas se realiza en la vNIC de la VM invitada. Esta protección se mueve con la VM durante vMotion para otorgar una protección completa en todo momento, lo que impide la aparición de una "ventana de oportunidad" en la que la VM puede ser atacada.
Deberá volver a configurar la regla predeterminada "Default Rule" en "Allow" para poder continuar con el siguiente módulo.
Cambie la acción de "Default Rule" a "Allow".
Haga clic en Publish para publicar los cambios.
Después de que se sincroniza con vCenter Server, NSX Manager recoge las direcciones IP de todas las máquinas virtuales alojadas en vCenter. Si la seguridad de una máquina virtual se compromete, la dirección IP se puede suplantar y las transmisiones maliciosas pueden eludir las políticas de firewall.
Usted debe crear una política de SpoofGuard para redes específicas que le permita autorizar las direcciones IP registradas y, si es necesario, modificarlas para evitar la suplantación de identidad. SpoofGuard confía de forma inherente en las direcciones de control de acceso a medios (Media Access Control, MAC) de las máquinas virtuales recogidas de los archivos VMX y vSphere SDK. Si no sigue las reglas de firewall, puede usar SpoofGuard para bloquear el tráfico que se considera que suplanta la identidad.
SpoofGuard es compatible con direcciones IPv4 e IPv6. Cuando se usa IPv4, la política de SpoofGuard es compatible con una dirección IP única asignada a una vNIC. IPv6 es compatible con varias direcciones IP asignadas a una vNIC. Con la política de SpoofGuard, se monitorean y administran las direcciones IP que registran las máquinas virtuales de uno de los siguientes modos:
Confianza automática en las asignaciones de IP en el primer uso
Este modo permite que todo el tráfico proveniente de las máquinas virtuales pase a la vez que se diseña una tabla de asignaciones de direcciones de vNIC a IP. Podemos analizar esta tabla cuando lo deseemos y realizar cambios en las direcciones IP. Mediante este modo, se aprueban de forma automática todas las direcciones de IPv4 y de IPv6 en una vNIC.
Inspección y aprobación manual de todas las asignaciones de IP antes de usarlas
Por medio de este modo, se bloquea todo el tráfico hasta que se aprueben todas las asignaciones de dirección de vNIC a IP.
Nota: De manera inherente, SpoofGuard permite realizar solicitudes de DHCP sin importar el modo habilitado. Sin embargo, si se encuentra en modo de inspección manual, el tráfico no pasa hasta que no haya aprobado la dirección de IP asignada por DHCP.
SpoofGuard incluye una política predeterminada generada por el sistema que se aplica a los grupos de puertos y a las redes lógicas que no cuentan con el respaldo de las demás políticas de SpoofGuard. Se incorpora automáticamente una red reciente a la política predeterminada hasta que el administrador agregue la red a una política existente o cree una nueva política para esta red.
Para que el firewall distribuido de NSX funcione, se deben descubrir las direcciones IP de los objetos que se especifican como de origen o destino. En versiones anteriores a NSX 6.2, esto se realizaba con VMtools dentro de la VM. En este ejercicio, se mostrará cómo descubrir direcciones IP con VMtools y un modelo de seguridad "Confianza desde el primer uso" (Trust-On-First-Use).
Revisión de SpoofGuard
Migración de Linux-01a desde vDS a un nuevo switch lógico
En primer lugar, debemos migrar la VM linux-01a desde el vDS actual a un switch lógico para aprovechar las competencias de descubrimiento de direcciones IP de SpoofGuard.
Regreso a la sección "Networking & Security"
En "Navigator", haga clic en el botón Back en el campo del historial para volver a la interfaz de configuración de NSX.
Seleccione SpoofGuard en el menú "Navigator".
Conclusión de SpoofGuard
Aquí concluye la sección "Mecanismo mejorado de descubrimiento de IP para máquinas virtuales y SpoofGuard". Hemos migrado con éxito una VM al entorno de NSX y hemos aprovechado SpoofGuard para conocer la dirección IP de la VM con la nueva función Trust-On-First-Use ARP.
En esta sección, profundizaremos en las competencias de grupo de seguridad que descubrimos en la sección Descripción general de firewall distribuido con microsegmentación. Los grupos de seguridad de NSX son un método de definición y agrupación lógica de los recursos que desea proteger. Los grupos de seguridad pueden ser estáticos (incluidas máquinas virtuales específicas) o dinámicos, en los que los miembros se pueden definir de una o más de las siguientes maneras:
Contenedores de vCenter (clústeres, grupos de puertos o centros de datos).
Etiquetas de seguridad, conjuntos de IP, conjuntos de MAC o incluso otros grupos de seguridad. Por ejemplo, se puede incluir un criterio para agregar al grupo de seguridad todos los miembros etiquetados con la etiqueta de seguridad especificada, como AntiVirus.virusFound.
Grupos de directorio (si NSX Manager está registrado en Active Directory).
Expresiones regulares como máquinas virtuales que incluyen "VM1" en el nombre.
Tenga en cuenta que los miembros del grupo de seguridad cambian constantemente. Por ejemplo, una máquina virtual con la etiqueta AntiVirus.virusFound se envía al grupo de seguridad "Quarantine". Cuando el virus se elimina y la máquina virtual ya no tiene esa etiqueta, la VM sale del grupo de seguridad "Quarantine".
Haga clic en Service Composer en el panel izquierdo.
Asegúrese de que se haya seleccionado la pestaña Security Groups.
Seleccione +ADD para crear un nuevo grupo de seguridad.
Validación de la membresía dinámica del grupo de seguridad
Seleccione la opción Groups and Tags.
Observe que se ha creado un nuevo grupo de seguridad que NO posee ningún miembro estático.
El grupo de seguridad dinámico se ha definido con un criterio.
Haga doble clic en 1 Criteria para conocer la lógica detrás de este grupo de seguridad dinámico.
Las políticas de seguridad de NSX pueden ser un conjunto de las siguientes configuraciones de servicio: reglas de firewall, servicios de terminales y servicios de visualización de redes. Las reglas de firewall pueden ser reglas que definen que el tráfico puede moverse hacia un grupo de seguridad, o bien desde un grupo de seguridad o dentro de él. Los servicios de terminales se pueden implementar mediante servicios de proveedores de soluciones de terceros tales como servicios de antivirus o de administración de vulnerabilidades. Los servicios de visualización de redes son servicios que monitorean la red, como sistemas de prevención de intrusiones (Intrusion Prevention System, IPS).
Durante la implementación de servicios en NSX, el proveedor de terceros selecciona la categoría del servicio que se implementa. Se crea un perfil predeterminado de servicio para cada plantilla del proveedor.
Nota: Cuando deba aplicar la misma política de seguridad a distintos grupos de seguridad, cree un grupo de seguridad principal que incluya todos estos grupos de seguridad secundarios y aplique la política común de seguridad al grupo de seguridad general. De esta manera, se asegurará de que el firewall distribuido de NSX utilice la memoria del host de ESXi de forma eficiente.
Creación de una nueva política de seguridad
Seleccione la opción Service Composer.
Seleccione la pestaña Security Policies en el panel " Service Composer".
Haga clic en +ADD para crear una política de seguridad.
Verificación de la sincronización de la regla de firewall
Prueba de conectividad de VM web a VM web con Putty
Pruebe la comunicación y el acceso entre las VM web que componen la aplicación de tres niveles. La primera prueba consistirá en abrir una consola para web-01a y enviar pings a web-02a.
Haga clic en el acceso directo de PuTTY, en la barra de tareas del escritorio.
Aquí finaliza el módulo 1 sobre Service Composer y el firewall distribuido. Hemos creado grupos de seguridad estáticos y dinámicos, hemos aplicado políticas de seguridad estáticas y dinámicas, incluidas reglas de firewall, y hemos utilizado SpoofGuard para descubrir VM que no ejecutan VMTools e incorporarlas en la red.
Antes de finalizar el módulo 1, debe eliminar la regla que se creó en esta sección.
Regrese a Service Composer.
Haga clic el botón de selección en la fila Block Web-to-Web Traffic.
Seleccione la opción Delete. Cuando aparezca la pregunta "Are you sure you want to delete the selected - Block Web-to-Web Traffic?", haga clic en "DELETE".
Limpieza del módulo 1: SpoofGuard
Antes de finalizar el módulo 1, debe desactivar la política predeterminada de SpoofGuard.
Seleccione Default Policy.
Seleccione la opción EDIT.
Limpieza del módulo 1: desactivar SpoofGuard
Asegúrese de que la opción "Enable" esté desactivada para guardar la configuración de la política predeterminada "Default Policy" de SpoofGuard.
Si desea obtener más información sobre la configuración y las capacidades de enrutamiento de NSX, consulte el centro de documentación de NSX 6.4.x mediante la siguiente URL:
Diríjase a https://tinyurl.com/y9fe6w8v.
(45 minutos). Básico. En este módulo, se analizará la microsegmentación de aplicaciones.
En este módulo, explorará de qué manera la funcionalidad de firewall distribuido (DFW) en NSX les permite a los clientes contraer arquitecturas de redes de múltiples niveles tradicionales para obtener redes únicas y de un solo nivel y, al mismo tiempo, mantener las aplicaciones aisladas. Esto es esencial para dejar atrás una estrategia de seguridad centrada en la red y poder adoptar una estrategia de seguridad centrada en las cargas de trabajo. Usará dos aplicaciones distintas (HR y Finance) que se encuentran en el mismo switch lógico y en la misma subred.
Luego deberá configurar y probar lo siguiente:
La comunicación entre las VM asociadas con las aplicaciones HR y Finance en la misma red antes de aislarlas.
La agrupación lógica de VM por medio de grupos de seguridad.
La creación de reglas de firewall distribuido para proteger la comunicación entre las aplicaciones.
La comprobación de que las aplicaciones funcionen correctamente y de que la comunicación entre las VM asociadas con las aplicaciones HR y Finance esté bloqueada.
La limpieza de las políticas de seguridad del laboratorio antes de continuar con el siguiente laboratorio.
Cuando haya completado este módulo del laboratorio, habrá comprobado que el DFW de NSX ha protegido y aislado las aplicaciones y ha permitido que la comunicación entre las aplicaciones funcione normalmente en la la misma infraestructura de red.
Revisión de la arquitectura de red de ejemplo
Antes de contraer la red de aplicaciones de tres niveles a una red única, veamos un ejemplo de una aplicación de tres niveles segmentada en subredes individuales para proporcionar aislamiento de capa 3 entre los niveles web, de aplicación y de base de datos. Es importante que tenga en cuenta que aquí no disponemos de reglas de seguridad de firewall que protejan la comunicación entre las VM que residen en el mismo dominio de capa 2 e incluso entre los niveles de la aplicación. Cuando las organizaciones comienzan a escalar de manera horizontal varias de estas cargas de trabajo de múltiples niveles, deben decidir si implementar más subredes o implementar componentes de aplicaciones (como bases de datos de distintas aplicaciones) en el mismo dominio de C2.
Por ejemplo, una organización puede tener los componentes de base de datos para múltiples aplicaciones que residen en la red "DB-Tier". Con los firewalls tradicionales, la comunicación entre dichas bases de datos no está protegida. Esto podría permitirle a una persona que tiene acceso autorizado a una de las máquinas de DB acceder a otra DB que se encuentra en la misma red. Con el firewall distribuido de NSX, las organizaciones pueden contraer toda la estructura de red a un único segmento de C2, suministrar funcionalidad entre las aplicaciones y, al mismo tiempo, aislarlas.
Validación del funcionamiento de la aplicación Finance
Asegúrese de que esté accediendo a la base de datos Financial Department Cost Centers Database. Como resultado, recibirá datos de la máquina virtual fin-web-01a.
Validación de la aplicación HR
Asegúrese de que esté accediendo a la base de datos HR Employee Salary Database.
Inicio de la consola remota de la VM fin-web-01a
Haga clic en el ícono de rueda de engranaje y seleccione la opción Launch Remote Console.
Regreso a la sesión de vSphere Web Client
Haga clic en el ícono del navegador vSphere Web Client (Flash) en la barra de tareas.
Regreso a vSphere Web Client
Haga clic en el ícono de vSphere Web Client del navegador Chrome en la barra de tareas o en el acceso directo en el escritorio.
Acceso a la configuración de firewall
Haga clic en Firewall en el menú "Navigator" que se encuentra a la izquierda.
Creación de grupo de seguridad de la aplicación HR
Seleccione la opción Security Group del menú desplegable Object Type.
Haga clic en New Security Group para definir el grupo de seguridad de la aplicación HR.
Creación de grupo de seguridad de la aplicación Finance
Haga clic en New Security Group para definir el grupo de seguridad de la aplicación Finance.
Incorporación de una nueva regla de firewall
Haga clic en los tres puntos de la sección Collapsed App Tier Rules.
Seleccione la opción Add Rule Above.
Haga clic en Publish Changes para implementar las nuevas reglas de firewall en las VM y los hosts correspondientes.
Haga clic en el botón de actualización.
Asegúrese de que esté accediendo a la base de datos Financial Department Cost Centers Database.
Antes de continuar con el próximo módulo, debemos limpiar las reglas de firewall.
Haga clic en la pestaña del navegador vSphere Web Client (Flash).
Aquí finaliza el módulo 2, en el cual se realizó una revisión guiada del aislamiento de las aplicaciones con el firewall distribuido (DFW) de NSX en una red de un solo nivel. En este módulo, demostramos que contraer una aplicación de red de tres niveles a un único switch lógico de NSX no afecta la seguridad de confianza cero que proporciona NSX por medio del firewall distribuido. Lo primero que hicimos en este laboratorio fue verificar la comunicación entre las VM de las aplicaciones HR y Finance que residen en la misma red. Luego, creamos reglas de firewall con agrupaciones lógicas de VM para proteger y evitar la comunicación entre las aplicaciones HR y Finance, y verificamos la implementación de las reglas que creamos por medio de una prueba de comunicación de VM entre las pilas de aplicaciones y dentro de ellas. Después de verificar que las aplicaciones estuvieran aisladas entre sí, eliminamos las reglas de firewall que creamos para poder prepararnos para el otro módulo del laboratorio.
Esperamos que haya disfrutado aprender sobre el aislamiento de las aplicaciones y las capacidades de confianza cero del DFW de NSX.
La finalización del soporte técnico (End of Support, EOS) de las plataformas empresariales más importantes como Windows XP, Windows 2000 Server y Windows Server 2003 es uno de los mayores desafíos a los que se enfrentan las organizaciones que ejecutan aplicaciones de misión crítica necesarias para el funcionamiento diario. Por ejemplo, en julio de 2015, cuando Microsoft finalizó el soporte para Windows 2003, puso en riesgo a millones de servidores empresariales.
Es posible que las organizaciones que usan sistemas operativos con EOS hayan introducido graves riesgos de seguridad en los entornos, a menos que hayan estado preparadas para migrar a una nueva plataforma o implementar controles que compensen el riesgo. Los atacantes saben que los proveedores de plataforma como Microsoft ya no podrán reconocer vulnerabilidades ni mucho menos resolverlas. Por lo tanto, estos sistemas no tardan en convertirse en el blanco favorito de ataque y los riesgos de ejecutar una plataforma sin soporte después de la EOS aumentará cada vez más a medida que surjan otros problemas y no se resuelvan.
NSX puede ayudar a mitigar los riesgos de los sistemas operativos con EOS ya que proporciona una mayor seguridad por medio del firewall distribuido (DFW) y Service Composer. En este laboratorio, usará los grupos de seguridad de NSX para reunir las VM con Windows XP e implementará políticas de firewall para protegerlas en un entorno simulado.
Creación de grupos de seguridad para VM con Windows XP y grupos de seguridad para el módulo 4
Creación de conjuntos de IP
Inclusión dinámica para agrupar automáticamente VM con Windows XP
Implementación de reglas de firewall para proteger VM con Windows XP
Prueba del acceso de VM con Windows XP a redes externas
Módulo 3: James Emmons, Staff Technical Account Manager, NSX Technical Account Specialist, Estados Unidos
Con el uso de VM con Windows XP, determinaremos el acceso de seguridad actual a recursos externos e internos.
(La página de inicio debe ser el vSphere Web Client. De lo contrario, haga clic en el ícono de la barra de tareas de vSphere Web Client para Google Chrome).
Escriba administrator@corp.local en el campo "User name".
Inicio de sesión a máquinas virtuales con EOS
Verificación de acceso interno
Abra el navegador Mozilla desde el escritorio.
Haga clic en el enlace Customer DB-App para iniciar la aplicación interna (asegúrese de que la URL sea https://web-01a.corp.local/cgi-bin/app.py). También acepte el aviso de certificado en web-01a si es necesario. (Advanced -> Add Exception -> Confirm Security Exception).
Uso del símbolo del sistema para acceso externo
La VM de la consola de control se encuentra fuera del entorno virtual que estamos usando en este laboratorio. Por lo tanto, representa un servicio externo a nuestro entorno. Usaremos la dirección IP del centro de control 192.168.110.10 para representar los servicios de Internet.
Inicie el símbolo del sistema
Si el ícono del símbolo del sistema no aparece, Haga clic en "Run", escriba "cmd" y presione la tecla Enter para abrir el símbolo del sistema.
Ahora que vemos la posible vulnerabilidad que implica permitirles a las VM con finalización del soporte técnico acceder a recursos externos, debemos buscar la manera de protegerlas. Para ello, usaremos grupos de seguridad de NSX para identificar de inmediato las máquinas que ejecutan sistemas operativos con finalización del soporte técnico (EOS) y las protegeremos por medio del cumplimiento de políticas.
Sección "Networking & Security": Service Composer
Seleccione la opción Networking & Security.
Nuevo grupo de seguridad
Haga clic en +ADD para crear un nuevo grupo de seguridad.
Nuevo conjunto de IP
NOTA: Primero crearemos un conjunto de IP que defina toda la infraestructura de máquina virtual del laboratorio.
¿Qué es un conjunto de IP?
Los conjuntos de IP (IP Sets) pueden contener cualquier combinación de direcciones IP individuales, intervalos IP o subredes que se utilizarán como orígenes y destinos de las reglas de firewall o como miembros de grupos de seguridad.
Siga los pasos que se detallan a continuación junto con las imágenes correspondientes:
Seleccione la pestaña IP Sets.
Haga clic en +ADD para crear un nuevo conjunto de IP.
Nuevo grupo de seguridad con conjunto de IP
Siga los siguientes pasos con las imágenes como guía para crear el nuevo grupo de seguridad con Service Composer:
En esta sección, implementaremos reglas para limitar el acceso a recursos externos de la VM.
Haga clic en la opción Service Composer.
La pestaña Security Policies debe estar seleccionada.
Haga clic en +ADD para crear una nueva política de seguridad.
Incorporación de la regla de firewall
En el menú "Navigation", haga clic en "Firewall".
Hemos creado un grupo de seguridad con el fin de que la VM con Windows XP pueda acceder a los servicios internos (aplicaciones internas). No obstante, todavía debemos agregar una regla adicional para permitir el acceso entre servicios internos y, además, modificar la regla de firewall predeterminada para bloquear todo otro tipo de acceso, incluido el acceso externo.
Incorporación de reglas de firewall en la sección nueva
Haga clic en el ícono de tres puntos para agregar una regla a la sección.
Haga clic en Add Rule.
Modificación de la regla predeterminada de firewall
Para bloquear el tráfico indeseado, incluido el tráfico a servicios externos desde las VM con Windows XP con EOS, debemos habilitar el bloqueo en la regla predeterminada de firewall. La regla predeterminada de firewall se encuentra en la sección de regla predeterminada de firewall.
Haga clic en la sección Default Rule para expandirla. En la sección "Default Rule", haga clic en el menú desplegable de la columna "Action". Seleccione la acción Block.
Ya hemos creado reglas para las VM con Windows XP con EOS. Por lo tanto, podemos continuar con la prueba de acceso a los servicios internos y externos.
Apertura de la consola de win-xp-01
Haga clic en la pestaña del navegador win-xp-01.
Verificación del bloqueo del acceso externo
Vuelva a abrir el símbolo del sistema en el escritorio win-xp-01.
En la ventana del símbolo del sistema, escriba ping 192.168.110.10.
Verifique que el acceso externo al centro de control se haya bloqueado.
Aquí podemos ver que la máquina virtual win-xp-01 tiene acceso a los servicios internos, pero su acceso externo se ha bloqueado por completo en conformidad con la política del grupo.
Limpieza del módulo: restauración de la regla predeterminada a "Allow"
Haga clic en el ícono + para expandir Default Section Layer 3.
En la sección "Default Rule", haga clic en el menú desplegable de la columna "Action" y seleccione la opción Allow.
En este laboratorio, hemos aprendido a usar la agrupación inteligente para agrupar sistemas operativos con finalización del soporte técnico en grupos de seguridad. Una vez que se crean los grupos de seguridad, podemos usarlos para crear reglas de firewall que pueden limitar el acceso hacia y desde las máquinas virtuales que son parte de estos grupos. Los grupos de seguridad son una herramienta versátil que se puede reutilizar para modificar o crear nuevas políticas a medida que los requisitos de seguridad varíen.
Si desea obtener más información sobre las capacidades de grupos de seguridad de NSX, consulte el centro de documentación de NSX 6.4.x mediante la siguiente URL:
Seguridad basada en el usuario en un escenario de servidor de seguridad.
En este módulo del laboratorio, creará reglas de firewall con la función Identity Based Firewall de NSX. Esta función utiliza una conexión con Active Directory desde NSX Manager. NSX Manager analiza el registro de eventos del servidor de AD para determinar las credenciales y los eventos de inicio de sesión. Las VM en las que los usuarios inician sesión se asignan de inmediato a grupos de seguridad según los grupos de AD de los usuarios. Los grupos de seguridad junto con las reglas de firewall nos permiten controlar el acceso en nuestro entorno.
En este laboratorio, se utilizan distintos grupos de Active Directory y dos usuarios diferentes. El primer usuario es un administrador de red que necesita acceder a cualquier aplicación que resida en el entorno y el segundo usuario es un administrador de Recursos Humanos que necesita acceder a una aplicación de RR. HH específica basada en la web.
Los temas incluidos en este módulo son los siguientes:
Configuración de la conexión de NSX con Active Directory
Creación de grupos de seguridad basados en grupos de AD
Creación de conjuntos de IP con grupos de seguridad
Incorporación de reglas de aplicación para las aplicaciones internas
Verificación y prueba de reglas basadas en AD
Módulo 4: James Emmons, Staff Technical Account Manager, NSX Technical Account Specialist, Estados Unidos
NSX se conecta con Active Directory para usar grupos de AD a fin de proporcionar reglas de firewall basado en la identidad.
Inicio del navegador y vSphere Web Client (Flash)
Haga doble clic en el ícono Chrome en el escritorio.
Haga clic en NSX Home.
Haga clic en NSX Manager.
Verifique que, en el estado de la sincronización de AD, se muestre la palabra "SUCCESS".
Antes de crear reglas de firewall basado en la identidad (Identity Based Firewall, IDFW), debemos configurar el servicio de introspección de invitados de NSX, Guest Introspection.
Navegación a la sección "Networking & Security"
Implementación del servicio Guest Introspection
Seleccione la opción Installation and Upgrades.
Haga clic en +ADD para implementar el servicio Guest Introspection.
Verificación de la instalación de Guest Introspection en los hosts
En este ejemplo del laboratorio, los objetos de seguridad se definen según los miembros de los grupos de AD y se usarán para implementar políticas de seguridad.
Creación de un grupo de seguridad y un conjunto de IP como prerrequisito
Nota: Se deben crear un conjunto de IP y un grupo de seguridad si no se han creado en el Módulo 3: Agrupación inteligente.
Creación de una nueva sección de regla de firewall (objeto de seguridad basado en grupos de AD)
Haga clic en la opción Firewall en el panel "Navigation".
Haga clic en el ícono de tres puntos.
Haga clic en Add Section Above en la sección Flow Monitoring & Traceflow Rule.
Para las aplicaciones internas de este laboratorio, se necesitan reglas adicionales que permitan la comunicación entre los niveles de cada aplicación.
Creación de reglas de firewall adicionales
Hemos creado reglas de firewall basadas en AD para permitirles a los administradores de RR. HH. y administradores de red acceder a las aplicaciones correspondientes según su rol. No obstante, todavía debemos agregar una regla adicional para permitir el acceso entre servicios internos y, además, modificar la regla de firewall predeterminada para bloquear todo otro tipo de acceso, incluido el acceso externo.
Haga clic en Firewall para acceder a todas las reglas de firewall.
Incorporación de reglas a la nueva sección de firewall
Haga clic en el ícono de res puntos de la sección Internal Services to Internal Services.
Para poder bloquear el tráfico no deseado, necesitamos activar la acción de bloqueo en la regla predeterminada de firewall. La regla predeterminada de firewall se encuentra en la sección de regla predeterminada de firewall.
Haga clic en el menú desplegable de Action en la sección Default Rule y luego seleccione la acción Block. Presione la tecla Enter para confirmar la selección.
Para probar las reglas creadas, debemos iniciar sesión en la VM win12-jump con distintas credenciales de usuario de AD.
Para probar las nuevas reglas basadas en la identidad, debe abrir la consola de la VM del servidor de seguridad (win-12-jump) que se encuentra en el dominio e iniciar sesión como miembro del grupo "AppConfiguration" o del grupo "Human Resources" de Active Directory. El usuario NetAdmin es miembro del grupo "AppConfiguration" y, por lo tanto, puede iniciar sesión en cualquier aplicación interna o en cualquier nivel de la aplicación. El usuario HRadmin es miembro del grupo "Human Resources" y, por lo tanto, solo puede iniciar sesión en las aplicaciones web HR y Financial. Inicie sesión con ambas identidades y observe qué sucede cuando intenta acceder a las aplicaciones de 3 niveles.
Apertura de la consola del servidor de seguridad
Expanda los contenedores de "RegionA01" y haga clic en la opción win12-jump.
Haga clic con el botón derecho del mouse en win12-jump.
Haga clic en la opción Open Console.
Haga clic en Send Ctrl-Alt-Del.
En el campo "User name", escriba NetAdmin.
En el campo "Password", escriba VMware1!.
En este laboratorio, hemos aprendido a usar las funciones de Identity Based Firewall de NSX para controlar el acceso a las aplicaciones internas. Para ello, creamos reglas de firewall basadas en AD para los roles de administrador de red y administrador de Recursos Humanos. Con estas reglas, el administrador de RR. HH. puede conectarse solo a la aplicación web HR por medio del protocolo HTTP. Estas reglas también le permiten al administrador de red conectarse a cualquiera de las aplicaciones disponibles por medio de cualquier protocolo. De esta manera, podemos controlar el acceso a las aplicaciones correspondientes con el nivel adecuado de privilegio según los roles dentro de la organización.
Si desea obtener más información sobre la configuración y las capacidades de la función de NSX Identity Based Firewall, consulte el centro de documentación de NSX 6.4.x mediante la siguiente URL:
Application Rule Manager (ARM) es un nuevo conjunto de herramientas que se incorporó en NSX 6.3. Application Rule Manager utiliza datos de flujo en tiempo real para planificar la microsegmentación e implementar modelos de seguridad de confianza cero de forma rápida y eficiente. Con ARM, se puede brindar mayor protección a aplicaciones nuevas o existentes que la que Log Insight puede proporcionar y se puede proteger entornos en menor escala que lo que se podría abordar con vRealize Network Insight (vRNI).
ARM recoge datos de flujo en tiempo real en la entrada y salida de cargas de trabajo de las aplicaciones y entre ellas, lo que permite crear modelos de seguridad centrados en las aplicaciones. ARM puede monitorear hasta 30 VM por sesión y se puede ejecutar un total de cinco sesiones simultáneas. ARM también proporciona visibilidad de los flujos bloqueados y las reglas de firewall que bloquean el tráfico.
En el flujo de trabajo de Application Rule Manager, se deben seguir tres pasos:
Seleccione las máquinas virtuales (VM) que conforman la aplicación y se deben monitorear. Una vez configurados, se monitorean todos los flujos de entrada y salida de un conjunto definido de tarjetas de interfaz de red virtualizadas (Virtualized Network Interface Cards, VNIC) de las VM que se monitorean. Puede haber hasta un máximo de cinco sesiones de recopilación de flujos al mismo tiempo.
Detenga el monitoreo para generar las tablas de flujo. Los flujos se analizan para revelar la interacción entre las VM. Los flujos se pueden filtrar para ver los registros de flujos de un conjunto limitado de procesos activos.
Use tablas de flujo para crear objetos de agrupación, como grupos de seguridad, conjuntos de IP, servicios, grupos de servicios y reglas de firewall.
Con Application Rule Manager 6.4, se incorporan las siguientes capacidades:
Recomendaciones automáticas para reglas de DFW basadas en datos de flujos
Automatización de la agrupación inteligente de objetos
Identificación incorporada de aplicaciones y protocolos
Estas son las nuevas ventajas de ARM 6.4 que se usan en este laboratorio:
Mayor contexto a partir de datos de flujos para aplicar controles de seguridad más detallados
Mayor facilidad para aplicar microsegmentación en las aplicaciones de las operaciones secundarias
Obtención de resultados más rápida
Módulo 5: James Emmons, Staff Technical Account Manager, NSX Technical Account Specialist, Estados Unidos
En esta lección, revisaremos algunos ejemplos de las modificaciones que se han realizado en la microsegmentación de aplicaciones en NSX 6.4.x.
Inicio del navegador Chrome y vSphere Web Client
Haga doble clic en el ícono "Chrome" del escritorio.
Si aún no inició sesión en vSphere Web Client (Flash), haga lo siguiente:
Escriba administrator@corp.local en el campo "User name" y escriba VMware1! en el campo "Password".
Selección de "Flow Monitoring"
En la pestaña "Top Flows", observe cómo se recopilan los flujos principales activos (la actividad puede variar según los módulos de laboratorio que se hayan realizado).
Creación de flujo en vivo: monitoreo de flujos
A continuación, crearemos un flujo en vivo.
Haga clic en la pestaña Live Flow.
Haga clic en la opción Select vNIC.
Escriba hr para filtrar la búsqueda.
Haga doble clic en la máquina virtual hr-web-01a_corp.local.
Selección de una vNIC
Seleccione la vNIC hr-web-01a_corp.local - Network adapter 1.
Inicio del proceso de monitoreo
Detención del proceso de monitoreo
Observe cómo se recopilan los datos del origen ("Source") y del destino ("Destination") de muestra con el monitoreo en vivo.
Application Rule Manager con recomendaciones automáticas: inicio de nueva sesión en la aplicación HR
Seleccione Application Rule Manager en el menú "Navigator".
Haga clic en +Start Session para comenzar a recopilar los datos de los flujos de la aplicación.
Inicio de nueva sesión
En la ventana "Start New Session", introduzca la siguiente información:
En "Name", escriba HR_DB_App.
Verifique que en el campo Object Type aparezca la opción Virtual Machine.
En el cuadro de búsqueda, escriba HR.
Selección de las VM de HR
Marque el cuadro que se encuentra al lado de cada una de las tres máquinas virtuales asociadas con HR (hr-web-01a.corp.local, hr-db-01a.corp.local, y hr-app-01a.corp.local).
Haga clic en la flecha hacia la derecha para mover las tres máquinas virtuales al cuadro Selected Objects.
Creación de flujos de tráfico: ICMP
Application Rule Manager está recopilando datos de flujos de tres máquinas virtuales asociadas con la aplicación HR. Mientras más tiempo dure el proceso de recolección de datos, más datos se analizarán. Para los fines de este laboratorio, recopilaremos datos de flujos durante tres minutos.
En la barra de tareas, haga clic en el ícono de PuTTY.
En la lista "Saved Sessions", haga doble clic en hr-web-01a.corp.local (deberá desplazarse hacia abajo con el mouse para encontrar la sesión).
Escriba ping -c 2 172.16.60.12.
NOTA: No cierre la sesión de PuTTY ya que la usará en breve.
Escriba ping 172.16.60.10
Haga clic en '>>' y seleccione el marcador HR DB App.
Actualice la página varias veces para generar más flujos de tráfico.
Sesión de recolección de datos
En tres minutos, verá que aparecen los flujos en la consola de monitoreo de flujos. La cantidad de flujos varía en cada laboratorio.
En vSphere Web Client, asegúrese de que la opción Application Rule Manager esté seleccionada en el menú "Navigator".
Detención del proceso de recolección de datos
Asegúrese de que la sesión "HR_DB_App" esté seleccionada.
Haga clic en STOP para revisar la información de los flujos recopilada.
Confirmación de detención de la sesión
Haga clic en STOP para confirmar.
Análisis de los datos de flujos
Haga clic en la sesión HR_DB_APP Virtual Machines.
Seleccione la opción OBJECT para indicar que desea que las reglas recomendadas para este laboratorio estén basadas en objetos.
Espera para finalización del análisis
Espere a que finalice el análisis. El tiempo que dure el proceso variará según la cantidad de datos que se recopile.
Haga clic en la sesión HR_DB_APP.
Observe las reglas recomendadas de ARM que se pueden implementar de inmediato y que se pueden exportar o publicar en el firewall a partir de esta actividad: aquí podemos ver las IP de origen y destino, como así también los servicios HTTP y HTTPS, entre otros.
Inicio de nueva sesión para Finance_DB_App
Antes de analizar los datos recopilados de HR_App, configuraremos una segunda sesión para la aplicación Fin_App a fin de mostrar distintas sesiones de recopilación de flujos de datos.
Haga clic en < para regresar a la pantalla principal de Application Rule Manager.
Inicio de sesión de las máquinas virtuales asociadas con Finance_App
Haga clic en Start Session .
Selección de las máquinas virtuales asociadas con Finance_App
En "Name", escriba Finance_DB_App.
En el cuadro de búsqueda, escriba fin.
Selección de las VM de Finance
Marque el cuadro que se encuentra al lado de cada una de las tres máquinas virtuales asociadas con la aplicación Finance (fin-web-01a.corp.local, fin-db-01a.corp.local, y fin-app-01a.corp.local).
Recolección de datos de Finance_App
Espere un par de minutos hasta que aparezcan los flujos.
Seleccione la sesión Finance_DB_App.
Análisis de Finance_DB_App
Asegúrese de que la sesión Finance_DB_App todavía esté seleccionada.
Asegúrese de que la opción Object esté seleccionada para indicar que desea que las reglas recomendadas para este laboratorio estén basadas en objetos.
Haga clic en el botón ANALYZE.
Podemos ver que Application Rule Manager ha recopilado correctamente datos de flujos de las máquinas virtuales de HR_DB_App y Finance_DB_App.
Haga clic en Details para revisar las vNIC que se están monitoreando.
Revisión de la duración de la recopilación
Observe la hora y la duración de las recopilaciones de flujos.
Flujos de HR_DB_App
Haga clic en HR_DB_App.
Vista procesada de HR_DB_App
Haga clic en la pestaña Flows.
Después de analizar y procesar los datos de flujos, NSX ha reemplazado las direcciones IP con nombres de VM, lo que facilita la asignación lógica de flujos entre objetos.
Dirección IP de HR-DB
En la columna "Destination", busque la máquina virtual hr-db-01a_corp.local y haga clic en ella.
Observe la dirección IP. Debe ser 172.16.60.12.
Sesión de PuTTY
Usaremos la información que ARM nos ha dado para microsegmentar las máquinas virtuales dentro de HR_DB_App y Finance_DB_App y entre estas aplicaciones. Veamos si hr-web-01a se puede comunicar con hr-db-01a.
Vuelva a la sesión PuTTY de hr-web-01a.corp.local. Si la cerró, deberá abrirla de nuevo y volver a establecer la conexión.
Escriba lo siguiente para enviar un ping a 172.16.60.12:
Verificamos que la máquina virtual web-01a asociada con HR_DB_App se puede comunicar directamente con la máquina virtual db-01a. No obstante, esta no es la situación ideal. Por lo tanto, configuraremos las reglas de firewall de forma adecuada para controlar el tráfico entre las máquinas virtuales de 3 niveles.
Nuevas reglas de firewall desde la pestaña "Rule Planning" de ARM
Asegúrese de que la opción Application Rule Manager esté seleccionada en el menú "Navigator".
Seleccione la sesión creada HR_DB_APP_Virtual.
Seleccione la pestaña Rule Planning.
Actualización de la regla creada previamente
Encuentre la regla creada previamente que tenga como origen 192.168.110.10 en la columna "Source".
En "Destination", esta regla también debe tener como destino hr-web-01a.corp.local.
Y en "Service", debe tener el servicio SSH.
Seleccione la regla ARM_Recommended para modificar su nombre.
Nuevo nombre: "Control Center to HR_Web"
Modifique el nombre de la regla a Control Center to HR_Web y luego presione la tecla Enter para guardar los cambios.
Incorporación del servicio HTTPS
Desplace el mouse hacia el servicio SSH y haga clic en el ícono de edición.
Escriba https en el cuadro de búsqueda.
Desplácese hacia abajo hasta que vea HTTPS.
Marque la casilla que se encuentra junto a HTTPS.
Haga clic en la flecha hacia la derecha para agregar el servicio "HTTPS" al cuadro "Selected Objects".
Confirmación del grupo de seguridad de ARM recomendado
Verificación del grupo de seguridad
Haga clic en "ARM_" en la columna "Applied To" de la regla Control Center to HR_Web.
Validación de las máquinas virtuales
Asegúrese de que el grupo tenga tres máquinas virtuales asociadas con HR: hr-web-01a, hr-db-01a y hr-app-01a.
Para ver las tres máquinas virtuales, deberá desplazarse hacia la parte inferior.
Modificación del grupo de seguridad de ARM recomendado
Asegúrese de que la sesión en ARM HR_DB_APP Virtual Machines esté seleccionada.
Seleccione la pestaña Security Group debajo de "Rule Planning".
Edición del grupo de seguridad de ARM
Seleccione el primer grupo de seguridad de la lista generado por ARM para modificar el nombre.
Haga clic en Edit para editar el grupo de seguridad seleccionado.
Nombre "HR_Machine_SG"
Cambie el nombre del grupo de seguridad actual a HR_Machine_SG.
Haga clic en el paso Select Objects to Include.
Asegúrese de que los objetos de este grupo de seguridad incluyan las máquinas virtuales hr-app01a, hr-db-01a y hr-web-01a. Si solo ve las máquinas virtuales hr-db-01a y hr-web-01a en la lista, haga clic en "Cancel" y seleccione el otro grupo de seguridad de ARM en la lista.
Modificación del grupo de seguridad de ARM recomendado n.° 2
Seleccione el segundo grupo de seguridad de la lista generado por ARM para modificar el nombre.
Nombre "HR_Machine_DB_WEB"
Cambie el nombre del grupo de seguridad actual a HR_Machine_DB_WEB.
Haga clic en el enlace Select Objects to Include.
Asegúrese de que los objetos de este grupo de seguridad incluyan las máquinas virtuales "hr-db-01a y "hr-web-01a".
Validación de los cambios de configuración de ARM
Observe que se han cambiado los nombres de ambos grupos de seguridad.
Haga clic en la pestaña Firewall Rules.
Validación de los cambios de firewall de ARM
Observe que se ha modificado el nombre de la regla de firewall a Control Center for HR_WEB.
NOTA: Quizá deba actualizar la página para ver el cambio.
Configuración de la regla de firewall "HR_Web to HR_App"
Seleccione la fila donde aparezca la máquina virtual hr-app-01a en la columna "Destination" y la máquina virtual hr-web-01a en la columna "Source".
Haga clic en el campo de nombre para modificar el nombre generado por ARM.
Nueva regla de firewall "HR_Web to HR_App"
Cambie el nombre a HR_Web to HR_App y presione la tecla Enter.
Deje todo lo demás con la configuración predeterminada y haga clic en SAVE.
Configuración de la nueva regla de firewall "HR_App to HR_DB"
Seleccione la fila donde aparezca la máquina virtual hr-db-01a en la columna "Destination" y la máquina virtual hr-app-01 en la columna "Source".
Haga clic en el campo de nombre para modificar el nombre de la regla de firewall generada por ARM.
Nueva regla de firewall "HR_App to HR_DB"
Cambie el nombre a HR_App to HR_DB y presione la tecla Intro.
Publicación de las reglas de firewall
Haga clic en Publish To Firewall.
Ventana "Firewall Publish"
En el campo Section Name, escriba HR_DB_APP.
Revisión de la regla de firewall HR_DB_App
Haga clic en Firewall en el panel "Navigator".
Haga clic en el ícono + para expandir la sección "HR_DB_APP".
Aquí podemos revisar las reglas de firewall que acabamos de configurar en Application Rule Manager. A continuación, probaremos la regla HR_DB_App para asegurarnos de que la página web funcione y el tráfico no seguro se haya bloqueado.
Expansión de la sección "Default Section Layer 3"
Haga clic en el ícono + para expandir la sección "Default Section Layer 3".
Desplácese hacia abajo hasta que vea la regla Default Rule.
En la regla Default Rule y en la columna Action (quizá deba desplazarse hacia abajo para encontrarla), cambie la acción de la regla de Allow a Block. Presione la tecla Enter.
Haga clic en el botón Publish.
Verificación del funcionamiento de HR_DB_App
Si cerró la pestaña "HOL-HR Department", realice lo siguiente:
Aquí debe ver la base de datos HR Employee Salary Database.
Regrese al símbolo del sistema. Si lo cerró, deberá abrirlo de nuevo.
Aquí debemos probar si podemos enviar con éxito un ping a los servidores web, de aplicación y de base de datos desde la consola principal:
Aquí podemos ver que el tráfico ICMP está bloqueado. El único tráfico permitido es HTTPS.
Nota: En este laboratorio, configuramos la regla de firewall de web01a para permitir el servicio SSH con el fin de acceder a la máquina virtual por medio de Putty para realizar la próxima prueba.
Regrese a la sesión SSH de hr-web-01a.
Después de aproximadamente 10 segundos, presione Control+C para finalizar el proceso.
Ahora podemos ver que el tráfico desde web-01a hacia db-01a se ha bloqueado.
Limpieza del Módulo 5: restauración de la regla predeterminada a "Allow"
Si desea obtener más información sobre las capacidades y la configuración de NSX Application Rule Manager, consulte el centro de documentación de NSX 6.4.x mediante la siguiente URL:
¿Cómo está funcionando mi entorno de NSX? Inicié sesión en vRealize Network Insight (vRNI) y noté distintos eventos activos entre otros elementos que se podrían revisar como microsegmentación, aplicaciones, redes y seguridad de VM. En este laboratorio, se incluyen distintos ejemplos de eventos en tiempo real. En un ejemplo, se muestran de forma breve algunos riesgos de respaldo que surgen en el entorno del laboratorio configurado de vRNI y VMware NSX.
¿Por qué se recomienda usar vRealize Network Insight (vRNI)?
VMware vRealize Network Insight les permite a los clientes crear una infraestructura de red optimizada, altamente disponible y segura en entornos de nubes múltiples. Además, acelera la implementación de la microsegmentación, reduce los riesgos comerciales durante la migración de las aplicaciones y les permite a los clientes administrar y escalar las implementaciones de NSX con seguridad.
Le recomendamos que busque los demás laboratorios HOL disponibles sobre vRealize Network Insight. También puede acceder al siguiente enlace para obtener más información: https://tinyurl.com/zarodvc.
¿Por qué se debe realizar un respaldo y una restauración de NSX?
Realizar un respaldo adecuado de todos los componentes de NSX es fundamental para restaurar el sistema a un estado de correcto funcionamiento en caso de que ocurra una falla. El respaldo con NSX Manager contiene todas las configuraciones de NSX, incluidos controladores, entidades de conmutación y enrutamiento lógicos, seguridad, reglas de firewall y todos los demás elementos que necesita para realizar la configuración en la interfaz de usuario (User Interface, UI) o la interfaz de programación de aplicaciones (Application Program Interface, API) de NSX Manager.
Como mínimo, recomendamos que realice respaldos frecuentes de NSX Manager y vCenter. Sin embargo, se recomienda que para todos los productos de VMware se cree una estrategia de respaldo.
La frecuencia y la programación de los respaldos que realice pueden variar según las necesidades del negocio y los procedimientos operacionales. Recomendamos que realice los respaldos de NSX con frecuencia durante los cambios frecuentes de configuración. Los respaldos de NSX Manager se pueden realizan según demanda por hora, por día, o por semana.
Recomendamos realizar respaldos en los siguientes casos:
Antes de una actualización de NSX o vCenter
Después de una actualización de NSX o vCenter
Después de la implementación y configuración inicial de componentes de NSX como, por ejemplo, después de la creación de controladores NSX Controllers, switches y enrutadores lógicos, puertas de enlace de servicios de NSX Edge, seguridad y políticas de firewall
Después de modificar la infraestructura o la topología
Después de modificaciones significativas en las operaciones secundarias
Puede encontrar la guía sobre respaldo de VMware NSX en el siguiente enlace: https://tinyurl.com/y98d98nd
Las mejores prácticas de VMware para VMware NSX 6.4.x se incluyen en el siguiente enlace: https://tinyurl.com/ycfy45sz
En este laboratorio, se deberán realizar las siguientes actividades en el orden detallado:
Breve descripción general del entorno de vRealize Network Insight
Descripción general de la validación de la conexión vSphere Web (Flash) con el entorno de vCenter o NSX
Configuración del respaldo con NSX Manager
Análisis de los cambios actualizados con vRealize Network Insight
Cambios en el entorno de NSX desde vRealize Network Insight: ejemplos de grupos de seguridad y reglas de firewall
Módulo 6: Resolución de problemas y creación de respaldos con vRealize Network Insight en NSX
James Emmons, Staff Technical Account Manager, NSX Technical Account Specialist, Estados Unidos
Análisis inicial de vRealize Network Insight
Resolución de problemas con vRealize Network Insight
Este laboratorio se ha configurado para que todas las tareas se puedan ejecutar desde la máquina Main Console como se muestra en la imagen:
1. Asegúrese de que esté conectado a esta máquina y que HOL-1903 sea el laboratorio seleccionado.
2. Haga clic en el navegador "Google Chrome" para acceder a las actividades del laboratorio.
Revise la sección "Networking & Security" de vCenter como se describe a continuación:
Seleccione el marcador vSphere Web (Flash) en el navegador Google.
Observe que la dirección URL del enlace web es https://vca-01a.corp.local/vsphere-client/?csp.
Inicie sesión en vCenter con el nombre de usuario administrator@corp.local y la contraseña VMware1!.
Configuración de tareas de respaldo con NSX Manager: inicio de sesión
Seleccione la carpeta de marcadores HOL Admin en el navegador Google.
Seleccione el marcador nsxmgr-01a en el navegador Google.
Observe que la dirección URL del enlace web es https://nsxmgr-01a.corp.local.
Inicie sesión en NSX Manager con el nombre de usuario admin y la contraseña VMware1!.
Botón "Backup & Restore" en NSX
A continuación, se ilustra la configuración de tareas de respaldo con NSX Manager:
Haga clic en el botón "Backup & Restore" en el tablero de NSX Manager.
Configuración de respaldo de NSX
Configuración de tareas de respaldo con NSX Manager: configuración del servidor FTP
Complete los campos de la ventana "Backup Location" de la siguiente manera:
En "IP/Host name", escriba 192.168.110.91.
En "Transfer Protocol", escriba FTP.
En "Port", escriba 21.
En "User name", escriba admin.
En "Backup Directory", escriba ftp://192.168.110.91.
En "Filename Prefix", escriba nsxmgr.
En "Pass Phrase", escriba VMware1!.
Una vez que haya completado todos los campos, haga clic en OK.
Cambio de programación del respaldo de NSX
Configuración de tareas de respaldo con NSX Manager: programación del respaldo en FTP.
Haga clic en el botón Change correspondiente con el campo "Scheduling".
vRealize Network Insight: Seguimiento de los pasos realizados en "Operate and Troubleshooting"
Se muestra la revisión de los cambios realizados en "Operate and Troubleshoot":
Observe la alerta en la página de inicio de "Operate and Troubleshoot" en vRNI que ha cambiado con respecto a la última vez que la vio.
Los respaldos están habilitados con NSX Manager pero no con el servidor SFTP preferido. Haga clic en el evento "NSX Manager backups not configured for SFTP" para obtener más información.
Cambios en el entorno con grupos de seguridad de NSX desde vRealize Network Insight
Se muestra la revisión de los cambios realizados en"Operate and Troubleshoot" desde el tablero principal:
Haga doble clic en NSX Security Group.
NSX Power Operations es una plataforma que les permite a los usuarios de NSX documentar su entorno de VMware NSX for vSphere en archivos de Microsoft Excel y Visio para usar y consultar con facilidad. En esta documentación, no solo se detalla el estado deseado (es decir, la configuración), sino también el estado real del entorno distribuido (como tablas sobre enrutamiento y reenvío). La plataforma también incluye herramientas integrales de comprobación del estado.
Visite el siguiente enlace para obtener más información y conocer las novedades sobre esta herramienta de la mano de sus autores originales: https://tinyurl.com/ybdsdxf3.
Se deben seguir al menos tres pasos para usar este conjunto de herramientas:
Siga todos los pasos para instalar el conjunto de herramientas y las aplicaciones de soporte requeridas (este paso ya se completó durante el laboratorio HOL-1903-NET).
Establezca conexión desde la máquina donde NSX-PowerOps está instalado.
Elija una de las siguientes tareas para completar:
Documentación sobre el entorno
Documentación sobre todos los componentes de NSX
Documentación de información sobre los hosts de ESXi
Documentación sobre el entorno de NSX mediante la herramienta Visio Diagramming
Documentación de información sobre enrutamiento
Documentación de información sobre balanceo de carga
Documentación de información sobre el DFW de NSX en Excel por medio de DFW2Excel (entornos pequeños)
Documentación de información sobre el DFW de NSX en Excel por medio de DFW2Excel (entornos grandes)
Sección del módulo 6 sobre NSX Data Center con NSX-PowerOps: James Emmons, Staff Technical Account Manager, NSX Technical Account Specialist, Estados Unidos
Revisión de la configuración de NSX con NSX-PowerOps
Validación de la ubicación de NSX PowerOps
Establezca conexión con NSX- PowerOps como se ilustra (NO USE LAS COMILLAS cuando introduzca los comandos):
NSX PowerOps está instalado en la siguiente dirección de directorio "c:\NSX-PowerOps\nsx-powerops-master\".
Inicio de la herramienta NSX-PowerOps
Establezca conexión desde la máquina donde NSX-PowerOps está instalado como se muestra a continuación:
Haga clic con el botón derecho del mouse en el ícono de Windows PowerShell desde el acceso directo en la consola principal de Windows Server.
Seleccione la opción Run as Administrator.
PowerOPs: PowerNSX está cargado
Es momento de establecer la conexión con VMware Infrastructure
1. Observe la sección NSX PowerOps Main Menu.
2. Seleccione el número 2 para establecer el perfil de conexión (esto es un requisito para completar las demás tareas: DEBE REALIZAR ESTE PASO ANTES DE REALIZAR CUALQUIER OTRA OPCIÓN [selección del n.° 2])
Selección del perfil de conexión predeterminado
Una vez que se haya creado y guardado el perfil de conexión predeterminado, lo puede seleccionar para comenzar a usar el conjunto de herramientas de NSX Power Ops.
Presione la tecla 4 y luego la tecla Enter para seleccionar la opción 4.
Presione la tecla X para regresar al menú principal NSX PowerOps (no "Connections Profiles").
NSX-PowerOps para realizar tareas de documentación
Para llegar a la ubicación actual, el último paso se debe realizar de forma correcta para garantizar que el conjunto de herramientas esté conectado con "Default Connection".
Si por alguna razón no está conectado con "NSX PowerOps Main Menu", vuelva a presionar la tecla X. No presione la tecla Q para salir porque quizá deba intervenir el instructor del laboratorio para volver a establecer la conexión para realizar este paso.
Observe que se muestra la conexión con NSX PowerOps Main Menu.
Herramientas de documentación de PowerOps
Elija la opción 4 ya que realizaremos la tarea "PowerOps Documentation Tools" (hay otras opciones disponibles pero no son el tema central de este laboratorio).
Si necesita información adicional sobre la resolución de problemas de NSX, revise todas las secciones de este laboratorio y póngase en contacto con el equipo de ventas de VMware que puede comunicarse con especialistas para satisfacer sus necesidades. Consulte son su equipo de ventas local sobre un especialista técnico de cuenta de NSX.
Código SKU del laboratorio: HOL-1903-02-NET
Versión: 20190108-215618

References: Resolución 
 resolución 
 resolución 
 resolución 
 Resolución 

Resolución 
 resolución