Il est indispensable de connaître les bonnes pratiques afin de sécuriser son serveur SSH auquel cas un pirate pourrait mener des actions malveillantes sur celui-ci.

---

Qu’est-ce qu’un serveur SSH ?

Revenons rapidement aux bases, SSH est un protocole de communication sécurisé qui signifie Secure SHell et qui va permettre à un client et un serveur de communiquer entre eux s’ils possèdent un programme qui implémente ce protocole.

Généralement, on utilise la brique logicielle OpenSSH qui est, comme son nom l’indique, open source. Open SSH possède de nombreux outils comme :

• ssh qui remplace le programme rlogin et telnet.
• scp qui remplace le programme rcp.
• sftp qui remplace le programme ftp.
• et bien d’autres…

---

Pourquoi sécuriser son serveur SSH ?

Le serveur SSH est souvent l’accès principal à un système. De ce fait, il est le Graal pour les pirates.

Nous allons donc voir une liste de mesures facilement applicables afin de renforcer la sécurité de votre serveur SSH, aussi appelé hardening de serveur SSH.

Toutes les lignes de configurations fournies seront à placer dans /etc/ssh/sshd_config. A chaque fois que vous modifiez votre configuration vous devez redémarrer le serveur SSH pour qu’elle s’applique.

Pour redémarrer le serveur SSH :

sudo systemctl restart sshd

---

Bannir SSHv1 et utiliser SSHv2

C’est probablement déjà le cas sur votre serveur si vous avez fait vos mises à jour mais nous ne sommes jamais trop sûrs.

Le SSHv1 est la version 1 du protocole SSH mais il existe aussi la version 2, SSHv2, qui corrige un large périmètre d’attaques comme l’usurpation de DNS et d’IP (DNS and IP Spoofing) et le MITM (Man In The Middle).

Pour savoir si votre serveur est bien configuré, il suffit d’essayer d’initier une connexion avec la commande :

ssh -1 user@adresse_ip -p num_de_port

Si tout se passe bien, vous aurez alors comme retour de la part de serveur :

SSH protocol v.1 is no longer supported

Pour vous assurer que le protocole SSHv2 fonctionne, vous pouvez de nouveau initier une connexion avec -2.

ssh -2 user@adresse_ip -p num_de_port

Pour les personnes qui arrivent à se connecter à le serveur via la version 1 du protocole SSH, rendez-vous dans votre fichier de configuration et ajoutez cette ligne (ou changez-la) :

Protocol 2

---

Interdire l’accès au compte root

Par défaut, vous pouvez vous connecter en SSH avec le compte root. Utile lors du début d’une configuration, si vous louez un VPS ou un dédié par exemple, cela ne doit pas rester ainsi. Il est inconcevable de laisser l’accès d’un autre Graal aux pirates.

Avant d’interdire l’accès au compte root, veillez à ajouter un autre utilisateur avec les permissions nécessaires pour continuer d’administrer dans de bonnes conditions votre serveur.

Pour interdire l’autorisation au compte root, modifiez ou ajoutez cette ligne :

PermitRootLogin no

Désormais, si vous essayez de vous connecter :

root@192.168.6.3's password: 
Permission denied, please try again.

---

Un utilisateur par personne ayant besoin d’un accès

Cela peut paraître logique mais j’ai souvent vu des serveurs avec un ou deux comptes utilisés par quatre ou cinq utilisateurs. C’est une très mauvaise pratique.

Si deux personnes souhaitent avoir accès au serveur, il faut créer deux comptes. C’est pratique pour la lecture de log par exemple pour savoir qui a fait quoi ou encore lors d’un piratage. Cela permet de cibler qui s’est fait avoir.

Pour ajouter un utilisateur :

adduser nom_user

---

Autoriser uniquement les comptes nécessaires

Si vous avez huit comptes sur votre serveur, vous n’avez peut-être pas besoin d’un accès SSH sur tous ces comptes. Si j’ai seulement besoin de me connecter avec le compte thibault, alors je n’autorise la connexion SSH qu’à celui-ci.

Pour se faire :

AllowUsers nom_user1 nom_user2
# Dans mon cas: AllowUsers thibault

Désormais si j’essaie de me connecter avec l’utilisateur ‘test’ :

ssh test@192.168.6.3
test@192.168.6.3's password:
Permission denied, please try again.

A noter que vous pouvez aussi autoriser un groupe :

AllowGroups nom_group1 nom_group2

---

Changer le numéro de port par défaut

Par défaut, vous vous connectez à votre serveur SSH sur le port 22.
Pour vérifier cela vous pouvez essayer de vous connecter sans préciser le port ou préciser le port 22.

ssh user@adresse_ip -p 22

Utiliser le port par défaut est une mauvaise pratique, c’est comme laisser le mot de passe par défaut. Le problème majeur est le fait que les pirates (mais surtout les robots qu’ils ont configurés) tentent de manière massive des connexions sur les serveurs SSH.

Pour être plus tranquille, il est vivement recommandé de changer le numéro de port par défaut. Encore une fois, on évite 222 et 2222 qui sont désormais aussi testé par les pirates. Attention aussi à ne pas mettre le même numéro de port qu’un autre service utilisé sur votre serveur.

Pour le changer, modifiez ou ajoutez cette ligne :

Port 2223

Désormais, pour vous connecter il faudra préciser le port.

ssh user@adresse_ip -p 2223

---

Désactiver le X11Forwarding

