Securitizando tu red: Integrando Sysmon y AuditD a Wazuh (Parte 7)

Escrito por Daniel Olivares

Introducción

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

• Securitizando tu red: Integrando PiHole y SQUID a Wazuh (Parte 6)
• Securitizando tu red: Instalación certificado e instalación de agentes (Parte 5)
• Securitizando tu red: Instalando servidores de Wazuh (Parte 4)
• Securitizando tu red: Sysmon y AuditD (Parte 3)
• Securitizando tu red: SQUID (Parte 2)
• Securitizando tu red: Pi-Hole (Parte 1)

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

• Un cluster de Wazuh como SIEM con acceso web HTTPS para la visualización de la data enviada.
• Servidores (DNS y PROXY) con agente Wazuh instalado y enviando logs de auditoría.
• Equipos de trabajo con el agente Wazuh instalado, pero enviando logs básicos.

Esta vez nos enfocaremos en la configuración necesaria para que las estaciones de trabajo con sistema operativo Windows y Linux envíen logs de auditoría mucho más completos.

A continuación, detallamos los equipos sobre los que trabajaremos en esta oportunidad:

Mejorando los logs enviados

En este artículo no abordaremos la configuración de SYSMON y AuditD, dado que fue explicado en detalle en Securitizando tu red: Sysmon y AuditD (Parte 3) – FINSIN

Comenzaremos configurando el agente Wazuh para que comience a enviar los logs de SYSMON en los equipos Windows y AuditD para los equipos con Linux. Ambos logs son de gran valor dado que entregan información detallada del funcionamiento del equipo, como por ejemplo:

• Creación de procesos
• Ejecuciones de comandos
• Conexiones de red
• Consultas DNS
• Creación/Eliminación de carpetas/archivos

Esto nos dará una mejor visión de lo que sucede en cada equipo y en nuestra red, lo que nos permitirá identificar de mejor manera amenazas o comportamientos anómalos.

Y en caso de que un equipo se encuentre afectado en algún grado, tendremos información de utilidad para realizar el diagnóstico o una investigación forense.

Integrando SYSMON: Actualización de la configuración del equipo

Iniciaremos configurando el agente en ambiente Windows para que comience a enviar los eventos de SYSMON.

Es importante mencionar que esta configuración aplica tanto para estaciones de trabajo como para servidores y en este artículo utilizaremos como ejemplo un equipo con Windows 10 (en este caso, IP: 10.10.10.201).

Para esto, tendremos que modificar la configuración del agente. El archivo de configuración se encuentra en ruta “C:\Program Files (x86)\ossec-agent\ossec.conf”

Para editarlo, lo abriremos con permiso de administrador con tu editor favorito y agregaremos la configuración al final de la sección “Log Analysis”.

  <localfile>
    <location>Microsoft-Windows-Sysmon/Operational</location>
    <log_format>eventchannel</log_format>
  </localfile>

Guardamos el archivo y lo cerramos, luego tendremos que reiniciar el agente. Para esto, abriremos el ejecutable “win32ui.exe” el cual corresponde a la interfaz gráfica del mismo. Si no lo encuentran fácilmente, está en la siguiente ruta: “C:\Archivos de Programa (x86)\ossec-agent\”.

Después, nos dirigiremos a “Manage” y luego haremos clic en “Restart”.

Aparecerá un mensaje confirmando la acción, el cual podremos cerrar sin problemas.

Ahora, el agente enviará todos los eventos de SYSMON al servidor de Wazuh, el cual cuenta con ocho decoders precargados enfocados en SYSMON.

• 0330-sysmon_rules.xml
• 0595-win-sysmon_rules.xml
• 0800-sysmon_id_1.xml
• 0810-sysmon_id_3.xml
• 0820-sysmon_id_7.xml
• 0830-sysmon_id_11.xml
• 0860-sysmon_id_13.xml
• 0870-sysmon_id_8.xml

Con esto, tendrás una buena base para identificar y detectar eventos de interés. Ahora bien, es importante mencionar que no verás los eventos en la consola web debido a que las reglas que los identifican vienen configuradas con un “nivel 0” y Wazuh no muestra estos eventos, pero sí los procesa.

En caso de que quieras visualizar estos eventos, tendrás que modificar cada regla para que tenga como mínimo “nivel 3”.

Es importante tener en cuenta que al modificar esta configuración se empezarán a almacenar más eventos y estos ocuparán más espacio en el disco duro. Tenemos un estimado de 500 MB de espacio máximo mensual por cada equipo, para que lo consideres.

Como ejemplo y para tener una idea de cómo se ve la información que comenzamos a enviar, modificaremos el archivo “0595-win -sysmon_rules.xml” que se encuentra en ruta “/var/ossec/ruleset/rules/“ del servidor Wazuh (20.20.20.11).

