Envíe Sophos Firewall Syslog de forma segura a SIEM

Con Syslog, un Sophos Firewall puede enviar eventos a un servidor de registro externo, un SIEM o una plataforma de seguridad. Esto es particularmente importante si los registros se conservarán durante períodos de tiempo más prolongados, se buscarán de forma centralizada, se correlacionarán con otros sistemas o se utilizarán para auditorías y respuesta a incidentes.

El visor de registros local es bueno para un análisis rápido directamente en el firewall. Informes del firewall central es conveniente cuando se utiliza Sophos Central como plataforma de informes. Syslog, por otro lado, es la mejor opción si tiene su propio SIEM, un SOC, un proceso de detección administrado o una arquitectura de registro entre fabricantes.

¿Qué artículo de registro encaja?

El inicio de sesión en Sophos Firewall consta de varios niveles. Dependiendo de la pregunta, Syslog no siempre es la mejor manera de empezar:

• Analizar conexión única, Rule ID o decisión web/IPS en vivo: Prueba de reglas Sophos Firewall con Log Viewer, probador de políticas y Packet Capture
• Asignar archivos de registro y servicios locales: Sophos Firewall Solución de problemas: Services y registros
• Realizar copias de seguridad de registros para soporte o análisis externo: Sophos Firewall Copia de seguridad de registros para soporte y análisis
• Seguimiento de cambios de configuración y acciones administrativas: Sophos Firewall Verificar registros de seguimiento de auditoría
• Utilice informes basados ​​en Sophos Central en varios firewalls: Sophos Firewall Activar y operar informes centrales
• Envíe registros a largo plazo a SIEM, SOC o servidor de registros: Este artículo
• Analizar flujos de tráfico en lugar de eventos de firewall individuales: Configurar monitoreo de sFlow en Sophos Firewall
• Verifique el estado del hardware y de la interfaz mediante monitoreo: Sophos Firewall Configuración de monitoreo de hardware SNMP

Esto mantiene limpia la evaluación: el Log Viewer responde al paquete o caso de política actual, los registros locales ayudan con diagnósticos más profundos del módulo, los informes centrales son convenientes para las evaluaciones de Sophos y el Syslog proporciona la capa externa a largo plazo y el SIEM.

Cuando Syslog tiene sentido

Syslog no sólo vale la pena para entornos grandes. Incluso con algunos firewalls, un servidor de registro central puede ayudar a retener los eventos por más tiempo e independientemente del dispositivo.

Casos de uso típicos:

• Almacenamiento central de registros durante semanas, meses o años.
• Correlación con registros de terminales, servidores, identidades, proxy, nubes o conmutadores
• Casos de uso de SIEM para ataques, escaneos de puertos, inicios de sesión de VPN, eventos WAF o accesos a fuentes de amenazas
• evaluación externa por SOC, MDR o equipos de seguridad internos
• Trazabilidad después de actualizaciones de firmware, conmutación por error, restauración o reemplazo de hardware
• Análisis forense cuando los registros del firewall local ya no son suficientes

Los registros locales siguen siendo importantes para los casos de resolución de problemas graves. Qué archivo de registro local pertenece a qué módulo de firewall se puede encontrar en Sophos Firewall Solución de problemas: Services y registros. Si desea realizar una copia de seguridad de los registros para soporte o análisis externo, Sophos Firewall Copia de seguridad de registros para soporte y análisis es adecuado.

¿Syslog, Central Reporting o registros locales?

Las tres vías responden a preguntas distintas. En la práctica, a menudo se utilizan varias en paralelo.

• Log viewer: análisis rápido en directo en el firewall, pero sin arquitectura central a largo plazo.
• Archivos de log locales: análisis detallado mediante Advanced Shell o caso de soporte, pero dependiente del estado y del almacenamiento del firewall.
• Central Firewall Reporting: informes de Sophos Central y visión sencilla de varios firewalls, pero ligados a Sophos Central, la licencia y el marco de almacenamiento.
• Syslog / SIEM: retención propia, correlación, detección y auditoría. Para ello se necesitan parsers, operación, monitorización y casos de uso claros.

Syslog no sustituye al Log Viewer. Lo complementa. El Log Viewer muestra rápidamente qué regla o módulo tomó la decisión. Syslog garantiza que esa información siga disponible externamente más adelante.

Requisitos

Antes de la configuración conviene aclarar estos puntos:

