1 INTRODUCERE ............................................................................................4

1.1 Securitatea în reŃele LAN .............................................................................................................. 4

1.2 Servicii bazate pe identitate........................................................................................................... 5

1.3 Structura lucr ării ........................................................................................................................... 6

2 PROTOCOLUL EAP .....................................................................................8

3 IMPLEMENTĂRI ALE PROTOCOLULUI EAP ...........................................17

3.1 EAP-MD5...................................................................................................................................... 17

3.2 EAP-OTP ...................................................................................................................................... 18

3.3 EAP-GTC...................................................................................................................................... 19

3.4 PEAP ............................................................................................................................................. 19

3.5 EAP-TLS....................................................................................................................................... 21

3.6 EAP-TTLS .................................................................................................................................... 22

3.7 LEAP............................................................................................................................................. 24

3.8 EAP-FAST .................................................................................................................................... 24

3.9 Alte implementări EAP................................................................................................................ 24

4 APLICAłIE PRACTICĂ - APLICAłIE DE MANAGEMENT AL SECURITĂłII EAPOL PENTRU UN SWITCH DE REłEA ................................26

4.1 FuncŃionalităŃile aplicaŃiei ........................................................................................................... 26 4.1.1 Autentificarea utilizatorilor ....................................................................................................... 26 4.1.2 Vizualizarea configuraŃiilor curente .......................................................................................... 27 4.1.3 Modificarea configuraŃiilor ....................................................................................................... 27

4.2 Arhitectura aplica Ńiei ................................................................................................................... 27

4.3 Implementarea modulelor componente...................................................................................... 28 4.3.1 Modulul de autentificare – login.php ........................................................................................ 28 4.3.2 Modulul main.php ..................................................................................................................... 30 4.3.3 Modulul device.php................................................................................................................... 30 4.3.4 Modulul port.php....................................................................................................................... 31

4.4 Protocoalele de securitate implementate .................................................................................... 33 4.4.1 Protocolul SNMPv3 .................................................................................................................. 33 4.4.2 Protocolul RADIUS .................................................................................................................. 34 4.4.3 Protocolul HTTPS..................................................................................................................... 37

4

1 Introducere

1.1 Securitatea în reŃele LAN

Securitatea echipamentelor de reŃea de nivel legătură de date este foarte importantă întrucât majoritatea atacurilor pornesc de la acest nivel iar de multe ori securitatea la acest nivel este ignorată de către administratorii de reŃea. Switch-urile de tip Ethernet LAN sunt considerate echipamentele de la baza reŃelei şi nu primesc atenŃia meritată. Sunt foarte uşor de instalat şi configurat, dar este foarte simplu să se uite despre securitate atunci când lucrurile par simple. Există multiple vulnerabilităŃi ale switch-urilor Ethernet. Unelte de atac care profită de aceste vulnerabilităŃi au apărut în ultimii ani (spre exemplu, bine-cunoscutul pachet dsniff sau aplicaŃia cain). Folosind aceste unelte de atac, un hacker poate să învingă mitul securităŃii unui switch-urilor, care spune că ascultarea şi interceptarea pachetelor sunt imposibile pe un switch datorită modalităŃii de funcŃionare. Folosind diverse unelte de atac, care au interfeŃe grafice prietenoase şi care rulează pe diverse sisteme de operare, un atacator poate foarte uşor să redirecŃioneze orice tip de trafic spre calculatorul său, spărgând astfel confidenŃialitatea şi integritatea datelor transmise în reŃea.

Cele mai multe vulnerabilităŃi Ńin de protocoalele de nivel 2, de la Spanning Tree Protocol până la DHCP (Dynamic Host Configuration Protocol). Daca nivelul legătură de date este compromis este foarte uşor să fie construite atacuri asupra protocoalelor de nivel superior, folosind tehnici precum man-in-the-middle (MITM). Un hacker care poate să intercepteze orice tip de trafic, poate să insereze date în comunicaŃiile în clar (precum HTTP sau Telnet) dar şi în canalele criptate (precum SSL sau SSH).

Pentru a exploata vulnerabilităŃile nivelului legătură de date, un atacator trebuie să fie adiacent la nivelul 2 cu Ńinta atacului. Chiar dacă pare imposibil pentru un hacker extern să se conecteze la reŃeaua LAN a unei companii, acesta poate să se folosească de ingineria socială (social engineering) pentru a obŃine acces în interiorul companiei. Totuşi, multe atacuri sunt derulate de persoane din interiorul companiei, angajaŃii interni. În mod tradiŃional, există regula nescrisă conform căreia angajaŃii companiei sunt persoane de încredere. Totuşi, în ultimii zece ani, numeroase cazuri şi statisticile dovedesc că regula menŃionată anterior este falsă. Raportul CSI/FBI din 2006 – „Computer Crime and Security Survey” a arătat că 68 % dintre pierderile companiilor au fost cauzate parŃial sau integral de către angajaŃii interni.

Odată intrat în sediul unei companii, un atacator poate să găsească foarte uşor o priză Ethernet liberă sau un dispozitiv conectat la reŃea (spre exemplu, o imprimantă de reŃea), care poate fi deconectat pentru a putea obŃine acces neautorizat la reŃea. Deoarece protocolul DHCP este folosit pe scară largă fără mecanisme de protecŃie şi majoritatea porturilor LAN nu sunt controlate prin autentificare (folosind protocolul 802.1X), calculatorul atacatorului obŃine o adresă IP şi, în majoritatea cazurilor, are aceleaşi drepturi de acces în reŃea ca toŃi ceilalŃi utilizatori normali ai reŃelei. Având la dispoziŃie o adresă IP de reŃea, hacker-ul poate să încerce diverse tipuri de atacuri.

5

Privind astfel nivelul de încredere într-un utilizator al reŃelei, expunerea datelor importante şi confidenŃiale care traversează reŃeaua este o realitate care nu poate fi trecută cu vederea. Majoritatea organizaŃiilor au implementate mecanisme de securitate a accesului la aplicaŃiile şi arhivele lor de documente. Totuşi, aceste mecanisme nu sunt impenetrabile; ele doar asigură că numai utilizatorii autorizaŃi pot să acceseze datele conŃinute în aplicaŃii sau arhive. Aceste mecanisme de control al accesului nu previn ascultarea datelor transmise prin reŃea. Majoritatea datelor transmise prin reŃea nu sunt criptate. Utilizatorii pricepuŃi dar mai ales cei curioşi, folosind scripturi simple, pot să asculte datele transmise prin reŃea căutând informaŃii în text clar. Astfel de date pot fi de natură confidenŃială, precum nume de utilizatori, parole, date confidenŃiale despre clienŃi, contracte sau informaŃii despre carduri bancare. Datele şi informaŃiile din cadrul unei companii sunt foarte importante, în unele cazuri fiind chiar coloana vertebrală a companiei respective. Pierderea sau expunerea informaŃiilor poate fi extrem de dăunătoare unei companii, cauzând pierderi financiare importante sau pierderea credibilităŃii.

Baza de cunoştinŃe necesare pentru ascultarea traficului s-a schimbat dramatic în ultimii 10 ani, datorită apariŃiei de unelte, precum Yersinia sau Cain, care profită de vulnerabilităŃile protocoalelor de reŃea. Aceste aplicaŃii permit unui atacator să se folosească de vulnerabilităŃile sistemelor de operare sau ale aplicaŃiilor pentru a obŃine informaŃii confidenŃiale sau pentru a cauza lipsa de disponibilitate a unui serviciu (atac de tip DoS).

Pentru a contracara aceste vulnerabilităŃi ale switch-urilor Ethernet, producătorii de echipamente au implementat aspecte de securitate precum autentificarea utilizatorilor, analiza protocoalelor atacate (DHCP, ARP, STP, etc), criptarea datelor la nivel 2, etc.

1.2 Servicii bazate pe identitate

Un concept care se răspândeşte rapid, în special datorită implementării în reŃelele fără fir (wireless), este cel de Servicii Bazate pe Identitate (IBNS - Identity Based Networking Services). Serviciile bazate pe identitate sunt implementate în reŃelele de tip LAN folosind protocolul IEEE 802.1X (EAPoL). ReŃelele companiilor trebuie să suporte accesul şi pentru utilizatori externi precum parteneri sau clienŃi. Astfel, securitatea şi accesul la reŃea au o foarte mare importanŃă. ReŃeaua trebuie să prevină accesul utilizatorilor neautorizaŃi, dar, în acelaşi timp, să ofere un mediu de lucru flexibil. Utilizatorii externi autentificaŃi pot primi niveluri diferite de autorizare sau pot fi forŃaŃi să treacă printr-un gateway. Standardul IEEE 802.1X permite folosirea modelului de control al accesului şi este cel mai utilizată metodă de autentificare la nivelul legătură de date, atât pe medii fără fir cât şi pe cele cablate. Standardul IEEE 802.1X stă şi la baza conceptului de control al accesului bazat pe port (port-based access control).

802.1X permite configurarea dinamică a porturilor de acces şi poate implementa politici de securitate la nivel de port. Un client 802.1X reprezintă un utilizator sau un dispozitiv care încearcă să obŃină un serviciu de reŃea. Clientul trebuie autentificat de un server de autentificare prin intermediul unui dispozitiv de acces la reŃea. Standardul 802.1X poate să ofere diverse niveluri de acces pentru clienŃii autentificaŃi. 802.1X ajută

6

la reducerea riscurilor de securitate, adaugă valoare şi reduce costurile de operare, de aceea este necesar pentru orice companie care are nevoie de control al accesului la reŃea, să implementeze standardul 802.1X.

Serviciile bazate pe identitate recomandă urmarea a trei principii legate de securitate, autorizare şi vizibilitate:

• Blocarea utilizatorilor care nu sunt permişi de către politica de securitate. Această regulă ajută împotriva fraudelor, furturilor de servicii şi elimină accesul neautorizat. Datorită utilizatorilor mobili, clienŃilor, vizitatorilor, perimetrele de securitate sunt restrânse iar riscurile de securitate cresc.

