Sophos NDR: elegir la plataforma y dimensionar correctamente el sensor

Sophos NDR puede ejecutarse como appliance virtual en VMware ESXi, Microsoft Hyper-V, AWS o Nutanix, así como en hardware certificado de Dell, NUC y OnLogic. La elección se realiza antes del despliegue: los sensores virtuales y en la nube se dimensionan según el ancho de banda, los paquetes y los flujos; para el hardware se aplican exclusivamente los modelos certificados y sus niveles de capacidad.

Decisión rápida: Para un sensor NDR virtual dedicado, la configuración estándar es suficiente hasta 500 Mbit/s, 70'000 paquetes por segundo y 1'200 flujos por segundo. Para hasta 1 Gbit/s, 300'000 paquetes por segundo y 4'500 flujos por segundo, se utilizan 8 vCPUs. Si una sola de estas métricas supera el límite, se necesitan varias appliances virtuales distribuidas por la red. Para anchos de banda superiores o un sensor físico, se elige hardware certificado en función de la carga sostenida y máxima realmente medida.

Licencia y fundamentos de planificación

Para la integración se requiere el Sophos Network Detection and Response integration license pack. Sophos calcula la licencia de NDR según el número total de usuarios y servidores de la organización. El software para las appliances virtuales está incluido; con la licencia se pueden desplegar tantos sensores NDR como sean necesarios. Esto es importante cuando un entorno de gran tamaño debe distribuirse entre varios sensores debido a los límites documentados de las máquinas virtuales.

Antes de elegir la plataforma, se recopilan los siguientes valores:

• ancho de banda máximo y sostenido del tráfico que realmente se va a replicar,
• paquetes por segundo y flujos por segundo durante el mismo periodo,
• capacidad del switch o del puerto espejo desde el que el sensor recibe el tráfico,
• número y ubicación previstos de los sensores,
• otras integraciones de Log Collector que deban ejecutarse en la misma appliance,
• microarquitectura de CPU, flags de CPU, memoria y almacenamiento disponibles,
• plataforma de virtualización compatible o modelo exacto de hardware certificado.

Un enlace ascendente a Internet por sí solo no constituye una base suficiente para el dimensionamiento. El sensor procesa el tráfico que se replica hacia él. Por tanto, los valores deben medirse en el punto de replicación previsto y documentarse como carga sostenida y carga máxima.

Elegir la plataforma

Appliance virtual o nube

Una appliance virtual es adecuada cuando ya se dispone de una de las plataformas probadas, la carga se mantiene dentro de los límites de la máquina virtual o puede distribuirse de forma razonable entre varios sensores. Se admiten:

• VMware ESXi,
• Microsoft Hyper-V,
• Amazon Web Services (AWS),
• Nutanix.

Para AWS, la especificación técnica de Sophos NDR indica el tipo de instancia c5n.2xlarge. Los mecanismos concretos de despliegue, las interfaces de red y los ajustes de Traffic Mirroring se describen en la guía de despliegue correspondiente y no se deducen de la decisión de dimensionamiento.

VMware Cloud no es compatible. Para ESXi y Hyper-V también se aplican los requisitos de versión y CPU que se describen más adelante. En cambio, los requisitos disponibles no contienen una matriz de versiones común para AWS y Nutanix; por tanto, sus requisitos de despliegue deben comprobarse en las instrucciones de la plataforma correspondiente.

Hardware certificado

El hardware es una opción cuando se necesita un sensor físico dedicado o cuando un nivel de capacidad certificado se ajusta a la carga medida. Sophos solo admite NDR en hardware con sistemas certificados. De ello no debe deducirse que sean compatibles los servidores x86 genéricos, las variantes de modelos similares o los sistemas montados por cuenta propia.

Hay sistemas certificados de estas familias:

• Dell,
• NUC,
• OnLogic.

El nombre del fabricante no es el único factor decisivo. Antes de la adquisición, debe cotejarse el modelo exacto con las Certified hardware specifications for NDR vigentes. La instalación, la imagen de disco y los pasos específicos del fabricante solo se abordan después de tomar esta decisión sobre el modelo.

Dimensionar los sensores virtuales y en la nube

Recursos mínimos

Para ESXi y Hyper-V se aplican los siguientes recursos mínimos:

