Comprendre le brute force sur un serveur

Dès qu'un serveur expose un service d'authentification sur Internet, il reçoit des tentatives automatisées. Ce n'est pas une attaque ciblée, c'est du bruit de fond : des robots essaient des identifiants courants sur SSH, les formulaires de connexion et les API. Savoir le reconnaître permet de ne pas confondre cette pression normale avec une intrusion réelle.

Ce que montrent les journaux

sudo journalctl -u ssh -n 100 --no-pager
sudo grep "Failed password" /var/log/auth.log | tail -n 20
sudo grep -c "Failed password" /var/log/auth.log
sudo lastb | head

Les lignes typiques mentionnent invalid user admin, root ou des noms aléatoires, suivies de Failed password. Sur une installation minimale sans rsyslog, /var/log/auth.log peut être absent : journalctl reste alors la source fiable. Des centaines de tentatives par jour sur une IPv4 publique sont banales. Ce qui compte, ce sont les lignes Accepted : une connexion réussie depuis une adresse inconnue est le signal à examiner en priorité.

Pourquoi les clés changent la donne

Une attaque par mot de passe n'a de prise que si l'authentification par mot de passe est active. Une clé Ed25519 correctement protégée ne se devine pas. L'ordre des opérations compte :

1. installez votre clé et testez-la dans une seconde session ;
2. définissez PasswordAuthentication no et PermitRootLogin prohibit-password dans /etc/ssh/sshd_config.d/ ;
3. validez avec sudo sshd -t, puis rechargez le service ;
4. gardez la première session ouverte jusqu'à confirmation.

Changer le port SSH réduit le bruit dans les journaux mais ne constitue pas une mesure de sécurité à lui seul : un scan trouve le port en quelques minutes.

Limiter la surface

• AllowUsers restreint les comptes autorisés à se connecter.
• MaxAuthTries 3 et LoginGraceTime 20 réduisent les essais par connexion.
• ufw limit 22/tcp applique une limitation de débit simple si UFW est en place.
• Fail2ban bannit temporairement une adresse après plusieurs échecs.

sudo apt install fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Dans jail.local, ajustez la durée et le seuil, et surtout ajoutez votre adresse d'administration à ignoreip avant d'activer :

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 VOTRE_IP_ADMIN

[sshd]
enabled = true

Contrôlez ensuite l'état avec sudo fail2ban-client status sshd. Sans liste blanche, une erreur de configuration peut vous bannir vous-même.

Réagir à une tentative réussie

Si vous trouvez une ligne Accepted inconnue, considérez le serveur comme compromis : vérifiez ~/.ssh/authorized_keys, les utilisateurs (/etc/passwd), les tâches cron, les processus et les connexions sortantes. Changez les mots de passe et les clés, puis envisagez une réinstallation si des binaires ont été modifiés. Redémarrer le service ne suffit pas : l'accès persiste.

Autres cibles

Les formulaires de connexion web, wp-login.php, les API et le SMTP subissent la même pression. Protégez-les avec une authentification solide, une limitation de débit au niveau de Nginx et, si possible, une double authentification. Si le trafic sature votre VPS, contactez le support : le filtrage réseau en amont ne remplace pas une application correctement configurée.