Suricata IDS — detector de red

Alertas de Suricata sin un stack ELK

Suricata escribe sus hallazgos en eve.json, un objeto JSON por evento, y el consejo habitual es enviar todo eso a Elasticsearch y mirarlo a través de Kibana. En un clúster tiene sentido. En un único VPS significa mantener un motor de búsqueda, un recolector de registros y un servidor de paneles — varios gigabytes de memoria y un segundo sistema que cuidar — para leer alertas desde la misma máquina en la que ya estaban escritas.

Esta página lee eve.json directamente, junto con fast.log cuando esa es la salida de su compilación. Muestra las alertas de las últimas veinticuatro horas agrupadas por categoría, las direcciones que generan más de ellas y las firmas individuales con origen, destino, protocolo y gravedad.

Si Suricata está funcionando pero no informa de nada, la causa casi siempre está en las reglas y no en el tráfico: una instalación nueva no trae firmas hasta que suricata-update se ha ejecutado al menos una vez. La otra sorpresa habitual es la gravedad. La mayor parte de lo que reporta un sensor expuesto es escaneo de gravedad baja que nunca llega a nada, así que lea las categorías antes que el contador.

Un sensor en el cable tiene un límite con el que se tropieza a menudo: el tráfico cifrado le llega como un flujo de bytes. Dirá que desde esta dirección llegó una conexión a su sitio, pero no dirá que la petición llevaba un intento de inyección SQL. Eso lo lee ModSecurity, dentro del servidor web, después del descifrado. No se sustituyen entre sí: uno mira la red desde fuera, el otro la petición desde dentro.