• Asigurarea onestităŃii utilizatorilor interni. O reŃea poate avea diverse niveluri de acces şi autorizare. Controlând unde poate să ajungă şi ce poate să facă un utilizator, presupune un efort considerabil.

• Creşterea vizibilităŃii asupra celor care se conectează la reŃea. Astfel se poate înregistra cine şi când a accesat sau a încercat să acceseze reŃeaua.

Serviciile bazate pe identitate definesc trei concepte care stau la baza autentificării utilizatorilor şi a dispozitivelor:

• Identificarea – Identitatea unui client este reprezentată de un identificator digital în contextul unui domeniu de încredere. Identificatorul este folosit de obicei ca un indicator spre un set de drepturi sau permisiuni şi permite diferenŃierea între utilizatori. Un identificator, din punct de vedere fizic, poate să fie reprezentat în orice fel şi poate fi prezent la orice nivel OSI în cadrul unui mediu de reŃea. O reŃea foloseşte identificatori digitali autentificaŃi pentru a oferi capabilităŃi de autorizare. O identitate este folositoare pentru înregistrări de audit şi ca un indicator spre o politică aplicabilă.

• Autentificarea – Autentificarea este procesul stabilirii şi confirmării identităŃii unui client care solicită servicii. Autentificarea este cerută la stabilirea autorizării corespunzătoare şi este la fel de puternică ca şi metoda de verificare folosită.

• Autorizarea – Autorizarea este definită ca drepturile la servicii dintr-un domeniu, şi poate fi aplicată oricărui nivel OSI. Autorizarea fără autentificarea nu are sens.

Împreună cu standardul 802.1X, serviciile bazate pe identitate oferă aceste concepte de bază (identificarea, autentificarea şi autorizarea) independent de mediul de transmisie folosit în LAN. Utilizatorii trebuie să fie autentificaŃi când accesează reŃeaua LAN prin mediu de transmisie cablat (punct la punct) sau fără fir. Doar utilizatorii şi dispozitivele permise de organizaŃie trebuie să aibă acces. Serviciile bazate pe identitate ajută la definirea a ceea ce pot face utilizatorii prin control diferenŃiat al accesului. Autentificarea oferă de asemenea posibilitatea înregistrării celor care primesc acces la reŃea, când, unde şi cum pot obŃine serviciile.

1.3 Structura lucr ării

Lucrarea de faŃă este structurată astfel: în capitolul 2, Protocolul EAP, va fi prezentat protocolul EAP descris în RFC 3748 şi implementarea pentru reŃele 802

7

descrisă în standardul IEEE 802.1X. Capitolul 3, Implementări ale protocolului EAP, va prezenta principalele implementări practice ale standardului IEEE 802.1X, cât şi avantaje şi dezavantaje ale implementărilor. Capitolul 4, AplicaŃie practică - AplicaŃie de management al securităŃii EAPoL pentru un switch de reŃea, va prezenta funcŃionalităŃile, arhitectura şi implementarea modulelor componente ale aplicaŃiei, dar şi protocoalele de securitate folosite.

8

2 Protocolul EAP

Protocolul EAP (Extensible Authentication Protocol) este definit în RFC 3748 şi reprezintă o arhitectură de autentificare pe care pot fi implementate diverse metode de autentificare. Protocolul EAP rulează direct pe nivelul legătură de date cum ar fi PPP (Extensible Authentication Protocol) sau IEEE 802, fără a avea nevoie de protocoale de nivel reŃea precum IP. Protocolul EAP oferă suport pentru eliminarea pachetelor duplicate şi pentru retransmisie, dar nu suportă fragmentarea pachetelor. Există implementări de EAP care suportă şi fragmentare.

Protocolul EAP poate fi folosit pe linii dedicate, circuite comutate, medii cablate dar şi pe medii fără fir. EAP a fost implementat între host-uri şi routere care se conectează prin circuite comutate sau linii dial-up care folosesc protocolul PPP. Cea mai răspândită implementare este pe switch-uri şi puncte de acces care folosesc IEEE 802. Implementarea EAP peste mediile cablate IEEE 802 este descrisă în standardul IEEE 802.1X. Implementarea EAP peste mediile wireless este descrisă în standardul IEEE 802.11i.

Unul din avantajele arhitecturii EAP este flexibilitatea protocolului. EAP este folosit pentru alegerea unui mecanism de autentificare specific, după ce autentificatorul cere mai multe informaŃii pentru a determina metoda de autentificare care trebuie folosită. În loc să fie necesar ca autentificatorul să fie actualizat pentru a suporta orice nouă metodă de autentificare, EAP permite folosirea unui server de autentificare care implementează o parte sau toate metodele de autentificare, autentificatorul servind ca un punct de trecere pentru aceste metode şi pentru clienŃi.

Standardul IEEE 802.1X dar şi RFC 3748 definesc o terminologie folosită pentru entităŃile participante în arhitectura protocolului EAP.

• Autentificatorul (authenticator) reprezintă entitatea aflată la capătul unui segment de reŃea punct la punct LAN , care facilitează autentificarea entităŃii aflate la celălalt capăt al segmentului de reŃea. În practică, autentificatorul este reprezentat de un switch de reŃea sau de un punct de acces pentru reŃelele fără fir.

• Suplicantul (supplicant) reprezintă entitatea aflată la capătul unui segment de reŃea punct la punct LAN , care trebuie să fie autentificat de un autentificator aflat la celălalt capăt al segmentului de reŃea. În practică, suplicantul este reprezentat de clientul care se autentifică într-o reŃea.

• Serverul de autentificare (Authentication server) reprezintă entitatea care oferă un serviciu de autentificare pentru autentificator. Serviciul de autentificare determină, în funcŃie de datele de identificare oferite de suplicant, dacă suplicantul are dreptul de accesa serviciile de reŃea oferite de autentificator. În practică, serverul de autentificare oferă un serviciu de tip AAA (Authentication, Authorization, and Accounting) – autentificare, autorizare şi înregistrare.

9

Protocoale de tip AAA care suportă EAP sunt RADIUS [RFC3579] şi Diameter.

Autentificarea prin EAP este un dialog între clientul (suplicantul) care doreşte să se conecteze şi să beneficieze de serviciile reŃelei şi reŃea. Acest dialog se bazează pe protocolul extensibil de autentificare EAP. Arhitectura de autentificare este constituită din suplicant, autentificator şi serverul de autentificare. Dialogul dintre suplicant şi autentificator se realizează prin pachete specifice protocolului EAP, la nivelul legătură de date, definite de protocolul EAPoL (EAP over LANs). Dialogul dintre autentificator şi serverul de autentificare este realizat prin protocolul RADIUS care încapsulează pachetele EAP (Figura 1).

Client 802.1X

(Supplicant)

Autentificator - Switch

(Authenticator)Server de autentificare – AAA

(Authentication server)

mesaje

EAPoLmesaje EAP

încapsulate de RADIUS

Figura 1 – Arhitectura de autentificare EAP

Schimbul de mesaje EAP în cadrul unui proces de autentificare se desfăşoară astfel (Figura 2):

[1] Autentificatorul trimite un pachet EAP Request pentru a autentifica suplicantul. Mesaje de tip Request pot fi Request Identity, Request MD5-challenge, etc. De obicei, autentificatorul trimite iniŃial un pachet Request Identity (cerere de identitate), dar acest pachet nu este obligatoriu. Spre exemplu, identitatea nu este ceruta atunci când este determinată de portul în care este conectat clientul (linii închiriate, porturi dial-up), sau când identitatea este obŃinută printr-o altă metodă (adresa MAC a clientului, câmpul Name dintr-un pachet MD5-challenge Response, etc.).

[2] Clientul răspunde la un pachet valid Request cu un pachet Response. La fel ca şi pachetul Request, un pachet Response conŃine un câmp Type (tip), care corespunde cu cel din pachetul Request.

[3] Autentificatorul răspunde cu un pachet Request adiŃional, iar clientul răspunde cu un Response. SecvenŃa de pachete Request şi Response continuă cât timp este nevoie. EAP este un protocol sincronizat (lock-step protocol), astfel că în afară de primul pachet Request trimis, un alt pachet Request nu poate fi transmis înainte de a primi un pachet Response valid.

10

[4] ConversaŃia continuă până când autentificatorul nu poate autentifica clientul (pachete Response incorecte ca răspuns pentru unul sau mai multe pachete Request), caz în care autentificatorul trimite un pachet EAP Failure (câmpul Code = 4). Alternativ, conversaŃia de autentificare continuă până când autentificatorul decide că autentificarea s-a încheiat cu succes, caz în care autentificatorul trimite un pachet EAP Success (câmpul Code = 3).

Client 802.1X

(Supplicant)

Autentificator - Switch

(Authenticator)Server de autentificare – AAA

(Authentication server)

mesaje

EAPoLmesaje EAP

încapsulate de RADIUS

EAP Start

EAP Request

EAP Response

EAP Response

EAP Request/Challenge

EAP Success/Fail

Figura 2 – Procesul de autentificare cu EAP

În Figura 2 este prezentat procesul de autentificare EAP. Autentificarea poate fi iniŃiată şi de client prin transmiterea unui pachet de tip EAP Start. Acest lucru este necesar atunci când pe un port al autentificatorului există mai mulŃi clienŃi care doresc să se autentifice. După ce suplicantul îşi trimite identitatea într-un pachet EAP Response, serverul de autentificare poate să îi trimită un pachet de tip EAP Request/Challenge (Încercare EAP), prin care se evită atacuri de tip reluare. Această metodă de autentificare este specifică pentru EAP-MD5.

Protocolul EAP prezintă următoarele avantaje:

• Protocolul EAP poate suporta multiple mecanisme de autentificare, fără a fi nevoie să fie negociat anterior un mecanism anume.

• Autentificatorii (switch-uri şi puncte de acces wireless) nu trebuie să înŃeleagă fiecare metodă de autentificare şi pot să funcŃioneze ca un agent de relay pentru un server de autentificare.

11

• Separarea autentificatorului de serverul de autentificare simplifică managementul datelor de identificare şi aplicarea politicilor.

Conceptual, implementările EAP sunt construite pe baza unui model de multiplexare, constituit din următoarele nivele componente:

[a] Nivelul inferior. Nivelul inferior este responsabil de trimiterea şi primirea cadrelor EAP dintre suplicant şi autentificator. EAP este implementat peste multe tipuri de niveluri inferioare precum PPP, medii LAN cablate IEEE 802 (IEEE-802.1X), medii fără fir IEEE 802.11, UDP (L2TP [RFC2661] şi IKEv2) şi TCP [PIC].

[b] Nivelul EAP. Nivelul EAP primeşte şi transmite pachete EAP prin intermediul nivelului inferior, implementează detecŃia pachetelor duplicate şi retransmisia, şi trimite şi primeşte mesaje EAP spre şi de la nivelele client şi autentificator EAP.

[c] Nivelele client şi autentificator EAP. Bazându-se pe câmpul Code din pachetul EAP, nivelul EAP demultiplexează pachetele EAP care vin spre nivelele client şi autentificator EAP.

[d] Nivelele metodelor EAP. Metodele EAP implementează algoritmii de autentificare şi primesc şi transmit mesaje EAP prin intermediul nivelelor client şi autentificator EAP. Deoarece fragmentarea pachetelor nu este suportată de protocolul EAP, această responsabilitate revine metodelor EAP.

Modelul de multiplexare EAP este ilustrat in Figura 3.

Client Autentificator

Metodă EAP

Tipul = X

Metodă EAP

Tipul = Y

Nivel inferiorNivel inferior

Nivel EAPNivel EAP

Nivel client EAP Nivel autentificator EAP

Metodă EAP

Tipul = X

Metodă EAP

Tipul = Y

Figura 3 – Modelul de multiplexare EAP

Câmpul Code din pachetul EAP funcŃionează similar ca un număr de protocol în IP. Nivelul EAP demultiplexează pachetele EAP primite în funcŃie de câmpul Code.

12

Pachetele EAP cu câmpul Code=1 (Request), 3 (Success), şi 4 (Failure) sunt trimise de nivelul EAP către nivelul client EAP. Pachetele EAP cu câmpul Code=2 (Response) sunt trimise spre nivelul autentificator EAP.

Câmpul Type din pachetul EAP funcŃionează similar cu un număr de port în UDP sau TCP. Nivelurile client şi autentificator EAP demultiplexează pachetele EAP primite în funcŃie de câmpul Type, şi le trimit spre metoda EAP corespunzătoare.

Când funcŃionează ca un agent de relay, un autentificator verifică câmpurile Code, Identifier şi Length. El trimite mai departe pachetele EAP primite de la client spre serverul de autentificare. Similar, pachetele primite de la serverul de autentificare şi destinate clientului, îi sunt trimise acestuia. Pachetele primite de autentificator şi care au câmpul Code=2 (Response) sunt trimise mai departe spre serverul de autentificare. Pachetele EAP primite de autentificator cu câmpul Code=1 (Request), 3 (Success), şi 4 (Failure) sunt trimise către clientul EAP. Dacă autentificatorul nu implementează local metode de autentificare EAP, câmpurile care Ńin de metoda EAP (Type, Type-Data) nu sunt examinate când se ia decizia de trimitere a pachetului EAP. Metodele de încapsulare a pachetelor EAP în protocoale precum RADIUS sau Diameter sunt descrise în specificaŃiile acestor protocoale. Modelul de trimitere a pachetelor EAP este prezentat în Figura 4.

Figura 4 – Modul de trimitere a pachetelor EAP

Formatul pachetelor EAP

Formatul general al pachetelor EAP este prezentat în continuare (Figura 5).

13

Figura 5 - Formatul general al pachetului EAP

Code – Câmpul Code are un octet lungime şi identifică tipul pachetului EAP. Valorile posibile pentru câmpul Code sunt următoarele:

1 Request 2 Response 3 Success 4 Failure

Identifier – Câmpul are un octet lungime şi este folositor la realizarea corespondenŃei dintre pachete Response şi pachete Request.

Length – Câmpul Length are doi octeŃi lungime şi indică lungimea, în octeŃi, a pachetului EAP incluzând câmpurile Code, Identifier, Length şi Data.

Data – Câmpul Data poate avea zero sau mai mulŃi octeŃi. Formatul câmpului Data este determinat de valoarea din câmpul Code.

Formatul pachetelor de tip Request şi Response este prezentat în Figura 6.

Figura 6 – Formatul pachetelor EAP Request şi Response

Câmpul Code este are valoarea 1 pentru un pachet EAP Request şi 2 pentru un pachet EAP Response. Câmpul Type are un octet lungime şi indică tipul de pachet EAP. Câmpul Type dintr-un pachet Response trebuie să corespundă cu cel din pachetul Request. Câmpul Type-Data variază în funcŃie de câmpul Type al pachetului Request şi a pachetului Response asociat. O parte din valorile pe care câmpul Type le poate lua sunt prezentate în RFC 3748:

1 Identity 2 Notification 3 Nak (Response only) 4 MD5-Challenge 5 One Time Password (OTP) 6 Generic Token Card (GTC) 254 Expanded Types 255 Experimental use

Formatul pachetelor de tip Request şi Response este prezentat în Figura 7.

14

Figura 7 – Formatul pachetelor EAP Request şi EAP Response

Câmpul Code poate lua valorile 3 pentru EAP Success şi 4 pentru EAP Failure. Câmpul Length are tot timpul valoarea 4.

Încapsularea pachetelor protocolului EAP în cadre IEEE 802 (EAPoL) este definită în standardul IEEE 802.1X. Standardul IEEE 802.1X defineşte ca adresă MAC destinaŃie generală pentru protocolul EAPoL - 01-80-C2-00-00-03. Dacă adresa MAC a clientului este cunoscută de autentificator şi vice-vers, la adresa destinaŃie pentru un cadru EAPoL se va folosi adresa individuală a entităŃii (autentificator sau client). Un cadru EAPoL în forma definită de standardul IEEE 802.2 LLC este prezentat în figura 8:

Octet

1-8

9

10

11-12

13-N

SNAP Ethernet Type

Protocol Version

Packet Type

Packet Body Length

Packet Body

Figura 8 – Formatul IEEE 802.2 LLC al cadrelor EAPoL

Ethernet Type reprezintă tipul de protocol încapsulat de cadrul Ethernet. Pentru cadrele EAPoL acest câmp are valoarea 0x888E.

Protocol Version reprezintă versiunea standardului IEEE 802.1X. Câmpul are o lungime de 1 octet. Valori posibile sunt 1 şi 2.

Packet Type reprezintă tipul de cadru EAPoL. Câmpul are o lungime de 1 octet. Există definite următoarele tipuri de cadre: a) EAP-Packet. Câmpul are valoarea 0. Cadrul conŃine un pachet EAP (Request, Response, Success, Failure). b) EAPoL-Start. Câmpul are valoarea 1. Cadrul este de tip EAPoL Start. c) EAPoL-Logoff. Câmpul are valoarea 2. Cadrul este de tip EAPoL LogOff. d) EAPoL-Key. Câmpul are valoarea 3. Cadrul este de tip EAPoL Key.

Packet Body Length are doi octeŃi lungime şi reprezintă lungimea câmpului Packet Body.

Packet Body conŃine pachetul EAP încapsulat în cadrul EAPoL.

15

Standardul IEEE 802.1X introduce conceptul de Acces Controlat la Porturi (Port Access Control). Accesul Controlat la Porturi – PAC oferă o metodă de a controla accesul neautorizat al suplicanŃilor la serviciile oferite de un sistem. Controlul accesului este realizat de autentificator prin forŃarea autentificării suplicaŃilor care se conectează la porturile controlate ale autentificatorului. În funcŃie de rezultatul procesului de autentificare, autentificatorul determină dacă suplicantul este autorizat să acceseze serviciile sale pe acel port controlat. Dacă suplicantul nu este autorizat pentru acces, autentificatorul schimbă starea portului controlat în neautorizat. În starea neautorizat accesul la port este restricŃionat pentru a preveni transferul de date dintre suplicant şi serviciile oferite de autentificator. În starea neautorizat, între suplicant şi autentificator sunt permise doar cadrele de tip EAPoL.

Conform PAC (Port Access Control), un port poate fi controlat sau necontrolat (Figura 9). Portul necontrolat (uncontrolled) permite schimbul necontrolat de date între suplicant şi alte sisteme din reŃea. Portul controlat permite suplicantului să acceseze reŃeaua doar dacă starea curentă a portului este autorizat.

Figura 9 – Stările unui port în conceptul Port Access Control

Standardul IEEE 802.1X defineşte doi parametri pentru un port controlat:

AuthControlledPortStatus – defineşte starea curentă de autorizare a portului: autorizat sau neautorizat. În Figura 9 această stare depinde de poziŃia comutatorului: deschis = neautorizat, închis = autorizat.

AuthControlledPortControl – acest parametru permite un control administrativ asupra stării de autorizare a portului. Acest parametru poate lua valorile ForceUnauthorized, Auto şi ForceAuthorized. RelaŃia dintre parametrii AuthControlledPortStatus şi AuthControlledPortControl este următoarea:

16

a) Valoarea ForceUnauthorized pentru parametrul AuthControlledPortControl forŃează autentificatorul să schimbe valoarea parametrului AuthControlledPortStatus în neautorizat. Portul controlat este neautorizat permanent.

b) Valoarea ForceAuthorized pentru parametrul AuthControlledPortControl forŃează autentificatorul să schimbe valoarea parametrului AuthControlledPortStatus în autorizat. Portul controlat este autorizat permanent.

c) Valoarea Auto pentru parametrul AuthControlledPortControl permite autentificatorului să controleze valoarea parametrului AuthControlledPortStatus în funcŃie de rezultatul autentificării prin EAP a suplicantului.

Standardul IEEE 802.1X specifică autentificatorului să identifice suplicantul după adresa MAC acestuia. Astfel, pe un port controlat cu parametrul AuthControlledPortStatus = autorizat, este permis doar traficul cu adresa MAC sursă a suplicantului care s-a autentificat prin EAP pe portul respectiv.

17

3 Implementări ale protocolului EAP

Protocolul EAP dispune de mai multe implementări practice care vor fi prezentate în continuare împreună cu avantajele şi dezavantajele acestor implementări.

