Dynamic Host Configuration Protocol

Da Wikipedia, l'enciclopedia libera.
(Reindirizzamento da DHCP)

In telecomunicazioni e informatica il Dynamic Host Configuration Protocol (DHCP) (protocollo di configurazione IP dinamica) è un protocollo di rete di livello applicativo che permette ai dispositivi o terminali di una certa rete locale di ricevere automaticamente ad ogni richiesta di accesso a una rete IP (quale una LAN) la configurazione IP necessaria per stabilire una connessione e operare su una rete più ampia basata su Internet Protocol, cioè interoperare con tutte le altre sottoreti scambiandosi dati, purché anch'esse integrate allo stesso modo con il protocollo IP. Il protocollo è implementato come servizio di rete ovvero come tipologia di server: ad es. nei sistemi Unix e Unix-like è implementato nel demone dhcpd, in quelli basati su Active Directory di Microsoft e/o Windows Server dal servizio server dhcp.

Generalità[modifica | modifica wikitesto]

In una rete basata sul protocollo IP, ogni calcolatore ha bisogno di un indirizzo IP, scelto in modo tale che appartenga all'insieme di indirizzi possibili assegnati all'intera sottorete (cioè al Net_ID) a cui è collegato e che sia univoco, cioè non ci siano altri calcolatori che stiano già utilizzando quell'indirizzo.

Il compito di assegnare manualmente gli indirizzi IP ai calcolatori comporta infatti un rilevante onere per gli amministratori di rete, soprattutto in reti di grandi dimensioni o in caso di numerosi computer che si connettono a rotazione solo a ore o giorni determinati. Inoltre gli indirizzi IPv4 disponibili (attualmente usati nella quasi totalità delle reti al mondo) con l'aumentare dei computer connessi a Internet hanno cominciato a scarseggiare, diminuendo la disponibilità di IP fissi per eventuali configurazioni statiche.

DHCP supporta questo compito automaticamente e in maniera dinamica, cioè solo quando richiesto dall'host. Viene utilizzato soprattutto in reti locali, in particolare su Ethernet. In altri contesti, funzioni simili sono svolte all'interno di PPP. Una volta ricevuta la configurazione di rete la stazione o computer della rete locale diventa a tutti gli effetti un host (ospite) della rete Internet e può intraprendere sessioni di navigazione Web e tutti gli altri servizi offerti dalla rete stessa. Infatti, un servizio DHCP è svolto anche da un semplice router di casa.

Parametri gestiti da DHCP[modifica | modifica wikitesto]

Il protocollo DHCP viene usato anche per assegnare al computer diversi parametri necessari per il suo corretto funzionamento sulla rete a cui è collegato. Tra i più comuni, oltre all'assegnazione dinamica dell'indirizzo IP, si possono citare:

Nel protocollo c'è comunque il supporto per assegnare tramite DHCP molti altri parametri, definiti nell'RFC 2132.

Componenti del protocollo[modifica | modifica wikitesto]

Il Client DHCP è un calcolatore che ha bisogno di ottenere un indirizzo IP valido per la sottorete a cui è collegato, e anche il programma che si occupa di richiedere l'indirizzo IP e configurarlo.

Il Server DHCP è il calcolatore che assegna gli indirizzi IP, è anche il processo che svolge questa funzione. Talvolta questa funzione è incorporata in un router.

Il DHCP relay è il calcolatore (o più spesso una funzione implementata in un router) che si occupa di inoltrare le richieste DHCP ad un server, qualora questo non sia sulla stessa sottorete. Questo componente è necessario solo se un server DHCP deve servire molteplici sottoreti. Deve esistere almeno un DHCP relay per ciascuna sottorete servita. Ogni relay deve essere esplicitamente configurato per inoltrare le richieste a uno o più server.

Richiesta e attribuzione dell'indirizzo[modifica | modifica wikitesto]

Un'immagine che mostra una sessione tipica DHCP; ogni messaggio potrebbe essere sia broadcast che unicast, a seconda delle capacità del client DHCP.[1]

DHCP utilizza il protocollo UDP, le porte registrate sono la 67 per il server e la 68 per il client.

Quando un calcolatore vuole ottenere un indirizzo tramite DHCP, attiva il processo DHCP client. In questo momento, il calcolatore non ha un indirizzo IP valido, quindi non può usare tutte le funzionalità della rete.

