Esta es la tercera parte de un artículo basado en una charla que quería tener para una conferencia que planeábamos hacer en conjunto con Whilolab para inicios del 2020. Pero claro… pandemia.
Si quieres ver los artículos anteriores, están acá: Un ED (casi EDR) gratis para tu casa y/o PyME (Parte 1), Un ED (casi EDR) gratis para tu casa y/o PyME (Parte 2)
En esta parte vamos a terminar con las alertas que podemos configurar para que nos alerte sobre ciertas anomalías. Queremos que quede el diseño final como lo que habíamos planteado en este diagrama:
Tercera Parte: Generando las alertas
En esta parte vamos a ver cómo generar las alertas sobre nuestros datos almacenados en Elasticsearch. Como queremos mantenernos en el lado “gratis” necesitamos instalar un sistema para poder revisar constantemente y alertar ante alguna de estas anomalías; aquí aparecen dos nuevos componentes ElastAlert y las reglas Sigma.
Este sistema ElastAlert fue creado por Yelp para monitorear anomalías y otro tipo de patrones dentro de datos en Elasticsearch. En el fondo lo que hace es generar búsquedas constantemente y cuando encuentra resultados te alerta de alguna de las formas definidas en la configuración
Para la instalación basta seguir los pasos del mismo Github, pero un resumen sería lo siguiente:
git clone https://github.com/Yelp/elastalert.git
cd elastalert
sudo pip3 install "setuptools>=11.3"
sudo python3 setup.py installCon eso tenemos la aplicación instalada, pero todavía necesitamos generar la configuración inicial para que tengamos el monitoreo constante. Por un diseño mental preferimos definirlo todo dentro de la carpeta /opt/elastalert/, entonces necesitamos crearla:
sudo mkdir -p /opt/elastalert/rules/
sudo chown www-data.www-data -R /opt/elastalert/Ahora podemos partir copiando el archivo de configuración de la misma carpeta (config.yaml.example) a la nueva carpeta de nuestra configuración o sencillamente generando uno nuevo con la configuración básica:
sudo echo '
rules_folder: /opt/elastalert/rules
run_every:
minutes: 1
buffer_time:
minutes: 15
es_host: localhost
es_port: 9200
writeback_index: elastalert_status
writeback_alias: elastalert_alerts
alert_time_limit:
days: 2
' > /opt/elastalert/config.yaml
sudo chown www-data.www-data /opt/elastalert/config.yamlLuego tenemos que agregar más cosas en esta configuración, pero por ahora puede quedar así.
Si revisamos la configuración, tenemos definido que hay una carpeta /opt/elastalert/rules/ en la que se van a definir las reglas que tiene que revisar el sistema, entonces ahora comencemos a probar algunas.
Las reglas sigma
Las reglas sigma son otro de los pilares en que nos basaremos para poder monitorear nuestros equipos. Estas son un conjunto de patrones que ha definido la comunidad de investigadores de seguridad, patrones que pueden indicar algún tipo de anomalía.
Una de las grandes gracias de las reglas sigma es que están basadas en un formato estándar, el cual se puede traducir a distintos tipos de formatos con el “sigma converter”.
Y no solo se pueden traducir a idioma “Elastic” sino que tiene muchas otras traducciones:
De hecho podemos ver que tiene 2 traducciones para Elastalert, dependiendo del tipo de lenguaje de la consulta hacia Elasticsearch.
Lo interesante del repositorio está en la carpeta “rules”, que es donde se almacenan todas las posibles reglas de comportamientos anómalos.
Si uno comienza a revisar el directorio podemos ver que al día de hoy tenemos 661 reglas distintas que nos pueden apoyar en los monitoreos de distintos sistemas.
Por ejemplo, si revisamos la regla en sigma/rules/windows/sysmon/sysmon_ads_executable.yml:
Esta regla quiere detectar cuando se oculta un archivo ejecutable dentro de un Alternate Data Stream. Para ello lo que hace es revisar los logs de creación de uno de estos Streams y buscar si es que existe algún Imphash (hash de tabla de importación).
Revisando el formato de la regla, podemos ver varios detalles, por ejemplo, que se requiere como “logsource” los logs de Sysmon y que además tengan configurado los Imphash (que bueno que ya los habíamos configurado!).
Inicialmente podemos intentar con el traductor integrado con sigma y desde la carpeta base del repositorio clonado de sigma tenemos que hacer lo siguiente:
tools/sigmac -c winlogbeat --target elastalert rules/windows/sysmon/sysmon_ads_executable.yml > /opt/elastalert/rules/windows_sysmon_ads_executable.yml
No hay que confiarse con “traducir la regla X a Elastalert” porque no siempre quedan bien alineadas, es necesario revisar si es que te va a servir o no.
De hecho al revisar los campos que me llegan al Elasticsearch, no aparece el “winlog.event_data.Imphash” sino que ese dato lo tengo en el campo “hash.imphash” o en “file.pe.imphash”.
En este caso, podemos ir directamente al panel de Kibana y poner el parametro “query” completo para revisar si es que saldrá algún resultado y ajustarlo a nuestra conveniencia:
Por lo que la alerta me va a quedar así:
winlog.channel:"Microsoft\-Windows\-Sysmon\/Operational" AND winlog.event_id:"15" AND hash.imphash:* AND NOT (hash.imphash:("00000000000000000000000000000000" OR "00000000000000000000000000000000"))Y luego de modificar la regla podemos testearla en el formato de ElastAlert con el siguiente comando:
elastalert-test-rule --config /opt/elastalert/config.yaml /opt/elastalert/rules/windows_sysmon_ads_executable.yml
Gatillando la alerta por Telegram
Para que las alertas de verdad hagan sentido necesitamos enterarnos en el momento en que estas alertas se gatillen. Podríamos usar las alertas por correo, pero como siempre llegan muchos correos, y uno generalmente los ignora, prefiero usar los bots de Telegram.
No vamos a entrar en detalle, pero para crear el Bot pueden seguir alguna de las varias guías online para esto, como https://core.telegram.org/bots#creating-a-new-bot o https://blogthinkbig.com/crear-bot-de-telegram-botfather, pero lo que necesitamos lograr son 2 datos: telegram_bot_token y telegram_room_id.
El Bot token lo tenemos de manera sencilla al crear el bot:
El room id es el identificador de la sala de chat a la que quieras enviar los mensajes de Telegram, y para ello, lo más fácil es interactuar con el bot recién creado a través de Telegram Web, y ahí ver cual es el id de la sala que aparece.
Con ambos datos tenemos que editar la regla recién creada para agregarle esa configuración de alerta. En este caso le voy a agregar los campos de Telegram, y además una configuración extra, para definir cuál de los campos quiero recibir como parte del mensaje. Esto quedaría así:
Ahora la parte final!
Para probar que toda la configuración funciona, en el server tienen que dejar corriendo ElastAlert, y si sólo quieren probar con esta regla pueden ejecutar el comando:
elastalert --config /opt/elastalert/config.yml --rule windows_sysmon_ads_executable.ymlLuego en el cliente monitoreado tienen que generar algún comportamiento malicioso como este, por ejemlo, si es que tienen un ejecutable como Putty, pueden hacer lo siguiente:
type putty.exe > inyectado.txt:putty.exeY al paso de algunos segundos/minutos:
(Opcional) Dejando todo un poco más ordenado
Para dejar Elastalert como servicio basta configurarlo en systemd, esto se puede hacer de la siguiente forma:
sudo echo '[Unit]
Description=Severe_logalerts
After=elasticsearch.service
[Service]
Type=simple
User=www-data
Group=www-data
WorkingDirectory=/opt/elastalert
ExecStart=/usr/local/bin/elastalert --verbose --config /opt/elastalert/config.yaml
[Install]
WantedBy=multi-user.target
' > "/etc/systemd/system/elastalert.service"
sudo systemctl daemon-reload
sudo systemctl enable elastalert
sudo systemctl restart elastalertCon esto no es necesario mantener la ejecución de elastalert, pero sí hay que reiniciar el servicio cada vez que se agregue o quite alguna de las reglas de la carpeta /opt/elastalert/rules/
Ojalá que les haya gustado y que les sirva para mejorar la visibilidad de lo que está pasando en sus sistemas.
En un futuro compartiremos más reglas para usar en este tipo de monitoreo.
Muchas gracias por leer hasta acá.
FINSIN 