Enviar Syslog seguro de Sophos Firewall a un SIEM

Con Syslog, Sophos Firewall envía eventos a un servidor de logs externo, un SIEM o un SOC. Para que la integración resulte realmente útil, deben encajar cuatro elementos: transporte, selección de logs, formato y parser. Por eso, este artículo empieza directamente con la configuración y después muestra cómo detectar logs ausentes o interpretados de forma incorrecta.

El Log viewer local sigue siendo importante para el análisis en tiempo real. Central Firewall Reporting es adecuado para los informes de Sophos Central; Syslog es la opción correcta para una retención propia, la correlación entre distintos fabricantes y la detección mediante SIEM.

Configurar el servidor Syslog

Antes deben definirse la IP de destino o el FQDN, el puerto, el formato de log esperado y un parser adecuado. El firewall necesita una ruta hacia el Collector y ambos sistemas deben disponer de una fuente de tiempo operativa. SFOS utiliza normalmente UDP 514 para Syslog. La pantalla no ofrece una selección de transporte independiente: Secure log transmission activa o desactiva la transmisión cifrada mediante TLS. El ejemplo TLS oficial de Sophos para syslog-ng utiliza el puerto 6514; el puerto y el listener siempre deben coincidir con el Collector utilizado.

Abrir System services > Log settings.
Seleccionar Add.
Asignar un nombre inequívoco, como siem-primary.
Introducir el Collector en IP address/domain.
Elegir Port, Facility, Severity level y Format de acuerdo con el sistema de destino.
Activar Secure log transmission si el Collector TLS está preparado.
Guardar.
En Log settings, activar los tipos de log deseados en la columna de este servidor Syslog.

SFOS admite hasta cinco servidores Syslog externos. Varios destinos tienen sentido si cumplen funciones distintas, por ejemplo un archivo local y un Collector MDR. Enviar todos los logs indiscriminadamente a todos los destinos aumenta el volumen, los costes y el riesgo para la privacidad.

Facility, severidad y formato

Facility: Las opciones incluyen DAEMON, KERNEL, USER y de LOCAL0 a LOCAL7. Por ejemplo, se pueden asignar LOCAL1 y LOCAL2 a dos firewalls. La asignación debe ser coherente en el Collector y en la documentación operativa.
Severity level: La selección representa la severidad mínima. Error también envía Critical, Alert y Emergency, pero no eventos Information ni Notice. Debug incluye todos los niveles. Un mínimo demasiado alto puede ocultar inicios de sesión y eventos operativos normales.
Format: Se puede elegir entre Standard syslog protocol y Device standard format (legacy). Lo determinante es el formato que espera el parser del SIEM. Un cambio posterior puede romper búsquedas, dashboards y reglas de detección.

Secure log transmission

TLS es recomendable para conexiones productivas a través de redes inseguras o compartidas, porque los logs pueden contener direcciones internas, nombres de usuario, URLs y eventos de seguridad. Sin embargo, no basta con activar la opción: el Collector debe aceptar TLS en el puerto seleccionado y ambos extremos deben poder validar los certificados.

Para la conexión Secure Syslog documentada por Sophos se aplica lo siguiente:

El certificado de servidor del Collector y su cadena de certificados deben ser de confianza para el firewall.
El FQDN configurado debe coincidir con el certificado. Sin LINCE, SFOS comprueba el Common Name; con LINCE puede coincidir el Common Name o el Subject Alternative Name.
En Certificates > Certificate authorities se descarga la CA de Sophos Default. El Collector debe confiar en el archivo Default.pem extraído de ella, porque Sophos utiliza esta CA para su extremo de la conexión.
Solo entonces se activa Secure log transmission con el puerto TLS preparado.

