Planificar y validar la duplicación de tráfico para Sophos NDR

La duplicación de tráfico proporciona a Sophos NDR una copia del tráfico de red. En redes locales o virtualizadas suele realizarse mediante SPAN; las fuentes remotas se encapsulan mediante ERSPAN sobre GRE o VXLAN; y, en AWS, se utiliza VPC > Traffic mirror sessions. El objetivo no es duplicar sin más tantos puertos como sea posible. NDR necesita las relaciones de tráfico adecuadas, sin bucles, duplicados innecesarios ni una ruta de destino sobrecargada.

El procedimiento seguro es el siguiente:

definir las relaciones de tráfico y los límites que deben supervisarse;
seleccionar exactamente un punto de observación adecuado para cada relación;
comprobar la capacidad desde la fuente hasta el sensor NDR;
comenzar por duplicar una pequeña fuente piloto;
validar por etapas la cadena desde la fuente hasta el procesamiento;
ampliar las fuentes únicamente de forma controlada y volver a medir después de cada cambio.

Antes de la activación, deben aprobarse y documentarse la fuente, la dirección, el filtro, el destino, la ventana de mantenimiento, el alcance de datos permitido y la responsabilidad de la reversión. Los datos duplicados pueden contener cargas útiles y otra información confidencial. Por tanto, no deben duplicarse de forma generalizada, por precaución o «por si acaso», segmentos no previstos de usuarios, administración, identidad u otros segmentos sensibles. La fuente piloto se limita al alcance operativo y de privacidad aprobado.

Seleccionar las fuentes y los puntos de observación

Antes de configurar, resulta útil preparar una breve matriz de cobertura. En lugar de limitarse a enumerar todos los puertos de los switches, debe recoger las rutas de comunicación relevantes, por ejemplo:

de los clientes a Internet y a servicios externos;
de los clientes a los servidores internos;
entre servidores, especialmente cuando el tráfico atraviesa límites de segmentos o zonas de seguridad;
del centro de datos a sucursales o redes en la nube;
tráfico este-oeste entre máquinas virtuales que no atraviesa ningún enlace ascendente físico.

Para cada ruta, seleccione un punto en el que sean visibles ambas direcciones. Por lo general, será un troncal, una VLAN o un puerto próximo al límite de un segmento. Un enlace ascendente a Internet ofrece buena visibilidad del tráfico norte-sur, pero no muestra el tráfico local dentro de la misma VLAN. A su vez, un switch físico no ve el tráfico que permanece dentro del mismo vSwitch. Estas carencias no pueden deducirse de un estado verde del sensor: deben identificarse a partir de la topología y la matriz de pruebas.

Fuente y dirección

Según la plataforma, una fuente SPAN puede ser un puerto, un grupo de puertos o una VLAN. Siempre que sea posible, duplique both, es decir, el tráfico entrante y saliente. Si solo se duplica una dirección, pueden quedar ocultas las respuestas, los errores y algunas partes de una sesión.

Un troncal o una VLAN completa simplifica la cobertura, pero aumenta el volumen de datos y la probabilidad de duplicados. Los puertos de acceso individuales son más específicos, aunque resulta más fácil olvidarlos cuando los sistemas cambian de ubicación o las cargas de trabajo son dinámicas. Por tanto, la elección debe basarse en la relación de tráfico, no en el número de fuentes disponibles.

Destino

El destino de la duplicación debe ser exclusivamente la ruta de captura del sensor NDR:

en una máquina virtual, el grupo de puertos o vSwitch al que esté conectado SPAN1 o SPAN2;
en una conexión física, el puerto dedicado del switch conectado a la interfaz SPAN;
en ERSPAN, la dirección de destino GRE o VXLAN configurada en el sensor;
en AWS, el NDR SPAN Target creado por la pila de CloudFormation.

La interfaz de administración no debe formar parte de esta cadena como destino SPAN. El puerto de destino tampoco debe utilizarse como una fuente normal ni enviar tráfico de producción de vuelta a la red.

Evitar bucles y paquetes duplicados

Port Mirroring copia paquetes; no debe devolverlos a la ruta de reenvío de producción. Puede producirse un bucle, por ejemplo, si el destino SPAN vuelve a duplicarse o se utiliza como enlace ascendente normal. Los datos duplicados son más frecuentes: el mismo paquete puede capturarse en el puerto de acceso y en el enlace ascendente, a ambos lados del límite de un segmento o de forma simultánea mediante SPAN local y ERSPAN.

