Wazuh: Documentación

  • https://documentation.wazuh.com/current/getting-started/components/index.html
  • Es un sistema open source que brinda características XDR y SIEM
  • Incluyen
    • Análisis de logs
    • Detección de malware y intrusos
    • Monitorización de integridad de archivos
    • Evaluación de la configuración
    • Detección de vulnerabilidades
    • Y soporte en la regulación de cumplimiento
  • Esta compuestos de 4 elementos
    • Wazuh indexer: es un motor de análisis y búsqueda de texto completo altamente escalable. Este componente central indexa y almacena alertas generadas por el servidor Wazuh.
    • Wazuh server: analiza los datos recibidos de los agentes. Lo procesa a través de decodificadores y reglas, utilizando inteligencia de amenazas para buscar indicadores de compromiso (IOC) bien conocidos. Un solo servidor puede analizar datos de cientos o miles de agentes y escalar horizontalmente cuando se configura como un clúster. Este componente central también se utiliza para administrar los agentes, configurándolos y actualizándolos de forma remota cuando sea necesario.
    • Wazuh Dashboard: es la interfaz de usuario web para visualización y análisis de datos. Incluye paneles listos para usar para eventos de seguridad, cumplimiento normativo (por ejemplo, PCI DSS, GDPR, CIS, HIPAA, NIST 800-53), aplicaciones vulnerables detectadas, datos de monitoreo de integridad de archivos, resultados de evaluación de configuración, monitoreo de infraestructura en la nube eventos y otros. También se utiliza para administrar la configuración de Wazuh y monitorear su estado.
    • Wazuh agents: se instalan en puntos finales como computadoras portátiles, computadoras de escritorio, servidores, instancias en la nube o máquinas virtuales. Proporcionan capacidades de prevención, detección y respuesta ante amenazas. Se ejecutan en sistemas operativos como Linux, Windows, macOS, Solaris, AIX y HP-UX.
  • Además de las capacidades de monitoreo basadas en agentes, la plataforma Wazuh puede monitorear dispositivos sin agentes, como firewalls, conmutadores, enrutadores o IDS de red, entre otros. Por ejemplo, los datos de registro de un sistema se pueden recopilar a través de Syslog y su configuración se puede monitorear a través de sondeos periódicos de sus datos, a través de SSH o a través de una API.

Wazuh indexer

  • El componente del servidor de Wazuh analiza los datos recibidos de los agentes, disparando alertas cuando se detectan amenazas o anomalías. También se utiliza para administrar la configuración de los agentes de forma remota y monitorear su estado.
  • El servidor de Wazuh utiliza fuentes de inteligencia de amenazas para mejorar sus capacidades de detección. También enriquece los datos de alerta mediante el uso del marco MITRE ATT&CK y los requisitos de cumplimiento normativo, como PCI DSS, GDPR, HIPAA, CIS y NIST 800-53, lo que proporciona un contexto útil para el análisis de seguridad.
  • Además, el servidor de Wazuh se puede integrar con software externo, incluidos sistemas de emisión de boletos como ServiceNow, Jira y PagerDuty, así como plataformas de mensajería instantánea como Slack. Estas integraciones son convenientes para optimizar las operaciones de seguridad.

Arquitectura del servidor

  • El siguiente diagrama representa la arquitectura y los componentes del servidor:
  • Agent enrollment service (Servicio de alta de agentes): Se utiliza para dar de alta nuevos agentes. Este servicio proporciona y distribuye claves de autenticación únicas para cada agente. El proceso se ejecuta como un servicio de red y admite la autenticación a través de TLS
  • Agent connection service (Servicio de conexión de agentes): Este servicio recibe datos de los agentes. Utiliza las claves compartidas por el servicio de inscripción para validar la identidad de cada agente y cifrar las comunicaciones entre el agente de Wazuh y el servidor de Wazuh. Además, este servicio proporciona una gestión de configuración centralizada, lo que le permite impulsar la configuración de nuevos agentes de forma remota.
  • Analysis engine: (Motor de análisis): Este es el componente del servidor que realiza el análisis de datos. Utiliza decodificadores para identificar el tipo de información que se procesa (eventos de Windows, registros SSH, registros del servidor web y otros). Estos decodificadores también extraen elementos de datos relevantes de los mensajes de registro, como la dirección IP de origen, la identificación del evento o el nombre de usuario. Luego, mediante el uso de reglas, el motor identifica patrones específicos en los eventos decodificados que podrían desencadenar alertas y posiblemente incluso solicitar contramedidas automáticas (por ejemplo, prohibir una dirección IP, detener un proceso en ejecución o eliminar un artefacto de malware).
  • Wazuh RESTful API (API RESTful de Wazuh): este servicio proporciona una interfaz para interactuar con la infraestructura de Wazuh. Se utiliza para administrar los ajustes de configuración de agentes y servidores, monitorear el estado de la infraestructura y la salud general, administrar y editar decodificadores y reglas de Wazuh, y consultar sobre el estado de los puntos finales monitoreados.
  • Wazuh cluster daemon(Daemon de clúster de Wazuh): este servicio se utiliza para escalar los servidores de Wazuh horizontalmente, desplegándolos como un clúster. Este tipo de configuración, combinado con un equilibrador de carga de red, proporciona alta disponibilidad y equilibrio de carga. El demonio del clúster de Wazuh es lo que utilizan los servidores de Wazuh para comunicarse entre sí y mantenerse sincronizados.
  • Filebeat: Se utiliza para enviar eventos y alertas al indexador de Wazuh. Lee la salida del motor de análisis de Wazuh y envía eventos en tiempo real. También proporciona equilibrio de carga cuando se conecta a un clúster indexador Wazuh de múltiples nodos.

