8.2. Détournement de flux

Les techniques de détournement de flux servent à rediriger le flux réseau vers un client, vers un serveur, ou vers une autre machine.

8.2.1. ARP-Poisoning

Toute carte réseau possède une adresse physique. C'est cette adresse qui lui permet de recevoir les paquets qui lui sont destinés sur le réseau local. Cette adresse physique est associée à l'adresse IP grâce au protocole ARP. La table de correspondance entre les adresses IP et les adresses physiques est contenue dans le cache ARP. Lorsqu'un échange doit s'établir entre 2 machines du réseau local, ces deux machines envoient des requêtes ARP avec l'adresse IP du récepteur, associée à un champ vide pour son adresse physique. Ce récepteur va renvoyer son adresse physique dans une réponse ARP.

Si un attaquant envoie un message de réponse ARP avec son adresse physique correspondant à l'adresse IP du récepteur, tout le flux IP dirigé vers le récepteur sera redirigé vers l'attaquant. On dit qu'il a empoisonné le cache ARP du récepteur.

Illustration :

B envoie à A une requête ARP pour connaître son adresse physique.
A renvoie à B son adresse physique par une réponse ARP. B la stocke dans son cache en faisant correspondre l'IP de A à son adresse physique.
Le trafic circule entre A et B.
C envoie à B, une réponse ARP avec son adresse physique correspondant à l'adresse IP de A. B stocke cette nouvelle correspondance dans son cache en écrasant l'ancienne.
C dialogue avec B à la place de A. A ne reçoit plus rien.

8.2.1.1. Comment s'en protéger ?

La solution la plus immédiate consiste à saisir manuellement sur chaque poste la table de toutes les adresses physiques présentes sur le réseau local. Si elle est immédiate, cette solution est quasiment inapplicable compte tenu du nombre d'hôtes connectés au réseau local.

Une solution correcte consiste à mettre en place un serveur DHCP avec une liste «fermée» de correspondance entre adresses physiques (MAC) et IP. Relativement à la solution précédente, la liste exhaustive des adresses physiques est centralisée sur le serveur DHCP. On peut ensuite configurer la journalisation du service pour que toute requête DHCP relative à une adresse MAC inconnue génère un courrier vers l'administrateur système.

Enfin, On peut utiliser sous UNIX, un logiciel spécialisé : arpwatch qui permet de surveiller tout le trafic ARP.

Les NIDS peuvent aussi détecter ce type d'attaques (notamment Prelude-IDS).

8.2.1.2. Documents

L'article Le arp-poisoning est une bonne introduction à la problématique.

La section Addresss Resolution Protocol (ARP) du Guide to IP Layer Network Administration with Linux montre toutes les possibilités d'interaction sur le protocole ARP avec le noyau Linux.

8.2.2. Désynchronisation TCP

L'ARP-Poisining permet de rediriger tout le trafic IP mais, si l'attaquant n'a besoin que du trafic TCP, il peut interférer entre une connexion client-serveur pour rediriger le flux du client vers lui. La synchronisation TCP est assurée par les numéros de séquences TCP. Si, pendant un échange, l'attaquant envoie des paquets mal formés au client avec une adresse IP correspondant à celle du serveur en y plaçant des mauvais numéros de séquences, le client va croire qu'il a perdu la connexion et stoppera ses échanges avec le serveur. Mais si l'attaquant envoie les bons numéros de séquences au serveur, il récupèrera la connexion pour lui.

Illustration :

A dialogue avec B. Il envoie un paquet avec de 60 octets, avec les numéros de séquences indiqués.
C répond à A en se faisant passer pour B et envoie de mauvais numéros de séquence.
A ne répond plus à B car il croit qu'il a perdu la connexion.
C répond à la place de A et communique avec B, il a volé la connexion.