WAZUH - SOPHOS

 

WAZUH - AMBASSADORS

🛡️🔥 Integración de Sophos Firewall con Wazuh SIEM: visibilidad centralizada de red

En esta práctica se integra un Sophos Firewall (SFOS) con Wazuh SIEM, de forma que los eventos de red que hasta ahora solo vivían en la consola del propio firewall (conexiones permitidas y denegadas, tráfico inválido, alertas de IPS...) pasan a analizarse, correlacionarse y visualizarse de forma centralizada junto con el resto de la telemetría de seguridad de la organización.

El escenario parte de una situación muy habitual: un firewall perimetral que genera logs valiosos, pero que solo se consultan de forma manual y aislada cuando surge un problema puntual. En lugar de depender de revisar la consola del firewall caso por caso, se configura el envío de sus logs por syslog hacia Wazuh, donde se decodifican, se evalúan contra un conjunto de reglas propio y generan alertas visibles en un único panel, junto con la telemetría de servidores, endpoints y otros dispositivos ya integrados.

🧰 Tecnologías empleadas

Sophos Firewall (SFOS) Es la fuente de los eventos de red de esta práctica: registra qué conexiones se permiten y cuáles se deniegan, detecta tráfico inválido o malformado, aplica políticas de filtrado de contenido y genera alertas de su motor de prevención de intrusiones (IPS). Toda esa información, por defecto, queda confinada a su propia consola de administración.

Wazuh Wazuh es la plataforma SIEM que centraliza el análisis. Se compone de tres piezas: el manager, que recibe y procesa los eventos; el indexer, que los almacena de forma estructurada; y el dashboard, donde se consultan y visualizan las alertas generadas. En esta práctica, el manager recibe los logs del firewall directamente por syslog, sin necesidad de instalar ningún agente adicional sobre el propio Sophos.

Syslog Es el protocolo de transporte que conecta ambas piezas: el firewall envía cada evento como un mensaje de syslog hacia una IP y puerto concretos, y Wazuh escucha en ese puerto para recibirlos en tiempo real.

Decoders y reglas personalizadas El formato de log que utiliza Sophos no es uno de los que Wazuh reconoce de fábrica, así que es necesario construir un decoder propio que extraiga los campos relevantes de cada mensaje (IP de origen y destino, puerto, protocolo, tipo de evento, severidad...) y un conjunto de reglas que decida, a partir de esos campos, qué eventos deben generar una alerta y con qué nivel de prioridad.

Ubuntu Server El manager de Wazuh se despliega sobre Ubuntu Server, con conectividad de red hacia el segmento donde se encuentra el firewall.

🎯 Objetivos de la práctica

El objetivo principal es dejar de depender de la consulta manual y puntual de los logs del firewall, y pasar a un modelo donde esos eventos se analizan de forma continua y automática, con alertas visibles en el mismo panel que el resto de la infraestructura de seguridad.

De forma más concreta, se busca configurar el envío de logs desde Sophos hacia Wazuh mediante syslog, seleccionar qué categorías de evento merece la pena enviar, construir un decoder capaz de interpretar el formato propio del fabricante, definir reglas que clasifiquen los eventos por severidad y tipo, y validar todo el recorrido, desde que se produce una conexión denegada en el firewall hasta que la alerta correspondiente aparece en el dashboard.

🧩 Desarrollo de la práctica

Configuración del servidor de syslog en Sophos El primer paso consiste en indicarle al firewall hacia dónde debe enviar sus logs: la dirección del manager de Wazuh, el puerto de escucha y el formato del mensaje. Sophos ofrece distintos formatos de log; elegir el correcto es imprescindible, ya que el decoder que se construye más adelante depende directamente de esa estructura.

Selección de las categorías de log No todos los tipos de evento que puede registrar un firewall aportan el mismo valor de forma continua. Antes de saturar el SIEM con tráfico de bajo interés, se decide qué categorías se envían: las reglas de firewall y el tráfico inválido resultan imprescindibles, mientras que otras categorías más ruidosas, como los mensajes de estado internos del propio dispositivo, se dejan fuera o se filtran más adelante.

Activación del registro por regla Además de la configuración global de logs, cada regla de firewall necesita tener activado su propio registro de tráfico de forma individual. Es un control independiente que conviene revisar, ya que sin él una regla puede estar bloqueando tráfico sin que ese bloqueo llegue a registrarse en ningún sitio.

Configuración del manager de Wazuh para recibir syslog En el lado de Wazuh se define un listener de syslog: puerto de escucha, protocolo e IP de origen permitida. A partir de ese momento, el manager empieza a recibir los mensajes que envía el firewall, aunque todavía no sabe interpretarlos.

