Suricata IDS — détecteur réseau

Des alertes Suricata sans stack ELK

Suricata écrit ses résultats dans eve.json, un objet JSON par événement, et le conseil habituel consiste à expédier tout cela vers Elasticsearch pour le consulter dans Kibana. Sur un cluster, c’est raisonnable. Sur un VPS unique, cela revient à faire tourner un moteur de recherche, un collecteur de journaux et un serveur de tableaux de bord — plusieurs gigaoctets de mémoire et un second système à maintenir — pour lire des alertes depuis la machine où elles ont déjà été écrites.

Cette page lit eve.json directement, ainsi que fast.log lorsque c’est ce que produit votre version. Elle présente les alertes des dernières vingt-quatre heures groupées par catégorie, les adresses qui en génèrent le plus, et les signatures individuelles avec source, destination, protocole et gravité.

Si Suricata tourne sans rien signaler, la cause tient presque toujours aux règles et non au trafic : une installation neuve n’embarque aucune signature tant que suricata-update n’a pas été exécuté au moins une fois. L’autre surprise concerne la gravité. L’essentiel de ce que rapporte une sonde exposée est du balayage de faible gravité qui ne débouche sur rien : lisez les catégories avant de regarder le compteur.

Un capteur sur le fil a une limite sur laquelle on trébuche régulièrement : le trafic chiffré lui apparaît comme un flux d'octets. Il dira qu'une connexion à votre site est venue de cette adresse, mais pas que la requête portait une tentative d'injection SQL. Cela, c'est ModSecurity qui le lit, dans le serveur web, après déchiffrement. Les deux ne se remplacent pas : l'un regarde le réseau de l'extérieur, l'autre la requête de l'intérieur.