ARP : résoudre une IP en adresse MAC sur le LAN

Vos deux serveurs sont sur le même réseau, le ping passe, mais vous ne savez pas comment l'adresse IP devient une adresse MAC ? ARP (Address Resolution Protocol) est la pièce manquante. Ce module vous montre comment une IPv4 est traduite en adresse matérielle sur un réseau local, comment lire et manipuler le cache ARP, et pourquoi ce protocole non authentifié est un terrain d'attaque classique (ARP spoofing). Public visé : débutant à intermédiaire en réseau, Linux ou DevSecOps.

TL;DR, L'essentiel en 30 secondes

• ARP traduit une adresse IPv4 (couche 3) en adresse MAC (couche 2 du modèle OSI) sur le réseau local.
• Mécanisme : une requête broadcast « qui a l'IP X ? » suivie d'une réponse unicast « c'est moi, voici ma MAC ».
• Le résultat est stocké dans le cache ARP, consultable avec ip neigh.
• ARP n'est pas authentifié : n'importe qui sur le LAN peut mentir, c'est la base du MITM par ARP poisoning.
• ARP n'existe pas en IPv6 : il est remplacé par NDP (Neighbor Discovery, via ICMPv6).

Je sais que c'est bon si...

• ip neigh show me liste des correspondances IP / MAC avec un état (REACHABLE, STALE)
• Je sais capturer une requête ARP avec tcpdump -i <iface> arp
• Je comprends pourquoi une entrée ARP statique protège contre le spoofing

Commandes minimales à retenir

ip neigh show                 # voir le cache ARP (commande moderne)
ip neigh flush all            # vider le cache
sudo tcpdump -e -n -i eth0 arp  # observer les trames ARP
arping -c 3 192.168.1.20      # tester la présence d'une IP

Ce que vous allez apprendre

