Securitizando tu red: Integrando PiHole y SQUID a Wazuh (Parte 6)

Escrito por Daniel Olivares

Introducción

Continuando con nuestra serie de artículos para mejorar la seguridad de nuestras PYMES y Hogar, hoy presentamos “Securitizando tu red: Integrando PiHole y SQUID a Wazuh”. Si no has visto los contenidos anteriores, acá te dejamos la lista completa:

Si has seguido los pasos descritos en nuestros artículos, la red que estamos armando debería verse de la siguiente manera:

En resumen tenemos:

Un servidor PiHole (DNS)
Un servidor SQUID (Proxy)
Un cluster de Wazuh como SIEM con acceso web HTTPS para la visualización de la data enviada.
- Wazuh Indexer (20.20.20.10)
- Wazuh Server (20.20.20.11)
- Wazuh Dashboard (20.20.20.12)
Equipos de trabajo y servidores con el agente Wazuh instalado, pero enviando logs básicos.
- Una máquina Windows con SYSMON instalado, pero solo enviando logs de sistema.
- Una máquina Linux con AuditD instalado, pero solo enviando logs de sistema.

En este artículo nos enfocaremos en la configuración necesaria para que se envíen los logs de los servidores de aplicación que configuramos en artículos pasados: PiHole y SQUID.

Además, abordaremos dos temas extra:

La creación del decoder necesario para que Wazuh pueda interpretar correctamente los datos enviados.
La creación de reglas para identificar los eventos de interés.

Para estos dos últimos puntos utilizaremos como ejemplo los logs enviados por PiHole, dado que Wazuh no tiene un decoder para sus eventos.

Integrando log de servidores aplicativos: Pihole DNS

En este documento no abordaremos la configuración del servidor DNS, dado que fue explicado en detalle en el artículo Securitizando tu red: Pi-Hole (Parte 1) – FINSIN

Comenzaremos con la configuración necesaria para que se envíen los logs aplicativos de PiHole. Para esto, continuaremos desde el último artículo donde el servidor quedó con el agente Wazuh instalado.

Configurando el envío de log DNS

Para que los logs de consultas DNS se envíen a Wazuh, tendremos que editar el archivo de configuración ubicado en el servidor de PiHole en la siguiente ruta “/var/ossec/etc/ossec.conf”, para que incluya los eventos DNS registrados en el archivo “/var/log/pihole/pihole.log”.

Esto lo haremos agregando a la sección “localfile” del archivo “ossec.conf”, el siguiente texto:

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/pihole/pihole.log</location>
  </localfile>

La configuración debería verse como la siguiente imagen:

Guardamos el archivo y reiniciamos el agente con el siguiente comando:

$ sudo systemctl restart wazuh-agent

Con esta pequeña configuración, los eventos que registran las consultas DNS en PiHole habrán comenzado a enviarse al SIEM.

Lamentablemente, Wazuh no cuenta con un decodificador (decoder) por defecto para identificar e interpretar (parsear) los eventos enviados, por lo que no será posible visualizarlos en la plataforma todavía. Para solucionar esto debemos crear un decoder propio.

Creando custom decoder “PiHole”

Es bastante fácil crear un decodificador para un evento. Para esto, dentro del servidor que habíamos llamado “Wazuh Server” (20.20.20.11), debemos crear un archivo XML en la ruta “/var/ossec/etc/decoders” y el nombre debe tener un número (SN) y un nombre descriptivo como formato, por ejemplo: “<SN>-<app_name>_ -_decoders.xml”

Es recomendable que el número SN sea un número sobre 1000. Esto debido a que si el SN es igual a otro existente, está el riesgo de que no se ejecute correctamente.

Para este ejemplo el nombre del archivo será “1000-dnsmasq_decoders.xml” y tendrá el siguiente contenido.

<decoder name="dnsmasq">
    <type>syslog</type>
    <prematch>dnsmasq</prematch>
</decoder>

<decoder name="dnsmasq-fields">
    <parent>dnsmasq</parent>
    <regex offset="after_parent">(\S+) (\S+) is (\S+)</regex>
    <order>query_type,query,answer </order>
</decoder>

