Rapport de projet : Tunneling DNS

Transcription

1 Rapport de projet de fin d année Auteur : Encadrants : ROJAT Antoine DALLOT Léonard 24/05/2012

2

3 Sommaire 1 Introduction Contexte Problème à Résoudre Aperçu de la solution Objectifs du projet Organisation & Outils Organisation du Projet Conception & Développement : Outils SVN L A TEX PYTHON BOUML INKSCAPE Description des protocoles DNS (Domain Name System) La structure du DNS Les serveurs de noms de domaines Format des paquets DNS HTTP (Hypertext Transfer Protocol) Les communications HTTP Les requêtes Les réponses Les méthodes HTTP TCP (Transport Control Protocol) UDP (User Datagram Protocol) Conception & développement Introduction Entités Fonctionelles Échanges Protocolaires Les étapes de traitement et d acheminement d une requête HTTP Entre le client HTTP et le proxy Entre le proxy et le serveur DNS Entre le serveur DNS et le serveur HTTP Les étapes de traitement et d acheminement d une réponse HTTP Entre le serveur DNS et le proxy Entre le proxy et le client HTTP La fragmentation et le réassemblage des messages HTTP La fragmentation des messages Le réassemblage des messages Quelques fonctions intéressantes Synthèse & Bilan Outils et développement Gestion Projet Les fonctionnalités Quelques exemples Exemple d une transaction : côté proxy Exemple d une transaction : côté serveur DNS Exemple d une question DNS Exemple d un acquittement Exemple d une question de type REP

4 6.6 Exemple d une réponse DNS Exemple de documentation Liste des figures 40 Liste des tableaux 41 Liste des algorithmes 42 Liste des programmes 43 Références bibliographiques 44

5 1 Introduction 1.1 Contexte Dans le cadre de la première année d études en master informatique option Ingénierie des Réseaux et des Systèmes de l université de Versailles Saint-Quentin-en-Yvelines, j ai choisi comme projet de fin d année la réalisation d un outil logiciel permettant d encapsuler des messages HTTP (Hypertext Transfer Protocol) dans des messages DNS (Domain Name System). Ce rapport a été rédigé pour : 1. Documenter le fonctionnement des modules logiciels implémentés dans le cadre de ce projet d étude. 2. Décrire les échanges entre les entités fonctionnelles du système. 3. Fournir les détails techniques relatifs à l implémentation. 1.2 Problème à Résoudre Dans les zones urbaines ou à forte densité (ex. aéroports), plusieurs points d accès Wi-Fi (encore appelés HotSpots ) ont été déployés pour permettre un accès généralisé à Internet. Néanmoins, l accès à Internet via ces points d accès n est pas ouvert à tous les utilisateurs. Le modèle communément déployé est de rediriger les demandes de connexion vers un portail captif pour inviter l utilisateur à renseigner ses données de connexion (ex. carte prépayée, mot de passe, etc.). En plus des attaques de brute force pour détecter des mots de passe valides, d autres solutions se basant sur les failles protocolaires sont envisageables. Dans le cadre de ce projet d étude, nous nous focalisons sur l investigation et la mise en œuvre des solutions permettant de contourner les mécanismes de filtrage et pouvoir ainsi accéder à Internet. 1.3 Aperçu de la solution Le service DNS est une composante critique pour le service d accès à Internet. En effet, le DNS permet d associer un nom de domaine (ex. mondomaine.fr ) à une adresse IP. Ce service n est pas convenablement filtré dans certains points d accès voire même les messages DNS ne sont pas filtrés par les points d accès. Cette défaillance peut être exploitée par un utilisateur malveillant pour accéder à Internet d une manière frauduleuse. Pour ce faire, il suffit de modifier un client pour encapsuler tous les messages IP dans des messages DNS. Ces messages DNS encapsulant des paquets IP seront envoyés vers un faux serveur DNS dont la tâche est de décapsuler ces messages et de les relayer vers la destination ultime. Pour démontrer la faisabilité de cette approche, nous utiliserons le service HTTP comme exemple. Ainsi, les messages HTTP seront encapsulés dans des messages DNS pour contourner les politiques de filtrage configurées dans les points d accès. 1.4 Objectifs du projet Les objectifs de ce projet sont : 1. Comprendre le fonctionnement des protocoles DNS et HTTP. 2. Modéliser le comportement des entités fonctionnelles (Client HTTP, Serveur HTTP, Proxy HTTP, Serveur DNS). 3. Implémenter les modules logicielles pour encapsuler et décapsuler les messages HTTP dans des messages DNS. 4. Tester et valider les entités fonctionnelles intervenant dans la réalisation de la procédure de contournement des filtres de sécurité. 1 INTRODUCTION page 1 sur 45

6 2 Organisation & Outils 2.1 Organisation du Projet Ce projet d étude est structuré en plusieurs étapes comme indiqué ci-dessous : 1. Documentation & Préparation (01/03/2012 au 31/03/2012) (a) Problèmeà résoudre : La première tâche de ce projet était de comprendre le problème à résoudre. Un travail de recherche a été entamé pour se familiariser avec les architectures réseaux et particulièrement les architectures hotspot. (b) Recherche documentaire. (c) Familiarisation avec les protocoles impliqués (ex., DNS, HTTP, IP, etc.). Le but de cette étape est de comprendre le fonctionnement ainsi que le rôle de chacun des protocoles impliqués dans le système d encapsulation DNS, sujet de ce projet. En effet, le protocole DNS permet de maintenir une association entre un nom de domaine et une adresse IP. Quant au protocole HTTP, il permet d accéder à des ressources localisées sur Internet. Ces ressources sont identifiées par des URLs sous forme de noms de domaine. Mais pour accéder à ces ressources, une résolution à l aide du DNS de l URL vers une adresse IP est nécessaire. Une fois que cette adresse IP est récupérée, des messages HTTP sont ensuite envoyés vers cette adresse. Les messages HTTP sont transportés sur TCP alors que les messages DNS sont généralement transporté sur UDP (TCP peut être aussi utilisé). Cette phase a permis de : i. Comprendre les échanges DNS et HTTP. ii. Assimiler la structure globale des protocoles DNS et HTTP. iii. Assimiler le format des messages DNS : Cet effort est important pour identifier les parties d un message DNS qu on pourra ensuite utiliser pour transporter des messages HTTP. iv. Comprendre le fonctionnement des deux protocoles de transfert TCP et UDP. 2. Réalisation & Validation (01/04/2012 au 10/05/2012) (a) Modélisation UML (b) Sélection du langage de programmation Java vs. Python. Notre choix s est porté sur Python pour les raisons suivantes : i. Syntaxe claire et concise. ii. Simplicité. iii. Facilité de maintien du code. iv. Rapidité et efficacité. (c) Réalisation du code i. Identification des entités fonctionnelles requises pour la mise en oeuvre de la solution d encapsulation DNS : Client HTTP, Serveur HTTP, Proxy HTTP, Serveur DNS. ii. Définir les échanges protocolaires basiques entre ces entités fonctionnelles (voir la figure cidessous). Pour ce faire, des diagrammes UML ont été produits. 2 ORGANISATION & OUTILS page 2 sur 45

