22. Considerazioni sulla sicurezza
Questa sezione conserva il testo RFC relativo a DHCPv6, inclusi gli scambi di messaggi, il comportamento dei relay, DUID, IA_NA, IA_TA, IA_PD, le opzioni DHCP, l'autenticazione RKAP, i registri IANA, i requisiti normativi e le matrici di comparsa delle opzioni in appendice.
Testo originale della RFC
22. Considerazioni sulla sicurezza
Questa sezione discute le considerazioni sulla sicurezza che non sono
relative alla privacy. Vedere la Section 23 per una discussione
dedicata alla privacy.
La minaccia a DHCP e intrinsecamente una minaccia interna (assumendo
una rete configurata correttamente, in cui le porte DHCP sono bloccate
sui gateway perimetrali dell'impresa). Indipendentemente dalla
configurazione del gateway, tuttavia, i potenziali attacchi da parte di
soggetti interni ed esterni sono gli stessi.
DHCP non dispone di cifratura end-to-end tra client e server; di
conseguenza, sono tutti possibili attacchi di dirottamento, alterazione
e intercettazione passiva. Alcuni ambienti di rete (discussi sotto)
possono essere protetti con vari mezzi per ridurre al minimo questi
attacchi.
La minaccia comune sia al client sia al server e l'attacco DoS di
"esaurimento delle risorse". Tipicamente, questi attacchi comportano
l'esaurimento degli indirizzi assegnati disponibili o dei prefissi
delegabili, oppure l'esaurimento della CPU o della banda di rete, e sono
presenti ogni volta che esiste una risorsa condivisa. Alcune forme di
questi attacchi di esaurimento possono essere mitigate parzialmente da
una politica del server appropriata, per esempio limitando il numero
massimo di lease che un client puo ottenere, limitando il numero di
lease che un client puo rifiutare e limitando il numero di messaggi che
un singolo client puo trasmettere in un periodo di tempo.
22.1. Considerazioni sulla sicurezza del client
Un attacco specifico a un client DHCP e la creazione di un server
malevolo con l'intento di fornire al client informazioni di
configurazione non corrette. La motivazione puo essere montare un
attacco "man-in-the-middle" che induce il client a comunicare con un
server malevolo invece che con un server valido per qualche servizio
(come DNS o NTP). Il server malevolo puo anche montare un attacco DoS
tramite la configurazione errata del client; questo attacco farebbe
fallire tutte le comunicazioni di rete provenienti dal client.
Un server DHCP malevolo potrebbe indurre un client a impostare i
parametri SOL_MAX_RT e INF_MAX_RT su un valore irragionevolmente elevato
con le opzioni SOL_MAX_RT (vedere Section 21.24) e INF_MAX_RT (vedere
Section 21.25); questo puo causare un ritardo eccessivo nel
completamento della transazione del protocollo DHCP da parte di un
client, nel caso in cui non venga ricevuta alcuna altra risposta valida.
Supponendo che il client riceva anche una risposta da un server DHCP
valido, valori elevati di SOL_MAX_RT e INF_MAX_RT non avranno alcun
effetto.
Un'altra minaccia per i client DHCP proviene da server DHCP configurati
erroneamente o accidentalmente, che rispondono alle richieste dei client
DHCP con parametri di configurazione involontariamente non corretti.
Se un'implementazione client supporta il meccanismo reconfigure, vedere
Section 22.3.
22.2. Considerazioni sulla sicurezza del server
La minaccia specifica a un server DHCP e un client non valido che si
maschera da client valido. La motivazione puo essere il furto del
servizio o l'elusione dell'auditing per un qualunque numero di scopi
illeciti.
I messaggi scambiati tra relay agent e server possono essere usati per
montare un attacco man-in-the-middle o DoS. La comunicazione tra un
server e un relay agent, e la comunicazione tra relay agent, puo essere
autenticata e cifrata mediante l'uso di IPsec, come descritto in
[RFC8213].
Tuttavia, l'uso di chiavi pre-condivise configurate manualmente per
IPsec tra relay agent e server non difende dai messaggi DHCP riprodotti.
I messaggi riprodotti possono rappresentare un attacco DoS tramite
esaurimento delle risorse di elaborazione, ma non tramite configurazione
errata o esaurimento di altre risorse quali indirizzi assegnabili e
prefissi delegabili.
Se un'implementazione server supporta il meccanismo reconfigure, vedere
Section 22.3.
22.3. Considerazioni sulla sicurezza di Reconfigure
RKAP, descritto nella Section 20.4, fornisce protezione contro l'uso di
un messaggio Reconfigure da parte di un server DHCP malevolo per montare
un attacco DoS o man-in-the-middle contro un client. Questo protocollo
puo essere compromesso da un attaccante capace di intercettare il
messaggio iniziale in cui il server DHCP invia la chiave in chiaro al
client.
A causa dell'opportunita di attacco tramite il messaggio Reconfigure, un
client DHCP MUST scartare qualsiasi messaggio Reconfigure che non includa
autenticazione o che non superi il processo di validazione per il
protocollo di autenticazione.
Un client DHCP puo anche essere soggetto ad attacco tramite la ricezione
di un messaggio Reconfigure da un server malevolo che induce il client a
ottenere informazioni di configurazione non corrette da quel server. Si
noti che, sebbene un client invii la propria risposta (messaggio Renew,
Rebind o Information-request) tramite un relay agent e, quindi, tale
risposta venga ricevuta solo dai server a cui i messaggi DHCP sono
inoltrati, un server malevolo potrebbe inviare un messaggio Reconfigure
a un client, seguito (dopo un ritardo appropriato) da un messaggio Reply
che verrebbe accettato dal client. Pertanto, un server malevolo che non
si trova sul percorso di rete tra il client e il server puo comunque
riuscire a montare un attacco Reconfigure contro un client. L'uso di
transaction ID crittograficamente solidi e non facilmente prevedibili
ridurra anche la probabilita che un tale attacco abbia successo.
22.4. Considerazioni di mitigazione
Anche vari ambienti di rete offrono livelli di sicurezza se distribuiti
come descritto sotto.
* Nelle reti aziendali e industriali, l'uso dell'autenticazione secondo
[IEEE8802.1x] puo impedire a client sconosciuti o non fidati di
connettersi alla rete. Tuttavia, questo non assicura
necessariamente che il client connesso sara un buon attore DHCP o di
rete.
* Per le reti cablate in cui i client sono tipicamente connessi a una
porta di switch, lo snooping del traffico DHCP multicast (o unicast)
diventa difficile, poiche gli switch limitano il traffico consegnato
a una porta. I messaggi DHCP del client (multicast verso
All_DHCP_Relay_Agents_and_Servers) vengono inoltrati solo alla porta
dello switch del server DHCP (o del relay), non a tutte le porte.
Inoltre, le risposte unicast del server (o del relay) vengono
consegnate solo alla porta del client di destinazione, non a tutte le
porte.
* Nelle reti pubbliche (come una rete Wi-Fi in un bar o in un
aeroporto), e possibile per altri entro la portata radio effettuare
snooping su DHCP e altro traffico. Ma in questi ambienti, se si
seguono le considerazioni sulla privacy fornite nella Section 23, dal
traffico DHCP stesso (dal client al server o dal server al client) si
puo apprendere molto poco, se non nulla. Anche per i dispositivi che
non seguono le considerazioni sulla privacy, c'e poco che si possa
apprendere che non sarebbe comunque disponibile dalle comunicazioni
successive (come l'indirizzo Media Access Control (MAC) del
dispositivo). Inoltre, poiche tutti i client riceveranno
tipicamente dettagli di configurazione simili, un attore malevolo che
avvia esso stesso una richiesta DHCP puo apprendere gran parte di
tali informazioni. Come menzionato sopra, una minaccia e che la
chiave RKAP per un client possa essere appresa (se viene monitorato
lo scambio iniziale Solicit/Advertise/Request/Reply) e inneschi una
riconfigurazione prematura; cio e pero relativamente facile da
prevenire vietando la comunicazione diretta client-to-client su
queste reti o usando [RFC7610] e [RFC7513].
Molti degli attacchi da parte di server rogue possono essere mitigati
usando i meccanismi descritti in [RFC7610] e [RFC7513].