Comment renforcer un serveur SSH?

119

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

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

    
posée LassePoulsen 30.01.2015 - 17:27
la source

13 réponses

21

Faites en sorte que les adresses IP clientes du bloc sshd qui n’ont pas fourni les informations de connexion correctes " DenyHØsts " puissent fonctionner correctement. Je l'ai installé sur toutes mes boîtes Linux qui sont en quelque sorte accessibles depuis l'extérieur.

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

    
réponse donnée LassePoulsen 10.06.2016 - 23:17
la source
100

Utilisez des paires de clés publiques / privées pour l’authentification au lieu des 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. Autoriser 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 au prompt).

  3. Désactiver l’accès SSH au mot de passe:

    Ouvrez /etc/ssh/sshd_config , recherchez la ligne indiquant #PasswordAuthentication yes et remplacez-la par PasswordAuthentication no . Redémarrez le démon du serveur SSH pour appliquer la modification ( sudo service ssh restart ).

Maintenant, la seule façon possible d’accéder à SSH sur le serveur consiste à utiliser une clé correspondant à une ligne dans ~/.ssh/authorized_keys . En utilisant cette méthode, I ne se soucie pas des attaques par force brute, car même si elles devinent mon mot de passe, il sera rejeté. Il est impossible de forcer une paire de clés publique / privée à forcer / a> avec la technologie d'aujourd'hui.

    
réponse donnée Evan Kroske 08.06.2016 - 02:31
la source
67

Je suggère:

  • Utilisation de 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, ce qui compliquait l'attaque.

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

  • Limiter les utilisateurs pouvant accéder à SSH au serveur. Soit par groupe ou simplement par des utilisateurs spécifiques.

    Ajoutez AllowGroups group1 group2 ou AllowUsers user1 user2 pour limiter l'accès SSH au serveur.

réponse donnée Mark Davidson 08.06.2016 - 02:07
la source
22

D'autres réponses apportent une sécurité, mais il y a une chose que vous pouvez faire pour rendre vos journaux plus silencieux et réduire le risque que vous soyez exclu de votre compte:

Déplacez le serveur du port 22 vers 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.

    
réponse donnée Douglas Leeder 08.06.2016 - 02:15
la source
21

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 sur l’authentification par mot de passe comme dans une autre réponse, mais exige également que l’utilisateur prouve qu’il détient son périphérique secondaire en plus de sa clé privée.

Résumé:

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

  2. Chaque utilisateur doit exécuter la commande google-authenticator , qui génère ~/.google-authenticator et les aide à configurer leurs périphériques à deux facteurs (par exemple, l’application Android de Google Authenticator).

  3. Modifier /etc/ssh/sshd_config et définir:

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

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

    @include common-auth
    

    avec:

    auth required pam_google_authenticator.so
    

Plus de détails sur les différentes options de configuration sont mon article de l’année dernière: Meilleure authentification ssh à deux facteurs sur Ubuntu .

    
réponse donnée Robie Basak 23.05.2017 - 00:29
la source
19

Voici une chose facile à faire: installer ufw (le "pare-feu non compliqué") et l'utiliser pour évaluer les connexions entrantes.

À l’invite de commandes, tapez:

$ sudo ufw limit OpenSSH 

Si ufw n’est pas installé, faites-le et réessayez:

$ sudo aptitude install ufw 

De nombreux attaquants tenteront d’utiliser votre serveur SSH pour forcer les mots de passe. Cela ne permettra que 6 connexions toutes les 30 secondes à partir de la même adresse IP.

    
réponse donnée mpontillo 15.08.2010 - 00:45
la source
12

Si je souhaite renforcer la sécurité ou accéder aux serveurs SSH à l’intérieur d’un réseau d’entreprise, je mets en place un hidden service via le logiciel d'anonymisation Tor .

  1. Installez Tor et configurez le serveur SSH lui-même.
  2. Assurez-vous que sshd écoute uniquement localhost .
  3. Ouvrez /etc/tor/torrc . Définissez HiddenServiceDir /var/lib/tor/ssh et 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 des 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".

    
réponse donnée qbi 08.06.2016 - 02:10
la source
8

Il existe 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 l'article suivant: Assurer la sécurité de l'accès SSH .

    
réponse donnée Huygens 12.10.2010 - 00:35
la source
6

