Tp arp poisoning








télécharger 65.89 Kb.
titreTp arp poisoning
date de publication12.04.2017
taille65.89 Kb.
typeDocumentos
p.21-bal.com > loi > Documentos

TP - ARP Poisoning


http://www-gtr.iutv.univ-paris13.fr/Equipe/vinatier/tparp

Objectif


L'attaque est connue sous le nom de "ARP Poisoning", et permet au pirate de rediriger le trafic d'une, ou de plusieurs, machines du réseau vers la sienne. L'opération vise à modifier le cache ARP de, ou des, victimes, en envoyant des paquets ARP Reply associant l'adresse IP de la passerelle (par exemple) à l'adresse MAC du pirate. Tout le trafic Victime --> Routeur sera envoyé vers l'ordinateur du Pirate. Ce dernier n'aura plus qu'à router ce flux vers la destination demandée, afin que la victime ne s'aperçoive de rien.

Question : Discussion autour d'autres applications.

Réponses possibles :

Cette technique est aussi utilisée dans le cadre d'écoutes passives sur des réseaux commutés. Les commutateurs (switchs) redirigent les trames ethernet sur des ports différents selon l'adresse physique. Il devient donc impossible à une station de sniffer les trames au delà de son brin de réseau. Elle ne verrais que ce qui lui est adressé. L'ARP Poisoning va donc permettre à un pirate d'écouter le trafic entre des machines situées sur des brins différents.

Une autre application consiste à faire déborder le cache ARP de certains commutateurs, en les maintenant sous un flot permanent de paquet ARP reply falsifiés. Lorsque le débordement intervient, beaucoup de commutateurs vont se mettre à fonctionner en mode concentrateur, afin de garantir la continuité de service. Le switch étant devenu hub, l'écoute du réseau peut commencer.

Afin de bien faire comprendre la démarche qu'impose une réflexion autour de la sécurité d'un protocole, je part de la présentation d'un paquet ARP reply. On se rend vite compte que l'on ca pouvoir intervenir à 2 endroits précis :

Ethernet (@MAC source et destination), c'est à dire au niveau 2.
Arp (@MAC source et destination, ainsi que @IP source et destination), c'est à dire au niveau 3.

