Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Faut-il changer le port par défaut du serveur SSH ?

Vobul

Si c'est un serveur dont on parle, il est fortement conseillé de changer le port pour le service ssh ! 😉

--
Modération : Discussion scindée du fil https://forum.ubuntu-fr.org/viewtopic.php?id=2055679

bruno

Vobul a écritSi c'est un serveur dont on parle, il est fortement conseillé de changer le port pour le service ssh ! 😉

Non.

bruno a écrit Changer le port d’écoute SSH est une mauvaise idée.
La première raison est assez évidente : il s’agit de sécurité par l’obscurité. Cela peut ralentir un attaquant et éviter les robots qui font de l’attaque par force brute, mais on pourra toujours trouver sur quel port ce service est en écoute.

La seconde raison est que cela peut devenir un vrai casse-tête pour l’administrateur système. Il va lui falloir penser à préciser le numéro de port pour chacune de ses commandes et de ses scripts. S’il a 50 serveurs avec des ports différents à chaque fois, cela ne va pas être simple. Il peut également arriver d’avoir à utiliser des applications qui ne peuvent se connecter que sur le port standard.

La troisième raison est que l’utilisation d’un port non privilégié diminue la sécurité. En effet, n’importe quel utilisateur peut écrire un script qui écoute sur un port non privilégié et ainsi capturer les informations qui transitent par ce port. Seul l’utilisateur root peut utiliser un port <1024.

Vobul

Bruno, je ne suis pas du tout d'accord avec ta vision des choses.

La première raison est assez évidente : il s’agit de sécurité par l’obscurité.

Et cela n'est un problème que si c'est l'unique rempart. Mais si ça vient s'ajouter à une config solide, c'est du bonus. Et puis ça permet d'avoir des logs d'authentication non pollués par 36000 bots.

Il y a énormément de bots qui viennent taper le port 22. Et oui on pourra toujours trouver le port d'écoute, mais ça nécessitera un scan plus approfondi.

La seconde raison est que cela peut devenir un vrai casse-tête pour l’administrateur système. Il va lui falloir penser à préciser le numéro de port pour chacune de ses commandes et de ses scripts.

Nan mais 3615 j'me marre là. Déjà si il a 50 serveurs il utilise ansible, chef ou salt et chaque serveur peut avoir un port différent si ça lui chante puisque tout est dans des fichiers de config. Ensuite, même pour un serveur, t'as déjà entendu parler de ~./ssh/config ? Non parce que tu peux spécifier le port là-dedans hein.

Il peut également arriver d’avoir à utiliser des applications qui ne peuvent se connecter que sur le port standard.

Comme ? Si une application utilise SSH mais ne permet pas de spécifier le port, c'est pas une application, c'est de la merde en boîte.

Seul l’utilisateur root peut utiliser un port <1024.

Là on est d'accord, il est préférable d'utiliser un port privilégié, juste pas le 22. C'est la base.

Je peux comprendre tes arguments pour un serveur dans un réseau interne, mais pour un truc sur le web c'est juste con de pas changer le port. Ou alors faut bien configurer les logs parce que va y'en avoir du monde qui va tenter de se logger....

Après si tu veux vraiment parler sécurité et ssh faut aller plus loin dans la conf, il suffit pas de changer le port.

Utiliser des clés ed25519, interdire les mots de passe, whitelister des utilisateurs, interdire X11 forwarding, changer la liste des algos pour le key exchange et MAC, désactiver AgentForwarding et autres détails.

bruno

Tu administres tes serveurs comme tu veux et tu peux trouver que le changement du port par défaut et pratique et efficient.

Le problème c'est de présenter ce changement de port comme un prérequis indispensable à la sécurisation de SSH. C'est complètement faux et tu le reconnais toi même entre les lignes à la fin de ta réponse. La seule utilité serait de diminuer la quantité des logs, mais ce n'est franchement pas un problème d'avoir des centaine ou des milliers de tentatives quotidiennes enregistrés.

Quels que soient les outils d'administration utilisés, ansible, puppet, scripts maison, etc. il va falloir ajuster les configuration pour chaque serveur et préciser le numéro de port. C'est donc une complication inutile et une source d'erreurs supplémentaire.