• 4 CPUs,
• 16 GB RAM,
• 160 GB de almacenamiento.

La OVA de VMware ya viene preconfigurada con estos valores mínimos para Sophos NDR y las integraciones de Log Collector. AWS utiliza el tipo de instancia indicado anteriormente. Para Nutanix, la fuente de requisitos utilizada no especifica en este punto recursos mínimos independientes. Sin embargo, los recursos mínimos aún no constituyen una garantía de capacidad. Para elegir entre la configuración estándar, 8 vCPUs y varias appliances, deben tenerse en cuenta las tres métricas de tráfico.

Los valores límite conforman conjuntamente una clase de carga. Un sensor con 400 Mbit/s, pero con 100'000 paquetes por segundo, ya no se encuentra por completo en la clase Media. Si los valores superan los de la clase Alta, Sophos prevé varias appliances virtuales distribuidas por la red; de las fuentes no se desprende que pueda utilizarse una única máquina virtual de mayor tamaño por encima de este límite.

La especificación técnica limita cada sensor NDR virtual a un máximo de 1 Gbit/s. Este valor no invalida los límites más estrictos de paquetes y flujos.

Comprobar la CPU y el hipervisor

Los siguientes requisitos de microarquitectura y flags se aplican al sistema en el que se ejecuta la máquina virtual. En ESXi, Hyper-V y otros hosts de máquinas virtuales autogestionados, los flags de CPU pdpe1gb y avx2 deben estar disponibles en la máquina virtual. pdpe1gb se necesita para la captura de paquetes y avx2 para las funciones de aprendizaje automático. Un mayor número de vCPUs no compensa la ausencia de estos flags.

Para AWS, en cambio, se comprueban el tipo de instancia compatible y los requisitos de despliegue de AWS; las appliances físicas se validan mediante el modelo certificado exacto y su configuración aprobada. De ello no se deriva la necesidad de comprobar manualmente flags adicionales ni para AWS ni para el hardware certificado.

Sophos documenta las siguientes microarquitecturas de CPU:

• Intel: Skylake Generation 6, Kaby Lake Generation 7, Coffee Lake Generation 8, Coffee Lake Refresh y Cascade Lake Generation 9, Comet Lake Generation 10, Cannon Lake/Palm Cove Generation 10, Ice Lake/Sunny Cove Generation 10, Rocket Lake/Cypress Cove Generation 11, Alder Lake/Golden Cove Generation 12 y Raptor Lake/Raptor Cove Generation 13.
• AMD: Naples y Great Horned Owl con Zen 1, Rome con Zen 2, Milan con Zen 3 y Genoa con Zen 4.

También pueden utilizarse CPU más recientes, siempre que estén disponibles los dos flags necesarios. Sophos señala que deberían funcionar las CPU lanzadas desde el primer trimestre de 2015; no obstante, para la aprobación sigue siendo necesaria la comprobación concreta de ambos flags en la máquina virtual prevista.

Para los hipervisores se aplican las siguientes versiones mínimas y limitaciones:

• VMware ESXi: versión 6.7 Update 3 o posterior y VM Hardware Version 11 o superior. En un clúster EVC debe seleccionarse Skylake generation or later. VMware Cloud no es compatible.
• Microsoft Hyper-V: versión 6.0.6001.18016 en Windows Server 2016 o posterior. Processor Compatibility Mode no es compatible.

Appliance compartida con Log Collectors

Los valores de máquina virtual para las clases Media y Alta se aplican a una appliance que solo ejecuta Sophos NDR. Si también se alojan integraciones de Log Collector, la planificación parte del tamaño de NDR y añade después la carga de dichas integraciones. Se han documentado los siguientes límites y efectos:

• En conjunto, todas las integraciones de Log Collector de una máquina virtual pueden aceptar un máximo de 8'000 eventos por segundo.
• Una integración de Log Collector necesita aproximadamente 400 MB RAM con una carga elevada.
• Con 4 CPUs, NDR utiliza 2 CPUs; con 8 CPUs, utiliza 3 CPUs. No obstante, otras integraciones también pueden utilizar estas CPU y reducir así el volumen de tráfico que NDR puede procesar.
• Con 16 GB RAM, las integraciones de Log Collector pueden utilizar como máximo 2 GB en conjunto, para que NDR conserve suficiente memoria.
• Un Log Collector que alcance la tasa máxima de eventos necesita, en una máquina virtual con las 4 CPUs estándar, aproximadamente la misma capacidad de procesamiento que NDR con una carga media.

