Protección de las redes y el almacenamiento de XenServer

En un entorno XenServer, las redes no solo se producen en el nivel físico, sino también en el nivel lógico. Desde el punto de vista de la capa 2 de red, XenServer funciona como un conmutador de red virtual que puede enviar tráfico internamente dentro del host (por ejemplo, en el caso de las redes privadas) y externamente a la red física.

Por lo tanto, es importante que el entorno de XenServer esté protegido en todos sus niveles: la capa de máquina virtual (invitado), la capa de hipervisor y la capa de red física, incluidas las redes de almacenamiento.

Recomendación

Le recomendamos que se asegure de que no haya datos que se crucen entre redes, incluidas las redes lógicas de la capa del hipervisor.

Separación del tráfico de red

XenServer tiene tres categorías distintas de tráfico de red en cada grupo: (a) tráfico de administración, (b) tráfico de almacenamiento y (c) tráfico de VM (sistema operativo invitado). Puede configurar los hosts de XenServer para que envíen este tráfico a través de redes independientes o compartidas.

En la siguiente ilustración se proporciona un ejemplo de esta separación en la que diferentes clases de tráfico utilizan diferentes NIC físicas.

En esta ilustración se muestra cómo las NIC que no están designadas para el tráfico de administración o almacenamiento solo transportan tráfico de máquina virtual.

• Gestión del tráfico: XenServer utiliza la red de administración para las comunicaciones de administración de XenServer, incluido el tráfico entre hosts, la migración en vivo, la importación y exportación de máquinas virtuales y las copias de seguridad de metadatos del grupo de recursos. La red de administración es la red conectada a la NIC que está configurada como interfaz de administración. El tráfico de administración no incluye las comunicaciones entre máquinas virtuales invitadas, pero sí incluye el tráfico que involucra a XenCenter, la consola de administración.

  La instalación de XenServer crea la red de administración en cada host y la asigna a una NIC específica que funcionará como interfaz de administración. XenServer le permitirá utilizar una única interfaz para los tres tipos de tráfico: administración, almacenamiento e invitado. Sin embargo, esta no es la configuración de red más segura y se recomienda encarecidamente separar el tráfico como se describe en esta sección.

• Tráfico de almacenamiento: El término tráfico de almacenamiento se refiere al tráfico de canal de fibra y al tráfico de almacenamiento basado en IP, como el tráfico del iniciador de software iSCSI, el tráfico NFS y el tráfico SMBv3. Sin embargo, cuando esta guía analiza la colocación del tráfico de almacenamiento en su propia red, se refiere específicamente al tráfico iSCSI y NFS. (El tráfico de Fibre Channel está inherentemente en su propia red). El tráfico de almacenamiento se analiza con más detalle a lo largo de esta sección y en Protección del almacenamiento virtualizado.

• Tráfico de invitados: El tráfico invitado se refiere al tráfico que se envía hacia o desde máquinas virtuales invitadas.

  La separación de la red física proporciona seguridad adicional. En la siguiente ilustración se proporciona un ejemplo.

En esta ilustración se muestra la interfaz de administración, la NIC utilizada para las comunicaciones de administración y la red de administración. La red de administración está separada de la red de almacenamiento y de la red de invitados.

Recomendación:

Se recomienda encarecidamente separar físicamente las redes de administración, almacenamiento e invitados a través de NIC, cables, conmutadores, puertos y configuración de red, así como separar lógicamente a través de la configuración en XenServer. Esto incluye asegurarse de que no envíe tráfico de invitado involuntariamente a través de la red de administración, como se explica en la sección siguiente.

Garantizar que el tráfico esté separado

Para comprender cómo separar el tráfico, es importante comprender cómo se comunican las máquinas virtuales.

Una máquina virtual solo puede usar una NIC para el tráfico de invitado si tiene una interfaz de red virtual en la misma red que la NIC.

No todas las NIC tienen interfaces de red virtual asociadas. Si no configura una interfaz de red virtual que se conecte a la red de administración, la NIC de administración se dedica al tráfico de administración. Por ejemplo, en la ilustración anterior, hay NIC conectadas a las redes de administración y almacenamiento que no tienen las interfaces de red virtual correspondientes.

En la ilustración anterior se muestran las máquinas virtuales que solo tienen interfaces de red virtual para la red invitada. Las máquinas virtuales no están conectadas a la red de administración o almacenamiento: las máquinas virtuales no tienen interfaces de red virtual que se conecten a esas redes.

