Implementar Sophos NDR en VMware ESXi o Hyper-V

Sophos NDR se ejecuta en ESXi o Hyper-V como un dispositivo virtual Integration Appliance. La máquina virtual requiere dos rutas claramente separadas: MGMT obtiene una dirección IP normal y se comunica con Sophos Fusion (antes Sophos Central) o Sophos Data Lake; SPAN1 y, opcionalmente, SPAN2 reciben únicamente copias reflejadas del tráfico que se va a inspeccionar. Por lo tanto, una máquina virtual en estado correcto o el estado Connected en Central aún no confirman que NDR pueda ver paquetes.

Flujo rápido: compruebe los requisitos previos y la capacidad, cree la configuración de NDR en Sophos Fusion, prepare la duplicación de tráfico para la plataforma correspondiente, implemente la imagen generada una sola vez, espere a que finalicen el primer inicio y el reinicio automático y, a continuación, valide por separado las rutas de administración y SPAN.

Límite importante: la ruta SPAN no está en línea y no debe utilizarse como red de administración. La duplicación de tráfico se configura en el switch y el hipervisor; el dispositivo NDR no modifica el tráfico de producción original. En el caso de Hyper-V, aquí se omiten deliberadamente comandos externos de PowerShell para configurar la duplicación. Implemente el diseño en Hyper-V de acuerdo con las directrices aprobadas de Microsoft y Sophos y verifíquelo con tráfico de prueba real.

Comprobar los requisitos previos

Los siguientes requisitos mínimos se aplican inicialmente a ambas plataformas:

• una licencia activa de Sophos Network Detection and Response integration license pack en el tenant utilizado;
• 4 vCPU, 16 GB de RAM y 160 GB de almacenamiento;
• los flags de CPU pdpe1gb para Packet Capture y avx2 para las funciones de aprendizaje automático;
• una red de administración dedicada con DHCP o una dirección estática, DNS, una puerta de enlace predeterminada y acceso saliente a Internet;
• rutas SPAN preparadas para obtener copias bidireccionales de todas las clases de tráfico aprobadas: tráfico virtual interno y tráfico físico externo, si ambos forman parte del alcance de supervisión acordado;
• responsabilidades documentadas para Central, el hipervisor, los switches físicos y la lista de permitidos del firewall.

Si el alcance aprobado contiene realmente solo una de estas clases de tráfico, documente expresamente ese límite. En tal caso, una única ruta SPAN no debe considerarse como cobertura de la otra clase.

No instale ningún Sophos Agent adicional ni otro agente antimalware en el dispositivo. Sophos administra las actualizaciones del sistema operativo, de seguridad y del dispositivo. Los requisitos propios de aplicación de parches o refuerzo no deben alterar este estado administrado sin una validación previa.

Límites de las plataformas

VMware ESXi requiere:

• ESXi 6.7 Update 3 o una versión posterior;
• VM hardware version 11 o una versión posterior;
• un modo EVC Skylake o posterior cuando se utilice Enhanced vMotion Compatibility;
• no realizar la implementación en VMware Cloud, ya que no es compatible.

Los indicadores de CPU deben seguir visibles en la máquina virtual con el modo EVC seleccionado. No basta con disponer de un procesador físico reciente si EVC oculta las capacidades necesarias.

Microsoft Hyper-V requiere:

• Hyper-V 6.0.6001.18016, correspondiente a Windows Server 2016, o una versión posterior;
• Processor Compatibility Mode desactivado;
• un máximo de 8 núcleos de CPU y 32 GB de RAM por máquina virtual NDR;
• como máximo un nodo NUMA y un socket de CPU.

Los límites de Hyper-V no son una recomendación para asignar siempre los recursos máximos a la máquina virtual. Su finalidad es evitar una topología NUMA no compatible.

Dimensionar la máquina virtual según el tráfico

El tamaño estándar con 4 vCPU está previsto para un dispositivo dedicado a NDR que no supere estos valores orientativos:

• 500 Mbit/s;
• 70'000 paquetes por segundo;
• 1'200 flujos por segundo.

Para cargas elevadas de hasta 1 Gbit/s, 300'000 paquetes por segundo o 4'500 flujos por segundo, utilice 8 vCPU. SPAN2 también requiere al menos 8 vCPU. Si la carga supera estos valores, distribúyala entre varios dispositivos NDR en puntos adecuados de la red; no amplíe una sola máquina virtual más allá de los límites documentados.