La plupart des applications clientes permettent effectivement de spécifier le port utilisé. Mais c'est encore une complication inutile et une source d'erreur. Si tu dois donner un accès SSH ou SFTP à diverses personnes (webmasters, clients sur un hébergement mutualisés, etc.) il va falloir leur expliquer comment configurer les divers logiciels qu'il pourraient utiliser pour changer le port.

Tu es d'accord que le fait d'utiliser un port non privilégié diminue la sécurité, mais c'est ce que la grande majorité des gens font, classiquement avec 2222.
Maintenant quel port inférieur à 1024 choisir pour être sûr de ne pas contrevenir aux standards (cf. /etc/services) et de ne pas entrer en conflit avec un autre service qui sera installé par la suite ?

Pour finir ce que tu qualifies d' « autres détails » sont les mesures de sécurité à prendre et à préconiser avant toute chose : connexion exclusivement par clé pour les utilisateurs privilégiés, chroot pour les autres, etc. Le changement de port non seulement ne suffit pas mais il n'est pas nécessaire. Au pire cela ne fait que donner un faux sentiment de sécurité et on oublie de s'attaquer aux vrais paramètres de sécurité.

HP

bruno a écritTu es d'accord que le fait d'utiliser un port non privilégié diminue la sécurité, mais c'est ce que la grande majorité des gens font, classiquement avec 2222.
Maintenant quel port inférieur à 1024 choisir pour être sûr de ne pas contrevenir aux standards (cf. /etc/services) et de ne pas entrer en conflit avec un autre service qui sera installé par la suite ?

curl 'https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=1' | html2text | grep -Ei '\s+(udp|[0-9]+)\s+Unassigned'

               4       udp   Unassigned
               6       udp   Unassigned
               8       udp   Unassigned
               10      udp   Unassigned
               12      udp   Unassigned
               14      udp   Unassigned
               15      udp   Unassigned
               16      udp   Unassigned
               26      udp   Unassigned
               28      udp   Unassigned
               30      udp   Unassigned
               32      udp   Unassigned
               34      udp   Unassigned
               36      udp   Unassigned
               40      udp   Unassigned

15 résultats rien que sur la première page…

Vobul

Je suis tombé là-dessus par hasard : https://www.tronyxworld.be/2020/hardening_ssh/

À noter qu'il change le port ;p

bruno

Des articles de blogs comme celui que tu cites, il y en a des dizaines sur le web. Ce n'est pas un argument technique valable.

L’article propose des choix sans jamais les justifier. Et on peut facilement les contester :
- Refuser les login depuis le root.
⇒ cela n’améliore pas la sécurité si un utilisateur pouvant élever ses privilèges avec sudo peut se connecter. Et cela va singulièrement compliquer les tâches de maintenance automatisées à distance, notamment les sauvegardes.
- Refuser l’identification par mot de passe.
⇒ comment mes utilisateurs SFTP vont-il se connecter ? Je vais devoir leur fournir des clés et leur expliquer comment les utiliser avec leurs divers clients FTP…
- N’accepter QUE l’authentification par clé.
⇒ oui mais uniquement pour les utilisateurs autorisés à faire du SSH et qui ne sont pas chrootés.
- Changer le port par défaut du SSH.
⇒ en écoute sur le port 61022, ce qui diminue donc la sécurité (déjà expliqué).
- On force l’usage du protocole niveau 2.
⇒ oui, bon, c'est la valeur par défaut depuis longtemps…
- On retire le support ECDSA & RSA.
⇒ cela mériterait une longue explication. Effectivement si possible il vaut mieux utiliser ED25519 pour des raisons de sécurité mais surtout de rapidité et de taille de clé. RSA avec une taille de clé suffisante reste jusqu'à présent fiable. ECDSA est écarté pour des raisons politiques et techniques.
- Déclaration des utilisateurs systèmes pouvant se connecter via AllowUsers.
⇒ et un seul utilisateur déclaré, donc un seul administrateur qui à un accès SSH et pas de SFTP. C'est un cas d'usage extrêmement basique qui ne reflète pas la réalité de serveurs en production.

