Migrar los colectores de logs SVA a Sophos XDR Data Collectors

Al pasar a la solución ampliada Sophos XDR, Sophos aprovisiona una nueva configuración de XDR Data Collector para los colectores de logs Sophos Security Virtual Appliance (SVA) que cumplen los requisitos. Esto no instala ni activa automáticamente la VM en su entorno. Debe desplegar el sustituto, cambiar la ruta de Syslog y verificar la recepción de nuevos eventos. Si se utiliza la misma dirección IP, el colector antiguo no debe estar en ejecución cuando arranque el nuevo.

XDR Data Collector es un receptor virtual de Syslog instalado localmente o en AWS, Azure o GCP. Reenvía los logs recibidos a Sophos XDR. Una integración directa mediante API no necesita este receptor Syslog. El procedimiento de integraciones explica Data Ingest, Response Actions y estos tipos de conexión.

Si ya utiliza Sophos Next-Gen SIEM, Sophos recomienda sustituir los colectores Syslog SVA existentes por XDR Data Collectors para aprovechar toda la retención de datos admitida por el producto SIEM. No es necesario reconfigurar las integraciones API existentes para este cambio de colector Syslog. Esto no implica una duración de retención concreta ni un derecho a la retención SIEM para todos los tenants XDR; siguen siendo aplicables las condiciones de retención de su propio producto SIEM.

Estado de la revisión: 11 de octubre de 2026. La guía de migración del 1 de octubre de 2026 complementa el despliegue de septiembre. La antigua ruta de documentación EAP indica la procedencia de la versión y no garantiza que todos los tenants dispongan ya de la función. Compruebe primero el estado de actualización de su tenant y el colector que realmente se ofrece en Security Operations > Integrations > Data Collectors. Este procedimiento describe el cambio de Syslog y un despliegue local concreto en vSphere; contextualiza las direcciones de la nube, pero la creación de los recursos de cada plataforma de nube queda fuera de los pasos de vSphere.

Inventariar las cargas de trabajo existentes y los ajustes que no se migran

Para cada colector SVA antiguo, debe registrar la plataforma, el nombre, el nombre de host, los valores de red estáticos o la concesión DHCP, todas las fuentes emisoras y su destino Syslog, puerto y protocolo. Anote también el formato de datos, la selección de tipos de eventos, las exclusiones de dominios y protocolos, los ajustes de passthrough y las credenciales necesarias. Documente la última recepción de datos verificable de cada fuente; así podrá distinguir, tras el cambio, entre un flujo sin actividad y un fallo.

Se transfieren automáticamente el nombre del colector, el nombre de host o su derivación, la dirección IP estática, la máscara de subred, la puerta de enlace y el DNS, o bien la configuración DHCP, además de las asignaciones de puertos y protocolos Syslog. Se conservan los puertos de origen originales y se asignan a los puertos Syslog estándar UDP/514 y TCP/601, respectivamente. El tipo de plataforma determina el nuevo colector local o de nube.

No se transfieren automáticamente:

• Integraciones NDR: NDR no utiliza una ruta de reenvío Syslog. En una SVA mixta solo se migra la parte de Syslog; una SVA dedicada exclusivamente a NDR no recibe un XDR Data Collector para este fin.
• Filtros de tipos de eventos y listas de exclusión de dominios y protocolos.
• Ajustes de formato Syslog y passthrough específicos de SVA.
• Credenciales de integración.
• Investigation Consoles, Nessus Scanner y otros tipos de VM distintos de los colectores de logs SVA.
• Appliances de hardware físico: no se migran automáticamente a colectores virtuales.

Compruebe expresamente qué filtros y formatos siguen siendo necesarios para la nueva integración y qué configuración ofrece el conector para ellos. La ausencia de filtros puede provocar la ingesta de más datos de los previstos; un formato incorrecto puede hacer que los logs solo se procesen como eventos genéricos. No copie credenciales de tickets ni de capturas antiguas: vuelva a proporcionarlas mediante el sistema de gestión de secretos previsto para ello.

