Durcissement SSH et fail2ban

Sommaire

1. Compte d'administration dédié
2. Authentification par clé
3. Configuration de sshd
4. fail2ban
5. Vérifier par l'attaque
6. Aller plus loin : 2FA

Le service SSH est la porte d'administration : c'est la première cible d'un balayage automatisé sur Internet. Le durcir, c'est réduire à la fois la surface et l'intérêt de l'attaque.

1. Compte d'administration dédié

On crée un utilisateur sysadmin réservé à l'administration, et on n'utilise jamais root en direct.

sudo adduser sysadmin
sudo usermod -aG sudo sysadmin

Imputabilité : les actions sont tracées sous un nom réel, alors que root est partagé par tous les administrateurs.
Réduction de la surface : root existe sur toutes les machines Linux, donc l'attaquant connaît déjà la moitié du couple identifiant / mot de passe.
Passage explicite par sudo : chaque élévation de privilège est journalisée.

2. Authentification par clé

Depuis le poste d'administration :

ssh-keygen -t ed25519
ssh-copy-id -p 22 sysadmin@IP_SERVEUR

Ed25519 vs RSA 4096 :

	RSA 4096	Ed25519
Famille mathématique	Factorisation de grands entiers	Courbes elliptiques (courbe Edwards 25519)
Taille de clé	4096 bits	256 bits pour un niveau de sécurité équivalent ou supérieur
Performance	Génération et signature lentes	Très rapide
Implémentation	Sensible à la qualité du générateur aléatoire, nombreux paramètres	Paramètres figés, signatures déterministes, moins de pièges d'implémentation

C'est cette robustesse d'implémentation, autant que la performance, qui motive la recommandation d'Ed25519.

3. Configuration de sshd

Dans /etc/ssh/sshd_config :

Port 2022
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
AllowUsers sysadmin

Directive	Effet
`Port 2022`	Déplace le service hors du port scanné en masse
`PermitRootLogin no`	Interdit la connexion directe en root
`PasswordAuthentication no`	Rend le brute-force de mot de passe sans objet
`MaxAuthTries 3`	Ferme la connexion après 3 échecs
`LoginGraceTime 30`	Limite le temps d'une session non authentifiée
`AllowUsers sysadmin`	Liste blanche des comptes autorisés à se connecter

sudo sshd -t          # vérifier la syntaxe AVANT de redémarrer
sudo systemctl restart ssh

Toujours garder une session ouverte en parallèle pendant la manipulation : si la nouvelle configuration est fautive, elle permet de revenir en arrière sans passer par la console physique.

Changer le port : sécurité ou security by obscurity ?

Les deux lectures se défendent, et l'exercice attend une réponse nuancée :

Ce n'est pas de la sécurité au sens strict : un nmap -p- retrouve le service en quelques secondes. Aucune faille n'est corrigée, aucune authentification n'est renforcée.
C'est utile en pratique : l'essentiel du bruit provient de robots qui ne testent que le port 22. Le déplacement supprime des milliers de lignes de log par jour, ce qui rend les vraies tentatives visibles.
Conclusion : mesure d'hygiène et de lisibilité des journaux, jamais une mesure suffisante à elle seule. Elle n'a de valeur qu'au-dessus des clés SSH et de fail2ban.

4. fail2ban

sudo apt-get install fail2ban

Dans /etc/fail2ban/jail.local :

[sshd]
enabled  = true
port     = 2022
maxretry = 3
findtime = 600
bantime  = 3600

Lecture : 3 échecs dans une fenêtre de 600 secondes déclenchent un bannissement de l'adresse IP pendant 3600 secondes. fail2ban lit les journaux et insère dynamiquement des règles de filtrage.

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

5. Vérifier par l'attaque

Depuis une machine Kali, sur le réseau de TP uniquement :

hydra -l sysadmin -P /usr/share/wordlists/rockyou.txt -s 2022 ssh://IP_SERVEUR -t 4

Résultat attendu : après quelques tentatives, la connexion est refusée et l'IP apparaît dans la liste des adresses bannies. Deux protections se cumulent ici : PasswordAuthentication no rend l'attaque inopérante par nature, et fail2ban coupe la source.

À ne faire que sur une infrastructure dont on a la responsabilité. Mener ce type de test sur un système tiers sans autorisation écrite relève de l'article 323-1 du Code pénal.

6. Aller plus loin : 2FA sur SSH

Ajout d'un second facteur avec libpam-google-authenticator : après la clé, le serveur demande un code temporaire (TOTP) généré par une application mobile. La clé couvre « ce que je possède » côté machine, le TOTP couvre « ce que je possède » côté utilisateur — utile lorsque le poste d'administration lui-même peut être compromis.