Comment lire une socket VPN sans faire confiance à un nom de domaine

Votre visionneuse d'extrémités liste un processus VPN à côté du domaine d'une société de publicité, et cet appariement démarre une histoire que les données ne peuvent pas soutenir. Le nom est une recherche inverse peinte sur une extrémité numérique, et il change dès que la recherche change. Les colonnes qui résistent à l'examen sont les adresses, l'état de la connexion et le PID qui possède la socket.

Rien dans une table de sockets ne décrit ce qui a voyagé à l'intérieur d'une connexion. Tout ce qui porte un nom d'hôte a déjà été interprété pour vous.

Un nom résolu est une traduction, pas un champ

La visionneuse demande au résolveur de transformer une adresse en nom, de la même manière qu'une requête PTR fonctionne dans le DNS. La réponse peut venir d'un cache local, d'une entrée du fichier hosts, d'une annonce de découverte de voisins ou d'un fournisseur qui a cédé l'adresse à quelqu'un d'autre la semaine dernière, et l'outil n'a aucun moyen de distinguer ces sources. Deux machines qui observent une connexion peuvent imprimer des noms différents pour la même adresse de pair, ce qui est difficile à expliquer si vous croyez que le nom est venu du fil. Traitez l'étiquette comme une commodité pour l'œil humain, non comme une affirmation sur qui a reçu les octets.

La documentation TCPView décrit les colonnes d'extrémité, d'état et de processus et documente la désactivation des noms résolus, ce qui vaut la peine d'être fait avant de lire quoi que ce soit dans un domaine. Désactiver la résolution rend l'incertitude visible au lieu de la créer : vous détenez toujours une adresse, et le travail de décider ce qu'elle signifie vous est simplement revenu.

Lisez les colonnes numériques dans l'ordre

Travaillez de gauche à droite et arrêtez-vous à la première colonne qui répond à votre question. L'extrémité locale montre ce à quoi le processus s'est lié, l'extrémité distante montre si un pair existe du tout, l'état montre si l'association est vivante, et le PID relie la ligne à un exécutable.

Les trois observations ci-dessous sont des formes illustratives et non une sortie capturée sur une machine d'ici. Elles sont regroupées selon ce que chacune peut soutenir, car c'est la question que les gens posent réellement à une ligne de socket :

Un écouteur ouvert que les autres machines ne peuvent pas atteindre, lié à l'adresse de bouclage, est la façon dont beaucoup de clients VPN exposent leur propre canal de contrôle. Une liaison générique signifie que le processus a accepté des connexions sur toutes les interfaces, et si cela est dangereux dépend du pare-feu de l'hôte et non de la ligne elle-même. Seule une association qui existe et porte des compteurs ressemble à l'accusation que les gens veulent habituellement porter, et même cette ligne s'arrête avant la charge utile.

Vérifiez la propriété avant de nommer un coupable

L'identité du processus est l'endroit où la plupart des accusations échouent réellement. Les PID sont réutilisés, les programmes de mise à jour et les assistants de navigateur engendrent des enfants de courte durée, et un client VPN peut confier son trafic à un service système privilégié. Comparez le chemin de l'exécutable et le processus parent plutôt que le nom affiché, car le nom affiché est choisi par celui qui a construit le binaire.

tcpvcon -n -a
Get-Process -Id 4188 | Select-Object Id, ProcessName, Path

La même lecture existe sous Linux, où les statistiques de sockets peuvent porter des informations de processus lorsque vous avez assez de privilèges pour voir les sockets d'autres utilisateurs. Demander les sockets établies liées au port 443 ou depuis celui-ci resserre la sortie sur les lignes qui comptent :

ss -tunp state established '( sport = :443 or dport = :443 )'

Capturez l'horodatage avec la ligne. Un PID seul est une référence mouvante, car le temps d'ouvrir un gestionnaire de processus, la socket peut appartenir à un successeur et le chemin que vous inspectez peut ne pas être celui qui détenait la connexion. Enregistrez la paire d'extrémités, l'état et le PID comme une seule observation, et la conclusion survit à un redémarrage ou à un second avis.

Ce que vaut encore un nom

Un nom d'hôte n'est pas une preuve sans valeur. Il enregistre que quelqu'un a associé cette adresse à ce nom à un moment donné. Cette association mérite attention lorsque l'adresse appartient à un fournisseur qui sert des milliers de clients sans rapport. C'est une affirmation plus faible qu'une destination, et c'est la seule affirmation que l'étiquette puisse soutenir.

Quand un nom semble faux, comparez l'adresse aux plages publiées du fournisseur, puis demandez ce que le processus faisait à ce moment-là : une vérification de mise à jour, un appel de licence, un envoi de télémétrie ou une poignée de main de tunnel. Ces activités laissent des formes de connexion différentes, et associer la forme au moment est plus instructif qu'associer le nom à une entreprise à laquelle vous ne faites pas confiance.

Préservez la ligne avant de terminer un assistant partagé ou de désinstaller quoi que ce soit. Une conclusion défendable couvre une extrémité observée, son état et son propriétaire ; un verdict à l'échelle d'une marque construit sur une étiquette résolue n'est pas une preuve, et l'assurance qu'un hôte de téléchargement familier doit être inoffensif ne l'est pas non plus.