Enviar Syslog de Sophos Firewall a SIEM

Con Syslog, un Sophos Firewall puede enviar eventos a un servidor de registros externo, un SIEM o una plataforma de seguridad. Esto es especialmente importante cuando se necesita conservar registros por más tiempo, buscarlos centralmente, correlacionarlos con otros sistemas o utilizarlos para auditorías y respuesta a incidentes.

El Log viewer local es útil para un análisis rápido directamente en el firewall. Central Firewall Reporting es práctico cuando se utiliza Sophos Central como plataforma de informes. Syslog, en cambio, es la mejor opción cuando se dispone de un SIEM propio, un SOC, un proceso de detección gestionado o una arquitectura de registros de múltiples fabricantes.

¿Qué artículo de registro es adecuado?

El registro en Sophos Firewall consta de varios niveles. Dependiendo de la pregunta, Syslog no siempre es el mejor punto de partida:

Tarea	Artículo adecuado
Analizar en vivo una conexión individual, ID de regla o decisión de Web/IPS	Probar reglas de Sophos Firewall con Log Viewer, Policy tester y Packet Capture
Asignar archivos de registro y servicios locales	Solución de problemas de Sophos Firewall: Servicios y registros
Asegurar registros para soporte o análisis externo	Asegurar registros de Sophos Firewall para soporte y análisis
Rastrear cambios de configuración y acciones de administración	Revisar registros de auditoría de configuración de Sophos Firewall
Utilizar informes basados en Sophos Central en múltiples firewalls	Activar y operar informes centrales de Sophos Firewall
Enviar registros a largo plazo a SIEM, SOC o servidor de registros	Este artículo
Analizar flujos de tráfico en lugar de eventos individuales del firewall	Configurar monitoreo sFlow en Sophos Firewall
Verificar el estado del hardware e interfaces mediante monitoreo	Configurar monitoreo de hardware SNMP en Sophos Firewall

Así se mantiene el análisis limpio: el Log Viewer responde al caso actual de paquete o política, los registros locales ayudan en el diagnóstico más profundo de módulos, Central Reporting es conveniente para evaluaciones de Sophos, y Syslog proporciona la capa externa de largo plazo y SIEM.

Cuándo es útil Syslog

Syslog no solo es valioso para grandes entornos. Incluso con pocos firewalls, un servidor de registros central puede ayudar a conservar eventos por más tiempo e independientemente del dispositivo.

Casos de uso típicos:

conservación central de registros durante semanas, meses o años
correlación con registros de Endpoint, servidor, identidad, proxy, nube o switch
casos de uso de SIEM para ataques, escaneos de puertos, inicios de sesión VPN, eventos WAF o aciertos de Threat Feeds
evaluación externa por SOC, MDR o equipos de seguridad internos
trazabilidad después de actualizaciones de firmware, failover, restauración o cambio de hardware
forense, cuando los registros locales del firewall no son suficientes

Para casos de solución de problemas agudos, los registros locales siguen siendo importantes. Qué archivo de registro local pertenece a qué módulo del firewall se detalla en Solución de problemas de Sophos Firewall: Servicios y registros. Si se deben asegurar registros para soporte o análisis externo, Asegurar registros de Sophos Firewall para soporte y análisis es adecuado.

Syslog, Central Reporting o registros locales?

Los tres métodos responden a diferentes preguntas. En la práctica, a menudo se utilizan varios de ellos en paralelo.

Objetivo	Fortaleza	Límite
Log viewer	análisis rápido en vivo en el firewall	sin arquitectura central a largo plazo
Archivos de registro locales	análisis detallado mediante Advanced Shell o caso de soporte	dependiente del estado y almacenamiento del firewall
Central Firewall Reporting	informes de Sophos Central, visión general sencilla de múltiples firewalls	vinculado a Sophos Central, licencia y límites de almacenamiento
Syslog / SIEM	conservación propia, correlación, detección y auditoría	requiere parser, operación, monitoreo y casos de uso claros

Por lo tanto, Syslog no reemplaza al Log Viewer. Lo complementa. El Log Viewer muestra rápidamente qué regla o módulo tomó una decisión. Syslog asegura que esta información esté disponible externamente más tarde.

Requisitos previos

Antes de la configuración, se deben aclarar estos puntos:

El servidor Syslog o SIEM es accesible.
La IP de destino o FQDN es estable y está documentada.
El puerto y el transporte están definidos, a menudo UDP 514 o TLS en un puerto propio.
El firewall puede enrutar y alcanzar el servidor Syslog.
En el sistema de destino existe un parser adecuado o al menos un almacenamiento de datos en bruto.
La duración de conservación y los requisitos de protección de datos están definidos.
Está claro qué tipos de registros realmente se necesitan.

En objetivos SIEM externos o basados en la nube, se debe prestar especial atención al cifrado de transporte, IP de origen, enrutamiento, DNS y verificación de certificados.

Aclarar protección de datos, conservación y responsabilidad

Syslog no es solo una retransmisión técnica. Los registros del firewall pueden contener direcciones IP internas, nombres de usuario, sistemas de destino, URLs, categorías, inicios de sesión VPN, eventos de administración y aciertos de seguridad. Por lo tanto, antes de la conexión productiva, debe estar claro quién puede ver estos datos y cuánto tiempo se almacenarán.

Antes del despliegue, aclarar:

Punto	Pregunta práctica
Conservación	¿Cuánto tiempo deben estar disponibles los registros para operación, auditoría o respuesta a incidentes?
Acceso	¿Qué personas o equipos pueden ver registros en bruto, consultas de búsqueda y paneles?
Protección de datos	¿Contienen los registros datos personales, IDs de usuario, direcciones IP de origen o URLs?
Multitenencia	¿Están los sitios, clientes, inquilinos o clústeres HA claramente separados en el SIEM?
Costos	¿Se cobran volúmenes de registros, EPS, almacenamiento o consultas de búsqueda al proveedor de SIEM?
Alertas	¿Quién responde a las alertas y en qué marco de tiempo?
Eliminación	¿Cómo se eliminan los registros antiguos después de que expira el período de conservación?

Especialmente en modelos MSP, SOC o MDR, esta responsabilidad no debe quedar abierta. Un SIEM sin propietarios claros genera datos, pero no una respuesta confiable.

Planificar el despliegue en fases

Para firewalls productivos, un pequeño piloto es mejor que enviar inmediatamente todos los tipos de registros a todos los destinos. Esto permite controlar parsers, nombres de campos, ruido y costos antes de que el SIEM se planifique como una fuente confiable.

Un procedimiento sensato:

Primero se selecciona un firewall piloto.
Se documentan el nombre del host, la fuente de tiempo, la versión del firmware y el formato de registro.
Se configura el destino Syslog con transporte seguro.
Se comienza con pocos tipos de registros, por ejemplo, firewall, eventos y VPN.
Se generan eventos de prueba definidos y se verifican en el sistema de destino.
Se validan parsers, campos, marcas de tiempo, zona horaria y device_name.
Se observa el volumen de registros y el ruido durante varios días.
Luego se agregan más tipos de registros como IPS, Web, WAF, respuesta activa a amenazas o salud del sistema.
Solo después de un piloto exitoso se despliega en más firewalls.

En entornos con varios firewalls, no solo se debe verificar si llegan los datos. Es importante si cada evento se asigna al sitio, dispositivo, nodo HA, cliente o inquilino correcto.

Agregar servidor Syslog

La configuración se realiza en la interfaz web de Sophos Firewall.

Abrir System services > Log settings.
Seleccionar Add.
Asignar un nombre único, por ejemplo, siem-primary o syslog-soc.
Ingresar la IP address/domain del servidor Syslog.
Establecer el Port adecuado para el sistema de destino.
Elegir conscientemente la Facility.
Establecer el Severity level.
Seleccionar el Format.
Opcionalmente, activar Secure log transmission si el destino admite TLS.
Guardar.

Sophos Firewall puede configurar varios servidores Syslog externos. La documentación actual prevé hasta cinco servidores Syslog. Sin embargo, no se debe conectar indiscriminadamente cada destino, sino establecer por cada destino cuál es su propósito.

Configuraciones importantes

Facility

La Facility ayuda al servidor Syslog a distinguir fuentes de registros o categorías. En entornos simples, a menudo basta con un valor estándar. En entornos más grandes, puede ser útil separar firewalls o grupos de sitios mediante diferentes valores de LOCAL0 a LOCAL7.

Es importante que las reglas de SIEM, parsers y documentación utilicen la misma lógica. Si cada firewall utiliza una Facility diferente al azar, el análisis se vuelve innecesariamente difícil.

Severity level

