Wiki Ubuntu et port d'écoute SSH

R136a1 · Le 20/11/2021, à 13:52

Salut
dans le wiki d'Ubuntu fr, il est écrit concernant le port SSH :
"Le changement du port par défaut , souvent conseillé, n'augmentera pas la sécurité. C'est même l'inverse si vous choisissez un port non privilégié, c'est à dire supérieur à 1024 "
https://doc.ubuntu-fr.org/ssh#configura … erveur_ssh

Cette affirmation, sans explication me laisse perplexe...
En quoi le fait de changer le port d'écoute de SSH pour un port au-delà des 1024 diminue la sécurité du serveur SSH ??

Dans le wiki d'Arch par exemple, qui n'est pas connu pour être olé olé, il est recommandé de mettre un port supérieur à 1024:
"If the server is to be exposed to the WAN, it is recommended to change the default port from 22 to a random higher one like this:
Port 39901"
(...)
"A port change from default port 22 will reduce the number of log entries caused by automated authentication attempts"

Si quelqu'un peut donc expliquer pourquoi la doc d'Ubuntu recommande le contraire.
Merci

Dernière modification par R136a1 (Le 20/11/2021, à 14:04)

bruno · Le 20/11/2021, à 14:34

Bonjour,

Je recopie ce que j'ai déjà écrit à plusieurs reprises :

bruno a écrit :

Pourquoi ne pas changer le port par défaut ?
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.

R136a1 · Le 20/11/2021, à 14:53

Salut
merci pour ta réponse, mais ça reste pas clair pour moi.

- "Sécurité par l'obscurité"? Les robots scannent les ports par défaut, donc je vois pas en quoi le fait de rester sur un port par défaut diminue les attaques par force brut, au contraire.

- "cela peut devenir un vrai casse-tête pour l’administrateur système"? Ben déjà, il me parait assez évident qu'un administrateur système ne va pas venir consulter la doc d'Ubuntu. Il connaît le fonctionnement d'un serveur SSH ou alors il n'a rien à faire en tant qu'admin système... Ce sont donc des utilisateurs lambda, sans connaissances approfondies, qui vont consulter ces doc. Aucune chance qu'ils aient un parc de 50 serveurs à administrer. Quand à un admin système, je pense qu'il n'est pas assez couillon pour mettre 50 ports d'écoute SSH différents, il va utiliser le même mais au-delà des 1024 premier.

-"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"? Les informations transitant par n'importe quel port SSH sont cryptées. Donc qu'est ce que ça peut faire s'il les intercepte? Par ailleurs, pour ça, il faut qu'il soit logé sur le serveur, donc qu'il ait accès à la machine. S'il est un utilisateur autorisé, je vois pas pourquoi il écouterait les ports du serveur, s'il n'est pas autorisé, la machine est compromise.

Je peux me tromper évidemment.
Merci pour tes précisions.

Dernière modification par R136a1 (Le 20/11/2021, à 14:54)

bruno · Le 20/11/2021, à 16:39

je vois pas en quoi le fait de rester sur un port par défaut diminue les attaques par force brut, au contraire.

Si le service est sensible aux attaques par force brute c'est qu'il est mal configuré. Changer le port par défaut n'y changera rien. Tu auras juste l'illusion d'avoir amélioré la sécurité parce que tu vois moins de tentatives dans les logs.

Ce sont donc des utilisateurs lambda, sans connaissances approfondies, qui vont consulter ces doc.

Raison de plus pour ne pas leur raconter d'âneries en recopiant bêtement de mauvais préceptes.
Un néophyte peut très bien avoir à utiliser un script ou un logiciel qui ne se connecte que sur le port par défaut.

Les informations transitant par n'importe quel port SSH sont cryptées. Donc qu'est ce que ça peut faire s'il les intercepte?