En el ejemplo oficial de syslog-ng, Default.pem y la CA externa se encuentran en el directorio de CA del Collector; peer_verify(required-trusted) fuerza la validación del certificado. Otros productos Collector utilizan sus propios Trust Stores. Un FQDN que solo figure en el SAN no funciona sin LINCE, y una dirección IP configurada no coincide con un certificado que solo contenga un nombre DNS.

Antes de activar LINCE con este fin, se deben comprobar el límite de certificación, los algoritmos permitidos y el reinicio de SSH del modo LINCE. El modo no es solo un interruptor de syslog y no debe activarse sin un acceso administrativo independiente.

Si un SIEM en la nube no admite este procedimiento directamente, el firewall puede enviar los logs internamente a un Collector local, que los reenvía de forma cifrada. Un tramo sin cifrar debe ser corto, estar segmentado y quedar documentado.

Definir los tipos de log y la visibilidad

El destino se activa en dos fases:

La regla o función correspondiente debe generar el evento. En las reglas de firewall se requiere Log firewall traffic y en las reglas de SSL/TLS Inspection, Log connections.
En System services > Log settings, debe seleccionarse el tipo de log correspondiente en la columna del servidor Syslog.

Si falta una de las dos fases, el Collector no puede recibir el evento. Para un piloto basta inicialmente con un conjunto pequeño y deliberado:

Firewall y Events: eventos de reglas, actividad de administradores y usuarios, así como eventos de autenticación, VPN, DHCP y DNS.
IPS, Content filtering, Web server protection y Zero-day protection: decisiones de seguridad y de políticas.
Active threat response: coincidencias de MDR, NDR Essentials, Sophos X-Ops y Third-Party Threat Feeds.
System health, Wireless, Heartbeat y SD-WAN: estado operativo adicional cuando se utilizan estos módulos.

Solo deben añadirse otros módulos cuando exista un objetivo de búsqueda, alarma o auditoría. Si se analizan eventos DoS, también debe comprobarse la configuración de Spoof Protection y DoS. Para Third-Party Threat Feeds y NDR y Active Threat Response, además del transporte de logs se necesitan búsquedas y alarmas concretas.

Errores habituales de visibilidad

Log Suppression: SFOS puede agrupar eventos de firewall idénticos y consecutivos. Esto afecta a Log Viewer, Sophos Central y Syslog. Por tanto, el parser y la detección también deben tener en cuenta log_occurrence.
Active Threat Response: Remote Source Match para tráfico DNAT o WAF entrante no está activado de forma predeterminada. Sin esta selección faltan las coincidencias de origen correspondientes.
Wireless: Los logs de Access Points y SSID no están disponibles en el Log Viewer local. Deben enviarse específicamente a Sophos Central o Syslog y comprobarse allí.
Content filtering y SSL/TLS: El tipo de log seleccionado no sustituye el logging en la regla de firewall o de Inspection correspondiente.
Proxy web: Para el tráfico web de los puertos 80 o 443, el log Firewall puede mostrar Allowed mientras Web Filter bloquea la misma solicitud. Para conocer la decisión efectiva de la política deben correlacionarse ambos eventos.

Comprobar el formato y el parser

Una prueba del parser no debe limitarse a demostrar que llega algún texto. Los valores centrales deben poder buscarse como campos independientes. Este ejemplo abreviado y anonimizado corresponde a Standard syslog protocol para un evento de regla de firewall:

device_name="BRANCH-01" timestamp="2026-08-03T09:15:21+0200" device_model="XGS136" device_serial_id="C00000000000000" log_id="010101600001" log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" log_version=1 severity="Information" fw_rule_id="12" fw_rule_name="LAN_to_WAN_Web" nat_rule_id="4" src_ip="10.10.20.25" dst_ip="203.0.113.10" protocol="TCP" src_port=53144 dst_port=443 con_event="Stop" log_occurrence="1"

