En el post de apertura sobre el mundo de los SIEM hablamos sobre algunos de los productos finales ampliamente desplegados por los equipos de IT para la monitorización de infraestructuras o servicios, nos referimos a: Splunk, QRadar de IBM, Fortisiem, AlienVault y ELK (Elastic).

De este último, ELK o Elastic, comentamos en la anterior entrega que se trataba de un stack de proyectos que, aun siendo desarrollados en el seno de la misma compañía y aunque independientes entre si, fueron concebidos para proporcionar una sinergia absoluta entre todos ellos y con esto solventar problemas derivados de la monitorización masiva de servidores, tratados de logs y presentación de los datos recabados; recordemos el workflow estándar de esta solución:

Workflow típico de Elastic

Al inicio, y entendiendo que para que este tipo de proyectos open-source pueda mantener un estándar de calidad, así como un ciclo elevado de actualizaciones, se requiere de una gran comunidad y profesionales que le den soporte; para mantener estos ritmos decidieron desde Elastic ofrecer algunas características premium que mejoraban o extendían las ya ofrecidas por el producto open-source. Estas características extras que trabajan por encima del stack son conocidas como X-Pack. Hasta la fecha existen diversos plugins distribuidos en forma de X-Pack, entre ellos:

  • X-Pack Security  (Elasticsearch Security)
  • X-Pack Alerting (Elasticsearch Alerting)
  • X-Pack Monitoring (Elasticsearch Monitoring)
  • X-Pack Reporting (Reporting)
  • X-Pack Graph (Graph)
  • X-Pack Machine Learning (Machine Learning)

Aunque como mencionamos en el párrafo anterior estas características extendidas fueron concebidas como un modo de monetización del stack, desde junio de 2018, junto con la liberación de la versión 6.3.0 del stack, muchas de estas características adicionales que desde Elastic mantenían en repositorios privados de Github fueron liberadas bajo una licencia permisiva (Elastic License) que permite la contribución a las mismas y forks. Acción que nos encanta, aquí vemos un claro ejemplo de crecimiento exponencial de una empresa manteniendo un compromiso con la comunidad.

En la siguiente imagen podemos ver algunas de las empresas que han adoptado Elastic como solución SIEM:

¿Quién usa Elastic? fuente: elastic.co

Una vez hechas las presentaciones sobre los componentes básicos del stack y sobre la historia reciente de la empresa que hay detrás, es hora de comenzar a ver algo más detalladamente cada uno de estos componentes, recapitulemos:

  • Logstash – Tratamiento de datos pre-ingesta
  • Elasticsearch – Persistencia de datos
  • Kibana – Presentación de información
  • X-Pack (opcionales) – Extensión de características

El lector avispado notará que ninguno de los componentes enumerados anteriormente son relativos al cliente, es decir, hasta ahora solo hemos visto componentes que entran en juego una vez recibidos los datos en el servidor que aglutina el stack, pero, un momento … ¿quién envía esos datos? hablemos de Beats!

Resultado de imagen de beats elastic

Beats

Beats lo componen una serie de shippers encargados de supervisar una serie de registros de eventos, ficheros, logs o datos del equipo y enviarlos (de ahí lo de shippers) a Logstash para su posterior tratado (en caso necesario), antes de ser ingestados por Elasticsearch. Estos shippers o clientes ligeros como algunos prefieren llamarlos por los pocos recursos que consumen, están escritos en Go. Actualmente, tal y como podemos comprobar en el siguiente repositorio https://github.com/elastic/beats,  contamos con los siguientes Beats:

Beats fundamentales
  • Auditbeat – integraremos en el reglas de auditctl para enviar cambios en archivos, ejecuciones de binarios, systemcalls, etc.
  • Filebeat – envía logs generados por servicios, por ejemplos logs de Apache o Nginx y cualquier otro log basado en texto plano.
  • Functionbeat – nos permite enviar datos de nuestra nube (AWS por ejemplo)
  • Heartbeat – para comprobar la disponibilidad de la máquina (ping).
  • Journalbeat – envía información de eventos registrados en el journald de la máquina (porque todos amamos a systemd 😊, ¿verdad?), esto podría hacerse con Filebeat si no fuera porque journald no almacena estos registros en texto plano, sino en binarios.
  • Metricbeat – recopila y envía métricas de los recursos y servicios
  • Packetbeat – monitoriza y envía datos sobre los paquetes (capa de red) que transcurren o se originan en la máquina monitorizada.
  • Winlogbeat – envía información registrada en los Windows Event Logs
  • … más todos los creados por la comunidad

Una vez que conocemos el componente encargado del envío de los datos desde las máquinas o servicios a monitorizar pasemos al siguiente componente, Logstash.


Logstash