La Severity establece a partir de qué gravedad se envían los registros. Para propósitos de seguridad y solución de problemas, un umbral demasiado alto es peligroso, ya que pueden faltar eventos importantes de información o aviso. Para entornos muy ruidosos, un umbral demasiado bajo puede generar un ruido innecesario.

Generalmente es útil un piloto con una selección más amplia de registros, seguido de una reducción consciente basada en aciertos reales y casos de uso de SIEM.

Format

Según la documentación actual, Sophos Firewall ofrece dos formatos:

Standard syslog protocol
Device standard format (legacy)

Para nuevas integraciones, primero se debe verificar qué formato espera el sistema de destino o el parser existente. Si un SIEM ya tiene un parser para Sophos Firewall, su expectativa es determinante. Un cambio de formato después del inicio productivo puede romper paneles, consultas de búsqueda y reglas de detección.

Secure log transmission

Cuando Secure log transmission está activo, los registros se envían cifrados al servidor Syslog. Para ello, el sistema de destino debe aceptar TLS en el puerto configurado, entregar un certificado de servidor adecuado y utilizar una cadena de certificados en la que confíe el firewall. Antes del lanzamiento, no solo se debe marcar la casilla en el firewall, sino también verificar el nombre del certificado, la cadena de confianza, el puerto, el parser y el proceso de renovación del destino Syslog.

Para laboratorios internos, técnicamente puede ser suficiente UDP. Sin embargo, para conexiones productivas a SIEM o SOC, Syslog sin cifrar a través de redes inseguras no es una buena base, ya que los datos de registro pueden contener direcciones IP internas, usuarios, destinos, URLs o eventos de seguridad.

Con TLS, el nombre del destino Syslog es importante. Sophos verifica, según el modo, el Common Name o el Subject Alternative Name del certificado contra el dominio del servidor Syslog. Si en el firewall se ingresa una dirección IP, pero el certificado solo contiene un nombre DNS, la conexión puede fallar. Por lo tanto, para destinos TLS-Syslog productivos, se debe planificar un FQDN estable, un certificado de servidor adecuado y una renovación de certificados documentada.

Seleccionar tipos de registros

Después de agregar el servidor Syslog, el trabajo aún no está terminado. Se debe establecer en System services > Log settings qué tipos de registros se enviarán a este destino.

Importante: Una regla de firewall solo genera registros de tráfico significativos si en la regla está activado Log firewall traffic. Para la inspección SSL/TLS, también debe estar activo el registro en la regla de inspección correspondiente. La selección de registros en Log settings determina luego a dónde se envían estos registros.

Tipos de registros típicos para un SIEM:

Tipo de registro	Por qué es útil
Firewall	conexiones permitidas y rechazadas, coincidencia de reglas, eventos DoS
IPS	ataques detectados o bloqueados
Web / Content filtering	accesos web, categorías, eventos de políticas web
SSL/TLS inspection	decisiones y errores de inspección TLS
Web server protection	eventos WAF para servicios publicados
Authentication / Events	eventos de administración, usuario y sistema
VPN	eventos de acceso remoto y VPN de sitio a sitio
Active threat response	aciertos de MDR Threat Feeds, NDR Essentials, Sophos X-Ops y Third-Party Threat Feeds
System health	CPU, memoria, usuarios, interfaces y particiones

Si se van a evaluar eventos DoS o de suplantación, también se debe verificar la protección técnica en sí. El procedimiento está en Verificar protección contra suplantación y configuraciones DoS de Sophos Firewall.

Si se utilizan Third-Party Threat Feeds, NDR y Active Threat Response o WAF, el SIEM debe evaluar estos eventos específicamente. Solo enviar registros no es suficiente. Se necesitan consultas de búsqueda claras, alertas, responsabilidades y ajuste contra falsas alarmas.

Trampas importantes de visibilidad

En proyectos de Syslog, muchas brechas no surgen en el transporte, sino antes: el firewall no genera el evento esperado, el tipo de registro no se envía al servidor Syslog o el SIEM interpreta incorrectamente los campos.

Registro de reglas y módulos

Las reglas de firewall y las reglas de inspección SSL/TLS deben generar registros por sí mismas. En System services > Log settings se selecciona luego si estos registros se envían localmente, a Sophos Central o a servidores Syslog. Si una regla de firewall no tiene Log firewall traffic, el servidor Syslog no puede mostrar un historial completo del tráfico del firewall.