3.1 EAP-MD5

Protocolul EAP-MD5 (Extensible Authentication Protocol - Message Digest 5) este un standard de bază în cadrul implementărilor EAP. EAP-MD5 se bazează pe protocolul CHAP (Challenge Handshake Authentication Protocol [RFC1994]) şi este foarte similar cu acesta. EAP-MD5 foloseşte ca elemente de identificare numele utilizatorului şi parola acestuia. Această implementare foloseşte funcŃia de dispersie (hash function) MD5 (Message Digest 5). După ce trimite numele utilizator, suplicantul primeşte de la serverul de autentificare un mesaj de tip Request MD5-Challenge (încercare) care conŃine un cuvânt de încercare. Suplicantul aplică funcŃia MD5 asupra parolei şi a cuvântului de încercare. Rezultatul va fi trimis spre server într-un mesaj Response MD5-Challenge. Serverul aplică, la rândul lui, funcŃia hash MD5 asupra parolei utilizatorului şi o compară cu valoarea primită de la suplicant în mesajul Response MD5-Challenge. Dacă cele două coincid atunci suplicantul este autorizat. În Figura 10 este prezentată succesiunea de mesaje în cadrul unei autentificări cu EAP-MD5:

Client 802.1X Autentificator - Switch Server de autentificare

AAA - RADIUS

EAP Start

(a) EAP Request Identity

(b) EAP Response

Identity

(d) EAP Response

MD5 Challenge

(c) EAP Request

MD5 Challenge

(e) EAP Success/Fail

Figura 10 – Autentificarea cu EAP-MD5

(a) Autentificatorul trimite spre client un mesaj EAP Request Identity, prin care solicită suplicantului să îi trimită numele utilizator.

(b) Suplicantul răspunde cu un mesaj EAP Response Identity în care trimite numele utilizator. Mesajul este trimis spre serverul de autentificare.

18

(c) Serverul de autentificare trimite suplicantului un mesaj de tip EAP Request MD5 Challenge (încercare) care conŃine cuvântul de încercare.

(d) Suplicantul trimite un mesaj Response MD5-Challenge în care include rezultatul funcŃiei MD5 asupra parolei şi a cuvântului de încercare concatenate.

(e) Serverul de autentificare decide dacă răspunsul este corect şi răspunde cu un mesaj de tip EAP Success daca suplicantul este autentificat sau EAP Fail daca nu a fost autentificat.

EAP-MD5 nu foloseşte certificate PKI pentru validarea clientului sau asigurarea unei criptări puternice în vederea protejării mesajelor de autentificare între client şi serverul de autentificare. EAP-MD5 presupune doar autentificarea clientului nu şi a serverului de autentificare. Deoarece nu oferă autentificare mutuală protocolul de autentificare EAP-MD5 este susceptibil la atacuri de tipul deturnarea sesiunii şi man-in-the-middle („om interpus”). De asemenea EAP-MD5 este vulnerabil la atacuri de tip dicŃionar, deoarece nu oferă confidenŃialitatea datelor transmise.

EAP-MD5 îşi execută operaŃiile foarte repede, şi este foarte uşor de implementat şi configurat. EAP-MD5 este adecvat, în special în cazul schimburilor de mesaje în reŃele cu cablu în care clientul EAP este conectat în mod direct la autentificator, iar şansele ascultării şi interceptării mesajelor sunt scăzute. Pentru autentificarea 802.1X în reŃele fără fir, se folosesc protocoale EAP mai puternice. Protocolul EAP-MD5 nu a mai fost implementat de compania Microsoft pentru adaptoarele fără fir din motive de securitate scăzută.

3.2 EAP-OTP

Protocolul EAP-OTP (Extensible Authentication Protocol – One-Time Password) se bazează pe sistemul de autentificare OTP (One-Time Password), descris în RFC 2289. EAP-OTP oferă protecŃie împotriva atacurilor de tip „reluare”, implementând un sistem de folosire a unei parole unice la fiecare autentificare. Protocolul EAP-MD5 este vulnerabil la atacuri de tip „reluare” deoarece foloseşte aceeaşi parolă pentru fiecare sesiune de autentificare. Pachetele trimise pe reŃea pot fi capturate şi retransmise mai târziu pentru a relua o sesiune. EAP-OTP previne un astfel de atac. OTP presupune ca serverul de autentificare şi clientul să deŃină o cheie secretă comună. Serverul trimite clientului o valoare de încercare (challenge) împreună cu alŃi parametri, care funcŃionează ca un punct de start pentru o funcŃie de dispersie. Clientul aplică asupra cheii secrete şi a valorii de încercare funcŃia de dispersie de un anumit număr de ori, precizat în parametrii primiŃi odată cu valoarea de încercare. Astfel se obŃine o parolă care este folosită o singură dată prevenind atacuri de tip „reluare”.

EAP-OTP nu foloseşte certificate PKI pentru validarea clientului sau asigurarea unei criptări puternice în vederea protejării mesajelor de autentificare între client şi serverul de autentificare. EAP-OTP presupune doar autentificarea clientului nu şi a serverului de autentificare.

19

3.3 EAP-GTC

Protocolul EAP-GTC (Extensible Authentication Protocol – Generic Token Card) se bazează pe folosirea unui token digital. Clientul trimite informaŃia citită de pe token la serverul de autentificare, ca răspuns la un mesaj Request care conŃine o valoare de încercare. EAP-GTC nu protejează informaŃiile trimise către server. Toate implementările EAP-GTC trebuie să ruleze printr-un tunel protejat şi să implementeze şi autentificarea serverului. O astfel de implementare este PEAPv1/EAP-GTC realizată de compania Cisco.

3.4 PEAP

PEAP (Protected EAP) este un standard implementat de companiile Microsoft, Cisco şi RSA Security ca o alternativă pentru EAP-TTLS. PEAPv0/ EAP-MSCHAPv2 este termenul tehnic pentru PEAP. În spatele PEAP există multe implementări, cea mai importantă fiind PEAPv0/EAP-MSCHAPv2. Această versiune de PEAP este cea mai folosită şi suportată implementare de EAP. Există implementări pentru clienŃi şi servere produse de Microsoft, Cisco, Apple şi Linux. PEAPv0/EAP-MSCHAPv2 are suport nativ în sisteme de operare precum MacOS X 10.3, Windows 2000 SP4 sau Windows XP. Servere RADIUS precum IAS din Windows 2003 server, au suport nativ pentru PEAPv0/EAP-MSCHAPv2.

PEAP implementează o metodă de a transmite securizat informaŃiile de autentificare, incluzând şi parole, prin reŃele cablate sau fără fir. PEAP se bazează pe o infrastructură de chei publice PKI. PEAP utilizează certificatul serverului pentru a autentifica serverul de autentificare. PEAP creează apoi un tunel SSL/TLS criptat între client şi server. Astfel informaŃiile de autentificare ale clientului sunt trimise securizat prin acest tunel, asigurând o puternică confidenŃialitate a datelor transmise. Clientul PEAP se autentifică direct la serverul de autentificare, iar autentificatorul se comportă ca un dispozitiv de trecere care nu are nevoie să înŃeleagă protocoalele de autentificare EAP specifice. Spre deosebire de EAP-TTLS, PEAP nu asigură, în mod implicit, autentificare pe bază de nume utilizator şi parolă în funcŃie de o bază de date a utilizatorilor, precum LDAP. Producătorii vin în întâmpinarea acestei nevoi prin crearea de funcŃionalităŃi care să permită autentificarea prin nume utilizator şi parolă. PEAPv0/EAP-MSCHAPv2 permite folosirea doar a protocolului MSCHAPv2 în cadrul autentificării tunelate de TLS.

PEAP este răspândit în foarte multe produse şi asigură o securitate foarte bună. Este similar cu EAP-TTLS, dar necesită doar certificatul serverului pentru a crea tunelul criptat SSL/TLS. Principalele avantaje ale PEAP sunt prezentate în continuare:

• protejarea informaŃiilor de autentificare ale utilizatorilor

• securizarea negocierii EAP

• standardizarea schimburilor de chei

• suport pentru fragmentare şi reasamblare;

• suport pentru reconectări rapide.

20

PEAP se potriveşte cel mai bine reŃelelor care necesită autentificare puternică, fără utilizarea unor certificate mutuale.

În Figura 11 este prezentat schimbul de mesaje în cadrul unei autentificări cu PEAP:

Figura 11 – Autentificarea PEAP

IniŃial, în paşii (a), (b) şi (c), autentificarea este similară cu orice altă implementare de EAP. În pasul (d) clientul trimite TLS Client_hello spre server pentru a iniŃia stabilirea tunelului criptat TLS. Paşii (e) - (h) stabilesc tunelul TLS şi clientul autentifică serverul folosind certificatul primit de la acesta. Începând cu pasul (i), tunelul

21

securizat TLS este stabilit, şi informaŃiile de autentificare ale clientului sunt trimise criptat spre serverul de autentificare. Dacă autentificarea are succes, serverul trimite un mesaj EAP Success necriptat iar tunelul TLS este închis.

O altă implementare de PEAP, este PEAPv1/EAP-GTC, creată de Cisco ca o alternativă la PEAPv0/EAP-MSCHAPv2. Implementarea Cisco permite folosirea de alte protocoale de autentificare tunelate de TLS, în afară de protocolul MSCHAPv2 care este proprietar Microsoft. PEAPv0 limitează folosirea PEAP doar cu baze de date utilizator care suportă protocolul MS-CHAP Version 2, precum domenii Windows NT şi Active Directory. PEAPv1 suportă autentificare cu OTP (precum RSA Security) şi alte baze de date utilizator (LDAP sau Novell NDS). PEAPv1 are şi posibilitatea de a ascunde numele utilizatorului până la stabilirea tunelului criptat TLS. Chiar dacă Microsoft (împreună cu RSA şi Cisco) a participat la dezvoltarea standardului PEAP, Microsoft nu a oferit suport pentru PEAPv1. De aceea, PEAPv1 este foarte rar folosit.

3.5 EAP-TLS