7 serveur DNS message DNS message HTTP serveur http Figure 1 Echanges protocolaires iii. Identification des messages DNS à utiliser pour encapsuler des messages HTTP. iv. Implémenter les modules logiciels nécessaires. Cette phase a été entreprise en plusieurs sousétapes incrémentales : Étape 1 : Cette étape consiste à développer un programme client/serveur avec un client capable d envoyer des requêtes DNS alors que le serveur a pour rôle d afficher les requêtes reçues sur son écran. Un exemple d utilisation est lorsque l utilisateur saisi un message, le client (ou le proxy) construit une entête de type question standard (i.e., QR = 0, OPCODE = 0 ) et transforme le message saisi pour respecter le format utilisé pour stocker les noms de domaine. En d autres termes, il transforme le message en une chaîne de caractères précédée par un chiffre indiquant le nombre de caractères de la chaîne. Ce chiffre est calculé en comptant le nombre de caractères entre le début de la chaîne et un point (. ) et ainsi de suite jusqu au dernier point représentant la racine (. ). L identification dans l entête est unique car elle est générée de manière aléatoire. Par exemple, le nom de domaine uvsq.fr. est stocké sous la forme suivante : 4uvsq2fr0. Étape 2 : Suite à l étape précédente, le serveur répond au client en respectant le format d une réponse DNS. Le serveur construit une entête et y ajoute la question reçue et une réponse. Les valeurs des champs sont choisies d une manière arbitraire car le but de cette phase est de vérifier si la réponse respecte les conventions DNS et non la validité des données. Plusieurs problèmes ont été rencontrés lors de cette phase, particulièrement la gestion des noms de domaine ainsi que la manière dont ils sont stockés. En effet, pour les réponses on n enregistre pas le nom de domaine en entier mais on sauvegarde seulement la position du nom de domaine dont la réponse a été trouvée. Par exemple, si la réponse a été trouvée pour un nom de domaine, le nom de domaine de la réponse aura comme valeur 12. Étape 3 : Pour cette étape, on s est focalisé sur le problème lié à la taille des questions étant donné que le DNS n accepte que des questions de petite taille. La même contrainte s applique pour les réponses sauf que le DNS accepte des réponses de tailles un peu plus grande par rapport aux questions. Pour résoudre ce problème, on a opté pour la fragmentation des messages DNS. Étape 4 : Après la phase d implémentation de la fragmentation et de réassemblage des messages DNS, un serveur HTTP simple a été mis en œuvre. Ce serveur est utilisé pour répondre aux requêtes reçues de la part d un proxy. Étape 5 : Une dernière étape était de finaliser la partie client HTTP pour récupérer les réponses HTTP. Le client HTTP est lié directement au serveur DNS. 2 ORGANISATION & OUTILS page 3 sur 45

8 (d) Tests et validation basique des modules logiciels implémentés 3. Suivi & Synthèse (01/03/2012 au 10/05/2012) (a) Points réguliers avec les encadrants pour présenter l état d avancement du projet. (b) Rédaction du rapport de projet. L outil LATEX a été utilisé pour cet effet. 2.2 Conception & Développement : Outils SVN Dans un contexte de développement en groupe et pour permettre aux encadrants de suivre l état d avancement du code, l outil SVN a été utilisé. En effet, SVN est un logiciel de gestion de versions, distribué sous licence Apache et BSD. SVN est un système de gestion de versions multiples de fichiers. SVN supporte en particulier les fonctionnalités suivantes : Les fichiers à contrôler sont confiés à un serveur Subversion centralisé. Plusieurs protocoles réseaux (ex. HTTP/HTTPS si le serveur supporte SSH) peuvent être utilisés pour y accéder. L utilisateur interagit avec le serveur via une interface locale (client) qui peut être un logiciel autonome ou une extension d un logiciel support (explorateur de fichiers, environnement de programmation). L utilisateur récupère une copie locale des fichiers, les modifie puis soumet sa nouvelle version accompagnée d un commentaire. Si le fichier mis à jour a été modifié par un autre utilisateur entre temps, une notification est généré par SVN. Pour les fichiers texte ASCII (source C par exemple), SVN permet de créer un nouveau fichier tenant en compte toutes les modifications (revues ligne par ligne). Les fichiers autres que texte ASCII, dits binaires, sont aussi pris en charge (ex. doc, xls, etc.). La fusion des modifications étant plus délicate que pour le texte simple, SVN offre un mécanisme de verrou pour prévenir les modifications concurrentes L A TEX Pour rédiger les documents pour rapporter l état d avancement du projet ainsi que pour ce présent document, L A TEX a été imposé par les encadrants. L A TEX est un langage et un système de composition de documents. Il est devenu la méthode privilégiée d écriture de documents scientifiques. Il est particulièrement utilisé dans les domaines techniques et scientifiques pour la production de documents. Avant de rédiger mes rapports hebdomadaires, une phase d apprentissage de L A TEX a été nécessaire car c est la première fois que j utilise un outil d éditions de texte de ce genre PYTHON Après une première phase de comparaison entre Java et Python, le choix a été porté sur Python pour la réalisation des modules logiciels. Python est un langage de programmation sous une licence libre proche de la licence BSD, libre et gratuit. Le langage est portable puisqu il fonctionne sur la plupart des plates-formes informatiques, des supercalculateurs aux ordinateurs centraux, de Windows à Unix en passant par Linux et Mac OS. Il permet de développer de façon modulaire et orienté objet [Zia06][Pyt]. Python est un langage conçu pour produire du code portable et facile à intégrer. La syntaxe du langage Python est concise et simple. Le code Python ressemble à un pseudo-code ce qui permet au développeur d optimiser le temps de développement. Les commentaires Les commentaires en Python sont préfixés par le caractère #, et peuvent être placés en fin d une ligne ou prendre une ligne complète. Programme 1 Exemples de commentaires # Un commentaire print Hello world #un autre commentaire 2 ORGANISATION & OUTILS page 4 sur 45