No existe un único tamaño aplicable de forma general a las cargas mixtas. Si se prevé que se superen los límites de NDR o los recursos disponibles, deben planificarse appliances adicionales. Cuando varias integraciones de Log Collector superan en conjunto los 8'000 eventos por segundo, se utilizan varias máquinas virtuales. Si, por el contrario, una única integración supera este límite, primero se intenta reducir el volumen de eventos mediante los ajustes de Syslog del sistema de origen. Los valores aproximados documentados no justifican una sobreasignación arbitraria.

Dimensionar el hardware certificado

Sophos determina el nivel de hardware a partir de la capacidad del switch que replica el tráfico y de la carga sostenida y máxima. El sensor NDR debe tener la misma capacidad que el switch del que procede el tráfico replicado. Las siguientes recomendaciones se basan en una organización típica con un 20 por ciento de usuarios avanzados, un 60 por ciento de usuarios habituales y un 20 por ciento de usuarios con un uso ligero. También se presuponen VoIP, algo de streaming de vídeo, cargas y descargas de gran tamaño, así como servidores de aplicaciones y web.

Estos nombres y niveles de rendimiento solo sirven para realizar una preselección. La adquisición no se aprueba hasta que tanto el modelo exacto como la configuración exacta figuren en las Certified hardware specifications for NDR vigentes.

Para cada fila, Sophos documenta una posible carga máxima de dos a tres veces la carga típica. Este valor máximo no sustituye una medición y no debe confundirse con el nivel de capacidad. Si también hay un uso intensivo del streaming de vídeo y música, puede ser necesario el nivel inmediatamente superior; la decisión se toma en función de la carga sostenida y máxima medida y de los límites certificados vigentes. Si predomina el uso del correo electrónico, puede ser adecuado un nivel inferior, siempre que la carga sostenida y máxima medida y el número de usuarios se mantengan dentro de sus valores.

El ancho de banda y el número de usuarios no bastan por sí solos para elegir el hardware. Además, en la certificación vigente deben comprobarse el número máximo de conexiones por segundo y la configuración aprobada de CPU, RAM y, cuando corresponda, sockets. Esto resulta especialmente importante para el tráfico con muchas conexiones. Por ejemplo, la hoja de datos de Sophos NDR del 19 de diciembre de 2024 indica para dos configuraciones del R660 el mismo rendimiento nominal, pero distintos límites de conexiones y recursos:

Estas son las configuraciones de la hoja de datos a fecha de 19.12.2024:

Dell R660, 2 sockets

• Rendimiento máx.: 40 Gbit/s
• Conexiones/s máx.: 120'000
• CPUs: 64
• RAM: 128 GB

Dell R660, 1 socket

• Rendimiento máx.: 40 Gbit/s
• Conexiones/s máx.: 80'000
• CPUs: 32
• RAM: 64 GB

Dell R650

• Rendimiento máx.: 20 Gbit/s
• Conexiones/s máx.: 40'000
• CPUs: 24
• RAM: 64 GB

Dell R450

• Rendimiento máx.: 10 Gbit/s
• Conexiones/s máx.: 20'000
• CPUs: 16
• RAM: 32 GB

Dell R350

• Rendimiento máx.: 4 Gbit/s
• Conexiones/s máx.: 8'000
• CPUs: 8
• RAM: 32 GB

Intel NUC 13th Gen

• Rendimiento máx.: 2,5 Gbit/s
• Conexiones/s máx.: 4'000
• CPUs: 12
• RAM: 32 GB

Estos valores fechados muestran todas las dimensiones técnicas del dimensionamiento y la importancia de la configuración exacta, pero no constituyen una matriz actual de adquisición o certificación. Para el R360, el R660xs, OnLogic y cualquier variante distinta, los valores que faltan no se deducen de modelos similares, sino que se toman exclusivamente de la especificación certificada vigente.

Las recomendaciones de hardware son un modelo de carga, no una garantía para cualquier distribución del tráfico. El streaming y los flujos de copias de seguridad de gran tamaño generan mucho volumen; Sophos NDR está optimizado para este tráfico de streaming y «Elephant Flow», mientras que muchas amenazas se detectan en el tráfico normal de navegación y aplicaciones. Por ello, se evalúan conjuntamente el perfil de los usuarios y los valores reales de la red.

