Dynamic Host Configuration Protocol: differenze tra le versioni

Versione delle 09:55, 12 apr 2019

Versione delle 04:04, 1 mag 2019

Riga 112:

*I Client non autorizzati che hanno accesso alle risorse.<ref name="Nome RFC2131" />

*Gli attacchi di esaurimento delle risorse da client DHCP dannosi.<ref name="Nome RFC2131" />

Poiché il client non ha modo di convalidare l'identità di un server DHCP, i server DHCP non autorizzati (comunemente chiamati "rogue DHCP") possono operare in rete, fornendo informazioni non corrette ai client DHCP.<ref name="Nome Embedded">Timothy Stapko (2011).[https://books.google.it/books?id=Mly55VntuYMC&pg=PA39&redir_esc=y#v=onepage&q&f=false Pratical Embedded Security:Building Secure Rescource-Constrained Systems]. Newnes. p.39. ISBN 978-0-08-055131-9.</ref> Ciò può servire sia come attacco denial-of-service che impedisce al client di accedere alla connettività di rete,<ref>Derrick Rountree (2013).[https://books.google.it/books?id=NFzou_d4MGUC&pg=SA2-PA13&redir_esc=y#v=onepage&q&f=false Windows 2012 Server Network Security: Securing Your Windows Network Systems and Infrastructure]. Newnes. p.22 ISBN 978-1-59749-965-1.</ref> che come [[attacco man in the middle|attacco man-in-the-middle]].<ref> Timothy Rooney (2010).[https://books.google.it/books?id=QgRDxkuI1MkC&pg=PA180&redir_esc=y#v=onepage&q&f=false Introduction to IP Address Management]. John Wiley & Sons. p. 180. ISBN 9781118073810</ref>Poiché il server DHCP fornisce il client DHCP con indirizzi IP del server, come l'indirizzo IP di uno o più server DNS,<ref name="Nome RFC2131" /> 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.<ref name='Nome TDSS'>Sergey Golovanov (Kaspersky Labs) (June 2011).[https://securelist.com/tdss-loader-now-got-legs/30844/ "TDSS loader now got"legs""].</ref><ref>Akash K Sunny (October 2015).[httphttps://greyhatsspeak.blogspot.it/2015/11/dhcp-protocol-and-its-vulnerabilities.html "DHCP protocol and its vulnerabilities"].</ref> 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.<ref name="Nome TDSS" />

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.<ref name="Nome Embedded" />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.<ref name="Nome Embedded" /> 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<ref> Francisco J. Hens; José M. Caballero (2008).[https://books.google.it/books?id=aS1ZngveBIkC&pg=PA239&redir_esc=y#v=onepage&q&f=false Triple Play: Building the converged network for IP,VoIP and IPTV] John Wiley & Sons. p. 239.ISBN 978-0-470-75439-9</ref><ref> David H. Ramirez (2008).[https://books.google.it/books?id=70tr_hSDULwC&pg=PA55&redir_esc=y#v=onepage&q&f=false IPTV Security: Protecting High-Value Digital Contents]. John Wiley & Sons. p. 55.ISBN 978-0-470-72719-5</ref>) 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.<ref name="Nome AUTENTICAZIONE" /> 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.<ref>Ted Lemon (April 2002).[httphttps://www.ietf.org/mail-archive/web/dhcwg/current/msg00876.html "Implementation of RFC3118"]</ref>

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 [[IEEE 802.1x|802.1x]], ha rallentato la distribuzione e il tasso di DHCP autenticati e non è mai stato ampiamente diffuso ".<ref>Philip Golden; Hervé Dedieu; Krista S. Jacobsen (2007).[https://books.google.it/books?id=Jjkd74jY47oC&pg=PA484&redir_esc=y#v=onepage&q&f=false Implementation and Applications of DSL Technology] Taylor & Francis. p. 484.ISBN 978-1-4200-1307-8</ref> 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".<ref>Timothy Rooney (2010).[https://books.google.it/books?id=QgRDxkuI1MkC&pg=PA181&redir_esc=y#v=onepage&q&f=false Introduction to IP Address Management] John Wiley & Sons. pp. 181–182.ISBN 978-1-118-07380-3</ref>