Elles sont chiffrées quand elles transitent sur le réseau.
L'utilisateur d'un tel script va pouvoir intercepter la totalité de la transaction en tant que MITM, voire en se faisant passer pour le serveur SSH. Les informations seront donc en clair pour lui : mots de passe, échange de clés, etc.
Il suffit d'un site web compromis et d'un serveur web pas super sécurisé pour qu'un tel utilisateur ait accès au serveur.

D'une manière générale il faut donner la priorité à la sécurisation du service lui-même. Pour un serveur SSH : mots de passe très forts ou identification uniquement par clés, restrictions d'accès par utilisateur, groupe, IP, etc. plutôt que d'appliquer des « recettes » (souvent infondées et toujours mal comprises) qui ne font que donner un faux sentiment de sécurité.

R136a1 · Le 20/11/2021, à 17:38

Okay, mais je trouve que tu pousses le bouchon en parlant "d'âneries en recopiant bêtement de mauvais préceptes" et de "recettes (souvent infondées et toujours mal comprises) qui ne font que donner un faux sentiment de sécurité."
Ou alors encore une fois, les documentations officielles de Red Hat, Arch, Suse etc et les blogs des admin système qui préconisent quasi tous de changer le port sont écrits par des idiots. je précise que ces documentations préconisent aussi l’utilisation de clés, les restrictions par groupe, IP etc comme tu dis. On peut très bien mettre tout ça en place en même temps.

Tu devrais relativiser tes propos. Surtout que la doc d'Ubuntu on ne précise pas par exemple clairement qu'il faut passer à no la valeur de "PermitRootLogin", ce qui me semble plus important que de conseiller de ne pas changer le port par défaut...

Enfin, merci d'avoir répondu à mes interrogation même si visiblement ça t'a gonflé.
A+

bruno · Le 20/11/2021, à 18:12

Cela ne m'a pas gonflé. Si c'était le cas je n'aurais pas répondu.

Attention de ne pas confondre les Wiki qui sont des documents collaboratifs modifiables par tout le monde et les documentations officielles. Ceux qui préconisent le changement de port ne sont pas forcément des idiots mais ils répètent une information largement répandue sans y avoir réellement réfléchi.
Tu trouveras aussi de nombreux blogs ou documentations qui disent la même chose que moi, des exemples pris au hasard : https://serverfault.com/questions/18928 … t-ssh-port ou https://security.stackexchange.com/ques … ux-servers

Surtout que la doc d'Ubuntu on ne précise pas par exemple clairement qu'il faut passer à no la valeur de "PermitRootLogin", ce qui me semble plus important que de conseiller de ne pas changer le port par défaut.

Non ce n'est pas plus important et c'est du même acabit que le changement de port. Il n'y a aucun problème de sécurité à se connecter directement en root à un serveur SSH du moment que ce n'est accessible que par clés (ou mot de passe très fort). C'est même pratiquement indispensable pour certaines tâches de maintenance automatisées.

R136a1 · Le 20/11/2021, à 19:39

Autant pour moi alors, j'ai mal interprété tes réponses.
Pour les wikis, oui je sais, c'est le cas d'Arch. Mais Red Hat et Suse, c'est bien dans les doc officielles.

En tout cas, l'échange m'a intéressé. J'ai appris quelques trucs. Par exemple, je ne savais pas que "Seul l’utilisateur root peut utiliser un port <1024." Ça change la donne...