Hypothèse 1 : Modification des champs @MAC de la trame ethernet (MAC Spoofing ou Usurpation d'adresse MAC).

L'objectif ici est de forger un paquet avec @MAC_source = @MAC_victime et @MAC_dest = @MAC_pirate.
Lorsque le switch va recevoir cette trame, il va mettre à jour son cache (CAM - Content Adressable Memory - chez CISCO), en associant l'@MAC de la vctime à notre port.
A ce stade, ne serait-ce qu'intuitivement, les étudiants doivent se rendre compte des limites de cette technique. En effet, la victime continue d'émettre sur le réseau, ce qui va mettre notre switch dans une situation étrange (1 @MAC pour 2 ports). La situation provoquée, n'est pas maitrisable par le pirate (sauf à connaitre exactement la réaction du switch). Cette réaction peut aller d'une simple mise à jour du cache lors du passage de chaque trame, jusqu'à l'émssion d'un trap (via snmp par exemple) sur un système de gestion d'incidents, en passant par une désactivation du port d'ou vient l'usurpation. Si les étudiants arrivent à cette analyse, il est possible d'aller un peut plus loin. Effectivement, pour sortir de ce cas de figure, il conviendrait de mettre hors service la station victime (denial of service). Ceci fait, le problème semble être réglé. Malgré tout, l'attaque ne peut pas être qualifiée de furtive et elle ne permet pas de détourner le trafic.

Hypothèse 2 : Modification des champs @MAC et @IP (source et destination) du paquet ARP (ARP Spoofing).

Nous montons un peut dans les couche et nous nous arrêtons à l'endroit où se trouve le mécanisme qui permet de faire la correspondance entre @MAC et @IP (le protocole ARP). L'objectif ici serait d'associer l'@MAC du pirate à l'@IP de la victime, lors de l'émission d'une requête ARP de la part d'un hôte. Pour cela, le pirate devra réponde à une requête ARP, avant la victime, de préférence avec un paquet falsifié. Si les étudiants sont bien entrés dans la logique, il devraient répondre que la victime va aussi émettre une réponse ARP avec son @MAC (la vraie). L'émetteur de la requête ARP va se trouver dans une situation tout aussi étrange que le switch de l'hypothèse 1. Encore une fois la mise hors service de la victime s'avère indispensable au déroulement de cette attaque, ce qui la rend relativement inéfficace, notamment en terme de discrétion.

Hypothèse 3 : Créer et mettre à jour une entrée dans le cache ARP de la victime (ARP Poisoning).

L'intérêt du cache ARP est de limiter le trafic en évitant de broacaster une requête who-was en permanence. Pour rendre encore plus importante cette économie de bande passante, tous les paquets ARP reçus (les requêtes comme les réponses) vont être utlisés. Ce comportement est très interressant !
Si nous forgeons une requête ARP (who-was) falsifiée à destination de la victime, il y a une forte probabilité pour qu'elle ajoute une entrée dans son cache (nous sommes dans le cadre d'une hypothèse).
Maintenant que nous pensons pouvoir écrire dans le cache, il nous faut pouvoir mettre à jour une entrée existante. Nous devrions pouvoir utiliser le mécanisme, vu précédemment, pour mettre à jour une entrée, en forgeant une requête ARP (reply) falsifiée. Il ne nous reste plus qu'à tenter de maintenir l'entrée créée (ou mise à jour). Il suffira de réitérer la requête à des intervales réguliers.
Il est toutefois important de souligner que l'émission de requête ARP en unicast est assez suspecte. Il s'agirait aussi de vérifier si certains systèmes d'exploitation n'implémentent pas un mécanisme leur permettant de na pas prendre en compte un paquet ARP reply alors qu'ils n'ont pas émis de request.
Pour terminer, si le pirate veut rediriger le trafic, il doit activer le forwarding (echo 1 > /proc/sys/net/ipv4/ip_forward)


Mise en oeuvre


L'objectif du TP est de rediriger le trafic Victime (V) --> Routeur (R) vers la machine du pirate (P).

Ressources

      . Un générateur de paquets ARP (arp-sk)

      . Une machine victime (V)

      . Un routeur (R) (machine sous linux avec 2 cartes ethernet)

      . La machine de l'attaquant (A)




Maquette
schéma à venir ...

Avant de lancer l'attaque il convient de prendre quelques repères sur la victime, afin de pouvoir rendre compte des modifications apportées par le pirate. Dans un premier temps étudions la route empruntée par les paquets émis par la victime et à destination du routeur, pour cela vous devez avoir recours à la commande traceroute (tracert sous windows). Un autre relevé nous sera utile, c'est celui de la table ARP de la victime, qui nous sera donné par la commande arp :

Question : Donner la sortie de la commande traceroute (victime --> Routeur).

Réponse possible :

[root@victime ~]# traceroute @IPr
traceroute to @IPr (@IPr), 30 hops max, 40 bytes packets
1 @IPr (@IPr) 0.024 ms 0.125 ms 0.189 ms


La seule chose à noter, c'est qu'il n'y a qu'un saut :-)

Question : Donner le contenu du cache ARP de la victime.

Réponse possible :

[root@victime ~] arp

Address

HWtype

HWAddress

Flags

Mask

Iface

@IPr

ether

@MACr

C




eth0

@IPp

ether

@MACp

C




eth1


Rien de spécial à remarquer, si ce n'est que ce doit être les vraies valeurs :-)



Avant de lancer l'attaque, démarrer un analyseur de trame sur la victme en positionnant un filtre de capture afin de ne vor que le trafic venant de la machine de l'attaquant.
(Liste de sniffers --> tcpdump, windump, etherreal, packetyzer)




Préparer un tableau récapitulatif des données utiles afin de compléter la commande arp-sk




Adresse IP

Adresse MAC

PC1

-

-

Routeur

-

-

PC2

-

-

Démarage de l'attaque :