Si NDR se ejecuta en la misma SVA, el cambio de Syslog no debe apagar accidentalmente el sensor. La variante con la misma IP exige apagar la SVA antigua y, por tanto, interrumpe también su carga de trabajo NDR. Planifique su funcionamiento por separado o elija otra IP para el nuevo colector Syslog, de modo que la SVA pueda seguir funcionando para NDR. El procedimiento operativo de NDR aborda esta carga de trabajo; aprovisionar un sustituto de Syslog no equivale a migrar NDR.

Definir la variante de direccionamiento antes de la descarga

La dirección de destino determina si ambas VM pueden funcionar simultáneamente y si es necesario modificar las fuentes.

Con la misma IP estática, debe prever una breve fase de cambio: apague la SVA antigua y, a continuación, arranque la nueva VM. Las fuentes conservan su destino. Esto no garantiza una transición sin pérdidas; la conservación de eventos durante la interrupción también depende del almacenamiento en búfer y del transporte del sistema de origen.

Para un cambio gradual, defina la nueva IP estática antes de descargar la ISO. Ejemplo: el colector antiguo utiliza 192.0.2.10 y el nuevo 192.0.2.20. Estas direcciones de documentación no deben utilizarse en producción. En su lugar, elija una dirección libre en la red propia adecuada y compruebe la subred, la puerta de enlace, el DNS y la accesibilidad desde las redes de origen. Una nueva IP facilita la reversión y permite cambiar las fuentes una a una, pero exige adaptar las reglas de destino y de firewall.

Con DHCP y reutilización de la IP antigua, documente antes del cambio las direcciones MAC de las VM antigua y nueva, la reserva IP existente y el estado actual de la concesión. Después, modifique o cree la reserva para asociar la IP antigua a la dirección MAC de la nueva VM; siga el procedimiento documentado de reservas y concesiones de la plataforma DHCP utilizada. A continuación, apague la SVA antigua y solo entonces arranque el nuevo colector. Compruebe su concesión real y la IP asignada antes de validar los datos. Una reserva no impide que una VM antigua que siga en ejecución utilice la misma dirección.

En los colectores de nube, la dirección siempre cambia. En AWS con CloudFormation, el valor CTPxCollectorDnsName está disponible en Outputs de la pila. Es el nombre DNS del Network Load Balancer y debe preferirse a una IP fija para las fuentes Syslog. En Azure, compruebe la dirección de la interfaz de red de la VM en el portal de Azure; en GCP, consulte la dirección interna en Compute Engine > VM instances. Las direcciones DHCP pueden obtenerse en la tabla de concesiones mediante la nueva dirección MAC o en Data Collectors. No confunda esta dirección de destino para las fuentes con las direcciones regionales de enlace ascendente de Sophos.

Preparar la ruta de red y los recursos del colector

La carga de datos del colector a Sophos XDR utiliza mTLS con TLS 1.3 y TCP/443 de salida. Esto no significa que no se necesiten puertos de entrada: sus fuentes Syslog deben poder llegar al colector por el puerto y protocolo configurados. Los destinos estándar son UDP/514 y TCP/601; además, compare las asignaciones de puertos migradas con la configuración anterior. No cree una regla general de acceso desde Internet al receptor Syslog.

Autorizar el enlace ascendente regional, el DNS y la sincronización horaria

Los siguientes destinos de enlace ascendente del colector reflejan el estado revisado el 11 de octubre de 2026. La asignación US1/US2/US3/EU1/EU2 procede de la configuración de XDR Collector, no de una equivalencia supuesta con una región de AWS de Central. Utilice únicamente la región realmente asignada. El conjunto existente de IP de Sophos para llamadas API entrantes al proveedor externo constituye una lista de permitidos distinta.

Si su firewall exige autorizaciones basadas en IP, las siguientes direcciones de destino corresponden a este estado revisado. No agrupe regiones:

• US1: 18.217.45.178/32, 3.16.4.173/32, 18.224.219.97/32, 13.59.146.90/32, 3.16.16.254/32, 18.223.74.238/32.
• US2: 52.14.113.127/32, 3.141.73.137/32, 3.136.78.106/32.
• US3: 44.229.101.49, 35.166.77.47, 34.214.135.78.
• EU1: 18.158.143.139/32, 35.159.14.37/32, 52.59.37.234/32.
• EU2: 54.217.251.111/32, 54.194.78.20/32, 52.50.215.147/32.