Wazuh dashboard

  • El panel de Wazuh es una interfaz de usuario web flexible e intuitiva para extraer, analizar y visualizar eventos de seguridad y datos de alertas. También se utiliza para la gestión y seguimiento de la plataforma Wazuh. Además, proporciona características para el control de acceso basado en roles (RBAC) y el inicio de sesión único (SSO).

Visualización y análisis de datos

  • La interfaz web ayuda a los usuarios a navegar por los diferentes tipos de datos recopilados por el agente de Wazuh, así como por las alertas de seguridad generadas por el servidor de Wazuh. Los usuarios también pueden generar informes y crear visualizaciones y paneles personalizados.
  • Como ejemplo, Wazuh proporciona paneles listos para usar para el cumplimiento normativo, como PCI DSS, GDPR, HIPAA y NIST 800-53. También proporciona una interfaz para navegar a través del marco MITRE ATT&CK y las alertas relacionadas.

Monitorización y configuración de agentes

  • El panel de control de Wazuh permite a los usuarios administrar la configuración de los agentes y monitorear su estado. Como ejemplo, para cada punto final monitoreado, los usuarios pueden definir qué módulos de agente se habilitarán, qué archivos de registro se leerán, qué archivos se monitorearán para cambios de integridad o qué controles de configuración se realizarán.

Gestión de plataforma

El panel de control de Wazuh proporciona una interfaz de usuario dedicada a administrar su implementación de Wazuh. Esto incluye monitorear el estado, los registros y las estadísticas de los diferentes componentes de Wazuh. También incluye la configuración del servidor Wazuh y la creación de reglas y decodificadores personalizados para el análisis de registros y la detección de amenazas.

Herramientas de desarrollo

  • El panel de control de Wazuh incluye una herramienta de prueba de conjunto de reglas que puede procesar mensajes de registro para verificar cómo se decodifican y si coinciden o no con una regla de detección de amenazas. Esta función es especialmente útil cuando se han creado reglas y decodificadores personalizados y el usuario desea probarlos.
  • El panel de control de Wazuh también incluye una consola API para que los usuarios interactúen con la API de Wazuh. Esto se puede usar para administrar la implementación de Wazuh (p. ej., administrar configuraciones de servidores o agentes, monitorear el estado y registrar mensajes, agregar o eliminar agentes, etc.).

Wazuh agent

El agente de Wazuh se ejecuta en Linux, Windows, macOS, Solaris, AIX y otros sistemas operativos. Se puede implementar en equipos portátiles, de escritorio, servidores, instancias en la nube, contenedores o máquinas virtuales. El agente ayuda a proteger su sistema proporcionando capacidades de prevención, detección y respuesta ante amenazas. También se utiliza para recopilar diferentes tipos de datos de aplicaciones y sistemas que reenvía al servidor de Wazuh a través de un canal encriptado y autenticado.

Agent architecture

El agente Wazuh tiene una arquitectura modular. Cada componente está a cargo de sus propias tareas, incluida la supervisión del sistema de archivos, la lectura de mensajes de registro, la recopilación de datos de inventario, el análisis de la configuración del sistema y la búsqueda de malware. Los usuarios pueden administrar los módulos de agentes a través de los ajustes de configuración, adaptando la solución a sus casos de uso particulares.

El siguiente diagrama representa la arquitectura y los componentes del agente:

Módulos de agentes

  • Log collector(Recopilador de registros): este componente del agente puede leer archivos de registro sin formato y eventos de Windows, recopilando mensajes de registro del sistema operativo y de la aplicación. Admite filtros XPath para eventos de Windows y reconoce formatos de varias líneas como registros de auditoría de Linux. También puede enriquecer eventos JSON con metadatos adicionales.
  • Command execution (Ejecución de comandos): los agentes ejecutan comandos autorizados periódicamente, recopilan su salida y la informan al servidor de Wazuh para un análisis más detallado. Puede usar este módulo para diferentes propósitos, como monitorear el espacio restante en el disco duro u obtener una lista de los últimos usuarios que iniciaron sesión.
  • File integrity monitoring (FIM) (Monitoreo de integridad de archivos (FIM)): este módulo monitorea el sistema de archivos, informando cuando los archivos se crean, eliminan o modifican. Realiza un seguimiento de los cambios en los atributos de archivo, permisos, propiedad y contenido. Cuando ocurre un evento, captura detalles de quién, qué y cuándo en tiempo real. Además, el módulo FIM crea y mantiene una base de datos con el estado de los archivos monitoreados, lo que permite ejecutar consultas de forma remota.
  • Security configuration assessment (SCA) (Evaluación de la configuración de seguridad (SCA)): este componente proporciona una evaluación continua de la configuración, utilizando verificaciones listas para usar basadas en los puntos de referencia del Centro de seguridad de Internet (CIS). Los usuarios también pueden crear sus propios controles SCA para monitorear y hacer cumplir sus políticas de seguridad.
  • System inventory (Inventario del sistema): este módulo de agente ejecuta exploraciones periódicamente y recopila datos de inventario, como la versión del sistema operativo, las interfaces de red, los procesos en ejecución, las aplicaciones instaladas y una lista de puertos abiertos. Los resultados del escaneo se almacenan en bases de datos SQLite locales que se pueden consultar de forma remota.
  • Malware detection (Detección de malware): utilizando un enfoque no basado en firmas, este componente es capaz de detectar anomalías y la posible presencia de rootkits. Además, busca procesos ocultos, archivos ocultos y puertos ocultos mientras monitorea las llamadas al sistema.
  • Active response (Respuesta activa): este módulo ejecuta acciones automáticas cuando se detectan amenazas, desencadenando respuestas para bloquear una conexión de red, detener un proceso en ejecución o eliminar un archivo malicioso. Los usuarios también pueden crear respuestas personalizadas cuando sea necesario y personalizar, por ejemplo, respuestas para ejecutar un binario en un espacio aislado, capturar el tráfico de la red y escanear un archivo con un antivirus.
  • Container security monitoring (Monitoreo de seguridad de contenedores): este módulo de agente está integrado con la API de Docker Engine para monitorear los cambios en un entorno en contenedores. Por ejemplo, detecta cambios en las imágenes de los contenedores, la configuración de la red o los volúmenes de datos. Además, alerta sobre contenedores que se ejecutan en modo privilegiado y sobre usuarios que ejecutan comandos en un contenedor en ejecución.
  • Cloud security monitoring (Monitoreo de seguridad en la nube): este componente monitorea proveedores en la nube como Amazon AWS, Microsoft Azure o Google GCP. Se comunica de forma nativa con sus API. Es capaz de detectar cambios en la infraestructura de la nube (p. ej., se crea un nuevo usuario, se modifica un grupo de seguridad, se detiene una instancia de la nube, etc.) y recopila datos de registro de servicios en la nube (p. ej., AWS Cloudtrail, AWS Macie, AWS GuardDuty, Azure Active Directory, etc.)

Comunicación con el servidor Wazuh

El agente de Wazuh se comunica con el servidor de Wazuh para enviar datos recopilados y eventos relacionados con la seguridad. Además, el agente envía datos operativos, reportando su configuración y estado. Una vez conectado, el agente puede actualizarse, monitorearse y configurarse de forma remota desde el servidor de Wazuh.

La comunicación del agente con el servidor se realiza a través de un canal seguro (TCP o UDP), proporcionando encriptación y compresión de datos en tiempo real. Además, incluye mecanismos de control de flujo para evitar inundaciones, poner en cola eventos cuando sea necesario y proteger el ancho de banda de la red.

Debe inscribir al agente antes de conectarlo al servidor por primera vez. Este proceso proporciona al agente una clave única que se utiliza para la autenticación y el cifrado de datos.

Arquitectura

La arquitectura de Wazuh se basa en agentes, que se ejecutan en los puntos finales monitoreados, que envían datos de seguridad a un servidor central. Los dispositivos sin agentes, como firewalls, conmutadores, enrutadores y puntos de acceso, son compatibles y pueden enviar datos de registro de forma activa a través de Syslog, SSH o mediante su API. El servidor central decodifica y analiza la información entrante y pasa los resultados al indexador de Wazuh para su indexación y almacenamiento.