[root@victime ~]# arp-sk -r -S @MACr -D @MACv -T @MACp -s @IPr -F @MACv -d @IPv
@MACv 0806 42: arp reply 10.0.0.1 is-at @MACp
@MACv 0806 42: arp reply 10.0.0.1 is-at @MACp
@MACv 0806 42: arp reply 10.0.0.1 is-at @MACp
@MACv 0806 42: arp reply 10.0.0.1 is-at @MACp
@MACv 0806 42: arp reply 10.0.0.1 is-at @MACp
@MACv 0806 42: arp reply 10.0.0.1 is-at @MACp



Entête ethernet


Entête ARP

Les arguments de la commande arp-sk

-r

Mode reply (avec winarp-sk => -m 2).

-S @MAC

Champ source de l'entête ethernet.

-D @MAC

Champ destination de l'entête ethernet.

-F @MAC

Champ " Adresse Ethernet Emetteur " du paquet ARP.

-s @IP

Champ " Adress IP Emetteur " du paquet ARP.

-T @MAC

Champ " Adresse Ethernet Récepteur " du paquet ARP.

-d @IP

Champ " Adress IP Récepteur " du paquet ARP.

L'attaquant envoi donc des paquets ARP reply empoisonnant le cache ARP de la victime en lui indiquant que l'@MAC associée à l'@IPr est désormais @MACp

Question : Montrer à l'enseignant la trace de l'attaque et décrire un des paquets reçus du pirate, en indiquant l'endroit ou s'est glissé le spoofing.

Réponse possible :

Packetyzer Trace:
Frame 1 (60 bytes on wire, 60 bytes captured)
Frame is marked: False
Arrival Time: Oct 6, 2004 11:17:33.1837592520
Time delta from previous packet: 0.000000000 seconds
Time since reference or first frame: 0.000000000 seconds
Frame Number: 1
Packet Length: 60 bytes
Capture Length: 60 bytes
Data (60 bytes)

