Skip to main content
  1. Concetti/

ARP - Address Resolution Protocol

·11 mins
Alessio Barnini
Author
Alessio Barnini
Table of Contents

Mappa ARP
#

Cos'è
#

Protocollo che traduce indirizzi IP (Layer 3) in indirizzi MAC (Layer 2). Quando un dispositivo vuole comunicare con un IP nella stessa subnet, usa ARP per scoprire il MAC address corrispondente prima di poter inviare i dati.

Note

Frame = unita' dati del Layer 2 (Ethernet). Ogni layer ha il suo nome: Layer 4 = Segment/Datagram, Layer 3 = Packet, Layer 2 = Frame, Layer 1 = Bit. Un frame Ethernet contiene MAC sorgente, MAC destinazione, tipo e payload (il pacchetto IP dentro). Lo switch legge solo il MAC del frame — non guarda mai l'IP.

Il problema che risolve
#

Layer 3 (IP)  →  sa dove vuole andare: 192.168.1.20
Layer 2 (MAC) →  non conosce IP — lavora solo con MAC

Domanda: come trovo il MAC di 192.168.1.20?
Risposta: ARP

Come funziona
#

[PC A]                    [BROADCAST]              [PC B]
192.168.1.10                                    192.168.1.20
AA:BB:CC:11:22:33                            DD:EE:FF:44:55:66
     │                                                │
     │── ARP Request ────────────────────────────────►│
"Chi ha 192.168.1.20?                        │
     │    Rispondimi — sono AA:BB:CC:11:22:33"(tutti ricevono)     │                                                │
     │◄── ARP Reply ───────────────────────────────── │
"Sono io — DD:EE:FF:44:55:66"     │                                                │
     │ salva in ARP cache:                            │
     │ 192.168.1.20 → DD:EE:FF:44:55:66               │

ARP Cache
#

# Visualizza la ARP cache locale
arp -a

# Output esempio:
192.168.1.1   → 00:11:22:33:44:55  [router]
192.168.1.20  → DD:EE:FF:44:55:66  [PC B]
192.168.1.30  → AA:BB:CC:77:88:99  [stampante]

La cache evita di fare ARP request ad ogni pacchetto. Le entry scadono dopo qualche minuto — ARP viene rifatto automaticamente.

I due MAC address nel pacchetto ARP
#

Quando il PC non conosce il MAC di destinazione, il pacchetto ARP contiene due indirizzi MAC con significati diversi:

PACCHETTO ARP REQUEST
┌─────────────────────────────────────────────────┐
│  Header Ethernet                                │
│    MAC src:  AA:BB:CC:11:22:33  (il mio MAC)│    MAC dst:  ff:ff:ff:ff:ff:ff  (broadcast)     │ ← frame Ethernet
├─────────────────────────────────────────────────┤
│  Payload ARP                                    │
│    Sender MAC: AA:BB:CC:11:22:33                │
│    Sender IP:  192.168.1.5                      │
│    Target MAC: 00:00:00:00:00:00                │ ← "non lo so ancora"
│    Target IP:  192.168.1.10                     │
└─────────────────────────────────────────────────┘
ff:ff:ff:ff:ff:ff → indirizzo broadcast Ethernet
                    il frame viene consegnato a TUTTI
                    i dispositivi della LAN dallo switch

00:00:00:00:00:00 → campo "Target MAC" nel payload ARP
                    significa: "questa è l'informazione che cerco"
                    non è un indirizzo reale — è un placeholder

Sono due livelli distinti che fanno due cose diverse:

  • ff:ff:ff:ff:ff:ff — dice allo switch "manda a tutti" (Layer 2)
  • 00:00:00:00:00:00 — dice al destinatario "dimmi il tuo MAC" (payload ARP)

CAM Table — come lo switch decide dove mandare il frame
#

Lo switch non manda il traffico in broadcast per tutto il traffico normale — solo quando non conosce la destinazione. Per decidere quale porta usare, mantiene una CAM table (Content Addressable Memory):

CAM TABLE DELLO SWITCH
┌──────────────────┬──────────┬──────────┐
│    MAC Address   │  Porta   │  Scade   │
├──────────────────┼──────────┼──────────┤
│ AA:BB:CC:11:22:33│  Porta 15 min   │ ← PC A
│ DD:EE:FF:44:55:66│  Porta 35 min   │ ← PC B
│ 00:11:22:33:44:55│  Porta 85 min   │ ← Router
└──────────────────┴──────────┴──────────┘

Logica dello switch quando riceve un frame:

Frame in arrivo → legge MAC destinazione
            ┌──────────┴──────────┐
            │                     │
      MAC noto in           MAC sconosciuto
       CAM table                  │
            │                     ▼
            ▼              Flooding: manda
      Manda solo           su TUTTE le porte
      sulla porta          tranne quella
      giusta               di ingresso

Il MAC broadcast ff:ff:ff:ff:ff:ff non è mai nella CAM table — per definizione viene sempre mandato su tutte le porte (flooding).

Note

MAC Flooding attack: un attaccante inonda lo switch con frame da MAC sorgenti sempre diversi — la CAM table si riempie e lo switch inizia a fare flooding di tutto il traffico su tutte le porte. Risultato: l'attaccante vede il traffico di tutti.


Comandi utili
#

ComandoFlagSignificato flagCosa faQuando usarlo
arp -n-nnumeric — non risolvere hostnameMostra ARP table con IP numericiDiagnosi veloce
arp -a -n-a all, -n numerictutti i dispositivi, no DNSEquivalente macOS di arp -nSu macOS
ip neighbor showARP table con stato entryVedere REACHABLE, STALE, FAILED
ip n flush dev eth0flush svuota, dev devicecancella entries sull'interfacciaSvuota ARP cacheDopo ARP poisoning sospetto
sudo tcpdump -i eth0 arp-i interface, arp filtrocattura solo ARPTraffico ARP in tempo realeRilevare "Who has" anomali
sudo arp-scan -l-l localscansiona rete localeInventario host via ARPScoprire dispositivi sconosciuti
sudo arping -I eth0 192.168.1.1-I Interfacespecifica interfacciaARP request a IP specificoVerificare se host è attivo
# Vedere la ARP table con stato
ip neighbor show
# 192.168.64.1 dev eth0 lladdr 72:8c:f2:1b:c8:64 REACHABLE
# 192.168.64.3 dev eth0 lladdr b6:56:08:90:16:03 STALE

# Catturare ARP in tempo reale
sudo tcpdump -i eth0 arp -n
# ARP request: who-has 192.168.64.3 tell 192.168.64.200
# ARP reply:   192.168.64.3 is-at b6:56:08:90:16:03

# Inventario LAN
sudo arp-scan -l
# 192.168.64.1  72:8c:f2:1b:c8:64  (Unknown)
# 192.168.64.3  b6:56:08:90:16:03  (Unknown)
Tip

ip neighbor show è più utile di arp -n perché mostra lo stato della entry: REACHABLE (comunicato di recente), STALE (obsoleto), FAILED (non raggiungibile). In un'investigazione, una entry che passa da REACHABLE a un MAC diverso è un segnale di ARP poisoning.


I due MAC address nel pacchetto ARP
#

Quando il PC non conosce il MAC di destinazione, il pacchetto ARP contiene due indirizzi MAC con significati diversi:

PACCHETTO ARP REQUEST
┌─────────────────────────────────────────────────┐
│  Header Ethernet                                │
│    MAC src:  AA:BB:CC:11:22:33  (il mio MAC)│    MAC dst:  ff:ff:ff:ff:ff:ff  (broadcast)     │ ← frame Ethernet
├─────────────────────────────────────────────────┤
│  Payload ARP                                    │
│    Sender MAC: AA:BB:CC:11:22:33                │
│    Sender IP:  192.168.1.5                      │
│    Target MAC: 00:00:00:00:00:00                │ ← "non lo so ancora"
│    Target IP:  192.168.1.10                     │
└─────────────────────────────────────────────────┘
ff:ff:ff:ff:ff:ff → broadcast Ethernet — lo switch manda a TUTTI
00:00:00:00:00:00 → placeholder nel payload ARP
                    significa: "questa e' l'informazione che cerco"

Come leggere il pacchetto ARP in Wireshark:

Opcode: request (1)  → ARP Request
Opcode: reply (2)    → ARP Reply

CAM Table — come lo switch decide dove mandare il frame
#

Lo switch mantiene una CAM table (Content Addressable Memory) per sapere su quale porta si trova ogni MAC address:

CAM TABLE DELLO SWITCH
┌──────────────────┬──────────┬──────────┐
│    MAC Address   │  Porta   │  Scade   │
├──────────────────┼──────────┼──────────┤
│ AA:BB:CC:11:22:33│  Porta 15 min   │ ← PC A
│ DD:EE:FF:44:55:66│  Porta 35 min   │ ← PC B
│ 00:11:22:33:44:55│  Porta 85 min   │ ← Router
└──────────────────┴──────────┴──────────┘