Protocolul extins de autentificare cu securitate la nivel transport (EAP-TLS – Extensible Authentication Protocol – Transport Layer Security), descris în RFC 2716, este cel mai sigur protocol de autentificare bazat pe EAP pentru reŃele LAN cablate sau fără fir. EAP-TLS asigură o securitate puternică, solicitând ca atât clientul cât şi serverul să se autentifice reciproc, folosind certificate PKI. EAP-TLS asigură autentificare mutuală între client şi serverul de autentificare şi este foarte sigur. Mesajele EAP sunt protejate de ascultare de un tunel TLS între client şi serverul de autentificare. Cel mai mare dezavantaj al EAP-TLS este necesitatea existenŃei certificatului PKI al clientului. Chiar dacă necesitatea unui certificat pentru client nu este agreată în general, este ceea ce oferă protocolului EAP-TLS o puternică securitate în autentificare. Aceasta face ca implementarea, întreŃinerea şi scalabilitatea să fie mult mai complexe. O parolă compromisă nu este de ajuns unui hacker pentru a pătrunde în reŃele protejate de EAP-TLS deoarece atacatorul are nevoie şi de cheia privată a clientului. Cea mai mare securitate se obŃine când certificatul şi cheia privată a clientului sunt stocate pe un smartcard. Cheia privată nu poate fi furată de pe un smartcard, decât dacă smartcard-ul respectiv este furat. Un smartcard furat este uşor de observat, în timp ce furtul unei parole nu poate fi observat. EAP-TLS este ideal în cazul firmelor cu infrastructură pentru certificate PKI. Aceasta este o necesitate în firme mari, dar devine nerealistă în firme mai mici. O autentificare prin numele utilizator şi parolă este mult mai practică, pentru multe dezvoltări publice. Schemele de autentificare fără fir 802.1x au, în mod normal, suport pentru EAP-TLS pentru a proteja schimbul de mesaje EAP. Spre deosebire de reŃelele cu fir, reŃelele fără fir trimit pachetele în mediu deschis, lucru care uşurează capturarea şi interceptarea pachetelor neprotejate. În cadrul implementărilor EAP-TLS pe reŃele fără fir, după ce clientul şi serverul se autentifică reciproc, o cheie de sesiune secretă va fi partajată între cele două entităŃi. Folosind această cheie de sesiune secretă, clientul şi serverul de autentificare stabilesc o cheie de criptare care va fi folosită pentru criptarea pachetelor în reŃeaua fără fir.

În Figura 12 este prezentat schimbul de mesaje în cadrul unei autentificări cu EAP-TLS:

22

Figura 12 – Autentificarea EAP-TLS

Protocolul EAP-TLS este sensibil la atacurile de tip “om-interpus” dacă nu este implementat corespunzător. Implementat corect, EAP-TLS rezistă la astfel de atacuri. EAP-TLS furnizează autentificare mutuală explicită între AS şi solicitant. Acest lucru este adevărat dacă ambele părŃi pot valida certificatul celeilalte părŃi. Aceasta se realizează având ambele certificate emise de aceeaşi autoritate de certificare (Certificate Authority). Chiar dacă este destul de rar implementat în practică, EAP-TLS este considerat cel mai sigur standard EAP existent şi este suportat de toŃi producătorii de sisteme de operare şi echipamente. EAP-TLS dispune de suport nativ în Mac OS X 10.3, Windows 2000 SP4, Windows XP sau Windows Vista.

3.6 EAP-TTLS

Propus de către companiile Funk Software şi Certicom, EAP-TTLS(EAP - Tunneled TLS) este predecesorul PEAP şi oferă beneficiile unei criptări puternice, fără complexitatea unor certificate mutuale, atât la client cât şi pe serverul de autentificare. Precum TLS, EAP-TTLS oferă suport pentru autentificarea mutuală, dar cere ca, printr-un schimb de certificate, să fie validat faŃă de client doar serverul de autentificare. EAP-

23

TTLS permite clientului să se autentifice faŃă de serverul de autentificare folosind numele utilizator şi parola. EAP-TTLS simplifică implementarea şi întreŃinerea, păstrând însă un nivel ridicat pentru securitate şi autentificare. Pentru a proteja mesajele EAP poate fi folosit un tunel TLS, iar pentru utilizatorii existenŃi servicii acreditive precum: Active Directory, RADIUS şi LDAP. Ele pot fi reutilizate pentru autentificare 802.1x. EAP-TTLS asigură şi compatibilitatea în sens invers cu alte protocoale de autentificare precum PAP, CHAP, MS-CHAP şi MS-CHAP-V2. EAP-TTLS nu este considerat de netrecut şi poate fi păcălit să transmită acreditive de identitate dacă nu se folosesc tunele TLS. EAP-TTLS este ideal pentru cazurile care necesită autentificare puternică fără a se folosi certificate mutuale. Schemele de autentificare 802.1x fără fir suportă în mod obişnuit EAP-TTLS. În Figura 13 este prezentat schimbul de mesaje în cadrul unei autentificări cu EAP-TTLS; protocolul de autentificare tunelat este MD5-Challenge; mesajele protejate de tunelul de autentificare sunt prezentate colorat diferit:

Figura 13 – Autentificarea EAP-TTLS

24

3.7 LEAP

Protocolul LEAP (Lightweight EAP) a fost creat de compania Cisco în noiembrie 2000 şi a fost destinat reŃelelor fără fir. LEAP a fost dezvoltat înaintea apariŃiei standardului IEEE 802.11i pentru securitatea în reŃele fără fir. LEAP este o variantă a EAP care necesită autentificare reciprocă între client şi autentificator. Clientul se autentifică faŃă de autentificator, iar mai apoi autentificatorul faŃă de client. Dacă ambii se autentifică cu succes, se acordă o conexiune în reŃea. Spre deosebire de EAP-TLS, LEAP se bazează pe scheme cu nume utilizator şi parolă şi nu certificate PKI, simplificând implementarea şi întreŃinerea.

Marele dezavantaj al protocolului LEAP este că foloseşte o versiune modificată a protocolului MS-CHAP. Această versiune nu protejează puternic informaŃiile de autentificare şi de aceea LEAP este uşor de compromis. În 2004 a apărut o aplicaŃie numită ASLEAP care beneficia de această vulnerabilitate a protocolului LEAP pentru a afla datele de autentificare ale utilizatorilor. Măsura luată de compania Cisco a fost să recomande utilizarea LEAP doar cu parole suficient de complexe, sau folosirea unor metode de autentificare mai puternice precum PEAP sau EAP-TLS. Ulterior Cisco a dezvoltat alte metode de autentificare precum EAP-FAST.

3.8 EAP-FAST

EAP-FAST (Flexible Authentication via Secure Tunneling) a fost creat şi implementat de compania Cisco pentru a înlocui protocolul LEAP. Protocolul a fost proiectat să elimine vulnerabilităŃile protocolului LEAP, dar în acelaşi timp să păstreze uşurinŃa de implementare a acestuia. Folosirea de certificate este opŃională în EAP-FAST. EAP-FAST foloseşte un PAC (Protected Access Credential) pentru a stabili un tunel TLS prin care sunt verificate datele de autentificare ale clientului. EAP-FAST. PAC reprezintă o cheie secretă comună între client şi serverul de autentificare. EAP-FAST funcŃionează în trei etape. Prima etapă constă în distribuirea de chei secrete PAC. Acest lucru se poate face manual sau dinamic. A doua etapă o reprezintă crearea tunelului între client şi serverul de autentificare folosind PAC. În ultima etapă datele de autentificare ale clientului sunt transmise prin tunelul TLS spre serverul de autentificare.

EAP-FAST este vulnerabil la distribuirea automată a cheilor secrete partajate PAC. Un atacator poate să intercepteze această cheie PAC şi o poate folosi pentru a compromite datele de autentificare ale clientului. Această vulnerabilitate poate fi evitată prin distribuirea manuală a cheilor PAC sau prin folosirea de certificate în etapa de distribuire automată a cheilor PAC.

3.9 Alte implementări EAP

EAP-PSK (EAP Pre-Shared Key), definit în RFC 4764, este o implementare EAP care suportă autentificare mutuală şi generare de chei de sesiune prin folosirea unei chei partajate (Pre-Shared Key). Autentificarea se încheie după numai patru mesaje schimbate între client şi serverul de autentificare. EAP-PSK oferă un canal de comunicaŃie protejat prin care clientul să aibă acces la reŃea, după ce autentificarea este încheiată cu succes.

25

EAP-PSK este folosit pentru reŃele fără-fir. EAP-PSK este uşor de implementat deoarece nu foloseşte o infrastructură de chei publice.

EAP-IKEv2 este o implementare EAP bazată pe protocolul IKEv2 (Internet Key Exchange Protocol v2). EAP-IKEv2 oferă autentificare mutuală şi suport pentru stabilirea unei chei de sesiune între un client şi serverul de autentificare. Protocolul suportă tehnici de autentificare bazate pe următoarele tipuri de date de autentificare: perechi de chei asimetrice, parole şi chei simetrice. Există posibilitatea folosirii de tipuri de date de autentificare diferite, pentru fiecare direcŃie de comunicaŃie. Spre exemplu, serverul de autentificare se autentifică cu perechea de chei asimetrice iar clientul cu o cheie simetrică.

EAP-SIM (EAP for GSM Subscriber Identity) este un protocol de autentificare şi distribuŃie de chei de sesiune, folosit în cadrul GSM. EAP-SIM este folosit pentru autentificare în reŃele mobile de generaŃia a doua. EAP-SIM se bazează pe un mecanism de tipul încercare-răspuns. Protocolul nu oferă autentificare mutuală. Protocolul include şi suport pentru anonimitate sau proceduri de reautentificare rapide. EAP-SIM este descris în RFC 4186.

EAP-AKA (EAP for UMTS Authentication and Key Agreement) este un protocol de autentificare şi distribuŃie de chei de sesiune, folosit în cadrul reŃelelor mobile de generaŃia a treia - UMTS (Universal Mobile Telecommunications System). EAP-AKA se bazează pe mecanisme de tipul încercare-răspuns şi criptografie simetrică. Protocolul EAP-AKA este rulat într-un SIM UMTS. Protocolul este descris în RFC 4187.

