Comment durcir un serveur SSH?

128

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.

LassePoulsen
la source
44
L'imperméabilité absolue nécessite de fermer la boîte.
Thorbjørn Ravn Andersen
Et si vous avez Wake-on-LAN?
Rébus
Le problème serait la partie LAN ... Les paquets Wake-on-LAN ne sont pas routés. Vous devez donc avoir accès à une machine du LAN pour envoyer le paquet WOL ...
LassePoulsen
Pour l'authentification par clé, vous pouvez limiter les chiffrements aux chiffrements dont vous avez réellement besoin.

Réponses:

108

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.pubchaque ordinateur sur des lignes individuelles ~/.ssh/authorized_keysdu serveur ou exécutez-le ssh-copy-id [server IP address]sur tous les ordinateurs auxquels 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 yeset changez-le en PasswordAuthentication no. Redémarrez le démon de serveur SSH pour appliquer le changement ( sudo service ssh restart).

Désormais, le seul moyen de SSH sur le serveur consiste à utiliser une clé correspondant à une ligne ~/.ssh/authorized_keys. En utilisant cette méthode, je me moque des attaques par force brute car même si elles devinent mon mot de passe, il sera rejeté. Forcer brutalement une paire de clés publique / privée est impossible avec la technologie actuelle.

Evan Kroske
la source
5
-1: En général, l'accès est accordé à des ordinateurs individuels et non à des ordinateurs. La création d'une clé pour chaque ordinateur client potentiel se connectant au serveur est déraisonnable. Votre dernière déclaration n'est pas correcte, selon votre suggestion et parce que vous n'avez pas suggéré de définir une phrase secrète pour les clés privées ayant un accès / compromettant l'un des systèmes client, accorderait automatiquement l'accès au serveur SSH. L'authentification par clé SSH est recommandée, mais les clés privées doivent être correctement protégées et doivent être utilisées individuellement, et non de manière distribuée comme décrit.
João Pinto
7
"En général, l'accès est accordé à des ordinateurs individuels et non à des ordinateurs. Il est déraisonnable de créer une clé pour chaque ordinateur client potentiel se connectant au serveur." . Je ne présente pas toutes les options, mais une simple que je pense que les gens peuvent comprendre. "... devrait être utilisé sur une base individuelle, pas de manière distribuée comme décrit" Cela semble contredire votre déclaration précédente et je n'ai rien décrit comme distribué.
Asa Ayers
5
"impossible" est peut-être exagéré un peu.
Thorbjørn Ravn Andersen
9
C'est pourquoi je dis "impossible". Personne n’a d’ordinateurs aussi rapides, aussi petits, autant ou autant de temps. "Imaginez un ordinateur de la taille d'un grain de sable capable de tester des clés par rapport à des données chiffrées. Imaginez également qu'il puisse tester une clé pendant le temps qu'il faut de lumière pour la traverser. Ensuite, considérons un cluster de ces ordinateurs, tellement que si vous couvriez la terre avec eux, ils couvriraient toute la planète à une hauteur d'un mètre. L'ensemble des ordinateurs fissurerait une clé de 128 bits en moyenne dans 1 000 ans. "
Asa Ayers
@ ThorbjørnRavnAndersen "Impossible" n'exagère pas vraiment, tant que vous utilisez une clé forte. Je ne trouve pas de devis pour le moment, mais avec les longueurs de clé actuelles, les attaques par force brute sont irréalisables "jusqu'à ce que les ordinateurs soient constitués d'autre chose que de matière et occupent autre chose que d'espace".
Maximillian Laumeister
72

Je voudrais suggerer:

  • Utiliser fail2ban pour empêcher les tentatives de connexion par force brute.

  • 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.

    Ajouter AllowGroups group1 group2ou AllowUsers user1 user2limiter qui peut SSH sur le serveur.

Mark Davidson
la source
2
Les AllowUsers et AllowGroups n'accepte pas une virgule , comme séparateur. Assurez-vous de ne pas essayer cela à distance. Je continue à être bloqué hors de mon NAS en le faisant de manière incorrecte.
bruit naïf
4
Validez toujours que votre sshdconfiguration est correcte avant de redémarrer sshd, pour éviter de vous verrouiller en dehors de la machine. Voir ce blog pour plus de détails - il suffit de s’exécuter sshd -Taprès un changement de configuration avant de redémarrer le principal sshd. Également, ouvrez une session SSH sur la machine lorsque vous modifiez la configuration, et ne la fermez pas tant que vous n'avez pas validé la configuration comme indiqué et avez peut-être effectué un test de connexion SSH.
RichVel
24

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.

