Guía Básica para integración de tecnologías mediante Protocolo SYSLOG

La importancia de analizar los eventos generados por las tecnologías de la información, así como las infraestructuras relacionadas nos ayudará a generar diversos indicadores los cuales pueden ser analizados según las necesidades del negocio de cada organización, e incluso dentro de la misma organización estos datos pueden ser analizados según cada área. Para poder analizar tanta información generada por las tecnologías es necesario contar con herramientas especializadas para minar datos. Cada proyecto tiene sus propias necesidades y surgen continuamente nuevas tecnologías de código abierto, bajo licencia o herramientas personalizadas donde siempre es necesario contar con información del cómo poder generar analíticas con estas nuevas tecnologías aprovechando las características que cada una ofrece.

En específico Wazuh al tratarse de una tecnología emergente de opensource orientada a generar indicadores minando datos de eventos, propone diversas integraciones sin límite alguno al ser una tecnología de código abierto requiere en algunos casos de configuraciones no tan claras como lo podria tener alguna tecnología con licencia como lo puede ser Splunk. Ante el escenario, en el cual se tiene como objetivo la integración de una tecnología a esta plataforma mediante syslog, a lo largo de este documento se establecerá consejos y tecnicas de como lograr una integración adecuada sin tener que pasar por esa etapa de frustración al no encontrar las respuestas ante esta problemática.

¿Qué es Wazuh?

Wazuh es una plataforma opensource para detección de amenazas, monitoreo de seguridad, respuesta a incidentes y cumplimiento normativo, con capacidad para monitorear servidores locales, servicios en la nube y contenedores.

Wazuh es un recurso importante para lograr el cumplimiento normativo de seguridad.

Los componentes principales que caracterizan la herramienta wazuh son los siguientes:

Recopilación de registros (log collection).
Análisis de registros (log analysis), se pueden personalizar un conjunto de 3000 reglas HIDS.
Monitoreo de integridad de archivos (File Integrity Monitoring).
Detección de anomalías basadas en host (Host-based anomaly detection).
Escaneo de cumplimiento de seguridad para vulnerabilidades (Security compliance scanning for know vulnerabilities).
Alertas en tiempo real (Real time alerting) por e-mail, SMS, Slack por mencionar algunas.
Respuesta activa (Active response) es una implementación de IPS impulsada por HIDS.

También se encuentra disponibles los agentes de wazuh para las siguientes plataformas:

Linux (Debian, CentOS, RedHat, SUSE, Amazon Linux, etc)
BSD (FreeBSD, OpenBSD y NetBSD)
Solaris (10 & 11)
AIX (5.3 o mayores)
MacOS
Windows
HP-UX (11v3)

Para la descarga e instalacion de la ultima version de wazuh y paquetes relacionados favor de acceder al siguiente enlace:

https://wazuh.com/start/

Y para consultas o documentación favor de acceder a al siguiente enlace:

https://documentation.wazuh.com/3.13/index.html

INTERFAZ WEB WAZUH

Interfaz-Wazuh

Arquitectura de Wazuh

Arquitectura-Wazuh

Componentes principales

protocolo wazuh

Es factible ejecutar el proceso de wazuh en un entorno con root o con un usuario sin privilegios dependiendo de la situación.

El servicio en linux se ejecuta ya se a con systemctl, service o initctl, en el caso de windows se utiliza C:\Program Files (x86)\ossec-agent\win32ui.exe.

A continuación se muestra un diagrama del flujo de las comunicaciones de red.

wazuh-guia

Las conexiones Agent-Manager se comprimen y cifran con claves precompartidas (AES) por agente a través de tcp o udp 1514.
Remoted puede aceptar directamente mensajes TCP y/o UDP puerto 514 desde dispositivos de envío de syslog.
Para una recopilación de syslog centralizada más robusta, los servidores de syslog se pueden usar en agentes o administradores.

Todas las comunicaciones de Wazuh se autentican y cifran mediante cifrado AES o TLS.

Los nodos de trabajo del administrador de Wazuh usan TLS para sincronizar la configuración y los datos de estado con el nodo maestro del administrador.

A cada agente se le asigna su propia clave criptográfica para informar al manager.

Si bien se ha creado una separación y aislamiento de privilegios significativos, aún es aconsejable fortalecer aún más el servidor de Wazuh, ya que muchos otros sistemas dependerán de él y se verán influenciados por él, especialmente si los comandos remotos están habilitados.

Estableciendo la conexión

