Supervisar el estado y la capacidad de Sophos NDR

Un estado verde de Sophos NDR es una comprobación intermedia importante, pero no demuestra que la cobertura de la duplicación sea completa ni que la cadena de detección funcione. Para obtener una evaluación fiable, hay que analizar por separado seis grupos de señales: Sophos Fusion, Appliance Manager, entrada SPAN, carga de datos, recursos de procesamiento y almacenamiento y, si está presente, la Investigation Console independiente.

Comprobación rápida: revise primero el estado de NDR en Sophos Fusion. A continuación, en NDR dentro de Appliance Manager, compruebe los valores de cada puerto SPAN previsto, Uploaded y el historial de flujos. En Status, compruebe CPU, Memory, Root Disk y Data Disk. El aviso amarillo spanX: packets being dropped significa que se descarta más del 10 % de los paquetes de red procesados por NDR. Un puerto SPAN verde cumple actualmente el criterio de clasificación del producto de que al menos el 2 % de los paquetes sean unicast. Ninguna de estas afirmaciones demuestra por sí sola que se estén duplicando todas las redes previstas ni que una detección llegue al final de la cadena.

Asociar cada indicador con su finalidad

Abra Appliance Manager en Sophos Fusion desde Threat Analysis Center > Integrations > Configured > Integration Appliances. En la fila del dispositivo, seleccione los tres puntos y, después, Open Appliance Manager. El encabezado muestra, entre otros datos, Version, K3S Helm Chart version, Uptime y System ID. Incluya estos datos en cada registro de incidencia, ya que dos dispositivos con síntomas aparentemente similares pueden ejecutar versiones de software distintas o tener tiempos de actividad diferentes.

Usar el estado de Fusion como punto de partida

Sophos Fusion distingue tres estados:

• Rojo: la integración de NDR no funciona. NDR containers not ready, <specific container names> indica que hay aplicaciones que no están listas. Upload to s3 failed ... está relacionado con la carga a la nube. spanX: unhealthy span está relacionado con la entrada de tráfico procedente del dispositivo de red que realiza la duplicación.
• Amarillo: la integración funciona, pero con errores. spanX: packets being dropped aparece cuando se descarta más del 10 % de los paquetes de red.
• Verde: la integración recibe tráfico SPAN y procesa los datos de los paquetes sin que se haya notificado ningún error. En la actualidad, un puerto SPAN se clasifica como correcto si al menos el 2 % de los paquetes observados son paquetes unicast.

Los dos porcentajes tienen denominadores diferentes y no deben compensarse entre sí. El umbral del 2 % clasifica la composición del tráfico que llega al sensor. No significa que baste con el 2 % de todo el tráfico de la empresa ni que NDR pueda perder el 98 %. «Al menos el 2 %» incluye exactamente el 2 %. En cambio, el mensaje de descarte describe la proporción de paquetes que ya llegan a NDR y que el procesamiento no puede gestionar por falta de recursos. Sophos documenta la advertencia para más del 10 %, no para «el 10 % o más».

Importante: el umbral de más del 10 % es un estado del producto, no un objetivo ni un margen de pérdida aceptable. Incluso un valor inferior al umbral de notificación puede suponer un deterioro respecto a su propia línea base. Del mismo modo, un puerto verde puede recibir tráfico duplicado de forma incorrecta o incompleta siempre que la mezcla observada cumpla el criterio de clasificación de tráfico unicast.

Comprobar por separado la entrada SPAN y la carga de datos

En Appliance Manager, la pestaña NDR muestra un valor de captura para cada puerto SPAN configurado. SPAN Port 2 solo aparece si se ha configurado un segundo puerto. El gráfico global de Network Flows se muestra en intervalos de 30 segundos.

Estos indicadores responden a tres preguntas distintas:

1. ¿Llega tráfico a cada puerto SPAN previsto? Si falta un valor o cambia de forma repentina y considerable, investigue primero el switch de origen, la sesión de duplicación o SPAN, la asignación de la interfaz de red virtual y cualquier VLAN o grupo de puertos modificado recientemente.
2. ¿Es verosímil la mezcla de tráfico? El color verde solo confirma el criterio de clasificación actual del tráfico unicast. El historial de flujos también debe ser coherente con los horarios, las ubicaciones y los picos de tráfico esperados habituales.
3. ¿Puede NDR procesar los paquetes? El mensaje amarillo de descarte indica un cuello de botella de procesamiento. No equivale a un puerto de duplicación sobresuscrito ni a una pérdida de paquetes en la ruta de producción.

El porcentaje de carga de datos, que también se muestra en la pestaña NDR, representa una etapa posterior. Una entrada SPAN correcta con un porcentaje de carga de datos en descenso no indica la misma clase de fallo que un puerto SPAN vacío. Si aparece Upload to s3 failed. Request was received but an error code was returned, compruebe el acceso saliente a Internet del dispositivo y las reglas del firewall y del proxy web. NDR carga los datos en un bucket de S3 mediante una URL prefirmada. Si el error persiste después de corregir la configuración de red o del proxy, póngase en contacto con Sophos Support.

