Cosa fa#
Protocollo che assegna automaticamente configurazione di rete ai dispositivi che si connettono — IP address, subnet mask, gateway, DNS. Senza DHCP ogni dispositivo dovrebbe essere configurato manualmente.
TL;DR#
Dispositivo si connette alla rete:
→ manda broadcast "c'è un server DHCP?"
→ server risponde con IP, gateway, DNS, lease
→ dispositivo conferma
→ server registra l'assegnazione e riparte il timer
Usa UDP porta 67 (server) e 68 (client) — non TCP.
Il ciclo si chiama DORA: Discover → Offer → Request → ACK.Perché è nato#
Prima di DHCP esisteva BOOTP (Bootstrap Protocol, 1985). Funzionava così: l'amministratore creava una tabella manuale con MAC → IP per ogni dispositivo della rete. Funzionava per reti piccole e statiche, ma non scalava:
- ogni nuovo dispositivo → intervento manuale
- dispositivi temporanei (laptop, ospiti) → problema
- reti grandi con centinaia di host → impossibile da gestire
DHCP (1993) ha risolto il problema introducendo il concetto di lease — l'IP viene "affittato" per un tempo limitato, non assegnato per sempre. Il server gestisce un pool dinamico: assegna, recupera, riassegna. Zero intervento manuale.
Wireshark mostra ancora i pacchetti DHCP come "Bootstrap Protocol" — eredità storica del nome originale BOOTP, su cui DHCP è costruito.
Come funziona — DORA#
DHCP usa UDP, non TCP. Il client non ha ancora un IP → non può fare un handshake TCP. Il broadcast non è supportato da TCP. UDP è l'unica scelta.
Porte fisse:
67/udp— bootps — porta del server DHCP68/udp— bootpc — porta del client DHCP
[Client] 0.0.0.0:68 [Server] 192.168.1.5:67
│ │
│── 1. DISCOVER ─────────────────────────────► │
│ src: 0.0.0.0 dst: 255.255.255.255 │
│ TX ID: 0x3d1d "chi è il server DHCP?" │
│ │
│◄── 2. OFFER ──────────────────────────────────│
│ TX ID: 0x3d1d (stesso — identifica il ciclo)│
│ "propongo: 192.168.1.10, lease 24h, │
│ gateway 192.168.1.1, DNS 8.8.8.8" │
│ │
│── 3. REQUEST ──────────────────────────────► │
│ src: 0.0.0.0 dst: 255.255.255.255 │
│ TX ID: 0x3d1d "accetto 192.168.1.10" │
│ │
│◄── 4. ACK ────────────────────────────────────│
│ src: 192.168.1.5 dst: 192.168.1.10 │
│ (unicast — il server conosce già il MAC) │
│ "confermato, è tuo per 24 ore" │Transaction ID — numero casuale generato dal client nel Discover. Il server lo copia in Offer, Request e ACK. Serve per abbinare le risposte alla richiesta giusta in una rete con molti client e magari più server DHCP. Il client confronta: "questo TX ID è mio? No → ignoro."
L'ACK va in unicast — tutti e tre i pacchetti precedenti sono broadcast. L'ACK no: il server conosce già il MAC del client dal Request, quindi usa unicast diretto. Il client non ha ancora configurato l'IP sulla propria interfaccia, ma a livello Ethernet il pacchetto arriva tramite MAC address.
Lease — la scadenza dell'IP#
DHCP non assegna IP per sempre — assegna un "affitto" (lease) con una durata. Router casalinghi: tipicamente 24 ore. Reti enterprise: 8 ore.
Il rinnovo avviene in anticipo rispetto alla scadenza:
| Tempo | Evento |
|---|---|
| T=0h | assegnazione IP — DORA completo |
| T=12h | primo tentativo rinnovo — unicast al server (50% del lease) — solo Request + ACK |
| T=21h | secondo tentativo — broadcast (87.5%), se il primo è fallito |
| T=24h | lease scaduto → DORA completo da zero |
In-lease renewal — al 50% il client manda direttamente un Request in unicast al server (sa già chi è e qual è il suo IP). Il server risponde con ACK e resetta il timer. Se sei sempre connesso e il server risponde, non arrivi mai al 87.5%.
Out-of-lease renewal — lease scaduto, si riparte con DORA completo.
Il lease database#
Il server DHCP mantiene un file persistente con tutti i lease attivi. Non è un database relazionale (MySQL, Postgres) — è quasi sempre un file di testo strutturato:
# Su Linux con isc-dhcp-server:
cat /var/lib/dhcp/dhcpd.leases
# Contenuto tipico:
# lease 192.168.1.10 {
# starts 4 2026/04/16 08:00:00;
# ends 4 2026/04/16 20:00:00;
# hardware ethernet 00:0c:29:59:fd:21;
# }Deve essere persistente (sopravvive al riavvio del server) perché se il server DHCP si riavvia senza memoria di cosa ha assegnato, potrebbe dare lo stesso IP a due client diversi — conflitto IP, entrambi smettono di funzionare. La ARP cache è volatile e si ricostruisce da sola; il lease database non può permetterselo.
DHCP Reservation — IP "fisso" senza toccare il client#
IP statico classico (router) vs DHCP Reservation#
La reservation è una regola nel server DHCP: "questo MAC address riceve sempre questo IP". Il client fa DORA normalmente, il server riconosce il MAC e assegna sempre lo stesso IP.
| IP statico classico | DHCP Reservation | |
|---|---|---|
| Dove si configura | direttamente sul dispositivo | sul router (MAC → IP fisso) |
| Il dispositivo fa DORA? | no — ignora il DHCP | sì — normalmente |
| Rischio | dimentichi che quell'IP è occupato → conflitto | nessuno — il router non lo assegna ad altri |
Il caso eMule / port forwarding — per aprire una porta sul router (NAT) devi indicare a quale dispositivo interno inoltrarla. Ma se il dispositivo ha IP dinamico, domani potrebbe avere un IP diverso e la regola di port forwarding punta nel vuoto. La soluzione: crei una DHCP reservation per quel dispositivo → IP sempre uguale → la regola di port forwarding funziona sempre.
La reservation si basa sul MAC address: il router legge il Client MAC address nell'header del Discover, controlla la sua tabella di reservation e assegna sempre lo stesso IP a quel MAC. Non è una risoluzione di nomi — è puro MAC → IP, livello 2/3. Vai sul pannello del router, trovi il dispositivo nella lista dei lease attivi (il MAC è già lì), premi "rendi fisso" e da quel momento quell'IP è riservato.
Questo vale per qualsiasi servizio che deve essere raggiungibile dall'esterno: eMule, un nodo Bitcoin su Raspberry Pi, telecamere, server locali.
IP statico su VM — file di configurazione#
Quando vuoi un IP fisso configurato direttamente sul dispositivo (senza passare dal DHCP), il file da modificare dipende dal sistema:
Kali Linux — /etc/network/interfaces (formato Debian):
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.64.200
netmask 255.255.255.0
gateway 192.168.64.1Ubuntu Server — /etc/netplan/50-cloud-init.yaml (formato YAML):
network:
version: 2
ethernets:
enp0s1:
dhcp4: false
addresses:
- 192.168.64.3/24
nameservers:
addresses: [8.8.8.8, 1.1.1.1]
routes:
- to: default
via: 192.168.64.1Le VM Ubuntu (192.168.64.3) e Kali (192.168.64.200) nel lab UTM hanno IP statici configurati direttamente su questi file — non passano dal DHCP di UTM. Questo garantisce che l'IP SSH sia sempre lo stesso indipendentemente da qualsiasi server DHCP.
DHCPv6 — la versione per IPv6#
DHCPv6 svolge lo stesso compito di DHCPv4 ma è costruito da zero per IPv6 — nessuna eredità BOOTP, formato più semplice.
La differenza principale: IPv6 ha eliminato il broadcast, quindi DHCPv6 usa il multicast. L'indirizzo ff02::1:2 è riservato a tutti i server DHCPv6 sulla rete locale.
Il ciclo si chiama SARR invece di DORA:
| Passo | Nome | Indirizzo |
|---|---|---|
| 1 | Solicit | client → ff02::1:2 (multicast) |
| 2 | Advertise | server → client (unicast) |
| 3 | Request | client → ff02::1:2 (multicast) |
| 4 | Reply | server → client (unicast) |
In IPv6 esiste anche SLAAC (Stateless Address Autoconfiguration): il router annuncia il prefisso di rete via Router Advertisement e il client si genera l'IP autonomamente dal proprio MAC address. In questo caso DHCPv6 viene usato solo per passare DNS e altri parametri, non per l'IP.
DHCPv6 è attivo ovunque ci sia IPv6 — ISP e grandi infrastrutture lo usano estensivamente. Le reti domestiche e le LAN aziendali usano ancora prevalentemente IPv4+DHCPv4.
DHCP Starvation — l'attacco DoS#
Il server DHCP ha un pool finito: es. 192.168.1.10 → 192.168.1.254 (244 IP).
L'attaccante manda migliaia di DHCP Discover con MAC address falsi e diversi. Il server assegna un IP per ogni MAC → pool esaurito in secondi. Nuovi client legittimi mandano Discover → silenzio → nessun IP disponibile → DoS sulla rete.
Rogue DHCP — l'attacco MITM#
L'attaccante installa un server DHCP falso sulla LAN. Il client fa Discover in broadcast — risponde prima il server falso. Il client accetta l'Offer falsa e riceve una configurazione malevola:
gateway: IP dell'attaccante → tutto il traffico passa da luiDNS: IP dell'attaccante → può rispondere con IP falsi
Risultato: MITM completo su tutta la rete, senza toccare il client.
Difese Blue Team#
DHCP Snooping — funzione degli switch managed. Definisce quali porte possono inviare risposte DHCP. Le porte verso gli utenti possono solo mandare Request, non Offer. Un rogue DHCP server su una porta utente viene bloccato.
Rate limiting DHCP — limita il numero di Request per porta per unità di tempo. Mitiga DHCP starvation.
Monitoraggio — segnali di alert:
- picco di DHCP Request con MAC diversi in breve tempo → starvation in corso
- DHCP Offer da IP non presenti nella lista dei server autorizzati → rogue DHCP
Scenario Reale#
Lunedì mattina decine di dipendenti non riescono a connettersi — i dispositivi non ottengono IP. L'analista SOC controlla i log del server DHCP: il pool di 200 IP è stato esaurito in 3 minuti durante la notte, da migliaia di Request con MAC diversi. DHCP starvation — probabilmente un dispositivo compromesso nella LAN. Il DHCP snooping non era attivo. Azione: abilita snooping, identifica la porta dello switch da cui sono arrivate le Request, isola il dispositivo.
Collegato a#
- network — categoria
- arp — ARP e DHCP lavorano insieme — DHCP snooping alimenta DAI (Dynamic ARP Inspection)
- tcp-udp — DHCP usa UDP perché il broadcast non è supportato da TCP
- unicast-broadcast-multicast — i tre modi di indirizzare pacchetti in rete
- icmp-mac-ip — MAC address usato da DHCP per identificare i client
- lan-topologies — il server DHCP vive nel router (casa) o in un server dedicato (enterprise)
- ip-addressing-subnetting — DHCP assegna IP dentro la subnet definita
