Suricata IDS – Instalación, puesta en marcha y primera prueba

PUBLICADO EL 
Buenas a todos!
Últimamente he estado trasteando con Suricata IDS, un detector de intrusiones del que a mi parecer merece la pena sacar unas pocas entradas 🙂 Hoy os traigo la primera parte, en la que instalaremos Suricata sobre una máquina virtual Debian y realizaremos una configuración básica para ponerlo en marcha. Manos a la obra, pues.
Lo primero, como siempre, es tener la máquina Debian lista y actualizada (no me entretendré aquí). Acto seguido, dado que Suricata está en los repositorios, la instalación no podría ser más fácil:
sudo apt install suricata
Instalación de Suricata IDS en Debian
todos hackeados listo! En otro tipo de sistemas la instalación podría ser más o menos complicada, utilizando otro gestor de paquetes o teniendo que descargar desde la página oficial el fichero comprimido TAR.GZ para realizar la instalación.
Podemos comprobar que tenemos el servicio corriendo, y por tanto todo ha ido bien, mediante el comando:
systemctl status suricata
Comprobación del estado del servicio Suricata
Ahora deberemos realizar un par de configuraciones para que todo funcione correctamente. De forma predeterminada, Suricata utiliza el modo de trabajo AF-PACKET (lectura de sockets en raw) sobre la interfaz eth0. Sin embargo, en las últimas versiones de Debian, esta interfaz no existe; ahora, la interfaz de red física predeterminada es ens33. Por supuesto, si la interfaz que queremos inspeccionar es otra, será ésa la que configuraremos.
Dentro del fichero de configuración localizado en /etc/suricata/suricata.yaml, debemos buscar el apartado de configuración del modo af-packet y cambiar la interfaz de la siguiente forma:
Edición de suricata.yaml para establecer la interfaz de escucha
¡Y ya tenemos nuestro servicio configurado y corriendo! Pero esto de poco nos va a servir si no sabe qué es lo que tiene que buscar. Para ello, ejecutaremos la herramienta suricata-oinkmaster-updater que se incluye con Suricata (al menos en Debian). Lo que hace es descargar las últimas reglas publicadas por Emerging Threats e instalarlas en nuestro sistema. Nos servirán para tener ya unas cuantas reglas básicas instaladas, que exploraremos en las siguientes entradas 🙂
Ejecución de suricata-oinkmaster-updater (parcial)
En las siguientes entradas recorreremos las reglas con mayor atención. Sin embargo, para empezar a toquetear, ¡vamos a crear nuestra primera regla! Para ello, crearemos y editaremos con nuestro editor de textos favorito (siempre vim :P) un fichero /etc/suricata/rules/custom.rules con la siguiente línea de contenido:
alert icmp any any -> any any (msg: "ICMP detected";)
Creación de nuestra primera regla en Suricata
¿Qué es lo que hace, a grandes rasgos, esta regla? Básicamente, sacará una alerta (visible en los logs) cada vez que detecte un paquete ICMP. ¿Ruidoso? ¡Mucho! Pero nos sirve para realizar nuestras primeras pruebas de forma fácil y rápida 🙂 Además, esto puede llegar a tener su sentido en ciertos entornos donde este tipo de tráfico está restringido (y por tanto, si aparece, ¡algo raro ha pasado!).
A continuación, debemos agregar nuestro fichero de reglas custom.rules a la configuración de Suricata para que pueda aplicarlas sobre el tráfico escuchado. Debemos agregarla al fichero /etc/suricata/suricata.yaml de la siguiente manera, a continuación de las reglas que aparecen agregadas anteriormente mediante suricata-oinkmaster-updater:
Agregando nuestras reglas junto a Emerging Rules en la configuración de Suricata
Hecho esto, debemos recargar el servicio (podría tardar más o menos) para que recoja las nuevas reglas agregadas, y comprobar que todo ha ido bien:
sudo systemctl reload suricata

sudo systemctl status suricata
Recarga del servicio tras agregar las reglas
Con esto, y si todo ha ido bien, ¡ya tenemos nuestras reglas funcionando! Podemos hacer una pequeña prueba para comprobarlo. Pero antes, vamos a  realizar un muy breve recorrido por los logs de Suricata, localizados en /var/log/suricata:
  • suricata.log: Recoge los eventos del mismo Suricata: inicializaciones, recargas, errores…
Muestra de suricata.log.
  • stats.log: Recoge estadísticas regulares acerca del tráfico que se ha ido analizando hasta el momento.
Muestra de stats.log.
  • fast.log: Recoge los eventos disparados por las reglas. Tiene como objetivo dar una impresión rápida y directa de los eventos.
  • eve.json: Recoge, igual que el anterior, los eventos disparados por las reglas, pero lo hace en formato JSON, lo que permite que posteriormente pueda ser interpretado de forma mucho más fácil por programas externos.
Enseguida veremos muestras de estos dos 🙂 Para lograr unos pocos eventos, en una terminal ejecutaremos un ping a 8.8.8.8 (los DNS de Google, por poner algo). Si hemos hecho todo bien (si no, tómate un café y revísalo todo, invita @CiberPoliES) deberían entrar eventos tanto a fast.log como a eve.json. Podemos comprobarlo en directo con un comando tail -f en ambos ficheros (que va mostrando las líneas nuevas). Adicionalmente, en ambos utilizaremos grep para que solamente muestre aquellas líneas que contengan «ICMP detected», es decir, las que saca nuestra regla.
Por tanto, en dos consolas diferentes:
tail -f eve.json | grep "ICMP detected"

