DHCP

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare

În telecomunicații și IT, Protocolul de configurare a gazdei dinamice ( acronim DHCP , lit. „protocol de configurare IP dinamic”) este un protocol de aplicație (auxiliar) care permite dispozitivelor sau terminalelor unei anumite rețele locale să primească automat fiecare cerere de acces, de la un IP rețea (cum ar fi o rețea LAN ), configurația IP necesară pentru a stabili o conexiune și pentru a opera pe o rețea mai largă bazată pe protocol Internet , adică interoperă cu toate celelalte subrețele prin schimbul de date, atâta timp cât acestea sunt, de asemenea, integrate cu aceeași cu protocolul IP. Protocolul este implementat ca serviciu de rețea sau ca tip de server : de exemplu în sistemele Unix și similare Unix este implementat în daemonul dhcpd, în cele bazate pe Active Directory Microsoft și / sau Windows Server de către serviciul server dhcp.

Generalitate

Într-o rețea bazată pe protocolul IP , fiecare computer are nevoie de o adresă IP , aleasă în așa fel încât să aparțină setului de adrese posibile atribuite întregii subrețele (adică Net_ID) la care este conectat și care este unic , adică nu există alte computere care folosesc deja acea adresă.

De fapt, sarcina de atribuire manuală a adreselor IP computerelor implică o povară semnificativă pentru administratorii de rețea , în special în rețelele mari sau în cazul numeroaselor computere care se conectează în rotație doar la anumite ore sau zile. În plus, adresele IPv4 disponibile (utilizate în prezent în aproape toate rețelele din lume) odată cu creșterea numărului de computere conectate la Internet au început să devină rare, scăzând disponibilitatea IP-urilor fixe pentru orice configurații statice .

DHCP acceptă această sarcină în mod automat și dinamic, adică numai la cererea gazdei. Este utilizat în principal în rețelele locale , în special prin Ethernet . În alte contexte, funcții similare sunt îndeplinite în cadrul PPP . Odată ce configurația rețelei a fost recepționată, stația sau computerul din rețeaua locală devine efectiv o gazdă ( oaspete ) a Internetului și poate efectua sesiuni de navigare pe web și toate celelalte servicii oferite de rețea. De fapt, un serviciu DHCP este realizat și de un simplu router de acasă.

În funcție de implementare, serverul DHCP poate avea trei metode de alocare a adreselor IP:

Alocare dinamică

Este alocarea automată a adreselor temporare.

Alocarea dinamică pentru o anumită perioadă se numește „leasing”. Clientul îl poate extinde prin cerere suplimentară sau poate elibera adresa închiriată oricând dacă nu mai este necesară. În caz de lipsă de adrese, serverul DHCP reutilizează adresele închiriate cu timpul expirat

Alocare automată

Serverul DHCP atribuie automat o adresă IP unui client solicitant în intervalul definit de administrator. Acesta este același lucru ca și în alocarea dinamică, dar serverul DHCP menține un tabel cu alocări de adrese IP anterioare, astfel încât să poată atribui preferențial aceeași adresă IP veche unui client.

Alocare manuală (denumită în mod obișnuit alocare statică)

Serverul DHCP emite o adresă IP privată dependentă de adresa MAC a fiecărui client, pe baza unei mapări predefinite de către administrator. Această caracteristică este menționată în diferite moduri: cum ar fi atribuirea statică DHCP în DD-WRT , adresa fixă din documentația dhcpd, rezervarea adreselor de la Netgear , DHCP sau rezervarea statică DHCP de către Cisco și Linksys și rezervarea adresei IP sau MAC / IP legarea adreselor de la diferiți producători de rute. Dacă nu se găsește nicio potrivire pentru adresa MAC a clientului, serverul nu poate recurge opțional la alocarea dinamică sau automată.

DHCP este utilizat pentru Internet Protocol versiunea 4 (IPv4), precum și pentru IPv6 . Deși ambele versiuni au același scop, detaliile protocolului pentru IPv4 și IPv6 diferă suficient încât să poată fi considerate două protocoale separate. [1] Pentru funcționarea IPv6 , dispozitivele pot folosi alternativ configurarea automată a adresei fără stat. Gazdele IPv6 pot utiliza, de asemenea, adresarea link-locală pentru a realiza operațiuni limitate la linkul de rețea locală.

