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.
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: ARPCome 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 placeholderSono 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 1 │ 5 min │ ← PC A
│ DD:EE:FF:44:55:66│ Porta 3 │ 5 min │ ← PC B
│ 00:11:22:33:44:55│ Porta 8 │ 5 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 ingressoIl MAC broadcast ff:ff:ff:ff:ff:ff non è mai nella CAM table —
per definizione viene sempre mandato su tutte le porte (flooding).
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#
| Comando | Flag | Significato flag | Cosa fa | Quando usarlo |
|---|---|---|---|---|
arp -n | -n | numeric — non risolvere hostname | Mostra ARP table con IP numerici | Diagnosi veloce |
arp -a -n | -a all, -n numeric | tutti i dispositivi, no DNS | Equivalente macOS di arp -n | Su macOS |
ip neighbor show | — | — | ARP table con stato entry | Vedere REACHABLE, STALE, FAILED |
ip n flush dev eth0 | flush svuota, dev device | cancella entries sull'interfaccia | Svuota ARP cache | Dopo ARP poisoning sospetto |
sudo tcpdump -i eth0 arp | -i interface, arp filtro | cattura solo ARP | Traffico ARP in tempo reale | Rilevare "Who has" anomali |
sudo arp-scan -l | -l local | scansiona rete locale | Inventario host via ARP | Scoprire dispositivi sconosciuti |
sudo arping -I eth0 192.168.1.1 | -I Interface | specifica interfaccia | ARP request a IP specifico | Verificare 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)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 ReplyCAM 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 1 │ 5 min │ ← PC A
│ DD:EE:FF:44:55:66│ Porta 3 │ 5 min │ ← PC B
│ 00:11:22:33:44:55│ Porta 8 │ 5 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 ingressoIl MAC broadcast ff:ff:ff:ff:ff:ff viene sempre flooded — per definizione.
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 senderTutti 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 stessoUso 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'attaccanteDifferenza 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 cacheIn 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 pulitaConfigurazione 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 tableLogica trusted vs untrusted:
| Tipo porta | Cosa ci si connette | Comportamento DAI |
|---|---|---|
| Trusted | Router, DHCP server, altri switch | ARP accettata senza verifica |
| Untrusted | Host, workstation, dispositivi utente | ARP verificata contro DHCP snooping table |
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 PERMANENTLimite: 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