9 Les structures de contrôle L instruction if est associée à une expression se terminant par le caractère : Programme 2 Exemple d instruction if # tester le plus grand if ( 5 > 3 ) : print je suis le plus grand! else : print Non, pourquoi pas moi L instruction for permet d exécuter un bloc de lignes en fonction d une séquence. Programme 3 Exemple d instruction for # afficher les elements du tableau tab= [0, 1, 2, 3, 4, 5] for elt in tab : print elt L instruction while permet d exécuter un bloc de lignes tant qu une condition est satisfaite. Lorsque l expression booléene n est plus vérifiée, l instruction else est exécutée s il existe et la boucle s arrête. Programme 4 Exemple dínstruction while # afficher les elements du tableau tab = [0, 1, 2, 3, 4, 5] long = len(tab) index = 0 while ( index < long) : print tab{[} index {]} index += 1 else : print fin fin BOUML Pour les besoins de modélisation et développement objet, l outil BOUML a été choisi pour cet effet. BOUML est un logiciel simple, efficace et gratuit. BOUML ne nécessite pas de configuration complexe. BOUML est un logiciel de création de diagrammes UML. Programmé en C++ et Qt, il est distribué sous licence propriétaire depuis la version 5.0. Il est multilingue. BOUML fonctionne sous plusieurs plateformes (ex. Linux et Windows).[bou] BOUML est composé du modeleur lui-même, et d une série de programmes externes appelés (Plug out). Un plug-out est un programme défini avec BOUML. Le principal Plug out existant est : Générateur C++, Java, Php et Python, etc INKSCAPE Inkscape est un logiciel libre de dessin vectoriel sous licence GNU/GPL. Il est conforme avec les standards XML, SVG et CSS du W3C. INKSCAPE se base sur le format de fichier standardisé SVG et propose à ce titre un grand nombre d éléments reconnus par ce format : formes élémentaires, chemins, clones, transformations, opérations booléennes, gradients, groupements, calques. L interface est développée sous GTK. 2 ORGANISATION & OUTILS page 5 sur 45

10 3 Description des protocoles 3.1 DNS (Domain Name System) La structure du DNS Le protocole DNS (Domain Name System) se base sur un système d attribution hiérarchique, appelé nom de domaine. Ce système hiérarchique, sous forme d arbre, permet d éviter la redondance des noms de domaine. racine non nommé. domaines top niveau a-arpa com gov net fr... us domaine second niveau 140 uvsq 252 etu domaines génériques domaines géographiques Tableau 1 Organisation hiérarchique du DNS [Ste99]. Chaque nœud de l arbre DNS a : Un label de 63 caractères maximum sauf pour la racine ayant un label nul. Les minuscules et les majuscules ne sont pas différenciés. Un nom de domaine unique : Ceci est la liste des labels entre ce nœud et la racine. Le nom de domaine est désigné par l arborescence complète de son nom appelée FQDN (Fully Qualified Domain Name). Note : Un nom de domaine (ou FQDN) qui se termine par un point est appelé nom de domaine absolu (ex. etu.uvsq.fr. ). Il existe trois types de niveaux supérieurs DNS [SER03] : 1. Les domaines (ex. fr, us, etc.) sont appelés les domaines pays. Ces domaines sont généralement composés de deux caractères. 2. Les domaines génériques qui sont formés de trois caractères. La liste ci-dessous énumère ces noms de domaine ainsi que l usage prévu pour chacun de ces domaines : Com : affecté à des organisations commerciales; Edu : affecté à institutions éducatives; Gov : affecté à organisations gouvernementales américaines; Int : alloué à des organisations internationales; Mil : alloué pour les militaires (particulièrement US); Net : affecté à organisations du réseau Internet; Org : affecté à des organisations non commerciales et non gouvernementales; Aero : ce domaine est réservé aux entreprises du secteur aéronautique; Biz : alloué aux entreprises commerciales; Coop : affecté pour les coopératives; Museum : affecté aux musées. Chaque extension est gérée par une entité appelée Registre, Registry ou encore office d enregistrement. Cet organisme a pour mission d enregistrer les noms de domaine assortis de l extension dont il a la charge (ICANN) et de les lister dans une base de données (registre) dont il assure la bonne tenue et le maintien. Ex : C est l entreprise Verisign Inc. Qui gère les extensions.net et.com. 3 DESCRIPTION DES PROTOCOLES page 6 sur 45