El clúster del indexador de Wazuh es una colección de uno o más nodos que se comunican entre sí para realizar operaciones de lectura y escritura en los índices. Las implementaciones pequeñas de Wazuh, que no requieren procesar grandes cantidades de datos, pueden manejarse fácilmente mediante un clúster de un solo nodo. Se recomiendan los clústeres de múltiples nodos cuando hay muchos puntos finales monitoreados, cuando se anticipa un gran volumen de datos o cuando se requiere alta disponibilidad.

Para entornos de producción, se recomienda implementar el servidor de Wazuh y el indexador de Wazuh en diferentes hosts. En este escenario, Filebeat se utiliza para reenviar de forma segura las alertas de Wazuh y los eventos archivados al clúster del indexador de Wazuh (de un solo nodo o de varios nodos) mediante el cifrado TLS.

El siguiente diagrama representa una arquitectura de implementación de Wazuh. Muestra los componentes de la solución y cómo el servidor de Wazuh y los nodos del indexador de Wazuh se pueden configurar como clústeres, proporcionando equilibrio de carga y alta disponibilidad.

Agente de Wazuh: comunicación con el servidor de Wazuh

El agente de Wazuh envía continuamente eventos al servidor de Wazuh para su análisis y detección de amenazas. Para comenzar a enviar estos datos, el agente establece una conexión con el servicio del servidor para la conexión del agente, que escucha en el puerto 1514 de forma predeterminada (esto es configurable). Luego, el servidor de Wazuh decodifica y verifica las reglas de los eventos recibidos, utilizando el motor de análisis. Los eventos que activan una regla se aumentan con datos de alerta, como el ID de la regla y el nombre de la regla. Los eventos se pueden poner en cola en uno o ambos de los siguientes archivos, dependiendo de si se dispara una regla o no:

El archivo /var/ossec/logs/archives/archives.json contiene todos los eventos, ya sea que activaron una regla o no.

El archivo /var/ossec/logs/alerts/alerts.json contiene solo eventos que activaron una regla con una prioridad lo suficientemente alta (el umbral es configurable).

El protocolo de mensajes de Wazuh utiliza cifrado AES de forma predeterminada, con 128 bits por bloque y claves de 256 bits. El cifrado Blowfish es opcional

Servidor Wazuh – Comunicación del indexador Wazuh

El servidor de Wazuh usa Filebeat para enviar alertas y datos de eventos al indexador de Wazuh, usando el cifrado TLS. Filebeat lee los datos de salida del servidor de Wazuh y los envía al indexador de Wazuh (de manera predeterminada, escuchando en el puerto 9200/TCP). Una vez que el indexador de Wazuh indexa los datos, el tablero de Wazuh se utiliza para extraer y visualizar la información.

El panel de control de Wazuh consulta la API RESTful de Wazuh (escuchando de manera predeterminada en el puerto 55000/TCP en el servidor de Wazuh) para mostrar la configuración y la información relacionada con el estado del servidor y los agentes de Wazuh. También puede modificar los ajustes de configuración de los agentes o del servidor a través de llamadas a la API. Esta comunicación se cifra con TLS y se autentica con un nombre de usuario y una contraseña.

Puertos requeridos

Almacenamiento de datos de archivo

Tanto los eventos de alerta como los que no son de alerta se almacenan en archivos en el servidor de Wazuh, además de enviarse al indexador de Wazuh. Estos archivos se pueden escribir en formato JSON (.json) o en formato de texto sin formato (.log). Estos archivos se comprimen y firman diariamente con sumas de verificación MD5, SHA1 y SHA256. La estructura de directorios y nombres de archivos es la siguiente:

/var/ossec/logs/archives/2022/Jan

Se recomienda la rotación y las copias de seguridad de los archivos comprimidos según la capacidad de almacenamiento del servidor de Wazuh. Mediante el uso de trabajos cron, puede administrar fácilmente mantener solo una ventana de tiempo específica de archivos de almacenamiento localmente en el servidor, por ejemplo, el año pasado o los últimos tres meses.

Por otro lado, puede optar por prescindir del almacenamiento de archivos y simplemente confiar en el indexador de Wazuh para el almacenamiento de archivos. Esta alternativa podría ser la preferida si ejecuta copias de seguridad periódicas de instantáneas del indexador de Wazuh y/o tiene un clúster de indexador de Wazuh de varios nodos con réplicas de fragmentos para una alta disponibilidad. Incluso podría usar un trabajo cron para mover los índices de las instantáneas a un servidor de almacenamiento de datos final y firmarlos usando los algoritmos hash MD5, SHA1 y SHA256.

Use cases

A continuación, puede encontrar ejemplos de algunos de los casos de uso más comunes de la plataforma Wazuh.

Análisis de datos de registro

En muchos casos, la evidencia de un ataque se puede encontrar en los mensajes de registro de dispositivos, sistemas y aplicaciones. Wazuh ayuda a los usuarios automatizando la gestión y el análisis de registros para acelerar la detección de amenazas.

