Le passe pare-feu

Publié par cleo le 03/12/2008

Comment Skype et compagnie contournent  les pare-feu

L'article original est à lire à :  http://www.heise-online.co.uk/security/How-Skype-Co-get-round-firewalls--/features/82481

C'est un article de Jürgen Schmidt, responsable de Heise Security. Les différents schémas et tableau ci-dessous sont repris de son article.

L'image ci-contre provient du site Webkeysoft, qui a lui même utilisé un document provenant de Comment ça marche.

Voici la traduction :

Les applications P2P sont le cauchemar des administrateurs de réseaux.   Afin d'échanger des paquets d'information avec leurs homologues aussi rapidement que possible elles utilisent des astuces imperceptibles pour  perforer des trous dans les pare-feu qui en fait ne devraient en aucune façon permettre à ces paquets de passer. De plus en plus souvent, les ordinateurs se protègent derrière des pare-feu afin de protéger leur système d'exploitation contre les menaces de l'internet.  L'idéal c'est lorsque les fonctions de pare-feu sont assumées par le routeur qui traduit  l'adresse de réseau locale de l'ordinateur en adresse IP publique (NDT : Network Address Translation - NAT).  Cela revient à dire qu'une attaque extérieure ne peut atteindre l'ordinateur - les connexions doivent être établies de l'intérieur.

Le problème survient quand deux ordinateurs protégés par leur pare-feu NAT doivent correspondre directement entre eux : dans le cas par exemple de deux utilisateurs qui voudraient se parler directement par le système de la voix sur réseau IP (VoIP).  Voilà tout le dilemme : quelle que soit la personne qui appelle, le pare-feu de la personne appelée repoussera ce semblant d'attaque en rejetant purement et simplement les paquets de données.  La communication téléphonique échouera ou tout au moins c'est à cela qu'un administrateur de réseau s'attendrait.

Perforé

Cependant tous ceux qui utilisent  Skype, ce fameux logiciel de téléphonie sur internet, savent que ça fonctionne derrière un pare-feu NAT aussi bien que si l'ordinateur était directement connecté à internet.  Cela s'explique par la solution élaborée et mise en place par les inventeurs de Skype ou de logiciels du même type.

Il est évident que chaque pare-feu doit aussi permettre à des paquets d'information d'entrer sur le réseau local : après tout les utilisateurs veulent visiter des sites internet, lire leurs courriels, etc.  Le pare-feu doit donc permettre aux paquets d'information appropriés de pénétrer dans les postes de travail informatiques situés sur le réseau local (LAN - Local Area Network).  Cependant il n'agit ainsi que dans les cas où il est convaincu que les paquets entrant sont la réponse à un paquet d'information sortant.  Un routeur NAT garde donc en mémoire quel ordinateur local a communiqué avec quel autre ordinateur  externe et par quels ports.

L'astuce utilisée par les logiciels VoIP  c'est de faire croire au pare-feu qu'une connexion sortante a bien été établie pour laquelle il doit  accepter les paquets de données qui arrivent.  Le protocole sans connexion UDP utilisé par Skype dans la transmission des données audio sur VoIP joue à son avantage.  A la différence du protocole de contrôle des transmissions (TCP) qui inclut des informations supplémentaires à chaque paquet lors des connexions, quand il s'agit d'une connexion UDP, le pare-feu ne voit que les adresses et les ports des systèmes de l'expéditeur et du destinataire.  Dans les cas où les paquets UDP correspondent à des données mémorisées par le pare-feu NAT, ce dernier délivrera les paquets d'information, la conscience tranquille.

Commutation

Le serveur de commutation avec lequel les deux bouts de l'appel sont en relation constante joue un rôle important lors d'une connexion Skype.  Cela se passe à travers une connexion TCP que les clients eux-même initient. C'est ainsi que le serveur Skype sait toujours par quelle adresse un utilisateur Skype est disponible sur internet.  Dans la mesure du possible les connexions téléphoniques elle-mêmes ne passent pas par le serveur Skype, les clients échangeant des données directement entre eux.

Considérons Alice qui souhaite appeler son ami, Bob.  Son compte client prévient le serveur Skype de son intention. Le serveur Skype connaît déjà Alice.  Par cette requête extérieure, le serveur constate que Alice est enregistrée à l'adresse IP 1.1.1.1  et un contrôle rapide indique que ses données audio proviennent toujours du port UDP 1414.  Le serveur Skype transmet cette information au compte client de Bob, qui d'après sa base de données est bien enregistré à l'adresse IP 2.2.2.2. et qu'il utilise de préférence le port UDP 2828.

