Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

VPN Fail : les solutions VPN touchées par une faille sur la redirection de ports

La solution ? Attendre

VPN Fail : les solutions VPN touchées par une faille sur la redirection de ports

Le 27 novembre 2015 à 16h46

La société de sécurité Perfect Privacy a averti hier dans un billet de blog que bon nombre de solutions VPN étaient vulnérables à des attaques par redirection de port. De fait, une bonne partie des utilisateurs pourraient voir leurs adresses IP réelles être dévoilées par des pirates utilisant les mêmes réseaux.

Les VPN, ou réseaux privés virtuels, sont conçus pour permettre l'accès à des ordinateurs distants. Ils sont également souvent utilisés pour masquer les adresses IP d'origine. Mais il n’est finalement pas très compliqué d’obtenir quand même cette information, surtout quand les solutions existantes autorisent la redirection de port et qu’elles ne sont protégées contre des attaques utilisant cette fonctionnalité.

La faille « VPN Fail »

Hier, la société Perfect Privacy a averti qu’un grand nombre de solutions VPN pouvaient révéler ces adresses IP si un pirate savait où chercher. Pour que l’attaque fonctionne, il doit se trouver sur le même réseau virtuel que sa victime et connaître son adresse IP de sortie. Comme l’indique The Hacker News, cette étape est assez simple puisqu’il suffit d’attirer l’utilisateur sur un site évidemment contrôlé par le pirate. Si la redirection de port est activée, le pirate pourra obtenir l’adresse IP réelle de la victime en l’amenant à ouvrir par exemple une image. À partir de là, il devient possible de rediriger le trafic vers un port là encore contrôlé par le pirate, d’où le nom de l’attaque.

Cette faille de sécurité, nommée « VPN Fail » par Perfect Privacy, a donné lieu à un avertissement lancé à de nombreux éditeurs. La plupart sont donc informés et le tir a été corrigé pour des solutions comme Private Internet Access, Ovpn.to et nVPN. Ce dernier est pour le moment le seul à avoir confirmé officiellement que c'était le cas, comme en atteste le tweet ci-dessous. Perfect Privacy indique cependant que toutes les solutions n’ont pas été testées et que le nombre de produits vulnérables est donc sans doute important.

Clients VPN, systèmes d'exploitation, BitTorrent

La faille pose évidemment un vrai problème de sécurité et de vie privée. Les VPN sont très utilisés dans les pays par exemple où la censure est importante, notamment parce qu’ils bloquent le repérage de la géolocalisation. En conséquence, une faille qui laisserait apparaître la véritable adresse IP ne peut que briser tout l’intérêt de ces solutions et on peut espérer que des correctifs seront rapidement déployés.

La dangerosité de la faille est grande selon Perfect Privacy, puisqu’à cause de la nature même de la faille, on risque de la retrouver dans un très grand nombre de produits, dont les systèmes d’exploitation. Elle peut également être utilisée pour piéger des internautes qui se serviraient de BitTorrent. La technique s’exploite d’ailleurs plus rapidement puisque le pirate n’a pas besoin d’amener l’utilisateur sur un site. Il doit simplement se trouver sur le même VPN et avoir activé la redirection de port.

Rien à faire pour l'instant du côté de l'utilisateur

Dans tous les cas, la victime n’a pas besoin d’avoir l’option activée, et il n’y a donc rien qu’elle puisse faire de son côté. Tous les protocoles liés au VPN, comme OpenVPN et IPSec, sont également concernés. La seule solution est actuellement d’attendre, jusqu’à recevoir une notification de son fournisseur de solution VPN, si bien entendu ce dernier prend la peine de communiquer.

On notera enfin que, dans le cadre de son programme de primes de sécurité, la société Private Internet Access a récompensé la découverte de Perfect Privacy par 5 000 dollars.

Commentaires (39)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar



Les VPN, ou réseaux privés virtuels, sont conçus pour masquer l’adresse IP d’origine.