El agente de Wazuh, que se ejecuta en el punto final monitoreado, está a cargo de leer los mensajes de registro del sistema operativo y de la aplicación, y reenviarlos al servidor de Wazuh, donde se lleva a cabo el análisis. El servidor también puede recibir datos a través de Syslog desde dispositivos o aplicaciones de red cuando no se implementa ningún agente.

Wazuh utiliza decodificadores para identificar la aplicación de origen del mensaje de registro. Luego, analiza los datos utilizando reglas específicas de la aplicación. Este es un ejemplo de una regla utilizada para detectar eventos de falla de autenticación SSH:

<rule id="5716" level="5">
  <if_sid>5700</if_sid>
  <match>^Failed|^error: PAM: Authentication</match>
  <description>SSHD authentication failed.</description>
  <mitre>
    <id>T1110</id>
  </mitre>
  <group>pci_dss_10.2.4,pci_dss_10.2.5,</group>
</rule>

Las reglas incluyen un campo de coincidencia que se utiliza para definir el patrón que busca la regla. También tienen un campo de nivel que especifica la prioridad de las alertas resultantes. Además, las reglas enriquecen los eventos con identificadores de técnicas del marco MITRE ATT&CK y asignaciones a los controles de cumplimiento normativo.

El administrador genera una alerta cada vez que un evento, recopilado por uno de los agentes o recibido a través de Syslog, coincide con una regla con un nivel de prioridad superior a un umbral predefinido (3 por defecto).

Vea a continuación una alerta de ejemplo que se encuentra en /var/ossec/logs/alerts/alerts.json. Algunos campos han sido eliminados por razones de brevedad:

{
  "agent": {
      "id": "005",
      "ip": "10.0.1.175",
      "name": "Centos"
  },
  "predecoder": {
      "hostname": "ip-10-0-1-175",
      "program_name": "sshd",
      "timestamp": "Jul 12 15:32:41"
  },
  "decoder": {
      "name": "sshd",
      "parent": "sshd"
  },
  "full_log": "Jul 12 15:32:41 ip-10-0-1-175 sshd[21746]: Failed password for root from 61.177.172.13 port 61658 ssh2",
  "location": "/var/log/secure",
  "data": {
      "dstuser": "root",
      "srcip": "61.177.172.13",
      "srcport": "61658"
  },
  "rule": {
      "description": "sshd: authentication failed.",
      "id": "5716",
      "level": 5,
      "mitre": {
          "id": [
              "T1110"
          ],
          "tactic": [
              "Credential Access"
          ],
          "technique": [
              "Brute Force"
          ]
      },
  },
  "timestamp": "2020-07-12T15:32:41.756+0000"
}

Una vez generadas por el servidor de Wazuh, las alertas se envían al componente indexador de Wazuh, donde se enriquecen con información de geolocalización, se almacenan y se indexan. El tablero de Wazuh se puede usar para buscar, analizar y visualizar los datos. A continuación se muestra una captura de pantalla de ejemplo de la interfaz:

Monitoreo de integridad de archivos

El componente Monitoreo de integridad de archivos (FIM) genera una alerta cuando detecta un cambio en el sistema de archivos. Esta capacidad se usa a menudo para detectar el acceso o los cambios en los datos confidenciales. Si sus servidores cumplen con PCI DSS, el requisito 11.5 estipula que se debe instalar una solución de monitoreo de integridad de archivos para pasar la auditoría con éxito.

A continuación se muestra un ejemplo de una alerta generada cuando se modifica un archivo supervisado. Los metadatos incluyen sumas de verificación MD5, SHA1 y SHA256, tamaños de archivo (antes y después del cambio), permisos de archivo, propietario del archivo, cambios de contenido y el usuario que realizó estos cambios (datos de quién).