Requisitos de red antes del despliegue

La appliance necesita conexiones salientes para iniciarse y recibir actualizaciones. Si el firewall admite comodines, Sophos documenta las siguientes reglas de acceso:

yum.oracle.com es opcional; sin acceso, la appliance utiliza la réplica del repositorio Sophos JFrog. Si el firewall no admite comodines, esta breve tabla no debe transformarse en una lista de hosts supuestos. En ese caso se utiliza la lista vigente específica de la región que figura en la página de Sophos Appliance requirements.

En la Integration Appliance no se instala ni Sophos Agent ni ningún otro agente antimalware. Las actualizaciones del sistema operativo y de seguridad tampoco se instalan manualmente; Sophos gestiona estas actualizaciones.

Validar y entregar la decisión

Antes del despliegue, un registro de planificación debe contener al menos los siguientes puntos:

1. Plataforma: ESXi, Hyper-V, AWS, Nutanix o el modelo exacto de hardware certificado.
2. Periodo de medición: fecha, hora y duración de la medición, así como los valores sostenidos y máximos de ancho de banda, paquetes y flujos en el punto de replicación previsto.
3. Dimensionamiento: clase de carga o nivel de hardware elegidos y el límite con menor margen en cada caso; para el hardware, también las conexiones máximas por segundo medidas frente al límite certificado vigente.
4. Recursos según la plataforma:
   • ESXi, Hyper-V y otros hosts de máquinas virtuales autogestionados: vCPUs, RAM, almacenamiento, modelo de CPU y los flags pdpe1gb y avx2 visibles en la máquina virtual.
   • AWS: tipo de instancia compatible c5n.2xlarge y requisitos de las instrucciones de despliegue de AWS.
   • Hardware certificado: modelo certificado exacto y configuración aprobada de CPU, RAM y sockets.
5. Carga adicional: nombres y eventos por segundo previstos de todas las integraciones de Log Collector alojadas en la misma appliance.
6. Red: conexiones de gestión y replicación previstas, así como reglas de acceso saliente confirmadas para puertos y dominios.
7. Escalado: número y ubicación de sensores adicionales si un sensor virtual fuera a superar los límites de la clase Alta.

La decisión es sólida cuando cada valor medido se encuentra dentro del nivel elegido y se cumplen los requisitos específicos de la plataforma. En los hosts de máquinas virtuales autogestionados, estos requisitos incluyen el hipervisor, la CPU y los flags visibles en la máquina virtual. En AWS, se tienen en cuenta el tipo de instancia compatible y los requisitos de despliegue. Para el hardware, el modelo exacto, la configuración de CPU, RAM y sockets, el rendimiento y el número máximo de conexiones por segundo deben coincidir con la certificación vigente. En una appliance compartida también deben tenerse en cuenta la tasa de eventos, la RAM y el impacto en la CPU de los Log Collectors.

La creación de la imagen, la instalación, el registro, el Traffic Mirroring y la primera Detection forman parte de los pasos posteriores de despliegue y validación. Un estado posterior Connected o un estado verde de la appliance solo confirma el estado de la integración; no demuestra que la cobertura de replicación sea completa ni que la detección de extremo a extremo funcione.

Límites de la planificación documentada

Las fuentes no proporcionan ninguna fórmula que permita calcular un tamaño de CPU y RAM individual y arbitrario por encima de los niveles de máquina virtual indicados a partir del número de usuarios, el ancho de banda o los eventos. Por encima de los límites de la clase Alta, la decisión documentada es, por tanto, varias appliances virtuales, no una única máquina virtual de mayor tamaño basada en especulaciones.

Del mismo modo, las tablas de hardware no sustituyen la especificación de certificación vigente. Indican valores de preselección o valores fechados de hojas de datos, pero no suponen la aprobación de servidores con nombres similares, componentes distintos o sistemas x86 propios. Si falta el modelo exacto de hardware y la configuración aprobada, o si no se dispone de valores fiables de tráfico y conexiones, la plataforma aún no se aprueba para su despliegue. Lo mismo se aplica a un host de máquinas virtuales autogestionado si faltan en la máquina virtual los flags de CPU necesarios.