Logica dello switch:

Frame in arrivo → legge MAC destinazione
            ┌──────────┴──────────┐
            │                     │
      MAC noto                MAC sconosciuto
       in CAM                       │
            │                       ▼
            ▼              Flooding: manda su
      Solo sulla            TUTTE le porte
      porta giusta          tranne ingresso

Il MAC broadcast ff:ff:ff:ff:ff:ff viene sempre flooded — per definizione.

Warning

MAC Flooding attack: un attaccante inonda lo switch con frame da MAC sorgenti sempre diversi — la CAM table si riempie e lo switch inizia a fare flooding di tutto il traffico su tutte le porte. Risultato: l'attaccante vede il traffico di tutti i dispositivi.


Gratuitous ARP — ARP non richiesto
#

Un Gratuitous ARP e' un pacchetto ARP mandato in broadcast dove Sender IP e Target IP sono lo stesso indirizzo:

Sender MAC: 00:03:47:b7:f2:f5
Sender IP:  24.6.125.19
Target MAC: 00:00:00:00:00:00
Target IP:  24.6.125.19         ← stesso IP del sender

Tutti i dispositivi che ricevono questo pacchetto aggiornano la loro ARP cache con la nuova associazione IP→MAC, senza che nessuno lo abbia chiesto.

Usi legittimi:

1. Cambio IP:       il dispositivo aveva 192.168.1.10, ora ha .20
                    annuncia il cambio a tutta la LAN

2. Avvio sistema:   il dispositivo si accende e annuncia la sua presenza

3. Load balancing:  se un server cade, l'altro manda Gratuitous ARP
                    per reindirizzare il traffico verso se stesso

Uso malevolo — come costruisce il pacchetto un attaccante:

Obiettivo: far credere a tutti che il gateway (192.168.0.1) sia lui

Pacchetto Gratuitous ARP falso:
  Sender MAC: MAC_attaccante
  Sender IP:  192.168.0.1     ← IP del gateway
  Target IP:  192.168.0.1     ← stesso

Risultato su ogni dispositivo della LAN:
  192.168.0.1 → MAC_attaccante  ← cache avvelenata
  Tutto il traffico verso internet passa dall'attaccante

Differenza tra Gratuitous ARP e ARP Poisoning normale:

ARP Poisoning normale → manda ARP Reply non richiesta
Gratuitous ARP falso  → manda ARP Request con IP src=IP target
Risultato:            → identico, entrambi avvelenano la cache
Tip

In Wireshark il Gratuitous ARP appare con il flag [Is gratuitous: True] nel dettaglio del pacchetto ARP. Un numero elevato di Gratuitous ARP da indirizzi sconosciuti e' un segnale di ARP poisoning in corso.


ARP Poisoning — l'attacco
#

SCENARIO NORMALE:
  PC A chiede: "Chi ha 192.168.1.1 (gateway)?"
  Router risponde: "Sono io — MAC 00:11:22:33:44:55"

ATTACCO ARP POISONING:
  Attaccante manda ARP Reply falsa senza che nessuno abbia chiesto:
  "192.168.1.1 sono io — MAC FF:FF:FF:AA:AA:AA"  ← FALSO

  PC A aggiorna la cache:
  192.168.1.1 → FF:FF:FF:AA:AA:AA  ← ora punta all'attaccante

  Tutto il traffico di PC A verso internet
  passa prima dall'attaccante → MITM completo
[PC A] ──────────► [Attaccante] ──────────► [Router] ──► Internet
        crede di               legge tutto,
        parlare col            poi passa avanti
        router                 (o no)

Perche' ARP e' vulnerabile
#

ARP non ha autenticazione. Accetta qualsiasi risposta senza verificare se qualcuno ha effettivamente fatto una richiesta. Questo design era ragionevole nelle reti locali degli anni '80, ma in reti moderne e' una superficie d'attacco significativa.

Gratuitous ARP e' un ARP Reply non richiesto usato legittimamente per aggiornare la cache della LAN dopo un cambio IP, e usato malevolmente per avvelenare le cache di tutti i dispositivi contemporaneamente.

Difese Blue Team
#

Le tre difese principali operano a livelli diversi: lo switch (DAI), la configurazione di sistema (ARP cache statica), e il monitoraggio (anomaly detection).

Dynamic ARP Inspection (DAI)
#