Construcción del decoder personalizado El formato de log de Sophos se estructura como una serie de pares campo="valor". El decoder se construye para reconocer esa estructura y extraer los campos que interesan: IP y puerto de origen y destino, tipo de componente que generó el evento, si la conexión fue permitida o denegada, y la severidad reportada por el propio firewall.

Definición de las reglas de alerta Con los campos ya extraídos, se definen las reglas que deciden qué hacer con cada evento: una conexión denegada aislada no tiene la misma prioridad que múltiples intentos denegados desde el mismo origen en pocos minutos, ni que un evento marcado como crítico por el propio firewall. Cada caso recibe un nivel de severidad distinto dentro de Wazuh.

Verificación y ajuste de ruido Antes de dar por completada la integración, se valida con una herramienta de prueba que el decoder interpreta correctamente un log real y que las reglas se disparan como se espera. También se revisa qué proporción de los eventos recibidos son realmente relevantes, ajustando tanto la configuración del propio firewall como las reglas de Wazuh para reducir el ruido de fondo sin perder eventos accionables.

🔍 ¿Por qué es importante esta práctica?

Un firewall perimetral genera, día a día, una cantidad considerable de información sobre lo que ocurre en el borde de la red: qué se intenta bloquear, desde dónde, con qué frecuencia. Si esa información solo se consulta de forma manual y aislada, buena parte de su valor se pierde, porque nadie está mirando la consola en el momento exacto en que ocurre algo relevante.

Integrar esos logs en un SIEM permite correlacionar eventos de red con el resto de la telemetría de la organización, mantener un histórico consultable, y construir alertas automáticas que no dependen de que alguien esté revisando la consola del firewall en ese instante. También sienta las bases para ampliar la cobertura a otros dispositivos de red con el mismo enfoque.

✅ Resultados esperados

Al finalizar la práctica, los eventos del Sophos Firewall llegan de forma continua al manager de Wazuh, se decodifican correctamente y generan alertas clasificadas por severidad en el dashboard. Las conexiones denegadas, el tráfico inválido y los eventos críticos quedan visibles junto con el resto de la telemetría de seguridad ya integrada, sin necesidad de consultar la consola del firewall de forma manual para detectarlos.

🏢 Propuesta empresarial

Clockwork Computer necesita dejar de depender de la revisión manual de los logs de su firewall perimetral. Hasta ahora, esos eventos solo se consultaban de forma puntual cuando surgía una incidencia, sin ningún mecanismo de alerta automática ni de correlación con el resto de la infraestructura de seguridad.

El departamento de IT ha decidido integrar el Sophos Firewall existente con la plataforma Wazuh SIEM ya desplegada, de forma que los eventos de red pasen a analizarse de forma continua junto con el resto de la telemetría de la organización.

📌 Escenario propuesto

Clockwork Computer dispone de un Sophos Firewall en producción y de un servidor Wazuh ya operativo con otras fuentes de datos integradas. El objetivo es sumar el firewall como una fuente más, sin necesidad de instalar ningún agente adicional sobre el propio dispositivo.

🎯 Requisitos técnicos solicitados por la empresa

La empresa solicita implementar las siguientes tareas:

Configurar en el Sophos Firewall el envío de logs por syslog hacia el servidor Wazuh. Seleccionar las categorías de log que aportan valor real, evitando saturar el SIEM con eventos de bajo interés. Activar el registro de tráfico en las reglas de firewall relevantes. Configurar en Wazuh la recepción de los mensajes de syslog procedentes del firewall. Construir un decoder capaz de interpretar el formato de log propio de Sophos. Definir reglas que clasifiquen los eventos por severidad, incluyendo detección de múltiples intentos denegados desde un mismo origen. Verificar de extremo a extremo que un evento real del firewall genera la alerta correspondiente en el dashboard de Wazuh. Ajustar la configuración para reducir el ruido de fondo sin perder eventos accionables.

🔐 Justificación técnica y de seguridad

Clockwork Computer necesita ampliar su capacidad de detección sin añadir infraestructura adicional ni depender de la revisión manual de una consola más. Integrar el firewall con el SIEM ya existente permite aprovechar el trabajo de correlación, almacenamiento histórico y visualización que la plataforma ya ofrece para otras fuentes.

El uso de syslog como mecanismo de transporte evita instalar cualquier componente adicional sobre el propio firewall, y la construcción de un decoder y reglas específicas garantiza que la información se interprete de forma estructurada, en lugar de tratarse como texto plano sin clasificar. Filtrar de forma deliberada qué categorías de log se envían, y ajustar la severidad de los eventos menos relevantes, evita que el volumen de ruido diluya las alertas realmente accionables.

