Comment durcir OpenSSH sur Ubuntu 18.04

L’auteur a choisi que le Electronic Frontier Foundation Inc recevrait une donation dans le cadre du programme Write for Donations.

Introduction

Les serveurs Linux sont souvent administrés à distance en utilisant SSH en se connectant à un serveur OpenSSH, qui est le logiciel serveur SSH par défaut utilisé dans Ubuntu, Debian, CentOS, FreeBSD et la plupart des autres systèmes basés sur Linux/BSD.

Le serveur OpenSSH est le côté serveur de SSH, également connu sous le nom de démon SSH ou sshd. Vous pouvez vous connecter à un serveur OpenSSH en utilisant le client OpenSSH — la commande ssh. Vous pouvez en apprendre plus sur le modèle client-serveur SSH dans Les Essentiels de SSH : Travailler avec les serveurs SSH, les clients et les clés. Il est important de sécuriser correctement votre serveur OpenSSH, car il agit comme la porte d’entrée ou l’entrée de votre serveur.

Dans ce tutoriel, vous allez durcir votre serveur OpenSSH en utilisant différentes options de configuration pour vous assurer que l’accès à distance à votre serveur est aussi sécurisé que possible.

Conditions préalables

Pour suivre ce tutoriel, vous aurez besoin de :

• Un serveur Ubuntu 18.04 configuré en suivant la Configuration initiale du serveur avec Ubuntu 18.04, y compris un utilisateur sudo non root.

Une fois que tout est prêt, connectez-vous à votre serveur en tant que non-root user pour commencer.

Étape 1 — Durcissement général

Dans cette première étape, vous allez implémenter quelques configurations de durcissement initiales pour améliorer la sécurité globale de votre serveur SSH.

La configuration de durcissement exacte qui est la plus appropriée à votre propre serveur dépend fortement de votre propre modèle de menace et de votre seuil de risque. Cependant, la configuration que vous utiliserez dans cette étape est une configuration sécurisée générale qui conviendra à la majorité des serveurs.

La plupart des configurations de durcissement pour OpenSSH que vous implémentez utilisent le fichier de configuration standard du serveur OpenSSH, qui est situé dans /etc/ssh/sshd_config. Avant de poursuivre ce tutoriel, il est recommandé de faire une sauvegarde de votre fichier de configuration existant, afin de pouvoir le restaurer dans le cas improbable où quelque chose se passerait mal.

Faites une sauvegarde du fichier en utilisant la commande suivante :

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Cela enregistrera une copie de sauvegarde du fichier situées à /etc/ssh/sshd_config.bak.

Avant de modifier votre fichier de configuration, vous pouvez examiner les options qui sont actuellement configurées. Pour ce faire, lancez la commande suivante :

sudo sshd -T

Cela exécutera le serveur OpenSSH en mode test étendu, qui validera l’intégralité du fichier de configuration et imprimera les valeurs de configuration effectives.

Vous pouvez maintenant ouvrir le fichier de configuration en utilisant votre éditeur de texte préféré pour commencer à implémenter les mesures de durcissement initial :

sudo nano /etc/ssh/sshd_config

