Technique de défense dans un réseau

Technique de défense dans un réseau Projet présenté dans le cadre des Bourses d'excellence ASIQ 2011-2012 Présenté par : Frédérik Paradis fredy_14@live.fr Gregory Eric Sanderson gzou2000@gmail.com Louis-Étienne Dorval ledor473@hotmail.com Simon Perreault perreault.simon@hotmail.com Sous la supervision de : François GAGNON (enseignant) francois.gagnon1@cegep-ste-foy.qc.ca Département de l informatique Techniques de l informatique Cégep de Sainte-Foy Hiver 2012

Table des matières 1 Introduction...4 2 Qu'est-ce que le spoofing?...4 3 Le but de la recherche...5 4 Les protocoles...6 4.1 Address resolution protocol (ARP)...6 4.1.1 Entête...6 4.1.2 Déroulement...7 4.2 Dynamic Host Configuration Protocol (DHCP)...8 4.2.1 Déroulement...8 4.3 Domain Name System (DNS)...10 4.3.1 Déroulement...10 5 Type de spoofing...11 5.1 ARP spoofing...11 5.1.1 Attaque...11 5.1.1.1 ARP Reply Spoofing...11 5.1.1.2 ARP Request Spoofing...12 5.1.2 Défense...13 5.1.2.1 Au niveau du système d'exploitation...13 5.1.2.2 Système de détection...13 5.2 DHCP spoofing...15 5.2.1 Rogue DHCP...15 5.2.1.1 Défense...16 5.2.2 DHCP Starvation...16 5.2.2.1 Défense...17 5.2.3 Libération d'adresse IP du réseau...18 5.2.3.1 Défense...18 5.3 DNS spoofing...19 5.3.1 Falsification d'une réponse...19 5.3.1.1 Défense...19 5.3.2 Empoisonnement du cache DNS...21 5.3.2.1 Défense...21 6 Prototypes...22 6.1 Attaquant...22 6.1.1 Reply ARP Service...22 6.1.2 ARP Broadcast Service...23 6.1.3 Rogue DHCP...23 6.1.4 IP Stealer...24 6.1.5 DNS Poisonning...24 6.2 Défenseur...25 6.2.1 Active ARP Protection...25 6.2.2 ARP Reply Rate...25 6.2.3 Rogue DHCP Detection...26 6.2.4 DNS spoof detection...26 2

7 Conclusion...27 8 Bibliographie...28 8.1 DHCP...28 8.2 ARP...28 8.3 DNS...28 3

1 Introduction Dans le cadre du cours «Approfondissement télécommunication et réseaux» du Cégep de Sainte-Foy avec François Gagnon, nous avons entrepris de faire une revue des mécanismes d'attaques et de défenses des principaux protocoles réseaux qui peuvent mener à une usurpation d'identité (réseautiquement parlant) ou en situation «d'attaque de l'homme du milieu» («man in the middle»). Ce document n'a pas la prétention de faire une liste exhaustive des attaques et des défenses possibles, mais de couvrir largement les avenues possibles. Notez que les attaques parlées dans ce document ne sont qu'au niveau réseau et qu'elles se font à distance de la victime. Le virus et les vers ne sont donc pas concernés par ces attaques. Notez aussi que certaines des techniques de défense se font sur l'ordinateur de l'hôte victime de l'attaque et que d'autres se font complètement à distance. 2 Qu'est-ce que le spoofing? Le spoofing, en sécurité informatique, est lorsqu'une personne réussit à obtenir des avantages en envoyant de fausses données, ou encore des données trafiquées. Souvent, le spoofing peut permettre de cacher son identité en falsifiant son adresse matérielle (MAC) ou son adresse logique (IP). Le spoofing peut servir à mettre l'attaquant en situation «d'attaque de l'homme du milieu» en effectuant des manipulations sur certains protocoles de configuration réseau comme ARP ou DHCP. L'attaque de «l'homme du milieu» consiste au fait que l'attaquant est capable de se positionner entre deux victimes et d'intercepter leurs communications. Habituellement, il s'agit d'une victime et du routeur sur lequel elle est connectée. Beaucoup d'attaques par spoofing sont uniquement dédiées aux réseaux locaux et ne sont donc heureusement pas utilisables sur Internet, mais ce n'est pas le cas pour tous. Pour notre part, la plupart des attaques que nous avons étudiées se font en réseau local. Ces attaques pourraient tout aussi bien être utilisées dans le contexte d'un réseau métropolitain (MAN). 4

