Fail2ban est souvent le réflexe par défaut pour protéger SSH contre les attaques bruteforce. Pourtant, SSHGuard offre une approche plus légère et tout aussi efficace. Découvrez le « set & forget » de la protection SSH.
Face aux milliers de tentatives de connexion SSH que subit quotidiennement tout serveur exposé sur Internet, un système de protection devient indispensable. Si Fail2ban domine le marché, SSHGuard propose une philosophie différente qui mérite votre attention.
Le « set & forget » résume bien la philosophie SSHGuard : on configure, on oublie, ça tourne.
SSHGuard vs Fail2ban : le match
Architecture et consommation de ressources
Fail2ban est écrit en Python et repose sur des expressions régulières pour parser les logs. Chaque service surveillé nécessite un “jail” avec ses propres règles regex.
SSHGuard est écrit en C, compilé nativement. Il utilise un parseur lexical optimisé qui reconnaît les patterns d’attaque sans configuration regex complexe.
En termes de mémoire, Fail2ban affiche une consommation variable : environ 9 Mo sur un système bien configuré, mais sa base SQLite peut gonfler avec le temps. Sur des serveurs très sollicités, des cas de bloat atteignant 2.5 Go ont été rapportés.
SSHGuard, lui, tourne autour de 1 à 2 Mo.
# Comparez par vous-même
ps aux | grep -E "(fail2ban|sshguard)" | awk '{print $11, $6/1024 " Mo"}'
Sur un VPS aux ressources limitées, la différence est significative.
Détection des attaques
| Critère | SSHGuard | Fail2ban |
|---|---|---|
| Méthode de détection | Parseur lexical natif | Expressions régulières |
| Configuration | Minimale | Extensive |
| Services supportés | SSH, FTP, SMTP, etc. | Quasi illimité |
| Faux positifs | Très rares | Dépend des regex |
| Temps de réaction | Quasi instantané | Intervalle de polling |
Quand choisir SSHGuard ?
- VPS/serveurs avec ressources limitées : empreinte mémoire minimale
- Protection SSH prioritaire : optimisé pour ce cas d’usage
- Configuration simple : fonctionne out-of-the-box
- Performances : parseur C natif vs interpréteur Python
Quand préférer Fail2ban ?
- Nombreux services à protéger : Apache, Nginx, Postfix, etc.
- Besoins de personnalisation : règles regex sur mesure
- Écosystème existant : nombreux jails communautaires disponibles
Installation sur Debian/Ubuntu
Installation depuis les dépôts
# Mise à jour des paquets
sudo apt update
# Installation de SSHGuard
sudo apt install sshguard
# Vérification de l'installation
sshguard -v
SSHGuard s’installe avec un backend par défaut adapté à votre système (généralement iptables ou nftables sur les distributions récentes).
Vérification du service
# Statut du service
sudo systemctl status sshguard
# Logs en temps réel
sudo journalctl -fu sshguard
Configuration de base
Le fichier de configuration principal se trouve dans /etc/sshguard/sshguard.conf :
# Afficher la configuration actuelle
cat /etc/sshguard/sshguard.conf
Paramètres essentiels
# /etc/sshguard/sshguard.conf
# Seuil de dangerosité avant blocage (défaut: 30)
# Une tentative SSH échouée = 10 points → 3 échecs = blocage
THRESHOLD=30
# Durée du premier blocage en secondes (défaut: 120)
BLOCK_TIME=180
# Temps après lequel le score d'une IP est réinitialisé (défaut: 1800)
DETECTION_TIME=1800
# Fichier whitelist
WHITELIST_FILE=/etc/sshguard/whitelist
# Backend utilisé (iptables, nftables, pf, etc.)
BACKEND="/usr/libexec/sshguard/sshg-fw-nft-sets"
Comprendre le système de scoring
SSHGuard utilise un système de points pour évaluer la dangerosité d’une IP :
| Événement | Points |
|---|---|
| Échec authentification SSH | 10 |
| Échec authentification FTP | 10 |
| Attaque détectée | 10-40 |
Quand le score atteint le THRESHOLD, l’IP est bloquée pour BLOCK_TIME secondes. Les blocages suivants sont exponentiels.
Configuration avancée
Whitelist : ne jamais se bloquer soi-même
Créez ou éditez le fichier whitelist :
sudo nano /etc/sshguard/whitelist
# /etc/sshguard/whitelist
# Une entrée par ligne
# IP locale
127.0.0.0/8
# Votre IP fixe (IMPORTANT)
203.0.113.42
# Plage d'IP de votre entreprise
192.168.1.0/24
# Nom d'hôte (résolu au démarrage)
monserveur.example.com
Attention : Ajoutez TOUJOURS votre IP de connexion avant d’activer SSHGuard. Sinon, quelques erreurs de mot de passe et vous serez bloqué.
Backend nftables (recommandé pour Debian 11+)
Sur les systèmes récents, nftables remplace iptables. Configurez SSHGuard pour l’utiliser :
# Vérifier le backend actuel
grep BACKEND /etc/sshguard/sshguard.conf
# Pour nftables avec sets (plus performant)
BACKEND="/usr/libexec/sshguard/sshg-fw-nft-sets"
Créez la table nftables pour SSHGuard si nécessaire :
# Créer la configuration nftables
sudo nano /etc/nftables.conf
#!/usr/sbin/nft -f
table inet sshguard {
set attackers {
type ipv4_addr
flags interval
}
set attackers6 {
type ipv6_addr
flags interval
}
chain input {
type filter hook input priority filter - 10; policy accept;
ip saddr @attackers drop
ip6 saddr @attackers6 drop
}
}
# Appliquer la configuration
sudo nft -f /etc/nftables.conf
# Redémarrer SSHGuard
sudo systemctl restart sshguard
Backend iptables (systèmes legacy)
Pour les systèmes utilisant encore iptables :
# Configuration backend iptables
BACKEND="/usr/libexec/sshguard/sshg-fw-iptables"
Tuning pour environnements sensibles
Pour un serveur de production critique, ajustez les paramètres :
# /etc/sshguard/sshguard.conf
# Plus strict : blocage après 2 échecs
THRESHOLD=20
# Blocage initial plus long : 10 minutes
BLOCK_TIME=600
# Fenêtre de détection étendue : 1 heure
DETECTION_TIME=3600
Surveillance de services additionnels
SSHGuard peut protéger d’autres services. Modifiez la source des logs :
# Surveiller plusieurs fichiers de logs
FILES="/var/log/auth.log /var/log/vsftpd.log"
# Ou via journald (systemd)
LOGREADER="LANG=C /usr/bin/journalctl -afb -p info -n1 -t sshd -t vsftpd -o cat"
Intégration dans une stratégie de sécurité SSH
SSHGuard est une couche de défense. Combinez-le avec d’autres mesures :
1. Configuration SSH durcie
# /etc/ssh/sshd_config
# Désactiver l'authentification par mot de passe
PasswordAuthentication no
# Autoriser uniquement les clés SSH
PubkeyAuthentication yes
# Désactiver root login
PermitRootLogin no
# Limiter les utilisateurs autorisés
AllowUsers deploy admin
# Réduire le délai d'authentification
LoginGraceTime 30
# Limiter les tentatives par connexion
MaxAuthTries 3
# Appliquer les changements
sudo systemctl restart sshd
2. Port SSH non standard
# /etc/ssh/sshd_config
Port 2222
# N'oubliez pas d'ouvrir le nouveau port dans le firewall
sudo ufw allow 2222/tcp
sudo ufw delete allow 22/tcp
3. Firewall de base avec ufw
# Activer ufw
sudo ufw enable
# Autoriser SSH (port personnalisé si modifié)
sudo ufw allow 2222/tcp
# Vérifier les règles
sudo ufw status verbose
Commandes utiles
Gestion du service
# Démarrer/Arrêter/Redémarrer
sudo systemctl start sshguard
sudo systemctl stop sshguard
sudo systemctl restart sshguard
# Activer au démarrage
sudo systemctl enable sshguard
# Logs en temps réel
sudo journalctl -fu sshguard
Gestion des blocages
# Voir les IPs bloquées (nftables - IPv4)
sudo nft list set ip sshguard attackers
# Voir les IPs bloquées (nftables - IPv6)
sudo nft list set ip6 sshguard attackers
# Voir les IPs bloquées (iptables)
sudo iptables -L sshguard -n
# Débloquer une IP manuellement (nftables)
sudo nft delete element ip sshguard attackers { 192.0.2.1 }
# Débloquer une IP (iptables)
sudo iptables -D sshguard -s 192.0.2.1 -j DROP
# Flush toutes les règles SSHGuard (nftables)
sudo nft flush set ip sshguard attackers
Tester le fonctionnement
# Depuis une autre machine, provoquez des échecs
ssh fakeuser@votre-serveur
# Entrez un mauvais mot de passe plusieurs fois
# Vérifiez les logs sur le serveur
sudo journalctl -fu sshguard
# Vous devriez voir : "Blocking 203.0.113.x for 180 seconds"
Troubleshooting
Bug Ubuntu : SSHGuard se bloque lui-même
Sur Ubuntu, la configuration par défaut de LOGREADER peut causer un bug où SSHGuard se retrigger sur ses propres messages de log. Résultat : une IP est bannie instantanément après une seule erreur.
Fix : Modifiez /etc/sshguard/sshguard.conf pour filtrer uniquement les logs sshd :
# Avant (bugué)
LOGREADER="LANG=C /bin/journalctl -afb -p info -n1 -o cat SYSLOG_FACILITY=4 SYSLOG_FACILITY=10"
# Après (corrigé)
LOGREADER="LANG=C /bin/journalctl -afb -p info -n1 -o cat -t sshd"
Redémarrez ensuite le service :
sudo systemctl restart sshguard
SSHGuard ne bloque pas les attaques
# Vérifier que le service tourne
sudo systemctl status sshguard
# Vérifier les logs pour les erreurs
sudo journalctl -u sshguard --no-pager | tail -50
# Vérifier que le backend est correct
grep BACKEND /etc/sshguard/sshguard.conf
# Tester le backend manuellement
sudo /usr/libexec/sshguard/sshg-fw-nft-sets -h
Auto-blocage accidentel
Si vous vous êtes bloqué (c’est couillon mais ça arrive):
- Accès console (KVM/IPMI/Console cloud)
- Débloquez votre IP :
sudo nft delete element ip sshguard attackers { VOTRE_IP }
- Ajoutez votre IP à la whitelist :
echo "VOTRE_IP" | sudo tee -a /etc/sshguard/whitelist
sudo systemctl restart sshguard
Conflit avec d’autres firewalls
SSHGuard peut entrer en conflit avec des règles existantes. Vérifiez l’ordre des chaînes :
# Pour nftables
sudo nft list ruleset | head -50
# Pour iptables
sudo iptables -L -n --line-numbers
2 Mo de RAM, zéro configuration regex, protection immédiate. SSHGuard fait le job sans faire de bruit. Un choix pertinent pour les serveurs où SSH est le principal vecteur d’attaque.
Combiné avec une configuration SSH durcie, des clés plutôt que des mots de passe, et un monitoring régulier, il constitue une défense efficace contre les attaques bruteforce automatisées qui ciblent continuellement les serveurs exposés.
La sécurité en couches reste la meilleure approche : SSHGuard est un maillon, pas une solution miracle.