26

4 AplicaŃie practică - AplicaŃie de management al securităŃii EAPoL pentru un switch de reŃea

Ca aplicaŃie practică pentru această lucrare a fost realizată o aplicaŃie de management securizat al configuraŃiilor de autentificare cu EAPoL pentru switch-uri de reŃea. În ultimele două decenii domeniul telecomunicaŃiilor s-a dezvoltat exponenŃial, expansiunea Internetului fiind un catalizator important. Calculatoarele, telefoanele mobile, PDA-urile sunt echipamente întâlnite foarte des şi toate pot fi conectate la Internet. Toate comunicaŃiile de date, voce şi video sunt susŃinute de reŃeaua Internet care la rândul ei se bazează pe echipamentele de reŃea. Necesitatea de echipamente de reŃea cu capabilităŃi de Quality of Service(QoS), securitate şi remote management a dus la dezvoltarea domeniului de networking.

Echipamentele de reŃea cu remote management sunt întâlnite în orice reŃea care are nevoie de calitate pentru serviciile oferite. O aplicaŃie software prin care se realizează managementul tuturor echipamentelor dintr-o reŃea este foarte utilă deoarece economiseşte mult timp pentru un administrator de reŃea. AplicaŃia prezentată în această lucrare realizează doar managementul pentru configuraŃiile de autentificare EAPoL, dar poate fi extinsă foarte uşor pentru a fi folosită la managementul tuturor configuraŃiilor de pe un echipament de reŃea.

În continuare vor fi prezentate funcŃionalităŃile, arhitectura şi modalităŃile de implementare a modulelor componente ale aplicaŃiei, dar şi protocoalele de securitate folosite.

4.1 FuncŃionalităŃile aplicaŃiei

AplicaŃia prezentată are ca funcŃionalitate principală managementul securizat al configuraŃiilor de autentificare cu EAPoL pentru switch-uri de reŃea. AplicaŃia este realizată pe platformă web în limbajul de scripting PHP. Pentru a facilita accesul online, aplicaŃia a fost proiectată să fie independentă de browser-ul web care este folosit.

Din punct de vedere al securităŃii aplicaŃia implementează doar protocoale de comunicaŃie securizate. ComunicaŃia dintre browser-ul web al utilizatorului aplicaŃiei şi serverul web se realizează prin protocolul HTTPS securizat cu ajutorul SSL. Autentificarea utilizatorului aplicaŃiei se face prin interogarea unui server RADIUS. Serverul web comunică cu switch-ul de reŃea folosind protocolul SNMPv3 care oferă autentificare şi confidenŃialitatea datelor. Astfel, se poate spune că aplicaŃia oferă posibilitatea managementului de la distanŃă a echipamentelor de reŃea, în condiŃii de securitate.

4.1.1 Autentificarea utilizatorilor

Pentru restricŃionarea accesului la aplicaŃie al utilizatorilor neautorizaŃi, a fost implementat un sistem de autentificare bazat pe protocolul RADIUS (Remote Authentication Dial In User Service) care permite accesul utilizatorilor înregistraŃi pe

27

serverul de autentificare RADIUS. Utilizatorii sunt creaŃi pe serverul RADIUS, care dispune de o bază de date cu utilizatori (spre exemplu Active Directory).

4.1.2 Vizualizarea configuraŃiilor curente

După autentificare, utilizatorul aplicaŃiei introduce adresa IP şi datele de autentificare SNMPv3 pentru un anumit echipament de reŃea. Utilizatorul poate să vizualizeze informaŃii generale despre echipament (numele echipamentului, descrierea echipamentului, locaŃia echipamentului sau timpul de funcŃionare), starea tuturor porturilor (conectat/neconectat), configuraŃiile pentru serverul de autentificare (adresă IP, cheie secretă partajată) şi configuraŃiile generale pentru protocolul EAPoL. De asemenea, pot fi vizualizate şi configuraŃii EAPoL detaliate pentru fiecare port al echipamentului.

4.1.3 Modificarea configuraŃiilor

Utilizatorul poate să modifice configuraŃiile pentru serverul de autentificare (adresă IP, cheie secretă partajată) şi configuraŃiile generale pentru protocolul EAPoL. De asemenea, pot fi modificate şi configuraŃiile EAPoL detaliate pentru fiecare port al echipamentului.

4.2 Arhitectura aplica Ńiei

AplicaŃia are un caracter modular, ca orice aplicaŃie web. AplicaŃia are patru componente principale şi anume:

• Modulul login.php are scopul de a prelua datele de autentificare ale utilizatorului aplicaŃiei şi de a interoga serverul RADIUS pentru a autentifica utilizatorul. Dacă autentificarea are succes sunt iniŃializate anumite variabile de sesiune care vor fi folosite pentru a verifica autentificarea în fiecare modul al aplicaŃiei.

• Modulul main.php afişează pagina principală a aplicaŃiei, unde utilizatorul poate introduce o adresă IP a unui echipament şi datele de autentificare pentru protocolul SNMPv3.

• Modulul device.php preia, folosind SNMPv3, informaŃiile generale despre switch-ul de reŃea, configuraŃiile globale de EAPoL şi configuraŃiile pentru serverul de autentificare. Modulul va afişa o reprezentare grafică a switch-ului pentru fiecare port existând opŃiunea de a face setări specifice.

• Modulul port.php preia, folosind SNMPv3, configuraŃiile EAPoL ale unui port selectat in pagina device.php. Modulele device.php şi port.php oferă şi posibilitatea schimbării setărilor de EAPoL pe un switch de reŃea.

În continuare este prezentată schema arhitecturii aplicaŃiei:

28

log

ou

t

Figura 14 – Arhitectura aplicaŃiei

4.3 Implementarea modulelor componente

4.3.1 Modulul de autentificare – login.php

Pentru autentificarea utilizatorilor aplicaŃiei s-a folosit interogarea unui server RADIUS. Datele de autentificare ale utilizatorului sunt preluate folosind un formular HTML afişat de pagina index.php care este oferită automat de serverul web la accesarea URL-ului aplicaŃiei. Formularul este simplu, preia datele de autentificare (nume utilizator şi parolă) şi le trimite, folosind variabila globală $_POST, spre modulul login.php care interoghează serverul RADIUS. Formularul afişat de index.php poate să afişeze şi mesaje de eroare (precum “server RADIUS inaccesibil” sau “username / parolă incorecte”). Aceste mesaje de eroare sunt preluate de scriptul index.php folosind variabila globală $_GET. Formularul de login este prezentat în continuare:

Figura 15 – Formularul de login

29

Modulul login.php primeşte prin intermediul variabilei globale $_POST datele de autentificare ale utilizatorului, trimise de index.php. Folosind aceste date se construieşte un pachet RADIUS Access Request folosind procedurile oferite de extensia radius-php. După ce pachetul este trimis, se aşteaptă un răspuns de la serverul RADIUS. Implementarea suportă atât autentificare cu PAP cât şi cu CHAP. Există trei răspunsuri pe care pot fi primite de la serverul RADIUS:

• Dacă se primeşte un mesaj RADIUS Access Accept înseamnă ca utilizatorul este a fost autentificat cu PAP şi urmează ca scriptul să iniŃializeze sesiunea de lucru.

• Dacă se primeşte un mesaj RADIUS Access Reject înseamnă că utilizatorul nu a fost autentificat cu succes, sesiunea nu este iniŃializată şi scriptul redirecŃionează browser-ul spre pagina de login, afişând şi un mesaj de eroare corespunzător.

• Dacă se primeşte un mesaj RADIUS Access Challenge înseamnă că autentificarea este realizată folosind CHAP. Folosind valoarea de încercare primită de la serverul RADIUS se va crea un nou pachet de tipul Access Request care va fi trimis ca răspuns spre serverul RADIUS. Serverul va răspunde cu un pachet de tipul Access Accept sau Access Reject.

Dacă nu se primeşte nici un răspuns de la serverul RADIUS într-un interval de timp prestabilit, sesiunea nu este iniŃializată şi scriptul redirecŃionează browser-ul spre pagina de login, afişând şi un mesaj de eroare corespunzător.

După ce utilizatorul este autentificat de serverul RADIUS, scriptul iniŃiază două variabile de sesiune specifice PHP, care vor fi folosite la verificarea autentificării în fiecare modul (main.php, device.php sau port.php). Prima variabilă folosită este $_SESSION[‘key_admin’]. În această variabilă este stocată cheia unică de sesiune. A doua variabilă este $_SESSION[‘timeout’]. În această variabilă este stocată ora ultimei accesări autorizate a unei pagini din aplicaŃie. Variabilele de sesiune PHP sunt folosite pentru a putea refolosi informaŃii de la o pagină la alta. Fiecare sesiune a unui utilizator este unică şi are atribuit un identificator unic care poate fi aflat folosind funcŃia session_id(). Pentru a beneficia de variabilele de sesiune, trebuie iniŃializată o sesiune folosind funcŃia session_start(). Pentru a distruge toate variabilele dintr-o sesiune se foloseşte funcŃia session_destroy(). Această funcŃie este folosită la ieşirea din aplicaŃie. Aceste variabile de sesiune nu oferă un grad de securitate mare, dar pot fi folosite în siguranŃă dacă datele transmise între browser-ul utilizatorului şi serverul web sunt criptate cu SSL sau TLS.

În fiecare pagină a aplicaŃiei, utilizatorul este verificat dacă sesiunea sa este autentificată. Pentru aceasta se compară identificatorul sesiunii iniŃiale, care a fost autentificată, $_SESSION[‘key_admin’], cu rezultatul funcŃiei session_id(). Dacă aceste două valori sunt identice se consideră că este aceeaşi sesiune. Pentru a adăuga un nivel sporit de securitate, este verificat şi timpul care s-a scurs de la ultima accesare a unei pagini a aplicaŃiei în cadrul acestei sesiuni. Dacă acest interval de timp este mai mare de 5 minute, sesiunea este considerată expirată şi utilizatorul este redirecŃionat către pagina index.php. Acest lucru este realizat scăzând din timpul curent, dat de funcŃia time(), valoarea variabilei de sesiune $_SESSION[‘timeout’]. Dacă valoarea obŃinută este mai