Mon approche du durcissement SSH est ... complexe. Les éléments suivants concernent la manière dont je le fais, depuis le bord le plus éloigné de mes réseaux jusqu'aux serveurs eux-mêmes.

  1. Filtrage au niveau de la frontière du trafic via IDS / IPS avec des scanneurs de services et des signatures connus dans la liste de blocage. J'y parviens avec Snort via mon pare-feu frontal (c'est mon approche appareil). Parfois, je ne peux pas le faire, comme avec mes VPSes.

  2. Filtrage du pare-feu / réseau du ou des ports SSH. Je n'autorise explicitement que certains systèmes à accéder à mes serveurs SSH. Cela se fait via un pare-feu pfSense à la limite de mon réseau ou les pare-feu de chaque serveur sont configurés explicitement. Il y a des cas où je ne peux pas le faire (ce qui n'est presque jamais le cas, sauf dans des environnements de test de stylo ou de test de sécurité privés où les pare-feu ne permettent pas de tester les choses).

  3. Conjointement avec mon pare-feu pfSense ou un pare-feu de frontière NAT sur le réseau interne et en le séparant d'Internet et des systèmes, Accès aux serveurs VPN uniquement . Donne le VPN dans mes réseaux pour accéder aux serveurs, car il n’existe pas de ports Internet. Cela ne fonctionne certainement pas pour tous mes VPS, mais en conjonction avec # 2, je peux avoir un VPS comme "passerelle" par VPNing sur ce serveur, puis autoriser les adresses IP aux autres cases. De cette façon, je sais exactement ce que peut ou ne peut pas SSH dans - ma boîte 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. Où # 3 n'est pas faisable, fail2ban, configuré pour bloquer après 4 tentatives infructueuses et bloquer les adresses IP pendant une heure ou plus est une protection décente contre les personnes qui attaquent constamment avec bruteforcing - juste bloquer automatiquement le pare-feu avec fail2ban et meh. Configurer fail2ban est un problème si ...

  5. Obfuscation du port en modifiant le port SSH. Cependant, ce n’est PAS une bonne idée 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ée et contestée dans de nombreux cas. Je l'ai fait en conjonction avec IDS / IPS et le filtrage de réseau, mais c'est toujours une très mauvaise chose à faire seul.

  6. Authentification à deux facteurs OBLIGATOIRE, via les solutions d'authentification à deux facteurs de Duo Security . Duo a été configuré sur mes serveurs SSH, de sorte que, même pour entrer, les invites 2FA se produisent et je dois confirmer chaque accès. (Ceci est la fonctionnalité utile ultime - parce que même si quelqu'un a ma phrase secrète ou entre par effraction, il ne peut pas dépasser les 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 lié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 cents pour sécuriser SSH. Ou, au moins, mes réflexions sur l’approche.

    
réponse donnée Thomas W. 10.06.2016 - 23:14
la source
1

Vous pourriez vouloir 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 comme un Yubikey, un eToken PASS ou un NG ou si vous avez de nombreux utilisateurs ou plusieurs serveurs, vous pouvez utiliser un backend d'authentification à deux facteurs opensource.

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

    
réponse donnée cornelinux 08.06.2016 - 02:12
la source
0

J'ai écrit un petit tutoriel sur ce sujet récemment. Fondamentalement, vous devez utiliser l'infrastructure à clé publique et mon tutoriel montre également comment utiliser l'authentification à deux facteurs pour encore plus de sécurité. Même si vous n'utilisez aucune de ces choses, il y a aussi quelques petites choses à propos de la sécurisation du serveur en supprimant les suites de chiffrement faibles et autres bases. lien

    
réponse donnée 01000101 19.05.2015 - 15:52
la source
0

Pour un grand nombre d’utilisateurs / de certificats, tenez compte de l’intégration LDAP. Les grandes organisations utilisent LDAP comme référentiel pour les informations d'identification et les certificats stockés sur les badges ou les fobs, que les certificats soient utilisés pour l'authentification ou la signature de courriers électroniques. 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 pour une gestion centralisée des informations d'identification. De cette façon, les centres d’aide peuvent avoir un guichet unique pour traiter de grandes populations.

Voici un lien vers l’intégration centOS: lien

    
réponse donnée weller1 29.04.2016 - 15:50
la source
0

Vous pouvez également bloquer en fonction du pays d’origine en utilisant la base de données geoIP.

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

Le script peut être trouvé ici: lien

Vous pouvez également lui ajouter des commandes iptables (que j'ai utilisées pour mes droplets) pour supprimer automatiquement tout le trafic en provenance / à destination de ces adresses IP.

    
réponse donnée Michael A Mike 10.08.2017 - 07:09
la source

Lire d'autres questions sur les étiquettes