Sécurisation SSH sur Ubuntu

Sécurisation du serveur SSH sous Ubuntu

Apprenez à renforcer efficacement la sécurité de vos serveurs Linux en durcissant votre configuration SSH.

Introduction

Nous incluons le serveur OpenSSH sur chaque machine virtuelle OpenSSH est le logiciel de serveur SSH par défaut utilisé sous Ubuntu, Debian, CentOS, FreeBSD et de nombreux autres systèmes basés sur Linux.

Il est important de sécuriser correctement votre serveur OpenSSH, car il constitue la porte d’entrée pour quiconque souhaite accéder à votre serveur. Dans ce tutoriel, vous apprendrez à renforcer votre serveur OpenSSH en utilisant différentes options de configuration pour garantir que l’accès à distance à votre serveur soit aussi sécurisé que possible.

Étape 1 : Renforcement général

Pour commencer à sécuriser votre serveur SSH, nous allons commencer par une configuration sécurisée générale qui conviendra à la majorité des serveurs. Certains utilisateurs avancés peuvent préférer configurer leurs serveurs en fonction de leur propre modèle de menace et de leur seuil de risque, ce qui dépasse le cadre de ce tutoriel.

La plupart des configurations de renforcement pour OpenSSH utiliseront le fichier de configuration standard du serveur OpenSSH, situé à /etc/ssh/sshd_config.

Sauvegarde du fichier de configuration

Avant de continuer avec ce tutoriel, il est recommandé de sauvegarder votre fichier de configuration existant, au cas où quelque chose tournerait mal. Utilisez la commande suivante pour ce faire :

$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.old

Cela sauvegarde une copie du fichier dans /etc/ssh/sshd_config.old.

Modification et test des paramètres

Nous pouvons examiner les options actuelles définies en utilisant cette commande qui exécute le serveur OpenSSH en mode de test étendu, ce qui validera le fichier de configuration complet et affichera les valeurs de configuration effectives :

$ sudo sshd -T

Vous pouvez maintenant ouvrir le fichier de configuration avec votre éditeur de texte préféré et commencer à implémenter les mesures de renforcement initiales :

$ sudo vim /etc/ssh/sshd_config