Componentele protocolului

Clientul DHCP este un computer care trebuie să obțină o adresă IP validă pentru subrețeaua la care este conectat, este și programul care se ocupă de solicitarea adresei IP și configurarea acesteia.

Serverul DHCP este computerul care atribuie adrese IP, este și procesul care îndeplinește această funcție. Uneori, această caracteristică este încorporată într-un router .

Releul DHCP este computerul (sau mai des o funcție implementată într-un router ) care se ocupă de redirecționarea cererilor DHCP către un server, dacă acesta nu se află pe aceeași subrețea. Această componentă este necesară numai dacă un server DHCP trebuie să deservească mai multe subrețele. Trebuie să existe cel puțin un releu DHCP pentru fiecare subrețea servită. Fiecare releu trebuie configurat în mod explicit pentru a redirecționa cererile către unul sau mai multe servere.

Parametrii gestionați de DHCP

Protocolul DHCP este, de asemenea, utilizat pentru a atribui computerului diverși parametri necesari funcționării sale corecte în rețeaua la care este conectat. Printre cele mai frecvente, pe lângă atribuirea dinamică a adresei IP, putem menționa:

Cu toate acestea, în protocol există suport pentru alocarea multor alți parametri prin DHCP, definit în RFC 2132 .

Cererea și atribuirea adresei

O imagine care prezintă o sesiune tipică DHCP; fiecare mesaj poate fi difuzat și unicast , în funcție de capacitățile clientului DHCP [2]

DHCP utilizează protocolul UDP , porturile înregistrate sunt 67 pentru server și 68 pentru client.

Când un computer dorește să obțină o adresă prin DHCP, acesta declanșează procesul client DHCP. În acest moment, computerul nu are o adresă IP validă, deci nu poate utiliza toate caracteristicile rețelei.

Procedura descrisă de protocol constă în mai multe strângeri de mână între client și server sau schimb de pachete, desigur toate încapsulate în cadre ale stratului de legătură , cum ar fi Ethernet :

  • În primul rând, clientul trimite un pachet numit DHCPDISCOVER în difuzare , cu adresa IP sursă setată în mod convențional la 0.0.0.0 și destinația 255.255.255.255 ( adresa de difuzare ).
  • Pachetul este primit de toate gazdele prezente în același domeniu de difuzare și, prin urmare, de orice servere DHCP prezente, care pot răspunde (sau nu) cu un pachet DHCPOFFER în care propun clientului o adresă IP și alți parametri de configurare. Acest pachet de returnare este adresat la adresa de nivel de legătură de date a clientului (la adresa MAC a acestuia - nu are încă o adresă IP) sau în unicast .

Dacă există, de asemenea, unul sau mai multe relee DHCP în domeniul de difuzare, acestea redirecționează pachetul către serverul lor de referință, care poate răspunde întotdeauna clientului prin releu. Agentul de releu îi spune serverului adresa IP pe subrețeaua de la care a primit pachetul DHCPDISCOVER , permițând serverului să afle din ce subrețea a venit cererea și apoi să ofere o adresă pentru subrețeaua potrivită. Un server DHCP care urmează să deservească mai multe subrețele IP trebuie să fie configurat pentru a cunoaște parametrii fiecăruia (adresa de rețea, masca de subrețea, adresa de difuzare, adresa gateway-ului).

  • Clientul așteaptă un anumit timp pentru a primi una sau mai multe oferte, apoi selectează una și trimite un pachet DHCPREQUEST (sau DHCPACCEPT) în difuzare, indicând în cadrul pachetului, cu câmpul „identificator server”, ce server a selectat. Acest pachet ajunge și la toate serverele DHCP din rețea (direct sau printr-un releu).
  • Serverul care a fost selectat confirmă atribuirea adresei cu un pachet DHCPACK (adresat din nou în transmisie la adresa de nivel de legătură de date a clientului, posibil printr-un releu); celelalte servere sunt informate automat că oferta lor nu a fost aleasă de client și că există un alt server DHCP pe subrețea.

Expirarea și reînnoirea adreselor