Ce n’est pas vraiment vrai, c’est juste une utilisation détournée de son but original, qui est pour rappel : “Virtual Private Network, est un système permettant de créer un lien direct entre des ordinateurs distants” (Wikipedia). En résumé le but original d’un VPN était de relier par exemple 2 réseaux d’entreprise…

votre avatar







clacbec a écrit :



Victim is connected to VPN server 1.2.3.4Victim’s routing table will look something like this:

0.0.0.0/0 -> 10.0.0.1 (internal vpn gateway ip)

1.2.3.4⁄32 -> 192.168.0.1 (old default gateway)Attacker connects to same server 1.2.3.4 (knows victim’s exit through IRC or other means)Attacker activates Port Forwarding on server 1.2.3.4, example port 12345Attacker

gets the victim to visit 1.2.3.4:12345 (for example via embedding

on a website)This connection will reveal the victim’s real IP to the attacker because of the “1.2.3.4⁄32 -> 192.168.0.1” vpn route. 




 






Attacker activates Port Forwarding on server 1.2.3.4, example port

12345



 Comment il fait ca sans avoir accès au serveur ? Quand tu as accès

au serveur je vois pourquoi tu te ferais chier a faire du port

forwarding , ou alors c’est pour identifier un user particulier dans la

tonne de connexion vpn

 

 Ca fait beaucoup de si, surtout sur celui de modifier la conf du serveur vpn


votre avatar

Je suis allé un peu vite en besogne et ai remanié la phrase, merci&nbsp;<img data-src=" />

votre avatar

lapin compris.



Normalement la connexion VPN force tout les connections à passer par elle (sauf si on s’est explicitement linké à une interface).



Le mec ouvre un port qui est commun aux utilisateurs utilisant le même serveur. Donc OpenVPN devient con est se connecte à ce port via l’interface qui a établi la connexion VPN ?!?!



Donc c’est un peu comme la faille IPV6 ou de n’importe quel client torrent qui se lie à chaque interface (qBittorrent donne la possibilité de se lié à une seule interface).



Pour ceux qui ont un cerveau et qui ont toujours filtré les connexions via le VPN only il y a aucune raison pour que ça “fuite”.



Ou alors j’ai vraiment rien compris <img data-src=" />

votre avatar

perso j’appelle pas ça une faille

Le VPN n’ayant pas été conçu pour masquer une adresse IP ( comme expliqué par Benjarobin ) je vois pas pourquoi on parle de faille

Mais bon … c’est sûr que pour l’utilisateur qui ne s’en servait que pour ça , c’est assez génant <img data-src=" />

votre avatar

Est-ce qu’il ne suffirait pas côté client de n’avoir la route vers le serveur VPN que pour le processus gérant le VPN (processus openvpn par ex).

Ainsi toute connexion provenant d’un autre programme utilisera forcément le VPN, quelle que soit l’adresse de destination (sauf vers le LAN bien sûr).



Sous Linux il y a plusieurs façons de faire ça :



votre avatar

Tu as raison, effectivement, l’O.S. le plus grand public, car le plus utilisé au monde : [Android], comprend bien iptables (depuis le kernel Linux 2.6.29 et au delà), mais dans sa version courante non-rootée, l’utilisateur ne peut pas le faire tourner puisque ça réclame des privilèges root. 




Rhaa zut alors... si on peut même plus critiquer Android c'est pas cool ! :non:
votre avatar







hwti a écrit :



Est-ce qu’il ne suffirait pas côté client de n’avoir la route vers le serveur VPN que pour le processus gérant le VPN (processus openvpn par ex).





Euh… comment tu fais ça ?

Je ne connais pas cette option dans “route”, c’est une commande plutôt “globale” !







hwti a écrit :



Sous Linux il y a plusieurs façons de faire ça (…)





Pas besoin d’utilisateur dédié, j’ai donné les 2 règles iptables (avec explication) à rajouter pour te protéger de la blague. C’est pas bien dur en réalité. <img data-src=" />

Bien sûr, si tu es prudent, il faut aussi rajouter des règles INPUT (que je vous laisse écrire !)