11 ICANN (Internet Corporation for Assigned Names and Numbers) : organisation de droit privé à but non lucratif chargée: d allouer l espace des adresses de protocole Internet (IP), d attribuer les identificateurs de protocole, de gérer le système de nom de domaine de premier niveau pour les codes génériques et les codes nationaux, et d assurer les fonctions de gestion du système de serveurs racines. AFNIC (Association Française pour le Nommage Internet en Coopération) : Créé en 1998, c est l organisation qui prend le relai de l ICANN au niveau français. Elle gère les noms de domaine en.fr ( plus de 2 millions en 2011). 3. Le domaine arpa est un domaine utilisé pour la correspondance adresse IP vers un nom de domaine. Une société dont le réseau est connecté à Internet obtient l autorité pour une partie de l espace d adressage DNS et pour la portion d espace d adressage de noms du in-addr.arpa correspondant à leurs adresses IP. Exemple : Pour le cas du domaine uvsq.fr, il est associé à la plage d adresses IP La machine soleil raccordée au réseau de l université UVSQ et dont l adresse IP est , son nom de domaine DNS correspond à in-addr.arpa Les serveurs de noms de domaines 1. Introduction Les serveurs de noms sont dépositaires de l information qui constitue la base de données des domaines. La base de données est divisée en sections appelées zones. Ces zones sont distribuées sur l ensemble des serveurs de noms. Comme les serveurs de noms peuvent implémenter des fonctions optionnelles et des sources de données différentes, la tâche essentielle d un serveur de nom reste de répondre à des requêtes sur ses données propres. Par conception, les serveurs de noms peuvent répondre à ces requêtes d une manière simple, la réponse peut toujours être générée à partir des seules données locales, et contiendra soit la réponse à la question posée, soit une référence à un autre serveur de noms plus susceptible d avoir l information demandée. 2. Les zones Les zones sont des sous arbres de l arbre DNS, l un des objectifs de cette structure en zones est que toute zone puisse disposer localement de toutes les données nécessaires pour communiquer avec les serveurs de noms de chacune de ses sous-zones. En d autres termes, les zones mères disposent de toute l information requise pour accéder aux serveurs des zones filles. Par exemple, une université peut subdiviser en zones basées sur des départements; ces zones peuvent à leur tours être subdivisées en sous-zones pointant vers les spécialités d un même département. Chaque zone doit avoir ses serveurs de noms puisque il existe deux types de serveurs primaires et secondaires qui sont indépendants entre eux. Serveurs primaires : chargent toutes les informations concernant la zone à partir de fichiers disque. Serveurs secondaires: Ces serveurs obtiennent les informations de la zone à partir des serveurs primaires. Cette opération est appelée transfert de zone. Serveurs caches : Le serveur cache ne constitue sa base d information qu à partir des réponses des serveurs de noms. Il inscrit les correspondances nom / adresse IP dans un cache avec une durée de validité limitée (TTL (Time To Live)); il n a aucune autorité sur le domaine : il n est pas responsable de la mise à jourdes informationscontenuesdans son cache,maisil est capablede répondreaux requêtes des clients DNS. De plus, on peut distinguer les serveurs racines : ils connaissent les serveurs de noms ayant autorité sur tous les domaines racine. Les serveurs racine connaissent au moins les serveurs de noms pouvant résoudre le premier niveau (.com,.edu,.fr, etc.) C est une pierre angulaire du système DNS : si les serveurs racine ne sont pas opérationnels, il n y a plus de communication sur l Internet. C est pour cette raison qu il y a plusieurs serveurs racines (actuellement il y en a 14). Chaque serveur racine reçoit environ requêtes par heure. 3. Les requêtes et les réponses Les serveurs de noms ont la responsabilité de répondre aux requêtes. La manière dont le serveur de noms répond peut être différente selon que le serveur utilise le mode récursif ou non. 3 DESCRIPTION DES PROTOCOLES page 7 sur 45

12 Le mode itératif : Le mode non-récursif (itératif) signifie que le serveur peut répondre à la requête uniquement sur la base de ses informations locales : la réponse contient une erreur, la réponse demandée, ou donne la référence d un autre serveur plus susceptible de disposer de l information demandée. Tous les serveurs de noms se doivent d implémenter le mode non-récursif. Le mode récursif : Le mode récursif signifie que le serveur ne peut retourner qu un message d erreur ou une réponse valide, mais jamais de référence. L utilisation du mode récursif est limité aux cas qui résultent d un accord négocié entre le client et le serveur. Cet accord est négocié par l utilisation de deux bits particuliers des messages de requête et de réponse : Le bit RA (Récursion admissible), est marqué ou non par le serveur dans toutes les réponses. Ce bit est marqué si le serveur accepte de fournir le service récursif au client, que ce dernier l ait demandé ou non. Autrement dit, le bit RA signale la disponibilité du service plutôt que son utilisation. Le bit RD (pour récursion désirée ). Ce bit indique que le requérant désire utiliser le service récursif pour cette requête. Les clients peuvent demander le service récursif à n importe quel serveur de noms, bien que ce service ne puisse leur être fourni que par les serveurs qui auront déjà marqué leur bit RA, ou des serveurs qui auront donné leur accord pour ce service par une négociation propriétaire ou tout autre moyen hors du champ du protocole DNS Format des paquets DNS Le protocole DNS utilise un format de messages commun pour tous les échanges entre serveurs ou entre clients et serveurs. Les messages DNS sont acheminés soit au dessus de UDP, soit au dessus de TCP. Dans les deux cas, le numéro de port prédéfini 53 est par défault utilisé. Si UDP est utilisé pour transporter les messages DNS, le protocole DNS ne gère pas la segmentation et impose une taille maximum de message DNS de 512 octets. A noter que le protocole UDP est utilisé par défaut; TCP pourrait être utilisé pour transporter des messages dépassant 512 octets. Tout message DNS a un en-tête de 12 octets de longueur fixe suivi de quatre champs de questions et de réponses de longueur variable. Le tableau ci-dessous illustre le format d un message DNS Identification Flags Nombre de questions Nombre de réponses Nombre de RRs autoriaires Nombre de RRs supplémentaires Questions Réponses Réponses Réponses Tableau 2 Format générique d un message DNS Identification Le champ Identification est un champ de 16 bits. Ce champ permet d identifier une transaction (ID) DNS spécifique. L ID de transaction est créée par l expéditeur du message (i.e. Client DNS) et est copié par le répondeur (i.e., Serveur) dans son message de réponse. A l aide de ce champ, le client DNS peut garantir la correspondance entre les réponses et les requêtes. 3 DESCRIPTION DES PROTOCOLES page 8 sur 45