În acest moment, clientului i se permite să utilizeze adresa primită pentru o perioadă limitată, numită timpul de închiriere . Înainte de expirare, va trebui să încerce să-l reînnoiască trimițând un nou pachet DHCPREQUEST la server, care va răspunde cu un DHCPACK dacă dorește să extindă atribuirea adresei. Acestea sunt pachete IP unicast normale schimbate între două computere care au adrese valide. Dacă clientul nu reușește să reînnoiască adresa, acesta va reveni la starea inițială încercând să obțină alta.

Identificarea și autentificarea clientului

Clientul se identifică la server printr-un câmp client-id al pachetelor DHCP. Acest câmp are în mod normal adresa MAC a plăcii de rețea pentru care se solicită adresa ca valoare, dar poate fi configurat și manual. Aceasta este singura formă de autentificare disponibilă pentru DHCP și este destul de slabă, deoarece folosește date care sunt difuzate prin rețeaua locală și, prin urmare, pot fi ușor găsite de orice alt computer conectat la aceeași rețea. Există modalități mai robuste de a controla accesul la o rețea, dar necesită asistență de la comutatoarele la care utilizatorii sunt conectați, cum ar fi IEEE 802.1x .

Un server ar trebui să încerce să atribuie întotdeauna aceeași adresă IP pe fiecare subrețea aceluiași client, dar nu există nicio garanție că acest lucru este posibil, cu excepția cazului în care o adresă este asociată exclusiv cu un singur client.

Serverul poate utiliza câmpul de identificare client pentru a decide ce adresă să îi atribuie clientului sau ce alți parametri să îi transmită sau chiar să nu răspundă deloc la solicitarea clientului.

Securitatea, în ceea ce privește accesul la o rețea , nu este asigurată de adresele IP statice, ci de implementarea politicilor de autentificare atât pe partea de domeniu , cât și, eventual, pe firewall : utilizarea adreselor dinamice nu are niciun impact asupra securității, așa cum este o bază de servicii care facilitează foarte mult adăugarea resurselor clientului, nefiind nevoit să recurgă la configurații specializate de fiecare dată, chiar dacă este doar inserarea parametrilor de conexiune fizică în rețea. După cum sa menționat, conexiunea logică trebuie gestionată prin permisiuni de autentificare.

În afară de clienți în sensul utilizatorilor, există servicii și resurse care trebuie de obicei abordate static: imprimante, routere, servere, sisteme de înregistrare sau supraveghere etc.

Identificarea serverului

Serverul se identifică clientului cu propria adresă IP. Un client ar putea decide apoi să accepte adresele numai de la un server care este deja cunoscut.

Orice computer conectat la o subrețea ar putea acționa ca un server DHCP pentru computerele din acea subrețea sau ca un releu către un server DHCP arbitrar. Prin urmare, este posibil ca un computer care este configurat greșit sau în mod deliberat în scopuri ilicite să ofere în mod ilegal adrese IP, creând defecțiuni ale rețelei și / sau probleme grave de securitate.

Un computer care a primit adresa IP de la un server DHCP prost configurat nu va putea utiliza rețeaua.

Dacă, pe de altă parte, serverul DHCP abuziv este configurat în scopuri ilegale, consecințele pot fi și mai grave: de fapt, poate oferi adrese despre care știe că sunt neutilizate sau pe o subrețea IP, alta decât cea oficială, evitând astfel generând conflicte cu serverul oficial. și se indică ca gateway implicit. Apoi va trebui să redirecționeze conexiunile făcute de clienți către gateway-ul oficial folosind mascherarea IP . În acest moment, va fi capabil să intercepteze și să adulmece tot traficul generat de clienți, care s-ar putea să nu observe cu ușurință diferența.

Pentru a preveni aceste riscuri, unele switch-uri oferă o caracteristică numită „DHCP snooping”, prin care analizează toate pachetele DHCP care trec prin ele, oprindu-le pe cele care nu provin de la servere autorizate.

Releu DHCP