Si se ejecutan además integraciones de recopiladores de registros en el mismo dispositivo, planifique su carga por separado. NDR reserva dos CPU con prioridad alta cuando se utilizan 4 vCPU y tres cuando se utilizan 8 vCPU. No obstante, otras integraciones pueden generar carga en estas CPU. Con 16 GB de RAM, las integraciones de recopiladores de registros pueden utilizar como máximo 2 GB en total. Con independencia del número de integraciones, un dispositivo acepta como máximo 8'000 eventos de registro por segundo. Solo puede haber una integración NDR por dispositivo.

Permitir conexiones salientes

Si el firewall admite comodines, el dispositivo requiere los siguientes destinos:

yum.oracle.com es opcional porque el dispositivo utiliza el repositorio espejo de Sophos en JFrog si no puede acceder a ese destino. No extienda indiscriminadamente los comodines a otras zonas. Si el firewall no permite comodines, añada a la lista de permitidos la lista completa y actualizada de nombres de host de Sophos correspondiente a la región antes del cambio y verifíquela desde la zona MGMT mediante pruebas de DNS y conectividad. Una lista abreviada o copiada de otra región no es una alternativa segura.

Crear la integración y la imagen en Sophos Fusion

1. En Sophos Fusion, abra Threat Analysis Center > Integrations > Marketplace.
2. Seleccione Sophos Network Detection and Response (NDR).
3. En Data Ingest (Security Alerts), haga clic en Add Configuration.
4. En Step 1, introduzca un nombre único y una descripción para la integración.
5. En Step 2, seleccione un dispositivo existente o haga clic en Create new appliance. Un dispositivo existente no debe tener ya otra integración NDR.
6. Para un dispositivo nuevo, elija un Appliance name único, una descripción y la plataforma correcta, VMware ESXi o Microsoft Hyper-V.
7. En Internet-facing network port settings, configure DHCP o Manual. Las direcciones asignadas mediante DHCP deben reservarse.
8. En Step 3, introduzca un Exclusion list name. Este nombre es obligatorio aunque la lista esté vacía inicialmente.
9. Para finalizar, haga clic en Save.

Si selecciona Manual, complete los campos IP address, Subnet mask, Gateway address, DNS 1 y, opcionalmente, DNS 2. Este es un ejemplo interno:

• IP address: 10.0.252.5
• Subnet mask: 255.255.255.0
• Gateway address: 10.0.252.1
• DNS 1: 10.0.252.53
• DNS 2: 10.0.252.54

Sustituya estos valores por direcciones disponibles y servidores DNS accesibles desde su propia red de administración. Compruebe previamente la dirección estática con el pool DHCP, el sistema IPAM y los hosts existentes.

En Domain exclusions, puede introducir un nombre de dominio. Protocol exclusions tiene un campo para el protocolo principal, como TCP o UDP, y otro para el subprotocolo, como facebook; cuando se especifican ambos, Central los une con un solo punto. No excluya un protocolo principal completo únicamente para reducir el volumen de datos. Cada exclusión requiere un falso positivo confirmado o una decisión de capacidad justificada, un responsable y una fecha de revisión.

Después de guardar, seleccione la descarga específica de la plataforma en la columna Actions: Download OVA file para ESXi o el paquete ZIP para Hyper-V. El estado situado a la izquierda de la integración cambia a Waiting for deployment. La imagen contiene la configuración específica del dispositivo y no debe reutilizarse entre tenants ni dispositivos.

Implementar en VMware ESXi

1. Preparar los grupos de puertos SPAN

Para el tráfico virtual interno, cree un grupo de puertos dedicado en el vSwitch estándar correspondiente:

1. Abra Networking > Virtual switches y seleccione el vSwitch previsto.
2. En Port groups, haga clic en Add port group.
3. Asigne un nombre único.
4. Establezca VLAN ID en 4095.
5. En Security, establezca Promiscuous mode en Accept.
6. Guarde el grupo de puertos.

Para el tráfico reflejado de un switch físico, utilice un vSwitch independiente con su propio grupo de puertos SPAN siguiendo el mismo patrón. En vSwitch topology, utilice Add uplink para asignar una NIC física disponible. Conecte el puerto de destino de duplicación dedicado del switch físico directamente a esta NIC del host ESXi.