13 Flags Le champ flags est codé sur 16 bits. Ce champ est structuré comme suit : QR OP CODE AA TC RD RA Réservé RCode 1 bit 4 bits 1 bit 1 bit 1 bit 1bit 3 bits 4 bits Tableau 3 Les champs flags. Le champ QR permet d identifier le type du message, deux valeurs sont possibles : 0 : pour les requêtes DNS; 1 : pour les réponses DNS. Le champ OPCode est codé sur 4 bits. Ce champ permet de spécifier le type de la requête : 0 : Requête standard (encore appelée Query ); 1 : Requête inverse (encore appelée Iquery ); 2 : l état d une requête serveur (encore appelée Status ); 3-15 : Ces valeurs sont réservées pour des utilisations futurs. Le champ AA (Authoritative Answer) indique la réponse d une entité autoritaire. Ce champ peut avoir les valeurs suivantes : 0 : Serveur autoritaire; 1 : Cache DNS. Le champ TC (Truncated) est codé sur un 1 bit. TC permet de déterminer si le message a été tronqué ou pas (ex. le message est trop grand). TC est positionné à 1 si le message est tronqué. Si UDP est utilisé, seuls les 512 premiers octets de la réponse UDP sont acheminées vers le client. Pour supporter le message dépassant 512 octets, il est recommandé d utiliser le mode connecté (i.e., TCP). Le champ RD (Recursion Desired) est utilisé pour indiquer une demande de résolution récursive (RD = 1 ) ou une résolution itérative (RD = 0 ). Le champ RA (Recursion Available) indique si la récursion est autorisée (RA = 1 ). Le champ Reserved est codé sur 3 bits. La valeur de ce champ est 0. Le champ Rcode, codé sur 4 bits, indique le type de la réponse envoyée par le serveur DNS : 0 : Pas d erreur 1 : Erreur de format dans la requête 2 : Problème côté serveur 3 : Le nom demandé n existe pas 4 : Non implémenté 5 : Refus 6-15 : Réservés Le nombre d enregistrements de ressource Les autres champs de l entête DNS ont tous une longueur de 16 bits : Nombre d enregistrements de ressource de question représente le nombre d entrées dans la section de la question du message DNS; Nombre d enregistrements de ressource de réponse représente le nombre d entrées dans la section réponse du message DNS; Nombre d enregistrements de ressource autoritaire représente le nombre d enregistrements de ressource d autorité dans le message DNS; Nombre d enregistrements de ressources supplémentaire représente le nombre d enregistrements de ressources supplémentaires dans le message DNS. 3 DESCRIPTION DES PROTOCOLES page 9 sur 45

14 Questions Qname Le format des champs questions est montré dans la figure ci-dessous. Nom de domaine Type de demande Classe de demande Figure 2 Format générique d une question DNS. Le champ Qname (i.e., Nom de Domaine), de longueur variable, contient le nom du nœud dont l adresse IP est recherchée. Les noms de domaine DNS sont exprimés en une série d étiquettes, telle que uvsq.fr, mais le champ Qname est codé comme une série de paires de valeur longueur consistant en un 1 octet indiquant la longueur de la valeur, suivi de la valeur. Par exemple webmail-etu.uvsq.fr sera encodé comme le montre la figure ci-dessous. 11 W E B M A I L - E T U 4 U V S Q 2 F R 0 Figure 3 Format du champ nom de domaine. Chaque question a un type de question; ainsi chaque réponse a un type. Le tableau ci-dessous liste quelques valeurs possibles. Nom Valeur Description A 1 Adresse IP NS 2 Nom du serveur CNAME 5 Nom canonique HINFO 13 Info machine Tableau 4 Les valeurs des types de question Réponses Le trois champs finaux du message DNS partagent le même format appelé un enregistrement de ressource (RR), la figure ci-dessous montre le format d un enregistrement de ressource Nom de domaine Type de l enregistrement TTL Longueur champ Ressources Classe Ressources Figure 4 Format d un enregistrement de ressource DNS Un enregistrement de ressource est l ensemble d informations de ressources associées à un nom de domaine. Il est composé de quatre enregistrements de ressources séparés (RR). L ordre des RRs n est pas significatif et ne doit pas nécessairement être préservé par les serveurs de noms, les résolveurs, ou tout autre entité fonctionnelle DNS. Les RRs sont représentés sous forme binaire dans les paquets du protocole DNS et contiennent les éléments suivants : Owner : Indique le nom de domaine où le RR est associé. Type : Indique une valeur encodée sur 16 bits spécifiant le type de ressource décrit par cet enregistrement. Il définit les types suivants : A : Indique une adresse IPv4. Elle est stockée comme une valeur binaire binaire sur 32 bits pour indiquer une adresse IPv4. A noter que AAAA indique une adresse IPv6; 3 DESCRIPTION DES PROTOCOLES page 10 sur 45