<decoder name="dnsmasq-fields">
    <parent>dnsmasq</parent>
    <regex offset="after_parent">(\S+) (\S+) from (\S+)</regex>
    <order>query_type,query,srcip</order>
</decoder>

<decoder name="dnsmasq-fields">
    <parent>dnsmasq</parent>
    <regex offset="after_parent">(\S+) (\S+) to (\S+)</regex>
    <order>query_type,query,dstip</order>
</decoder>

Este archivo decoder lo puedes encontrar en el siguiente repositorio de Github wazuh/decoders (github.com)

Para entender esta configuración debemos considerar:

Los decoders utilizan sintaxis XML.
El archivo se lee secuencialmente de arriba hacia abajo.
La búsqueda de patrones se puede realizar por expresiones regulares (regex) dando mayor universalidad. Pero es importante que sepas que existe un decoder para eventos enviados en formato JSON, el cual permite identificar automáticamente los campos (Si tienes la oportunidad de enviar los logs en formato JSON, hazlo).
El decodificador puede tener decodificadores “hijo”.
Si se identifica un patrón regex en un evento, se seguirá evaluando la información después del “match” en busca de decodificadores “hijo”.

En el siguiente enlace podrás encontrar la documentación Decoders Syntax.

Comenzaremos analizando la primera sección del decoder:

<decoder name="dnsmasq">
    <type>syslog</type>
    <prematch>dnsmasq</prematch>
</decoder>

La siguiente tabla detalla los aspectos más importantes del primer elemento:

Elemento	Descripción
decoder	El elemento “decoder” permite crear una sección donde el evento será analizado buscando patrones. Para poder identificarlo, éste contiene el atributo “name” que definirá su nombre, en este caso, “dnsmasq”.
type	Este “text content” indicará el tipo de evento que será evaluado. En este caso,espera recibir eventos en formato “syslog”.
prematch	Este “text content” define la expresión que debe coincidir para aplicar este decoder. En este caso buscará el texto “dnsmasq”.

La siguiente sección contiene la configuración con la que se realizará la identificación y extracción de datos mediante regex.

<decoder name="dnsmasq-fields">
    <parent>dnsmasq</parent>
    <regex offset="after_parent">(\S+) (\S+) is (\S+)</regex>
    <order>query_type,query,answer </order>
</decoder>

A continuación, se detallan los aspectos más importantes del segundo elemento:

Elemento	Descripción
decoder	El elemento “decoder” permite crear una sección donde el evento será analizado buscando patrones. Para poder identificarlo, éste contiene el atributo “name” que definirá su nombre, en este caso, “dnsmasq-fields”
type	Este “text content” indica que es un decoder “hijo” del decoder definido, en este caso, “dnsmasq”.
regex	Este “text content” indica que se utilizará una expresión regular para hacer la búsqueda. Adicionalmente tiene el atributo “after_parent” que buscará inmediatamente el patrón definido despues del match realizado por el decoder padre. En este caso, se buscará el valor cuando se identifique el siguiente patron: ” is “
order	Este “text content” asignará nombre secuencialmente a los valores identificados. En este ejemplo se asignarán los siguientes nombres según el valor: valor1 = query_type valor2 = query valor3 = answer Estos valores se convertirán en el nombre de las columnas que visualizaremos en el módulo “discover” de Wazuh.

Esta misma lógica de extracción e identificación de campos por regex se puede aplicar a cualquier tipo de log que quieras ingestar.

Guardamos y cerramos el archivo, para luego cambiarle los permisos de usuario y asignarle un nuevo propietario. Para esto utilizaremos:

$ chmod 600 1000-dnsmasq_decoder.xml
$ chown wazuh:wazuh 1000-dnsmasq_decoder.xml

Creando custom rule “PiHole”

Ahora que hemos creado el decoder, Wazuh será capaz de parsear los campos, pero no podremos visualizarlos sin antes crear el archivo de reglas que utilice el decoder para identificar y clasificar los eventos.

Es importante mencionar también que en este mismo archivo, configuraremos las reglas de detección de comportamiento anómalo que necesitemos.

Para esto deberemos crear un archivo XML en la ruta “/var/ossec/etc/rules” del servidor Wazuh Server (20.20.20.11) y el nombre del archivo debe estar en formato “-_rules.xml

