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.
Réponses:
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.
Utilisez un mot de passe fort, composé d'au moins (disons) 10 lettres majuscules et minuscules, chiffres et autres caractères.
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
ChrootDirectory
directive native du serveur OpenSSH . Un exemple de tutoriel à ce sujet peut être trouvé ici .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.
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.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.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.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.deny
et en ajoutant les éléments suivants:et d'
/etc/hosts.allow
ajouter ce qui suit: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 par192.168.1.
seront acceptées. Si cela ne fonctionne pas, votre distribution pourrait utiliser à lassh
place desshd
. Dans ce cas, vous devriez essayerssh: 192.168.1.*
et à lassh: ALL
place.Vous ne pouvez autoriser que des hôtes spécifiques, faire de même avec le
/etc/hosts.allow
et/etc/hosts.deny
comme décrit dans 6, mais en/etc/hosts.allow
ajoutant la ligne suivante et chaque hôte à autoriser séparés par des espaces: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: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:
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.supprimez le, 1 pour que la ligne soit
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.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:
ou
en fonction de la distribution de Linux que vous utilisez.
la source
sudo service ssh restart
sur Ubuntu.sudo restart ssh
.Quelques conseils:
la source
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
webmaster
etbob
) et les mots de passe faibles. Vous pouvez éliminer ce risque en interdisant les connexions de mot de passe (misPasswordAuthentication no
ensshd_config
et soit également misUsePAM No
ou 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 avecAllowUsers
ouAllowGroups
danssshd_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é.
la source
Trois choses me sont venues à l'esprit:
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
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
Même si l'utilisateur root est désactivé par défaut pour Ubuntu, désactivez explicitement la connexion root
PermitRootLogin non
la source