Réponses:
La raison la plus probable est de rendre plus difficile pour les personnes essayant au hasard de forcer brutalement toute connexion SSH qu'ils peuvent trouver. Ma machine accessible sur Internet utilise le port SSH par défaut, et mes journaux étaient auparavant remplis de trucs comme celui-ci (extrait d'un fichier journal réel):
sshd[16359]: Invalid user test from 92.241.180.96
sshd[16428]: Invalid user oracle from 92.241.180.96
sshd[16496]: Invalid user backup from 92.241.180.96
sshd[16556]: Invalid user ftpuser from 92.241.180.96
sshd[16612]: Invalid user nagios from 92.241.180.96
sshd[16649]: Invalid user student from 92.241.180.96
sshd[16689]: Invalid user tomcat from 92.241.180.96
sshd[16713]: Invalid user test1 from 92.241.180.96
sshd[16742]: Invalid user test from 92.241.180.96
sshd[16746]: Invalid user cyrus from 92.241.180.96
sshd[16774]: Invalid user temp from 92.241.180.96
sshd[16790]: Invalid user postgres from 92.241.180.96
sshd[16806]: Invalid user samba from 92.241.180.96
Ces jours-ci, j'utilise DenyHosts pour bloquer les adresses IP qui ne s'authentifient pas trop souvent, mais il est probablement aussi simple de changer de port; pratiquement toutes les attaques par force brute de ce type ne gêneront pas la numérisation pour voir si votre sshd écoute sur un autre port, elles supposeront simplement que vous n'en exécutez pas et continuer
Non, c'est une sécurité par obscurité tactique de .
Si votre configuration sshd n'est pas assez adaptée pour faire face à des gamins de script stupides essayant uniquement le port 22, vous avez quand même un problème.
Une réaction plus rationnelle serait:
Certaines personnes peuvent également être ennuyées par le bruit que sshd écrit dans le journal système, par exemple:
Jan 02 21:24:24 example.org sshd[28396]: Invalid user guest from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28396]: input_userauth_request: invalid user guest [preauth]
Jan 02 21:24:24 example.org sshd[28396]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth]
Jan 02 21:24:24 example.org sshd[28398]: Invalid user ubnt from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28398]: input_userauth_request: invalid user ubnt [preauth]
Jan 02 21:24:24 example.org sshd[28398]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth
Il pourrait alors être tentant d'obscurcir le port sshd ou d'utiliser une solution de blocage automatique (comme DenyHosts, Fail2ban ou BlockHosts) afin d'augmenter le rapport signal / bruit nouveau le .
Mais de meilleures alternatives existent. Par exemple, vous pouvez configurer votre démon syslog de telle sorte que le bruit du journal sshd ne soit écrit que - disons - /var/log/sshd-attempts.loget que le signal (c'est-à-dire les messages de journal sshd restants) soit écrit sur /var/log/messagesetc. comme auparavant.
Le déploiement d'outils de blocage automatique doit être envisagé avec soin car ajouter plus de complexité aux systèmes liés à la sécurité signifie également augmenter le risque d' exploitation . Et en effet, au fil des ans, il existe plusieurs rapports de vulnérabilité DoS pour chaque DenyHosts , Fail2ban et BlockHosts .
Changer le port SSH est principalement un théâtre de sécurité . Cela vous donne un sentiment flou d'avoir fait quelque chose. Vous avez caché le port SSH sous le paillasson.
Si vous exécutez un serveur SSH sur Internet, vous verrez de nombreuses tentatives de connexion infructueuses dans vos journaux, à partir de robots qui recherchent des mots de passe stupidement faibles, des clés faibles et des exploits connus dans les anciennes versions du serveur. Les tentatives infructueuses ne sont que cela: échoué tentatives . En ce qui concerne l'évaluation de votre vulnérabilité, elles sont complètement hors de propos. Ce dont vous devez vous soucier, c'est des tentatives d'intrusion réussies, et vous ne les verrez pas dans vos journaux.
Changer le port par défaut réduira le nombre de hits de tels bots, mais cela ne déjouera que les attaquants les moins sophistiqués qui sont arrêtés par une sécurité décente (mises à jour de sécurité appliquées régulièrement, mots de passe raisonnablement forts ou authentification de mot de passe désactivée). Le seul avantage est de réduire le volume des journaux. Si c'est un problème, envisagez quelque chose comme Denyhosts ou Fail2ban pour limiter le débit de connexion à la place, cela fera également du bien à votre bande passante.
La modification du port par défaut présente un inconvénient majeur: elle vous rend moins susceptible de pouvoir vous connecter depuis un pare-feu. Les pare-feu sont plus susceptibles de laisser passer les services sur leur port par défaut que sur un autre port aléatoire. Si vous n'exécutez pas de serveur HTTPS, envisagez également d'écouter SSH sur le port 443 (ou redirigez les demandes TCP entrantes du port 443 vers le port 22), car certains pare-feu autorisent le trafic qu'ils ne peuvent pas décoder sur le port 443 car il semble comme HTTPS.