ModSecurity et CrowdSec en bordure
Le trafic public vers plusieurs de nos services passe d'abord par un reverse proxy (NS1), où nous terminons le TLS. Sur ce bord, nous activons deux briques complémentaires : ModSecurity (pare-feu applicatif) et CrowdSec (détection / réaction à partir des journaux et de signaux partagés).
ModSecurity
ModSecurity inspecte les requêtes HTTP selon des règles (injections, sondes courantes, etc.). Chez nous, il tourne sur le proxy d'entrée — utile pour filtrer une partie du bruit avant qu'il n'atteigne l'origine.
Ce n'est pas une garantie absolue contre toute vulnérabilité applicative. Un plugin WordPress mal conçu reste votre responsabilité à mettre à jour ; le WAF est une couche, pas un substitut aux correctifs.
CrowdSec
CrowdSec analyse des comportements suspects (bruteforce, scans) et peut bloquer des adresses IP. L'intérêt du modèle est la réaction automatisée et la mutualisation de signaux — pas un « scrubbing center » de plusieurs Tbps.
Ce que nous ne revendiquons pas
Nous n'affichons pas de « protection DDoS 2 Tbps » ni de centres de nettoyage backbone que nous n'opérons pas. Pour la posture globale (pare-feu machines, MFA admin, sauvegardes, surveillance), voir Sécurité et sauvegardes.