Recomendación:

Se recomienda aislar las redes de producción de las redes de ensayo, pruebas y desarrollo.

Planificación de una red de almacenamiento independiente

Recomendación

Le recomendamos que segregue el tráfico configurando interfaces de almacenamiento adicionales para el tráfico de almacenamiento basado en IP y configurando XenServer para acceder al almacenamiento a través de esa interfaz. (Sin embargo, también debe aislar físicamente las redes invitadas y configurar máquinas virtuales solo para usar esas redes aisladas). Tenga en cuenta que las interfaces adicionales también se conocen como interfaces secundarias en cierta literatura.

El proceso general para crear una red de almacenamiento independiente es el siguiente:

1. Configuración de la infraestructura de red física para que haya diferentes tráficos en diferentes subredes.
2. Creación de una interfaz de almacenamiento para utilizar la nueva red.

Considere la posibilidad de configurar la redundancia, ya sea multiruta o vinculación, durante los pasos anteriores si lo desea.

Seguir el proceso anterior le permite establecer redes separadas para el tráfico basado en IP siempre que:

• XenServer no se configura para que utilice esta red para ningún otro propósito (por ejemplo, conectando una interfaz de red virtual a esta red).
• Se ha establecido la configuración de red física adecuada.

Por ejemplo, para dedicar una NIC al tráfico de almacenamiento, la NIC, el destino de almacenamiento, el conmutador o la VLAN deben configurarse de modo que solo se pueda acceder al destino a través de la NIC asignada.

Para asegurarse de que el tráfico de almacenamiento esté separado del tráfico de administración, la red de almacenamiento debe estar en una subred diferente. La subred para el almacenamiento debe ser una subred IP independiente que no sea “enrutable” desde la interfaz de administración. Si la configuración física o lógica no aplica la separación del tráfico, XenServer puede dirigir el tráfico de almacenamiento a través de la interfaz de administración después de un reinicio del host, debido al orden en que XenServer inicializa las NIC.

Planificación de una red de invitados separada

Recomendación

• Se recomienda configurar todas las máquinas virtuales para que solo tengan redes invitadas. Las máquinas virtuales no requieren acceso a las redes de almacenamiento y administración, como se explica a continuación.

• Le recomendamos que configure correctamente las redes de invitados para que no envíen tráfico involuntariamente a través de las redes de administración y almacenamiento:

  • Asegúrese de que la red de invitados esté físicamente aislada del tráfico de administración y almacenamiento. Conecte la NIC que las máquinas virtuales usarán para el tráfico de invitados a un puerto de conmutador que solo se usará para el tráfico de máquinas virtuales. Este puerto debe estar físicamente aislado de las redes de almacenamiento y administración.
  • Cree una interfaz de red virtual en las mismas redes que la NIC.
  • No enrute ningún tipo de tráfico, que no sea tráfico de invitado, a través de esa NIC.
  • Al crear máquinas virtuales, si configuró la interfaz de administración en la NIC 0, asegúrese de que la NIC 0 no esté habilitada en el Asistente para máquinas virtuales al crear la máquina virtual, como se explica en el procedimiento siguiente.

• Alternativa: En situaciones en las que los hosts solo tienen una NIC dedicada al tráfico de invitados, se recomienda separar el tráfico en redes lógicas independientes. Por ejemplo, una configuración común es que un servidor de aplicaciones gestione el tráfico “front-end” (por ejemplo, a un servidor web) y el tráfico “back-end” (por ejemplo, a una base de datos). Esto se puede hacer mediante VLAN. Una VLAN etiqueta el tráfico Ethernet por separado, pero el tráfico sigue pasando por la misma NIC física en el host.

• Se recomienda no asignar al dominio de control una dirección IP para ninguna red que no sean las redes de almacenamiento y la red de administración aislada. No coloque el tráfico de máquina virtual invitada en ninguna red que tenga una dirección IP de dominio de control.

• Le recomendamos que, si tiene una red de invitados que se conecta a una red que no está bajo el control de su organización (como Internet), se asegure de que el segmento local de la red esté protegido. Cualquier red desprotegida puede ser vulnerable a ataques de red de nivel 2, como ataques DHCP falsos, que deben realizarse desde el mismo switch que el objetivo del ataque.
• Se recomienda que, si tiene algunas máquinas virtuales que requieren acceso a Internet y otras que no, configure redes separadas para que las máquinas virtuales que no requieren acceso a Internet no se expongan directamente a posibles ataques desde Internet.