🧪 Validación esperada

Al finalizar la práctica, Clockwork Computer deberá comprobar que un evento real del firewall, como una conexión denegada, se decodifica correctamente en Wazuh y genera una alerta con la información esperada (origen, destino, tipo de evento y severidad), visible en el dashboard junto con el resto de la telemetría de seguridad ya integrada.

✅ Resultado empresarial esperado

Como resultado final, Clockwork Computer dispondrá de una visibilidad centralizada sobre la actividad de su firewall perimetral, integrada en la misma plataforma SIEM que el resto de su infraestructura. La detección de conexiones denegadas, tráfico inválido y eventos críticos dejará de depender de la revisión manual de la consola del firewall, con la posibilidad de ampliar en el futuro esta misma integración a otros dispositivos de red del mismo fabricante o de fabricantes distintos.

Esta práctica representa un caso real de consolidación de la visibilidad de seguridad, evaluando la capacidad de integrar una fuente de red externa en una plataforma SIEM existente, interpretando su formato propio y ajustando el volumen de alertas a un nivel operativamente útil.

🔗 Enlaces de interés

      DOCUMENTACIÓN

⚙️ Estructura de red

🛡️🔥 Integrating Sophos Firewall with Wazuh SIEM: centralized network visibility

In this exercise, a Sophos Firewall (SFOS) is integrated with Wazuh SIEM, so that the network events that used to live only in the firewall's own console — allowed and denied connections, invalid traffic, IPS alerts — are now analyzed, correlated, and visualized centrally alongside the rest of the organization's security telemetry.

The scenario starts from a very common situation: a perimeter firewall that generates valuable logs, but that are only checked manually and in isolation whenever a specific issue comes up. Instead of relying on checking the firewall console case by case, its logs are forwarded via syslog to Wazuh, where they are decoded, evaluated against a custom set of rules, and turned into alerts visible in a single dashboard, alongside telemetry from servers, endpoints, and other devices already integrated.

🧰 Technologies used

Sophos Firewall (SFOS) This is the source of the network events for this exercise: it logs which connections are allowed and which are denied, detects invalid or malformed traffic, applies content filtering policies, and generates alerts from its intrusion prevention engine (IPS). By default, all of that information stays confined to its own management console.

Wazuh Wazuh is the SIEM platform that centralizes the analysis. It's made up of three components: the manager, which receives and processes events; the indexer, which stores them in a structured way; and the dashboard, where alerts are queried and visualized. In this exercise, the manager receives the firewall's logs directly via syslog, with no need to install any additional agent on the Sophos device itself.

Syslog This is the transport protocol connecting both pieces: the firewall sends each event as a syslog message to a specific IP and port, and Wazuh listens on that port to receive them in real time.

Custom decoders and rules The log format used by Sophos isn't one Wazuh recognizes out of the box, so a custom decoder has to be built to extract the relevant fields from each message (source and destination IP, port, protocol, event type, severity...), along with a set of rules that decide, based on those fields, which events should trigger an alert and at what priority level.

Ubuntu Server The Wazuh manager is deployed on Ubuntu Server, with network connectivity to the segment where the firewall is located.

🎯 Objectives of the exercise

The main objective is to move away from manually and occasionally checking the firewall's logs, and toward a model where those events are analyzed continuously and automatically, with alerts visible in the same dashboard as the rest of the security infrastructure.

More specifically, the goal is to configure log forwarding from Sophos to Wazuh via syslog, select which event categories are actually worth sending, build a decoder capable of interpreting the vendor's own format, define rules that classify events by severity and type, and validate the full path, from the moment a connection is denied on the firewall to the moment the corresponding alert shows up on the dashboard.

🧩 How the exercise unfolds

Configuring the syslog server on Sophos The first step is telling the firewall where to send its logs: the Wazuh manager's address, the listening port, and the message format. Sophos offers several log formats; picking the right one is essential, since the decoder built later depends directly on that structure.

Selecting log categories Not every type of event a firewall can log is equally valuable on an ongoing basis. Before flooding the SIEM with low-value traffic, a decision is made about which categories get forwarded: firewall rules and invalid traffic are essential, while noisier categories, such as the device's own internal status messages, are left out or filtered further down the line.

Enabling logging per rule On top of the global log configuration, each firewall rule needs to have its own traffic logging enabled individually. It's an independent setting worth double-checking, since without it a rule can be blocking traffic without that block ever being logged anywhere.