Une dernière question. Tu ne penses pas que le fait de changer les ports par défaut, de SSH et OpenVPN par exemple (ce que j'ai fait sur mon serveur), rend "invisible" le serveur? Je veux dire que comme les robots scannent les ports inférieurs aux 1024 premiers, le fait qu'il n'y ait aucune réponse quand ils scannent mon serveur, le rend invisible, non? Sachant qu'il n'y a que ces deux services qui sont à l'écoutes. A contrario, même si SSH est sécurisé, le fait que le robot identifie SSH à l'écoute sur le port 22, ça donne déjà une indication, celle qu'il y a un serveur à cette adresse.

Et du coup, dans le cas d'un usage domestique du serveur, le rendre invisible en modifiant les ports par défaut, ça n'est pas intéressant? Puisque j'ai pas les contraintes d'un serveur ou d'un ensemble de serveur tournant dans une entreprise, contraintes qui sont les principaux arguments avancés dans tes liens pour ne pas changer de port. Même si c'est pas catégorique non plus, il y a aussi du positif avancé pour le changement de port.

Au final, je trouve que ton deuxième lien est le plus intéressant. il relativise en fonction de l'usage fait du serveur. Vous devriez peut être envisager d'ajouter un paragraphe dans le wiki reprenant les arguments en faveur et les arguments contre le changement de ports selon l'usage envisagé du serveur. Ça serait plus clair et ça éviterait que dans quelques temps un énième linuxien vienne poster un message s'étonnant du commentaire en défaveur du changement de port dans le wiki.

Dernière modification par R136a1 (Le 20/11/2021, à 20:07)

bruno · Le 21/11/2021, à 11:41

Effectivement dans la doc officielle de RedHat on peut lire :

Doc RedHat a écrit :

Changing the port reduces the exposure of the system to attacks based on automated network scanning and thus increase security through obscurity.

Traduction de mon cru :

Le changement de port rend le système moins exposé aux attaques basées sur l'analyse automatisée du réseau et augmente ainsi la sécurité par l'obscurité.

Je ne vais surtout pas le prendre comme un argument d'autorité parce que c'est RedHat.
La première partie de la phrase est a peu près exacte.
La seconde partie est quand me assez gonflée : la sécurité par l'obscurité ce n'est pas de la sécurité (même si certains affirment le contraire).
Et cette doc se garde bien d'aborder le problème de l'utilisation d'un port non privilégié.
L'utilisation d'un port non conventionnel rendra le service plus long à découvrir mais n'empêche en rien les attaques. Et surtout contrairement à ce que tu dis cela ne le rend pas « invisible ». C'est juste un tout petit peu plus long à trouver. Pour faire une analogie un peu foireuse c'est comme si tu déplaçais la porte d'entrée de ta maison de la façade principale vers une arrière-cour. Le cambrioleur devra faire le tour de la maison avant de trouver la serrure, cela va le retarder un peu mais ne l'empêchera pas de la crocheter si elle de mauvaise qualité.
Si je veux vraiment trouver tous les ports en écoute sur une machine il y a des tas d'outils pour cela, à commencer par nmap (avec des scripts qui peuvent donner pleins d'infos sur un service) où des services en ligne comme shodan.io.

Je crois que cette idée de changer le port par défaut du serveur SSH vient d'une interprétation naïve du constat que font tout ceux qui installent un tel service. Très rapidement les logs sont remplis de tentatives de connexion avec divers nom d'utilisateur, y compris root. Et là on se dit : « Mon dieu je vais être piraté ! »
Dans la réalité toutes ce tentatives sont absolument voués à l'échec sauf en cas de très grosse négligence : authentification avec un couple utilisateur/mot de passe connu ou mot de passe faible.
Et surtout on se croit protégé parce que ces lignes de logs ont disparu. Mais on a pas pris de vraies mesure de sécurité comme AllowUsers et on a oublié que l'on avait créé à des fin de test un utilisateur du genre test:test …
Certaines personnes ont monté de « Honeypots » SSH pour voir à quoi correspondait réellement ces tentatives. Je t'invite à faire une recherche sur honeypot ssh. Il s'avère que la quasi totalité des robots qui les lancent font une simple attaque par dictionnaire en utilisant des couples utilisateur /mot de passe bien connus. Tu serais surplis du nombre de machines, par exemple, publiquement accessibles avec pi:raspberry.

Pour résumer, si tu n'as pas conservé un utilisateur/mot de passe connu et si tu utilise un mot de passe fort, ou mieux l'identification exclusivement par clés, aucune attaque par dictionnaire ou par force brute ne peut aboutir. Et ça c'est vraiment de la sécurité : en utilisant une authentification forte on rend la probabilité de réussite d'une attaque quasiment nulle car elle nécessiterait des moyens phénoménaux. Par conséquent toutes ces lignes qui emplissent les logs SSH, on s'en fout complètement !