Para configurar máquinas virtuales solo con redes invitadas

Nota: No

Este procedimiento puede ser más fácil de realizar si cambia los nombres de las redes para asignarles nombres claros, como se describe en Nombrar las redes claramente.

1. Después de iniciar el XenCenter Nueva máquina virtual Asistente (VM > Nueva máquina virtual), siga las indicaciones hasta que llegue a la Gestión de redes página.

2. En el Gestión de redes , quite todas las redes que la máquina virtual no vaya a usar. Seleccione la red que desea eliminar y haga clic en Borrar.

   

   De forma predeterminada, la instalación de XenServer configura la interfaz de administración en la red 0, que suele ser NIC0.

   Las redes resultantes pueden tener un aspecto similar al siguiente:

   

3. Si es necesario, haga clic en Propiedades para configurar los ajustes de QoS o las direcciones MAC virtuales.

   Importante:

   Las interfaces de red virtual que aparezcan en este cuadro de diálogo se crearán como redes en la máquina virtual.

Nombrar las redes claramente

Recomendación

Se recomienda cambiar el nombre de las redes predeterminadas para que tengan nombres claros que sean significativos para la configuración y evitar que un invitado se conecte inadvertidamente a una red a la que no debería tener acceso, como la red de administración.

Por ejemplo, cambie los nombres predeterminados que XenServer asigna a las NIC por otros que representen las funciones que realizan en su entorno:

Para cambiar los nombres de las redes

En Gestión de redes en XenCenter, seleccione la red y haga clic en Propiedades, como se muestra en la siguiente captura de pantalla:

Esta captura de pantalla muestra los nombres de las redes, que se cambiaron de sus nombres predeterminados para mayor claridad. También puede agregar información sobre la red a la columna de descripción.

También puede cambiar los nombres de red ejecutando el siguiente comando:

  # xe network-param-set uuid=<network uuid> name-label="<new network name>"
<!--NeedCopy-->

Por ejemplo, para asignar a la red 1 el nombre “red de almacenamiento”, ejecute:

  # xe network-param-set uuid=213e396e-1e1f-0744-7a43-64c3e9dfd649 \ name-label="Storage Network"
<!--NeedCopy-->

El uso del parámetro name-label es lo mismo que cambiar el nombre de la red en XenCenter.

Consejo:

Para obtener el UUID de red, ejecute xe lista-de-red.

Protección de la red de administración

La protección de la red de administración es importante porque esta red puede proporcionar acceso a todos los componentes conectados a un host. La comunicación entre los hosts de XenServer 8.4 y XenCenter y otros hosts de XenServer 8.4 se realiza mediante conexiones TLS (encriptadas) al puerto 443. Sin embargo, las funciones de administración de XenServer escuchan tanto en el puerto 80 (sin cifrar) como en el puerto 443 (cifrado TLS) para las solicitudes de API de administración. Esto permite la interoperabilidad con versiones anteriores del producto y otros (p. ej. productos de terceros).

Recomendación

A menos que tenga agentes de API de administración de terceros que no puedan usar TLS, le recomendamos que bloquee el acceso al puerto 80 con el comando de la CLI: xe pool-param-set uuid=<pool uuid> https-only=verdadero.

Si necesita revertir este comando, por ejemplo, si necesita migrar máquinas virtuales a un host XenServer 8.4 desde una versión anterior del producto, puede hacerlo con el comando CLI: xe pool-param-set uuid=<pool uuid> https-only=false.

Es posible configurar la interfaz de administración para que no haya una dirección IP vinculada a ella. Sin embargo, esto significa que ninguna de las funciones de administración funcionará desde fuera de la consola local en el host de XenServer. Tenga en cuenta que en esta configuración no puede crear grupos de recursos, importar o exportar máquinas virtuales ni aprovechar de ningún otro modo características como las alertas por correo electrónico.

Configuración del bloqueo de puertos del switch

En entornos con máquinas virtuales invitadas que no son de confianza, puede ser conveniente usar medidas de seguridad, como la protección contra la suplantación de identidad, para reducir la capacidad de las máquinas virtuales para atacar a otras máquinas virtuales a través de la red.

Recomendación