Douglas Leeder
la source
1
Pour ceux qui croient en la sécurité par l'obscurité ( en.wikipedia.org/wiki/Security_through_obscurity ), il est logique d'utiliser un autre port. Je ne pense pas ..
LassePoulsen
32
Il ne s'agit pas de la sécurité par l'obscurité (même si l'obscurité peut avoir un effet positif marginal). Il s'agit de réduire le bruit de fond des tentatives de force brute sans fin. Vous ne pouvez pas utilement auditer vos journaux d'échec d'accès s'ils sont pleins d'attaques automatisées; fail2ban ne réduit pas suffisamment le volume compte tenu du nombre d’attaques et de la prévalence d’attaques distribuées (botnet) et limitées. Avec ssh sur un port inhabituel, vous savez que les attaques que vous voyez dans les journaux proviennent d'un véritable attaquant intéressé par votre ordinateur. Je le recommande fortement.
Bobince
Étant donné que vous pouvez interroger des services Internet tels que shodan pour des serveurs ssh sur le Web, ou que vous utilisez nmap et la capture de bannière, il est pratiquement inutile de changer le port par défaut. Je déconseillerais cela.
SLow Loris
Shodan ne saisit pas tous les ports 65k, donc passer à un port haut le supprimera probablement de leurs scans. De plus, si vous passez à un port haut aléatoire, l'attaquant devra probablement effectuer des analyses TCP 65K (très bruyant) pour trouver votre service et commencer à l'attaquer. Ces deux solutions sont gagnantes du point de vue de la sécurité. Le passage à un port haut est donc généralement un bon plan. Une autre
solution est qu'en choisissant
23

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

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

Sommaire:

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

  2. Demandez à chaque utilisateur d'exécuter la google-authenticatorcommande, qui les génère ~/.google-authenticatoret les aide à configurer leurs appareils à deux facteurs (par exemple, l'application Android Google Authenticator).

  3. Modifier /etc/ssh/sshd_configet définir:

    ChallengeResponseAuthentication yes
    PasswordAuthentication no
    AuthenticationMethods publickey,keyboard-interactive
    
  4. Exécuter sudo service ssh reloadpour récupérer vos modifications /etc/ssh/sshd_config.

  5. Editez /etc/pam.d/sshdet remplacez la ligne:

    @include common-auth
    

    avec:

    auth required pam_google_authenticator.so
    

Mon article de blog de l'année dernière contient des informations plus détaillées sur les différentes options de configuration: Meilleure authentification SSH à deux facteurs sous Ubuntu .

Robie Basak
la source
21

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.

LassePoulsen
la source
2
Existe-t-il une option telle que 10 tentatives de connexion infructueuses avant d'interdire l'adresse IP?
sayantankhan
20

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

À partir d'une invite de commande, tapez:

$ sudo ufw limit OpenSSH 

Si ufw 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.

Mpontillo
la source
+1 utiliser limite peut être bon. Cependant, je dois signaler que j'ai rencontré des problèmes lors de l'utilisation du serveur sftp intégré, car cela limite également les connexions.
Mark Davidson
2
@ Mark - bon point, mais cela ne ressemble-t-il pas à un client SFTP mal écrit? Pourquoi voudraient-ils continuer à se reconnecter au port SSH alors qu'ils pourraient simplement ouvrir davantage de canaux SSH?
mpontillo
12

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 sur localhost.
  3. Ouvert /etc/tor/torrc. Définir HiddenServiceDir /var/lib/tor/sshet HiddenServicePort 22 127.0.0.1:22.
  4. Regarde var/lib/tor/ssh/hostname. Il y a un nom comme d6frsudqtx123vxf.onion. C'est l'adresse du service caché.
  5. Ouvrez $HOME/.ssh/configet 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 myhostet 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".

qbi
la source
10
Sécurité par obscurité avancée, mais très intéressante.
Johannes
8

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 .

Huygens
la source
3
Un peu en retard, mais s'il vous plaît, lorsque vous répondez aux questions, copiez les parties importantes d'un lien afin que si le lien se désintègre, les informations sont toujours là.
umop aplsdn
1
Bonne idée. Bien que je traverse une période avec beaucoup moins de temps pour participer. Ma réponse est un "wiki de communauté", alors n'hésitez pas à ajouter les informations du lien si vous en avez le temps.
Huygens
6

Mon approche du durcissement SSH est ... complexe. Les éléments suivants décrivent comment je le fais, de la limite extrême de mon (mes) réseau (s) aux serveurs eux-mêmes.

  1. Filtrage du trafic au niveau de la frontière via IDS / IPS avec des scanners de services connus et des signatures figurant dans la liste de blocage. Je réalise cela avec Snort via mon pare-feu frontière (c’est mon approche, une appliance 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 uniquement certains systèmes à accéder à mes serveurs SSH. Cela 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, connectez le réseau interne et séparez Internet et les systèmes de l’ 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 qui peut ou ne peut pas SSH dans - mon seul boîtier, 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 qui attaquent en permanence avec des armes brutes - il suffit de les bloquer au pare-feu automatiquement avec fail2ban et meh. La configuration de fail2ban est difficile cependant ...

  5. Obfuscation de port en changeant le port SSH. Cependant, ce n’est PAS une bonne idée de se passer également 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 réseau, mais cela reste très TRES médiocre à faire par lui-même.

  6. Authentification à deux facteurs OBLIGATOIRE via les solutions d'authentification à deux facteurs de Duo Security . Duo est configuré sur chacun de mes serveurs SSH, de telle sorte que même pour entrer, des invites 2FA se produisent et que 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.

Thomas W.
la source
1

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 que Yubikey ou eToken PASS ou NG, ou si vous avez plusieurs utilisateurs ou plusieurs serveurs, vous pouvez utiliser un backend à authentification Open Source à deux facteurs.

Dernièrement, j'ai écrit un howto à ce sujet .

cornelinux
la source
0

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 autres bases. https://joscor.com/blog/hardening-openssh-server-ubuntu-14-04/

01000101
la source
0

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

weller1
la source
0

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.

Michael A Mike
la source
1
Parfois, les bases de données GeoIP peuvent être fausses - on m'a demandé si j'étais à Moscou hier ... hein non! :)
Sean