• Se puede acceder al servidor Syslog o SIEM.
• La IP o FQDN de destino es estable y está documentada.
• El puerto y el transporte son fijos, normalmente UDP 514 o TLS en su propio puerto.
• El firewall puede enrutar y alcanzar el servidor Syslog.
• Hay un analizador adecuado o al menos un almacenamiento de datos sin procesar en el sistema de destino.
• NTP funciona en firewall y plataforma de destino.
• Se definen el plazo de conservación y los requisitos de protección de datos.
• Está claro qué tipos de registros son realmente necesarios.

Para destinos SIEM externos o basados ​​en la nube, se debe prestar especial atención al cifrado de transporte, la IP de origen, el enrutamiento, el DNS y la verificación de certificados. Algunos proveedores de SIEM o MDR esperan deliberadamente que el Syslog no cifrado llegue a un recopilador o sensor local que luego reenvía los datos. Entonces, la ruta no cifrada debe ser corta, segmentada internamente y documentada.

Aclarar protección, almacenamiento y responsabilidad de datos

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

Aclare antes del lanzamiento:

• Almacenamiento: ¿Cuánto tiempo deben permanecer disponibles los registros operativos, de auditoría o de respuesta a incidentes?
• Acceso: ¿Qué personas o equipos pueden ver registros sin procesar, consultas de búsqueda y paneles?
• Protección de datos: ¿Los registros contienen información personal, ID de usuario, direcciones IP de origen o URL?
• Capacidad multicliente: ¿Las ubicaciones, los clientes, los inquilinos o los clústeres del HA están claramente separados en el SIEM?
• Costo: ¿Los volúmenes de registros, EPS, almacenamiento o consultas de búsqueda los factura el proveedor SIEM?
• Alerta: ¿Quién responde a las alarmas y en qué plazo?
• Eliminación: ¿Cómo se eliminan los registros antiguos una vez transcurrido el período de retención?

Esta responsabilidad no debe quedar abierta, especialmente con los modelos MSP, SOC o MDR. Un SIEM sin un propietario claro produce datos, pero no una respuesta confiable.

Planificar la implementación en fases

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

Un proceso sensato:1. Primero, se selecciona un firewall piloto. 2. Se documentan el nombre del host, la fuente horaria, la versión del firmware y el formato de registro. 3. El destino Syslog está configurado con transporte seguro. 4. Comienza con algunos tipos de registros, por ejemplo firewall, eventos y VPN. 5. Los eventos de prueba definidos se generan y verifican en el sistema de destino. 6. Se validan el analizador, los campos, la marca de tiempo, la zona horaria y device_name. 7. El volumen de los registros y el ruido se observan durante unos días. 8. Luego se agregan tipos de registros adicionales como IPS, Web, WAF, respuesta activa a amenazas o estado del sistema. 9. Sólo después de una prueba piloto exitosa se implementará en otros firewalls.

Si tiene varios cortafuegos, no debería limitarse a comprobar si llegan datos. Lo importante es si cada evento está asignado a la ubicación, dispositivo, nodo HA, cliente o inquilino correcto.

El piloto debería contener al menos un evento operacional normal, un evento de seguridad y un evento de error. Por lo demás, el transporte parece saludable, pero los campos importantes posteriores sólo faltan en caso de emergencia.

Agregar servidor Syslog

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

1. Abra System services > Log settings.
2. Seleccione Agregar.
3. Asigne un nombre exclusivo, por ejemplo siem-primary o syslog-soc.
4. Ingrese dirección IP/dominio del servidor Syslog.
5. Configure Puerto para que coincida con el sistema de destino.
6. Elija Instalación conscientemente.
7. Establezca Nivel de gravedad.
8. Seleccione Formato.
9. Opcionalmente, habilite Secure log transmission si el destino admite TLS.
10. Guardar.

Sophos Firewall puede configurar múltiples servidores Syslog externos. La documentación actual proporciona hasta cinco servidores Syslog. Sin embargo, no se deben conectar todos los objetivos al azar, sino más bien determinar el propósito detrás de cada objetivo.

Si tiene varios objetivos, debe separar conscientemente la selección de registros para cada objetivo. Un servidor de registros local puede necesitar todos los registros de firewall y VPN, mientras que un recopilador MDR solo espera tipos de registros relevantes para la seguridad. Si todos los objetivos reciben ciegamente los mismos datos, aumentan los costos, el riesgo de privacidad y el ruido del analizador.

Configuraciones importantes

Instalación