Para eventos de políticas web, también es relevante si la regla de firewall asociada genera registros de tráfico. De lo contrario, es posible que se vean menos eventos de filtrado de contenido o web en el SIEM de lo esperado.

Supresión de registros

Sophos Firewall puede suprimir múltiples entradas de registro idénticas consecutivas. Esto ahorra almacenamiento y procesamiento, pero puede confundir en casos de uso de SIEM si se deben evaluar valores de conteo, frecuencia o comportamiento de ráfaga. La función afecta al Log Viewer, Sophos Central y servidores Syslog externos.

Antes de un despliegue productivo de SIEM, se debe establecer:

¿Qué eventos de firewall pueden ser suprimidos?
¿Qué reglas de detección necesitan cada conexión individual?
¿Se trabaja en el SIEM con valores de conteo o solo con eventos individuales?
¿Cómo se documenta que la supresión de registros está activa?

Respuesta activa a amenazas

Los registros de respuesta activa a amenazas son especialmente útiles cuando se utilizan Threat Feeds, NDR Essentials o feeds externos. Sophos distingue entre diferentes tipos de coincidencias, por ejemplo, coincidencias de destino en tráfico saliente y coincidencias de origen en tráfico entrante.

Importante: La coincidencia de fuente remota para tráfico entrante no está activada automáticamente. Si se desea monitorear el tráfico WAF o DNAT contra Threat Feeds, esta visibilidad debe ser verificada conscientemente. De lo contrario, faltarán exactamente las coincidencias entrantes que un SOC a menudo espera.

Registros inalámbricos

Los registros inalámbricos no son visibles automáticamente en el Log Viewer local. Los registros de puntos de acceso y SSID deben enviarse específicamente a Sophos Central o Syslog y verificarse por separado en el sistema de destino si los eventos inalámbricos son relevantes para operación, soporte o cumplimiento.

Entornos con múltiples firewalls

En entornos con múltiples firewalls, cada evento debe poder asignarse claramente a un dispositivo. Para ello, son relevantes el nombre del host, número de serie, modelo y otros campos. La guía de Syslog de SFOS describe, entre otros, campos como device_name, device_model y device_serial_id.

Recomendaciones prácticas:

Establecer claramente el nombre del host del firewall.
Considerar el sitio o el rol en el nombre del host.
Definir una estrategia unificada de Facility o etiquetado.
Verificar en el SIEM si los eventos se pueden filtrar por firewall, sitio y clúster.
Distinguir claramente entre clústeres HA y firewalls independientes.

Especialmente después de un cambio de hardware o restauración, esta asignación es importante. De lo contrario, los eventos en el SIEM pueden parecer sistemas nuevos o duplicados.

Probar la configuración

Después de guardar, la conexión debe probarse conscientemente. Un sistema de destino verde por sí solo no prueba que los registros correctos lleguen con los campos correctos.

Puntos de prueba:

En el firewall, abrir System services > Log settings.
Asegurarse de que el servidor Syslog sea visible.
Activar Syslog de prueba para un tipo de registro inofensivo.
Desencadenar una acción definida, por ejemplo, una regla de firewall registrada o un acceso de prueba.
Verificar en el sistema de destino si llega el evento.
Verificar campos como tiempo, nombre del host, device_name, origen, destino, ID de regla, acción y tipo de registro.
Controlar marcas de tiempo y zona horaria en el SIEM.

Para pruebas de reglas, Probar reglas de firewall con Log Viewer, Policy Test y Packet Capture es útil. Si no se generan eventos, a menudo la causa no está en el transporte Syslog, sino en el registro desactivado en la regla o en el tipo de registro incorrecto.

Operación y monitoreo

Una conexión Syslog no es un simple ajuste. La operación debe ser monitoreada y revisada regularmente.

Al menos estos puntos deben estar documentados:

¿Quién es el propietario de la plataforma de registros?
¿Qué firewalls envían registros?
¿Qué tipos de registros se envían?
¿Cuál es la duración de conservación?
¿Qué parsers, paneles y alertas dependen de ello?
¿Cómo se detecta que ya no llegan registros?
¿Cómo se verifican los cambios de formato después de actualizaciones de firmware?
¿Quién evalúa las falsas alarmas y ajusta las reglas de SIEM?

Después de actualizaciones de firmware, se debe verificar aleatoriamente si los eventos importantes aún se analizan correctamente. Esto es especialmente cierto para las reglas de SIEM productivas que dependen de nombres de campos, tipos de registros o formatos específicos.