En el switch físico, seleccione como orígenes de duplicación únicamente los puertos o las VLAN aprobados y seleccione ambos sentidos. El puerto de destino transporta las copias a la NIC de ESXi y no debe utilizarse simultáneamente como puerto normal de acceso, enlace troncal o administración. La sintaxis exacta del switch depende del fabricante y no debe copiarse de un ejemplo destinado a otro modelo.

Si se utilizan conjuntamente SPAN físico y vMotion, la máquina virtual NDR debe permanecer en el host ESXi cuya NIC física recibe el tráfico reflejado. Una migración involuntaria a otro host puede eliminar silenciosamente la ruta SPAN aunque MGMT siga funcionando.

2. Importar el OVA y asignar las interfaces

El OVA descargado está vinculado a esta configuración de Central y solo puede utilizarse una vez. Para sustituir el dispositivo o realizar una implementación nueva, genere un OVA nuevo en Central.

1. En el host ESXi, abra Virtual Machines > Create/Register VM.
2. Seleccione Deploy a virtual machine from an OVF or OVA file.
3. Introduzca un nombre para la máquina virtual y seleccione ndr-sensor.ova.
4. Seleccione Standard como tipo de almacenamiento y, a continuación, elija el datastore previsto.
5. En Deployment options, asigne las redes cuidadosamente:
   • SPAN1: primer grupo de puertos SPAN preparado;
   • SPAN2: segundo grupo de puertos SPAN, si realmente es necesario;
   • SYSLOG: para un dispositivo dedicado a NDR, seleccione un grupo de puertos provisional y desconecte el adaptador después de la importación;
   • MGMT: el grupo de puertos de administración con DHCP o los parámetros de red estáticos introducidos en Central.
6. Establezca Disk Provisioning en Thin.
7. Active Power on automatically.
8. Omita Additional settings sin realizar cambios y haga clic en Finish para importar.

Antes de encender la máquina virtual por primera vez, vuelva a documentar la asignación, el estado del enlace y las direcciones MAC de todas las vNIC. MGMT no debe estar en un grupo de puertos SPAN. Si se utiliza SPAN2, la máquina virtual debe tener al menos 8 vCPU.

Implementar en Microsoft Hyper-V

1. Preparar el diseño de duplicación de tráfico

Antes de ejecutar el script, determine la finalidad de cada vSwitch:

• un vSwitch normal para MGMT con DHCP o la ruta de red estática planificada;
• una ruta de destino para SPAN1;
• opcionalmente, una segunda ruta de destino para SPAN2, en cuyo caso se requieren al menos 8 vCPU;
• ninguna ruta SYSLOG activa, salvo que el mismo dispositivo procese también integraciones de terceros aprobadas.

En Hyper-V, la configuración de la duplicación de tráfico consta conceptualmente de cuatro partes: un puerto de duplicación de tráfico, una SPAN Virtual Interface conectada al vSwitch, la Microsoft NDIS Capture Extension activada y los modos de duplicación Source y Destination correctamente configurados. La implementación depende de la versión de Windows/Hyper-V, del tipo de vSwitch y del origen del tráfico que se va a reflejar. Por este motivo, no copie comandos de PowerShell sin verificar de otros entornos.

Antes de iniciar NDR, el equipo de la plataforma comprueba la ruta prevista como prueba rápida de implementación mediante un flujo de prueba bidireccional conocido. La copia debe llegar a la ruta de destino prevista sin alterar el flujo de producción original. Solo entonces se selecciona este vSwitch como destino SPAN en el script de Sophos. Esta prueba individual no confirma que la duplicación de tráfico tenga una cobertura completa.

2. Extraer el ZIP y ejecutar el script de Sophos

1. Extraiga el ZIP descargado de Central en una carpeta local protegida del host Hyper-V. Contiene discos virtuales, seed.iso y ndr-sensor.ps1.
2. En la carpeta, inicie ndr-sensor.ps1 con Run with PowerShell.
3. Cuando aparezca Security Warning, verifique el archivo local descargado directamente de Central y permita su ejecución con Open.
4. Introduzca un nombre único para la máquina virtual.
5. Compruebe el nuevo directorio de la máquina virtual que se muestra en la ruta predeterminada de los discos virtuales e introduzca C para crearlo.
6. Especifique 4 CPU para el tamaño estándar o 8 CPU para una carga elevada o SPAN2.
7. Especifique 16 GB de RAM como valor predeterminado; no supere el límite de 32 GB de Hyper-V.
8. En la lista numerada de vSwitches, seleccione primero el vSwitch de MGMT.
9. Para SYSLOG en un dispositivo dedicado a NDR, seleccione un vSwitch provisional y desconecte este adaptador después de la creación.
10. Seleccione el vSwitch preparado para SPAN1 y, si está previsto, el de SPAN2.
11. Espere hasta que aparezca Installation Completed Successfully y, después, pulse cualquier tecla para salir del script.
12. Abra la nueva máquina virtual en Hyper-V Manager y, antes de iniciarla, compruebe la CPU, la RAM, los adaptadores de red, los vSwitches conectados y el adaptador SYSLOG desconectado.