La función ayuda al servidor Syslog a distinguir fuentes o categorías de registros. En entornos simples, un valor predeterminado suele ser suficiente. En entornos más grandes, puede tener sentido separar firewalls o grupos de ubicaciones utilizando diferentes valores de LOCAL0 a LOCAL7.

Es importante destacar que las reglas, los analizadores y la documentación del SIEM utilizan la misma lógica. Si cada firewall utiliza una instalación diferente, la evaluación se vuelve innecesariamente difícil.

Nivel de gravedad

La gravedad determina la gravedad con la que se envían los registros. Por motivos de seguridad y solución de problemas, un umbral demasiado alto es peligroso porque se puede perder información importante o eventos de aviso. Sin embargo, en entornos muy ruidosos, un umbral demasiado bajo puede generar una cantidad innecesaria de ruido.

Por lo general, tiene sentido tener una prueba piloto con una selección más amplia de registros y luego una reducción consciente basada en visitas reales y casos de uso de SIEM.

El umbral debe entenderse como gravedad mínima. Por ejemplo, si se selecciona Error, el firewall también envía mensajes más críticos como Critical, Alert y Emergency, pero no eventos informativos normales. Para muchos casos de uso SIEM, los eventos Information y Notice son importantes porque, de lo contrario, pueden faltar inicios de sesión VPN, eventos de reglas o estados del sistema.

formato

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

• Protocolo syslog estándar
• Formato estándar del dispositivo (heredado)

Para nuevas integraciones, primero debe verificar qué formato espera el sistema de destino o el analizador existente. Si un SIEM ya tiene un analizador de firewall de Sophos, sus expectativas tienen prioridad. Un cambio de formato después de la puesta en marcha puede alterar los paneles, las consultas de búsqueda y las reglas de detección.

Secure log transmission

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

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

Con TLS, el nombre del destino Syslog es importante. Sin el modo de cumplimiento LINCE activado, Sophos Firewall comprueba el Common Name del certificado con el dominio del servidor Syslog; en este caso estándar, el Subject Alternative Name no se usa como sustituto. Con LINCE activado puede coincidir el Common Name o el Subject Alternative Name. Si se ingresa una dirección IP en el firewall pero el certificado solo contiene un nombre DNS, o si un certificado solo coincide mediante SAN, la conexión puede fallar según el modo. Para destinos TLS Syslog productivos conviene planificar un FQDN estable, un certificado de servidor adecuado y un proceso documentado de renovación de certificados.

Al mismo tiempo, el sistema objetivo debe comprender realmente el procedimiento elegido. Algunas integraciones de SIEM requieren un recopilador local y no admiten directamente el firewall Secure log transmission. Entonces, la mejor solución suele ser: el firewall envía internamente al recopilador, y el recopilador cifra aún más en la nube o plataforma SOC. Esta arquitectura debe incluirse en el documento operativo; de lo contrario, se asumirá erróneamente que todos los tramos de la ruta están cifrados.

Seleccionar tipos de registro

Después de agregar el servidor Syslog, el trabajo no ha terminado. Debe especificar en System services > Log settings qué tipos de registros se envían a este destino.

Importante: Una regla de firewall solo crea registros de tráfico significativos si Log firewall traffic está activado en la regla. Para SSL/TLS Inspection también debe estar activo Log connections en la regla de inspección adecuada. La selección de registros en Log settings determina después si estos logs se envían localmente, a Sophos Central o a servidores Syslog.

Tipos de registros típicos para un SIEM:

• Cortafuegos: conexiones permitidas y rechazadas, coincidencia de reglas, eventos DoS
• IPS: Ataques detectados o bloqueados
• Filtrado web/contenido: Tráfico web, categorías, eventos de políticas web
• Inspección SSL/TLS: Decisiones y errores de inspección de TLS
• Protección del servidor web: Eventos WAF para servicios publicados
• Autenticación/Eventos: Eventos de administrador, usuario y sistema
• VPN: Acceso remoto y eventos de sitio a sitio VPN
• Respuesta activa a amenazas: Visitas de fuentes de amenazas MDR, NDR Essentials, Sophos X-Ops y fuentes de amenazas de terceros
• Estado del sistema: CPU, memoria, usuarios, interfaces y particiones

Si se van a evaluar DoS o eventos de suplantación de identidad, también se debe probar el refuerzo técnico en sí. El proceso se encuentra en Sophos Firewall Verificar configuración de Spoof Protection y DoS.

Si se utilizan fuentes de amenazas de terceros, NDR y Active Threat Response o WAF, el SIEM debe evaluar específicamente estos eventos. No basta con enviar registros. Requiere consultas de búsqueda claras, alarmas, responsabilidades y ajuste contra falsas alarmas.