tail -f fast.log | grep "ICMP  detected"
Preparando la prueba de generación y visualización de logs.
Cruza los dedos, y en otra terminal ejecuta lo siguiente para lanzar dos pings:
ping -c 2 8.8.8.8
Éxito en la prueba de generación y visualización de logs.
¡¡Bingo!! Vemos que correctamente se recogen y visualizan los eventos en ambos logs, en su formato correspondiente y con el mensaje que indicamos: ICMP detected. ¡Todo ha salido bien!
Hasta aquí la primera entrega de lo que espero que sea una serie más o menos larga acerca de Suricata IDS en la madriguera 🙂 Espero de verdad que os sirva para hacer algunos experimentos y aprendáis lo mejor posible. Un saludo!!
PD: La siguiente entrega:

27 comentarios en “Suricata IDS – Instalación, puesta en marcha y primera prueba

  1. Muy buen post, le das confianza para no hacerle el feo a la herramienta. Un par de preguntas:
    1. ¿La tarjeta de red en la maquina. Virtual debían, se configura en algún modo tipo promiscuo, on el Debían propiamente?
    2. ¿El puerto del switch a donde conectas la maquina se configura en portmirroring?
    1. Buenas Odin, gracias por el feedback! De momento, dado que estamos filtrando tráfico que realmente viene hacia nosotros (con el ping), no es necesario. En caso de recepcionar tráfico que no está dirigido hacia nosotros (típico IDS por mirroring) sí que sería necesario colocar la interfaz de recepción en modo promiscuo desde el propio Debian. El puerto del switch se debería colocar en port mirroring en caso de que esa sea la fuente del tráfico, pero todo depende de tu arquitectura de red y de dónde quieres recepcionar el tráfico. Un saludo!
  2. Hola
    Creo que donde pones tail -f fast.json | grep «ICMP detected»
    debería ser tail -f fast.log | grep «ICMP detected»
    Saludos.
  3. El sistema no es tan importante como el hardware en el que lo pongas.. Y más concrétamente la memoria del hw y la configuración 😀
    No es lo mismo cargar 10 reglas que 40000. Puedes hacer pruebas en tu equipo, comprobar el consumo de memoria y ver si el router en el que lo quieres poner tendría suficiente memoria (si es que es un router con openwrt, claro :D). Ten en cuenta que por configuración puedes especificar muchos parámetros relacionados precarga y capacidad de consumo(*prealloc*.. *memcap*..).
    Slds
    1. Había pensado montar 2Gb de una memoria flash USB como memoria swap, aunque me preocupa que lo vuelva muy lento.
      Ya os contaré qué tal y si veo que necesito ayuda acudiré por aquí.
      Gracias!
  4. Para no reinciar el servicio cada vez que añades o modificas reglas (que es un co..zo) te recomiendo que hagas un kill -USR2 $(pidof suricata) este comando te recarga las relgas sin necesidad de reiniciar el servicio.
    Muy util cuando tienes Suricata configurada en modo inline y una recarga del servicio implica corte de servicio 🙂
    1. Hola Diego, muchas gracias por el aporte! De todos modos, el reload desde systemd (sudo systemctl reload suricata) lo que hace es hacer un update de las reglas desde el suricatasc, así que por lo que entiendo no tiene por qué parar el servicio. Gracias por leernos!!
  5. Si, efectivamente hace lo mismo de hecho la señal USR2 llama a la función DetectEngineReloadStart() (fichero suricata.c) y con suricatasc -c reload-rules (que es lo que ejecuta el reload) llama tambien a DetectEngineReloadStart() (fichero unix-manager.c) asi que sí hacen exactamente lo mismo, en ninguno de los dos casos como comentas hay perdida de servício. No obstante en el comentario anterior cuando hablaba de reiniciar me refería a hacer un restart y en este caso si que hay afectación. Un saludo!
  6. Felicidades por el articulo , si al ejecutar el ping y el «tail -f fast.log | grep «ICMP detected» no muestra nada , en que log se puede ver que puede estar pasando.
    Un saludo y gracias
    1. Hola G0rd0Kabr0n! Es extraño que siguiendo los pasos ocurra… intenta revisar los ficheros de configuración, y revisa el script de gestión en init.d o systemd (depende lo que estés usando) para saber si el servicio se levanta en la interfaz correcta. Un saludo!
  7. Muy buen manual, me has sacado de un apuro, todo muy claro y bien explicado. Por cierto, hay un «entorno» llamado Smooth-Sec que tal vez te interese.
    Gracias XD
  8. Veo que al instalarlo por apt, se instala la versión 3.X y veo en su sitio web que la versión estable es 4.X, cual recomiendan, alguna diferencia?
    1. Buenas Carlos, la verdad es que todavía no he probado las últimas versiones, pero no debería cambiar demasiado. Siempre recomiendo probar la última versión estable del desarrollador. Un saludo y gracias por leernos!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *
 
 
 
Los datos introducidos se guardarán en nuestra base de datos como parte del comentario publicado, como se indica en la política de privacidad.