Detección de intrusos con Suricata
Esta herramienta sirve para detección y prevención (IDS/IPS) de intrusos, es decir, suricata funciona para detectar y prevenir posibles ataques o ingreso de intrusos a través de conexiones propias o desconocidas en nuestro sistema. Para ello, es este artículo veremos en detalle el uso, configuración y funcionamiento para aplicarlo como una capa más de seguridad a nuestro Firewall.
Instalación y Revisión
apt-get install -y suricata
Colocamos el parámetro -y para aceptar la instalación de los paquetes necesarios para el correcto funcionamiento de suricata. Por ejemplo, librerías, el comando oinkmaster para administración, reglas por defecto, y compatibles, que vienen en snort (otro ids), entre otros..
Para saber si suricata está activo podemos ejecutar el siguiente comando:
systemctl status suricata
En caso de no estar, lo podemos activar de la siguiente manera:
Podemos notar que esta herramienta se ejecuta con el parámetro -D indicando que estará trabajando como un demonio del sistema (proceso en segundo plano), y con –af-packet indica la forma de captura de paquete que utilizará.
Archivo de configuración
El archivo de configuración de suricata se encuentra en /etc/suricata/suricata.yaml y está conformado por 4 pasos:
Como vemos, esta información es crucial para la detección de intrusos en suricata. En el primer paso encontramos información de las conexiones con respecto a las variables de configuración “address-groups” y “port-groups”.
addres-groups
La primera hace referencia al HOME_NET donde debemos especificar el tipo de red que estamos utilizando para diferenciarlas de las redes externas. Por defecto, si prestamos atención, se encuentra descomentada la primera variable haciendo referencia a los tres tipos de redes: “[192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12]”. Se recomienda cancelar esta configuración (colocando el signo de almohadilla) y elegir solo la red en la que nos encontramos, como se vé en las configuraciones debajo de esta.
La segunda variable se refiere al EXTERNAL_NET donde tenemos las opciones de negar todo tipo de conexión a la nuestra (como se encuentra configurada por defecto) o elegir la opción “any” donde hará todo lo contrario.
port-groups
En esta variable nos encontramos con las configuraciones de los distintos puertos donde podremos cambiar el número de origen por defecto. Cada uno debe ser configurado específicamente de acuerdo al entorno de red en el que se encuentre, ya que por defecto todas las configuraciones vienen establecidas de forma muy genérica.
Debemos tener en cuenta que, para la detección de intrusos y un uso correcto de suricata, es necesario tener configurada la interfaz de red que estamos usando dentro del archivo suricata.yaml. Por ejemplo, a través del comando ip addr podemos conocerla y establecerla en dicho archivo de la siguiente manera:
Reglas de Suricata
Dentro del directorio /etc/suricata/rules encontramos las reglas que se establecen dentro del archivo de configuración suricata.yaml. Estas nos permitirá establecer los parámetros necesarios para la detección de intrusos, tanto con las reglas de snort como con suricata. Podemos ver su directiva mencionada en dicho archivo.
Como vemos, aquí debemos especificar y agregar las reglas que queremos tener activadas. Por lo tanto, si queremos activar las reglas para las conexiones ssh deberíamos colocar – ssh-events.rules debajo de rule-files (o especificar la ruta completa a la misma).
Configuración
A modo de ejemplo, dentro del directorio /etc/suricata/rules veremos como están compuestas las configuraciones para los eventos del servicio ssh:
Las reglas para la detección de intrusos en suricata se dividen es tres partes: Acción, Cabeceras y Opciones.
Acción
En el caso de la imagen anterior la acción a tomar es “alert”. Es decir, cuando haya un evento con respecto a la misma, veremos los registros dentro del archivo fast.log dentro del directorio /var/log/suricata. Estas acciones también pueden ser reject, drop y pass. Por lo tanto:
alert → Genera una alerta ante la detección de algún intruso según el método seleccionado en suricata y almacena el log.
log → Archiva el log del paquete.
activate → Activa el paquete y llama a una regla dinámica.
pass → Ignora el paquete.
dynamic → Se pone en funcionamiento cuando es llamada por una regla activate.
Cabeceras
Estas se componen por Protocolos, Origen y Destino de direcciones y puertos y Dirección de operación: → (puede ser →, ←).
En el caso de la imagen anterior vemos que no se especifica el protocolo a analizar. Sin embargo, vemos “any” en cuanto a la dirección y puertos de origen y destino. Esto lo podemos configurar con las variables red (HOME_NET y EXTERNAL_NET) para una correcta detección de intrusos en suricata. Recordemos que las mismas las encontramos en el archivo suricata.yaml.
Opciones
Las opciones pueden ser: msg, flags, ack, reference, class-type, sid, rev, entre otras.
Cabe mencionar, que los tipos de clase de una regla (class-type) se encuentran definidas dentro de /etc/suricata/classification.
Como vemos, las mismas se clasifican en “nombre, tipo de clase, prioridad”. La prioridad es más grave mientras menor sea el número (por ejemplo 1). Caso contrario, si el número es 3 o 4 la criticidad es baja (con 2 sería media).
La opción de revisión (rev) casi siempre la encontraremos en 1. Podemos decir que esto refiere al número de versión en nuestra regla ya que, a medida que modificamos la regla para mejorarla, podamos tener una versión explicada y detallada de la misma.
Otro dato a tener en cuenta, es que en la mayoría de los casos veremos sid (identificador) mayores a un millón. Esto se debe a que, los números menores al mismo suelen utilizarse para reglas internas de snort y suricata. Entonces por convención se colocan números iguales o mayores a un millón.
Descarga de Reglas con oinkmaster
Si bien estas reglas son de gran ayuda para la detección de intrusos, aún mejor, las mismas se instalan junto con suricata. Por defecto, esta herramienta no solo nos permite actualizar las reglas, sino también descargar otras. Por ejemplo, el proveedor de reglas más conocidos es Emerging Threat, cuyas reglas a disposición son Open Source y otras pagas.
A continuación, a través de dicho sitio web, procederemos a descargar una versión compatible con nuestro ids. Es decir, debemos buscar la misma versión o anteriores a la que tenemos. Por ejemplo, con el comando suricata -V podemos saber la versión utilizada.
En el apartado de “open” podemos ver las que se listan las versiones disponibles y, una vez elegida, veremos lo siguiente:
En el directorio rules encontraremos una amplia variedad de archivos, o juegos de reglas, con la extensión .rules para distintos programas. Para descargarnos una variedad de dichas reglas en nuestro ids, a modo de ejemplo, lo que podemos hacer es copiar la url de “emerging.rules.tar.gz” y pegarla dentro del archivo /etc/oinkmaster.conf.
Luego, para su descarga y ejecución, debemos especificar el directorio donde queremos que se almacenen las reglas. Para ello ejecutamos:
Debemos tener en cuenta en NO colocar nuestras reglas personalizadas con el mismo nombre que las descargadas para evitar que se “pisen” entre sí.
Configuración de logs
Existen muchas opciones para representar la detección de intrusos a través de logs que se van registrando en suricata. En el paso 2 del archivo suricata.yaml podemos verificar dicha configuración.
Como vemos, el directorio por defecto de todos los logs se encuentra en /var/log/suricata. A su vez, dentro del mismo encontramos distintos archivos en los que se almacenan estos registros. Estos son:
Estadísticas globales
El archivo se encuentra como stats.log y nos permite saber cómo esta funcionando suricata (o sus estadísticas) con respecto a la cantidad de paquetes y flujo de datos que se están procesando. Este archivo es importante ya que nos permite visualizar una medición de los registros. Es decir, si hay un problema de velocidad debido a la cantidad de paquetes, por ejemplo, podemos verificarlo en este archivo
Tipo de alertas y salidas
Dentro del archivo fast.log veremos de una forma rápida y sencilla los últimos logs que se van generando en el sistema. Es decir, podremos visualizar, la fecha, id, mensaje, clasificación, prioridad, puerto y direcciones de entrada y salida. Para visualizarlos en tiempo real podemos hacer uso del comando tail -f fast.log.
Formato de evento extensible
Este formato se encuentra en el archivo eve.log y nos permite almacenar mucha más información que el anterior, pero lo que lo hace especial es que viene definido en formato json. Por tanto, dependiendo como queramos configurar suricata con otros sistemas, su uso se vuelve crucial para desarrolladores o programas externos ya que, por otro lado, también nos permite enviar dichos registros a un archivo, por syslog o una base de datos redis (no sql).
Información por clase de eventos
En el archivo suricata.log encontraremos la depuración de las reglas. Las mismas, nos permite conocer la información sobre la fecha, hora, tipo de alerta (Error, Notice, Warning, Error), número de núcleos y archivos procesados, entre otros. Veamos un ejemplo en la siguiente imagen:
Reglas Personalizadas básicas
Del mismo modo que usamos las reglas (las cuales añadimos o vienen instaladas por defecto y son compatibles con snort), podemos aplicar una correcta detección de intrusos, de forma personalizada para cualquier programa o acción dentro de un archivo, con suricata. Para ello vamos a crear el archivo personal.rules dentro del directorio /etc/suricata/rules y luego lo colocaremos dentro del archivo suricata.yaml.
En caso de colocar el archivo en otro directorio, debemos especificar la ruta completa del mismo dentro de suricata.yaml.
Para saber si hemos colocado bien una regla, podemos verificarlo con el comando suricata -c /etc/suricata/suricata.yaml -i (interface).
Escaneo ICMP
La siguiente regla establece una alerta cuando recibimos paquetes ICMP (o escaneo ping) en nuestro equipo. Esto se suele utilizar para comprobar la conexiones activas de un equipo.
Desde nuestra máquia Windows vamos a enviar trazas icmp a nuestra máquina kali, cuya dirección ip es la 192.168.100.18.
Por tanto, a través del comando tail -f en el archivo /var/log/suricata/fast.log vamos a poder visualizar la alerta de dicha regla.
Conexión FTP
Ahora veremos una alerta con el tipo de clase “policy-violation” cuyo número se representa con el 1 (alta prioridad), a través de una conexión ftp. Para ello, haremos uso de la siguiente regla.
Ahora bien, procederemos a conectarnos a nuestra máquina víctima por dicho servicio.
Veremos dicho resultado en nuestro archivo de log.
Tener en cuenta
A veces se suele alertar o bloquear algunas consultas a ciertos dominios en oficinas de trabajo, por ejemplo a redes sociales. Para ello, debemos tener el cuenta que si la información viaja a través de https estará cifrada y esto puede hacer que suricata no reconozca ciertos dominios. Sin embargo, la única parte que no viaja cifrada en una conexión https es el nombre del servidor. Entonces con la opción content podemos especificar el contenido para alertar/bloquear dentro del payload (carga útil).
Por ejemplo, la siguiente regla deberá alertar sobre cualquier conexión establecida con dominio, o subdominios, cuyo contenido tenga “instagram”
alert tcp any any → any any (msg:“Conexión a Instagram. Bloquear Host”; content:“instagram”; nocase; sid:1000000; rev:1;)
En la siguiente regla, veremos otro ejemplo con esto.
Reglas Personalizadas Avanzadas
Las siguiente reglas nos permitirán conocer un enfoque más avanzado para la detección de intrusos con respecto a la personalización y acción de las mismas en ciertos programas con suricata.
Consulta DNS
A continuación vamos a generar una regla que nos alerte sobre las consultas dns.
Lo que hará suricata será analizar la consulta DNS, lo cual especificamos con dns_query, verificar con content si dentro de la misma existe el contenido “debian” para reportarlo, y con nocase le hacemos saber que no diferencie entre mayúsculas y minúsculas.
Por lo tanto, para verificar el funcionamiento de dicha regla podemos hacer uso del comando dig, el cual nos permite hacer consulta a un servidor dns.
Cuyo registro de log sería el siguiente.
De esta manera, podemos analizar cualquier consulta a determinados dominios que puedan ser considerados maliciosos, o investigarlos particularmente, a través de dicha regla.
Reglas con umbrales (thresholds)
En algunos casos, podemos estar interesados que una regla nos alerte una cierta cantidad de veces. Para esto, suricata nos provee la opción de thresholds para evaluar una regla de acuerdo a diferentes parámetros. Veamos la siguiente regla.
Como podemos ver, con dsize indicamos paquetes mayores a 512 bytes y con el operador threshold indicamos lo siguiente:
type threshold →Hace referencia al tipo de operador a utilizar. También podemos usar “limit” para limitar la cantidad de veces que se va a disparar la regla.
track by_src → Con esto especificamos el registro de cantidades en base a la regla que declaremos. En este caso, nos referimos a la cantidad de origen de los paquetes emitidos.
count 5 →Cantidad de 5 paquetes.
seconds 60 →Tiempo límite de paquetes emitidos.
Esto quiere decir que, si dentro de un umbral de 60 segundos se reciben 5 paquetes de $EXTERNAL_NET (mayores a 512 bytes), se aplicará la alerta de la regla con el mensaje en msg.
Entonces vamos a enviar 11 paquetes con un tamaño de 1024 bytes para generar dos alertas desde una máquina Windows.
Dentro de fast.log veríamos lo siguiente:
Detección de Protocolos
A continuación veremos dos ejemplos para analizar una regla de acuerdo a un protocolo específico. Para ello, haremos uso de la opción app-layer-protocol como vemos en la siguiente imagen.
En el caso de realizar una solicitud o conexión ssh, suricata lo identificará de inmediato
A su vez, vamos a levantar un servidor en Python en una terminal de la siguiente manera:
y vamos a conectarnos desde nuestro navegador en Firefox para realizar una consultar GET por HTTP.
Veamos a continuación los registros de logs generados por suricata.
Reglas con nmap
Tomar una acción sobre los distintos escaneos a través de ciertas herramientas, por ejemplo nmap, no siempre es fácil de realizar ya que existen muchas funciones para evadir Firewall e IDS/IPS, o simplemente porque necesitamos que ciertos puertos estén abiertos debido al uso de los mimos. No obstante, a continuación veremos una serie de reglas que nos ayudará a detectar posibles intrusos.
Veamos la siguiente regla:
Por lo tanto, con dicha regla especificamos flags:S para detectar paquetes con flag SYN (escaneos usados para no establecer conexión SYN-ACK) y las opciones de threshold de type both para que alerte y limite los logs generados por 5 paquetes en un período de 5 segundos mediante track by_src.
Como ejemplo, podemos generar dicha cantidad de paquetes realizando un escaneo a google como vemos a continuación:
Como resultado veríamos lo siguiente:
El uso de la opción flag es muy bueno para estos casos, por ejemplo con flags:A establecemos banderas del tipo ACK, con flags:F establecemos una conexión del tipo “nmap FIN scan” para alertar sobre una conexión establecida, con flags:0 alertamos sobre conexiones tipo NULL, entre otras..