Comprobar conscientemente los campos del parser

Los eventos Syslog de Sophos contienen campos distintos según el tipo de log. Para parsers y dashboards son especialmente relevantes log_id, log_type, log_component, log_subtype, severity, status, device_name, device_model, device_serial_id, fw_rule_id, fw_rule_name, nat_rule_id, src_ip, dst_ip, user_name y las marcas de tiempo.

log_id es más que un número aleatorio. La ID se compone de tipo de log, componente, subtipo, gravedad y Message ID. Esto ayuda cuando un SIEM debe crear reglas de detección, dashboards o normalizaciones estables en lugar de buscar solo texto libre.

Para la aceptación no basta con comprobar si llegan datos raw. Lo decisivo es si los campos llegan realmente como campos separados al SIEM. Si fw_rule_id o nat_rule_id quedan solo dentro del texto raw, las búsquedas y alertas posteriores suelen funcionar peor de lo esperado.

Un evento de firewall anonimizado puede verse así en formato raw:

date=2026-07-01 time=14:23:11 log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" status="Allow" device_name="SFOS-XGS" device_serial_id="C00000000000000" 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" dst_port="443" user_name="AVANET\\test.user"

El ejemplo no sustituye a la referencia oficial de campos. Muestra qué información debería ser visible como campos separados durante la prueba del parser.

Conjunto inicial típico para el piloto SIEM

Para un piloto, un conjunto inicial pequeño y deliberado es mejor que una activación completa sin evaluación.

• Inicio: Cortafuegos, Eventos, VPN. Verifique el nivel de ruido, los eventos de reglas, el administrador y la visibilidad de VPN
• Seguridad: IPS, Web, Protección de servidores web, Respuesta activa a amenazas. Validar casos de uso de seguridad y campos del analizador
• Operación: Estado del sistema, DHCP, DNS, autenticación. Agregar contexto operativo y de identidad
• Ajuste fino: módulos adicionales según sea necesario. activar sólo si hay un propósito de búsqueda, alarma o auditoría

Después de cada fase se debe comprobar si el SIEM reconoce los campos correctamente y si realmente alguien está utilizando los nuevos eventos. Los tipos de registros no verificados no son valor agregado, solo volumen adicional.

Trampas de visibilidad importantes

En los proyectos Syslog muchos fallos no surgen en el transporte, pero sí de antemano: el firewall no genera ningún evento esperado, el tipo de log 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 el registro por sí mismas. En System services > Log settings puede elegir si estos registros se envían localmente, en Sophos Central o al servidor Syslog. Si una regla de firewall no tiene Registrar tráfico de firewall, el servidor Syslog no puede mostrar un historial completo de tráfico de 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 vea menos eventos de filtrado de contenido o web en el SIEM de lo esperado.

Supresión de registros

Sophos Firewall puede suprimir varias entradas de registro consecutivas idénticas. Esto ahorra memoria y procesamiento, pero puede resultar confuso en los casos de uso del SIEM cuando es necesario evaluar los valores de conteo, la frecuencia o el comportamiento de ráfaga. La función funciona en servidores Log Viewer, Sophos Central y externos Syslog.

Por lo tanto, antes de realizar una implementación productiva del SIEM, debe determinar:

• ¿Qué eventos del firewall se pueden suprimir?
• ¿Qué reglas de detección necesita cada conexión individual?
• ¿El SIEM funciona con valores contados o sólo con eventos individuales?
• ¿Cómo se documenta que la supresión de registros está activa?

Active Threat Response

Los registros de Active Threat Response son particularmente útiles cuando se utilizan Threat Feeds, NDR Essentials o feeds externos. Sophos diferencia entre diferentes tipos de concordancia, por ejemplo, visitas de destino para el tráfico saliente y visitas de origen para el tráfico entrante.

Importante: La coincidencia de origen remoto para el tráfico entrante no se activa automáticamente. Si se va a monitorear el tráfico WAF o DNAT en comparación con las fuentes de amenazas, esta visibilidad debe verificarse conscientemente. De lo contrario, se perderán los hits 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 punto de acceso y SSID deben enviarse específicamente a Sophos Central o Syslog y examinarse por separado en el sistema de destino si los eventos inalámbricos son relevantes para las operaciones, el soporte o el cumplimiento.

Entornos con múltiples firewalls

