Tehnologia IPsec. Abonați-vă la noi

În lumea modernă, peste tot sunt folosite diverse tehnologii VPN. Unele (de exemplu, PPTP) sunt recunoscute ca fiind nesigure în timp și se sting treptat, altele (OpenVPN), dimpotrivă, își măresc impulsul în fiecare an. Dar liderul incontestabil și cea mai recunoscută tehnologie pentru crearea și menținerea canalelor private securizate este încă VPN IPsec. Uneori, în timpul unui pentest, puteți găsi o rețea serios protejată, cu doar cinci sute de port UDP ieșit în afară. Orice altceva poate fi închis, corectat și filtrat în mod fiabil.

Într-o astfel de situație, poate apărea gândul că nu este nimic special de făcut aici. Dar nu este întotdeauna cazul. În plus, există o idee larg răspândită că IPsec, chiar și în configurațiile implicite, este inexpugnabil și oferă nivelul adecvat de securitate. Aceasta este exact situația pe care o vom analiza în practică astăzi. Dar mai întâi, pentru a combate IPsec cât mai eficient posibil, trebuie să înțelegeți ce este și cum funcționează. Asta vom face!

IPsec din interior

Înainte de a trece direct la IPsec în sine, ar fi bine să ne amintim ce tipuri de VPN-uri există. Există o mulțime de clasificări VPN, dar nu ne vom aprofunda tehnologii de rețeași să o luăm pe cea mai simplă. Prin urmare, vom împărți VPN în două tipuri principale - conexiuni VPN de la site la site (pot fi numite și permanente) și VPN de acces la distanță (RA, de asemenea temporar).

Primul tip servește pentru comunicarea constantă a diferitelor insule de rețea, de exemplu, un birou central cu multe ramuri împrăștiate. Ei bine, RA VPN este un scenariu în care un client se conectează pentru o perioadă scurtă de timp și obține acces la anumite resursele rețelei iar după terminarea lucrărilor se oprește în siguranță.

Ne va interesa a doua opțiune, deoarece în cazul unui atac reușit putem obține imediat acces la rețeaua internăîntreprindere, ceea ce este o realizare destul de serioasă pentru un pentester. IPsec, la rândul său, vă permite să implementați atât VPN de la site la site, cât și de la distanță. Ce fel de tehnologie este aceasta și din ce componente constă?

Este demn de remarcat faptul că IPsec nu este unul, ci un întreg set de protocoale diferite care oferă transparent și protectie sigura date. Specificul IPsec este că este implementat la nivelul rețelei, completându-l în așa fel încât totul să se întâmple neobservat pentru straturile ulterioare. Principala dificultate este că, în procesul de stabilire a conexiunii, doi participanți la un canal securizat trebuie să cadă de acord asupra unui număr destul de mare de parametri diferiți. Și anume, trebuie să se autentifice reciproc, să genereze și să facă schimb de chei (și printr-un mediu neîncrezător) și, de asemenea, să convină asupra protocoalelor pentru a cripta datele.

Din acest motiv, IPsec constă dintr-un teanc de protocoale a căror responsabilitate este să asigure stabilirea, funcționarea și gestionarea unei conexiuni securizate. Întregul proces de stabilire a conexiunii constă din două faze: prima fază este utilizată pentru a asigura schimbul securizat de mesaje ISAKMP în a doua fază. ISAKMP (Internet Security Association and Key Management Protocol) este un protocol care servește la negocierea și actualizarea politicilor de securitate (SA) între participanții la o conexiune VPN. Aceste politici indică în mod specific ce protocol să utilizați pentru a cripta (AES sau 3DES) și cu ce să vă autentificați (SHA sau MD5).

Două faze principale ale IPsec

Așadar, am aflat că participanții trebuie mai întâi să cadă de acord asupra mecanismelor care vor fi folosite pentru a crea o conexiune sigură, așa că acum intră în joc protocolul IKE. IKE (Internet Key Exchange) este folosit pentru a forma o IPsec SA (Security Association, aceleași politici de securitate), cu alte cuvinte, pentru a coordona munca participanților la o conexiune securizată. Prin acest protocol, participanții convin asupra algoritmului de criptare care va fi utilizat, ce algoritm va fi utilizat pentru a verifica integritatea și cum să se autentifice reciproc. Trebuie remarcat faptul că astăzi există două versiuni ale protocolului: IKEv1 și IKEv2. Ne va interesa doar IKEv1: în ciuda faptului că IETF (The Internet Engineering Task Force) l-a introdus pentru prima dată în 1998, este încă foarte des folosit, în special pentru VPN-urile RA (vezi Figura 1).


Orez. 1. Expert VPN Cisco ASDM

În ceea ce privește IKEv2, primele sale schițe au fost făcute în 2005, a fost complet descris în RFC 5996 (2010) și abia la sfârșitul anului trecut a fost anunțat ca standard de internet (RFC 7296). Puteți citi mai multe despre diferențele dintre IKEv1 și IKEv2 în bara laterală. După ce ne-am ocupat de IKE, revenim la fazele IPsec. În prima fază, participanții se autentifică reciproc și convin asupra parametrilor de instalare conexiune specială, destinat doar schimbului de informații despre algoritmii de criptare doriti și alte detalii ale viitorului tunel IPsec. Parametrii acestui prim tunel (numit și tunel ISAKMP) sunt determinați de politica ISAKMP. Primul pas este să cădeți de acord asupra hashurilor și a algoritmilor de criptare, apoi există un schimb de chei Diffie-Hellman (DH) și abia apoi își dă seama cine este cine. Adică, ultimul pas este procesul de autentificare, fie folosind o cheie PSK, fie RSA. Iar dacă părțile ajung la o înțelegere, atunci se stabilește un tunel ISAKMP, prin care trece deja a doua fază a IKE.

În a doua fază, participanții care au deja încredere unii în alții convin asupra modului de construire a tunelului principal pentru transferul direct de date. Își oferă unul altuia opțiunile specificate în parametrul transform-set și, dacă sunt de acord, ridică tunelul principal. Este important de subliniat că, odată ce este stabilit, tunelul auxiliar ISAKMP nu merge nicăieri - este folosit pentru a actualiza periodic SA-ul tunelului principal. Ca rezultat, IPsec stabilește într-un fel nu unul, ci două tuneluri.

Cum se prelucrează datele

Acum câteva cuvinte despre transform-set. La urma urmei, trebuie să criptezi cumva datele care trec prin tunel. Prin urmare, într-o configurație tipică, transform-set este un set de parametri care indică în mod explicit cum ar trebui procesat pachetul. În consecință, există două opțiuni pentru o astfel de prelucrare a datelor - protocoalele ESP și AH. ESP (Encapsulating Security Payload) se ocupă direct de criptarea datelor și poate oferi, de asemenea, verificarea integrității datelor. AH (Authentication Header), la rândul său, este responsabil doar pentru autentificarea sursei și verificarea integrității datelor.

De exemplu, comanda `crypto ipsec transform-set SET10 esp-aes` va indica routerului că transformarea-setul cu numele `SET10` ar trebui să funcționeze numai folosind protocolul ESP și cu criptare AES. Privind în viitor, voi spune că în continuare vom folosi ca ținte routerele și firewall-urile Cisco. De fapt, cu ESP totul este mai mult sau mai puțin clar, sarcina lui este să cripteze și astfel să asigure confidențialitatea, dar de ce atunci este nevoie de AH? AH oferă autentificarea datelor, adică confirmă că aceste date provin exact de la cel cu care am stabilit legătura și nu au fost modificate pe parcurs. Oferă ceea ce se numește uneori protecție anti-reluare. În rețelele moderne, AH practic nu este utilizat doar ESP poate fi găsit peste tot.

Parametrii (aka SA) selectați pentru a cripta informațiile dintr-un tunel IPsec au o durată de viață, după care trebuie înlocuiți. Setarea implicită IPsec SA pentru durata de viață este de 86.400 de secunde sau 24 de ore.

Drept urmare, participanții au primit un tunel criptat cu parametri care li se potriveau tuturor și au trimis fluxuri de date pentru a fi criptate acolo. Periodic, în conformitate cu durata de viață, cheile de criptare pentru tunelul principal sunt actualizate: participanții comunică din nou prin tunelul ISAKMP, trec prin a doua fază și restabilesc SA.

moduri IKEv1

Am aruncat o privire rapidă asupra mecanismelor de bază ale modului în care funcționează IPsec, dar mai sunt câteva lucruri pe care trebuie să ne concentrăm. Prima fază, printre altele, poate funcționa în două moduri: modul principal sau modul agresiv. Am discutat deja despre prima variantă mai sus, dar ne interesează modul agresiv. Acest mod folosește trei mesaje (în loc de șase în modul principal). În acest caz, cel care inițiază conexiunea oferă toate datele sale deodată - ce vrea și ce poate face, precum și partea sa din schimbul DH. Răspunsul își finalizează imediat porțiunea din generația DH. Ca rezultat, există în esență doar două etape în acest mod. Adică, primele două etape din modul principal (acord hash și schimb DH) sunt, parcă, comprimate într-una singură. Ca urmare, acest mod este mult mai periculos datorită faptului că răspunsul vine cu o mulțime de informații tehnice în text clar. Și cel mai important, gateway-ul VPN poate trimite o parolă hash, care este folosită pentru autentificare în prima fază (această parolă este adesea numită cheie pre-partajată sau PSK).

Ei bine, toată criptarea ulterioară are loc fără modificări, ca de obicei. Atunci de ce se mai folosește acest mod? Cert este că este mult mai rapid, cam de două ori mai rapid. Un interes deosebit pentru pentester este faptul că modul agresiv este foarte des folosit în RA IPsec VPN. O altă mică caracteristică a VPN RA IPsec atunci când utilizați modul agresiv: atunci când clientul contactează serverul, acesta îi trimite un identificator (numele grupului). Numele grupului de tunel (vezi Figura 2) este numele unei intrări care conține un set de politici pentru o anumită conexiune IPsec. Aceasta este deja una dintre caracteristicile specifice echipamentelor Cisco.


Orez. 2. Numele grupului de tunel

Două faze nu au fost suficiente

S-ar părea că oricum nu merge prea bine circuit simplu de lucru, dar în realitate este încă puțin mai complicat. De-a lungul timpului, a devenit clar că PSK singur nu era suficient pentru a asigura securitatea. De exemplu, dacă stația de lucru a unui angajat a fost compromisă, atacatorul ar putea obține imediat acces la întreaga rețea internă a întreprinderii. Prin urmare, faza 1.5 a fost dezvoltată chiar între prima și a doua fază clasică. Apropo, această fază nu este de obicei utilizată într-o conexiune VPN standard de la site la site, ci este utilizată atunci când se organizează conexiuni VPN la distanță (cazul nostru). Această fază conține două noi extensii - Extended Authentication (XAUTH) și Mode-Configuration (MODECFG).

XAUTH este o autentificare suplimentară a utilizatorului în cadrul protocolului IKE. Această autentificare este uneori numită și al doilea factor IPsec. Ei bine, MODECFG servește la transmiterea informațiilor suplimentare către client, aceasta ar putea fi o adresă IP, mască, server DNS etc. Se poate observa că această fază pur și simplu le completează pe cele discutate anterior, dar utilitatea ei este neîndoielnică.

IKEv2 vs IKEv1

Ambele protocoale funcționează pe portul UDP numărul 500, dar sunt incompatibile între ele, situația în care există IKEv1 la un capăt al tunelului și IKEv2 la celălalt; Iată principalele diferențe dintre a doua versiune și prima:

În IKEv2 nu mai există concepte precum moduri agresive sau principale.
- În IKEv2, termenul de primă fază este înlocuit cu IKE_SA_INIT (un schimb de două mesaje care asigură negocierea protocoalelor de criptare/hashing și generarea de chei DH), iar a doua fază este înlocuită cu IKE_AUTH (tot două mesaje care implementează autentificarea). în sine).
- Mode Config (ceea ce a fost numit faza 1.5 în IKEv1) este acum descris direct în specificația protocolului și este o parte integrantă a acesteia.
- IKEv2 a adăugat un mecanism suplimentar de protecție împotriva atacurilor DoS. Esența sa este că înainte de a răspunde la fiecare solicitare în stabilirea unei conexiuni securizate (IKE_SA_INIT) IKEv2, gateway-ul VPN trimite un anumit cookie la sursa unei astfel de solicitări și așteaptă un răspuns. Dacă sursa a răspuns - totul este în ordine, puteți începe să generați DH cu el. Dacă sursa nu răspunde (așa se întâmplă în cazul unui atac DoS; această tehnică amintește de inundația TCP SYN), atunci gateway-ul VPN pur și simplu uită de asta. Fără acest mecanism, cu fiecare cerere din partea oricui, gateway-ul VPN ar încerca să genereze o cheie DH (care este un proces destul de intensiv în resurse) și în curând s-ar confrunta cu probleme. Drept urmare, din cauza faptului că toate operațiunile necesită acum confirmare din partea cealaltă a conexiunii, este imposibil să se creeze un număr mare de sesiuni pe jumătate deschise pe dispozitivul atacat.

Ajungem la linie

După ce ați înțeles în sfârșit caracteristicile de operare ale IPsec și componentele sale, puteți trece la principalul lucru - atacuri practice. Topologia va fi destul de simplă și în același timp apropiată de realitate (vezi Fig. 3).


Orez. 3. Schema generala retelelor

Primul pas este să determinați prezența unui gateway VPN IPsec. Acest lucru se poate face efectuând o scanare a portului, dar există o mică caracteristică aici. ISAKMP folosește protocolul UDP, portul 500, în timp ce scanarea implicită cu Nmap afectează numai porturile TCP. Și ca rezultat va apărea un mesaj: `Toate cele 1000 de porturi scanate de pe 37.59.0.253 sunt filtrate`.

Se pare că toate porturile sunt filtrate și nu există porturi deschise. Dar după executarea comenzii

