JournalBruit
925 648 événements, 3 notifications
Un outil de détection qui sonne sans arrêt finit coupé. Voici nos mesures sur un serveur de test, et les règles de réduction du bruit que vous pouvez appliquer à votre propre supervision.
À retenir+
- 11 h 44 min d'observation, 925 648 événements, 3 notifications, 0 fausse alerte.
- Une nouveauté sonne une fois, ses répétitions descendent en INFO.
- Une alerte de force brute ne part que si une tentative réussit.
La mesure
Du démarrage du démon à l'instantané : 11 h 44 min, 925 648 événements observés, 3 notifications envoyées. Toutes concernaient la clé SSH cachée qu'on avait plantée nous-mêmes. Le démon a utilisé 23 Mo de mémoire et environ 0,06 % d'un cœur.
Sur l'hôte de rodage, 26 opérations d'administration et tâches automatiques n'ont déclenché aucune alerte HIGH ou CRITICAL.
Les règles qui font la différence
- Une nouveauté sonne une fois. Une connexion root depuis une nouvelle adresse part en HIGH. La suivante depuis la même adresse passe en INFO.
- Ce qui est planifié reste discret. Les redémarrages après une mise à jour sont en INFO.
- On résume ce qui échoue. Les tentatives de force brute sont regroupées dans un résumé hebdomadaire. Une alerte immédiate part seulement si un compte visé accepte un mot de passe, ou au-delà de 20 échecs en une minute (#103).
Ces trois règles valent pour n'importe quel outil de supervision : une alerte doit demander une action, sinon elle apprend aux gens à ignorer les suivantes.
La limite
Douze heures sur une seule machine, c'est court. Il faudra plus de machines et plus de temps pour dire que le bruit est maîtrisé.