La procedura descritta dal protocollo consta di diversi handshake tra client e server, ovvero scambio di pacchetti, ovviamente tutti incapsulati in frame di livello datalink, come Ethernet:

  • In primis, il client invia un pacchetto chiamato DHCPDISCOVER in broadcast, con indirizzo IP sorgente messo convenzionalmente a 0.0.0.0, e destinazione 255.255.255.255 (indirizzo di broadcast).
  • Il pacchetto è ricevuto da tutto il dominio di broadcast e in particolare da tutti i server DHCP presenti, i quali possono rispondere (o meno) ciascuno con un pacchetto di DHCPOFFER in cui propongono un indirizzo IP e gli altri parametri di configurazione al client. Questo pacchetto di ritorno è indirizzato in broadcast all'indirizzo di livello datalink del client (che non ha ancora un indirizzo IP) cioè in unicast, per cui può essere inviato solo da un server che si trovi sullo stesso dominio di broadcast.

Se nel dominio di broadcast ci sono anche uno o più DHCP relay, questi inoltrano il pacchetto al loro server di riferimento, che può rispondere al client sempre attraverso il relay. Il relay agent comunica al server il proprio indirizzo IP sulla sottorete da cui ha ricevuto il pacchetto di DHCPDISCOVER, permettendo al server di capire da quale sottorete è arrivata la richiesta, e quindi offrire un indirizzo per la sottorete giusta. Un server DHCP che debba servire diverse sottoreti IP deve essere configurato per conoscere i parametri di ciascuna (indirizzo della rete, maschera di sottorete, indirizzo di broadcast, indirizzo del gateway).

  • Il client aspetta per un certo tempo di ricevere una o più offerte, dopodiché ne seleziona una, e invia un pacchetto di DHCPREQUEST (o DHCPACCEPT) in broadcast, indicando all'interno del pacchetto, con il campo "server identifier", quale server ha selezionato. Anche questo pacchetto raggiunge tutti i server DHCP presenti sulla rete (direttamente o tramite un relay).
  • Il server che è stato selezionato conferma l'assegnazione dell'indirizzo con un pacchetto di DHCPACK (nuovamente indirizzato in broadcast all'indirizzo di livello datalink del client, possibilmente attraverso un relay); gli altri server vengono automaticamente informati che la loro offerta non è stata scelta dal client, e che sulla sottorete è presente un altro server DHCP.

Scadenza e rinnovo degli indirizzi[modifica | modifica wikitesto]

A questo punto, il client è autorizzato a usare l'indirizzo ricevuto per un tempo limitato, detto tempo di lease. Prima della scadenza, dovrà tentare di rinnovarlo inviando un nuovo pacchetto DHCPREQUEST al server, che gli risponderà con un DHCPACK se vuole prolungare l'assegnazione dell'indirizzo. Questi sono normali pacchetti IP unicast scambiati tra due calcolatori che hanno indirizzi validi. Se il client non riesce a rinnovare l'indirizzo, tornerà allo stato iniziale cercando di farsene attribuire un altro.

Identificazione e autenticazione dei client[modifica | modifica wikitesto]

Il client si identifica verso il server attraverso un campo client-id dei pacchetti DHCP. Questo campo ha normalmente come valore il mac address della scheda di rete per cui si richiede l'indirizzo, ma può anche essere configurato manualmente. Questa è l'unica forma di autenticazione disponibile per DHCP, ed è piuttosto debole, in quanto utilizza un dato che viene inviato in broadcast sulla rete locale, e quindi può essere facilmente trovato da qualunque altro calcolatore connesso alla stessa rete. Per controllare l'accesso a una rete esistono metodi più solidi, che però richiedono un supporto da parte degli switch a cui sono collegati gli utenti, come IEEE 802.1x.

Un server dovrebbe cercare di assegnare allo stesso client sempre lo stesso indirizzo IP su ciascuna sottorete, ma non ci sono garanzie che questo sia possibile, a meno che un indirizzo non sia associato esclusivamente a un client.

Il server può utilizzare il campo client-id per decidere quale indirizzo assegnare al client, o quali altri parametri passargli, o anche di non rispondere per nulla alla richiesta del client.

La sicurezza, in termini di accesso ad una rete, non è assicurata da indirizzi IP statici ma dall'implementazione di policy di autenticazione sia lato dominio che, eventualmente, firewall: l'utilizzo di indirizzi dinamici non ha alcun riflesso sulla sicurezza essendo un servizio base che facilita enormemente l'aggiunta di risorse client non dovendo ricorrere ogni volta a configurazione specialistica fosse pure solo l'inserimento dei parametri di connessione fisica alla rete. Come detto la connessione logica deve essere gestita attraverso le autorizzazioni di autenticazione.

A parte i client nel senso di utenti vi sono invece servizi e risorse che tipicamente devono essere indirizzati staticamente: stampanti, router, server, sistemi di registrazione o sorveglianza, ecc.

Identificazione del server[modifica | modifica wikitesto]

Il server si identifica verso il client con il proprio indirizzo IP. Un client potrebbe quindi decidere di accettare indirizzi solo da un server già noto.

Qualunque calcolatore collegato a una sottorete potrebbe fare da server DHCP per i calcolatori di quella sottorete, o da relay verso un server DHCP arbitrario. È quindi possibile che un calcolatore configurato male o deliberatamente per fini illeciti offra abusivamente indirizzi IP, creando malfunzionamenti alla rete e/o gravi problemi di sicurezza.

Un calcolatore che abbia ricevuto l'indirizzo IP da un server DHCP mal configurato non sarà in grado di utilizzare la rete.

Se invece il server DHCP abusivo è configurato per scopi illeciti, le conseguenze possono essere anche peggiori: esso, infatti, può offrire indirizzi che sa essere inutilizzati, oppure su una sottorete IP diversa da quella ufficiale, evitando così di generare conflitti con il server ufficiale, e indicare sé stesso come default gateway. Dovrà poi ridirigere le connessioni effettuate dai client verso il gateway ufficiale utilizzando IP masquerading. A questo punto, potrà intercettare e sniffare tutto il traffico generato dai client, che potrebbero non accorgersi facilmente della differenza.

Per prevenire questi rischi, alcuni switch offrono una funzionalità detta "DHCP snooping", per cui analizzano tutti i pacchetti DHCP che li attraversano, fermando quelli che non sono originati da server autorizzati.

Sicurezza[modifica | modifica wikitesto]

Vedi inoltre: DHCP snooping

Il DHCP base non include alcun meccanismo per l'autenticazione.[2] Per questo motivo, è vulnerabile a vari attacchi. Questi attacchi si dividono in tre categorie principali:

  • I server DHCP non autorizzati forniscono informazioni false ai client.[3]
  • I Client non autorizzati che hanno accesso alle risorse.[3]
  • Gli attacchi di esaurimento delle risorse da client DHCP dannosi.[3]

Poiché il client non ha modo di convalidare l'identità di un server DHCP,i server DHCP non autorizzati (comunemente chiamati "rouge DHCP") possono essere operati in rete, fornendo informazioni non corrette ai client DHCP.[4] Ciò può servire sia come attacco denial-of-service che impedisce al client di accedere alla connettività di rete,[5] che come attacco man-in-the-middle.[6]Poiché il server DHCP fornisce il client DHCP con indirizzi IP del server, come l'indirizzo IP di uno o più server DNS,[3] un attaccante può convincere un client DHCP a eseguire le proprie ricerche DNS tramite il proprio server DNS e può inoltre fornire le proprie risposte alle query DNS dal client.[7][8] Ciò a sua volta consente all'attaccante di reindirizzare il traffico di rete attraverso se stesso, consentendogli di intercettare le connessioni tra il client e i server di rete che contatta, oppure semplicemente sostituire i server di rete con i propri.[7]

Poiché il server DHCP non ha un meccanismo protetto per l'autenticazione del client, i client possono ottenere accesso non autorizzato agli indirizzi IP presentando credenziali, come gli identificatori client, che appartengono ad altri client DHCP.[4]Ciò consente inoltre ai client DHCP di esaurire l'archivio di indirizzi IP del server DHCP presentando nuove credenziali ogni volta che esso richiede un indirizzo, il client può consumare tutti gli indirizzi IP disponibili su un determinato collegamento di rete, impedendo che altri client DHCP ottengano il servizio.[4] DHCP fornisce alcuni meccanismi per mitigare questi problemi. L'estensione del protocollo Relay Agent Information Option ( RFC 3046, solitamente indicato nell'industria attraverso il numero effettivo come Option 82 [9][10]) consente agli operatori di rete di allegare i tag ai messaggi DHCP in quanto questi messaggi arrivano sulla rete di fiducia dell'operatore di rete . Questo tag viene quindi utilizzato come token di autorizzazione per controllare l'accesso del client alle risorse di rete. Dato che il client non ha accesso alla rete del relay agent, la mancanza di autenticazione non impedisce all'operatore del server DHCP a fare affidamento sul token di autenticazione. [2] Un'altra estensione, Authentication for DHCP Messages (RFC 3118), fornisce un meccanismo per l'autenticazione dei messaggi DHCP. Sfortunatamente RFC 3118 non ha visto (a partire dal 2002) un’adozione diffusa a causa dei problemi di gestione delle chiavi per un gran numero di client DHCP. [11]