Nmap -sU --top-ports=20 37.59.0.253 Pornind Nmap 6.47 (http://nmap.org) la 2015-03-21 12:29 GMT Raport de scanare Nmap pentru 37.59.0.253 Gazda este activată (latență de 0,066 s) . SERVICIUL STATUL PORTULUI 500/udp deschis isakmp
Ne asigurăm că acesta nu este cazul și că acesta este într-adevăr un dispozitiv VPN.

Să atacăm prima fază

Acum ne va interesa prima fază, modul agresiv și autentificarea folosind cheia pre-partajată (PSK). În acest scenariu, așa cum ne amintim, dispozitivul VPN sau răspunsul trimite un PSK hash către inițiator. Una dintre cele mai cunoscute utilitare pentru testarea protocolului IKE este ike-scan, este inclusă în distribuția Kali Linux. Ike-scan vă permite să trimiteți mesaje IKE cu diverși parametri și, în consecință, să decodați și să analizați pachetele de răspuns. Să încercăm să verificăm dispozitivul țintă:

Root@kali:~# ike-scan -M -A 37.59.0.253 0 strângere de mână returnată; 0 notificare returnată

Orez. 4. Ike-scan modul agresiv

Comutatorul `-A` indică faptul că trebuie utilizat modul agresiv, iar `-M` indică faptul că rezultatele trebuie afișate linie cu linie (multilinie), pentru o citire mai ușoară. Este clar că nu s-a obținut niciun rezultat. Motivul este că trebuie să specificați același identificator, numele grupului VPN. Desigur, utilitarul ike-scan vă permite să setați acest identificator ca unul dintre parametrii săi. Dar, din moment ce ne este încă necunoscut, să luăm o valoare arbitrară, de exemplu 0000.

Root@kali:~# ike-scan -M -A --id=0000 37.59.0.253 37.59.0.253 Strângere de mână în mod agresiv a fost returnată


Orez. 5. ID-ul Ike-scan

De data aceasta vedem că răspunsul a fost primit (vezi Fig. 5) și ni s-au oferit destul de multe Informatii utile. O parte destul de importantă a informațiilor primite este setul de transformare. În cazul nostru, se afirmă că „Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK”.

Toți acești parametri pot fi specificați pentru utilitarul ike-scan folosind comutatorul `--trans`. De exemplu, `--trans=5,2,1,2` va indica faptul că algoritmul de criptare este 3DES, hashing HMAC-SHA, metoda de autentificare PSK și al doilea tip de grup DH (1024-bit MODP). Puteți vizualiza tabelele de corespondență valoric la această adresă. Să adăugăm o altă cheie (`-P`) pentru a afișa direct sarcina utilă a pachetului, sau mai degrabă hash-ul PSK.

Root@kali:~# ike-scan -M -A --id=0000 37.59.0.253 -P


Orez. 6. Sarcina utilă Ike-scan

Depășirea primelor dificultăți

S-ar părea că hașul a fost obținut și poți încerca să-l brutezi, dar totul nu este atât de simplu. Pe vremuri, în 2005, unele hardware Cisco aveau o vulnerabilitate: aceste dispozitive dădeau un hash doar dacă atacatorul trecea valoarea corectă a ID-ului. Acum, desigur, este aproape imposibil să găsești un astfel de echipament și valoarea hashed este întotdeauna trimisă, indiferent de valoarea corectă ID-ul a fost trimis de atacator sau nu. Evident, hashingul cu forță brută este inutil. Prin urmare, prima sarcină este de a determina valoarea corectă a ID-ului pentru a obține hash-ul corect. Și o vulnerabilitate recent descoperită ne va ajuta în acest sens.

Ideea este că există o mică diferență între răspunsuri în timpul schimbului inițial de mesaje. Pe scurt, dacă se folosește numele corect al grupului, există patru încercări de a continua stabilirea conexiunii VPN plus două pachete criptate faza a doua. În timp ce în cazul unui ID incorect, doar două pachete ajung ca răspuns. După cum puteți vedea, diferența este destul de semnificativă, așa că SpiderLabs (autorul instrumentului Responder la fel de interesant) a dezvoltat mai întâi un PoC și apoi utilitarul IKEForce pentru a exploata această vulnerabilitate.

Care este puterea IKE

Puteți instala IKEForce într-un director arbitrar rulând comanda

Clona Git https://github.com/SpiderLabs/ikeforce
Funcționează în două moduri principale - modul de calcul `-e` (enumerare) și modul forță brută `-b` (forță brută). Vom ajunge la al doilea când ne uităm la atacurile asupra celui de-al doilea factor, dar ne vom ocupa de primul acum. Înainte de a începe procesul real de determinare a ID-ului, trebuie să setați valoarea exactă a setului de transformare. Am definit-o deja mai devreme, așa că o vom specifica cu opțiunea `-t 5 2 1 2`. Ca rezultat, procesul de găsire a ID-ului va arăta astfel:

Python ikeforce.py 37.59.0.253 -e -w liste de cuvinte/group.txt -t 5 2 1 2


Orez. 7. Enumerarea IKEForce

Ca rezultat, a fost posibil să se obțină destul de rapid valoarea ID corectă (Fig. 7). Primul pas a fost finalizat, puteți merge mai departe.

Primim PSK

Acum trebuie să utilizați nume corect grupuri, salvați hash-ul PSK într-un fișier, acest lucru se poate face folosind ike-scan:

Ike-scan -M -A --id=vpn 37.59.0.253 -Pkey.psk
Și acum că a fost găsită valoarea corectă a ID-ului și a fost obținut hash-ul PSK corect, putem începe în sfârșit forța brută offline. Există destul de multe opțiuni pentru o astfel de forță brută - acesta este utilitarul clasic psk-crack și John the Ripper (cu un patch jumbo) și chiar oclHashcat, care, după cum se știe, vă permite să utilizați puterea GPU. Pentru simplitate, vom folosi psk-crack, care acceptă atât forța brută directă, cât și atacul de dicționar:

Psk-crack -d /usr/share/ike-scan/psk-crack-dictionary key.psk

Orez. 8. Psk-crack

Dar chiar și restabilirea cu succes a PSK (vezi Fig. 8) este doar jumătate din luptă. În această etapă, trebuie să ne amintim că ceea ce ne așteaptă în continuare este XAUTH și al doilea factor al VPN IPsec.

Se confruntă cu al doilea factor IPsec

Deci, permiteți-mi să vă reamintesc că XAUTH este o securitate suplimentară, un al doilea factor de autentificare și este în faza 1.5. Pot exista mai multe opțiuni pentru XAUTH - aceasta include verificarea utilizând protocolul RADIUS, parole unice (OTP) și o bază de utilizatori locale obișnuită. Ne vom concentra asupra situației standard când o bază de utilizatori locale este folosită pentru a verifica al doilea factor. Până de curând, nu a existat un instrument pentru acces public pentru forța brută XAUTH. Dar odată cu apariția IKEForce, această problemă a primit o soluție demnă. Lansarea forței brute XAUTH este destul de simplă:

Python ikeforce.py 37.59.0.253 -b -i vpn -k cisco123 -u admin -w wordlists/passwd.txt -t 5 2 1 2 [+]Programul a început în XAUTH Brute Force Mode [+]Furnizat un singur utilizator - forțare brută parole pentru utilizator: admin [*]Autentificare XAUTH reușită! Nume utilizator: admin Parola: cisco


Orez. 9. IKEForce XAUTH

În acest caz, sunt indicate toate valorile găsite anterior: ID (cheia `-i`), PSK restaurat (cheia `-k`) și autentificarea dorită (cheia `-u`). IKEForce acceptă atât căutarea în forță brută a unei autentificări, cât și căutarea printr-o listă de autentificări, care poate fi specificată cu parametrul `-U`. In caz de posibilă blocare selectare există o opțiune `-s`, care vă permite să reduceți viteza forței brute. Apropo, utilitarul vine cu mai multe dicționare bune, utile în special pentru setarea valorii parametrului ID.

Conectați-vă la rețeaua internă

Acum că avem toate datele, rămâne ultimul pas - pătrunderea efectivă în rețeaua locală. Pentru a face acest lucru, vom avea nevoie de un fel de client VPN, dintre care există foarte multe. Dar în cazul lui Kali, puteți utiliza cu ușurință VPNC-ul deja preinstalat. Pentru ca acesta să funcționeze, trebuie să ajustați un fișier de configurare - `/etc/vpnc/vpn.conf`. Dacă nu există, atunci trebuie să creați și să completați o serie de parametri evidenti:

Gateway IPSec 37.59.0.253
ID IPSec vpn
IPSec secret cisco123
IKE Authmode psk
Xauth Nume de utilizator admin
Parola Xauth cisco

Aici vedem că au fost folosite absolut toate datele găsite în pașii anteriori - valoarea ID, PSK, login și parola celui de-al doilea factor. După care conexiunea în sine are loc cu o singură comandă:

Root@kali:~# vpnc vpn
Dezactivarea este, de asemenea, destul de simplă:

Root@kali:~# vpnc-disconnect
Puteți verifica funcționalitatea conexiunii folosind comanda `ifconfig tun0`.


Orez. 10. VPNC

Cum să construiți o protecție fiabilă

Protecția împotriva atacurilor discutate astăzi trebuie să fie cuprinzătoare: trebuie să instalați patch-uri la timp, să folosiți chei puternice pre-partajate, care, dacă este posibil, ar trebui înlocuite cu certificate digitale. Politica de parole și alte elemente evidente ale securității informațiilor joacă, de asemenea, un rol important în asigurarea securității. De asemenea, trebuie menționat că situația se schimbă treptat, iar în timp va rămâne doar IKEv2.

Care este rezultatul?

Am acoperit în detaliu procesul de audit RA IPsec VPN. Da, desigur, această sarcină este departe de a fi banală. Trebuie să faci mulți pași, iar dificultățile te pot aștepta la fiecare dintre ei, dar dacă reușești, rezultatul este mai mult decât impresionant. Obținerea accesului la resursele rețelei interne deschide cea mai largă posibilitate pentru actiunile urmatoare. Prin urmare, cei care sunt responsabili pentru protejarea perimetrului rețelei nu ar trebui să se bazeze pe șabloane implicite gata făcute, ci să se gândească cu atenție la fiecare nivel de securitate. Ei bine, pentru cei care efectuează pentesturi, portul UDP detectat cinci sute este un motiv pentru a efectua o analiză profundă a securității VPN IPsec și, eventual, pentru a obține rezultate bune.

Abonați-vă la „Hacker”

În lumea modernă, peste tot sunt folosite diverse tehnologii VPN. Unele (de exemplu, PPTP) sunt recunoscute ca fiind nesigure în timp și se sting treptat, altele (OpenVPN), dimpotrivă, își măresc impulsul în fiecare an. Dar liderul incontestabil și cea mai recunoscută tehnologie pentru crearea și menținerea canalelor private securizate este încă VPN IPsec. Uneori, în timpul unui pentest, puteți găsi o rețea serios protejată, cu doar cinci sute de port UDP ieșit în afară. Orice altceva poate fi închis, corectat și filtrat în mod fiabil.

Într-o astfel de situație, poate apărea gândul că nu este nimic special de făcut aici. Dar nu este întotdeauna cazul. În plus, există o idee larg răspândită că IPsec, chiar și în configurațiile implicite, este inexpugnabil și oferă nivelul adecvat de securitate. Aceasta este exact situația pe care o vom analiza în practică astăzi. Dar mai întâi, pentru a combate IPsec cât mai eficient posibil, trebuie să înțelegeți ce este și cum funcționează. Asta vom face!

IPsec din interior

Înainte de a trece direct la IPsec în sine, ar fi bine să ne amintim ce tipuri de VPN-uri există. Există o mulțime de clasificări ale VPN-urilor, dar nu ne vom scufunda adânc în tehnologiile de rețea și o vom lua pe cea mai simplă. Prin urmare, vom împărți VPN în două tipuri principale - conexiuni VPN site-to-site (pot fi numite și permanente) și VPN cu acces la distanță (RA, de asemenea temporar).

Primul tip servește pentru comunicarea constantă a diferitelor insule de rețea, de exemplu, un birou central cu multe ramuri împrăștiate. Ei bine, RA VPN este un scenariu în care un client se conectează pentru o perioadă scurtă de timp, obține acces la anumite resurse de rețea și apoi se deconectează în siguranță după finalizarea lucrării.

Vom fi interesați de a doua opțiune, deoarece în cazul unui atac de succes, este posibil să obțineți imediat acces la rețeaua internă a întreprinderii, ceea ce este o realizare destul de serioasă pentru un pentester. IPsec, la rândul său, vă permite să implementați atât VPN de la site la site, cât și de la distanță. Ce fel de tehnologie este aceasta și din ce componente constă?

Este de remarcat faptul că IPsec nu este unul, ci un întreg set de protocoale diferite care oferă protecție transparentă și sigură a datelor. Specificul IPsec este că este implementat la nivelul rețelei, completându-l în așa fel încât totul să se întâmple neobservat pentru straturile ulterioare. Principala dificultate este că, în procesul de stabilire a conexiunii, doi participanți la un canal securizat trebuie să cadă de acord asupra unui număr destul de mare de parametri diferiți. Și anume, trebuie să se autentifice reciproc, să genereze și să facă schimb de chei (și printr-un mediu neîncrezător) și, de asemenea, să convină asupra protocoalelor pentru a cripta datele.

Din acest motiv, IPsec constă dintr-un teanc de protocoale a căror responsabilitate este să asigure stabilirea, funcționarea și gestionarea unei conexiuni securizate. Întregul proces de stabilire a conexiunii constă din două faze: prima fază este utilizată pentru a asigura schimbul securizat de mesaje ISAKMP în a doua fază. ISAKMP (Internet Security Association and Key Management Protocol) este un protocol care servește la negocierea și actualizarea politicilor de securitate (SA) între participanții la o conexiune VPN. Aceste politici indică în mod specific ce protocol să utilizați pentru a cripta (AES sau 3DES) și cu ce să vă autentificați (SHA sau MD5).

Două faze principale ale IPsec

Așadar, am aflat că participanții trebuie mai întâi să cadă de acord asupra mecanismelor care vor fi folosite pentru a crea o conexiune sigură, așa că acum intră în joc protocolul IKE. IKE (Internet Key Exchange) este folosit pentru a forma o IPsec SA (Security Association, aceleași politici de securitate), cu alte cuvinte, pentru a coordona munca participanților la o conexiune securizată. Prin acest protocol, participanții convin asupra algoritmului de criptare care va fi utilizat, ce algoritm va fi utilizat pentru a verifica integritatea și cum să se autentifice reciproc. Trebuie remarcat faptul că astăzi există două versiuni ale protocolului: IKEv1 și IKEv2. Ne va interesa doar IKEv1: în ciuda faptului că IETF (The Internet Engineering Task Force) l-a introdus pentru prima dată în 1998, este încă foarte des folosit, în special pentru VPN-urile RA (vezi Figura 1).


Orez. 1. Expert VPN Cisco ASDM

În ceea ce privește IKEv2, primele sale schițe au fost făcute în 2005, a fost complet descris în RFC 5996 (2010) și abia la sfârșitul anului trecut a fost anunțat ca standard de internet (RFC 7296). Puteți citi mai multe despre diferențele dintre IKEv1 și IKEv2 în bara laterală. După ce ne-am ocupat de IKE, revenim la fazele IPsec. În prima fază, participanții se autentifică reciproc și convin asupra parametrilor pentru stabilirea unei conexiuni speciale destinate doar schimbului de informații despre algoritmii de criptare doriti și alte detalii ale viitorului tunel IPsec. Parametrii acestui prim tunel (numit și tunel ISAKMP) sunt determinați de politica ISAKMP. Primul pas este să cădeți de acord asupra hashurilor și a algoritmilor de criptare, apoi există un schimb de chei Diffie-Hellman (DH) și abia apoi își dă seama cine este cine. Adică, ultimul pas este procesul de autentificare, fie folosind o cheie PSK, fie RSA. Iar dacă părțile ajung la o înțelegere, atunci se stabilește un tunel ISAKMP, prin care trece deja a doua fază a IKE.

În a doua fază, participanții care au deja încredere unii în alții convin asupra modului de construire a tunelului principal pentru transferul direct de date. Își oferă unul altuia opțiunile specificate în parametrul transform-set și, dacă sunt de acord, ridică tunelul principal. Este important de subliniat că, odată ce este stabilit, tunelul auxiliar ISAKMP nu merge nicăieri - este folosit pentru a actualiza periodic SA-ul tunelului principal. Ca rezultat, IPsec stabilește într-un fel nu unul, ci două tuneluri.

Cum se prelucrează datele

Acum câteva cuvinte despre transform-set. La urma urmei, trebuie să criptezi cumva datele care trec prin tunel. Prin urmare, într-o configurație tipică, transform-set este un set de parametri care indică în mod explicit cum ar trebui procesat pachetul. În consecință, există două opțiuni pentru o astfel de prelucrare a datelor - protocoalele ESP și AH. ESP (Encapsulating Security Payload) se ocupă direct de criptarea datelor și poate oferi, de asemenea, verificarea integrității datelor. AH (Authentication Header), la rândul său, este responsabil doar pentru autentificarea sursei și verificarea integrității datelor.

De exemplu, comanda `crypto ipsec transform-set SET10 esp-aes` va indica routerului că transformarea-setul cu numele `SET10` ar trebui să funcționeze numai folosind protocolul ESP și cu criptare AES. Privind în viitor, voi spune că în continuare vom folosi ca ținte routerele și firewall-urile Cisco. De fapt, cu ESP totul este mai mult sau mai puțin clar, sarcina lui este să cripteze și astfel să asigure confidențialitatea, dar de ce atunci este nevoie de AH? AH oferă autentificarea datelor, adică confirmă că aceste date provin exact de la cel cu care am stabilit legătura și nu au fost modificate pe parcurs. Oferă ceea ce se numește uneori protecție anti-reluare. În rețelele moderne, AH practic nu este utilizat doar ESP poate fi găsit peste tot.

Parametrii (aka SA) selectați pentru a cripta informațiile dintr-un tunel IPsec au o durată de viață, după care trebuie înlocuiți. Setarea implicită IPsec SA pentru durata de viață este de 86.400 de secunde sau 24 de ore.

Drept urmare, participanții au primit un tunel criptat cu parametri care li se potriveau tuturor și au trimis fluxuri de date pentru a fi criptate acolo. Periodic, în conformitate cu durata de viață, cheile de criptare pentru tunelul principal sunt actualizate: participanții comunică din nou prin tunelul ISAKMP, trec prin a doua fază și restabilesc SA.

moduri IKEv1

Am aruncat o privire rapidă asupra mecanismelor de bază ale modului în care funcționează IPsec, dar mai sunt câteva lucruri pe care trebuie să ne concentrăm. Prima fază, printre altele, poate funcționa în două moduri: modul principal sau modul agresiv. Am discutat deja despre prima variantă mai sus, dar ne interesează modul agresiv. Acest mod folosește trei mesaje (în loc de șase în modul principal). În acest caz, cel care inițiază conexiunea oferă toate datele sale deodată - ce vrea și ce poate face, precum și partea sa din schimbul DH. Răspunsul își finalizează imediat porțiunea din generația DH. Ca rezultat, există în esență doar două etape în acest mod. Adică, primele două etape din modul principal (acord hash și schimb DH) sunt, parcă, comprimate într-una singură. Ca urmare, acest mod este mult mai periculos datorită faptului că răspunsul vine cu o mulțime de informații tehnice în text clar. Și cel mai important, gateway-ul VPN poate trimite o parolă hash, care este folosită pentru autentificare în prima fază (această parolă este adesea numită cheie pre-partajată sau PSK).

Ei bine, toată criptarea ulterioară are loc fără modificări, ca de obicei. Atunci de ce se mai folosește acest mod? Cert este că este mult mai rapid, cam de două ori mai rapid. Un interes deosebit pentru pentester este faptul că modul agresiv este foarte des folosit în RA IPsec VPN. O altă mică caracteristică a VPN RA IPsec atunci când utilizați modul agresiv: atunci când clientul contactează serverul, acesta îi trimite un identificator (numele grupului). Numele grupului de tunel (vezi Figura 2) este numele unei intrări care conține un set de politici pentru o anumită conexiune IPsec. Aceasta este deja una dintre caracteristicile specifice echipamentelor Cisco.


Orez. 2. Numele grupului de tunel

Două faze nu au fost suficiente

S-ar părea că aceasta nu este o schemă de lucru foarte simplă, dar în realitate este încă puțin mai complicată. De-a lungul timpului, a devenit clar că PSK singur nu era suficient pentru a asigura securitatea. De exemplu, dacă stația de lucru a unui angajat a fost compromisă, atacatorul ar putea obține imediat acces la întreaga rețea internă a întreprinderii. Prin urmare, faza 1.5 a fost dezvoltată chiar între prima și a doua fază clasică. Apropo, această fază nu este de obicei utilizată într-o conexiune VPN standard de la site la site, ci este utilizată atunci când se organizează conexiuni VPN la distanță (cazul nostru). Această fază conține două noi extensii - Extended Authentication (XAUTH) și Mode-Configuration (MODECFG).

XAUTH este o autentificare suplimentară a utilizatorului în cadrul protocolului IKE. Această autentificare este uneori numită și al doilea factor IPsec. Ei bine, MODECFG servește la transmiterea informațiilor suplimentare către client, aceasta ar putea fi o adresă IP, mască, server DNS etc. Se poate observa că această fază pur și simplu le completează pe cele discutate anterior, dar utilitatea ei este neîndoielnică.

IKEv2 vs IKEv1

Ambele protocoale funcționează pe portul UDP numărul 500, dar sunt incompatibile între ele, situația în care există IKEv1 la un capăt al tunelului și IKEv2 la celălalt; Iată principalele diferențe dintre a doua versiune și prima:

În IKEv2 nu mai există concepte precum moduri agresive sau principale.
- În IKEv2, termenul de primă fază este înlocuit cu IKE_SA_INIT (un schimb de două mesaje care asigură negocierea protocoalelor de criptare/hashing și generarea de chei DH), iar a doua fază este înlocuită cu IKE_AUTH (tot două mesaje care implementează autentificarea). în sine).
- Mode Config (ceea ce a fost numit faza 1.5 în IKEv1) este acum descris direct în specificația protocolului și este o parte integrantă a acesteia.
- IKEv2 a adăugat un mecanism suplimentar de protecție împotriva atacurilor DoS. Esența sa este că înainte de a răspunde la fiecare solicitare în stabilirea unei conexiuni securizate (IKE_SA_INIT) IKEv2, gateway-ul VPN trimite un anumit cookie la sursa unei astfel de solicitări și așteaptă un răspuns. Dacă sursa a răspuns - totul este în ordine, puteți începe să generați DH cu el. Dacă sursa nu răspunde (așa se întâmplă în cazul unui atac DoS; această tehnică amintește de inundația TCP SYN), atunci gateway-ul VPN pur și simplu uită de asta. Fără acest mecanism, cu fiecare cerere din partea oricui, gateway-ul VPN ar încerca să genereze o cheie DH (care este un proces destul de intensiv în resurse) și în curând s-ar confrunta cu probleme. Drept urmare, din cauza faptului că toate operațiunile necesită acum confirmare din partea cealaltă a conexiunii, este imposibil să se creeze un număr mare de sesiuni pe jumătate deschise pe dispozitivul atacat.