Bien entendu, chacun fait comme il veut et administre ses serveurs comme il l'entend.
À titre personnel avoir des serveurs qui sont en écoute sur un port non standard c'est chiant : playbook ansible, script de sauvegarde ou de maintenance à reparamétrer, éventuelles règles de pare-feu à modifier, utilisateurs de client SFTP à qui il faut expliquer qu'il faut changer le port sur leur logiciel, etc.
Et je ne connais aucun hébergeur professionnel qui s'amuse à proposer du SSH / SFTP sur un autre port que 22.

Je ne m'insurge pas contre le changement de port en tant que tel, je m'insurge contre le fait qu'il soit présenté comme une mesure de sécurité indispensable ou comme un pré-requis à la sécurisation du serveur SSH. Ça c'est entièrement faux et c'est idiot.

On peut distinguer l'usage d'un serveur accessible uniquement sur un réseau local de celui qui est accessible publiquement et se dire à juste titre que les impératifs de sécurité ne sont pas les mêmes. Cependant je conseille d'appliquer les mes préceptes dans les deux cas. On est jamais à l'abri d'un oubli qui fait que le serveur n'est plus isolé : une redirection de port que l'on a fait sur un routeur et que l'on a oublié, une machine sur un réseau privé IPv4 mais qui reçoit une Ipv6 publique, etc.

Pou finir, je ne crois pas que le WiKi soit l'endroit où développer ce genre de considérations. La page en question est déjà beaucoup trop étoffée et un peu mal organisée. Je pense que le WiKi devrai se contenter d'explication de base claire et concise et renvoyer aux pages de manuel ou autres documentations pour approfondir.

Dernière modification par bruno (Le 21/11/2021, à 11:51)

R136a1 · Le 21/11/2021, à 12:55

bruno a écrit :

L'utilisation d'un port non conventionnel rendra le service plus long à découvrir mais n'empêche en rien les attaques. Et surtout contrairement à ce que tu dis cela ne le rend pas « invisible ». C'est juste un tout petit peu plus long à trouver. Pour faire une analogie un peu foireuse c'est comme si tu déplaçais la porte d'entrée de ta maison de la façade principale vers une arrière-cour. Le cambrioleur devra faire le tour de la maison avant de trouver la serrure, cela va le retarder un peu mais ne l'empêchera pas de la crocheter si elle de mauvaise qualité.
Si je veux vraiment trouver tous les ports en écoute sur une machine il y a des tas d'outils pour cela, à commencer par nmap (avec des scripts qui peuvent donner pleins d'infos sur un service) où des services en ligne comme shodan.io.

Ah mais je suis tout à fait d'accord avec ce que tu dis. Mais tu conviendras aussi que les robots ne scannent pas les 65536 ports des ip quand ils balayent le net à la recherche d'une proie. Ils balayent les ports les plus connus comme le 22 pour ssh, le 1194 pour openvpn etc. Après, c'est évident que si un attaquant sait qu'il y a un serveur à tel ip et qu'il veut attaquer précisément ce serveur, ce n'est pas parce que les ports par défaut sont changés qu'il ne va pas découvrir les bon ports s'il prend son temps.
Mais pour un particulier, qui a une ip variable en plus, à moins d'être la cible d'un vengeur masqué qui connaît son nom de domaine, je me dis que changer de port ce n'est pas non plus une mauvaise idée. Je ne serai pas la cible par hasard d'un attaquant, il faudra qu'il m'ait dans le collimateur...

Sinon, quand je parlais d'un serveur domestique, je ne parlais pas d'un serveur lan, mais bien d'un serveur ouvert au wan qui n'est pas chez un professionnel mais chez un particulier. C'est mon cas, vu le faible nombre de personnes qui s'y connecte, je n'ai pas les contraintes que des admin système comme toi peuvent avoir en entreprise, ça ne me gène donc pas du tout de changer de port. Et je prends par ailleurs les mesures de base de renforcement de la sécurité comme l'usage de clés publies/privées.