Para este ejemplo, el nombre del archivo será “1000-dnsmasq_rules.xml” y tendrá el siguiente contenido:

<group name="dns,pihole,">
  <rule id="101000" level="3">
    <decoded_as>dnsmasq</decoded_as>
    <description>DNSMASQ messages grouped.</description>
  </rule>

<rule id="101010" level="3">
     <if_sid>101000</if_sid>
     <field name="query_type">query[A]</field>
     <description>DNSMASQ: Quering type A record </description>
     <group>query_dns</group>
</rule>

<rule id="101015" level="3">
     <if_sid>101000</if_sid>
     <field name="query_type">query[CNAME]</field>
     <description>DNSMASQ: Quering type CNAME record</description>
     <group>query_dns</group>
</rule>

<rule id="101020" level="3">
     <if_sid>101000</if_sid>
     <field name="query_type">query[AAA]</field>
     <description>DNSMASQ: Quering type AAA record</description>
     <group>query_dns</group>
</rule>

<rule id="101025" level="3">
     <if_sid>101000</if_sid>
     <field name="query_type">query[MX]</field>
     <description>DNSMASQ: Quering type MX record</description>
     <group>query_dns</group>
</rule>

<rule id="101030" level="3">
     <if_sid>101000</if_sid>
     <field name="query_type">query[TXT]</field>
     <description>DNSMASQ: Quering type TXT record</description>
     <group>query_dns</group>
</rule>

<rule id="101035" level="3">
     <if_sid>101000</if_sid>
     <field name="query_type">query[PTR]</field>
     <description>DNSMASQ: Quering type PTR record</description>
     <group>query_dns</group>
</rule>

<rule id="101040" level="3">
     <if_sid>101000</if_sid>
     <field name="query_type">query[HTTPS]</field>
     <description>DNSMASQ: Quering type HTTPS record</description>
     <group>query_dns</group>
</rule>

<rule id="101045" level="3">
     <if_sid>101000</if_sid>
     <field name="query_type">cached</field>
     <description>DNSMASQ: Query Cached</description>
     <group>query_dns</group>
</rule>

<rule id="101050" level="3">
     <if_sid>101000</if_sid>
     <field name="query_type">reply</field>
     <description>DNSMASQ: Reply Query</description>
     <group>query_dns</group>
</rule>

<rule id="101055" level="3">
     <if_sid>101000</if_sid>
     <field name="query_type">forwarded</field>
     <description>DNSMASQ: Reply Forwarded</description>
     <group>query_dns</group>
</rule>

<rule id="101060" level="3">
     <if_sid>101000</if_sid>
     <field name="query_type">blocked</field>
     <description>DNSMASQ: Query Blocked</description>
     <group>query_dns</group>
</rule>

</group>

Este archivo de reglas lo puedes encontrar en el siguiente repositorio de Github
wazuh/rules (github.com)

Para entender esta configuración debemos considerar:

Las reglas utilizan sintaxis XML.
El archivo se lee secuencialmente de arriba hacia abajo.
Las reglas pueden tener reglas “hijo”.
El SN de las reglas custom debe estar entre los números 100000 y 120000, dado que fue el rango asignado por el fabricante.
En caso de identificar un patrón en un evento, se seguirá evaluando la información después del “match” en busca de reglas “hijo” que puedan hacer un match más preciso.

En el siguiente enlace podrás encontrar la documentación Rules Syntax.

Comenzaremos analizando la primera sección de la regla:

<group name="dns,pihole,">
  <rule id="101000" level="3">
    <decoded_as>dnsmasq</decoded_as>
    <description>DNSMASQ messages grouped.</description>
  </rule>
</group>

La siguiente tabla detalla los aspectos más importantes del primer elemento:

Elemento	Descripción
group	El elemento “Group” definirá los nombres de grupo que tendrán de base todas las reglas. Esto se realizará utilizando el atributo “name” indicando el nombre de los grupos entre comillas separados por coma. Para este ejemplo las reglas tendrán los grupos “dns” y “pihole”
rule	En este elemento definiremos el ID de la regla y el nivel que tendrá la misma. Utilizaremos el atributo “id” para definir el número de la regla y el atributo “level” para definir la severidad de la alerta. El valor del atributo “level” puede ir de 0 al 16. En este caso, utilizaremos el nivel 3 dado que es el nivel mínimo para que el evento se visualice en la consola.
decoder	El elemento “decoder” permite crear una sección donde el evento será analizado buscando patrones. En este caso, se procesarán los eventos que hayan sido decodificados por el decoder “dnsmasq”.
description	El nombre que recibirá el evento si hace match con la regla.

