Quels sont les problèmes de sécurité possibles avec un démon SSH?

J'aimerais pouvoir SSH vers mon PC de bureau Ubuntu 10.04 de l'extérieur. Je pense donc à démarrer un démon SSH sur le PC. Quels sont les problèmes de sécurité, les problèmes possibles, les paramètres de configuration spécifiques, etc. Je devrais être au courant?

Au cas où cela importe: c'est essentiellement pour mon usage personnel uniquement, je ne pense pas qu'il y aura d'autres personnes qui l'utiliseront; c'est un PC Ubuntu 10.04 dans un environnement principalement Windows 7 / Vista / XP.

La plus grande préoccupation serait que les personnes se connectent en tant qu'administrateur de l'ordinateur via SSH. Cela peut être fait par force brute si vous avez un mot de passe facile à deviner.

Il existe plusieurs mesures de sécurité que vous pouvez prendre, voici quelques-unes de celles que je prends toujours lors de la configuration d'un serveur SSH et quelques autres.

1. Utilisez un mot de passe fort, composé d'au moins (disons) 10 lettres majuscules et minuscules, chiffres et autres caractères.

2. Emprisonner les utilisateurs dans leur répertoire personnel. Les utilisateurs emprisonnés ne pourront pas accéder / modifier des fichiers qui se trouvent en dehors de leur répertoire personnel. Ainsi, votre utilisateur ne pourra pas accéder / modifier les fichiers système clés. De nombreux didacticiels peuvent être trouvés en ligne sur la façon d'emprisonner un utilisateur. La plupart d'entre eux utilisent JailKit . Un exemple d'un tel tutoriel peut être trouvé ici . Alternativement, vous pouvez également utiliser la ChrootDirectorydirective native du serveur OpenSSH . Un exemple de tutoriel à ce sujet peut être trouvé ici .

3. Installez Fail2Ban . Fail2Ban est un programme qui vérifie les journaux d'authentification pour les entrées incorrectes. Lorsqu'une certaine limite est atteinte, il ajoute un bloc de pare-feu pour cette certaine IP pendant une durée prédéfinie. Il existe également plusieurs didacticiels en ligne sur la façon de configurer Fail2Ban avec SSH, un exemple serait celui-ci . La page d'accueil de Fail2Ban contient également des HOWTO sympas et complets.

4. Désactivez la connexion root via SSH. C'est l'utilisateur qui a accès à pratiquement tous les fichiers de votre système, il est donc recommandé de désactiver sa connexion shell. Dans les dernières versions d'Ubuntu, l'utilisateur root est automatiquement désactivé mais cela ne fait pas de mal de désactiver son accès SSH de toute façon. Cela se fait en modifiant le fichier /etc/ssh/sshd_config. ^✝ Recherchez la ligne suivante et assurez-vous qu'il n'y a pas de # devant.

   #PermitRootLogin no
   

5. Utiliser un port non standard (par exemple, pas 22) Cela se fait soit par la redirection de port dans votre routeur (par exemple 16121 -> 22 au lieu de 22 -> 22) ou en faisant écouter le démon SSH sur un port différent. Cela rendra votre service SSH moins facilement détectable par les utilisateurs malveillants. Cela se fait en modifiant le fichier /etc/ssh/sshd_config. ^✝ Recherchez la ligne suivante et remplacez 22 par le port souhaité. N'oubliez pas de transmettre ensuite le bon port de votre routeur.

   Port 22
   

