Pratiquement tous les guides Suricata se terminent par l’installation d’Elasticsearch, Logstash et Kibana. Pour un seul VPS, c’est un mauvais conseil : la pile réclamera quatre gigaoctets de mémoire et une attention constante, alors que vous vouliez seulement voir ce que l’IDS a attrapé en une journée. Suricata fonctionne très bien sans eux — mais elle a une particularité à cause de laquelle on l’installe et on la retire une semaine plus tard.

La mine dans les réglages par défaut

D’origine, Suricata écrit dans eve.json plus de trente types d’événements : non seulement les alertes, mais chaque requête DNS, chaque poignée de main TLS, chaque transaction HTTP, ARP, DHCP, flux après flux. Plus un stats.log distinct toutes les huit secondes. Et Suricata ne configure aucune rotation des journaux — c’est la tâche de l’administrateur, et ce n’est écrit en gros nulle part.

Un chiffre relevé sur un serveur réel : 15 gigaoctets en deux jours — neuf dans eve.json et près de six dans stats.log. Il restait environ cinq jours avant le disque plein. Le trafic sur ce serveur n’était même pas important ; sur un nœud chargé, cela se serait compté en heures.

Vérifiez chez vous tout de suite :

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

Ne gardez que ce que vous lisez

Si vous regardez les alertes et ne faites pas de criminalistique réseau, un seul type d’événement est nécessaire dans eve-log. Dans /etc/suricata/suricata.yaml, trouvez le bloc outputs et, sous types de eve-log, ne laissez que alert en commentant le reste. Désactivez au même endroit la sortie des statistiques :

  - stats:
      enabled: no

Après la modification, la vérification de la configuration est obligatoire — avant de redémarrer le service :

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

L’ordre compte : le test échouera si les règles ne sont pas encore chargées. D’abord suricata-update, puis la vérification, puis le démarrage.

Une rotation qui fonctionne vraiment

Le fichier /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
}

Deux lignes n’y sont pas évidentes, et toutes deux sont décisives.

su suricata suricata — sans elle, logrotate ignore silencieusement tous les fichiers. Le répertoire /var/log/suricata appartient au groupe suricata et non à root, et logrotate juge une telle configuration dangereuse. Aucune erreur dans le courrier, aucune dans le journal ; vous serez simplement convaincu que la rotation existe — jusqu’à ce que le disque soit plein. Le seul moyen de le repérer à l’avance est un essai à blanc :

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

create 0664 suricata suricata — les droits du nouveau fichier. Avec les valeurs par défaut (0640), tout panneau ou script qui lit les journaux autrement qu’en root ne verra plus rien après la première rotation.

Ce qu’il faut régler en dehors des journaux

HOME_NET. C’est la description de ce que Suricata considère comme sien. La valeur par défaut énumère toutes les plages privées, or un VPS a une adresse publique — de sorte que certaines règles ne se déclenchent pas ou se déclenchent à l’envers. Indiquez explicitement votre réseau.

Règles. Le jeu Emerging Threats Open est récupéré par suricata-update, à placer dans cron une fois par jour. Les signatures trop bavardes se désactivent une à une par identifiant dans /etc/suricata/disable.conf — n’ayez pas peur de vous en servir : ce jeu est prévu pour un réseau d’entreprise, et sur un serveur web ordinaire une douzaine de règles se déclencheront en permanence et sans raison.

Mode. Par défaut, Suricata écoute une copie du trafic et se contente d’avertir (IDS). Le mode bloquant (IPS, via nfqueue) sur un serveur unique est un risque avant tout pour vous-même : un faux positif, et vous vous êtes fermé l’accès. Commencez par observer, et passez un mois à voir ce qui se fait attraper.

Lire sans Kibana

Les alertes courtes sont dans /var/log/suricata/fast.log — une ligne par événement, lisible à l’œil :

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

Le détail est dans eve.json, un objet JSON par ligne. Tout ce pour quoi on installe habituellement Kibana tient en une commande :

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

Ce sont les vingt signatures les plus fréquentes. Sur une semaine, une telle liste répond honnêtement à la question de ce qui se passe sur le serveur, et montre au passage quelles règles il est temps de désactiver.

À quoi bon, puisque Fail2ban est déjà là

Leur nature diffère. Fail2ban lit les journaux applicatifs et réagit aux connexions échouées — donc à ce qui a déjà atteint un service. Suricata regarde le trafic lui-même et voit ce qui ne figurera dans aucun journal : les balayages de ports, les tentatives d’exploitation selon des signatures connues, les connexions vers des serveurs de commande depuis votre machine. Ce dernier point est particulièrement précieux : une connexion sortante vers un serveur de commande étranger est le signe le plus précoce que quelque chose tourne déjà sur le serveur sans que vous l’ayez lancé.

Garder les deux est normal, ils ne se gênent pas. La seule question est de savoir si quelqu’un lit leur sortie plus d’une fois par trimestre. À quoi ressemblent ces mêmes alertes sur une page, réparties par catégorie et par source, la démonstration ci-dessous le montre.