votre avatar







Bylon a écrit :



Euh… comment tu fais ça ?

Je ne connais pas cette option dans “route”, c’est une commande plutôt “globale” !





Regarde le premier lien, “ip route” a une option “table ID”, ça s’appelle du “policy routing”.

Il faut se servir de iptables pour marquer les paquets, ils utiliseront ensuite une table de routage différente de celle par défaut. On peut donc avoir des routes différentes selon l’utilisateur, le port, le processus (2ème lien), …



Le dernier lien se sert des namespaces réseau (utilisés pour les conteneurs LXC par exemple) : les interfaces réseau vues sont différentes (c’est configurable, on peut donner un accès direct aussi), la table de routage est dédiée.









Bylon a écrit :



Pas besoin d’utilisateur dédié, j’ai donné les 2 règles iptables (avec explication) à rajouter pour te protéger de la blague. C’est pas bien dur en réalité. <img data-src=" />

Bien sûr, si tu es prudent, il faut aussi rajouter des règles INPUT (que je vous laisse écrire !)





L’idée était d’avoir quelque chose qui devrait permettre de dialoguer avec le “voisin de VPN” qui a ouvert des ports.


votre avatar

Pas nécessairement toutes les connexions, non.

Ex : je peux me connecter au réseau de ma boîte via un VPN; Toutes la plage d’adresses de l’entreprise passe par le VPN, le reste (notamment le web, mon client web) passe par ma connexion en direct.

votre avatar

Ah ok, je n’avais pas compris le but de la suggestion, désolé ! 




Oui effectivement, on peut marquer les paquets avec iptables à un moment de leur cheminement pour réutiliser la marque ensuite, et par exemple les poser dans une autre table de routage.      







J'avais essayé le "truc" de la deuxième table de routage pour un autre besoin avec mon Synology... et en fait il a un kernel limité du coup tu crois qu'il créee une deuxième table, mais en fait il n'en a qu'une et ça n'avait pas marché. Mais sur un Linux non-réduit (NAS oblige à la "réduction"), c'est effectivement possible.      







Maintenant, à savoir si ça en vaut la peine pour récupérer les sources hypothétiques chez les "voisins" du VPN, c'est une autre histoire !..      







&nbsp;Et si c'est pour un réseau que tu maîtrises à 100%, par exemple un VPN via la Freebox, là c'est plus simple d'ouvrir les ports "à la demande" avec des règles IPTables par client du VPN.




… mais ça reste un bon exercice de jouer avec le marques iptables et les tables de routage, on comprend plein de trucs pas faciles… et ce n’est pas aisé à mettre en place également ! <img data-src=" />

votre avatar

Si je comprend bien, des fournisseurs de VPN mettent tous leurs clients sur le même VPN, du coup les clients peuvent voir leurs adresses IP entre eux. Au lieu de faire un VPN par client.

C’est ça ou j’ai rien compris ? <img data-src=" />

votre avatar







Mihashi a écrit :



Si je comprend bien, des fournisseurs de VPN mettent tous leurs clients sur le même VPN, du coup les clients peuvent voir leurs adresses IP entre eux. Au lieu de faire un VPN par client.

C’est ça ou j’ai rien compris ? <img data-src=" />







J’avoue que je n’ai pas tout bien compris moi non plus … (j’ai des excuses, shooté aux medocs).



Techniquement parlant, il faut quoi pour pouvoir voir la véritable adresse IP d’un utilisateur de VPN ?



Je m’interroge car je vais bientôt m’acheter un email, et je pensais justement au passage à prendre un bon petit VPN Suisse au passage.


votre avatar

&nbsp;







Bylon a écrit :



&nbsp; mais vous faites encore du BT ? <img data-src=" />





Heu oui ? What else ? Drôle de question.<img data-src=" />


votre avatar







Bylon a écrit :



BT est par exemple utilisé très “officiellement” par le client de mise à jour Blizzard pour WoW, et aussi pour télécharger toutes vos ISO de Linux n’est-ce pas. <img data-src=" />