0000: 00 01 02 9C 7B E0 00 09 6B 7D B6 E2 08 06 00 01 ....{...k}......
0010: 08 00 06 04 00 02 00 09 6B 7D B6 E2 37 3B 04 01 ........k}..7;..
0020: 00 01 02 9C 7B E0 37 3B 05 BE 20 20 20 20 20 20 ....{.7;..
0030: 20 20 20 20 20 20 20 20 20 20 20 20

Notes :

00 00 00 00 00 00 --> @MAC Source (couche 2) --> Normalement @MACr
00 00 00 00 00 00 --> @MAC Destination (couche 2) --> Normalement @MACv
00 00 --> Type 0x806 ' ARP (couche 2)
00 00 --> Type hardware ' ethernet (couche 3)
00 00 --> Opcode 0x0002 ' reply
00 00 00 00 00 00 --> @MAC Sender --> Normalement @MACp
00 00 00 00 --> @IP Sender --> Normalement @IPr
00 00 00 00 00 00 --> @MAC Target --> Normalement @MACv
00 00 00 00 --> @IP Target --> Normalement @IPv

Dans la couche 3, au niveau du protocol ARP (pas encore tout à fait IP) on devrait constater que @MAC Sender et @IP Sender ne correspondent pas (objectif de l'attaque). Si cela est le cas, le paquet forgé est bon.

Question : Donner le contenu du cache ARP de la victime.

Désormais, le cache ARP de la victime devrait être :

[root@victime ~] arp

Address

HWtype

HWAddress

Flags

Mask

Iface

@IPr

ether

@MACp

C




eth0

@IPp

ether

@MACp

C




eth1

L'objectif semble atteint :-)

Question : Mettre en évidence l'atteinte de l'objectif par l'utilisation de la commande traceroute.

Réponse possible :

Il nous faut maintenant vérifier que le trafic sortant de la machine victime transit bien par celle du pirate. Un nouveau traceroute vers le routeur, depuis la victime devrait ressembler à :

[root@victime ~]# traceroute @IPr
traceroute to @IPr (@IPr), 30 hops max, 40 byte packets
1 @IPp (@IPp) 1.712 ms 1.465 ms 1.501 ms
2 @IPr (@IPr) 2.238 ms 2.121 ms 2.169 ms


L'objectif semble atteint :-)
L'attaquant peut donc désormais écouter le trafic Victime --> Routeur.

Question : Mettre en évidence la réussite de l'attaque par l'utilisation de la commande ping vers le routeur. Comment procédez-vous ? Que constatez-vous ?

Réponse possible :

Lancer un sniffer sur la machine de l'attaquant. Essayer de filtrer la capture du trafic (host @IPv …). Lancer un ping @IPr sur la machine victime. La requête icmp devrait aboutir sur la machine du pirate.

Packetyzer Trace:
Frame 1 (74 bytes on wire, 74 bytes captured)
Frame is marked: False
Arrival Time: Oct 6, 2004 11:54:50.1839829520
Time delta from previous packet: 0.000000000 seconds
Time since reference or first frame: 0.000000000 seconds
Frame Number: 1
Packet Length: 74 bytes
Capture Length: 74 bytes
Data (74 bytes)

0000: 00 09 6B 7D B6 E2 00 01 02 9C 7B E0 08 00 45 00 ..k}......{...E.
0010: 00 3C C8 E8 00 00 80 01 F9 A3 37 3B 05 BE 37 3B ..........7;..7;
0020: 04 01 08 00 2C 5C 02 00 1F 00 61 62 63 64 65 66 ....,\....abcdef
0030: 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 ghijklmnopqrstuv
0040: 77 61 62 63 64 65 66 67 68 69 wabcdefghi

@MACp
@IPr


Conclusion


Plusieurs solutions peuvent être mises en œuvre afin de limiter ce scénario catastrophe :
- Contenu statique des caches ARP (intérêts et limites).
- Outils permettant de monitorer les paires @IP/@MAC (arpwatch, winarpwatch, xarp …).
- Détecteur d'intrusion implémentant un module de surveillance du protocole arp (snort, prelude, …).
- Analyse régulière des logs pertinents (tâche classique d'un administrateur réseau ou sécurité).
- Une sensibilisation des administrateurs à la sécurité réseau.
- …
A ce stade les étudiants pourraient proposer des améliorations possible du protocole ARP (ajout ou modification de certains mécanismes

http://www.securiteinfo.com/conseils/nat.shtml

NAT

Overview
La technique de translation d'adresses (NAT en anglais, RFC 3022) est une pratique courante qui est apparue à l'origine pour palier au manque croissant d'adresses IPv4 libres. En effet, ces adresses sont codées sur 4 octets et sont du type 0.0.0.0 à 255.255.255.255 (certaines valeurs étant réservées et par conséquence inutilisables); il y a donc peu d'adresses disponibles en comparaison du nombre croissant de machines sur Internet. Il fut donc décidé de réserver des intervalles d'adresses à des usages privés uniquement (RFC 1918). Ce sont les adresses :
10.0.0.0 - 10.255.255.255 (10/8 prefix)

172.16.0.0 - 172.31.255.255 (172.16/12 prefix)

192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
En conséquence, ces adresses ne sont pas routables sur Internet et ne doivent pas être utilisées par des machines de ce réseau. Par contre, tous les réseaux privés peuvent utiliser ces adresses sans restrictions.

Comme ces adresses ne sont pas routables sur le réseau public, la translation d'adresse est utilisée pour permettre aux machines du réseau privé d'accéder à Internet, et de façon générale à d'autres réseaux. Le principe de base est simple puisqu'il s'agit de remplacer à la volée les champs d'adresses dans les paquets qui sont destinés à un autre réseau (ce qui implique que le NAT soit effectué entre les 2 interfaces réseau, entre le réseau privé et les autres).


Comme le montre le schéma, le NAT va effectuer le remplacement de l'IP source de A par son IP X puis il va router le paquet vers le réseau extérieur. La réponse lui parviendra, et suivant la technique utilisée que nous allons détailler plus loin, il va cette fois-ci modifier l'adresse de destination X pour celle de A sur son réseau privé.

Techniques de translation
Il existe plusieurs variantes de NAT suivant la topologie du réseau privé, le nombre de machines privées, le nombre d'adresses IP publiques et les besoins en termes de services, d'accessibilité et de visibilité de l'extérieur.

Le NAT de base est statique et attribue de façon automatique une adresse IP à une autre. Aucune information liée à la connexion n'est nécessaire, il suffit de modifier le paquet suivant la règle prédéfinie de translation. L'idéal dans ce cas-ci est d'avoir le même nombre d'IP extérieures que d'IP privées.
Le NAT dynamique ne considère aucune association prédéfinie entre l'IP publique et l'IP privée de la requête qu'il reçoit. Il peut d'ailleurs y avoir plusieurs IP extérieures tout comme il y a plusieurs IP privées. Cela entraine nécessairement un suivi de la connexion car le NAT attribue l'IP extérieure lors de la requête initiale qui provient de son réseau privé; il doit ensuite pouvoir discriminer les paquets entrants de façon à pouvoir leur attribuer à chacun l'IP correspondante sur le réseau privé (celle de la connexion). Le but étant de rester transparent vis-à-vis de l'ordinateur source ou distant; un problème se pose si l'on ne dispose pas du même nombre d'adresses IP externes que d'adresses privées, car si toutes les adresses externes sont déjà en cours d'utilisation, aucune machine supplémentaire ne pourra accéder au réseau extérieur.
Le NAPT MASQ (Network Address and Port Translation) permet de résoudre le problème cité précédement et s'avère donc particulièrement utile si le nombre d'adresses externes est limité; c'est le cas typique d'une connexion Internet simple où plusieurs machines vont devoir partager la même adresse IP publique (externe).

Le problème technique derrière cette méthode est bien de savoir à quelle machine privée les paquets entrants sont destinés, puisqu'ils ont tous -à priori- la même adresse IP de destination (celle de la passerelle). Pour permettre leur différenciation, le NAT va devoir conserver une trace plus complète des paramètres de chaque connexion de façon établir un véritable contexte pour chacune de ces dernières. Parmi ces critères de séparation, citons :
l'adresse source est le premier élément qui est regardé; chaque machine du réseau privé aura tendance dans la majorité des cas à communiquer avec une machine extérieure différente. Donc les paquets entrants seront porteurs de cette information et permettront au NAT d'identifier la machine à l'origine de chaque échange. Mais cela ne fonctionnera pas si les machines extérieures ne sont pas toutes différentes.

le protocole supérieur peut également être régardé par le NAT pour pouvoir identifier le contexte. Ce sera par exemple de l'UDP ou du TCP, et si une machine utilise le premier et une autre utilise TCP, alors le NAT saura retrouver la machine initiale de la connexion.

le port et d'autres informations liées aux protocoles supérieurs peuvent être utilisés pour identifier chaque contexte. Ainsi le NAT pourra faire la différence entre des paquets entrants qui présentent la même IP source, le même protocole de transport mais un port de destination différent.

Il reste un dernier cas dans lequel tout cela ne suffira pas, c'est celui où les 2 contextes basés sur ces informations sont identiques, c'est-à-dire quand les paquets entrants présentent la même IP source, le même protocole de transport et le même port de destination. Dans ce cas-là, le NAT effectue une translation de port en même temps que d'adresse pour pouvoir identifier les flux de façon certaine. Cela consiste à modifier les paramètres de connexion avec la machine distante de façon à utiliser le port voulu sur la passerelle où se situe le NAT. Cette opération reste transparente pour la machine locale (privée) puisque cela est effectué au niveau du NAT qui rétablit ensuite les paramètres initiaux pour cette machine.

Comme il existe 65535 ports disponibles (moins les 1024 réservés), cela laisse une grande marge de sécurité. La dénomination MASQ provient du fait que cette opération est comparable à une attaque du type man-in-the-middle sauf qu'elle ne vise pas à obtenir quelqu'information que ce soit (la législation à ce niveau est stricte, voir les recommandations de la CNIL).
Le NAPT Redirect/Port Forwarding est identique au précédent sauf qu'il présente des services additionnels de redirection des flux entrants ou sortants. Ainsi, le Port Forwarding permet à l'extérieur d'accéder à un service (serveur WEB ou autre) qui est en fait basé sur une machine de réseau privé : la machine distante pense communiquer avec la machine hébergeant le NAT alors qu'en fait celui-ci redirige le flux vers la machine correspondant réellement à ce service. Le Redirect permet quant à lui de rediriger les flux sortants vers des services particuliers commes des proxies, firewalls, etc...
Le Bi-directional NAT diffère des précédents puisqu'il permet à des machines distantes d'accéder à des machines du réseau privé, et ce directement contrairement au Port forwarding. Le principe fait appel au service DNS pour interpréter les requêtes; celles-ci sont initiées par la machine distante et reçues par le NAT. La passerelle répond par sa propre adresse IP tout en gardant en mémoire l'association entre l'IP distante et l'IP requise pour le service. Ainsi, les paquets provenant de la machine distante seront transférés vers la machine correspondante.

Le problème de cette technique est l'utilisation du service DNS qui peut être couteux dans le cas d'un utilisateur de base accédant au réseau public Internet. Par contre, cette solution pourra se révéler utile dans le cas d'une entreprise interconnectant plusieurs réseaux privés car les serveurs DNS sont alors mieux maitrisés.
Le Twice-NAT est, comme son nom l'indique, une technique de double translation d'adresses et de ports. A la fois les paramètres de destination et ceux de la source seront modifiés. Concrètement, on peut dire que le NAT cache les adresses internes vis-à-vis de l'extérieur ainsi que les adresses externes vis-à-vis du réseau privé. L'utilité de cette technique apparait quand plusieurs réseaux privés sont interconnectés : comme nous l'avons expliqué précédement, les machines doivent utiliser des plages d'adressage bien précises ce qui peut créer des conflits et des collisions entre plusieurs réseaux privés (c'est-à-dire plusieurs machines utilisant la même adresse IP privée). Le Twice-NAT permet de résoudre ces problèmes de collisions en modifiant les 2 adresses du paquet.
Le NAT avec Serveurs Virtuels/Load Balancing est une évolution des techniques de NAT qui permet d'optimiser leurs implémentations. L'utilisation de serveurs virtuels est actuellement très répandue; cela correspond à une machine inexistante représentée uniquement par son adresse IP et prise en charge par une ou plusieurs machines réelles qui ont également leurs propres adresses (différentes). Ainsi, les requêtes des machines distantes sont adressées à une ou plusieurs adresses virtuelles correspondant à la passerelle où est implémenté le démon effectuant le NAT. Celui-ci remplace alors l'adresse virtuelle par une des adresses réelles appartenant aux machines implémentant le service NAT, puis leur transmet la requete et la connexion associée.

La sélection de l'adresse réelle peut se faire sur la base de la charge de travail de la machine correspondante: si le serveur NAT est surchargé, on choisira un autre serveur NAT moins chargé. Cette technique est à la base du load balancing et il existe de nombreux algorithmes de sélection et de répartition de la charge.

Enfin, comme le service NAT est habituellement placé sur la machine chargée du routage, une évolution possible est l'utilisation de routes virtuelles tout comme nous avons vu les adresses virtuelles. Dans ce dernier cas, la passerelle possède plusieurs interfaces vers le réseau externe et peut choisir laquelle utiliser en fonction de la charge de traffic sur chaque brin.
Avantages et inconvénients
N'oublions pas que l'utilité principale du NAT est d'économiser les adresses IP nécessaires pour connecter un réseau à Internet par exemple. Cela s'avère particulièrement utile pour tout particulier possédant une connexion Internet simple (modem, ADSL, cable) avec allocation d'une adresse dynamique. Si ce particulier possède plusieurs machines sur son réseau privé, il pourra utiliser la fonctionnalité de NAT pour partager l'adresse IP de sa machine principale.

D'autre part, les fonctionnalités avancées du NAT permettent d'interconnecter plusieurs réseaux privés de façon transparente même s'il existe des conflits d'adressage entre eux.
Par contre, dans la majorité des techniques citées précédement, la connexion est nécessairement initiée à partir d'une machine locale. Les machines externes ne verront que l'adresse de la passerelle et ne pourront pas se connecter directement aux machines locales; cela est bien sûr résolu avec les techniques plus évoluées de translation, mais celles-ci restent couteuses et peu accessibles.

Enfin, l'opération même de translation peut poser un certain nombres de problèmes que nous allons aborder dans le paragraphe suivant.

Sécurité et NAT
Le NAT présente à la fois des inconvénients et des avantages au niveau de la sécurité pour les machines du réseau privé.
Tout d'abord, comme nous l'avons vu précédement, le NAT n'est pas une opération anodine et ce bien qu'il ait pour vocation d'être transparent. En effet, le NAT modifie les paquets IP et cela a pour conséquence directe de casser tout contôle d'intégrité au niveau IP et même aux niveaux supérieurs puisque TCP par exemple inclue les adresses dans ses checksums! Concrètement, on se rend compte qu'un protocole de sécurisation des datagrammes comme IPSec est totalement incompatible avec le NAT, que ce soit en mode tunneling ou transport (voir fiche IPSec).

Une autre raison simple est qu'un NAT évolué a tendance à remonter les couches pour étudier les protocoles de transport afin de rassembler assez d'informations pour chaque contexte. Tout chiffrement à ce niveau empêcherait donc le NAT de fonctionner, puisque les informations seraient alors cryptées.
Un des avantages du NAT est de protéger les machines du réseau privé d'attaques directes puiqu'elles ne sont en fait pas accessibles de l'extérieur. De plus dans la majorité des cas, les requêtes de connexion ne peuvent provenir que de ces machines privées. Cela permet également de se prémunir contre un monitoring du traffic qui viserait à scruter les communications entre 2 machines particulières, un serveur sur Internet par exemple et une machine du réseau privé. Comme cette dernière n'est plus identifiable, l'opération devient impossible à moins de remonter au niveau applicatif (d'où l'utilité d'utiliser une protection/chiffrement à ce niveau également).

Conclusion
Le NAT est aujourd'hui incontournable dans la plupart des topologies réseau, à partir du moment où l'on souhaite connecter le réseau à d'autres. Comme nous l'avons vu, les techniques correspondant au service NAT ont évolué pour répondre aux besoins croissants de transparence, connectivité, disponibilité, etc... Quoiqu'il en soit, l'utilisation d'une telle technique ne doit pas être prise à la légère car elle implique autant d'inconvénients que d'avantages. Enfin, on peut s'interroger sur la pérennité du NAT sachant que cette technique n'était à l'origine destinée qu'à palier les lacunes d'IPv4. Or, il y a fort à parier qu'elle sera toujours effective avec les nouvelles adresses IPv6, autant à cause de ses qualités de sécurisation que du fait de la lenteur prévisible de la migration des terminaux d'un système d'adressage à l'autre.


Module NET Cours 4


Notes et compléments du cours 4.

  • Résumé du cours sur les réseaux locaux

  • Présentation d'Ethernet comme illustration des LAN

  • Mécanismes de communications dans les LAN

    • Adressage

    • ARP

    • RARP

Communication dans les réseaux locaux


Les réseaux locaux de type Ethernet permettent d'avoir une communication directe entre les machines qui sont physiquement reliées au réseau. Cette communication est réalisée ici en utilisant Ethernet comme réseau d'exemple. Les trames Ethernet utilisent des adresses physiques inscrites en dur dans les cartes par les constructeurs pour s'identifier. Si on connaît l'adresse physique (aussi appelée adresse MAC) d'une carte il est possible de lui envoyer des données directement. Par contre si on ne connaît que son adresse IP il faut pouvoir retrouver son adresse MAC. Le mécanisme de résolution d'adresse proposé ici est le protocole ARP (Address Resolution Protocol) qui permet en deux échanges de trames de retrouver l'adresse MAC d'une machine à partir de son adresse IP.

Le protocole ARP est bien un protocole de niveau 3 car il permet au niveau réseau de savoir avec qui il veut communiquer sur le lien Ethernet. Après la résolution ARP, la couche de niveau 3 ne connaît que la taille des identifiants de niveau 2 et des valeurs numériques pour joindre les machines distantes. De cette façon IP peut fonctionner sur plusieurs types de protocoles de niveau 2 sans changer le principe de base de la résolution d'adresse ARP. Les requêtes ARP sont véhiculées dans des trames Ethernet.

Trame Ethernet




  • Préambule:

  • Destination: adresse Ethernet de destination

  • Source: adresse Ethernet source de la trame

  • Type: type de données transportées

  • Données: taille maximum 1500 octets. Les données sont complétées par des octets de bourrage pour avoir une taille minimum de 46 octets

  • CRC: somme de contrôle sur la trame

Les adresses Ethernet sont composées de 8 octets et sont habituellement notées en hexadécimal sous la forme 12:34:56:78:9a:bc. Les 3 premiers octets de l'adresse sont fixes pour un constructeur et les 3 derniers servent à assurer l'unicité des adresses physiquement inscrites dans les cartes Ethernet produites en série.

Les types rencontrés habituellement pour les trames Ethernet dans un réseau TCP/IP sont les suivantes

Trame ARP




Une requête/réponse ARP est véhiculée par une trame Ethernet de type 0x0806. La machine émettrice envoie une requête en broadcast (FF:FF:FF:FF:FF:FF) afin de contacter toutes les machines du réseau local au niveau Ethernet. La machine qui reconnais son adresse IP peut renvoyer une réponse ARP en utilisant l'adresse Ethernet inscrite dans la requête comme adresse de destination. Voici un exemple de requête/réponse entre une machine d'adresse IP 129.104.254.6 cherchant à contacter la machine 129.104.254.5

  • Requète ARP

    • Partie Ethernet

      • FF:FF:FF:FF:FF:FF broadcast adresse destination question ARP

      • 08:00:20:02:45:9E} adresse Ethernet source

      • 0x0806 type de trame ethernet question ARP

    • Partie ARP

      • 0x0001 type de réseau de niveau 2 -> ethernet

      • 0x0800 type de réseau de niveau 3 -> IP

      • 0x06 taille des adresses de niveau 2 (6 octets)

      • 0x04 taille des adresses de niveau 3 (4 octets)

      • 0x0001 opcode : requête

      • 08:00:20:02:45:9E adresse Ethernet source

      • 81.68.FE.06 adresse IP source (129.104.254.6)

      • 00:00:00:00:00:00 adresse MAC demandée (non renseigné dans la requète)

      • 81.68.FE.05 adresse IP demandée.

  • Réponse ARP

    • Partie Ethernet

      • 08:00:20:02:45:9E dest trame ethernet

      • 08:00:20:07:0B:94 source trame ethernet

      • 0x0806 trame ARP

    • Partie ARP

      • 0x0001 ethernet

      • 0x0800 IP

      • 06 adresses Ethernet sur 6 octets

      • 04 adresses IP sur 4 octets

      • 0x0002 réponse ARP

      • 08:00:20:02:45:9E adresse Ethernet source

      • 81.68.FE.06 adresse IP source (129.104.254.6)

      • 08:00:20:02:45:9E adresse MAC demandée

      • 81.68.FE.05 adresse IP demandée.

Certains systèmes d'exploitation apprennent les adresses Ethernet des autres machines en écoutant les requêtes ARP qui passent sur le réseau.

Les traductions IP/ARP sont conservées dans une machine de façon temporaire dans une
table ARP. Vous pouvez voir le contenu de la table de la machine sur laquelle vous êtes en tapant la commande (sous Unix) arp -a



http://www.ybet.be/hardware2_ch11/Reseau_sans_fil.htm
http://www.linux-france.org/prj/edu/archinet/systeme/c1602.html

similaire:

Tp arp poisoning iconNote apparaît clairement. Le protocole arp
«Internet Le protocole arp» issu de CommentCaMarche net est soumis à la licence gnu fdl. Vous pouvez copier, modifier des copies...








Tous droits réservés. Copyright © 2016
contacts
p.21-bal.com