- SigmaShooter (I): Preparando el SIEM Graylog.
- SigmaShooter (II): Generando nuestra primera firma Sigma.
- SigmaShooter (III): Desplegando SigmaShooter.
- SigmaShooter (IV): Ejecución automática de Sigma contra SIEM.
- SigmaShooter (V): DFIR con SigmaShooter.
Esta semana se publicaba la herramienta SigmaShooter, una aplicación web para gestionar firmas Sigma y ejecutarlas contra el SIEM Graylog en su primera versión:
En esta serie de posts veremos la utilización de la herramienta, desde que instalamos el SIEM y enviamos datos al sistema, hasta la ejecución automática de firmas Sigma contra el mismo. Dividiremos la serie en las siguientes entregas:
- SigmaShooter (I): Preparando el SIEM Graylog.
- SigmaShooter (II): Generando nuestra primera firma Sigma.
- SigmaShooter (III): Desplegando SigmaShooter.
- SigmaShooter (IV): Ejecución automática de Sigma contra SIEM.
- SigmaShooter (V): DFIR con SigmaShooter.
Así que en este post, empezaremos por el principio, instalar y configurar el SIEM Graylog.
1 Sobre esta guía
En la siguiente guía instalaremos la versión oficial de Graylog 3.2.4, que corresponde con la última versión en el momento de realización esta guía. Para ello, descargamos esta versión en formato OVA, la cual, ya nos ofrece la versión de Graylog preinstalada en una máquina virtual. Esta OVA la importaremos sobre el software de virtualización VMware Workstation, versión 15.5.1.
Podemos ver las descargas disponibles de Graylog en otros formatos desde el siguiente enlace:
https://www.graylog.org/downloads
2 Instalando Graylog desde OVA
Descargamos la última versión de Graylog estable disponible, en nuestro caso, es la versión 3.2.4, la cual se puede descargar del siguiente enlace:
https://downloads.graylog.org/releases/graylog-omnibus/ova/graylog-3.2.4-1.ova
Y la importamos en VMware desde “Open a Virtual Machine”:
Seleccionamos la OVA descargada y continuamos con la importación siguiendo las opciones por defecto.
Una vez importada, abrimos su configuración, desde el panel “Library”, el cual por defecto se muestra en la parte izquierda, clicamos con el botón derecho en la máquina importada, seleccionamos “Settings…”, y, dentro de la configuración, en la ventana de “Network Adapter” marcamos la opción de NAT, esta opción asignará de manera automática una dirección IP al servidor desde el cual podremos interactuar con el equipo anfitrión y con Internet, en el caso de que se quieran actualizar paqueterías o instalar alguna en concreto:
Aplicamos los cambios y ya podemos iniciar la máquina.
Una vez iniciada, accedemos con las credenciales que nos mostrará por pantalla, en nuestro caso ubuntu/ubuntu.
El servidor inicia el servicio SSH en su arranque por lo que también recomendamos acceder desde el cliente SSH favorito, en nuestro caso utilizaremos MobaXterm. Una vez accedido al servidor, el primer cambio que haremos será cambiar el teclado al español:
Accedemos por SSH $ ssh ubuntu@ Cambiamos teclado a español $ sudo loadkeys es
Una vez cambiado el teclado, recomendamos cambiar la contraseña en este momento por otra más segura, con el comando $ passwd <usuario>, ya que este usuario dispone de permisos para escalar a súper-usuario, root.
A continuación, generamos una contraseña para acceder a la consola web de Graylog, calculamos su hash sha256 y la copiamos en el fichero de configuración de la herramienta:
# Creamos nuestra contraseña y calculamos su hash sha256 $ echo -n "secret0" | sha256sum 97699b7cc0a0ed83b78b2002f0e57046ee561be6942bec256fe201abba552a9e - # Abrimos fichero de configuración de Graylog y pegamos el valor en la variable root_password_sha2 $ sudo vi /etc/graylog/server/server.conf
Configuración de la contraseña de admin en server.conf
# Reiniciamos el servidor para aplicar los cambios $ sudo graylog-ctl restart
Con estos cambios realizados, ya podemos acceder a Graylog directamente desde el navegador introduciendo la dirección IP del servidor y accediendo con las credenciales admin/<contraseña creada en el paso anterior>.
NOTA: para conocer la dirección IP del servidor se puede ejecutar el siguiente comando desde el terminal:
$ hostname -I | awk '{print $1}'
En el siguiente punto veremos la puesta en marcha de Graylog para empezar a enviar eventos al sistema.
3 Envío de Eventos a Graylog
En este punto describiremos las configuraciones necesarias para empezar a recibir eventos en el SIEM Graylog. Los datos enviados como ejemplo para comprobar su funcionamiento serán eventos generados en un sistema Windows.
3.1 Configuración de inputs en Graylog
Para poder recibir eventos en Graylog tendremos que crear inputs que son unos mecanismos de entrada de datos los cuales escuchan en un puerto configurado un tipo de dato elegido en la creación del input. Todos los datos enviados a dicho puerto con el formato correcto serán almacenados en la base de datos de Graylog, para posteriormente poder ser consultados desde la interfaz.
Para crear un input, desde la interfaz, nos desplazamos al desplegable System y seleccionamos Inputs:
Y desde la ventana de Inputs, seleccionamos por ejemplo el tipo de entrada GELF UDP, un tipo de formato de registro propio de Graylog que corrige y mejora algunas de las capacidades del clásico syslog:
Una vez seleccionado, pulsamos en el botón “Launch new input” para terminar de configurar el input. En la siguiente ventana nos aparecerán las opciones disponibles para configurarlo. En nuestro caso, se ha marcado la opción “Global”, para que el input se inicie en todos los nodos, se ha elegido el título “Windows Events”, ya que aquí es donde enviaremos todos los eventos Windows de los equipos, y se ha dejado el resto de los valores por defecto.
Finalizada la configuración, pulsamos en “Save” para guardar, y ya tendríamos nuestro primer input de Graylog configurado:
En el siguiente punto veremos cómo enviar eventos a este input y consultarlos a través de la interfaz.
3.2 Envío de eventos Windows a Graylog con NxLog
Ya creado el input en Graylog, disponemos del puerto 12201/UDP, seleccionado por defecto, para enviar datos en formato GELF.
En este punto, enviaremos eventos de Windows al SIEM, para ello accedemos a una máquina con sistema operativo Windows, en nuestro caso, para no afectar en gran medida el rendimiento del equipo anfitrión, se ha elegido una máquina virtual Windows 7, pero el procedimiento descrito a continuación es similar en todas las versiones de Windows 7 en adelante.
Además de los eventos generados por defecto por el propio sistema operativo, “Application”, “Security” y “System”, también enviaremos los eventos generados por la utilidad Sysmon, de Microsoft, la cual aporta en formato evento de Windows más información detallada de la actividad del sistema. En el siguiente punto describimos más detenidamente la funcionalidad de Sysmon y su instalación en un sistema Windows. Si ya se tiene instalado Sysmon en el equipo o no se va a utilizar este tipo de información, puede saltar al siguiente punto.
3.2.1 Instalación de Sysmon en Windows
Sysmon, System Monitor, es un servicio creado por Sysinternals, de Microsoft, que trabaja a nivel de controlador en el equipo para recopilar información de toda la actividad relevante que sucede en un sistema Windows, como procesos creados, conexiones de red o cambios en la hora de creación de los ficheros, entre otros.
Se puede encontrar más información sobre este servicio en el siguiente enlace:
https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon
Para instalar Sysmon, descargamos la última versión desde el enlace anterior y abrimos un terminal con permisos de administrador:
Para la instalación de Sysmon es recomendable definir un fichero de configuración de los eventos que se deseen generar, ya que con la configuración por defecto podemos perder eventos relevantes del sistema de nuestro interés. Para esta instalación vamos a utilizar el fichero de configuración de Sysmon realizado por SwiftOnSecurity que ofrece una configuración interesante para generar los eventos más relevantes del sistema midiendo no afectar en gran medida el rendimiento del equipo. Esta configuración se puede encontrar en el siguiente enlace:
https://github.com/SwiftOnSecurity/sysmon-config
Con Sysmon y el fichero de configuración ya descargados, instalamos el servicio con el siguiente comando:
> sysmon.exe -accepteula -i sysmonconfig-export.xml
NOTA: utilizar la versión de 64 bits del instalador de Sysmon para sistemas operativos con esta arquitectura.
En el proceso de instalación se incluye Sysmon para que arranque cada vez que se inicie el sistema operativo.
Una vez finalizada la instalación, podemos ver en la ruta del visor de eventos de Windows, Visor de eventos > Registros de aplicaciones y servicios > Microsoft > Windows > Sysmon > Operational, los eventos de Sysmon que se van generando:
3.2 Envío de eventos Windows a Graylog con NxLog (cont.)
Volviendo al punto principal en el que nos encontrábamos, y ya habiendo definido los eventos de Windows a enviar a Graylog, procederemos a instalar la utilidad NxLog para enviar estos datos al SIEM.
NxLog es una herramienta de administración de registros multiplataforma que cuenta con múltiples librerías para analizar sintácticamente los datos a enviar, normalizar estos eventos y enviarlos con el formato definido hasta un punto de destino.
En nuestro caso, instalaremos NxLog y lo configuraremos para recolectar los eventos de Windows definidos y enviar estos valores al input de Graylog, creado en los puntos anteriores.
Descargamos la última versión de NxLog desde el siguiente enlace:
https://nxlog.co/products/nxlog-community-edition/download
E instalamos el programa, con todos los valores por defecto, aceptando los términos de uso de la aplicación:
En el proceso de instalación se incluye NxLog para que arranque cada vez que se inicie el sistema operativo.
Una vez instalado, abrimos su fichero de configuración con nuestro editor preferido con permisos de administrador:
Y copiamos la siguiente configuración para enviar los eventos de Windows seleccionados con anterioridad, “Application”, “Security”, “System” y “Sysmon”, parseados, a nuestro servidor Graylog, puerto 12201/UDP, en formato GELF:
- nxlog.conf
Panic Soft
#NoFreeOnExit TRUE
define ROOT C:\Program Files\nxlog
define CERTDIR %ROOT%\cert
define CONFDIR %ROOT%\conf
define LOGDIR %ROOT%\data
define LOGFILE %LOGDIR%\nxlog.log
LogFile %LOGFILE%
Moduledir %ROOT%\modules
CacheDir %ROOT%\data
Pidfile %ROOT%\data\nxlog.pid
SpoolDir %ROOT%\data
<Extension _syslog>
#Module xm_syslog
Module xm_gelf
</Extension>
<Extension _charconv>
Module xm_charconv
AutodetectCharsets iso8859-2, utf-8, utf-16, utf-32
</Extension>
<Extension _exec>
Module xm_exec
</Extension>
<Extension _fileop>
Module xm_fileop
# Check the size of our log file hourly, rotate if larger than 5MB
<Schedule>
Every 1 hour
Exec if (file_exists('%LOGFILE%') and \
(file_size('%LOGFILE%') >= 5M)) \
file_cycle('%LOGFILE%', 8);
</Schedule>
# Rotate our log file every week on Sunday at midnight
<Schedule>
When @weekly
Exec if file_exists('%LOGFILE%') file_cycle('%LOGFILE%', 8);
</Schedule>
</Extension>
<Input eventlog>
Module im_msvistalog
ReadFromLast TRUE
<QueryXML>
<QueryList>
<Query Id='1'>
<Select Path='Application'>*</Select>
<Select Path='Security'>*</Select>
<Select Path='System'>*</Select>
<Select Path='Microsoft-Windows-Sysmon/Operational'>*</Select>
</Query>
</QueryList>
</QueryXML>
</Input>
<Output out>
Module om_udp
Host 192.168.37.130
Port 12201
#Exec to_syslog_snare();
OutputType GELF
</Output>
<Route 1>
Path eventlog => out
</Route>
Guardamos el documento y para aplicar los cambios, reiniciamos el servicio de NxLog. Para ello buscamos la utilidad “Servicios” en el buscador de Windows:
La abrimos, seleccionamos el servicio de NxLog y lo reiniciamos:
Una vez reiniciado, el servicio empezará a enviar todos los eventos definidos al destino configurado, que corresponde con el input de Graylog creado.
Si entramos en la interfaz de Graylog, en la ventana “Search” ya deberíamos estar viendo todos los eventos de Windows que se van generando en el equipo:
4 Configuración de wildcards en las consultas de Graylog
En este punto describiremos cómo activar en las consultas de Graylog, versión 3 o superior, los wildcards, o caracteres comodín, para ampliar las capacidades de búsqueda y beneficiarnos de las ventajas que nos aportan estos caracteres, como podría ser el asterisco (*) para indicar que todos los caracteres son válidos.
Por defecto, Graylog sólo permite el uso de wildcards en los campos “message”, “full_message” y “source”. Si queremos activar los wildcards en otros campos deberemos de configurarlo manualmente para cada campo siguiendo los pasos siguientes:
1. Crear un nuevo fichero con extensión .json y abrir con el editor de texto preferido:
$ vim graylog-custom-mapping.json
2. Añadir los campos en los que se quiera habilitar los wildcards. En el siguiente ejemplo, estaríamos habilitando los wildcards para los campos “Image” y “ParentImage”:
{
"template": "graylog_*",
"mappings": {
"message": {
"properties": {
"Image": {
"analyzer": "standard",
"fielddata": "false",
"type" : "text"
},
"ParentImage": {
"analyzer": "standard",
"fielddata": "false",
"type" : "text"
}
}
}
}
}3. Guardar el fichero y enviar estos valores a Graylog a través de su API con el siguiente comando:
$ curl -X PUT -d @'graylog-custom-mapping.json' -H "Content-Type: application/json" 'http://localhost:9200/_template/graylog-custom-mapping?pretty'
4. Una vez aplicada esta nueva configuración, rotaremos el índice, dónde se están almacenando los eventos enviados, para iniciar un nuevo índice con la configuración anterior. Para ello, desde la interfaz de Graylog, desplegamos la ventana de “System” y seleccionamos “Indices”:
Seleccionamos el índice que se esté utilizando:
Y en la pantalla siguiente, desplegamos la opción de “Maintenance” y clicamos en “Rotate active write index”:
A partir del rotado realizado, los campos configurados de los próximos eventos vendrán con la opción de wildcard habilitada y ya podremos beneficiarnos de las ventajas aportadas por los caracteres comodín en las búsquedas de los valores de estos campos, como se muestra a continuación:
Muy interesante tema.