Session SSH piratée potentielle et meilleures pratiques SSH

Je panique un peu en ce moment. Je me connecte à un serveur distant que j'ai récemment mis en service. Je fais ça en tant que root. J'ai installé fail2ban et j'avais une quantité massive d'adresses IP interdites dans le journal.

La dernière fois que je me suis connecté, j'ai remarqué que mon terminal était vraiment lent, puis ma connexion Internet a diminué. Lorsque je l'ai racheté après environ 5 minutes, je me suis reconnecté au serveur et j'ai fait un «qui» et j'ai réalisé qu'il y avait deux utilisateurs root connectés. J'aurais pensé que si ma connexion était terminée, le processus de la dernière session aurait été arrêté sur le serveur?

La connexion s'est terminée par un "Echec de l'écriture: canal cassé" lorsque j'ai été déconnecté pour la première fois. J'ai tué la session bash avec l'autre racine. Je ne sais pas grand chose sur la sécurité ssh mais les sessions pourraient-elles être détournées? existe-t-il un moyen de vérifier cela? Je dois continuer à me connecter via ssh quelles précautions dois-je prendre? Si je passais par un proxy pour atteindre mon serveur (comme un homme au milieu de l'attaque), pourraient-ils détourner ma session ssh?

Les connexions root sont probablement des sessions shell suspendues qui étaient autrefois vous. Votre serveur reçoit également probablement dDOS avec toutes les tentatives de connexion.

Verrouillez SSH. N'autorisez pas la connexion root, et les demandes qui tentent de forcer brutalement cette machine échoueront immédiatement (en prenant beaucoup moins de ressources). Connectez-vous en tant qu'utilisateur normal et augmentez les autorisations via sudo, une pratique que vous devriez faire de toute façon. Limitez également la connexion SSH à une liste d'adresses IP clientes afin que les machines peu recommandables ne puissent même pas essayer de se connecter.

Utilisez des clés SSH au lieu de mots de passe pour la connexion utilisateur. Ils sont plus faciles à gérer et peuvent être protégés par un mot de passe au cas où vous donneriez accidentellement une clé privée au mauvais endroit (vous donnant le temps de les remplacer et d'invalider l'ancienne). Comme @EEAA l'a mentionné dans les commentaires, vous devez également désactiver l'authentification par mot de passe si vous souhaitez restreindre les clients à utiliser uniquement des clés au lieu des mots de passe et des clés.

Si les clans mongols continuent de battre votre mur de ville, déplacez peut-être SSH vers un autre port haut (sous 1024, comme l'a souligné @AustinBurke - afin d'utiliser un port privilégié) au lieu de 22. Cela réduira le trafic sur ce port si cela est un problème pour vous (et la plupart des bots ne sont pas très gracieux, ils ne tenteront donc que sur 22). Cela n'empêchera pas les choses d'essayer le port 22 ou même de scanner votre machine pour voir quel port écoute sur SSH, et dans la plupart des cas, c'est un inconvénient inutile. Mais cela peut aider.

D'autres pourraient être en mesure de fournir plus de conseils, mais ce sont des mesures de sécurité assez génériques pour un serveur SSH public.