Configuring the Wazuh manager to receive syslog On the Wazuh side, a syslog listener is defined: listening port, protocol, and allowed source IP. From that point on, the manager starts receiving the messages sent by the firewall, although it doesn't yet know how to interpret them.

Building the custom decoder Sophos's log format is structured as a series of field="value" pairs. The decoder is built to recognize that structure and extract the fields that matter: source and destination IP and port, which component generated the event, whether the connection was allowed or denied, and the severity reported by the firewall itself.

Defining the alert rules With the fields already extracted, rules are defined to decide what to do with each event: an isolated denied connection doesn't carry the same priority as multiple denied attempts from the same source within a few minutes, nor the same as an event flagged as critical by the firewall itself. Each case gets a different severity level within Wazuh.

Verification and noise tuning Before considering the integration complete, a testing tool is used to confirm that the decoder correctly interprets a real log line and that the rules fire as expected. The proportion of received events that are actually relevant is also reviewed, adjusting both the firewall's own configuration and the Wazuh rules to cut background noise without losing actionable events.

🔍 Why does this exercise matter?

A perimeter firewall generates, day after day, a considerable amount of information about what's happening at the edge of the network: what's being blocked, from where, how often. If that information is only checked manually and in isolation, much of its value is lost, because no one is watching the console at the exact moment something relevant happens.

Integrating those logs into a SIEM makes it possible to correlate network events with the rest of the organization's telemetry, keep a searchable history, and build automatic alerts that don't depend on someone reviewing the firewall console at that particular moment. It also lays the groundwork for extending this same approach to other network devices later on.

✅ Expected results

By the end of the exercise, Sophos Firewall events arrive continuously at the Wazuh manager, get decoded correctly, and generate alerts classified by severity on the dashboard. Denied connections, invalid traffic, and critical events become visible alongside the rest of the security telemetry already integrated, with no need to manually check the firewall console to spot them.

🏢 Business proposal

Clockwork Computer needs to stop relying on manually reviewing the logs from its perimeter firewall. Until now, those events were only checked occasionally whenever an incident came up, with no automatic alerting mechanism and no correlation with the rest of the security infrastructure.

The IT department has decided to integrate the existing Sophos Firewall with the Wazuh SIEM platform already deployed, so that network events start being analyzed continuously alongside the rest of the organization's telemetry.

📌 Proposed scenario

Clockwork Computer has a Sophos Firewall in production and a Wazuh server already operational with other data sources integrated. The goal is to add the firewall as one more source, without needing to install any additional agent on the device itself.

🎯 Technical requirements requested by the company

The company requests the following tasks:

Configure the Sophos Firewall to send logs via syslog to the Wazuh server. Select the log categories that provide real value, avoiding flooding the SIEM with low-interest events. Enable traffic logging on the relevant firewall rules. Configure Wazuh to receive syslog messages from the firewall. Build a decoder capable of interpreting Sophos's own log format. Define rules that classify events by severity, including detection of multiple denied attempts from the same source. Verify end to end that a real firewall event generates the corresponding alert on the Wazuh dashboard. Adjust the configuration to reduce background noise without losing actionable events.

🔐 Technical and security rationale

Clockwork Computer needs to expand its detection capability without adding extra infrastructure or relying on manually reviewing yet another console. Integrating the firewall with the existing SIEM makes it possible to take advantage of the correlation, historical storage, and visualization work the platform already does for other sources.

Using syslog as the transport mechanism avoids installing any additional component on the firewall itself, and building a specific decoder and rule set ensures the information is interpreted in a structured way, rather than treated as unclassified plain text. Deliberately filtering which log categories get sent, and adjusting the severity of less relevant events, prevents the volume of noise from diluting the alerts that are actually actionable.

🧪 Expected validation

By the end of the exercise, Clockwork Computer should confirm that a real firewall event, such as a denied connection, is correctly decoded in Wazuh and generates an alert with the expected information (source, destination, event type, and severity), visible on the dashboard alongside the rest of the security telemetry already integrated.

✅ Expected business outcome

As a final result, Clockwork Computer will have centralized visibility over its perimeter firewall's activity, integrated into the same SIEM platform as the rest of its infrastructure. Detecting denied connections, invalid traffic, and critical events will no longer depend on manually reviewing the firewall console, with the possibility of extending this same integration to other network devices, from the same vendor or different ones, in the future.

This exercise represents a real-world case of security visibility consolidation, testing the ability to integrate an external network source into an existing SIEM platform, interpret its proprietary format, and tune the volume of alerts down to an operationally useful level.