30

mică de 300 secunde şi cheia de sesiune este identică cu cea salvată, utilizatorul are acces la pagina aplicaŃiei.

4.3.2 Modulul main.php

Utilizatorul aplicaŃiei este direcŃionat către pagina main.php după ce se autentifică cu succes. Datele de autentificare pentru echipamentul care se doreşte a fi configurat sunt preluate folosind un formular HTML.

Figura 16 – Formular autentificare cu SNMPv3

Adresa IP a echipamentului de reŃea este trimisă spre modulul device.php folosind o variabilă globală $_GET. Datele de autentificare SNMPv3 sunt menŃinute în variabile de sesiune PHP. Astfel încât ele pot fi accesate şi de alte module din aplicaŃie precum port.php sau setting.php. Datele introduse în formular sunt trimise către scriptul setting.php care se ocupă cu stocarea datelor de autentificare in variabile de sesiune PHP şi redirecŃionarea către modulul device.php. Verificarea validităŃii datelor din formular poate fi realizată cu ajutorul unor scripturi JavaScript. Se poate verifica dacă adresa IP este validă sau dacă nivelul de securitate SNMPv3 selectat corespunde cu datele introduse.

4.3.3 Modulul device.php

Acest modul afişează o descriere globală a switch-ului de reŃea, fiind prezentate configuraŃiile globale de EAPoL şi configuraŃiile pentru serverul de autentificare RADIUS. Modulul afişează şi o reprezentare grafică a switch-ului, care prezintă toate porturile switch-ului, fiecare colorat în funcŃie de starea portului (link up / link down). Fiecare port reprezintă o referinŃă HTML prin care poate fi accesată pagina port.php unde pot fi vizualizate sau modificate configuraŃiile de EAPoL specifice portului.

Modulul afişează informaŃii specifice switch-ului de reŃea precum SystemDescription, SystemUptime, SystemLocation. Aceste informaŃii sunt utile la identificarea echipamentului şi sunt menŃinute de echipament în arborele de informaŃii MIB, accesibil prin SNMP. Datele despre serverul de autentificare RADIUS includ adresa IP a acestuia, portul UDP pe care ascultă mesaje şi cheia secretă partajată de

31

switch şi serverul RADIUS. Pentru EAPoL există o singură configuraŃie globală pentru echipament: activat sau dezactivat. Pagina device.php este prezentată în Figura 17:

Figura 17 – Pagina afişată de modulul device.php

Datele trimise de formularul din pagina device.php sunt preluate din variabila globală $_POST de către scriptul setting.php, care, folosind SNMPv3, schimbă configuraŃiile EAPoL pe switch. Dacă nu apar erori de comunicaŃie cu switch-ul, utilizatorul este redirecŃionat către pagina device.php unde va putea vizualiza datele de configuraŃie schimbate.

4.3.4 Modulul port.php

Acest modul oferă posibilitatea vizualizării şi modificării configuraŃiilor de EAPoL specifice fiecărui port al switch-ului de reŃea. Modulul afişează identificatorul portului (numărul) şi starea acestuia (link up / link down). Acest modul oferă posibilitatea vizualizării şi/sau modificării următoarelor configuraŃii EAPoL:

• Controlul administrativ al stării de autorizare a portului (AuthControlledPortControl) – poate lua valorile ForceAuthorized, ForceUnauthorized sau Auto. OID-ul pentru această configuraŃie este dot1xAuthAuthControlledPortControl = 1.0.8802.1.1.1.1.2.1.1.6.

32

• Starea curentă de autorizare a portului (AuthControlledPortStatus): autorizat sau neautorizat. Această stare a portului poate fi doar vizualizată. OID-ul pentru această stare este dot1xAuthAuthControlledPortStatus = 1.0.8802.1.1.1.1.2.1.1.5.

• Controlul administrativ al direcŃiei traficului care este blocat atunci când portul este în starea Unauthorized. Valori posibile sunt In & Out sau In. OID-ul pentru această configuraŃie este dot1xAuthAdminControlledDirections = 1.0.8802.1.1.1.1.2.1.1.3.

• Controlul reautentificării pentru port. Valori posibile sunt Enabled sau Disabled. OID-ul pentru această configuraŃie este dot1xAuthReAuthEnabled = 1.0.8802.1.1.1.1.2.1.1.13.

• Perioada de reautentificare pentru port. Această valoare este în intervalul 1 - 604800 secunde. OID-ul pentru această configuraŃie este dot1xAuthReAuthPeriod = 1.0.8802.1.1.1.1.2.1.1.12.

• Alte configuraŃii sunt Port Initialize şi Port Reauthenticate now, care permit reiniŃierea maşinii de stări EAPoL pentru port şi, respectiv, reautentificarea clientului conectat la port.

Pagina port.php este prezentată în Figura 18:

Figura 18 – Pagina afişată de modulul port.php

Datele trimise de formularul din pagina port.php sunt preluate din variabila globală $_POST de către scriptul setting.php, care, folosind SNMPv3, schimbă configuraŃiile EAPoL pentru portul selectat. Dacă nu apar erori de comunicaŃie cu switch-ul, utilizatorul este redirecŃionat către pagina port.php unde va putea vizualiza datele de configuraŃie schimbate.

33

4.4 Protocoalele de securitate implementate

4.4.1 Protocolul SNMPv3

Protocolul SNMP (The Simple Network Management Protocol) face parte din stiva de protocoale TCP/IP definită de IETF. SNMP este folosit în sisteme de management al reŃelelor (NMS – Network Management System), pentru a monitoriza echipamentele de reŃea. SNMP poate să preia sau să modifice datele de pe sistemele monitorizate. EntităŃile care participă în schimbul de mesaje SNMP sunt sistemele de management al reŃelelor (NMS – Network Management System) şi agenŃii SNMP de pe echipamente. Un agent SNMP este o componentă software care rulează pe un echipament monitorizat şi se ocupă de preluarea informaŃiilor din sistem şi de schimbul de mesaje SNMP. Fiecare sistem într-o reŃea, fie el switch, router, server, imprimantă de reŃea, menŃine o bază de date cu informaŃii dinamice ce reflectă caracteristici şi resurse ale sistemului în cauză. Baza de date se numeşte Management Information Base. Intrările din MIB se numesc obiecte. MIB-ul apare sub forma unui arbore, o ierarhie de obiecte, în care nivelul de top aparŃine diverselor organizaŃii de standardizare, iar nivelele inferioare sunt create de alte organizaŃii şi de producători, care adaugă obiecte specifice echipamentelor lor. ColecŃiile de obiecte sunt referite ca fiind MIB-uri. Nu toate obiectele din MIB-uri sunt accesabile prin SNMP. Fiecare obiect are un ObjectID, o valoare, un tip de dată pentru acea valoare care poate fi de tip simplu – integer sau string sau de tip complex – tabel, şi o metodă de acces. Metoda de acces poate fi read-only (doar citire) sau read-write (citire-scriere), cele mai multe obiecte fiind read-only. Datele de tip tabel sunt necesare mai ales pe switch-uri, routere, pentru obiecte care pot avea mai mult de o valoare, de exemplu tabela de rutare, tabela ARP, obiectul ifOperStatus (câte o valoare pentru fiecare interfaŃă), etc. Valorile multiple ale unui obiect se numesc instanŃe ale acelui obiect şi trebuie identificate atunci când vrem să accesăm obiectul – fiecare instanŃă are un index, de exemplu pentru ifOperStatus este identificatorul portului, care se adaugă la sfârşitul OID-ului sub forma „.index” . Dacă obiectul poate returna o singură valoare, va avea .0 la sfârşitul OID-ului.

SNMPv3 este ultimul standard publicat din categoria SNMP. SNMPv3 aduce multe îmbunătăŃiri faŃă de versiunile anterioare SNMPv1 si SNMPv2. SNMPv3 defineşte mecanisme de securitate bune, Ńinând cont că versiunile anterioare dispuneau de un sistem rudimentar de autentificare. SNMPv3 nu foloseşte termenii de agent şi sistem de management, ci de entităŃi SNMPv3, fiecare entitate având un Engine SNMP şi un modul software de funcŃii ce iniŃiază sau răspund la cereri SNMP. Engine-ul furnizează securitatea, controlul de acces, procesarea mesajelor. Fiecare entitate are un identificator EngineID.

Pentru a asigura autentificarea şi confidenŃialitatea datelor, SNMPv3 foloseşte modelul de securitate USM (User-based Security Model) descris în RFC 3414. USM se bazează pe criptografia simetrică şi pe funcŃii de dispersie. USM introduce trei nivele de securitate pentru SNMPv3:

• noAuthNoPriv – acest nivel nu oferă autentificarea utilizatorilor şi nici confidenŃialitatea datelor. Este echivalentul securităŃii oferite de SNMPv1 şi v2.

34

• authNoPriv – acest nivel oferă doar autentificare, fără criptare.

• authPriv – acest nivel de securitate oferă atât autentificare cât şi confidenŃialitatea datelor prin criptarea mesajelor.

Utilizatorii configuraŃi pe echipamentul de reŃea sunt încadraŃi într-unul din aceste trei nivele de securitate.

Pentru autentificare, fiecărui utilizator îi este atribuită o parolă de autentificare, cunoscută de utilizatorul de pe sistemul de management al reŃelei cât si de engine-ul SNMP de pe echipament. Mecanismul de autentificare folosit este HMAC (keyed-Hash Message Authentication Code). Folosind o funcŃie de dispersie precum MD5 sau SHA, se calculează un hash pe tot pachetul SNMP, incluzând şi parola de autentificare. Acest cod hash este inclus în pachetul SNMPv3 şi este recalculat de engine-ul SNMP destinaŃie, care compară cele două coduri. Este asigurat astfel un nivel bun de autentificare. Pentru evitarea atacurilor de tip reluare, sistemul de management trebuie să cunoască valorile a două variabile: snmpEngineBoots şi snmpEngineTime. Aceste două valori sunt menŃinute şi încrementate de engine-ul SNMP de pe echipamentul de reŃea. La începerea comunicaŃiei între sistemul de management şi agentul SNMP, acesta află cele două valori şi le include apoi în pachetul SNMP, fiind incluse şi în codul HMAC. Agentul SNMP trebuie sa verifice că snmpEngineBoots este identic cu cel propriu şi snmpEngineTime nu diferă cu mai mult de 150 secunde.

