laravel-scanner-guard

Laravel Scanner Guard est un package Composer pour les applications Laravel qui identifie et bloque le trafic automatisé des scanners de vulnérabilités atteignant le routeur du framework. Il cible les chemins de sondage courants tels que /wp-admin, /wp-login, /.git/config, /phpmyadmin et /wp-json, en comptant les requêtes répétées par IP et en émettant un bannissement une fois qu'un seuil configurable est atteint dans une fenêtre temporelle. Les IP bannies reçoivent une réponse immédiate (404 par défaut) afin d'éviter le coût du démarrage complet du framework, du routage et du rendu des vues. Le package enregistre un alias de middleware de route scanner-guard que le développeur attache manuellement à un groupe de middlewares ou à des routes spécifiques. La configuration inclut ban_threshold, ban_window, ban_duration, scanner_paths (caractères génériques de style fnmatch) et response_status. Il ne gère explicitement pas les requêtes vers des fichiers .php inexistants littéraux qui échouent au niveau nginx/PHP-FPM avant le démarrage de Laravel — celles-ci nécessitent une correction try_files dans nginx. Le blocage ASN optionnel permet de bloquer entièrement des réseaux entiers (par exemple AS16276/OVH) en utilisant la résolution GeoIP déléguée aux pilotes ip_api ou maxmind de laravel-visitor-fingerprint. Lorsque la liste de blocage est vide, aucune recherche GeoIP n'a lieu, ce qui n'ajoute aucune latence. Chaque bannissement écrit une ligne d'audit dans scanner_guard_bans avec reason, matched_value, hit_count, banned_at et expires_at. La base de données ne stocke qu'un hachage salé de l'IP (jamais l'adresse brute) ; l'IP brute est mise en cache séparément avec un TTL égal à ban_duration pour les besoins de l'export nginx. Une commande Artisan export-denylist écrit les bannissements actifs sous forme de lignes deny nginx, avec une synchronisation automatique quotidienne optionnelle. Le package prend en charge trois pilotes : database (par défaut, avec piste d'audit et statistiques), http (transmet les bannissements à une application centrale via une requête POST JSON signée HMAC, permettant une architecture hub-and-satellite) et cache (bannissement uniquement, sans persistance). Les statistiques agrégées quotidiennes (bans_count, hits_total, reason_stats, top_matched_values) sont enregistrées au moment du bannissement et survivent à la suppression des lignes de bannissement. Une commande aggregate-and-prune réconcilie les statistiques, purge les bannissements expirés et applique la rétention (90 jours par défaut), auto-planifiée quotidiennement par défaut.