Un libro del 2007 sulle tecnologie DSL ha rilevato che "sono state individuate numerose vulnerabilità di sicurezza contro le misure di sicurezza proposte da RFC 3118. Questo fatto, combinato con l'introduzione di 802.1x, ha rallentato la distribuzione e il tasso di DHCP autenticati e non è mai stato ampiamente diffuso ". [12] Un libro del 2010 rileva che "ci sono state pochissime implementazioni di autenticazione DHCP. I problemi di gestione delle chiavi e dei ritardi di elaborazione sono stati ritenuti un prezzo troppo alto da pagare per benefici percepiti". [13] Delle proposte architettoniche più recenti (2008) implicano l'autenticazione delle richieste DHCP usando 802.1x o PANA (i quali trasportano l'EAP).[14] Una proposta di IETF è stata fatta per includere EAP in DHCP stesso, il cosiddetto EAPoDHCP;[15] questo non sembra aver superato il livello di IETF, l’ultimo del quale risale al 2010.[16]

Visualizzare la configurazione IP[modifica | modifica wikitesto]

I sistemi Windows offrono un comando da digitare direttamente su shell, detto ipconfig, che permette di conoscere la configurazione IP del proprio computer. I comandi sono:

  • ipconfig

oppure

  • ipconfig /all

L'uscita di quest'ultimo comando fornisce informazioni più dettagliate rispetto al precedente comando.