3 Le but de la recherche Comme dit précédemment, la recherche se fait sur les mécanismes d'attaques et de défenses de différents protocoles qui contiennent des failles qu'il est possible d'exploiter en envoyant de fausses données (spoofing). La finalité de la recherche est, bien sûr, de sensibiliser la société face à ces attaques et de trouver des techniques permettant de les déjouer ou de les prévenir si c'est possible. Notre recherche s'est concentrée sur 3 protocoles : ARP, DHCP, DNS. Il faut dire qu'il est possible d'effectuer du spoofing avec plusieurs autres protocoles, mais cela se fait la plupart du temps du côté applicatif et non du côté réseau. 5

4 Les protocoles Voici les descriptions des protocoles dont notre recherche portait. 4.1 Address resolution protocol (ARP) Le protocole ARP est un protocole permettant d'obtenir l'adresse physique d'un hôte (habituellement une adresse MAC) à l'aide de son adresse logique (typiquement une adresse IP). Le protocole ARP est classé comme étant de couche 2 dans le modèle OSI (Couche de liaison de données). Le protocole ARP est habituellement encapsulé dans le protocole Ethernet. [10] [11] [14] 4.1.1 Entête Voici l'entête du protocole ARP ainsi qu'une description sommaire de chacun des champs 1 : Octet 1 Octet 2 Octet 3 Octet 4 Hardware Address Length Hardware type Protocol Address Length Adresse MAC source (octets 1-4) Protocol type Operation Adresse MAC source (octets 5-6) Adresse IP source (octets 1-2) Adresse IP source (octets 3-4) Adresse MAC destination (octets 1-2) Adresse MAC destination (octets 3-6) Adresse IP destination (octets 1-4) Hardware type (type de matériel) : Habituellement 1 pour Ethernet Protocol type (Type de protocole de niveau 3) : Habituellement 0x0800 pour IP Hardware Address Length (longueur de l adresse physique en octet) : Habituellement 1 pour Ethernet Protocol Address Length (longueur de l adresse logique en octet) : Habituellement 4 pour IPv4 1 http://fr.wikipedia.org/wiki/address_resolution_protocol 6

