Diagnosticar Sophos NDR Integration Appliance y el sensor

Este runbook permite acotar las incidencias de NDR Integration Appliance y del sensor NDR. Comienza por el estado exacto en Sophos Fusion, ayuda a interpretar los estados y valores visibles e indica cuándo recopilar registros para Sophos Support.

Un estado Connected o de color verde solo es una comprobación intermedia. No demuestra una cobertura completa del tráfico replicado, la carga correcta de todos los conjuntos de datos ni una detección integral operativa.

Procedimiento rápido

1. Anote el nombre del appliance, el System ID, la hora de inicio del error con su zona horaria y el texto exacto del mensaje.
2. Compruebe en Sophos Fusion el color y el estado del appliance, pero no reinicie nada todavía.
3. Consulte Status, NDR, Integrations y Advanced en Appliance Manager y obtenga capturas de pantalla con marca de tiempo.
4. Asigne el síntoma a una categoría: plataforma/CPU, salida/carga, SPAN, registro o recursos compartidos.
5. Aplique una sola corrección reversible dentro de esa categoría.
6. Vuelva a comprobar los mismos indicadores con una carga comparable.
7. Si las señales se contradicen, algún contenedor no está listo o la medida no surte efecto, recopile los registros y escale el caso.

Síntoma, comprobación y paso siguiente

Interpretar correctamente los estados rojo, amarillo y verde

Rojo: la integración no funciona

Cuando el estado es rojo, el mensaje concreto es más importante que el color:

• NDR containers not ready, <specific container names>. indica que al menos una aplicación necesaria no está lista. Si se menciona dragonfly o su estado visible resulta anómalo, comience por la compatibilidad de la CPU y los requisitos de la plataforma.
• Upload to s3 failed. Request was received but an error code was returned. Error code: <S3 upload error> indica que el appliance intentó cargar mediante una URL prefirmada en un bucket de S3 y recibió un código de error. Se trata principalmente de una incidencia de salida o proxy.
• spanX: unhealthy span sitúa la incidencia en la entrada del puerto SPAN indicado. Compruebe primero el componente de red de origen o la ruta de replicación virtual.

Amarillo: la integración funciona con errores

spanX: packets being dropped aparece cuando se descarta más del 10 % de los paquetes de red. La captura y el procesamiento de paquetes consumen mucha CPU. Una VM puede necesitar vCPU adicionales; en hardware certificado, la carga se puede distribuir entre otro appliance de acuerdo con el plan de cobertura aprobado. Los Log Collectors que se ejecutan en el mismo appliance también pueden consumir esos recursos.

Sin embargo, un cambio de capacidad por sí solo no corrige orígenes de replicación solapados, una ruta de destino sobresaturada ni una configuración SPAN errónea. Compare el perfil de tráfico y la topología antes de ampliar recursos.

Verde: no se notifican errores de integración en este momento

El color verde indica que NDR recibe tráfico SPAN y procesa datos de paquetes sin notificar problemas. El clasificador de estado actual exige al menos un 2 % de paquetes unicast para considerar correcto un puerto SPAN. Esto no demuestra que se capturen todas las VLAN, ubicaciones, direcciones o franjas horarias deseadas. No se utiliza la afirmación anterior de que el puerto debía mostrar un 100 % de tráfico unicast.

Consulte «Supervisar el estado y la capacidad de Sophos NDR» para interpretar en detalle las señales de estado y capacidad.

Si siguen faltando las detecciones previstas pese al estado verde, ejecute primero la detección de prueba segura de NDR. Si tampoco obtiene esa confirmación y sospecha de un problema de VLAN, guarde para Sophos Support la franja horaria, el puerto SPAN, la VLAN seleccionada y el estado visible del appliance. Solo debe cambiar VLAN Strip cuando el análisis confirme que el sensor recibe tanto la VLAN seleccionada como VLAN0; de lo contrario, no modifique el ajuste.

Acotar eventos locales con NDR Query

Cuando sea necesario comprobar por separado la captura y la carga, NDR Query de Appliance Manager puede mostrar el nivel de eventos local. La consulta se ejecuta en la base de datos de eventos NDR de esta máquina virtual, no en Sophos Data Lake. Debe distinguirse claramente de Investigation Console, que se despliega por separado y proporciona datos de un NDR Appliance asignado para buscar amenazas en la red local.

1. Anote el appliance afectado y la franja horaria del error.
2. Abra NDR Query y seleccione Example queries en Query.
3. Copie una consulta predefinida adecuada con Copy, péguela en el cuadro de texto y ejecútela con Go.
4. Guarde el resultado de Query Results con una marca de tiempo; reordene las columnas mediante arrastrar y soltar si es necesario.
5. Compare el resultado con la actividad de NDR y el estado de Fusion durante la misma franja horaria.