En entornos con varios firewalls, cada evento debe asignarse de forma única a un dispositivo. El nombre de host, número de serie, el modelo y otros campos son relevantes para esto. Dependiendo del tipo de registro, campos como device_name, device_model y device_serial_id pueden aparecer en los eventos Syslog. El SIEM no sólo debería almacenar estos campos, sino también hacerlos utilizables para filtros, paneles y alarmas.

Recomendaciones prácticas:

• Establecer el nombre de host del firewall de forma limpia.
• Considere la ubicación o el rol en el nombre de host.
• Definir una instalación uniforme o estrategia de etiquetado.
• En el SIEM verifique si los eventos se pueden filtrar por firewall, ubicación y clúster.
• Distinga claramente entre clústeres HA y firewalls independientes.

Esta asignación es particularmente importante después de una sustitución o restauración de hardware. De lo contrario, los eventos en el SIEM parecen sistemas nuevos o duplicados.

Para los clústeres HA, también se debe probar cómo aparecen los eventos después de una conmutación por error. Lo que importa es si las operaciones y el SOC continúan reconociendo la misma ubicación o si de repente aparece un nombre de host, un número de serie o un activo nuevo diferente en el SIEM.

Configuración de prueba

Después de guardar, se debe probar deliberadamente la conexión. Un sistema de destino ecológico por sí solo no demuestra que lleguen los registros correctos con los campos correctos.

Puntos de prueba:

1. Abra System services > Log settings en el firewall.
2. Asegúrese de que el servidor Syslog esté visible.
3. Para un tipo de registro seguro, active Syslog como prueba.
4. Desencadene una acción definida, por ejemplo, una regla de firewall registrada o un acceso de prueba.
5. Verifique en el sistema de destino si llega el evento.
6. Verifique campos como hora, nombre de host, device_name, origen, destino, Rule ID, acción y tipo de registro.
7. Verifique la marca de tiempo y la zona horaria en el SIEM.
8. En eventos de firewall, comprobar si fw_rule_id, fw_rule_name, nat_rule_id, src_ip, dst_ip, status y log_occurrence son buscables por separado.

Para probar reglas, es útil Probar regla de firewall con Log Viewer, Policy Test y Packet Capture. Si no se produce ningún evento, la causa no suele ser el transporte Syslog, sino el registro desactivado como regla general o el tipo de registro incorrecto.

Eventos de prueba significativos

Una buena prueba de aceptación no crea un registro cualquiera, sino exactamente los eventos que se buscarán más adelante.

• La regla de prueba registrada permite una conexión: Fuente, Destino, Servicio, Acción, Rule ID y Firewall claramente visibles
• Golpes de regla de caída definidos: El evento de caída aparece con la dirección y hora correctas
• Usuario VPN se conecta y desconecta: Se detecta usuario, tipo de túnel, hora y firewall
• Evento de prueba de política web o IPS: El analizador resuelve correctamente el tipo de registro, la categoría o la firma
• ATR o prueba de alimentación de amenazas, si está disponible: El hit aparece en el caso de uso esperado y no genera una falsa alarma
• Prueba de conmutación por error o restauración de HA si está prevista: Los eventos permanecen asignados de manera rastreable a la ubicación, el clúster y el dispositivo. Para obtener reglas SIEM productivas, también debe documentar un resultado de prueba negativo: ¿Qué sucede si no ocurre un evento esperado? Sólo entonces será evidente más adelante si un analizador, recopilador o tipo de registro ha fallado silenciosamente.

Operaciones y seguimiento

Una conexión Syslog no es un problema único. El funcionamiento debe ser supervisado y controlado periódicamente.

Al menos estos puntos deben documentarse:

• ¿Quién es el propietario de la plataforma de registro?
• ¿Qué cortafuegos envían registros?
• ¿Qué tipos de registros se envían?
• ¿Qué período de retención se aplica?
• ¿Qué analizadores, paneles y alarmas están adjuntos?
• ¿Cómo reconoces que ya no llegan troncos?
• ¿Cómo se verifican los cambios de formato después de las actualizaciones de firmware?
• ¿Cómo se monitorean los vencimientos de certificados, las actualizaciones del recopilador y los cambios del analizador?
• ¿Quién evalúa los falsos positivos y ajusta las reglas del SIEM?

Después de las actualizaciones de firmware, se deben realizar comprobaciones aleatorias para ver si los eventos importantes todavía se están analizando correctamente. Esto es especialmente cierto para las reglas productivas SIEM que se basan en nombres de campos, tipos de registros o formatos específicos.

Detectar una pérdida silenciosa de logs