En cambio, el formato legacy utiliza, entre otros, device, date, time, timezone, device_id y priority. Campos como status, user_name, nat_rule_id o log_occurrence dependen además del tipo de log y del evento. No deben tratarse como obligatorios para todos los eventos del formato estándar. Para la aceptación inicial, configure el parser solo con los campos principales que se indican a continuación; exija otros campos específicos del tipo de log únicamente después de confirmarlos con un evento de prueba real.

Para la aceptación son especialmente importantes, según el caso de uso:

Identidad: device_name, device_model, device_serial_id
Clasificación: log_id, log_type, log_component, log_subtype, severity
Política: fw_rule_id, fw_rule_name, nat_rule_id
Conexión: src_ip, dst_ip, puertos, protocolo y usuario
Tiempo y frecuencia: timestamp, zona horaria y log_occurrence

log_id contiene el tipo de log, el componente, el subtipo, la severidad y el Message ID. Esto hace que las reglas de detección sean más estables que las búsquedas de texto libre. Aun así, los campos que proporciona cada módulo deben comprobarse con un evento real de ese tipo de log.

Los doce caracteres ocupan posiciones fijas: los caracteres 1 y 2 forman el Log Type ID, 3 y 4 el Component ID, 5 y 6 el Subtype ID, el carácter 7 el Priority ID y los caracteres 8 a 12 el Message ID. Por tanto, 010101600001 se interpreta como 01 / 01 / 01 / 6 / 00001. El parser debe conservar los ceros iniciales y la anchura fija de los campos; como comprobación adicional se evalúan log_type, log_component, log_subtype y severity.

El módulo Syslog Events no es idéntico a configuration-audit.log. Los valores anteriores y posteriores solo están disponibles allí para objetos clave compatibles, como reglas de firewall, interfaces e IP hosts, no para todos los cambios de configuración. El alcance y el análisis se explican en el artículo sobre Audit Trail Logs.

Varios firewalls y HA

En un entorno con varias appliances, cada evento debe poder asignarse claramente a un firewall, ubicación, cliente y clúster HA. Por tanto, el hostname, el número de serie, el modelo y la Facility deben estar documentados y ser filtrables en el SIEM. Desde SFOS 22.0, device_name identifica el hostname del firewall que generó el log. Después de una actualización, debe comprobarse que el parser incorpora este campo y no sigue usando solo device_serial_id o la cabecera Syslog como clave del asset.

Después de un failover HA, una restauración o un cambio de hardware, debe comprobarse si los eventos siguen asignados al asset existente o si aparecen como un sistema nuevo o duplicado. Lo mismo se aplica después de cambiar el hostname o el formato Syslog.

Probar la conexión con eventos reales

Un Collector en verde no demuestra que la selección de logs sea correcta ni que el parser funcione. Para la aceptación:

Documentar un firewall piloto y el estado inicial: nombre del servidor, destino, puerto, TLS, Facility, Severity, Format y todos los tipos de log activados en la columna del servidor.
Enviar inicialmente Firewall y Events al destino.
Generar tráfico que coincida con una regla de prueba con logging y Source, Destination y Service definidos.
Comprobar en el SIEM el dispositivo, la hora, el tipo de log, la acción, Rule ID, Source y Destination.
Generar un drop definido y establecer y cerrar una conexión VPN.
Probar al menos un evento de seguridad de IPS, Content filtering o Active threat response, siempre que el módulo se utilice en producción.
Activar después otros tipos de log paso a paso y observar el volumen y el resultado del parser.

Para probar reglas resulta útil la guía sobre Log Viewer, Policy Test y Packet Capture. También es importante una prueba negativa: una conexión esperada se bloquea de forma deliberada y debe aparecer como drop con la regla correcta.

En proyectos HA o de migración, la aceptación debe incluir una prueba de failover, restauración o cambio de hardware. Después, el SOC debe seguir reconociendo qué dispositivo y ubicación han generado el evento.

Revertir un cambio sin crear una interrupción de datos