Actualmente, Appliance Manager solo admite consultas predefinidas en esta sección. No utilice una consulta SQL propia ni una consulta de Investigation Console. Si hay resultados locales pero faltan datos en Fusion, continúe comprobando la carga y la salida. Si el resultado local está vacío, compruebe primero la entrada SPAN, la franja horaria y la consulta predefinida seleccionada; el resultado vacío por sí solo no demuestra que haya una incidencia.

Interpretar detecciones inesperadas de Nmap

Si empiezan a aparecer análisis de sistema operativo basados en Nmap en otros productos de seguridad, compruebe el estado de OS Detection en Global NDR Settings. Cuando se activa esta opción, que está desactivada de forma predeterminada, se analizan cada dos horas todas las direcciones IP internas que NDR haya visto. Esto puede generar detecciones en otros productos de seguridad.

Compare la hora de activación, el appliance afectado, las direcciones IP de destino y las marcas de tiempo de las detecciones. Si la activación no está autorizada, los destinos no están permitidos o se producen efectos operativos, vuelva a desactivar OS Detection y documente la hora. A continuación, supervise que no se añadan nuevos eventos de análisis provocados por esta función; trate las alertas existentes conforme al proceso de la herramienta correspondiente. No repita manualmente comandos de Nmap ni cree excepciones en otros productos de seguridad solo para ocultar el síntoma. Si la función debe permanecer activada, se requiere la aprobación documentada de los responsables de red y seguridad, así como una validación durante al menos un intervalo completo de dos horas.

Acotar síntomas de contenedores y Dragonfly sin usar la CLI

Dragonfly procesa los datos de NDR. Hay dos patrones visibles relevantes para el diagnóstico:

• Puede aparecer un mensaje rojo sobre contenedores no disponibles si dragonfly entra en un bucle de reinicio porque faltan instrucciones de CPU necesarias.
• Si el appliance figura como Connected en Fusion, pero los datos no llegan a Data Lake y Dragonfly aparece como Pending en Advanced, compruebe el modo EVC si utiliza un clúster VMware EVC. Sophos exige Skylake generation or later; Sandy Bridge no es compatible.

Las VM de NDR en VMware ESXi o Hyper-V deben disponer de los indicadores de CPU pdpe1gb y avx2. pdpe1gb es necesario para la captura de paquetes y avx2 para las funciones de aprendizaje automático. Añadir vCPU no compensa la ausencia de esos indicadores. En Hyper-V, Processor Compatibility Mode no es compatible. En ESXi también se requiere VM Hardware Version 11 o posterior, además de los requisitos de plataforma documentados.

Comprobación segura:

1. En Advanced, documente el estado y el nombre visible del contenedor afectado.
2. En Status, anote CPU Usage, Memory, Root Disk y Data Disk.
3. Compare el hipervisor, el modelo de CPU, el ajuste EVC o de compatibilidad y los indicadores disponibles para la VM con la documentación de plataforma aprobada.
4. Corrija un ajuste incorrecto de hipervisor o CPU únicamente durante una ventana de mantenimiento planificada; antes, documente el valor inicial y el procedimiento de reversión.
5. Después, valide la VM y el estado del appliance mediante las interfaces operativas normales.
6. Si dragonfly continúa en Pending, un contenedor sigue sin estar listo o se observa un bucle de reinicio, genere el paquete de registros y escale el caso.

Los valores de plataforma y requisitos de CPU compatibles se resumen en «Elegir la plataforma y dimensionar correctamente el sensor de Sophos NDR».

Comprobar la carga en S3 y la conexión saliente

Un error de carga en S3 no implica que el tráfico SPAN no llegue. La captura y la carga son dos etapas independientes. En NDR de Appliance Manager, registre por tanto la actividad de captura o de flujos y el valor Uploaded durante la misma franja horaria.

Compruebe la ruta de salida en este orden:

1. ¿Coincide la configuración de la IP de MGMT, por DHCP o manual, con la red de gestión?
2. ¿Funcionan la resolución DNS y NTP a través de los servicios previstos?
3. ¿Utiliza la ruta predeterminada la salida a Internet o la ruta de salida central prevista?
4. ¿Permiten la Network ACL, el Security Group o el firewall local el tráfico HTTPS saliente?
5. ¿Permite Web Proxy el appliance y los destinos necesarios sin modificar ni bloquear la solicitud S3 prefirmada?
6. ¿Coinciden las reglas con las excepciones de puertos y dominios actuales de Sophos?