Le X11Forwarding est un système permettant de vous renvoyer un retour graphique si votre serveur a un environnement graphique justement. Votre serveur est probablement en interface CLI (noir et blanc), alors il est recommandé de le désactiver.

X11Forwarding no

---

Afficher la dernière connexion au serveur SSH

Par défaut, l’affichage de la dernière connexion avec la date et l’adresse IP est affichée. Si ça n’est pas le cas, changez ou modifier par :

PrintLastLog yes

Désormais si vous vous connectez vous pouvez voir :

Last login: Mon Dec  7 04:50:42 2020 from 192.168.6.1

Cette mesure est importante si vous ne surveillez jamais vos logs, alors c’est un moyen simple pour que chaque utilisateur surveille les connexions à son échelle.

---

Désactiver la connexion via des comptes sans mots de passe

Il est possible de créer des utilisateurs sans mot de passe. Si ces utilisateurs sont autorisés à se connecter en SSH, alors vous laissez la porte ouverte aux personnes qui connaissent le nom d’utilisateur. Normalement la valeur par défaut est « No », si ça n’est pas le cas :

PermitEmptyPasswords no

---

Changer la durée maximale d’authentification au serveur SSH

Par défaut, lorsque vous initiez une connexion sur un serveur SSH, vous avez deux minutes pour terminer l’authentification. C’est bien plus que nécessaire. Si un attaquant lance plusieurs connexions, votre serveur gardera la connexion pendant 2 minutes s’il ne tente pas trois connexions.

Pour limiter la charge serveur, il est recommandé de diminuer la valeur à 30 secondes par exemple.

# Avant : LoginGraceTime 2m
LoginGraceTime 30

---

Générer des clés RSA de 2048 bits minimum

Désormais, il est recommandé de générer des clés RSA de 2048 bits minimum. Pour qu’un utilisateur génère sa paire de clé privée/publique, il suffit d’effectuer la commande :

ssh-keygen -t rsa -b 2048

Bien entendu il faut définir une passphrase (phrase secrète) afin que votre clé privée soit chiffrée. De ce fait, lors de vos futures connexions à un serveur SSH, il ne vous sera plus demandé le mot de passe de votre compte mais la phrase secrète pour déchiffrer la clé privée.

---

Une paire de clés par service

Même idée que : « un accès, un compte », on prend soin de générer une paire de clés par service. Si vous avez un compte Gitlab et un serveur SSH, il est impensable d’utiliser la même paire de clés sur les deux services.

En effet, l’idée est de diminuer les risques. Si vous utilisez la même paire de clés sur dix services et que votre clé privée est compromise, alors vos dix services le sont aussi…

---

Activer l’option StrictModes

L’option StrictModes permet de vérifier les permissions de l’utilisateur en question notamment ses clés SSH, sinon la connexion est refusée car le risque est trop important.

En pratique :

• Votre clé privée ne doit être lisible et écrivable uniquement par vous.
• Votre clé publique doit être lisible et écrivable uniquement par vous et lisible pour tout le monde.

Pour activer cette option :

StrictModes yes

---

Qu’est qu’un VPS ? 

Un hébergement VPS est un serveur logique ou virtuel ce qui est différent d’un serveur physique, VPS signifiant Virtual Private Server en anglais. C’est différent d’un serveur physique puisque la première différence étant qu’un serveur physique peut héberger plusieurs serveurs virtuels puisque les ressources principes d’un serveur physique peuvent être partagées entre plusieurs serveurs virtuels. Cela peut donc être une solution plus sécurisée et plus stable que l’hébergement partagé où vous n’aurez pas d’espace serveur dédié. Cependant, le fait que le serveur virtuel est plus petit est à prendre en compte, mais du coup l’avantage c’est qu’il est moins cher que de louer un serveur entier. En général, ce sont les propriétaires de sites Web qui ont un trafic de niveau moyen dépassant les limites des plans d’hébergement partagés, mais qui cependant, n’ont toujours pas besoin des ressources d’un serveur dédié, qui choisissent l’hébergement VPS. En général, ces solutions offrent plusieurs plans d’hébergement afin de pouvoir répondre aux différents besoins de l’entreprise pour vous permettre de faire évoluer votre site internet de manière transparente lorsque vous avez besoin de davantage de ressources. Pour comprendre le fonctionnement d’un hébergeur VPS, il est fondamental de savoir qu’un serveur est un ordinateur sur lequel votre hébergeur stocke les fichiers et les bases de données nécessaires à votre site internet. C’est pourquoi il est primordial de parler de la sécurisation de votre VPS sous windows, puisque chaque fois qu’un visiteur en ligne voudra accéder à votre site internet, son navigateur va envoyer une demande à votre serveur et transférera les fichiers qui sont nécessaires via internet. L’Hébergeur VPS va donc vous fournir un serveur virtuel qui va simuler un serveur physique, mais en réalité, la machine sera partagée entre plusieurs utilisateurs. Si ce concept d’hébergement vous a séduit, n’hésitez plus une seule seconde. 

Sécuriser son serveur SSH : conclusion

Les serveurs SSH sont des points d’entrée extrêmement sensibles, il est donc indispensable d’appliquer ces quelques mesures. J’en ai probablement oubliées et je m’en excuse par avance. J’essaierai de tenir ce billet à jour car ce qui est vrai en ce moment ne le sera pas forcément dans cinq ans.

Bien sûr, faites régulièrement vos mises à jour, on remarque que de nombreux conseils sont appliqués dans la configuration par défaut si le serveur SSH est bien à jour.