Antes de realizar un cambio en producción, contraste la región y los valores de destino con la configuración actual del tenant y la lista de destinos permitidos del colector mantenida por el responsable de operaciones. Las discrepancias deben abordarse mediante un cambio revisado, no ampliando preventivamente los permisos. La grafía técnica del endpoint secureworks.com se mantiene sin cambios.

El colector también necesita UDP y TCP/53 hacia los servidores DNS indicados durante el aprovisionamiento. Para la sincronización horaria, se necesita UDP/123 hacia los servidores NTP elegidos. Si no se especifica un NTP propio, los colectores que no están en AWS utilizan de 0.pool.ntp.org a 3.pool.ntp.org; en AWS, el destino predeterminado es 169.254.169.123. Con NTP local, debe permitirse el tráfico entre el colector y el servidor horario en ambas direcciones. En el colector local, estos valores NTP sirven para el arranque inicial; una vez establecida la conexión, el canal del backend XDR se encarga de la sincronización horaria. Según la guía de la plataforma, los controladores de dominio de Windows no son un destino NTP para este host no unido al dominio.

Puede configurar un proxy web de reenvío mediante Host Proxy. La descripción general del colector excluye los proxies autenticados configurados de forma fija, mientras que la guía local también muestra una sintaxis de URL con usuario y contraseña. Estas indicaciones no coinciden. Por tanto, no planifique una ruta de proxy autenticado en producción sin aclarar su autorización con Sophos; no eluda esta contradicción incorporando credenciales en la ISO. Si se utiliza inspección TLS, el enlace ascendente mTLS concreto debe funcionar sin intervención MITM. Limite cualquier excepción a las conexiones necesarias del colector.

No dimensionar la VM local según los valores de la SVA antigua

La nueva VM local necesita 4 vCPU de al menos 2 GHz, 8 GB de RAM, un disco de sistema de 20 GB y un disco de datos de 200 GB. La guía de la plataforma recomienda vSphere ESXi 6.7 o posterior, Hyper-V 8.0 en Windows Server 2016 o posterior y Nutanix 6.8.x o posterior. La VM debe tener acceso a las funciones de CPU x86-64-v2; una máscara de compatibilidad de CPU inadecuada puede impedir el arranque.

La cifra de hasta 200 000 EPS es un límite máximo para colectores locales y de nube configurados adecuadamente, no una garantía de rendimiento con estos recursos mínimos. Dimensione según la cantidad, el tamaño y los picos de carga de los eventos, y controle el flujo de datos real. No se deben instalar herramientas de terceros ni aplicaciones adicionales en el colector. Las actualizaciones se realizan automáticamente, normalmente cada 24 horas, si la conexión funciona correctamente.

Desplegar en vSphere el colector local preaprovisionado

Para una migración existente, utilice la configuración correspondiente en Security Operations > Integrations > Data Collectors. Compare el nombre, los valores de red y las asignaciones Syslog con la SVA antigua. Descargue la ISO con la configuración del colector y la OVA de la VM. Ambas deben corresponderse; una ISO de otro colector aprovisionaría un estado incorrecto. Guarde los archivos de configuración con acceso restringido.

Si falta la configuración, compruebe primero las exclusiones y los errores de red de la siguiente sección. Para crear deliberadamente un sustituto nuevo de forma manual, la interfaz ofrece Actions > Add Collector > On-Premises > Next. Introduzca el nombre y el nombre de host, opcionalmente la descripción, Host Proxy y NTP, así como DHCP o todos los valores de red estáticos, y créelo con Create Collector. Esto no justifica crear un colector duplicado sin control junto a una migración ya existente.

El despliegue en vSphere se realiza de la siguiente manera:

1. En la consola web de vSphere, abra Virtual Machines > Create / Register VM y seleccione Deploy a virtual machine from an OVF or OVA file.
2. Asigne un nombre de VM único, como sophos-xdr-collector, y seleccione la OVA descargada. Puede elegir libremente el nombre; debe permitir distinguir la VM de la SVA antigua en el hipervisor.
3. Seleccione un datastore con al menos 220 GB libres para los dos discos. Compruebe la asignación de red y la configuración de discos, revise el resumen y finalice con Finish. Deje la VM apagada por el momento.
4. Cargue la ISO de configuración correspondiente en Storage > Datastore Browser.
5. Abra Edit Settings de la VM. Cambie el CD-ROM de Client Device a Datastore ISO File, seleccione la ISO cargada y guarde. Antes del primer arranque, compruebe que la ISO esté realmente conectada y que la VM pueda acceder a la red de origen correcta.
6. Si se utiliza la misma IP, apague ahora la SVA antigua. Solo después arranque la nueva VM. Con una IP nueva, la SVA antigua puede seguir funcionando; las fuentes se cambiarán posteriormente una a una.
7. En Security Operations > Integrations > Data Collectors, espere hasta que el nuevo colector muestre Ready. Solo entonces puede desmontar la ISO. Ready aún no confirma que todas las fuentes se estén recibiendo correctamente.

Para Hyper-V, Sophos proporciona un paquete VHD en lugar de una OVA; para Nutanix, archivos QCOW2. Siguen siendo necesarios el segundo disco de datos y la ISO conectada durante el primer arranque. La secuencia de clics de vSphere no debe trasladarse a estas plataformas. Del mismo modo, los colectores de nube deben desplegarse con los recursos de sus respectivas plataformas, no como OVA en vSphere.

Cambiar las fuentes y validar el flujo de datos

Si cambia la dirección de destino, configure todos los dispositivos y aplicaciones afectados para utilizar la nueva IP del colector o el nuevo nombre DNS. Cambie únicamente el destino, sin modificar el puerto, el protocolo ni el formato de logs sin verificarlos: estas asignaciones deben transferirse desde la SVA. Si una fuente enviaba antes por UDP/514, seguirá utilizando UDP/514 en esta migración. Cambiar el transporte a TCP constituye un cambio independiente que requiere comprobar el sistema de origen.

Si las IP son distintas, cambie primero una fuente de alcance limitado. Genere en ella un evento inocuo que el conector pueda recoger y anote la fuente, el tipo de evento y la hora con zona horaria. Búsquelo en XDR mediante la vía de datos o consultas disponible para esta integración. La verificación debe mostrar el tenant correcto, la fuente, la marca de tiempo y el formato de evento adecuado. Tenga en cuenta los retrasos previstos del conector; un evento de prueba no tiene por qué generar un caso ni una detección.

Solo después de esta comprobación cambie las demás fuentes. Compare, para cada fuente, los últimos eventos anteriores al cambio y los primeros posteriores. No cabe esperar una duración ni una tasa de eventos idénticas para todas las fuentes; lo decisivo es su actividad real y la ausencia de intervalos sin explicación. Evite enviar sin planificación el mismo flujo de datos simultáneamente a ambos colectores, ya que puede generar duplicados.

La SVA existente puede seguir funcionando durante la planificación. Los datos históricos ya recibidos por la SVA siguen pudiendo consultarse en XDR; el sustituto no necesita volver a enviarlos. Esto no implica una nueva garantía de retención ilimitada. El búfer de almacenamiento de 200 GB del nuevo colector almacena logs cuando el enlace ascendente es lento o se interrumpe temporalmente. No sustituye la comprobación de la fuente ni garantiza la cobertura de interrupciones de duración ilimitada.

La validación operativa solo se completa cuando todas las fuentes previstas proporcionan datos actuales y correctamente asignados, se han revisado expresamente los filtros y las exclusiones, funcionan el DNS, la sincronización horaria y el enlace ascendente y, si procede, NDR sigue funcionando por separado. Documente el momento del cambio y el periodo de observación. Hasta entonces, conserve la SVA antigua y su configuración para una posible reversión; solo después decida qué hacer con sus cargas de trabajo restantes y cómo retirarla de forma segura.

Acotar los errores y revertir sin conflictos de IP