No copie de casos antiguos la lista de dominios regionales sin comodines. Compárela, en el momento de la comprobación, con los Appliance requirements actuales. Habilitar temporalmente un acceso general a Internet no constituye una prueba segura. Aplique los cambios de uno en uno y valide después de cada paso utilizando la misma franja horaria del error.

Reversión: tras la prueba, restablezca al valor inicial cualquier regla de proxy, ACL o firewall modificada para la comprobación, salvo que sea necesaria de forma permanente. Al revertirla, deben seguir funcionando las rutas de gestión y carga de las demás integraciones.

SPAN incorrecto, pérdida de paquetes o ausencia de flujos

spanX: unhealthy span

Compruebe lo siguiente para el puerto indicado:

• origen y dirección previstos de la replicación;
• interfaz de destino dedicada y cableado físico;
• asignación de la NIC de captura, el grupo de puertos o vSwitch;
• en ERSPAN, dirección de destino, enrutamiento, MTU y valores GRE o VXLAN;
• últimos cambios de VLAN, trunk, grupo de puertos, ubicación del host o sesión de replicación;
• si el propio destino se ha configurado por error de nuevo como origen.

Genere tráfico unicast conocido y no dañino desde un host piloto, y observe durante la misma franja el puerto SPAN previsto y la evolución de los flujos. Si no hay actividad, mantenga el diagnóstico en el origen, la dirección, el filtro, el transporte o la asignación de captura. Evalúe el procesamiento y la carga solo después de confirmar la entrada.

spanX: packets being dropped

Si la pérdida supera el 10 %, recopile además:

• vCPU asignadas y CPU por núcleo;
• ancho de banda, paquetes/s y flujos/s;
• orígenes de replicación añadidos recientemente o solapados;
• tendencia de Memory, Root Disk y Data Disk;
• todos los Log Collectors del mismo appliance con Received, Filtered, Accepted y Uploaded.

Para un appliance compartido, el dimensionamiento parte de NDR y después incorpora la carga de los collectors. Como señales límite adicionales, el appliance admite como máximo 8'000 eventos de collector por segundo y, con 16 GB de RAM, un máximo de 2 GB para Log Collectors. Incluso los núcleos de CPU asignados a NDR pueden ser utilizados por otras integraciones y afectar a la capacidad de NDR. Si debe distribuir la carga de collectors, determine primero el responsable y el appliance de destino y utilice la guía de integraciones; este runbook no modifica orígenes syslog específicos del proveedor.

Con 4 vCPU, DPDK suele mantener un núcleo al 100 %; con 8 vCPU, dos núcleos permanecen al 100 %. Por sí solo, esto es normal. Una incidencia de capacidad se demuestra por su combinación con pérdidas, otros núcleos saturados, una reducción de la carga o un cambio en la evolución de los flujos.

La cadena de replicación, la validación piloto y un procedimiento de reversión limitado se describen en «Planificar y validar la replicación de tráfico para Sophos NDR».

Diagnosticar el registro y el estado Connected

Al principio, un appliance nuevo aparece como Waiting for deployment. Tras completar el proceso de arranque y establecer la ruta de gestión, el estado del appliance cambia a Connected en Threat Analysis Center > Integrations > Configured > Integration Appliances.

Si el estado no cambia:

1. identifique el appliance correcto por el nombre, la plataforma y la imagen o el archivo seed generado;
2. compruebe si el arranque de la VM entra en un bucle persistente de error o reinicio;
3. revise la IP de MGMT, la VLAN, los valores de DHCP o manuales, el gateway y DNS;
4. compare NTP y la salida necesaria con los requisitos actuales del appliance;
5. en ESXi, utilice la OVA generada en Fusion para un único intento de despliegue. En otras plataformas, consulte el procedimiento de despliegue vigente;
6. documente la hora, el estado visible y la última salida de arranque sin incluir secretos.

No elimine ni reinstale el appliance. Este runbook no incluye deliberadamente ningún procedimiento de desmontaje o sustitución. Connected confirma la conexión y asignación centrales, pero no la cobertura SPAN, la carga ni la detección.

Si el appliance ya tenía el estado Connected y lo pierde, compruebe primero la ruta de gestión, la salida y la disponibilidad del appliance. Los ajustes de replicación no son el primer punto de análisis porque SPAN y la gestión utilizan rutas independientes.

Comprobar el acceso a Appliance Manager, no el sensor

