Comment assurer (encore) la sécurité SSH ?

Effectuez autant de mesures d'atténuation que possible.

Votre objectif est de forcer une grande variété d'attaquants potentiels à dépenser plus d'efforts, de ressources, de temps d'ordinateur (et donc de facture d'électricité), et plus particulièrement d'heures-personnes "qualifiées" (rares ou rares, et donc précieuses). Aucune protection ne fonctionne contre toutes les menaces. Toutes les menaces ne peuvent pas être protégées tout en restant sur Internet.

Cependant, un grand nombre de menaces (script kiddies et attaquants peu qualifiés ou disposant de peu de ressources) peuvent être vaincues presque tout le temps en ayant une défense en profondeur - de nombreuses couches de sécurité solide et de qualité, dont chacune devrait - théoriquement - suffire à vaincre de nombreuses menaces par lui-même. Ainsi, lorsque les règles iptables de votre système laissent quelqu'un entrer par accident, l'authentification par certificat SSHD les empêche d'entrer. Lorsque votre service SSHD présente un défaut, votre VPN empêche quiconque de le voir. Lorsque votre VPN et votre SSHD ont un défaut en même temps, vos règles de pare-feu empêchent la plupart des adresses IP du monde de tenter de le faire, ne laissant que les locaux et les grands botnets pour essayer d'exploiter les vulnérabilités, que vous corrigez en tant que dès que possible.

Ainsi, je le répète, mettez autant d'atténuations à autant de niveaux que possible. Vous ne pouvez pas savoir à l'avance lesquels ont des vulnérabilités non découvertes et dans quel ordre celles-ci seront exploitées.

• Assurez-vous de n'autoriser que SSH v2

  • sshd_config

    • Protocole 2

• Restez patché

• Utilisez vos iptables pour autoriser UNIQUEMENT les adresses IP ou les plages que vous utilisez réellement

• Configurez votre SSH pour autoriser l'accès UNIQUEMENT par certificat, et non par nom d'utilisateur/mot de passe, conformément à la page d'aide SSH/OpenSSH/Configuration du site d'aide d'Ubuntu

  • sshd_config

    • PubkeyAuthentication oui

    • Authentification par mot de passe non

  • Si vous utilisez un répertoire personnel chiffré

    • AuthorizedKeysFile /etc/ssh/%u/authorized_keys

  • Sinon, le réglage normal des répertoires personnels peut fonctionner

    • AuthorizedKeysFile %h/.ssh/authorized_keys

    • Assurez-vous qu'il n'y a pas d'autorisations excessives.

      • chmod 700 ~/.ssh

      • chmod 600 ~/.ssh/authorized_keys

      • chmod aller-w ~

  • Et établissez un certificat aussi solide que possible. La génération de clés est couverte sur la page SSH/OpenSSH/Keys du site d'aide d'Ubuntu

    • Je commencerais avec une clé RSA de 4096 bits ou une clé ed25519 avec une phrase de passe longue et forte. Assurez-vous de le générer localement, saisissez une phrase de passe longue et forte lorsque vous y êtes invité, utilisez -o pour garantir le nouveau format de clé OpenSSH 6.5 et assurez-vous que le serveur ne dispose jamais que de la clé publique.

      • ssh-keygen -o -t ed25519 -f ~/.ssh/id_ed25519

      • ssh-keygen -o -b 4096 -t rsa -f ~/.ssh/id_rsa

      • Pour vérifier la longueur d'une clé existante, utilisez ssh-keygen -e -f mykeyfile

  • Si vous le pouvez, limitez les clés du fichier authorized_keys à une adresse IP spécifique ou à un ensemble de noms d'hôte

    • from="192.168.1.2" ssh-rsa ABCDE...012 [email protected]

    • from="*.test.test,!BadPC.test.test" ssh-ed25519ABCDE...012 [email protected]

  • Si vous êtes sur OpenSSH 6.8 ou supérieur, vous pouvez également restreindre les clés autorisées à certains types dans sshd_config

    • PubkeyAcceptedKeyTypes ssh-ed25519*,ssh-rsa*

• Utilisez fail2ban pour que les tentatives de force brute demandent plus d'efforts (c'est-à-dire les faire utiliser un botnet au lieu d'une seule machine, ou les faire prendre beaucoup de temps)

  • Configurer des certificats (clés) est préférable si vous demandez lequel faire en premier

• Réduisez votre temps de grâce de connexion

  • Si vous utilisez des certificats, vous avez la possibilité de le réduire VRAIMENT à moins que vous n'utilisiez des connexions très, très lentes

    • ConnexionGraceTime 8

  • Sinon, eh bien, à quelle vitesse tapez-vous ?

    • ConnexionGraceTime 20