Los discos virtuales y seed.iso generados por Sophos forman un conjunto. No sustituya archivos individuales por otros con el mismo nombre procedentes de una descarga anterior.

Primer inicio y prueba rápida de implementación

Durante el primer inicio, el dispositivo comprueba las redes asignadas y el acceso a Internet y, después, se reinicia automáticamente. Este proceso puede tardar hasta diez minutos.

No interrumpa el primer inicio ni el reinicio automático. Apagar manualmente la máquina virtual durante este periodo puede dejarla en un estado incompleto y no constituye un paso de resolución de problemas.

Realice la prueba rápida técnica de implementación en este orden:

1. Consola de la máquina virtual: el proceso de arranque finaliza sin un bucle persistente de errores o reinicios.
2. Ruta de administración: se puede acceder a la dirección MGMT configurada o reservada, a DNS, NTP y a los destinos salientes necesarios.
3. Ruta de control de Central: en Threat Analysis Center > Integrations > Configured > Integration Appliances o en la página de la integración NDR, el dispositivo cambia de Waiting for deployment a Connected.
4. Ruta SPAN: para cada ruta SPAN implementada, genere un flujo de prueba anunciado e inocuo en ambos sentidos entre dos sistemas de prueba conocidos. En el switch o hipervisor, Source, Direction y Destination deben coincidir con el cambio; en el dispositivo, el adaptador SPAN asignado debe recibir tráfico.
5. Coherencia: compare el intervalo de tiempo, las direcciones de origen y destino y el sentido del flujo de prueba observado. La ruta implementada correspondiente solo queda confirmada para esta prueba rápida cuando estos valores coinciden.
6. Carga: durante un primer periodo de carga adecuado, compare el rendimiento, los paquetes y los flujos con el nivel de dimensionamiento seleccionado. El estado Connected no demuestra que exista capacidad suficiente.

No se requiere una detección artificial para la prueba rápida de implementación. Lo importante es contar con una ruta de administración estable y demostrar que hay tráfico bidireccional en la interfaz SPAN correcta. El flujo de prueba no contiene malware ni datos reales de clientes en una Packet Capture.

Esta prueba rápida demuestra únicamente las rutas probadas de forma específica. La aceptación completa de todos los orígenes, VLAN, sentidos y clases de tráfico previstos corresponde al runbook independiente Planificar y validar la duplicación de tráfico para Sophos NDR; ni Connected ni un único flujo correcto se consideran aquí una prueba de que la cobertura de duplicación sea completa.

Resolver problemas según el síntoma

El estado permanece en Waiting for deployment

1. Verifique que se haya implementado la imagen correcta, recién descargada desde esta configuración.
2. Compruebe la consola y el estado de alimentación de la máquina virtual y espere al menos diez minutos sin interrumpir el primer inicio.
3. Compare la vNIC de MGMT, el grupo de puertos o vSwitch y la reserva DHCP o los campos estáticos.
4. Compruebe DNS, la puerta de enlace, NTP, TCP 443, TCP 22 y UDP 123 desde la red de administración de acuerdo con la lista de permitidos.
5. No vuelva a realizar la implementación hasta haber completado estas comprobaciones. En ESXi se requiere un OVA recién generado; no vuelva a importar el OVA ya utilizado.

Connected, pero no hay tráfico NDR

En ESXi, compruebe primero la asignación de SPAN1/SPAN2, VLAN ID 4095, Promiscuous mode: Accept, el enlace ascendente físico y el puerto de destino de duplicación. Si utiliza vMotion, verifique que la máquina virtual siga ejecutándose en el host que tiene conectada la NIC de SPAN.

