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 transporte, 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. UDP 514 es habitual; con TLS se utiliza a menudo TCP 6514, pero la configuración del Collector es la que manda.

1. Abrir System services > Log settings.
2. Seleccionar Add.
3. Asignar un nombre inequívoco, como siem-primary.
4. Introducir el Collector en IP address/domain.
5. Elegir Port, Facility, Severity level y Format de acuerdo con el sistema de destino.
6. Activar Secure log transmission si el Collector TLS está preparado.
7. Guardar.
8. 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: LOCAL0 a LOCAL7 permiten distinguir firewalls o grupos de ubicaciones. La asignación debe ser idéntica en el Collector y en la documentación.
• 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. Esto puede hacer que falten 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:

1. El certificado de servidor del Collector y su cadena de certificados deben ser de confianza para el firewall.
2. 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.
3. 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.
4. 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.

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:

1. 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.
2. 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.

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 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.

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.

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:

1. Documentar un firewall piloto y el formato configurado.
2. Enviar inicialmente Firewall y Events al destino.
3. Generar tráfico que coincida con una regla de prueba con logging y Source, Destination y Service definidos.
4. Comprobar en el SIEM el dispositivo, la hora, el tipo de log, la acción, Rule ID, Source y Destination.
5. Generar un drop definido y establecer y cerrar una conexión VPN.
6. 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.
7. 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.

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.