Recibir telemetría de red mediante Sophos XDR Collector

Para OPNsense, pfSense, Netskope SSE y NetScaler ADC, la ruta documentada utiliza un Sophos XDR Data Collector. Primero desplegar el collector, después conectar la fuente en su formato syslog y verificar la ingesta real. Una dirección syslog genérica no basta: Sophos debe interpretar correctamente formato y categoría.

Los datos netflow descritos requieren una suscripción Sophos Next-Gen SIEM. Netskope y NetScaler también entregan otros esquemas que no llevan todos la misma nota SIEM en la documentación. En OPNsense y pfSense, el alcance comprobado son eventos firewall de conexión en netflow. La guía SIEM y los fundamentos de integración explican elección y licencias.

Preparar collector y fuentes

Aprovisionar el collector para el tenant correcto en Security Operations > Integrations > Data Collectors. El runbook del collector explica recursos, uplinks regionales, DNS, hora y diferencias frente a SVA antigua y NDR. Un XDR Data Collector nuevo no asume automáticamente una carga NDR existente.

Antes de cambiar la fuente, documentar ruta de logs previa, destino nuevo, redes autorizadas y eventos deseados. Permitir syslog entrante solo desde esas redes. No sustituir una ruta UDP documentada por TLS-syslog u otro formato sin verificar compatibilidad. UDP no confirma cada entrega; considerar pérdidas al comparar origen y destino.

Elegir para cada piloto un evento inocuo autorizado con hora y evidencia original. Un receptor configurado o estado verde no prueba ingesta de todas las categorías ni normalización. Validar por separado comunicación, flujo y contenido.

OPNsense: filterlog por UDP/514

La ruta OPNsense procesa mensajes filterlog de conexiones TCP, UDP e ICMP permitidas o bloqueadas. Requiere acceso administrativo OPNsense y collector accesible.

1. Tras desplegar el collector, abrir Remote Logging de OPNsense. La navegación depende de la versión; los siguientes campos reflejan la documentación Sophos.
2. Activar Enabled y elegir UDP(4) en Transport.
3. En Applications, elegir filter (filterlog). En Levels, seleccionar info, notice, warn, error, critical, alert y emergency. Dejar Facilities vacío.
4. En Hostname, poner la IP real del collector y en Port, 514. Desactivar rfc5424. La Description documentada es FilterLog; no confundir ese nombre con otro formato.
5. Guardar y generar un evento firewall inocuo previsto. La regla de origen debe registrarlo realmente. Comprobar primero hora, direcciones y acción en OPNsense; luego compararlas en netflow en Sophos.

Si falta el registro, comprobar logging de origen, selección filterlog, ruta UDP/IPv4, IP, puerto y RFC5424. No desactivar protección para forzar un flujo de prueba.

pfSense: Firewall Events en formato BSD

pfSense también entrega filter logs TCP, UDP e ICMP. El formato documentado difiere de otros logs pfSense; no sirve una selección syslog arbitraria.

1. Abrir Log Settings en la administración pfSense.
2. En General Logging Options, elegir BSD (RFC 3164, default).
3. Activar Enable Remote Logging en Remote Logging Options.
4. Elegir una interfaz o red accesible al collector en Source Address. Definir IP Protocol como IPv4.
5. Introducir la IP real del collector en Remote log servers y elegir Firewall Events en Remote Syslog Contents.
6. Guardar, generar un evento autorizado realmente registrado y encontrarlo en netflow del tenant Sophos correcto. Acción y conexión deben coincidir con el origen.

Otra Source Address puede cambiar routing y selección de firewall. Si faltan datos, comprobar primero la salida de esa interfaz, luego receptor y formato BSD. El procedimiento no incluye automáticamente otras categorías.

Netskope SSE: Cloud Log Shipper y CEF

Hay dos etapas: Netskope Cloud Log Shipper consulta las API Netskope y reenvía CEF por syslog al collector Sophos. Una cuenta Netskope introducida directamente en el collector no sustituye al Shipper.

Se pueden recibir actividades web/cloud, malware, alertas de seguridad/policy y administración, normalizadas, entre otros, en http, antivirus, thirdpartyalert, nids y auth. Los eventos adicionales de conexión/túnel netflow requieren SIEM.

1. Desplegar un Cloud Log Shipper aprobado para el tenant Netskope. Configurar API y categorías según el procedimiento Netskope correspondiente. La documentación Sophos no define permisos API universales.
2. Elegir Plugin: Syslog como salida del Shipper.
3. Usar Syslog Defaults Mapping en Mapping. Mantener la ruta CEF documentada; un mapping personalizado puede alterar la normalización.
4. Establecer la IP real del XDR Data Collector como destino. Transporte y receptor deben corresponder a la configuración aprobada; los requisitos UDP/514 de otros productos no fijan un puerto Netskope universal.
5. Elegir un evento adecuado y confirmar que el Shipper lo obtuvo de la API y lo reenvió. Comparar después esquema y campos en Sophos.

Si faltan solo conexiones, comprobar también categorías y entitlement SIEM. Un registro HTTP no prueba todas las categorías Netskope. Separar problemas de consulta API y reenvío syslog.

NetScaler ADC: auditoría con hora inequívoca

NetScaler ADC, antes Citrix ADC, envía eventos web/Application Firewall (http), autenticaciones/sesiones VPN (auth) y comandos administrativos (managementevent). Apertura y cierre TCP se asignan a netflow y requieren SIEM.

1. Tras desplegar el collector, abrir Audit Logging de syslog en NetScaler. Configurar servidor/policy según versión y alcance; Sophos no documenta un comando CLI universal.
2. Poner la IP del collector correcto como destino y verificar la ruta autorizada.
3. Usar fecha MM/DD/YYYY. DD/MM/YYYY no es compatible para la ingesta correcta.
4. Enviar marcas temporales en UTC. Cambiar después la visualización Sophos no corrige una fecha de origen mal interpretada.
5. Generar un cambio administrativo o login autorizado dentro del alcance. Comparar evidencia, hora, usuario y acción con el esquema Sophos adecuado. Netflow necesita su propia prueba de conexión.

Si un evento parece ausente, comparar primero hora de origen y ventana de búsqueda. Fecha o zona erróneas pueden colocarlo fuera del intervalo. Luego revisar audit policy, categoría enviada, IP y conectividad.

Aceptación y retirada controlada

Documentar por fuente al menos un evento reproducible, fuente, tenant, hora de ingesta y esquema. Comparar direcciones, puertos, acción y usuario cuando se esperen y estén presentes. La ausencia de detection o case no significa necesariamente ausencia de datos; importa el registro real.

Repetir la aceptación tras cambiar fuente o formato. Procesar bien CEF ayer no prueba nada del mapping modificado hoy. Para diferencias horarias, revisar el reloj de origen en lugar de desactivar la protección.

Para retirar, detener la nueva entrada Remote Logging o salida Shipper dedicada y comprobar la ruta anterior documentada. Conservar collectors, identidades API y otras salidas compartidas. Retirar recursos exclusivamente dedicados solo tras revisar dependencias. Eliminar la integración no prueba borrado histórico ni restaura eventos perdidos.