• Recomendamos que los entornos con tráfico de invitados potencialmente hostil o desconocido configuren la función de bloqueo de puertos de conmutador de XenServer:
• Se recomienda usar la característica de bloqueo de puerto de switch para definir direcciones IP específicas desde las que una máquina virtual individual puede enviar tráfico.
• La función de bloqueo de puertos de conmutador de XenServer le permite controlar el tráfico que se envía desde máquinas virtuales desconocidas, no confiables o potencialmente hostiles al limitar su capacidad para fingir que tienen una dirección MAC o IP que no se les asignó.
• Se recomienda que los entornos que tienen (a) máquinas virtuales que contienen datos confidenciales y (b) máquinas virtuales que no son de confianza usan la característica de bloqueo de puerto de conmutador para evitar que una máquina virtual que no es de confianza envíe tráfico suplantado a máquinas virtuales confidenciales.

La función de bloqueo de puertos de conmutador de XenServer puede ayudar en implementaciones que tienen una arquitectura de red en la que cada máquina virtual tiene una dirección IP pública conectada a Internet. Para obtener más información sobre el bloqueo del puerto del switch, consulte el Documentación del producto.

Protección de la red física

Recomendación

• Le recomendamos que tome precauciones para asegurarse de que no cablea inadvertidamente la interfaz de administración a la red de invitados. Por ejemplo:
  • Se recomienda designar de forma coherente las mismas NIC para su uso con las mismas redes en todos los hosts de todos los grupos.
  • En entornos con varios grupos, se recomienda designar siempre puertos específicos para tipos específicos de tráfico y usar estos puertos de forma coherente. Por ejemplo, en todos los pools, utilice siempre el primer puerto de red para la red de administración, el segundo puerto de red para la red de almacenamiento, etc.
  • En caso de que su organización aún no tenga estándares de cableado, le recomendamos que considere etiquetar o codificar los cables por colores para indicar su propósito.

• Le recomendamos que borre todas las configuraciones anteriores cuando vuelva a utilizar conmutadores físicos.

  Las contraseñas o configuraciones anteriores podrían exponer su entorno a entidades o tráfico hostiles. Por ejemplo, alguien podría haber configurado el conmutador para enrutar el tráfico automáticamente a otro sitio o red.

• Le recomendamos que proteja la ubicación física de la red, incluida la seguridad del área física donde se encuentra la red.

Protección del almacenamiento virtualizado

Se considera que el almacenamiento de datos está virtualizado cuando no existe una relación uno a uno entre el dispositivo de almacenamiento físico y los dispositivos (o discos) de almacenamiento virtualizado resultantes. Por ejemplo, cuando un dispositivo de almacenamiento físico se presenta a los usuarios como uno o más dispositivos de almacenamiento virtualizados o, por el contrario, cuando varios dispositivos físicos se presentan como un disco virtual. Si bien la virtualización del almacenamiento de datos reduce la percepción de complejidad del usuario, es importante garantizar que el almacenamiento se virtualice de forma segura.

Para las empresas que desean proteger y monitorear su almacenamiento virtualizado, vale la pena señalar que el almacenamiento virtualizado puede residir en múltiples ubicaciones físicas simultáneamente.

Recomendación

• Se recomienda tener en cuenta dónde se encuentran todas las unidades físicas que se van a virtualizar al determinar la seguridad física de los discos y no colocar los discos en una ubicación en la que estén físicamente en riesgo.
• Por ejemplo, si agrega otro SR porque el SR original se quedó sin espacio y el nuevo SR se encuentra en una ubicación física diferente (por ejemplo, en un servidor que podría no estar en la misma sala de máquinas), asegúrese de que ambas ubicaciones sean físicamente seguras.

Las NIC de almacenamiento dedicadas requieren una dirección IP que debe estar en una subred IP diferente a la interfaz de administración principal. Puede usar XenCenter para dedicar una NIC de almacenamiento y también para vincular varias NIC para lograr resistencia.

Recomendación

• Se recomienda aislar el tráfico de almacenamiento del tráfico de administración. Si utiliza dispositivos de almacenamiento basados en IP, como NFS o iSCSI SR, el tráfico de almacenamiento también fluye a través del dominio de control de XenServer.
• Se recomienda que, cuando corresponda al tipo de almacenamiento, configure la autenticación de destino y de host. Esto ayuda a proteger sus datos si su red de almacenamiento está expuesta a otras partes menos confiables de su organización. Los ataques internos a las redes de almacenamiento pueden permitir que partes hostiles intercepten cualquier dato destinado al almacenamiento. Dichos datos van desde datos que podrían comprometer la integridad de su entorno virtual hasta datos confidenciales contenidos en las máquinas virtuales.