Logstash es el componente que intercepta cualquier dato que vaya a ser ingestado por Elasticsearch para proceder con su parseo y tratado, si procede, y enviarlo a Elasticsearch con un formato específico creado por nosotros, para esto hace uso de filtros, que realizan una serie de operaciones sobre los datos que llegan al input de Logstash para procesarlos y crear un output estandarizado por nosotros con los datos relevantes. Existen multitud de filtros, como por ejemplo el filtro xml que parsea archivos xml en campos, useragent, que parsea la entrada en busca de user-agents , geoip, que añade información geográfica a las ip que recibe como inputs o, y siendo este el más versátil de todos, GROK, que parsea (valiéndose de expresiones regulares) los datos que llegan al input de Logstash como datos no estructurados para crear campos y de ahí, datos estructurados, sobre los que después poder hacer consultas una vez los enviemos por el output a Elasticsearch.

Logstash es mucho más que un simple recolector de logs puesto que puede recibir datos de diferentes fuentes, ya sea estructurada o no, y realizar un tratado de la misma para democratizarla y enviarla a Elasticsearch para su indexación ordenada, para esto establece 3 pipelines básicos por los que fluirán los datos:

Logstash es mucho más que un simple recolector de logs puesto que puede recibir datos de diferentes fuentes, ya sea estructurada o no, y realizar un tratado de la misma para democratizarla y enviarla a Elasticsearch para su indexación ordenada, para esto establece 3 pipelines básicos por los que fluirán los datos:

  • Input – entrada de datos (puede ser desde un archivo, syslog, Beats, etc)
  • Filter (grok, xml, geoip, etc)
  • Output (Elasticsearch, un archivo, etc)

El siguiente componente, y pilar central de la persistencia de datos en el stack es Elasticsearch.

Una vez que ya tenemos los datos enviados desde las maquinas a monitorizar, han sido convenientemente parseados y/o tratados por Logstash, debemos trasladarlos por el pipeline output de Logstash hacía la solución de persistencia del stack, en este caso, Elasticsearch.

Resultado de imagen de elasticsearch


Elasticsearch

Tal y como se describe en la página oficial de Elastic, Elasticsearch es un motor de búsqueda full-text basado en Apache Lucene. Además de esto podemos decir que básicamente estamos una base de datos NoSQL que almacena documentos en formato JSON dentro de índices de Apache Lucene y que usa unas estructuras llamadas “índices invertidos” que de manera resumida consiste en crear un índice en el que se incluye cada palabra de cada documento tras lo cual mantendrá actualizada una estructura en la que almacena para cada documento, si dicho termino encuentra un “match” u ocurrencia o no, seguro que si lo vemos gráficamente captamos el concepto:


Inverted Index de Elasticsearch

Este tipo de solución de almacenamiento nos permitirá hacer búsquedas rápidas a través de todos los índices además de permitirnos almacenar documentos basados en JSON de diversas fuentes de datos y con estructuras no fijas, schemaless. Otra de las virtudes de Elasticsearch es la potencia y facilidad que nos ofrece para interactuar con el a través de su API REST.

Ahora que tenemos los datos en forma de documentos de pares clave:valor (JSON), llega la hora de visualizar estos datos mediante dashboards personalizados y ajustados a nuestras necesidades y casuística particular, ha llegado el momento de KIBANA.

Imagen relacionada


Kibana

Kibana es una solución que trabajo por encima de todo el stack nutriéndose de la información almacenada en Elasticsearch y proporcionando vías de visualización en tiempo real de los índices de manera sencilla y directa, lo que nos permite tener una visión global de toda la información importante de los sistemas o servicios que estamos monitorizando además de permitir la creación de queries ajustadas a nuestras necesidades.

Dashboard de Kibana

Como podéis imaginar la implementación de un sistema como este en nuestra infraestructura informática nos permitirá mejorar tanto en las operativas de seguridad (son ampliamente usados en SOC), monitorización de servicios, métricas, etcétera, incluso con los módulos de machine learning son capaces de predecir tendencias futuras, por ejemplo, nos alertaría de picos de solicitudes a nuestros servidores web para que podamos escalar horizontalmente con kubernetes, todo ventajas!

Una vez hecha una pequeña presentación sobre cada uno de los elementos de Elastic estamos preparados para realizar un pequeño lab en el que adentrarnos en todas las fases de implementación de esta solución SIEM; desde instalar un shipper que forme parte de Beats en los equipos a monitorizar, configurar los pipelines de Logstash para recibir los datos enviados desde los equipos target, almacenar los datos en nuestra propia instancia de Elasticsearch y crear un primer dashboard con Kibana con el que obtener una visión global de los servicios y métricas monitorizados.

Todo esto en el siguiente post!

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.