Continuaremos analizando la configuración de la segunda sección en adelante. Para esto, tendremos como ejemplo la siguiente sección:

<rule id="101010" level="3">
     <if_sid>101000</if_sid>
     <field name="query_type">query[A]</field>
     <description>DNSMASQ: Quering type A record </description>
     <group>query_dns</group>
</rule>

La siguiente tabla detalla los aspectos más importantes desde el segundo elemento:

Elemento	Descripción
rule	En este elemento definiremos el ID de la regla y el nivel que tendrá la misma. Utilizaremos el atributo “id” para definir el número de la regla y el atributo “level” para definir la severidad de la alerta. El valor del atributo “level” puede ir de 0 al 16. En este caso, utilizaremos el nivel 3 dado que es el nivel mínimo para que el evento se visualice en la consola.
if_sid	Este “text content” indica que la regla será evaluada si se identifica un event ID “101000”, lo que lo convertirá en una regla “hijo” de la primera regla.
field	Este “text content” definirá el nombre del campo y el valor que hará match para que esta regla sea gatillada. Para este ejemplo el atributo será “query_type” y buscará cuando el valor sea “query[A]”. Y cuando haga match generará un evento que se llama “DNSMASQ: Quering type A record”.
group	Este “text content” agregará un grupo adicional cuando algún evento haga match. En este caso el grupo agregado será “query_dns”.

Esta misma lógica de identificación de eventos mediante el uso de campos extraídos con el decoder se puede aplicar para cualquier regla de detección que deseemos crear.

Guardamos y cerramos el archivo, para luego cambiarle los permisos de usuario y asignarle un nuevo propietario. Para esto utilizaremos:

$ chmod 660 1000-dnsmasq_rules.xml
$ chown wazuh:wazuh 1000-dnsmasq_rules.xml

Luego reiniciamos el servicio wazuh-server con el siguiente comando:

$ sudo systemctl restart wazuh-manager

Con esto Wazuh ya puede identificar y categorizar los eventos que enviamos según el decoder que se configuró y las reglas que creamos, pero todavía nos falta un paso…

Actualizando el Index Patterns

El siguiente paso será actualizar los “index” de Wazuh, para que se reconozcan los nuevos campos y puedan ser “buscables”. Estos nuevos campos serán los que incluimos en la sección “order” en el decoder.

Para esto, desde la consola web, haremos clic en el botón de “menú” y luego “Stack Management”:

Luego iremos a “Index Patterns” y seleccionaremos el index “wazuh-alert-*”.

Y finalizaremos haciendo clic en el ícono de “Refresh”. Como pueden ver el índex tiene 544 campos originalmente.

Luego del “Refresh” se identifican 564 campos.

Con esto habremos terminado la configuración de un decoder con un set de reglas para eventos de syslog custom y con esto ¡ya hora de ver los eventos desde la interfaz web de Wazuh!

Visualizando los eventos

Para visualizar los eventos que integramos, utilizaremos el módulo “Discover”, donde podremos ver y hacer búsquedas globales de la información que se esté recibiendo.

Para esto haremos clic en el botón de “menú” y luego “Discover”

Luego, para filtrar solo los eventos que utilicen el decoder “dnsmasq”, introduciremos el siguiente filtro en la barra de búsqueda y luego apretamos el botón “>| Update”

decoder.name:dnsmasq

Con esto podremos ver el registro de las consultas DNS registradas en nuestro servidor PiHole.

Pero la visualización no es muy amigable, por lo que elegiremos solo algunos campos para ver. Para este ejemplo utilizaremos los siguientes campos:

Rule.description
Data.srcip
Agent.ip
Data.query_type
Data.query
Data.answer

Los buscaremos utilizando la barra de búsqueda de campos en la barra lateral izquierda:

