Pourquoi changer le port ssh par défaut ?

La sécurité par l'obscurité s'est avérée inutile. En général, je configure l'accès ssh avec le port standard pour toutes les raisons mentionnées ci-dessus (problèmes de reconfiguration du client, problèmes de pare-feu et de proxy, etc.)

En outre, je désactive toujours l'authentification du login et du mot de passe de la racine et, en dernière étape, j'utilise fail2ban pour se débarrasser de ces messages gênants dans le syslog. Dans Debian/Ubuntu, c'est aussi simple que de taper aptitude install fail2ban . La configuration par défaut fonctionne assez bien, mais j'ai l'habitude d'ajuster certains paramètres pour être plus restrictif, avec une durée de bannissement plus longue (au moins un jour) et seulement 2 tentatives d'authentification échouées comme déclencheur du bannissement.

Je dirais que la chose contre laquelle vous vous protégez le plus en changeant le port SSH, ce sont les scans automatisés qui essaieront d'obtenir un accès en utilisant des noms d'utilisateur/mots de passe standard.

Si vous désactivez les connexions par mot de passe sur votre serveur (ce qui est fortement recommandé), il est totalement inutile de modifier le port SSH. En désactivant les connexions par mot de passe (et en exigeant une authentification par clé), vous supprimez la possibilité de tentatives de saisie de mot de passe par force brute, de sorte que vous ne gagnez rien à jouer avec les numéros de port.

Si vous continuez à autoriser l'authentification par mot de passe, vous vous exposez à la possibilité d'une tentative réussie de force brute ou - ce qui est plus courant, d'après mon expérience - à la compromission de votre mot de passe parce que vous l'avez tapé en utilisant un système doté d'un enregistreur de frappe.

Ce n'est pas une réponse, mais c'est trop long pour un commentaire, alors je vais faire ce CW.

J'ai réfléchi à cette question pendant un certain temps et je suis arrivé à la conclusion qu'il y a beaucoup de vérité dans ce que Juliano dit dans les commentaires à la réponse d'Alnitak. Néanmoins, je trouve qu'en exécutant SSH sur le port 22, il est beaucoup trop facile de lancer des attaques de toutes sortes contre lui.

Pour résoudre ce problème, je fais fonctionner mes serveurs SSH internes sur le port 22 et j'utilise le pare-feu pour transférer le port élevé vers le port 22 sur les machines cibles. Cela permet d'assurer une certaine sécurité par l'obscurité tout en conservant la sécurité d'un port bas, comme l'a souligné Juliano.

La sécurité par l'obscurité n'est pas un principe auquel je souscris normalement et il est souvent souligné qu'un simple balayage de port révélera le port cible, ce qui rend l'obscurité inutile. Pour résoudre ce problème, mes pare-feu (Smoothwall Express), au travail comme à la maison, utilisent un script appelé Guardian Active Response, qui est déclenché par les alertes Snort. D'après mes observations, je peux vous dire que lorsque vous touchez plus de trois ports différents à partir de la même source, vos paquets sont abandonnés jusqu'au délai de réinitialisation prédéfini. Il est donc assez difficile et extrêmement long d'effectuer un balayage des ports, ce qui fait que l'obscurité vaut vraiment la peine. Cela m'a d'ailleurs valu d'être exclu si souvent par le passé que j'ai mis en place une exclusion pour mon adresse IP source (maison ou bureau). Bien sûr, un attaquant peut tomber sur le bon port la première fois, mais il y a peu de chances que ce soit le cas.

Bien que cela ressemble à une "sécurité par l'obscurité" typique, j'estimerais que cela a du sens puisque scanner tous les ports possibles (~ 64k) est beaucoup plus coûteux en temps qu'un seul d'entre eux.

Mais je peux ajouter que "port knocking" est bien meilleur.