Moi je m’en sers pour DL comme un goret des films et séries. Et un peu pour les iso.


votre avatar

Ca existe encore les iso ???? C’est pas install by cloud only ?

votre avatar







Mihashi a écrit :



Si je comprend bien, des fournisseurs de VPN mettent tous leurs clients sur le même VPN, du coup les clients peuvent voir leurs adresses IP entre eux. Au lieu de faire un VPN par client.

C’est ça ou j’ai rien compris ? <img data-src=" />









FRANCKYIV a écrit :



J’avoue que je n’ai pas tout bien compris moi non plus … (j’ai des excuses, shooté aux medocs).



Techniquement parlant, il faut quoi pour pouvoir voir la véritable adresse IP d’un utilisateur de VPN ?



Je m’interroge car je vais bientôt m’acheter un email, et je pensais justement au passage à prendre un bon petit VPN Suisse au passage.







Le VPN attache tout le monde au même “réseau ip vpn” du coup si des utilisateurs se parlent entre eux, ils vont utiliser leurs IP publiques au lieu de l’IP du VPN. Ce n’est pas une faille du VPN a proprement parler mais une faille dans l’exploitation non réfléchie d’une techno d’interconnexion :)



votre avatar

Ce n’est pas exactement ça : tu peux tout à fait te parler entre clients du VPN en utilisant l’IP interne au VPN fournie par le serveur, ça ne révèle rien !



En fait il faut en plus la “redirection”, et que le client qui parle n’ait pas les règles firewall (iptables ou selon) indiquées plus haut. Sinon, sur OpenVPN par exemple, le mode client to client utilise bien les IP allouées par le VPN.

votre avatar







Bylon a écrit :



Ce n’est pas exactement ça : tu peux tout à fait te parler entre clients du VPN en utilisant l’IP interne au VPN fournie par le serveur, ça ne révèle rien !



En fait il faut en plus la “redirection”, et que le client qui parle n’ait pas les règles firewall (iptables ou selon) indiquées plus haut. Sinon, sur OpenVPN par exemple, le mode client to client utilise bien les IP allouées par le VPN.







Oui tout à fait. J’ai voulu simplifié pour expliqué mais j’ai omis la redirection <img data-src=" />

Mais çà reste une mauvaise exploitation du VPN.



votre avatar







CryoGen a écrit :



Le VPN attache tout le monde au même “réseau ip vpn” du coup si des utilisateurs se parlent entre eux, ils vont utiliser leurs IP publiques au lieu de l’IP du VPN. Ce n’est pas une faille du VPN a proprement parler mais une faille dans l’exploitation non réfléchie d’une techno d’interconnexion :)







Ah ok … mais quand je vois que certains VPN payant utilisent des centaines de réseaux …



Enfin comme c’est une faille, j’imagine qu’il y a toujours moyen, mais que le pourcentage doit être bien faible quand même.


votre avatar

Je conçois la vulgarisation, c’est parfait pour expliquer !



Mais comme le disait un internaute plus haut en réponse à un de mes commentaires au second degré, ne nous voilons pas la face, la plupart des ventes de VPN sont pour des gens qui veulent faire du BT. Par conséquent, ils ont besoin de rediriger les ports pour être en “High ID”. Si tu es fournisseur de VPN et que tu ne proposes pas ça, en gros tu es “hors marché” vu l’usage commun de la chose.



Donc on ne peut pas vraiment dire “mauvais usage” en réalité, puisque c’est ce que les clients veulent.



Maintenant, en dehors de toute protection de base des clients (que je suggère), il y a des mesures à prendre côté serveur pour parer la faille.

Certaines de ces mesures sont indiquées dans le lien sur l’article. J’opérerais un VPN, j’imaginerais par exemple une règle à la connexion des clients pour exclure leurs IP des redirections chez les autres. C’est pas trop dur à faire sur un OpenVPN par exemple puisqu’il te permet de lancer des scripts à plusieurs moments clé, dont connexion/déconnexion d’un client.