Luego, nos posicionaremos sobre el campo y haremos clic en el signo “+” para visualizar solo ese campo.

Cuando seleccionemos todos los campos que queremos, se debería ver así:

Con esta configuración ya podremos ver fácilmente cuales consultas DNS realizo cada equipo, registrando también el tipo de consulta y su respuesta.

Integrando log de servidores aplicativos: SQUID Proxy

Continuando, instalaremos y configuraremos el agente Wazuh para enviar los LOG de conexión SQUID a Wazuh.

En este documento no abordaremos la configuración de SQUID como Proxy, dado que fue explicado en detalle en el artículo Securitizando tu red: SQUID (Parte 2) – FINSIN

Configurando el envío de logs SQUID

Para que los logs de consultas DNS se envíen a Wazuh, tendremos que editar el archivo de configuración ubicado en la siguiente ruta “/var/ossec/etc/ossec.conf” del servidor SQUID, para que incluya los eventos DNS registrados en el archivo “/var/log/squid/access.log”.

Esto lo haremos agregando a la sección “localfile” del archivo “ossec.conf”, el siguiente texto:

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/squid/access.log</location>
  </localfile>

La configuración debería verse como la siguiente imagen:

Guardamos el archivo y reiniciamos el agente con el siguiente comando:

$ sudo systemctl restart wazuh-agent

Con esta configuración, los eventos que se registran en el “access.log” de SQUID habrán comenzado a enviarse al SIEM y esta vez Wazuh trae un decodificador y de reglas para los eventos de SQUID, por lo que no será necesario que creemos uno como en el ejemplo anterior.

Si deseas revisarlos estos archivos se encuentran en las siguientes rutas:

Decoder: /var/ossec/ruleset/decoders/0305-squid_decoders.xml
Rules: /var/ossec/ruleset/rules/0275-squid_rules.xml

Tampoco será necesario actualizar el “index patterns” dado que estos ya vienen configurados.

Visualizando los eventos

Para visualizar los eventos que integramos, utilizaremos el módulo “Discover”, en donde podremos ver y hacer búsquedas globales de la información que se esté recibiendo.

Para esto haremos clic en el botón de “menú” y luego “Discover”

Para filtrar solo los eventos de SQUID buscaremos los eventos que utilicen el decoder “squid-accesslog”, utilizando el siguiente filtro en la barra de búsqueda y luego apretamos el botón “>| Update”

decoder.name: squid-accesslog

Con esto podremos ver el registro de los eventos de SQUID según lo configurado en el archivo de reglas que trae Wazuh.

Pero la visualización no es muy amigable, por lo que elegiremos solo algunos campos para ver. Para este ejemplo utilizaremos los siguientes campos:

Rule.description
Data.srcip
Data.url
Data.action

Estos los agregadores como se explicó en la visualización de eventos PiHole y cuando hayamos seleccionado los campos, debería verse de la siguiente manera.

Con esta configuración ya podremos ver fácilmente cuales eventos de SQUID generaron un evento, en este caso vemos las conexiones bloqueadas hacía un sitio.

Consultas básicas

En esta sección queremos que le puedan sacar provecho a los datos que están siendo centralizados en Wazuh, tanto de PiHole como de SQUID, con una serie de consultas (queries) básicas.

Con estas consultas podrán tener una mejor visión de qué es lo que se puede hacer con los datos para que después generen sus propias consultas ad-hoc.

PiHole

SQUID Proxy

Por defecto el archivo de reglas de SQUID solo muestra eventos específicos, asociados a violación de políticas. Pero si queremos visualizar todos los eventos debemos editar el archivo “/var/ossec/ruleset/rules/0275-squid_rules.xml” y aumentar el nivel de la sección con descripción “Squid messages grouped” de “0” a “3” como minimo.

Conclusiones

Con esto habremos terminado la integración de eventos de servidores aplicativos, para que los logs de estos sistemas nos sean de utilidad para cualquier tipo de investigación de una manera mucho más amigable que si tuviéramos que buscar directamente en ellos.

Además, abordamos como crear un decoder personalizado para eventos que no están considerandos hoy en la base de Wazuh y sus respectivas reglas de detección, para así comenzar a generar detección de eventos específicos.