Ok pour le Wiki, je peux comprendre ton point de vue.

Nuliel · Le 21/11/2021, à 13:51

Mais tu conviendras aussi que les robots ne scannent pas les 65536 ports des ip quand ils balayent le net à la recherche d'une proie. Ils balayent les ports les plus connus comme le 22 pour ssh, le 1194 pour openvpn etc.

Si seulement
Les informations suivantes sont tirées d'un article sur crowdsec:
Une ipv4 est scannée entre 300 et 1000 fois par jour.
En 1 mois une machine qui ne fait tourner aucun service public mais accessible sur internet: 22 675 ip différentes ont scanné des ports TCP, 5254 des ports UDP, et 186 pour de l'ICMP. Au final ça fait 49875 ports TCP différents scannés, et 8460 ports UDP différents scannés.

Dernière modification par Nuliel (Le 21/11/2021, à 13:51)

bruno · Le 21/11/2021, à 15:46

Merci pour ces chiffres.
Cela ne m'étonne pas du tout. Entre les différents bots qui tournent sur des machine vérolées, les scripts kiddies, le services comme Shodan (un exemple) ou Censys et même les agence gouvernementale comme l'ANSSI, cela fiat beaucoup de monde qui scanne les réseaux et pas seulement les ports bien connus

R136a1 · Le 21/11/2021, à 18:04

Nuliel a écrit :

Mais tu conviendras aussi que les robots ne scannent pas les 65536 ports des ip quand ils balayent le net à la recherche d'une proie. Ils balayent les ports les plus connus comme le 22 pour ssh, le 1194 pour openvpn etc.
Si seulement
Les informations suivantes sont tirées d'un article sur crowdsec:
Une ipv4 est scannée entre 300 et 1000 fois par jour.
En 1 mois une machine qui ne fait tourner aucun service public mais accessible sur internet: 22 675 ip différentes ont scanné des ports TCP, 5254 des ports UDP, et 186 pour de l'ICMP. Au final ça fait 49875 ports TCP différents scannés, et 8460 ports UDP différents scannés.

49875 ports TCP différents de scannés et 8460 ports UDP différents ? Tu es sûr que tu ne confonds pas avec le total des ports TCP et UDP de scannés? Et en plus, même ces chiffres ne veulent pas dire grand chose. 49875 ports TCP différents de scannés, ça ne donne pas la proportion par port. S'il y a quelques scannes par ports au delà des 1024, contre des dizaine de milliers par ports en dessous des 1024, ça fait le même total, mais la proportion en dessous et au-dessus des 1024 n'a juste rien à voir. Sinon, peux tu donner le lien vers l'article dont tu cites les chiffres? Je mets pas en doute ce que tu dis hein, mais ça ne correspond pas à mon expérience. Je parle du nombre de ports différents de scannés, pour le reste, les chiffres que tu donnes n'ont rien d'étonnant et personne n'a dit le contraire.

J'ai eu un VPS chez OVH jusqu'à il y a 2 ans, donc une IP fixe, psad ne m'a jamais donné de tels chiffres. Et pourtant les IP OVH sont visiblement connus et scannées à boulet rouge.
90% des ports qui étaient scannés étaient en dessous des 1024 premiers et ils se concentraient sur les ports les plus connus comme le 80, le 443, le 22 ou le 1194.
J'avais bien des ports au-delà des 1024 de scannés mais ils pouvaient se compter sur les doigts d'une main. C'était le plus souvent les ports 2222, 11940 etc. J'avais aussi un port dans les 49000 (me rappelle plus exactement le numéro) qui était souvent scanné sans que je sache pourquoi... Peut-être que les mecs ont fait des stats Alors donc oui, ça scannait énormément, plusieurs milliers de fois ces ports, mais le nombre de ports différents après les 1024 qui étaient scannés, n'étaient pas très nombreux.