Ajungem la linie

După ce ați înțeles în sfârșit caracteristicile de operare ale IPsec și componentele sale, puteți trece la principalul lucru - atacuri practice. Topologia va fi destul de simplă și în același timp apropiată de realitate (vezi Fig. 3).


Orez. 3. Diagrama generală a rețelei

Primul pas este să determinați prezența unui gateway VPN IPsec. Acest lucru se poate face efectuând o scanare a portului, dar există o mică caracteristică aici. ISAKMP folosește protocolul UDP, portul 500, în timp ce scanarea implicită cu Nmap afectează numai porturile TCP. Și ca rezultat va apărea un mesaj: `Toate cele 1000 de porturi scanate de pe 37.59.0.253 sunt filtrate`.

Se pare că toate porturile sunt filtrate și nu există porturi deschise. Dar după executarea comenzii

Nmap -sU --top-ports=20 37.59.0.253 Pornind Nmap 6.47 (http://nmap.org) la 2015-03-21 12:29 GMT Raport de scanare Nmap pentru 37.59.0.253 Gazda este activată (latență de 0,066 s) . SERVICIUL STATUL PORTULUI 500/udp deschis isakmp
Ne asigurăm că acesta nu este cazul și că acesta este într-adevăr un dispozitiv VPN.

Să atacăm prima fază

Acum ne va interesa prima fază, modul agresiv și autentificarea folosind cheia pre-partajată (PSK). În acest scenariu, așa cum ne amintim, dispozitivul VPN sau răspunsul trimite un PSK hash către inițiator. Una dintre cele mai cunoscute utilitare pentru testarea protocolului IKE este ike-scan, este inclusă în distribuția Kali Linux. Ike-scan vă permite să trimiteți mesaje IKE cu diverși parametri și, în consecință, să decodați și să analizați pachetele de răspuns. Să încercăm să verificăm dispozitivul țintă:

Root@kali:~# ike-scan -M -A 37.59.0.253 0 strângere de mână returnată; 0 notificare returnată

Orez. 4. Ike-scan modul agresiv

Comutatorul `-A` indică faptul că trebuie utilizat modul agresiv, iar `-M` indică faptul că rezultatele trebuie afișate linie cu linie (multilinie), pentru o citire mai ușoară. Este clar că nu s-a obținut niciun rezultat. Motivul este că trebuie să specificați același identificator, numele grupului VPN. Desigur, utilitarul ike-scan vă permite să setați acest identificator ca unul dintre parametrii săi. Dar, din moment ce ne este încă necunoscut, să luăm o valoare arbitrară, de exemplu 0000.

Root@kali:~# ike-scan -M -A --id=0000 37.59.0.253 37.59.0.253 Strângere de mână în mod agresiv a fost returnată


Orez. 5. ID-ul Ike-scan

De data aceasta vedem că răspunsul a fost primit (vezi Fig. 5) și ni s-au oferit destul de multe informații utile. O parte destul de importantă a informațiilor primite este setul de transformare. În cazul nostru, se afirmă că „Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK”.

Toți acești parametri pot fi specificați pentru utilitarul ike-scan folosind comutatorul `--trans`. De exemplu, `--trans=5,2,1,2` va indica faptul că algoritmul de criptare este 3DES, hashing HMAC-SHA, metoda de autentificare PSK și al doilea tip de grup DH (1024-bit MODP). Puteți vizualiza tabelele de corespondență valoric la această adresă. Să adăugăm o altă cheie (`-P`) pentru a afișa direct sarcina utilă a pachetului, sau mai degrabă hash-ul PSK.

Root@kali:~# ike-scan -M -A --id=0000 37.59.0.253 -P


Orez. 6. Sarcina utilă Ike-scan

Depășirea primelor dificultăți

S-ar părea că hașul a fost obținut și poți încerca să-l brutezi, dar totul nu este atât de simplu. Pe vremuri, în 2005, unele hardware Cisco aveau o vulnerabilitate: aceste dispozitive dădeau un hash doar dacă atacatorul trecea valoarea corectă a ID-ului. Acum, desigur, este aproape imposibil să găsești un astfel de echipament și întotdeauna se trimite o valoare hashed, indiferent dacă atacatorul a trimis sau nu valoarea corectă a ID-ului. Evident, hashingul cu forță brută este inutil. Prin urmare, prima sarcină este de a determina valoarea corectă a ID-ului pentru a obține hash-ul corect. Și o vulnerabilitate recent descoperită ne va ajuta în acest sens.

Ideea este că există o mică diferență între răspunsuri în timpul schimbului inițial de mesaje. Pe scurt, dacă se folosește numele corect al grupului, există patru încercări de a continua stabilirea conexiunii VPN plus două pachete criptate faza a doua. În timp ce în cazul unui ID incorect, doar două pachete ajung ca răspuns. După cum puteți vedea, diferența este destul de semnificativă, așa că SpiderLabs (autorul instrumentului Responder la fel de interesant) a dezvoltat mai întâi un PoC și apoi utilitarul IKEForce pentru a exploata această vulnerabilitate.

Care este puterea IKE

Puteți instala IKEForce într-un director arbitrar rulând comanda

Clona Git https://github.com/SpiderLabs/ikeforce
Funcționează în două moduri principale - modul de calcul `-e` (enumerare) și modul forță brută `-b` (forță brută). Vom ajunge la al doilea când ne uităm la atacurile asupra celui de-al doilea factor, dar ne vom ocupa de primul acum. Înainte de a începe procesul real de determinare a ID-ului, trebuie să setați valoarea exactă a setului de transformare. Am definit-o deja mai devreme, așa că o vom specifica cu opțiunea `-t 5 2 1 2`. Ca rezultat, procesul de găsire a ID-ului va arăta astfel:

Python ikeforce.py 37.59.0.253 -e -w liste de cuvinte/group.txt -t 5 2 1 2


Orez. 7. Enumerarea IKEForce

Ca rezultat, a fost posibil să se obțină destul de rapid valoarea ID corectă (Fig. 7). Primul pas a fost finalizat, puteți merge mai departe.

Primim PSK

Acum trebuie să salvați hash-ul PSK într-un fișier folosind numele de grup corect, acest lucru se poate face folosind ike-scan:

Ike-scan -M -A --id=vpn 37.59.0.253 -Pkey.psk
Și acum că a fost găsită valoarea corectă a ID-ului și a fost obținut hash-ul PSK corect, putem începe în sfârșit forța brută offline. Există destul de multe opțiuni pentru o astfel de forță brută - acesta este utilitarul clasic psk-crack și John the Ripper (cu un patch jumbo) și chiar oclHashcat, care, după cum se știe, vă permite să utilizați puterea GPU. Pentru simplitate, vom folosi psk-crack, care acceptă atât forța brută directă, cât și atacul de dicționar:

Psk-crack -d /usr/share/ike-scan/psk-crack-dictionary key.psk

Orez. 8. Psk-crack

Dar chiar și restabilirea cu succes a PSK (vezi Fig. 8) este doar jumătate din luptă. În această etapă, trebuie să ne amintim că ceea ce ne așteaptă în continuare este XAUTH și al doilea factor al VPN IPsec.

Se confruntă cu al doilea factor IPsec

Deci, permiteți-mi să vă reamintesc că XAUTH este o securitate suplimentară, un al doilea factor de autentificare și este în faza 1.5. Pot exista mai multe opțiuni pentru XAUTH - aceasta include verificarea utilizând protocolul RADIUS, parole unice (OTP) și o bază de utilizatori locale obișnuită. Ne vom concentra asupra situației standard când o bază de utilizatori locale este folosită pentru a verifica al doilea factor. Până de curând, nu a existat un instrument disponibil public pentru forța brută XAUTH. Dar odată cu apariția IKEForce, această problemă a primit o soluție demnă. Lansarea forței brute XAUTH este destul de simplă:

Python ikeforce.py 37.59.0.253 -b -i vpn -k cisco123 -u admin -w wordlists/passwd.txt -t 5 2 1 2 [+]Programul a început în XAUTH Brute Force Mode [+]Furnizat un singur utilizator - forțare brută parole pentru utilizator: admin [*]Autentificare XAUTH reușită! Nume utilizator: admin Parola: cisco


Orez. 9. IKEForce XAUTH

În acest caz, sunt indicate toate valorile găsite anterior: ID (cheia `-i`), PSK restaurat (cheia `-k`) și autentificarea dorită (cheia `-u`). IKEForce acceptă atât căutarea în forță brută a unei autentificări, cât și căutarea printr-o listă de autentificări, care poate fi specificată cu parametrul `-U`. În cazul unei posibile blocări a selecției, există opțiunea `-s`, care vă permite să reduceți viteza forței brute. Apropo, utilitarul vine cu mai multe dicționare bune, utile în special pentru setarea valorii parametrului ID.

Conectați-vă la rețeaua internă

Acum că avem toate datele, rămâne ultimul pas - pătrunderea efectivă în rețeaua locală. Pentru a face acest lucru, vom avea nevoie de un fel de client VPN, dintre care există foarte multe. Dar în cazul lui Kali, puteți utiliza cu ușurință VPNC-ul deja preinstalat. Pentru ca acesta să funcționeze, trebuie să ajustați un fișier de configurare - `/etc/vpnc/vpn.conf`. Dacă nu există, atunci trebuie să creați și să completați o serie de parametri evidenti:

Gateway IPSec 37.59.0.253
ID IPSec vpn
IPSec secret cisco123
IKE Authmode psk
Xauth Nume de utilizator admin
Parola Xauth cisco

Aici vedem că au fost folosite absolut toate datele găsite în pașii anteriori - valoarea ID, PSK, login și parola celui de-al doilea factor. După care conexiunea în sine are loc cu o singură comandă:

Root@kali:~# vpnc vpn
Dezactivarea este, de asemenea, destul de simplă:

Root@kali:~# vpnc-disconnect
Puteți verifica funcționalitatea conexiunii folosind comanda `ifconfig tun0`.


Orez. 10. VPNC

Cum să construiți o protecție fiabilă

Protecția împotriva atacurilor discutate astăzi trebuie să fie cuprinzătoare: trebuie să instalați patch-uri la timp, să folosiți chei puternice pre-partajate, care, dacă este posibil, ar trebui înlocuite cu certificate digitale. Politica de parole și alte elemente evidente ale securității informațiilor joacă, de asemenea, un rol important în asigurarea securității. De asemenea, trebuie menționat că situația se schimbă treptat, iar în timp va rămâne doar IKEv2.

Care este rezultatul?

Am acoperit în detaliu procesul de audit RA IPsec VPN. Da, desigur, această sarcină este departe de a fi banală. Trebuie să faci mulți pași, iar dificultățile te pot aștepta la fiecare dintre ei, dar dacă reușești, rezultatul este mai mult decât impresionant. Obținerea accesului la resursele rețelei interne deschide cea mai largă posibilitate pentru acțiuni ulterioare. Prin urmare, cei care sunt responsabili pentru protejarea perimetrului rețelei nu ar trebui să se bazeze pe șabloane implicite gata făcute, ci să se gândească cu atenție la fiecare nivel de securitate. Ei bine, pentru cei care efectuează pentesturi, portul UDP detectat cinci sute este un motiv pentru a efectua o analiză profundă a securității VPN IPsec și, eventual, pentru a obține rezultate bune.

Abonați-vă la „Hacker”

VPN-urile cu IPsec oferă conectivitate flexibilă și scalabilă. Conexiunile interprofesionale pot oferi comunicații la distanță sigure, de mare viteză și fiabile. La Ajutor VPN Cu IPsec, informațiile dintr-o rețea privată sunt transmise în siguranță retea publica. Datorită acestui lucru, puteți crea rețea virtualăîn loc să utilizați o conexiune dedicată Layer 2, așa cum se arată în figură. Pentru a asigura confidențialitatea datelor, traficul este criptat.

IPsec este un standard IETF care definește modul în care o rețea VPN poate fi configurată în siguranță folosind protocolul IP.

IPsec este o structură standarde deschise, care definește regulile de organizare a comunicațiilor securizate. IPsec nu este asociat cu anumite metode de criptare sau autentificare, algoritmi de securitate sau tehnologie de schimb de chei. Pentru a asigura o comunicație sigură, se utilizează protocolul IPsec algoritmii existenti. IPsec vă permite să creați algoritmi noi, mai buni, a căror dezvoltare nu necesită ajustări la standardele IPsec existente.

IPsec operează la nivelul rețelei pentru a asigura securitatea și autentificarea pachetelor IP între dispozitivele IPsec comunicante, numite și peer-uri. IPsec vă permite să securizați calea dintre o pereche de gateway-uri, o pereche de computere sau între un gateway și un computer. Ca rezultat, IPsec poate proteja aproape orice trafic de aplicații, deoarece poate implementa protecție la straturile 4 până la 7.

Toate soluțiile IPsec implementate folosesc un antet Layer 3 necriptat, deci nu există probleme de rutare. IPsec funcționează pe deasupra oricăror protocoale de nivel 2, cum ar fi Ethernet, ATM și Frame Relay.

Următoarele sunt principalele caracteristici ale protocolului IPsec:

  • IPsec este un cadru standard deschis care este independent de algoritmi.
  • IPsec asigură confidențialitatea și integritatea datelor, precum și autentificarea sursei.
  • IPsec acționează ca un protocol stratul de rețea, protejând pachetele IP și verificându-le autenticitatea.
  • Protecție IP

  • Figura arată că serviciile de securitate IPsec îndeplinesc următoarele funcții importante:


    • Confidențialitate (criptare)- Într-o rețea VPN, datele private sunt transmise printr-o rețea publică. Prin urmare, asigurarea confidențialității datelor este esențială. Pentru a realiza acest lucru, datele sunt criptate înainte de transmiterea prin rețea. Criptarea este procesul de codificare a tuturor datelor trimise de la un computer la altul într-o formă pe care numai computerul care îl primește o poate decoda. Dacă un mesaj este interceptat, un atacator (hacker) nu îl va putea citi. IPsec oferă caracteristici avansate de securitate (cum ar fi algoritmi puternici de criptare).
    • Integritatea datelor- Destinatarul poate verifica dacă datele au fost transmise în mod normal prin Internet și nu au fost modificate în niciun fel. Este important nu numai să ne asigurăm că datele sunt criptate în rețeaua publică, ci și să ne asigurăm că nu au fost modificate în tranzit. IPsec oferă un mecanism pentru a verifica dacă nu au existat modificări la porțiunea criptată a pachetului, întregul antet sau corpul de date al pachetului. IPsec garantează integritatea datelor folosind sume de control (aplicat simpla verificare folosind redundanța). Dacă este detectată o corupție, pachetul este aruncat.
    • Autentificare- vă permite să verificați cine a fost sursa datelor trimise. Acest lucru este necesar pentru a proteja împotriva atacurilor care folosesc falsificarea (sender spoofing). Autentificarea vă ajută să vă asigurați că este stabilită o conexiune cu partenerul de comunicare corect. Destinatarul poate verifica identitatea sursei pachetului prin certificarea sursei informațiilor. IPsec folosește tehnologia Internet Key Exchange (IKE) pentru a autentifica utilizatorii și dispozitivele care pot comunica independent unul de celălalt. IKE folosește autentificare tipuri variate(în special, sunt utilizate numele de utilizator și parola, parolă de unică folosință, biometrie, cheie pre-partajată (PSK) și certificate digitale).
    • Protecție la reluare- vă permite să detectați și să respingeți pachetele duplicate, precum și să preveniți falsificarea. Cu protecția la reluare, vă puteți asigura că un pachet este unic și nu este duplicat. Pachetele IPsec sunt securizate prin compararea numărului de secvență al pachetelor primite cu o fereastră glisantă la gazda de destinație sau gateway-ul de securitate. Pachet cu număr de serie, care vine înainte ca fereastra glisantă să fie considerată întârziată sau duplicată. Pachetele întârziate și duplicate sunt aruncate.

    Abrevierea CIA aduce în minte în multe cazuri aceste trei funcții: confidențialitate, integritate și autentificare.

  • Structura protocolului IPsec

  • Confidențialitate

    Confidențialitatea traficului VPN este menținută prin criptare. Datele clare (necriptate) transmise prin Internet pot fi interceptate și citite. Criptarea este utilizată pentru a menține confidențialitatea datelor. Criptarea digitală a datelor rămâne ilizibilă până când este decriptată de către un destinatar autorizat.

    Pentru a asigura o comunicare criptată, atât expeditorul, cât și destinatarul trebuie să cunoască regulile folosite pentru a converti mesajul original într-o formă criptată. Regulile se bazează pe algoritmi și chei corespunzătoare. În contextul criptării, un algoritm este o secvență matematică de acțiuni care combină un mesaj, text, numere sau toate cu un șir de numere numit cheie. Ieșirea apare ca un șir criptat care nu poate fi citit. Algoritmul de criptare determină, de asemenea, modul în care mesajul criptat este decriptat. Fără cheia corectă, este aproape imposibil să decriptezi datele.


  • Imaginea arată că Gail vrea să facă un transfer electronic de fonduri prin internet către Jeremy. Pe partea locală, documentul este combinat cu o cheie și supus unei proceduri de criptare. Rezultatul este un text cifrat. Acest text cifrat este apoi trimis prin Internet. Pe partea de la distanță, mesajul este din nou combinat cu cheia și trecut prin algoritmul de criptare în direcția opusă. Ieșirea reprezintă documentul financiar original.

    Confidențialitatea este obținută prin criptarea traficului atunci când este transmis prin VPN. Gradul de securitate depinde de lungimea cheii din algoritmul de criptare și de complexitatea algoritmului în sine. Dacă un hacker încearcă să spargă o cheie folosind un atac de forță brută, numărul de opțiuni de forță brută va depinde de lungimea cheii. Timp de procesare pentru toți opțiuni posibile depinde de puterea de calcul a computerului atacatorului. Prin urmare, cu cât cheia este mai scurtă, cu atât este mai ușor de spart. De exemplu, dacă pentru a sparge o cheie de 64 de biți relativ computer puternic Deși va dura aproximativ un an, același computer poate dura între 10 și 19 ani pentru a sparge o cheie pe 128 de biți.

Algoritmi de criptare IPsec

Gradul de securitate depinde de lungimea cheii din algoritmul de criptare. Pe măsură ce lungimea cheii crește, probabilitatea de rupere a cifrului scade. Cu toate acestea, cu cât cheia este mai lungă, cu atât vor fi necesare mai multe resurse CPU pentru a cripta și decripta datele.

DES și 3DES nu mai sunt considerate sigure, așa că AES este recomandat pentru criptarea IPsec. Cel mai înalt nivel de securitate pentru criptarea VPN între dispozitivele Cisco care utilizează IPsec este oferit de opțiunea AES pe 256 de biți. În plus, deoarece cheile Rivest-Shamir-Edleman (RSA) de 512 și 768 de biți pot fi compromise, Cisco recomandă utilizarea cheilor de 2048 de biți în varianta RSA (dacă sunt utilizate în timpul fazei de autentificare IKE).

Criptare simetrică

Algoritmii de criptare precum AES necesită o cheie secretă partajată pentru a realiza atât criptarea, cât și decriptarea. Pentru a decoda informațiile, ambele dispozitive din rețea trebuie să cunoască cheia. Cu criptarea cu cheie simetrică (numită și criptare cu cheie privată), fiecare dispozitiv criptează datele înainte de a fi trimise prin rețea către alt dispozitiv. Cu criptarea cu cheie simetrică, trebuie să știți ce dispozitive vorbesc între ele, astfel încât fiecare dispozitiv să poată fi configurat cu aceeași cheie (vezi Figura 1).

De exemplu, expeditorul creează un mesaj codificat în care fiecare literă se schimbă în litera următoare două litere în jos în alfabet (adică A devine C, B devine D etc.). În acest caz, cuvântul SECRET devine UGETGV. Expeditorul a spus deja destinatarului că cheia secretă este un offset de 2. Când destinatarul primește un mesaj UGETGV, computerul său decodifică mesajul prin schimbarea înapoi cu două litere și primește cuvântul SECRET. Orice alt utilizator care se uită la acest mesaj îl vede în formă criptată. Pentru a preveni ca un astfel de mesaj să arate ca gobbledygook, trebuie să cunoașteți cheia secretă.

Următoarele sunt caracteristicile algoritmilor simetrici:

  • se utilizează criptografia bazată pe chei simetrice;
  • aceeași cheie este folosită pentru criptare și decriptare;
  • folosit de obicei pentru a cripta conținutul mesajului.
  • Exemple: DES, 3DES și AES

Cum pot dispozitivele de criptare și decriptare să obțină informații despre cheia secretă partajată? Cheile secrete partajate ar putea fi, desigur, trimise administratorilor de dispozitive prin e-mail, prin poștă obișnuită sau curier. Dar o altă metodă, mai fiabilă, este criptarea asimetrică.

Criptare asimetrică

În criptarea asimetrică, criptarea și decriptarea se fac folosind chei diferite. Cunoașterea uneia dintre chei împiedică un hacker să descopere a doua cheie și să decodeze informațiile. O cheie este folosită pentru a cripta mesajul, a doua este folosită pentru a-l decripta (vezi Figura 2). Nu puteți efectua criptarea și decriptarea utilizând aceeași cheie.

Una dintre variante criptare asimetrică este criptarea cu chei publice, în care se utilizează o combinație de chei secrete și deschise (publice). Destinatarul furnizează cheia publică oricărui expeditor cu care destinatarul trebuie să comunice. Pentru a cripta un mesaj, expeditorul folosește o cheie secretă, care este combinată cu cheia publică a destinatarului. În plus, expeditorul trebuie să partajeze cheia publică cu destinatarul. Pentru a decripta mesajul, destinatarul va folosi cheia publică a expeditorului împreună cu propria sa cheie privată.

Următoarele sunt caracteristicile algoritmilor asimetrici:

  • se utilizează criptografia cu cheie publică;
  • diferite chei sunt folosite pentru criptare și decriptare;
  • Utilizat de obicei în gestionarea certificatelor digitale și a cheilor.

Integritate și algoritmi de hashing

Algoritmii hash sunt utilizați pentru a asigura integritatea și autentificarea traficului VPN. Integritatea și autentificarea datelor sunt asigurate de coduri hash, care asigură că mesajele transmise nu sunt manipulate de persoane neautorizate. Un cod hash, numit și rezumat de mesaj, este un număr care este creat dintr-un șir de text. Codul hash este mai mic decât textul în sine. Este creat folosind o formulă în așa fel încât obținerea aceleiași valori de cod hash dintr-un alt text este extrem de puțin probabilă.

Expeditorul original creează un hash al mesajului și îl trimite împreună cu mesajul în sine. Destinatarul analizează mesajul și codul hash, creează un alt cod hash pe baza mesajelor primite și compară ambele hash-uri. Dacă se potrivesc, atunci destinatarul poate avea încredere rezonabilă în integritatea mesajului original.

Imaginea arată că Gale i-a trimis lui Alex un e-mail remitereîn valoare de 100 de dolari SUA. Jeremy a interceptat și a modificat transferul pentru a arăta că el a fost destinatarul și suma transferului a fost de 1.000 USD. În acest caz, dacă a fost folosit un algoritm de integritate a datelor, hashurile nu se vor potrivi și tranzacția va fi invalidă.

Datele VPN sunt transmise prin Internet acces public. După cum se arată în figură, există posibilitatea de interceptare și modificare a acestor date. Pentru a se proteja împotriva acestei amenințări, computerele pot avea coduri hash adăugate la mesaj. Dacă codul hash transmis se potrivește cu codul hash primit, integritatea mesajului este asigurată. Cu toate acestea, dacă hashurile nu se potrivesc, atunci mesajul a fost modificat.

Pentru a verifica integritatea și autenticitatea unui mesaj, VPN-urile folosesc un cod de autentificare fără a utiliza mecanisme suplimentare.

Codul de autentificare a mesajelor bazat pe hash (HMAC) este un mecanism de autentificare a mesajelor folosind funcții de hashing. HMAC cu schimb de chei este un algoritm de integritate a datelor care garantează integritatea mesajului. HMAC are doi parametri: mesajul de intrare și o cheie secretă cunoscută doar de autorul și destinatarii mesajului. Expeditorul mesajului folosește funcția HMAC pentru a crea o valoare (codul de autentificare a mesajului) generată prin procesarea cheii secrete și a mesajului de intrare. Codul de autentificare a mesajului este trimis împreună cu mesajul. Destinatarul calculează codul de autentificare a mesajului din mesajul primit folosind aceeași cheie și funcție HMAC pe care le-a folosit expeditorul. Destinatarul compară apoi rezultatul calculat cu codul de autentificare a mesajului primit. Dacă ambele valori se potrivesc, mesajul corect a fost primit, iar destinatarul poate fi sigur că expeditorul este membru al comunității de utilizatori care utilizează cheia partajată. Puterea criptografică a algoritmului HMAC depinde de puterea criptografică a funcției hash subiacente, dimensiunea și calitatea cheii și lungimea rezultatului funcției hash (în biți).

Există doi algoritmi HMAC cei mai comuni:

  • MD5- se folosește o cheie secretă partajată de 128 de biți. Mesajul de lungime aleatorie și cheia secretă partajată de 128 de biți sunt combinate între ele și procesate de algoritmul de hashing HMAC-MD5. Rezultatul este un cod hash de 128 de biți. Codul hash este adăugat la mesajul original și redirecționat către partea de la distanță.
  • SHA- SHA-1 folosește o cheie secretă partajată de 160 de biți. Mesajul cu lungime variabilă și cheia secretă partajată pe 160 de biți sunt combinate între ele și procesate de algoritmul de hashing HMAC-SHA1. Rezultatul este un cod hash de 160 de biți. Codul hash este adăugat la mesajul original și redirecționat către partea de la distanță.

Notă. Cisco IOS acceptă, de asemenea, opțiuni SHA pe 256, 384 și 512 biți.

Autentificare IPsec

VPN-urile IPsec acceptă autentificare. Dacă partenerii tăi de afaceri sunt la mare distanță de tine, atunci este important să știi cu cine vorbești la telefon, cine te trimite mesaj electronic sau fax. Același lucru este valabil și pentru rețelele VPN. După cum este indicat în figură, identitatea dispozitivului de la celălalt capăt al tunelului VPN trebuie verificată înainte ca canalul de comunicație să poată fi considerat securizat. Există două metode de autentificare a interlocutorului:

  • PSK- o cheie secretă cunoscută în prealabil de doi utilizatori care comunică printr-un canal securizat. Metoda cheii pre-partajate (PSK) folosește algoritmi criptografici cu cheie simetrică. Cheia PSK este introdusă manual pe fiecare dintre nodurile de comunicare (peer) și este folosită pentru a se autentifica reciproc. Pe fiecare parte, PSK este combinat cu alte informații pentru a forma o cheie de autentificare.

Algoritmul IPsec folosește algoritmul RSA (public key cryptographic system) pentru autentificare în contextul IKE. RSA utilizează o schemă de semnătură digitală prin care fiecare dispozitiv atașează o semnătură digitală unui set de date și o transmite unui alt utilizator. Algoritmul de semnare RSA utilizează o autoritate de certificare (CA) pentru a crea un certificat digital cu un identificator unic care este atribuit fiecărui peer pentru autentificare. Certificatul de identitate digitală în sine este similar cu o cheie PSK, dar oferă un nivel mult mai ridicat de securitate. Fiecare inițiator și răspuns dintr-o sesiune IKE care utilizează semnături RSA trimite propria sa valoare de identitate, certificatul său digital de identitate și o valoare de semnătură RSA constând din mai multe valori IKE. O metodă de criptare negociată de IKE (cum ar fi AES) este utilizată pentru a cripta toate aceste date.

O altă metodă de autentificare este algoritmul de semnătură digitală (DSA).

Structura protocolului IPsec

După cum sa menționat mai sus, suita de protocoale IPsec descrie o modalitate de a schimba mesaje către sesiuni de comunicații securizate, dar se bazează pe aplicarea algoritmilor existenți.

Figura 1 prezintă cele două protocoale IPsec principale:

  • Antet de autentificare (AH)- AH este un protocol special folosit în cazurile în care confidențialitatea nu este cerută sau interzisă. Oferă autentificare și integritate a datelor pentru pachetele IP trimise între două sisteme. Cu toate acestea, AH nu asigură confidențialitatea (criptarea) datelor din pachete. Tot textul este transmis în text clar (fără criptare). Dacă este utilizat doar protocolul AH (și nu sunt utilizate alte mecanisme), atunci acesta oferă o protecție slabă.
  • Încapsularea sarcinii utile de securitate (ESP) este un protocol de securitate care oferă confidențialitate și autentificare prin criptarea pachetului IP. Procesul de criptare a unui pachet IP ascunde datele și identificatorii sursă și destinație. ESP verifică autenticitatea pachetului IP intern și a antetului ESP. Autentificarea asigură autenticitatea sursei de date și integritatea datelor. Deși procedurile de criptare și autentificare nu sunt necesare în ESP, trebuie să selectați cel puțin una dintre ele.

În fig. Figura 2 prezintă componentele unei configurații IPsec. Există patru blocuri de bază ale designului IPsec care trebuie selectate.


  • Confidențialitate (dacă este selectată opțiunea folosind IPsec cu protocol ESP)- algoritmul de criptare selectat trebuie cel mai bun mod asigura nivelul necesar de securitate: DES, 3DES sau AES. AES este foarte recomandat (AES-GCM oferă cel mai înalt nivel de securitate).
  • Integritate- se asigură că conținutul nu a fost modificat în timpul transmiterii. Pentru a îndeplini această funcție, se folosesc algoritmi de hashing. Puteți alege MD5 și SHA.
  • Autentificare- Definește modul în care dispozitivele de la ambele capete ale tunelului VPN sunt autentificate. Opțiuni disponibile: PSK sau RSA.
  • Grup de algoritmi DH- definește metoda de generare a unei chei secrete partajate între noduri. Există mai multe opțiuni, dar DH24 oferă cel mai înalt nivel de securitate.

Combinația acestor blocuri oferă confidențialitate, integritate și autentificare pentru VPN-urile IPsec.

Notă. Această secțiune oferă o descriere generală a protocolului IPsec pentru a vă ajuta să înțelegeți cum protejează IPsec tuneluri VPN. Procesul de configurare a rețelelor VPN IPsec nu este acoperit în acest curs.

Figura 1 - Exemplu de operare IPsec

Scurt istoric al apariției protocolului

Internetul a fost creat inițial ca un mediu sigur pentru transferul de date între personalul militar. Deoarece doar un anumit cerc de oameni au lucrat cu el, oameni care au fost educați și au înțeles politica de securitate, nu a fost evidentă necesitatea de a construi protocoale sigure. Securitatea a fost organizată la nivelul izolării fizice a obiectelor de străini, iar acest lucru a fost justificat atunci când un număr limitat de mașini aveau acces la rețea. Cu toate acestea, când internetul a devenit public și a început să se dezvolte și să crească în mod activ, a apărut o astfel de nevoie.

În 1994, Internet Architecture Board (IAB) a lansat raportul „Security of the Internet Architecture”. Acest document a descris principalele aplicații fonduri suplimentare securitate pe Internet, și anume protecție împotriva monitorizării neautorizate, falsificarea pachetelor și controlul fluxului de date. Printre primele și cele mai importante măsuri de protecție a fost necesitatea dezvoltării unui concept și a unor mecanisme de bază care să asigure integritatea și confidențialitatea fluxurilor de date. Deoarece schimbarea protocoalelor de bază ale familiei TCP/IP ar determina o restructurare completă a Internetului, sarcina a fost stabilită pentru a asigura securitatea schimbului de informații în rețelele de telecomunicații deschise pe baza protocoalelor existente. Astfel, a început să fie creată specificația Secure IP, complementară protocoalelor IPv4 și IPv6. În 1995, grupul de lucru a publicat RFC-1825 prin RFC-1827, prima implementare de lucru a protocolului.

Particularități

Specificul IPsec este că este implementat la nivelul rețelei, completându-l în așa fel încât totul să se întâmple neobservat pentru straturile ulterioare. Principala dificultate este că, în procesul de stabilire a conexiunii, doi participanți la un canal securizat trebuie să cadă de acord asupra unui număr destul de mare de parametri diferiți. Și anume, trebuie să se autentifice reciproc, să genereze și să facă schimb de chei (și printr-un mediu neîncrezător) și, de asemenea, să convină asupra protocoalelor pentru a cripta datele.

Din acest motiv, IPsec constă dintr-un teanc de protocoale a căror responsabilitate este să asigure stabilirea, funcționarea și gestionarea unei conexiuni securizate. Întregul proces de stabilire a conexiunii constă din două faze: prima fază este utilizată pentru a asigura schimbul securizat de mesaje ISAKMP în a doua fază. ISAKMP (Internet Security Association and Key Management Protocol) este un protocol care servește la negocierea și actualizarea politicilor de securitate (SA) între participanții la o conexiune VPN. Aceste politici indică în mod specific ce protocol să utilizați pentru a cripta (AES sau 3DES) și cu ce să vă autentificați (SHA sau MD5).

Noțiuni de bază

AES ( Criptare avansată Standard), cunoscut și sub numele de Rijndael - algoritm simetric criptare bloc (dimensiunea blocului 128 biți, cheie 128/192/256 biți), adoptată ca standard de criptare de către guvernul SUA pe baza rezultatelor competiției AES. Din 2009, AES este unul dintre cei mai folosiți algoritmi de criptare simetrică.

DES (Standard de criptare a datelor)- un algoritm de criptare simetrică dezvoltat de IBM și aprobat de guvernul SUA în 1977 ca standard oficial (FIPS 46-3). DES are blocuri de 64 de biți și o structură de rețea Feistel cu 16 cicluri, utilizează o cheie de 56 de biți pentru criptare. Algoritmul folosește o combinație de transformări neliniare (S-box) și liniare (permutări E, IP, IP-1).

3DES (Standard triplu de criptare a datelor)- un cifru bloc simetric creat de Whitfield Diffie, Martin Hellman și Walt Tuchmann în 1978 pe baza algoritmului DES, pentru a elimina principalul dezavantaj al acestuia din urmă - lungimea mică a cheii (56 de biți), care poate fi spartă prin forța brută . Viteza 3DES este de 3 ori mai mică decât cea a DES, dar puterea criptografică este mult mai mare - timpul necesar pentru a criptoanaliza 3DES poate fi de un miliard de ori mai mare decât timpul necesar pentru a sparge DES. 3DES este folosit mai des decât DES, care este ușor de rupt cu tehnologia actuală (în 1998, Electronic Frontier Foundation, folosind calculator special DES Cracker, deschis DES în 3 zile). 3DES este într-un mod simplu abordarea deficiențelor DES. Algoritmul 3DES se bazează pe DES, deci este posibil să folosiți programe create pentru DES pentru a-l implementa.

RSA (algoritmul Ron Rivest, Adi Shamir și Leonard Adleman)- algoritm criptografic cu cheie publică. RSA a fost primul algoritm de acest tip, potrivit atât pentru criptare, cât și pentru semnătură digitală. Algoritmul este utilizat într-un număr mare de aplicații criptografice.

Certificat- un document digital sau pe hârtie care confirmă corespondența dintre o cheie publică și informații de identificare a proprietarului cheii. Conține informații despre proprietarul cheii, informații despre cheia publică, scopul și domeniul de aplicare al acesteia, numele autorității de certificare etc.

PKI (Infrastructură cu cheie publică)- tehnologie de autentificare folosind chei publice. Acest sistem complex, care conectează cheile publice cu identitatea utilizatorului printr-o autoritate de certificare (CA).

CRL (listă de revocare a certificatelor)- lista certificatelor revocate.

Standarde

Arhitectura IPSec

Construirea unui canal de comunicare securizat poate fi implementată folosind diferite niveluri Modele OSI. De exemplu, popularul protocol SSL operează la nivel de prezentare, în timp ce PPTP operează la nivel de sesiune. IP Security este un set de protocoale care se ocupă de problemele de criptare, autentificare și securitate în timpul transportului pachetelor IP; acum include aproape 20 de propuneri de standarde și 18 RFC-uri.

Specificația IP Security (cunoscută astăzi ca IPsec) este dezvoltată de IETF IP Security Protocol Working Group. IPsec a inclus inițial 3 specificații de bază independente de algoritm, publicate ca RFC: IP Security Architecture, Authentication Header (AH), Encapsulation of Encrypted Data (ESP) (RFC1825, 1826 și 1827). De menționat că în noiembrie 1998, IP Security Protocol Working Group a propus noi versiuni ale acestor specificații, care în prezent au statut de standarde preliminare, acestea fiind RFC2401 - RFC2412. Rețineți că RFC1825-27 a fost considerat învechit de câțiva ani și nu este cu adevărat folosit. În plus, există mai multe specificații dependente de algoritm care utilizează protocoalele MD5, SHA, DES. Grupul de lucru pentru protocolul de securitate IP dezvoltă, de asemenea, protocoale cheie de gestionare a informațiilor. Misiunea acestui grup este de a dezvolta Internet Key Management Protocol (IKMP), un protocol de gestionare a cheilor la nivel de aplicație care este independent de protocoalele de securitate utilizate. Conceptele de management al cheilor sunt în prezent explorate utilizând specificația Internet Security Association și protocolul de management al cheilor (ISAKMP) și protocolul Oakley Key Determination Protocol. Specificația ISAKMP descrie mecanisme de negociere a atributelor protocoalelor utilizate, în timp ce protocolul Oakley vă permite să instalați chei de sesiune pe computerele de pe Internet. Anterior, au fost luate în considerare și posibilitățile de utilizare a mecanismelor de management cheie ale protocolului SKIP, dar acum astfel de posibilități practic nu sunt folosite nicăieri. Standardele emergente de gestionare a informațiilor cheie pot suporta Centre de distribuție a cheilor similare cu cele utilizate în Kerberos. Protocoalele de gestionare a cheilor bazate pe Kerberos pentru IPSec sunt abordate în prezent de grupul de lucru KINK (Kerberized Internet Negotiation of Keys), relativ nou. Garanțiile de integritate și confidențialitate a datelor în specificația IPsec sunt furnizate prin utilizarea mecanismelor de autentificare și, respectiv, de criptare. Acestea din urmă, la rândul lor, se bazează pe acordul preliminar al părților la așa-numitul schimb de informații. „context de securitate” – algoritmi criptografici aplicați, algoritmi de gestionare a informațiilor cheie și parametrii acestora. Specificația IPsec prevede posibilitatea părților de a sprijini schimbul de informații din diferite protocoale și parametri pentru autentificarea și criptarea pachetelor de date, precum și diverse scheme distribuirea cheilor. În acest caz, rezultatul negocierii contextului de securitate este stabilirea unui index al parametrilor de securitate (SPI), care este un pointer către element specific structura internă a părții schimbului de informații, descriind seturi posibile de parametri de securitate. În esență, IPSec, care va deveni parte integrantă a IPv6, operează la nivelul al treilea, adică la nivelul rețelei. Ca rezultat, pachetele IP transmise vor fi protejate transparent aplicații de rețeași modul de infrastructură. Spre deosebire de SSL (Secure Socket Layer), care operează la nivelul 4 (adică, transportul) și este mai strâns asociat cu straturile superioare ale modelului OSI, IPSec este conceput pentru a oferi securitate la nivel scăzut. IPSec adaugă un antet la datele IP gata să fie trimise printr-o rețea privată virtuală pentru a identifica pachetele protejate. Înainte de a fi transmise prin Internet, aceste pachete sunt încapsulate în alte pachete IP. IPSec acceptă mai multe tipuri de criptare, inclusiv Data Encryption Standard și Message Digest 5. Pentru a stabili o conexiune sigură, ambele părți ale sesiunii trebuie să poată conveni rapid asupra parametrilor de securitate, cum ar fi algoritmii și cheile de autentificare. IPSec acceptă două tipuri de scheme de gestionare a cheilor prin care participanții pot negocia parametrii sesiunii. Acest suport dublu la un moment dat a provocat unele fricțiuni în grupul de lucru IETF. CU Versiune curentă Pot fi utilizate IP, IPv4, fie Internet Secure Association Key Management Protocol (ISAKMP), fie Simple Key Management for Protocol Internet. Odată cu noua versiune de IP, IPv6, va trebui să utilizați ISAKMP, acum cunoscut sub numele de IKE, deși posibilitatea de a utiliza SKIP nu este exclusă. Cu toate acestea, trebuie reținut că SKIP a fost de mult abandonat ca candidat cheie la management și a fost eliminat din lista de posibili candidați încă din 1997. IPsec este un set de standarde de internet și un fel de „suprastructură” pe IP. protocol. Nucleul său este format din trei protocoale:

  • Authentication Header (AH) asigură integritatea datelor transmise, autentificarea sursei de informații și funcția de prevenire a retransmiterii pachetelor
  • Încapsulating Security Payload (ESP) asigură confidențialitatea (criptarea) informațiilor transmise și limitează fluxul de trafic confidențial. În plus, poate îndeplini funcții AH: asigurarea integrității datelor transmise, autentificarea sursei de informații și funcția de prevenire a retransmiterii pachetelor. La utilizarea ESP, trebuie specificat un set de servicii de securitate: fiecare dintre funcțiile sale poate fi inclusă opțional.
  • Internet Security Association and Key Management Protocol (ISAKMP) este un protocol utilizat pentru configurarea inițială a conexiunii, autentificarea reciprocă între nodurile finale și schimbul de chei secrete. Protocolul prevede utilizarea diferitelor mecanisme de schimb de chei, inclusiv specificarea cheilor fixe, folosind protocoale precum Internet Key Exchange, Kerberized Internet Negotiation of Keys (RFC 4430) sau înregistrări tip DNS IPSECKEY (RFC 4025).

De asemenea, unul dintre conceptele cheie este Security Association (SA). În esență, SA este un set de parametri care caracterizează o conexiune. De exemplu, algoritmul de criptare și funcția hash utilizate, cheile secrete, numărul pachetului etc.

Antet AH

Antetul de autentificare (AH) este un antet opțional comun și este de obicei situat între antetul principal al pachetului IP și câmpul de date. Prezența AH nu afectează în niciun fel procesul de transmitere a informațiilor din transport și niveluri superioare. Principalul și singurul scop al AH este de a oferi protecție împotriva atacurilor legate de modificări neautorizate ale conținutului unui pachet, inclusiv falsificarea adresei sursă a stratului de rețea. Protocoalele de nivel superior trebuie modificate pentru a verifica autenticitatea datelor primite. Formatul AH este destul de simplu și constă dintr-un antet de 96 de biți și date de lungime variabilă constând din cuvinte de 32 de biți. Numele câmpurilor reflectă conținutul lor destul de clar: Next Header indică următorul antet, Payload Len reprezintă lungimea pachetului, SPI este un pointer către contextul de securitate și Sequence Number Field conține numărul de secvență al pachetului. Numărul de secvență al pachetului a fost introdus în AH în 1997 ca parte a procesului de revizuire a specificațiilor IPsec. Valoarea acestui câmp este generată de expeditor și servește la protejarea împotriva atacurilor legate de reutilizare datele procesului de autentificare. Deoarece Internetul nu garantează ordinea în care vor fi livrate pachetele, destinatarul trebuie să stocheze informații despre numărul maxim de secvență al unui pachet autentificat cu succes și dacă au fost primite un număr de pachete care conțin numere de secvență anterioare (de obicei 64). Spre deosebire de algoritmii de calcul al sumelor de control utilizați în protocoalele de transmitere a informațiilor prin linii de comunicații comutate sau prin canalele rețelei locale și care vizează corectarea erorilor aleatoare din mediul de transmisie, mecanismele de asigurare a integrității datelor în rețelele de telecomunicații deschise trebuie să aibă mijloace de protecție împotriva modificărilor vizate. Un astfel de mecanism este o utilizare specială a algoritmului MD5: în timpul formării AH, o funcție hash este calculată secvențial din unirea pachetului în sine și a unei chei convenite în prealabil, apoi din unirea rezultatului rezultat și a cheie transformată. Acesta este mecanismul implicit pentru a se asigura că toate implementările IPv6 au cel puțin una algoritm general, fără restricții la export.

Antet ESP

Când se utilizează încapsularea datelor criptate, antetul ESP este ultimul dintre anteturile opționale „vizibile” din pachet. Deoarece scopul principal al ESP este de a asigura confidențialitatea datelor, diferite tipuri de informații pot necesita algoritmi de criptare semnificativ diferiți. În consecință, formatul ESP poate suferi modificări semnificative în funcție de algoritmii criptografici utilizați. Cu toate acestea, se pot distinge următoarele câmpuri obligatorii: SPI, care indică contextul de securitate și Câmpul Număr de secvență, care conține numărul de secvență al pachetului. Câmpul „Date de autentificare ESP” (sumă de control) este opțional în antetul ESP. Destinatarul pachetului ESP decriptează antetul ESP și utilizează parametrii și datele algoritmului de criptare aplicat pentru a decoda informațiile din stratul de transport. Există două moduri de utilizare a ESP și AH (precum și combinațiile acestora) - transport și tunel.

AH și ESP

Asociații de securitate

O Asociație de Securitate (SA) este o conexiune care oferă servicii de securitate pentru traficul care trece prin ea. Două computere de fiecare parte a SA stochează modul, protocolul, algoritmii și cheile utilizate în SA. Fiecare SA este utilizat într-o singură direcție. Comunicarea bidirecțională necesită două SA. Fiecare SA implementează un mod și un protocol; astfel, dacă sunt necesare două protocoale pentru un pachet (cum ar fi AH și ESP), atunci sunt necesare două SA. Pentru a începe schimbul de date între două părți, este necesar să se stabilească o conexiune numită SA (Security Association). Conceptul de SA este fundamental pentru IPsec, de fapt, este esența acestuia. Acesta descrie modul în care părțile vor folosi serviciile pentru a asigura o comunicare sigură. Conexiunea SA este simplex (unidirecțională), deci trebuie stabilite două conexiuni pentru ca părțile să poată comunica. De asemenea, este de remarcat faptul că standardele IPsec permit punctelor terminale ale unui canal securizat să utilizeze fie un SA pentru a transmite trafic de la toate gazdele care interacționează prin acest canal, fie să creeze un număr arbitrar de asociații securizate în acest scop, de exemplu, una pentru fiecare Conexiune TCP. Acest lucru face posibilă alegerea nivelului dorit de granularitate de protecție. Stabilirea unei conexiuni începe cu autentificarea reciprocă a părților. În continuare, sunt selectați parametrii (dacă se va efectua autentificarea, criptarea, verificarea integrității datelor) și protocolul necesar (AH sau ESP) pentru transferul de date. După aceasta, algoritmi specifici (de exemplu, criptare, funcție hash) sunt selectați dintre mai mulți scheme posibile, dintre care unele sunt definite de standard (pentru criptare - DES, pentru funcții hash - MD5 sau SHA-1), altele sunt adăugate de producătorii de produse care folosesc IPsec (de exemplu Triple DES, Blowfish, CAST).

Baza de date a asociațiilor de securitate

Toate SA sunt stocate în baza de date SAD (Security Associations Database) a modulului IPsec. Fiecare SA are un marker unic format din trei elemente:

  • Indexul parametrilor de securitate (SPI)
  • Adresele IP de destinație
  • identificatorul protocolului de securitate (ESP sau AH)

Modulul IPsec, având acești trei parametri, poate găsi o intrare în SAD pentru un anumit SA. Lista componentelor SA include:

Număr de serie

O valoare de 32 de biți care este utilizată pentru a forma câmpul Număr de secvență din anteturile AH și ESP.

Număr de secvență depășire

Un steag care semnalează că contorul numărului de secvență a depășit.

Fereastra pentru suprimarea atacurilor de reluare

Folosit pentru a determina retransmisia pachetelor. Dacă valoarea din câmpul Număr secvență nu se încadrează în intervalul specificat, pachetul este aruncat.

Informații AH

algoritm de autentificare utilizat, cheile necesare, durata de viață cheie și alți parametri.

informații ESP

algoritmi de criptare și autentificare, chei necesare, parametri de inițializare (de exemplu, IV), durata de viață a cheii și alți parametri

Mod de operare IPsec

tunel sau transport

SA durata de viata

Specificat în secunde sau octeți de informații care trec prin tunel. Stabilește durata existenței SA când se atinge această valoare, SA actuală trebuie să se termine, dacă este necesar, se stabilește un nou SA;

Antet de autentificare

AH este utilizat pentru a autentifica expeditorul de informații, pentru a asigura integritatea datelor și poate fi utilizat opțional pentru a proteja împotriva retransmiterii datelor. Autentificarea se realizează prin calcularea funcției hash a pachetului IP (sunt excluse câmpurile care se pot modifica în timpul transmiterii pachetului (de exemplu, TTL). Funcția hash calculată este adăugată la antetul pachetului AH și trimisă destinatarului pachetului. Antetul AH conține câmpul Valoare de verificare a integrității, care este calculat folosind algoritmii MD5 sau SHA-1. În practică, HMAC (Codul de autentificare a mesajelor hash) este mai des folosit, deoarece folosește o cheie secretă cunoscută dinainte de participanți atunci când calculează funcția hash. HMAC, la rândul său, utilizează algoritmi MD5 sau SHA-1 pentru a calcula funcția hash. În funcție de algoritmul utilizat, HMAC se va numi HMAC-MD5 sau, respectiv, HMAC-SHA-1.

„Format antet de autentificare”
Compensații Octetul 16 0 1 2 3
Octetul 16 Bit 10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Următorul antet Sarcina utilă Len Rezervat
4 32 Indexul parametrilor de securitate (SPI)
8 64 Număr de secvență
C 96 Valoarea de verificare a integrității (ICV)
... ...

Următorul tip de antet (8 biți)

Tipul de antet de protocol care vine după antetul AH. Folosind acest câmp, modulul IP-sec receptor învață despre protocolul protejat de nivel superior. Semnificațiile acestui câmp pentru diferite protocoale pot fi găsite în RFC 1700.

Lungimea conținutului (8 biți)

Acest câmp specifică dimensiunea totală a antetului AH în cuvinte de 32 de biți, minus 2. Cu toate acestea, când se utilizează IPv6, lungimea antetului trebuie să fie un multiplu de 8 octeți.

Rezervat (16 biți)

Rezervat. Umplut cu zerouri.

Indexul parametrilor sistemului de securitate (32 de biți)

Indexul parametrilor de securitate. Valoarea acestui câmp, împreună cu adresa IP destinatarului și protocolul de securitate (protocol AN), identifică în mod unic conexiunea virtuală securizată (SA) pentru a acestui pachet. Intervalul de valori SPI 1...255 este rezervat de IANA.

Număr de secvență (32 de biți)

Număr de serie. Servește pentru a proteja împotriva retransmiterii. Câmpul conține o valoare a parametrului care crește monoton. Deși destinatarul poate renunța la serviciul de protecție a reluării pachetelor, acesta este obligatoriu și este întotdeauna prezent în antetul AH. Modulul IPsec de trimitere folosește întotdeauna acest câmp, dar este posibil ca receptorul să nu-l proceseze.

Date de autentificare

Semnatura digitala. Servește la autentificarea și verificarea integrității pachetului. Trebuie să fie completat la o dimensiune care este un multiplu de 8 octeți pentru IPv6 și 4 octeți pentru IPv4. Protocolul AH este folosit pentru autentificare, adică pentru a confirma că comunicăm cu cine credem că suntem și că datele pe care le primim nu sunt corupte în timpul transmiterii.

Procesarea pachetelor IP de ieșire

Dacă modulul IPsec de trimitere determină că pachetul este asociat cu un SA care implică procesarea AH, atunci începe procesarea. În funcție de mod (mod transport sau tunel), acesta inserează diferit antetul AH în pachetul IP. În modul de transport, antetul AH este plasat după antetul protocolului IP și înaintea antetelor protocolului de nivel superior (de obicei TCP sau UDP). În modul tunel, întregul pachet IP original este înconjurat mai întâi de antetul AH, apoi de antetul protocolului IP. Acest antet se numește extern, iar antetul pachetului IP original este numit intern. După aceasta, modulul IPsec care transmite trebuie să genereze un număr de secvență și să îl scrie în câmpul Număr de secvență. Când se stabilește un SA, numărul de secvență este setat la 0 și este incrementat cu unu înainte ca fiecare pachet IPsec să fie trimis. În plus, se face o verificare pentru a vedea dacă contorul a intrat într-o buclă. Dacă a atins valoarea maximă, atunci este setată din nou la 0. Dacă se utilizează serviciul de prevenire a reluării, atunci când contorul atinge valoarea maximă, modulul IPsec de trimitere resetează SA. Acest lucru asigură protecția împotriva retrimiterii pachetelor, modulul IPsec de primire va verifica câmpul Număr de secvență și va ignora pachetele care sosesc în mod repetat. În continuare, se calculează suma de control ICV. Trebuie remarcat faptul că aici suma de control este calculată folosind o cheie secretă, fără de care un atacator va putea recalcula hash-ul, dar fără să cunoască cheia, nu va putea genera suma de control corectă. Algoritmii specifici utilizați pentru a calcula ICV pot fi găsiți în RFC 4305. În prezent, de exemplu, algoritmii HMAC-SHA1-96 sau AES-XCBC-MAC-96 pot fi utilizați. Protocolul AH calculează o sumă de control (ICV) pe baza următoarelor câmpuri ale pachetului IPsec:

câmpurile antetului IP care nu au fost supuse modificărilor în timpul procesului de difuzare sau identificate ca fiind cel mai important antet AH (Câmpuri: „Următorul Antet”, „Payload Len”, „Rezervat”, „SPI”, „Număr de secvență”, Valoarea „Verificarea integrității” Câmpul „Valoarea verificării integrității” este setat la 0 atunci când se calculează ICV al datelor de protocol de nivel superior. Dacă câmpul se poate modifica în timpul transportului, atunci valoarea sa este setată la 0 înainte de calcularea ICV. Excepții sunt câmpuri care se pot modifica, dar a căror valoare poate fi prevăzută la recepție, acestea nu sunt completate cu zerouri adresa IP a destinatarului. O descriere mai detaliată a câmpurilor care sunt luate în considerare la calcularea ICV poate fi găsită în standardul RFC 2402.

Procesarea pachetelor IP de intrare

După primirea unui pachet care conține un mesaj de protocol AH, modulul de primire IPsec caută conexiunea virtuală securizată (SA) SAD (Security Associations Database) corespunzătoare folosind adresa IP a destinatarului, protocolul de securitate (AN) și indexul SPI. Dacă nu se găsește niciun SA care se potrivește, pachetul este aruncat. O conexiune virtuală securizată (SA) găsită indică dacă serviciul de prevenire a reluării pachetelor este utilizat, adică necesitatea de a verifica câmpul Număr de secvență. Dacă serviciul este utilizat, câmpul este bifat. Aceasta folosește o metodă de fereastră glisantă pentru a limita memoria tampon cerută de protocol. Modulul IPsec receptor formează o fereastră cu lățimea W (de obicei W este selectat egal cu 32 sau 64 de pachete). Marginea din stânga a ferestrei corespunde numărului de secvență minim N al unui pachet primit corect. Un pachet cu un câmp de Număr de secvență care conține o valoare cuprinsă între N+1 și N+W este primit corect. Dacă pachetul primit se află pe marginea stângă a ferestrei, acesta este distrus. Modulul IPsec de recepție calculează apoi ICV din câmpurile corespunzătoare pachetului primit, folosind algoritmul de autentificare pe care îl învață din înregistrarea SA și compară rezultatul cu valoarea ICV situată în câmpul Integrity Check Value. Dacă valoarea ICV calculată coincide cu cea primită, atunci pachetul primit este considerat valid și este acceptat pentru procesarea IP ulterioară. Dacă verificarea dă un rezultat negativ, atunci pachetul primit este distrus.

Încapsularea sarcinii utile de securitate

ESP este un protocol de securitate care asigură confidențialitatea și protecția datelor. Sunt posibile autentificarea (AH) și detectarea reluării. ESP încapsulează complet pachetele. ESP poate fi folosit singur sau cu utilizarea AH.

MTU

Dimensiunea maximă a pachetului care poate fi transmisă pe un canal virtual fără fragmentare. Fiecare protocol (ESP/AH) trebuie să aibă propriul SA pentru fiecare direcție, astfel încât combinația AH+ESP necesită patru SA pentru un canal duplex. Toate aceste date se află în SAD.

Pe lângă baza de date SAD, implementările IPsec acceptă o bază de date SPD (Security Policy Database). SPD servește la corelarea pachetelor IP primite cu regulile de procesare pentru acestea. Înregistrările SPD constau din două câmpuri. Primul stochează trăsăturile caracteristice ale pachetelor, prin care poate fi identificat unul sau altul flux de informații. Aceste câmpuri se numesc selectori. Exemple de selectoare care sunt conținute în SPD:

  • Destinatia adresei IP
  • Adresa IP a expeditorului
  • Nume de utilizator în format DNS sau X.500
  • Porturi de expeditor și receptor

Al doilea câmp din SPD conține politica de securitate corespunzătoare fluxului de pachete dat. Selectorii sunt utilizați pentru a filtra pachetele de ieșire pentru a potrivi fiecare pachet cu un anumit SA. Când sosește un pachet, valorile câmpurilor corespunzătoare din pachet (câmpurile de selecție) sunt comparate cu cele conținute în SPD. Când se găsește o potrivire, câmpul de politică de protecție conține informații despre ce trebuie făcut cu pachetul: transmiteți-l ca atare, aruncați-l sau procesați-l. În cazul procesării, același câmp conține un link către intrarea corespunzătoare din SAD. Apoi se determină SA pachetului și indicele parametrului de securitate asociat (SPI) și se efectuează operațiuni IPsec (operații de protocol AH sau ESP). Dacă pachetul este primit, atunci acesta conține imediat SPI - se efectuează procesarea corespunzătoare.

Politică de securitate

Politica de securitate este stocată în SPD (Security Policy Database). SPD poate specifica una dintre următoarele pentru un pachet de date: trei actiuni: Aruncați pachetul, nu procesați pachetul folosind IPSec, procesați pachetul folosind IPSec. În acest ultim caz, SPD-ul indică și ce SA ar trebui utilizat (dacă, desigur, a fost deja creată un SA adecvat) sau indică cu ce parametri ar trebui creat un nou SA. SPD este un mecanism de control foarte flexibil care permite un control foarte bun asupra procesării fiecărui pachet. Pachetele sunt clasificate după un număr mare de câmpuri, iar SPD-ul poate examina unele sau toate câmpurile pentru a determina acțiunea corespunzătoare. Acest lucru ar putea duce la transportul întregului trafic între două mașini folosind un singur SA, sau SA-uri separate pentru fiecare aplicație sau chiar pentru fiecare conexiune TCP. Sistemele care implementează IPSec trebuie să accepte două baze de date:

  • Baza de date pentru politici de securitate (SPD);
  • baza de date a contextelor de securitate a protocolului (Security Association Database, SAD);

Toate pachetele IP (de intrare și de ieșire) sunt comparate cu un set ordonat de reguli de politică de securitate. La comparare se folosește selectorul care apare în fiecare regulă - un set de câmpuri analizate la nivel de rețea și niveluri superioare de protocol. Prima regulă potrivită determină soarta ulterioară a pachetului:

  • pachetul poate fi lichidat;
  • pachetul poate fi procesat fără participarea instrumentelor IPSec;
  • pachetul trebuie procesat de IPSec, ținând cont de setul de contexte de protocol asociate regulii;

În acest fel, sistemele care implementează IPSec funcționează ca firewall-uri, filtrănd și transformând fluxurile de date pe baza unei politici de securitate predefinite.

Contextul de securitate al protocolului în IPSec este o „conexiune” unidirecțională (de la sursă la destinație) care oferă fluxurilor de date deservite un set de servicii de securitate în cadrul unui singur protocol (AH sau ESP). În cazul interacțiunii simetrice, partenerii vor trebui să organizeze două contexte (câte unul în fiecare direcție). Dacă sunt utilizate atât AH, cât și ESP, sunt necesare patru contexte.

Elementele bazei de date de context de protocol conțin următoarele câmpuri (în fiecare caz, unele valori de câmp vor fi goale):

  • algoritmul de autentificare utilizat în protocolul AH, cheile acestuia etc.;
  • algoritmul de criptare utilizat în protocolul ESP, cheile acestuia, vectorul inițial etc.;
  • algoritmul de autentificare utilizat în protocolul ESP, cheile acestuia etc.;
  • durata de viață a contextului;
  • Mod de operare IPSec: transport sau tunel;
  • dimensiunea maximă a pachetului;
  • un grup de câmpuri (contor, fereastră, steaguri) pentru a proteja împotriva reluării pachetelor;

Utilizatorii contextelor de protocol sunt de obicei procese de aplicație. În general, poate exista un număr arbitrar de contexte de protocol între două noduri de rețea, deoarece numărul de aplicații din noduri este arbitrar. Utilizatorii contextelor de control sunt de obicei noduri de rețea (deoarece este de dorit să se concentreze funcționalitatea comună în aceste contexte, servicii necesare securitatea tuturor straturilor de protocol ale modelului de referință pentru gestionarea cheilor criptografice).

Contextele de control sunt bidirecționale, adică fiecare partener poate iniția un nou schimb de chei. O pereche de noduri poate suporta simultan mai multe contexte de control activ dacă există aplicații cu diferite diferite cerințe criptografice. De exemplu, este posibil să se genereze o parte din chei pe baza materialului pre-distribuit, în timp ce cealaltă parte este generată folosind algoritmul Diffie-Hellman.

Contextul protocolului pentru IPSec este identificat prin adresa IP țintă, protocolul (AH sau ESP) și o valoare suplimentară, Indexul parametrilor de securitate (SPI). Ultima valoare este necesară deoarece pot exista mai multe contexte cu aceleași adrese IP și protocoale. Următoarele arată cum sunt utilizați indecșii SPI la procesarea pachetelor de intrare.

IPSec impune suport pentru gestionarea manuală și automată a contextelor de securitate și a cheilor criptografice. În primul caz, toate sistemele sunt furnizate în prealabil cu materiale cheie și alte date necesare pentru interacțiunea sigură cu alte sisteme. În al doilea, materialul și datele sunt generate dinamic, pe baza unui protocol specific - IKE, al cărui suport este obligatoriu.

Contextul protocolului este creat pe baza managerului care utilizează materialul cheie și mijloacele de autentificare și criptare ale acestora din urmă. În cel mai simplu caz, atunci când cheile de protocol sunt generate pe baza celor existente. Când a fost dezvoltat contextul de control, au fost create trei tipuri de chei pentru acesta:

  • SKEYID_d - material cheie folosit pentru generarea cheilor de protocol;
  • SKEYID_a - material cheie pentru autentificare;
  • SKEYID_e - material cheie pentru criptare;

Toate tipurile de chei enumerate sunt implicate în schimb. Mesajele sunt criptate folosind cheia SKEYID_e. Cheia SKEYID_a servește ca argument pentru funcțiile hash și, prin urmare, autentifică mesajele. În cele din urmă, cheile de protocol sunt rezultatul aplicării unei funcții pseudo-aleatoare (hash) la SKEYID_d cu parametri suplimentari, care includ numerele de unică folosință ale inițiatorului și partenerului. Ca urmare, crearea unui context de protocol este autentificată, protejată de accesul neautorizat, de redarea mesajelor și de interceptarea conexiunii.

Mesajele (1) și (2) pot avea încărcătură suplimentară, de exemplu, date pentru generarea de chei secrete „complet noi” sau identificatori ai clienților în numele cărora serverele ISAKMP formează un context de protocol. Conform protocolului IKE, într-un schimb (constând din cele trei mesaje afișate) se formează două contexte unidirecționale - câte unul în fiecare direcție. Destinatarul contextului îl setează la un indice de parametri de securitate (SPI), care îl ajută să găsească un context pentru a procesa pachetele IPSec primite.

Contextele de protocol joacă un rol de sprijin, fiind doar un mijloc de aplicare a politicii de securitate; trebuie să fie setat pentru toată lumea interfata retea cu IPSec activat și pentru fiecare direcție a fluxurilor de date (intrare/ieșire). Conform specificațiilor IPSec, politica este concepută pentru a procesa pachetele IP fără context (independent), în spiritul routerelor de filtrare moderne. Desigur, trebuie să existe instrumente pentru administrarea bazei de date SPD, la fel cum există instrumente pentru administrarea bazei de reguli firewall, cu toate acestea, acest aspect nu este inclus în standardizare.

Dintr-o perspectivă externă, o bază de date de politici de securitate (SPD) este un set ordonat de reguli. Fiecare regulă este specificată ca o pereche:

  • un set de selectoare;
  • un set de contexte de securitate a protocolului;

Selectorii sunt utilizați pentru a selecta pachetele, contextele specifică procesarea necesară. Dacă o regulă se referă la un context inexistent, trebuie să conțină suficiente informații pentru ca acesta (contextul) să fie creat dinamic. În acest caz, este necesar suport pentru contextul automat și managementul cheilor. În principiu, funcționarea sistemului poate începe prin setarea bazei SPD cu o bază de date de context (SAD) goală; acesta din urmă va fi completat după caz.

Diferențierea politicii de securitate este determinată de selectorii utilizați în reguli. De exemplu, o pereche de gazde care comunică poate utiliza un singur set de contexte dacă selectoarele includ numai adrese IP; pe de altă parte, setul poate fi diferit pentru fiecare aplicație dacă sunt analizate numerele de porturi TCP și UDP. În mod similar, două gateway-uri de securitate sunt capabile să organizeze un singur tunel pentru toate gazdele deservite sau să-l divizeze (prin organizarea de contexte diferite) în perechi de gazde sau chiar aplicații.

Toate implementările IPSec trebuie să accepte selecția următoarelor elemente:

  • adrese IP sursă și destinație (adresele pot fi individuale și de grup; regulile permit intervale de adrese și „orice” metacaractere;
  • nume de utilizator sau gazdă în format DNS sau X.500;
  • protocol de transport;
  • numerele portului sursă și destinație (intervalele și metacaracterele pot fi, de asemenea, folosite aici);

Procesarea traficului de ieșire și de intrare nu este simetrică. Pentru pachetele de ieșire, baza de date SPD este scanată, se găsește o regulă adecvată, se recuperează contextele de protocol asociate și se aplică mecanismele de securitate adecvate. Pachetele primite pentru fiecare protocol de securitate au deja o valoare SPI, care identifică în mod unic contextul. În acest caz, vizualizarea bazei de date SPD nu este necesară; se poate presupune că politica de securitate a fost luată în considerare la formarea contextului adecvat. (În practică, aceasta înseamnă că pachetele ISAKMP au nevoie de un tratament special, iar regulile cu selectori corespunzători trebuie incluse în SPD.)

Asimetria remarcată reflectă o anumită incompletitudine a arhitecturii IPSec. RFC 1825 anterior nu avea conceptele unei baze de date de politici de securitate și selectoare. Noua ediție face o jumătate de pas înainte - vizualizarea bazei de date SPD este specificată ca fiind obligatorie pentru fiecare pachet de ieșire, dar procesarea pachetelor de intrare nu este modificată. Preluarea contextului dintr-un index SPI este mai eficientă decât a căuta printr-un set de reguli, dar această abordare face dificilă schimbare operațională politici de securitate. În ceea ce privește eficiența navigării regulilor, aceasta poate fi îmbunătățită prin tehnici de stocare în cache, care sunt utilizate pe scară largă în implementările IP.

ISAKMP/Oakley

Protocolul ISAKMP definește structura generala protocoale care sunt utilizate pentru a stabili SA și pentru a îndeplini alte funcții cheie de management. ISAKMP acceptă mai multe Domenii de Interpretare (DOI), dintre care unul este IPSec-DOI. ISAKMP nu definește un protocol complet, ci mai degrabă oferă „blocuri de bază” pentru diferite DOI și protocoale de schimb de chei. Protocolul Oakley este un protocol de descoperire a cheilor care utilizează algoritmul de înlocuire a cheilor Diffie-Hellman. Protocolul Oakley acceptă Perfect Forward Secrecy (PFS). Prezența PFS înseamnă că este imposibil să decriptați întregul trafic dacă orice cheie din sistem este compromisă.

IKE

Deoarece ambele părți ale conversației trebuie să cunoască valorile secrete utilizate în procesul de hashing sau de criptare, se pune întrebarea cum sunt schimbate aceste date. Cheile proprii necesită introducerea manuală a valorilor secrete la ambele capete, probabil transmise printr-un mecanism extern, iar IKE (Internet Key Exchange) oferă un mecanism complex pentru a face acest lucru online.

IKE este protocolul implicit de schimb de chei pentru ISAKMP și în prezent este singurul. IKE se află deasupra ISAKMP și realizează înființarea atât a ISAKMP SA, cât și a IPSec SA. IKE suportă un set de diferite funcții primitive pentru utilizare în protocoale. Printre acestea se numără funcția hash și funcția pseudo-aleatorie (PRF). O „funcție hash” este o funcție rezistentă la coliziuni. Rezistența la coliziune înseamnă faptul că este imposibil să găsiți două mesaje diferite m1 și m2 astfel încât H(m1)=H(m2), unde H este o funcție hash. În ceea ce privește funcțiile pseudo-aleatoare, o funcție hash este utilizată în prezent în locul PRF-urilor speciale în designul HMAC (HMAC este un mecanism de autentificare a mesajelor care utilizează funcții hash). Pentru a defini HMAC, avem nevoie de o funcție hash criptografică (să o numim H) și de o cheie secretă K. Presupunem că H este o funcție hash în care datele sunt hash folosind o procedură de compresie aplicată secvențial unei secvențe de blocuri de date. Notăm cu B lungimea acestor blocuri în octeți și lungimea blocurilor obținute ca urmare a hashingului cu L (L

ipad = octet 0x36, repetat de B ori; opad = octet 0x5C repetat de B ori.

IKE combină trei direcții principale (protocoale separate):

  • ISAKMP (Internet Security Association and Key Management Protocol) - protocol pentru asociațiile de securitate și managementul cheilor pe Internet; aceasta este o descriere generală (cadru) pentru furnizarea de autentificare și schimb de chei fără a specifica algoritmi de aplicație specifici;
  • Oakley (Oakley key determination protocol) - protocol Oakley de determinare a cheii; descrie secvențele de schimb de chei - moduri - și descrie funcțiile pe care le oferă;
  • SKEMI (Secure Key Exchange Mechanism for Internet) - un mecanism pentru schimbul securizat de chei pe Internet; descrie tehnologii multifuncționale care asigură anonimatul, non-repudierea (apelabilitate) și actualizarea rapidă a tastelor;

IKE conține două faze ale acordului cheie. În prima fază se creează un canal securizat, în a doua se negociază și se schimbă cheile și se stabilește un SA. Prima fază folosește unul dintre cele două moduri: modul principal sau modul agresiv. Diferența dintre ele este nivelul de securitate și viteza de operare. Modul de bază, care este mai lent, protejează toate informațiile transferate între noduri. Modul agresiv pentru accelerarea muncii lasă o serie de parametri deschisi și vulnerabili la interceptări, se recomandă să fie utilizat numai atunci când viteza este o problemă critică. A doua fază folosește Quick Mode, numit așa pentru că nu autentifică nodurile, presupunând că acest lucru a fost făcut în prima fază. Această fază asigură schimbul de chei cu care datele sunt criptate.
IKE (pronunțat ike, abrevierea pentru Internet Key Exchange) este un protocol care leagă toate componentele IPsec într-un întreg funcțional. În special, IKE oferă autentificarea inițială a părților, precum și schimbul lor de chei secrete partajate.

Este posibil să setați manual o cheie pentru o sesiune (a nu fi confundată cu o cheie pre-partajată pentru autentificare). În acest caz, IKE nu este utilizat. Cu toate acestea, această opțiune nu este recomandată și este rar folosită. În mod tradițional, IKE operează prin portul UDP 500.

Există IKE și o versiune mai nouă a protocolului: IKEv2. Există unele diferențe în specificațiile și funcționarea acestor protocoale. IKEv2 stabilește parametrii de conectare într-o singură fază constând din mai mulți pași. Procesul IKE poate fi împărțit în două faze.

Primă fază

IKE creează un canal securizat între doi colegi, numit asociere de securitate IKE (IKE SA). De asemenea, în această fază, două noduri convin asupra unei chei de sesiune folosind algoritmul Diffie-Hellman. Prima fază a IKE poate avea loc în unul dintre cele două moduri:

Mod de bază

Constă din trei schimburi bidirecționale între expeditor și destinatar: în timpul primului schimb, algoritmii și funcțiile hash care vor fi utilizate pentru a securiza conexiunea IKE sunt negociate prin potrivirea IKE SA a fiecărui nod. Folosind algoritmul Diffie-Hellman, părțile schimbă o cheie secretă partajată. Nodurile verifică, de asemenea, identificarea reciprocă prin transmiterea și confirmarea unei secvențe de numere pseudoaleatoare. Identitatea părții opuse este verificată folosind adresa IP criptată. Ca urmare a execuției modului principal, este creat un canal securizat pentru schimbul ISAKMP ulterioar (acest protocol definește procedura de autentificare a conexiunilor nodurilor, crearea și gestionarea SA, generarea cheilor și atenuarea amenințărilor precum atacurile DoS sau atacurile replay).

Modul agresiv

Acest mod necesită un număr mai mic de schimburi și, în consecință, un număr mai mic de pachete. Primul mesaj conține aproape toate informațiile necesare înființării unui IKE SA: cheia publică Diffie-Hellman, pentru sincronizarea pachetelor, confirmată de un alt participant, identificatorul pachetului. Destinatarul trimite înapoi tot ce este necesar pentru a finaliza schimbul. Primul nod trebuie doar să confirme conexiunea. Din punct de vedere al securității, modul agresiv este mai slab, deoarece participanții încep să facă schimb de informații înainte de a stabili un canal securizat, astfel încât interceptarea neautorizată a datelor este posibilă. Cu toate acestea, acest mod este mai rapid decât cel principal. Conform standardului IKE, orice implementare este necesară pentru a suporta modul de bază și este foarte de dorit să suporte modul agresiv.

Faza a doua

În faza a doua a IKE, există un singur mod rapid. Modul rapid este executat numai după crearea unui canal securizat în prima fază. Negociază o politică comună IPsec, obține chei secrete partajate pentru algoritmii de protocol IPsec (AH sau ESP) și stabilește un SA IPsec. Utilizarea numerelor secvențiale oferă protecție împotriva atacurilor de reluare. Modul rapid este, de asemenea, utilizat pentru a revizui IPsec SA curent și pentru a selecta unul nou atunci când durata de viață a SA expiră. În mod implicit, modul rapid actualizează cheile secrete partajate folosind algoritmul Diffie-Hellman din prima fază.

În plus

De-a lungul timpului, a devenit clar că PSK singur nu era suficient pentru a asigura securitatea. De exemplu, dacă stația de lucru a unui angajat a fost compromisă, atacatorul ar putea obține imediat acces la întreaga rețea internă a întreprinderii. Prin urmare, faza 1.5 a fost dezvoltată chiar între prima și a doua fază clasică. Apropo, această fază nu este de obicei utilizată într-o conexiune VPN standard de la site la site, ci este utilizată atunci când se organizează conexiuni VPN la distanță (cazul nostru). Această fază conține două noi extensii - Extended Authentication (XAUTH) și Mode-Configuration (MODECFG).

XAUTH este o autentificare suplimentară a utilizatorilor în cadrul protocolului IKE. Această autentificare este uneori numită și al doilea factor IPsec. MODECFG servește la transmiterea de informații suplimentare către client, aceasta poate fi o adresă IP, mască, server DNS etc. Se poate observa că această fază pur și simplu le completează pe cele discutate anterior, dar utilitatea ei este neîndoielnică.

IKEv2 vs IKEv1

Ambele protocoale funcționează pe portul UDP numărul 500, dar sunt incompatibile între ele, situația în care există IKEv1 la un capăt al tunelului și IKEv2 la celălalt; Iată principalele diferențe dintre a doua versiune și prima:

MD5, SHA-1 etc.

Configurarea unei conexiuni IPsec implică tot felul de soluții criptografice, dar este mult simplificată de faptul că orice conexiune poate folosi nu mai mult de două sau (rar) trei odată.

Autentificarea calculează valoarea de verificare a integrității (ICV) a conținutului pachetului și, de obicei, utilizează un algoritm hash criptografic, cum ar fi MD5 sau SHA-1. Include o cheie secretă cunoscută de ambele părți, permițând destinatarului să calculeze ICV în același mod. Dacă destinatarul primește aceeași valoare, atunci expeditorul a fost autentificat cu succes (pe baza ipotezei că hashurile criptografice sunt practic imposibil de inversat). AH oferă întotdeauna autentificare, dar aceasta este opțională pentru ESP. Criptarea folosește o cheie secretă pentru a cripta datele înainte de transmitere, care protejează conținutul real al pachetului de interceptări. Există destul de multe opțiuni pentru algoritmi, cele comune sunt DES, 3DES, Blowfish și AES. Altele sunt posibile.

Atacuri asupra AH, ESP și IKE

Toate tipurile de atacuri asupra componentelor IPSec pot fi împărțite în următoarele grupe: atacuri care exploatează resursele finite ale sistemului (un exemplu tipic este un atac Denial of Service, un atac Denial-of-service sau DOS), atacuri care exploatează caracteristicile și erori ale unei implementări specifice IPSec și, în sfârșit, atacuri bazate pe punctele slabe ale protocoalelor în sine. AH și ESP. Atacurile pur criptografice pot fi ignorate - ambele protocoale definesc conceptul de „transformare”, unde toată criptografia este ascunsă. Dacă cripto-algoritmul utilizat este stabil, iar transformarea definită cu acesta nu introduce slăbiciuni suplimentare (nu este întotdeauna cazul, deci este mai corect să luăm în considerare puterea întregului sistem - Protocol-Transform-Algorithm), atunci din partea asta totul este bine. Ce ramane? Replay Attack - nivelat folosind Sequence Number (într-un singur caz, acest lucru nu funcționează - atunci când utilizați ESP fără autentificare și fără AH). În plus, ordinea acțiunilor (întâi criptare, apoi autentificare) garantează respingerea rapidă a pachetelor „rele” (mai mult, conform cercetărilor recente din lumea criptografiei, această ordine a acțiunilor este cea mai sigură; ordinea inversă în unele, deși cazuri foarte speciale, pot duce la posibile găuri de securitate, din fericire, nici SSL, nici IKE, nici alte protocoale comune cu ordinea acțiunilor „mai întâi autentificați, apoi criptați” nu se aplică acestor cazuri speciale și, prin urmare, nu au aceste găuri; ). Ceea ce rămâne este atacul Denial-Of-Service. După cum știți, acesta este un atac împotriva căruia nu există o apărare completă. Cu toate acestea, respingerea rapidă a pachetelor proaste și absența oricărei reacții externe la acestea (conform RFC) fac posibilă tratarea mai mult sau mai puțin bine cu acest atac. În principiu, majoritatea (dacă nu toate) atacurilor de rețea cunoscute (sniffing, spoofing, hijacking etc.) sunt rezistate cu succes de AH și ESP atunci când sunt utilizate corect. Cu IKE este puțin mai complicat. Protocolul este foarte complex și greu de analizat. În plus, din cauza greșelilor de scriere (în formula de calculare a HASH_R) la scrierea acestuia și a soluțiilor care nu sunt complet reușite (același HASH_R și HASH_I), conține mai multe „găuri” potențiale (în special, în prima fază, nu toate sarcinile utile din mesajele sunt autentificate), cu toate acestea, nu sunt foarte serioase și conduc, cel mult, la refuzul de a stabili o conexiune IKE se protejează mai mult sau mai puțin cu succes de atacuri precum replay, spoofing, sniffing, hijacking. Cu criptografia este ceva mai complicat - nu se realizează separat, ca în AH și ESP, ci este implementat în protocolul în sine. Cu toate acestea, dacă utilizați algoritmi și primitive persistente (PRF), nu ar trebui să existe probleme. Într-o oarecare măsură, poate fi considerat o slăbiciune a IPsec faptul că DES este indicat ca singurul algoritm criptografic obligatoriu în specificațiile actuale (acest lucru este valabil atât pentru ESP, cât și pentru IKE), ai căror 56 de biți ai cheii nu mai sunt considerați suficienți. . Cu toate acestea, aceasta este o slăbiciune pur formală - specificațiile în sine sunt independente de algoritm și aproape toți furnizorii cunoscuți au implementat de mult 3DES (și unii au implementat deja AES). Astfel, dacă sunt implementate corect, cel mai „periculos” atac rămâne Refuzarea serviciului .

Cum funcționează IPsec

Protocoalele IPsec funcționează în cinci etape:

Utilizare

Protocolul IPsec este utilizat în principal pentru a organiza tuneluri VPN. În acest caz, protocoalele ESP și AH funcționează în modul tunel. În plus, prin configurarea politicilor de securitate într-un anumit mod, protocolul poate fi folosit pentru a crea un firewall. Scopul unui firewall este că controlează și filtrează pachetele care trec prin el în conformitate cu regulile specificate. Este instalat un set de reguli și ecranul se uită la toate pachetele care trec prin el. Dacă pachetele transmise intră în domeniul de aplicare al acestor reguli, firewall-ul le procesează în consecință. De exemplu, poate respinge anumite pachete, oprind astfel conexiunile nesigure. Setând politica de securitate în mod corespunzător, puteți, de exemplu, să blocați traficul web. Pentru a face acest lucru, este suficient să interziceți trimiterea de pachete care conțin mesaje de protocol HTTP și HTTPS. IPsec poate fi folosit și pentru a proteja serverele - pentru aceasta, toate pachetele sunt aruncate, cu excepția celor necesare pentru executarea corectă a funcțiilor serverului. De exemplu, pentru un server Web, puteți bloca tot traficul, cu excepția conexiunilor prin portul TCP 80 sau prin portul TCP 443 în cazurile în care este utilizat HTTPS. IPsec este folosit aici pentru a asigura accesul utilizatorului securizat la server. Când se utilizează protocolul ESP, toate apelurile către server și răspunsurile acestuia sunt criptate. Cu toate acestea, mesajele clare sunt transmise în spatele gateway-ului VPN (în domeniul de criptare). Alte exemple de utilizare a IPsec:

Evaluarea protocolului

Protocolul IPSec a primit recenzii mixte de la experți. Pe de o parte, se observă că protocolul IPSec este cel mai bun dintre toate celelalte protocoale dezvoltate anterior pentru protejarea datelor transmise prin rețea (inclusiv PPTP dezvoltat de Microsoft). Potrivit celeilalte părți, există o complexitate excesivă și o redundanță a protocolului. Astfel, Niels Ferguson și Bruce Schneier în lucrarea lor „A Cryptographic Evaluation of IPsec” notează că au găsit probleme serioase de securitate în aproape toate componentele majore ale IPsec. Acești autori observă, de asemenea, că suita de protocoale necesită îmbunătățiri semnificative pentru ca aceasta să ofere un nivel bun de securitate. Lucrarea descrie o serie de atacuri care exploatează atât punctele slabe ale schemei generale de procesare a datelor, cât și punctele slabe ale algoritmilor criptografici.

Avantaje și dezavantaje

IPsec are următoarele avantaje:

  • Standard industrial deschis. IPSec oferă un standard industrial deschis ca alternativă la tehnologiile de securitate proprietare bazate pe IP. Acest lucru permite administratorilor de rețea să beneficieze de interoperabilitatea rezultată.
  • Transparenţă. IPSec există sub nivelul de transport, făcându-l transparent pentru utilizatori și aplicații, ceea ce înseamnă că nu este nevoie să modificați aplicațiile de rețea de pe desktopul utilizatorului dacă IPSec este implementat în firewall sau router.
  • Autentificare. Serviciile de autentificare puternică împiedică acceptarea datelor prin utilizarea identităților revendicate în mod fals.
  • Confidențialitate. Serviciile de confidențialitate împiedică accesul la datele sensibile în timp ce acestea sunt în tranzit între părți.
  • Verificarea originii și integrității datelor. Autentificarea și integritatea sursei de date sunt asigurate de valoarea HMAC (Hash Message Authentication Code) care este inclusă în fiecare pachet.
  • Recodificare dinamică. Recodificarea dinamică în timpul conexiunilor în curs elimină reconfigurarea manuală a cheilor secrete și ajută la protejarea împotriva descoperirii cheilor secrete.
  • Linkuri securizate de la capăt la capăt. IPSec pentru Windows 2000 oferă legături securizate end-to-end pentru utilizatorii din rețele private din același domeniu sau din orice domeniu de încredere din cadrul întreprinderii.
  • Management centralizat. Administratorii de rețea folosesc politicile IPSec pentru a asigura nivelul adecvat de securitate bazat pe utilizator, grup de lucru sau alte criterii. Managementul centralizat reduce costurile administrative.
  • Flexibilitate. Flexibilitatea IPSec pentru Windows 2000 vă permite să aplicați politici la nivelul întregii întreprinderi sau la o singură stație de lucru.

Deși IPSec este cea mai populară și probabil cea mai bună soluție pentru crearea de rețele private virtuale, există unele limitări. Dacă este utilizat în modul de transport, nu este exclusă posibilitatea unor atacuri din exterior, ceea ce este cauzat de unele limitări ale protocolului ISAKMP. Deturnarea sesiunii IPSec este destul de probabilă dacă nu este utilizat antetul de autentificare AH. Cu acest tip de atac, datele atacatorului pot fi inserate în informații utile transmise de exemplu, în cazul sistemelor Unix, este suficient să inserați comanda rm -R în flux, astfel încât destinatarului să ajungă să lipsească multe; chiar și toate fișierele de pe hard disk. Deoarece traficul IPSec este rutabil, diverse implementări practice IPSec pot fi supuse unui atac mai subtil - falsificarea rutei inițiale. Să facem o rezervare că acest tip de atac este posibil numai atunci când se folosește IPSec în modul de transport, dar dacă este folosit pentru a construi un tunel, toate informațiile de rutare în acest caz sunt criptate și acest tip de atac nu va avea succes.

AT&T Research observă că multe potențiale slăbiciuni ale IPSec sunt o consecință a unor deficiențe specifice ale algoritmilor de criptare utilizați într-o anumită implementare IPSec. Prin urmare, pe măsură ce fiabilitatea acestor algoritmi crește, IPSec poate deveni mult mai sigur.

În prezent, IPSec face parte din IPv6, dar nu IPv4. Deși, desigur, există și implementări IPSec pentru cea de-a patra versiune a protocolului IP. Implementarea IPv6 abordează unele dintre deficiențele IPSec care încă există în versiunea IPv4. De exemplu, câmpurile de fragmentare din antetul pachetului IPv4 pot fi potențial modificate, astfel încât atunci când operează IPSec în modul de transport, un atacator ar putea intercepta pachetul și schimba câmpul de fragmentare, apoi inserează datele necesare în fluxul transmis. În IPv6, routerele intermediare nu permit modificări ale câmpurilor de fragmentare.

Concurenți

Multe produse care pot utiliza interfața IPSec cu o tehnologie de criptare alternativă numită Secure Sockets Layer (SSL). Principala diferență dintre IPSec și SSL este că IPSec funcționează la nivel de rețea, securizând conexiunea la rețea de la un capăt la altul. SSL funcționează la nivel de aplicație, oferind protecție numai unei aplicații selectate, cum ar fi un browser web sau un program de e-mail. Deși atât IPSec, cât și SSL sunt concepute pentru a asigura confidențialitatea schimbului de informații, care se realizează în moduri complet diferite. SSL a fost dezvoltat de Netscape pentru a securiza traficul HTTP care trece printr-un program de browser. SSL este un protocol la nivel de sesiune și, în acest sens, este fără îndoială inferior IPSec, care vă permite să construiți un tunel permanent care este independent de traficul de rețea care trece prin acesta. Protocolul SSL se bazează pe un model client-server și este utilizat de obicei pentru securitatea gazdă la gazdă. Deoarece IPSec comunică la nivel de rețea, sunt posibile opțiuni precum subnet-to-subnet, network-to-network sau network-to-host. Acest lucru sugerează că IPSec permite rutarea, dar SSL nu.

Deși mulți utilizatori consideră că SSL și IPSec sunt tehnologii concurente, această afirmație nu este în întregime exactă, deoarece IPSec și SSL sunt menite să rezolve diferite probleme. În timp ce implementarea IPSec necesită o planificare avansată a infrastructurii, SSL simplifică mult lucrurile. De regulă, dacă atât clientul, cât și serverul sunt inițial capabili să lucreze cu SSL, atunci procedura de configurare a unei sesiuni securizate se reduce la un set extrem de banal de acțiuni, accesibil chiar și unui utilizator începător.

Comparație între IPSec și SSL

Mai jos este un tabel care compară IPSec și SSL.

Particularități IPSec SSL
„Independență hardware” da da
"Cod" Nu sunt necesare modificări ale aplicației. Poate necesita acces la codul sursă al stivei TCP/IP. Sunt necesare modificări ale aplicației. Pot fi necesare noi DLL-uri sau accesul la codul sursă al aplicației.
Protejați întregul pachet IP. Permite protecție pentru protocoale de nivel superior. Numai la nivel de aplicație.
Filtrarea pachetelor Pe baza antetelor autentificate, adreselor expeditorului și destinatarului etc. Simplu și ieftin. Potrivit pentru routere Bazat pe conținut și semantică de nivel înalt. Mai inteligent și mai complex.
Performanţă Mai puține schimbări de context și mișcare a datelor. Mai multe schimbări de context și mișcare a datelor. Blocurile mari de date pot accelera operațiunile criptografice și pot oferi o compresie mai bună.
Platforme Orice sistem, inclusiv routere În principal sisteme finale (clienți/servere), și firewall-uri.
Firewall/VPN Tot traficul este protejat Numai traficul la nivel de aplicație este protejat. ICMP, RSVP, QoS etc. poate fi neprotejat.
Transparenţă Pentru utilizatori și aplicații Doar pentru utilizatori.
Statusul curent Standard emergent. Folosit pe scară largă de browserele WWW, folosit și de alte câteva produse.

Surse

Legături

  • Unixwiz.net [Resursă electronică]: Un ghid ilustrat pentru IPsec / Data accesului: 19.12.2017. Mod de acces:

Protocolul ESP (Encapsulating Security Payload) asigură confidențialitatea datelor. În plus, vă permite să identificați expeditorul datelor, precum și să asigurați integritatea datelor și protecția împotriva reproducerii informațiilor.

Diferența dintre protocolul ESP și protocolul Authentication Header (AH) este că ESP realizează criptarea datelor. În același timp, ambele protocoale asigură identificarea, verificarea integrității și protecție împotriva reproducerii informațiilor. Când lucrează cu ESP, ambele sisteme finale folosesc o cheie partajată pentru a cripta și decripta datele.

Dacă criptarea și identificarea datelor sunt utilizate simultan, sistemul care răspunde mai întâi identifică pachetul, iar dacă identificarea are succes, apoi decriptează pachetul. Acest mod de procesare a pachetelor reduce încărcarea sistemului și reduce riscul ca securitatea să fie compromisă de un atac de tip denial of service.

Două moduri de a folosi ESP

Protocolul ESP poate fi utilizat în două moduri: modul de transmisie deschis și modul tunel. În modul de transmisie deschis, antetul ESP apare după antetul datagramei IP. Dacă datagrama are deja un antet IPSec, atunci antetul ESP este plasat înaintea acestui antet. Limitatorul ESP și datele de identificare, dacă există, sunt indicate după câmpul de date.

În modul de transfer deschis, antetul IP nu este identificat sau criptat. În acest caz, adresele specificate în antet pot fi interceptate în timp ce datagrama este transmisă prin rețea. Comunicarea în modul deschis necesită mai puține resurse decât în ​​modul tunel. Cu toate acestea, acest mod oferă un nivel mai scăzut de protecție. În cele mai multe cazuri, când se lucrează cu protocolul ESP, se folosește modul de transfer deschis.

În modul tunel, un nou antet IP este creat și devine antetul cel mai exterior al datagramei. După aceasta este antetul ESP și apoi datagrama în sine (antetul IP și datele). Remorca ESP și datele de identificare, dacă sunt prezente, sunt adăugate la sfârșitul câmpului de date. Dacă criptarea și autentificarea sunt utilizate simultan, ESP protejează complet datagrama originală, deoarece datagrama devine câmpul de date din noul pachet ESP. Noul antet IP nu este protejat. Când se stabilește o conexiune între gateway-uri, ESP ar trebui să fie utilizat în modul tunel.

Algoritm de securitate a informațiilor utilizat de ESP

Protocolul ESP folosește o cheie simetrică cu care datele sunt criptate și decriptate de sistemele finale. Înainte de a face schimb de date, expeditorul și destinatarul trebuie să convină asupra cheii pe care o vor folosi. Funcția VPN acceptă metodele de criptare DES, triple DES (3DES), RC5, RC4, AES sau AES-CBC.

Când utilizați algoritmul de criptare AES, puteți activa numărul de secvență extins (ESN). ESN vă permite să transferați cantități mari de date la viteze mari. Conexiunea VPN folosește numere de secvență pe 64 de biți în loc de numerele de 32 de biți prin IPSec. Utilizarea numerelor de secvență pe 64 de biți crește timpul înainte de a avea loc o modificare a cheii, ceea ce împiedică epuizarea grupului de numere de secvență și reduce consumul de resurse de sistem.

Internet Working Group (IETF) descrie în mod oficial algoritmii din următoarele RFC:

Acestea și alte RFC-uri pot fi găsite pe Internet la următorul site web: http://www.rfc-editor.org.

Protocolul ESP acceptă algoritmii de identificare HMAC-MD5, HMAC-SHA, HMAC-SHA-256 și AES-XCBC-MAC. Ambii algoritmi preiau date cu lungime variabilă și o cheie privată ca intrare și le folosesc pentru a produce date cu lungime fixă ​​(sau o valoare hash sau MAC). Dacă valorile hash calculate pentru două mesaje sunt aceleași, atunci există o probabilitate mare ca mesajele să fie aceleași.

Internet Working Group (IETF) descrie în mod oficial algoritmii din următoarele RFC:

Aceste RFC-uri pot fi vizualizate pe următorul site web: http://www.rfc-editor.org.