I sistemi Unix e Unix-like come LINUX offrono il comando ifconfig da digitare su shell che permette di conoscere la configurazione IP del proprio computer.

Note[modifica | modifica wikitesto]

  1. ^ RFC 2131, Section 4.1 Constructing and sending DHCP messages
  2. ^ a b Michael Patrick (January 2001)."RFC 3046-DHCP Relay Agent Information Option".Network Working Group.
  3. ^ a b c d Ralph Droms (March 1997)."RFC 2131-Dynamic Host Configuration Protocol".Network Working Group.
  4. ^ a b c Timothy Stapko (2011).Pratical Embedded Security:Building Secure Rescource-Constrained Systems. Newnes. p.39. ISBN 978-0-08-055131-9.
  5. ^ Derrick Rountree (2013).Windows 2012 Server Network Security: Securing Your Windows Network Systems and Infrastructure. Newnes. p.22 ISBN978-1-59749-965-1.
  6. ^ Timothy Rooney (2010).Introduction to IP Address Managment. John Wiley & Sons. p. 180. ISBN978-1-118-07380
  7. ^ a b Sergey Golovanov (Kaspersky Labs) (June 2011)."TDSS loader now got"legs"".
  8. ^ Akash K Sunny (October 2015)."DHCP protocol and its vulnerabilities".
  9. ^ Francisco J. Hens; José M. Caballero (2008).Triple Play: Building the converged network for IP,VoIP and IPTV John Wiley & Sons. p. 239.ISBN978-0-470-75439-9
  10. ^ David H. Ramirez (2008).IPTV Security: Protecting High-Value Digital Contents. John Wiley & Sons. p. 55.ISBN978-0-470-72719-5
  11. ^ Ted Lemon (April 2002)."Implementation of RFC3118"
  12. ^ Philip Golden; Hervé Dedieu; Krista S. Jacobsen (2007).Implementation and Applications of DSL TechnologyTaylor & Francis. p. 484.ISBN978-1-4200-1307-8
  13. ^ Timothy Rooney (2010).Introduction to IP Address ManagementJohn Wiley & Sons. pp. 181–182.ISBN978-1-118-07380-3
  14. ^ Rebecca Copeland (2008).Converging NGN Wireline and Mobile 3G Networks with IMSTaylor & Francis. pp. 142–143.ISBN978-1-4200-1378-8
  15. ^ Ramjee Prasad; Albena Mihovska (2009).New Horizons in Mobile and Wireless Communications:Networks,services, and applications. 2. Artech House. p. 339. ISBN978-1-60783-970-5
  16. ^ "Archived copy"Archived fromthe originalon 2015-04-03. Retrieved 2013-12-12.








Voci correlate[modifica | modifica wikitesto]

Collegamenti esterni[modifica | modifica wikitesto]

  • RFC 2131 - Dynamic Host Configuration Protocol
  • RFC 1534 - Interoperation Between DHCP and BOOTP
  • RFC 2132 - DHCP Options and BOOTP Vendor Extensions
  • Sito del server DHCP prodotto dall'Internet Systems Consortium
Controllo di autorità GND: (DE4608416-2
Telematica Portale Telematica: accedi alle voci di Wikipedia che parlano di reti, telecomunicazioni e protocolli di rete