Ainsi, si tu exclus les IP de tes clients de la redirection programmée par un autre, même si le “piège” décrit est mis en place, les iptables sur le serveur bloqueront le flux et tu n’as plus de “faille”.

votre avatar

Ce que je comprends :

Certains providers vpn permettent aux utilisateurs de définir un port forwarding (via une interface web) sur leur ip de sortie (1.2.3.4), qui va rediriger de manière statique par exemple le port 12345 vers leur machine (10.0.0.18 sur leur interface vitrtuelle). Ca permet à certains softs de mieux fonctionner (voire fonctionner tout court).



L’attaquant met en place une redirection du port 12345 vers sa machine. Ainsi toutes les connexions sur le port 12345 de l’ip 1.2.3.4 vont chez lui (10.0.0.18).



Si un autre utilisateur du même côté du VPN (10.0.0.42) que lui essaye d’y accéder, il ne va pas sortir par l’ip de sortie mais rester sur la partie privée du VPN, et la machine cible voit donc 10.0.0.42 en source.



Ce que je ne comprends pas :

L’attaquant devrait voir l’ip de l’interface virtuelle du client vpn, pas l’ip de l’interface publique.

Tous les softs de VPN que je connais permettent d’interdire aux machines du VPN de communiquer entre elles. Ce n’est pas activé par défaut (normal, un VPN sert à faire communiquer des machines entre elles à la base), et ils sont juste en train de dire qu’une partie des providers ne sont pas foutus de lire une doc (finalement ce point là je pense le comprendre).

votre avatar

Tu n’as que le début de bon, mais cela m’a permit de comprendre la chose. Je ne connaissais pas cette fonctionnalité de port forwarding des services VPN, c’est assez pratique, cela permet de fournir un accès à des services de sa machine (par exemple BT :-) )



Bref, sauf que les clients ne se voient pas, c’est là ton erreur. Il ne peuvent pas communiquer entre eux.

La personne qui se fait attaquer et qui va essayer d’accéder à 1.2.3.4:12345 va sortir via son IP de connexion normale et non l’IP du VPN (ce qui est normal, c’est la règle de routage nécessaire pour faire fonctionner le VPN).



En résumé lors de l’accès à 1.2.3.4:12345 le VPN n’est absolument pas utilisé, ce qui est normal. Le correctif doit être fait coté serveur


votre avatar

Par contre je ne comprend pas comment une simple règle de parfeu peut régler le problème sans créer d’effet de bord. Si tu as 2 PC derrière un NAT, un avec le VPN de configuré et l’autre sans, je ne vois pas comment ils arrivent à bloquer la connexion (à 1.2.3.4:12345) du premier PC et l’autoriser pour le second…

votre avatar

Évidemment, c’est pas con en fait.

&nbsp;

Pour empêcher ça, suffit d’avoir une IP d’entrée dans le VPN différente de l’IP de sortie.

votre avatar

Apparemment Mullvad et Torguard auraient patché la faille depuis déjà plusieurs années, mais j’ai pas vérifié.

votre avatar

Hum, si tu as une IP d’entrée dans le VPN différente de l’IP de sortie, en effet tu pourras fournir l’accès à un serveur Web tournant sur ta machine, et il n’y aura plus de faille.

Mais je crains que certains services nécessitent d’avoir l’IP de sortie (vue publiquement) et l’IP d’entrée (le forwarding) identiques, par exemple BT (qui je pense est l’utilisation la plus courante du port forwarding)



Sur perfect-privacy, ils indiquent des solutions

On Client connect set server side firewall rule to block access from Client real ip to portforwardings that are not his own.

Sauf que s’ils font cela, cela à des effets de bord, comme expliqué au dessus…

votre avatar

La grosse bouse c’est qu’un VPN public autorise le “port forwarding” en réalité !.. 




 La Freebox (V6) est affectée par exemple, puisque tu peux faire des règles de redirection de port vers les clients du VPN (Freebox en tant que server VPN) si tu as fixé l'IP de ceux-ci (pas en IP dynamique).




