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.

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.

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.

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.

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 .

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.

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.

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

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 .

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.

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 .

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/

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

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.