web-dev-qa-db-fra.com

Comment durcir un serveur SSH?

Quelles mesures puis-je/dois-je prendre pour m'assurer que la sécurité autour de mon serveur SSH est absolument imperméable?

Ce sera un wiki de communauté dès le début, alors voyons ce que les gens font pour sécuriser leurs serveurs.

securityssh
128
LassePoulsen

Assurez-vous que les adresses IP des clients du bloc sshd qui n'ont pas réussi à fournir les informations de connexion correctes " DenyHØsts " peuvent effectuer ce travail de manière très efficace. J'ai installé ceci sur toutes mes machines Linux qui sont en quelque sorte accessibles depuis le grand extérieur.

Cela garantira que les attaques de force sur le SSHD ne seront pas efficaces, mais souvenez-vous (!) De cette façon, vous pourrez vous verrouiller si vous oubliez votre mot de passe. Cela peut être un problème sur un serveur distant auquel vous n'avez pas accès.

21
LassePoulsen

Utilisez des paires de clés publique/privée pour l'authentification au lieu de mots de passe.

  1. Générez une clé SSH protégée par mot de passe pour chaque ordinateur devant accéder au serveur:

    ssh-keygen

  2. Autorisez l'accès SSH à clé publique à partir des ordinateurs autorisés:

    Copiez le contenu de ~/.ssh/id_rsa.pub de chaque ordinateur dans des lignes individuelles de ~/.ssh/authorized_keys sur le serveur ou exécutez ssh-copy-id [server IP address] sur chaque ordinateur auquel vous accordez l'accès (vous devrez entrer le mot de passe du serveur à l'invite).

  3. Désactiver l'accès SSH par mot de passe:

    Ouvrez /etc/ssh/sshd_config, trouvez la ligne qui dit #PasswordAuthentication yes et remplacez-la par PasswordAuthentication no. Redémarrez le démon de serveur SSH pour appliquer la modification (Sudo service ssh restart).

Désormais, le seul moyen de SSH sur le serveur consiste à utiliser une clé correspondant à une ligne dans ~/.ssh/authorized_keys. En utilisant cette méthode, I ne vous inquiétez pas des attaques par force brute car même s'ils devinent mon mot de passe, il sera rejeté. Il est impossible de forcer brute une paire de clés publique/privée avec la technologie actuelle.

108
Asa Ayers

Je voudrais suggerer:

  • Utilisation de fail2ban pour empêcher les tentatives de connexion brutales.

  • Désactiver la connexion en tant que root via SSH. Cela signifie qu'un attaquant devait déterminer à la fois le nom d'utilisateur et le mot de passe, rendant une attaque plus difficile.

    Ajoutez PermitRootLogin no à votre /etc/ssh/sshd_config.

  • Limiter le nombre d'utilisateurs pouvant utiliser SSH sur le serveur. Soit par groupe ou juste des utilisateurs spécifiques.

    Ajoutez AllowGroups group1 group2 ou AllowUsers user1 user2 pour limiter les utilisateurs autorisés à SSH sur le serveur.

72
Mark Davidson

D'autres réponses apportent une sécurité, mais vous pouvez faire une chose pour rendre vos journaux plus calmes et réduire les risques de blocage de votre compte:

Déplacez le serveur du port 22 à un autre. Soit à votre passerelle, soit sur le serveur.

Cela n'augmente pas la sécurité, mais signifie que tous les scanners Internet aléatoires n'encombreront pas vos fichiers journaux.

24
Douglas Leeder

Activez l'authentification à deux facteurs avec HOTP ou TOTP . Ceci est disponible à partir de 13h10.

Ceci inclut l’utilisation de l’authentification par clé publique sur l’authentification par mot de passe comme dans une autre réponse ici, mais requiert également que l’utilisateur prouve qu’il détient son périphérique à facteur 2 en plus de sa clé privée.

