Prácticamente todas las guías de Suricata terminan instalando Elasticsearch, Logstash y Kibana. Para un solo VPS es un mal consejo: la pila pedirá cuatro gigabytes de memoria y atención constante, cuando usted solo quería ver qué ha capturado el IDS en un día. Suricata funciona perfectamente sin ellos, pero tiene una particularidad por la cual se instala y se retira una semana después.

La mina en los ajustes por omisión

De fábrica, Suricata escribe en eve.json más de treinta tipos de eventos: no solo alertas, sino cada consulta DNS, cada saludo TLS, cada transacción HTTP, ARP, DHCP, flujo tras flujo. Más un stats.log aparte cada ocho segundos. Y Suricata no configura ninguna rotación de registros: esa es tarea del administrador, y en ningún sitio está escrito en letras grandes.

Una cifra de un servidor real: 15 gigabytes en dos días, nueve en eve.json y casi seis en stats.log. Quedaban unos cinco días hasta llenar el disco. Y el tráfico de ese servidor ni siquiera era alto; en un nodo cargado habría sido cuestión de horas.

Compruébelo ahora mismo en el suyo:

sudo du -sh /var/log/suricata/*

Conserve solo lo que lee

Si mira alertas y no hace análisis forense de red, de eve-log hace falta exactamente un tipo de evento. En /etc/suricata/suricata.yaml busque el bloque outputs y, bajo types de eve-log, deje solo alert comentando el resto. Desactive en el mismo sitio la salida de estadísticas:

  - stats:
      enabled: no

Tras el cambio, la comprobación de la configuración es obligatoria, antes de reiniciar el servicio:

sudo suricata -T -c /etc/suricata/suricata.yaml -v

El orden importa: la prueba no pasará si las reglas aún no están cargadas. Primero suricata-update, después la comprobación, después el arranque.

Una rotación que de verdad funciona

El archivo /etc/logrotate.d/suricata:

/var/log/suricata/*.log /var/log/suricata/*.json {
    daily
    rotate 7
    maxsize 200M
    missingok
    compress
    delaycompress
    create 0664 suricata suricata
    su suricata suricata
    postrotate
        systemctl kill -s HUP suricata
    endscript
}

Dos líneas ahí no son evidentes y ambas resultan decisivas.

su suricata suricata: sin ella, logrotate omite en silencio todos los archivos. El directorio /var/log/suricata pertenece al grupo suricata y no a root, y logrotate considera insegura esa disposición. No hay error en el correo ni en el registro; sencillamente estará convencido de que la rotación existe, hasta que el disco se llene. La única forma de detectarlo antes es una pasada en seco:

sudo logrotate -d /etc/logrotate.d/suricata

create 0664 suricata suricata: los permisos del archivo nuevo. Con los valores por omisión (0640), cualquier panel o script que lea los registros sin ser root no verá nada después de la primera rotación.

Qué configurar además de los registros

HOME_NET. Describe lo que Suricata considera propio. El valor por omisión enumera todos los rangos privados, pero un VPS tiene dirección pública, de modo que algunas reglas no se disparan o se disparan al revés. Indique su red de forma explícita.

Reglas. El conjunto Emerging Threats Open lo trae suricata-update, que se pone en cron una vez al día. Las firmas ruidosas concretas se desactivan por identificador en /etc/suricata/disable.conf: no tema usarlo, ese conjunto está pensado para una red corporativa, y en un servidor web corriente una docena de reglas se disparará continuamente y sin motivo.

Modo. Por omisión, Suricata escucha una copia del tráfico y solo avisa (IDS). El modo de bloqueo (IPS, mediante nfqueue) en un servidor único es un riesgo sobre todo para usted mismo: un falso positivo y se habrá cerrado el acceso. Empiece observando y dedique un mes a ver qué se captura.

Leer sin Kibana

Las alertas breves están en /var/log/suricata/fast.log: una línea por evento, legible a simple vista:

sudo tail -50 /var/log/suricata/fast.log

El detalle está en eve.json, un objeto JSON por línea. Todo aquello para lo que suele instalarse Kibana cabe en un comando:

sudo jq -r 'select(.event_type=="alert") | .alert.signature' \
    /var/log/suricata/eve.json | sort | uniq -c | sort -rn | head -20

Son las veinte firmas más frecuentes. A lo largo de una semana, esa lista responde con honestidad a qué ocurre con el servidor y muestra de paso qué reglas conviene desactivar.

Para qué, si ya está Fail2ban

Su naturaleza es distinta. Fail2ban lee registros de aplicaciones y reacciona ante accesos fallidos, es decir, ante lo que ya llegó a un servicio. Suricata mira el tráfico en sí y ve lo que no estará en ningún registro: escaneos de puertos, intentos de explotación según firmas conocidas, conexiones a servidores de mando desde dentro de su máquina. Esto último es especialmente valioso: una conexión saliente a un servidor de mando ajeno es el indicio más temprano de que en el servidor ya hay algo en marcha que usted no lanzó.

Mantener ambos es normal, no se estorban. La única cuestión es si alguien lee su salida más de una vez por trimestre. Cómo se ven esas mismas alertas en una página, repartidas por categoría y origen, lo muestra la demostración de abajo.