6. N'utilisez pas de mots de passe pour vous connecter. Outre les mots de passe, SSH permet également de se connecter en utilisant des clés privées. Cela signifie qu'une clé est stockée sur votre ordinateur sur laquelle vous accédez au SSH de la machine SSH. Lorsqu'une connexion est tentée, le client SSH utilise la clé pour se connecter au serveur au lieu d'une authentification par mot de passe. Les clés d'authentification sont beaucoup plus solides cryptographiquement que les mots de passe et ne sont donc pas si faciles à déchiffrer. Il existe également plusieurs didacticiels en ligne sur la façon de configurer l'authentification basée sur des clés avec SSH, un exemple serait celui-ci . (Si vous SSH à partir de Windows avec PuTTY, consultez ce lien pour un guide PuTTY.) Après avoir configuré l'authentification par clé, vous pouvez désactiver l'authentification par mot de passe en modifiant le fichier /etc/ssh/sshd_config. ^✝ Recherchez la ligne suivante et assurez-vous qu'il n'y a pas de # devant.

   #PasswordAuthentication no
   

7. Facultativement, comme @ Linker3000 l'a mentionné dans son commentaire, vous pouvez configurer un tunnel VPN vers le PC auquel vous souhaitez accéder via SSH, puis interdire l'accès au réseau non local sur le serveur SSH. De cette façon, aucun appareil externe sans connexion VPN ne pourra accéder à votre serveur SSH. Cela peut être fait en refusant TOUS les hôtes et en autorisant uniquement les adresses IP du réseau local à se connecter. Cela se fait en modifiant /etc/hosts.denyet en ajoutant les éléments suivants:

   sshd: ALL
   

   et d' /etc/hosts.allowajouter ce qui suit:

   sshd: 192.168.1.*
   

   où l'adresse IP correspond à celle de votre réseau local. *est un caractère générique, donc toutes les adresses IP commençant par 192.168.1.seront acceptées. Si cela ne fonctionne pas, votre distribution pourrait utiliser à la sshplace de sshd. Dans ce cas, vous devriez essayer ssh: 192.168.1.*et à la ssh: ALLplace.

8. Vous ne pouvez autoriser que des hôtes spécifiques, faire de même avec le /etc/hosts.allowet /etc/hosts.denycomme décrit dans 6, mais en /etc/hosts.allowajoutant la ligne suivante et chaque hôte à autoriser séparés par des espaces:

   sshd: {IP OF HOST TO ALLOW 1} {IP OF HOST TO ALLOW 2} {IP OF HOST TO ALLOW 3} {ETC.}
   

9. Autorisez uniquement des utilisateurs spécifiques à accéder à votre serveur SSH. Cela se fait en modifiant le fichier /etc/ssh/sshd_config. ^✝ Recherchez la ligne suivante et assurez-vous qu'il n'y a pas de # devant. S'il n'existe pas, créez-le. Par exemple, si vous souhaitez autoriser john, tom et mary uniquement, ajoutez / modifiez cette ligne:

   AllowUsers john tom mary
   

   Vous pouvez également refuser des utilisateurs spécifiques, par exemple, si vous souhaitez refuser l'accès à john, tom et mary, ajoutez / modifiez cette ligne:

   DenyUsers john tom mary
   

10. Autorisez uniquement le protocole SSH2 pour les connexions entrantes. Il existe deux versions du protocole SSH. SSH1 est soumis à des problèmes de sécurité, il est donc recommandé d'utiliser SSH 2. Cela peut être forcé en modifiant le fichier /etc/ssh/sshd_config. ^✝ Recherchez la ligne suivante et assurez-vous qu'il n'y a pas de # devant. S'il n'existe pas, créez-le.

    Protocol 2,1
    

    supprimez le, 1 pour que la ligne soit

    Protocol 2
    

11. N'autorisez pas les utilisateurs à se connecter sans mot de passe. Cela peut être forcé en modifiant le fichier /etc/ssh/sshd_config. ^✝ Recherchez la ligne suivante et assurez-vous qu'il n'y a pas de # devant. S'il n'existe pas, créez-le.

    PermitEmptyPasswords no
    

12. Et bien que simple et peut-être inutile de le dire, mais prouvé crucial dans plusieurs cas, gardez votre logiciel à jour. Mettez à jour régulièrement vos packages / logiciels installés.