D'autre part la sécurité ne consiste pas à chercher à obtenir la meilleure note possible sur un service comme ssh-audit ou ssllabs. Ces services fournissent des informations intéressantes mais obtenir un A+ ne doit pas être un but en soi. En blindant à ce point la sécurité des échanges chiffrés on va généralement exclure les clients qui utilisent des logiciels un peu anciens et ne prennent donc pas en charge les algorithmes imposés : la sécurité est toujours un compromis.
D'autant que la cryptographie et les algorithmes de chiffrement sont des sujets complexes et mouvants : ce qui est blindé aujourd'hui ne le sera plus demain. De bonnes sources pour le blindage (hardening) des service avec chiffrement sont :
- pour SSH https://infosec.mozilla.org/guidelines/openssh
- pour d'autres services web, courriel https://ssl-config.mozilla.org/
- pour le web https://www.ssllabs.com qui a l'avantage de montrer les clients incompatibles.

Pour résumer sur la sécurisation d'un serveur SSH :
- le changement de port est, AMHA, inutile voire contre-productif en diminuant la sécurité et en compliquant l'administration du serveur ;
- si root est autorisé à se connecter il ne peut le faire qu'avec des clés solides, idéalement ed25519, sinon rsa 4096 bits ;
- si des utilisateurs sont autorisés à se connecter par mot de passe, ceux-ci doivent être extrêmement solides et fail2ban doit être configuré pour bloquer au bout de quelques tentatives ;
- si des utilisateurs ont un accès, celui-ci doit être restreint à l'aide de directives AlllowUser, AllowGroup, avec ChrootDirectory et ForceCommand (lire le man de sshd_config)
- le blindage des échanges chiffrés ne se fait qu'en dernier recours en tenant compte des capacités des clients, ou autres serveurs, susceptibles de se connecter au serveur.

Un exemple pour illustrer :

Port 22
#AddressFamily any
ListenAddress 0.0.0.0
ListenAddress ::

HostKey /etc/ssh/ssh_host_ed25519_key

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication
LoginGraceTime 2m
PermitRootLogin prohibit-password
StrictModes yes
MaxAuthTries 3
MaxSessions 5

PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys2

IgnoreRhosts yes

ChallengeResponseAuthentication no

UsePAM yes

AllowAgentForwarding no
#AllowTcpForwarding yes

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem       sftp    /usr/lib/openssh/sftp-server

AllowGroups sftpusers root

Match group sftpusers
        PasswordAuthentication yes
        ChrootDirectory %h
        AllowTcpForwarding no
        ForceCommand internal-sftp

Seul root peut se connecter en SSH et uniquement par clé. Les utilisateurs membres du groupe sftpusers peuvent faire du SFTP en se connectant par mot de passe et sont bloqués (chroot) dans leur dossier personnel.

Vobul

@bruno, je ne suis pas d'accord avec tout ce que tu dis, mais certains points sont justes 🙂

mazarini

J'avais l'habitude de changer le port ssh, jusqu’à ce que je me rende compte qu'un scan me donnait le port en question.

J'aime bien utiliser des groupes pour les autorisations. C'est assez facile à gérer pour moi qui ne suis pas un expert.

bruno

mazarini a écritJ'avais l'habitude de changer le port ssh, jusqu’à ce que je me rende compte qu'un scan me donnait le port en question.

Toutafé.
Et si on ne veut pas s'embêter avec un scan, on utilise un service comme shodan.io qui donne tout un tas d'infos 😉

Changer le port par défaut cela peut au mieux ralentir légèrement un attaquant déterminé, les robots qui font du brute force on s'en moque puisque c'est authentification par clé ou mots de passe costaud + fail2ban, au pire cela diminue la sécurité (port > 1024) et complique l'administration système. Bref jusqu'à ce que l'on me prouve le contraire cela n'améliore en rien la sécurité et c'est même contre-productif.

kedjo

Bonjour à tous.
Je comprends @bruno, et j'essaierai d'appliquer ses conseils.
Un scan permet de retrouver le nouveau port: à quoi bon de changer à fois? Même après changement de port il y a toujours de tentatives de connexion via le nouveau port: c'est ce qui m'était déjà arrivé... Et je me suis posé la question à quoi servait de changer de port

LeoMajor

bonjour,
Changer de port n'a strictement rien à voir avec la sécurité.
tu prends apache sur un port exotique. Quel est le rapport avec la sécurité ? aucun. ssh. idem. cqfd.
Statistiquement, il y a moins de requêtes, et de facto moins de requêtes indésirables (bots de bas niveau). Pas de log surchargé, noir, et inutile.
Par ailleurs, le ssh, pierre angulaire des admins, n'est pas considéré comme un service grand public, mais plutôt un service confidentiel et fermé (c.a.d réservé).
Après les admins qui gèrent le ssh comme si il s'agissait d'un service grand public, ou qui se foutent d'avoir des logs volumineux, ils font ce qu'ils veulent ...

