Comunicații protejate cu IKEv2 și IPSec: analiza securității și [628594]
UNIVERSITATEA „POLITEHNICA” DIN BUCUREȘTI
FACULTATEA DE ELECTRONICĂ, TELECOMUNICAȚII ȘI TEHNOLOGIA
INFORMAȚIEI
Comunicații protejate cu IKEv2 și IPSec: analiza securității și
aplicații
PROIECT DE DIPLOMĂ
Prezentat ca cerință par țială pentru obținerea titlului de Inginer în
domeniul Electronică și Telecomunicații programul de studii: Rețele și
Software de Telecomunicații
Conducător științific: Student: [anonimizat]
2019
ANEXA1
DECLARATIE DE ONESTITATE ACADEMICA
CUPRINS
LISTĂ DE FIGURI ________________________________ ______________________________ – 9 –
LISTĂ DE ACRONIME ________________________________ __________________________ – 11 –
CAPITOLUL 1 – INTROD UCERE ________________________________ ___________________ – 13 –
1.1 MOTIVAȚIE ________________________________ ______________________________ – 13 –
1.2 OBIECTIVE ________________________________ _______________________________ – 14 –
1.3 STRUCTURA LUCRĂRII ________________________________ ________________________ – 14 –
CAPITOLUL 2 – SECURI TATEA REȚELELOR IP ________________________________ ________ – 15 –
2.1 SERVICII DE SECURITAT E ________________________________ ______________________ – 15 –
2.1.1 Confidențialitate, Integritate, Disponibilitate ______________________________ – 15 –
2.1.2 Autentificare ________________________________ ________________________ – 19 –
2.1.3 PKI – Infrastructura pentru chei publice ________________________________ __ – 20 –
2.2 SUITA DE PROTOCOALE IPSEC ________________________________ __________________ – 22 –
2.2.1 Caracteristici generale ________________________________ ________________ – 22 –
2.2.2 Protocoalele AH și ESP ________________________________ ________________ – 23 –
2.2.3 Protocoale de stabilire a cheilor secrete ________________________________ __ – 25 –
CAPITOLUL 3 – REȚELE PRIVATE VIRTUALE (V PN) ________________________________ ___ – 31 –
3.1 NOȚIUNI GENERALE ________________________________ _________________________ – 31 –
3.1.1 Rețele private virtuale cu acces la distanță ________________________________ – 31 –
3.1.2 Rețele private virtuale de tip site -to-site ________________________________ __ – 32 –
3.2 TUNELE GRE/ MGRE________________________________ ________________________ – 33 –
3.2.1 Tunele GRE ________________________________ _________________________ – 33 –
3.2.2 Tunele mGRE ________________________________ ________________________ – 34 –
3.3 DMVPN ________________________________ ________________________________ – 34 –
3.3.1 Tehnologii utilizate în DMVPN ________________________________ __________ – 35 –
3.3.2 Etapele (fazele) de implementare a DMVPN _______________________________ – 35 –
CAPITOLUL 4 – PROTOC OLUL IKEV2 (INTERNET KEY EXCHANGE VERSIO N 2) _____________ – 39 –
4.1 ASPECTE GENERALE ________________________________ _________________________ – 39 –
4.2 SCHIMBURI IKEV2 ________________________________ _________________________ – 39 –
4.2.1 Schimburi inițiale ________________________________ ____________________ – 39 –
4.2.2 CREATE_CHILD_SA ________________________________ ___________________ – 42 –
4.2.3 IN FORMATIONAL ________________________________ ____________________ – 44 –
4.3 ASPECTE PRIVIND SECUR ITATEA PROTOCOLULUI IKEV2 ________________________________ _ – 45 –
CAPITOLUL 5 – ANALIZ A SECURITĂȚII ȘI APL ICAȚII ÎN SERVICII I PSEC ___________________ – 47 –
5.1 CONFIGURAȚII DE BAZĂ PENTRU STUDIUL DE CA Z ________________________________ _____ – 47 –
5.1.1 OSPF ________________________________ ______________________________ – 48 –
5.1.2 Tunele GRE ________________________________ _________________________ – 50 –
5.1.3 Tunele mGRE ________________________________ _________________________ – 2 –
5.1.4 DMVPN ________________________________ _____________________________ – 4 –
5.2 IMPLEMENTAREA PROTOCO LULUI IKEV2 PENTRU SECURIZAREA COMUNICAȚIILOR _______________ – 10 –
CAPITOLUL 6 – CONCLU ZII ________________________________ _____________________ – 44 –
6.1 CONCLUZII GENERALE ________________________________ ________________________ – 44 –
6.2 CONTRIBUȚII PERSONALE ________________________________ _____________________ – 44 –
6.3 DEZVOLTĂRI ULTERIOARE ________________________________ _____________________ – 45 –
BIBLIOGRAFIE ________________________________ _______________________________ – 47 –
ANEXE ________________________________ ________________________________ _____ – 50 –
List ă de figuri
Figura 1. Pachetul IP utilizat cu IPSec în modul tunel ………………………….. ………………………….. …………….. – 23 –
Figura 2. Pachetul IP utilizat cu IPSec în modul transport ………………………….. ………………………….. ………. – 23 –
Figura 3. Pachetul IP utilizat cu pr otocolul AH în modul transport ………………………….. ……………………….. – 24 –
Figura 4. Pachetul IP utilizat cu protocolul AH în modul tunel ………………………….. ………………………….. … – 24 –
Figura 5. Antetul protocolului IPSec ESP ………………………….. ………………………….. ………………………….. ….. – 25 –
Figura 6. Pachetul IP utilizat cu protocolul ESP în modul transport ………………………….. ………………………. – 25 –
Figura 7. Pachetul IP utilizat cu protocolul ESP în modul tunel ………………………….. ………………………….. .. – 25 –
Figura 8. Schimbul de chei în cadrul protocolului Diffie -Hellman ………………………….. …………………………. – 27 –
Figura 9. Schimbul de chei în cadrul protocolului bazat pe autentificare cu semnături ………………………. – 27 –
Figura 10. Schimbul de chei în cadrul protocolului bazat pe autent ificare cu PSK și MAC ……………………. – 28 –
Figura 11. Schimbul de chei în cadrul protocolului bazat pe criptografie cu chei publice …………………….. – 29 –
Figura 12. Schema de bază a unei rețele private virtuale ………………………….. ………………………….. ……….. – 31 –
Figura 13. Structura rețelei VPN cu acces la distanță ………………………….. ………………………….. …………….. – 32 –
Figura 14. Structura rețelei VPN de tip site -to-site ………………………….. ………………………….. ………………… – 32 –
Figura 15. Schematizarea funcționării tunelelor GRE ………………………….. ………………………….. …………….. – 33 –
Figura 16. Pachet IP original ………………………….. ………………………….. ………………………….. …………………… – 33 –
Figura 17. Pachet IP la care se adaugă antetul GRE ………………………….. ………………………….. ……………….. – 33 –
Figura 18. Pachetul IP obținut în urma încapsulării GRE ………………………….. ………………………….. …………. – 33 –
Figura 19. Schematizarea funcționalitătii tunele lor mGRE ………………………….. ………………………….. ……… – 34 –
Figura 20. Reprezentare schematică. Etapa I DMVPN ………………………….. ………………………….. ……………. – 36 –
Figura 21. Reprezentare schematică. Etapa II DMVPN ………………………….. ………………………….. …………… – 36 –
Figura 22. Reprezentare schematică. Etapa III DMVPN ………………………….. ………………………….. ………….. – 37 –
Figura 23. Schimbul IKE_SA_INIT din cadrul IKEv2 ………………………….. ………………………….. …………………. – 40 –
Figura 24. Schimbul IKE_AUTH din cadrul IKEv2 ………………………….. ………………………….. ……………………. – 41 –
Figura 25. Schimbul CREATE_CHILD_SA din cadrul IKEv2 ………………………….. ………………………….. ……….. – 42 –
Figura 26. Recodificarea Asociației de Securitate în cadrul schimbului CREATE_CHILD_SA …………………. – 43 –
Figura 27. Recodificarea Child SA în cadrul schimbului CREATE_CHULD_SA ………………………….. ………….. – 44 –
Figura 28. Schimbul INFORMATIONAL din cadrul IKEv2 ………………………….. ………………………….. …………. – 44 –
Figura 29. Topologia utilizată în cadrul studiului de caz ………………………….. ………………………….. …………. – 47 –
Figura 30. Captură de rețea ce ilustrează efectele tunelării cu ajutorul protocolului GRE …………………….. – 1 –
Figura 31. Captură de rețea. Cerere de înregistrare NHRP ………………………….. ………………………….. …………… 4
Figura 32. Catură de rețea. Pachete transmise în clar, nesecurizat ………………………….. ………………………….. 10
Figura 33. Topologie utilizată în cadr ul implementării protocolului IKEv2 ………………………….. ………………… 11
Figura 34. Captură de rețea. Schimburile inițiale din cadrul protocolului IKEv2 ………………………….. ………… 32
Figura 35. Captură de rețea. Conținutul mesajelor de tip cerere IKE_SA_INIT ………………………….. ………….. 33
Figura 36. Captură de rețea. Conținutul mesajelor de tip răspuns IKE_SA_INIT ………………………….. ………… 34
Figura 37. Captură de rețea. Conținutul câmpului de solicitare a certificatelor ………………………….. …………. 35
Figura 38. Captură de rețea. Conținutul mesajelor de tip cerere IKE_AUTH ………………………….. ……………… 36
Figura 39. Captură de rețea. Mesaje din cadrul celei de a doua etape a protocolului IKEv2 ……………………. 37
Figura 40. Captură de rețea. Conținutul mesajelor de tip cerere CREATE_CHILD_SA ………………………….. …. 37
Figura 41. Captură de rețea. Mesaje din cadrul ultimei etape a protocolului IKEv2 ………………………….. …… 38
Figure 42. Captură de rețea. Funcționarea protocolului IKEv2 prin confirmarea criptării ……………………….. 41
List ă de acronime
AAA – Authentication, Authorization, Accounting
AES – Advanced Encryption Standard
AH – Authentication Header
AUTH – Authentication
C – Country
CA – Certificate Authority
CBC – Cipher Block Chaining
CDP – Cisco Discovery Protocol
CERT – Certificate
CERTREQ – Certificate Request
CIE – Client Information Element
CN – Common Name
CP – Configuration
CRL – Certificate Revocation List
D- Delete
DBD – Database Description
DDoS – Distributed Denial of Service
DES – Data Encryption Scheme
DH – Diffie -Hellman
DLP – Discrete Logarithm Problem
DMVPN – Dynamic Multipoint VPN
DN – Domain Name
DNS – Domain Name Server
DoS – Denial of Service
DR – Designated Router
EAP – Extensible Authentication
ESP – Encapsulating Security Protocol
FQDN – Fully Qualified Domain Na me
GRE – Generic Routing Encapsulation
H – Hub
HDR – Header
HE – Hub Edge
HTTP – Hypertext Transfer Protocol
ICMP – Internet Control Message Protocol
ICV – Integrity Check Value
ID – Identification
IDS – Intrusion Detection System
IGP – Internet Gateway P rotocol
IKEv2 – Internet Key Exchange version 2
IP – Internet protocol
ISAKMP – Internet Security Association & Key Management Protocol
KE – Key Exchange
L – Localty
LSA – Link State Acknowledgement
LSDB – Link State Database
LSR – Link State Request
LSU – Link State Update
MAC – Mediun access control
MD5 – Message Digest 5
mGRE – Multipoint Generic Routing Encapsulation
N – Nonce
N – Notification
NBMA – Non Broadcast Multiple -Access
NHC – Next Hop Client
NHRP – Next Hop Resolution Protocol
NHS – Next Hop Server
NVRAM – Non-Volatile Random -Access Memory
O – Organization
OSI – Open Systems Interconnection
OSPF – Open Shortest Path First
OU – Organizational Unit
PKI – Public Key Infrastructure
PRF – Pseudo -Random Function
RA – Registration Authority
S – Spoke
SA – Security Association
SCEP – Simple Certificate and Enrollment Protocol
SE – Spoke Edge
SHA – Secure Hash Algorithm
SP – Service Provider
TCP – Transmission Control Protocol
TS – Traffic Selector
TTL – Time to Live
URL – Uniform Resource Locator
VPN – Virtual Private Network
VTI – Virtual Tunnel Interface
CAPITOLUL 1 – INTRODUCERE
1.1 Motivație
Într-o lume a tehnologiei care se află în continu ă dezvoltare, protejarea informației
constituie cel mai important aspect al comunicațiilor. Începând cu datele personale care identifică
fiecare individ în parte și culminând cu documentații esențiale care țin de securitatea națională a
fiecarui stat, scopu l principal al erei tehnologice este reprezentat de protejarea informației
împotriva situațiilor în care aceasta se poate pierde sau chiar a atacurilor cibernetice.
Importanța informației este un subiect controversat, fiind dezbătut de -a lungul timpului. Cea
mai simplă definiție a informației, dar și cea mai reprezentativă este cea conform căreia
“cunoașterea înseamnă putere”. Validitatea acesteia a fost confirmată atât în diferite evenimente
istorice, cât și în circumstanțe actuale.
O conjunctură istori că în care informația a reprezentat cu adevărat putere este reprezentată
de cel de -al Doilea Război Mondial în care, pentru păstrarea confidențialității mesajelor, Germania
nazistă a utilizat mașina Enigma, o mașină criptografică cu rolul de a genera cifru ri pentru criptarea
și decriptarea de mesaje secrete. Din cauza vulnerabilitaților criptografice ale cifrurilor Enigma, o
mare parte din mesajele transmise prin intermediul acestei mașini s -a reușit a fi decriptată, astfel că
aflarea informațiilor secrete a condus la un alt final al Războiului fa ță de cel așteptat.
Într-un context actual, dar la fel de semnificativ, anul 2016 a reprezentat pentru securitatea
cibernetică un moment de slăbiciune privind protecția informațiilor. Descoperirea atacului KRACK
(Key Reinstallation Attack), atac ce vizează cheile criptografice utilizate în cadrul comunicațiilor
care se desfășoară în Internet, a demonstrat vulnerabilitatea protocolului WPA2 responsabil cu
securizarea conexiunilor Wireless.
Principiul de bază al atac ului KRACK este reprezentat de forțarea reutilizării valorilor
“nonce”. Prin definitie, un “nonce” reprezintă o valoare aleatoare care poate fi folosită o singură
dată într -o comunicație criptografică. Prin reutilizarea acestuia, atacatorii reușesc, astfel , să
compromită protocolul de criptare, să reia transmisiunea pachetelor și să decripteze mesajele
conținute de acestea.
Reinstalarea valorilor “nonce”, mai exact setarea continuă a acestora la valorile inițiale,
determină utilizarea acelorași chei cript ografice, astfel că procedeul de criptare a mesajelor implică
refolosirea informațiilor originale. Ca rezultat final, atacatorii pot decripta mesajele și, mai mult de
atât, le pot modifica.
Conform analizelor realizate asupra atacului KRACK, cea mai bună soluție pentru
securizarea comunicațiilor este reprezentată de implementarea rețelelor private virtuale (VPN) .
Acestea asigură crearea unui canal de comunicație securizat care nu permite accesul entităților
neautorizate și nici obținerea și manipularea inf ormațiilor transmise.
Rețelele private virtuale (VPN) sunt implementate cu ajutorul suitei de protocoale IPSec.
Acestea sunt responsabile cu criptarea traficului de date și asigurarea confidențialității în cadrul
comunicației. Unul dintre protocoalele di n cadrul suitei IPSec este IKEv2, protocol de schimb al
cheilor în internet.
Protocolul IKEv2 este implementat prin intermediul procedeului de tip “handshake”, utilizat
și de protocolul WPA2, demonstrat ca fiind vulnerabil la atacuri KRACK. De asemenea, tot ca
element asemănător, IKEv2 folosește din punct de vedere criptografic valori “nonce” pentru
stabilirea cheilor criptografice utilizate în comunicația dintre participanți.
Deși foarte asemănătoare din anumite aspecte, protocolul IKEv2, față de WPA2, reușește să
mențină o securitate ridicată a comunicației și să nu devină vulnerabil asupra atacurilor KRACK.
Lucrarea de față are ca scop analiza securității protocolului IKEv2 implementat în cadrul
rețelelor private virtuale, testarea funcționalității acestuia și studiul vulnerabilitătilor pe care le
prezintă, din punct de vedere al posibilelor atacuri.
1.2 Obiective
În cadrul lucrării de față, au fost stabilite o serie de obiective care se bazează pe analiza,
implementarea și testarea protocolului I KEv2 și a protocolului IPSec în scopul securizării
comunicațiilor din cadrul rețelelor private virtuale care utilizează un furnizor de servicii în Internet.
Obiectivele urmărite au fost alese astfel încât să respecte o ierarhie graduală ascendentă din
punct de vedere al complexității, după cum urmează:
• Analiza modalității de asigurare a securității prin utilizarea diferitelor variante de implementare
a protocolului IKEv2;
• Analiza criptografică asupra generării cheilor secrete în cazul funcționalității prot ocolului
IKEv2 cu chei predistribuite (PSK);
• Analiza soluțiilor de implementare a infrastructurilor pentru chei publice și a securită ții oferite
de acestea în cazul utilizării protocolului IKEv2;
• Alegerea soluției optime din punct de vedere al securității pentru implementarea protocolului
IKEv2 în situația unei topologii de rețele private virtuale care comunică prin intermediul unui
furnizor de servicii.
• Implementarea studiului de caz prin intermediul unei infrastructuri pentru chei publice ce
utilizează un server cu rol de Autoritate de Certificare ca terță parte de încredere.
• Testarea soluției implementate prin securizarea conexiunilor cu ajutorul protocolului IKEv2.
• Analiza experimentală a funcționării protocolului IKE v2 în cadrul rețelelor private virtuale
implementate în cadrul studiului de caz.
1.3 Structura lucrării
Structurarea lucrării urmărește, în principal, obiectivele prezentate în subcapitolul anterior,
oferind detalii legate de analiza, implementarea și te starea securității rețelelor private virtuale ce
utilizează protocolul IKEv2.
Capitolul 2, Scuritatea Rețelelor IP, prezintă o introducere asupra serviciilor de securitate
necesare în cadrul topologiilor de rețea, iar, ulterior, o descriere formală și funcțională a suitei de
protocoale IPSec ce înglobează AH, ESP și protocoale de stabilire a cheilor secrete din punct de
vedere criptografic.
Capitolul 3 ilustrează aspecte legate de rețelele private virtuale, prezentând inițial idei
generale asupra clas ificării și funcționalității acestor a, iar ulterior aspecte definitorii privind
configurarea tunelelor GRE/ mGRE și a tehnicii de rutare DMVPN.
Protocolul IKEv2 este descris în cadrul capitolului 4 și urmărește prezentarea aspectelor
generale, de bază ale schimbului de chei în Internet, etapele de implementare ale protocolului
ilustrat atât formal, cât și func țional din punct de vedere criptografic, dar și caracteristici privind
securitatea IKEv2 în care au fost analizate diferite vulnerabilități și modalit ați de mitigare a
acestora.
Capitolul 5 înglobează studiul de caz realizat ca parte practică a proiectului de față, fiind
împărțit în două subcapitole: configurațiile de bază, necesare implementării ulterioare ale
obiectivelor lucrării și dezvoltarea prac tică a studiului de caz ce prezintă soluția oferită de
protocolul IKEv2 în cazul rețelelor private virtuale.
Capitolul 6 este dedicat concluziilor asupra analizei, implementării și testării protocolului
IKEv2 în cadrul rețelelor private virtuale ce folos ește o infrastructur ă pentru chei publice.
CAPITOLUL 2 – SECURITATEA REȚELELOR IP
2.1 Servicii de securitate
2.1.1 Confidențialitate, Integritate, Disponibilitate
CONFIDENȚIALITATE
Unul dintre principiile de bază ale securității comunicațiilor îl constituie asigurarea
confidențialității în cazul transmiterii de date. Astfel, se urmărește ca schimbul de informații să fie
privat. Acest lucru presupune faptul că o entitate neautorizată (potențial atacator) nu poate citi
datele transmise, adică nu poat e obține informații sensibile din cadrul comunicației.
Metodele de protecție a confidențialității datelor includ : controlul accesului , criptarea
datelor , steganografia .
Controlul accesului
O formă de prevenire a dezvăluirii informațiilor transmise printr -un canal de comunicare o
reprezintă acordarea de permisiuni entităților componente unei structuri ierarhice. Controlul
accesului reprezintă serviciul de securitate care interceptează o cerer e de acces din partea unui
subiect, determină ulterior gradul de autorizare bazat pe îndeplinirea politicilor de acces și permite
sau respinge efectuarea acțiunii în funcție de caz.
Controlul accesului asupra informațiilor se împarte în mai multe categor ii și poate fi:
1. Control al accesului fizic – determină cine, unde și când poate intra/ieși;
2. Control al accesului logic – reprezentat de soluțiile hardware și software;
3. Control al accesului administrativ – cuprinde politici, proceduri, standarde, procese.
Pe de altă parte, strategiile de control a accesului se împart în:
1. Controlul accesului obligatoriu – aplică restricții pentru anumite acțiuni pe care
dorește să le efectueze un subiect asupra unui proces;
2. Controlul accesului discreționar – acordul sau restricția asupra unor obiecte este
determinat de proprietarul obiectului;
3. Controlul accesului bazat pe rol – permisiunile de acces asupra unor obiecte sunt
stabilite în funcție de rolul unui subiect în cad rul organizației;
4. Controlul accesului bazat pe reguli – accesul este stabilit pe baza unor reguli
existente într -o listă de control a accesului (ACL);
Criptografia – criptarea
Criptografia reprezintă o modalitate de a transmite și stoca date astfel încât doar anumite
entități să le poată citi și/sau procesa.
Metoda criptării realizează o conversie reversibilă a textelor clare (plaintext) în texte cifrate
(ciphertext) prin utili zarea unui algoritm de criptare. Această tehnică asigură confidențialitatea
datelor fie prin criptarea datelor aflate într -un mediu de stocare, fie prin criptarea datelor aflate în
tranzit. Cea de a doua metodă reprezintă, în sens larg, criptarea canalului de comunicație, adică a
tuturor datelor care circulă între două sisteme. Procesul de transmitere a informațiilor se încheie în
momentul în care datele ajung la destinatar. Acesta utilizează procedeul invers criptării,
decriptarea, pentru a realiza convers ia între textul cifrat și textul clar.
Criptarea datelor poate fi simetrică sau asimetrică în funcție de cheile folosite în cadrul
procedeului ales. O cheie reprezintă o informație aleatoare folosită în algoritmul de criptare pentru
a realiza criptarea sa u decriptarea datelor.
Criptarea simetrică
Procesul de criptare simetrică se mai numește și criptare cu cheie secretă. Acest procedeu
presupune folosirea unei chei unice atât pentru criptare, cât și pentru decriptare. Principiul de
functionare conține următorii pași:
1. Generarea unei chei private și distribuirea acesteia între participanți;
2. Criptarea datelor de către expeditor folosind cheia privată;
3. Transportul datelor prin intermediul unui canal de comunicație;
4. Decriptarea de către destinatar a datelor folosind cheia privată.
Caracteristicile algoritmului de criptare simetrică se referă, în general, la proprietățile cheii
folosite. Cele mai importante aspecte cuprind particularități precum:
1. Cheia aleasă este generată aleator;
2. Cheia trebuie partajată cu p ersoana care urmează să decripteze mesajul;
3. Cheia trebuie pastrată secretă față de entitățile care nu ar trebui să decripteze mesajul;
4. Cheia trebuie cunoscută doar de entitațile participante la comunicație, altfel se
pierde confidențialitatea.
Din punct de vedere al avantajelor, algoritmii de criptare simetrică sunt cei mai rapizi și mai
eficienți. Se obține o performanță ridicată în cazul criptării unei cantități mari de informații.
Pe de altă parte, procesul de partajare a cheii este unul dificil. Pentru distribuție, este
necesar să se asigure autenticitatea și confidențialitatea cheii. De asemenea, un alt dezavantaj al
criptării simetrice îl constituie numărul de chei necesare garantării mai multor transferuri de
informații. Pentru fiecare destinatar, ex peditorul trebuie să genereze o cheie diferită, astfel ca
numărul necesar de chei pentru n comunicații este:
𝑵𝒖𝒎 ă𝒓𝒖𝒍 𝒅𝒆 𝒄𝒉𝒆𝒊 = 𝒏∗(𝒏−𝟏)/𝟐
Criptarea asimetrică
Criptarea asimetrică sau criptarea cu cheie publică presupune generarea unei perechi de
chei. Astfel, fiecare participant dispune de o cheie publică și una privată. Modalitatea de
funcționare a acestui algoritm respectă următoarele etape:
1. Expeditorul cunoaște cheia publică a destinatarului și cu ajutorul acesteia criptează
datele p e care dorește să le trimită;
2. Datele sunt transportate prin intermediul unui canal de comunicație;
3. Destinatarul decriptează datele folosind cheia sa privată;
Spre deosebire de criptarea simetrică, unde aceeași cheie era folosită atât pentru criptare, cât
și pentru decriptare, în cazul criptării asimetrice cele două chei au roluri opuse. Dacă, pe de o parte,
cheia publică este folosită pentru criptare, cea priva tă are rolul decriptării.
Cheia publică este partajată cu participanții la comunicație. În acest caz, este necesară
asigurarea autenticității, dar nu și a confidențialitătii. Cheia privată rămâne secretă și este folosită
doar de cel care decriptează mesaj e.
Printre avantajele criptării asimetrice se numără simplificarea procesului de distribuție a
cheilor. Contrar criptării simetrice, confidențialitatea cheii nu mai este necesară deoarece cheia
publică nu este una secretă și este distribuită partenerilor pentru criptare. Pe de altă parte, cheia
privată trebuie menținută secretă și nu este partajată.
Un alt avantaj al criptării asimetrice este constituit de administrarea cheilor. Dacă în cazul
simetric era necesară câte o cheie pentru fiecare participant, î n cazul criptării asimetrice fiecare
utilizator deține o pereche de chei, dintre care una publică și una privată.
Dezavantajul criptării asimetrice este reprezentat de faptul că algoritmii sunt mai lenți și
mai ineficienți.
INTEGRITATE
Odată ce confidențialitatea informațiilor a fost asigurată, un alt aspect important al
securității îl constituie integritatea datelor. Acest serviciu de securitate urmărește detecția și
prevenirea modificărilor neautorizate asupra mesajelor aflate în tran zit (transmiterea de la sursă la
destinație) sau într -un mediu de stocare.
În scopul protecției datelor împotriva modificărilor neautorizate, principal ele modalit ăți de
asigurare a integrității sunt reprezentat e de:
A. Funcții hash
B. Semnături digitale
C. Certificate digitale
Funcții hash
O funcție hash este un algoritm care, în scopul asigurării integrității datelor, prelucrează
informațiile și produce un răspuns unic. Acest răspuns este o reprezentație de lungime fixă a
datelor, numită valoare hash.
După obținerea valorii hash, expeditorul poate decide să inițieze o comunicație pe baza
acesteia sau o poate păstra într -un mediu de stocare.
Funcțiile hash sunt funcții cu sens unic deoarece este imposibil de aplicat un algoritm
reversibil în urma c ăreia să rezulte datele inițiale . În sens explicit, dacă se cunoaște valoarea hash a
anumitor date prelucrate, operația de obținere a datelor inițiale pornind de la această valoare hash
este irealizabilă.
Proprietăți :
1. Datele de intrare pot avea lungime variabi lă;
2. Datele de ieșire au lungime fixă , în funcție de algoritmul aplicat;
3. Funcția hash este cu sens unic și ireversibilă ;
4. Funcția hash este sensibilă la orice modificări ;
5. Două valori de intrare nu vor rezulta în aceeași valoare hash.
6. O valoare de intrare va rezulta întotdeauna în aceeași valoare hash dacă se aplică
același algoritm.
În cazul comunicării între doi participanți, expeditorul trimite valoarea hash împreună cu
datele . În momentul în care primește mesajul, destinatarul verifică integritatea prin a plicarea
aceluiași algoritm datelor și compararea valorii hash obținute cu cea primită de la expeditor. Dacă
cele două coincid, înseamnă că datele nu au fost alterate în timpul tranzitului.
Un algoritm simplu de implementare a funcțiilor hash este repreze ntat de 8 -bit Checksum
(verificarea sumei pe 8 biți). Acest algoritm efectuează transformarea mesajului în numere binare,
calculează valoarea hash a acestuia , iar ulterior organizează șirul în grupări de 8 biți. Valorile pe 8
biți sunt adunate, iar apoi convertite folosind complementul în bază 2.
Semnături digitale
Semnătura digitală, cu aceeași funcționalitate ca și cea scrisă, reprezintă o modalitate de
asigurare a integrității prin care destinatarul verifică dacă datele au fost sau nu alterate în procesul
de transmitere.
Un document semnat digital se obține prin îmbinarea mesajului cu valoarea hash a acestuia
(criptată anterior cu o cheie privată) și cheia publică a expeditorului. Prin intermediul acestora,
expedi torul poate verifica atât integritatea cât și autenticitatea datelor prin efectuarea unei
comparații între valoarea hash pe care o obține aplicând algoritmul mesajul ui primit și valoarea
hash obținut ă prin decriptarea valorii hash primite . Această tehnică determină, de fapt, dacă un
mesaj a fost sau nu modificat după aplicarea semnăturii digitale.
Semnătura digitală este, de fapt, o schemă de autentificare cu cheie publică alcătuită dintr –
un algoritm de generare a cheilor, un algoritm de semnare și un algo ritm de verificare. Aspectul
specific unei astfel de scheme este acela de semnare cu cheie secretă și verificare cu cheie publică.
Cerințele de securitate ale unei astfel de semnături digitale includ nemodificarea mesajelor
supuse la atacuri asupra mesaje lor alese adaptiv.
Certificate digitale
Un certificat digital reprezintă un fișier electronic ce permite schimbarea securizată de
informații în Internet. Echivalent al unui pașaport electronic, certificatul digital autentifică
utilizatorii și efectuează transferul cheilor folosite pentru criptarea sau semnarea digitală a
mesajelor.
Certificatul digital asigură integritatea datelor prin permiterea semnării mesajelor. Prezența
unei semnături determină dacă transferul datelor a fost sau nu securizat și, implicit, dacă datele
transmise printr -un canal de comunicație au fost sau nu alterate .
Standardul de certificate X.509 pentru chei publice definește servicii de autentificare și
autorizare în funcție de componentele certificatului. Printre acestea, cele mai importante sunt:
1. Numele posesorului cheii și cheia sa publică;
2. Numele autorității de certificare care a emis certificatul și semnătura;
3. Numărul de serie și valabilitatea. (SRS)
Infrastructura cheilor publice, cunoscută sub denumirea de PKI (Public Key Infrastructure),
stabilește politicile și procedurile necesare creării, administrării, distribuirii certificatelor digitale.
DISPONIBILITATE
Un alt principiu de bază al securității comunicațiilor este reprezentat de disponibilitatea
serviciilor de comunicații. Acest aspect urmărește ca serviciile să fie disponibile în momentul în
care utilizatorul le solicită.
Necesitatea accesului la informații securizate a entităților autorizate a condus la
implementarea unor tehnici de asigurare a disponibilității care sporesc protecția sistemelor. Se
consideră, astfel, că un sistem sau serviciu protejat are un procent al disponibilității mult mai mare
decât cel al unuia ne protejat.
Asigurarea disponibilității
În scopul asigurării disponibilității, tehnicile principale includ proceduri care vizează
aspecte software și hardware ale sistemelor.
Pe lângă autorizarea accesului asupra unui sistem sau a unui serviciu, acordarea de
permisiuni utilizatorilor are ca scop limitarea acțiunilor pe care aceștia le pot efectua asupra
resurselor disponibile. Limitarea acțiunilor și autorizarea accesului repre zintă tehnici de sporire a
performanței și micșorarea probabilității de indisponibilitate.
Din punct de vedere a protecției fizice a echipamentelor, mentenanța tehnică și operațională
a acestora reprezintă o modalitate de asigurare a disponibilității prin evitarea apariției situațiilor
critice. Aceste situații critice pot apărea datorită lipsei evaluărilor tehnice periodice ale
dispozitivelor. Pe de altă parte, redundanța echipamentelor reprezintă o modalitate de protecție a
sistemelor și a serviciilor prin asigurarea disponibilității în caz de defecte ale echipamentelor.
De asemenea, copiile de rezervă sunt utilizate în cazul datelor corupte sau indisponibile.
Existența copiilor poate fi considerată un indice de performanță în cazul restabilirii disponibilității
deoarece evită pierderea datelor sensibile.
Principiul disponibilității ridicate
Principiul disponibilității ridicate (High -Availability) presupune existența unor sisteme cu
un nivel de performanță foarte ridicat. Principalele scopuri care stau la baza implementării
principiului disponibilității ridicate includ:
1. Eliminarea punctelor si ngulare de eșec;
2. Asigură încrucișarea fiabilă;
3. Detectează defecțiunile în momentul apariției.
Scopul unei astfel de implementări este acela de continuitate în operare, adică de a dezvolta
sisteme și servicii care pot opera în condiții extreme.
“Five Nines ” (cinci de nouă ) reprezintă o tehnică de implementare a disponibilității ridicate.
În acest caz, scopul este de a obține o disponibilitate a sistemelor si a serviciilor de 99.999%, mai
exact un timp de indisponibilitate de 5.26 minute pe an. Această metodă include costuri ridicate și
necesitatea utilizării mai multor resurse.
De asemenea, conceptul de disponibilitate ridicată urmărește clasificarea atacurilor asupra
sistemelor , realizând un raport al impacturilor ce vizează efectele asupra bilanțului financiar al unei
organizații.
2.1.2 Autentificare
În scopul implementării securității, procesul de autentificare oferă o metodă de permitere
sau interzicere a accesului în cadrul unei rețele sau asupra serviciilor oferite de aceasta. Precedent
autentificării, identificarea utilizatorului constituie primul pas în cazul unui subiect ce solicită
accesul asupra unei resurse.
Controlul accesului determină, pe baza unui identificator unic, dacă utilizatorului i se oferă
sau nu acces la res ursele solicitate. Acest identificator este determinat de politicile de securitate și
asociază fiecărui utilizator activitățile permise în cadrul unei rețele. Sistemul identifică individual
fiecare subiect prin intermediul acestor identificatori unici (ex. Nume de utilizator).
În cadrul procesului de autentificare, fiecare utilizator trece printr -o etapă de verificare a
identității. Acest lucru poate fi efectuat prin intermediul unor metode de autenti ficare ce descriu
procedeul prin care un utilizator poate obține accesul la o rețea sau la anumite servicii.
Metode de autentificare
În momentul autentificării, fiecare utilizator își poate dovedi identitatea utilizând în cadrul
procesului următoarele:
Ceea ce știe – cel mai comun factor de autentificare; utilizatorului i se verifică identitatea pe
baza unei informații (ex. Parolă, cod PIN )
Ceea ce are – utilizatorul folosește ceva ce posedă pentru a se autentifica (ex. Card, cartelă )
Ceea ce este – metodă de autentificare complexă ce oferă utilizatorului acces prin identificarea
acestuia pe baza unei caracteristici definitorii psihologice sau comportamentale (ex. Date
biometrice – amprentă digitală, scanarea retinei, voce) .
Autentificarea multi -factor
Cu o complexitate mult mai mare decât folosirea metodelor de bază, autentificarea multi –
factor utilizează cel puțin doi factori pentru identificarea unui utilizator. Pentru a putea fi
considerată autentificare multi -factor, cele două metode trebuie să fie obligatoriu distincte: ceea ce
știe-ceea ce are, ceea ce știe – ceea ce este, ceea ce are – ceea ce este.
Autentificarea folosind o metodă cu doi factori se bazează pe utilizarea a două metode de
bază (ex. Ceea ce știe – Ceea ce are). Un exe mplu, în acest caz, îl constituie folosirea unui
smartcard. Această manieră combină ceea ce are un anumit subiect (cardul) și ceea ce știe (codul
PIN asociat cardului). De asemenea, alte exemple pot fi date biometrice -parolă (ceea ce este – ceea
ce știe) s au token fizic -parolă (ceea ce are – ceea ce știe).
Cea mai complexă metodă de autentificare o constituie combinarea tuturor factorilor și se
numește autentificare cu trei factori. Un utilizator este identificat, astfel, prin ceea ce știe, ceea ce
are și c eea ce este. Spre exemplu, utilizatorului i se poate solicita în cazul autentificării scanarea
retinei, folosirea unui card și cunoașterea unei parole corespunzătoare acelui card.
Autentificarea multi -factor este folosită uzual deoarece sporește securitate a atât în mediul
online, cât și în cel fizic. Fie că ne referim la o retragere bancară, fie că ne conectăm la o aplicație
de cont bancar, autentificarea multi -factor este o metodă mult mai sigură decât cea de bază care
utilizează un singur factor.
Servicii de autentificare
Cunoscut e drept entități ale conceptul ui AAA (Authentication /Autentificare ,
Authorization /Autorizare , Accounting /Contabilitate ), serviciile de autentificare stau la baza
asigurării securității rețelelor și a serviciilor de care d ispun acestea. Pe de o parte, acestea setează
politicile și procedeele de control a accesului, iar pe de altă parte, monitorizează acțiunile care se
desfășoară în cadrul rețelei.
Primul A, corespunzător autentificării, descrie procesul de identificare a unui utilizator.
Astfel, acesta își demonstrează identitatea prin utilizarea fie a unei metode de autentificare de bază,
fie autentificarea multi -factor, în funcție de politicile de securitate.
Ulterior autentifică rii, utilizatorului î i sunt puse la dispoz iție o serie de acțiuni pe care le
poate desfășura în cadrul rețelei. Autorizarea folosește un set de atribute pentru a descrie acțiunile
care îi sunt permise fiecărui utilizator în parte. Aceste atribute determină nivelul de acces pe care
utilizatorul îl are asupra anumitor resurse și pot oferi drepturi de citire, c opiere, creare și/sau
ștergere a acestora.
Cea din urmă entitate a conceptului AAA, contabilitatea, are rolul de a monitoriza
activitatea din cadrul rețelei, prevenirea acțiunilor dăunătoare, st ocarea informațiilor care descriu
acțiunile utilzatorilor. Acestea permit unei organizații înregistrarea tuturor acțiunilor care se
desfășoară în cadrul rețelei, inclusiv erori și/sau greșeli.
2.1.3 PKI – Infrastructura pentru chei publice
Comunicarea protejată prin folosire a criptografiei cu chei publice (criptografie asimetrică)
are la bază o pereche de chei (una publică și alta privată) folosite pentru criptare și decriptare . Dacă,
pe de o parte, cheia privată este menținută secretă de către fiecare parte , cheia publică poate deveni
vulnerabilă și, implicit, își pierde atributele de încredere ale entităților participante la comunicație.
În scopul asigurării unei comunicări securizate, conceptul de infrastructură a cheilor publice
(PKI) descrie practicile, procesele, tehnologiile care stabilesc integritatea acestor chei . Această
infrastructură trebuie să ofere participanților la comunicație integritate, autentificare,
confidențialitate , controlul accesului și non -repudiere . Modalitatea prin care aceste caracteristici
sunt asigurate este reprezentată de introducerea în cadrul comunicației a unei terțe părți de
încredere care să garante ze verificarea participantilor și schimbul securizat de informații.
Infrastructura pentru ch ei publice definește o arhitectură ce înglobează perechi de chei duale
în scopul realizării criptării, dar și a semnăturilor digitale. Perechea pentru criptare asigură
confidențialitatea datelor, pe când cea pentru realizarea semnăturii digita le oferă aute ntificare,
integritate si non -repudiere.
Pentru îndeplinirea acestui scop, infrastructura pentru chei publice integrează certificate
digitale, criptografie cu chei publice și autorități de certificare. Din punct de vedere al structurii, o
astfel de infrastructură este alcătuită din următoarele componente:
1. Autorități de Certificare
2. Autorități de Înregistrare
3. Spațiu de depozitare
4. Chei publice și private
5. Certificate digitale
Autoritatea de Certificare (CA)
O Autoritate de Certificare este un server securizat care asigură semnarea certificatelor
digitale și integritatea acestora. In sens larg, CA reprezintă o organizație de încredere care oferă
securitate prin procesele de verificare și emitere a certificatelo r. Acestea, la rândul lor, au ca și
caracteristică principală asocierea la cerere a unei chei publice cu o anumită identitate.
Procesul de obținere a unui certificat urmărește trei etape. Inițial, o anumită entitate solicită
un certificat digital asociat identității sale și cheii publice care a fost generată anterior sub gruparea
unei perechi de chei. După verificarea informațiilor primite(identitatea și cheia privată asociată
celei publice ) și în urma îndeplnirii cerințelor, Autoritatea de Certificare emite certificatul digital.
În cazul unui schimb de informații, utiltatea certificatelor este una semnificativă. O entitate
participantă în schimbul de informații verfică aspectele pe care certific atul digital le conține, și,
bazându -se pe încrederea față de Autoritatea de Certificare, prezintă încredere și față de
componentele certificatului precum cheia publică pe care acesta o conține.
Autoritățile de Certificare au o structură ierarhică de tip arbore. Astfel, primu l CA este
considerat rădăcină și beneficiază de încredere deplină în fața altor entități. Acestea, la rândul lor,
dețin cheia publică a CA -ului rădăcină. Infrastructura de tip arbore este compusă din mai multe
nivele, astfel că Autorit atea de Certificare principală emite certificate pentru CA -urile subordonate,
iar aceste CA -uri pentru utilizatori.
Autoritatea de înregistrare (RA)
Așa cum a fost precizat anterior, înainte ca Autoritatea de Certificare să emită certificatul
digital, entitatea solicitantă este verificată. Această verificare este realizată de către Autoritatea de
înregistrare. Responsabilitatea acesteia cuprinde accept area cererilor de certificate de la clienți și
validarea entității solicitante pentru care urmează a se emite certificatul.
Servere de certificate
Serverul de certificate funcționează ca un depozit pentru informațiile publice. După
emiterea certificatelor de către CA, acestea sunt stocate si pot fi accesate public.
Atunci când informațiile sunt stocate, iar ulterior accesate, nu beneficiază de protecție prin
criptare. Datorită faptului că certificatele digitale conțin și o semnătură, acest l ucru garantează
integritatea lor. De aceea, informațiile sunt stocate în text clar, protecția fiind asigurată de către
semnătura digitală aplicată anterior.
Expirarea și revocarea certificatelor
Un certificat digital conține printre atributele sale și o perioadă de valabilitate. În momentul
în care această perioadă este depășită se consideră ca certificatul este expirat și, prin urmare, nu mai
poate fi utilizat.
Pe de altă parte, deși un certificat încă se află în perioada de valabilitate, pot exista si tuații
în care nu mai poate fi folosit. Spre exemplu, în cazul în care informațiile pe care le conține
certificatul nu mai sunt valabile sau cheia privată a fost compromisă, certificatul este revocat.
Pentru ca utilizatorii să poată verifica dacă un cert ificat a fost sau nu revocat, pe baza
modelului X.509 de certificat s -a creat o listă ce cuprinde toate certificatele digitale revocate. Sub
denumirea de Certificate Revocation List – CRL, această metodă oferă posibilitatea de verficare a
certificatelor în ainte de validare. În acest sens, înainte de a valida un nou certificat, trebuie verificat
dacă există sau nu în lista de certificate revocate.
2.2 Suita de protocoale IPSec
2.2.1 Caracteristici generale
În scopul securizării comunicațiilor la nivel de rețea, IPsec definește setul de protocoale și
algoritmi folosiți pentru criptarea traficului de date. Din punct de vedere al funcționalității, I PSec
este dezvoltat peste toate protocoalele de nivel doi și este transparent atât pentru aplicații, cât și
pentru utilizatori.
Beneficiile aduse de conceptul I PSec includ :
• confidențialitatea datelor – garantată prin util izarea tehnicilor criptografice;
• integritate – calcu lul sumei de verificare la fiecare capat de tunel sau a valorilor hash
pentru fiecare mesaj în parte;
• autentificare – identificarea surselor mesajelor prin utilizarea semnăturilor și a
certificatelor digitale;
• controlul accesului
IPSec este folosit în mod uzual pentru implementarea rețelelor virtuale private (VPN) între
două locații sau între un utilizator conectat la distanță și o rețea corporatistă , dar și în comunicațiile
end-to-end (de la un capăt la altul) sau host-to-host (între ut ilizatori).
Ca orice concept de securitate, I PSec prezintă atât avantaje, cât și dezavantaje. Printre
avantaje se enumeră implementarea unei căi de comunicații securizate, protejarea identității
rețelelor implicate în transferul de informații, dar și eficiența ridicată a protocolului de securitate.
Pe de altă parte, datorită faptului că traficul transportat este criptat, sistemul de detecție a
intruziunilor (IDS – Intrusion Detection System) nu îl poate detecta. De asemenea, în cazul apariției
unei erori singulare, întrea ga rețea este deconectată (nu oferă soluții de remediere care să prevină
întreruperea traficului).
Structura pachetelor care utilizează I PSec poate fi împărțită în cinci blocuri în funcție de
funcționalitatea fiecăruia, după cum urmează:
• Protocolul I PSec utilizat
• Confidențialitate (DES, 3DES)
• Integritate (MD5, SHA)
• Autentificare (chei secrete pre distribuite , semnături digitale)
• Grupu ri Diffie -Hellman
În funcție de modalitatea de securizare a pachetelor IP, în cadrul protocolului I PSec se pot
identifica două modalități de implementare și/sau funcționare:
1. Modul tunel
2. Modul transport
Ipsec – modul tunel
Funcționarea în modul tunel a protocolului IPSec presupune încapsularea întregului pachet
obținut la nivelul de rețea al stivei OSI, acest pachet devenind componenta de date (payload) a unui
nou pachet IP.
Această modalitate de implementare a protocolului este utilizată în rețele private virtuale în
care IPSec este configurat site -to-site. Modul de configurare și aplicabilitatea acestuia va fi desc risă
ulterior în cadrul studiului de caz.
La nivel teoretic, protocolul IPSec utilizează pachete IP încapsulate complet (pachete care
conțin și antetul IP adăugat la nivelul rețea). Antetele specifice IPSec sunt adăugate ulterior
antetului IP, astfel că s e va obține un nou pachet care , din acest moment , va fi considerat ca pachet
de date (payload). Pentru ca acesta să poată fi utilizat (transmis) în rețea, este necesară adăugarea
unui nou antet IP care să completeze payload -ul.
Procesul de creare a pachet ului IP în cazul utilizării modului tunel este descrisă de
următoarea schemă:
Antet TCP Date
Antet IP Original DATE
Antet IPSec DATE
Antet IP Nou Antet IPSec DATE
Figur a 1. Pachetul IP utilizat cu IPSec în modul tunel
Ipsec – modul transport
În cazul implementării IPSec în modul transport, antetul specific IPSec nu mai este adăugat
în fața pachetului IP original, ci este inserat în cadrul pachetului. Din acest motiv, nu se mai creează
un nou pachet IP ca în cazul modului tunel.
Aplicabilitatea modului de transport este evidențiată prin protec ția mesajelor (pachetelor de
date) care circulă prin nivelul de transport al stivei OSI.
Din punct de vedere funcțional, nivelul transport încapsulează datele pentru transmisiune și
le transmit e nivelului rețea. Ajuns la nivelul rețea, pachetul de date recepționat de la nivelul inferior
reprezintă payload -ul sau datele utile pentru datagrama IP ce va fi constituită la acest nivel.
În modul transport, ant etul corespunzător IPSec este aplicat doar acestui pachet, nu și
antetului IP adăugat la nivelul rețea, astfel că schema de implementare a IPSec în modul transport
este următoarea:
Antet TCP Date
Antet IP Original DATE
Antet IP Original Antet IPSec DATE
Figur a 2. Pachetul IP utilizat cu IPSec în modul transport
2.2.2 Proto coalele AH și ESP
IPSec oferă, în termeni generali, servicii securizate la nivelul rețea pentru alte protocoale
sau aplicații TCP/IP. Astfel, două echipamente care vor să comunice protejat, stabilesc un traseu
securizat între ele, traseu care poate străbate sisteme intermediare nesecurizate. O etapă important ă
în stabilirea căii securizate este reprezentată de alegerea unui set de protocoale de securitate. În
cadrul IPSec au fost definite două protocoale care stau la baza implementării comunicației
securizate, AH și ESP.
Protocolul AH
Protocolul AH (Authentication Header) oferă autentificarea serviciilor care funcționează cu
IPSec. În acest sco p, se dorește verificarea autenticității unei presupuse surse care transmite mesaje
în cadrul rețelei. De asemenea, are rolul de a se asigura că echipamentele intermediare nu au
modificat conținutul datagramei pe parcursul traseului.
Autentificarea cu ajutorul acestui protocol are scopul de a verifica fie întregul conținut al
unei datagrame, fie părți ale acesteia prin intermediul adăugării unui antet calculat pe baza valorilor
din cadrul pachetelor. Din punct de vedere func țional, protocolul AH utilize ază un algoritm special
de hashing și o cheie criptografică specifică ce au rolul de a identifica sursa/destinația sau
eventualele modificări ale pachetelor de date.
Protocolul AH poate fi folosit atât în modul transport, cât și în modul tunel. În modul
transport, structura cadrelor este următoarea, pornind de la pachetul de date original:
Antet TCP Date
Antet IP Original DATE
Antet IP Original Antet AH DATE
Figur a 3. Pachetul IP utilizat cu protocolul AH în modul transport
În modul tunel, structura pachetului care utilizează protocolul AH este următoarea:
Antet TCP Date
Antet IP Original DATE
Antet AH DATE
Antet IP Nou Antet AH DATE
Figur a 4. Pachetul IP utilizat cu protocolul AH în modul tunel
Se poate observa că în ambele moduri, transport și tunel, protocolul AH autentifică doar
payload -ul pachetului, nu și alte câmpuri variabile ale antetului IP precum TTL, offset sau
fanioane . Din aceste motive, dar și din cauza utilității, protocolul AH nu este folosit în cazul real,
alegându -se ca protocol de securitate IPSec protocolul ESP.
Protocolul ESP
Deoarece se dorește și asigurarea confidențialității pe lângă serviciul de autentificare,
soluția care oferă securitatea necesară în cadrul transportului datagramelor este implementată cu
ajutorul protocolului ESP (Encapsulating Security Protocol).
Protocolul ESP utilizează un algoritm de criptare ce combină datele corespunzătoare
datagramelor cu ajutorul unei chei criptografice pentru a asigura confidențialitatea. Ulterior,
pachetul este “reasamblat” și transmis la destinație, unde este decriptat cu ajutorul aceluiași
algoritm.
Structura protocolului ESP este asemănătoare cu a protocolului AH, dar câmpurile
corespunzătoare sunt utilizate într -un alt mod. În loc de a utiliza un singur antet, câmpurile sunt
împarțite în trei categorii:
• Antetul ESP – conține două câmpuri, indecșii parametrilor de securitate (SPI) și
numărul de secvență și este plasat în faț a datelor criptate. Locația sa depinde de modul
utilizat în cadrul IPSec, transport sau tunel.
• Atașamentul ESP – câmp plasat după datele criptate și care conține padding -ul utilizat
pentru alinierea datelor criptate. De asemenea, conține și câmpul corespunz ător
următorului antet pentru ESP.
• Autentificarea datelor ESP – conține o valoare de verificare a integrității (ICV).
Formatul antetului ESP din punct de vedere al câmpurilor utilizate este următorul:
0 31
Indecșii Parametrilor de Securitate (SPI)
Număr de secvență
ESP Payload (Date)
Padding
ESP Autentificare Date
Figur a 5. Antetul protocolului IPSec ESP
După cum se poate observa, SPI și numărul de secvență au 4 octeți, datele, padding -ul și, dacă
există, vectorul de inițializare au valori aleatoare. În cadrul padding -ului se regăsesc 2 elemente a
câte 8 biți – lungimea padding -ului și următorul antet/prot ocol.
Utilizarea protocolului ESP, se utilizează conform IPSec în modul transport sau în modul
tunel. În cazul utilizării modului transport, protocolul ESP este implementat astfel:
Figur a 6. Pachetul IP utilizat cu protocolul ESP în modul transport
Pentru cazul în care este utilizat modul tunel în cadrul protocolului ESP, se păstrează
ordinea de adăugare a câmpurilor în cadru, dar se respectă etapele de implementare ale modului
tunel. Astfel, câmpurile specifice ESP sunt inser ate în aceeași ordine, dar pachetul este încapsulat
cu ajutorul unui nou antet IP.
Structura pachetului în cadrul implementării modului tunel cu protocol ESP este
următoarea :
Figur a 7. Pachetul IP utilizat cu protocolul ESP în modul tunel
2.2.3 Protocoale de stabilire a cheilor secrete
Securizarea comunicațiilor prin utilizarea suitei de protocoale IPSec implică, pe lângă
stabilirea unui canal sigur de comunicații, utilizarea cheilor secrete în cadrul sesiunilor împreună cu
un protocol de schimb a acestor chei. Pentru a putea oferi participanților un protocol eficient de
schimb al cheilor secrete, este necesar ca acesta să îndeplinească următoarele aspecte:
• Să permită verificarea identității participanților pentru care sunt st abilite cheile secrete și să
asigure securitatea acestor chei din punct de vedere al unor entități neautorizate;
• Să permită autentificarea entităților participante și transportul securizat al cheilor pe canalul
de comunicație.
Soluțiile eficiente pentru implementarea comunicațiilor securizate combină diferite strategii
precum:
• Criptarea mesajelor din cadrul comunicațiilor folosind un algoritm de criptare simetrică și
utilizarea a câte unei chei diferite pentru fiecare mesaj;
• Asigurarea transportului secur izat al cheilor secrete prin utilizarea criptografiei la nivel de
chei publice;
• Utilizarea semnăturilor digitale ce au la bază cheia privată a transmițătorului pentru
autentificarea mesajelor și non -repudiere.
Din punct de vedere al protocoalelor utilizat e pentru stabilirea cheilor secrete, se pot
evidenția, în funcție de strategiile utiliza te în implementarea acestor a, următoarele protocoale:
1. Protocolul de schimb al cheilor Diffie -Hellman
2. Protocolul de schimb al cheilor bazat pe autentificare cu semnături
3. Protocolul de schimb al chelor bazat pe autentificare cu chei predistribuite si MAC
4. Protocolul de schimb al cheilor bazat pe criptografie cu chei publice
Protocolul de schimb al cheilor Diffie -Hellman
Schimbul de chei ce utilizează protocolul Diffie -Hellman permite participanților unei
comunicații care nu dețin informații unul despre celălalt să stabilească o cheie secretă distribuită pe
un canal de comunicații nesecurizat. Protocolul Diffie -Hellman se bazează pe problema
logaritmilor discreți (DLP – Discrete Logarithm Problem).
Se consideră un grup ciclic G de ordin q și un polinom generator g care aparține grupului G .
Modalitatea de obținere a cheilor secrete în cadrul protocolului Diffie -Hellman este următoarea:
1. Participantul A la comunicație alege o valoare aleatoare întreagă x și calculează 𝑿=𝒈𝒙
unde x reprezintă cheia privată, secretă a participantului, iar X cheia publică corespondentă.
Participantul A transmite valoarea X participantului B.
2. În mod similar, participantul B alege o valoare aleatoare întreagă y și calculează 𝒀=𝒈𝒚
unde y reprezintă cheia privată, secretă a participantului, iar Y cheia publică corespondentă.
Participantul B transmite valoarea Y participantului A.
3. A calculează cheia secretă distribuită 𝑲=𝒀𝒙=(𝒈𝒚)𝒙=𝒈𝒙𝒚. B obține aceeași valoare prin
calculul 𝑲=𝑿𝒚=(𝒈𝒙)𝒚=𝒈𝒙𝒚 .
Reprezentarea schematică a schimbului de chei utilizând protocolul Diffie -Hellman este
următoarea:
Figur a 8. Schimbul de chei în cadrul protocolului Diffie -Hellman
Protocolul de schimb al cheilor bazat pe autentificare cu semnături
Acest protocol de schimb al cheilor combină protocolul Diffie -Hellman prezentat anterior
cu protocolul de autentificare mutuală prin semnături. Prin această implementare, se asigură atât
confidențialitatea, cât și autenticitatea și independența cheilor.
Din punct de vedere al paramentrilor protocolului Diffie -Hellman, se utilizează tot
următoarele asumpții: grup ciclic G de ordin q și un polinom generator g care aparține grupului G .
În acest caz, în schimb, cheile obținute în urma procesului sunt autentif icate utilizând o schemă de
semnături digita le ce securizează comunicația împotriva atacurilor asupra mesajelor alese ( Chosen
Message Attacks ).
Modalitatea de obținere a cheilor secrete în acest caz este urm ătoarea:
1. Participantul A generează o pereche de chei DH și transmite către destinatarul B informația
ce conține identitatea sa împreună cu cheia publică DH corespondentă cheii private
calculate anterior.
2. Participantul B generează la rândul său perechea de chei DH, calculează semnătura
𝑺𝑰𝑮 𝑩=(𝑨 ||𝒀||𝑿) și le transmite participantului A.
3. Participantul A verifică semnătura lui B și răspunde cu semnătura 𝑺𝑰𝑮 𝑨=(𝑩 ||𝑿||𝒀).
Ulterior, A calculează cheia secretă 𝑲=𝒀𝒙=𝒈𝒙𝒚 .
4. Participantul B verifică semnătura lui A și calculează cheia secretă 𝑲=𝑿𝒚=𝒈𝒙𝒚.
Reprezentarea schematică a schimbului de chei utilizând protocolul de schimb al cheilor
bazat pe autentificare cu semnături este următoarea:
Figur a 9. Schimbul de chei în cadrul protocolului bazat pe autentificare cu semnături
Protocolul de schimb al cheilor bazat pe autentificare cu chei predistribuite și MAC
Acest protocol de schimb al cheilor are la bază criptografie sime trică utilizată pentru
transportul cheilor secrete. Pentru autentificare, se folosește o schemă MAC ce oferă securitate
împotriva atacurilor asupra mesajelor alese (CMA) .
Spre deosebire de protocoalele prezentate anterior, în acest caz participanții schim bă inițial
câte două chei, una utilizată pentru schema MAC, iar alta pentru schema de criptare simetrică.
Varianta cea mai eficientă de implementare a acestui protocol este cea în care se utilizează
algoritmul Diffie -Hellman pentru asigurarea securității redirecționării.
Parametrii specifici protocolului Diffie -Hellman sunt: grup ciclic G de ordin q și un
polinom generator g care aparține grupului G .
Modalitatea de implementare este următoarea:
1. Participantul A alege o valoare aleatoare x și un nonce (valoare arbitrară utilizată o singură
data într -o comunicație criptografică) și calculează cheia publică X, pe care o transmite
participantului B.
2. Participantul B alege o valoare aleatoare y și un nonce , calculează cheia publică Y și
transmite participantului A identitatea sa, nonce -ul ales, cheia publică, dar și valoarea MAC
obținută pe baza identității sale, a celor două nonce -uri și a cheilor publice.
3. Participantul A calculează la rândul său valoarea MAC utilizând același principiu.
4. Ulterior, se calculează cheile secrete pe baza cheilor predistribuite inițial și a unei funcții
pseudo -aleatoare.
Reprezentarea schematică a schimbului de chei utilizând protocolul de schimb al cheilor bazat
pe autentificare cu chei predistribu ite și MAC este următoarea:
Figur a 10. Schimbul de chei în cadrul protocolului bazat pe autentificare cu PSK și MAC
Protocolul de schimb al cheilor bazat pe criptografie cu chei publice
În cazul protocolului de schimb al cheilor bazat pe criptografie cu chei publice, se pornește
de la ipoteza că fiecare participant deține, inițial, o pereche de chei. Specific acestui protocol, se
consideră 𝑃𝐸𝐴(𝑟) ca fiind valoarea ob ținută în urma cri ptării șirului r cu cheia publică a
participantului A. Analog, 𝑃𝐸 𝐵(𝑟) reprezintă valoarea obținută în urma criptării șirului r cu cheia
publică a participantului B.
Funcționarea acestui protocol poate fi împărțită în două etape, după cum urmează:
1. Etapa de distribuire în care participanții stabilesc o cheie secretă K utilizând criptarea cu
chei publice. În această etapă, participantul A alege un șir aleator 𝒓𝑨 și transmite valoarea
𝑷𝑬 𝑩(𝒓𝑨) lui B. Analog, participantul B alege un șir aleator 𝒓𝑩 și transmite valoarea
𝑷𝑬 𝑨(𝒓𝑩) lui A. La final, fiecare participant decriptează șirul primit și calculează o cheie
secretă 𝑲𝟎=𝑯(𝒓𝑨||𝒓𝑩) utilizând funcția hash criptografică H.
2. Etapa de autentificare în care, după calcularea 𝑲𝟎 , participan ții confirm ă cunoașterea
secretului distribuit și se autentifică unul pe celălalt folosind valori “nonce ” aleatoare și
MAC.
Reprezentarea schematică a schimbului de chei utilizând protocolul de schimb al cheilor
bazat pe criptografie cu chei publice este următoarea:
Figur a 11. Schimbul de chei în cadrul protocolului bazat pe criptografie cu chei publice
CAPITOLUL 3 – REȚELE PRIVATE VIRTUALE (VPN)
3.1 Noțiuni generale
Rețelele private virtuale (VPN) reprezintă o modalitate de a simula rețele private care
folsesc infrastructuri publice precum Internetul pentru a realiza conexiuni securizate la distanță
(remote). O astfel de rețea utilizează căile corespunzătoare unei rețele publice, dar menține
securitatea și prote cția rețelelor private. Un aspect important al rețelelor VPN este reprezentat de
faptul că în cadrul acestora conexiunle sunt virtuale, temporare, deci nu ilustrează o prezență fizică
în topologia în care sunt configurate.
Reprezentarea schematică a unei rețele private virtuale este următoarea:
Figur a 12. Schema de bază a unei rețele private virtuale
Din punct de vedere al cerințelor unei rețele private virtuale, elementele de bază care
defines c acest concept sunt:
• Securitate prin asigurarea confidențialității, integrității și controlul accesului ;
• Calitatea Serviciilor (QoS): disponibilitate, performanță;
• Costuri reduse pentru instalare și operare .
Clasificarea rețelelor private virtuale
Rețelele private virtuale, denumite pe scurt VPN -uri, pot fi clasificate în două categorii,
după cum urmează:
1. Rețele private virtuale cu acces la distanță (remote)
2. Rețele private virtuale de tip Site -to-Site
3.1.1 Rețele private virtuale cu acces la distanță
Aceste tipuri de VPN -uri sunt utilizate pentru a conecta un utilizator la o rețea privat ă și a-i
oferi acces la resurse și servicii în mod remote (la distanță). În acest caz, conexiunea este realizată
prin intermediul unui furnizor de servicii de Internet, astfel că este necesară o con exiune privat ă și
securizată. Pentru a nu compromite securitatea datelor transferate prin intermediul canalului de
comunicație, se utilizează criptarea.
Rețelele de tip VPN cu acces remote sunt alcătuite din două componente: un server de acces
la rețea (N AS – Network Access Server) la care se conectează utilizatorul și care solicit ă în
momentul conectării autentificarea acestuia; și componenta software utilizată de clientul rețelei
pentru a se conecta la rețeaua privată. Această component ă software permite stabilirea și
menținerea conexiunii la VPN.
Structura unei rețele VPN cu acces la distanță este urmatoarea:
Figur a 13. Structura rețelei VPN cu acces la distanță
3.1.2 Rețele private virtuale de tip site -to-site
Rețelele VPN de tip site -to-site, denumite și router -to-router, sunt utilizate, în principal, în
cadrul corporațiilor care doresc conectarea diferitelor rețele care se află în arii geografice distincte.
Din punct de vedere ar conexiunilor realizate, rețe lele VPN site -to-site pot fi împărțite în
două categorii, astfel:
• Intranet bazat pe VPN
• Extranet bazat pe VPN
Rețelele Intranet bazat pe VPN conectează mai multe oficii ale aceleiași companii , utilizând
topologia site -to-site, pe când rețelele extranet bazat pe VPN au rolul de a conecta un oficiu al unei
companii la un oficiu sau mai multe oficii ale altei companii.
Similar rețelelor VPN cu acces la distanță, legăturile create între rețelele d istante geografic
sunt conectate prin intermediul furnizorului de servicii de Internet și mențin comunicația securizată
și privată.
Structura unei rețele VPN de tip site -to-site este prezentată în figura următoare:
Figur a 14. Structura rețelei VPN de tip site -to-site
3.2 Tunele GRE/mGRE
3.2.1 Tunele GRE
Un tunel GRE reprezintă o conexiune logică între două puncte ce corespund unei rețele
fizice. Mai exact, se creează o legătură virtuală care, în cazul unei rețele destul de mari, aduce
avantajul unui număr redus de p ași până la destinație.
Figura 15. Schematizarea funcționării tunelelor GRE
Tunelele GRE utilizează interfețe de tunel virtuale (VTI), în care rețeaua din spatele
acestora devine tra nsparen tă atunci când un tunel este configurat . Astfel, rețeaua peste care trec
tunelele se numește rețea underlay . Tunelul este construit deasupra re țelei underlay și, de aceea, se
numește rețea overlay .
Traficul este încapsulat când trece prin tunel. Astfel, sunt adăugate alte anteturi pentru
fiecare tunel în parte la fiecare pachet. Structură de bază a pachetului este următoarea:
IPintern PAYLOAD
Figura 16. Pachet IP original
În prima etapă, se adaugă antetul GRE care include informații despre traficul care este
transportat prin tunel. Cea mai importantă informație inclusă în acest antet este protocolul folosit de
pachetul inițial (IPv4/IPv6). Mai poate include chei de autentificare, dar și sume de verificare.
GRE IPintern PAYLOAD
Figura 17. Pachet IP la care se adaugă antetul GRE
Ulterior, se adaugă un alt antet IP . Acest ante t este folosit pentru a transporta pachetul peste
rețeaua underlay și folosește adresele IP reale ale routerelor pentru sursă și destinație.
IPextern GRE IPintern PAYLOAD
Figura 18. Pachetul IP obținut în urma încapsulării GRE
În timpul transportului prin tunelul GRE, pachetul original nu este modificat. Când se
ajunge la destinație , anteturile adiționale sunt eliminate, rămânând doar pachetul original
nemodificat. În continuare pachetul poate fi transportat la destinația finală.
Concluzionând cele prezentate anterior, se poate deduce faptul că tunelele GRE sunt tunele
punct -la-punct, astfel că, în continuare, va fi prezentat conceptul de tunel GRE multipunct, denumit
tunel mGRE.
3.2.2 Tunele mGRE
Tunelele mGRE sunt utilizate în cadrul unei topologii de tip hub -and-spoke pentru
configurarea routerului Hub. Astfel, în cadrul topologiei, conexiunile realizate prin tunel de către
routerul Hub vor folosi încapsulare mGRE , iar conexiunile spoke -to-spoke vor utiliza, în continuare
tunele GRE.
Un tunel mGRE simplifică dimensiunile configurațiilor, prezent ând avantajul că se poate
folosi o singură interfață GRE ce poate suporta mai multe tunele. Din punct de vedere constructiv,
o interfață mGRE este alcătuită din adresa IP corespunzătoare echipamentului pe care este
configurată, sursa tunelului și cheia tunelului.
Un aspect important al tunelelor mGRE este reprezentat de faptul că nu au o destinație,
astfel că nu pot fi folosite în mod solitar. Protocolul utilizat împre ună cu mGRE este NHRP (Next
Hop Resoluțion Protocol), protocol ce identifică următoarea destinație în cadrul comunicației.
Ca elemente principale ale NHRP, clientul de la următoarea destinație, NHC – Next Hop
Client, se înregistrează d inamic cu serverele u rmătoarelor destinații, NHS – Next Hop Server.
Pentru o topologie hub -and-spoke, NHC pot fi considerate routerele spoke, iar NHS routerul Hub.
Astfel, tunelele mGRE, de și nu au o destinație de sine stătătoare specificată, utilizează
protocolul NHRP pentru direcționarea pachetelor în cadrul comunicațiilor. Modalitatea de
încapsulare a pachetelor coincide ce cea din cazul tunelelor GRE, astfel că singura diferență pe care
o aduce implementarea tunelelor mGRE ține de simplificarea configurațiilor.
Din punct de vedere al funcționalității tunelelor mGRE în cadrul topologiilor hub -and-
spoke, aceasta poate fi descrisă de următoarea schemă:
Figura 19. Schematizarea funcționalitătii tunelelor mGRE
3.3 DMVPN
DMVPN (Dynamic Multipoint VPN) reprezintă o tehnică de rutare ce utilizează o
arhitectură centralizată prin care se oferă o implementare și o administrare facilă a rețelelor VPN.
De asemenea, prin utilizarea acesteia, se elimină necesitatea configurațiilor statice a
echipamentelor.
DMVPN se aplică pentru topologii de rețele hub -and-spoke și aduce avantajul comunicației
directe între echipamentele de tip spoke, fără a mai fi necesară traversarea echipamentului hub. Din
acest punct de vedere, se pot deosebi două tipuri de implementăr i ale DMVPN, după cum urmează:
DMVPN Hub -to-Spoke și DMVPN Spoke -to-Spoke .
3.3.1 Tehnologii utilizate în DMVPN
DMVPN funcționează prin combinarea mai multor tehnologii ce au ca scop final
implementarea unei topologii de rețea privată virtuală ușor de con figurat și administrat, ce aduce
avantaje evidente implementărilor tradiționale. Tehnologiile utilizate în cadrul DMVPN sunt
următoarele:
• Tunele GRE multipunct (mGRE);
• Protocolul NHRP ;
• Protocol de rutare dinamică (OSPF, EIGRP, BGP etc.) ;
• Criptarea datelor utilizând IPSec (optional) ;
• Protocolul CEF (Cisco Express Forwarding) .
Configurarea tunelelor GRE obișnuite, punct -la-punct, nu oferă o soluție scalabilă, astfel că
implementarea tunelelor mGRE aduce avantajul configurării unui singur tunel cu destinații
multiple. Se obține, prin aceasta, o reducere a configurațiilor. Existența unei singure interfețe care
administrează mai multe conexiuni reprezintă un aspect important al tehnicii DMVPN.
Deoarece , prin structura lor, tunelele mGRE nu prezintă informații e vidente despre
destinația fiecărei comunicații în parte, protocolul NHRP realizează procesul de identificare a
destinatarilor prin utilizarea modelului “server -clienți”. Astfel, problema lipsei de informații
privind adresele destinație ale mGRE este rezolv ată.
Pentru eliminarea configurărilor statice a rutelor dintre echipamente, se folosesc protocoale
de rutare dinamice precum OSPF care “învață” de la echipamentele vecine informații despre rețea,
actualizând dinamic tabelele de rutare și simplificând procesul de aflare a rutelor.
Criptarea datelor folosi nd protocolul IPSec este opțională, dar recomandată. Deoarece în
cazul DMVPN se poate vorbi despre două rețele diferite în cadrul unei singure topologii (rețea
underlay și rețea overlay), traficul care trece prin tunelele create pe deasupra furnizorului de servicii
este recomandat a fi criptat, astfel că se dorește obținerea unui transfer securizat de date.
3.3.2 Etapele (fazele) de implementare a DMVPN
Implementarea DMVPN se realizează în trei etape, fiecare dintre acestea aducând topologiei
scalabilitate și facilitate în administrare. Cele trei etape vor fi prezentate detaliat în continuare .
În cadrul primei etape DMVPN, scopul configurării este de a crea tunele hub -and-spoke ce
asigură comunicația î ntre fiecare echipament de tip spoke cu echipamentul hub. Această etapă
aduce dezavantajul faptului că pentru comunicația spoke -to-spoke este necesară traversarea
echipamentului hub, astfel că timpul de transfer al pachetelor este ridicat. Totodată, prin traversarea
echipamentului Hub, este transmisă întreaga tabelă de rutare de la Hub către Spoke, ceea ce
reprezintă o soluție ineficientă.
Pentru exemplificare, vom considera cazul în care echipamentul Spoke 1 dorește să
comunice cu echipamentul Spoke 3. În acest caz, conform schemei următoare, comunicația nu
poate avea loc direct, astfel că este necesară traversarea echipamentului Hub.
Reprezentarea schematică a primei etape DMVPN este ilustrată în următoarea figură:
Figura 20. Reprezentare schematică. Etapa I DMVPN
Cea de a doua etapă din cadrul implementării DMVPN este reprezentată de cre area
tunelelor spoke -to-spoke la cerere, evitându -se astfel traversarea echipamentului Hub în cazul
comunicației între două echipamente de tip Spoke. Realizarea conexiunii Spoke -to-Spoke este
posibilă prin utilizarea protocolului NHRP care funcționează pe principiul “cerere -răspuns” și la
finalul căruia, ulterior transmiterii informației de mapare, este posibilă crearea tunelului direct într e
echipamentele de tip spoke.
Figura 21. Reprezentare schematică. Etapa II DMVPN
Ultima etapă din cadrul configurării DMVPN aduce scalabilitate soluției prezentate în cea
de a doua etapă și prezintă configurație mGRE pe echipamentul Hub și tunele mGRE pe
echipamentele spoke.
Tunele le între echipamentele de tip spoke sunt realizate, în cont inuare, la cerere, diferența
față de cea de a doua etapă fiind reprezentată de faptul că în momentul primirii unei cereri NHRP
de către echipamentul Hub, acesta redirecționează cererea către echipamentul spoke aflat la
distanță, împreună cu solicitarea de actualizare a tabelei de rutare.
De această dată, este permisă și rutarea implicită, astfel că indiferent dacă tabela de rutare
indică echipamentul Hub ca fiind următoarea destinație, traficul circulă direct între cele două
echipamente de tip Spoke.
De această data, se consider situația în care echipamentul Spoke 1 dorește să
comunice cu echipamentul Spoke 2. Pentru aceasta, inițial se realizează traversarea
echipamentului Hub, dar acesta, la rândul său, redirecționează cererea către echipamentul
Spoke 2. Astfel, după actualizarea tabelei de rutare a echipamentului Spoke 1, comunicația
Spoke 1 – Spoke 2 se poate realiza direct.
Repre zentarea schematică a celei de a treia etapă a DMVPN este următoarea:
Figura 22. Reprezentare schematică. Etapa III DMVPN
CAPITOLUL 4 – PROTOCOLUL IKEv2 (Internet Key Exchange version 2)
4.1 Aspecte generale
Protocolul IKEv2 (Internet Key Exchange version 2) este un protocol de schimb de chei în
Internet utilizat în cadrul rețelelor private virtuale. IKEv2 a apărut ca o îmbunătățire față de
versiunea anterioară, IKEv1, și ca aspect de bază, acest protocol poat e fi descris ca o soluție de
autentificare folosind chei predistribuite, certificate sau EAP (Extensible Authentication Protocol).
IKEv2 este utilizat în cadrul topologiilor pentru stabilirea Asociațiilor de Securitate (SA),
iar implementarea sa are ca sc op securizarea comunicațiilor care se desfășoară utilizând un furnizor
de servicii de Internet. Ca principiu de funcționare, acest protocol folosește două “strângeri de
mână”, principiu denumit în rețelistică “handshake”, utilizând modelul cerere -răspuns.
Protocolul IKEv2 face parte din suita de protocoale IPSec, astfel că implementările sale sunt
bazate pe structura IPSec, preluând funcționalitățile sale și conlucrând cu acesta. Astfel, putem
spune că IKEv2 este responsabil de stabilirea tunelelor securiz ate de comunicații între un client
VPN și un server VPN.
În cadrul implementării, IKEv2 urmărește , pe lângă stabilirea Asociațiilor de Securitate și a
autentificării prin diferite metode, ascunderea identității participanților la comunicație din punct de
vedere al unui atacator pasiv, dar și recodificarea Asociațiilor de Securitate sau a cheilor folosite în
cadrul comunicației.
IKEv2 este un protocol rapid care oferă, de asemenea, securitate de nivel înalt. În plus,
oferă avantajul restabilirii rapide a conexiunii în cazul modificărilor ce pot apărea la nivel de rețea.
Modalitatea de implementare a IKEv2 este simplă, după cum va fi prezentat în continuare.
4.2 Schimburi IKEv2
În cazul protocolului IKEv2, implementarea se bazează pe diferite schimburi între
participanții la comunicație. Pot fi deosebite, astfel, trei etape în cadrul configurării:
• Schimburi inițiale (IKE_SA_INIT și IKE_AUTH) ;
• CREATE_CHILD_SA;
• INFORMATIONAL.
Fiecare dintre aceste etape va fi prezentată detaliat în continuare, urmărind evidențierea
aspectelor esențiale, dar funcționalitatea acesteia.
4.2.1 Schimburi inițiale
În cadrul schimburilor inițiale, sunt realizate schimburile de mesaje IKE_SA_INIT și
IKE_AUTH. Spre deosebire de următoarele etape, schimburile din cadrul celei curente trebuie
realizate într -o ordine exact ă, strictă deoarece implementarea corectă a acestora are la bază
interdependența dintre ele.
Primul schimb, IKE_SA_INIT, are rolul de a negocia algoritmii criptografici folosiți în
continuare pentru stabilirea Asociațiilor de Securitate și de a schimba valori Diffie -Hellman și
valori unice “nonce”.
Schimbul de mesaje din cadrul IKE_SA_INIT este reprezentat de următoarea schemă:
Figur a 23. Schimbul IKE_SA_INIT din cadrul IKEv2
Primul mesaj este reprezentat de o cerere din partea inițiatorului și este alcătuit din
următoarele câmpuri:
• HDR – Antet specific protocolului IKEv2 alcătuit din indecșii parametrilor de securitate
SPI, numărul de versiune și diferite fanioane specifice.
• SAi1 – Propunerea inițiatorului legată de protocoalele IPSec și algoritmii criptografici pe
care îi poate utiliza în procesul de stabilire a Asociațiilor de Securitate
• KEi – Key Exchange – valoarea Diffie -Hellman corespunzătoare inițiatorului;
• Ni – valoare “nonce” corespunzătoare inițiatorului ce reprezintă un număr arbitrar ce poate
fi folosit o singură data în cadrul unei comunicații criptografice
Mesajul de răspuns are o structură asemănatoare cererii, fiecare dintre câmpuri având
următoarele semnificaț ii:
• HDR – Antet specific IKEv2;
• SAr1 – Suita criptografică aleasă de către respondent dintre propunerile inițiatorului SAi1;
• KEr – valoarea Diffie -Hellman corespunătoare respondentului; odată cu aceasta, se
completează schimbul DH;
• Nr – valoare “nonce” co respunzătoare respondentului;
• CERTREQ – câmp optional ce reprezintă o solicitare de certificate = Certificate Request;
În urma schimbului celor două mesaje cerere -răspuns, fiecare participant la comunicație
poate genera SKEYSEED, folosit ulterior în genera rea cheilor necesare stabilirii SA. Valoarea
SKEYSEED este calculat ă cu ajutorul unei funcții pseudo -aleatoare, denumită pe scurt PRF
(Pseudo Random Function) și are următoarea formulă:
𝑺𝑲𝑬𝒀𝑺𝑬𝑬𝑫 =𝑷𝑹𝑭 (𝑵𝒊|𝑵𝒓,𝒈𝒊𝒓),
unde variabilele funcției pseudo -aleatoare sunt cele două valori “nonce” corespunzătoare
inițiatorului și respondentului și valoarea Diffie -Hellman secretă, calculată pe baza KEi și KEr.
Cheile utilizate pentru criptare și asigurarea integrității sunt derivate din SKEYSEE D și sunt
diferite pentru fiecare în parte (SK_e pentru criptare și SK_a pentru autentificare). De asemenea , se
calculează chei diferite pentru fiecare direcție din cadrul comunicației.
Ulterior calculului cheilor, mesajele transmise în continuare sunt protejate, conținutul lor
fiind criptat, urmând ca participanții sa fie autentificați, asigurându -se, astfel, integritatea mesajelor
din cadrul comunicației.
Cel de -al doilea schimb de mesaje, IKE_AUTH, are rolul de a interschimba identită țile
participanț ilor la comunicație și, op țional, și certificate. În cadrul acestui schimb se realizează
autentificarea entităților prin utilizarea fie a cheilor predistribuite (PSK) prin MAC, fie a
semnăturilor digitale aplicate certificatelor.
Mesajele din cadrul IKE_AUTH sunt ilustrate în următoarea schemă:
Figura 24. Schimbul IKE_AUTH din cadrul IKEv2
Primul mesaj este reprezentat de cererea IKE_AUTH a inițiatorului și este alcătuită din
următoarele câmpuri:
• HDR – Antet specific IKEv 2;
• IDi – identitatea inițiatorului în cadrul comunicației;
• CERT – câmp optional ce cuprinde certificatele corespunzătoare inițiatorului;
• CERTREQ – câmp optional ce cuprinde punctele de încredere asociate inițiatorului;
• IDr – câmp optional ce conține identi tatea respondentului cunoscută de către initiator;
• AUTH – confirmarea protejării integrității primului mesaj;
• SAi2 – propunerile legate de protocoalele IPSec și algoritmii criptografici utilizați în
stabilirea primului Child SA.
• TSi, TSr – selectori de trafic corespunzători inițiatorului și respondentului ce au rolul de a
identifica fluxuri de pachete necesare procesării de către servicii IPSec.
Mesajul IKE_AUTH corespunzător răspunsului conține următoarele câmpuri împreună cu
semnificațiile lor:
• HDR – Antet specific IKEv2;
• IDr – identitatea asumată a respondentului;
• CERT – câmp optional ce poate conține certificatele deținute de către respondent;
• AUTH – confirmarea protejării integrității;
• SAr2 – suita criptografică aleasă de către respondent;
• TSi, TSr – selectori de trafic;
În urma completării schimbului IKE_AUTH, se poate considera finalizat procesul de
stabilire a Asociației de Securitate IKE SA și a primei entități Child SA. Tot în cadrul acestei etape
se realizează și veri ficarea corectitudinii semnăturilor și a MAC. Pentru entitatea Child SA stabilită
în urma schimburilor inițiale, cheile criptografice respect ă algoritmul utilizat anterior pentru
generarea cheilor necesare IKE, de această dat ă cheile fiind denumite SK_d.
4.2.2 CREATE_CHILD_SA
Etapa ulterioară schimburilor inițiale este reprezentată de schimbul CREATE_CHILD_SA
și are rolul de a stabili o entitate Child SA adițională pentru Asociația de Securitate creată anterior.
De asemenea, tot în cadrul acestui schimb pot fi efectuate recodificări ale Asociației de Securitate și
ale Child SA prin crearea unor entități noi și stergerea celor precedente.
În cadrul schimbului de față, mesajele de tip cerere -răspuns sunt caracterizate de un singur
schimb (două mesaje), com parativ cu schimburile inițiale în care numărul mesajelor schimbate era
de patru.
Un aspect important al acestei etape este reprezentat de faptul că schimbul poate fi inițiat de
oricare dintre cei doi participanți la comunicație. Astfel, respondentul poat e solicita inițierea
schimbului CREATE_CHILD_SA, fără a afecta funcționalitatea protocolului.
Cele două mesaje din cadrul CREATE_CHILD_SA sunt prezentate în următoarea schemă:
Figura 25. Schimbul CREATE_CHILD_SA din cadrul IKEv 2
Cererea trimisă de către initiator (sau responden t prin inversarea rolurilor) este alcătuită din
următoarele câmpuri:
• HDR – Antet specific IKEv2;
• N – câmp optional ce poate conține diferite notificări;
Un exemplu de notificare transmisă în cadrul cererii CREATE_CHILD_SA este
reprezentată de utilizarea în cadrul comunicației a modului transport în loc de cel implicit, tunel. În
cazul în care această cerere este acceptată, în cadrul mesajului de răspuns trebuie să existe o
notificare cu privire la mo dul de securizare utilizat.
• SA – propunerile criptografice împreună cu cele legate de protocoalele IPSec;
• Ni – valoare “nonce”;
• KEi – câmp opțional ce poate conține o nouă valoare DH;
• TSi, TSr – câmpuri opționale ce conțin selectori de trafic.
Mesajul as ociat respondentului are o structură similar ă și este alc ătuit din:
• HDR – Antet specific IKEv2;
• SA – propunerea criptografică aleasă de către respondent;
• Nr – valoare “nonce”;
• KEr – câmp opțional ce poate conține o nouă valoare DH;
• TSi, TSr – câmpuri opți onale ce conțin selectori de trafic;
Protocoalele IPSec AH și ESP utilizate în cadrul acestei etape pot coexista, astfel că
schimbul CREATE_CHILD_SA poate stabili perechi de Asociații de Securitate bazate pe ESP, AH
sau ESP+AH.
Pentru calcului cheilor corespunzătoare noilor Asociații de Securitate se utilizează același
principiu ca în cazul IKE în care cheile sunt calculate pe baza SK_d și a noilor valori “nonce”
schimbate în cadrul mesajelor.
În cazul în care la nivelul acestei etape sunt realizate recodificări ale Asociațiilor de
Securitate sau ale cheilor, structura mesajelor transmise este diferită, după cum urmează:
Figura 26. Recodificarea Asociației de Securitate în cadrul schimbului CREA TE_CHILD_SA
Pentru situația în care se dorește recodificarea Asociației de Securitate, inițiatorul transmite
în cadrul solicitării noile propuneri criptografice în câmpul SA, o valoare unică „nonce” în câmpul
Ni și, de această dată, obligatoriu, o valoar e nouă Diffie -Hellman în câmpul KEi. In momentul
primirii cererii de către celălalt participant la conversație, prin înștiințarea de recodificare a SA –
ului, nu este recomandată inițierea altor schimburi CREATE_CHILD_SA.
Ca și răspuns al cererii inițiatoru lui, respondentul transmite în mesajul său propunerea
criptografică acceptată, valoarea „nonce” și valoarea DH.
Un aspect important al recodificării Asociațiilor de Securitate este reprezentat de faptul că
indecșii parametrilor de securitate SPI sunt rei nițializați, astfel că numărătoarele noii Asociații de
Securitate sunt și e le reinițializa te, fără a mai ține cont de valorile pe care le aveau anterior.
Recodificarea entităților Child SA respectă o structură diferită față de cea a mesajelor din
cadrul recodificării Asociațiilor de Securitate, după cum urmează:
Figura 27. Recodificarea Child SA în cadrul schimbului CREATE_CHULD_SA
De această dată, la recodificarea Child SA, se remarcă faptul că cererea conține o notificare
REKEY_SA ce are rolul de a anunța că schimbul asociat cererii include și înlocuirea antetelor
IPSec AH sau ESP a Asociațiilor de Securitate. De asemenea, transmiterea valorilor Diffie –
Hellman devine opțională, in schimb este obligatorie includerea în cadru l mesajelor a selectorilor
de trafic TSi și TSr.
4.2.3 INFORMATIONAL
Ultimele schimburi din cadrul implementării protocolului IKEv2 sunt reprezentate de
schimburi informaționale, denumite sugestiv INFORMATIONAL. Utilitatea lor este cea a
necesității transmiterii mesajelor de control care pot indica erori sau notificări desp re anumite
evenimente apărute pe parcursul desfășurării procesului.
Mesajele informaționale sunt, la rândul lor, de trei tipuri : notificare, ștergere și configurare.
Pentru identificarea fiecăruia dintre ele, în cadrul mesajelor sunt utilizate abrevieril e N-Notificare,
D-Ștergere și CP -Configurare.
Mesajele de notificare contin erori și informații despre statusul curent. Mesajele de ștergere
informează participantul despre faptul că inițiatorul mesajului a eliminat una sau mai multe
Asociații de Securitate. Mesajele de configurare sunt utilizate pentru aspecte legate de configurarea
datelor între participanții la comunicație.
Structura schematică a schimbului INFORMATIONAL este următoarea:
Figura 28. Schimbul INFORMATIO NAL din cadrul IKEv2
4.3 Aspecte privind securitatea protocolului IKEv2
În scopul lucrării de față au fost analizate aspecte legate de securitatea protocolului IKEv2
atât în etapele de implementare, cât și în situații de funcționare a acestuia. Deși IKEv2 este un
protocol relativ recent, au fost identificate diferite vulnerabilități care pot duce la succesul unui atac
din exterior asupra rețelei.
Aspectele analizate cuprind caracteristici criptografice utilizate în cadrul IKEv2, precum
generarea cheilor s ecrete și schimbul acestora între participanți, importanța funcțiilor pseudo –
aleatoare și modul în care acestea oferă securitate ridicată protocolului. De asemenea, autentificarea
participanților a fost un alt criteriu analizat din punct de vedere al secur ității, dar și aspecte legate
de transportul pachetelor în rețea.
În continuare, vor fi prezentate aspectele analizate, vulnerabilitățile protocolului IKEv2
identificate și soluțiile care există în momentul de față pentru înlăturarea acestor vulnerabilită ți.
→ Ca și aspect definitoriu al protocolului IKEv2, în cadrul schimburilor inițiale unul dintre
participanții la comunicație trebuie să se identifice prin prezentarea identității sale. De
asemenea, acesta este și participantul care se autentifică primul î n cadrul comunicației. Mesajul
conține, astfel, identificatorul participantului, câmpul de autentificare și, optional certificatele
deținute împreună cu punctele de încredere asociate acestuia .
Vulnerabilitate : Un atacator care se află sub identitatea respondentului poate afla nu numai
identitatea inițiatorului, ci și certificatele pe care acesta dorește să le folosească.
Soluție : Protocolul EAP, prin funcționalitatea sa, solicită identificarea inițială a resp ondentului,
astfel ca identitatea acestuia poate fi verificată în avans, înainte de a transmite acestuia identitatea și
certificatele sale.
→ În timpul funcționării protocolului IKEv2, autentificarea prin utilizarea credențialelor este
utilizată în cadrul i nițierii conexiunilor. În momentul în care un utilizator introduce o parolă, se
aplică o funcție hash, iar rezultatul obținut este comparat cu o valoare hash stocată anterior.
Vulnerabilitate : Utilizarea unor parole cu un grad scăzut de complexitate poate duce la aflarea
acestora în cazul în care un presupu s atacator utilizează atacuri asupra parolelor (ex. Atac de
dictionar)
Soluție : Alegerea parolelor cu un grad foarte ridicat de complexitate poate împiedica succesul
atacurilor initiate de diferiți atacat ori, făcând dificilă aflarea parolelor.
→ În cadrul schimbului CREATE_CHILD_SA pot fi efectuate recodificări ale entităților Child
SA. Acestea au loc la fiecare solicitare din partea unuia dintre participanți, astfel că un Child
SA poate fi recodificat de mai multe ori.
Vulnerabilitate : În structura mesajelor care corespund recodificării Child SA schimbul de valori
Diffie -Hellman nu este obligatoriu, câmpul KE fiind opțional. Recodificarea repetată poate face ca
Asociația de Securitate să devină vulnerabilă criptanalizei, în condiția în care se utilizează o singură
cheie.
Soluție : Limitarea numărului de recodări poate elimina posibilitatea criptanalizei.
→ Una dintre variantele de implementare a protocolului IKEv2 folosește principiul cheilor pre –
distribuite (PSK). La nivel criptografic, cheile au la bază șiruri de valori aleatoare și valori
arbitrare “nonce”, așa cum au fost descri se în capitolul 3.
Vulnerabilitate : Un grad de aleatorizare scăzut al valorilor utilizate pentru obținerea cheilor poate
introduce vulnerabilități ale cheilor secrete. Spre exemplu, obținerea informațiilor secrete utilizând
la bază nume, parole sau alte entități previzibile pot face ca inf ormațiile secrete să devină
predispose la atacuri.
Soluție : Pentru eliminarea vulnerabilității, este necesar ca gradul de aleatorizare să fie ales astfel
încât cheia obținută să prezinte cel mai înalt grad de securitate.
→ În cazul stabilirii cheilor secrete sunt utilizate schimburi Diffie -Hellman. La nivel de
configurați, se stabilește ce grup DH este utilizat, fiecare grup având ca și caracteristici
dimensiuni diferite ale exponenților și valori aleatoare diferite.
Vulnerabilitate : Gradul de securitate a un ei chei obținute în urma schimburilor Diffie -Hellman
este puternic influențat de grupul ales, dar și capacitățile generatorului de valori aleatoare. Astfel, o
cheie poate deveni vulnerabilă atacurilor dacă grupul DH ales nu este sufiecient de puternic sau
capacitatea generatorului de valori aleatoare este redusă.
Soluție : Explorarea soluțiilor oferite și alegerea grupurilor Diffie -Hellman care prezintă un modul
cu un număr ridicat de biți. De asemenea, utilizarea unui anumit grup DH cu un algoritm de
criptare eficient scade posibilitatea succesului unui atac asupra cheii secrete.
→ Pentru stabilirea cheilo r secrete în cadrul IKEv2 sunt utilizate funcții pseudo -aleatoare care pe
baza valorilor Diffie -Hellman și a valorilor “nonce” calculează SKEYSEED -ul necesar în
stabilirea Asociațiilor de Securitate.
Vulnerabilitate : Gradul de securitate al cheilor secrete este puternic influențat de dimensiunea
valorilor rezultate în urma aplicării funcțiilor pseudo -aleatoare. O dimensiune redusă a rezultatului
(mai mic de 128 biți), împreună cu un algoritm de criptare ce are o eficiență redusă pot determina
un grad scăzut de securitate al cheii secrete, aceasta devenind vulnerabilă.
Soluție : Utilizarea funcțiilor pseudo -aleatoare cu rezultat de dimensiuni ridicate, împreună cu un
algoritm de criptare eficient (ex. AES -CBC).
→ Protocolul IKEv2 folosește ca o modalitate de im plementare infrastructura pentru chei publice,
implicit certificatele digitale pentru securizarea comunicațiilor, introducând, astfel, o terță parte
de încredere.
Vulnerabilitate : Utilizarea certificatelor digitale în cadrul comunicației determină creșterea
dimensiunii mesajelor în schimburile corespunzătoare IKEv2. Mesajele de dimensiuni prea lungi
necesită fragmentarea la nivel IP, astfel că atacatorii pot opri completarea schimburilor prin
eliminarea zonelor libere de memorie.
Soluție : Utilizarea codărilor Hash sau URL în locul transmiterii certificatelor.
→ Un aspect important este reprezentat de faptul că în cadrul schimburilor inițiale, ordinea
mesajelor trebuie respectată, astfel că după un mesaj IKE_SA_INIT este necesar sa se transmită
un mes aj IKE_AUTH.
Vulnerabilitate : Un atacator care dorește să introduc ă un atac de tipul DDOS poate transmite
continuu un număr mare de mesaje IKE_SA_INIT fără a transmite și mesaje IKE_AUTH. Astfel,
sistemul este obligat să utilizeze resurse pentru administrarea lor, ajungând să le epuizeze.
Soluție : Introducerea unor siste me de tip ceas care să permită așteptarea doar pe o anumită
perioadă a mesajului IKE_AUTH după ce mesajul IKE_SA_INIT a fost transmis. Dacă perioada
este depășită, memoria alocată anterior este eliberată.
CAPITOLUL 5 – ANALIZA SECURITĂȚII ȘI APLICAȚII ÎN SERVICII IPSec
5.1 Configurații de bază pentru studiul de caz
În cadrul studiului de caz care se propune a fi elaborat, a fost aleasă o topologie alcătuită din
unsprezece routere care alcătuiesc următoarea structură:
• Furnizor de Servicii (SP – Service Provider), situat central în cadrul topologiei și alcătuit din
trei routere denumite sugestiv SP1, SP2, respectiv SP3;
• Rețele Private Virtuale (VPN – Virtual Private Network), în număr de patru, alcătuite
fiecare din două routere;
Structura topologiei este de tipul hub -and-spoke în care una dintre rețelele VPN a fost
aleasă ca Hub, iar restul ca entități Spoke. Denumirile echipamentelor au fost alese sugestiv pentru
a ilustra topologia rețelei (H – Hub, S -Spoke). Echipamentele care conectează rețeaua furnizorului
de servicii cu fiecare dintre rețelele private au fost evidențiate prin atribuirea statutului de
echipament marginal (denumiri de tipul HE și SE, unde E -Edge/Margine).
Din punct de vedere al adreselor utilizate în cadrul topologiei, p entru rețelele private au fost
alese adrese de tipul 3.3.x.0/24 , unde x reprezintă numărul rețelei. Pentru rețeaua furnizorului de
servicii, dar și rețelele care leagă rețelele private de cea publică au fost alese adrese de tipul
2.3.1.y/30 , cu câte două h osturi pe rețea, fiind utilizat un număr total de 14 adrese pentru definirea
acestora.
Fiecărui echipament i -a fost a locată câte o adresă de loopback , care în cadrul rețelelor
private are forma 192.168.255.k/0 , iar pentru rețeaua furnizorului de servicii au fost alese distinctiv
5.5.5.5/0 , 6.6.6.6/0 , respectiv 7.7.7.7/0.
Topologia utilizată, împreună cu denumirile echipamentelor și adresele IP asignate pot fi
vizualizate în următoarea schemă:
Figura 29. Topologia utilizată în cadrul studiului de caz
5.1.1 OSPF
Protocolul de rutare ales pentru topologia de față este OSPF (Open Shortest Path First).
OSPF este de tip IGP -Interior Gateway Protocol, orientat pe starea legăturilor – link-state protocol.
Scopul acestui protocol de rutare este ca routerele implicate să “învețe” informațiile cunoscute de
vecinii săi, iar la final fiecare dintre ele să cunoască ace leași informații ca și celelalte.
Procesul de învățare se realizează prin intermediul unor notificări de stare a legăturilor
(LSA – Link -State Advertisments) ce conțin, în principal, informații despre subrețelele asociate și
despre routerele implicate. După ce aceste notificări sunt transm ise, OSPF păstrează informațiile
într-o bază de date LSDB – Link -State Database. Astfel, rezultatul final al acestui protocol de
rutare este ca LSDB -urile din cadrul topologiei să conțină aceleași informații.
În cadrul topologiei, protocolul OSPF a fost co nfigurat, pe de -o parte în cadrul rețelei
furnizorului de servicii (Service Provider), iar pe de altă parte în rețeaua privată virtuală.
Implementarea protocolului urmărește trei etape, după cum urmează:
1. Crearea relațiilor de vecinătate;
2. Schimbul informați ilor conținute în bazele de date LSDB;
3. Alegerea celor mai bune rute;
Analiza implementării practice a fiecărei etape a fost realizată pe baza capturilor obținute cu
ajutorul programului Wireshark în comparație cu noțiunile teoretice standardizate.
1.Crearea relațiilor de vecinătate
După configurarea protocolului OSPF pe fiecare echipament în parte, routerele stabilesc
relații de vecinătate prin intermediul a trei mesaje de tip “HELLO”.
No Time Source Destination Protocol Length Info
34 21.881048 3.3.1.1 224.0.0.5 OSPF 118 Hello Packet
36 25.944046 3.3.2.1 224.0.0.5 OSPF 118 Hello Packet
40 31.017011 3.3.1.1 224.0.0.5 OSPF 118 Hello Packet
44 35.392071 3.3.2.1 224.0.0.5 OSPF 118 Hello Packet
Inițial, routerul cu adresa IP 3.3.1.1 trimite mesajul ce conține identificatorul
echipamentului, vecinii pe care deja îi cunoaște, dar și alte informații adiționale. Routeru l cu adresa
IP 3.3.2.1 analizează informațiile primite și efectuează verificări, după care trece în starea INIT
STATE și trimite un mesaj de tip “HELLO” prin care îl declară pe routerul cu adresa 3.3.1.1 ca
fiind vecin. Acesta, la rândul său, trece în star ea 2-WAY STATE și transmite încă un mesaj de tip
“HELLO” prin care își anunță noul vecin. La final, și routerul cu adresa 3.3.2.1 trece în starea 2 –
WAY STATE.
În cadrul rețelei furnizorului de servicii, se pot observa pe fiecare dintre cele trei routere
constituente vecinii cunoscuti.
SP1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
7.7.7.7 1 FULL/DR 00:00:38 2.3.1.10 FastEthernet3/0
6.6.6.6 1 FULL/DR 00:00:32 2.3.1.6 FastEthernet0/0
Identificatorii routerelor au fost aleși conform principiului ca fiind adresele de loopback ale
echipamentului.
În mod simiar, apelând aceeași comandă pe routerele ce fac parte din rețeaua privată
virtuală, se pot observa relațiile de vecinătate:
SE1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.255.21 0 FULL/ – 00:00:31 3.3.2.1 Tunnel1
192.168.255.12 1 FULL/DR 00:00:33 3.3.1.2 FastEthernet0/0
2.Schimbul de informații
Pentru a efectua schimbul de informații, routerele trec în starea EXSTART STATE, iar pe
baza identificatorului fiecăruia se stabilește un master și un slave. Ulterior, se trece în starea
EXCHANGE STATE în care ambele routere schimbă liste cu LSA -uri sub forma unor baze de date
denumite DBD – Database Descr iption.
În ultima parte a acestei etape, routerele trec în starea LOADING STATE în care fiecare
echipament analizează baza de date primită și solicit ă vecinului informațiile pe care nu le deține.
Pentru aceasta, se transmite ca cerere un LSR – Link State Request și se primește ca răspuns un
LSU – Link State Update. La final, se primește confirmarea schimbului printr -un LSA – Link State
Acknowledgement.
No Time Source Destination Protocol Length Info
17 12.463003 3.3.1.1 224.0.0.5 OSPF 94 LS Request
18 12.473003 3.3.1.1 224.0.0.5 OSPF 102 DB Description
19 12.548003 3.3.2.1 224.0.0.5 OSPF 134 LS Update
20 12.558003 3.3.2.1 224.0.0.5 OSPF 94 LS Request
21 12.632001 3.3.1.1 224.0.0.5 OSPF 134 LS Update
22 13.113006 3.3.1.1 224.0.0.5 OSPF 146 LS Update
23 13.206051 3.3.2.1 224.0.0.5 OSPF 146 LS Update
25 15.120482 3.3.1.1 224.0.0.5 OSPF 102 LS Acknowledge
26 15.194006 3.3.2.1 224.0.0.5 OSPF 122 LS Acknowledge
3.Alegerea celor mai bune rute
Se realizează prin folosirea unei metrici numite “cost”. În cadrul OSPF, costul reprezintă o
valoare egală cu raportul dintre banda de referință și banda interf eței folosite. Pentru verificarea
implementării cu succes a protocolului OSPF, se poate apela comanda show ip route ospf. Se pot
observa următoarele:
– Rutele învătate sunt de tipul OSPF;
– Routerul știe să ajungă la orice alt client din cadrul rețelei private virtuale;
– Se cunosc distanțele administrative ale OSPF;
– Au fost calculate costurile OSPF pentru fiecare rută în parte;
SE1# show ip route ospf | begin Gateway
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
3.0.0.0/8 is variably subnetted, 5 s ubnets, 2 masks
O 3.3.2.0/24 [110/1001] via 3.3.2.1, 00:15:56, Tunnel1
O 3.3.3.0/24 [110/2001] via 3.3.2.1, 00:15:46, Tunnel1
O 3.3.4.0/24 [110/2001] via 3.3.2.1, 00:15:56, Tunnel1
192.168.255.0/32 is subnetted, 8 subnets
O 192.168.255.12 [110/2] via 3.3.1.2, 00:16:06, FastEthernet0/0
O 192.168.255.21 [110/1001] via 3.3.2.1, 00:16:33, Tunnel1
O 192.168.255.22 [110/1002] via 3.3.2.1, 00:15:56, Tunnel1
O 192.168.255.31 [110/2001] via 3.3.2.1, 00:15:46, Tu nnel1
O 192.168.255.32 [110/2002] via 3.3.2.1, 00:15:46, Tunnel1
O 192.168.255.41 [110/2001] via 3.3.2.1, 00:15:56, Tunnel1
O 192.168.255.42 [110/2002] via 3.3.2.1, 00:15:56, Tunnel1
Cu ajutorul comenzii show ip ospf database sunt afiș ate informațiile pe care routerul le
conține în baza de date după ce implementarea OSPF a fost realizată cu succes.
SE1# show ip ospf database
OSPF Router with ID (192.168.255.11) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
192.168.255.11 192.168.255.11 991 0x80000003 0x002013 3
192.168.255.12 192.168.255.12 992 0x80000002 0x00812D 2
192.168.255.21 192.168.255.21 973 0x80000005 0x00C735 5
192.168.255.22 192.168.255.22 987 0x80000002 0x00731B 2
192.168.255.31 192.168.255.31 974 0x80000003 0x0034BE 3
192.168.255.32 192.168.255.32 979 0x80000002 0x00650 9 2
192.168.255.41 192.168.255.41 983 0x80000003 0x003E94 3
192.168.255.42 192.168.255.42 988 0x80000002 0x0057F6 2
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
3.3.1.2 192.168.255.12 992 0x80000001 0x00AE23
3.3.2.2 192.168.255.22 988 0x80000001 0x00585A
3.3.3.2 192.168.255.32 979 0x80000001 0x000291
3.3.4.2 192.168.255.42 988 0x80000001 0x00ABC8
5.1.2 Tunele GRE
Pentru realizarea tunelelor peste rețeaua furnizorului de servicii s -a folosit protocolul GRE
(Generic Routing Encapsulation). Topologia utilizată în cadrul proiectului este de tip hub -and-
spoke, astfel că, pe routerul hub au fost construite tunele către fiecare dintre clienții VPN de tip
spoke. Configurația unui astfel de tunel este următoarea:
interface Tunnel1
ip unnumbered FastEthernet0/0
keepalive 5 3
tunnel source F astEthernet1/0
tunnel destination 2.3.1.14
Asemănător au fost configurate și celelalte tunele către clienții VPN, dar și tunelele în sens
invers, de la routerul de tip spoke către routerul de tip hub.
Pentru a observa funcționalitatea acestor tunele, au fost folosite utilitarele ping si
traceroute . S-a verificat conectivitatea între rețelele 3.3.2.0/24 si 3.3.4.0/24, mai exact conexiune
între routerele aflate în spatele celor cu configurații de tunele GRE (H1-S2).
H# ping 3.3.4.2
Type escape sequence to abort.
Sending 5, 100 -byte ICMP Echos to 3.3.4.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round -trip min/avg/max = 136/148/164
ms
H# traceroute 3.3.4.2
Type escape sequence to abort.
Tracing the route to 3.3.4.2
VRF info: (vrf in name/id, vrf out name/id)
1 3.3.2.1 44 msec 72 msec 48 msec
2 3.3.4.1 136 msec 164 msec 156 msec
3 3.3.4.2 156 msec 152 msec 140 msec
Se poate observa că transfer ul de pachete a fost realizat cu succes, iar rutele urmărite în cadrul comunicației corespund trecerii prin tunelul
GRE configurat.
Rezultatul încapsulării și transportului pachetelor poate fi observat utilizând o captură de rețea, pe baza căreia se pot observa următoarele:
– Adresele sursă și destinație din cadrul antetului IP corespund cu adresa de loopback 2.3.1.22, respectiv adresa de la capătul tunelului 2.3.1.18;
– Câmpul “Protocol” specifică faptul că pachetul original va fi încapsulat folosind un antet GRE;
– Antetul GRE specific tipul pachetului transportat, adica pachet de tip IP;
– După încapsulare, adresa sursă și cea destinație sunt cele reale ale router -elor, 3.3.2.2 și 3.3.4.2;
– Tipul aplicației transportate este ICMP -Internet Control Message Protocol.
Figura 30. Captură de rețea ce ilustrează efectele tunelării cu ajutorul protocolului GRE
Starea finală a rutelor create prin intermediul OSPF, dar și st area tunelelor GRE configurate pot fi observate cu ajutorul comenzilor show ip
route ospf și show ip interface brief | include Tunnel , după cum urmează:
HE# show ip route ospf | begin Gateway
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
3.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
O 3.3.1.0/24 [110/1001] via 3.3.1.1, 00:42:36, Tunnel1
O 3.3.3.0/24 [110/1001] via 3.3.3.1, 00:42:16, Tunnel3
O 3.3.4.0/24 [110/1001] via 3.3.4.1, 00:42:26, Tunnel2
192.16 8.255.0/32 is subnetted, 8 subnets
O 192.168.255.11 [110/1001] via 3.3.1.1, 00:43:03, Tunnel1
O 192.168.255.12 [110/1002] via 3.3.1.1, 00:42:26, Tunnel1
O 192.168.255.22 [110/2] via 3.3.2.2, 00:42:26, FastEthernet0/0
O 192.168.2 55.31 [110/1001] via 3.3.3.1, 00:42:16, Tunnel3
O 192.168.255.32 [110/1002] via 3.3.3.1, 00:42:16, Tunnel3
O 192.168.255.41 [110/1001] via 3.3.4.1, 00:42:26, Tunnel2
O 192.168.255.42 [110/1002] via 3.3.4.1, 00:42:26, Tunnel2
HE# show ip interface brief | include Tunnel
Tunnel1 3.3.2.1 YES TFTP up up
Tunnel2 3.3.2.1 YES TFTP up up
Tunnel3 3.3.2.1 YES TFTP up up
Implementarea tunelelor GRE, prezentată anterior, a implicat configurarea unor tunele punct -la-punct ce funcționează între câte două routere
pentru fiecare tunel în parte. Aceast ă soluție este una potrivită în cazul în care numărul de routere de tip spoke este unul relativ mic.
5.1.3 Tunele mGRE
Pentru situația în care complexitatea topologiei crește, mai exact, numărul routerelor conectate la hub crește, o soluție mai eficientă ar fi cea în
care configurația pentru routerul hub ar fi una multipunct – mGRE (multipoint Generic Routin Encapsulation). O configurație de acest tip folosește o
singură interfață pentru crearea mai multor tunele către dispozitivele spoke, păstr ând, în continuare, configurația punct -la-punct pentru acestea.
Un aspec t important în cadrul implementării mGRE este reprezentat de utilizarea NHRP – Next Hop Resolution Protocol. Acest protocol oferă
posibilitatea mapării unei adrese IP de tunel cu o adresă logică IP denumită NBMA – Non-Broadcast Multi -Acces. Rezultatul folo sirii unei astfel de
configurații aduce avantajul că tunelele mGRE sunt implementate dinamic, fără a fi nevoie de o configurație explicită pentru fiecare mapare între două
punct e adiacente.
Configurația tunelului mGRE corespunzătoare routerului central (hu b) este următoarea, iar în comparație este prezentată și configurația pentru
un router de tip spoke.
HE# show running -config interf Tunnel10
ip address 100.100.100.1 255.255.255.0
no ip redirects
ip mtu 1416
ip nhrp map multicast dynamic
ip nhrp network -id 1
ip nhrp holdtime 300
ip ospf network point -to-multipoint ip ospf mtu -ignore
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel key 999
SE1# show running -config interf Tunnel1
ip address 100.100.100.2 255.255.255.0
ip mtu 1416
ip nhrp map 100.100.100.1 2.3.1.22
ip nhrp map multicast 2.3.1.22
ip nhrp network -id 1
ip nhrp holdtime 300
ip nhrp nhs 100.100.100.1 ip ospf network point -to-multipoint
ip ospf mtu -ignore
tunnel sour ce FastEthernet2/0
tunnel mode gre multipoint
tunnel key 999
Pentru routerul hub, configurația are următoarea explicație: configurarea NHRP pentru obținerea tunelelor cu echipamentele de tip spoke a fost
realizată cu comanda ip nhrp map multicast dynamic ; implementarea sesiunilor pentru NHRP și pentru tunele a fost realizată cu ajutorul comenzilor ip
nhrp network -id 1 și tunnel key 999 ; pentru rutare a fost setat OSPF în rețeaua overlay; tipul rețelei, dar și al tunelelelor au fo st definite prin comenzile
ip ospf network point -to-multipoint și tunnel mode gre multipoint.
Această configurație pentru routerul hub are următorul rezultat:
HE# show dmvpn | begin Type
Type :Hub, NHRP Peers:3,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
1 2.3.1.14 100.100.100.2 UP 00:43:50 D
1 2.3.1.18 100.100.100.3 UP 00:42:48 D
1 2.3.1.26 100.100.100.4 UP 00:43:08 D
Se poate observa că tunelele create su nt de tip D -Dynamic și se evidențiază adresele NBMA din rețeaua underlay, dar și adresele de tunel ale
routerelor de tip spoke.
Pentru routerele de tip spoke se remarcă maparea adresei tunelului cu cea NBMA prin comanda ip nhrp map 100.100.100.1 2.3.1.22. Comanda
ip nhrp nhs 100.100.100.1 atribuie NHS – Next -Hop Server adresa 100.100.100.1. Rezultatul este următorul:
SE1#show dmvpn | begin Interface
Interface: Tunnel1, IPv4 NHRP Details
Type: Spoke, NHRP Peers:1,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
1 2.3.1.22 100.100.100.1 UP 00:51:14 S
Se observă că, de această dată, tunelul creat este unul de tip static, iar adresa NBMA preluată este cea dorită.
Cu ajutorul unei capturi de rețea, putem observa procesul de înregistrare a NHRP, precum urmează:
Figura 31. Captură de rețea. Cerere de înregistrare NHRP
Adresa IP sursă este 2.3.1.14, iar adresa IP destinație 2.3.1.22. Adresa preluată în cadrul mapării pentru NBMA este 2.3.1.14. Adresele sursă și
destinație ale protocolului sunt 100.100.100.2, respectiv 100.100.100.1 și reprezintă adresele corespunzătoare tunelului.
5.1.4 DMVPN
DMVPN (Dynamic Multipoint VPN) este o soluție eficientă pentru securizarea dinamică a rețelelor de tip overlay. Spre deosebir e de
implementările prezentate anterior, DMVPN aduce avantajul reducerii configurațiilor, utilizării protocoalelor de rutare dinam ice, a tunelării mGRE și a
NHRP, dar și criptarea dinamică IPSec.
În implementarea inițială a tehnologiei GRE, tunelele create au fost de tipul punct -la-punct, existând câte o singură interfață GRE pentru
fiecare echipament de tip spoke. Din punct de vedere al configurațiilor, tunelele au fost definite ca având destinații statice pentru fiecare tunel în parte
și adrese statice pentru fiecare echipament spoke. De asemenea, mărirea rețelei prin adăugarea de echipamente necesita schimb ări ale configurației
hub-ului, iar comunicația spoke -to-spoke se realiza prin transmiterea obligatorie a traficului prin echipamentul hub.
Pentru reducerea configurațiilor și utilizarea eficientă a spațiului de adrese, s -a optat pentru implementarea unor tunele multipunct GRE. Ast fel,
o singura interfață mGRE pe routerul hub deservea toate routerele de tip spoke, permițând noului tunel să aibă destinații mul tiple. Un aspect important,
așa cum a fost prezentat sumar anterior, îl constituie protocolul NHRP care este, de asemenea, un element esențial în cadrul soluției oferite de
DMVPN.
NHRP creează o schema de rutare optimizată în cadrul rețelelor NBMA (non -broadcast multiple -access). Într -o primă etapă, acest protocol este
folosit pentru a informa routerul hub asupra aparițiilor dina mice ale routerelor spoke. Inițial, fiecare router spoke are o configurație de tunel GRE cu
adresa IP a echipamentului hub ca fiind serverul NHS, adică destinația tunelului static creat reprezentând adresa fizică a ro uterului hub. Routerele de
tip spoke co munică direct doar cu routerul hub, iar comunicația spoke -to-spoke se realizează prin intermediul hubului. Configurațiile specific e pentru
NHRP sunt următoarele:
SPOKE HUB
ip nhrp map 100.100.100.1 2.3.1.22
ip nhrp map multicast 2.3.1.22
ip nhrp network -id 1
ip nhrp holdtime 300
ip nhrp nhs 100.100.100.1 ip nhrp map multicast dynamic
ip nhrp network -id 1
ip nhrp holdtime 300
Comanda ip nhrp map 100.100.100.1 2.3.1.22 creează o legătura între o adresă IP logică și o adresă IP NBMA. Deoarece NHRP tratează
mGRE ca fiind un mediu N BMA, adresa logică 100.100.100.1 corespunde unei adrese IP interne (din interiorul tunelului), iar adresa NBMA 2.3.1.22
corespunde unei adrese IP externe (adresa IP folosită ca sursă a tunelului).
Comanda ip nhrp multicast dynamic / [2.3.1.22] specifică destinația traficului provenit de la routerul respectiv. Echipamentele spoke se
mapează multicast la adresa static ă NBMA a echipamentului hub, iar echipame ntul hub realizează, la rândul lui, mapări dinamice ale pachetelor
multicast, adică replică pachetele multicast la toate echipamentele spoke înregistrate prin NHRP.
Comanda ip nhrp nhs 100.100.1 configurează clientul NHRP cu adresa IP a serverului NHRP. A ceastă adresă reprezintă adresa logică a
hubului și, de aceea, echipamentele spoke necesită o mapare static ă pentru a ajunge la hub. Acestea folosesc NHS pentru a -și înregistra adresa IP
logică în cadrul asociațiilor IP NBMA și trimit o cerere de rezoluție NHRP (NHRP resolution request).
Comanda ip nhrp network -id 1 identifică rețeaua logică NHRP, iar comanda ip nhrp holdtime 300 specifică valoarea setată pentru așteptare în
cadrul cererilor NHRP. NHS va păstra cererea de înregistrare stocată în memoria cache timp de 300 de secunde și, dacă nu primește nicio actualizare
de înregistrare, o va șterge. NHS trimite, de asemenea, în aceeași durată de timp , răspunsurile corespunzătoare cererilor de înregistrare.
HE# show ip nhrp detail
100.100.100.2/32 via 10 0.100.100.2
Tunnel10 created 02:16:06, expire 00:03:55
Type: dynamic, Flags: unique registered used
NBMA address: 2.3.1.14
100.100.100.3/32 via 100.100.100.3
Tunnel10 created 02:15:04, expire 00:03:59
Type: dynamic, Flags: unique registered used
NBMA address: 2.3.1.18
100.100.100.4/32 via 100.100.100.4
Tunnel10 created 02:15:24, expire 00:04:07
Type: dynamic, Flags: unique registered used
NBMA address: 2.3.1.26
Se poate observa că adresa logică 100.100.100.2 se mapează la adresa NBMA 2.3.1.14 și, analog, 100.100.100.3 la 2.3.1.18, iar 100.100.100.4
la 2.3.1.26. Fanionul de înregistrare “unique” este folosit pentru a preveni mapările duplicate în memoria cache. Da că o mapare unică pentru o anumită
adresă IP logică se află deja în memoria cache NHRP și un alt NHC (Next -Hop Client) încearcă să înregistreze aceeași adresă IP logică, serverul NHS
va respinge înregistrarea până la expirarea intrării unice.
Verificarea procesului de înregistrare poate fi realizată prin pornirea depanării NHRP folosind comenzile debug nhrp și debug nhrp packet. Se
pot observa următoarele:
NHRP: Receive Registration Request via Tunnel10 vrf 0, packet size: 92
(F) afn: AF_IP (1), type: IP (800), hop: 255, ver: 1
shtl: 4(NSAP), sstl: 0(NSAP)
pktsz: 92 extoff: 52
(M) flags: "unique nat ", reqid: 65537
src NBMA: 2.3.1.26
protocol: 100.100.100.4, dst protocol: 100.100.100.1
(C-1) code: no error (0)
prefix: 32, mtu: 17912, hd_time: 300
addr_l en: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
Tu10: Creating dynamic multicast mapping NBMA: 2.3.1.26
NHRP: Added dynamic multicast mapping for NBMA: 2.3.1.26
NHRP : New mandatory length: 32
NHRP: Attempting to send packet via DEST 100.100.100.4
NHRP: Encapsulation succeeded. Sending NHRP Control Packet NBMA Address: 2.3.1.26
Formatul unui pachet NHRP conține trei elemente: (F) – parte fixată ce specifică versiunea, familia de adrese (afn), protocolul utilizat, dar și
tipul și lungimea NBMA. Sht l are valoarea 4, ceea ce semnifică lungimea în bytes a adresei IPv4, iar sstl are valoarea 0 și reprezintă câmpul de
subadrese, nefolosit în IPv4.
(M) reprezintă partea obligatorie a antetului și specifică diferite fanioane , în acest caz unique și nat, d ar și request id (65537). Tot aici, sunt
specificate adresa sursă NBMA care reprezintă adresa sursă a tunelului, dar și adresele IP sursă și destinație din cadrul pro tocolului IP.
(C-1) reprezintă câmpul ce conține informații despre client, C -1 fiind abrev ierea de la CIE 1 (“Client Information Element”).
După procesarea cererii, routerul răspunde cu un NHRP Registration Reply în care antetul (M) nu se modifică, ci doar adresele IP logice sursă
și destinație sunt inversate:
NHRP: Send Registration Reply via Tunnel10 vrf 0, packet size: 112
src: 100.100.100.1, dst: 100.100.100.4
(F) afn: AF_IP (1), type: IP (800), hop: 255, ver: 1
shtl: 4(NSAP), sstl: 0(NSAP)
pktsz: 112 extoff: 52
(M) flags: "unique nat ", reqid: 65537
src NBMA: 2.3.1.26
src protocol: 100.100.100.4, dst protocol: 100.100.100.1
(C-1) code: no error (0)
prefix: 32, mtu: 17912, hd_time: 300
addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
Dezavantajul acestei etape este reprezentat de incapacitatea de a stabili tunele direc te spoke -to-spoke. Astfel, pentru a rezolva această prolemă
este necesară impementarea unei configurații care să permită routerelor spoke comunicația direct, fără a mai fi necesară impl icarea routerului hub.
Deoarece protocolul de rutare este OSPF, în ca drul configurațiilor este necesar ca rețeaua pe care a fost definit protocolul de rutare să fie de tip
broadcast (în prima etapă, rețeaua era de tip point -to-multipoint, ceea ce făcea ca traficul să traverseze routerul hub în cadrul unei comunicații dintre
două routere spoke). De asemenea, topologia fiind de tipul hub -and-spoke, este de dorit ca routerul hub să devină DR – Designated Router. Acesta, la
rândul lui, va fi responsabil de stabilirea adiacențelor cu toate routerele Drother, adică toate routerele spoke. Routerul DR va asculta actualizările pe
adresa multicast 224.0.0.6 și va transmite fluxul de LSA -uri către routerele Drother/Spoke prin adresa 224.0.0.5.
Pentru a ne asigura de faptul că niciun router spoke nu ia parte în procesul de alegere al routerului DR și doar routerul hub poate deveni
Designated Router, este necesară configurarea priorităților în cadrul tunelelor. Astfel, routerele spoke sunt definite ca avâ nd prioritate 0, pe când
routerul hub are prioritate 255. Configurațiile pentru hub și spoke sunt următoarele:
HE# show running -config interf Tunnel10
interface Tunnel10
ip address 100.100.100.1 255.255.255.0
no ip redirects
ip mtu 1416
ip nhrp map multicast dynamic
ip nhrp network -id 1
ip nhrp holdtime 300
ip ospf network broadcast ip ospf priority 255
ip ospf mtu -ignore
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel key 999
end
SE1# show running -config interf Tunnel1
interface Tunnel1
ip address 100.100.100.2 255.255.255.0
ip mtu 1416
ip nhrp map 100.100.100.1 2.3.1.22
ip nhrp map multicast 2.3.1.22
ip nhrp network -id 1
ip nhrp holdtime 300
ip nhrp nhs 100.100.100.1 ip ospf network broadcast
ip ospf priority 0
ip ospf mtu -ignore
tunnel source FastEthernet2/0
tunne l mode gre multipoint
tunnel key 999
Pentru a verifica rezultatul procesului de selecție a routerului DR, se folosește comanda show ip ospf neighbor, urmărindu -se starea vecinilor,
dar și prioritatea acestora.
HE# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.255.11 0 FULL/DROTHER 00:00:39 100.100.100.2 Tunnel10
192.168.255.31 0 FULL/DROTHER 00:00:35 100.100.100.4 Tunnel10
192.16 8.255.41 0 FULL/DROTHER 00:00:38 100.100.100.3 Tunnel10
192.168.255.22 1 FULL/DR 00:00:31 3.3.2.2 FastEthernet0/0
SE1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.255.21 255 FULL/DR 00:00:39 100.100.100.1 Tunnel1
192.168.255.12 1 FULL/DR 00:00:33 3.3.1.2 FastEthernet0/0
Se poate observa că routerul hub a fost ales ca fiind Designed Router, iar routerele spoke sunt de tipul Drother. Se remarcă prioritățile
routerelor spoke ca fiind 0, iar cea a routerului hub ca fiind 255. Routerele de tip spoke prezintă în plus o vecinătate cu u n al doilea router de tip DR,
acesta făcând parte din rețeaua Cl ient.
Pentru a verifica funcționalitatea comunicației spoke -to-spoke și modul în care este realizată aceasta, se folosește utilitarul traceroute pentru a
vizualiza rutele urmate. Se ia ca exemplu comunicația între SE1 și SE2 folosing adresele de loopback.
SE1#show dmvpn
Interface: Tunnel1, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
1 2.3.1.22 100.100.100.1 UP 00:49:08 S
În starea inițială, pe routerul SE1 există un tunel static către routerul hub. Se verifică, în continuare, posibilitatea comunicației între SE1 și SE2
prin adresele de loopback:
SE1#ping 192.168.255.41
Type escape sequence to abort.
Sending 5, 100 -byte ICMP Echos to 192.168.255.41, timeout is 2 secon ds:
!!!!!
Success rate is 100 percent (5/5), round -trip min/avg/max = 184/841/1904 ms
Comunicația are loc cu succes, urmând verificarea căilor de acces către routerul SE2:
SE1#traceroute 192.168.255.41
Type escape sequence to abort.
Tracing the route to 192.168.255.41
VRF info: (vrf in name/id, vrf out name/id)
1 100.100.100.1 180 msec 152 msec 136 msec
2 100.100.100.3 208 msec 176 msec 128 msec
Inițial, traficul traversează routerul hub deoarece încă nu cunoaște calea directă către SE2. În urma ace steia, routerul SE1 învață calea directă
către SE2, modificare ce poate fi vizualizată reapelând comanda traceroute anterioară:
SE1#traceroute 192.168.255.41
Type escape sequence to abort.
Tracing the route to 192.168.255.41
VRF info: (vrf in name/id, vrf out name/id)
1 100.100.100.3 152 msec 136 msec 172 msec
La final, se verifică existența unui tunel dinamic între SE1 și SE2 prin comanda show dmvpn
:
SE1#show dmvpn
Interface: Tunnel1, IPv4 NHRP Details
Type:Spoke, NHRP Peers:3,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
1 2.3.1.22 100.100.100.1 UP 00:50:59 S
1 2.3.1.18 100.100.100.3 UP 00:00:14 D
5.2 Implementarea protocolului IKEv2 pentru securizarea comunicațiilor
Așa cum a fost precizat anterior, soluția oferită de DMVPN implică și aspecte legate de securizarea rețelei. Astfel, DMVPN pe rmite criptarea
dinamică a traficului prin intermediul diferitelor protocoale de securitate.
După cum se poate obse rva din captura de pachete de mai jos, traficul între echipamentele folosite în cadrul topologiei este necriptat, transmis
în clar.
Figur a 32. Catură de rețea. Pachete transmise în clar, nesecurizat
Pentru stabilirea securității , va fi implementat protocolul IKEv2 folosind tunele GRE multipunct și o infrastructură pentru chei publice care
introduce în cadrul topologiei o terță parte de încredere responsabilă cu generarea și administrarea certificatelor digitale.
Pentru implement area unei infractructuri pentru chei publice ce folosește protocolul IKEv2, este necesară introducerea în cadrul topologiei a
unei entități de încredere ce va funcționa ca terță parte în procesul de comunicație. În scopul implementării Autorității de Certi ficare (CA -Server), s -a
ales un router c3725. Topologia utilizată în cadrul acestui studiu de caz este următoarea:
Figura 33. Topologie utilizată în cadrul implementării protocolului IKEv2
Pentru obținerea unei topologii ce funcționează cu PKI (Public Key Infrastructure) și IKEv2, trebuie realizați următorii pași:
1. Configurarea serverului ca Autoritate de Certificare
2. Configurarea routerelor pentru înrolarea la CA -Server și solicitarea de certificate
3. Configurarea protocolului IKEv2 pentru securizarea topologiei
Configurarea serverului ca Autoritate de Certificare
Pentru ca routerul ales să poată funcționa ca un server de certificare, este necesar ca acesta să fie declarat primordial ca server http prin
aplicarea comenzii ip http server. Această comandă va permite, ulterior, configurarea serverului pki.
Ca primă parte a procesului de configurare a serverului CA, este necesară o pereche de chei ce vor fi utilizate, pe de o part e, pentru semnarea
certificatelor digitale, iar pe de altă parte pentru criptarea lor.
Se alege, astfel, o pereche de chei RSA (Ri vest, Shamir, Adleman), de tipul usage -keys, tip de chei specific diferențierii scopului fiecareia
dintre ele (semnare și criptare). Prin sintaxa label se specifică numele care va fi atribuit perechii de chei, în cazul nostru, “CA -Server”, în momentul
expo rtării. Pereche a de chei va fi declarată “exportable”, iar dimensiunea IP a modulului de chei va fi de 2048 biți, conform recomandărilor pentr u o
Autoritate de Certificare.
Sintaxa comenzii este urmă toarea, împreună cu rezultatele sale:
CA-Server(config)# crypto key generate rsa usage -keys label CA -Server modulus 2048 exportable
The name for the keys will be: CA -Server
% The key modulus size is 2048 bits
% Generating 2048 bit RSA keys, keys will be exportable…
[OK] (elapsed time was 4 seconds)
% Generating 2048 bit RSA keys, keys will be exportable…
[OK] (elapsed time was 7 seconds)
*Apr 26 09:34:22.351: %SSH -5-ENABLED: SSH 1.99 hab been enabled
Ulterior generării perechii de chei, aceasta este exportată cu ajutorul comenzii crypto key export rsa în memoria ram non -volatilă. Cele două
chei sunt exportate în format pem, un format specific stocării și transmiterii cheilor criptografice și ale certificatelor. S e stabilește, de asemenea, în
cadrul sintaxei, o parola de acces (“ silvia123” ) și algoritmul 3D ES, cifru bloc pentru chei simetrice care aplică algoritmul DES de câte trei ori pentru
fiecare bloc de date.
Sintaxa completă a comenzii și rezultatele sale sunt următoarele:
CA-Server(config)# crypto key export rsa CA -Serv er pem url nvram: 3des
silvia123
# Key name: CA -Server
Usage: Signature Key
Exporting public key…
Destination filename [CA -Server -sign.pub]?
Writing file to nvram:CA -Server -sign.pub
Exporting private key…
Destination filename [CA -Server -sign.prv]?
Writing file to nvram:CA -Server -sign.prv
# Key name: CA -Server
Usage: Encryption Key
Exporting public key…
Destination filename [CA -Server -encr.pub]?
Writing file to nvram:CA -Server -encr.pub
Exporting private key…
Destination filename [CA -Server -encr.prv] ?
Writing file to nvram:CA -Server -encr.prv
Se poate observa că pentru fiecare dintre cele două chei (semnare și criptare), se exportă câte o cheie publică și una privat ă, diferentiate prin
terminatiile .pub și .prv. De asemenea, pentru fiecare cheie se adaugă în denumirea fisierului tipul de cheie (sign și encr).
Pentru verificarea generării corecte a perechii de chei, se poate folosi comanda show crypto key mypubkey rsa care ilustrează cheile generate,
denumirea lor, tipul de ch eie, dacă sunt sau nu exportabile, data generării cheilor, dar și fiecare cheie în parte, astfel:
CA-Server#sh ow crypto key mypubkey rsa
% Key pair was generated at: 09:34:15 UTC Apr 26 2019
Key name: CA -Server
Usage: Signature Key
Key is exportable.
Key Data:
30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00FDEA5F
F623632D DC229DCA E1362F8A 4DDA7753 B70E54F8 C0AAF7B7 071BC146 BA64E2A7
52903EA8 FE730626 A8E712AA E87A762C AF12FBCA 367164F8 A1160C81 242D56D9
DC658AA9 FC9D66F5 AD5E4 135 AA39AB5B 677BA82C 928975A5 263E69EB 72E7A745
CF6C95F4 2DBDF759 E7ED5CF4 7DED5C6E D66CA684 A60E032C 7E74B060 37020301 0001
% Key pair was generated at: 09:34:22 UTC Apr 26 2019
Key name: CA -Server
Usage: Encryption Key
Key is exportable.
Key Data:
30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00DA2DB8
18D27917 58D0D05E 34FB7507 4C273363 CED1AA43 183B7178 D8FFC653 22C94EED
8FD4BB3B EB45B3F6 CE3C8D6D 65561CBC FE19F88C 74B7E00E 48CB8A2A F2321CAB
1F1C194D 04B0300D 2C133114 1A7DA 112 5CB6D104 09A81E17 F54DFC56 8C219BFC
6FBBD6EA 4912D11C 8815295D 44AE4A46 DB79F1A7 93C90D04 4C7DA5FF 67020301 0001
% Key pair was generated at: 09:34:22 UTC Apr 26 2019
Key name: CA -Server.server
Usage: Encryption Key
Key is not exportable.
Key Data:
307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00C12CFA 20CE524D
DCEE4BCA 39B9D69A 2893F31A C318B75A 3185D041 02F6E21B A657B2A2 C36E79A5
485F3C93 40A75105 7F659836 F728288D BA748460 B41F3987 8AF3E069 846B7352
31C20B1E 86DD484A 5DC 91697 0F96FC2B 59E9AA14 05F5A04F D1020301 0001
După ce au fost generate, exportate și verificate cele două chei care vor fi utilizate în procesul de creare și distribuire a certificatelor digitale,
cea de a doua parte în cadrul creării serverului CA este reprezentată de configurarea în sine a serverului PKI. Se definește, astfel, un server de tip PKI
ce va utiliza aceeași denumire ca și perechea de chei generate anterior (CA -Server). Comenzile necesare definirii serverului sunt permise deoarece, în
etapa inițială, routerul a fost configurat cu ajutorul comenzii ip http server.
Comenzile utilizate sunt următoarele:
crypto pki server CA -Server
database level complete
database username Silvia_Ioana_Stanciu
database archive pem password 7 083245421F100446 4058
issuer -name CN=UPB -ETTI.ro O=UPB -ETTI OU=X.509certs L=Bucuresti C=Romania
lifetime crl 24
lifetime certificate 730
lifetime ca -certificate 1460
cdp-url http://192.168.255.51/CA -Servercdp.CA -Server.crl
• database level – controlează tipul de date stocate în baza de date de certificate și cea a Autorității de Certificare. Prin specificarea unui nivel
complet (database level complete), fiecare certificat soli citat este înscris în baza de date.
• database username – folosită pentru a solicita un nume de utilizator în momentul accesării locației primare a bazei de date. Comanda poate
conține, pe lângă numele de utilizator, și o parolă.
• database archive – setează f ormatul de arhivare a certificatelor CA și a cheilor. Acestea vor fi exportate în format PEM, utilizându -se, de
asemenea, și o parolă.
• issuer -name – specifică informațiile necesare folosind formatul DN (distinguished name). Atributele specificate sunt conf orme standardului
X.509. Se precizează CN -CommonName, O -Organization, OU -OrganizationalUnit, L -Localty, C -CountryName. Aceste atribute vor apărea în
fiecare certificat emis de către Autoritatea de Certificare după cum va fi prezentat ulterior.
• lifetime – este utilizată de trei ori, specificând pe rând, următoarele: timpul de viață a CRL (Certificate Revocation List) de 24 de or e, timpul de
viață al serverulu ide semnare a certificatelor de 1460 zile (4 ani) și timpul de viață al certificatelor de 730 zile (2 ani).
• cdp-url – specifică un CDP (Cisco Discovery Protocol) folosit în certificatele solicitate de către serverul de certificare. Cu ajutorul acesteia, se
creează o politică de revocare împreună cu comanda anterioară în care se specific timpul de viață al CRL -ului. În cazul de față, CDP -ul se
publică pe router în sine, folosind adresa de loopback a acestuia.
După configurarea serverului CA, este necesară activarea acestuia cu ajutorul comenzii no shutdown ce permite trecerea serverului din starea
disabl ed în starea enabled. Rezultatele acestei comenzi sunt următoarele:
CA-Server(cs -server)#no shutdown
%Some server settings cannot be changed after CA certificate generation.
% Exporting Certificate Server signing certificate and keys…
%Certificate Server enabled.
*Apr 26 09:54:28.943: %PKI -6-CS_ENABLED: Certificate server now enabled.
Se poate observa că după aplicarea comenzii no shutdown, inițial sunt exportate cheile si certificatele necesare semnării, după care serverul
trece în starea enabled. Pentr u verificarea atributelor serverului de certificare, ulterior activării sale, se utilizează comanda show crypto pki server.
Rezultatele sunt următoarele:
CA-Server#show crypto pki server
Certificate Server CA -Server:
Status: enabled
Server's configuration is locked (enter "shut" to unlock it)
Issuer name: CN=UPB -ETTI.ro O=UPB -ETTI OU=X.509certs L=Bucuresti C=Romania
CA cert fingerprint: 627E62C4 EF857F80 F77FB428 6E7F260A
Granting mode is: manual
Last certificate issued serial number: 0x1B
CA certificate expiration timer: 17:48:15 UTC Apr 25 2023
CRL NextUpdate timer: 12:26:46 UTC Apr 27 2019
Current storage dir: nvram:
Database Level: Complete – all issued certs written as <serialnum>.cer
După ac tivarea serverului, configurarea acestuia este blocată. Modificările asupra configurațiilor, sau adăugarea anumitor caracteri stici pot fi
făcute doar dacă serverul este blocat, adică serverul se află în starea disabled.
Sunt evidențiate în cadrul serveru lui de certificare următoarele:
• Issuer -name : configurat anterior conform standardului de certificare X.509;
• Amprenta certificatului CA care va fi utilizată ulterior în procesul de creare și distribuire a certificatelor digitale;
• Modalitatea de acordare a certificatelor = manual; În cadrul configurației nu a fost definită o metodă de acordare, astfel că a fost preluată
varianta implicită. Prin specificare, putea fi aleasă varianta automata de acordare a certificatelor;
• Data de expirare a certificatelor CA – corespunzătoare intervalului stabilit de 4 ani;
• Data de actualizare a CRL -ului – corespunzătoare intervalului stability de 24 ore;
• Directorul de stocare curent : memoria non -volatil ă nvram;
• Nivelul bazei de date configurat anterior ca fiind unul complet.
Ulterior configurării serverului de certificare, se definește un trustpoint (punct de încredere), cu ajutorul căruia perechea de chei generat ă
anterior este asociat ă cu acesta. Certificatele pentru pentru fiecare client vor fi generate prin intermediul acestui trustpoint, care descrie carac teristici
ale înrolării clienților cu serverul de certificare. Comenzile pentru configurarea punctului de încredere sut următoarel e:
crypto pki trustpoint CA -Server
revocation -check crl
rsakeypair CA -Server
Comanda revocation -check crl este folosită pentru a verifica dacă un certificat a fost sau nu revocat anterior de către serverul de certificare.
Comanda rsakeypair specifică perechea de chei asociată punctului de încredere, aceasta fiind chiar perechea de chei generată inițial.
Verificarea trustpointului se realizează cu ajutorul comenzii show crypto pki trustpoints și are următorul rezultat:
CA-Server#show crypto pki trustpoints
Trustpoint CA -Server:
Subject Name:
cn=UPB -ETTI.ro O \=UPB -ETTI OU \=X.509certs L \=Bucuresti C \=Romania
Serial Number: 01
Certificate configured.
Se poate oberva că punctul de încredere a preluat caracteristicile definite în cadrul serverului de certificare și sunt conforme cu standardul
X.509. De asemenea, a fost atribuit un număr de ordine (01), iar la final se specifică faptul că certificatul a fost configur at.
Pentru vizualizarea certificatului din cadrul serverului CA , se utilizează comanda show crypto pki certificates ce ilustrează certificatul obținut
anterior, împreună cu informații despre starea certificatului, numărul de ordine, tipul certificatului, entitatea care solici tă certificatul, punctul de
încredere asoci at, dar și validitatea acestuia.
CA-Server#show crypto pki certificates
CA Certificate
Status: Available
Certificate Serial Number: 01
Certificate Usage: Signature
Issuer:
cn=UPB -ETTI.ro O \=UPB -ETTI OU \=X.509certs L \=Bucuresti C \=Romania
Subject:
cn=UPB -ETTI.ro O \=UPB -ETTI OU \=X.509certs L \=Bucuresti C \=Romania
Validity Date:
start date: 17:48:15 UTC Apr 26 2019
end date: 17:48:15 UTC Apr 25 2023
Associated Trustpoints: CA -Server
În configurarea serverului de certificare, a fost specificată ca locație de stocare a certificatelor memoria non -volatila ram. Astfel, pentru
vizualizarea și confirmarea unui process desfășurat cu succes, se verifică memoria nvram și entitățile prezente în cadrul acesteia, folosind comanda dir
nvram:. Se obțin următoarele rezultate:
CA-Server#dir nvram:
Directory of nvram:/
49 -rw- 1828 <no date> startup -config
50 –- 3826 <no date> private -config
1 –- 4 <no date> rf_cold_starts
2 -rw- 0 <no date> ifIndex -table
3 -rw- 272 <no date> CA -Server -sign.pub
4 -rw- 963 <no date> CA -Server -sign.prv
5 -rw- 272 <no date> CA -Server -encr.pub
6 -rw- 963 <no date> CA -Server -encr.prv
7 -rw- 33 <no date> CA -Server.ser
8 -rw- 615 <no date> 1.crt
9 -rw- 121 <no date> 1.cnm
10 -rw- 494 <no date> CA -Server.crl
11 -rw- 1852 <no date> CA -Server.pem
Se observă c ă în cadrul nvram, apar următoarele:
• Cheile publice și private pentru semnarea și criptarea certificatelor;
• Fisiere specific serverului de certificare (crl, pem, ser)
• Certificatul cu numărul de ordine 01, atribuit trustpointului
Fișierele stocate în nvram pot fi vizualizate folosind comanda more nvram:denumire_fișier. Pentru verificare, vor fi vizualizate două fișiere:
cheia publică folosită pentru semnarea certificatelor (CA -Server -sign.pub) și cheia private folosită pentru semnarea certificatelor (CA -Server –
sign.prv):
CA-Server#more nvram:CA -Server -sign.pub
––BEGIN PUBLIC KEY ––
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQD96l/2I2Mt3CKdyuE2L4
pN2ndT tw5U+MCq97cHG8FGumTip1KQPqj+cwYm qOcSquh6diyvEvvKNnFk+KEWDI
EkLVbZ
3GWKqfydZvWtXkE1qjmrW2d7qCySiXWlJj5p63Lnp0XPbJX0Lb33WeftXPR9
7Vxu
1mymhKYOAyx+dLBgNwIDAQAB
––END PUBLIC KEY ––
CA-Server#more nvram:CA -Server -sign.prv
––BEGIN RSA PRIVATE KEY ––
Proc -Type: 4, ENCRYPTED
DEK-Info: DES-EDE3 -CBC,C81263549E45DC08
sAF4kcaYmDcP8jXUSkUE/rcfEr/clRFQl4Oa/+JW8z0QVUB7xw4ZcckDvB9zCg
+L
rH2opbhTE4+h2Uk/O3ABpT/rs9iKCa+dbnXGcJPEjls9KOB3fKwGUgPalSyZiU
Qa
eTGPQfCIjbvIEF+zbN1UrOwVo6xCOc8BphclTdGR18rGVoI2a/YIuRTcK2s9z5O
L
pwqYRDrgl87un3n4tgTnlydmpgQf2eakEtNDRWsXZgquCVjPO/x/aqQo1dBa
KZvj
iCCvcE4P+4orCrBGuCZB+aBpihVhDH/EMyzq53PLb2sutUErm2LyLs6rcbXQle3
n BEv/Aq23qamf192OD4tcxokBCFKHPJcaiBNh7s+gQY8K+iEm+W8GUiXDND1
nYB4T
kjdwsG7wWPO97hn88QOM0PAxpwOYAXaqEdS5462yk6FDMCMnlFrZhmu/
xpHOK tMP
RhFxphtisUl1itLbpcX3kQhiKTyd6/SICeXMpZERKl1frU+s5Kgxqx0CkWDiY9RP
30nB39ZpEvvcErcev0Nhho5kBV9sG4W+YNMWgimyTqIX2L9TZTlH0HECjYpG
c3RR
seV3xSD0/RzVT7IQvC8xKFFZgVacG7FA+RZFAMppAE5RHYK8OLw3FeZMeIch
c8YG
BW1wzUa4g/z+PnN1GFYHCQb4XBBeEpoGk4JPLASHko92jEf7ViB3KLWCM zy
vsWaY
iDgav6vGlZKgR7P8G4tJ3I0dkM7liC2Jww/1k1Yvb79nLR5V4TOaMkyXtsf75JL
C
Cf6eNztKsePZbC0uimUvyXTx8utjhn9C0MbDyfO5i/0ke60+JBJSOQ==
––END RSA PRIVATE KEY ––
Configurarea routerelor pentru înrolarea la CA -Server și solicitarea de certificate
Pentru ca fiecare router să poată solicita certificate digitale Autorității de Certificare, este necesar ca în cadrul configu rației fiecărui echipament
serverul să fie declarant ca trustpoint (punct de încredere). Declarând serverul Autorității de Certificare ca punct de încredere, se definește, în termeni
largi, o terță parte de încredere în cadrul comunicației dintre echipamente. Astfel, pentru asigurarea unei comunicații secur izate, serverul are rolul de
intermediar și emite certificate digitale pentru asigurarea confidențialității.
Pentru explicarea configurațiilor și a funcționalității acestora, se ia ca exemplu routerul HE, direct conectat la serverul C A-Server. Toate
celelalte echipamen te sunt configurate similar.
Inițial, pentru a putea configura punctul de încredere și pentru ca funcționarea acestuia să fie corecta, este necesar să ne asigurăm că între cele
două echipamente (HE și CA -Server) se poate desfășura cu succes comunicația. A cest lucru poate fi verificat prin aplicarea comenzii ping pe unul
dintre echipamente către celălalt. Se poate alege testarea comunicației fie prin intermediul rețelei 3.3.5.0/24 care leagă ce le două echipamente, fie prin
intermediul interfețelor de loopba ck.
HE#ping 3.3.5.2
Type escape sequence to abort.
Sending 5, 100 -byte ICMP Echos to 3.3.5.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round -trip min/avg/max = 8/13/28 ms
HE#ping 192.168.255.51
Type escape sequence to abort.
Sending 5, 100 -byte ICMP Echos to 192.168.255.51, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round -trip min/avg/max = 16/72/188 ms
Se poate observa că, indifferent de varianta aleasă, comunicația se desfășoară cu succes, astfel că în momentu l de față este posibilă
configurarea cu succes a punctului de încredere în cadrul routerului HE.
Configurația aleasă pentru definirea punctului de încredere este următoarea:
crypto pki trustpoint CA -Server
enrollment retry count 5
enrollment retry peri od 3
enrollment url http://192.168.255.51:80
serial -number
fqdn HE.SE.com
ip-address 192.168.255.21
subject -name CN=HE OU=X.509certs O=UPB -ETTI C=Romania
revocation -check none
source interface Loopback0
În declararea punctului de încredere, este necesar ca denumirea acestuia să coincidă cu denumirea serverului Autorității de Certificare. În
continuare vor fi explicate comenzile alese pentru configurare, după cum urmează:
• Enrollment retry count 5 – specifică de câte ori routerul va retransmite solicitarea de certificate în cazul în care nu primește răspuns la cererea
efectuată. Numărul de retransmiteri este între 1 și 100, iar în cazul de față, procesul este reluat de 5 ori.
• Enrollment retry period 3 – specifică perioada de așteptare între încer cările de retransmitere a cererilor de certificare. Dacă nu este menționată o
perioadă, valoarea implicită este 1, iar în cazul de față, fiind declarată, perioada este de 3 minute.
• Enrollment url http ://192.168.255.51:80 – declară URL -ul fișierului din sis tem în care routerul trebuie să transmit solicitarea de certificate.
Locația aleasă este reprezentată de adresa de loopback a serverului Autorității de Certificare, iar conexiunea se realizează prin intermediul
portului 80, port corespunzător protocolului HTTP (Hypertext Transfer Protocol).
• Serial -number – comandă opțională care impune includerea numărului de ordine al routerului în solicitarea de certificate. În cazul în care
această comandă este precedată de cuvântul < none >, efectul comenzii are efect inv ers, adică numarul de ordine al routerului nu va fi inclus în
solicitarea de certificate.
• fqdn HE.SE.com – definește numele de domeniu complet calificat (FQDN) ce va fi utilizat în procesul de solicitare a certificatelor și reprezin tă
locația exacta a unui obiect în ierarhia DNS. Prin intermediul acestei comenzi, se specifică toate nivelele domeniului, inclu zand domeniul de
nivel înalt, dar și rădăcina acestuia. Este o adresă unică complete pentru locația aleasă.
• ip-address 192.168.255.21 – declară adresa IP a unei anumite interfețe în cadrul procesului de slicitare a unui certificat. Prin includerea acestei
comenzi în configurația punctului de încredere, se elimină solicitarea ulterioară a unei adrese IP în momentul înrolării rout erului cu punctul de
încredere.
• subject -name – comandă opțională care specific numele subiectului solicitat în cadrul cererii de ce rtificat. Are structură specific standardului
X.509, incluzând informații precum numele comun (CN), unitatea organizațională (OU), organizația (O) și țara ( C). Dacă atrib utele acestea nu
sunt specificate, atunci se va prelua automat FQDN -ul precizat anter ior.
• revocation -check none – prin includerea în cadrul comenzii a cuvântului <none>, se specific faptul că nu vor fi efectuate verificări de revocare
ale certificatelor.
• source interface Loopback0 – specifică interfața sursă care va fi utilizată în cadrul procesului de solicitare a certificatelor, în acest caz, interfața
de loopback a routerului.
După realizarea configurației, poate fi verificat efectul acesteia în cadrul routerului prin apelarea comenzii show crypto pki trustpoints , iar ulterior a
comenzi i show crypto pki trustpoints status. Rezultatul acestora este următorul:
HE#show crypto pki trustpoints
Trustpoint CA -Server:
HE#show crypto pki trustpoints status
Trustpoint CA -Server:
Issuing CA certificate not configured.
State:
Keys generated …………. Yes (Usage Keys, exportable)
Issuing CA authenticated ……. No
Certificate request(s) ….. None
Se poate observa că rezultatul comenzii afișează punctul de încredere configurat anterior pe routerul HE. Corespunzător routerului HE a fost
definit punctul de încredere CA -Server prin intermediul căruia vor fi, ulterior, solicitate certificatele.
Cea de -a doua comandă afișează statusul punctului de încredere care, în momentul de față, nu are un certificat co nfigurat și nici o cerere de
certificate transmisă, fiind prezente doar cheile generate de tipul “usage keys”, exportabile.
Următoarea etapă este reprezentată de autentificarea Autorității de Certificare, in cazul nostru, serverul CA -Server. Această coman dă este
necesară în cadrul configurării inițiale și autentifică CA prin obținerea certificatului auto -semnat al serverului de certificare ce conține cheia publică a
CA-ului. Deoarece autoritatea de certificare semnează un certificate propriu, este recomand ată autentificarea manuală a cheii publice.
Comanda de autentificare nu este salvată în cadrul configurațiilor routerului, dar cheile publice incorporate în certificatel e CA primate sunt
salvate în configurație ca parte a înregistrărilor publice RSA.
Com anda utilizată pentru autentificarea serverului de certificare este crypto pki authenticate, fiind urmată de denumirea serverului, CA -Server.
Comanda completă, impreună cu rezultatul său, sunt următoarele:
HE(config)#crypto pki authenticate CA -Server
Certificate has the following attributes:
Fingerprint MD5: 627E62C4 EF857F80 F77FB428 6E7F260A
Fingerprint SHA1: 9090744F C425FBAD 43EA9055 9960D70D B768A77D
% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
Rezultatul comenzii ilustrează atributele certificatului, incluzând amprentele MD5 și SHA1. Ulterior, deoarece s -a ales autentificarea manuală,
certificatul trebuie acceptat de către utilizator. Pentru a accepta certificatul digital sugerat, este necesa r ca amprentele ilustrate în răspunsul prezentat
anterior să coincidă cu cele înregistrate. Pentru a verifica dacă amprentele sunt identice, se utilizează comanda show crypto pki certificate CA -Server
verbose pe serverul de certificare, astfel:
CA-Server# show crypto pki certificate CA -Server verbose | include Fingerprint
Fingerprint MD5: 627E62C4 EF857F80 F77FB428 6E7F260A
Fingerprint SHA1: 9090744F C425FBAD 43EA9055 9960D70D B768A77D
Prin comparație, amprentele coincid, astfel că certificatul oferit poate fi acceptat prin introducerea manuală a cuvântului “ yes” la întrebarea
“%Do you accept this certificate? [yes/no] ”. Ulterior accesptării certificatului, este primită confirmarea acceptării certificatului.
Anterior autentificării, comenzile de afișa re ale punctului de încredere și al statusului acestuia ilustrau sumar doar denumirea trustpointului și
faptul că au fost generate perechi de chei. Pentru a vizualiza efectul autentificării punctului de încredere, se reapelează c ele două comenzi. Rezultatu l
este următorul:
HE#sh crypto pki trustpoints
Trustpoint CA -Server:
Subject Name:
cn=UPB -ETTI.ro O=UPB -ETTI OU=X.509certs L=Bucuresti C=Romania
Serial Number (hex): 01
Certificate configured.
SCEP URL: http://192.168.255.51:80/cgi -bin
Se poate observa că ulterior autentificării, pe lânga denumirea punctului de încredere apar și alte informații precum: atribu tele specifice
standardului de certificare X.509 care includ numele comun, organiz ația, localitatea și țara, numărul de serie atribuit certificatului în format
hexazecimal, confirmarea configurării certificatului, dar și protocolul de înrolare SCEP ce folosesște HTTP pentru a comunica cu Autoritatea de
Certificare.
HE#sh crypto pki trustpoints status
Trustpoint CA -Server:
Issuing CA certificate configured:
Subject Name:
cn=UPB -ETTI.ro , O=UPB -ETTI OU=X.509
certs L=Bucuresti C=Romania
Fingerprint MD5: 627E62C4 EF857F80 F77FB428 6E7F260A
Fingerprint SHA1: 9090744F C425FBAD
43EA9055 9960D70D B768A77D
State:
Keys generated Yes (Usage Keys, exportable)
Issuing CA authenticated ……. Yes
Certificate request(s) ….. None
În comparație cu statusul anterior al punctului de încredere, după aute ntificarea Autorității de Certificare, se poate observa că certificatul CA a
fost configurat și apar, de asemenea, informațiile specifice standardului X.509. De asemenea, sunt illustrate amprentele MD5 și SHA1 care coincid cu
amprentele de pe serverul de c ertificare. Din punct de vedere al statusului, pe lânga confirmarea generării anterioare a cheilor, în momentul de față este
confirmată și autentificarea serverului CA emitent.
Momentan, nu există cereri de solicitare a certificatelor, urmând ca după înr olare acestea să fie solicitate pentru a asigura comunicația realizată
prin intermediul certificatelor digitale.
Ulterior autentificării, următoarea etapă în cadrul procesului de obținere a certificatelor digitale este reprezentată de îns crierea certifica telor și
configurarea pentru fiecare participant PKI în parte. Procesul de obținere a unui certificat este reprezentat de înregistrare a acestuia și poate fi obținut de
la Autoritatea de Certificare. Fiecare echipament care dorește să solicite certificate d in partea serverului CA trebuie să efectueze procesul de înscriere.
Comanda corespunzătoare înscrierii este crypto pki enroll și este urmată de denumirea serverului Autorității de Certificare. Comanda complete,
împreună cu rezultatele sale este următoarea:
HE(config)#crypto pki enroll CA -Server
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
password to the CA Administrator in order to revoke your certificate.
For security reasons your password will not be saved in the configuration.
Please make a note of it.
După apelarea comenzii, începe procesul de înrolare care urmărește mai mult e etape. Inițial, este solicitată o parolă care va fi aleasă de către
administrator. Această parolă trebuie să fie transmisă, de asemenea, și administratorului serverului Autorității de Certifica re pentru revocarea ulterioară
a certificatelor. Parola aleas ă în cazul studiului de față este “ silvia123 ” după cum se poate observa în continuare.
Password: silvia123
Re-enter password: silvia123
Ulterior alegerii parolei, sunt prezentate în cadrul consolei informațiile preluate de pe echipamentul utilizat în procesul de înrolare și care vor fi
utilizate în certificatele digitale care vor fi emise ulterior. Se poate observa, în continuare, că pentru routerul HE vor fi folosite în cadrul certificatelor
atributele specific standardului X.509, FQDN -ul, numărul de ordine, dar și adresa IP a echipamentului, care în cazul de față este reprezentată de adresa
de loopback, așa cum fost configurat inițial în cadrul declarării punctului de încredere.
% The subject name in the certificate will include: CN=HE OU=X.509certs O=UPB -ETTI C=Romania
% The subject name in the certificate will include: HE.SE.com
% The serial number in the certificate will be: 4279256517
% The IP address in the certificate is 192.168.255.21
În continuare, este solicitat acceptul/refuzul administrat orului privind solicitarea de certificat de la serverul CA. După acceptare, cererea este
trimisă către serverul Autorității de Certificare.
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
% The 'show crypto pki certificate verbose CA -Server' commandwill show the fingerprint.
May 3 21:59:15.209: CRYPTO_PKI: Signature Certificate Request Fingerprint MD5: 2FE4A274 651A98FD 3764175C 251E0423
May 3 21:59:15.209: CRYPTO_PKI: Signature Certificate Request Fingerpr int SHA1: B0153DC1 7340D96E 84AF1FE0 8125880C 5A95252F
May 3 21:59:15.697: CRYPTO_PKI: Encryption Certificate Request Fingerprint MD5: 60ED2793 34FCD296 0C2C69A1 52343398
May 3 21:59:15.713: CRYPTO_PKI: Encryption Certificate Request Fingerprint SHA1: 8D F1F368 5FC7777C 4A4EAAC7 910881FD 685184C4
Se poate observa că au fost trimise patru solicitări de certificate, două pentru semnare și două pentru criptare, corespunzăt oare amprentelor
MD5 și SHA1.
Deoarece în cadrul configurării serverului Autorității de Certificare nu a fost declarată acceptarea automata a solicitărilor, acestea vor fi
realizate manual, după cum urmează. Acceptarea manual a certificatelor aduce avantajul faptului că pot fi vizualizate detalii le procesului de obținere a
certificatelor din partea serverului CA.
Pentru vizualizarea cererilor primate de către serverul CA, se apelează comanda crypto pki server CA -Server info requests ce are următorul
rezultat:
CA-Server#crypto pki server CA -Server info requests
Enrollment Request Database:
Router certificates requests:
ReqID State Fingerprint SubjectName
–––––––––––––––––––––
4 pending 60ED279334FCD2960C2C69A152343398 serialNumber=4279256517+hostname=HE.SE. com+ipaddress=192.168.255.21,cn=HE OU \=X.509certs
O\=UPB -ETTI C \=Romania
3 pending 2FE4A274651A98FD3764175C251E0423 serialNumber=4279256517+hostname=HE.SE.com+ipaddress=192.168.255.21,cn=HE OU\=X.509certs
O\=UPB -ETTI C \=Romania
Baza de date cores punzătoare cererilor de înrolare are forma unei tabele ce conține identificatorul cererii, starea cererii, amprenta și numele
subiectului. Se poate observa că în urma cererilor transmise anterior, în baza de date a serverului CA au apărut două cereri de în registrare cu numele de
ordine 3 și 4, ce se află în stare de așteptare. Prin comparare, putem observa faptul că aceste cereri corespund celor efectu ate de echipamentul HE. În
cadrul cererii apar și informațiile despre numele subiectului, adresa FQDN, adre sa IP utilizată, dar și atributele X.509.
În scopul studiului de față, se dorește acceptarea cerificatelor care va fi efectuată manual, așa cum a fost precizat anterio r. Pentru acceptare sunt
necesari identificatorii cererilor din baza de date a serverulu i. Comanda utilizată este “crypto pki server CA -Server grant” și este necesară pentru
acceptarea fiecarei cereri în parte:
CA-Server#crypto pki server CA -Server grant 3
CA-Server#crypto pki server CA -Server grant 4
Acceptarea cererilor poate fi realizat ă și fără a preciza identificatorul solicitării, prin utilizarea comenzii crypto pki server CA -Server grant all ,
ce poate fi utilizată în cazul unui număr ridicat de cereri. Prin intermediul acesteia, sunt acceptate toate cererile înregis trate în baza de d ate a cererilor
de înrolare de pe serverul Autorității de Certificare.
În continuare, se așteaptă transmisia și recepția certificatelor, rezultatul fiind confirmat pe echipamentul solicitant, în c azul de față, routerul HE.
May 3 22:05:19.493: %PKI -6-CERTRET: Certificate received from Certificate Authority
May 3 22:05:22.769: %PKI -6-CERTRET: Certificate received from Certificate Authority
Certificatele au fost recepționate cu succes, urmând ca în continuare să fie verificată informația din ca drul acestora, dar și modul în care
cererea -primirea de certificate a influențat procesele din cadrul infrastructurii de chei publice.
Prin utilizarea comenzii show crypto pki counters pot fi vizualizate informații despre sesiunile desfășurate în cadrul i nfrastructurii de chei
publice, validări sau revocări conform listei de revocări a certificatelor:
HE#sh crypto pki counters PKI Sessions Started: 12
PKI Sessions Ended: 12
PKI Sessions Active: 0
Successful Validations: 8
Failed Validations: 0
Bypassed Validations: 0
Pending Validations: 0 CRLs checked: 0
CRL – fetch attempts: 0
CRL – failed attempts: 0
CRL – rejected busy fetching: 0
AAA authorizations: 0
Se poate observa că în urma primirii certificatelor , pe routerul HE nu mai există sesiuni PKI active, că n uau existat revocări pe baza CRL -ului
și că validările cu succes până în momentul de față sunt în număr de opt.
Pentru vizualizare certificatelor obținute de la serverul Autorității de Certificare, e ste folosită comanda show crypto pki certificates care are
următorul rezultat:
HE#show crypto pki certificates
Certificate
Status: Available
Certificate Serial Number (hex): 15
Certificate Usage: Encryption
Issuer:
cn=UPB -ETTI.ro O=UPB -ETTI OU=X.509certs L=Bucuresti C=Romania
Subject:
Name: HE.SE.com
IP Address: 192.168.255.21
Serial Number: 4279256517
cn=HE OU=X.509certs O=UPB -ETTI C=Romania
CRL Distribution Points:
http://192.168.255.51/CA -Servercdp.CA -Server.crl
Validity Date:
start date: 22:03:09 UTC May 3 2019
end date: 22:03:09 UTC May 2 2021
Associated Trustpoints: CA -Server
Storage: nvram:UPB -ETTIroOU#15.cer
Certificate
Status: Availabl e
Certificate Serial Number (hex): 14
Certificate Usage: Signature
Issuer:
cn=UPB -ETTI.ro O=UPB -ETTI OU=X.509certs L=Bucuresti C=Romania
Subject:
Name: HE.SE.com
IP Address: 192.168.255.21
Serial Number: 4279256517
cn=HE OU=X.509certs O=UPB -ETTI C=Romania
CRL Distribution Points:
http://192.168.255.51/CA -Servercdp.CA -Server.crl
Validity Date:
start date: 22:03:07 UTC May 3 2019
end date: 22:03:07 UTC May 2 2021
Associated Trustpoints: CA -Serve r
Storage: nvram:UPB -ETTIroOU#1 4.cer
Putem observa că pe echipamentul HE există două certificate disponibile, tipul certificatului fiind descris de câmpul “ Certificate usage ”. Se
confirm faptul că în urma solicitării au fost obținute două certificate, unul pentru criptare și altul pentru semnătură.
Din analiza certificatelor, pot fi evidențiate următoarele aspecte:
• Fiecărui certificat i -a fost atribuit un număr de ordine în format hexazecimal;
• Fiecare certificat conține entitatea solicitantă descrisă prin atributele X.509 (CN, O, OU, L, C);
• Câmpul “Subiect” conține informațiile pe baza cărora au fost efectuate cererile de certificate (nume, adresă IP, număr de ord ine);
• Punct ul de distribuție al listei de revocare a certificatelor este în format HTTP, având ca sursă adresa de loopback a serverului Autorității de
Certificare;
• Conform configurărilor inițiale, certificatul este valabil pe o perioada de 2 ani;
• Este afișat punctul de încredere asociat, CA -Server;
• Locația de stocare a certificatelor este memoria ram non -volatilă.
Pentru verificarea salvării certificatelor în nvram, se utilizează comanda dir nvram: care are următorul rezultat:
HE#dir nvram:
Directory of nvram:/
126 -rw- 2691 <no date> startup -config
127 –- 3811 <no date> private -config
128 -rw- 2691 <no date> underlying -config
1 –- 69 <no date> persistent -data
2 -rw- 0 <no date> ifIndex -table
3 -rw- 272 <no date> HE.HE.com -sign.pub
4 -rw- 963 <no date> HE.HE.c om-sign.prv
5 -rw- 272 <no date> HE.HE.com -encr.pub
6 -rw- 963 <no date> HE.HE.com -encr.prv
7 -rw- 717 <no date> UPB -ETTIroOU#15.cer
8 -rw- 717 <no date> UPB -ETTIroOU#14.cer
9 -rw- 615 <no date> UPB -ETTIroOU#1CA.cer
Se poate observa că cele două certificate au fost salvate în memoria nvram. Pentru vizualizarea conținut ului unui fișier din nvram, este utilizată
comanda more nvram: împreună cu denumirea fișierului. Se vizualizează, pentru exemplificare, certificatul cu numărul de ordine 15, corespunzător
criptării:
HE#more nvram:UPB -ETTIroOU#15.cer
0^B^BI0^B^B2 ^C^B^A^B^B^A^U0^F*^FH^Fw
^A^A^D^E^@0E1C0A^F^CU^D^C^S:UPB -ETTI.ro O=UPB -ETTI OU=X.509certs L=Bucuresti
C=Romania0^^^W190503220309Z^W210502220309Z0z1.0,^F^CU^D^C^S%HE OU=X.509certs O=UPB -ETTI C=Romania1H0^Q^F^CU^D^E^S42792565170^V^F
*^FH^Fw^A^B^VHE.SE.com0^[ ^F
*^FH^Fw^A^S^N192.168.255.210^A^_0^F*^FH^Fw^A^A^A^E^@^C^A^@0^A^B^A^A^@^U0w.q^U^P;^^_b$lPP4YeMp4^OS^ClpnI'N^Z+(3yWn^Dw^Nhw^E^R!
""^L[]q4n^X^S)?^BSG%^QsPR=bd6jN^[^FgL<^W|E2P!0vp(^^P:1%@!Bu]Kw^U^O2$"jL1YO=L8NS#^B^C^A^@^A#^A^S0^A^P0A^F^CU^]^_^D:0806 4
2^F0ht tp://192.168.255.51/CA -Servercdp.CA -Server.crl0^K^F^CU^]^O^D^D^C^B^E
0^_^F^CU^]#^D^X0^V^@^T8,^K^P^ \^L&D^Sx/<FX^[6r"F0^]^F^CU^]^N^D^V^D^TqU^W^S4F!6^_^R9^Nr
De asemenea, certificatele sunt salvate și în configurația echipamentului și pot fi vizualizate uti lizând următoarea comandă:
HE#show running -config | section crypto pki certificate chain CA -Server
crypto pki certificate chain CA -Server
certificate 15
308202C9 30820232 A0030201 02020115 300D0609 2A864886 F70D0101
04050030
45314330 41060355 0403133A 5550422D 45545449 2E726F20 4F3D5550
422D4554
43412D53 65727665 722E6372 6C300B06 03551D0F 04040302 0520301F
0603551D
23041830 168014B8 AC0B101C 0C26C493 78AF3CC6 588D1B36 72224630
1D060355
1D0E0416 0414F1D5 1713B446 21B60 D1F 12B90E72 8F8C8872 B551300D
06092A86
4886F70D 01010405 00038181 00E572D4 46BBA9D3 C2A0DF35 CA6A4C65
FCCDD66F 39CF6305 AECEEC37 A5190B55 2417CA54 9A75F2EB FD00AB3E D7B49E2D
A8306F3C
9124F088 D416A36B 894EC16B 78
certificate 14
30820263 308201CC A 0030201 02020101 300D0609 2A864886 F70D0101
04050030
45314330 41060355 0403133A 5550422D 45545449 2E726F20 4F3D5550
422D4554
5449204F 553D582E 35303963 65727473 204C3D42 75637572 65737469
20433D52
6F6D616E 6961301E 170D3139 30343236 31373438 31355A17 0D323330
34323531
37343831 355A3045 31433041 06035504 03133A55 50422D45 5454492E
726F204F
3D555042 2D455454 49204F55 3D582E35
quit
Serverul Autorității de Certificare păstrează o copie a certificatelor emise tot în me moria nvram, certificate pe care le poate revoca fie la finalul
perioadei de valabilitate, fie înainte de finalizarea acesteia din diferite motive de Securitate sau de nerespectare a standa rdelor.
CA-Server#dir nvram:
Directory of nvram:/
49 -rw- 1828 <no date> startup -config
50 –- 3826 <no date> private -config
1 –- 4 <no date> rf_cold_starts
2 -rw- 0 <no date> ifIndex -table
3 -rw- 272 <no date> CA -Server -sign.pub
4 -rw- 963 <no date> CA -Server -sign.prv
5 -rw- 272 <no date> CA -Server -encr.pub 6 -rw- 963 <no date> CA -Server -encr.prv
7 -rw- 33 <no date> CA -Server.ser
8 -rw- 615 <no date> 1.crt
9 -rw- 121 <no date> 1.cnm
10 -rw- 494 <no date> CA -Server.crl
11 -rw-1852 <no date> CA -Server.pem
13 -rw- 615 <no date> UPBETTIroOU#6101CA.cer
14 -rw- 717 <no date> 14.crt
15 -rw- 166 <no date> 14.cnm 16 -rw- 717 <no date> 15.crt
17 -rw- 166 <no date> 15.cnm
Funcționarea infrastructurii pentru chei publice în procesul de obținere a certificatelor
Pentru a putea analiza modalitatea în care se realizează autentificarea și înrolarea la serverul Autorității de Certificare, mai exact , modalitatea
de obținere a certificatelor digitale, a fost urmărit procesul desfășurat de infrastructura pentru chei publice prin utilizar ea debugging -ului. Astfel, a fost
pornită depanarea mesajelor prin comanda debug crypto pki messages.
1. Autentificarea serverului Autorității de Certificare
Comanda utilizată pentru autentificarea serverului CA a fost crypto pki authenticate CA -Server. După apelarea acesteia, a fost transmisă o
solicitare de certificat serverului care, conform configurației, a utilizat protocolul HTTP astfel:
CRYPTO_PKI: Sending CA Certificate Request:
GET /cgi -bin/pkiclient.exe?operation=GetCACert&message=CA -Server HTTP/1.0
User -Agent: Mozilla/4.0 (compatible; MSIE 5.0; Cisco PKI)
Host: 192.168.255.51
CRYPTO_PKI: http connection opened
CRYPTO_PKI: Sending HTTP message
În cadrul sesiunii PKI, procesul de solicitare a certificatului a fost identificat prin operația GetCACert, iar în etapa inițială, cererea a fost
transmisă catre server sub forma de mesaj HTTP către adresa de loopback 19 2.168.255.51. În continuare, răspunsul primit conține confirmarea tot
printr -un mesaj de tipul HTTP, specificându -se, de asemenea tipul mesajului conținut, aplicație – certificat standard X.509
CRYPTO_PKI: Reply HTTP header:
HTTP/1.1 200 OK
Server: cisco -IOS
Content -Type: application/x -x509 -ca-cert
Certificatul solicitat este recepționat, fiind confirmată primirea acestuia, împreună cu dimensiunea, urmată de o cerere de s olicitare a
capacităților de lucru:
Content -Type indicates we have received a CA ce rtificate.
Received 615 bytes from server as CA certificate:
CRYPTO_PKI: (0)Sending Get Capabilities Request:
GET /cgi -bin/pkiclient.exe?operation=GetCACaps&message=CA -Server HTTP/1.0
User -Agent: Mozilla/4.0 (compatible; MSIE 5.0; Cisco PKI)
Host: 192.168.255.51
Solicitarea este confirmată prin validare din partea serverului sub forma unui răspuns de tip “HTTP/1.1 200 OK”, conținutul m esajul fiind de
această dată conform mesajelor pki:
CRYPTO_PKI: Reply HTTP header:
HTTP/1.1 200 OK
Server: cisco -IOS
Content -Type: application/x -pki-message
Autentificarea serverului CA se încheie prin confirmarea completării operației GetCACert și notificarea asupra primirii certificatului CA. De
asemenea, în cadrul funcției de autentificare este actualizat statusul punctului de încredere, iar la final este afișată perioada de validitate a certificatului
conform configurației (patru ani):
CRYPTO_PKI: transaction GetCACert completed
CRYPTO_PKI: CA certificate received.
CRYPTO_PKI: CA certificate received.
CRYPTO_PKI: c rypto_pki_authenticate_tp_cert()
CRYPTO_PKI: trustpoint CA -Server authentication status = 0
PKI:get_cert CA -Server 0x10 (expired=0):
PKI:Cert valid: 17:48:15 UTC Apr 26 2019 -17:48:15 UTC Apr 25 2023 shadow 17:48:15 UTC Nov 30 2022
2. Procesul de înrolare la serverul Autorității de Certificare
Ulterior autentificării, pentru obținerea certificatelor de criptare, respectiv semnare, a fost utulizată comanda crypto pki enroll CA -Server. După
apelarea acesteia, se poate observa în cadrul mesajelor de debugging fap tul că în procesul de înregistrare este utilizată cheia privată corespunzătoare
FQDN -ului HE.SE.com. Tranzacțiile inițiale sunt încheiate prin confirmarea terminării operației de solicitare a cheilor criptograf ice:
CRYPTO_PKI: using private key HE.SE.com for enrollment
CRYPTO_PKI: Capabilites already obtained 80000000
CRYPTO_PKI: transaction PKCSReq completed
În continuare, statusul procesului desfășurat de infrastructura pentru chei publice ilustrează amprentele utilizate în cadrul solicitărilor de
certificate, proces ce este urmat de semnarea solicitărilor cu ajutorul cheilor criptografice și transmiterea acestora către serve rul CA prin intermediul
protocolului HTTP, folosind adresa de loopback 192.168.255.51:
CRYPTO_PKI: status:
CRYPTO_PKI: Signature Ce rtificate Request Fingerprint MD5: 2FE4A274 651A98FD 3764175C
CRYPTO_PKI: Signature Certificate Request Fingerprint SHA1: B0153DC1 7340D96E 84AF1FE0 8125880C 5A95252F
PKI: PKCS7 to issuer cn=UPB -ETTI.ro O=UPB -ETTI OU=X.509certs L=Bucuresti C=Romania seria l 01
PKI: Signing pkcs7 with CA -Server trustpoint temp self -signed cert
CRYPTO_PKI: Encryption Certificate Request Fingerprint MD5: 60ED2793 34FCD296 0C2C69A1 52343398
CRYPTO_PKI: Encryption Certificate Request Fingerprint SHA1: 8DF1F368 5FC7777C 4A4EAAC7 910881FD 685184C4
PKI: PKCS7 to issuer cn=UPB -ETTI.ro O=UPB -ETTI OU=X.509certs L=Bucuresti C=Romania serial 01
PKI: Signing pkcs7 with CA -Server trustpoint temp self -signed cert
CRYPTO_PKI: http connection opened
CRYPTO_PKI: Sending HTTP message
CRYPTO_PKI: Reply HTTP header:
HTTP/1.0
Host: 192.168.255.51
Cererea de certificate este transmisă către serverul CA, iar procesele PKI trec într -o stare de așteptare, până la primirea confirmării de acceptare
sau refuzare a certificatului din partea Auto rității de Certificare:
CRYPTO_PKI: status = 102: certificate request pending
CRYPTO_PKI: Send GetCertInitial for session: 0
În acest moment, solicitările de certificate din partea routerului HE sunt recepționate de serverul CA și sunt stocate în baz a de date a cererilor
de înrolare. Prin acțiunea administratorului serverului de a accepta cererile și a emite certificate, este creat, pentru fiec are solicitare în parte, un
certificate digitalcare este stocat în memoria nvram a serverului, iar ulterior transm is către entitatea solicitantă. Mesajele de debugging ilustrează în
continuare confirmarea primirii certificatului, detalii despre acesta (solicitant, valabilitate, atribute conforme standardul ui X.509), iar la final încheierea
procesului de înregistrare p rin completarea tuturor operațiilor de solicitare a certificatelor prin punctul de încredere CA -Server:
CRYPTO_PKI: status = 100: certificate is granted
The PKCS #7 message contains 1 certs and 0 crls.
Newly -issued Router Cert: issuer=cn=UPB -ETTI.ro O=UPB -ETTI OU=X.509certs L=Bucuresti C=Romania serial=1C
start date: 22:03:09 UTC May 3 2019
end date: 22:03:09 UTC May 2 2021
Router date: 22:03:09 UTC May 3 2019
Received router cert from CA
CRYPTO_PKI: All enrollment requests completed for trustpoint CA -Server..
CRYPTO_PKI: Setting renewal timers
Configurarea protocolului IKEv2 pentru securizarea topologiei
După configurarea serverului CA și obținerea certificatelor digitale pentru fiecare router din topologie, este necesară imple mentarea unei
tehnici de securizare a echipamentelor care comunică în rețea prin intermediul furnizorului de servicii (SP).
Studiul de caz prezent are ca scop configurarea și implementarea protocolului IKEv2 în cadrul rețelei. Prin folosirea unei au torități de
certificare în cadrul unei infrastructuri de chei publice și a unui protocol ce securizează schimbul de chei în Internet, ne do rim să analizăm efectele
configurațiilor din punct de vedere al securității comunicațiilor.
Pentru implementarea protocolului IKEv 2, este necesară realizarea următoarelor etape:
1. Definirea propunerii IKEv2 necesară etapei de negociere a IKE SA;
2. Definirea politicii IKEv2 pe baza propunerii, utilizată în cadrul IKE_SA_INIT;
3. Definirea profilului IKEv2 necesari în contextul schimbului de parametri în cea de -a doua etapă a negocierii;
4. Definirea profilului IPSec ce are rol în definirea parametrilor utilizați pentru criptarea datelor
5. Aplicarea profilului IPSec pe interfețele de tunel
Pentru exemplificare, va fi prezentată configurația pentru routerul HE, celelalte echipamente având configurații similare.
În scopul definirii propunerii IKEv2, este necesară vizualizarea configurațiilor premise pe echipamente, utilizând comanda show crypto ikev2
proposal , care are următorul rezultat:
HE#show crypto ikev2 proposal
IKEv2 proposal: default
Encryption : AES -CBC-256 AES -CBC-192 AES -CBC-128
Integrity : SHA512 SHA384 SHA256 SHA96 MD596
PRF : SHA512 SHA384 SHA256 SHA1 MD5
DH Group : DH_GROUP_1536_MODP/Group 5 DH_ GROUP_1024_MODP/Group 2
Pentru configurare, se alege standardul de criptare avansat cu înlănțuire de cifruri bloc pe 256 de biți, setul criptografic SHA -256 ca funcții
hash pe 256 de biți și grupul 2 Diffie -Hellman, corespunzător modulelor de 1024 de biți . Configurarea complet ă este următoarea:
crypto ikev2 proposal proposal
encryption aes -cbc-256
integrity sha256
group 2
Pentru definirea politicii IKEv2 utilizate, este necesară declararea propunerii configurate anterior, astfel:
crypto ikev2 policy policy
proposal proposal
Profilul IKEv2 trebuie să conțină în mod obligatoriu următoarele elemente:
• Identitatea utilizată pentru conectarea “la distanță”
• Modalitatea de autentificare locală și “la distanță”
În definirea profilului a fost ales domeniul fqdn SE.com ca identitate remote, valoarea fqdn HE.SE.com ca identitate locală, modalitate de
autentificare prin semnături RSA și a fost definit serverul CA ca punct de încredere PKI, după cum urmează:
crypto ikev2 profile IKEv2 -PROFILE
match identity rem ote fqdn domain SE.com
identity local fqdn HE.SE.com
authentication remote rsa -sig
authentication local rsa -sig
pki trustpoint CA -Server
Profilul IPSec declară în cadrul configurației profilul IKEv2 implementat anterior, preluându -se astfel cerințele i mpuse care urmează a fi
applicate în cadrul comunicației:
crypto ipsec profile default
set ikev2 -profile IKEv2 -PROFILE
Configurația protocolului IKEv2 se încheie cu aplicarea profilului IPSec pe interfața tunel definită în cadrul routerului HE, utilizând comanda
tunnel protection ipsec profile default.
Se pornește o captură de rețea pe o interfață corespunzătoare routerul ui HE și se analizează modul în care este implementat protocolul IKEv2.
Pentru exemplificare, va fi prezentat procesul între HE și SE1. Rezultatul capturii este următorul:
Figur a 34. Captură de rețea. Schimburile inițiale din ca drul protocolului IKEv2
Etapele procesului de implementare a IKEv2 sunt definite în cadrul Wireshark prin protocolul ISAKMP. Adresele sursă și destin ație identifică
participanții la comunicație, în cazul de față 2.3.1.14 fiind adresa SE1, iar 2.3.1.22 adr esa HE.
În captura prezentată anterior sunt ilustrate cele două etape ale primei faze IKEv2. În această fază sunt realizate negocieri le inițiale în scopul
stabilirii Asocierii de Securitate (SA).
Primul mesaj identificat în captură este un mesaj transmis de SE1 către HE și reprezintă cererea IKE_SA_INIT. Mesajul conține antetul IKE,
propuneri ale SA, algoritmi de criptare și hash, grupuri Diffie -Hellman, dar si valori “nonce”. Conținutul pachetului este urmatorul:
Figur a 35. Captură de rețea. Conținutul mesajelor de tip cerere IKE_SA_INIT
Pentru a analiza conținutul acestui mesaj, se vizualizează, payload -ul Security Association. Acesta conține propunerea inițiatorului după cum
urmează:
Payload: Security Association (33)
Next payload: Key Exchange (34)
Payload length: 48
Payload: Proposal #1
Proposal number: 1
Protocol ID: IKE (1) Proposal Transforms: 4
Payload: Transform
Transform Type: Encryption Algorithm (ENCR)
Transform ID (ENCR): ENCR_AES_CBC (12)
Payload: Transform
Transform Type: Pseudo -random Function (PRF)
Transform ID (PRF): PRF_HMAC_SHA2_256 Payload: Transform
Transform Type: Integrity Algorithm (INTEG)
Transform ID (INTEG): AUTH_HMAC_SHA2_256_128 Payload: Transform
Transform Type: Diffie -Hellman Group (D -H)
Transform ID (D -H): Alternate 1024 -bit MODP group (2)
În cadrul propunerii sunt vizualizate algoritmul de criptare ales (AES -CBC -256), funcția pseudo -aleatoare utilizată pentru hash (SHA2_256),
algoritmul utilizat pentru asigurarea integrității în cazul autentificării (AUTH_HMAC_SHA2_256_128) și grupul 2 Diffie -Hellman.
Mesajul de răspuns al etapei IKE_SA_INIT este transmis de către routerul HE, iar pachetul conține, de asemenea, propuneri ale SA, algoritmi
de crip tare și hash, grupuri Diffie -Hellman, dar si valori “nonce”:
Figur a 36. Captură de rețea. Conținutul mesajelor de tip răspuns IKE_SA_INIT
Se poate observa că în r ăspunsul corespunzător acestei etape ale negocierii apare și o so licitare de certificat, împreună cu notificarea asupra
posibilității verificării certificatelor prin HTTP. În cadrul solicitării de certificat, este precizat tipul certificatului ș i datele corespunzătoare Autorității
de Certificare:
Figur a 37. Captură de rețea. Conținutul câmpului de solicitare a certificatelor
Un aspect important al etapei IKE_SA_INIT este reprezentat de faptul că datele sunt transmise în clar, nefiind criptate, astf el că informațiile
din cadrul co municației pot fi vizualizate cu ușurință. Cea de a doua etapă a procesului de negociere elimină acest dezavantaj, astfel că cele două
mesaje corespunzătoare etapei IKE_AUTH sunt criptate și autentificate cu ajutorul Asocierii de Securitate stabilite anter ior.
IKE_AUTH are rolul de a autentifica mesajele anterioare, de a valida identitatea vecinilor IPSec, iar la final de a crea prim ul CHILD_SA.
Conținutul unui astfel de mesaj are următoarea structură, putându -se observa că informațiile transmise sunt crip tate și autentificate:
Figur a 38. Captură de rețea. Conținutul mesajelor de tip cerere IKE_AUTH
După realizarea negocierilor și a procedeelor de criptare și autentificare, urmează cea de -a doua fază a procesului de implementare I KEv2.
Această fază poartă denumirea de CREATE_CHILD_SA și are rolul de a crea noi entități CHILD_SA, dar și de a recodifica Asocier ile de Securitate
IKE SA și entitățile Child SA.
După cum se poate observa în următoarea captură, pentru această etapă sunt schimbate două mesaje de tipul cerere -răspuns:
Figur a 39. Captură de rețea. Mesaje din cadrul celei de a doua etape a protocolului IKEv2
Structura acestor mesaje are un conținut criptat și transmite noile propuneri pentru Asoci erile de Securitate, noi valori Diffie -Hellman, dar și
selectori de traffic necesari procesulu ide creare a Child SA -urilor.
Structura mesajului de tip cerere CREATE_CHILD_SA este prezentată în continuare cu ajutorul unei capturi de rețea, după cum u rmeaz ă:
Figur a 40. Captură de rețea. Conținutul mesajelor de tip cerere CREATE_CHILD_SA
Răspunsul din cadrul acestei etape conține propunerile acceptate de către entitatea respondent, la finalul acesteia finalizân du-se crearea noilor
Asocieri de Securitate Child SA.
Ultima parte a procesului de implementare IKEv2 este reprezentată de mesajele de schimb informational. Aceste mesaje conțin, pe lângă
antetul specific IKE, trei tipuri de informații după cum urmează:
• Notificări – informații legate de statusul protocolului, dar și informații despre diferite erori apărute în cadrul procesului;
• Ștergere – mesaj informational care anunță vecinii că transmițătorul a șters una sau mai multe Asocieri de Securitate;
• Configurare – informații utilizate în cadrul negocierii datelor de configurare între vecini IPSec; una dintre utilizările importante ale câmpului
de configurare este reprezentată de solicitarea și atribuirea unei adrese într -o rețea protejată de o poartă de Securitate.
În cadrul capturilor de rețea, mesajele informaționale au următoarea structură:
Figur a 41. Captură de rețea. Mesaje din cadrul ultimei etape a protocolului IKEv2
După finalizarea etapelor necesare implementării protocolului IKEv2, router ele configurate anterior sunt securizate din punct de vedere al
comunicației ce utilizează un furnizor de servicii în Internet. Pentru a putea vizualiza modificările aduse de configurarea I KEv2, vor fi utilizate diferite
comenzi pe routerul HE.
Pentru exe mplificare, vor fi prezentate statisticile corespunzătoare protocolului IKEv2 pentru comunicația dintre HE și SE1.
Sesiunea crypto curentă, împreună cu statusul ei pot fi vizualizate cu ajutorul comenzii show crypto session care prezintă informații despre
fiecare vecin asociat sesiunii, interfața folosită, asociația de securitate conformă protocolului IKEv2, dar și lista de acce s care permite stabilirea
conexiunii securizate. Pentru a ilustra statusul sesiunii dintre HE și SE 1, este folosită următoarea comandă împreună cu rezultatele sale:
HE#show crypto session
Crypto session current status
Interface: Tunnel10
Session status: UP -ACTIVE
Peer: 2.3.1.14 port 500
IKEv2 SA: local 2.3.1.22/500 remote 2.3.1.14/500 Active
IPSEC FLOW: permit 47 host 2.3.1.22 host 2.3.1.14
Active SAs: 2, origin: crypto map
Pentru a vizualiza statusul detaliat al sesiunii curente, se utilizează comanda show crypto session detail, care în comparație cu comanda
anterioară, afișează și informații despre durata de timp în care sesiunea a fost activă, identificatorul corespunzător fazei 1 pentru vecinul cu a dresa
2.3.1.14, timpul de viată al asocierii de securitate, dar și numărul pachetelor criptate și decriptate cu succes.
HE#sh cryp to sess detail
Crypto session current status
Interface: Tunnel10
Uptime: 00:02:23
Session status: UP -ACTIVE
Peer: 2.3.1.14 port 500 fvrf: (none) ivrf: (none)
Phase1_id: SE1.SE.com
Desc: (none)
IKEv2 SA: local 2.3.1.22/500 remote 2.3.1.14/500 Active
Capabilities:(none) connid:2 lifetime:23:57:37
IPSEC FLOW: permit 47 host 2.3.1.22 host 2.3.1.14
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 36 drop 0 life (KB/Sec) 4265788/3457
Outbound: #pkts enc'ed 35 drop 0 life (KB/Sec) 4265787/3457
Comenzile specifice protocolului IKEv2 sunt definite de sintagma “ show crypto ikev2”. Astfel, pot fi vizualizate propu nerea, politica aleasă și
profilul IKEv2, conform configurațiilor inițiale pentru implementarea securității. Pentru a ilustra asociațiile de Securitate create în cadrul primei faze
IKEv2, se utilizează comanda show crypto ikev2 sa care are următoarele rezu ltate:
HE# show crypto ikev2 sa
IPv4 Crypto IKEv2 SA
Tunnel -id Local Remote fvrf/ivrf Status
2 2.3.1.22/500 2.3.1.14/500 none/none READY
Encr: AES -CBC, keysize: 256, Hash: SHA256, DH Grp:2, Auth sign: RSA, Auth verify: RSA
Life/Active Time: 86400/908 sec
Acest rezultat furnizează informații despre Asociația de Securitate creată între HE și SE1. Sunt prezente detalii despre ide ntificatorul tunelului
corespunzător SA -ului, adresa locală și cea remote, statusul SA, dar și algoritmul de criptare, algoritmul utilizat pentru hash, metoda de aut entificare și
timpul de viață al asocierii.
Pentru a obține un rezultat mai detaliat al co menzii, se utilizează comanda show crypt ikev2 sa detailed astfel:
HE#sh cry ike sa detailed
IPv4 Crypto IKEv2 SA
Tunnel -id Local Remote fvrf/ivrf Status
2 2.3.1.22/500 2.3.1.14/500 none/none READY
Encr: AES -CBC, keysize: 256, Hash: SHA256, DH Grp:2, Auth sign: RSA, Auth verify: RSA
Life/Active Time: 86400/1593 sec
CE id: 1006, Session -id: 3
Status Description: Negotiation done
Local spi: 1400B35 4619581C6
Remote spi: 017E65D94F333EEB
Local id: HE.SE.com
Remote id: SE1.SE.com
Local req msg id: 0
Remote req msg id: 2
Local next msg id: 0
Remote next msg id: 2
Local req queued: 0
Remote req queued: 2
Local window: 5
Remote window: 5
DPD configured for 0 seconds, retry 0
NAT -T is not detected
Cisco Trust Security SGT is disabled
Initiator of SA: No
Această comandă oferă, în plus, detalii despre identificat orul sesiunii, statusul negocierii, indecșii parametrilor de securitate utilizați,
identificatorul local și remote în format FQDN, dar și informații despre mesajele transmise între cele două echipamente în ca drul stabilirii SA.
Sesiunea crypto curentă core spunzătoare protocolului IKEv2 poate fi vizualizată cu ajutorul comenzii show crypto ikev2 session care
ilustează, comparativ cu comanda sesiunii crypto descrisa anterior, și entitățile Child SA create în cadrul celei de a doua e tape IKE. Rezultatul
comenzii este următorul:
HE#show crypto ikev2 session
IPv4 Crypto IKEv2 Session
Session -id:3, Status:UP -ACTIVE, IKE count:1, CHILD count:1
Tunnel -id Local Remote fvrf/ivrf Status
2 2.3.1.22/500 2.3.1.14/500 none/none READY
Encr: AES -CBC, keysize: 256, Hash: SHA256, DH Grp:2, Auth sign: RSA, Auth verify: RSA
Life/Active Time: 86400/1791 sec
Child sa: local selector 2.3.1.22/0 – 2.3.1.22/65535
remote selector 2.3.1.14/0 – 2.3.1.14/65535
ESP spi in/out: 0x460F093/0x915BEA40
Se poate observa că, pe lângă informațiile prezentate anterior, în cazul comenzii de afișare a sesiunii IKEv2, sunt prezente și detalii
despre asociația de securitate Child SA, în cadrul căreia sunt descriși selectori locali și remote, dar și indecsii parametrilor de securitate
corespunzători protocolului ESP. Prin solicitarea detaliată a informațiilor despre sesiunile active IKEv2, se obțin următoare le rezultate:
HE#sh ow crypto ike v2 sess ion detailed
IPv4 Crypto IKEv2 Session
Session -id:1, Status: UP-ACTIVE, IKE count:1, CHILD count:1
Tunnel -id Local Remote fvrf/ivrf Status
1 2.3.1.22/500 2.3.1.14/500 none/none READY
Encr: AES -CBC, keysize: 256, Hash: SHA256, DH Grp:2, Auth sign: RSA, Auth verify: RSA
Life/Active Time: 86400/255 sec
CE id: 1003, Session -id: 1
Status Description: Negotiation done
Local spi: 91F8C1701197078B
Remote spi: FEDF573344968D43
Local id: HE.SE.com
Remote id: SE1.SE.com
Local req msg id: 0
Remote req msg id: 2
Local next msg id: 0 Remote next msg id: 2
Local req queued: 0
Remote req queued: 2
Local window: 5
Remote window: 5
DPD configured for 0 seconds, retry 0
NAT -T is not detected
Cisco Trust Security SGT is disabled
Initiator of SA: No
Child sa: local selector 2.3.1.2 2/0 – 2.3.1.22/65535
remote selector 2.3.1.14/0 – 2.3.1.14/65535
ESP spi in/out: 0x4EC801B7/0xD6C6CB89
AH spi in/out: 0x0/0x0
CPI in/out: 0x0/0x0
Encr: AES -CBC, keysize: 128, esp_hmac: SHA96
ah_hmac: None, comp: IPCOMP_NONE, mode transport
Ca o modalitate finală de verificare a implementării cu succes a protocolului IKEv2 pentru securizarea comunicațiilor între e chipamente, se
utilizează o captură de rețea care ilustrează dacă pach etele de date sunt transmise în clar sau au fost criptate. Rezultatul este următorul:
Figure 42. Captură de rețea. Funcționarea protocolului IKEv2 prin confirmarea criptării
42
Se confirmă, astfel, funcționarea corectă a protocol ului IKEv2, datele din cadrul comunicației fiind criptate, fapt demonstrat de utilizarea
protocolului ESP.
43
44
CAPITOLUL 6 – CONCLUZII
6.1 Concluzii generale
Protocolul IKEv2, protocol de schimb al cheilor în Internet, prezintă o soluție eficientă pentru securizarea comunicațiilor î n cadrul topologiilor
hub-and-spoke. In scopul lucrării de față, asigurarea protecției datelor din punct de vedere al confidențiali tății, integrității, dar și al autentificării
participanților a fost realizată prin implementarea unei infrastructuri pentru chei publice PK I și a protocoalelor de încapsulare și criptare.
Prezența unei Autorități de Certificare cu rol în generarea și adm inistrarea certificatelor digitale, împreună cu un protocol eficient de criptare
care asigură confidențialitatea informațiilor transmise pe canalul de comunicație a determinat securizarea transferului de da te în topologia hub -and-
spoke utilizată .
În urma unei analize funcționale și criptografice, utilizarea încapsulării la nivel de canal folosind tunele multipunct GRE și a protocolul ui
IKEv2 pentru securizarea pachetelor de date, a condus la realizarea unei protecții eficiente a informației. Prin utilizare a certificatelor digitale, procesul
de înrolare a participanților din cadrul comunicației a permis implementarea unor metode de autentificare a acestora care, conform unor principii de
acces la canalul de comunicație verifică identitatea entităților și împ iedică accesul unui presupus atacator.
Din punct de vedere al securității, protocolul IKEv2 reprezintă o soluție funcțională și criptografică sigură, cu avantaje ev idente. Modalitățile
de implementare permit alegerea procedeului care corespunde cel mai bi ne rezultatelor așteptate, cu rezultate optime în fiecare dintre cazuri.
În scopul testării vulnerabilităților, protocolul IKEv2 s -a dovedit a fi un protocol care oferă securitate ridicată comunicațiilor. Deși a fost
evidențiată o serie de vulnerabilități care face ca topologia de rețea să poată fi atacată cu succes, soluțiile asupra acesto ra prezintă modalități eficiente
de a mitiga eventualele atacuri.
Ca o concluzie asupra analizelor teoretice și experimentale, rețelele private virtuale reprezintă o modalitate sigură de comunicație. Prin
utilizarea împreună cu acestea a tehnicii DMVPN, a instrastructurii pentru chei publice PKI, dar și a protocolului IKEv2, sol uția re zultată poate
garanta cu succes transferul securizat al informațiilor “sensibile” în cazul traversării unei rețele publice.
6.2 Contribuții personale
În scopul lucrării de față, obiectivele propuse inițial au fost îndeplinite , obținându -se, ca produs fin al, comunicații protejate cu IKEv2 și IPSec
în topologia din cadrul studiului de caz.
Contribuțiile personale evidențiază analize funcționale și experimentale, alături de rezultate favorabile. De asemenea, testa rea implementării
practice ilustrează realiz area unei soluții optime din punct de vedere al securității comunicațiilor.
Dintre acestea, pot fi amintite următoarele:
45
• A fost realizată analiza funcțională și criptografică a protocolului IKEv2 pentru fiecare variantă de implementare, și tinând cont și de
considerentele atacului KRACK, s -a stabilit un grad de securitate mai ridicat pentru implementarea cu certificate digitale .
• Au fost analizați diferiți algoritmi criptografici și protocoale de comunicație în scopul determinării celor mai eficiente va riante de
implementare;
• A fost studiat principiul de funcționare a infrastructurilor pentru chei publice în scopul determinării avantajelor utilizări i unor Autorități de
Certificare ca terță parte în cadrul comunicației .
• Conform rezultatelor analizelor, a f ost aleasă și implementată varianta protocolului IKEv2 care utilizează o infrastructură pentru chei publice și
certificate digitale în cadrul unei topologii de tipul hub -and-spoke în care comunicația este realizată prin intermediul unui furnizor de servici i.
• Testarea funcționalității implementării a prezentat rezultate favorabile în contextul comunicațiilor securizate.
• Analiza experimentală a protocolului IKEv2 a avut ca rezultat determinarea unui grad ridicat de securitate al acestuia, care, utilizând rețe le
private virtuale, reușește să înlature vulnerabilitățile prezentate de rezultatele analizei funcționale și criptografice.
Contribuțiile personale asupra lucrări de față au determinat realizarea unui studi u de caz complex care urmărește cerințele de securitate actuale,
asigurând protecția comunicației prin intermediul unei rețele publice.
6.3 Dezvoltări ulterioare
Rezultatele analizelor funcționale, criptografice și experimentale sugerează implementarea cu succes a securității rețelelor IP pentru topologia
aleasă în cadrul studiului de caz. Cu toate acestea, a fost dovedită prezență anumitor vulnerabilități în cazul protocolului IKEv2. Pe lângă acestea,
IKEv2 fiind un protocol din suita IPSec, preia și punctele “slabe” ale protocolului IPSec.
Deși aceste vulnerabilități prezintă și soluții de mitigare, o testare amănunțită poate fi realizată prin testarea infiltrări i adversarilor, utilizând
distribuția Kali Linux. Exemple de atacuri ce pot fi analizate sunt următoarele:
• DoS/DDoS – protocolul IKEv2 s -a dovedit a fi pasibil de aceste atacuri și prezintă diferite soluții de mitigare în funcție de modalitatea de
impleme ntare
• Atacuri de dictionar pentru aflarea parolelor – a se observa faptul că în cadrul studiului de caz au fost alese parole cu un grad foarte scăzut de
complexitate (“ silvia123 ”)
• Atacuri de impersonare bazate pe oracole Bleichenbacher – atac asupra semnăturilor digitale
• Atac Man -in-the-middle – realizat prin modificarea parametrilor Diffie -Hellman, în scopul compromiterii cheilor secrete. (fără aplicabilitate
practică în momentul de față).
Din punct de vedere al topolgiei utilizate, există o serie de dezvoltări care pot fi realizate ulterior:
46
• Utilizarea unui echipament care să suporte atât protocolul IKEv2 cât și configurarea Autorității de Certificare – server http (ex. Cisco IO S XE)
• Configurare Dual Hub pentru asigurarea redundanței prin stabilirea tunelelor statice între cele două echipamente Hub și tunele dinamice către
echipamentele Spoke
• Configurare FlexVPN pentru simplificarea implementării soluțiilor VPN
• Configurarea listelor de acces ACL pentru filtrarea traficului în cadrul topologiei
• Utilizarea crypto map pentru selecția traficului sub formă de liste de acces.
47
Bibliografie
[1] Catrina, O., „ Cryptographic Algorithms and Protocols ”, Editura Matrix Rom , București 2016
[2] Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone. Handbook of
Applied Cryptography. CRC Press, 1996, 2001
[3] Catrina, O., Curs „ Securitatea Rețelelor și Serviciilor” , http://discipline.elcom.pub.ro/srs1/curs , accesat la data 12.09.2018
[4] RFC2401, „ Security Architecture for the Internet Protocol ” , The Internet Society (1998)
[5] RFC6071, „ IP Security (IPSec) and Internet Key Exchange (IKE) Document Roadmap ” , Internet Engineering Task Force (IETF)
[6] RFC5996, „ Internet Key Exchange Protocol Version 2 (IKEv2) ” , Internet Engineering Task Force (IETF)
[7] RFC2784, „ Generic Routing Encapsulation (GRE) ”, The Internet Society (2000)
[8] RFC2328, „ OSPF Version 2 ” , The Inte rnet Society (1998)
[9] RFC2332, „ NBMA Next Hop Resolution Protocol (NHRP) ” , The Internet Society (1998)
[10] RFC5280, „ Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profilre ”
[11] RFC6489, „ Certification Auth ority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI) ” , Internet Engineering Task Force
(IETF)
[12] RFC2631, „ Diffie -Hellman Key Agreement Method ” , The Internet Society (1999)
[13] Clarke, G., „ CompTIA Security + Certification Study Guide, Second Edition” , Editura Mc Graw Hill Education
[14] Cremers, C., „ Key Exchange in IPSec revisited: Formal Analysis of IKEv1 and IKEv2 ”
[15] APNIC eLearning, Course „ IPSec Basics”
[16] Salman, F., Indonsian Journal od Electrical Engineering and Computer Science, „ Implementation od IPSec -VPN Tunneling using GNS3” ,
Septembrie 2017
[17] Katuwal, A., „ Deploying and Testing IKEv2, Flex VPN and GET VPN” , Metropolia University of Applied Scien ces, November 2017
[18] Kozierok, C., „ The TCP/IP Guide: A Comprehensive, illustrated Internet Protocols Reference ”, first edition
[19] W. Diffie, P. van Oorschot and M. Wiener, „ Authentication and authenticated key exchanges ”, Design, Codes and Cryptograp hy, 2, 1992, pp
107-125
[20] N. Ferguson, B. Schneier, „ A Cryptographic Evaluation od IPSec ”
[21] Goldreich, O., „ Foundations of Cryptographic: Basic Tools ”, Cambridge Press, 2001
[22] Perlman, R. și Kufman, C., „ Analysis of the IPSec key exchange Standard ”, WET -ICE Security Confefrence, MIT, 2001
[23] Catrina, O., „ Cryptoraphy and Security in Communication Networks, IPSec and Secure VPNs”, Curs ETTI -Master -Advanced Wireless
Telecommunications
[24] „Studey of mechanism ensuring service continuity for IKEv2 and IPSec protocols”, https://tes.archives -ouvertes.fr/tel -00939092 accesat la data
21.10.2018
48
[25] CCNP Routing and Switching ROUTE 300 -101 Official Cert Guide, Video Enhanced Edition
[26] CCIE Routing and Switching v5.1 Foundations: Bridging the Gap Between CCNP and CCIE
[27] „Dynamic Multipoint IPSec VPNs (Using Multipoint GRE/NHRP to Scale IPSec VPNs)”, https://www.cisco.com/c/en/us/support/docs/security –
vpn/ipsec -negotiation -ike-protocols/41940 -dmvpn.html accesat la data 25.10.2018
[28] „ Basic Cryptographic concepts used for authentication ”, CISCO Incubator, Jan Krupa, 23 Nov 2016
[29] „ VPN Connectivity Models ”, CISCO Incubator, Jesus Casero Diaz -Cano, 30 Nov 2016
[30] „ An Ilustrated Guide to IPSec ”, http://www.unixwiz.net/techtips/iguide -ipsec.html accesat la data 24.11.2018
[31] „ Undestandind VPN IPSec Tunnel Mode and IPSec Transport Mode – What’s the difference?” http://www.firewall.cx/networking –
topics/protocols/870 -ipsec-modes.html accesat la data 24.11.2018
[32] „ Tunelare și VPN – Proiectarea rețelelor”, Curs GRE, IPSec, https://ocw.cs.pub.ro/courses/_media/pr/courses/pr_curs09_gre_ipsec.pdf accesat
la data 24.11.2018
[33] „ Public Key Infrastructure – An Enabler for Secure Trusted Computing” , Martin Serauskis , SANS Institute 2003
[34] „PKI, The What, The Why, and The How”, Duncan Wood, SANS Institute, Information Security Reading Room
[35] „IOS PKI Deployment Guide, Certificate Rollover – Configuration and Operation Overview ”,
https://www.cisco.com/c/en/us/support/docs/security -vpn/public -key-infrastructure -pki/211322 -IOS-PKI-Deployment -Guide -Certificate -Ro.html
accesat la data 08.01.20 19
[36] „Public Key Infrastructure Configuration Guide, Cisco IOS Release 15MT” , https://www.cisco.com/c/en/us/td/docs/ios –
xml/ios/sec_conn_pki/configuration/15 -mt/sec -pki-15-mt-book/sec -cfg-mng-cert-serv.html accesat la data 11.01.2019
[37] „ Dynamic to Dynamic IPSec Tunnel Configuration Example” , https://www.cisco.com/c/en/us/support/docs/security -vpn/ipsec -architecture –
implementation/118048 -technote -ipsec -00.html accesat la data 11.01.2019
[38] „ Cisco IOS Certificate Enrollment Using Enhanced Enrollment Commands Configuration Example” ,
https://www.cisco.com/c/en/us/support/docs/security -vpn/ipsec -negotiation -ike-protocols/27860 -ios-enhanced -enrollment.html accesat la data
13.01.2019
[39] „ Configure and Enroll a Cisco IOS Router to Another Cisco IOS Router Configured as a CA Server” ,
https://www.cisco.com/c/en/us/support/docs/security -vpn/ipsec -negotiation -ike-protocols/50282 -ios-ca-ios.html accesat la data 13 .01.2019
[40] „ Configuring a GRE Tunnel over IPSec with OSPF” , https://www.cisco.com/c/en/us/support/docs/security -vpn/ipsec -negotiation -ike-
protocols/14381 -gre-ipsec -ospf.html accesat la data 28.12.2018
[41] „Configuring Dynamic Multipoint VPN (DMVPN) using GRE over IPSec between Multiple
Routers” ,https://www.cisco.com/c/en/us/support/docs/security -vpn/ipsec -negotiation -ike-protocols/29240 -dcmvpn.html accesat la data 28.12.2019
[42] „Configuring IPSec Router -to-Router Hub and Spoke with Communication Between the
Spokes” ,https://www.cisco.com/c/en/us/suppor t/docs/security -vpn/ipsec -negotiation -ike-protocols/7912 -ios-hub-spoke2.html accesat la data
02.02.2019
[43] „DMVPN Phase 1 Debugs Troubleshoot Guide” , https://www.cisco.com/c/en/us/support/docs/security -vpn/dynamic -multi -point -vpn-
dmvpn/116957 -technote -dmvpn -00.html accesat la data 17.02.2019
49
[44] „ DMVPN Hub as the CA Server for the DMVPN Network Configuration Example” ,
https://www.cisco.com/c/en/us/support/docs/security/dynamic -multipoint -vpn-dmvpn/117688 -config -dmvpn -00.html accesat la data 18.02.2019
[45] „ Dynamic to Dynamic IPsec Tunnel Configuration Example ”, https://www.cisco.com/c/en/us/support/docs/security -vpn/ipsec -architecture –
implementation/118048 -technote -ipsec -00.html accesat la data 12.02.2019
[46] „ IOS PKI Auto -Enroll, Auto -Rollover, and Timers ”, https://www.cisco.com/c/en/us/support/docs/security -vpn/public -key-infrastructure –
pki/116094 -technote -pki-00.html accesat la data 10.02.2019
[47] „ IOS PKI Deployment Guide: Initial Design and Deployment ”, https://www.cisco.com/c/en/us/support/docs/security -vpn/public -key-
infrastructure -pki/211333 -IOS-PKI-Deployment -Guide -Initial -Design.html accesat la data 11.02.2019
50
Anexe
Anexa 1 – Configurație S1
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname S1
!
boot -start -marker
boot -end-marker
!
!
!
no aaa new -model
no ip icmp rate -limit unreachable
ip cef
!
!
!
no ip domain lookup
no ipv6 cef
!
!
multilink bundle -name authenticated
!
!
!
ip tcp synwait -time 5
!
!
!
interface Loopback0
ip address 192.168.255.12 255.255.255.255 !
interface FastEthernet0/0
ip address 3.3.1.2 255.255.255.0
duplex full
!
router ospf 1
network 3.3.1.0 0.0.0.255 area 0
network 192.168.255.12 0.0.0.0 area 0
!
ip forward -protocol nd
!
!
no ip http server
no ip http secure -server
ip route 0.0.0.0 0.0.0.0 FastEthernet0/0
control -plane
!
!
line con 0
exec -timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line aux 0
exec -timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line vty 0 4
login
!
51
!
End
Anexa 2 – Configurație S2
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname S2
!
boot -start -marker
boot -end-marker
!
!
!
no aaa new -model
no ip icmp rate -limit unreachable
ip cef
!
!
!
no ip domain lookup
no ipv6 cef
!
!
multilink bundle -name authenticated
!
!
!
ip tcp synwait -time 5
!
!
!
interface Loopback0 ip address 192.168.255.42 255.255.255.255
!
interface FastEthernet0/0
ip address 3.3.4.2 255.255.255.0
duplex full
!
router ospf 1
network 3.3.4.0 0.0.0.255 area 0
network 192.168.255.42 0.0.0.0 area 0
!
ip forward -protocol nd
!
!
no ip http server
no ip http secure -server
ip route 0.0.0.0 0.0.0.0 FastEthernet0/0
!
!
Anexa 3 – Configurație S3
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname S3
!
boot -start -marker
boot -end-marker
!
!
!
no aaa new -model
ip cef
!
52
!
!
no ipv6 cef
!
!
multilink bundle -name authenticated
!
!
!
interface Loopback0
ip address 192.168.255.32 255.255.255.255
!
interface FastEthernet0/0
ip address 3.3.3.2 255.255.255.0
duplex full
!
router ospf 1
network 3.3.3.0 0.0.0.255 are a 0
network 192.168.255.32 0.0.0.0 area 0
!
ip forward -protocol nd
!
!
no ip http server
no ip http secure -server
!
!
!
control -plane
!
!
line con 0
exec -timeout 0 0
stopbits 1 line aux 0
stopbits 1
line vty 0 4
login
!
!
End
Anexa 4 – Configurație H
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname H
!
boot -start -marker
boot -end-marker
!
!
!
no aaa new -model
no ip icmp rate -limit unreachable
ip cef
!
!
!
no ip domain lookup
no ipv6 cef
!
!
multilink bundle -name authenticated
!
!
!
53
ip tcp synwait -time 5
!
!
!
interface Loopback0
ip address 192.168.255.22 255.255.255.255
!
interface FastEthernet0/0
ip address 3.3.2.2 255.255.255.0
duplex full
!
router ospf 1
network 3.3.2.0 0.0.0.255 area 0
network 192.168.255.22 0.0.0.0 area 0
!
ip forward -protocol nd
!
!
no ip http server
no ip http secure -server
ip route 0.0.0.0 0.0.0.0 FastEthernet0/0
!
!
!
control -plane
!
!
line con 0
exec -timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line aux 0
exec -timeout 0 0 privilege level 15
logging synchronous
stopbits 1
line vty 0 4
login
!
!
End
Anexa 5 – Configurație SE1
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname SE1
!
boot -start -marker
boot -end-marker
!
!
!
no aaa new -model
no ip icmp rate -limit unreachable
ip cef
!
!
!
no ip domain lookup
ip domain name SE.com
no ipv6 cef
!
!
multilink bundle -name authenticated
!
54
crypto pki trustpoint CA -Server
enrollment retry count 5
enrollment retry period 3
enrollment url http://192.168.255.51:80
serial -number
fqdn SE1.SE.com
ip-address 192.168.255.11
subject -name CN=SE2 OU=X.509certs O=UPB -ETTI C=Romania
revocation -check none
source interface Loopba ck0
!
!
crypto pki certificate chain CA -Server
certificate 16 nvram:UPB -ETTIroOU#16.cer
certificate 17 nvram:UPB -ETTIroOU#17.cer
certificate ca 01 nvram:UPB -ETTIroOU#1CA.cer
!
!
!
ip tcp synwait -time 5
!
!
crypto ikev2 proposal proposal
encryption aes -cbc-256
integrity sha256
group 2
!
crypto ikev2 policy policy
proposal proposal
!
!
crypto ikev2 profile IKEv2 -PROFILE
match identity remote fqdn domain SE.com
identity local fqdn SE1.SE.com authentication remote rsa -sig
authenticat ion local rsa -sig
pki trustpoint CA -Server
!
!
!
crypto ipsec profile default
set ikev2 -profile IKEv2 -PROFILE
!
!
!
interface Loopback0
ip address 192.168.255.11 255.255.255.255
!
interface Tunnel1
ip address 100.100.100.2 255.255.255.0
no ip redirects
ip mtu 1416
ip nhrp map 100.100.100.1 2.3.1.22
ip nhrp map multicast 2.3.1.22
ip nhrp network -id 1
ip nhrp holdtime 300
ip nhrp nhs 100.100.100.1
ip ospf network broadcast
ip ospf priority 0
ip ospf mtu -ignore
tunnel source FastE thernet2/0
tunnel mode gre multipoint
tunnel key 999
tunnel protection ipsec profile default
!
interface FastEthernet0/0
ip address 3.3.1.1 255.255.255.0
duplex full
55
!
interface FastEthernet2/0
ip address 2.3.1.14 255.255.255.252
duplex full
!
route r ospf 1
network 3.3.1.0 0.0.0.255 area 0
network 100.100.100.0 0.0.0.255 area 0
network 192.168.255.11 0.0.0.0 area 0
!
ip forward -protocol nd
!
!
ip http server
no ip http secure -server
ip route 0.0.0.0 0.0.0.0 FastEthernet2/0
!
!
!
control -plane
!
!
line con 0
exec -timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line aux 0
exec -timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line vty 0 4
login !
ntp server 3.3.5.2
!
End
Anexa 6 – Configurație SE2
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname SE2
!
boot -start -marker
boot -end-marker
!
!
!
no aaa new -model
no ip icmp rate -limit unreachable
ip cef
!
!
!
no ip domain lookup
ip domain name SE.com
no ipv6 cef
!
!
multilink bundle -name authenticated
!
crypto pki trustpoint CA -Server
enrollment retry count 5
enrollment retry period 3
56
enrollment url http://192.168.255.51:80
serial -number
fqdn SE2.SE.com
ip-address 192.168.255.41
subject -name CN=SE2 OU=X.509certs O=UPB -ETTI C=Romania
revocation -check none
source interface Loopback0
!
!
crypto pki certificate chain CA -Server
certificate 1A nvram:UPB -ETTIroOU#1A.cer
certificate 1B nvram:UPB -ETTIroOU#1B.cer
certificate ca 01 nvr am:UPB -ETTIroOU#1CA.cer
!
!
!
ip tcp synwait -time 5
!
!
crypto ikev2 proposal proposal
encryption aes -cbc-256
integrity sha256
group 2
!
crypto ikev2 policy policy
proposal proposal
!
!
crypto ikev2 profile IKEv2 -PROFILE
match identity remote fqdn domain SE.com
identity local fqdn SE2.SE.com
authentication remote rsa -sig
authentication local rsa -sig
pki trustpoint CA -Server !
!
!
crypto ipsec profile default
set ikev2 -profile IKEv2 -PROFILE
!
!
!
interface Loopback0
ip address 192.168.255.41 255.255.255.255
!
interface Tunnel2
ip address 100.100.100.3 255.255.255.0
no ip redirects
ip mtu 1416
ip nhrp map 100.100.100.1 2.3.1.22
ip nhrp map multicast 2.3.1.22
ip nhrp network -id 1
ip nhrp holdtime 300
ip nhrp nhs 100.100.100.1
ip ospf network broadcast
ip ospf priority 0
ip ospf mtu -ignore
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel key 999
tunnel protection ipsec profile default
!
interface FastEthernet0/0
ip address 3.3.4.1 255.255.255.0
duplex full
!
interface FastEthernet1/0
ip address 2.3.1.18 255.255.255.252
57
duplex full
!
router ospf 1
network 3.3.4.0 0.0.0.255 area 0
network 100.100.100.0 0.0.0.255 area 0
network 192.168.255.41 0.0.0.0 area 0
!
ip forward -protocol nd
!
!
ip http server
no ip http secure -server
ip route 0.0.0.0 0.0.0.0 FastEthernet1/0
!
!
!
control -plane
!
!
line con 0
exec -timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line aux 0
exec -timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line vty 0 4
login
!
ntp server 3.3.5.2
! End
Anexa 7 – Configurație SE3
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname SE3
!
boot -start -marker
boot -end-marker
!
!
!
no aaa new -model
ip cef
!
!
!
ip domain name SE.com
no ipv6 cef
!
!
multilink bundle -name authenticated
!
crypto pki trustpoint CA -Server
enrollment retry count 5
enrollment retry period 3
enrollment url http://192.168.255.51:80
serial -number
fqdn SE3.SE.com
ip-address 192.168.255.31
subject -name CN=SE2 OU=X.509certs O=UPB -ETTI C=Romania
revocation -check none
58
source interface Loopback0
!
!
crypto pki certificate chain CA -Server
certificate 18 nvram:UPB -ETTIroOU#18.cer
certificate 19 nvram:UPB -ETTIroOU#19.cer
certificate ca 01 nvram:UPB -ETTIroOU#1CA.cer
!
!
!
crypto ikev2 proposal proposal
encryption aes -cbc-256
integrity sha256
group 2
!
crypto ikev2 policy policy
proposal proposal
!
!
crypto ikev2 profile IKEv2 -PROFILE
match identity remote fqdn domain SE.com
identity local fqdn SE3.SE.com
authentication remote rsa -sig
authentication local rsa -sig
pki trustpoint CA -Server
!
!
!
crypto ipsec profile default
set ikev2 -profile IKEv2 -PROFILE
!
!
!
interface Loopback0 ip address 192.168.255.31 255.255.255.255
!
interface Tunnel3
ip address 100.100.100.4 255.255.255.0
no ip redirects
ip mtu 1416
ip nhrp map 100.100.100.1 2.3.1.22
ip nhrp map multicast 2.3.1.22
ip nhrp network -id 1
ip nhrp holdtime 300
ip nhrp nhs 100.100.100.1
ip ospf network broadcast
ip ospf priority 0
ip ospf mtu -ignore
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel key 999
tunnel protection ipsec profile default
!
interface FastEthernet0/0
ip address 3.3.3.1 255.255.255.0
duplex full
!
interface FastEthernet1/0
ip address 2.3.1.26 255.255.255.252
duplex full
!
router ospf 1
network 3.3.3.0 0.0.0.255 area 0
network 100.100.100.0 0.0.0.255 area 0
network 192.168.255.31 0.0.0.0 area 0
!
ip forward -protocol nd
!
59
!
ip http server
no ip http secure -server
ip route 0.0.0.0 0.0.0.0 FastEthernet1/0
!
!
!
control -plane
!
!
line con 0
exec -timeout 0 0
stopbits 1
line aux 0
stopbits 1
line vty 0 4
login
!
ntp server 3.3.5.2
!
End
Anexa 8 – Configurație HE
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname HE
!
boot -start -marker
boot -end-marker
!
!
! no aaa new -model
no ip icmp rate -limit unreachable
ip cef
!
!
!
no ip domain lookup
ip domain name SE.com
no ip v6 cef
!
!
multilink bundle -name authenticated
!
crypto pki trustpoint CA -Server
enrollment retry count 5
enrollment retry period 3
enrollment url http://192.168.255.51:80
serial -number
fqdn HE.SE.com
ip-address 192.168.255.21
subject -name CN=HE OU=X.509certs O=UPB -ETTI C=Romania
revocation -check none
source interface Loopback0
!
!
crypto pki certificate chain CA -Server
certificate 15 nvram:UPB -ETTIroOU#15.cer
certificate 14 nvram:UPB -ETTIroOU#14.cer
certificate ca 01 nvra m:UPB -ETTIroOU#1CA.cer
!
!
!
ip tcp synwait -time 5
!
60
!
crypto ikev2 proposal proposal
encryption aes -cbc-256
integrity sha256
group 2
!
crypto ikev2 policy policy
proposal proposal
!
!
crypto ikev2 profile IKEv2 -PROFILE
match identity remote fqdn domain SE.com
identity local fqdn HE.SE.com
authentication remote rsa -sig
authentication local rsa -sig
pki trustpoint CA -Server
!
!
!
crypto ipsec profile default
set ikev2 -profile IKEv2 -PROFILE
!
!
!
interface Loopback0
ip address 192.168.255.21 255.255.255.255
!
interface Tunnel10
ip address 100.100.100.1 255.255.255.0
no ip redirects
ip mtu 1416
ip nhrp map multicast dynamic
ip nhrp network -id 1
ip nhrp holdtime 300 ip ospf network broadcast
ip ospf priority 255
ip ospf mtu -ignore
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel key 999
tunnel protection ipsec profile default
!
interface FastEthernet0/0
ip address 3.3.2.1 255.255.255.0
duplex full
!
interface FastEthernet1/0
ip address 2.3.1 .22 255.255.255.252
duplex full
!
interface FastEthernet2/0
ip address 3.3.5.1 255.255.255.0
duplex full
!
router ospf 1
network 3.3.2.0 0.0.0.255 area 0
network 3.3.5.0 0.0.0.255 area 0
network 100.100.100.0 0.0.0.255 area 0
network 192.168.255.21 0.0.0.0 area 0
default -information originate
!
ip forward -protocol nd
!
!
ip http server
no ip http secure -server
ip route 0.0.0.0 0.0.0.0 FastEthernet1/0
!
61
!
!
control -plane
!
!
line con 0
exec -timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line aux 0
exec -timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line vty 0 4
login
!
ntp server 3.3.5.2
!
End
Anexa 9 – Configurație SP1
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname SP1
!
boot -start -marker
boot -end-marker
!
!
! no aaa new -model
no ip icmp rate -limit unreachable
ip cef
!
!
!
no ip domain lookup
no ipv6 cef
!
!
multilink bundle -name authenticated
!
!
!
ip tcp synwait -time 5
!
!
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
interface FastEthernet0/0
ip address 2.3.1.5 255.255.255.252
duplex full
!
interface FastEthernet1/0
ip address 2.3.1.21 255.255.255.252
duplex full
!
interface FastEthernet2/0
ip address 2.3.1.13 255.255.255.252
duplex full
!
interface FastEthernet3/0
62
ip address 2.3.1.9 255.255.255.252
duplex full
!
router ospf 1
passive -interface FastEthernet1/0
passive -interface FastEthernet2/0
network 2.3.1.0 0.0.0.255 area 0
network 5.5.5.5 0.0.0.0 area 0
!
ip forward -protocol nd
!
!
no ip http server
no ip http secure -server
!
!
!
control -plane
!
!
line con 0
exec -timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line aux 0
exec -timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line vty 0 4
login
!
! end
Anexa 10 – Configurație SP2
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname SP2
!
boot -start -marker
boot -end-marker
!
!
!
no aaa new -model
no ip icmp rate -limit unreachable
ip cef
!
!
!
no ip domain lookup
no ipv6 cef
!
!
multilink bundle -name authenticated
!
!
!
ip tcp synwait -time 5
!
!
!
63
interface Loopback0
ip address 6.6.6.6 255.255.255.255
!
interface FastEthernet0/0
ip address 2.3.1.6 255.255.255.252
duplex full
!
interface FastEthernet1/0
ip address 2.3.1.17 255.255.255.252
duplex full
!
interface FastEthernet2/0
ip address 2.3.1.1 255.255.255.252
duplex full
!
router ospf 1
passive -interface FastEthernet1/0
network 2.3.1.0 0.0.0.255 area 0
network 6.6.6.6 0.0.0.0 are a 0
!
ip forward -protocol nd
!
!
no ip http server
no ip http secure -server
!
!
!
!
control -plane
!
!
line con 0
exec -timeout 0 0 privilege level 15
logging synchronous
stopbits 1
line aux 0
exec -timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line vty 0 4
login
!
!
End
Anexa 11 – Configurație SP3
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname SP3
!
boot -start -marker
boot -end-marker
!
!
!
no aaa new -model
no ip icmp rate -limit unreachable
ip cef
!
!
!
no ip domain lookup
no ipv6 cef
64
!
!
multilink bundle -name authenticated
!
!
!
ip tcp synwait -time 5
!
!
!
interface Loopback0
ip address 7.7.7.7 255.255.255.255
!
interface FastEthernet0/0
no ip address
shutdown
duplex full
!
interface FastEthernet1/0
ip address 2.3.1.25 255.255.255.252
duplex full
!
interface FastEthernet2/0
ip address 2.3.1.2 255.255.255.252
duplex full
!
interface FastEthernet3/0
ip address 2.3.1.10 255.255.255.252
duplex full
!
router ospf 1
passive -interface FastEthernet1/0
network 2.3.1.0 0.0.0.255 area 0
network 7.7.7.7 0.0.0.0 area 0 !
ip forward -protocol nd
!
!
no ip http server
no ip http secure -server
!
!
!
control -plane
!
!
line con 0
exec -timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line aux 0
exec -timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line vty 0 4
login
!
!
end
Anexa 12 – Configurație CA -Server
version 12.4
service timestamps debug datetime msec
service timestamps log dat etime msec
no service password -encryption
!
65
hostname CA -Server
!
boot -start -marker
boot -end-marker
!
!
no aaa new -model
!
resource policy
!
memory -size iomem 5
ip subnet -zero
no ip icmp rate -limit unreachable
ip cef
ip tcp synwait -time 5
!
!
!
no ip domain lookup
!
!
!
crypto pki server CA -Server
database level complete
database username Silvia_Ioana_Stanciu
database archive pem password 7 083245421F1004464058
issuer -name CN=UPB -ETTI.ro O=UPB -ETTI OU=X.509certs L=Bucuresti
C=Romania
lifetime crl 24
lifetime certificate 730
lifetime ca -certificate 1460
cdp-url http://192.168.255.51/CA -Servercdp.CA -Server.crl
!
crypto pki trustpoint CA -Server revocation -check crl
rsakeypair CA -Server
!
!
crypto pki certificate chain CA -Server
certificate ca 01 nvram:UPB -ETTIroOU#6101CA.cer
!
!
!
interface Loopback0
ip address 192.168.255.51 255.255.255.255
!
interface FastEthernet0/0
no ip address
shutdown
duplex auto
speed auto
!
interface FastEthernet0/1
no ip address
shutdown
duple x auto
speed auto
!
interface FastEthernet2/0
ip address 3.3.5.2 255.255.255.0
duplex auto
speed auto
!
router ospf 1
log-adjacency -changes
redistribute static subnets
network 3.3.5.0 0.0.0.255 area 0
network 192.168.255.51 0.0.0.0 area 0
66
!
ip classless
!
ip http server
no ip http secure -server
!
!
!
control -plane
!
!
!
line con 0
exec -timeout 0 0
privilege level 15
logging synchronous
line aux 0
exec -timeout 0 0
privilege level 15
logging synchronous
line vty 0 4
login
!
ntp master
!
end
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Comunicații protejate cu IKEv2 și IPSec: analiza securității și [628594] (ID: 628594)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.