Pourquoi j'ai mis Sentinelle en vert
Sentinelle est le bundle de sécurité Symfony que j'utilise sur tous mes sites, publié en open source. Il note chaque requête, repère les tentatives (un .env, un .git, les chemins de WordPress, les injections), bloque les adresses fautives et prévient par e-mail.
Trop d'alertes, plus d'alerte
Les scanners passent sur tous les sites, toute la journée. Sur un de mes sites en production, les e-mails d'alerte montaient à environ 200 par semaine. Presque tous racontaient la même histoire : une adresse cherche /.env, reçoit une 404, se fait bloquer. Il ne s'est rien passé.
À ce rythme, on ne lit plus les alertes. Et le jour où l'une d'elles compte vraiment, elle est noyée dans les autres.
La seule question qui compte
Une tentative n'est pas une fuite. Ce qui compte, c'est la réponse du site : si /.env répond 404, rien n'est sorti ; s'il répond 200, il faut agir tout de suite.
La version 0.4 regarde donc les réponses, plus seulement les demandes. Un fichier sensible servi avec succès (.env, .git, clés, sauvegardes de base, journaux, outils de debug) ou un secret qui apparaît dans une réponse : l'adresse est bloquée 30 jours et une alerte rouge part immédiatement, en priorité haute, avec ce qu'il faut faire maintenant.
Le vert
Chaque alerte montre désormais ce que l'adresse a fait pendant les 48 dernières heures. Quand aucune de ses requêtes vers une adresse sensible n'a abouti, l'alerte le dit dans un bandeau vert. On sait en une seconde qu'on peut fermer l'e-mail.
Et les adresses déjà bloquées dont toutes les tentatives ont échoué n'envoient plus d'e-mail du tout. Elles sont comptées dans un résumé quotidien, qui ne part que s'il s'est passé quelque chose. Ceux qui préfèrent l'ancien comportement le retrouvent avec une ligne de configuration (quiet_when_blocked: false).
Mise à jour du 27 octobre : ce réglage ne s'appliquait pas en réalité, à cause d'un bug corrigé dans la version 0.6. Je l'explique dans Une alerte par robot, c'est zéro alerte.
Ce que j'en retiens
Une alerte doit répondre à une seule question : est-ce que je dois agir ? Vert : non. Rouge : oui, maintenant. Tout le reste peut attendre le résumé du matin.
La première ligne de défense reste le serveur web : sur mes sites, un fichier sensible déposé par erreur dans le dossier public n'est jamais servi. Sentinelle est là pour le jour où cette ligne-là cède, et pour le dire clairement.
À lire aussi
Une alerte par robot, c'est zéro alerte
Mon bundle de sécurité devait se taire quand un robot était déjà bloqué. Il ne le faisait jamais. Sentinelle 0.6 corrige le bug, et n'écrit plus à la minute que si quelque chose est vraiment sorti.
L'IA écrit mon code, je garde les clés
Je ne tape plus de code : une IA écrit tout. Elle n'a pourtant accès ni au serveur ni à un seul secret. Qui peut faire quoi, ce qui est en place, et ce qui ne l'est pas encore.
Mon site se met à jour pendant que je dors, et je valide le matin
Uplift fait monter PHP, Symfony et les dépendances dans des limites que je fixe, lance les tests et me laisse décider. Premier vrai passage : Symfony 7.3 vers 7.4.21, 40 paquets.