Sécuriser SSH sous Debian 11

L’accès SSH est l’accès le plus crucial pour un serveur. Dans ce tutoriel, nous allons appliquer quelques bonnes pratiques pour sécuriser au maximum l’accès SSH.

Désactiver l’accès SSH avec mot de passe

Un mot de passe ne signifie quasiment plus rien en 2022. Si auparavant, celui-ci permettait de sécuriser l’accès à un service, aujourd’hui, nous avons atteint un capacité de calcul et un capacité de trafic réseau suffisamment énorme pour envisager d’essayer toutes les caractères possibles.

Cette technique s’appelle le bruteforce et consiste tout simplement à demander à un ou plusieurs PC, Mac, serveurs Linux, votre frigo connecté ou votre smartphone, d’essayer un à un une liste de mot de passe sur un service. Grâce à internet et une petite armée d’appareils infectés, les hackers arrivent à essayer des milliers si ce n’est des millions de combinaisons de mots de passe en quelques minutes. Il est aussi courant de voir des pirates louer des serveurs ou pirater des sites justement pour cet usage.

Le meilleur moyen de leur couper l’herbe sous le pied et tout simplement de ne pas disposer de mot de passe. S’il n’y a pas de mot de passe à pirater, alors leur bruteforce ne vont pas du tout aboutir.

En remplacement du mot de passe, nous pouvons utiliser la cryptographie à notre avantage et utiliser donc une paire de clé privée/publique pour s’authentifier sur notre serveur SSH.

Création d’une paire de clé SSH

Vous pouvez créer une paire de clé SSH depuis votre PC ou depuis le serveur lui-même. D’ailleurs vous pouvez le créer sur n’importe quel appareil. Sous Windows, l’outil PuTTY vous permet de le faire. Sous Linux et Mac, vous pouvez utiliser la commande suivante :

ssh-keygen -t rsa

L’option -t rsa permet d’indiquer l’algorithme à utiliser. Une fois vos clés créés, vous devez être en possession d’une clé privée et d’une clé publique.

Autoriser la clé SSH à se connecter à un utilisateur sur le serveur SSH

Ensuite, il s’agit d’ajouter votre clé SSH à un utilisateur du serveur. Pour cela, ouvrez le fichier de clé publique qui devrait contenir la clé publique de la forme ssh-rsa XXXXXXXXXXXX(…) user@hostname. Copiez tout cela et ajoutez-le au fichier /root/.ssh/authorized_keys du serveur (créez le fichier et le dossier si nécessaire).

Une fois ajouté au fichier, essayez de vous connecter au SSH. Le serveur ne devrait plus vous demander de mot de passe lors de la connexion.

Désactiver la connexion par mot de passe

Enfin, nous pouvons désactiver la connexion par mot de passe pour l’utilisateur root. Dans le fichier de configuration de votre serveur SSH (/etc/ssh/sshd_config), remplacez :

PermitRootLogin yes

par :

PermitRootLogin without-password

et redémarrez le service SSH :

systemctl restart sshd

Bannir les tentatives de connexion avec mauvais mot de passe avec fail2ban

Une autre chose qui peut être faite est de bannir une adresse IP s’il a obtenu trop d’échec de connexion pour mauvais mot de passe. L’outil fail2ban est justement destiné à cet usage. Pour l’installer :

apt-get install -y fail2ban

Ensuite, pour la configuration, il nous faudra créer le fichier /etc/fail2ban/jail.local avec comme contenu :

[DEFAULT]
bantime = 3600

[sshd]
maxretry = 3
action = iptables-multiport

Dans la section DEFAULT, je définis le temps de blocage sur 3600 secondes (1 heure). Ceci s’appliquera alors à tous les services surveillé par fail2ban. Rien ne vous empêche de spécifier un bantime différent par service en utilisant la même directive dans les sections des services.

La section sshd s’applique du coup pour le service SSH uniquement. J’ai mis maxretry sur 3 pour limiter la connexion à 3 tentatives. L’action iptables-multiport est une action prédéfinie dans fail2ban qui permet de bloquer l’adresse IP détectée sur tous les ports du serveurs et ce en utilisant IPTables.

Maintenant, il s’agit de démarrer fail2ban :

systemctl restart fail2ban

N’oublions pas de l’activer au démarrage :

systemctl enable fail2ban

Vous pouvez ensuite visualiser l’état global de fail2ban avec la commande suivante :

fail2ban-client status

Et vous pouvez voir l’état du monitoring du SSH avec la commande suivante :

fail2ban-client status sshd

Je ne serais pas du tout surpris que vous aillez déjà quelques adresses IP bloqués. Vive internet.

Limiter l’accès SSH à quelques adresses IP de confiance

C’est la solution que je préconise au maximum. Si un voleur ne peut pas toucher votre porte, alors il ne pourra pas faire sauter votre serrure. Malheureusement, je suis dans un cas où mon adresse IP n’est pas fixe, et par conséquent, je peux risquer de me bloquer moi-même si je mets une adresse IP aujourd’hui et que demain je ne peux plus m’y connecter en utilisant cette même adresse IP.

Ainsi, j’utilise l’approche suivante. J’ai listé tous les adresses IPs que mes fournisseurs d’accès Internet pourraient me fournir. Ceci se liste facilement grâce aux informations liés au ASN et aux routes BGP ainsi associés. Pour faire simple, un fournisseur d’accès Internet dispose généralement sa propre numéro AS (le ASN du coup) et chaque adresse IP est associé à un ASN. Une fois l’ASN de votre fournisseur identifié sur peeringdb.com, vous pouvez rechercher les blocs d’IPs associés sur hackertarget.

J’ajoute dans la liste également quelques adresses IPs de confiance, notamment l’adresse IP de quelques un de mes autres serveurs, au cas où je suis vraiment bloqué et que je dois utiliser un autre de mes serveurs pour se frayer un chemin dans ce serveur en particulier. C’est toujours mieux que se connecter sur une console KVM over IP.

C’est une sacré liste, mais pas aussi grande qu’Internet tout entier. Ca coupe déjà l’herbe sous le pied de pas mal de machines infectés et de hackers malintentionnés. C’est mieux que rien.

Maintenant qu’on a la liste à autoriser, configurons le pare-feu. Pour ma part, j’utilise IPSet avec IPTables qui me permet de lister un grand nombre de plage IP sans perdre trop de performances. Commençons par créer le set d’IP autorisé à se connecter en SSH :

ipset -N admin hash:net

Ensuite, ajoutons-y des adresses IP :

ipset -A admin 1.2.3.4

Evidement, 1.2.3.4 a vocation à être remplacé par une adresse IP ou un CIDR. Enfin, autorisons ce set d’IP sur le port 22 :

iptables -A INPUT -p tcp --dport 22 -m set --match-set admin src -j ACCEPT

Et enregistrons les modifications :

ipset save > /etc/ipset.conf
iptables-save > /etc/iptables/rules.v4

Si vous n’avez pas iptables-save, alors il faut installer iptables-persistent :

apt-get install iptables-persistent

Et voilà, votre service SSH est désormais limité aux adresses IPs que vous avez fournis.