• Contrôlez vos choix de suite de chiffrement avec les informations de Mozilla.org Security/Guidelines/OpenSSH

  • Puisqu'il s'agit de votre serveur et que vous êtes le seul à y accéder, vous pouvez sélectionner un groupement très, très serré, de sorte que seuls les clients les plus modernes soient autorisés. Peut-être

  • HostKey /etc/ssh/ssh_host_rsa_key

    • sudo ssh-keygen -o -N '' -b 4096 -t rsa -f /etc/ssh/ssh_host_rsa_key

      • ou

      • Clé d'hôte /etc/ssh/ssh_host_ed25519_key

      • sudo ssh-keygen -o -N '' -t ed25519 -f /etc/ssh/ssh_host_ed25519_key

    • correspond évidemment exactement à vos noms de fichiers HostKey !

      • ou les deux (le plus préféré en premier)

      • supprimez entièrement toutes les clés dsa ; ils sont fixés à un pathétique 1024 bits pour SSH

  • Utilisez les directives ssh -Q pour déterminer ce que votre système prend en charge pour les options de suite de chiffrement

  • KexAlgorithms [email protected]

  • Ciphers [email protected], [email protected], [email protected]

  • MAC [email protected]

  • Ou tout choix spécifique qui vous fait vous sentir le plus en sécurité

  • Et suivez la littérature; lorsqu'il y a un défaut dans quelque chose que vous avez choisi, choisissez quelque chose qui n'a pas de défauts connus à ce moment-là.

• Utilisez votre iptables (ou pare-feu) avec les listes de blocage de I-blocklist

• Utilisez votre iptables (ou votre pare-feu) avec des listes d'adresses IP géographiques ou basées sur les FAI ; l'une de ces sources de listes géographiques est maxmind.com

• Basculez vers un port dans la plage de ports dynamiques (éphémères) de 49152 à 65535 selon RFC6335

  • Et seulement lier aux adresses IP requises

• Bloquez tout autre port sur ce serveur via iptables ; il y a de fortes chances que vous soyez touché par BEAUCOUP d'attaques

  • Renforcez particulièrement votre base de données MySQL, le cas échéant - je vois BEAUCOUP d'attaques MySQL (et SQL Server) sur mon IDS, et je n'en ai jamais exécuté ni l'un ni l'autre. Définissez-les uniquement sur des adresses IP locales non routables, etc., des mots de passe longs, désactivez-les, etc.

  • Désactivez en particulier tous les serveurs Web, définissez-les uniquement sur des adresses IP locales et non routables, etc.

• Utilisez le port knocking selon le site d'aide d'Ubuntu ou un article de DigitalOcean

• Limiter le taux de nouvelles tentatives de connexion, selon cette réponse à la question ServerFault "Des centaines d'échecs de connexion ssh"

iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 5 --name SSH --rsource -j DROP

iptables -A INPUT -p tcp --dport 22 -m recent --set --name SSH --rsource -j ACCEPTER

• Envisagez d'utiliser chroot selon la documentation Debian "OpenSSH SFTP chroot() avec ChrootDirectory"

• Assurez-vous que rhosts est désactivé avec l'option sshd_config

  • IgnorerRhosts oui

  • Authentification RhostsRSA non

  • RhostsAuthentication non

• Ajouter plus de restrictions au processus non privilégié de pré-authentification

  • Utiliser le bac à sable PrivilegeSeparation

• Si vous n'utilisez pas le transfert ou le tunneling, désactivez-le dans sshd_config

  • X11Numéro de transfert

  • AllowTcpForwarding non

  • GatewayPorts non

  • PermisTunnel non

• Empêcher toute autre configuration non sécurisée dans les répertoires ou les autorisations

  • StrictModes oui

  • Et puis passez en revue vos autorisations et paramètres jusqu'à ce que cela fonctionne à nouveau :)

• Désactiver l'authentification basée sur l'hôte

  • HostbasedAuthentication non

• Notez que selon la réponse de This Serverfault à "Le démon OpenSSH ignore la directive ServerKeyBits", l'ancienne directive ServerKeyBits sshd_config n'est plus applicable, puisque vous n'autorisez pas SSH v1 en premier lieu.

• Ne pas autoriser la racine dans sshd_config

  • Numéro de connexion racine autorisée

• N'autorisez pas différents utilisateurs - peut-être des utilisateurs de services sur certains packages que vous installez - à avoir d'autres options

  • Non de PermitUserEnvironment

• Installez un pare-feu complet séparé comme pfSense ou Ubiquiti Edgerouter Lite entre cette machine et le monde extérieur.

  • Et puis utilisez le VPN intégré EN PLUS DE votre connexion SSH renforcée

  • Également avec des connexions basées sur des certificats, et non sur des connexions basées sur un nom d'utilisateur/mot de passe

  • Si vous utilisez OpenVPN

    • Assurez-vous d'utiliser également une clé pré-partagée --tls-auth "ta.key"

    • Et choisissez de meilleurs chiffrements que ceux par défaut

  • Et utilisez également les listes de blocage mentionnées ci-dessus à ce niveau

Comme DeerHunter l'a mentionné, la modification de ssh et/ou iptables et/ou d'autres paramètres de pare-feu sans autre moyen peut entraîner un manque de capacité à se connecter en SSH.

Voilà :

• Générer des clés SSH + les protéger avec un mot de passe
• Autoriser uniquement un utilisateur spécifique à se connecter (AllowUsers)
• Autoriser à partir d'une IP spécifique [email protected]
• Modifier le port par défaut
• Créer des règles de pare-feu
• et dernière chose, installez fail2ban.