DHCP - Dynamic Host Configuration Protocol

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.

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 DHCP
• 68/udp — bootpc — porta del client DHCP

sequenceDiagram
    participant C as Client (0.0.0.0:68)
    participant S as DHCP Server (192.168.1.5:67)

    C->>S: 1. DISCOVER — broadcast 255.255.255.255
    Note over C,S: TX ID: 0x3d1d — src 0.0.0.0
    Note right of C: "C'è un server DHCP in rete?"

    S-->>C: 2. OFFER — unicast al MAC del client
    Note over C,S: TX ID: 0x3d1d (stesso — identifica il ciclo)
    Note right of S: IP 192.168.1.10 · lease 24h · gw 192.168.1.1 · DNS 8.8.8.8

    C->>S: 3. REQUEST — broadcast 255.255.255.255
    Note over C,S: TX ID: 0x3d1d — src ancora 0.0.0.0
    Note right of C: "Accetto 192.168.1.10 (gli altri server ignoratemi)"

    S-->>C: 4. ACK — unicast a 192.168.1.10
    Note over C,S: Il server conosce già il MAC — passa a unicast
    Note right of S: "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:

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.

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.1

Ubuntu 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.1

Le 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.

DNS Suffix Leak

#

Il DHCP non assegna solo un IP: tramite le sue opzioni (DHCP Options) passa al client anche altri parametri di rete. L'opzione 15 (domain-name) passa il suffisso DNS del dominio interno. In ambienti non correttamente segregati, questo rivela informazioni sull'infrastruttura interna a chiunque ottenga un lease DHCP.

# Visualizzare le DHCP options ricevute su Linux
nmcli device show eth0 | grep DOMAIN
# IP4.DOMAIN: corp.internal

# Oppure con dhclient
cat /var/lib/dhcp/dhclient.leases | grep domain-name
# option domain-name "corp.internal";

Perche' e' un problema: un attaccante che ottiene un lease DHCP (es. nella guest WiFi di un hotel aziendale mal configurata) impara la struttura del dominio interno: corp.internal, ad.company.com, internal.bank.it. Queste informazioni facilitano l'enumerazione DNS successiva e il phishing interno (email "password@ad.company.com").

Difesa: segregare le VLAN guest/IoT in modo che non ricevano le stesse DHCP options della rete corporate. Configurare scope DHCP separati con opzioni diverse per tipo di rete.

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:

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.

Security — Attacchi e Difese

#

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 lui
• DNS: IP dell'attaccante → può rispondere con IP falsi

Risultato: MITM completo su tutta la rete, senza toccare il client.

Difese Blue Team

#

DHCP Snooping e' la difesa principale contro i rogue DHCP server. E' una funzione degli switch managed che classifica ogni porta come trusted o untrusted:

• Trusted port: puo' inviare DHCP Offer/ACK (solo le porte verso i server DHCP legittimi)
• Untrusted port: puo' inviare solo DHCP Discover/Request - mai Offer. Qualsiasi Offer da una porta untrusted viene bloccato dallo switch.

Quando DHCP Snooping e' attivo, lo switch costruisce automaticamente la DHCP Snooping Binding Table: una tabella MAC→IP→VLAN→porta che mappa ogni lease attivo. Questa tabella viene usata anche da DAI (Dynamic ARP Inspection) - vedi arp.

# Configurazione Cisco IOS - DHCP Snooping
ip dhcp snooping              # abilita globalmente
ip dhcp snooping vlan 10      # abilita sulla VLAN 10

interface GigabitEthernet0/1  # porta verso il server DHCP
 ip dhcp snooping trust       # porta trusted

# Le altre porte sono untrusted per default

Rate limiting DHCP — limita il numero di Request per porta per unita' di tempo. Mitiga DHCP starvation:

# Cisco: max 15 DHCP packet/secondo per porta
interface GigabitEthernet0/24
 ip dhcp snooping limit rate 15

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
• Log del server DHCP che mostra DHCPNAK ripetuti → pool esaurito o conflitti IP

Dev parallel: Come il service discovery interno in Docker Compose o Kubernetes: invece di IP statici, i container ottengono indirizzi dal bridge network interno tramite il DHCP integrato del daemon Docker. Il comando docker network inspect bridge mostra il pool DHCP assegnato e i lease attivi per ogni container. La differenza: in K8s il DNS interno (CoreDNS) risolve i nomi dei service, non gli IP - ma il meccanismo sottostante di assegnazione dinamica e' lo stesso principio DORA.

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

#

• 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