Quelqu’un le dit à Free d’ailleurs ? Qu’ils analysent si ça leur semble une faille ou pas. A mon sens non, puisque ceux qui font ça maîtrisent l’intégralité de leur réseau. 




 Donc le fait de pouvoir faire du port-forwarding sur le VPN fait qu'en réalité tu as accès aux tables de routage du serveur (d'où la faille !). Dans l'exemple, si tu sais forwarder le port 12345 vers ta machine, ça veut dire que tout ce qui va entrer sur le serveur (1.2.3.4) et sur ce port (12345), va atterrir sur ta machine, sur le port vers lequel tu as forwardé.       


 Comme évidemment ceux qui sont connectés à 1.2.3.4 ont une route vers celui-ci avec leur "vraie" IP pour que les paquets du VPN puissent passer... si tu sais amener le gogo à utiliser 1.2.3.4:12345 tu verras ça vraie IP.       









 Cependant, @Vincent, dire "il n'y a rien à faire, la seule solution est d'attendre..." est une grosse contre-vérité.  







 La solution tient en 2 règles iptables.       







 Supposons, pour poursuivre l'exemple 1.2.3.4 qu'on fonctionne en OpenVPN avec le standard par défaut : UDP sur le port 1194.       







 On mettra alors les règles ci-dessous :






  • iptables -A OUTPUT -d 1.2.3.4 -p udp –dport 1194&nbsp; -j ACCEPT

  • iptables -A OUTPUT -d 1.2.3.4&nbsp; -j DROP





    Et du reste, ne pas faire ça sur un serveur public est évidemment de l’inconscience.

    En gros, ces deux règles disent :

    -(règle 1) j’autorise l’udp sur 1194 vers 1.2.3.4 (c’est à dire OpenVPN en UDP sur 1194 vers mon fournisseur VPN)

    -(règle 2) tout autre trafic vers ce fournisseur est interdit.



    Et du coup le petit malin qui veut vous faire afficher une image qui réside à 1.2.3.4:12345 (en TCP donc), eh bien vos règles l’interdisent, il n’aura donc rien…. et vous ne verrez bien sûr pas d’image !



    Bien sûr, cela vous interdit aussi de faire du BT avec un “voisin de VPN” qui aurait ouvert ses ports pour être en “HighID”… mais vous faites encore du BT ? <img data-src=" />





    Bref… dire “il n’y a rien à faire” est visiblement faux.



    Après, que certain O.S. grand public ne soient pas capables de gérer des règles de filtrage de la sorte, je veux bien le croire… mais dans ce cas il faut utiliser un O.S. sérieux. <img data-src=" />

votre avatar

Je ne vois pas pourquoi, c’est le fonctionnement classique d’un NAT :p

votre avatar







Bylon a écrit :



La grosse bouse c’est qu’un VPN public autorise le “port forwarding” en réalité !.





Je n’utilise pas de VPN, mais je pense que au contraire que c’est surement une fonctionnalité recherché. Et qu’est ce que tu as contre BT ?

Mais sinon en effet ta solution coté client est une très bonne solution avec des effets de bord maitrisé (interdit de faire du BT avec un “voisin de VPN”)


votre avatar

Et aussi pour être complet… il faut aussi mettre un règle pour bloquer tous les INPUTs&nbsp; depuis votre fournisseur VPN qui ne soit pas de l’UDP provenant du 1194.



Ainsi, si le fournisseur tente de pénétrer sur votre machine, de façon mal-intentionné, ou parce qu’il a été “hacké”… eh bien cela l’empêchera.



Par contre, dans ce cas, si vous utilisez vous même des port-forward, il faut évidemment ouvrir les INPUTs correspondants !

votre avatar

Je n’ai rien contre BT, c’était une partie à lire au second degré !..