Finalmente, mostramos cómo generar algunas consultas (queries) básicas para visualizar mejor los datos que necesitamos encontrar dentro de los logs de las aplicaciones.

Ahora debemos mejorar y ampliar los eventos que se registran en nuestros sistemas y comenzaremos a abordarlo en el próximo artículo el envío de los logs de SYSMON y AUDITD como parte de los logs de sistema.

Muchas gracias por leer hasta acá, y los esperamos en el siguiente.

Nombre	Búsqueda de consultas por IP
Descripción	Con esta query podrás buscar las consultas realizadas por la “IP” de origen de un equipo.
Query	decoder.name:dnsmasq and data.srcip:<IP_EQUIPO>
Output

Nombre	Búsqueda de consultas por IP
Descripción	Con esta query podrás buscar las consultas realizadas por una IP, mostrando solo las consultas tipo “A” y las respuestas “reply”. En la sección donde se definen los tipos de query puede modificar según lo que requieras.
Query	decoder.name:dnsmasq AND (NOT _exists_:data.srcip OR data.srcip:<IP_EQUIPO>) AND (data.query_type:query[A] OR data.query_type:reply)
Output

Nombre	Búsqueda de consultas realizadas hacía una IP/Dominio
Descripción	Con esta query podrás identificar cuales son los equipos que están consultando por un destino ya sea una URL o un Dominio. Ten en cuenta que, si quieres realizar una búsqueda incluyendo los subdominios, debes anteponer un “” al dominio Ej: data.query:Microsoft.com
Query	decoder.name:dnsmasq and data.query: and data.query_type:query[A]
Output

Nombre	Búsqueda de consultas por IP
Descripción	Con esta query podrás identificar cuales son los equipos que están consultando por un Con esta query podrás buscar los eventos de SQUID por la “IP” de origen de un equipo.
Query	decoder.name:squid-accesslog and data.srcip:<IP_EQUIPO>
Output

Nombre	Búsqueda de consultas por IP y URL/DOMINIO
Descripción	Con esta query podrás buscar los eventos de SQUID por la “IP” de origen de un equipo hacía una URL/DOMINIO. Ten en cuenta que, si quieres realizar una búsqueda incluyendo los subdominios, debes anteponer un “” al dominio: Ej: data.query:Microsoft.com*
Query	decoder.name:squid-accesslog and data.srcip: and data.url:< URL/DOMINIO >
Output

Securitizando tu red: Integrando PiHole y SQUID a Wazuh (Parte 6)

Escrito por Daniel Olivares

Introducción

Integrando log de servidores aplicativos: Pihole DNS

Configurando el envío de log DNS

Creando custom decoder “PiHole”

Creando custom rule “PiHole”

Actualizando el Index Patterns

Visualizando los eventos

Integrando log de servidores aplicativos: SQUID Proxy

Configurando el envío de logs SQUID

Visualizando los eventos

Consultas básicas

PiHole

SQUID Proxy

Conclusiones

Una respuesta a “Securitizando tu red: Integrando PiHole y SQUID a Wazuh (Parte 6)”

Add yours

Deje un comentario Cancelar respuesta

Nombre	Búsqueda de conexiones con resultado diferente a “200”
Descripción	Con esta query podrás buscar las conexiones que tengan como resultado un código diferente a “200” En caso de que necesites filtrar más de un código puedes realizarlo de la siguiente manera: NOT (data.id:200 or data.id:403)
Query	decoder.name:squid-accesslog and data.srcip:<IP_EQUIPO> and NOT data.id:200
Output

Escrito por Daniel Olivares

Introducción

Integrando log de servidores aplicativos: Pihole DNS

Configurando el envío de log DNS

Creando custom decoder “PiHole”

Creando custom rule “PiHole”

Actualizando el Index Patterns

Visualizando los eventos

Integrando log de servidores aplicativos: SQUID Proxy

Configurando el envío de logs SQUID

Visualizando los eventos

Consultas básicas

PiHole

SQUID Proxy

Conclusiones

Compártelo:

Relacionado

Una respuesta a “Securitizando tu red: Integrando PiHole y SQUID a Wazuh (Parte 6)”

Add yours

Deje un comentario Cancelar respuesta