• # Quelques pistes

    Posté par (site web personnel) . En réponse au message Nombre de connexions SSH malveillantes à un serveur. Évalué à 10.

    • Utiliser des clés SSH revient à restreindre à des clés données, puisqu'elles doivent être déclarées explicitement (authorized_keys).
    • Désactiver les mots de passe est une très bonne idée (et en fonction des distributions/versions c'est le cas par défaut) mais ne change rien au bruit dans les logs.
    • Utiliser AllowUsers/AllowGroups peut être un bon complément (et à nouveau aucun impact sur le bruit dans les logs).
    • Changer le port de connexion peut limiter le bruit mais le bruteforce peut être tenté sur n'importe quel port...
    • Limiter l'accès au port du serveur SSH via le firewall peut être une option, mais cela peut être embêtant si on n'a pas d'IP fixe depuis laquelle se connecter.
    • Implémenter du port-knocking peut compléter le point précédent. Par exemple : depuis chez moi ou depuis les autres serveurs que j'administre, je peux me connecter en direct à certaines machines, mais si je suis « on the go », il faut envoyer la bonne séquence de paquets pour faire ouvrir le port SSH pour cette IP, de manière temporaire (attention aux limitations de certains réseaux, e.g. UDP vs. Wi-Fi TGV).
    • Enfin, ne pas exposer du tout le service SSH sur internet permet de s'épargner tout ce bruit. Cela peut être implémenté en le rendant accessible uniquement au travers d'un VPN, cf. modèle du fromage suisse.
    • Bonus : CrowdSec et son firewall bouncer permettent de bloquer des IPs en avance de phase (par rapport à fail2ban qui est uniquement réactif), grâce aux listes de blocage construites avec la communauté.

    Debian Consultant @ DEBAMAX