Et bien évidemment, c’est très certainement LA fonctionnalité recherchée qui pousse au port-forward. Parce que héberger son serveur Web derrière un VPN pour le “cacher”, c’est juste une grosse blague. Si les “autorités” veulent savoir, elle n’ont qu’à aller demander au fournisseur VPN… et en ce moment elles n’ont même pas besoin de juge : il suffit d’entrer en défonçant la porte et piquer les infos. <img data-src=" />



… mais bon, il y en a encore qui croient qu’un fournisseur de VPN les cache !..

En réalité ça déplace juste la “confiance” depuis votre FAI vers votre fournisseur VPN. Et ça complique juste un petit peu si le VPN est à l’étranger.



BT est par exemple utilisé très “officiellement” par le client de mise à jour Blizzard pour WoW, et aussi pour télécharger toutes vos ISO de Linux n’est-ce pas. <img data-src=" />

votre avatar







Bylon a écrit :



Après, que certain O.S. grand public ne soient pas capables de gérer des règles de filtrage de la sorte, je veux bien le croire… mais dans ce cas il faut utiliser un O.S. sérieux. <img data-src=" />







Hmmm je ne sais pas s’il est courant de faire du bittorent sur un Android non-rooté.



Sinon, n’importe quel OS grand public a un firewall capable de gérer ce genre de règles de filtrage, désolé, ton troll tombe à l’eau.


votre avatar







Liam a écrit :



Hmmm je ne sais pas s’il est courant de faire du bittorent sur un Android non-rooté.



Sinon, n’importe quel OS grand public a un firewall capable de gérer ce genre de règles de filtrage, désolé, ton troll tombe à l’eau.







Sauf que sur Windows (post XP). Dès que la connexion est établie sur l’interface, il téléphone maison (chez Bill Gates) pour vérifier si la connexion est fonctionnelle et résoudre l’IP public.



Donc sur Windows, Microsoft sait qu’elles sont les IP qui ont été utilisée sur une machine.



En théorie <img data-src=" />

[/MODEPARANO]


votre avatar
votre avatar







PixelMort a écrit :



réponse intéressante de airvpn 




 &nbsp;https://airvpn.org/topic/16129-ip-leak-affecting-vpn-providers-with-port-forward... (le post #4)









Effectivement, c'est nettement plus clair que l'article.      


Apparemment c'est une non faille, et seulement une preuve d'amateurisme de 5 fournisseurs...      







Jusque là, rien d'étonnant ni de nouveau. Ceux qui ont fait cette annonce, et ceux qui la reprennent, semble juste faire du buzz avec un truc vieux comme le monde (c'est à dire internet :D).

votre avatar

5&nbsp;000 dollars&nbsp; <img data-src=" />

votre avatar

Ne nous voilons pas la face ? Non mais le VPN est une technologie largement exploitée par les entreprises depuis des années <img data-src=" />

Il y a surement bien d’utilisation de VPN “légal” que tu ne sembles le croire… Accès à distance sécurisé, interconnexion de site distants, cloud… bref.



Le VPN c’est “virtual private network” , l’exploitation de VPN pour ce cacher c’est une dérive. Et oui le VPN peut servir à çà.

votre avatar

Totalement d’accord avec toi !



Du reste j’ai mon propre VPN, le serveur est ma Synology, plus les postes que j’ai enrôlés moi même sur ma PKI. Sur ce VPN je ne fais que des échanges comme ceux que tu cites.



Quant aux VPN business, en général c’est ton entreprise qui héberge le serveur… et oui, c’est utilisé pour tout ce qui est télétravail, ou simplement quand ton entreprise te confie un PC pour que tu puisses par exemple consulter tes mails&nbsp; professionnels tout en étant branché sur ta ligne privée.



Mais on ne parle pas de la même chose là je pense… (enfin je n’affirme rien n’étant pas client moi-même !) <img data-src=" />

VPN Fail : les solutions VPN touchées par une faille sur la redirection de ports

  • La faille « VPN Fail »

  • Clients VPN, systèmes d'exploitation, BitTorrent

  • Rien à faire pour l'instant du côté de l'utilisateur

Fermer