Lors de la modification de votre fichier de configuration, certaines options seront commentées par défaut à l’aide d’un caractère dièse (#) au début de la ligne. Pour modifier ces options et/ou faire en sorte que l’option commentée soit reconnue, vous devrez les décommenter en supprimant le dièse.

Sécurisation SSH de base (Recommandée)

Tout d’abord, désactivez la connexion via SSH en tant qu’utilisateur root en définissant l’option suivante :

PermitRootLogin no

Ensuite, limitez le nombre maximum de tentatives d’authentification pour une session de connexion particulière en modifiant ce qui suit :

MaxAuthTries 3

Si nécessaire, vous pouvez également définir une période de grâce de connexion réduite, qui est le temps dont dispose un utilisateur pour terminer l’authentification après s’être initialement connecté à votre serveur SSH :

LoginGraceTime 20

Authentification par clé SSH (Optionnelle)

Les clés SSH sont une autre méthode pour authentifier une connexion distante à un serveur. En savoir plus ici.

Tout d’abord, si ce n’est pas déjà fait, vous devrez définir une paire de clés SSH. En savoir plus sur la façon de le faire ici.

Ensuite, vous devrez transférer la clé publique de votre ordinateur vers le serveur. Vous pouvez le faire en exécutant la commande suivante depuis votre propre ordinateur :

ssh-copy-id user@<SERVER IP>

Si vous avez configuré des clés SSH pour l’authentification, plutôt que d’utiliser des mots de passe, désactivez l’authentification par mot de passe SSH pour empêcher les mots de passe d’utilisateur divulgués de permettre à un attaquant de se connecter :

PasswordAuthentication no

Comme mesure de renforcement supplémentaire liée aux mots de passe, vous pouvez également désactiver l’authentification avec des mots de passe vides. Cela empêchera les connexions si le mot de passe d’un utilisateur est défini sur une valeur vide ou nulle :

PermitEmptyPasswords no

Désactivation des autres méthodes d’authentification (Optionnelle)

Dans la majorité des cas d’utilisation, SSH sera configuré avec l’authentification par clé publique comme seule méthode d’authentification en cours d’utilisation. Cependant, le serveur OpenSSH prend également en charge de nombreuses autres méthodes d’authentification, dont certaines sont activées par défaut. Si elles ne sont pas nécessaires, vous pouvez les désactiver pour réduire davantage la surface d’attaque de votre serveur SSH :

ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no

Le transfert X11 permet l’affichage d’applications graphiques distantes via une connexion SSH, mais cela est rarement utilisé en pratique. Il est recommandé de le désactiver s’il n’est pas nécessaire sur votre serveur :

X11Forwarding no

Le serveur OpenSSH permet aux clients connectés de passer des variables d’environnement personnalisées, c’est-à-dire de définir un $PATH ou de configurer les paramètres du terminal. Cependant, comme le transfert X11, ceux-ci ne sont pas couramment utilisés, ils peuvent donc être désactivés dans la plupart des cas :

PermitUserEnvironment no

Ensuite, vous pouvez désactiver plusieurs options diverses liées au tunneling et au transfert si vous ne les utiliserez pas sur votre serveur :

AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no

Enfin, vous pouvez désactiver la bannière SSH détaillée qui est activée par défaut, car elle affiche diverses informations sur votre système, telles que la version du système d’exploitation :

DebianBanner no

Enregistrement et application des changements

Enregistrez et quittez le fichier une fois que vous avez terminé. Vous pouvez maintenant valider la syntaxe de votre nouvelle configuration en exécutant sshd en mode test :

$ sudo sshd -t

Si votre fichier de configuration a une syntaxe valide, il n’y aura aucune sortie. En cas d’erreur de syntaxe, une sortie décrivant le problème sera affichée.

Une fois que vous êtes satisfait de votre fichier de configuration, vous pouvez recharger sshd pour appliquer les nouveaux paramètres :

$ sudo service sshd reload

Étape 3 : Mise en place d’une liste blanche d’adresses IP

Vous pouvez utiliser des listes blanches d’adresses IP pour limiter les utilisateurs autorisés à se connecter à votre serveur en fonction de leur adresse IP. Dans cette étape, vous allez configurer une liste blanche d’adresses IP pour votre serveur OpenSSH.

Vous pouvez identifier l’adresse IP à partir de laquelle vous vous connectez actuellement à votre serveur en utilisant la commande w :

$ w

Cela devrait afficher quelque chose de similaire à ce qui suit :

Output
14:11:48 up 2 days, 12:25, 1 user, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
your_username pts/0 203.0.113.1 12:24 1.00s 0.20s 0.00s w

Pour commencer à mettre en place votre liste blanche d’adresses IP, ouvrez le fichier de configuration du serveur OpenSSH dans votre éditeur de texte préféré :

$ sudo nvim /etc/ssh/sshd_config

Vous pouvez mettre en place des listes blanches d’adresses IP en utilisant la directive de configuration AllowUsers, qui restreint les authentifications des utilisateurs en fonction du nom d’utilisateur et/ou de l’adresse IP.

Votre propre configuration système et vos besoins détermineront quelle configuration spécifique est la plus appropriée. Les exemples suivants vous aideront à identifier celle qui convient le mieux :

Restreindre tous les utilisateurs à une adresse IP spécifique :

AllowUsers \*@203.0.113.1

Restreindre tous les utilisateurs à une plage d’adresses IP spécifique en utilisant la notation CIDR (Classless Inter-Domain Routing) :

AllowUsers \*@203.0.113.0/24

Restreindre tous les utilisateurs à une plage d’adresses IP spécifique (en utilisant des caractères génériques) :

AllowUsers _@203.0.113._

Restreindre tous les utilisateurs à plusieurs adresses IP et plages spécifiques :

AllowUsers _@203.0.113.1 _@203.0.113.2 _@192.0.2.0/24 _@172.16.*.1

Interdire tous les utilisateurs sauf les utilisateurs nommés à partir d’adresses IP spécifiques :

AllowUsers sammy@203.0.113.1 alex@203.0.113.2

Restreindre un utilisateur spécifique à une adresse IP spécifique, tout en continuant à autoriser tous les autres utilisateurs à se connecter sans restrictions :

Match User toto
AllowUsers toto@203.0.113.1

Avertissement : Dans un fichier de configuration OpenSSH, toutes les configurations sous un bloc Match ne s’appliqueront qu’aux connexions correspondant aux critères, indépendamment de l’indentation ou des sauts de ligne. Cela signifie que vous devez être prudent et vous assurer que les configurations destinées à s’appliquer globalement ne sont pas accidentellement placées dans un bloc Match. Il est recommandé de placer tous les blocs Match en bas/à la fin de votre fichier de configuration pour éviter cela.

Une fois que vous avez finalisé votre configuration, ajoutez-la en bas de votre fichier de configuration du serveur OpenSSH comme indiqué ci-dessus.

Enregistrez et fermez le fichier, puis procédez à la vérification de la syntaxe de votre configuration :

$ sudo sshd -t

Si aucune erreur n’est signalée, vous pouvez recharger le serveur OpenSSH pour appliquer votre configuration :

$ sudo service sshd reload

Étape 4 : (Optionnel/Avancé) Restriction du shell utilisateur

Dans cette étape, vous allez examiner les différentes options pour restreindre le shell d’un utilisateur SSH.

En plus de fournir un accès shell distant, SSH est également idéal pour transférer des fichiers et d’autres données, par exemple via SFTP. Cependant, vous ne souhaitez peut-être pas toujours accorder un accès shell complet aux utilisateurs lorsqu’ils n’ont besoin que de pouvoir effectuer des transferts de fichiers.

Il existe plusieurs configurations dans le serveur OpenSSH que vous pouvez utiliser pour restreindre l’environnement shell de certains utilisateurs. Par exemple, dans ce tutoriel, nous allons les utiliser pour créer des utilisateurs uniquement SFTP.

Tout d’abord, vous pouvez utiliser le shell /usr/sbin/nologin pour désactiver les connexions interactives pour certains comptes d’utilisateurs, tout en permettant aux sessions non interactives de fonctionner, comme les transferts de fichiers, le tunneling, etc.

Pour créer un nouvel utilisateur avec le shell nologin, utilisez la commande suivante :

$ sudo adduser --shell /usr/sbin/nologin alex

Alternativement, vous pouvez changer le shell d’un utilisateur existant pour nologin :

$ sudo usermod --shell /usr/sbin/nologin sammy

Si vous essayez ensuite de vous connecter de manière interactive en tant que l’un de ces utilisateurs, la demande sera rejetée :

$ sudo su alex

Cela affichera un message similaire au suivant :

Output
This account is currently not available.

Malgré le message de rejet lors des connexions interactives, d’autres actions telles que les transferts de fichiers seront toujours autorisées.

Ensuite, vous devez combiner votre utilisation du shell nologin avec quelques options de configuration supplémentaires pour restreindre davantage les comptes d’utilisateurs concernés.

Commencez par ouvrir à nouveau le fichier de configuration du serveur OpenSSH dans votre éditeur de texte préféré :

$ sudo nano /etc/ssh/sshd_config

Il y a deux options de configuration que vous pouvez implémenter ensemble pour créer un compte utilisateur strictement restreint à SFTP : ForceCommand internal-sftp et ChrootDirectory.

L’option ForceCommand dans le serveur OpenSSH force un utilisateur à exécuter une commande spécifique lors de la connexion. Cela peut être utile pour certaines communications machine à machine, ou pour lancer de force un programme particulier.

Cependant, dans ce cas, la commande internal-sftp est particulièrement utile. Il s’agit d’une fonction spéciale du serveur OpenSSH qui lance un démon SFTP de base en place qui ne nécessite aucun fichier système ou configuration de support.

Cela devrait idéalement être combiné avec l’option ChrootDirectory, qui remplacera/modifiera le répertoire racine perçu pour un utilisateur particulier, le restreignant essentiellement à un répertoire spécifique sur le système.

Ajoutez la section de configuration suivante à votre fichier de configuration du serveur OpenSSH pour cela :

Match User alex
ForceCommand internal-sftp
ChrootDirectory /home/alex/

Avertissement : Comme indiqué à l’étape 2, dans un fichier de configuration OpenSSH, toutes les configurations sous un bloc Match ne s’appliqueront qu’aux connexions correspondant aux critères, indépendamment de l’indentation ou des sauts de ligne. Cela signifie que vous devez être prudent et vous assurer que les configurations destinées à s’appliquer globalement ne sont pas accidentellement placées dans un bloc Match. Il est recommandé de placer tous les blocs Match en bas/à la fin de votre fichier de configuration pour éviter cela.

Enregistrez et fermez votre fichier de configuration, puis testez à nouveau votre configuration :

$ sudo sshd -t

S’il n’y a pas d’erreurs, vous pouvez alors appliquer votre configuration :

$ sudo service sshd reload

Cela a créé une configuration robuste pour l’utilisateur alex, où les connexions interactives sont désactivées et toute activité SFTP est restreinte au répertoire personnel de l’utilisateur. Du point de vue de l’utilisateur, la racine du système, c’est-à-dire /, est leur répertoire personnel, et ils ne pourront pas parcourir le système de fichiers pour accéder à d’autres zones.

Conclusion

Dans cet article, vous avez examiné la configuration de votre serveur OpenSSH et mis en œuvre diverses mesures de renforcement pour aider à sécuriser votre serveur.

Cela aura réduit la surface d’attaque globale de votre serveur en désactivant les fonctionnalités inutilisées et en verrouillant l’accès de certains utilisateurs.

Vous pouvez consulter les pages de manuel du serveur OpenSSH et son fichier de configuration associé pour identifier d’éventuelles autres modifications que vous souhaitez apporter.