CrowdSec est un outil de défense réseau communautaire qui dépasse les limites de fail2ban en mutualisant les informations entre serveurs. Contrairement à fail2ban, isolé et réactif, CrowdSec permet à un serveur d’apprendre des attaques détectées ailleurs et d’appliquer des bannissements préventifs avant même qu’une IP malveillante n’atteigne son infrastructure. Le système repose sur trois composants : l’Agent, qui analyse les logs locaux et génère des décisions de blocage ; le Bouncer, qui applique ces décisions à différents niveaux (réseau, proxy ou application) ; et la CAPI, une API centrale qui agrège et redistribue les bannissements validés par consensus parmi la communauté.
Le modèle de CrowdSec répond à trois faiblesses majeures de fail2ban : l’isolement des serveurs, l’inefficacité face aux attaques distribuées (botnets utilisant des milliers d’IP) et le coût silencieux des attaques répétées sur les ressources. En partageant les signaux d’attaque et en appliquant des bannissements globaux, CrowdSec réduit la charge sur les infrastructures tout en améliorant la réactivité contre les menaces émergentes.
L’écosystème de CrowdSec permet une intégration flexible, avec des scénarios personnalisables et des mécanismes de consensus pour limiter les faux positifs. Prochainement, un billet détaillera son déploiement concret, illustrant comment cette approche communautaire transforme la sécurité des serveurs publics.
Cet article explique comment sécuriser une connexion SSH en utilisant des clés publiques/privées, en désactivant l'authentification par mot de passe et en installant fail2ban. Il détaille les étapes pour générer une paire de clés (préférentiellement avec l'algorithme ed25519), les copier sur le serveur, ajuster les permissions et configurer PuTTY pour Windows. Une manipulation simple mais efficace pour protéger son serveur contre les attaques par force brute.
Ce guide explique comment sécuriser un serveur personnel Linux sur un MiniPC en installant Fail2ban avant de l'ouvrir à Internet. Fail2ban protège contre les attaques par force brute en bannissant les adresses IP après un nombre défini de tentatives de connexion échouées. Le tutoriel détaille l'installation de Fail2ban, l'ouverture du serveur sur Internet, et l'installation de Docker pour déployer des services comme Adguard. Il souligne l'importance de la sécurité même pour les serveurs personnels, souvent ciblés par des robots malveillants.
Ce guide pratique propose des bonnes pratiques pour sécuriser un serveur Apache2 sous Debian/Ubuntu. Il couvre des aspects essentiels comme masquer la version d'Apache et de l'OS, désactiver le listing des répertoires, configurer des en-têtes de sécurité, désactiver les méthodes HTTP inutiles, et utiliser Fail2Ban pour bloquer les attaques par force brute. Des exemples de configurations et des explications détaillées sont fournis pour chaque étape, avec une conclusion rappelant l'importance de maintenir les mises à jour régulières pour une sécurité continue.
Ce guide compare SSHGuard et Fail2ban pour la protection SSH sur Debian/Ubuntu. SSHGuard, écrit en C, est plus léger (1-2 Mo) et utilise un parseur lexical natif, tandis que Fail2ban, en Python, consomme plus de ressources (9 Mo à 2.5 Go) et repose sur des expressions régulières. SSHGuard est idéal pour les serveurs avec ressources limitées et une protection SSH prioritaire, tandis que Fail2ban convient pour protéger plusieurs services avec des règles personnalisées. Le guide explique aussi l'installation, la configuration de base et le système de scoring de SSHGuard.
Ce billet détaille l’expérience de passage à FrankenPHP en production, comparant l’ancienne stack Nginx/PHP-FPM à une technologie dépassée comme le Minitel. L’auteur explique comment il a déployé FrankenPHP sur un VPS à l’aide d’un Makefile optimisé, en abordant la création d’un Dockerfile de production, l’intégration CI/CD, et une astuce de multiplexing SSH pour éviter les blocages par fail2ban. Une lecture utile pour ceux qui veulent moderniser leur infrastructure PHP avec simplicité et efficacité.
Le 17 août 2025, le blog de l’auteur a subi un incident informatique : environ 179 000 requêtes web en 14 heures, ciblant uniquement trois fichiers sitemap.xml, provenant de 168 000 adresses IP uniques (majoritairement IPv4). L’attaque, jugée naïve et peu sophistiquée, a permis à l’auteur de réviser ses connaissances sur nftables et fail2ban. Après avoir bloqué l’accès aux fichiers ciblés via Apache, il a tenté de filtrer les requêtes avec fail2ban, mais a dû ajuster sa stratégie face à la charge : bannissement par grands blocs d’IP (/8 puis /16 en IPv4), limitation du trafic entrant, et enfin blocage par pays (sauf France). Malgré des erreurs initiales (rechargement intempestif de fail2ban, lecture complète des logs), l’incident a été maîtrisé en combinant ces outils et en nettoyant les logs pour éviter d’alourdir les sauvegardes. L’auteur souligne l’importance de bien connaître ses outils avant un incident et partage des commandes utiles pour nftables et fail2ban.
Un retour d’expérience technique et pédagogique sur la gestion d’un flux massif de requêtes indésirables.
L'auteur souhaite sécuriser son réseau local très ouvert, notamment contre les robots d'IA qui consomment des ressources. Il utilise pour cela Reaction, une alternative légère et performante à Fail2Ban, écrite en Rust, pour bloquer les connexions indésirables. Les logs sont centralisés sur une machine via rsyslog, où Reaction sera installé pour surveiller et réagir en exécutant des commandes SSH sur le routeur/firewall, un Turris Omnia sous OpenWRT. La configuration du firewall, basée sur nft, a été modernisée pour supporter à la fois IPv4 et IPv6.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
L'auteur montre comment combiner un conteneur Docker pour Nginx avec Fail2Ban.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Une alternative à fail2ban
Tout est dans le titre