Passa al contenuto principale

23. Considerazioni sulla sicurezza

La minaccia a DHCP è intrinsecamente una minaccia interna (assumendo una rete correttamente configurata dove le porte DHCPv6 sono bloccate sui gateway perimetrali dell'azienda). Indipendentemente dalla configurazione del gateway, tuttavia, i potenziali attacchi da parte di interni ed esterni sono gli stessi.

L'uso di chiavi precondivise configurate manualmente per IPsec tra agenti relay e server non difende contro i messaggi DHCP riprodotti. I messaggi riprodotti possono rappresentare un attacco DOS attraverso l'esaurimento delle risorse di elaborazione, ma non attraverso la configurazione errata o l'esaurimento di altre risorse come gli indirizzi assegnabili.

Un attacco specifico a un client DHCP è l'istituzione di un server dannoso con l'intento di fornire informazioni di configurazione errate al client. La motivazione per farlo può essere quella di montare un attacco "man in the middle" che fa sì che il client comunichi con un server dannoso invece di un server valido per un servizio come DNS o NTP. Il server dannoso può anche montare un attacco denial of service attraverso la configurazione errata del client che causa il fallimento di tutte le comunicazioni di rete dal client.

C'è un'altra minaccia per i client DHCP da server DHCP configurati erroneamente o accidentalmente che rispondono alle richieste dei client DHCP con parametri di configurazione involontariamente errati.

Un client DHCP può anche essere soggetto ad attacco attraverso la ricezione di un messaggio Reconfigure da un server dannoso che fa sì che il client ottenga informazioni di configurazione errate da quel server. Si noti che sebbene un client invii la sua risposta (messaggio Renew o Information-request) attraverso un agente relay e, pertanto, tale risposta sarà ricevuta solo dai server a cui vengono inoltrati i messaggi DHCP, un server dannoso potrebbe inviare un messaggio Reconfigure a un client, seguito (dopo un ritardo appropriato) da un messaggio Reply che sarebbe accettato dal client. Pertanto, un server dannoso che non si trova sul percorso di rete tra il client e il server può comunque essere in grado di montare un attacco Reconfigure su un client. L'uso di ID di transazione che sono crittograficamente sicuri e non possono essere facilmente previsti ridurrà anche la probabilità che tale attacco abbia successo.

La minaccia specifica a un server DHCP è un client non valido che si maschera da client valido. La motivazione per questo può essere il furto di servizio, o per aggirare l'audit per qualsiasi numero di scopi nefasti.

La minaccia comune sia al client che al server è l'attacco "denial of service" (DoS) delle risorse. Questi attacchi comportano tipicamente l'esaurimento degli indirizzi disponibili, o l'esaurimento della CPU o della larghezza di banda della rete, e sono presenti ogni volta che c'è una risorsa condivisa.

Nel caso in cui gli agenti relay aggiungano opzioni aggiuntive ai messaggi Relay Forward, i messaggi scambiati tra agenti relay e server possono essere utilizzati per montare un attacco "man in the middle" o denial of service.

Questo modello di minaccia non considera importante la privacy dei contenuti dei messaggi DHCP. DHCP non viene utilizzato per scambiare informazioni di autenticazione o configurazione che devono essere mantenute segrete da altri nodi di rete.

L'autenticazione DHCP fornisce l'autenticazione dell'identità dei client e dei server DHCP e dell'integrità dei messaggi consegnati tra client e server DHCP. L'autenticazione DHCP non fornisce alcuna privacy per i contenuti dei messaggi DHCP.

Il protocollo di autenticazione differita descritto nella sezione 21.4 utilizza una chiave segreta condivisa tra un client e un server. L'uso di un "realm DHCP" nella chiave condivisa consente l'identificazione dei domini amministrativi in modo che un client possa selezionare la chiave o le chiavi appropriate durante il roaming tra domini amministrativi. Tuttavia, il protocollo di autenticazione differita non definisce alcun meccanismo per la condivisione delle chiavi, quindi un client potrebbe richiedere chiavi separate per ogni dominio amministrativo che incontra. L'uso di chiavi condivise potrebbe non scalare bene e non fornisce ripudio delle chiavi compromesse. Questo protocollo si concentra sulla risoluzione del problema intradominio dove lo scambio fuori banda di una chiave condivisa è fattibile.

A causa dell'opportunità di attacco attraverso il messaggio Reconfigure, un client DHCP DEVE scartare qualsiasi messaggio Reconfigure che non include l'autenticazione o che non supera il processo di validazione per il protocollo di autenticazione.

Il protocollo della chiave Reconfigure descritto nella sezione 21.5 fornisce protezione contro l'uso di un messaggio Reconfigure da parte di un server DHCP dannoso per montare un attacco denial of service o man-in-the-middle su un client. Questo protocollo può essere compromesso da un attaccante che può intercettare il messaggio iniziale in cui il server DHCP invia la chiave al client.

La comunicazione tra un server e un agente relay, e la comunicazione tra agenti relay, può essere protetta attraverso l'uso di IPSec, come descritto nella sezione 21.1. L'uso della configurazione manuale e dell'installazione di chiavi statiche sono accettabili in questo caso perché gli agenti relay e il server apparterranno allo stesso dominio amministrativo e gli agenti relay richiederanno altre configurazioni specifiche (ad esempio, la configurazione dell'indirizzo del server DHCP) oltre alla configurazione IPSec.