• Situer ARP entre la couche 2 (Ethernet/MAC) et la couche 3 (IP).
• Décrire la séquence requête/réponse et le format du paquet ARP.
• Lire et modifier le cache ARP avec ip neigh (et l'ancien arp).
• Capturer des trames ARP avec tcpdump et arping.
• Reproduire un échange ARP dans un lab Docker isolé.
• Comprendre l'ARP spoofing et les défenses (entrées statiques, DAI, arpwatch).

Prérequis

• Savoir ce qu'est une adresse IP et un réseau local : voir Les bases absolues du réseau.
• Maîtriser les bases de la commande ip : voir ip : administrer le réseau.
• Un terminal Linux avec droits sudo (les commandes de capture nécessitent les privilèges réseau).

Pourquoi ARP est nécessaire

Sur un réseau local, deux machines ne s'envoient pas des paquets « par IP ». Elles s'envoient des trames Ethernet, et une trame Ethernet ne sait s'adresser qu'à une adresse MAC (l'identifiant matériel unique de chaque carte réseau, du type aa:bb:cc:dd:ee:01). L'adresse IP, elle, vit à un étage au-dessus : c'est la couche 3 (réseau) du modèle OSI, alors que la MAC est en couche 2 (liaison de données).

Quand votre machine veut joindre 192.168.1.20 sur le même réseau, elle connaît l'IP de destination mais pas la MAC correspondante. Or sans MAC, impossible de construire la trame Ethernet. ARP comble exactement ce trou : il résout une IPv4 en adresse MAC sur le domaine de broadcast local.

Analogie : le concierge de l'immeuble

Imaginez un immeuble (le réseau local). Vous voulez livrer un colis à « monsieur Dupont, appartement 20 » (l'IP), mais le système de tubes pneumatiques de l'immeuble n'achemine qu'en fonction d'un numéro de casier physique (la MAC). Vous criez dans la cage d'escalier : « Qui est l'appartement 20 ? » (requête ARP en broadcast). Dupont répond : « C'est moi, mon casier est le 47 » (réponse ARP). Vous notez la correspondance sur un post-it (le cache ARP) pour ne pas recrier à chaque colis.

ARP est défini par la RFC 826 (1982), toujours un standard Internet (STD 37). Il se situe entre la couche 2 et la couche 3 : il utilise les trames Ethernet pour transporter des informations qui servent à la couche IP. Son EtherType dans l'en-tête Ethernet est 0x0806 (à comparer à 0x0800 pour IPv4).

Comment fonctionne un échange ARP

L'échange tient en deux messages. Tout part du moment où une machine doit envoyer un paquet IP à une destination du même réseau local dont elle ignore la MAC.

1. Requête ARP (ARP request) : l'émetteur diffuse une trame en broadcast, c'est-à-dire vers l'adresse MAC de destination FF:FF:FF:FF:FF:FF. Toutes les machines du réseau local la reçoivent. Le message dit en substance : « Qui a l'IP 192.168.1.20 ? Répondez à 192.168.1.10 (MAC aa:bb:cc:dd:ee:01). »

2. Réponse ARP (ARP reply) : seule la machine qui possède l'IP demandée répond. Elle envoie une trame en unicast (directement à l'émetteur, pas en broadcast) : « 192.168.1.20, c'est moi, ma MAC est 00:11:22:33:44:55. » Les autres machines ignorent la requête.

3. Mise en cache : l'émetteur enregistre la correspondance IP / MAC dans son cache ARP. Les paquets suivants vers cette IP partent directement, sans nouvelle requête, tant que l'entrée reste valide.

Point important pour la sécurité : la réponse ARP est crue sur parole. Aucune machine ne vérifie que celui qui répond est réellement le propriétaire de l'IP. C'est cette absence de contrôle qui ouvre la porte à l'usurpation.

Le format du paquet ARP

Un paquet ARP est court et régulier. Pour IPv4 sur Ethernet, il fait 28 octets et contient les champs suivants (source : Wikipedia ARP, RFC 826) :

Champ	Taille	Rôle
HTYPE	16 bits	Type de protocole de liaison (1 = Ethernet)
PTYPE	16 bits	Type de protocole réseau (0x0800 = IPv4)
HLEN	8 bits	Longueur de l'adresse matérielle (6 octets pour une MAC)
PLEN	8 bits	Longueur de l'adresse protocole (4 octets pour IPv4)
OPER	16 bits	Opération : 1 = requête, 2 = réponse
SHA	48 bits	MAC de l'émetteur (Sender Hardware Address)
SPA	32 bits	IP de l'émetteur (Sender Protocol Address)
THA	48 bits	MAC de la cible (Target Hardware Address)
TPA	32 bits	IP de la cible (Target Protocol Address)

Glissez pour voir

Dans une requête, le champ THA (MAC cible) est vide ou à zéro : c'est justement ce qu'on cherche. Dans la réponse, tous les champs sont remplis.

Le cache ARP et la durée de vie des entrées

Recommencer une requête ARP pour chaque paquet serait absurde. Chaque machine garde donc un cache ARP (aussi appelé table de voisinage) : une liste de correspondances IP / MAC apprises récemment. Sous Linux, chaque entrée porte un état qui décrit sa fraîcheur, comme REACHABLE (validée récemment) ou STALE (suspecte, à revérifier). Le noyau gère lui-même l'expiration et la revalidation, sans intervention.

Cette mécanique de cache et ses états (REACHABLE, STALE, DELAY, PROBE, FAILED, PERMANENT) sont détaillés, avec les commandes complètes, dans le guide dédié à la commande ip. Retenez ici qu'un cache ARP n'est pas figé : il vit, expire, et peut être empoisonné.

Gratuitous ARP et proxy ARP

Deux variantes utiles existent au-delà du simple couple requête/réponse.

Le gratuitous ARP (ARP gratuit, ou GARP) est une annonce non sollicitée : une machine diffuse en broadcast « voici ma MAC pour mon IP » alors que personne n'a rien demandé. Cas d'usage légitimes : annoncer un changement d'adresse MAC après une bascule de serveur (failover de cluster, adresse IP virtuelle), forcer la mise à jour des caches des voisins, ou détecter un conflit d'IP au démarrage (si quelqu'un répond, l'IP est déjà prise).

Le proxy ARP consiste pour un équipement (souvent un routeur) à répondre à la place d'une autre machine, dont il sait acheminer le trafic. C'est un choix d'architecture délibéré, par exemple pour faire croire à deux sous-réseaux qu'ils sont sur le même segment. Mal maîtrisé, le proxy ARP brouille le diagnostic : une IP semble présente sur le LAN alors qu'elle est ailleurs.

Les commandes Linux pour observer et manipuler ARP

Deux générations d'outils coexistent. La moderne (iproute2) est à privilégier ; l'ancienne (net-tools) reste courante dans les scripts et la documentation existante.

ip neighbor, la commande moderne

ip neigh (abréviation de ip neighbour) gère le cache ARP en IPv4 et le cache NDP en IPv6. C'est la commande recommandée sous Linux depuis que arp est déprécié.

# Afficher tout le cache ARP/NDP
ip neigh show

# Restreindre à une interface
ip neigh show dev eth0

# Ajouter une entrée statique (permanente, non expirable)
sudo ip neigh add 192.168.1.50 lladdr aa:bb:cc:dd:ee:ff dev eth0 nud permanent

# Supprimer une entrée
sudo ip neigh del 192.168.1.50 dev eth0

# Vider tout le cache
sudo ip neigh flush all

Une sortie typique ressemble à ceci :

192.168.1.1 dev eth0 lladdr 00:11:22:33:44:01 REACHABLE
192.168.1.20 dev eth0 lladdr 00:11:22:33:44:55 STALE
192.168.1.99 dev eth0  FAILED

La dernière ligne montre une résolution échouée : aucune machine n'a répondu pour 192.168.1.99. La syntaxe complète (nud, change, replace, états) est couverte dans le guide ip et la man page ip-neighbour.

arp, l'ancienne commande (net-tools)

L'outil historique arp reste pratique pour une lecture rapide, mais il appartient au paquet net-tools, qui n'est plus installé par défaut sur de nombreuses distributions récentes (Debian, Ubuntu Server, Fedora, conteneurs minimalistes).

# Afficher le cache, avec résolution DNS des noms
arp -a

# Afficher sans résolution DNS (plus rapide, plus lisible)
arp -n

Si la commande renvoie command not found, installez le paquet ou, mieux, basculez sur ip neigh.

Debian / Ubuntu

sudo apt-get install -y net-tools

Rocky / Alma / Fedora

sudo dnf install -y net-tools

arping, tester la présence d'une IP

arping envoie des requêtes ARP « à la main » pour vérifier qu'une IP est bien occupée, sans dépendre d'ICMP (utile quand le ping est filtré par un pare-feu). Attention, deux implémentations existent (iputils et celle de Thomas Habets) ; les options ci-dessous suivent la version iputils, la plus répandue (man page arping).

# Tester si une IP répond (3 requêtes)
arping -c 3 -I eth0 192.168.1.20

# Détection de doublon d'adresse (DAD) : renvoie 0 si l'IP est libre
sudo arping -D -I eth0 192.168.1.50

# Annoncer sa propre IP aux voisins (gratuitous ARP)
sudo arping -U -I eth0 192.168.1.10

Le mode -D est idéal pour détecter un conflit d'IP avant d'assigner une adresse : s'il reçoit une réponse, l'adresse est déjà prise.

tcpdump, observer les trames ARP

Pour voir l'échange en direct, tcpdump filtre le trafic ARP. L'option -e affiche les adresses MAC (l'en-tête Ethernet), -n désactive la résolution DNS.

# Capturer uniquement le trafic ARP sur une interface
sudo tcpdump -n -i eth0 arp

# Avec les en-têtes Ethernet (MAC source/destination, EtherType)
sudo tcpdump -e -n -i eth0 arp

Sortie typique d'une requête puis d'une réponse (source : man tcpdump) :

14:32:01.123 aa:bb:cc:dd:ee:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.20 tell 192.168.1.10, length 28
14:32:01.125 00:11:22:33:44:55 > aa:bb:cc:dd:ee:01, ethertype ARP (0x0806), length 60: Reply 192.168.1.20 is-at 00:11:22:33:44:55, length 46

On lit clairement la grammaire d'ARP : who-has ... tell ... pour la requête en broadcast (ff:ff:ff:ff:ff:ff), ... is-at ... pour la réponse en unicast.

Lab reproductible : observer ARP avec Docker

Pour voir ARP fonctionner sans risquer votre réseau, le plus simple est un réseau bridge Docker avec deux conteneurs. Chaque conteneur a sa propre pile réseau (interface, table de routage, cache ARP isolé), exactement comme deux machines sur un même LAN. Pour aller plus loin sur les types de réseaux, voir Réseaux Docker.

Pourquoi --cap-add

tcpdump et arping ont besoin de capacités réseau (NET_RAW, NET_ADMIN) que Docker retire par défaut. On les rajoute explicitement sur les conteneurs du lab, jamais en production.

1. Créer un réseau bridge dédié : un sous-réseau isolé pour le lab.

   docker network create --subnet 172.30.0.0/24 lab-arp

2. Lancer deux conteneurs sur ce réseau, avec les outils nécessaires.

   docker run -d --name hote-a --network lab-arp --ip 172.30.0.10 \
     --cap-add NET_RAW --cap-add NET_ADMIN \
     nicolaka/netshoot sleep infinity
   
   docker run -d --name hote-b --network lab-arp --ip 172.30.0.20 \
     --cap-add NET_RAW --cap-add NET_ADMIN \
     nicolaka/netshoot sleep infinity

   L'image nicolaka/netshoot embarque ip, arping, tcpdump et ping.

3. Vider le cache ARP de hote-a pour partir d'un état propre.

   docker exec hote-a ip neigh flush all
   docker exec hote-a ip neigh show

   La sortie doit être vide : aucun voisin connu.

4. Lancer la capture ARP sur hote-a en arrière-plan, puis générer du trafic vers une IP jamais contactée.

   # Terminal 1 : capture sur hote-a
   docker exec hote-a tcpdump -e -n -i eth0 arp
   
   # Terminal 2 : ping vers hote-b (déclenche la résolution ARP)
   docker exec hote-a ping -c 2 172.30.0.20

   La capture montre la requête who-has 172.30.0.20 tell 172.30.0.10 en broadcast, suivie de la réponse 172.30.0.20 is-at ... en unicast.

5. Vérifier que le cache s'est rempli sur hote-a.

   docker exec hote-a ip neigh show

   Vous voyez maintenant une entrée 172.30.0.20 dev eth0 lladdr ... REACHABLE. La correspondance a été apprise et mémorisée.

6. Nettoyer le lab une fois l'observation terminée.

   docker rm -f hote-a hote-b
   docker network rm lab-arp

Variante sans Docker

Le même résultat s'obtient avec des namespaces réseau (ip netns) reliés par un bridge et des paires veth. C'est plus bas niveau mais identique sur le fond : deux piles réseau isolées qui dialoguent par ARP sur un segment commun.

Sécurité : ARP spoofing et défenses

ARP a un défaut de conception assumé : il est né en 1982 dans un monde de confiance, et n'intègre aucune authentification. N'importe quelle machine du réseau local peut envoyer une réponse ARP affirmant « l'IP X, c'est ma MAC », et les voisins la croient sur parole. C'est la racine d'une famille d'attaques.

Comment fonctionne l'ARP poisoning

L'ARP spoofing (ou ARP poisoning, empoisonnement du cache) consiste, pour un attaquant présent sur le LAN, à injecter de fausses correspondances IP / MAC dans le cache de ses victimes. Le scénario classique du Man-in-the-Middle (MITM) :

• L'attaquant dit à la victime : « la passerelle 192.168.1.1, c'est ma MAC ».
• Il dit à la passerelle : « la victime 192.168.1.42, c'est ma MAC ».
• Résultat : tout le trafic entre la victime et le reste du réseau transite par l'attaquant, qui peut l'observer, le modifier ou le bloquer.

Cette technique est référencée par le MITRE ATT&CK sous l'identifiant T1557.002 (Adversary-in-the-Middle : ARP Cache Poisoning). Elle ouvre la voie à l'interception de trafic, au vol de sessions et au mouvement latéral.

Périmètre pédagogique

Des outils offensifs comme ettercap, arpspoof (suite dsniff) ou bettercap automatisent ces attaques. Ils sont cités ici à titre défensif : savoir qu'ils existent aide à reconnaître une attaque et à tester ses propres défenses en environnement contrôlé. Aucun mode opératoire offensif n'est fourni. N'utilisez ces outils que sur un réseau dont vous êtes responsable et avec autorisation explicite.

Les défenses contre l'ARP spoofing

Comme on ne peut pas authentifier ARP lui-même, la défense combine plusieurs couches.

Défense	Niveau	Ce qu'elle apporte
Entrées ARP statiques	Hôte	Fige la MAC de la passerelle critique : ip neigh add ... nud permanent. Robuste mais ingérable à grande échelle.
Dynamic ARP Inspection (DAI)	Switch	Le switch inspecte chaque trame ARP et rejette celles qui ne correspondent pas à la table DHCP snooping. La défense de référence en entreprise.
Port security	Switch	Limite le nombre de MAC par port, bloque l'usurpation grossière.
arpwatch	Réseau	Surveille les changements de couple IP / MAC et alerte quand une MAC change pour une IP donnée (signe d'attaque).
Segmentation / VLAN	Architecture	Réduit la taille du domaine de broadcast, donc la surface exposée.
Chiffrement (TLS, VPN)	Applicatif	Même si le trafic est intercepté, il reste illisible. Ne stoppe pas l'attaque mais en limite l'impact.

Glissez pour voir

La Dynamic ARP Inspection (DAI) est la pièce maîtresse côté infrastructure : le switch compare chaque association IP / MAC annoncée par ARP à une source de vérité (la table de DHCP snooping) et jette les paquets non conformes (Cisco Meraki DAI).

Côté détection sur Linux, arpwatch journalise chaque couple IP / MAC vu sur le réseau et envoie une alerte au moindre changement suspect, ce qui transforme une attaque silencieuse en événement visible.

Le réflexe DevSecOps

Sur un réseau plat sans DAI ni segmentation, considérez le LAN comme hostile : chiffrez tout (HTTPS, SSH, mTLS entre services), ne faites jamais confiance à la couche 2 seule. ARP spoofing reste une attaque « facile » sur les réseaux d'entreprise mal segmentés.

ARP n'existe pas en IPv6 : place à NDP

Point souvent source de confusion : ARP est spécifique à IPv4. En IPv6, il n'y a pas d'ARP du tout. Sa fonction est reprise par le NDP (Neighbor Discovery Protocol), défini par la RFC 4861.

NDP ne s'appuie pas sur des trames Ethernet dédiées comme ARP, mais sur des messages ICMPv6 : Neighbor Solicitation (équivalent de la requête ARP) et Neighbor Advertisement (équivalent de la réponse). Différences notables :

• NDP utilise du multicast (groupe « solicited-node ») au lieu du broadcast d'ARP, ce qui réduit le bruit réseau.
• NDP couvre plus qu'ARP : découverte de routeurs, autoconfiguration d'adresse (SLAAC), détection d'adresse dupliquée (DAD).
• Côté Linux, le même ip neigh affiche les voisins IPv6 : la commande est unifiée.

Pour les pièges IPv6 en production, voir le module dédié dans cette formation.

Pièges courants et dépannage

ARP cause des incidents subtils parce qu'il est invisible tant qu'il fonctionne. Voici les symptômes les plus fréquents et leur cause.

Symptôme	Cause probable	Action
Connexion KO après changement de carte ou de VM	Cache ARP obsolète : ancienne MAC mémorisée	sudo ip neigh flush all puis re-tester
Entrée FAILED ou INCOMPLETE dans ip neigh	La cible ne répond pas (éteinte, mauvais VLAN, IP hors sous-réseau)	Vérifier que l'IP est bien sur le même LAN et active
Connexions intermittentes, latence anormale	Conflit d'IP : deux MAC pour une même IP	arping -D pour confirmer, puis corriger l'IP en double
Une machine d'un autre réseau « ne répond pas en ARP »	ARP ne traverse pas les routeurs : il est limité au domaine de broadcast	Normal : pour sortir du LAN, on passe par la passerelle
MAC d'une IP qui change toute seule	ARP spoofing possible, ou failover légitime (gratuitous ARP)	Corréler avec arpwatch, vérifier les bascules de cluster

Glissez pour voir

Le piège conceptuel le plus important : ARP est strictement local. Il ne fonctionne qu'à l'intérieur d'un domaine de broadcast (un segment LAN, un VLAN). Pour joindre une machine sur un autre réseau, votre hôte ne fait pas d'ARP sur l'IP distante : il fait un ARP sur la MAC de sa passerelle, puis lui confie le paquet. Si vous voyez une requête ARP pour une IP qui n'est pas dans votre sous-réseau, quelque chose cloche dans le routage ou le masque.

À retenir

• ARP traduit une IPv4 en adresse MAC sur le réseau local, entre la couche 3 (IP) et la couche 2 (Ethernet).
• Le mécanisme : requête broadcast « who-has » suivie d'une réponse unicast « is-at », puis mise en cache.
• ip neigh est la commande moderne pour lire et manipuler le cache ; arp (net-tools) est legacy et souvent absent.
• tcpdump -e arp et arping permettent d'observer et de tester ARP directement.
• ARP n'est pas authentifié : c'est la faille de conception qui rend l'ARP spoofing / MITM possible.
• Défenses : entrées statiques, Dynamic ARP Inspection, arpwatch, segmentation, et chiffrement applicatif.
• En IPv6, ARP n'existe pas : c'est NDP (ICMPv6) qui prend le relais.
• ARP est limité au LAN : il ne traverse jamais un routeur.

FAQ : questions fréquentes sur ARP

À quoi sert le protocole ARP ?

ARP (Address Resolution Protocol) traduit une adresse IPv4 en adresse MAC sur un réseau local. Pour envoyer une trame Ethernet à une machine du même réseau, on connaît son IP mais pas sa MAC : ARP comble ce trou en diffusant une requête « qui a cette IP ? » et en récupérant la MAC en réponse.

Quelle est la différence entre une adresse IP et une adresse MAC ?

L'adresse MAC est physique, gravée sur la carte réseau (couche 2), unique et locale au segment. L'adresse IP est logique, attribuée par configuration ou DHCP (couche 3), routable à travers Internet. ARP fait le lien entre les deux sur le réseau local.

Comment voir le cache ARP sous Linux ?

La commande moderne est `ip neighbor show` (ou `ip neigh`), qui liste les correspondances IP/MAC apprises avec leur état (REACHABLE, STALE, FAILED). La commande historique `arp -a` ou `arp -n` existe encore via net-tools, parfois à installer. Pour vider le cache : `ip neigh flush all`.

Qu'est-ce que l'ARP spoofing (ou ARP poisoning) ?

L'ARP spoofing est une attaque où un pirate envoie de fausses réponses ARP pour associer sa MAC à l'IP d'une autre machine (souvent la passerelle). Le trafic des victimes est redirigé vers l'attaquant en Man-in-the-Middle. Sans authentification, l'attaque est simple sur un LAN.

Comment se protéger de l'ARP spoofing ?

Plusieurs couches : entrées ARP statiques pour les machines critiques, Dynamic ARP Inspection (DAI) et port security sur les switches managés, arpwatch pour détecter les changements de MAC, segmentation réseau (VLAN), et surtout chiffrement de bout en bout (HTTPS, SSH) qui neutralise l'interception.

Le protocole ARP existe-t-il en IPv6 ?

Non. En IPv6, ARP est remplacé par NDP (Neighbor Discovery Protocol), défini dans la RFC 4861 et basé sur ICMPv6. NDP utilise des messages en multicast (et non broadcast comme ARP) et ajoute des fonctions comme l'autoconfiguration d'adresse.

Pourquoi ARP ne fonctionne-t-il que sur le réseau local ?

ARP repose sur le broadcast Ethernet, qui ne traverse pas les routeurs : il reste confiné au segment local. Pour joindre une machine d'un autre réseau, on envoie la trame à la MAC de la passerelle, qui se charge du routage. ARP ne sert qu'à joindre des voisins directs.

Prochaines étapes

La commande ip en détail États du cache ARP, ip neigh add/del/flush, NDP IPv6 : la référence complète des commandes.

ICMP, le protocole de diagnostic Comprendre ping, traceroute et les messages d'erreur réseau.

DHCP, comment votre machine obtient son IP Le processus DORA et le lien avec le DHCP snooping qui alimente la DAI.

Réseaux Docker Bridge, host, overlay : approfondir le réseau de conteneurs utilisé dans le lab.

La boîte à outils réseau Les commandes essentielles de diagnostic : ip, ss, ping, dig et compagnie.

×

📖 Voir la documentation →