Lorsque vous éditez votre fichier de configuration, certaines options peuvent être commentées par défaut en utilisant un simcaractère dièse (#) au début de la ligne. Pour modifier ces options, ou pour que l’option commentée soit reconnue, vous devrez les décommenter, en supprimant le dièse.

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

PermitRootLogin no

Ceci est très avantageux, car cela empêchera un attaquant potentiel de se connecter directement en tant que root. Cela encourage également de bonnes pratiques de sécurité opérationnelles, telles que le fait de travailler en tant qu’utilisateur non privilégié et d’utiliser sudo pour augmenter les privilèges seulement lorsque cela est absolument nécessaire.

Ensuite, vous pouvez limiter le nombre maximum de tentatives d’authentification pour une session de connexion particulière en configurant ce qui suit :

MaxAuthTries 3

Une valeur standard de 3 est acceptable pour la plupart des configurations, mais vous pouvez souhaiter la fixer à un niveau supérieur ou inférieur en fonction de votre propre seuil de risque.

Si nécessaire, vous pouvez également définir un délai de grâce de connexion réduit, qui correspond au temps dont dispose un utilisateur pour terminer l’authentification après sa première connexion à votre serveur SSH :

LoginGraceTime 20

Le fichier de configuration spécifie cette valeur en secondes.

Le fait de définir une valeur inférieure permet d’éviter certaines attaques par déni de service lorsque plusieurs sessions d’authentification sont maintenues ouvertes pendant une période prolongée.

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 mots de passe SSH pour empêcher que les mots de passe divulgués des utilisateurs puissent permettre à un attaquant de se connecter :

PasswordAuthentication no

Comme mesure de durcissement supplémentaire liée aux mots de passe, vous pouvez également souhaiter 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 à une valeur vierge ou vide :

PermitEmptyPasswords no

Dans la majorité des cas d’utilisation, SSH sera configuré avec une clé d’authentification 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 ce elles ne sont pas nécessaire, vous pouvez les désactiver pour réduire encore la surface d’attaque de votre serveur SSH :

ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no

Si vous souhaitez en savoir plus sur certaines des méthodes d’authentification supplémentaires disponibles dans SSH, vous pouvez consulter ces ressources :

• Authentification défi-réponse
• Authentification Kerberos
• Authentification GSSAPI

X11 forwarding permet l’affichage d’applications graphiques à distance via une connexion SSH, mais cela est rarement utilisé dans la pratique.  Il est recommandé de la 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 des paramètres de terminal. Cependant, tout comme X11 forwarding, ces fonctions ne sont pas couramment utilisées, et peuvent donc être désactivées dans la plupart des cas :

PermitUserEnvironment no

Si vous décidez de configurer cette option, vous devriez également vous assurer de commenter toute référence à AcceptEnv en ajoutant un dièse(#) au début de la ligne.

Ensuite, vous pouvez désactiver plusieurs options diverses liées au tunneling, et à la redirection si vous ne les utilisez pas sur votre serveur :

AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no

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

DebianBanner no

Notez que cette option ne sera probablement pas déjà présente dans le fichier de configuration, vous devrez donc probablement l’ajouter manuellement. Enregistrez et quittez le fichier une fois que vous avez terminé.

Validez maintenant la syntaxe de votre nouvelle configuration en exécutant sshd en mode test :

sudo sshd -t

Si la syntaxe de votre fichier de configuration est valide, il n’y aura aucune sortie. En cas d’erreur de syntaxe, vous recevrez une sortie décrivant le problème.

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

Dans cette étape, vous avez terminé un durcissement général de votre fichier de configuration du serveur OpenSSH. Ensuite, vous allez implémenter une liste d’adresse IP pour restreindre davantage ceux qui peuvent se connecter à votre serveur.

Étape 2 — Mise en place d’une liste d’adresses IP autorisées

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

Dans de nombreux cas, vous ne vous connecterez à votre serveur qu’à partir d’un petit nombre d’adresses IP connues et de confiance. Par exemple, votre connexion à Internet à domicile, un appareil VPN d’entreprise, ou une boîte de saut statique ou un hôte bastion dans un centre de données.

En implémentant une liste d’adresse IP autorisées, vous pouvez vous assurer que les personnes ne pourront se connecter qu’à partir de l’une des adresses IP pré-approuvées, ce qui réduit considérablement le risque d’une violation en cas de fuite de vos clés privées ou de vos mots de passe.

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

w

Il en résultera 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

Localisez votre compte utilisateur dans la liste et prenez note de l’adresse IP connectée. Ici, nous utilisons l’IP 203.0.113.1 à titre d’exemple

Pour commencer à implémenter votre liste d’adresse IP autorisées, ouvrez le fichier de configuration du serveur OpenSSH dans votre éditeur de texte préféré :

sudo nano /etc/ssh/sshd_config

Vous pouvez implémenter des listes d’adresse IP autorisées en utilisant la directive de configuration AllowUsers qui restreint les authentifications des utilisateurs en fonction du nom d’utilisateur ou de l’adresse IP.

La configuration et les exigences de votre système détermineront la configuration spécifique la plus appropriée. Les exemples suivants vous aideront à identifier la plus appropriée :

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

AllowUsers *@203.0.113.1

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

AllowUsers *@203.0.113.0/24

• Restreindre tous les utilisateurs à une plage d’adresse IP spécifique (en utilisant des jokers) :

AllowUsers *@203.0.113.*

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

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

• Interdire tous les utilisateurs à l’exception des 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 à permettre à tous les autres utilisateurs de se connecter sans restriction :

Match User ashley
  AllowUsers ashley@203.0.113.1

Une fois que vous avez terminé votre configuration, ajoutez-la au bas de votre fichier de configuration OpenSSH :

AllowUsers *@203.0.113.1

Enregistrez et fermez le fichier, puis testez 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

Dans cette étape, vous avez implémenté une liste d’adresse IP autorisées sur votre serveur OpenSSH. Ensuite, vous allez restreindre le shell d’un utilisateur à limiter les commandes qu’il est autorisé à utiliser.

Étape 3 — Restreindre le Shell d’un utilisateur

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

En plus de fournir un accès distant au shell, SSH est également très utile pour le transfert de fichiers et d’autres données, par exemple, via SFTP. Cependant, vous ne voudrez peut-être pas toujours accorder un accès en shell complet aux utilisateurs lorsqu’ils doivent seulement pouvoir effectuer des transferts de fichier.

Il existe plusieurs configurations au sein du serveur OpenSSH que vous pouvez utiliser pour restreindre l’environnement shell d’utilisateurs particuliers. Par exemple, dans ce tutoriel, nous les utiliserons pour créer des utilisateurs uniquement SFTP.

Tout d’abord, vous pouvez utiliser le shell /usr/sbin/nologin pour désactiver les connexions interactives de certains comptes 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

Vous pouvez également modifier le shell d’un utilisateur existant pour qu’il devienne nologin :

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

Si vous tentez ensuite de vous connecter de manière interactive en tant qu’un de ces utilisateurs, la requête sera rejetée :

sudo su alex

Il en résultera quelque chose de similaire à ce message :

Output
This account is currently not available.

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

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

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

sudo nano /etc/ssh/sshd_config

Il existe deux options de configuration que vous pouvez implémenter ensemble pour créer un compte utilisateur uniquement SFTP très restreint : ForceCommand internal-sftp et ChrootDirectory.

L’option ForceCommand dans le serveur OpenSSH force un utilisateur à exécuter une commande spécifique lors de sa connexion. Ceci peut être utile pour certaines communications de 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 de base en place qui ne nécessite aucun fichier ou configuration système.

Idéalement, cette fonction devrait être combinée avec l’option ChrootDirectory qui va remplacer/changer le répertoire racine perçu d’un utilisateur particulier, en le limitant essentiellement à un répertoire spécifique du système.

Ajoutez la section de configuration suivante à votre fichier de configuration OpenSSH pour ce faire :

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

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

Ceci a créé une configuration robuste pour l’utilisateur alex, où les connexions interactives sont désactivées, et toute l’activité SFTP est limitée au répertoire d’accueil de l’utilisateur. Du point de vue de l’utilisateur, la racine du système, c’est-à-dire /, est son répertoire d’accueil, et il ne pourra pas remonter le système de fichiers pour accéder à d’autres zones.

Vous avez implémenté le shell nologin pour un utilisateur et vous avez ensuite créé une configuration pour restreindre l’accès SFTP à un répertoire spécifique.

Étape 4 — Durcissement avancé

Dans cette dernière étape, vous allez implémenter diverses mesures de durcissement supplémentaires pour rendre l’accès à votre serveur SSH aussi sécurisé que possible.

Une fonction moins connue du serveur OpenSSH est la capacité d’imposer des restrictions sur une base par clé, c’est-à-dire des restrictions qui ne s’appliquent qu’aux clés publiques spécifiques présentes dans le fichier .ssh/authorized_keys. Ceci est particulièrement utile pour contrôler l’accès aux sessions de machine à machine, et pour permettre aux utilisateurs non sudo de contrôler les restrictions de leur propre compte utilisateur.

Vous pouvez également appliquer la plupart de ces restrictions au niveau du système ou de l’utilisateur, mais il est toujours plus avantageux de les implémenter au niveau clé également afin de fournir une défense en profondeur et une sécurité supplémentaire en cas d’erreurs de configuration accidentelles à l’échelle du système.

Commencez par ouvrir votre fichier .ssh/authorized_keys dans votre éditeur de texte préféré :

nano ~/.ssh/authorized_keys

Une fois que vous aurez ouvert votre fichier authorized_keys, vous verrez que chaque ligne contient une clé publique SSH, qui commencera très probablement par quelque chose comme ssh-rsa AAAB... Des options de configuration supplémentaires peuvent être ajoutées au début de la ligne, et elles ne s’appliqueront qu’aux authentifications réussies avec cette clé publique spécifique.

Les options de restriction suivantes sont disponibles :

• no-agent-forwarding : désactiver le transfert de l’agent SSH.
• no-port-forwarding : désactiver le transfert de port SSH.
• no-pty : désactiver la capacité d’allouer un tty (c’est-à-dire lancer un shell).
• no-user-rc : Empêcher l’exécution du fichier ~/.ssh/rc.
• no-X11-forwarding : désactiver le déport d’affichage X11.

Vous pouvez les appliquer pour désactiver des fonctionnalités SSH spécifiques pour des clés spécifiques. Par exemple, pour désactiver le déport d’agent et le déport X11 pour une clé, vous utiliserez la configuration suivante :

no-agent-forwarding,no-X11-forwarding ssh-rsa AAAB...

Par défaut, ces configurations fonctionnent en utilisant une méthode "autoriser par défaut, bloquer par exception " ; cependant, il est également possible d’utiliser "bloquer par défaut, autoriser par exception ", qui est généralement préférable pour assurer la sécurité.

Vous pouvez le faire en utilisant l’option restrict qui reniera implicitement toutes les fonctionnalités SSH pour la clé spécifique, en exigeant qu’elles soient explicitement réactivées seulement lorsque cela est absolument nécessaire. Vous pouvez réactiver des fonctionnalités en utilisant les mêmes options de configuration décrites plus haut dans ce tutoriel, mais sans le préfixe no-.

Par exemple, pour désactiver toutes les fonctionnalités SSH d’une clé particulière, à l’exception du déport d’affichage X11, vous pouvez utiliser la configuration suivante :

restrict,X11-forwarding ssh-rsa AAAB...

Vous pouvez également envisager d’utiliser l’option command, qui est très similaire à l’option ForceCommand décrite à l’Étape 3. Cela n’apporte pas d’avantage direct si vous utilisez déjà ForceCommand, mais la mettre en place constitue une bonne défense en profondeur dans le cas (peu probable) où votre fichier de configuration principal du serveur OpenSSH serait écrasé, modifié, etc.

Par exemple, pour forcer les utilisateurs qui s’authentifient avec une clé spécifique à exécuter une commande spécifique lors de leur connexion, vous pouvez ajouter la configuration suivante :

command="top" ssh-rsa AAAB...

Enfin, pour utiliser au mieux les restrictions par clé pour l’utilisateur uniquement SFTP que vous avez créé à l’Étape 3, vous pouvez utiliser la configuration suivante :

restrict,command="false" ssh-rsa AAAB...

L’option restrict désactivera tout accès interactif, et l’option command="false" agit comme une deuxième ligne de défense au cas où l’option ForceCommand ou le shell nologin devaient échouer.

Enregistrez et fermez le fichier pour appliquer la configuration. Cela prendra effet immédiatement pour tous les nouveaux logins, vous n’avez donc pas besoin de recharger OpenSSH manuellement.

Dans cette étape, vous avez implémenté des mesures de durcissement avancées supplémentaires pour le serveur OpenSSH en utilisant les options personnalisées dans votre (vos) fichier(s) .ssh/authorized_keys.

Conclusion

Dans cet article, vous avez passé en revue la configuration de votre serveur OpenSSH et implémenté diverses mesures de durcissement pour aider à sécuriser votre serveur.

Cela aura permis de réduire la surface d’attaque globale de votre serveur en désactivant les fonctionnalités inutilisées et en bloquant l’accès à des utilisateurs spécifiques.

Vous pouvez consulter les pages du manuel pour le serveur OpenSSH et son fichier de configuration associé, pour identifier tout autre ajustement potentiel que vous souhaiteriez apporter.