En las integraciones de recopiladores de registros de terceros, las tarjetas de Integrations contabilizan Received, Filtered, Accepted y Uploaded. Estos contadores de syslog no son el valor de carga de datos de NDR ni el valor de captura SPAN. Aun así, son importantes porque una integración de recopilación de registros con mucha carga que se ejecute en el mismo dispositivo consume CPU y Memory de ese dispositivo.

Evaluar CPU, Memory y el almacenamiento

En Status, Appliance Manager muestra el uso de CPU, Memory, Root Disk y Data Disk. Es normal que determinados núcleos de CPU se mantengan totalmente ocupados en NDR: Data Plane Development Kit (DPDK) funciona en núcleos reservados en modo de sondeo. Sondea continuamente la llegada de paquetes en lugar de esperar interrupciones durante los periodos de inactividad.

Sophos ofrece dos ejemplos concretos:

• En una máquina virtual con 4 núcleos de CPU, un núcleo se mantiene al 100 %.
• En una máquina virtual con 8 núcleos de CPU, dos núcleos se mantienen al 100 %.

Por tanto, este tipo de uso por núcleo no demuestra por sí solo que exista una sobrecarga y no tiene por qué desaparecer cuando hay poco tráfico. Por otro lado, no se debe utilizar «DPDK es normal» para explicar cualquier uso elevado de la CPU. Una combinación de tráfico creciente, otros núcleos totalmente ocupados, el mensaje packets being dropped, un porcentaje de carga de datos en descenso o un historial de flujos que se haya desviado de la línea base pasa a ser crítica.

Se aplican las siguientes directrices de capacidad a los dispositivos virtuales:

Las tres métricas deben evaluarse conjuntamente. Un entorno puede mantenerse por debajo del límite de ancho de banda y, aun así, generar muchos paquetes por segundo porque estos son muy pequeños. Si los valores superan el perfil High, Sophos recomienda implementar varios dispositivos virtuales en la red.

Estos valores se aplican a una máquina virtual que ejecuta únicamente NDR. Con una carga de trabajo elevada, cada integración adicional de recopilación de registros alojada en el dispositivo requiere aproximadamente 400 MB de RAM y puede consumir capacidad adicional de CPU. Por este motivo, compruebe también las tarjetas de Integrations antes de ampliar los recursos. Si la carga de trabajo mixta se mantiene en el tiempo, distribuirla entre varios dispositivos puede ser más adecuado que añadir recursos repetidamente a la misma máquina virtual.

La documentación del producto empleada en este artículo no especifica un umbral de advertencia general para Memory, Root Disk ni Data Disk. Por tanto, sería engañoso tratar un porcentaje arbitrario como un límite de Sophos. Los factores relevantes son la tendencia, el margen disponible y los síntomas simultáneos. Si el uso del disco aumenta de forma continua, no elimine manualmente archivos ni contenedores. Documente primero el estado y el periodo y, si la causa no está clara, conserve los registros para Sophos Support.

Establecer una línea base útil

Una instantánea no permite distinguir un patrón diario normal del inicio de una sobrecarga. Por ello, después de la implementación y de cada cambio relevante, registre puntos de datos comparables:

• fecha, hora y zona horaria, así como el periodo de carga previsto;
• color de Fusion y texto exacto del mensaje;
• valor de captura de cada puerto SPAN configurado;
• porcentaje de carga de datos y forma del historial de flujos;
• CPU por núcleo y uso global de CPU, Memory, Root Disk y Data Disk;
• vCPU y RAM asignadas a la máquina virtual;
• valores estimados de Mbit/s, paquetes/s y flujos/s, o valores medidos en el sistema de origen;
• integraciones de terceros que se ejecutan al mismo tiempo y su actividad;
• cambios en el switch, hipervisor, proxy, firewall o dispositivo.

Resulta útil tomar medidas durante un periodo tranquilo, con una carga de trabajo normal y durante un pico conocido. El objetivo no es obtener un valor de referencia universal, sino comparar el mismo dispositivo en condiciones similares. Así se puede detectar una caída repentina en un puerto SPAN aunque Fusion aún aparezca en verde. Después de un cambio de capacidad, establezca una línea base nueva solo cuando el estado sea estable.

Resolver los problemas en un orden seguro