În rețelele mici, unde este gestionată o singură subrețea IP, clienții DHCP comunică direct cu serverele DHCP. Cu toate acestea, serverele DHCP pot furniza și adrese IP pentru mai multe subrețele. În acest caz, un client DHCP care nu a dobândit încă o adresă IP nu poate comunica direct cu serverul DHCP folosind rutare IP, deoarece nu are o adresă IP a routerului, nu cunoaște adresa IP a unui router și nu știe adresa IP. Adresa IP a serverului DHCP.

Pentru a permite clienților DHCP de pe subrețele care nu sunt deservite direct de serverele DHCP să comunice cu serverele DHCP, puteți instala agenți de releu DHCP pe aceste subrețe. Clientul DHCP transmite pe link-ul local; agentul de releu primește transmisia și o redirecționează către unul sau mai multe servere DHCP folosind unicast . Agentul de releu își stochează adresa IP în câmpul GIADDR al pachetului DHCP. Serverul DHCP utilizează GIADDR pentru a determina subrețeaua pe care agentul de releu a primit difuzarea și atribuie o adresă IP pe acea subrețea. Când serverul DHCP răspunde clientului, acesta trimite răspunsul la adresa GIADDR, utilizând din nou unicast. Agentul de releu retransmite apoi răspunsul prin rețeaua locală.

În această situație, comunicația dintre agentul de releu și serverul DHCP utilizează de obicei portul UDP sursă și de destinație 67.

Fiabilitate

DHCP garantează fiabilitatea în mai multe moduri: reînnoire periodică, rebinding [3] și failover. Clienților DHCP li se atribuie contracte de leasing care durează o anumită perioadă de timp. Clienții încep să încerce să reînnoiască contractul de leasing odată cu expirarea jumătății intervalului de leasing. [3] Acestea fac acest lucru trimițând un mesaj DHCPREQUEST unicast către serverul DHCP care a acordat contractul original de închiriere. Dacă serverul este defect sau nu poate fi accesat, [3] nu va răspunde la DHCPREQUEST. Cu toate acestea, în acest caz, clientul repetă DHCPREQUEST din când în când, deci dacă serverul DHCP este resetat sau devine din nou accesibil, clientul DHCP va putea să îl contacteze și să reînnoiască contractul de închiriere.

Dacă serverul DHCP nu poate fi accesat pentru o perioadă lungă de timp, [3] clientul DHCP va încerca să se reasocieze, difuzând DHCPREQUEST-ul său mai degrabă decât unicast. Odată transmis, mesajul DHCPREQUEST va ajunge la toate serverele DHCP disponibile. Dacă orice alt server DHCP este capabil să reînnoiască contractul de închiriere, îl va face în acest moment.

Pentru a relua funcționarea, atunci când clientul contactează cu succes un server DHCP de rezervă, acel server trebuie să aibă informații corecte de legare a clientului. Menținerea informațiilor corecte de legare între două servere este o problemă complicată; dacă ambele servere sunt capabile să actualizeze aceeași bază de date de închiriere, trebuie să existe un mecanism pentru a evita conflictele între actualizări pe servere independente. O propunere de implementare a serverelor DHCP tolerante la erori a fost trimisă către Task Force de Inginerie Internet, dar nu a fost formalizată niciodată. [4]

În cazul în care refacerea eșuează, contractul de închiriere va expira în cele din urmă. Când expiră leasingul, clientul trebuie să înceteze să utilizeze adresa IP acordată acestuia în leasingul său. [3] Apoi va reporni procesul DHCP de la început prin trimiterea unui mesaj DHCPDISCOVER. Deoarece contractul de închiriere a expirat, acesta va accepta orice adresă IP oferită. Odată ce are o adresă nouă (probabil de la un alt server DHCP) va putea utiliza din nou rețeaua. Cu toate acestea, odată cu schimbarea adresei sale IP, toate conexiunile în curs vor fi abandonate.

Siguranță

DHCP de bază nu include niciun mecanism de autentificare. [5] Din acest motiv, este vulnerabil la diferite atacuri. Aceste atacuri se împart în trei categorii principale:

  • Serverele DHCP neautorizate furnizează informații false clienților. [6]
  • Clienți neautorizați care au acces la resurse. [6]
  • Atacuri de epuizare a resurselor de la clienți DHCP rău intenționați. [6]

