Bonjour à tous,
Je fais face à un problème étrange et j'aimerai avoir vos avis, ou à défaut partager mon désarrois.
J'ai un serveur à la maison, derrière une box ADSL Bouygues. Cette box fait du NAT pour rendre accessible en SSH mon serveur. Vu depuis Internet, SSH écoute sur le port 80 (pourquoi j'utilise ce port a été abordé il y a longtemps sur LinuxFR).
Je me suis rendu compte que si j'essaye de me connecter en utilisant le partage de connexion de mon téléphone chez SFR, la connexion SSH débute mais ne s’établit jamais. En utilisant le partage de connexion de mon autre téléphone chez Free, ou juste en changeant de port sur la box, ça passe.
Quelques informations plus techniques qui parleront peut-être :
- il n'y pas de pare-feu sur le serveur
- quand ça ne marche pas, le client SSH en mode verbeux écrit la ligne
debug1: expecting SSH2_MSG_KEX_ECDH_REPLYpuis attend sans fin - en comparant les logs du client SSH quand ça marche et quand ça ne marche pas, tout est identique, hormis le fait que le client reçoit une réponse et que l'établissement de la connexion peut se poursuivre
- côté serveur, en faisant une comparaison manuelle des captures tcpdump/wireshark, la différence commence au 9ème paquet échangé :
- dans le cas où ça ne fonctionne pas, c'est un bête ACK TCP envoyé par le client
- dans le cas où ça fonctionne, l'ACK TCP contient une charge utile, à savoir une liste d’algorithmes pour l'échange de clés (déjà mentionnés dans le 8ème paquet envoyé par le serveur)
D'où les questions :
- avez-vous déjà rencontré ce problème, et dans quelles circonstances ?
- peut-on mettre en cause SFR, ou est-il bien plus probable que j'ai fait une erreur dans mes configurations ?
# plusieur piste
Posté par ChocolatineFlying . Évalué à 2.
il est possible que tu ai 2 version différente de ssh (j'en doute mais bon :/ )
la version sur ton téléphone ne supporte pas la clé de ton serveur. ou les option de chiffrement de ton telephone sfr ne supporte pas cette clé
complotiste : sfr supprime des packets sur les connection ssh sur le port 80
ave telnet ca passe ? :O
[^] # Re: plusieur piste
Posté par YvanM (site web personnel) . Évalué à 1.
J'utilise bien toujours mon ordinateur comme client, je change de téléphone simplement pour la connexion Internet.
Un complot non, une bizarrerie peut-être plus…
Pas essayé :-)
# 80?
Posté par GG (site web personnel) . Évalué à 6.
Pourquoi tu fais écouter ton serveur SSH sur le port 80?
C'est prendre le risque qu'il y ait de l'inspection de paquets…
Avec le port 443, c'est prendre moins de risques.
Enfin, Bouygues ou SFR, c'est déjà prendre le risque que quelque chose sera forcément filtré. (idem pour Orange)
Il est très probable que ce soit le fait de passer par un partage de connexion via smartphone, et selon l'emplacement, les antennes disponibles et les contraintes réseaux de l'opérateur, ça coince. En effet, dans certains cas il y a des trucs crades qui sont fait par l'opérateur, du CG-Nat par exemple. Et, ça concerne tous les opérateurs.
https://fr.wikipedia.org/wiki/Carrier-grade_NAT
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: 80?
Posté par wismerhill . Évalué à 4.
Non, quel que soit le port utilisé, ssh parle le ssh, et donc sera forcément crypté, le choix du port n'a pas d'incidence sur le risque (mis à part que le port standard est une cible plus évidente).
Le seul problème potentiel (qui me vienne à l'esprit) à détourner un port bien établi, tout particulièrement celui de http(s), c'est qu'il pourrait y avoir dans le chemin quelque chose qui décide que si ce qui passe sur le port 80 ne ressemble pas à du trafic http, alors il le bloque (possible aussi pour le port 443, à l'établissement de la connexion).
[^] # Re: 80?
Posté par aiolos . Évalué à 9.
Moi j'aurais dit chiffré ;)
Je pense aussi qu'il peut y avoir sur le chemin, chez ton opérateur mobile puisque visiblement c'est que chez lui que ça plante, un firewall ou un IDS un peu zélé qui décide que le paquet n'est pas du HTTP(S)…
Mais dans ce cas, est-ce qu'on ne rentre pas dans la catégorie précédente ? :
[^] # Re: 80?
Posté par YvanM (site web personnel) . Évalué à 2.
Effectivement, ça se tiendrait…
[^] # Re: 80?
Posté par fearan . Évalué à 8. Dernière modification le 02 mai 2023 à 20:02.
le vpn de ma boite fonctionne chez free, mais avec d'autre opérateurs ça bloque.
Je subodore ces dernier de ne pas vendre internet, mais juste une sous partie. Le filtrage sur port 80 est probablement là pour éviter les petits malin qui tenteraient de passer outre. L'avantage d'utiliser le 443, c'est que c'est du web chiffré (https) et donc ya de forte chances que l'opérateur laisse passer. Dans le temps j'avais fais la même avec corkscrew pour passer le firewall de la boite (pas la même boite boite) ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: 80?
Posté par YvanM (site web personnel) . Évalué à 2.
Question peut-être bête, mais pourquoi les pare-feux qui font de l'inspection de paquet regarderaient plus le port 80 que les autres ?
Je n'arrive pas à imaginer un scénario où le début de la connexion fonctionne mais pas la suite, sachant que je viens de vérifier sur la capture Wireshark, il n'y a pas de changement de port quand ça fonctionne. Est-ce que tu as une idée ?
[^] # Re: 80?
Posté par ted (site web personnel) . Évalué à 8.
Le port 80 c'est pour du http, non chiffré donc facile à analyser. Si ils voient que ce qui passe ne ressemble pas à du traffic http ils peuvent donc le bloquer.
Le port 443 c'est pour du https, donc a priori les FAI ne peuvent pas facilement analyser le contenu, et surtout ils ne s'attendent pas à pouvoir l'analyser. Donc faire passer un autre protocole chiffré sur ce port est moins suspect.
Si on utilise un port au hasard, il y a malheureusement des chances qu'un FAI zélé ou autre réseau d'entreprise bloque le flux (il y a plus de 65000 ports, mais on peut en utiliser qu'une dizaine -_-, et pas le 22)
Personnellement j'utilise le port 993 et ça passe bien: c'est le port du protocole IMAP sur TLS.
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: 80?
Posté par gUI (Mastodon) . Évalué à 10. Dernière modification le 03 mai 2023 à 08:16.
Juste pour recadrer 2-3 trucs au passage :
Ces ports "c'est pour" ce qu'on veut. Le HTTP et HTTPS sur 80 et 443 c'est l'us-et-coutume, les ports par défauts, mais aucune loi/RFC n'oblige à utiliser ces protocoles sur ces ports.
Ça n'a rien de "suspect", il n'y a rien de mal à faire transiter du SSH sur un port 443.
Comme disait le poète : "Chacun fait fait fait c'qui lui plait plait plait"
C'était juste pour vraiment insister sur le fait que le FAI s'occupe de ce qui ne le regarde pas, il n'a pas à filtrer quoi que ce soit, sur quel port que ce soit. Attention donc aux phrases qui sous-entendent qu'on fait ce qu'on ne devrait pas : c'est bien le FAI qui est dans l'erreur.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: 80?
Posté par ted (site web personnel) . Évalué à 6. Dernière modification le 03 mai 2023 à 09:24.
Oui je me suis mal exprimé, en aucun cas je ne voulais faire penser que ce que font certains opérateurs est bien. C'est même contre productif, maintenant quand on héberge plusieurs services il faut penser à mettre en place un reverse-proxy pour que tout passe par des ports "standards" et que ça marche de partout.
Je viens de voir que l'Arcep a une application pour vérifier la neutralité d'un réseau: Wehe. D'après les résultats publiés, SFR ne briderait pas le trafic chiffré sur le port 80. Ça serait peut être intéressant qu'YvanM teste cette application pour avoir plus de détails (elle ne semble pas libre).
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: 80?
Posté par gUI (Mastodon) . Évalué à 5.
Oui je me doutais bien, moi-même parfois j'ai tendance à en parler comme ça. Mais c'est vraiment à nous (les érudits, les sachants… les moules quoi) de nous discipliner pour maintenir un Internet ouvert et libre, au moins dans les esprits sinon dans les faits.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: 80?
Posté par YvanM (site web personnel) . Évalué à 4.
J'ai installé l'application Wehe que je ne connaissais pas (libre, elle est sur F-Droid). Effectivement, le test de débit échoue totalement sur le port 80. Si je comprends bien l'appli essaye de transmettre du HTTPS sur ce port, pour comparer le débit avec le même transfert mais sur le port 443.
Comme suggéré dans l'application, je viens de faire un signalement à l'ARCEP.
[^] # Re: 80?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
« [C]'est bien le FAI qui est dans l'erreur. »
Comme quoi, il n'y a que celui qui FAI(t) qui peut se tromper.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: 80?
Posté par tkr (Mastodon) . Évalué à 3.
je sais bien que ca fait troll de base bien gras, mais quand j'entends des gens parler de leur problème en précisant qu'ils sont chez sfr, je leur dis que j'ai arrêté de lire/écouter quand l'opérateur aux trois lettres a été mentionné…
https://www.capital.fr/entreprises-marches/patrick-drahi-proprietaire-de-numericable-sfr-liberation-l-express-et-homme-a-abattre-1049851
et je parle meme pas de celui là :
https://www.lejdd.fr/Economie/Depenses-bloquees-prestataires-essores-departs-en-serie-dans-l-enfer-de-SFR-725174
[^] # Re: 80?
Posté par GG (site web personnel) . Évalué à 3.
Oui, SFR, c'est souvent un problème, mais ça dépend aussi beaucoup de l'emplacement géographique. Parfois il n'y a pas de soucis, alors qu'à d'autres endroits il n'y a pas IPv6, ou l'inverse, et des filtrages, ou pas.
Quand aux connexions par GSM, c'est encore plus compliqué.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: 80?
Posté par YvanM (site web personnel) . Évalué à 2.
Je ne connaissais pas la réputation de SFR, j'admets avoir choisi pour le prix…
# Et depuis le smartphone direct ?
Posté par Pierre Tramal (site web personnel) . Évalué à 4.
Est ce que ca marche en se connectant directement depuis le téléphone (avec ConnectBot par exemple), sans passer par le partage de connexion ?
[^] # Re: Et depuis le smartphone direct ?
Posté par Pierre Tramal (site web personnel) . Évalué à 6.
PS. Si je pose la question c'est parce qu'en fonction de la configuration, le trafic du partage de connexion peut être dirigé (par Android, je présume que tu es sous Android) vers un APN différent de celui utilisé par le trafic venant du téléphone lui-même.
Références :
https://www.reddit.com/r/hacking/comments/5wdzp7/how_does_setting_dun_0_allow_you_to_bypass_mobile/
https://danielpocock.com/android-betrays-tethering-data/
http://www.madore.org/~david/linux/android.html
[^] # Re: Et depuis le smartphone direct ?
Posté par YvanM (site web personnel) . Évalué à 3.
Merci, c'est très intéressant. J'ai testé depuis le téléphone, le comportement est identique.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.