Résumé:

  1. Sudo apt-get install libpam-google-authenticator

  2. Demandez à chaque utilisateur d'exécuter la commande google-authenticator, qui génère ~/.google-authenticator et l'aide à configurer ses périphériques à deux facteurs (par exemple, l'application Google Authenticator Android).

  3. Éditez /etc/ssh/sshd_config et réglez:

    ChallengeResponseAuthentication yes
PasswordAuthentication no
AuthenticationMethods publickey,keyboard-interactive

  4. Exécutez Sudo service ssh reload pour récupérer vos modifications à /etc/ssh/sshd_config.

  5. Editez /etc/pam.d/sshd et remplacez la ligne:

    @include common-auth

    avec:

    auth required pam_google_authenticator.so

Mon article de blog de l'année dernière contient plus de détails sur les différentes options de configuration: Meilleure authentification SSH à deux facteurs sur Ubunt .

23
Robie Basak

Voici une chose facile à faire: installez fw (le "pare-feu simple") et utilisez-le pour limiter le nombre de connexions entrantes.

A partir d'une invite de commande, tapez:

$ Sudo ufw limit OpenSSH

Si fw n'est pas installé, faites ceci et essayez à nouveau:

$ Sudo aptitude install ufw

De nombreux attaquants vont essayer d'utiliser votre serveur SSH pour forcer la brutalité des mots de passe. Cela permettra seulement 6 connexions toutes les 30 secondes à partir de la même adresse IP.

20
mpontillo

Si je souhaite bénéficier d'une sécurité supplémentaire ou si j'ai besoin d'accéder à des serveurs SSH situés à l'intérieur d'un réseau d'entreprise, je configure un service caché à l'aide du logiciel d'anonymisation Tor .

  1. Installez Tor et configurez le serveur SSH lui-même.
  2. Assurez-vous que sshd n'écoute que localhostname__.
  3. Ouvrez /etc/tor/torrc. Définissez HiddenServiceDir /var/lib/tor/ssh and HiddenServicePort 22 127.0.0.1:22.
  4. Regardez var/lib/tor/ssh/hostname. Il y a un nom comme d6frsudqtx123vxf.onion. C'est l'adresse du service caché.

  5. Ouvrez $HOME/.ssh/config et ajoutez quelques lignes:

    Host myhost
HostName d6frsudqtx123vxf.onion
ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050

De plus, j'ai besoin de Tor sur mon hôte local. S'il est installé, je peux entrer ssh myhost et SSH ouvre une connexion via Tor. Le serveur SSH de l'autre côté ouvre son port uniquement sur localhost. Donc, personne ne peut le connecter via "Internet normal".

12
qbi

Il y a un article sur l'administration Debian sur ce sujet. Il couvre la configuration de base du serveur SSH ainsi que les règles de pare-feu. Cela pourrait également être intéressant pour renforcer un serveur SSH.

Voir cet article: sécurisation de l'accès SSH .

8
Huygens

Mon approche du durcissement SSH est… complexe. Les éléments suivants décrivent comment je le fais, de la bordure la plus à la périphérie de mon (mes) réseau (s) aux serveurs eux-mêmes.

  1. Filtrage au niveau de la frontière du trafic via IDS/IPS avec des scanners de service et des signatures connus dans la liste des personnes bloquées. Je réalise cela avec Snort via mon pare-feu mon approche, un appareil pfSense). Parfois, je ne peux pas faire cela, comme avec mes VPS.

  2. Filtrage de pare-feu/réseau du (des) port (s) SSH. J'autorise explicitement certains systèmes à accéder à mes serveurs SSH. Ceci est effectué via un pare-feu pfSense à la frontière de mon réseau ou via les pare-feu de chaque serveur explicitement configurés. Cependant, il y a des cas où je ne peux pas faire cela (ce qui n'est presque jamais le cas, sauf dans les environnements privés de tests au stylo ou de tests de sécurité où les pare-feu ne facilitent pas les tests).

  3. En conjonction avec mon pfSense, ou un pare-feu de frontière NAT qui connecte le réseau interne et se sépare d’Internet et des systèmes, Accès VPN uniquement aux serveurs . Je dois utiliser un réseau privé virtuel sur mes réseaux pour accéder aux serveurs, car il n'y a pas de ports Internet en tant que tels. Cela ne fonctionne certainement pas pour tous mes VPS, mais en conjonction avec # 2, je peux avoir un VPS qui est la "passerelle" en VPN sur ce serveur, puis autoriser ses adresses IP aux autres boîtes. De cette façon, je sais exactement ce que peut ou ne peut pas SSH dans - mon seul boîtier qui est le VPN. (Ou, dans mon réseau domestique derrière pfSense, ma connexion VPN et je suis le seul à avoir un accès VPN).

  4. Là où # 3 n'est pas faisable, fail2ban, configuré pour bloquer après 4 tentatives infructueuses et bloquer les IP pendant une heure ou plus est une protection décente contre les personnes attaquer avec bruteforcing - bloquez simplement em au niveau du pare-feu automatiquement avec fail2ban, et meh. La configuration de fail2ban est difficile cependant ...

  5. Obfuscation de port en changeant le port SSH. Cependant, , il n’est PAS judicieux de se passer de mesures de sécurité supplémentaires. - Le mantra de "La sécurité par l'obscurité" a déjà été réfuté et contesté dans de nombreux cas. Je l'ai fait en conjonction avec IDS/IPS et le filtrage de réseau, mais cela reste une très mauvaise chose à faire par lui-même.

  6. OBLIGATOIRE Authentification à deux facteurs, via solutions d'authentification à deux facteurs de Duo Security . Sur chacun de mes serveurs SSH, Duo est configuré dessus, de telle sorte que même pour entrer, les invites 2FA se produisent, et je dois confirmer chaque accès. (C'est la fonctionnalité la plus utile - car même si quelqu'un a ma phrase secrète ou s'introduit, il ne peut pas aller au-delà des plugins Duo PAM). C'est l'une des plus grandes protections sur mes serveurs SSH contre les accès non autorisés - chaque connexion d'utilisateur DOIT être rattachée à un utilisateur configuré dans Duo, et comme j'ai un ensemble restrictif, aucun nouvel utilisateur ne peut être enregistré dans le système.