{
  "agent": {
      "id": "006",
      "ip": "10.0.1.214",
      "name": "RHEL7"
  },
  "decoder": {
      "name": "syscheck_integrity_changed"
  },
  "syscheck": {
      "audit": {
          "effective_user": {
              "id": "0",
              "name": "root"
          },
          "group": {
              "id": "0",
              "name": "root"
          },
          "login_user": {
              "id": "1001",
              "name": "wazuh"
          },
          "process": {
              "cwd": "/home/wazuh",
              "id": "13235",
              "name": "/usr/bin/vim",
              "parent_cwd": "/home/wazuh",
              "parent_name": "/usr/bin/bash",
              "ppid": "10942"
          },
          "user": {
              "id": "0",
              "name": "root"
          }
      },
      "diff": "0a1\n> 8.8.8.8     ads.fastclick.net\n",
      "event": "modified",
      "gid_after": "0",
      "gname_after": "root",
      "inode_after": 198194,
      "inode_before": 55652,
      "md5_after": "feb5cea0deb5925101b642bca97dc7b3",
      "md5_before": "54fb6627dbaa37721048e4549db3224d",
      "mode": "whodata",
      "mtime_after": "2020-07-12T18:07:57",
      "mtime_before": "2020-07-12T18:00:55",
      "path": "/etc/hosts",
      "perm_after": "rw-r--r--",
      "sha1_after": "2aa2079c3972b4bb8f28d69877a7c5e93dacbe6f",
      "sha1_before": "7335999eb54c15c67566186bdfc46f64e0d5a1aa",
      "sha256_after": "48f09f8c313b303ce2ca9365f70ae8d992c5589c56493ac055f0ab129d82c365",
      "sha256_before": "498f494232085ec83303a2bc6f04bea840c2b210fbbeda31a46a6e5674d4fc0e",
      "size_after": "188",
      "size_before": "158",
      "uid_after": "0",
      "uname_after": "root"
  },
  "rule": {
      "description": "Integrity checksum changed.",
      "id": "550",
      "level": 7,
      "mitre": {
          "id": [
              "T1492"
          ],
          "tactic": [
              "Impact"
          ],
          "technique": [
              "Stored Data Manipulation"
          ]
      }
  },
  "timestamp": "2020-07-12T18:07:57.676+0000"
}

En la sección Supervisión de integridad del panel de control de Wazuh, los usuarios pueden ver todos los detalles de las alertas activadas y encontrar un resumen completo de los cambios detectados.

Detección de rootkits

El agente de Wazuh escanea periódicamente el sistema monitoreado para detectar rootkits tanto en el kernel como en el nivel del espacio del usuario. Este tipo de malware generalmente reemplaza o cambia los componentes del sistema operativo existente para alterar el comportamiento del sistema. Los rootkits pueden ocultar otros procesos, archivos y conexiones de red.

Wazuh utiliza diferentes mecanismos de detección para buscar anomalías en el sistema o intrusiones conocidas. El componente Rootcheck hace esto periódicamente:

Vea a continuación un ejemplo de una alerta generada cuando se encuentra un proceso oculto. En este caso, el sistema afectado está ejecutando un rootkit a nivel de kernel de Linux (llamado Diamorphine):
{
  "agent": {
      "id": "1030",
      "ip": "10.0.0.59",
      "name": "diamorphine-POC"
  },
  "decoder": {
      "name": "rootcheck"
  },
  "full_log": "Process '562' hidden from /proc. Possible kernel level rootkit.",
  "rule": {
      "description": "Host-based anomaly detection event (rootcheck).",
      "id": "510",
      "level": 7
  },
  "timestamp": "2020-07-12T18:07:00-0800"
}

Respuesta activa

El agente de Wazuh automatiza la respuesta a las amenazas ejecutando acciones cuando se detectan. El agente tiene la capacidad de bloquear conexiones de red, detener procesos en ejecución y eliminar archivos maliciosos, entre otras acciones. Además, también puede ejecutar scripts personalizados desarrollados por el usuario (por ejemplo, Python, Bash o PowerShell).

Para usar esta función, los usuarios definen las condiciones que activan las acciones programadas, que generalmente implican la detección y evaluación de amenazas. Por ejemplo, un usuario puede usar reglas de análisis de registros para detectar un intento de intrusión y una base de datos de reputación de direcciones IP para evaluar la amenaza buscando la dirección IP de origen del intento de conexión.

En el escenario descrito anteriormente, cuando la dirección IP de origen se reconoce como maliciosa (baja reputación), el sistema monitoreado se protege mediante la configuración automática de una regla de firewall para descartar todo el tráfico del atacante. Según la respuesta activa, esta regla de firewall es temporal o permanente.

En los sistemas Linux, el agente de Wazuh generalmente se integra con el firewall local de Iptables para este propósito. En los sistemas Windows, en cambio, utiliza la técnica de enrutamiento nulo (también conocida como blackholing). A continuación puede encontrar la configuración para definir dos scripts que se utilizan para el bloqueo de conexión automatizado:

<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>
<command>
  <name>win_route-null</name>
  <executable>route-null.exe</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

Además de los comandos definidos, las respuestas activas establecen las condiciones que deben cumplirse para desencadenarlas. A continuación, se muestra un ejemplo de una configuración que activa el comando de caída del firewall cuando coincide la regla de análisis de registro 100100.

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>100100</rules_id>
  <timeout>60</timeout>
</active-response>

En este caso, la regla 100100 se usa para buscar alertas donde la dirección IP de origen es parte de una base de datos de reputación de direcciones IP conocida.