15 CNAME : Indique le nom canonique d un alias; HINFO : Indique le CPU et le système d exploitation (OS) d un hôte; MX : Indique un schéma d échange de courrier pour ce domaine; NS : Indique le serveur de noms autorisé pour le domaine; PTR : Indique un pointeur vers une autre partie de l espace de noms de domaine; Class : une valeur encodée sur 16 bits; elle identifie une famille de protocoles ou une instance d un protocole. La classe suivante est la plus utilisée dans le système DNS : IN : Indique le système Internet. TTL : Indique la durée de vie d une ressource DNS (ex. RR). Cette valeur est représentée sous forme d un entier encodé sur 32 bits. TTL est exprimée en secondes. Elle est utilisée par les résolveurs lorsqu ils mémorisent temporairement des RRs. Le champ TTL définit combien de temps un RR peut être mémorisé localement avant de devoir être considéré comme obsolète. RDATA : Indique le type des données. Parfois, il indique les données dépendantes de la classe décrivant la ressource Le type : IN : une adresse IP sur 32 bits. La classe : CNAME : Un nom de domaine. MX : Une valeur de préférence sur 16 bits (la plus basse possible) suivie d un nom d hôte souhaitant servir d échangeur de courrier pour le domaine de l Owner. NS : Un nom d hôte. PTR : Une adresse IP sous forme d un nom de domaine. SOA : Plusieurs champs. 3.2 HTTP (Hypertext Transfer Protocol) Les communications HTTP Le protocole de transfert hypertexte (HTTP, HyperText Transfer Protocol HTTP) est le protocole le plus utilisé sur Internet depuis HTTP est un protocole de la couche application, il s appuie sur le protocole TCP comme protocole de transport. Le protocole HTTP est utilisé pour les communications entre les clients HTTP et les serveurs HTTP. La connexion entre ces deux entités n est pas toujours directe mais peut faire intervenir, comme pour ce projet de fin d année, une entité intermédiaire appelée Proxy. En plus d un proxy, d autres éléments intermédiaires comme les passerelles[fgm + 99] peuvent être impliqués dans une connexion HTTP. Le proxy agit comme un serveur puisque il reçoit les demandes des clients et il les envoie au serveur. Le proxy agit aussi comme un serveur quand il répond aux clients. Les questions et les réponses sont modifiées par le proxy pour insérer les identifiants des clients sources. Une passerelle est un serveur qui agit comme intermédiaire pour un autre serveur, il reçoit les demandes comme si la passerelle était le serveur d origine pour la ressource demandée Les requêtes Une requête HTTP est un ensemble de lignes envoyéespar un client HTTP vers à un serveur HTTP. La requête HTTP est sous la forme suivante :[LQ10] Méthode URL Version En-tête : valeur En-tête : valeur... Corps de la requête La première ligne de la requête comprend trois éléments séparés par un espace : La méthode (ex. GET, HEAD, POST, etc.) (voir 3.2.4); URL : La ressource demandée par le client; Version : la version du protocole utilisé. Les en-têtes HTTP et le corps de la requête correspondent à un ensemble de lignes optionnelles qui permettent d insérer plus d informations (ex. adresse IP) dans une requête. 3 DESCRIPTION DES PROTOCOLES page 11 sur 45

16 3.2.3 Les réponses La réponse HTTP est un ensemble de lignes envoyées au client HTTP par un serveur HTTP. La syntaxe d une réponse HTTP est constituée de trois parties : Version Code de réponse En-tête : valeur En-tête : valeur... Corps de la requête La première partie contient la version et le code de réponse. Ce code de trois chiffres indique l état de la transaction : 20x : Indique le bon déroulement de la transaction. 30x : Indique que la ressource n est plus à l emplacement demandé. 40x : Indique un erreur côté client. 50x : Indique un erreur côté serveur. L ensemble des entêtes contient des champs optionnels alors que la dernière partie contient la page web demandée Les méthodes HTTP GET : La plus utilisée par les clients HTTP. Elle permet de télécharger et de lire une ressource HTTP. HEAD : Similaire à la méthode GET mais ne demande que l entête du message. POST : Permet d envoyer des données au serveur, par exemple les données d un formulaire. CONNECT : Permet d utiliser un proxy comme un tunnel de communication. OPTIONS : Permet d obtenir les options disponibles pour obtenir la ressource. DELETE : Permet de supprimer une ressource. TRACE : Le serveur répond avec la même requête reçue. PUT : Utilisée pour ajouter ou modifier une ressource. 3.3 TCP (Transport Control Protocol) Le protocole de contrôle de transport TCP (Transport Control Protocol TCP) a été conçu pour fournir plus de fiabilité de bout en bout des connexions. En cas de fragmentation, TCP attribue à chaque fragment un numéro de séquence ce qui permet à la couche TCP de remettre en ordre les paquets reçus. Le protocole TCP fournit les fonctionnalités suivantes : Détection des erreurs de transmission Correction des erreurs de transmission Récupération de pertes et duplicatas de paquets Service orienté connexion fiable, il permet les connexions bidirectionnelles Le protocole TCP assure que chaque message est acquitté. Les acquittements peuvent être inclus dans des paquets de données normaux. TCP protège les paquets par une temporisation : si un paquet n est pas reçu pendant un temps d attente prédéfini, le message sera retransmis de manière à corriger cette erreur de transmission. En ce qui concerne les erreurs de la congestion, TCP les corrige en appliquant l algorithme de slow start. Cet algorithme permet d éviter la congestion du réseau puisque au début des connexions commencent par un débit lent augmenté graduellement et diminué rapidement en cas de congestion. La plupart des applications Internet sont envoyées au-dessus de TCP, c est le cas de telnet, FTP, SMTP et HTTP. 3 DESCRIPTION DES PROTOCOLES page 12 sur 45

17 3.4 UDP (User Datagram Protocol) Le protocole UDP (User Datagram Protocol UDP) est un protocole non orienté connexion de la couche transport du modèle TCP/IP. Le protocole UDP est une alternative à TCP pour les applications qui préfèrent utiliser le service non-connecté. UDP ne fournit pas le service de contrôle d erreurs puisque c est aux applications ellesmêmes d assurer la correction d erreurs et le contrôle de congestion. UDP est utilisé quand il est nécessaire soit de transmettre des données très rapidement, et où si la perte d une partie de ces données n affecte pas la communication. Par exemple dans le cas de la transmission de la voix sur IP, la perte occasionnelle d un paquet est tolérable; c est aussi le cas pour les applications de diffusion audio/vidéo. Le paquet UDP n est pas compliqué que celui du TCP car il ne contient que cinq champs : Port source : Indique le numéro de port utilisé par le client pour envoyer le paquet UDP; Port destination : Indique le numéro de port utilisé par le serveur distant pour recevoir le paquet UDP; Longueur UDP : la taille du contenu et de l entête; UDP Checksum : UDP permet de détecter les erreurs sur le contenu alors que IP permet la détection des erreurs sur entête; Contenu : les données envoyées. L utilisation du protocole UDP signifie que : La taille maximale pour les SDUs (Segment Data Unit) envoyés par une application est imposée par la taille des paquets IP; Le service fournit est sans connexion et non fiable; Il n y a aucune garantie sur l acheminement correct d un SDU et donc un SDU peut être perdu; Il n y a aucune garantie sur le respect de la séquence; Les paquets peuvent être dupliqués ou perdus. Plusieurs protocoles tels que DNS, RIP(Routing Information Protocol) ou SNMP (Simple Network Management Protocol) utilise UDP comme protocole de transport. 3 DESCRIPTION DES PROTOCOLES page 13 sur 45

