Le Hub · ScanGuard
Les robots d’attaque
restent à la porte.
Une requête qui cherche un fichier de configuration oublié, une page d’administration WordPress ou une faille connue est arrêtée à l’entrée du Hub. Vos programmes ne la voient pas.
À quoi ça sert
Dès qu’une adresse existe sur Internet, des robots viennent la tester. Ils ne vous visent pas : ils essaient tout le monde. Ils demandent /wp-login.php à un site qui n’est pas un WordPress, cherchent un fichier .env oublié avec ses mots de passe, glissent un bout de code PHP dans une adresse, tentent une faille célèbre comme celle de Log4j. Chacune de ces requêtes arrive jusqu’au programme, le fait travailler, et remplit ses journaux.
ScanGuard les reconnaît à l’entrée du Hub, avant tout traitement par le programme, et répond par un refus (code HTTP 403) avec une page qui explique pourquoi.
Ce qu’on voit à l’écran
L’écran ScanGuard — anti-scan, au 2026-09-23. Son sous-titre dit ce qu’il fait : il bloque les requêtes typiques de scanners (WordPress, PHP, fuite .env, scanners de failles connues) avant tout traitement applicatif.
Quatre compteurs, depuis le dernier démarrage du Hub.
- 2 422 requêtes bloquées au total ;
- 3 par les motifs enregistrés en base, ceux qu’on ajoute soi-même ;
- 2 419 par les motifs intégrés au Hub, écrits dans son code ;
- 31 motifs enregistrés, chargés en mémoire.
L’état du filtre. Badge vert ACTIF, « Le filtrage anti-scan est actif. » En dessous, de quoi le suspendre : une Durée (ici « 1 heure »), une Raison, obligatoire, et le bouton orange Désactiver temporairement. L’exemple proposé dans le champ est parlant : le temps d’installer un WordPress.
Top 10 patterns par hits. Le palmarès des motifs enregistrés, avec leur type, leur catégorie, leur total et leur dernier déclenchement. Ces totaux-là courent depuis la création de chaque motif, pas depuis le démarrage :
/wp-json/, préfixe, catégorie wp : 3 190 fois, la dernière le jour même à 12 h 15 ;<?phpdans les paramètres, catégorie injection : 568 ;${jndi:, la signature de la faille Log4j : 174 ;/autodiscover/, catégorie scanner : 75 ;<?=, injection : 3, la dernière le 2026-09-04.
Ajouter un pattern. Un champ pour le motif (l’exemple montre /wp-admin/), une liste pour son type, une catégorie, une description, et le bouton Ajouter.
Patterns built-in. En bas, les motifs intégrés, en lecture seule : « Toujours actifs, même si la DB est indisponible. » Pour laisser passer une catégorie sur un nom d’hôte précis, on y ajoute une exception.
Comment on s’en sert
On laisse tourner
ScanGuard est actif dès l’installation du Hub. Les motifs intégrés couvrent les tentatives les plus courantes sans rien régler.
On lit le palmarès
Il montre ce que les robots cherchent chez vous. Un motif qui monte vite dit quelle famille d’attaque est à la mode.
On ajoute un motif
Un chemin exact, un préfixe, une expression régulière, ou un motif dans les paramètres. Il est chargé tout de suite, sans redémarrage.
On pose une exception
Un site légitime a besoin d’un chemin qu’une catégorie bloque ? On exempte cette catégorie pour ce nom d’hôte, pour une durée ou pour toujours.
On suspend, le temps d’une opération
Une à 240 minutes, avec une raison. Le geste est tracé, et ScanGuard se réactive seul à la fin.
Ce que ça vous évite
Vos programmes ne passent pas leur temps à répondre à des robots, et leurs journaux restent lisibles. Les tentatives sur des failles célèbres, comme celle de Log4j, sont arrêtées à l’entrée. Et vous voyez, chiffres à l’appui, ce qu’on essaie contre vous.
Les limites d’aujourd’hui
ScanGuard reconnaît des motifs dans l’adresse demandée et ses paramètres. Il ne juge ni le contenu envoyé, ni le rythme des requêtes d’un même visiteur : ce n’est pas un pare-feu applicatif complet, et il ne dispense pas de tenir vos programmes à jour.