SSH, ou Secure SHell, a remplacé Telnet quelque part dans les années 1990 en tant que protocole d'accès à distance de choix, et pour une bonne raison. SSH permet aux administrateurs (ou utilisateurs) d'accéder à un shell distant via un tunnel sécurisé, en connectant leur client SSH à un serveur SSH. SSH peut également gérer les transferts de fichiers, qui devraient remplacer FTP, bien qu'il existe un nombre surprenant de situations qui reposent toujours sur le bon vieux FTP en texte clair.
Pourquoi? Ugh.
Pour les raisons ci-dessus, les systèmes Linux modernes sont gérés via SSH. La plupart des administrateurs système expérimentés apprécient l'accès direct et la puissance qu'ils obtiennent en se connectant en toute sécurité au shell de leur système avec une relative facilité. Dans cet article, je parlerai spécifiquement du démon du serveur OpenSSH, sshd . Nous aborderons certains des problèmes de sécurité que vous pouvez rencontrer et comment les atténuer ou les résoudre carrément.
Pourquoi nous avons besoin de SSH
Comme je l'ai mentionné, SSH est un outil puissant. Grâce à une session SSH, vous pouvez connecter un terminal virtuel directement à votre système cible. Entre de mauvaises mains, cette capacité peut être problématique, alors pourquoi laissons-nous un tel pouvoir accessible ? Eh bien, la puissance de SSH implique un équilibre délicat. En quelques minutes, un administrateur peut ouvrir une session sécurisée sur son serveur pour répondre à un incident. La simplicité est élégante.
SSH est également au cœur des outils d'automatisation comme Ansible. Ansible peut appliquer des modifications à un système via SSH sans avoir besoin d'un agent. Toutes les modifications sont effectuées à la place en utilisant SSH et Python.
SSH peut également être utilisé, comme je l'ai mentionné, pour les transferts de fichiers sécurisés. Par exemple, rsync tunnels via SSH pour une synchronisation sécurisée des données. SSH peut également être utilisé pour passer d'un système à un autre, ce qui est idéal pour le dépannage, mais également pour un attaquant.
Si les paragraphes précédents ne vous ont pas convaincu, je le répète :SSH est un outil puissant, et comme tout outil puissant, il peut être abusé. Si un attaquant peut obtenir un shell sécurisé dans votre système, la partie est terminée. Et les attaquants le savent, ils recherchent donc constamment des systèmes avec SSH ouverts sur le monde pour pouvoir attaquer.
Verrouiller SSH
L'attaque la plus courante contre SSH est la force brute. Sur mes systèmes, je n'ai personnellement jamais eu d'attaque par force brute contre SSH. Cependant, avant de commencer à suivre des règles de verrouillage simples, je peux vous dire qu'ils ont certainement essayé.
Une recherche rapide sur Shodan, un moteur de recherche qui cible les appareils connectés à Internet, montre 20 984 090 systèmes avec SSH ouverts sur le monde. Doivent-ils être configurés de cette manière ? Je peux presque vous garantir que chacun de ces systèmes reçoit plusieurs attaques par force brute SSH par seconde. Pendant que j'écrivais cet article, j'ai lancé une gouttelette sur Digital Ocean, laissé SSH ouvert au monde et suivi /var/log/secure . En 20 minutes environ, j'ai vu la première sonde SSH. En moins d'une heure, le flot d'attaques par force brute a commencé.
Jun 23 01:35:33 centos-s-1vcpu-1gb-sgp1-01 sshd[10926]: Did not
receive identification string from 81.22.45.137 port 61000
Jun 23 01:37:47 centos-s-1vcpu-1gb-sgp1-01 sshd[10928]: Invalid
user fake from 104.248.132.25 port 36050
Jun 23 01:37:47 centos-s-1vcpu-1gb-sgp1-01 sshd[10928]:
input_userauth_request: invalid user fake [preauth]
Jun 23 01:37:47 centos-s-1vcpu-1gb-sgp1-01 sshd[10928]: Received
disconnect from 104.248.132.25 port 36050:11: Bye Bye [preauth]
Bref, un mauvais mot de passe sur un sshd par défaut l'installation pourrait être tout ce qui se dresse entre les méchants et votre système. Bien que la configuration par défaut d'OpenSSH soit décemment sécurisée, elle peut être renforcée. Heureusement pour vous, j'ai des suggestions.
Restreindre l'accès au port 22
Commencez par vérifier si le port SSH par défaut (port 22) est ouvert au monde. Vous pouvez le faire en exécutant Nmap, qui sondera votre réseau selon vos spécifications :
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-22 20:56 EDT
Nmap scan report for 167.71.200.117
Host is up (0.26s latency).
Not shown: 995 closed ports
PORT STATE SERVICE
22/tcp open ssh Limiter qui peut accéder au port 22 est la chose la plus élémentaire que vous puissiez faire pour sécuriser votre système. Je me rends compte que cette tactique peut ne pas fonctionner pour tous les scénarios. Peut-être que vous gérez un système à usage public, ou peut-être que le CIO voyage beaucoup et peut accéder aux systèmes à partir de nombreux endroits différents (nous parlerons des VPN dans un instant). Ce que je veux dire, c'est que vous avez peut-être une raison valable pour que SSH soit absolument ouvert au grand public. Pensez très difficile d'éviter cette configuration, cependant. Je l'ai fait, mais surtout par paresse. Il existe généralement un meilleur moyen.
Si vous utilisez un fournisseur de cloud, configurez un groupe de sécurité pour n'accepter que le trafic SSH du réseau à partir duquel vous travaillez. Cette tâche devrait être simple si vous accédez à ce fournisseur à partir d'un environnement d'entreprise. Vous avez probablement votre propre plage d'adresses IP, ce qui signifie que vous pouvez la mettre sur liste blanche et bloquer tout le reste. Si vous accédez au fournisseur de cloud depuis chez vous, vous devrez peut-être effectuer quelques astuces pour mettre en liste blanche le bloc IP alloué dynamiquement de votre FAI. L'utilisation d'un groupe de sécurité devrait vous permettre de modifier la plage d'adresses IP via le portail en libre-service de votre fournisseur de cloud si nécessaire.
Si vous hébergez un système qui n'est pas derrière un pare-feu, utilisez le pare-feu basé sur l'hôte pour bloquer le port 22 de n'importe où sauf votre plage d'adresses IP, en utilisant les mêmes méthodes que je viens de décrire. Le problème ici, bien sûr, est que si vous êtes bloqué parce que votre adresse IP a changé, vous aurez plus de mal à apporter les modifications nécessaires.
Et n'oubliez pas qu'un environnement d'entreprise présente des avantages. Si votre serveur se trouve sur un réseau d'entreprise, il y a de fortes chances qu'il existe un pare-feu réseau que vous pouvez utiliser pour verrouiller l'accès SSH, alors utilisez ce fait à votre avantage. La défense en profondeur les amis, c'est un truc !
Exiger un VPN pour l'accès à distance
Ok, parlons donc de ce DSI itinérant qui a absolument besoin accès à ssh depuis une chambre d'hôtel. La solution semble évidente pour ceux d'entre nous qui ont fait le tour du quartier, mais si vous envisagez d'ouvrir l'accès SSH au monde entier, vous devez peut-être entendre ceci :un VPN, ou réseau privé virtuel, vous permet de construire un tunnel crypté d'un point de terminaison, comme l'ordinateur portable de votre CIO dans cet hôtel à Maui, vers votre réseau d'entreprise à Seattle. Cette connexion est protégée à sa manière, et cryptée.
Cependant, vos dizaines de serveurs qui ne sont pas accessibles au monde entier pourraient devenir accessibles via ce point unique. Oui, cette pratique déplace la cible de l'attaque vers le VPN, mais cela signifie qu'il y a un obstacle de plus à franchir pour les méchants.
Refuser l'accès root
Maintenant, nous arrivons au réel sshd configuration. Le démon OpenSSH a une option appelée PermitRootLogin . Par défaut, cette option est définie sur Yes , puisque lorsque vous installez certains systèmes, seul root existe au début. Lorsque cette situation se produit, vous avez besoin du compte root pour accéder au système et effectuer la configuration initiale.
Je recommande d'ajouter un utilisateur pendant le processus d'installation, ou dans le cadre de votre image dorée, et de désactiver les connexions root dès le départ. Il n'y a aucune raison de se connecter en tant que root, et il n'y a certainement aucune raison de se connecter en tant que root via SSH. Remplacez donc la ligne de configuration par :
PermitRootLogin no Mettre en œuvre l'authentification par clé
Au départ, j'utilisais l'authentification par clé pour plus de commodité. J'ai généré une clé privée, ajouté la clé publique à mes authorized_keys fichier sur les serveurs que je gérais, et pourrait alors se connecter en toute sécurité à mes systèmes sans mot de passe. Cela a permis de gagner du temps et de rendre l'automatisation possible. GAGNER! Ce n'est que plus tard que j'ai découvert que l'authentification basée sur une clé SSH pouvait être utilisée pour éliminer les tentatives de force brute de mot de passe.
Pour générer une clé, exécutez ssh-keygen sur une machine Mac ou Linux. Peut-être que vous, les gens de Windows, pouvez le faire de manière native maintenant, mais sur les machines Windows, j'ai toujours utilisé PuTTYGen (puis j'ai utilisé la clé avec le client PuTTY). On vous demandera un type de clé et une longueur. J'ai récemment créé des clés RSA 4096 bits. Plus il y a de bits, plus la clé est difficile à casser. Alors pourquoi pas ?
[gangrif@meliodas ~]$ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/gangrif/.ssh/id_rsa): ./test-key
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ./test-key.
Your public key has been saved in ./test-key.pub.
The key fingerprint is:
SHA256:xfHOf4t3V3CCkJ+3FbEnQusAjBwOjBXfOa9WdGXBMqc [email protected]
The key's randomart image is:
+---[RSA 4096]----+
| ++o.+. ....+o.|
| . .+o..+o+o+o..|
| o + =o=B..o|
| = *E.+.+|
| S o +. * |
| o .. .|
| o . o|
| . .o+|
| ...o|
+----[SHA256]-----+
Vous obtenez alors un nouveau fichier appelé test-key (dans ce cas), et test-key.pub . La clé dans test-key est ma clé privée, et test-key.pub contient la clé publique. Protégez la clé privée de votre vie. Vous pouvez cependant laisser la clé publique où vous voulez, car elle est inutile sans la clé privée.
[gangrif@meliodas ~]$ cat test-key.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDAQxmjoHO6i4Kkq8vp49KtqAsMcw+ptgvd+PGjxVYkDPGdzRZpJhq0c3BDstFs86ENlojs61zZaP3MihLR0BlDdIyM3jh9TmVvmOPiylhu4X9QliAca/ODxyVp76OpTKm+QcgBi/7i/JNiJdEgcSy8izB0Oil7LZjIhS6wCs3mQFVbkPXPfe1lmHQIcuMDOKO0RuyecY/lrKodcr/YbEE4GsM/P11QdDPZ78lq83G3H5vqLqMrxVKkLw7Z4//+PZPFFxi/N1EBwBp/uPEo4MfD1IwSmnKromRlkYTdOYlbiCNosdvEobtMARySdqjv7RDn0Iwb3JxioUW6jQdAXfl8d01LvX/0Yb1tq5hF44ahwvI6TyoB4z3DRs+3cFiMPWQR7LK8/qQOvHk5I2NMBAV9KuSN2ML0d7xeB8tglw38PYjhZsXl/t2rAWT4n8PU0o6+Hrrli+WEfvk8QWpLesmBBmzG0sLjH0mXBU/xN4UBLLJNlrsUQ/TzEsdknntMhh7leOzechlU3PiTNuUitweT9NqLJwCP+CHbeSJn2M5qzb090CPnCGpnr2GOfm2dL+RfHQi2R1Cf04nBDq3WuhAPJY5SoEw2llfSgA2GlOdhcY9N9Bl9rLUBPgQ6ttBd7qZJ6E3BkiPlHnU+kSSpYr8Gkw1oDGbtd2UUjExZqvz4rQ== [email protected]
Sur les machines auxquelles vous souhaitez vous connecter sans utiliser de mot de passe, copiez la clé publique dans .ssh/authorized_keys (ou demandez à l'utilisateur de le faire, selon la situation). Maintenant, je dis sans mot de passe, mais vous devez toujours déverrouiller la clé privée avec le mot de passe que vous avez défini lors de la génération. Vous avez défini un mot de passe, n'est-ce pas ?
Vous pouvez également copier à distance cette clé sur un serveur en utilisant ssh-copy-id .
Désactiver l'authentification par mot de passe
Vous souvenez-vous quand j'ai dit que l'authentification par clé vous ouvre la possibilité de verrouiller complètement les tentatives de force brute SSH ? Eh bien, voici comment. Avec vos clés privées et publiques en place, SSH ne vous demande plus de mot de passe, n'est-ce pas ? Alors pourquoi laisser cette voie ouverte comme vecteur d'attaque ?
Sur chaque serveur Linux que j'exécute, j'ajoute ma clé publique dans le cadre de notre installation de base et je désactive l'authentification par mot de passe SSH avant même que le système n'atteigne le réseau. Il s'agit d'un paramètre directement dans sshd le fichier de configuration de . Encore une fois, le paramètre par défaut permet l'authentification par mot de passe, car cette fonctionnalité doit fonctionner pour la configuration. Une fois que vous avez vos clés en place, désactivez-les.
PasswordAuthentication no Félicitations, vous êtes désormais immunisé contre les attaques par force brute par mot de passe.
Cage utilisateur SSH, avec chroot
Le chroot - généralement prononcée "chi-root" ou "ch-root" - la commande est un outil soigné. Il vous permet de changer le répertoire racine vu par un processus et ses enfants, d'où le nom. C'est idéal pour dépanner un système où vous pouvez accéder au disque, mais il ne démarre pas. Vous montez simplement son disque et chrootez sur /mnt/whatever.
C'est également un outil de sécurité soigné pour quelque chose comme un serveur shell. Vous pouvez chrooter un utilisateur lors de la connexion, de sorte qu'il ne puisse littéralement pas voir le reste du système de fichiers. Je ne le fais pas souvent, mais c'est une prison très viable pour les utilisateurs. J'ai trouvé ce qui semble être une bonne rédaction ici.
Rotation
Cela vaut la peine d'envisager la rotation des mots de passe et des clés ssh. Je vais essayer de décrire le bon et le mauvais ici.
Politique et rotation des mots de passe
Je regrouperai la politique de mot de passe avec la rotation des mots de passe car ils sont liés. Les politiques de mot de passe qui renforcent la complexité sont un excellent moyen d'inciter vos utilisateurs à choisir un mot de passe "fort". Cependant, cela comporte quelques mises en garde, en particulier lorsqu'il est associé à une expiration arbitraire (c'est-à-dire temporisée) du mot de passe. Je pourrais écrire un article entier sur ce que je pense de la politique et de la rotation des mots de passe, mais je vais essayer d'être bref ici.
L'année dernière, le NIST a fait volte-face sur ses directives de mot de passe, modifiant quelques-unes de ses suggestions qui étaient ancrées dans la plupart de nos esprits pendant la plupart de nos carrières. La communauté Infosec (dont je m'occupe) suggère depuis des années qu'un mot de passe aléatoire de 8 caractères, ou une longueur minimale de 8 caractères avec des règles de complexité strictes, faisait plus pour nuire à l'hygiène des mots de passe que pour l'aider. Combinez des règles de complexité strictes avec une politique de rotation des mots de passe de 3 à 6 mois, et vous exposez vos utilisateurs à la frustration. Cette frustration conduit à la réutilisation des mots de passe et à d'autres mauvaises habitudes. Réfléchissez donc bien si vous voulez imposer cela à vos utilisateurs. Les nouvelles recommandations tendent vers l'expiration uniquement lorsqu'une violation ou un compromis est suspecté, et une politique qui conduit vos utilisateurs à des phrases de passe fortes plutôt qu'à des mots de passe. "C'est mon p@ssw0rd 2019." est beaucoup plus difficile à deviner et à déchiffrer que "W1nt3r2019". Ce qui, soit dit en passant, est une référence commune pour les créateurs de mots de passe et les équipes rouges. Gardez cependant à l'esprit que si vous demandez aux administrateurs intelligents de faire pivoter leurs mots de passe, vous n'aurez peut-être pas ce problème (car ils comprennent POURQUOI ils le font et à quel point c'est important). Mais pour vos utilisateurs en général, les expirations arbitraires et les « mots de passe » complexes appartiennent au passé.
Rotation de la clé privée SSH
Comme tout identifiant qui peut être généré, il peut être bon d'envisager de faire tourner votre clé privée périodiquement. Votre clé privée n'est pas aussi facile à voler ou à deviner qu'un mot de passe, mais il est possible que quelqu'un ait récupéré votre clé à votre insu. Cela entre dans le territoire "comment aimeriez-vous être paranoïaque". Cependant, changer le mot de passe de votre clé privée n'est pas suffisant. Ce mot de passe déverrouille cette clé, si je glisse votre clé aujourd'hui, et que vous changez votre mot de passe demain, la copie si votre clé que j'ai a toujours votre ancien mot de passe. Si vous voulez le faire correctement, vous devez générer une toute nouvelle clé. C'est le bon moment pour allonger la longueur de la clé si la norme a augmenté depuis la dernière génération de clé. Peut-être que vous générez une nouvelle clé chaque fois que votre employeur vous délivre un nouvel ordinateur portable, peut-être que vous le faites une fois par an lors de votre anniversaire de travail. Cependant, je n'ai pas trouvé de solution qui gère cela pour vous.
Gardez à l'esprit que la génération d'une nouvelle clé signifie que toutes les clés publiques que vous avez dans le monde sont désormais invalides. Ou du moins, ils ne sont pas valides avec votre nouvelle clé. Vous devrez probablement utiliser votre ancienne clé pour placer votre nouvelle clé publique.
MFA
L'authentification multifacteur devient la norme. Certaines personnes ont essayé de prétendre que les clés SSH sont une forme de MFA, ce n'est en quelque sorte pas le cas. Surtout si vous avez désactivé l'authentification par mot de passe. Vous pouvez cependant intégrer des mfa comme TOTP ou YubiKey dans la configuration PAM de vos systèmes. Les solutions d'authentification centralisée telles que FreeIPA facilitent cette tâche.
Conclusion
Donc voilà, j'espère que vous prendrez ces informations et les appliquerez à vos systèmes pour améliorer votre sécurité. Ne soyez pas l'un de ces 21 millions de systèmes avec SSH ouvert sur le monde. Il n'y a simplement aucune raison pour cela.
Merci d'avoir lu !
Cet article a été initialement publié sur Undrground.org. Republié avec permission.