Luego reiniciamos el servicio “wazuh-manager” ejecutando el siguiente comando:

sudo systemctl restart wazuh-manager

Ahora sí podrás visualizar todos los eventos.

Antes

Después

Con esto hemos terminado la configuración en el ambiente Windows.

Integrando SYSMON: Consultas (Query) de ejemplo

Integrando AuditD: Actualizando la configuración de AuditD

Ahora revisaremos la configuración necesaria para que el agente Wazuh en ambiente Linux pueda enviar los eventos AuditD.

Pero antes de continuar tendremos que realizar algunas modificaciones en el archivo “audit.rule” que tenemos configurado y que modificaremos para que el flag “key” sea representativo a la acción realizada “Acceso, Escritura, Ejecución o modificación”, siendo éste un requerimiento de Wazuh. Ref: Configuration – Monitoring system calls · Wazuh documentation.

Si seguiste el artículo donde explicamos la instalación de AuditD (Securitizando tu red: Sysmon y AuditD (Parte 3) – FINSIN), lo más probable es que estés utilizando la configuración propuesta por Florian Roth disponible en el siguiente repositorio de GitHub auditd · GitHub.

¿Por qué debemos realizar esta modificación? Porque algunas configuraciones se encuentran “sumarizadas” y podrían no ser lo suficientemente descriptivas para la detección en Wazuh.

Por ejemplo, en la sección de Usuarios y grupos se define que se monitorearán los “atributos y el acceso” (WA) de la ruta “/etc/group” con llave “etcgroup”.

Si utilizamos este formato, Wazuh no podrá identificar correctamente si fue una acción sobre los atributos o si fue un acceso. Para solucionar esto, lo que haremos será separar cada configuración para que la diferenciación sea más sencilla.

Para ejecutar esta actividad, nos apoyaremos con el siguiente script en Python, que se encargará de separar los registros en base a la directiva -P y luego modificará la directiva -K para que coincida con la acción.

El script es el siguiente:

import argparse

def process_file(input_file, output_file):
    with open(input_file, 'r') as f:
        lines = f.readlines()

    processed_lines = []
    for line in lines:
        parts = line.split()
        new_lines = [line.strip()]

        # Process '-p' flag
        if '-p' in parts:
            flag_index = parts.index('-p')
            permissions = parts[flag_index + 1]
            if len(permissions) > 1:
                new_lines = [
                    ' '.join(parts[:flag_index] + ['-p', perm] + parts[flag_index + 2:])
                    for perm in permissions
                ]

        # Process '-S' flag
        if '-S' in parts:
            temp_lines = []
            for l in new_lines:
                parts = l.split()
                flag_index = parts.index('-S')
                syscalls = parts[flag_index + 1]
                if len(syscalls.split(',')) > 1:
                    temp_lines.extend([
                        ' '.join(parts[:flag_index] + ['-S', syscall] + parts[flag_index + 2:])
                        for syscall in syscalls.split(',')
                    ])
                else:
                    temp_lines.append(l)
            new_lines = temp_lines

        processed_lines.extend(new_lines)

    with open(output_file, 'w') as f:
        f.writelines([line + '\n' for line in processed_lines])


def modify_output_file(output_file):
    with open(output_file, 'r') as f:
        lines = f.readlines()

    modified_lines = []
    for line in lines:
        parts = line.strip().split()
        if '-k' in parts:
            flag_index = parts.index('-k')
            key = parts[flag_index + 1]

            if '-p' in parts:
                p_index = parts.index('-p')
                p_value = parts[p_index + 1]
                new_key = f'{key}-{p_value}'
                parts[flag_index + 1] = new_key
            elif '-S' in parts:
                s_index = parts.index('-S')
                s_value = parts[s_index + 1]
                new_key = f'{key}-{s_value}'
                parts[flag_index + 1] = new_key

        modified_lines.append(' '.join(parts))

    with open(output_file, 'w') as f:
        f.writelines([line + '\n' for line in modified_lines])


def extract_keys(modified_output_file, keys_file):
    key_dict = {
        'w': 'write',
        'r': 'read',
        'a': 'attribute',
        'x': 'execute',
        'c': 'command'
    }

    keys = set()
    with open(modified_output_file, 'r') as f:
        lines = f.readlines()

    for line in lines:
        parts = line.strip().split()
        if '-k' in parts:
            flag_index = parts.index('-k')
            key = parts[flag_index + 1]

            if '-' in key:
                value = key.split('-')[-1]
                description = key_dict.get(value, 'execute')
                keys.add(f'{key}:{description}')
            else:
                keys.add(f'{key}:execute')

    with open(keys_file, 'w') as f:
        f.writelines([key + '\n' for key in sorted(keys)])