Para la operación debe existir un indicador simple de fallo:

• Por firewall: definir el número mínimo esperado de eventos por período, por ejemplo eventos Firewall o System.
• Por tipo de log importante: comprobar si Firewall, VPN, Web, IPS o Active threat response siguen generando eventos con regularidad.
• Por parser: supervisar si campos centrales como device_name, Source, Destination, Action y Rule ID siguen rellenándose.
• Por collector: detectar si un collector local deja de aceptar datos o ya no los reenvía.
• Después de cambios: usar actualización de firmware, actualización de parser, cambio de certificado, restore de firewall y failover HA como motivo para repetir la prueba de aceptación.

Una buena operación SIEM no alerta solo sobre eventos sospechosos, sino también sobre eventos que faltan. Si un firewall productivo deja de enviar logs de repente, eso también es un evento operativo.

Solución de problemas

No llegan registros al SIEM

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

Si se puede acceder al servidor Syslog a través de un túnel VPN o una red de administración separada, verifique también la ruta, la política SD-WAN, la NAT de origen y el firewall contrario. Desde la perspectiva de Sophos Firewall, Syslog es tráfico saliente normal; en realidad debe llegar al coleccionista.

Sólo faltan ciertos eventos

Entonces, el módulo o el registro de reglas a menudo no están activos. Para las reglas de firewall, se debe configurar Registrar tráfico de firewall. Para eventos web o SSL/TLS, también se debe generar la política adecuada o el registro de reglas de inspección.

Los registros llegan pero se analizan incorrectamente

Verifique el formato, la versión del analizador y la versión del firmware. Si se cambia entre Protocolo syslog estándar y Formato estándar del dispositivo (heredado), el analizador SIEM debe coincidir.

TLS-Syslog no se conecta

Verifique FQDN, certificado, Common Name, Subject Alternative Name, modo LINCE, cadena de certificados y puerto. En la mayoría de entornos sin LINCE, el Common Name debe coincidir con el dominio configurado; un nombre que solo coincide en el SAN no basta. Si el firewall espera un nombre DNS, pero solo se ingresó al servidor Syslog a través de la dirección IP, la verificación del certificado también puede fallar. Además, verifique si el sistema de destino realmente acepta TLS en el puerto configurado.

Si un proveedor de SIEM no admite directamente Secure log transmission, no se debe intentar rescatar el analizador con formatos aleatorios. Es mejor tener un colector local compatible, un diseño de transporte diferente o una decisión clara sobre qué ruta interna permanecerá sin cifrar.

Las marcas de tiempo son incorrectas

Verifique NTP en el firewall, zona horaria en SIEM y lógica del analizador. Los tiempos incorrectos hacen que la correlación con los registros de identidad, servidor o punto final no sea confiable.

Demasiados registros o demasiado ruido

No desactives todo inmediatamente. Primero verifique qué tipos de registros son realmente necesarios, qué reglas registran innecesariamente y si tiene sentido la supresión de registros. Luego reduzca específicamente.

Lista de verificación

• Se puede acceder al servidor Syslog o SIEM.
• El transporte, el puerto y el cifrado están arreglados.
• Para TLS: se verifican FQDN, certificado, cadena de confianza y renovación.
• El formato coincide con el analizador SIEM.
• La estrategia de la instalación está documentada.
• Los tipos de registros relevantes se activan en System services > Log settings.
• Las reglas de firewall importantes tienen Registrar tráfico de firewall activo.
• Las reglas de inspección SSL/TLS generan sus propios registros si es necesario.
• La supresión de registros se evalúa y documenta conscientemente.
• Los tipos de coincidencias de respuesta a amenazas activas coinciden con los casos de uso de SIEM.
• Se ha aclarado la protección de datos, el plazo de acceso y conservación.
• Se han validado el firewall piloto, los eventos de prueba y el analizador SIEM.
• Los eventos de prueba llegan al sistema de destino.
• Campos como Nombre de host, device_name, Fuente, Destino, Acción y Rule ID se reconocen correctamente.
• Campos importantes del parser como log_id, log_type, log_component, fw_rule_id, nat_rule_id, src_ip, dst_ip, user_name, severity y status son buscables por separado.
• HA, el escenario de restauración o reemplazo de hardware se incluye en el modelo de mapeo SIEM si es necesario.
• La marca de tiempo y la zona horaria son correctas.
• La monitorización detecta cuando no llegan más registros.
• La función del analizador se verifica después de las actualizaciones del firmware.

Preguntas frecuentes