NFS

Un repositorio de almacenamiento NFS basado en archivos monta el repositorio NFS especificado en el dominio de control. Cada SR se representa como un directorio en el servidor NFS remoto, y cada disco virtual es un archivo en ese directorio almacenado en el formato de archivo VHD.

Recomendación

• Le recomendamos que se asegure de que, dado que el VHD no es un formato de archivo cifrado, solo los hosts autorizados de XenServer y los administradores autorizados puedan montar el sistema de archivos. Puede asegurarse de que solo los hosts XenServer correctos puedan montar el sistema de archivos limitando la exportación a direcciones IP específicas. La limitación de la exportación se realiza normalmente al configurar el sistema de almacenamiento NFS.
• Recomendamos asegurarse de que las interfaces de almacenamiento del dispositivo de almacenamiento remoto no sean visibles fuera de la red de almacenamiento dedicada.
• Se recomienda habilitar la autenticación de host AUTH_SYS NFSv4.

Iniciador de software iSCSI

En el caso del tráfico iSCSI, XenServer utiliza el iniciador de software OpenISCSI para conectarse a los destinos iSCSI.

Si comparte la red de almacenamiento iSCSI con otros grupos de XenServer o sistemas que no sean de XenServer, considere la posibilidad de separar el tráfico de almacenamiento iSCSI con VLAN.

Recomendación:

• Si tiene varias agrupaciones de XenServer, le recomendamos que no comparta redes de almacenamiento iSCSI entre agrupaciones que tengan diferentes niveles de confianza. Por ejemplo, un grupo de servidores de producción y un grupo de servidores de prueba no deben compartir una red de almacenamiento.
• Le recomendamos que configure la autenticación de host y destino CHAP a menos que esté utilizando GFS2.

Canal de fibra

Recomendación:

• Le recomendamos que habilite el enmascaramiento de LUN en su SAN para proteger el tráfico de Fibre Channel.

  El enmascaramiento de LUN es una forma de configurar un LUN para que solo acepte solicitudes de HBA específicos, de modo que un LUN esté disponible para algunos hosts y no para otros. El enmascaramiento de LUN protege a los LUN de la detección cuando se analiza un objetivo. En función de la configuración de HBA, el enmascaramiento de LUN puede permitir controlar qué hosts pueden acceder a qué volúmenes de una SAN. El enmascaramiento de LUN le permite configurar los LUN exactos que un host especificado puede detectar.

• Te recomendamos que crees zonas en tu SAN para separar y proteger el tráfico de Fibre Channel.

  La zonificación SAN es una forma de agrupar dispositivos de canal de fibra de forma lógica en la configuración física de la estructura de almacenamiento. Considere la posibilidad de implementar la división en zonas SAN para separar el tráfico de almacenamiento de los servidores más vulnerables (por ejemplo, servidores web u otros servidores con mucho tráfico de Internet) del tráfico de almacenamiento de otros servidores.

  Las zonas aíslan eficazmente los dispositivos de la zona de los dispositivos que se encuentran fuera de la zona y evitan que los dispositivos que se encuentran fuera de la zona detecten los dispositivos de la zona. Dado que la zonificación se implementa en la estructura mediante el conmutador de canal de fibra, la zonificación puede controlar el tráfico entre dispositivos y, en esencia, proporcionar un método de control de acceso para las SAN. Las zonas también proporcionan seguridad porque el tráfico de zona está aislado del tráfico de otras zonas, lo que, a su vez, limita la cantidad de tráfico comprometido en un ataque exitoso.

SMB

Si comparte la red de almacenamiento SMB con otros grupos de XenServer o sistemas que no sean XenServer, considere la posibilidad de separar el tráfico de almacenamiento SMB con VLAN.

Recomendación:

• Si tiene varios grupos de XenServer, le recomendamos que no comparta redes de almacenamiento SMB entre grupos que tengan diferentes niveles de confianza. Por ejemplo, un grupo de servidores de producción y un grupo de servidores de prueba no deben compartir una red de almacenamiento.
• Se recomienda configurar la autenticación de host de nombre de usuario y contraseña de SMB.