Antes de la activación, compruebe lo siguiente:

La interfaz de destino solo actúa como destino y nunca como fuente de la misma sesión ni de otra que se solape con ella.
Siempre que sea posible, una ruta de tráfico de extremo a extremo se duplica exactamente en un límite relevante.
Dos puertos SPAN no reciben fuentes solapadas, salvo que el solapamiento esté documentado y se haya previsto para una prueba de duración limitada.
El tráfico de difusión y multidifusión no se recopila en varios puntos del mismo dominio de capa 2.
En un clúster o con vMotion, se sabe qué host y enlace ascendente reciben la duplicación física. Una máquina virtual NDR que utilice SPAN estándar desde un switch físico debe permanecer en el host ESXi que recibe ese tráfico.
En AWS, solo existe la sesión necesaria para cada ENI y alcance de tráfico previsto. También se comprueban el orden de las sesiones y los filtros.

Los duplicados consumen capacidad de captura, túnel y CPU sin mejorar la cobertura operativa. Resulta sospechoso que las tasas de paquetes o bytes casi se dupliquen tras añadir una fuente cuando el tráfico de producción no ha cambiado. Si ocurre, desactive la última fuente añadida y compruebe si existen solapamientos en la topología.

Configurar SPAN localmente o en el hipervisor

La sintaxis exacta varía según el switch y el hipervisor. Con independencia de la plataforma, el modelo es el mismo: seleccionar la fuente y la dirección, definir un destino dedicado y asegurarse de que el grupo de puertos de captura virtual permita la recepción en modo promiscuo.

En una sesión de Sophos Switch, una pequeña configuración piloto podría, por ejemplo, duplicar los puertos del 1 al 4 en ambas direcciones hacia el puerto 8:

configure terminal
monitor session 1 destination interface gigabitethernet 0/8 allow-ingress
monitor session 1 source interface gigabitethernet 0/1 both
monitor session 1 source interface gigabitethernet 0/2 both
monitor session 1 source interface gigabitethernet 0/3 both
monitor session 1 source interface gigabitethernet 0/4 both
save
end
show monitor session 1

Los números de interfaz son ejemplos y deben adaptarse al cableado real. Antes de guardar, verifique que 0/8 conduzca únicamente a la ruta de captura de NDR. Para otros fabricantes, utilice sus comandos SPAN documentados; que los nombres sean similares no implica que su semántica sea idéntica.

En un ESXi Standard vSwitch, configure el grupo de puertos de captura con VLAN ID 4095 y, en Security, establezca Promiscuous mode en Accept. El tráfico duplicado físicamente requiere además un enlace ascendente dedicado desde el switch hasta el vSwitch correspondiente. El tráfico interno de las máquinas virtuales puede requerir una fuente de duplicación virtual independiente. En Hyper-V, la interfaz de captura de NDR debe estar conectada al vSwitch correcto como destino de la duplicación de puertos; compruebe la configuración de la plataforma por separado del ajuste del sensor NDR.

Sophos NDR activa SPAN Port 1 de forma predeterminada; SPAN Port 2 está desactivado de forma predeterminada. Un segundo puerto SPAN solo es útil si recibe una fuente independiente sin solapamientos innecesarios. La máquina virtual necesita al menos 8 vCPU para SPAN Port 2.

Utilizar ERSPAN con GRE o VXLAN

ERSPAN transporta las copias de fuentes remotas al sensor a través de una red IP. Esto convierte la ruta de transporte en parte del análisis de capacidad y de fallos: la MTU, el enrutamiento, las ACL y una posible fragmentación pueden afectar a la captura aunque la sesión de origen sea correcta.

Configure la interfaz de captura correspondiente en Settings de Sophos Appliance Manager:

VXLAN

Active Enable ERSPAN junto al puerto SPAN previsto.
En Tunnel Protocol, seleccione vxlan.
En IP Address, introduzca la dirección de la interfaz VTEP.
Configure VXLAN ID y VXLAN Port exactamente igual que en la fuente que realiza la encapsulación.
Seleccione Save.

GRE

Active Enable ERSPAN junto al puerto SPAN previsto.
En Tunnel Protocol, seleccione gre.
En IP Address, introduzca la dirección de la interfaz de destino GRE.
Introduzca en GRE Port el valor correspondiente a la configuración de origen.
Seleccione Save.

