Zeek - Sistema de monitorización (3)
En este último artículo (aquí capítulo anterior) vamos a realizar una prueba de concepto, es decir, una implementación práctica del escenario descrito en el Apartado “Escenario” del primer artículo para ver en funcionamiento los conceptos teóricos anteriormente explicados. [10]
Prueba de Concepto (PoC)
Para esta prueba en el archivo /usr/local/zeek/share/zeek/site/local.zeek hemos realizado algunas modificaciones como la activación de algunas políticas/scripts, como por ejemplo la política detect-bruteforcing de ftp que detecta los ataques por fuerza bruta realizados por FTP o la política scan que detecta los escaneos.
Todas estas políticas están situadas, como hemos visto anteriormente, en /usr/local/zeek/share/zeek/policy. Zeek trae muchas políticas por defecto, en Internet se puede encontrar más y en cada actualización van incluyendo políticas nuevas, puesto que es uno de los pilares de Zeek. En la monitorización la afinación de la herramienta conforme a las particularidades del sistema es un trabajo esencial y prolongado en el tiempo. Por esto, todos los scripts zeek que se vayan a utilizar pueden y deben ser modificados. Los scripts zeek traen al principio del código un apartado “export” con elementos que podemos modificar para adaptarlo a nuestra red:
Durante esta PoC hemos puesto a monitorizar Zeek durante un tiempo y, finalmente, lo hemos parado. Tras pararlo todo el contenido de la monitorización pasa de la carpeta current a la carpeta del día en el que se haya realizado dicha monitorización, y cada log es comprimido. Para facilitar el análisis del tráfico generado vamos a copiar todos los ficheros logs que Zeek ha generado a partir de las 18 horas y lo pegamos en otra carpeta donde procederemos a su análisis:
Por lo que finalmente nos quedamos con el siguiente contenido:
Como podemos observar el tráfico capturado es categorizado automáticamente por Zeek, conforme vayamos creando políticas podemos afinar esta categorización para mejorar la selección de datos y facilitar su posterior análisis.
Para este análisis vamos a hacer uso de las siguientes herramientas o comandos:
- zcat: Nos hace un ‘cat’, es decir, mostrar por pantalla, sobre archivos comprimidos.
- zeek-cut: Nos filtra el contenido de un log generado por Zeek por las columnas que le indiquemos. Con ‘-d’ podemos transformar la marca de tiempo del formato epoch a un formato que podamos comprender directamente.
- more: Con este comando iremos mostrando poco a poco el contenido del fichero, muy útil para ficheros de gran longitud.
A continuación, vamos a proceder a destacar y observar los logs más interesantes.
Comenzaremos por logs que nos ofrecen información general sobre la captura de tráfico realizada [11]. En conn-summary.log podemos observar diferentes tablas con información resumida, como por ejemplo los puertos y servicios con más tráficos, o las IPs origen y destino más frecuente en estos paquetes, tanto de todas las conexiones en general como del tráfico de salido o de entrada aisladamente. Y si estamos analizando distintas subredes nos informará de estas estadísticas del total de todas las subredes, así como de forma separada:
En software.log podemos ver el software utilizado por cada uno de los equipos de la red, así como su versión. Algo de gran utilidad para controlar que no se utiliza software desactualizado y vulnerable en nuestra red. Entre la información de nuestra prueba podemos ver como el host 192.168.12.87 está utilizando un Huawei MAR-L21A con Android 10. También podemos ver las versiones de Firefox, Apache o PHP, entre otras cosas, que utilizan los diferentes hosts de la red.
En capture_loss.log podemos ver en la columna gaps el número de ACKs perdidos, sobre los ACKs totales representados en la columna acks, así como el porcentaje de pérdidas:
En el archivo know_hosts.log nos indica todos los hosts detectados en la red y la fecha en la que fue detectado en esta captura de tráfico.
De la misma forma know_services.log nos informa de los servicios activos y los puertos por los que se están ejecutando. En la siguiente captura podemos observar que se han detectado muchos puertos abiertos sobre el host 192.168.12.30, por lo que sería interesante comprobar existe necesidad de que todos esos puertos deban estar abiertos y con servicios activos.
Y por último sobre el contenido general de los logs, mencionamos el archivo stats.log donde podemos ver información de la memoria en uso en MB, de los paquetes, de eventos, de conexiones (tcp, udp e icmp) y de archivos, esta información por tramos de tiempo de 5 minutos. Este tramo temporal de 5 minutos se puede cambiar modificando la política /usr/local/zeek/share/zeek/policy/misc/stats.zeek que genera este log.
En cuanto a ficheros con *información más concreta vamos a comenzar con conn.log, donde se registra todas las conexiones realizadas:
En este fichero podemos observar, por ejemplo, como existen muchas conexiones al puerto 22, SSH, realizadas sobre el host 192.168.12.30 y proveniente en intervalos de muy poco tiempo desde el host 192.168.12.130.
Si nos vamos a ssh.log, donde se recogen todas las conexiones SSH, podemos observar esto que vimos en la captura anterior con más claridad:
Podemos ver la resolución de nombres de dominios pedidas por los distintos hosts en dns.log:
El tráfico HTTP podemos verlo en http.log:
Y por último llegamos a dos ficheros fundamentales con información concreta y que, para su buen funcionamiento dependerá del buen trabajo en la configuración y mantenimiento de la herramienta y del conocimiento sobre la actividad general de la red monitorizada. El primer fichero es weird.log donde registra comportamientos extraños que no llegan a ser sospechosos:
Y el siguiente fichero, probablemente el más importante, es notice.log, donde veremos en funcionamiento las políticas que indicamos que activamos al inicio de este subapartado. En notice.log se registran eventos importantes que deben ser analizados, en nuestra captura tenemos el siguiente contenido en notice.log:
De lo mostrado vamos a fijarnos más concretamente en dos líneas. A las 18:23:27 podemos ver que Zeek detecta que el host 192.168.12.130 está realizando un escaneo de puertos sobre la red. Posteriormente, a las 18:48:25 podemos ver como Zeek detecta y advierte de que se está llevando a cabo un ataque por fuerza bruta a través de FTP, llevado a cabo por el host 192.168.12.130 el cual ha tenido 10 intentos fallidos de inicio de sesión durante un intervalo de 22 minutos y 14 segundos.
Conclusiones
Zeek es un sistema IDS que aporta muchísimas posibilidades, por lo que podríamos decir que es muy completo. Por otro lado, es muy destacable la existencia de una gran comunidad detrás, lo cual proporciona una documentación muy extensa y facilita la curva de aprendizaje. Esta gran comunidad también se nota en las actualizaciones de las herramientas, las cuales incluyen cada vez más contenido de interés.
Sobre la curva de aprendizaje hay que decir que es uno de los puntos negativos de este software, ya que para personas que no conozcan previamente el funcionamiento de otros IDS en detalle esta sería muy dificultosa. Además, Zeek cuenta con su propio lenguaje de programación para la elaboración de políticas, lo cual implica el poder ajustar Zeek mucho más pero también un trabajo costoso a la hora de aprender el funcionamiento de este lenguaje. Y no cuenta con una interfaz gráfica, puesto que se desarrolló inicialmente como una herramienta de investigación y no se centraron en la usabilidad ni la facilidad de instalación.
Por otro lado, y aunque en este documento no hayamos explorado esa posibilidad, se puede integrar zeek en sistema de tratamiento de logs, o insertar logs en bases de datos compatibles. Lo más común, y existen muchísimos tutoriales y guías para ello, es integrar Zeek con ELK Stack (es decir, Elasticsearch, Logstash y Kibana) para tener un sistema de monitorización muy completo. [12]
Más allá de las funcionalidades vistas en este documento, Zeek también puede descargar y enviar archivos de la red para un análisis de malware, realizar listas negras, apagar equipos, consultar IPs en bases de datos de reputación para tomar acciones… Las capacidades de Zeek son muy elevadas, pero para llevarlas a cabo hace falta abarcar esa curva de aprendizaje que comentamos.
Por lo que podemos decir que es una herramienta altamente recomendable si el interés y la apuesta por la monitorización es fuerte y decidida.
Referencias
[10] Analysing PCAPs with Bro/Zeek - darkdefender