if __name__ == '__main__':
    parser = argparse.ArgumentParser(description='Process flags in a file.')
    parser.add_argument('-f', '--file', required=True, help='Input file')
    parser.add_argument('-o', '--output', default='wazuh-audit.rules', help='Output file')
    parser.add_argument('-k', '--keys', default='audit-keys', help='Keys output file')
    args = parser.parse_args()

    process_file(args.file, args.output)
    modify_output_file(args.output)
    extract_keys(args.output, args.keys)

Este script lo podrás encontrar también en el siguiente GitHub wazuh-auditDKey
y su utilización es bastante sencilla. Solo tendremos que descargar el archivo audit.rules e idealmente dejarlo en la misma carpeta que el script.

Luego ejecutaremos el siguiente comando para que modifique el archivo audit.rules y genere el archivo de “keys” necesarios para Wazuh.

python3 wazuh-auditdkey.py -f audit.rules

Una vez ejecutado el script se generarán dos archivos: “audit-keys” y “wazuh-audit.rules”.

El primero contendrá el listado de “keys” únicos que debemos cargar en el servidor con rol “Wazuh Server”.

Y el segundo archivo contiene la configuración expandida del archivo original.

Con esto, tendremos listos los dos archivos necesarios para continuar.

Integrando AuditD: Actualización de la configuración de Wazuh

El siguiente paso será configurar el servidor con rol Wazuh Server (20.20.20.11) para que reconozca las “keys” que fueron creadas a partir de la configuración del archivo audit.rules.

Para esto ingresaremos vía SSH al servidor y editaremos el siguiente archivo.

/var/ossec/etc/lists/audit-keys

El archivo debería verse de la siguiente forma:

Puedes borrar la configuración existente, pero en nuestro caso pegaremos la configuración del archivo “audit-keys” a continuación.

Guardamos la información y luego cerramos el archivo dado que tendremos que reiniciar el servidor Wazuh.

Esto lo haremos con el siguiente comando:

sudo systemctl restart wazuh-manager

Luego verificaremos que el servicio corra correctamente con el siguiente comando:

sudo systemctl status wazuh-manager

Con esto tendremos configurado el servidor con rol “Wazuh Server” para poder interpretar correctamente los eventos de AuditD.

Integrando AuditD: Actualización de la configuración del equipo

El siguiente paso será actualizar la configuración de AuditD en el equipo que deseamos monitorear.

Para esto, editaremos el archivo de configuración, que deberíamos encontrar en la siguiente ruta según corresponda:

/etc/audit/rules.d/audit.rules

Para actualizar la configuración, primero deberemos borrar todo el contenido existente y luego pegar el contenido del archivo “wazuh-audit.rules” generado anteriormente. Una vez actualicemos el archivo, deberemos reiniciar el servicio con el siguiente comando:

sudo systemctl restart auditd

Verificaremos que el servicio se esté ejecutando correctamente utilizando el siguiente comando:

sudo systemctl status auditd

Finalmente, configuraremos el agente Wazuh para que haga el envío del log de autoría.

Para esto, editaremos el archivo de configuración que encontraremos en la siguiente ruta:

/var/ossec/etc/ossec.conf

Y al final de la sección “Log analysis”, agregaremos la siguiente configuración:

  <localfile>
      <location>/var/log/audit/audit.log</location>
      <log_format>audit</log_format>
  </localfile>

Guardamos y cerramos el archivo para reiniciar el agente de Wazuh con el siguiente comando:

systemctl restart wazuh-agent

Ahora, nos dirigimos a la consola web de Wazuh y revisaremos los eventos de auditoría del equipo monitoreado.

Esto lo haremos desde el menú “Agents”

Luego deberemos hacer clic en “More…” y luego en “Security events”.

Ahora haremos clic en la pestaña “Events”, para visualizar los eventos de auditoría que configuramos:

¡Con esto habremos terminado de integrar todos los sistemas que revisamos en artículos anteriores!

Integrando AuditD: Consultas (Query) de ejemplo

A continuación, encontrarás algunas query básicas que podrían ayudarte a identificar algún comportamiento anómalo.

Conclusión

De esta forma, habremos concluido la integración de nuestros sistemas con Wazuh, tanto para los logs aplicativos como los logs de sistema mejorados.

Esto nos dará una imagen general de lo que sucede en nuestra red y nos dará información suficiente para realizar una revisión en caso de sospecha de infección o de algún comportamiento anómalo.

Ahora que ya tenemos una base de monitoreo, podremos enfocarnos en desarrollar mecanismos de detección y, de ser posible, acciones automatizadas ante ciertos casos. Justamente en este tema enfocaremos nuestros próximos artículos.

¡Nos vemos!