Los cambios en la configuración de SPAN solo surten efecto después de reiniciar la máquina virtual. Antes de reiniciarla, compruebe si el mismo dispositivo procesa otras integraciones, ya que su recopilación de datos también se interrumpirá. Después, vuelva a validar los parámetros del túnel y el procesamiento.

Utilizar SPAN junto con VXLAN en el mismo dispositivo es un diseño habitual. Utilice VXLAN y GRE de forma simultánea en el mismo dispositivo únicamente si las fuentes, la capacidad y los dominios de fallo están claramente separados y documentados.

Entender AWS Traffic Mirroring

En AWS se aplica el mismo modelo de arquitectura: el Mirror Source es la ENI de la carga de trabajo aprobada, no la ENI de administración del sensor NDR; el Mirror Target y el filtro deben pertenecer al diseño NDR desplegado. Limite el filtro al alcance de datos previsto. El despliegue en AWS y la creación de la Traffic Mirror Session se describen en «Desplegar Sophos NDR en AWS» y no se repiten aquí.

Para la aceptación, utilice la cadena de evidencias descrita a continuación. La mera existencia de una sesión de AWS no demuestra que los paquetes lleguen al destino ni que se procesen, se carguen o generen una detección.

Limitar la capacidad antes de la aceptación

SPAN Port 2 no amplía la capacidad: la máquina virtual necesita al menos 8 vCPU para activarlo, pero la segunda entrada añade tráfico y, por tanto, demanda de procesamiento. Utilícelo solo para una fuente independiente que no se solape. Si la tasa o la pérdida de paquetes aumenta tras activarlo, compruebe si SPAN2 ha introducido carga adicional o duplicada.

«Supervisar el estado y la capacidad de Sophos NDR» explica cómo evaluar las señales de estado, unicast y descartes, y cómo valorar la capacidad. Para conocer los pasos de diagnóstico según los síntomas, consulte «Diagnosticar el appliance de integración y el sensor NDR». Según la plataforma, las medidas de capacidad pueden incluir más CPU para la máquina virtual o una distribución sin solapamientos en otro dispositivo; las demás integraciones con un uso intensivo de CPU deben planificarse por separado. Añadir SPAN2 por sí solo no aumenta la capacidad de procesamiento.

Validación: desde la fuente hasta la detección

Realice la validación con un host piloto conocido y una ventana de tiempo definida. De este modo, podrá atribuir un error a una etapa concreta en lugar de modificar simultáneamente el switch, el túnel, el sensor y Sophos Fusion.

1. Configuración y topología

Compare la fuente, la dirección y el destino con la matriz de cobertura.
Compruebe el estado indicado por el fabricante para la sesión SPAN o de AWS.
Asegúrese de que el destino no esté incluido como fuente.
En ERSPAN, compruebe la dirección de destino, los parámetros GRE o VXLAN y la ruta de red.
En plataformas virtuales, compruebe la asignación de la NIC de captura, el grupo de puertos o el vSwitch.

2. Paquetes en el destino

Utilice tráfico de prueba unicast controlado desde el host piloto para comprobar que los paquetes llegan al destino de captura previsto. Como evidencia, registre la ventana de tiempo, la interfaz de destino, las direcciones de origen y destino esperadas y, cuando corresponda, ambas direcciones del tráfico. Esta etapa demuestra que los paquetes probados llegaron al destino previsto, pero no que ya se hayan procesado o cargado. El tráfico de difusión por sí solo no es una prueba fiable. Si faltan paquetes, limite en un primer momento la investigación a la fuente, el filtro, la dirección, el transporte y el grupo de puertos virtual.

3. Captura y flujo en el puerto SPAN previsto

En Sophos Appliance Manager > NDR, registre para el puerto SPAN previsto tanto el porcentaje de captura mostrado como la actividad del gráfico Total Flow durante la ventana de 30 segundos. Ambos deben coincidir temporalmente con el tráfico piloto. Esto demuestra actividad en la entrada seleccionada; los indicadores no demuestran una captura completa de los paquetes, el alcance de datos correcto, ambas direcciones ni una carga satisfactoria.

La clasificación actual de Sophos considera que un puerto SPAN está en buen estado cuando al menos el 2 % de los paquetes de red son unicast. Este valor es únicamente el clasificador mínimo de estado: solo descarta que la proporción de tráfico unicast sea cero en la muestra observada. Una fuente incorrecta, parcial, duplicada, obsoleta o inadecuada para el objetivo también puede alcanzar el umbral del 2 %. Por tanto, este valor no demuestra que la fuente y la dirección sean las esperadas, que el tráfico sea útil, que exista cobertura, que el valor de captura mostrado sea correcto ni que se produzcan la carga o la detección. Las referencias anteriores a un 100 % de tráfico unicast no se consideran un requisito vigente.

