Introducción a Wazuh
1.1 OSSEC HIDS
OSSEC HIDS es un sistema de detección de intrusiones (HIDS) basado en host para detección de seguridad, visibilidad y cumplimiento. escucha. Se basa en un agente multiplataforma que reenvía datos del sistema, como mensajes de registro, hashes de archivos y anomalías detectadas, a un administrador central donde se analizan y procesan más a fondo para generar alertas de seguridad. Los agentes pasan datos de eventos a través de un canal seguro y autenticado al administrador central para su análisis.
Además, OSSEC HIDS proporciona un servidor syslog centralizado y un sistema de monitoreo de configuración sin agentes que brinda visibilidad de dispositivos sin agentes, como firewalls, conmutadores, enrutadores, puntos de acceso y dispositivos de red, información sobre eventos y cambios.
1.2 OpenSCAP
OpenSCAP es un intérprete OVAL (lenguaje abierto de evaluación de vulnerabilidades) y XCCDF (formato de descripción de lista de verificación de configuración extensible) para verificar la configuración del sistema y detectar vulnerabilidades fáciles de atacar.
Se trata de una herramienta muy conocida para comprobar el cumplimiento de la seguridad y reforzar los entornos empresariales utilizando líneas de base de seguridad estándar de la industria.
1.3 Elastic Stack
El Elastic Stack es un paquete de software (Filebeat, Logstash, Elasticsearch y Kibana) para recopilar, analizar, indexar, almacenar, buscar y mostrar datos de registro. Proporciona una interfaz web que proporciona vistas de panel de eventos de alto nivel y admite análisis avanzados y extracción de datos en lo profundo del almacén de datos de eventos.
II.Componentes
Los componentes principales de Wazuh son los agentes que se ejecutan en cada host monitoreado y el análisis de los datos recibidos de agentes y fuentes sin agentes como el servidor syslog. Además, el servidor reenvía datos de eventos al clúster de Elasticsearch, donde se indexa y almacena la información.
2.1Wazuh Agent
Wazuh Agent se ejecuta en los sistemas operativos Windows, Linux, Solaris, BSD y Mac. Se utiliza para recopilar diferentes tipos de datos del sistema y de las aplicaciones que se reenviarán a los servidores de Wazuh a través de canales cifrados y autenticados. Para establecer este canal seguro, se utiliza un proceso de registro que contiene una clave única preasegurada.
Los agentes se pueden utilizar para monitorear servidores físicos, máquinas virtuales e instancias en la nube (como Amazon AWS, Azure o Google Cloud). Hay instaladores de agentes precompilados disponibles para Linux, HP-UX, AIX, Solaris, Windows y Darwin (Mac OS X).
En los sistemas operativos basados en Unix, el agente ejecuta múltiples procesos que se comunican entre sí a través de sockets de dominio Unix locales. Uno de los procesos se encarga de enviar comunicaciones y datos al servidor de Wazuh. En los sistemas Windows, solo hay un proceso de agente que ejecuta múltiples tareas utilizando mutex.
Diferentes tareas o procesos del agente monitorean el sistema de diferentes maneras (por ejemplo, monitoreando la integridad de los archivos, leyendo mensajes de registro del sistema y escaneando la configuración del sistema).
El siguiente diagrama representa las tareas y procesos internos que ocurren a nivel de agente:
Todos los procesos de agente tienen diferentes propósitos y configuraciones. Aquí tienes una breve descripción de ellos:
Root Check: Este proceso realiza varias tareas relacionadas con la detección de rootkits, malware y anomalías del sistema. También realiza algunas comprobaciones de seguridad básicas en los archivos de configuración del sistema.
Recopilador de registros: este componente del agente se utiliza para leer mensajes de registro de aplicaciones y del sistema operativo, incluidos archivos de registro planos, registros de eventos estándar de Windows e incluso canales de eventos de Windows. También se puede configurar para que se ejecute periódicamente y capture el resultado de comandos específicos.
Syscheck: Este proceso realiza el Monitoreo de Integridad de Archivos (FIM) y también monitorea las claves de registro en sistemas Windows. Detecta cambios en el contenido, la propiedad y otros atributos del archivo, y registra la creación y eliminación de archivos. Si bien realiza escaneos FIM periódicos de forma predeterminada, se puede configurar para comunicarse con el kernel del sistema operativo para detectar cambios en los archivos en tiempo real y generar informes de cambios detallados (diffs) en archivos de texto.
OpenSCAP: este módulo utiliza resúmenes de seguridad básicos publicados de OVAL (lenguaje abierto de evaluación de vulnerabilidades) y XCCDF (formato de descripción de lista de verificación de configuración extensible). Al escanear periódicamente el sistema, puede descubrir aplicaciones o configuraciones vulnerables que no cumplen con estándares bien conocidos, como los definidos en los puntos de referencia del CIS (Centro para la Seguridad de Internet).
Demonio del agente: este proceso recibe datos generados o recopilados por todos los demás componentes del agente. Comprime, cifra y transmite datos al servidor a través de un canal autenticado. El proceso se ejecuta en un entorno "chroot" separado, lo que significa que tiene acceso limitado al sistema monitoreado. Esto mejora la seguridad general del agente ya que es el único proceso conectado a la red.
2.2 Servidor Wazuh
El componente del servidor es responsable de analizar los datos recibidos del agente y activar alertas cuando los eventos coinciden con las reglas (p. ej., intrusión detectada, cambio de archivo, configuración excedida de la política). , posible rootkit, etc.).
El servidor normalmente se ejecuta en una máquina física, una máquina virtual o una instancia de nube separada y ejecuta un componente de agente cuyo propósito es monitorear el servidor mismo. La siguiente es una lista de los componentes principales del servidor:
Servicio de registro: registra nuevos agentes proporcionando y distribuyendo una clave de autenticación previa específica para cada agente. El proceso se ejecuta como un servicio de red y admite autenticación mediante TLS/SSL y/o contraseñas fijas.
Servicio demonio remoto: Es el servicio que recibe datos del agente. Autentica a cada agente mediante una clave preprotegida y cifra la comunicación entre el agente y el administrador.
Demonio de análisis: Es el proceso que realiza el análisis de datos. Utiliza un decodificador para identificar el tipo de información que se procesa (como eventos de Windows, registros SSHD, registros del servidor web, etc.) y luego extrae elementos de datos relevantes (como IP de origen, ID de evento, usuario, etc.) del información de registro. Luego, mediante el uso de reglas, puede identificar patrones específicos en registros decodificados que pueden activar alertas o incluso invocar contramedidas automatizadas (respuestas proactivas), como prohibiciones de IP en firewalls.
API RESTful API RESTful: Proporciona una interfaz para gestionar y monitorear la configuración del agente y el estado de implementación. Esta API también la utiliza la interfaz web Wazuh de la aplicación Kibana.
2.3Elastic Stack
El Elastic Stack es un conjunto unificado de proyectos populares de código abierto para la gestión de registros, incluidos Elasticsearch, Logstash, Kibana, Filebeat, etc. Los proyectos de particular relevancia para las soluciones de Wazuh incluyen:
Elasticsearch: un motor de análisis y búsqueda de texto completo altamente escalable. Elasticsearch se distribuye, lo que significa que los datos (índice) se dividen en varios fragmentos y cada fragmento puede tener cero o más réplicas.
Logstash: herramienta que recopila y analiza registros y los guarda en un sistema de almacenamiento como Elasticsearch. También se pueden utilizar complementos de entrada, filtrado y salida para enriquecer y transformar los eventos recopilados.
Kibana: Una interfaz web flexible e intuitiva para extraer, analizar y visualizar datos.
Se ejecuta sobre el contenido indexado en un clúster de Elasticsearch.
Filebeat: un reenviador ligero para entregar registros a través de la red, normalmente utilizado con Logstash o Elasticsearch.
Wazuh se integra con Elastic Stack para proporcionar una fuente decodificada de mensajes de registro que serán indexados por Elasticsearch, así como una consola web en tiempo real para alertas y análisis de datos de registro. Además, la interfaz de usuario de Wazuh (que se ejecuta en Kibana) se puede utilizar para administrar y monitorear su infraestructura de Wazuh.
Un índice de Elasticsearch es una colección de documentos que comparten ciertas características similares, como ciertos campos públicos y requisitos hedónicos de retención de datos.
Wazuh utiliza hasta tres índices diferentes por día para almacenar diferentes tipos de eventos:
Wazuh - Alertas: El servidor Wazuh genera un índice de alerta cada vez que un evento activa una regla.
wazuh-events: Índice de todos los eventos (datos archivados) recibidos del agente, independientemente de si activaron una regla.
wazuh-monitoring: índice de datos relacionados con el estado del agente, utilizado por la interfaz web para mostrar si un agente individual está o ha estado "activo", "desconectado" o "nunca conectado".
Un índice está formado por documentos. A los efectos del índice anterior, un documento se refiere a una sola alerta, evento archivado o evento de estado.
Los índices de Elasticsearch se dividen en uno o más fragmentos, y cada fragmento puede tener opcionalmente una o más réplicas. Cada fragmento primario y réplica es un índice de Lucene. Por lo tanto, los índices de Elasticsearch se componen de múltiples índices de Lucene. Cuando ejecuta una búsqueda en un índice de Elasticsearch, se ejecuta en paralelo en todos los fragmentos y los resultados de la búsqueda se combinan. Divida un índice de Elasticsearch en múltiples fragmentos y réplicas para clústeres de Elasticsearch de múltiples nodos para limitar el alcance de la búsqueda y lograr una alta disponibilidad. Los clústeres de Elasticsearch de un solo nodo normalmente tienen solo un fragmento por índice y no tienen réplicas.
Arquitectura III
La arquitectura Wazuh se basa en agentes que se ejecutan en hosts monitoreados que reenvían datos de registro a un servidor central. Además, se admiten dispositivos sin agentes (como firewalls, conmutadores, enrutadores, puntos de acceso, etc.), que pueden enviar datos de registro de forma proactiva mediante la detección periódica de registros del sistema y/o cambios de configuración y luego reenviarlos a un servidor central. El servidor central decodifica y analiza la entrada y pasa los resultados al clúster de Elasticsearch para su indexación y almacenamiento.
Un clúster de Elasticsearch es una colección de uno o más nodos (servidores) que se comunican entre sí para realizar operaciones de lectura y escritura para el índice. Un clúster de un solo nodo puede manejar fácilmente implementaciones pequeñas de Wazuh (50 agentes). Se recomienda la agrupación en clústeres de múltiples nodos si tiene una gran cantidad de sistemas monitoreados, espera grandes volúmenes de datos y/o requiere alta disponibilidad.
Cuando el servidor Wazuh y el clúster de Elasticsearch están en hosts diferentes, Filebeat puede reenviar de forma segura alertas de Wazuh y/o eventos archivados al servidor de Elasticsearch mediante cifrado TLS.
El siguiente diagrama ilustra la distribución de componentes cuando un servidor Wazuh y un clúster de Elasticsearch se ejecutan en diferentes hosts.
En implementaciones de Wazuh más pequeñas que utilizan una instancia de Elasticsearch de un solo nodo, Wazuh y la pila Elastic se pueden implementar en un solo servidor. En este caso, Logstash puede leer las alertas de Wazuh y/o archivar eventos directamente desde el sistema de archivos local y enviarlos a la instancia local de Elasticsearch.
IV.Comunicación y flujo de datos
4.1 Comunicación agente-servidor
El agente Wazuh utiliza el protocolo de mensajería OSSEC a través del puerto 1514 (UDP o TCP) para recopilar los Eventos se envían al servidor Wazuh. Luego, el servidor Wazuh decodifica y utiliza un motor de análisis para realizar comprobaciones de reglas en los eventos recibidos. El evento que desencadena la regla agrega datos de advertencia, como el ID y el nombre de la regla. Dependiendo de si una regla se activó o no, los eventos se pueden almacenar en uno o ambos de los siguientes archivos:
El archivo /var/ossec/logs/archives/archives.json contiene todos los eventos, ya sea que se hayan activado o no. una regla o no.
El archivo /var/ossec/logs/alerts/alerts.json contiene solo los eventos que activaron la regla.
El protocolo de mensajería Wazuh utiliza cifrado Blowfish de 192 bits (16 rondas completamente implementadas) o cifrado AES (128 bits por bloque, clave de 256 bits).
4.2 Comunicación Wazuh-Elastic
En implementaciones grandes, el servidor Wazuh utiliza Filebeat para enviar datos de alertas y eventos a través del cifrado TLS a loghide (5000/TCP) en el servidor Elastic Stack. Para una arquitectura de host único, Logstash puede leer eventos/alertas directamente desde el sistema de archivos local sin usar Filebeat.
Logstash formatea los datos entrantes y opcionalmente los enriquece con información GeoIP antes de enviarlos a Elasticsearch (puerto 9200/TCP). Una vez que los datos se indexan en Elasticsearch, se utiliza Kibana (puerto 5601/TCP) para extraer y visualizar la información.
La APP Wazuh se ejecuta en Kibana y consulta continuamente la API RESTful (puerto 55000/TCP en Wazuh Manager) para mostrar información relacionada con la configuración y el estado del servidor y el proxy, reiniciándose cuando sea necesario actuar. Esta comunicación se cifra mediante TLS y se autentica mediante nombre de usuario y contraseña.
v. Puertos requeridos
Al instalar el stack Wazuh y Elastic, deben estar disponibles y abiertos varios puertos de red para que los diferentes componentes puedan comunicarse correctamente.
6. Almacenamiento de datos en archivos
Además de enviarse a Elasticsearch, los eventos de alerta y no alerta también se almacenan en archivos en el servidor Wazuh. Estos archivos pueden estar en formato JSON (.JSON) y/o en formato de texto plano (registro - sin campos de decodificación, pero más compacto). Estos archivos se comprimen y firman diariamente mediante sumas de comprobación MD5 y SHA1. La estructura de directorio y nombre de archivo es la siguiente:
Se recomienda rotar los archivos comprimidos y realizar copias de seguridad según la capacidad de almacenamiento del servidor Wazuh Manager. Al utilizar una tarea cron, puede programar fácilmente que solo se mantengan los archivos archivados en el administrador durante un período de tiempo específico (por ejemplo, el último año o los últimos tres meses).
Por otro lado, puede optar por no almacenar los archivos en absoluto y confiar completamente en Elasticsearch para almacenarlos, especialmente si ejecuta copias de seguridad instantáneas de Elasticsearch con regularidad y/o utiliza réplicas fragmentadas para alta disponibilidad. en múltiples nodos. Incluso puede utilizar un trabajo cron para mover el índice de la instantánea al servidor de almacenamiento de datos final y firmarlo utilizando los algoritmos MD5 y SHA1.