DAI e' una feature degli switch managed (Cisco, HP/Aruba, Juniper) che verifica ogni ARP packet in transito. Lo switch mantiene una DHCP snooping binding table che associa IP, MAC, porta e VLAN. Ogni ARP reply viene confrontata con questa tabella: se la coppia IP-MAC non corrisponde, il pacchetto viene scartato silenziosamente.

SENZA DAI:
  Attaccante manda ARP Reply falsa → accettata da tutti gli host

CON DAI:
  Attaccante manda ARP Reply falsa → Switch confronta con DHCP snooping table
  Coppia MAC/IP non trovata → pacchetto DROPPATO
  Host non riceve mai la risposta falsa → ARP cache rimane pulita

Configurazione su switch Cisco:

# Abilitare DHCP snooping sulla VLAN (prerequisito di DAI)
ip dhcp snooping
ip dhcp snooping vlan 10

# Abilitare DAI sulla VLAN
ip arp inspection vlan 10

# Configurare le porte trusted (uplink verso router e DHCP server)
interface GigabitEthernet0/1
 ip dhcp snooping trust
 ip arp inspection trust

# Le porte verso gli host restano untrusted per default
# su porte untrusted, ogni ARP viene verificato contro la binding table

Logica trusted vs untrusted:

Tipo portaCosa ci si connetteComportamento DAI
TrustedRouter, DHCP server, altri switchARP accettata senza verifica
UntrustedHost, workstation, dispositivi utenteARP verificata contro DHCP snooping table
Tip

La porta uplink verso il router deve essere configurata come trusted, altrimenti DAI droppera' anche le ARP reply legittime del router. Un router che non riesce a mandare ARP reply verso la LAN causa un blackout di rete completo.

ARP Cache Statica
#

Per i dispositivi piu' critici (gateway, DNS server, server di autenticazione), si puo' configurare una entry ARP statica che non viene mai sovrascritta da ARP reply dinamiche.

# Aggiungere entry ARP statica su Linux
sudo arp -s 192.168.1.1 00:11:22:33:44:55

# Verificare che l'entry sia marcata come permanente
ip neighbor show
# 192.168.1.1 dev eth0 lladdr 00:11:22:33:44:55 PERMANENT

Limite: in reti grandi e' impraticabile configurare ARP statiche per ogni host. Si usa solo per il default gateway e i server critici.

Monitoraggio Anomalie
#

Indicatori di ARP poisoning in corso che un sistema di monitoraggio o un analista puo' rilevare:

  • Stesso IP che appare con MAC diversi in un breve intervallo di tempo
  • Elevato numero di ARP Reply non richieste da un singolo MAC
  • Entry nella ARP cache che cambiano frequentemente
  • Gratuitous ARP da MAC sconosciuti alla rete

Tool per rilevare: arpwatch (notifica via email quando una coppia IP-MAC cambia), analisi di flusso SIEM con regola di correlazione su cambio MAC per stesso IP.

Dev parallel: in un'architettura a microservizi dove i servizi si chiamano via nome host interno (es. http://user-service:3000), il rischio ARP poisoning a Layer 2 e' reale se i container condividono la stessa rete Docker bridge o la stessa VLAN fisica. Un attaccante che compromette un container potrebbe fare ARP poisoning verso il gateway della rete interna, intercettando le chiamate tra microservizi. La difesa principale non e' solo a Layer 2 (DAI, segmentazione VLAN per servizio) ma anche a Layer 7: mutual TLS (mTLS) sulle comunicazioni inter-servizio garantisce che anche se il traffico fosse reindirizzato verso un impostore, l'handshake TLS fallirebbe per mancanza del certificato corretto.

Scenario Reale
#

Un analista SOC vede traffico anomalo — un utente si lamenta che la connessione è lenta e alcune sessioni si disconnettono. L'analista cattura traffico con Wireshark: vede decine di ARP Reply non richieste che mappano il gateway su un MAC sconosciuto. È ARP poisoning — qualcuno nella LAN sta intercettando tutto il traffico. Identifica il MAC attaccante, lo traccia alla porta dello switch, isola il dispositivo.

Dove l'ho incontrato
#

  • network-fundamentals — TryHackMe modulo 2
  • icmp-mac-ip — MAC address e Layer 2
  • osi-model — ARP opera tra Layer 2 e Layer 3

Collegato a
#

  • icmp-mac-ip — MAC address che ARP risolve
  • osi-model — il "ponte" tra Layer 2 e Layer 3
  • lan-topologies — ARP funziona solo nella stessa LAN
  • dhcp — DHCP snooping usato insieme a DAI per difendersi

Related