En Hyper-V, el equipo de la plataforma comprueba la SPAN Virtual Interface, la NDIS Capture Extension, el modo Source/Destination y el vSwitch seleccionado en el script de Sophos. No añada reglas de firewall ni comandos de duplicación inventados basándose en suposiciones.

En ambas plataformas, no restrinja de inmediato el filtro de prueba: compruebe primero los contadores del adaptador y un flujo bidireccional claramente identificable. El tráfico MGMT en el adaptador MGMT no demuestra que SPAN funcione.

Solo se ve un sentido o una red

• El origen de duplicación debe incluir tanto el envío como la recepción.
• Con enrutamiento asimétrico, la ruta de retorno puede utilizar otro enlace ascendente.
• El tráfico virtual interno y el físico externo pueden requerir rutas SPAN independientes.
• Si SPAN2 está configurado, el segundo vSwitch o grupo de puertos debe estar asignado correctamente y debe haber al menos 8 vCPU disponibles.

Repita exactamente el mismo flujo de prueba después de cada corrección. De este modo, quedará claro qué cambio ha surtido efecto.

Dragonfly permanece en Pending

Si Central ya muestra Connected, pero NDR no funciona, compruebe el estado del servicio Dragonfly en Sophos VA Console. Antes de realizar este paso, debe haberse habilitado el acceso a la consola local según el runbook independiente Operar Sophos NDR Integration Appliance y el sensor. No reutilice para este fin credenciales del hipervisor o de Central sin validarlas; este runbook de implementación no crea ni divulga credenciales locales del dispositivo.

Si el estado es Pending en un clúster EVC de ESXi, compruebe primero el modo EVC y las capacidades de CPU visibles. Sandy Bridge no es compatible con este uso; se requiere Skylake o una versión posterior, además de pdpe1gb y avx2.

En Hyper-V, compruebe también Processor Compatibility Mode, los límites de CPU y RAM y la topología, que no debe tener más de un nodo NUMA y un socket de CPU. No intente «reparar» la máquina virtual añadiendo CPU o RAM por encima de los límites compatibles.

Faltan paquetes o resultados bajo carga

Compare el rendimiento, los paquetes y los flujos actuales con los límites de dimensionamiento. Si un destino SPAN es más lento que el conjunto de sus orígenes, la copia puede perder paquetes mientras el tráfico de producción continúa sin interrupciones. En ese caso, restrinja la selección de orígenes, divida las rutas SPAN o utilice varios dispositivos. Las exclusiones amplias de protocolos no sustituyen un dimensionamiento correcto.

Reversión local limitada de esta implementación

Los siguientes pasos son una recomendación conservadora de reversión local del cambio para la implementación pasiva descrita aquí. No constituyen un procedimiento completo de retirada o baja documentado por Sophos. La reversión se limita deliberadamente a los objetos del sensor y de duplicación creados como parte del cambio:

1. Guarde las evidencias de las pruebas y los últimos estados conocidos: estado de Central, recursos de la máquina virtual, asignación de interfaces, orígenes de duplicación y sentidos.
2. Desactive primero la sesión SPAN o de duplicación en el switch o hipervisor. Durante este proceso, no elimine ni vuelva a cablear los puertos de origen, las VLAN ni los vSwitches de producción.
3. Verifique que el tráfico original siga funcionando y que no lleguen más copias a la ruta de destino de NDR.
4. Después, apague correctamente la máquina virtual NDR.
5. Elimine los grupos de puertos, vSwitches, enlaces ascendentes o archivos de la máquina virtual dedicados solo después de confirmar que los utiliza exclusivamente este dispositivo. Los objetos compartidos de administración o producción permanecen intactos.
6. Revierta la reserva DHCP estática, la lista de permitidos del firewall y los registros DNS como cambios independientes después de comprobar sus referencias.

La integración o el dispositivo de Central no se eliminan como parte de esta reversión local. Dicha eliminación queda fuera de esta reversión de la implementación y requiere un proceso de baja independiente, validado y aprobado. Del mismo modo, un OVA existente no se considera una imagen de reversión: genere una imagen nueva en Central para otra implementación en ESXi.

Por lo tanto, tras un primer inicio fallido, la reversión limitada localmente consiste en detener la duplicación, apagar la máquina virtual, revertir únicamente los objetos de red asociados claramente a este cambio e identificar la causa antes de una nueva implementación. No convierta de forma improvisada una prueba pasiva de NDR en otro diseño de red ni en una ruta en línea.