Alice appelle  Bob

Etape  1 : Alice essaye d'appeler Bob et un signal se déclenche sur Skype.

Le programme Skype de Bob perce alors un trou dans le pare-feu de son propre système, qui envoie un paquet UDP à l'adresse 1.1.1.1. sur le port 1414.  Le pare-feu d'Alice rejette ce paquet. Cependant le pare-feu de Bob ne le sait pas.  Il pense maintenant que tout ce qui provient de 1.1.1.1. par le port 1414 et adressé à l'adresse IP de Bob 2.2.2.2. par le port 2828 est acceptabe car c'est certainement la réponse à la requête qui vient d'être envoyée.

Le trou est percé

Etape  2 : Bob tente d'atteindre Alice qui perce un trou dans le pare-feu de Bob.

C'est à ce moment que le serveur Skype transmet les coordonnées de Bob à Alice dont la propre application Skype essaye de contacter Bob au 2.2.2.2. par le port 2828.  Le pare-feu de Bob reconnaît l'adresse de l'expéditeur et transmet ce qui lui semble être la  réponse à l'ordinateur de Bob et c'est alors que son téléphone Skype retentit.

L'appel est établi.

Etape 3 : Alice atteint finalement l'ordinateur de  Bob à travers le trou.

Un tour d'horizon

Cette description est quelque peu simplifiée et dans le détail cela dépendra des propriétés spécifiques à chaque pare-feu. Dans le principe, elle correspond aux observations que nous avons pu faire à propos du processus de connexions entre deux comptes-clients Skype dont chacun d'entre eux se trouvait protégé par un pare-feu Linux.  Les pare-feu étaient configurés avec le NAT pour un environnement LAN et autorisaient un trafic UDP en sortie.

Dans les fonctionnalités du traducteur d'adresses de réseaux (NAT) de Linux, on trouve la propriété conviviale de la VoIP qui consiste à ne pas modifier, du moins au départ, les ports des paquets sortant.  Le routeur NAT remplace simplement l'adresse IP locale et privée par sa propre adresse - le port source UDP choisi par Skype est gardé en mémoire. Ce n'est que dans le cas où des clients multiples au niveau local utilisent le même port de sortie que le  routeur NAT est alerté  et qu'il réinitialise alors le port sur une valeur non utilisée auparavant.  En fait chaque groupe de deux adresses IP et de deux ports doit être attribué, sans ambiguïté aucune et à tout moment, à une connexion entre deux ordinateurs.  En conséquence, le routeur devra reconstruire l'adresse IP interne de l'expéditeur de départ par rapport à la réponse du port du destinataire.

D'autres routeurs NAT vont chercher à relier des ports à des séries spécifiques, par exemple à partir de  30000 et au-delà, et ils transformeront ainsi le port UDP 1414 en 31414, si possible.  Bien entendu ceci n'est pas un problème pour Skype. La procédure décrite plus haut continue à marcher de la même manière et sans limite.

Cela devient un peu plus compliqué lorsqu'un pare-feu donne aux ports des valeurs séquentielles. C'est le cas du pare-feu Check Point : la première connexion est nommée 30001, la suivante, 30002, etc.  Le serveur Skype sait que Bob lui parle à partir du port 31234, cependant la connexion vers Alice sera établie à partir d'un autre port.  Mais même dans ce cas Skype est capable de déjouer les stratégies du pare-feu.  Il va simplement essayer de passer par les ports au delà de 31234, en suivant une séquence, espérant, à un certain moment, tomber sur le bon.  Si ça ne marche pas du premier coup, Skype n'abandonne pas.  Le Skype de Bob démarre une nouvelle connexion vers le serveur Skype, qui devient le port source et qui sera alors utilisé pour une nouvelle série de tentatives.

Capture d'écran avec Wireshark

ZoomSkype a la faculté de scanner les ports.  Dans cet exemple il arrive à passer à travers le pare-feu et établit la connexion par le port 38901.

Cependant dans les réseaux très actifs, Alice peut ne pas trouver l'accès au bon port.  Ceci s'applique aussi à des types particuliers de pare-feu qui désignent au hasard un port source pour chaque  nouvelle connexion.  Le serveur Skype est incapable alors de montrer à Alice le chemin vers le passage approprié dans le pare-feu de Bob.