Vobul

bruno a écrit Changer le port d’écoute SSH est une mauvaise idée.
La première raison est assez évidente : il s’agit de sécurité par l’obscurité.

@bruno: un article qui décrit pourquoi ce n'est pas de la "sécurité par l'obscurité" comme tu lu proclames :
https://danielmiessler.com/blog/no-moving-your-ssh-port-isnt-security-by-obscurity/

Pour info le mec qui écrit l'article sait de quoi il parle.

bruno

Vobul a écrit @bruno: un article qui décrit pourquoi ce n'est pas de la "sécurité par l'obscurité" comme tu lu proclames :
https://danielmiessler.com/blog/no-moving-your-ssh-port-isnt-security-by-obscurity/

Je connais, il en a écrit toute une série là-dessus et c'est intéressant bien que je ne soit pas d'accord avec lui. Relis ses articles il dit bien que la sécurité par l’obscurité est une mauvaise pratique.
Tout son argumentaire sur l'intérêt de la sécurité avec de l’obscurité tient à cette équation qu'il balance comme une vérité absolue :

risk = probability X impact

en prétendant que « cacher » des choses va diminuer la probabilité et donc le risque. Le problème c'est qu'il confond la probabilité d'une tentative d'attaque vouée à l’échec et celle d'une attaque couronnée de succès. Ce qui détermine la probabilité d'un accès frauduleux à un service ce n'est pas qu'il soit plus ou moins caché mais la bonne configuration du service et la présence de failles dans le logiciel utilisé.
On peut aussi avoir des situations où la probabilité et l'impact semblent faibles (typiquement un site web) mais où le risque est finalement très grand à cause de services mal configurés.
Je cite https://danielmiessler.com/study/security-by-obscurity/ :

Obscurity can be extremely valuable when added to actual security as an additional way to lower the chances of a successful attack,…

Traduction de mon cru :

L'obscurité peut être précieuse lorsqu'elle s'ajoute à la véritable sécurité comme un moyen supplémentaire de diminuer les chances d'une attaque réussie…

Ce n'est pas complètement faux mais on voit bien qu'il s’emmêle les pinceaux dans son discours :
- l'obscurité n'est pas de la véritable sécurité, la sécurité par l’obscurité c'est mal, nous sommes d'accord.
- l’obscurité peut-elle diminuer la probabilité d'une attaque réussie ? Évidemment non comme expliqué plus haut sauf si l'on compte sur le manque de détermination de l'attaquant (et ça ce n'est pas de la sécurité du tout!).

Certes en changeant le port SSH on va pratiquement éliminer toutes les attaques par force brute des bot ou script kiddies. Mais ces attaques là, on s'en moque parce que l'on a correctement configuré le service et elles vont forcément échouer.

Pour faire une analogie un peu moins foireuse que les siennes, je dirais que tu peux planquer une porte à l'arrière de ta maison mais il suffira d'en faire le tour pour la trouver. Ce n'est pas de la sécurité, tu vas juste éviter les cambrioleurs pressées et stupides. Il vaut mieux commencer par installer une porte blindée avec une serrure impossible à crocheter même si elle est bien visible.

Après si en plus tu veux changer le port par défaut pour un autre port privilégié, libre à toi. Ce sont tes machines tu les administres comme tu veux.
Mais j'ai déjà expliqué tous les problèmes de maintenance et complications inutiles que cela peut engendrer.

Par contre il faut éviter de balancer de but en blanc qu'il faut absolument changer le port par défaut du service SSH. Il faut d'abord leur expliquer comment sécuriser le service : mot de passe fort, identification par clés de préférence, filtrage par utilisateur, groupe, IP, etc.

Vobul a écrit Pour info le mec qui écrit l'article sait de quoi il parle.

C'est dommage d'avoir ajouté cet argument d'autorité tout à fait inutile….

Vobul

bruno a écrit C'est dommage d'avoir ajouté cet argument d'autorité tout à fait inutile….

Tu as raison. Sur le reste aussi, désormais j'éviterai de conseiller un changement de port sans en expliquer les raisons 😉