Deoarece clientul nu are nicio modalitate de a valida identitatea unui server DHCP, serverele DHCP neautorizate (denumite în mod obișnuit „DHCP necinstit”) pot funcționa în rețea, oferind informații incorecte clienților DHCP. [7] Acest lucru poate servi fie ca un atac de refuz de serviciu care împiedică clientul să acceseze conectivitatea de rețea, [8], fie ca un atac om-în-mijloc . [9] Întrucât serverul DHCP furnizează clientului DHCP adresele IP ale serverului, cum ar fi adresa IP a unuia sau mai multor servere DNS, [6] un atacator poate convinge un client DHCP să efectueze căutările DNS prin intermediul serverului său DNS și poate, de asemenea, furnizează propriile răspunsuri la întrebările DNS de la client. [10] [11] Acest lucru, la rândul său, permite atacatorului să redirecționeze traficul de rețea prin el însuși, permițându-i să intercepteze conexiunile dintre client și serverele de rețea pe care le contactează sau pur și simplu să înlocuiască serverele de rețea cu ale sale. [10]

Deoarece serverul DHCP nu are un mecanism sigur pentru autentificarea clientului, clienții pot obține acces neautorizat la adresele IP prezentând acreditări, cum ar fi identificatorii clientului, care aparțin altor clienți DHCP. [7] Acest lucru permite, de asemenea, clienților DHCP să epuizeze depozitul de adrese IP al serverului DHCP, prezentând noi acreditări de fiecare dată când solicită o adresă, clientul poate consuma toate adresele IP disponibile pe o anumită legătură de rețea, împiedicând alți clienți DHCP să primească serviciul. [7] DHCP oferă câteva mecanisme pentru a atenua aceste probleme. Extensia protocolului Opțiunea de informație a agentului de releu ( RFC 3046 , denumită de obicei în industrie prin numărul real ca opțiunea 82 [12] [13] ) permite operatorilor de rețea să atașeze etichete la mesajele DHCP pe măsură ce aceste mesaje ajung în rețeaua de încredere a operatorului de rețea. . Această etichetă este apoi utilizată ca jeton de autorizare pentru a controla accesul clientului la resursele de rețea. Deoarece clientul nu are acces la rețeaua agentului de releu, lipsa autentificării nu împiedică operatorul serverului DHCP să se bazeze pe jetonul de autentificare. [5] O altă extensie, autentificare pentru mesaje DHCP ( RFC 3118 ), oferă un mecanism pentru autentificarea mesajelor DHCP. Din păcate, RFC 3118 nu a fost adoptat pe scară largă (începând cu 2002) din cauza problemelor cheie de gestionare pentru un număr mare de clienți DHCP. [14]

O carte din 2007 despre tehnologiile DSL a constatat că „o serie de vulnerabilități de securitate au fost identificate împotriva măsurilor de securitate propuse de RFC 3118. Acest fapt, combinat cu introducerea 802.1x , a încetinit distribuția și rata DHCP autentificat. nu a fost niciodată larg răspândită. " [15] O carte din 2010 notează că "au existat foarte puține implementări de autentificare DHCP. Problemele cheie de gestionare și întârzierile de procesare au fost considerate un preț prea mare pentru a fi plătit pentru beneficiile percepute". [16] Propunerile arhitecturale mai recente (2008) implică autentificarea solicitărilor DHCP folosind 802.1x sau PANA (care poartă EAP ). [17] S-a făcut o propunere IETF de a include EAP în DHCP în sine, așa-numitul EAPoDHCP; [18] nu pare să fi depășit nivelul IETF, ultimul datând din 2010. [19]

Vizualizarea configurației IP

Sistemele Windows oferă o comandă pentru a tasta direct din shell , numită ipconfig (configurație interfață), care vă permite să cunoașteți configurația IP a computerului. Comanda ipconfig vă permite să aveți multe informații despre configurația și starea interfeței de rețea. Comanda:

  • ipconfig / all

vă permite să vizualizați toate interfețele de rețea prezente pe un computer și oferă informații mai detaliate decât comanda anterioară.

Sistemele Unix și Unix, cum ar fi LINUX, oferă comanda ifconfig pentru a tasta din shell care vă permite să cunoașteți configurația IP a computerului.

