Sécurisez la connexion SSH de votre système Linux pour protéger votre système et vos données. Les administrateurs système et les particuliers doivent renforcer et sécuriser les ordinateurs connectés à Internet, mais SSH peut être compliqué. Voici dix solutions rapides pour vous aider à protéger votre serveur SSH.
Principes de base de la sécurité SSH
SSH signifie Enveloppe de protection . Le nom «SSH» est utilisé de manière interchangeable pour désigner soit le protocole SSH lui-même, soit les outils logiciels qui permettent aux administrateurs système et aux utilisateurs d'établir des connexions sécurisées avec des ordinateurs distants à l'aide de ce protocole.
Le protocole SSH est un protocole crypté conçu pour fournir une connexion sécurisée sur un réseau non sécurisé, tel qu'Internet. SSH sous Linux repose sur une version portable du OpenSSH projet. Il est implémenté dans un modèle client-serveur classique , avec un serveur SSH acceptant les connexions des clients SSH. Le client sert à se connecter au serveur et à afficher la session à l'utilisateur distant. Le serveur accepte la connexion et exécute la session.
Dans sa configuration par défaut, un serveur SSH écoutera les connexions entrantes sur Transmission Control Protocol ( TCP ) port 22. Comme il s'agit d'un port bien connu , c'est une cible pour acteurs de la menace et bots malveillants .
Les acteurs de la menace lancent des bots qui analysent une plage d'adresses IP à la recherche de ports ouverts. Les ports sont ensuite sondés pour voir s'il existe des vulnérabilités qui peuvent être exploitées. Penser: «Je suis en sécurité, il y a des cibles plus grandes et meilleures que moi pour les méchants», est un faux raisonnement. Les robots ne sélectionnent pas les cibles en fonction de leur mérite; ils recherchent méthodiquement les systèmes qu'ils peuvent violer.
Vous vous nommez comme victime si vous n’avez pas sécurisé votre système.
Friction de sécurité
Les frictions en matière de sécurité sont l'irritation - à quelque degré que ce soit - que les utilisateurs et les autres subiront lorsque vous implémenterez des mesures de sécurité. Nous avons de longs souvenirs et nous nous souvenons d'avoir présenté un système informatique à de nouveaux utilisateurs et de les entendre demander d'une voix horrifiée s'ils vraiment a dû entrer un mot de passe à chaque fois ils se sont connectés au mainframe. C'était - pour eux - une friction sécuritaire.
(Incidemment, l'invention du mot de passe est créditée à Fernando J. Corbató , autre figure du panthéon des informaticiens dont les travaux combinés ont contribué aux circonstances qui ont conduit à la naissance de Unix .)
L'introduction de mesures de sécurité implique généralement une forme de friction pour quelqu'un. Les propriétaires d'entreprise doivent payer pour cela. Les utilisateurs d'ordinateurs devront peut-être modifier leurs pratiques habituelles, se souvenir d'un autre ensemble de détails d'authentification ou ajouter des étapes supplémentaires pour se connecter avec succès. Les administrateurs système auront du travail supplémentaire à faire pour mettre en œuvre et maintenir les nouvelles mesures de sécurité.
Le renforcement et le verrouillage d'un système d'exploitation de type Linux ou Unix peuvent être très impliqués, très rapidement. Ce que nous présentons ici est un ensemble d’étapes faciles à mettre en œuvre qui amélioreront la sécurité de votre ordinateur sans avoir besoin d’applications tierces et sans passer par votre pare-feu.
Ces étapes ne sont pas le dernier mot en matière de sécurité SSH, mais elles vous permettront d'avancer loin des paramètres par défaut, et sans trop de frictions.
Utiliser le protocole SSH version 2
En 2006, le protocole SSH a été mis à jour de la version 1 à version 2 . C'était une mise à niveau significative. Il y a eu tellement de changements et d'améliorations, en particulier autour du chiffrement et de la sécurité, que la version 2 n'est pas rétrocompatible avec la version 1. Pour empêcher les connexions des clients de la version 1, vous pouvez stipuler que votre ordinateur n'acceptera que les connexions des clients de la version 2.
Pour ce faire, modifiez le
/ etc / ssh / sshd_config
fichier. Nous ferons souvent cela tout au long de cet article. Chaque fois que vous avez besoin de modifier ce fichier, voici la commande à utiliser:
sudo gedit / etc / ssh / sshd_config
Ajoutez la ligne:
Protocole 2
Et enregistrez le fichier. Nous allons redémarrer le processus du démon SSH. Encore une fois, nous le ferons beaucoup tout au long de cet article. Voici la commande à utiliser dans chaque cas:
sudo systemctl redémarrer sshd
Vérifions que notre nouveau paramètre est en vigueur. Nous allons passer à une autre machine et essayer de SSH sur notre machine de test. Et nous utiliserons le
-1
(protocole 1) pour forcer la
ssh
commande pour utiliser la version 1 du protocole.
ssh -1 [email protected]
Super, notre demande de connexion est rejetée. Assurons-nous que nous pouvons toujours nous connecter avec le protocole 2. Nous utiliserons le
-2
(protocole 2) option pour prouver le fait.
ssh -2 [email protected]
Le fait que le serveur SSH demande notre mot de passe est une indication positive que la connexion a été établie et que vous interagissez avec le serveur. En fait, comme les clients SSH modernes utiliseront par défaut le protocole 2, nous n'avons pas besoin de spécifier le protocole 2 tant que notre client est à jour.
ssh [email protected]
Et notre connexion est acceptée. Ainsi, seules les connexions de protocole 1 les plus faibles et les moins sécurisées sont rejetées.
Avoid Port 22
Le port 22 est le port standard pour les connexions SSH. Si vous utilisez un port différent, cela ajoute un peu de sécurité par l'obscurité à votre système. La sécurité par l'obscurité n'est jamais considérée comme une véritable mesure de sécurité, et je l'ai dénoncée dans d'autres articles. En fait, certains des robots d'attaque les plus intelligents sondent tous les ports ouverts et déterminent le service qu'ils offrent, plutôt que de se fier à une simple liste de recherche de ports et de supposer qu'ils fournissent les services habituels. Mais l'utilisation d'un port non standard peut aider à réduire le bruit et le mauvais trafic sur le port 22.
Pour configurer un port non standard, modifiez votre fichier de configuration SSH:
sudo gedit / etc / ssh / sshd_config
Supprimez le hash # au début de la ligne «Port» et remplacez le «22» par le numéro de port de votre choix. Enregistrez votre fichier de configuration et redémarrez le démon SSH:
sudo systemctl redémarrer sshd
Voyons quel effet cela a eu. Sur notre autre ordinateur, nous utiliserons le
ssh
commande pour se connecter à notre serveur. le
ssh
La commande utilise par défaut le port 22:
ssh [email protected]
Notre connexion est refusée. Essayons à nouveau et spécifiez le port 470, en utilisant l’option -p (port):
ssh -p 479 [email protected]
Notre connexion est acceptée.
Filtrer les connexions à l'aide de wrappers TCP
TCP Wrappers est un logiciel facile à comprendre liste de contrôle d'accès . Il vous permet d'exclure et d'autoriser les connexions en fonction des caractéristiques de la demande de connexion, telles que l'adresse IP ou le nom d'hôte. Les wrappers TCP doivent être utilisés avec, et non à la place, un pare-feu correctement configuré. Dans notre scénario spécifique, nous pouvons considérablement resserrer les choses en utilisant des wrappers TCP.
Les wrappers TCP étaient déjà installés sur la machine Ubuntu 18.04 LTS utilisée pour rechercher cet article. Il devait être installé sur Manjaro 18.10 et Fedora 30.
Pour installer sur Fedora, utilisez cette commande:
sudo yum installer tcp_wrappers
Pour installer sur Manjaro, utilisez cette commande:
sudo pacman -Syu tcp-wrappers
Il y a deux fichiers impliqués. L'un contient la liste autorisée et l'autre la liste refusée. Modifiez la liste de refus en utilisant:
sudo gedit /etc/hosts.deny
Cela ouvrira le
gedit
éditeur avec le fichier de refus chargé dedans.
Vous devez ajouter la ligne:
TOUS: TOUS
Et enregistrez le fichier. Cela bloque tous les accès qui n’ont pas été autorisés. Nous devons maintenant autoriser les connexions que vous souhaitez accepter. Pour ce faire, vous devez modifier le fichier d'autorisation:
sudo gedit /etc/hosts.allow
Cela ouvrira le
gedit
éditeur avec le fichier allow chargé dedans.
Nous avons ajouté le nom du démon SSH,
SSHD
, Et l'adresse IP de l'ordinateur que nous allons autoriser à établir une connexion. Enregistrez le fichier et voyons si les restrictions et les autorisations sont en vigueur.
Tout d'abord, nous allons essayer de nous connecter à partir d'un ordinateur qui n'est pas dans le
hosts.allow
fichier:
La connexion est refusée. Nous allons maintenant essayer de nous connecter depuis la machine à l'adresse IP 192.168.4.23:
Notre connexion est acceptée.
Notre exemple ici est un peu brutal - un seul ordinateur peut se connecter. Les wrappers TCP sont assez polyvalents et plus flexibles que cela. Elle supporte noms d'hôte, caractères génériques et masques de sous-réseau pour accepter les connexions à partir de plages d'adresses IP. Vous êtes encouragé à consultez la page de manuel .
Rejeter les demandes de connexion sans mot de passe
Bien que ce soit une mauvaise pratique, un administrateur système Linux peut créer un compte utilisateur sans mot de passe. Cela signifie que les demandes de connexion à distance de ce compte n'auront aucun mot de passe à vérifier. Ces connexions seront acceptées mais non authentifiées.
Les paramètres par défaut de SSH acceptent les demandes de connexion sans mot de passe. Nous pouvons changer cela très facilement et nous assurer que toutes les connexions sont authentifiées.
Nous devons éditer votre fichier de configuration SSH:
sudo gedit / etc / ssh / sshd_config
Faites défiler le fichier jusqu'à ce que vous voyiez la ligne qui indique «#PermitEmptyPasswords no.» Supprimer le hachage
#
depuis le début de la ligne et enregistrez le fichier. Redémarrez le démon SSH:
sudo systemctl redémarrer sshd
Utilisez des clés SSH au lieu de mots de passe
Les clés SSH fournissent un moyen sécurisé de se connecter à un serveur SSH. Les mots de passe peuvent être devinés, piratés ou brute-forced . Les clés SSH ne sont pas ouvertes à de tels types d'attaques.
Lorsque vous générez des clés SSH, vous créez une paire de clés. L'une est la clé publique et l'autre est la clé privée. La clé publique est installée sur les serveurs auxquels vous souhaitez vous connecter. La clé privée, comme son nom l'indique, est conservée en sécurité sur votre propre ordinateur.
Les clés SSH vous permettent d'établir des connexions sans mot de passe qui sont, de manière contre-intuitive, plus sécurisées que les connexions utilisant l'authentification par mot de passe.
Lorsque vous effectuez une demande de connexion, l'ordinateur distant utilise sa copie de votre clé publique pour créer un message chiffré qui est renvoyé à votre ordinateur. Comme il a été chiffré avec votre clé publique, votre ordinateur peut le déchiffrer avec votre clé privée.
Votre ordinateur extrait ensuite certaines informations du message, notamment l'ID de session, les crypte et les renvoie au serveur. Si le serveur peut le déchiffrer avec sa copie de votre clé publique, et si les informations contenues dans le message correspondent à ce que le serveur vous a envoyé, il est confirmé que votre connexion provient de vous.
Ici, une connexion est établie avec le serveur en 192.168.4.11, par un utilisateur avec des clés SSH. Notez qu'ils ne sont pas invités à entrer un mot de passe.
ssh [email protected]
Les clés SSH méritent un article à elles seules. Nous en avons un pour vous. Voici comment créer et installer des clés SSH .
EN RELATION: Comment créer et installer des clés SSH à partir du shell Linux
Désactiver complètement l'authentification par mot de passe
Bien sûr, l'extension logique de l'utilisation des clés SSH est que si tous les utilisateurs distants sont obligés de les adopter, vous pouvez désactiver complètement l'authentification par mot de passe.
Nous devons éditer votre fichier de configuration SSH:
sudo gedit / etc / ssh / sshd_config
Faites défiler le fichier jusqu'à ce que vous voyiez la ligne commençant par «#PasswordAuthentication yes». Supprimer le hachage
#
depuis le début de la ligne, changez le «oui» en «non» et enregistrez le fichier. Redémarrez le démon SSH:
sudo systemctl redémarrer sshd
Désactiver le transfert X11
Le transfert X11 permet aux utilisateurs distants d'exécuter des applications graphiques à partir de votre serveur via une session SSH. Entre les mains d'un acteur menaçant ou d'un utilisateur malveillant, une interface graphique peut faciliter leurs objectifs malveillants.
Un mantra standard en matière de cybersécurité est que si vous n'avez pas de raison valable de l'activer, désactivez-le. Nous le ferons en modifiant votre fichier de configuration SSH:
sudo gedit / etc / ssh / sshd_config
Faites défiler le fichier jusqu'à ce que vous voyiez la ligne commençant par «# X11Forwarding no.» Supprimer le hachage
#
depuis le début de la ligne et enregistrez le fichier. Redémarrez le démon SSH:
sudo systemctl redémarrer sshd
Définir une valeur de délai d'inactivité
S'il existe une connexion SSH établie avec votre ordinateur et qu'aucune activité n'a été effectuée dessus pendant un certain temps, cela peut poser un risque pour la sécurité. Il est possible que l'utilisateur ait quitté son bureau et soit occupé ailleurs. Toute autre personne qui passe devant son bureau peut s'asseoir et commencer à utiliser son ordinateur et, via SSH, votre ordinateur.
Il est beaucoup plus sûr d’établir un délai d’attente. La connexion SSH sera abandonnée si la période d'inactivité correspond à la limite de temps. Une fois de plus, nous modifierons votre fichier de configuration SSH:
sudo gedit / etc / ssh / sshd_config
Faites défiler le fichier jusqu'à ce que vous voyiez la ligne commençant par «#ClientAliveInterval 0» Supprimez le hachage
#
à partir du début de la ligne, changez le chiffre 0 en la valeur souhaitée. Nous avons utilisé 300 secondes, soit 5 minutes. Enregistrez le fichier et redémarrez le démon SSH:
sudo systemctl redémarrer sshd
Définir une limite pour les tentatives de mot de passe
La définition d'une limite sur le nombre de tentatives d'authentification peut aider à contrecarrer les devinettes de mots de passe et les attaques par force brute. Après le nombre désigné de demandes d'authentification, l'utilisateur sera déconnecté du serveur SSH. Par défaut, il n'y a pas de limite. Mais cela est rapidement corrigé.
Encore une fois, nous devons modifier votre fichier de configuration SSH:
sudo gedit / etc / ssh / sshd_config
Faites défiler le fichier jusqu'à ce que vous voyiez la ligne commençant par «#MaxAuthTries 0». Supprimer le hachage
#
à partir du début de la ligne, changez le chiffre 0 en la valeur souhaitée. Nous en avons utilisé 3 ici. Enregistrez le fichier lorsque vous avez effectué vos modifications et redémarrez le démon SSH:
sudo systemctl redémarrer sshd
Nous pouvons tester cela en essayant de nous connecter et en entrant délibérément un mot de passe incorrect.
Notez que le nombre MaxAuthTries semblait être un de plus que le nombre d'essais autorisés par l'utilisateur. Après deux mauvaises tentatives, notre utilisateur de test est déconnecté. C'était avec MaxAuthTries réglé sur trois.
Désactiver les connexions racine
Il est déconseillé de se connecter en tant que root sur votre ordinateur Linux. Vous devez vous connecter en tant qu'utilisateur normal et utiliser
sudo
pour effectuer des actions qui nécessitent des privilèges root. Plus encore, vous ne devriez pas autoriser root à se connecter à votre serveur SSH. Seuls les utilisateurs réguliers devraient être autorisés à se connecter. S'ils doivent effectuer une tâche administrative, ils doivent utiliser
sudo
aussi. Si vous êtes obligé d'autoriser un utilisateur root à se connecter, vous pouvez au moins le forcer à utiliser des clés SSH.
Pour la dernière fois, nous allons devoir modifier votre fichier de configuration SSH:
sudo gedit / etc / ssh / sshd_config
Faites défiler le fichier jusqu'à ce que vous voyiez la ligne commençant par «#PermitRootLogin prohibit-password» Supprimer le hachage
#
dès le début de la ligne.
- Si vous voulez empêcher le root de se connecter, remplacez «interdire-mot de passe» par «non».
- Si vous autorisez root à se connecter mais que vous le forcez à utiliser des clés SSH, laissez «interdire-mot de passe» en place.
Enregistrez vos modifications et redémarrez le démon SSH:
sudo systemctl redémarrer sshd
L'étape ultime
Bien sûr, si vous n'avez pas du tout besoin de SSH sur votre ordinateur, assurez-vous qu'il est désactivé.
sudo systemctl stop sshd
sudo systemctl désactiver sshd
Si vous n’ouvrez pas la fenêtre, personne ne peut y entrer.
