La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Autres systèmes d'exploitation => Discussion démarrée par: MacMan le 10 février 2025 à 18:59:59
-
Bonjour,
Je ne sais pas trop où poster ce sujet auquel je ne trouve aucune solution.
Un iMac (Intel) avec Séquoia 15.3, envoie des paquets vers le réseau publique.
exemple :
in:ether2-LAN1 out:(unknown 0), connection-state:new src-mac a0:ce:c8:xx:xx:xx, proto TCP (SYN), 192.168.1.51:52787->yy.yy.yy.yy:443, len 64
où : 192.168....:52787 est l'adresse locale et le port d'envoi
yy.yy.yy.yy:443 est l'adresse et le port de destination (le WAN du routeur)
il y a une dizaine de paquets semblables, toutes les 2 - 10 minutes environ (très variable)
Alors bien sûr, ces paquets ne contiennent aucune donnée, et mon adresse publique n'est pas accessible de l'extérieur, ni le port 443.
Tout ça passe dans mon routeur Mikrotik CCR2004 sur la fibre Orange, et pour le moment, ces paquets sont stoppés par une règle RAW.
J'avais pensé à un malware quelconque, une analyse n'a rien montré.
Une précision encore : tous mes macs sont concernés sauf un vieux MacBook Air avec Catalina. Les PC Windows et machines Linux ne posent pas de problème semblable.
A votre avis, c'est quoi ce bazar qui ne sert à rien ?
Merci pour votre aide
-
Quelle est l'IP de destination ?
Vous dites que les paquets ne contiennent rien ?
Rien du tout ?
-
Le port 443, cela peut-être pour passer plus facilement les pare-feu. Le port 443 est en général ouvert par défaut.
Sinon, oui, quelle est l'adresse de destination ? Cela permettrait de voir à qui elle appartient, Apple ou autre.
-
Bonsoir,
L'IP de destination est mon IP publique sur le port 443 (https) (port fermé)
C'est ça qui est bizarre ???
Je ne sais pas à quoi correspond ce détour : joindre mon réseau local en passant par dehors !
[Edit]
Pour essayer de résumer (pas évident)
En gros, c'est un Mac du réseau local qui envoie des paquets sur l'adresse IP publique du routeur où il n'y a pas d'accès (pas de NAT et port 443 fermé)
-
Si tu bloques les SYN (ouverture de connexion TCP), effectivement, le paquet ne contiendra pas de données. Il faut que la connexion TCP soit établie pour que des données puissent être échangées (ignorant TCP fast open).
Est-ce que tu observes ce comportement toutes applications fermées ? Je ne serai pas étonné que ce soit un test de connectivité de MacOS, du genre détection de portail captif ou autre.
-
@simon,
merci pour les idées !
La connexion ne peut pas s'établir puisque l'accès IPv4 de mon routeur coté wan est fermée (pas de NAT, pas de port ouvert)
Ce phénomène se produit même sans application ouverte, mais il y a tellement de choses qui tournent en silence !
J'observe ce comportement même le Mac en suspension d'activité (écran éteint etc),
pour que ces paquets disparaissent je dois éteindre la machine complètement
Ce que je ne vois vraiment pas, c'est le but poursuivi ? tenter une connexion depuis le lan pour y revenir en passant par le coté man ??
[Edit] Demain je vais essayer de mettre place une entrée https, une règle NAT .. juste pour voir !
-
C'est pas juste du DoH ?
-
C'est pas juste du DoH ?
Sûrement.
Avec le DNS, c'est comme d'habitude de toutes façons.
Avant on avait: «UNE IP ESSAIE DE ME HACKER AVEC DE L'UDP!» -> donne l'IP du serveur DNS ::)
Désormais «UNE IP ESSAIE DE ME HACKER AVEC DU TCP!» -> donne l'IP du serveur DNS ;D
-
Ce serait bizarre d'avoir l'IP WAN dans la configuration DNS, et pas l'IP LAN du routeur.
-
Ce serait bizarre d'avoir l'IP WAN dans la configuration DNS, et pas l'IP LAN du routeur.
Oui, et le fait que ca continue quand le mac est en veille est étonnant aussi.
Ca me fait plus penser à un mécanisme de détection de l'environnement réseau. Mais à quel but, va savoir. Apple est assez opaque.
Tous les Mac et iDevices maintiennent aussi une connexion sur le port 5223/tcp en permanence pour les notifications. Autant pour les mobiles ca ne me choquait pas, autant quand j'ai vu MacOS le faire, j'ai été un peu surpris au début.
-
Je me pose quand même quelques questions :
iMac:~ vert$ netstat -anv | grep "192.168.1.51"
tcp4 0 0 192.168.1.51.59848 151.101.121.91.443 ESTABLISHED 75042 3004 166472 131688 2320 2320 00000 00000000 0000000000000000 00000000 00000000 0 0 000000
tcp4 0 0 192.168.1.51.59830 17.188.185.135.5223 ESTABLISHED 16452 75650 131072 131768 130 130 00000 00000000 0000000000000000 00000000 00000000 0 0 000000
iMac:~ vert$
On dirait qu'il y a bien des connexions établies
-
Tu n'aurais pas le Private Relay d'iCloud activé ?
-
Bonsoir,
@Hugues : non, je viens de vérifier (au cas ou ..)
J'ai beaucoup de mal pour comprendre ce qui se passe.
Tu connais fastly.com ? J'ai l'impression qu'ils sont dans le coup... l'ip 151.101.121.91 qui apparait leur appartient ...
Tout ça est très très fugitif, ça change très vite et bien sûr pas analyser ça ...
-
Fastly est un des prestataires d'Apple pour le private relay justement
-
ah merci de l'info.
Le private relay est bien désactivé (du moins dans la fenêtre du dialogue)
Je me méfie tellement d'Apple .... si ça se trouve, même désactivé, certaines fonctions (celle qui intéressent Apple) restent actives
-
On dirait qu'il y a bien des connexions établies
Mais pas vers l'IP WAN de ton routeur, donc rien d'anormal ?
-
@simon
ben, j'ai l'impression qu'il y a bien une connexion d'établie entre mon iMac (192.268.1.51) avec 151.101.121.91 (machine de chez fastly.com)
C'est ça qui m'inquiète, et je ne sais pas comment la bloquer :o
-
Tu dois pouvoir passer en root et faire un netstat -naltp pour voir quel process utilise cette connexion? MacOS établit plein de connexions dans tous les sens, c'est pas nécessairement un symptome de quelque chose de malicieux.
-
le netstat -naltp ne passe pas (même en root)
Je verrai la syntaxe qu'il me faut demain.
Je ne dis pas que c'est quelque chose de malicieux, c'est un truc qui m'énerve car je ne sais pas ce que Apple bricole sur mon Mac (remarque, c'est peut-être aussi bien !)
Le truc qui avait attiré mon attention c'est la tentative de connexion de mon Mac sur le lan vers le routeur coté wan.... c'est pour moi assez étrange.
J'ai à coté un KDE avec une Debian, je n'ai pas l'impression de pareilles choses !
-
Ah oui, je confirme que MacOS et Windows sont très chatty sur le réseau...
-
bah c'est sur qu'un OS qui sait faire un peu plus qu'afficher une page web et un traitement de texte a besoin de converser un peu avec internet :p
-
ah merci de l'info.
Le private relay est bien désactivé (du moins dans la fenêtre du dialogue)
Je me méfie tellement d'Apple .... si ça se trouve, même désactivé, certaines fonctions (celle qui intéressent Apple) restent actives
vous vous méfiez d'apple et vous possédez un mac? :o
après faut admettre que le truc qu'ils ont mis pour les mails sur iphone, forcément ca redirige le trafic ailleurs.
pour ma part, à la lecture de votre topic au premier coup d'oeil, l'indication que cela ne "vient que des macs" faisait forcément raison d'une subtilité expliquée par apple. Je vois pas d'autre cas. Eventuellement, vous avez appelé le support apple? ou sur macrumors, en complément..
-
après faut admettre que le truc qu'ils ont mis pour les mails sur iphone, forcément ca redirige le trafic ailleurs.
À quoi fais-tu référence? J'utilise Mail avec plusieurs comptes iMap et ai pu vérifier que le trafic est direct entre l'iPhone et les serveurs IMAP/SMTP. Je n'utilise pas iCloud relay.
-
MacMan, un temps. il y avait LittleSnitch pour filter les connexions process par process sur MacOS.
Je crois avoir entendu qu'il ne fonctionne plus (car Apple a changé son SDK et la facon dont les applications peuvent gérer le firewall, notamment en exemptant ses applications et services du firewall), donc pas sûr que ce soit encore d'actualité.
Si ce que tu recherches c'est un OS plus respectueux de ta vie privée, notamment qui n'ait pas ce genre ce comportements, une distribution Linux est probablement plus ce qu'il te faut.
Avec Gnome sur Debian comme environnement graphique, les seules connexions que je peux observer sont celles du test de connectivité à Internet de network-manager. Et encore, j'ai pu les désactiver (je suis souvent connecté à des réseaux sans accès à internet, et ce test désactivait la connexion Ethernet lorsqu'il échouait).
-
Bonjour,
@simon
Oui LittleSnitch ! j'ai beaucoup utilisé à l'époque (tout comme le bouton MacsBug)
Ce n'est pas un problème de respect de la vie privée.
Comme dit à plusieurs reprises, un Mac ou un Windows ce n'est pas l'idéal !
On ne parle là que de l'OS ; si on commence à se pencher sur les app ...
Je n'ai toujours pas trouvé d'explication pour ces paquets originaires du Mac et à destination de l'adresse publique du routeur.
D'ailleurs à ce sujet, un process du Mac n'est pas censé utiliser cette adresse publique qui, si je ne m'abuse, est inconnue de la machine, même si elle est trouvable dans le routeur.
De toute façon, cette adresse est inutile, puisque inaccessible (pas de dstNAT, port fermé); le tcp SYN ne va pas plus loin.
Donc :
Je vais arrêter de me creuser la tête, ça me fatigue pour rien ::)
... tant pis pour ce traffic inutile !
-
J'ai littlesnitch ici, ça marche encore sans pbm
-
D'ailleurs à ce sujet, un process du Mac n'est pas censé utiliser cette adresse publique qui, si je ne m'abuse, est inconnue de la machine, même si elle est trouvable dans le routeur.
Elle n'est pas inconnue si il se connecte à une autre machine à l'extérieur et lui demande l'adresse IP source vue par le serveur. Je suis sur qu'il y a un cas tordu de portail captif qui nécessite ce test... mais comme tu le dis, ca n'a pas d'impact dans ton cas.
-
J'ai littlesnitch ici, ça marche encore sans pbm
Je confirme. Il y a eu des problèmes lorsque Apple a introduit ses nouvelles API et la dépréciation des extensions noyau, mais c’est résolu depuis bien longtemps.