Mes deux sous pour sécuriser SSH. Ou du moins, mes réflexions sur l'approche.

6
Thomas Ward

Vous voudrez peut-être utiliser l'application FreeOTP de RedHat au lieu d'utiliser Google Authenticator. Parfois, lors de la mise à jour de l'application, ils vous bloquent! ;-)

Si vous souhaitez utiliser d'autres jetons matériels, tels qu'un Yubikey ou un eToken PASS ou NG, ou si vous avez plusieurs utilisateurs ou plusieurs serveurs, vous pouvez utiliser un système d'authentification à deux facteurs opensource.

Dernièrement, j'ai écrit un howto about this .

1
cornelinux

Pour un grand nombre d'utilisateurs/de certificats, envisagez l'intégration LDAP. Les grandes entreprises utilisent LDAP en tant que référentiel pour les informations d'identification de l'utilisateur et les certificats stockés sur des badges ou des fobs, que les certificats soient utilisés pour l'authentification ou la signature d'e-mails. Les exemples incluent openLDAP, openDJ, Active Directory, Oracle Universal Directory, IBM Directory Server, snareWorks ...

Les ordinateurs et les groupes peuvent également être gérés dans LDAP, ce qui permet une gestion centralisée des informations d'identification. De cette façon, les centres d’assistance peuvent avoir un guichet unique pour traiter les grandes populations.

Voici un lien vers l'intégration centOS: http://itdavid.blogspot.com/2013/11/howto-configure-openssh-to-fetch-public.html

0
weller1

Vous pouvez également bloquer en fonction du pays d'origine à l'aide de la base de données geoIP.

En gros, si vous vivez aux États-Unis, il n'y a aucune raison pour que quelqu'un en Russie se connecte à votre SSH, de sorte qu'il sera automatiquement bloqué.

Le script peut être trouvé ici: https://www.axllent.org/docs/view/ssh-geoip/

Vous pouvez également y ajouter des commandes iptables (ce que j'ai fait pour mes droplets) afin de supprimer automatiquement tout le trafic vers/depuis ces IP.

0
Michael A Mike

J'ai écrit un petit tutoriel sur le faire récemment. En gros, vous devez utiliser une infrastructure à clé publique (PKI) et mon tutoriel explique également comment utiliser l'authentification à deux facteurs pour encore plus de sécurité. Même si vous n'utilisez aucune de ces choses, il existe également quelques petites astuces sur la sécurisation du serveur en supprimant les suites de chiffrement faibles et d'autres bases. https://joscor.com/blog/hardening-openssh-server-ubuntu-14-04/

0
01000101