<rule id="100100" level="10">
  <if_group>web|attack|attacks</if_group>
  <list field="srcip" lookup="address_match_key">etc/lists/blacklist-alienvault</list>
  <description>IP address found in AlienVault reputation database.</description>
</rule>

A continuación, puede encontrar una captura de pantalla con dos alertas de Wazuh: una que se activa cuando se detecta un ataque web que intenta explotar una vulnerabilidad del servidor PHP y otra que informa que el actor malicioso ha sido bloqueado.

Evaluación de la configuración

La evaluación de configuración de seguridad automatizada (SCA) es una capacidad esencial para mejorar la postura de seguridad de la empresa y reducir su superficie de ataque. El módulo Wazuh SCA ayuda a mantener una configuración estándar a través de los puntos finales monitoreados. Esto se hace a través de comprobaciones predefinidas basadas en las guías de refuerzo del Centro de Seguridad de Internet (CIS).

Cuando el módulo SCA está habilitado, el agente de Wazuh realiza escaneos periódicamente, informando configuraciones incorrectas en el sistema monitoreado. Esos escaneos evalúan la configuración del sistema a través de archivos de políticas que contienen un conjunto de comprobaciones para ejecutar. Por ejemplo, una verificación de SCA puede inspeccionar la configuración del sistema de archivos, buscar la presencia de una actualización de software o un parche de seguridad, ver que el firewall local esté habilitado, identificar servicios en ejecución innecesarios o verificar la política de contraseñas de los usuarios.

Las políticas para los escaneos SCA están escritas en formato YAML, lo que permite a los usuarios comprenderlas rápidamente. Con la sintaxis de SCA, los usuarios pueden ampliar las políticas existentes para adaptarlas a sus necesidades o escribir otras nuevas. Cada política contiene un conjunto de controles y cada control tiene una o más reglas. Por ejemplo, se puede usar una regla para buscar la existencia de un archivo, un directorio, una clave de registro de Windows o un proceso en ejecución, entre otros. También es posible ejecutar un comando y comparar su salida con una expresión regular.

Ejemplo de regla SCA de Linux:

- id: 5546
  title: "Ensure IP address forwarding is disabled"
  description: "The net.ipv4.ip_forward flag is used to tell the system whether it can forward packets or not."
  rationale: "Setting the flag to 0 ensures that a system with multiple interfaces (for example, a hard proxy), will never be able to forward packets, and therefore, never serve as a router."
  remediation: "Set the following parameter in /etc/sysctl.conf or a /etc/sysctl.d/* file: net.ipv4.ip_forward = 0 and set the active kernel parameters."
  compliance:
    - cis: ["3.1.1"]
    - cis_csc: ["3", "11"]
    - pci_dss: ["2.2.4"]
    - nist_800_53: ["CM.1"]
  condition: all
  rules:
    - 'c:sysctl net.ipv4.ip_forward -> r:^net.ipv4.ip_forward\s*=\s*0$'
    - 'c:grep -Rh net\.ipv4\.ip_forward /etc/sysctl.conf /etc/sysctl.d -> r:^net.ipv4.ip_forward\s*=\s*0$'

Windows SCA rule example:

- id: 14038
  title: "Ensure Microsoft Firewall is enabled"
  compliance:
    - pci_dss: ["10.6.1", "1.4"]
    - hipaa: ["164.312.b", "164.312.a.1"]
    - nist_800_53: ["AU.6", "SC.7"]
    - tsc: ["CC6.1", "CC6.8", "CC7.2", "CC7.3", "CC6.7"]
  condition: all
  rules:
    - 'r:HKEY_LOCAL_MACHINE\software\policies\microsoft\windowsfirewall\domainprofile -> enablefirewall -> 1'

macOS SCA rule example:

- id: 8522
  title: "Ensure nfs server is not running"
  description: "macOS can act as an NFS fileserver. NFS sharing could be enabled to allow someone on another computer to mount shares and gain access to information from the user's computer. File sharing from a user endpoint has long been considered questionable and Apple has removed that capability from the GUI. NFSD is still part of the Operating System and can be easily turned on to export shares and provide remote connectivity to an end user computer."
  rationale: "File serving should not be done from a user desktop, dedicated servers should be used.  Open ports make it easier to exploit the computer."
  remediation: "Ensure that the NFS Server is not running and is not set to start at boot Stop the NFS Server: sudo nfsd disable    Remove the exported Directory listing: rm /etc/export"
  compliance:
    - cis: ["4.5"]
  condition: none
  rules:
    - 'p:nfsd'
    - 'p:/sbin/nfsd'
    - 'f:/etc/exports'

A continuación se muestra un ejemplo de los resultados de una evaluación de valoración de la configuración. Estos se pueden obtener a través de la interfaz de usuario web o directamente a través de la API RESTful de Wazuh.