Operation 1 - Request : requête ARP 2 - Reply : réponse ARP Ce champ permet de connaître la fonction du message et donc son objectif. Sender Hardware Address (adresse physique de l émetteur) Sender Internet Address (adresse réseau de l émetteur) Target Hardware Address (adresse physique du destinataire) (0 lorsque c'est une requête) Target Internet Address (adresse réseau du destinataire) 4.1.2 Déroulement La procédure [14] [15] pour obtenir une adresse MAC à partir d'une adresse IP se déroule comme ceci : Un client veut connaître l'adresse MAC de destination qui a l'adresse IP 192.168.1.100 et est dans le même sous-réseau que lui. Il envoie donc un paquet ARP avec le code d'opération 1 et l'adresse de la destination dans le champ «Target Internet Address». Ce paquet est envoyé en diffusion (broadcast) Ethernet c'est-à-dire avec l'adresse MAC FF:FF:FF:FF:FF:FF comme destination. Tous les hôtes du sous-réseau du client reçoivent le paquet ARP de celui-ci. Étant donné que l'hôte de destination est dans le même sous-réseau que le client, il reçoit également le paquet ARP. Tous les hôtes vérifient si l'adresse IP à laquelle est destiné ce paquet ARP est la leur et sinon il la jette. Étant donné que le paquet ARP lui est destiné, le destinataire répond. Le paquet ARP avec le code d'opération 2 est envoyé avec l'adresse IP et l'adresse MAC du destinataire comme source et l'adresse IP et l'adresse MAC du client comme destination. Seul le client reçoit la réponse du destinataire. Lorsque reçus, il met les informations du destinataire dans sa cache ARP afin de ne pas à avoir à faire un paquet ARP à chaque fois qu'il veut effectuer une communication vers le destinataire. Chaque entrée dans la cache ARP a une durée de vie définie par le client. Lorsqu une entrée expire, le client doit envoyer de nouveau un paquet ARP pour avoir de nouveau une entrée valide. 7

4.2 Dynamic Host Configuration Protocol (DHCP) Le protocole DHCP est un protocole permettant d'obtenir une configuration réseau automatiquement sans avoir à expliciter manuellement cette configuration dans le système. Il est possible d'utiliser le protocole DHCP pour plusieurs choses, mais il est habituellement utilisé pour obtenir une adresse IP ainsi que le masque de sous réseau. Il permet également au système d'exploitation de connaître l'adresse de la passerelle par défaut ainsi les adresses des serveurs DNS à utiliser. [1] [2] [3] Le protocole DHCP est classé comme étant de couche 7 dans le modèle OSI (Application). Le protocole est encapsulé dans le protocole UDP. En ce qui a trait au port UDP, le client DHCP utilisera toujours le port 68 et le serveur DHCP utilisera toujours le port 67. [4] [5] 4.2.1 Déroulement L'acquisition[5] de la configuration réseau se fait en 4 phases : DHCP Discover : Le client envoie un paquet DHCP du port UDP 68 au port UDP 67 à l'adresse IP de diffusion c'est-à-dire 255.255.255.255 et à l'adresse MAC de diffusion FF:FF:FF:FF:FF:FF. Les données du paquet DHCP indiquent que le type de paquet est DHCP Discover. Ce paquet est fait dans le but de «découvrir» les serveurs DHCP du réseau et d'avoir une offre de configuration IP. Il peut y avoir plusieurs serveurs DHCP sur le réseau qui répondent à ce paquet par un DHCP Offer. DHCP Offer : Les serveurs DHCP recevant le DHCP Discover envoient au client en diffusion Ethernet et IP ou pas (cela dépend des serveurs DHCP) un paquet DHCP de type Offer. Dans ce paquet, il y a une offre de configuration IP pour le client. Dans cette offre, il y a une adresse IP offerte au client, des informations générales sur le réseau comme la passerelle ou les serveurs DNS et des informations plus spécifiques que le client a demandé dans son paquet DHCP Discover par exemple des informations NetBios que Windows demande souvent. 8

DHCP Request : Comme dit précédemment, le client peut recevoir plusieurs DHCP Offer. Il doit donc choisir parmi un des serveurs DHCP. Ce choix est de l'ordre de l'implémentation du client DHCP. Donc, lorsqu'il choisit une offre, le client envoie un paquet DHCP de type DHCP Request qui indique le choix de configuration IP. Ce paquet est encore fait en diffusion pour que tous les serveurs DHCP soient au courant de la configuration que le client a choisi. DHCP Acknowledge : Finalement, le serveur DHCP dont l'offre a été acceptée par le client envoie un paquet DHCP de type Acknowledge (Ack). Ce paquet contient les mêmes informations que dans le DHCP Offer si le client les a redemandés ce qui est le cas la plupart du temps. Ce paquet confirme au client que le DHCP Request a été accepté et qu'il peut maintenant utiliser l'adresse IP offerte en toute légitimité. Il y a également d'autres types de paquet DHCP qui sont moins utilisés : DHCP Nak : Un paquet de type DHCP Nak est envoyé à un client lorsque le client ne semble pas avoir une bonne configuration IP. Ce type de paquet est seulement pris en compte lors de la configuration et n'est plus pris en compte lorsque le client a accepté la configuration. [1] DHCP Release : Un paquet de type Release est utilisé par le client pour avertir le serveur DHCP qu'il ne souhaite plus avoir de configuration IP. Ce paquet libère donc l'adresse IP allouée au client des adresses IP des adresses IP prises. Ce type de paquet est utile afin de pouvoir redonner les adresses IP qui ont été délibérément libérées par les clients.[1] 9

4.3 Domain Name System (DNS) Le protocole DNS est un protocole permettant d'obtenir la ou les adresses IP correspondantes à un nom de domaine. Le système des noms de domaine est un système hiérarchique où il y a les 13 serveurs DNS racines d'internet d'où tous les autres serveurs DNS tirent leurs informations. Bien entendu, les serveurs DNS locaux ne s'en servent pas et ne partagent pas leurs informations à l'extérieur. Le protocole DNS est classé comme étant de couche 7 dans le modèle OSI (Application). Le protocole est encapsulé dans le protocole UDP. Le serveur DNS utilisera le port UDP 53. [18] [19] 4.3.1 Déroulement Le déroulement d'une requête DNS peut paraître assez simple, mais, en réalité, si le serveur DNS n'a pas dans sa cache l'information que l'on cherche, il sera obligé de déléguer la requête à un serveur DNS supérieur. [16] [16] [18] [19] Voici un exemple simple : L'hôte qui cherche à joindre l'adresse www.exemple.com enverra une requête DNS de type «query» sur le port UDP 53 du serveur DNS. Le serveur DNS recevant cette requête regarde dans sa cache DNS si www.exemple.com y est déjà. Lorsqu'il l'a trouvé, il répond à la requête par une requête DNS de type «response» qui contient la ou les adresses IP correspondantes au nom de domaine, car un nom de domaine peut correspondre à plusieurs adresses IP. 10

5 Type de spoofing 5.1 ARP spoofing 5.1.1 Attaque L'ARP spoofing comprend plusieurs techniques permettant tous de mettre en place «une attaque de l'homme du milieu». La plupart du temps, il est question d'intercepter des données passant de la victime au routeur et vice-versa. 5.1.1.1 ARP Reply Spoofing Une des techniques de ARP Spoofing consiste à envoyer un paquet ARP avec le code d'opération 2 c'est-à-dire le code pour indiquer une réponse («reply») à l'hôte que l'on souhaite attaquer. Ce paquet indiquera à l'hôte victime que l'adresse IP du routeur réfère à l'adresse MAC de l'attaquant. Lors de la réception de ce paquet, la victime tiendra pour acquis qu'il s'agit d'une réponse à un paquet qu'il a envoyé et mettra sa cache à jour. Afin de maintenir la cache ARP de la victime avec les informations voulues, il est nécessaire de répéter souvent ce paquet. [12] [13] Pour être en mesure de recevoir les réponses du routeur destinées à l'hôte, plusieurs techniques sont possibles. La technique la plus courante est d'effectuer la même chose pour le routeur, mais en se 11

faisant passer pour l'hôte que l'on attaque. Il faut bien sûr effectuer une redirection des paquets reçus pour que le routeur et l'hôte reçoivent les paquets leur étant destinés. Une autre technique est d'effectuer du NAT entre l'hôte et le routeur : de cette façon, il n'est plus nécessaire de spoofer le routeur ce qui devient transparent pour lui. 5.1.1.2 ARP Request Spoofing Une autre des techniques permettant de faire du ARP Spoofing consiste à envoyer un paquet avec le code d'opération 1 c'est-à-dire le code pour indiquer le type «request» et non le type «reply» que l'attaque précédente utilise. Cette fois-ci, les champs ARP qui seront falsifiés sont l'adresse IP source et l'adresse MAC source du paquet ARP : l'adresse IP sera celle du routeur et l'adresse MAC sera celle de l'attaquant. Lors de la réception de ce paquet ARP, la victime mettra les informations provenant du destinataire dans sa cache. Cela est fait dans un but d'optimisation; comme cela, l'hôte n'a pas à refaire un paquet ARP plus tard s'il désire communiquer à le destinataire en question. La particularité de cette attaque est qu'elle permet de spoofer tout le réseau sur lequel se trouve l'attaquant, car le paquet ARP est envoyé en diffusion Ethernet sur le réseau. L'attaquant doit également être en mesure de rediriger tout le trafic vers le routeur et vice-versa vers les hôtes du réseau. Le prototype que nous avons fait implémente ces deux types de spoofing. 12

5.1.2 Défense Diverses défenses contre ces attaques sont possibles. Certaines de ces défenses sont au niveau du système d'exploitation et les autres sont des systèmes de détection de ARP Spoofing sur le réseau. 5.1.2.1 Au niveau du système d'exploitation Pour prévenir la première attaque (ARP Reply Spoofing) au niveau du système d'exploitation, le système d'exploitation pourrait ne prend en compte que les ARP reply répondant à un ARP request précédemment envoyé. Il pourrait également s'apercevoir du ARP Spoofing lorsque les réponses à une ARP request se contredisent. Pour ce qui est de la deuxième attaque (ARP Request Spoofing), le système d'exploitation pourrait tout simplement ne pas prendre en compte les informations qui y sont contenues. 5.1.2.2 Système de détection Pour détecter un ARP Reply Spoofing, il est possible de calculer le taux entre le nombre de ARP reply reçu comparativement au nombre de ARP request reçu. Bien entendu, s'il y a plus de ARP reply qui sont reçus, il y a un ARP Reply Spoofing en cours. Il n'est pas possible d'effectuer la même chose pour la deuxième attaque (ARP Request Spoofing), car 13

les ARP request sont en envoyés en diffusion, mais pas les ARP reply. Il est également normal de recevoir plus de ARP request que de ARP reply étant donné que certaines n'ont pas de réponse normalement lorsque, par exemple, l'hôte à contacter n'est plus sur le réseau. Pour détecter les deux attaques, il est possible de vérifier activement si les données reçues dans un paquet ARP sont légitimes ou non. Il s'agit d'envoyer un paquet ARP avec les informations reçues et de voir si les informations que nous avions préalablement reçues sont les mêmes que les nouvelles informations. Le prototype que nous avons fait implémente ces deux systèmes de détection. 14

5.2 DHCP spoofing 5.2.1 Rogue DHCP Le principe d'un rogue DHCP est très simple : l'attaquant ouvre un serveur DHCP non légitime sur le réseau. Lorsqu'un client se connecte au réseau, si le serveur DHCP de l'attaquant est plus rapide que le serveur DHCP local, le client recevra une configuration IP du serveur DHCP non légitime. Cette attaque se base sur le fait qu'il n'y ait aucune authentification de la part du serveur DHCP pour s'assurer qu'il est légitime. [3] [7] Certains serveurs DHCP envoient des paquets DHCP de type «NAK» lorsqu'il s'aperçoit que le client s'apprête à accepter une configuration incorrecte. Il faut donc que le serveur DHCP malicieux soit assez rapide pour finaliser l'acquisition de la configuration IP par le client avant que le client ne reçoive la paquet de type NAK. Lorsque le client a finalisé l'acquisition de la configuration, il ne se préoccupe plus de cet paquet.[1] Avec cette attaque, il est possible, dans le moins pire des cas, de donner des mauvaises configurations au client ce qui les met en incapacité de communiquer sur le réseau. Dans le pire des cas, il y aura «une attaque de l'homme du milieu» entre l'attaquant et les hôtes se connectant sur le réseau. Étant donné qu'il est également possible de fournir la configuration DNS des clients, il est possible donner 15

l'adresse de l'attaquant comme étant un serveur DNS et ensuite de falsifier les adresses IP des noms de domaine dans le but de faire de l hameçonnage par exemple. Le prototype que nous avons fait implémente un rogue DHCP. 5.2.1.1 Défense Une technique très simple pour détecter si un rogue DHCP est sur le réseau est d'effectuer un paquet DHCP de type «discover» et de comparer la liste des serveurs DHCP qui ont répondu avec la liste des serveurs DHCP connus sur le réseau. Si un serveur DHCP qui a répondu n'est pas dans la liste des serveurs DHCP connus, il s'agit sans doute d'un rogue DHCP. Le prototype que nous avons fait implémente cette technique de détection de rogue DHCP. 5.2.2 DHCP Starvation Le principe d'un DHCP Starvation est encore très simple : il s'agît de faire des paquets DHCP dans le but d'avoir un bail de chacune des adresses IP disponibles dans la plage d'adresses IP du serveur DHCP local. Ceci peut résulter en l'impossibilité des clients qui se connectent d'avoir une adresse IP. Il est également possible de mettre en service un rogue DHCP qui donnerait la configuration IP au client sans que le serveur DHCP local réagisse.[6] [7] [8] 16

Le prototype que nous avons fait implémente cette technique et il est possible de démarrer le rogue DHCP du prototype pour donner les adresses IP qui ont été prises. 5.2.2.1 Défense Il n'y a pas de réelle protection connue contre cette attaque. Il serait possible de limiter le nombre de clients qui reçoivent une adresse IP sur un port physique du routeur, mais il faut être sûr qu'il n'y aura jamais beaucoup de personnes connectées sur le port du routeur. Il serait également possible de restreindre le nombre de configurations IP que le serveur donne selon le temps, par exemple, il ne serait pas possible d'avoir plus de 5 configurations IP autorisées en 5 secondes sinon il y aurait un temps d attente de 60 secondes. 17

5.2.3 Libération d'adresse IP du réseau Étant donné la faible sécurisation du protocole DHCP, il est également possible de libérer n'importe quelle adresse IP du réseau en effectuant un paquet DHCP de type «Release». Il est donc possible de libérer toutes les adresses IP prises sur le réseau. Par contre, les hôtes qui se font libérer leur adresse IP n'en sont pas conscients, mais les nouveaux clients qui se connecteront sur le réseau auront de fortes chances, selon l'implémentation, d'obtenir la même adresse IP qu'un client et ainsi d'avoir un conflit d'adresse IP. Les nouveaux clients seront donc dans l'impossibilité d'obtenir une configuration correcte. 5.2.3.1 Défense Une technique de défense contre la libération non voulue d'adresse IP sur le réseau serait que le serveur DHCP envoie un paquet ARP pour voir si un hôte du réseau utilise encore l'adresse IP lorsqu'il reçoit un DHCP Release. Il pourrait également y avoir la vérification de l'adresse MAC de l'ordinateur qui tente de libérer son adresse afin de vérifier la légitimité de cette demande. Si l'adresse MAC qui libère une adresse IP n'est pas la même que celle qui l'a demandé à l'origine, la libération de l'adresse IP ne doit pas être faite. Le serveur DHCP pourrait aussi ne plus prendre en compte les paquets DHCP de type «Release». Cela aurait par contre comme inconvénient de toujours attendre la fin des baux DHCP. Cependant, il y a actuellement beaucoup de systèmes d'exploitation qui n envoient pas systématiquement des paquets DHCP de type «Release» lorsqu'il n'a plus besoin de l'adresse IP par exemple lorsqu'il s'éteint. 18

5.3 DNS spoofing 5.3.1 Falsification d'une réponse Étant donné que le protocole DNS ne permet pas d'authentification du serveur DNS, il est possible de falsifier une requête DNS lorsqu'un client en fait une. Comme les requêtes DNS ne sont pas diffusées sur le réseau, il n'est évidemment pas possible d'intercepter une requête DNS s'il n'y a pas de position «d'attaque de l'homme du milieu». Si l'attaque de «l'homme du milieu» est bien orchestrée, il est même possible de ne pas envoyer la requête DNS initialement envoyée à l'adresse du serveur DNS légitime lorsqu'elle est interceptée par l'attaquant. La victime ne recevra donc qu'une seule réponse qu'il croira légitime étant donné que l'attaquant aura également falsifié l'adresse IP de la requête par celle du serveur auquel la requête était envoyée. [21] Le prototype que nous avons fait implémente cette technique et il est possible de la coupler avec le ARP spoofing pour qu'il ne redirige pas certaines requêtes DNS que l'on souhaite falsifier. 5.3.1.1 Défense Divers systèmes de détection pourraient être mis en place. Premièrement, le système de détection que notre prototype implémente est, lors de l'envoi d'une requête DNS par le système d'exploitation, l'envoi d'une autre requête DNS vers un serveur DNS qui n'existe pas. Si une réponse à cette requête est 19

effectuée, cela veut dire qu'il y a quelqu'un sur le réseau qui fait du DNS spoofing et qui répond à toutes les requêtes DNS peu importe leur adresse IP de destination. Un autre système de défense possible est d'effectuer une requête DNS vers un nom de domaine dont on connaît déjà la résolution. Évidemment, il faut que cette résolution n'ait pas changé depuis le temps et que cette résolution n'ait pas été elle-même spoofée par quelqu'un ce qui rend la défense difficile à mettre en place. De plus, la plupart des applications permettant de faire du DNS spoofing permettent de spécifier les noms de domaines visés par l'attaque ce qui fait que l'on ne peut pas vraiment savoir quel nom de domaine il faut tester. Il est également possible de détecter si l'on reçoit plusieurs réponses contradictoires à une requête DNS, car certains outils de DNS spoofing ne permettent pas d'empêcher la requête DNS du serveur DNS légitime de se rendre à la victime. Il existe aussi le protocole DNSSEC(Domain Name System Security Extensions) qui permet de signer cryptographiquement un enregistrement DNS. Donc, lorsqu'une requête DNS est faite et que l'hôte reçoit la réponse, l'hôte peut vérifier si l'enregistrement fourni est légitime avec le certificat de l'autorité de certification. [22] [23] 20

5.3.2 Empoisonnement du cache DNS Les serveurs DNS communiquent entre eux pour résoudre un nom de domaine qu'ils n'ont pas dans leur cache. Si un attaquant a un serveur DNS, avec certains serveurs DNS, il est possible d'envoyer des résolutions pour d'autres noms de domaine que celui demandé par le serveur DNS. Le serveur DNS ayant demandé la résolution d'un nom de domaine par le serveur DNS malicieux mettra donc dans sa cache toutes les informations envoyées par le serveur DNS de l'attaquant.[20] 5.3.2.1 Défense De nos jours, peu de serveurs DNS sont encore victimes de cette attaque. Il s'agit simplement de ne pas mettre dans sa cache des résolutions de nom de domaine non demandées au préalable. 21

6 Prototypes Dans le cadre de la recherche, nous avons fait deux logiciels qui sont des prototypes permettant de démontrer certaines techniques d'attaque et de défense découvertes dans cette recherche. Un des deux prototypes se consacre à la partie «attaque» et l'autre à la partie «défense». Chacun des prototypes est séparé en «services» qui implémentent un des types d'attaque ou de défense. Chacun des services a une console de journalisation où les actions prises par le service y sont décrites. Il est possible de démarrer ou d'arrêter chacun des services à tout moment. 6.1 Attaquant Toutes les attaques ont déjà été décrites dans la section 5. Cette section ne fait que décrire les spécificités du prototype d'attaque. 6.1.1 Reply ARP Service Ce service implémente un «ARP Reply Spoofing» comme décrit dans la section 5.1.1.1. Il permet d'effectuer «une attaque de l'homme du milieu» entre deux hôtes sur le réseau local. Un NAT est implémenté pour permettre la redirection entre les deux hôtes attaqués. 22

6.1.2 ARP Broadcast Service 6.1.3 Rogue DHCP 23

6.1.4 IP Stealer 6.1.5 DNS Poisonning de l'homme du milieu», le DNS Poisonning n'aura aucun effet. 24

6.2 Défenseur Toutes les défenses ont déjà été décrites dans la section 5. Cette section ne fait que décrire les spécificités du prototype de défense. 6.2.1 Active ARP Protection Ce service sert à détecter s'il y a du ARP spoofing avec paquet ARP de type «reply». Lorsqu'il reçoit un paquet ARP de type «reply», il envoie un paquet ARP de type «request» puis vérifie si la ou les réponses obtenues concordent avec le premier «reply» reçu : sinon, il y a du ARP Spoofing. 6.2.2 ARP Reply Rate Ce service sert à détecter s'il y a du ARP spoofing avec paquet ARP de type «reply». Il calcule le ratio entre le nombre de ARP reply et de ARP request reçus. S'il y a plus de ARP reply reçu, il y a une forte chance qu'il y ait un ARP spoofing. Le service permet de spécifier un intervalle pendant lequel le service reçoit les paquets ARP et calcule ensuite le ratio. Par défaut, l'intervalle est de 10 secondes et plus l'intervalle est élevé, plus la probabilité de détecter un ARP spoofing est élevée. 25

6.2.3 Rogue DHCP Detection Ce service implémente la technique de détection de rogue DHCP décrite dans la section 5.2.1.1. L'interface permet d'ajouter ou de supprimer l'adresse IP des serveurs DHCP connus sur le réseau. Lorsque l'on démarre le service, il effectue un paquet DHCP et attend les réponses pendant 5 secondes. Il fait ensuite la comparaison entre la liste des serveurs DHCP connus et des serveurs DHCP qui ont répondu. 6.2.4 DNS spoof detection Ce type de défense est décrit dans la section 5.3.2.1. Il s'agit d'envoyer une requête DNS vers une adresse IP qui n'a pas de serveur DNS et de voir si une réponse est faite ou non. Dans notre cas, lorsque le client envoie une requête DNS, nous en envoyons une autre vers l'adresse IP 240.1.2.3 qui est en fait une adresse réservée par l'iana (Internet Assigned Numbers Authority) pour des usages futurs, mais qui n'est présentement pas utilisée. Si une réponse vient de cette adresse IP, il y a alors eu une falsification de réponse DNS. 26

7 Conclusion Pour conclure, on a vu que ces trois protocoles (ARP, DHCP et DNS) ont encore des faiblesses qu'il est actuellement possible d'exploiter dans les réseaux actuels. Il faut donc prendre des mesures pour contrer les attaques possibles. Une de ses mesures possibles serait de toujours utiliser le chiffrement des communications via des protocoles sécurisés comme SSL avec des certificats électroniques afin d'éviter que les attaques de «l'homme du milieu» ne permettent l'accès à des données confidentielles. Une autre mesure qu'il est possible de prendre et qui s'adresse particulièrement aux administrateurs réseau est d'observer le réseau interne et de journaliser les comportements suspects comme le fait notre prototype. Il existe évidemment d'autres attaques au niveau réseau que celles mentionnées dans ce document. D'ailleurs, il serait intéressant de s'intéresser aux techniques d'attaques qui sont plus de hauts niveaux c'est-à-dire dans la couche applicative du modèle OSI. Un domaine assez intéressant de la sécurité informatique concerne les attaques au niveau du protocole HTTP et des sites web en général. Il existe beaucoup d'attaques au niveau des sites web comme, par exemple, les attaques de type Cross-site scripting (XSS) ou les injections SQL. 27

8 Bibliographie 8.1 DHCP [1] http://www.ietf.org/rfc/rfc2131.txt [2] http://cisco.goffinet.org/s1/dhcp [3] http://en.wikipedia.org/wiki/dynamic_host_configuration_protocol [4] http://www.commentcamarche.net/contents/internet/dhcp.php3 [5] http://www.frameip.com/dhcp/ [6] http://revolutionwifi.blogspot.ca/2011/03/preventing-dhcp-starvation-attacks.html [7] http://www.antionline.com/showthread.php?t=255905 [8] http://www.networkdictionary.com/networking/dhcpstarvationattack.php [9] http://www.networksorcery.com/enp/protocol/dhcp.htm 8.2 ARP [10] http://www.ietf.org/rfc/rfc826.txt [11] http://www.frameip.com/entete-arp/ [12] http://fr.wikipedia.org/wiki/arp_poisoning [13] http://en.wikipedia.org/wiki/arp_spoofing [14] http://en.wikipedia.org/wiki/address_resolution_protocol [15] http://www.commentcamarche.net/contents/internet/arp.php3 8.3 DNS [16] http://www.ietf.org/rfc/rfc1035.txt [17] http://technet.microsoft.com/en-us/library/dd197470%28v=ws.10%29.aspx [18] http://en.wikipedia.org/wiki/domain_name_system [19] http://fr.wikipedia.org/wiki/domain_name_system 28

[20] http://fr.wikipedia.org/wiki/dns_cache_poisoning [21] http://www.securiteinfo.com/attaques/hacking/dnsspoofing.shtml [22] http://www.dnssec.net/ [23] http://fr.wikipedia.org/wiki/dnssec 29