No hay un colector nuevo: Un appliance de hardware, una SVA dedicada exclusivamente a NDR o una VM que no sea SVA no se migran automáticamente. Si se utiliza activamente una SVA para Syslog, compruebe que el puerto y el protocolo estén configurados y que los valores de red estáticos estén completos. La falta de valores de puerta de enlace o DNS puede impedir la migración. Corrija la configuración de red no válida en Fusion y acuerde con soporte una nueva migración, o cree un colector manual expresamente planificado. No introduzca direcciones ficticias solo para que se acepte un formulario.

La nueva VM no arranca: Compruebe la asignación de la ISO, el segundo disco, la RAM, las vCPU y las funciones x86-64-v2 visibles para la VM. No instale software de reparación ni de monitorización en el colector.

El colector sigue sin conexión: Compruebe primero la IP realmente asignada o la concesión, la puerta de enlace, el DNS y la sincronización horaria del arranque inicial. Después, revise los logs de firewall y proxy para el enlace ascendente regional TCP/443. Un puerto de salida abierto no demuestra por sí solo que el canal mTLS funcione. Si se utiliza la misma IP, asegúrese además de que la SVA antigua esté realmente apagada.

El colector está Ready, pero falta una fuente: Compruebe la dirección de destino de la fuente, la ruta y el puerto Syslog de entrada. Compare la asignación de puertos y el formato con la integración antigua. Un reenviador de logs intermedio debe conservar el formato esperado por la integración; de lo contrario, los datos pueden llegar como eventos genéricos en lugar de ajustarse al esquema previsto. Verifique primero la ruta de datos y busque después una detección.

Para la reversión, las direcciones estáticas y las reservas DHCP deben tratarse por separado:

• Misma IP estática: Apague la nueva VM y solo después arranque la SVA antigua con su configuración estática conservada. Las fuentes mantienen su destino anterior. Compruebe que la SVA antigua utilice realmente esa IP y reciba y reenvíe nuevos eventos Syslog. Nunca encienda ambas VM con esta dirección.
• Reserva DHCP para la misma IP: Apague primero la nueva VM. Después, vuelva a asociar la reserva de la IP antigua a la dirección MAC documentada de la SVA antigua y gestione el estado de la concesión conforme al procedimiento documentado de su plataforma DHCP. Este procedimiento no presupone ningún comando universal para eliminar concesiones. Solo entonces arranque la SVA antigua, compruebe su concesión real y su IP, y verifique la recepción y el reenvío con un nuevo evento Syslog. Las fuentes mantienen su destino anterior; por ello, el mero arranque de la SVA no demuestra que la reversión funcione. Nunca encienda ambas VM con esta dirección.
• Otra IP o destino DNS: Restablezca los destinos documentados de las fuentes y, si procede, las reglas de red correspondientes para apuntar al colector antiguo. Compruebe con un nuevo evento que la SVA antigua vuelva a recibir y reenviar datos. Retire el nuevo colector solo después de comprobar todas las asignaciones.

La reversión solo queda validada cuando se demuestra que la SVA antigua tiene la dirección de destino prevista y vuelve a recibir y reenviar eventos Syslog nuevos.

La reversión solo funciona mientras la SVA antigua siga disponible y conserve su configuración. No revierte la actualización del producto realizada por el proveedor ni garantiza la recuperación de eventos no entregados. Sophos anuncia un futuro fin de soporte para los colectores de logs SVA, pero no indica una fecha concreta en el estado de migración revisado aquí. Tras la migración, las nuevas instancias de colectores de logs deben crearse como XDR Data Collectors; por tanto, la SVA antigua es una opción limitada de reversión a la instalación existente, no una estrategia de nuevas instalaciones a largo plazo.

Si la causa sigue sin estar clara, recopile la identidad del colector y del tenant, la plataforma, los valores de red depurados, la fuente afectada, los intervalos de tiempo exactos, el estado y el mensaje de error. Para escalar el problema, consulte Abrir un ticket de soporte de Sophos. No incluya secretos, la ISO de configuración ni datos de logs sin depurar en tickets o capturas de pantalla de acceso público.