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
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:
assurez-vous que vos utilisateurs utilisent de bons mots de passe difficiles à deviner / force brute
désactivez l'authentification par mot de passe (au moins pour les comptes importants) et utilisez simplement l'authentification par clé publique
attention aux problèmes de sécurité ssh et aux mises à niveau
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 .
Je ne suis pas vraiment d'accord avec le fait que "c'est la sécurité par l'obscurité". Je pense que cette réponse est une erreur courante dans ce cas. @ Le raisonnement de Michael montre généralement une meilleure raison de l'avoir ailleurs. C'est surtout pour se débarrasser de toutes les attaques en bouteille scriptées. Cela ne signifie pas nécessairement que vous en avez peur ou que vous le considérez efficace contre un attaquant déterminé. Je sais que je ne me suis jamais inquiété de leur entrée. Mais toute la bûche était ennuyeuse.
xenoterracide
1
@xenoterracide: Si vous n'êtes préoccupé que par la lisibilité de vos fichiers journaux, il existe d'autres meilleures alternatives pour exclure le bruit au lieu de changer le port comme tactique d'obscurité, c'était la question. En ce qui concerne le blocage IP, qui ne faisait pas partie de la question: veuillez noter que l'ajout de plus de complexité aux systèmes liés à la sécurité signifie également une augmentation du risque d'exploitation. Considérez par exemple seclists.org/fulldisclosure/2007/Jun/121 ossec.net/main/attacking-log-analysis-tools . Oui, DenyHosts en a été affecté.
maxschlepzig
1
Il n'y a pas que la lisibilité à l'esprit. Un changement de port correctement documenté n'est pas une sécurité par obscurité.
xenoterracide
4
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.
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):
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
la source
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:
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 .
la source
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.
la source