Je n'ai pas installé psad sur mon serveur perso. Cet échange m'a donné envie de le faire. Je posterai ici le retour de psad status (le haut du rapport, celui qui indique les chiffres des scans par ports TCP et UDP).
On verra mais je peux déjà te dire que ça sera beaucoup moins violent que mon ancien VPS parce que j'ai une IP variable (et les mecs ils reviennent et reviennent dès qu'ils savent qu'il y a un serveur en ligne à une adresse, même en les blacklistant pour plusieurs jours) et qu'il n'est pas en ligne H24 ( je l'allume à la demande grâce au wol).

Dernière modification par R136a1 (Le 21/11/2021, à 18:40)

Nuliel · Le 21/11/2021, à 19:58

Je cite:

le bruit de fond d'internet, MISC 114 a écrit :

La machine était connectée quasi en direct puisque la box de l'opérateur était en mode pass-through / DMZ.
Durant la période d'observation (1 mois), 22 675 IP différentes ont scanné des ports TCP, 5 254 des ports UDP, et 186 IP ont envoyé des probes ICMP. Encore une fois, cette machine n'hébergeant rien, toutes ces requêtes étaient non sollicitées.
En ce qui concerne les ports, 49 875 ports TCP et 8 460 ports UDP différents ont été scannés.

Et après il y a un tableau indiquant les ports qui ont été le plus scanné, avec le nombre de scans par ports (genre le port 23 a été scanné 8000 fois).
Bien sûr les services les plus connus (ssh, ftp, http, https, smb, ...) se font scanner largement plus qu'un port perdu dans les 50 000
Forcément, le port 598 (pris au hasard) sera moins scanné que le port 22, néanmoins un serveur ssh se manifeste quand on essaie de s'y connecter (un netcat dessus permet de voir un truc comme "SSH-2.0-OpenSSH_X.Y ..."), le port en question ne restera pas secret très longtemps

J'ai aussi un vps chez ovh, le port 22 est scanné régulièrement, et il y a des tentatives de mot de passe régulières (m'en fout, j'ai désactivé l'authentification par mdp )

R136a1 · Le 23/11/2021, à 17:28

Bon ben ça ne sert à rien psad sur mon serveur, il est derrière un routeur avec pare-feu activé.
Les logs d'iptables analysés par psad ne concernent que le lan.

Tu peux l'installer sur ton VPS toi par contre. Tu verras que le top 20 des ports scannés concerne à 90% ceux inférieurs au 1024 premiers.
Bon, sur ceux...
A+

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 20/11/2021, à 13:52

Wiki Ubuntu et port d'écoute SSH

#2 Le 20/11/2021, à 14:34

Re : Wiki Ubuntu et port d'écoute SSH

#3 Le 20/11/2021, à 14:53

Re : Wiki Ubuntu et port d'écoute SSH

#4 Le 20/11/2021, à 16:39

Re : Wiki Ubuntu et port d'écoute SSH

#5 Le 20/11/2021, à 17:38

Re : Wiki Ubuntu et port d'écoute SSH

#6 Le 20/11/2021, à 18:12

Re : Wiki Ubuntu et port d'écoute SSH

#7 Le 20/11/2021, à 19:39

Re : Wiki Ubuntu et port d'écoute SSH

#8 Le 21/11/2021, à 11:41

Re : Wiki Ubuntu et port d'écoute SSH

#9 Le 21/11/2021, à 12:55

Re : Wiki Ubuntu et port d'écoute SSH

#10 Le 21/11/2021, à 13:51

Re : Wiki Ubuntu et port d'écoute SSH

#11 Le 21/11/2021, à 15:46

Re : Wiki Ubuntu et port d'écoute SSH

#12 Le 21/11/2021, à 18:04

Re : Wiki Ubuntu et port d'écoute SSH

#13 Le 21/11/2021, à 19:58

Re : Wiki Ubuntu et port d'écoute SSH

#14 Le 23/11/2021, à 17:28

Re : Wiki Ubuntu et port d'écoute SSH

Pied de page des forums