Pentru confidenŃialitatea datelor fiecărui utilizator îi este atribuită o parolă de autentificare, cunoscută de utilizatorul de pe sistemul de management al reŃelei cât si de engine-ul SNMP de pe echipament. Mecanismul de criptare este cu cheie simetrică, putând fi folosit orice algoritm de criptare cu cheie simetrică (DES, AES, 3DES, etc.). Întreg pachetul SNMP este criptat folosind algoritmul specificat şi cheia de criptare cunoscută de ambele părŃi.

SNMPv3 foloseşte un model de control al accesului numit VACM (View-based Access Control Model). Cu VACM se definesc view-uri şi grupuri de utilizatori. Fiecare view defineşte porŃiunea din MIB care să fie accesibilă, apoi view-ul este asociat unui grup de utilizatori. Astfel se poate realiza un control al accesului foarte detaliat şi se pot defini niveluri de autorizare diferite pentru fiecare grup de utilizatori.

Pentru aplicaŃia prezentată în această lucrare, protocolul SNMPv3 este folosit la comunicaŃia dintre serverul WEB pe care rulează aplicaŃia şi echipamentele de reŃea care sunt configurate. ComunicaŃia este astfel securizată, protocolul SNMPv3 oferind o modalitate simplă şi eficientă de a configura un echipament în condiŃii de securitate.

4.4.2 Protocolul RADIUS

RADIUS (Remote Authentication Dial In User Service) este un protocol de tip AAA (Authentication, Authorization and Accounting) pentru controlul accesului la resursele unei reŃele. RADIUS este folosit în mod curent de către ISP-uri (Internet Service Provider) şi de către corporaŃiile ce administrează accesul la Internet sau reŃele

35

interne ce folosesc o diversitate de tehnologii printre care modem, DSL, wireless şi VPN-uri.

Multe servicii de reŃea (inclusiv reŃele ale corporaŃiilor şi ISP-uri publice ce folosesc diverse tehnologii precum Ethernet, DSL, sau tehnologii fără fir 802.11) solicită prezentarea unor elemente de securitate(nume utilizator şi parolă sau certificate digitale) pentru a acorda conexiunea la reŃea. Înainte ca accesul să fie oferit, aceste informaŃii sunt transmise către dispozitivul NAS (Network Access Server - Server de Acces în ReŃea) prin intermediul protocolul de legătură de date – de exemplu, Protocolul Point-to-Point (PPP) în cazul mai multor furnizori de DSL sau dialup – şi apoi către un server RADIUS prin intermediul protocolului RADIUS. Serverul RADIUS verifică dacă informaŃia este corectă folosind procedee de autentificare precum PAP, CHAP, sau EAP. În trecut serverele RADIUS verificau informaŃiile despre utilizatori într-o bază locală de date. Serverele moderne de RADIUS pot face acest lucru, sau pot consulta o sursă externă – de obicei servere SQL, Kerberos, LDAP sau Active Directory – pentru a verifica datele de autentificare(nume utilizator, parola).

Odată ce utilizatorul este autentificat, serverul RADIUS va verifica deseori dacă utilizatorul este autorizat pentru a folosi serviciul de reŃea solicitat. Un utilizator dat, poate avea permisiunea de a folosi reŃeaua fără fir a unei companii dar nu şi serviciul VPN, de exemplu. Astfel de informaŃii pot fi stocate local pe serverul RADIUS, sau pot fi găsite într-o sursă externă cum ar fi LDAP sau Active Directory.

În final, daca utilizatorul a fost autentificat si autorizat, serverul RADIUS poate trimite către NAS parametrii adiŃionali cum ar fi: • Adresa IP specifică ce trebuie atribuită utilizatorului • O plajă de adrese din care trebuie aleasă adresa IP a utilizatorului • Durata maximă a conexiunii utilizatorului • O listă de acces, o coadă de priorităŃi sau alte restricŃii asupra accesului utilizatorului • Parametrii L2TP • Parametrii QoS (calitatea serviciilor)

Serverele RADIUS folosesc conceptul AAA pentru a administra resursele reŃelei printr-un proces format din următoarele trei etape:

(a) Autentificarea – Utilizatorul sau maşina solicită acces la resursele reŃelei prin intermediul unui Server de Acces în ReŃea (NAS) . În schimb, NAS-ul emite o cerere de acces RADIUS către serverul RADIUS solicitând autentificarea utilizatorului. Această cerere include o formă de identificare şi o dovada a identificării, de obicei sub forma unui nume de utilizator şi parola furnizată de către acesta. AdiŃional, cererea conŃine informaŃii furnizate de către NAS, informaŃii ce conŃin detalii despre utilizator, cum ar fi adresa MAC sau punctul de conexiune fizică a utilizatorului cu NAS-ul.

(b) Autorizarea – Cererea de acces a utilizatorului este procesată de către serverul RADIUS. Serverul RADIUS va căuta şi verifica apoi contul utilizatorului într-o listă internă de conturi sau va face o interogare pe o bază de date la distanŃă pentru informaŃii referitoare la utilizator. Dovada de identificare a utilizatorului este verificată şi opŃional,

36

alte informaŃii ce au legătură cu cererea cum ar fi adresa de reŃea a utilizatorului sau numărul de telefon, starea contului şi tipul serviciilor de reŃea pentru care este autorizat. Serverul RADIUS va emite unul din trei răspunsuri: mesaj RADIUS Accept (Acceptare Acces), RADIUS Reject (Refuz Acces) sau RADIUS Challenge (mesaj de Încercare) către NAS-ul responsabil de punerea în aplicare a deciziilor de acces emise de serverul RADIUS.

• RADIUS Challenge – Solicită informaŃii adiŃionale din partea utilizatorului, de exemplu o parolă secundara , un PIN, card (jeton) de răspuns la încercare.

• RADIUS Reject – Utilizatorului i se refuză necondiŃionat accesul la toate resursele de reŃea solicitate. Motivele pot include lipsa furnizării unei dovezi de identificare sau nerecunoaşterea / inexistenŃa contului de utilizator.

• RADIUS Accept – Se acceptă accesul utilizatorului la resursele reŃelei. Atributele de autorizare sunt transmise către NAS, acestea stipulând termenii în care a fost oferit dreptul de acces. Aceşti termini pot include limitele referitoare la durata pe care e valabil dreptul de acces, limite referitoare la cantitatea de date sau lăŃimea de bandă disponibilă, restricŃii de securitate pentru controlul accesului şi adresa de reŃea atribuită.

(c) Înregistrarea operaŃiunilor (Accounting) – Serverul NAS notifică serverul RADIUS în legătură cu evenimente cum ar fi:

• Startul sesiunii utilizatorului • Sfârşitul sesiunii utilizatorului • Totalul pachetelor transferate în timpul sesiunii • Motivul încheierii sesiunii

Scopul principal al acestor date este taxarea adecvată a utilizatorului; de asemenea datele pot fi folosite pentru realizarea de statistici şi pentru monitorizarea generală a reŃelei.

(3) Access – Request

(4) Access – Accept / Reject

(1) Access – Request

(2) Access – Challenge

NAS

(Network

Authentication

Server)

RADIUS

Server

Figura 19 – Schimbul de mesaje în cadrul unei autentific ări cu RADIUS

Protocolul RADIUS nu transmite parolele în clar între NAS şi serverul RADIUS (nici măcar cu protocolul PAP). În schimb, se foloseşte o cheie comună împreună cu un algoritm de dispersie MD5 pentru a ascunde parolele. Acest procedeu nu este considerat

37

ca fiind o metodă foarte buna de protecŃie a datelor de autentificare ale utilizatorului. Dacă este posibil, ar trebui folosite protecŃii adiŃionale – de exemplu tunele IPSEC – pentru a cripta şi mai bine traficul RADIUS, mai ales când luăm în considerare faptul că datele de autentificare ale utilizatorului, sunt protejate numai parŃial de către serverul RADIUS.

4.4.3 Protocolul HTTPS

HTTPS nu este un protocol distinct, el fiind de fapt protocolul HTTP care transferă mesajele printr-o conexiune securizată cu SSL (Secure Sockets Layer) sau TLS (Transport Layer Security). HTTPS oferă o bună securitate pentru confidenŃialitatea datelor şi împotriva atacurilor de tip man-in-the-middle. Un server HTTPS ascultă conexiuni de obicei pe portul 443, dar poate fi configurat, pentru o securitate sporită, să asculte conexiunile HTTPS pe alt port.

Un server web care oferă suport pentru conexiuni securizate cu HTTPS trebuie să deŃină un certificat digital cu cheie publică. Aceste certificate pot fi create şi emise de o autoritate de certificare sau pot fi create local folosind o aplicaŃie precum OpenSSL. În medii de lucru organizaŃionale certificatele folosite pe serverele web sunt folosite pentru accesul securizat la aplicaŃiile web din intranet. În astfel de situaŃii se folosesc certificate autosemnate care sunt adăugate în lista de certificate sigure pe calculatoarele angajaŃilor. Pentru serverele web din internet sunt folosite certificate digitale emise de autorităŃi de certificare.

HTTPS oferă suport şi pentru autentificarea clienŃilor, pentru a permite accesul la un server web doar clienŃilor autorizaŃi. Fiecare client deŃine un certificat propriu, emis de o autoritate de certificare locală, prin care se autentifică la serverul web. Certificatul poate fi instalat pe calculatorul clientului sau stocat pe un smart-card. Nivelul de protecŃie oferit de HTTPS depinde de corectitudinea modului de implementare a autentificării cu certificate pe browser-ul web al clientului şi aplicaŃia de pe serverul web, dar şi de algoritmii criptografici suportaŃi. Datele sunt protejate pe parcursul dintre client şi server. Odată ajunse la destinaŃie, sunt protejate de politica de securitate aplicată pe serverul web sau serverul de baze de date locale.