18 4 Conception & développement 4.1 Introduction Le projet étudié dans ce mémo a pour but d implémenter et de valider une solution permettant de détourner les contrôles d accès à un service HTTP en exploitant le protocole DNS comme un protocole de transport. Ceci est possible parce que le protocole DNS n est pas filtré par les points d accès. Les protocoles applications (ex. HTTP) sont encapsulés dans des messages DNS. Cette section a pour objectif de décrire la procédure générale, les entités fonctionnelles ainsi que les échanges protocolaires entre ces éléments. La figure ci-dessous montre les entités fonctionnelles intervenant pour la réalisation de la procédure de contournement des filtres de sécurité implémentés par un point d accès (encore appelé hotspot ). serveur DNS réponse DNS réponse HTTP serveur http Figure 5 Schéma global de la procédure Entités Fonctionelles Les entités fonctionnelles suivantes interviennent pour la réalisation de la procédure de contournement des filtres de sécurité des point d accès : Client HTTP : Il dénote la partie de la procédure permettant d établir des connexions avec des serveurs HTTP. Particulièrement, le client HTTP a la responsabilité d afficher les pages HTTP telles que retournées par un serveur HTTP. Pour les besoins de la procédure décrite ci-haut, le client HTTP envoie ses requêtes par défaut à un proxy HTTP préconfiguré. Proxy HTTP (appelé aussi proxy) : Cet élément intervient comme entité intermédiaire entre le client HTTP et un serveur HTTP. Les messages échangés entre le proxy et le client HTTP sont des messages HTTP alors que les messages échangésentre le proxy et le serveur DNS sont des messages DNS. Les messages HTTP reçus de la part d un client HTTP sont encapsulés dans des messages DNS. La requête HTTP est stockée dans le champ Qname du message DNS. Serveur DNS : Le serveur sert de passerelle entre le proxy et l accès à internet. Lorsque le serveur DNS reçoit un message DNS contenant une requête HTTP, et après l extraction de la requête HTTP, il transfère la requête vers le serveur HTTP. Une fois la réponse HTTP est reçue par le serveur DNS, elle est fragmentée et envoyée au proxy. Serveur HTTP : Le serveur HTTP est une machine connectée à Internet et qu héberge un serveur HTTP. 4 CONCEPTION & DÉVELOPPEMENT page 14 sur 45

19 Hotspot (ou Point d accès) : Le hotspot est un point d accès à un réseau Wi-Fi conçu par les fournisseurs d accès à Internet (FAI). Toute demande de connexion est orientée vers un portail captif pour demander à l utilisateur de s authentifier. Seuls les utilisateurs ayant les droits d accès peuvent se connecter à Internet. Il existe plusieurs types de hotspots : hotspots payants hotpsots publics hotspots privés Échanges Protocolaires La procédure décrite dans ce mémo fait appel aux échanges suivants : Entre le client HTTP et le proxy : Le client HTTP est configuré à envoyer toutes les requêtes HTTP vers un proxy. Entre le proxy et le serveur DNS : Le proxy fragmente et transfère les requêtes vers le serveur DNS. Les messages HTTP sont alors encapsulés dans des messages DNS. Quant au serveur DNS, il réassemble la requête HTTP puis la transfère vers le serveur HTTP destination. Pour toute réponse reçues de la part d un serveur HTTP, le serveur DNS la fragmente, l encapsule dans un message DNS et la transfère vers le proxy HTTP. Entre le serveur DNS et le Serveur HTTP : La comminication entre ces deux entités se fait en HTTP. 4.2 Les étapes de traitement et d acheminement d une requête HTTP Entre le client HTTP et le proxy Le client HTTP est configuré de telle manière à envoyer ses requêtes HTTP vers un proxy et non directement au serveur HTTP. La configuration du client HTTP est simple puisque il suffit de changer les paramètres concernant le proxy du client HTTP. Une tâche importante de ce projet est de développer un serveur HTTP permettant de récupérer les requêtes HTTP et d en extraire tous les éléments pour faciliter le fonctionnement du serveur DNS. Cette section décrit les tâches réaliséespar le proxy et le client HTTP. Si l une de ces tâches n est pas accomplie, le programme logiciel ne fonctionnera pas. la communication entre le proxy DNS et le serveur HTTP envoyer la requête HTTP client HTTP envoyer les réponses HTTP proxy Figure 6 Diagramme use cases : client HTTP - proxy Comme le montre la figure ci-dessus, un client HTTP est censé envoyer des requêtes et de recevoir des réponses HTTP. Le client HTTP fournit plusieurs tâches : La requête HTTP contenant la méthode utilisée, l URL du site désiré et la version du protocole HTTP utilisé. Les clients HTTP utilisent principalement la version HTTP1.1. Une requête a le format suivant : Méthode URL Version Exemple : Get http :// HTTP/1.1 4 CONCEPTION & DÉVELOPPEMENT page 15 sur 45

20 L extraction de la méthode utilisée permet de savoir si les données envoyées par le client HTTP contiennent des données supplémentaires La méthode GET : Si la méthode utilisée est GET, le proxyenverrala requête reçue, la versiondu protocole HTTP et les en-têtes HTTP. La méthode POST : Le proxy est obligé de récupérer les données cachées dans un fichier nommé rfile de l objet BaseHTTPRequestHandler de la classe BaseHTTPServer. Ces informations sont saisies par l utilisateur (ex. nom et mot de passe, la transaction souhaitée). Le proxy gère ce cas en exécutant cette portion du code Programme 5 Extraire les informations cachées dans le fichier rfile # on teste la methode utlisee if ( (s. command). upper () == POST ) : # si oui, on lit autant de caracteres que le header Content Length authenticity_token= s. rfile. read(int(s. headers [ Content Length ]) ) Le proxy récupère ainsi les en-têtes liées à la requête HTTP. Ces en-têtes sont eux même envoyées au serveur DNS. Dans notre programme les en-têtes peuvent être une liste ou une collection. Exemple : liste : [( Host, ),( Content-Type, text/html; utf-8 )] collection : { Content-Type : text/html; utf-8, Host : } Le proxy enregistre ces données dans un tableau sous la forme suivante : méthode requête versionhttp headers Tableau 5 Format d un message envoyé au serveur DNS Entre le proxy et le serveur DNS Le proxy et le serveur DNS sont les éléments critiques pour le bon déroulement de la procédure d encapsulation DNS. Le proxy communique avec le client HTTP tandis que le serveur DNS communique avec le serveur HTTP. La figure ci-dessous illustre l ensemble des tâches réalisées par ces deux entités fonctionnelles. la communication entre le proxy et le serveur DNS analyser et fragmenter si nécessaire la requête HTTP créer les messages DNS et intégrer les fragments HTTP envoyer les messages DNS serveurdns proxy ré-assembler la requête HTTP fragmenter la réponse HTTP envoyer le nombre de réponses DNS (NBR_REP) envoyer NBR_REP de messages DNS envoyer les réponses DNS Figure 7 Diagramme uses cases :proxy - serveur DNS 4 CONCEPTION & DÉVELOPPEMENT page 16 sur 45