Si Open Appliance Manager se abre, pero falla el inicio de sesión con zadmin, se trata inicialmente de un problema de acceso, no de una prueba sobre SPAN, la carga o Dragonfly. Si ha olvidado la contraseña, use el enlace reset it del cuadro de confirmación de Open Appliance Manager y establezca una nueva. Guarde la nueva contraseña directamente en el sistema de contraseñas; no incluya la contraseña anterior ni la nueva en capturas de pantalla, registros de operaciones o el Support Case.

Si la cuenta se ha bloqueado por demasiados intentos con contraseñas incorrectas, la vía alternativa documentada es la consola web del hipervisor que aloja el appliance: en ella, seleccione Unlock Account en Weblink interface. Esta alternativa presupone que ya se dispone de acceso autorizado a la consola web del hipervisor; este runbook no añade comandos de shell, SSH o consola ni deduce de esta opción otra vía de acceso. Después, pruebe una sola vez el inicio de sesión con la contraseña almacenada de forma segura. Si la cuenta sigue bloqueada, no pruebe más contraseñas: documente la hora y el mensaje visible y contacte con Sophos Support.

Configuración de administración sin conexión como último paso de recuperación local

Actions > Settings > Management en Appliance Manager solo se debe modificar localmente si la VM no tiene conectividad de red. Si existe conectividad, el cambio se debe realizar en Sophos Fusion. El hecho de que la VM esté sin conexión no crea por sí solo una nueva vía de acceso: la corrección local presupone un procedimiento de recuperación existente y autorizado. Si no se dispone de este acceso, registre la IP de MGMT actual, el último estado conocido en Fusion y los datos de la plataforma, y escale el caso.

Antes de seleccionar Save, compare los valores anteriores y nuevos de IP Assignment, IPv4/Netmask, Gateway IP, DNS, DNS 2 y, si corresponde, Enable Web Proxy, Web Proxy Type, Proxy URL y Port Number. Las credenciales del proxy deben permanecer en el sistema de contraseñas. Modifique únicamente el valor que se haya demostrado que es incorrecto. Si la interfaz solicita confirmar un reinicio, se trata de un reinicio del appliance: se interrumpen NDR y todos los Log Collectors. Por ello, documente primero las cargas de trabajo compartidas, la ventana de mantenimiento, la nueva dirección IP prevista y la vía de reversión.

Una vez aplicado el cambio, compruebe la accesibilidad en la nueva dirección IP, el estado de Fusion, la captura y carga de NDR y todos los Log Collectors. Si sigue disponible el acceso de recuperación autorizado y la validación falla, revierta exactamente el último cambio a los valores iniciales registrados. Si ya no se puede acceder a la interfaz, no pruebe direcciones ni valores de proxy al azar; escale el caso con la línea base, la hora y el impacto. El procedimiento completo de comprobación previa y posterior se encuentra en «Operar de forma segura el appliance y el sensor Sophos NDR».

Appliance compartido: proteger las demás integraciones

Antes de reiniciar o cambiar recursos en Fusion, abra la flecha junto al nombre del appliance y anote todas las integraciones que se ejecutan en él. Integrations en Appliance Manager muestra su estado, el último reinicio y los contadores syslog.

• Puede reiniciar un único Log Collector por separado mediante Restart; NDR y las demás integraciones permanecen activas.
• Restart All afecta a todos los Log Collectors, pero no a NDR.
• Restart NDR afecta al sensor NDR, pero no a los Log Collectors.
• Actions > Restart afecta a toda la VM e interrumpe NDR y todos los Log Collectors.
• Actions > Shutdown detiene toda la VM y todas las integraciones; es necesario disponer de un método de encendido comprobado por separado.

Reiniciar toda la VM no es el primer paso de diagnóstico. Recopile antes los valores de estado y las métricas, e identifique el componente afectado de menor alcance. «Operar de forma segura el appliance y el sensor Sophos NDR» describe el impacto y la secuencia operativa segura.

Recopilar datos de diagnóstico y registros

Paquete básico

Antes de realizar cambios, recopile:

• nombre del appliance, System ID, Version, K3S Helm Chart version y Uptime;
• estado en Fusion y texto exacto del error;
• hora de inicio y de reproducción, con zona horaria;
• en Status, CPU por núcleo, Memory, Root Disk y Data Disk;
• en NDR, Capture de cada puerto SPAN configurado, Uploaded y evolución de los flujos;
• en Integrations, todos los Log Collectors del mismo appliance con su estado y contadores;
• en Advanced, estado visible de los contenedores y hora del último reinicio visible;
• plataforma, recursos de la VM, perfil de tráfico y últimos cambios;
• resultado previsto, resultado real e impacto para la empresa.