Notă

  1. ^ (EN) Droms Ralph și Ted Lemon, Manualul DHCP , Editura Sams, 2003, p. 436 , ISBN 978-0672323270 .
  2. ^ RFC 2131, Secțiunea 4.1 Construirea și trimiterea mesajelor DHCP
  3. ^ a b c d și Droms, Ralph (martie 1997). Opțiuni DHCP și extensii pentru furnizori BOOTP. IETF. RFC 2131 . Adus pe 9 septembrie 2014.
  4. ^ Droms, Ralph; Kinnear, Kim; Stapp, Mark; Volz, Bernie; Gonczi, Steve; Rabil, Greg; Dooley, Michael; Kapur, Arun (martie 2003). DHCP Failover Protocol. IETF. ID draft-ietf-dhc-failover-12. Adus pe 09 mai 2010.
  5. ^ a b Michael Patrick (ianuarie 2001). "RFC 3046 - Opțiunea de informații despre agentul de releu DHCP". Grupul de lucru în rețea.
  6. ^ a b c d Ralph Droms (martie 1997). "RFC 2131 - Protocol de configurare dinamică a gazdei". Grupul de lucru în rețea.
  7. ^ a b c Timothy Stapko (2011). Securitate încorporată practică: construirea de sisteme de restricționare a resurselor securizate . Newnes. p.39. ISBN 978-0-08-055131-9 .
  8. ^ Derrick Rountree (2013). Securitatea rețelei Windows 2012 Server: securizarea sistemelor și a infrastructurii de rețea Windows . Newnes. p.22 ISBN 978-1-59749-965-1 .
  9. ^ Timothy Rooney (2010). Introducere în gestionarea adreselor IP . John Wiley & Sons. p. 180. ISBN 9781118073810
  10. ^ a b Sergey Golovanov (Kaspersky Labs) (iunie 2011). „Încărcătorul TDSS are acum„ picioare ”” .
  11. ^ Akash K Sunny (octombrie 2015). "Protocolul DHCP și vulnerabilitățile sale" .
  12. ^ Francisco J. Hens; José M. Caballero (2008). Triple Play: Construirea rețelei convergente pentru IP, VoIP și IPTV John Wiley & Sons. p. 239. ISBN 978-0-470-75439-9
  13. ^ David H. Ramirez (2008). Securitate IPTV: protejarea conținutului digital de mare valoare . John Wiley & Sons. p. 55. ISBN 978-0-470-72719-5
  14. ^ Ted Lemon (aprilie 2002). "Implementarea RFC3118"
  15. ^ Philip Golden; Hervé Dedieu; Krista S. Jacobsen (2007). Implementarea și aplicațiile tehnologiei DSL Taylor & Francis. p. 484. ISBN 978-1-4200-1307-8
  16. ^ Timothy Rooney (2010). Introducere în gestionarea adreselor IP John Wiley & Sons. pp. 181–182. ISBN 978-1-118-07380-3
  17. ^ Rebecca Copeland (2008). Convergerea rețelelor NGN Wireline și Mobile 3G cu IMS Taylor & Francis. pp. 142–143. ISBN 978-1-4200-1378-8
  18. ^ Ramjee Prasad; Albena Mihovska (2009). Noi orizonturi în comunicații mobile și wireless: rețele, servicii și aplicații. 2. Casa Artech. p. 339. ISBN 978-1-60783-970-5
  19. ^ „Copie arhivată” Arhivat din original la 03-04-2015. Adus 12-12-2013.

Elemente conexe

Documente standard IETF

  • RFC 2131 - Protocol de configurare a gazdei dinamice
  • RFC 1534 - Interoperarea între DHCP și BOOTP
  • RFC 2132 - Opțiuni DHCP și extensii pentru furnizori BOOTP
  • RFC 3046 - Opțiune de informații despre agentul de releu DHCP
  • RFC 3118 - Autentificare pentru mesaje DHCP

Alte proiecte

linkuri externe

  • Site-ul serverului DHCP produs de Internet Systems Consortium
Controlul autorității GND ( DE ) 4608416-2
Adus de la „ https://it.wikipedia.org/w/index.php?title=Dynamic_Host_Configuration_Protocol&oldid=121764693 ”