^✝ = après avoir édité le fichier de configuration SSH, n'oubliez pas de redémarrer le démon pour appliquer les modifications. Redémarrez le démon en exécutant:

sudo /etc/init.d/ssh restart

ou

sudo /etc/init.d/sshd restart

en fonction de la distribution de Linux que vous utilisez.

Quelques conseils:

1. Utilisez l'authentification basée sur les clés, qui est bien plus sûre que les mots de passe
2. SSH 2 uniquement
3. Désactiver les connexions root
4. Pour le paranoïaque, changez le port du port standard 22
5. Pour plus de commodité, utilisez un outil pour mapper votre IP à un nom DNS, comme Dyndns ou son acabit. Vous pouvez aller longtemps avec la même adresse IP, mais une fois que vous voyagez et en avez besoin, vous constaterez que vous en avez obtenu une nouvelle.
6. Bien sûr, n'autorisez que le port requis pour SSH (port 22, ou non standard si vous le souhaitez) via votre pare-feu.

Le principal risque est d'oublier que vous exécutez un serveur ssh et de mettre un mot de passe faible sur un compte. Il existe des attaquants qui essaient systématiquement les noms de compte courants (comme webmasteret bob) et les mots de passe faibles. Vous pouvez éliminer ce risque en interdisant les connexions de mot de passe (mis PasswordAuthentication noen sshd_configet soit également mis UsePAM Noou désactiver l' authentification par mot de passe dans les paramètres du PAM pour ssh). Une mesure intermédiaire consiste à restreindre les connexions ssh à une liste blanche d'utilisateurs avec AllowUsersou AllowGroupsdans sshd_config.

Notez que l'autorisation des connexions par mot de passe n'est pas en soi un problème de sécurité. Les mots de passe faibles et les mots de passe espionnés sont les problèmes, et permettre l'authentification par mot de passe dans le serveur ssh est un facilitateur. Pour vous protéger contre l'espionnage par mot de passe, ne tapez jamais votre mot de passe sur une machine à laquelle vous ne faites pas entièrement confiance (mais alors si vous faites confiance à une machine, vous pourriez aussi bien y installer une clé privée et vous n'avez pas besoin d'authentification par mot de passe).

La condition minimale pour utiliser un client ssh sur une machine est que vous ayez confiance qu'il n'y aura pas de détournement actif de la communication ssh (une attaque man-in-the-middle est possible si elle s'exécute sur la machine client - vous pensez vous saisissez des commandes dans un client ssh vierge, mais le client transmet fidèlement vos données d'authentification mais insère également un cheval de Troie dans la communication par la suite). Il s'agit d'une exigence plus faible que de faire confiance à un espion de mot de passe (généralement effectué via un enregistreur de frappe, mais il existe d'autres méthodes moins automatisées telles que la navigation à l'épaule). Si vous avez le minimum de confiance mais craignez toujours les espions, vous pouvez utiliser des mots de passe à usage unique (OpenSSH les prend en charge via son support PAM).

Bien sûr, comme tout autre programme qui interagit avec des machines hors de votre contrôle (pas seulement des serveurs réseau mais aussi des clients), vous devez suivre les mises à jour de sécurité.

Trois choses me sont venues à l'esprit:

1. Si vous ouvrez le port par défaut 22, il sera bientôt détecté et votre PC sera martelé par des attaques par force brute. Je vous suggère de configurer sshd pour écouter un autre port ou de faire un mappage de port sur votre pare-feu. Bien que ce ne soit pas une solution miracle, il vous fera au moins économiser les mêmes cycles CPU.

   Port 12345

2. Désactivez explicitement l'authentification par mot de passe et utilisez uniquement les clés. N'importe quelle clé sera meilleure que le mot de passe le plus complexe dont vous vous souviendrez.

   PasswordAuthentication no

3. Même si l'utilisateur root est désactivé par défaut pour Ubuntu, désactivez explicitement la connexion root

   PermitRootLogin non