Si no puede acceder a Appliance Manager

1. Abra Threat Analysis Center > Integrations > Configured > Integration Appliances en Fusion.
2. Seleccione Collect logs en el menú de tres puntos del appliance afectado.
3. Abra la información de la columna Log requested y anote el nombre de archivo mostrado.
4. Facilite a Sophos Support ese nombre junto con el appliance, la franja horaria y el texto del error.

Si Appliance Manager está disponible

1. En el menú de tres puntos, seleccione Open Appliance Manager y después Open.
2. En Appliance Manager, seleccione Actions > Download Log File.
3. Envíe el archivo de registros al caso existente únicamente mediante el canal de soporte acordado.

Los archivos de registros pueden contener direcciones IP, nombres de host y otros datos operativos confidenciales. La contraseña de zadmin, los tokens, las claves privadas, las credenciales del proxy y otros secretos nunca deben incluirse en el ticket, las capturas de pantalla ni los archivos adjuntos.

Habilitar Remote Assistance de forma controlada

Active Remote Assistance únicamente para un caso de soporte concreto. El appliance debe estar en línea.

1. Abra Threat Analysis Center > Integrations > Configured > Integration Appliances en Fusion.
2. Seleccione Remote Assistance en el menú de tres puntos.
3. Active Enable en el cuadro de diálogo.
4. Marque la confirmación de Sophos Group Privacy Notice y seleccione Save.
5. Espere hasta que aparezca un Access ID.
6. Envíe exclusivamente ese Access ID a Sophos Support a través del canal acordado.

El acceso finaliza automáticamente después de un máximo de siete días. Si el análisis termina antes, desactive Enable en el mismo cuadro de diálogo y documente el cierre. Remote Assistance no sustituye al Support Case ni al paquete de diagnóstico.

Validar y revertir la corrección de forma segura

Modifique una sola hipótesis en cada intento. Documente antes el valor inicial, la persona responsable, la ventana de mantenimiento y el procedimiento de reversión. Después, compruebe con una carga comparable que:

• el mensaje rojo o amarillo anterior no vuelve a aparecer;
• el estado previsto del appliance y la ruta de gestión permanecen estables;
• cada puerto SPAN previsto muestra una actividad acorde con el tráfico piloto;
• la evolución de los flujos y la carga permanecen estables durante una franja representativa;
• no vuelve a aparecer el mensaje de pérdida superior al 10 %;
• la CPU, aparte de los núcleos DPDK previstos, Memory y el almacenamiento conservan margen suficiente;
• todos los Log Collectors del appliance compartido siguen procesando datos;
• cualquier cambio de plataforma proporciona los indicadores de CPU necesarios y un modo compatible.

Si la comprobación falla o aparecen efectos nuevos, revierta exactamente el último cambio. Si no puede restablecer el estado inicial, no realice más cambios: recopile los datos de diagnóstico y abra un caso con Sophos Support.

Incluso después de la corrección técnica, una integración verde no constituye una prueba de detección. Cuando la cadena de replicación y carga sea estable, utilice «Generar y comprobar una detección de prueba segura de Sophos NDR».

Escalar el caso a Sophos Support

Abra un caso con Sophos Support si:

• persiste NDR containers not ready o dragonfly permanece visiblemente en Pending o en un bucle de reinicio;
• los indicadores de CPU necesarios no están disponibles pese a utilizar la plataforma correcta;
• continúa el error de carga en S3 después de confirmar DNS, proxy, firewall y la ruta de salida;
• persiste spanX: unhealthy span después de verificar el origen, la dirección y la asignación del destino;
• la pérdida de paquetes reaparece tras ajustar adecuadamente la capacidad o distribuir la carga;
• Connected, la carga local y la recepción en Data Lake muestran resultados contradictorios;
• el proceso de arranque no completa el registro o el appliance cambia de estado inesperadamente;
• una corrección segura exigiría intervenciones de bajo nivel en contenedores, Kubernetes o Dragonfly.

Incluya en el caso el paquete básico, el nombre o el archivo de registros, los pasos exactos y los resultados medibles. Indique claramente las hipótesis ya descartadas. Sophos Support atiende problemas del producto durante la instalación, la administración y el funcionamiento; el caso no constituye una solicitud para investigar una detección.

Una detección de XDR autogestionada sigue siendo responsabilidad del cliente. Solo Sophos MDR investiga y responde a un caso MDR gestionado por Sophos. Consulte «Abrir un ticket de Sophos Support con Support Assistant» para crear y escalar el caso.