Solución de problemas

No llegan registros al SIEM

Primero verificar dirección IP, puerto, enrutamiento y reglas de firewall entre Sophos Firewall y el servidor Syslog. Luego, controlar si en System services > Log settings está activado el tipo de registro correcto para el servidor Syslog.

Solo faltan ciertos eventos

A menudo, el registro de módulos o reglas no está activo. En las reglas de firewall, debe estar activado Log firewall traffic. En eventos web o SSL/TLS, además, la política o regla de inspección correspondiente debe generar registros.

Los registros llegan, pero se analizan incorrectamente

Verificar formato, versión del parser y versión del firmware. Si se cambió entre Standard syslog protocol y Device standard format (legacy), el parser de SIEM debe coincidir.

Syslog TLS no se conecta

Verificar FQDN, certificado, Common Name, Subject Alternative Name, cadena de certificados y puerto. Si el firewall espera un nombre DNS, pero el servidor Syslog solo se ingresó con dirección IP, la verificación del certificado puede fallar. Además, controlar si el sistema de destino realmente acepta TLS en el puerto configurado.

Las marcas de tiempo no son correctas

Verificar NTP en el firewall, zona horaria en el SIEM y lógica del parser. Tiempos incorrectos hacen que la correlación con registros de Endpoint, servidor o identidad sea poco confiable.

Demasiados registros o demasiado ruido

No desactivar todo de inmediato. Primero verificar qué tipos de registros realmente se necesitan, qué reglas generan demasiado registro y si la supresión de registros es útil. Luego reducir de manera específica.

Lista de verificación

El servidor Syslog o SIEM es accesible.
Transporte, puerto y cifrado están definidos.
El formato coincide con el parser de SIEM.
La estrategia de Facility está documentada.
Los tipos de registros relevantes están activados en System services > Log settings.
Las reglas de firewall importantes tienen activado Log firewall traffic.
Las reglas de inspección SSL/TLS generan registros propios si es necesario.
La supresión de registros está evaluada y documentada conscientemente.
Los tipos de coincidencia de respuesta activa a amenazas coinciden con los casos de uso de SIEM.
Protección de datos, acceso y duración de conservación están aclarados.
Se validaron el firewall piloto, los eventos de prueba y el parser de SIEM.
Los eventos de prueba llegan al sistema de destino.
Campos como nombre del host, device_name, origen, destino, acción e ID de regla se reconocen correctamente.
Las marcas de tiempo y la zona horaria son correctas.
El monitoreo detecta cuando ya no llegan registros.
Después de actualizaciones de firmware, se verifica la función del parser.

FAQ

¿Cuántos servidores Syslog soporta Sophos Firewall?

SFOS actualmente soporta hasta cinco servidores Syslog externos. En la práctica, sin embargo, solo se deben configurar los destinos que realmente se necesitan y se monitorean.

¿Es suficiente UDP 514 para Syslog de Sophos Firewall?

UDP 514 es el estándar clásico de Syslog y funciona en muchas redes internas. Para conexiones productivas a SIEM o SOC, se debe verificar si es posible TLS con Secure log transmission, especialmente si los registros se transportan a través de redes inseguras o compartidas.

¿Por qué no se ven eventos de reglas de firewall en el SIEM?

A menudo, en la regla de firewall afectada no está activado Log firewall traffic o el tipo de registro Firewall no se envía al servidor Syslog. Ambos deben coincidir.

¿Es Syslog mejor que Central Firewall Reporting?

Es un propósito diferente. Central Firewall Reporting es conveniente para informes de Sophos Central. Syslog es más fuerte cuando se necesita conservación propia, correlación SIEM, procesos SOC o evaluación de múltiples fabricantes.

¿Qué registros se deben enviar a un SIEM?

Al menos se deben evaluar Firewall, Events, VPN, IPS, Web, Web server protection, Active threat response y System health. La selección concreta depende de la arquitectura, protección de datos, costos de SIEM, casos de uso y modelo operativo.

¿Por qué faltan eventos web o de firewall individuales a pesar de Syslog?

A menudo, el tipo de registro correcto se envía a Syslog, pero la regla de firewall o la regla de inspección afectada no generan registros por sí mismas. Además, la supresión de registros, los filtros del parser o un tipo de coincidencia no activado en la respuesta activa a amenazas pueden reducir la visibilidad.