1. Registrar el alcance: documente el dispositivo y el puerto SPAN afectados, la hora de inicio, el texto exacto de Fusion y el cambio más reciente. Conserve capturas de pantalla o mediciones antes de reiniciar.
2. Comprobar la entrada: ante unhealthy span, la ausencia de flujos o una desviación de la línea base del puerto, compruebe primero el origen de duplicación, el puerto de destino o la interfaz de red virtual y las redes previstas. Añadir CPU no corrige un origen SPAN configurado incorrectamente.
3. Comprobar la carga de datos: ante un error de carga en S3, compruebe el acceso saliente a Internet, el firewall y el proxy web. A la inversa, una carga de datos correcta no resuelve una cobertura de duplicación incompleta.
4. Comprobar la capacidad: cuando los descartes superen el 10 %, compare el perfil de tráfico, los demás núcleos totalmente ocupados, la asignación de vCPU y las integraciones que se ejecutan en el mismo dispositivo. En una máquina virtual, asigne vCPU adicionales; el perfil High documentado especifica 8 vCPU. En hardware certificado, puede implementar otro dispositivo y dividir el tráfico SPAN entre ambos. Antes de dividir el tráfico es obligatorio disponer de un plan de cobertura aprobado: debe asignar claramente cada red, VLAN y origen de duplicación previstos al dispositivo de destino, y evitar tanto las lagunas como la duplicación involuntaria de las entradas. En cargas de trabajo mixtas, NDR y los recopiladores de registros se pueden distribuir entre dispositivos independientes.
5. Delimitar el alcance de un reinicio: si NDR sigue sin funcionar correctamente después de resolver la causa, puede plantearse un reinicio específico de NDR conforme a las instrucciones operativas o de solución de problemas aplicables. Durante el reinicio no se realiza el procesamiento normal de NDR; reiniciar no sustituye una corrección de capacidad. Reiniciar o apagar toda la máquina virtual tiene un ámbito de impacto mayor y no debe ser el primer paso de la solución de problemas.

Si se modifican las vCPU o la distribución del tráfico, efectúe los cambios durante una ventana de mantenimiento aprobada y conforme a los requisitos de la plataforma de virtualización utilizada. Realice un cambio cada vez para poder medir su efecto. Después de dividir el tráfico, contraste el plan de cobertura con cada puerto SPAN resultante y valide también la ruta de prueba integral aprobada.

No confundir la Investigation Console con el dispositivo NDR

La Investigation Console es un componente independiente. Su estado no demuestra ni el estado de la integración de NDR, ni la cobertura completa de los orígenes SPAN, ni que los datos se entreguen correctamente. Por tanto, este artículo se limita a aclarar esta separación: SPAN, la carga de datos de NDR, DPDK y los descartes de paquetes se comprueban en la integración de NDR y en Appliance Manager; la comprobación y la solución de problemas de Investigation Console corresponden a la documentación operativa específica de la consola.

Validar después de cada medida

Repita las comprobaciones con una carga comparable a la de la medición inicial. Una corrección solo se considera eficaz cuando:

• Fusion muestra el estado esperado sin el mensaje rojo o amarillo anterior;
• todos los puertos SPAN previstos están visibles y vuelven a ajustarse a su propio historial de referencia;
• el criterio de clasificación de tráfico unicast no se ha utilizado erróneamente como prueba de cobertura;
• el mensaje de pérdida de más del 10 % de los paquetes no vuelve a aparecer;
• la carga de datos y Network Flows se mantienen estables durante un periodo de observación significativo;
• la CPU, al margen de los núcleos DPDK previstos, así como Memory, Root Disk y Data Disk, muestran margen suficiente;
• las integraciones de terceros que se ejecutan en el mismo dispositivo siguen procesando los datos previstos;
• después de dividir el tráfico, cada red, VLAN y origen de duplicación previstos alimenta exactamente al dispositivo correspondiente de acuerdo con el plan de cobertura aprobado, y la ruta de prueba integral aprobada funciona.

Estas comprobaciones validan el estado operativo, pero aún no una cadena de detección completa. La demostración integral requiere además una prueba aprobada de NDR y la verificación de la detección resultante.

Cuándo recurrir a Sophos Support

Recurra a Sophos Support si los contenedores no pasan a estar listos, si persiste un error de carga en S3 pese a haber confirmado el acceso a Internet y la ruta a través del proxy, si un puerto SPAN sigue en estado unhealthy pese a haber corregido la configuración de origen, si se repiten los descartes de paquetes después de un aumento adecuado de la capacidad o si los indicadores de recursos y los mensajes de estado se contradicen.

Prepare al menos los siguientes datos para la escalación:

• nombre del dispositivo, System ID, Version, K3S Helm Chart version y Uptime;
• texto exacto del estado y del error, incluida la hora de inicio y la zona horaria;
• puerto SPAN afectado, valores de captura y carga de datos e historial de flujos;
• CPU por núcleo, Memory, Root Disk y Data Disk antes y después de la medida;
• asignación de la máquina virtual, perfil de tráfico observado e integraciones que se ejecutan en el mismo dispositivo;
• cambios recientes en el switch, hipervisor, firewall o proxy;
• medidas adoptadas y sus resultados cuantificables;
• para problemas de una Investigation Console independiente, las pruebas exigidas en la documentación operativa aplicable.

No incluya contraseñas, claves privadas ni otras credenciales en el ticket. No ejecute comandos de Kubernetes de bajo nivel ni modifique manualmente los contenedores basándose en una sospecha; ante NDR containers not ready, recopile las observaciones disponibles y coordínese con Sophos Support.