4. Procesamiento y carga

En Sophos Appliance Manager > NDR, registre el porcentaje de carga mostrado para la misma ventana de tiempo y compárelo temporalmente con la actividad de captura y flujo. Esto documenta que existe actividad de carga, pero no demuestra que se hayan cargado todos los paquetes duplicados ni que posteriormente se genere una detección. Connected confirma principalmente la conexión del dispositivo y no sustituye esta evidencia. Si las señales de estado, captura, carga y descartes no concuerdan, siga el diagnóstico sistemático del dispositivo y el sensor.

5. Cobertura operativa

Para cada fila de la matriz de cobertura, genere tráfico de prueba específico y autorizado, y registre la hora, el dispositivo de prueba, el segmento esperado, la fuente, el destino y la dirección. Asocie a la prueba las evidencias de las etapas 2 a 4. Solo estas muestras indican que, en principio, se capturan las rutas probadas; no demuestran nada sobre segmentos o ventanas de tiempo que no se hayan probado.

6. Detección inofensiva de extremo a extremo

Solo después de aceptar correctamente la duplicación debe ejecutar el procedimiento independiente y aprobado «Generar y verificar una detección de prueba segura de Sophos NDR». Aquí no se anticipa la generación de la prueba. Verifique el resultado para el dispositivo de prueba y la ventana de tiempo esperados en Threat Analysis Center > Detections, y vincúlelo a la cadena de evidencias anterior. Una detección de prueba observada en ese punto demuestra la ruta de extremo a extremo probada; no garantiza la detección de todas las técnicas de ataque ni la cobertura de otras rutas.

Acotar las discrepancias etapa por etapa

Si la aceptación falla, investigue únicamente la primera etapa que no presente la evidencia esperada: primero, la ruta real de origen, la dirección y el filtro; después, el cableado de destino o la asignación de captura virtual; en ERSPAN, a continuación, el transporte y la correspondencia de los valores del túnel; luego, la captura y el flujo en el puerto previsto; y, por último, la carga y la detección. Un estado verde o un porcentaje de tráfico unicast de al menos el 2 % no permite omitir ninguna de estas etapas. Realice un solo cambio cada vez y vuelva a medir con el mismo piloto y la misma ventana de tiempo.

Si solo falta una dirección o un segmento, compare la matriz de cobertura con la ruta física o virtual real, sin añadir de forma preventiva más segmentos sensibles ni todos los puertos. Si la tasa es inusualmente alta, compare uno a uno los solapamientos documentados con los contadores y la visibilidad del tráfico piloto. Este procedimiento termina con la aceptación de la duplicación y la localización del fallo; si se producen errores del sensor, de carga o de la plataforma, continúe con el diagnóstico del dispositivo y el sensor.

Revertir de forma segura los cambios de este procedimiento

Antes de cada ampliación, registre el ID de sesión, las fuentes, las direcciones, los filtros, el destino, los parámetros del túnel y las tasas iniciales. La siguiente reversión solo abarca los cambios de duplicación que se hayan realizado durante este procedimiento; no es una guía para retirar un dispositivo, una pila en la nube u otra infraestructura.

Si surgen problemas, revierta los cambios en orden inverso:

elimine la última fuente local añadida; elimine cualquier AWS Traffic Mirror Session creada expresamente para este procedimiento;
restaure el último filtro ampliado al alcance piloto documentado;
desactive el ERSPAN que se haya activado o restaure los valores anteriores del túnel;
desactive SPAN Port 2 si ha introducido la nueva carga o el solapamiento;
restaure la sesión anterior del switch si se modificó una duplicación física;
vuelva a comprobar el flujo de paquetes, la tasa de descartes, el estado de la integración y el tráfico piloto.

La reversión de la configuración SPAN de Sophos vuelve a requerir Save y un reinicio de la máquina virtual para que el cambio surta efecto. También deben tenerse en cuenta las repercusiones en otras integraciones del mismo dispositivo. La reversión solo se considera finalizada cuando el estado vuelve a estar verde y, además, las rutas piloto documentadas anteriormente son visibles sin nuevos duplicados ni pérdidas de paquetes problemáticas.