21 Comme le montre la figure ci-dessus, chacune de ces deux entités fonctionnelles réalise une partie des tâches : Après la réception des requêtes HTTP, le proxy réalise les tâches suivantes : Fragmenter les requêtes HTTP si nécessaire; Construire les requêtes DNS; Intégrer le fragment HTTP dans la partie question des messages DNS; Envoyer les requêtes DNS construites; Une fois le nombre de réponses attendues est reçu, le proxy envoie les requêtes DNS. Tandis que le serveur DNS réalise les tâches suivantes : Recevoir les requêtes DNS; Envoyer des acquittements; Ré-assembler les messages HTTP; Recevoir les réponses HTTP; Fragmenter les réponses HTTP; Construire les réponses DNS; Envoyer les réponses DNS. Le proxy Après la réception d une requête HTTP, le proxy analyse les données reçues pour vérifier si la taille ne dépasse pas un seuil prédéfini. Si le proxy ne procède pas à cette vérification lorsqu il reçoit un message de la part du client HTTP, le message sera reconnu comme un paquet mal formé. La figure ci-dessous montre les étapes suivies après la réception d une requête par le serveur DNS. recevoir la requête HTTP requête reçue [len(data)> 20] non oui fragmenter la requête requête fragmentée intégrer la requête HTTP dans la question DNS intégrer les fragments HTTP dans les question DNS requête HTTP intégrée pour tous les fragments HTTP envoyer la requête DNS pour tous les messages DNS message DNS envoyé Figure 8 Diagramme d état :proxy - serveur DNS Comme le montre la figure ci-dessus, le proxy peut recevoir des requêtes de tailles différentes. En effet deux cas sont possibles : 1. Une taille de données inférieure au seuil fixé par le proxy (20 caractères par message DNS). 2. Une taille de données qui est plus grande que le seuil. 4 CONCEPTION & DÉVELOPPEMENT page 17 sur 45

22 Dans le premier cas, le proxy construit directement le message DNS et y intègre les données dans sa partie consacrée aux questions. Par contre dans le deuxième cas, le proxy est obligé de fragmenter la requête HTTP reçue. Après la fragmentation de la requête HTTP, le client stocke les fragments dans un tableau et commence à construire les messages DNS de type question standard ( QR = 0, OPCODE = 0 ). La valeur 0 du champ QR signifie que le message est une question; la valeur 0 du champ OPCODE signifie que le message est une question standard (Standard Query). Chaque message DNS est envoyé directement au serveur DNS puisque le proxy n attend pas la fin de la construction des autres messages DNS. A noter que la même valeur du champ Identification ID doit être préservée. Une fois le proxy termine d envoyer tous les fragments, un message DNS supplémentaire est envoyé au serveur DNS dans le but est de lui permettre de répondre avec un message DNS contenant le nombre de réponses qu il possède. La figure ci-dessous montre les étapes suivies par le proxy dés qu il reçoit une requête HTTP. :proxy :serveurdns vérifier la taille du message [len(data)>20 =?] alt : len(data)>20 fragmenter le message DNS loop NBR_FRAG créer une requête DNS insérer le fragment HTTP envoyer le message DNS envoyer l'acquittement du message envoyer un message DNS supplémentaire créer la requête DNS insérer la question HTTP dans le message DNS envoyer la requête DNS envoyer un message supplémentaire envoyer un acquittement Figure 9 Diagramme de séquence : les étapes suivies lors de l envoi des requêtes 4 CONCEPTION & DÉVELOPPEMENT page 18 sur 45

23 Le serveur DNS Le serveur DNS reçoit les questions DNS et les stocke dans un tableau. Chaque question reçue doit être acquittée par le serveur DNS. Les messages redondants sont rejetés directement puisque le serveur DNS vérifie l identification et le numéro de séquence de chaque fragment. Si ce fragment existe déjà dans le tableau des fragments, le serveur ne l enregistre pas. Après la réception de tous les fragments, le serveur DNS réassemble le message DNS. La figure ci-dessous illustre le comportement du serveur DNS lorsqu il reçoit une requête DNS. recevoir la question DNS message reçu [ nbr_frag > 1 && nbr_msg_reçu!= nbr_frag ] oui non ré-assembler le message HTTP message ré-assemblé envoyer la question au serveur HTTP question envoyée Figure 10 Diagramme d état : Réception des questions par le serveur DNS Comme le montre la figure ci-dessus, le serveur DNS reçoit les questions et vérifie le numéro du fragment ainsi que le nombre des messages reçus. Si le nombre des fragments est plus que 1 et le nombre des messages reçus est égal au nombre de fragments total, le serveur DNS passe à l étape suivante (i.e., le réassemblage de la requête HTTP). Après le réassemblage, le serveur DNS transfère cette requête vers le serveur HTTP Entre le serveur DNS et le serveur HTTP La figure ci-dessous résume les tâches réalisées par le serveur HTTP et le serveur DNS. la communication entre le serveur DNS et le serveur HTTP envoyer la requête HTTP serveur DNS envoyer la réponse HTTP serveur HTTP Figure 11 Diagramme d état : serveur DNS et serveur HTTP 4 CONCEPTION & DÉVELOPPEMENT page 19 sur 45