La primera parte en la que uno se enfrenta al integrar una nueva tecnología hacia la solución Wazuh, es el cómo?.

Existen dos opciones principales para el envío de información hacia la solución Wazuh, la primera opción es mediante la instalación de un agente que envíe los eventos al wazuh manager, la segunda opción mediante la conexión syslog hacia el Wazuh manager, en este caso vamos a exponer el cómo integrar una tecnología mediante syslog.

Para la integración mediante syslog hacia Wazuh la solución se presenta de manera clara en la documentación, por lo que en algunos casos no presenta mayor problema el realizar esta configuración que está compuesta por 5 etiquetas clave valor como se muestra a continuación.

https://documentation.wazuh.com/3.8/user-manual/capabilities/log-data-collection/how-it-works.html

<connection>syslog</connection>

<allowed-ips>192.168.2.0/24</allowed-ips>

</remote>

Analizando los eventos

Una vez establecido la recepción de eventos se procede a analizar los mismos, Wazuh cuenta con decoders que sirven para identificar eventos y extraer campos críticos o importantes de los mismos, por parte de Wazuh existe una serie de decoders predeterminados los cuales son eficientes para algunas tecnologías pero en la mayoría de los casos estos decoders tienen sus limitantes y no proveen la información requerida al momento de trabajar con los eventos, esto resulta en tiempo invertido en vano en investigar si existe algún trabajo ya hecho, por lo que al momento de realizar una correcta integración es mejor realizar un decoder personalizado.

Lo primero es obtener una muestra de evento o eventos:

Feb 19 14:16:08 ISE-SF CISE_Administrative_and_Operational_Audit 0003835838 1 0 2020-02-19 14:16:08.414 -06:00 0109300897 60134 NOTICE System-Management: DNS Resolution failure, ConfigVersionId=142, AdminInterface=CLI, AdminIPAddress=127.0.0.1, AdminName=system, OperationMessageText=DNS resolution failed for the hostname ISE-SF against the currently configured name servers., AcsInstance=ISE-SF,

Feb 25 09:13:49 ISE-SF CISE_Administrative_and_Operational_Audit 0003867949 1 0 2020-02-25 09:13:49.508 -06:00 0110068270 51002 NOTICE Administrator-Login: Administrator logged off, ConfigVersionId=142, AdminInterface=GUI, AdminIPAddress=xxx.xxx.xxx.xxx, AdminSession=AdminGUI_Session, AdminName=xx, OperationMessageText=User logged out,

Lo principal al momento de analizar los eventos es identificar los campos o las cadenas que identifican este evento de un universo entero de eventos, estas cadenas deben de identificar única y exclusivamente a esta tecnología, por lo que al identificar esta cadena o campo se nombrará como cadena o campo padre, esto nos permitirá generar un decoder padre que de él saldrá todas las posibles variantes que presentan los eventos de esta tecnología.

Del ejemplo anterior se puede identificar los campos Fecha, Hora y nombre de la tecnología como el evento padre.

Feb 19 14:16:08 ISE-SF CISE

Una vez identificado este evento padre se debe de generar su respectiva expresión regular tomando en cuenta la sintaxis de expresiones regulares de ossec.

https://www.ossec.net/docs/syntax/regex.html

Cuando se tiene la expresión regular padre se genera el decoder padre con la siguiente sintaxis:

<decoder name="ise-decoder">

<prematch>CISE\w\.+\s\d+\s\d+\s\d+\s</prematch>

</decoder>

En la etiqueta de prematch se ingresa la expresión regular que identifica el evento padre, esta etiqueta identifica en un universo de eventos que única y exclusivamente cumplan con el criterio establecido por la expresión regular.

Después de obtener el evento padre se puede obtener los campos que se denominan eventos hijos a partir del decoder padre, estos eventos se pueden extraer ya sea con una expresión regular que extraiga todos los eventos o hacer una extracción campo por campo.

Extracción de eventos mediantes campo por campo.

Para extraer de manera eficiente campo por campo es necesario tener un decoder padre como se muestra en el documento y analizar el evento completo como se muestra a continuación:

Lo primero que se debe de hacer es identificar algún carácter, número o cadena que separe los campos, esto con el fin de generar una expresión regular que identifique única y exclusivamente el campo, ya que en algunos casos el mismo campo puede estar en una posición diferente dependiendo del evento que entregue la tecnología.

En el ejemplo anterior se identifica que los campos están separados por el signo ( , ) esto nos servirá a generar la siguiente expresión regular:

AdminInterface=(\w+),|(\.*)$

La expresión regular se compone de lo siguiente: el nombre del campo (AdminInterface) seguido del signo (=), el valor del campo que en este caso está compuesto por caracteres (\w) seguido del signo (+) el cual indica que habrá uno o más caracteres, el signo que identifica el fin del campo (,) , el signo de ( | ) genera un “OR” entre múltiples patrones. la expresión “(\.*)$” indica que si la información del campo no cumple con el criterio establecido de \w+, tome cualquier carácter o no como lo expresa el signo (*), esto quiere decir que el campo puede tener información o no, asimismo se asegura lo siguiente con el signo ($) que este campo puede ser el final del evento o estar en alguna parte del mismo.

Al final el evento se integrará de la siguiente manera al decoder.

<decoder name="ise-decoder">

<parent>ise-decoder</parent>

<regex>AdminInterface=(\w+),|(\.*)$</regex>

<order>admininterface</order>

</decoder>

Donde parent es el nombre del evento padre de la tecnología y order es el nombre del campo que se indexara en elasticsearch, se visualizará en Kibana y en la app de Wazuh.

Generando las reglas (alertas)

Una vez finalizado el proceso de análisis de eventos y extracción de campos, el siguiente paso es generar las reglas con los campos y eventos previamente extraídos para así desplegar estas reglas como alertas en la App de Wazuh, generando los índices correspondientes de manera predeterminada mediante Filebeat y así poder visualizar estas alertas mediante Kibana.

Así como los decoders existen reglas predeterminadas en Wazuh para ciertas tecnologías, en específico se plantea en esta sección el caso en el que se quiere utilizar un campo extraído y no uno generado de manera predeterminada, para poder lograr este objetivo es necesario utilizar el siguiente formato de clave valor dentro del archivo de reglas generadas:

<field name="nombre del campo">Valor del campo</field>

Es importante otorgar el nombre exacto del campo entre los símbolos (“ ”) para que la regla reconozca mediante el decoder el campo con el que trabajara, después de ingresar el nombre del campo se ingresa el valor del campo, el cual puede generar la alerta o establecer una condición padre de la cual derivar varias alertas.

<rule id="100010" level="4">

<if_sid>1000000</if_sid>

<field name="administrator_login">Administrator authentication failed</field>

<description>Login Fail - ISE</description>

</rule>

*Nota las reglas personalizadas deben de tener un rule id > 100,000 ya que una cifra menor está reservada por las reglas predeterminadas de Wazuh y esto podría provocar conflictos entre las reglas predeterminadas y las personalizadas

Pintando las alertas en el Dashboard

El dashboard será el producto final de una integración eficiente, ya que es la conclusión del análisis de eventos, la extracción de campos y la creación de reglas que derivan en alertas.

En Kibana los dashboard son conformados por uno o varios paneles por lo que se generará en primera instancia los paneles que conforman el dashboard.

Para generar un dashboard basta con tener la idea de que es lo que se va presentar en el.

En el siguiente ejemplo se genera un panel con base en el id de la regla generada y la Ip del agente, en ambos casos los filtros se pueden generar tanto en la parte de Query como de Filter.

La parte superior donde está situada la IP corresponde al campo de Queries y la parte inferior donde se presenta el id de la regla corresponde al apartado de Filter.

*Nota: La sintaxis varía con respecto al campo de Queries y Filter.

Una vez generado los filtros necesarios para especificar la búsqueda y reducir tiempos de búsqueda, se procede a exponer la información de la alerta con base en los campos que contiene la misma.

Wazuh

wazuh

Una vez extraídos los campos se despliega la información en el panel y este se ingresa en el dashboard para finalizar el proceso de integración de cero a dashboard expuesto en el blog.

Panel-Ciberseguridad

Panel-integracion-wazuh

Conclusión

A través de este blog se mostró a detalle el cómo integrar una tecnología mediante syslog hacia Wazuh, desde la configuración del entorno Wazuh para recibir eventos a través de syslog, el análisis de los eventos recibidos para extraer los campos críticos y formar un campo padre, para así obtener eventos que identifiquen cada tecnología, con los campos generados se formaron reglas mediante los campos extraídos para así presentar estas alertas mediante paneles que conforman los dashboard a visualizar.

Con estos pasos se realiza una integración adecuada de cualquier tipo de tecnología a Wazuh otorgando los tips para lograr esta integración de manera efectiva sin la necesidad de invertir tiempo en documentación no disponible con facilidad.