Protéger les accès SSH sur un serveur Linux demeure une priorité pour maintenir une bonne sécurité opérationnelle et réduire les risques d’intrusion. Les attaques par force brute ciblent souvent les services SSH en multipliant les tentatives d’authentification jusqu’à une compromission éventuelle.
La mise en œuvre d’outils comme Fail2ban permet d’automatiser le blocage et la réaction face à ces tentatives malveillantes, tout en coopérant avec le pare-feu. Les points pratiques à appliquer pour la protection des accès suivent sous le titre A retenir :
A retenir :
- Blocage automatique des adresses IP après tentatives répétées
- Renforcement des règles d’authentification SSH par clés publiques
- Interaction contrôlée avec le pare-feu pour blocage temporaire
- Surveillance des journaux et alertes en cas d’intrusion
Étape visuelle pour la configuration et l’analyse des logs :
Configurer Fail2ban pour protéger SSH sous Linux
Après la synthèse, la configuration de Fail2ban offre une ligne de défense immédiate contre le force brute, réduisant le bruit des scans malveillants sur le port SSH. La mise en œuvre repose sur des jails, des filtres et des actions définis dans des fichiers de configuration, faciles à adapter aux contraintes d’exploitation.
Le tableau ci-dessous compare les jails les plus courants et leurs actions associées, pour choisir une stratégie adaptée au service SSH. Ces éléments aident à choisir les règles adaptées au profil de menace du serveur et à l’architecture réseau.
Jail
Description
Action
sshd
Protection basique du service OpenSSH
Blocage IP temporaire
sshd-ddos
Détection des rafales rapides de connexions
Blocage court et limitation de débit
recidive
Blocage des IP récidivistes sur plusieurs services
Blocage prolongé
ssh-guard
Surveillance fine des tentatives SSH spécifiques
Alertes et blocage
Étapes de base :
- Installer fail2ban via le gestionnaire de paquets
- Activer et démarrer le service systemd ou équivalent
- Éditer /etc/fail2ban/jail.local pour le service SSH
- Tester les règles avec des tentatives contrôlées
« J’ai installé Fail2ban sur trois hôtes et les tentatives SSH ont chuté dès la première journée. »
Marc N.
Selon Fail2ban, la combinaison jails+actions reste la méthode recommandée pour bloquer rapidement les IP malveillantes. Selon OpenSSH, renforcer l’authentification par clés réduit fortement la surface d’attaque par force brute.
Pour finir cette section, la configuration de base doit être alignée avec le pare-feu utilisé sur le serveur, afin d’éviter des conflits d’interdiction et de routage. Ce point conduit naturellement à l’intégration directe entre Fail2ban et les règles de filtrage réseau.
Image d’illustration pour intégration pare-feu :
Intégration au pare-feu et réglages d’authentification pour SSH
Comme les jails affectent le filtrage, l’intégration avec le pare-feu est essentielle pour une protection robuste et cohérente des accès. L’ajustement des règles évite des blocages involontaires et améliore la réponse aux incidents côté réseau.
Compatibilité avec iptables, nftables et firewalld
Ce point relie la configuration Fail2ban aux outils de filtrage en place, garantissant une action exécutée correctement au niveau noyau. Selon ANSSI, l’adaptation aux outils locaux est une bonne pratique pour maintenir la disponibilité tout en bloquant les attaquants.
Pare-feu
Compatibilité Fail2ban
Remarque
iptables
Élevée
Interface classique pour Fail2ban
nftables
Bonne
Nécessite hooks récents
firewalld
Support via direct rules
Gestion dynamique des zones
ufw
Compatible
Abstraction simple pour administrateurs
Paramètres recommandés :
- Définir bantime et findtime adaptés au service
- Limiter maxretry selon le profil des utilisateurs
- Utiliser les actions iptables/nftables appropriées
- Activer le journal complet pour audit
« Sur notre parc, l’ajustement bantime a évité des blocages légitimes pendant les pics d’activité. »
Julie N.
L’autre angle concerne l’authentification, avec l’utilisation systématique de clés publiques et la désactivation des mots de passe si possible, afin de réduire l’efficacité des attaques par force brute. Cette préparation oriente la gestion opérationnelle et la surveillance.
Image représentant surveillance et alertes :
Surveillance, alertes et réponse aux intrusions SSH
Après l’intégration au pare-feu et l’amélioration de l’authentification, il reste la surveillance continue, indispensable pour détecter les signes d’une intrusion. La détection précoce permet de limiter l’impact et de déclencher des procédures de réponse adaptées.
Collecte des journaux et alertes automatisées
Ce volet relie la prévention à l’opérationnel par la collecte des logs et la génération d’alertes pour les incidents significatifs. Selon Fail2ban, l’export des événements vers un SIEM augmente la visibilité sur les tendances et les attaques persistantes.
Actions post-intrusion :
- Isoler l’hôte compromis du réseau
- Analyser les journaux pour évaluer la portée
- Changer les clés et les accès affectés
- Renforcer les règles et documenter l’incident
« Après une intrusion, l’analyse des logs a permis d’identifier une clé compromise et de restaurer rapidement le service. »
Prénom N.
« Avis : Fail2ban ne remplace pas une politique globale de sécurité, mais il reste un outil efficace pour le blocage initial. »
Anne N.
Pour conclure ce parcours opérationnel, la combinaison Fail2ban plus règles pare-feu et surveillance apporte une défense en profondeur efficace contre les attaques par force brute. Le passage à une politique plus large doit intégrer la rotation des clés et des audits réguliers pour maintenir la résilience.
Source : ANSSI, « Guide d’hygiène informatique », ANSSI, 2019 ; Fail2ban, « Fail2ban documentation », fail2ban.org, 2024 ; OpenSSH, « OpenSSH manual », OpenBSD, 2020.