No se deben cambiar al mismo tiempo el formato, la severidad mínima y la selección de logs. Si queda libre uno de los cinco espacios para servidores, se añade un segundo destino para migrar el parser o el Collector y ambos se mantienen primero en paralelo. Así se pueden comparar los datos sin procesar, los campos poblados, las marcas de tiempo y el volumen sin tocar el destino que funciona.

Solo después de la aceptación se desactivan los tipos de log en la columna del destino antiguo. Su entrada de servidor se conserva durante un periodo de observación acordado. Si faltan eventos, falla el parsing o el volumen es inesperado, se vuelven a activar allí exactamente los tipos de log documentados y se revierte la selección del nuevo destino. Si no queda ningún espacio libre, se registran los valores actuales antes de cada cambio individual y se restauran por completo si falla; no se elimina la entrada ni se cambia a la vez el parser.

Operación, retención y fallos

Una integración Syslog necesita un Owner, una retención definida y una respuesta ante las alarmas. Además, debe estar claro quién evalúa los falsos positivos y adapta las reglas de detección. Los logs de firewall pueden contener datos personales, direcciones internas, nombres de usuario, URLs y actividad VPN. Por tanto, los derechos de acceso, los plazos de eliminación, la separación entre tenants y los costes del SIEM deben aclararse antes del despliegue general.

La operación no solo debe detectar ataques, sino también la ausencia de datos:

supervisar una actividad mínima esperada por firewall;
comprobar por separado que tipos de log importantes como Firewall, Events, IPS o Active threat response estén actualizados;
supervisar campos centrales del parser para detectar valores vacíos o renombrados de forma inesperada;
generar alertas sobre la caducidad de certificados y el estado del Collector;
volver a generar eventos de prueba después de actualizar firmware, parser o certificados.

La propia supervisión también debe probarse: si se interrumpe deliberadamente el envío de un tipo de log esperado o de un firewall, debe activarse la alarma de ausencia definida.

Los datos sin procesar que no contienen campos interpretados también representan un fallo. Una actualización del parser puede dejar intacto el transporte mientras los dashboards y las reglas de detección dejan de generar coincidencias.

Syslog no sustituye los Service Logs locales ni un archivo de troubleshooting para soporte. Para registros v5 de reglas de firewall con logging activado de forma selectiva resulta adecuado NetFlow; para muestras de interfaz y patrones de tráfico, sFlow. El estado del hardware y de las interfaces también puede supervisarse mediante SNMP.

Aislar errores de forma específica

No llega ningún log: Comprobar el destino, el puerto, el transporte, el routing y el firewall del extremo opuesto. Después, verificar si el tipo de log deseado está activado en la columna Syslog. Si el Collector se encuentra detrás de una VPN o una red de administración, tener en cuenta también la ruta, la SD-WAN Policy y Source NAT.

Solo faltan determinados eventos: Comprobar primero el logging en la regla de firewall o de Inspection afectada y después el tipo de log en Log settings. En ATR, comprobar además el Match Type necesario.

Llegan logs sin procesar, pero faltan campos: Comparar el formato configurado, la versión del parser y la versión del firmware. Los campos estándar y legacy no deben esperarse en un mismo perfil de parser.

TLS no conecta: Comprobar el puerto TLS y el servicio del servidor, después la cadena de certificados, el FQDN, Common Name, SAN y el modo LINCE. Además, el Collector debe confiar en la CA de Sophos Default.pem. Al cambiar certificados, comprobar ambos Trust Stores y el proceso de renovación.

Las marcas de tiempo no coinciden: Comprobar NTP en el firewall y el Collector, la zona horaria del SIEM y la normalización del parser. Las horas incorrectas impiden una correlación fiable con logs de Endpoint, servidor e identidad.

Demasiados logs o demasiado ruido: No desactivar todo de forma indiscriminada. Evaluar primero los tipos de log que no se utilizan, las reglas innecesariamente ruidosas, los casos de uso del SIEM y log_occurrence; después, reducir la selección de forma específica.