Inventario del sistema

El módulo de inventario del sistema del agente de Wazuh recopila información de hardware y software del sistema monitoreado. Esta herramienta ayuda a identificar activos y evaluar la eficacia de la gestión de parches.

Los datos de inventario recopilados, para cada uno de los puntos finales monitoreados, se pueden consultar a través de la API RESTful de Wazuh y desde la interfaz de usuario web. Esto incluye uso de memoria, espacio en disco, especificaciones de CPU, interfaces de red, puertos abiertos, procesos en ejecución y una lista de aplicaciones instaladas.

Para recopilar los datos, el agente de Wazuh ejecuta escaneos periódicos (el intervalo de tiempo es configurable). Una vez que se completa un escaneo, el agente compara los nuevos datos de inventario con los antiguos del escaneo anterior. De esta forma, el agente identifica eventos del sistema, por ejemplo, cuando se ha abierto un nuevo puerto, se ha detenido un proceso o se ha instalado una nueva aplicación.

Ejemplo de inventario de hardware, interfaces de red, puertos abiertos y configuración de red:

Example of software inventory:

Example of running processes:

Detección de vulnerabilidades

Las aplicaciones de software vulnerables suelen ser el objetivo de los atacantes para comprometer los puntos finales y obtener una presencia persistente en las redes objetivo. Basándose en sus capacidades de inventario de software, la plataforma de Wazuh mantiene una lista actualizada de todas las aplicaciones instaladas en los puntos finales donde se encuentra el agente de Wazuh.

Además, Wazuh identifica aplicaciones vulnerables y produce informes de riesgo al correlacionar esa lista con la Base de datos nacional de vulnerabilidades (NVD) y con la información recopilada de diferentes proveedores de sistemas operativos. Para detectar software vulnerable, Wazuh utiliza una base de datos de vulnerabilidades y exposiciones comunes (CVE) creada automáticamente mediante el procesamiento de datos extraídos de las siguientes fuentes:

Para habilitar la detección de vulnerabilidades, los usuarios deben configurar el agente de Wazuh para recopilar datos de inventario de software y el servidor de Wazuh para extraer información CVE de las diferentes fuentes de vulnerabilidad.

Vea a continuación un ejemplo de una alerta de detección de vulnerabilidad:

{
  "agent": {
    "id": "003",
    "ip": "10.0.1.102",
    "name": "Windows"
  },
  "location": "vulnerability-detector",
  "data": {
    "vulnerability": {
      "assigner": "cve@mitre.org",
      "cve": "CVE-2020-12395",
      "cve_version": "4.0",
      "cvss": {
        "cvss2": {
          "base_score": "10",
          "vector": {
            "access_complexity": "low",
            "attack_vector": "network",
            "authentication": "none",
            "availability": "complete",
            "confidentiality_impact": "complete",
            "integrity_impact": "complete"
          }
        }
      },
      "cwe_reference": "CWE-119",
      "package": {
        "architecture": "x86_64",
        "condition": "less than 68.8.0",
        "generated_cpe": "a:mozilla:thunderbird:68.0::::::x86_64:",
        "name": "Mozilla Thunderbird 68.0 (x64 en-US)",
        "version": "68.0"
      },
      "published": "2020-05-26",
      "references": [        "https://bugzilla.mozilla.org/buglist.cgi?bug_id=1595886%2C1611482%2C1614704%2C1624098%2C1625749%2C1626382%2C1628076%2C1631508",
        "https://security.gentoo.org/glsa/202005-03",
        "https://security.gentoo.org/glsa/202005-04",
        "https://usn.ubuntu.com/4373-1/",
        "https://www.mozilla.org/security/advisories/mfsa2020-16/",
        "https://www.mozilla.org/security/advisories/mfsa2020-17/",
        "https://www.mozilla.org/security/advisories/mfsa2020-18/",
        "https://nvd.nist.gov/vuln/detail/CVE-2020-12395"
      ],
      "severity": "High",
      "title": "Mozilla developers and community members reported memory safety bugs present in Firefox 75 and Firefox ESR 68.7. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox ESR < 68.8, Firefox < 76, and Thunderbird < 68.8.0.",
      "updated": "2020-06-12"
    }
  },
  "rule": {
    "description": "CVE-2020-12395 affects Mozilla Thunderbird 68.0 (x64 en-US)",
    "id": "23505",
    "level": 10
  },
  "timestamp": "2020-07-20T00:41:36.302+0000"
}

Vulnerability detection dashboard:

Cloud security

Falta

Container security

https://documentation.wazuh.com/current/getting-started/use-cases/container-security.html

Regulatory compliance

https://documentation.wazuh.com/current/getting-started/use-cases/regulatory-compliance.html