Même dans ce cas, Skype ne lâche pas prise.  Dans ces situations, le serveur Skype est utilisé comme relais.  Il accepte les connexions qu'elles viennent d'Alice comme de Bob et relaie les paquets d'information à partir de là.  Cette solution est possible du moment que le pare-feu accepte le trafic UDP en sortie.   Cela implique cependant une charge supplémentaire sur l'infrastructure, en effet toutes les données audio doivent passer par les serveurs de Skype.  Les temps prolongés dans la transmission des paquets peuvent aussi se traduire par des retards déplaisants.

L'utilisation de la procédure décrite ci-dessus n'est pas propre à Skype et est bien connue sous le nom de "UDP hole punching" (NDT : percer un trou avec UDP).  D'autres services d'internet, comme les jeux Hamachi, en application VPN, qui se basent sur la communication peer-to-peer entre des ordinateurs protégés par leur pare-feu, utilisent des procédures identiques.  Une version plus développée est même devenue une référence.  Il s'agit de RFC-3489, Simple Traversal of UDP through NAT" (STUN) (NDT : une simple passerelle du protocole sans connexion  à traves un traducteur d'adresse réseau). Ce protocole permet à deux clients STUN de contourner, dans de nombreux cas, les restrictions imposées par le NAT grâce à un serveur STUN. Le projet de protocole TURN (Traversal Using Relay NAT) (NDT :  le NAT utilisant des passerelles relais) décrit une norme possible pour les serveurs relais.

Comment percer un trou soi-même

Avec quelques petits utilitaires, vous pouvez essayer vous-même de percer un trou avec un protocole sans connexion (UDP). Les outils nécessaires, à savoir hping2 et netcat, se trouvent dans les logiciels Linux. Considérons un réseau local constitué d'ordinateurs derrière un pare-feu Linux (local-fw) avec un filtrage dynamique des paquets d'information, qui ne permet que les connexions sortantes de type UDP.  Pour simplifier les choses, dans notre test, on considère que l'ordinateur distant (remote) est directement relié à internet sans pare-feu.

La première chose c'est de commencer une écoute UDP sur le port 14141 à partir du poste local/1, derrière son pare-feu :

local/1# nc -u -l -p 14141

Un ordinateur extérieur (remote) cherche alors à le contacter :

remote# echo "hello" | nc -p 53 -u local-fw 14141

Toutefois, comme on pouvait s'y attendre, local/1 ne reçoit aucune donnée et grâce au pare-feu rien ne repart vers l'ordinateur distant (remote).  Ensuite, sur un deuxième poste, local/2, hping2, notre outil universel pour produire des paquets IP, perce un trou dans le pare-feu :

local/2# hping2 -c 1 -2 -s 14141 -p 53 remote

Aussi longtemps que l'ordinateur distant (remote) se comporte comme il se doit, il renverra la réponse, "port injoignable" à travers son ICMP,  mais cela n'aura aucune conséquence.  Lors de la seconde tentative :

remote# echo "hello" | nc -p 53 -u local-fw 14141

l'auditeur netcap sur le poste local/1, répondra alors "hello" signifiant que le paquet UDP entrant est passé à travers le pare-feu et a atteint l'ordinateur qu'il protégeait.

Les administrateurs de réseaux qui n'apprécient pas ce type de trou dans leur pare-feu et qui sont soucieux des abus possibles, sont placés devant le seul choix acceptable : ils doivent bloquer le trafic UDP sortant ou le limiter à des cas individuels bien précis.  De toutes les façons les connexions UDP ne sont pas nécessaires à la communication de base sur internet :  la toile, les courriels, etc. utilisent les connexions TCP.  Les protocoles en flux continu rencontreront quant à eux des problèmes car ils utilisent souvent UDP pour plus de fluidité.

Cela peut paraître étonnant mais percer des trous dans le pare-feu fonctionne aussi avec les connexions TCP.  Lorsqu'un paquet avec la balise SYN sort, le routeur formé du pare-feu/NAT  transmettra les paquets entrant avec les bonnes adresses IP et les bons ports aux réseaux locaux même si ceux-ci n'ont pas confirmé ou s'ils ont confirmé une séquence erronnée de chiffres (balise ACK). Tout au moins les pare-feu Linux n'ont pas réussi à contrôler l'information de façon consistante.  Il faut cependant dire qu'établir une connexion TCP de cette manière n'est en rien simple car Alice n'a pas connaissance de la séquence des chiffres envoyés avec le premier paquet de données de Bob.  Le paquet contenant cette information a été rejeté par son pare-feu.