| CATEGORII DOCUMENTE |
Virtual Private Network (VPN)
Voi prezenta in aceasta lucrare metode implementabile in practica de realizare a asa numitelor Retele Virtuale Private (Virtual Private Networks), pe scurt VPN si, de asemenea, chestiuni teoretice, de amanunt, ale tehnologiilor folosite.
In pofida numelui, nu e nimic virtual in aceste solutii, ele sunt solutii reale. Cuvantul virtual se refera la faptul ca nu se construiesc retele noi pentru transportul datelor, ci se formeaza pe suportul deja disponibil, pe stiva de protocoale IP ce formeaza Internetul. Doar ca din punct de vedere logic, se formeaza retele independente, ale caror noduri sunt strict definite.
Astfel, un PC din Bucuresti, unul din Paris si unul din New York, care, fiind conectate la internet, adica avand fiecare un IP public (rutabil), pot forma o retea virtuala in care datele schimbate de ele, sunt indescifrabile pentru restul lumii. Mai exact, chiar daca am avea controlul unui router prin care trec pachetele de date intre 2 din calculatoarele membre ale retelei virtuale, interceptandu-le nu intelegem absolut nimic.
Ca exemplu practic, imaginati-va o companie multinationala cu un sediu central in Bruxel si cu reprezentante in Los Angeles si mai multe tari din Europa. Cum si-ar putea organiza activitatea aceasta companie? Pana nu demult erau cateva variante: posta clasica, fax, e-mail. Nevoia de comunicare a crescut foarte mult in ultimul timp insa, aceste solutii devenind insuficiente.
Astazi, se folosesc solutii complexe gen ERP (Enterprise Resource Planning) sau CRM (Customer Relationship Management). Aceste solutii au urmatoarea structura simplificata: o baza de date, o aplicatie care lucreaza cu baza de date si utilizatori (clienti) care sunt partea finala a acestui lant (Figura 1). Nici o problema atunci cand toate partile se afla in aceeasi retea locala, separata de internet, nefiind posibila scurgerea de date. Daca, insa, analizam cazul de mai sus, al companiei cu sediul central in Bruxel si cu reprezentante in Los Angeles si mai multe tari din Europa, situatia se complica. Am vrea ca utilizatori din reprezentantele firmei sa poata comunica cu baza de date centralizata care se gaseste la sediul central. Datele care se transfera sunt confidentiale si este inacceptabil ca persoane din afara organizatiei sa poata avea acces la ele. Am avea, asadar, nevoie de canale de comunicatie dedicate la care sa aiba acces numai filialele companiei. Exista astfel de canale, asa numitele linii inchiriate, oferite de obicei de operatorii de telefonie. Problema acestor linii inchiriate este ca sunt scumpe si, mai mult, nu sunt flexibile. Ba chiar, la un moment dat, ar putea exista teama ca datele sunt receptionate de catre operatorul de telefonie. Si aici ne punem intrebarea: nu am putea sa folosim canale deja existente, cum ar fi legatura internet deja prezenta pentru a transmite aceste date, dar intr-un mod securizat? Ba da, am putea! Creem la sediul central al companiei un punct de acces, adica un server configurat in asa fel incat sa accepte conexiuni doar de la filialele firmei (autentificare) si sa cripteze continutul datelor transmise (criptare).
Exista doua tipuri mai importante de protocoale pentru VPN: PPTP si IPsec.
PPTP (Point to Point Tunnelling Protocol) a fost folosit indeosebi de Microsoft. Avea la baza urmatorul procedeu: se facea un handshake pe TCP port 1723 si, dupa o autentificare corecta se trecea la encapsularea pachetelor in protocolul GRE (numarul 47). Sunt probleme insa cu protocolul GRE, deoarece majoritatea gateway‑urilor care fac NAT nu "stiu" sa translateze si acest protocol (stiu doar UDP si TCP).
IPsec in schimb, poate fi folosit si in situatii cand este implicat NAT‑ul, folosindu‑se pentru encapsulare protocoalele UDP sau TCP (Cisco foloseste, de obicei TCP portul 10000).
Figura
Inchei aceasta introducere prin a mentiona ca pe parcursul lucrarii voi folosi termeni specifici IPsec in forma lor nativa din limba engleza, evitand astfel confuzii de termeni si licente de traducere.
2.1. Ce este IPsec?
Internet Protocol Security (IPsec) este o colectie de standarde care contribuie la asigurarea comunicatiilor sigure din punct de vedere autentificare si criptare pentru retele de tip Internet Protocol (IP). IPsec suporta integritatea, confidentialitatea, autentificarea originii si replay protection.
IPsec ofera servicii de criptare si autentificare la nivelul IP din modelul TCP/IP al stivei de protocoale. Lucrand la acest nivel, poate proteja orice tip de trafic transportat peste IP, spre deosebire de alte metode de criptare care, in general, protejeaza doar un protocol de nivel mai inalt: PGP pentru e-mail, SSH pentru remote login, SSL pentru web si asa mai departe.
IPsec poate fi folosit pe orice masina care are instalat protocolul IP. Gateway-uri dedicate IPsec pot fi instalate oriunde este nevoie pentru a proteja traficul. IPsec poate, de asemenea, rula pe routere, pe firewall-uri, pe diferite servere de aplicatii, ca si pe statii de lucru ale utilizatorului final sau laptopuri.
Sunt folosite trei protocoale pentru IPsec: ESP (Encapsulating Security Payload), optional AH (Authentication Header) si IKE (Internet Key Exchange).
2.2. Avantaje / Dezavantaje
Avantajele criptarii direct de la nivelul IP sunt numeroase. IPsec este "cel mai general mod" de a oferi servicii de securitate pentru Internet.
Protocoalele de nivel mai inalt protejeaza un singur protocol, de exemplu PGP protejeaza doar e‑mailul.
Serviciile de securitate de nivel mai jos (hardware de obicei) protejeaza un singur mediu de transmitere a datelor; de exemplu o pereche de cutii de criptare la capetele unei linii fac inutil ascultarile de linie daca cel care asculta nu poate sa sparga algoritmul de criptare.
IPsec, in schimb, poate proteja orice protocol mai sus de IP si orice mediu peste care functioneaza IP. Mai exact, poate proteja o mixtura de protocoale de aplicatie care ruleaza peste o combinatie complexa de medii. Aceasta este si cazul internetului. IPsec este singura solutie generala.
IPsec poate, de asemenea, sa ofere anumite servicii in background, fara ca utilizatorii sa constientizeze acest lucru. Pentru a folosi PGP si semnaturi pentru e-mail, de exemplu, utilizatorul trebuie cel putin sa: memoreze o parola, sa o tina sigura, sa urmareasca proceduri pentru a valida cheile corespondentilor.
Sistemul poate fi proiectat astfel incat sarcina ce cade in seama utilizatorilor sa fie cat mai mica.
IPsec e construit pentru a securiza legaturi IP intre masini. O face foarte bine, dar e important de tinut minte ca sunt multe lucruri pe care nu le face. Cele mai importante limitari sunt:
IPsec nu poate fi sigur daca sistemul pe care e instalat nu e sigur;
IPsec nu este end-to-end
Autentifica masini, nu utilizatori
Nu opreste atacuri tip Denial of Service
Nu opreste analizoarele de trafic (se pot trage anumite concluzii chiar daca nu se pot decripta pachetele, cum ar fi adresa gateway sursa si destinatie, dimensiunea pachetelor).
Avantajul principal al IPsec este ca ofera protectie la tot ce este trimis prin protocolul IP. IPsec creeaza tunele securizate prin retele nesigure. Locatiile conectate prin aceste tunele formeaza VPN-uri (Virtual Private Networks).
2.3. Aplicatii ale IPsec
Pentru ca IPsec opereaza la nivelul Network, sau Internet, in modelul TCP/IP, este foarte flexibil si poate fi folosit pentru a securiza aproape orice fel de trafic. Doua aplicatii, totusi, sunt extrem de raspandite:
IPsec este inclus in routere, in produse tip firewall si in majoritatea sistemelor de operare, in principal pentru a suporta aceste aplicatii.
Un VPN permite ca doua retele sa comunice in siguranta, atunci cand singura conexiune dintre ele este o a treia retea, care insa nu poate fi considerata sigura din punct de vedere al confidentialitatii datelor. Solutia VPN consta in plasarea a cate unui nod (gateway) securizat intre retelele care doresc sa comunice si reteaua nesigura (internetul). Gateway-urile cripteaza pachetele care intra in reteaua nesigura si le decripteaza pe cele care ies, creand un tunel privat prin reteaua nesigura.
Daca criptografia este puternica, implementarea este atenta, si administrarea nodurilor tip gateway e competenta, atunci se poate avea incredere in securitatea tunelului. Cele doua retele, apoi, se comporta ca o singura retea privata, mai mare, care are unele din legaturi ca tunele criptate printr‑o retea nesigura. VPN-urile reale sunt, adeseori, mai complexe. O organizatie poate avea, la un moment dat, 50 de filiale, plus cativa parteneri si clienti, cu care trebuie sa comunice date confidentiale. O alta organizatie ar putea sa aiba 5000 de magazine, sau 50000 de puncte de vanzare. Reteaua nesigura nu trebuie neaparat sa fie Internetul. Aceleasi probleme se ivesc intr‑o retea de corporatie sau institutionala atunci cand doua departamente vor sa comunice privat intre ele.
Din punct de vedere administrativ, simplitatea majoritatii VPN‑urilor este ca parti mari ale lor sunt statice, adica se cunoaste adresa IP a majoritatii nodurilor implicate. Mai important, se stie ca acestea nu se vor schimba. Acest lucru simplifica mult munca de administrare.
Asa numitul Road Warrior este un utilizator mobil care se conecteaza la un server de obicei de pe un laptop, pentru a avea acces securizat la resursele din spatele acelui server.
2.4. Protocoalele ESP si AH
In versiunea 4 a Protocolului Internet (IPv4), exista un camp de 8 biti numit "Protocol", care identifica protocolul de nivel urmator. Lista completa a protocoalelor este urmatoarea:
0 HOPOPT IPv6 Hop-by-Hop Option [RFC1883]Majoritatea serviciilor de securitate sunt oferite prin folosirea a doua protocoale de securizare a traficului, Authentication Header (AH) si Encapsulating Security Payload (ESP), si prin folosirea unor proceduri si protocoale de management criptografic al cheilor. Se observa din lista de mai sus ca ESP si AH, respectiv numarul 50 si 51 sunt, la fel ca TCP sau UDP (numerele 6 si 17) subprotocoale ale Protocolului Internet (IP).
Atunci cand IPsec este corect implementat el nu afecteaza negativ utilizatorii, hosturile sau alte noduri din Internet care nu folosesc IPsec pentru protectia traficului. Protocoalele de securitate IPsec (AH, ESP si mai putin IKE) sunt gandite de a fi independente de algoritmul de criptare folosit. Aceasta modularitate permite selectarea diferitelor seturi de algoritmi de criptare care sunt potriviti pentru aplicatia data, fara a afecta celelalte componente ale implementarii. De exemplu, comunitati diferite de utilizatori pot alege, la un moment dat, diferiti algoritmi de criptare. Este, totusi, specificata o multime data de algoritmi de criptare utilizabili pentru AH si ESP pentru a usura interoperabilitatea globala in Internet. Utilizarea acestor algoritmi de criptare, complementar cu protectia traficului IPsec si protocoalele de management ale cheilor, are ca scop de a permite programatorilor de sisteme si de aplicatii sa dezvolte tehnologii de securitate criptografica la nivelul Internet (in topologia TCP/IP) de o inalta calitate.
O implementare IPsec opereaza intr‑un host, ca gateway de securitate, sau ca un device independent, permitand protectia traficului IP. Un gateway de securitate este un sistem intermediar care are implementat IPsec, de exemplu un firewall sau un router cu capacitati de IPsec. Acest IPsec creeaza o granita intre interfetele protejate si cele neprotejate, pentru un nod sau o retea intreaga:
Figura
In aceasta diagrama, "neprotejat" se refera la o interfata care poate fi descrisa ca si "neagra", sau "cifrata", iar "protejat" se refera la o interfata care poate fi denumita si "rosie", sau "plaintext". Interfata protejata este de obicei interna, de exemplu intr‑o implementare IPsec pe un gateway, interfata protejata ar fi legatura catre o interfata soket accesibila doar sistemului de operare. Voi folosi termenul de "inbound" pentru traficul care intra intr‑un nod implementat cu IPsec prin interfata neprotejata. Analog, termenul "outbound" va referi traficul care intra in nod prin interfata protejata si urmeaza a fi rutat prin interfata neprotejata, sau trafic initiat de pe localhost catre interfata neprotejata. O implementare IPsec poate suporta mai cel putin o interfata pe fiecare din cele doua parti ale granitei pe care o stabileste.
IP Authentication Header (AH), ofera integritatea datelor si autentificarea originii datelor, cu posibilitati optionale de anti-replay. Protocolul Encapsulating Security Payload (ESP) ofera aceleasi servicii ca AH si, in plus confidentialitate prin criptare. Folosirea ESP‑ului doar pentru criptare (confidentialitate) nu este recomandata. Atat ESP cat si AH ofera controlul accesului, impus prin distribuirea de chei criptografice si prin managementul traficului. Aceste protocoale pot fi aplicate separat sau impreuna pentru a oferi servicii de securitate in IPv4 si IPv6. Totusi majoritatea cerintelor de securitate pot fi indeplinite prin folosirea doar a ESP. De aceea, incepand din acest punct ne vom referi numai la ESP, lasand la o parte AH.
ESP suporta doua moduri de folosire: modul transport si modul tunel. In modul transport se ofera protectie in principal pentru protocoalele de nivel mai inalt, in comunicatia dintre cele doua hosturi care discuta; in modul tunel, ESP este aplicat pachetelor IP care urmeaza sa intre in tunel, astfel asigurandu‑se comunicatie securizata intre subretelele ce se afla in spatele gateway‑urilor cu IPsec. Vom discuta mai jos diferentele dintre cele doua moduri.
IPsec permite utilizatorului sa controleze granularitatea serviciului de securitate. De exemplu, se poate crea un singur tunel criptat pentru a transporta tot traficul dintre doua noduri de securitate, dar, in acelasi timp se poate crea cate un tunel separat pentru fiecare pereche de noduri care comunica.
Pentru ca majoritatea serviciilor de securitate pe care le ofera IPsec folosesc chei criptografice, IPsec se bazeaza pe un set separat de mecanisme pentru a pozitiona aceste chei acolo unde trebuie. Pentru a securiza comunicatii bidirectionale intre doua sisteme cu IPsec trebuie sa existe o pereche de SA‑uri (Security Associations), cate una pe fiecare directie. IKE creeaza in mod explicit perechi SA ca urmare a acestei cerinte.
Headerul ESP ofera un mix de servicii de securitate pentru IPv4 si IPv6. ESP poate fi aplicat singur, in combinatie cu AH, sau recursiv, de exemplu prin folosirea modului tunel. Serviciile de securitate pot fi oferite intre o pereche de host‑uri care comunica, intre o pereche de gateway‑uri securizate, sau intre un gateway securizat si un host.
Headerul ESP este introdus dupa headerul IP si inainte de headerul protocolului mai inalt (modul transport), sau inaintea unui header ip incapsulat (modul tunel). ESP este folosit pentru a oferi confidentialitate, autentificarea originii datelor, integritate fara conexiune, servicii de anti‑raspuns (anti‑replay - o forma de integritate secventei partiala), si confidentialitatea fluxului de traficm dar limitat. Serviciile oferite depinde de optiunile selectate in momentul in care se stabileste SA‑ul si de felul implementarii. Confidentialitatea poate fi aleasa independent de celelalte servicii. Totusi, folosirea confidentialitatii (criptarea) fara integritate/autentificare (fie cu ESP sau separat cu AH), poate pune traficul in pericolul de a fi atacat si de a‑i fi subminat serviciul de confidentialitate. Autentificarea originii datelor si integritatea fara conexiune sunt servicii care vin impreuna (numite "autentificare") si sunt oferite ca o optiune impreuna cu confidentialitatea. Serviciul anti‑raspuns poate fi ales numai daca se alege si autentificarea originii datelor, iar alegerea sa depinde numai de destinatie. Cu toate ca apelurile implicite catre sursa de a incrementa Numarul de Secventa folosit pentru anti‑raspuns, serviciul este efectiv doar daca destinatia verifica acest Numar de Secventa).
Confidentialitatea fluxului de date necesita alegerea modului tunel de transmitere, si este cea mai eficienta daca se implementeaza intr‑un gateway, acolo unde se pot ascunde sursele si destinatiile pachetelor de date. A se lua aminte ca, in pofida faptului ca atat confidentialitatea cat si autentificarea sunt optionale, cel putin una dintre ele trebuie aleasa.
Forma pachetului ESP este urmatoarea:
Figura
Headerul protocolului, care se afla imediat inaintea headerului ESP, va contine valoarea 50 in campul Protocol. Voi defini in continuare campurile specifice acestui header. "Optional" inseamna ca acel camp este omis daca optuinea nu este selectata. Daca o optiune este selectata sau nu, se defineste la stabilirea SA‑urilor. Asadar, formatul pachetelor ESP pentru o SA data este fix, pe toata durata SA. In contrast, campurile obligatorii sunt prezente intotdeauna in formatul pachetului ESP, pentru toate SA‑urile.
SPI (Security Parameters Index) este o valoare aleatoare pe 32 de biti care, in combinatie adresa IP a destinatiei si protocolul ESP, identifica in mod unic SA‑ul pentru aceasta datagrama. Multimea de valori SPI din gama de la 1 pana la 255 sunt rezervate de IANA (Autoritatea pentru numere asignate in Internet) pentru utilizare ulterioara; o valoare rezervata SPI nu ar fi asignata de IANA decat daca folosirea valorii SPI asignate e specificata in vreun RFC (Request For Comment). SPI este ales in mod normal de sistemul destinatie odata cu stabilirea unei SA. Campul SPI este obligatoriu.
O valoare de 0 (zero) pentru SPI este rezervata pentru uz local, specific si nu trebuie trimisa mai departe "pe fir". De exemplu, o implementare de management al cheilor poate folosi valoarea zero pentru SPI pentru a specifica cum "ca nu exista nici o SA" pe perioada in care implementarea IPsec cere de la sistemul de management sa se stabileasca o noua SA, dar SA nu a fost inca stabilita.
Numarul de secventa este un camp de 32 de biti care contine un contor monoton crescator. Este obligatoriu si totdeauna prezent chiar daca destinatia nu alege sa activeze serviciul anti‑raspuns pentru o SA anume. Procesarea campului numar de secventa este la alegerea destinatiei, adica sursa trebuie sa transmita intotdeauna acest camp, iar destinatia nu e obligata sa‑l ia in seama.
Contorul sursei si a destinatiei sunt initializate la zero atunci cand se stabileste SA, primul pachet trimis folosind o SA data va avea numarul de secventa 1. Daca serviciul anti‑raspuns este activat, numarul de secventa transmis nu trebuie sa se repete. Astfel, contorul sursei si destinatiei trebuie resetate (prin crearea unei noi SA, deci o noua cheie) inainte de transmiterea celui de‑al 2^32 pachet din SA.
Campul Payload Data este un camp de marime variabila continand datele descrise de campul Next Header. Campul Payload Data este obligatoriu si are un numar intreg de octeti ca lungime. Daca algoritmul folosit la criptarea datelor necesita date de sincronizare a criptografiei, de exemplu un vector de initializare (IV - Initialization Vector), atunci aceste date pot fi purtate in mod explicit in campul Payload. Orice algoritm de criptare care necesita astfel de date de sincronizare explicite, per pachet, trebuie sa indice lungimea, o structura pentru aceste date, si locatia lor ca parte a unui RFC care sa specifice cum este folosit algoritmul cu ESP. Daca astfel de date de sincronizare sunt implicite, algoritmul folosit pentru obtine datele trebuie sa faca parte dintr‑un RFC.
Completarea (Padding). Mai multi factori necesita sau motiveaza folosirea campului de completare:
- daca un algoritm de criptare este folosit si cere ca textul necriptat sa fie multiplu al unui numar de octeti, de exemplu marimea blocului unui cifru bloc, campul de completare este folosit pentru a umple textul plain (constand din campurile Payload Data, Pad Length si Next Header, cat si completarea) pana la dimensiunea ceruta de algoritm.
- completarea mai poate fi necesara, indiferent de necesitatile algoritmului de criptare, pentru a fi siguri ca textul criptat rezultat se termina intr‑o limita de 4 octeti. Adica campurile Pad Length si Next Header trebuie sa fie aliniat la un cuvant de 4 octeti, asa cum este ilustrat in formatul de pachet ESP de mai sus, pentru a asigura ca campul Authentication Data, daca este prezent, este aliniat la o limita de 4 octeti la randul sau.
- completarea peste necesarul algoritmului sau alinierii poate fi folosita pentru a ascunde lungimea reala a datelor utile, in vederea unei confidentialitati partiale a fluxului de trafic. Totusi, completari de acest gen au dezavantaje referitoare la latimea de banda consumata si deci trebuie analizata cu grija.
Sursa poate adauga 0‑255 octeti de completare. Includerea campului Padding intr‑un pachet ESP este optionala, dar toate implementarile trebuie sa suporte generarea si consumarea completarilor.
a. Pentru a ne asigura ca bitii ce urmeaza a fi criptati sunt multipli de marimea blocului algoritmului folosit, calcularea completarii se aplica doar datelor utile (Payload Data), in afara de campurile IV, Pad Length si Next Header.
b. In scopul de asigura ca datele de autentificare (Authentication Data) sunt aliniate la 4 octeti, calculul completarii se aplica datelor utile inclusiv ctmpurile IV, Pad Lengthsi Next Header.
Daca octetii de completare sunt necesari, dar algoritmul de criptare nu specifica ce continut trebuie sa aiba aceasta completare, atunci se va folosi urmatorul model implicit. Octetii de completare sunt initializati cu o multime de valori intregi fara semn pe un byte. Primul octet de completare adaugat la plaintext este numerotat 1, urmatorii octeti de completare formand un sir crescator: 1, 2, 3, Cand se foloseste acesta schema de completare, destinatia ar trebui sa verifice campul Padding.
Orice algoritm de criptare care necesita o alta schema de completare in afara de cea implicita descrisa mai sus, trebuie sa specifice continutul completarii (de exemplu zerouri sau numere aleatorii), si orice mecanism de procesare la destinatie al acestor octeti de completare, intr‑un RFC care sa specifice cum este folosit algoritmul cu ESP. In aceste circumstante, continutul campului Padding va fi determinat de algoritmul si modul de criptare ales si definit in RFC. RFC‑ul corespunzator poate specifica cum ca destinatia trebuie sa verifice campul de completare sau ca destinatia trebuie sa informeze sursele cum va procesa acest camp.
Campul Pad Length indica numarul de octeti de completare care il urmeaza imediat. Plaja de valori posibile este 0‑255, unde o valoare de zero indica faptul ca nu sunt prezenti octeti de completare. Acest camp este obligatoriu.
Next Header este un camp pe 8 biti care identifica tipul de date continute in campul Date Utile (Paylod Data), de exemplu, un header extensie in IPv6 sau un identificator de protocol de nivel mai inalt in IPv4. Valoarea acestui camp este aleasa din multimea de numere de protocol IP enumerata mai sus. Acest camp este, de asemenea, obligatoriu.
Date de Autentificare (Authentication Data) este un ctmp de lungime variabila care contine o valoare de verificare a integritatii (ICV - Integrity Check Value) calculata in functie de pachetul ESP, mai putin Authentication Data. Lungimea acestui camp e specificata de functia de autentificare aleasa. Campul este optional, si este inclus numai daca serviciul de autentificare a fost ales pentru SA in cauza. Algoritmul de autentificare trebuie sa specifice lungimea lui ICV si regulile de comparatie si pasii de procesare pentru validare.
Formatul unui pachet IPv4 inainte si dupa aplicarea ESP este (Figura 4):
Figura
Pentru IPv6 avem (Figura 5)
Figura
2.5. IKE - protocol de managementul cheilor
Atat Oakley cat si SKEME (vezi Anexa A) definesc o metoda de a stabili o sesiune de schimbare de chei autentificata. Aceasta include construirea payload‑urilor, purtarea payload‑urilor de informatii, ordinea in care sunt procesate si cum sunt folosite. In timp ce Oakley denumeste "moduri", ISAKMP defineste "faze" relatia dintre cele doua este directa si IKE prezinta schimburi diferite ca moduri care opereaza in una sau doua faze.
Faza 1 este aceea in care cele doua parti ISAKMP stabilesc un canal sigur si autentificat prin care sa comunice. Acesta se numeste ISAKMP Security Association (SA). "Main Mode" si "Aggressive Mode" se folosesc numai in faza 1.
Faza 2 este cea in care sunt "negociate" SA‑uri pentru servicii ca IPsec sau orice alt serviciu care necesita chei si/sau negociere de parametri. "Quick Mode" realizeaza un schimb de faza 2 si trebuie folosit numai in faza 2.
"New Group Mode" nu este nici cafaza 1 nici ca faza 2. Urmeaza dupa faza 1, dar are ca scop stabilirea unui nou grup care sa fie folosit in negocieri ulterioare. Se foloseste numai dupa faza 1.
ISAKMP SA este bidirectionala, adica, odata stabilita, fiecare parte poate initia schimburi Quick Mode, Informational sau New Group
Prin folosirea fazelor ISAKMP, o implementare poate atinge viteze mare de negociere a cheilor. O singura negociere de faza 1 poate fi folosita pentru mai multe negocieri de faza 2. In pus, o singura negociere de faza 2 poate ere mai multe SA‑uri. Cu aceste optimizari, o implementare poate avea mai putin de un ciclu per SA si la fel de bine mai putin de o exponentiere Diffie‑Hellman per SA. Main Mode pentru faza 1 ofera protejarea identitatii. Atunci cand protectia identitatii nu este necesara, "Aggressive Mode" poate fi folosit pentru a reduce ciclurile si mai mult.
Urmatoarele atribute sunt folosite de IKE si sunt negociate ca parte din ISAKMP SA:
algoritmul de criptare
algoritmul de hash
metoda de autentificare
informatii despre grupul peste care sa se faca Diffie-Hellman
Toate aceste atribute sunt obligatorii si trebuie negociate. In plus, se poate, optional, negocia o functie pseudo‑aleatoare ("prf")
Grupul Diffie‑Hellman trebuie sa fie specificat sau folosind o descriere de grup definita, sau definind toate atributele unui grup. Atributele de grup nu trebuie sa fie oferite in conjunctie cu un grup definit anterior.
Implementarile IKE suporta urmatoarele standarde:
MD5 si SHA
Autentificare prin preshared keys
MODP peste grupul implicit numarul unu.
3DES pentru criptare
RSA - standardul pentru semnaturi digitale
Sunt doua metode principale folosite pentru a stabili un schimb de chei autentificat: Main Mode si Aggresive Mode. Fiecare genereaza material de schimb autentificat dintr‑un schimb Diffie‑Hellman temporar.
Payload‑ul SA trebuie sa preceada toate celelalte payload‑uri intr‑un schimb de faza 1. Exceptand cazurile cand este specificat altfel, nu sunt cerinte pentru payload‑urile ISAKMP din orice mesaj de a fi intr‑o ordine stabilita.
Main Mode este o instantiere a Schimbului Protejat de Identitate (Identity Protect Exchange) ISAKMP: primele doua mesaje negociaza regula; urmatoarele doua schimba valorile publice Diffie‑Hellman si datele ajutatoare, necesare schimbului; ultimele doua mesaje autentifica schimbul Diffie‑Hellman. Metoda de autentificare negociata ca parte din schimbul initial ISAKMP influenteaza construirea payload‑urilor, dar nu si scopul lor. XCHG pentru Main Mode este ISAKMP Identity Protect.
In mod similar, Aggressive Mode este o instantiere a Schimbului Agresiv (Agressive Exchange) ISAKMP. Primele doua mesaje negociaza regula, schimba valori publice Diffie‑Hellman si date auxiliare necesare schimbului si identitati. In plus, al doilea mesaj autentifica partea care a raspuns (responder). Al treilea mesaj autentifica initiatorul si ofera dovada participarii la schimb. CHG pentru Aggressive Mode este ISAKMP Aggressive. Ultimul mesaj poate sa nu mai fie trimis sub protectia ISAKMP SA, permitand fiecarei parti sa amane exponentierea, daca se doreste, pana cand negocierea acestui schimb se termina.
Schimburile in IKE nu sunt infinite si au un numar fixat de mesaje. Primirea unei cereri de certificat nu creste numarul de mesaje transmise sau asteptate.
Negocierea SA‑urilor este limitata in Aggressive Mode. Datorita cerintelor de construire a mesajului, grupul in care schimbul DH are loc nu poate fi negociat. In plus, diferite metode de autentificare pot sa constranga mai mult negocierea atributelor. De exemplu, autentificarea cu criptare tip cheie publica nu poate fi negociata si atunci cand se foloseste metoda revizuita de criptare cu cheie publica pentru autentificare, codul (cipher) si hash‑ul nu pot fi negociate.
Main Mode, Aggressive Mode si Quick Mode realizeaza negocierea SA‑urilor
Ceea ce ofera o SA ia forma unor payload‑uri Transform incapsulate in payload‑uri Proposal, incapsulate in payload‑uri Securitz Association. Daca sunt facute mai multe oferte pentru schimburile de faza 1, trebuie sa ia forma mai multor payload‑uri Transform pentru un singur payload Proposal intr‑o singur payload de SA.
Urmatoarea diagrama (Figura 6), ilustreaza payload‑urile schimbate intre doua parti in primul schimb dus‑intors:
Figura
Primitorul alege si returneaza o propunere de transformare (atributele ISAKMP SA). Al doilea schimb contine urmatoarele payload‑uri (Figura 7).
Figura
Faza 2 din Quick Mode:
Figura
Consideratii de securitate
Am discutat mai sus un protocol hibrid, care combina parti din Oakley si din SKEME cu ISAKMP pentru a negocia si obtine keying material pentru asociatii de securitate, totul intr‑o maniera autentificata.
Confidentialitatea este asigurata prin folosirea unui algoritm de criptare negociat de parti. Autentificarea este asigurata de folosirea unei metode negociate: un algoritm tip semnatura digitala, un algoritm tip cheie publica care suporta criptare, sau o fraza secreta (preshared key). Confidentialitatea si autentificarea acestui schimb sunt la fel de bune cat atributele negociate ca parte din asociatia de securitate ISAKMP.
Re‑keyingul repetat folosind Quick‑Mode poate consuma entropia secretului partajat Diffie‑Hellman. Perfect Forward Secrecy (PFS) al keying material si al identitatilor este posibil cu acest protocol.
2.6. FreeS/WAN - IPsec pentru kernelul 2.4 si 2.6
FreeS/WAN este implementarea Linux a protocoalelor IPsec. Sunt folosite doua protocoale, ESP si IKE, prezentate in capitolele anterioare.
Aceasta implementare are trei parti principale:
Pe scurt, FreeS/WAN urmeaza urmatorii pasi la stabilirea unei conexiuni:
Ambele faze IKE sunt repetate periodic pentru a automa renegocierea (re‑keying)
Criptografia are un trecut lung si fascinant. Cea mai completa relatare atehnica despre acest subiect a facut‑o Kahn in lucrarea "The CodeBreakers". Aceasta carte urmareste criptografia de la utilizarea ei initiala si limitata de catre egipteni acum 4000 de ani, pana in secolul 20 unde a jucat un rol crucial in rezultatul celor doua razboaie mondiale.
Proliferarea computerelor si a sistemelor de comunicatie in 1960 a adus o cerere din sectorul privat pentru metode de protejarea informatiei in format digital si pentru a oferi servicii de securitate. Incepand cu rezultatele lui Feistel la IBM la inceputul anilor 70 si culminand in 1977 cu adoptarea lor ca Standard al Procesarii Informatiilor Federale ale Statelor Unite pentru criptarea informatiilor non‑secrete, DES (Data Encryption Standard) este cel mai bine cunoscut mecanism de criptare cunoscut in istorie.
Cea mai importanta descoperire in istoria criptografiei a venit in 1976 cand Diffie si Hellman a publicat lucrarea "Noi Directii in Criptografie". Aceasta lucrare a introdus conceptul revolutionar de criptografie cu cheie publica si a oferit si o metoda noua si ingenioasa pentru schimbul de chei, a cui securitate e bazata dificultatea rezolvarii problemei logaritmului discret. Cu toate ca autorii nu au avut o realizare practica a schemei de criptare cu cheie publica la momentul acela, ideea era clara si genera un interes deosebit. In 1978 Rivest, Shamir si Adleman au descoperit prima schema practica de criptare cu cheie publica si semnatura, numita acum RSA. Aceasta schema e bazata pe o alta problema matematica grea, dificultatea de rezolvare a factorizarii intregilor mari. Aceasta aplicare a unei probleme grele de matematica in criptografie a revitalizat eforturile de a gasi noi metode eficiente de factorizare. Anii 80 au adus avansari majore pe aceasta tema, dar nimic care sa dovedeasca RSA ca nesigur.
Una dintre cele mai importante contributii oferite de criptografia cu cheie publica este semnatura digitala. In 1991 a fost adoptat primul standard international pentru semnaturi digitale (ISO/IEC 9796). E bazat pe schema cheie publica a RSA. In 1994 guvernul Statelor Unite a adoptat standardul semnaturii digitale (Digital Signature Standard), un mecanism bazat pe schema cheie publica ElGamal.
Cautarea de noi scheme de cheie publica, imbunatatiri ale mecanismelor de criptare existente si dovezi de securitate continua intr‑un ritm rapid. Diferite standarde si infrastructuri care tin de criptografie sunt adoptate. Produse care ofera securitate sunt dezvoltate pentru a adresa nevoile de securitate ale unei societati informatizate intensiv.
Pentru a introduce criptografia, este necesara o intelegere a problemelor legate de securitatea informatiilor in general, este necesara. Securitate informatiei se manifesta in multe feluri, in functie de situatie si de necesitati. Indiferent de partile implicate, pana la punct, toate partile unei tranzactii trebuie sa aiba incredere ca anumite obiective asociate cu securitatea informatiei au fost indeplinite. (Tabelul 1)
|
confidentialitate |
Pastrarea informatiei secreta pentru toti, exceptand cei autorizati sa o inteleaga |
|
integritatea datelor |
Asigurarea ca informatia nu a fost modificata de metode neautorizate sau necunoscute |
|
autentificarea sau identificarea partilor |
Confirmarea identitatii unei parti (ex: persoana, computer, carte de credit etc.) |
|
autentificarea mesajului |
Confirmarea sursei informatiilor, cunoscut si sub numele de autentificarea originii |
|
semnatura |
O metoda de a lega informatia de o entitate |
|
autorizare |
Permiterea unei alte parti de a face ceva sau de a fi ceva |
|
validare |
O metoda de a oferi oportunitate autorizarii de a folosi sau manipula informatii sau resurse |
|
control acces |
restrictionarea accesului resurselor doar pentru entitati privilegiate |
|
certificare |
aprobarea de catre o entitate acreditata. |
|
timestamping |
inregistrarea timpului crearii sau duratei existentei informatiei |
|
nota primire |
instiintarea ca informatia a fost primita |
|
confirmare |
instiintarea ca serviciile au fost oferite. |
|
posesiune |
o metoda de a oferi unei entitati dreptul de a folosi sau de a transfera o resursa catre ceilalti. |
|
anonimitate |
ascunderea identitatii unei parti. |
|
non‑repudiere |
prevenirea negarii angajamentelor sau actiunilor precedente |
|
revocare |
retragerea certificarii sau autorizarii. |
Tabel
3.1. Diferente
Vom alege un exemplu simplu pentru a evidentia diferenta dintre termeni. Fie un server de mail acesibil prin web, aplicatie tipica numita webmail. Pentru a‑si citi mesajele din casuta de mail electronica, un utilizator deschide un browser web si tasteaza adresa serverului sau de mail, de exemplu https://webmail.server.net. In acest moment ii apare o pagina care cere niste date de identificare. Utilizatorul nostru, in schimb, este un pic mai circumspect si vrea sa fie sigur ca nu trimite nume de utilizator si parole oricui. Pentru acesta, el vrea ca serverul sa se autentifice intr‑un fel oarecare, dar sa‑i confere siguranta ca "discuta" cu adevaratul server. Nu vom analiza acum metode prin care serverul poate face acest lucru, important este ca am inteles ce inseamna autentificare.
In acest moment utilizatorul nostru este linistit ca nu a trimis datele de identificare la o terta parte, serverul i s‑a autentificat. Dar nu e suficient! Ar fost fi bine daca s‑ar fi asigurat ca datele trimise catre server au fost impachetate cumva inainte de trimitere, pentru ca, in cazul in care ele sunt interceptate pe parcurs (de exemplu pe un router din cale) sa nu fie intelese. Adica daca datele ar fi fost criptate inainte de transmitere si decriptate la primirea lor pe server. Serverul ar fi trebuit sa fie singurul in masura sa poata decripta acele date. Bineinteles ca nici serverul nu se lasa mai prejos si vrea ca si utilizatorul sa i se autentifice. Apoi, ca totul sa fie riguros, comunicatia dinspre server catre client trebuie sa fie, la randul ei criptata.
Sunt si situatii in care autentificarea se face intr‑un singur sens, mai exact clientul se autentifica serverului, iar criptarea se face in celalalt sens, pentru datele trimise de la client la server. Ca exemplu pentru acest caz sunt formularele online, pentru care trebuie sa se asigure confidentialitate.
In cazul aplicatiilor web cea mai la indemana metoda pentru asigurarea criptarii si autentificarii este protocolul https, sau Secure http, care foloseste, de fapt, tehnologie SSL (Secure Sockets Layer).
3.2. Algoritmi de criptare si autentificare folositi
Algoritmi simetrici: Nou - standardul AES
AES = Advanced Encryption Standard
Acest standard specifica algoritmul Rijndael, un bloc de criptare care poate procesa blocuri de date de 128 biti , folosind chei de criptare de 128, 192 sau 256 biti. Succesul acestui algoritm este in primul rand datorat performantelor mai bune obtinute cu acelasi hardware, referindu‑ne aici la viteza decriptare‑decriptare.
Rijndael a fost conceput sa functioneze si cu alte marimi ale blocuri de date si chei de criptare dar acest standard nu le adopta. In functie de ce lungime a cheii se foloseste, vom denumi: "AES-128", "AES-192" si "AES-256".
Intrarea si iesirea pentru AES constau din secvente de 128 biti. Aceste secvente sunt de multe ori numite blocuri, iar lungimea acestor blocuri semnifica numarul de biti pe care ii contin. Cheia de criptare pentru AES este o secventa de 128, 192 sau 256 biti. Bitii din aceste secvente sunt numerotati incepand de la zero. Sunt folositi, in schimb, in special octetii, conventia fiind ca pentru un bloc de 128 biti - a, care e compus din 16 octeti, primul octet sa fie notat a0 sau a[0] si asa mai departe. Sirurile de octeti sunt reprezentate sub forma:
a0 a1a2. a15
Algoritmi simetrici: Standardul DES
DES, este acronimul de la Data Encryption Standard, si este un algoritm simetric (atat cel care cripteaza, cat si cel care decripteaza, trebuie sa posede aceasi cheie). A fost adoptat de ANSI (American National Standards Institute), ca standard ANSI X3.92 si intitulat DEA. Algoritmul foloseste o cheie de 56 de biti, care o aplica la blocuri din mesaj de 64 de biti, de 16 ori; adica, ia un bloc de 64 de biti, ii aplica cheia de 56 de biti si obtine un bloc de text criptat de 64 de biti; aceasta operatie, este repetata de 16 ori.
Modul de functionare
Prima data este aplicata o functie de permutare blocului de 64 de biti (de exemplu, bitul 58 devine bitul 1, bitul 50 - bitul 2, s.a.m.d.). Rezultatul, este divizat in doua sub-blocuri de cate 32 de biti, L0 si R0, dupa care, de 16 ori, se aplica urmatorii pasi:
Iteratia numarul i (1 <= i < 17):
Acesti pasi, pot fi descrisi prin diagrama de mai jos:
Figura
Functia f, ia 32 de biti din text (A) si cheia pe 48 de biti (J). O functie de expandare ii este aplicata lui A, care schimba cativa biti intre ei, si mai pune inca 16, ceea ce duce la cresterea lui A la 48 de biti. A expandat si J, sunt combinati, folosind un Sau Exclusiv. Cei 48 de biti rezultati, sunt trecuti prin niste 'S-boxes' (explicate mai jos), pentru a produce un rezultat pe 32 de biti. La final, este aplicata o alta permutare.
S-boxes, iau ca date de intrare 6 biti, si returneaza 4 biti. Acest proces, foloseste un tabel (numit S-Box), format din 4 linii si 16 coloane. Un exemplu de astfel de tabel, este dat mai jos:
Tabel
Pentru a se obtine 4 biti, se ia primul si ultimul bit din grupul de 6 pentru a stabili linia, si grupul de 4 biti de la mijloc, pentru a stabili coloana. De exemplu, daca se da grupul de biti 110111 si tabelul de mai sus, se ia primul si ultimul bit, care sunt 11 si reprezinta linia 3, si mijlocul de 4 biti 1011, care reprezinta coloana 11. Deci numarul rezultant, este la intersectia liniei 3 si a coloanei 11, si este 14 (in binar 1110).
Astfel, cei 48 de biti, sunt impartiti in 8 grupe de cate 6 biti si trecute prin 8 S-Boxes diferite, care sunt definite in specificatiile algoritmului. Se obtin tot 8 grupe, dar de cate 4 biti, care puse una langa alta, dau rezultatul final de 32 de biti.
Functia f(), este descrisa prin diagrama de mai jos:
Figura
Atacarea DES-ului
Pentru a ataca algoritmul DES, se folosesc 3 metode:
Metodele de criptanaliza diferentiala, descoperite in 1990, au scos la iveala faptul ca orice algoritm de criptare in bloc care a fost inventat inainte de 1990, sunt vulnerabili, cu exceptia DES-ului.
Algoritmul de criptare folosit acum ca standard in majoritatea implementarilor, inclusiv
Algoritmi asimetrici
Criptarea cu cheie publica
Bazele criptarii asimetrice, au fost puse in 1976 de Whitfield Diffie si Martin Hellman. Criptarea asimetrica, presupune generarea a doua chei, dintre care una este publica si poate fi data oricui, iar cealalta, este privata, si nu trebuie sa fie cunoscuta decat de cel care o foloseste. Cele doua chei au o proprietate speciala: sunt una inversul celeilalte, si nu pot fi deduse una din cealalta. In mare, principiul este urmatorul: cheia publica = 3, cheia privata = 1/3, iar mesajul= 4. Criptarea, se face astfel: cipher = cheie publica X mesaj = 3X4= 12. Decriptarea: mesaj = cipher X cheie privata = 12 X 1/3 = 4.
Algoritmul RSA
RSA, sunt initialele numelui celor trei inventatori ai algoritmului: Ron Rivest, Adi Shamir si Leonard Adleman. Algoritmul, functioneaza astfel: se genereaza doua numere prime foarte mari (de sute de zecimale) p si q. Cele doua numere se inmultesc, iar rezultatul se pune in n. Se alege un numar e, mai mic decat n, care sa fie relativ prim cu (p-1)(q-1). Se mai alege un numar d, cum ar fi (ed-1), care este divizibil cu (p-1)(q-1). Numarul e, este numit exponentul public, iar numarul d, este numit exponentul privat. Perechile (n,e) si (n,d) sunt cheia pulica, respectiv cheia privata.
Cele doua numere prime p si q, sunt fie tinute secrete, fie sunt distruse, deoarece toata securitatea algoritmului RSA (care este unul dintre cei mai folositi algoritmi cu cheie publica, atat pe plan guvernamental, cat si pe plan comercial), se bazeaza pe dificultatea obtinerii celor doua numere (p si q) din produsul lor (n). Odata cu obtinerea numerelor p si q, se poate afla si numarul d, care reprezinta cheia privata.
Exemplu de
criptare RSA: fie mesajul necriptat M, numerele prime p=5 si q=7. Produsul lor,
n=5X7=35. Numarul e=3, iar d=
=16.
Criptarea se face astfel: 
,
iar decriptarea 
.
Deci, fie mesajul M=4
Criptarea: C = 43 mod 35 = 39
Decriptarea: M = 2916 mod 35 = 2,5 x 1023 mod 35 = 4
Semnatura digitala RSA
Semnatura digitala este folosita pentru a identifica autorul unui mesaj. La semnatura digitala, se trimite atat textul criptat, cat si textul decriptat, care este criptat cu cheia privata a persoanei care-l trimite. Persoana care primeste mesajul, il decripteaza cu cheia publica a celui care l-a trimis, si il compara cu mesajul necriptat. Daca cele doua texte coincid, atunci se confirma ca cel care a trimis datele este intr‑adevar cine pretinde ca este.
3.3. Atacuri tip forta bruta
DES nu mai poate fi considerat sigur. Cu toate ca nu sunt cunoscute defecte majore in acest algoritm, este total inadecvat deoarece cheia sa de 56 biti este prea scurta. Este vulnerabil la o cautare prin forta bruta in intregul spatiu de chei, fie prin seturi mari de computere cu scop general, sau chiar mai repede cu hardware specializat. Bineinteles ca acestea se aplica oricarui alt algoritm de criptare cu o cheie de doar 56 biti sau mai putin. Singurul motiv pe care cineva ar putea avea nevoie sa mai foloseasca o cheie de 56 au 64 de biti ar fi pentru a se adapta diferitelor legi menite sa asigure posibilitatea ca un algoritm sa fie spart.
Hardware‑ul dedicat poate sparge DES in cateva zile. Semnul de intrebare asupra securitatii DES‑ului a fost pus definitiv. La inceputul lui 1998, fundatia "Electronic Frontier" a construit o masina de spart DES. Aceasta putea gasi o cheie DES in medie cam in cateva zile. O astfel de masina costa cam de 200000 USD pentru a fi conceputa si construita. Cum computerele devin din ce in ce mai rapide la acelasi pret, in numai 18 luni suma de 20000 USD a devenit 50000 USD, ceea ce spune totul. Agentii secrete din diferite natiuni se poate sa fi avut de multi ani masini de spart DES‑ul. Este greu de facut majoritatea aplicatiilor de computer sa functioneze bine pe masini paralele, sau sa se conceapa hardware pentru a le face mai rapide. Spargerea de algoritmi de criptare face parte din putinele exceptii insa. Este usor de crescut viteza de spargere doar adaugand hardware. In limite foarte largi, se poate ajunge la o viteza oricat de mare daca exista bugetul necesar.
DES poate fi spart chiar si folosind puterea de calcul distribuita intr‑o retea de computere. O corporatie mai mare, o universitate sau departament guvernamental ar putea sparge DES folosind ciclii masina liberi din retelele lor de calculatoare. Se poate sa le ia saptamani sau chiar luni, dar in cele din urma vor reusi. In ceea ce priveste munca unui singur individ pentru sparge DES, neavand resursele unei organizatii mai mari, viteza de spargere scade considerabil, dar se poate chiar si asa. Cu cateva mii de dolari se pot cumpara suficient de multe calculatoare, care, facute sa comunice ar putea sa sparga DES in cateva luni sau ani. Ba chiar s‑ar putea construi un virus care sa foloseasca putin din puterea de calcul a fiecarei victime, avand in acest fel un sistem de calcul distribuit urias.
Pe scurt, este acum absolut clar ca DES nu este sigur impotriva:
unui atacator cu fonduri pentru a‑si cumpara un hardware suficient de bun
oricarui atacator, chiar si fara resurse, dar care poate avea acces la cateva computere obisnuite.
Implementarea FreeS/WAN dezactiveaza DES din aceste motive prezentate mai sus.
3DES
DES triplu, abreviat ca 3DES, aplica DES de 3 ori, cu 3 chei diferite. DES este conceput foarte bine ca algoritm de criptare; a rezistat mai multor decenii de intensa analiza fara sa‑i fie gasite prea multe hibe. Singura lui problema este cheia scurta care permite succesul atacurilor tip forta bruta. 3DES mareste dimensiunea cheii la 168 biti, facand cautarea prin forta bruta o imposibilitate ridicola. In momentul de fata 3DES este singurul algoritm de criptare bloc implementat in FreeS/WAN. Din pacate viteza sa este de 3 ori mai mica decat a DES‑ului simplu, dar procesoarele moderne se descurca la viteze foarte bune. O analiza a performantelor va fi facuta in subcapitolul 5.9.
Dupa cum am anticipat chiar din introducere, exista doua tipuri principale de VPN, din punct de vedere structural:
site la site VPN
acces de la distanta VPN
Cisco are o alta clasificare, in functie de pozitia clientilor care se conecteaza:
Access VPN
Intranet VPN
Extranet VPN
Figura
Singura diferenta intre Intranet si Extranet VPN este ca prin Intranet VPN se conecteaza membrii organizatiei, iar prin Extranet partenerii de afaceri ai organizatei in cauza. Deci din punct de vedere tehnic este acelasi lucru, problema se pune la drepturile de acces care se primesc in fiecare din cazuri. Asadar vom trata in continuare cele doua tipuri, site la site si acces la distanta, urmand ca in subcapitolele 4.5., 5.6. si 5.7. sa vedem cum se poate restrictiona accesul la resursele locale in functie de cine se conecteaza.
4.1. Site la site VPN
In aceasta categorie intra conexiunile intre doua retele aflate in locatii diferite. Sigurul suport de comunicatie intre cele doua este internetul. Deoarece este nevoie ca resurse din una din retele sa fie accesibile din cealalta retea si invers, trebuie construit un tunel intre cele doua locatii care sa permita conexiuni intre IP‑uri nepublice din cele doua retele. Acesta s‑ar putea face simplu prin niste rute statice adaugate pe ambele routere si printr‑o encapsulare IP in IP a pachetelor, formandu‑se un tunel. Dar datele transferate nu trebuie sa fie intelese daca sunt interceptate pe parcurs. Trebuie ca ambele routere gateway ale celor doua retele sa poata cripta si decripta informatiile trimise, respectiv primite de la gateway‑ul cu care comunica. Topologia descrisa in acest scenariu poarta numele de VPN site la site (sau retea la retea). Tunelul stabilit intre locatii este un tunel IPsec criptat si autentificat. Nici unul dintre gateway‑uri nu stabileste tunelul decat cu celalalt gateway.
Caracteristic acestui tip de VPN e faptul ca adresele IP ale celor doua gateway‑uri sunt cunoscute si nu se schimba (IP‑uri statice).
O diagrama exemplificativa pentru acest tip de conexiune este reprezentata in figura urmatoare:
Figura
4.2. Acces la distanta
Aceasta topologie implica un server (gateway) care accepta conexiuni de la utlizatori mobili izolati. In felul acesta se stabileste un tunel criptat si autentificat intre utilizatorul mobil si reteaua din spatele serverului.
Diferenta majora dintre acest tip de VPN si cel site la site este ca utilizatorul mobil, numit in documentatia de specialitate si Road Warrior are aproape intoate cazurile un IP dinamic. Sau altfel privind lucrurile, nu se stie de la ce IP se va conecta data viitoare (indiferent ca s‑a conectat din aceeasi locatie dar i s‑a alocat un alt IP, sau s‑a conectat din alta locatie). Din aceasta cauza trebuie sa avem o metoda buna de autentificare, serverul nostru fiind deschis la conexiuni de la orice IP. Implementarea noastra cu IPsec si clienti mobili cu Windows va folosi ca metoda de autentificare atat certificate digitale cat si o pereche user/password. Certificatele digitale sunt eliberate de o Certification Authority (Autoritate de Certificare), nu neaparat publica si de root, deoarece vom acorda acces la reteaua noastra numai utilizatorilor pe care ii cunoastem si carora putem sa le inmanam certificatul semnat chiar de noi. Vom folosi in acest sens pachetul OpenSSL de pe Linux cu ajutorul caruia ne cream propria noastra CA (Certification Authority). Apoi generam cate un certificat digital pentru fiecare utilizator care dorim sa aiba acces de la distanta, il semnam cu autoritatea noastra si il oferim utilizatorului. In acelasi timp trebuie sa ii cream si o pereche user/parola necesare autentificarii la nivel L2TP. Practic, dupa ce se importa certificatul pe laptopul sau PC‑ul de pe care urmeaza sa se faca conectarea, pentru utilizator va fi transparent faptul ca mai intai autentificarea se face la nivel de masina, prin acest certificat, si abia apoi i se ofera ocazia sa introduca perechea user/parola. Bineinteles ca exista in clientul de Windows optiunea de a tine minte aceasta pereche user/parola, pentru ca utilizatorul sa se conecteze foarte simplu, doar cu un click de mouse.
Daca nu tinem cont de IP‑uri, aceasta topologie poate fi considerata un caz particular al topologiei site la site la site.
Figura
4.3. Server Linux si clienti Windows
Este firesc sa ne punem urmatoarele intrebari cand vedem un astfel de titlu: De ce nu server Linux si clienti tot Linux? Sau server Windows si clienti Windows? De ce trebuie sa avem o mixtura de tehnologii? Ei bine, este o alegere bine studiata si folosita de foarte multa lume. Sistemul de operare Windows este foarte raspandit ca sistem de operare pentru desktop. Aceasta deoarece este foarte intuitiv si usor de invatat si folosit de aproape oricine. Scopul oricarei companii este ca angajatii sa aiba o eficienta cat mai mare si de aceea astazi aproape orice activitate este informatizata. Timpul in care un nou angajat invata sa foloseasca sistemul informatic al companiei care l‑a angajat este foarte important sa fie cat mai mic, daca nu redus chiar la zero. Sistemul de operare Windows are avantajul ca a fost primul pentru utilizatorii de acasa si de aceea este acum cel mai bine cunoscut de utilizatorii obisnuiti. Asadar, managerul unei companii ajunge la concluzia ca banii cheltuiti pe o licenta de sistem de operare Windows pentru statia de lucru sunt justificati. Lucrurile nu stau chiar la fel in cazul variantei server de la Microsoft. Nu vom analiza performantele acestei variante de sistem de operare in comparatie cu altele pentru ca nu acesta e scopul lucrarii si dezbaterile in acest domeniu sunt aprinse. Ne vom referi insa la costul licentelor pentru Windows Server. Daca sistemul de operare pr‑zis poate costa in jur de 1000 dolari pentru un server, ei bine nu e singurul cost care trebuie luat in calcul. Politica de licentiere de la Microsoft este ca trebuie achizitionate licente si pentru fiecare utilizator care foloseste acest server. Deci pentru o retea de 30 de statii de lucru Windows XP Professional si 2 servere cu Windows Server 2003 se vor cumpara licente atat pentru fiecare Win XP Pro, pentru fiecare din cele doua Win Server 2003, dar si cate o licenta de acces client pentru fiecare utilizator din retea. Va dati seama ca intr‑o retea cu sute de statii de lucru cheltuielile pentru licente sunt foarte mari daca se alege prezenta unui sau mai multor servere Windows. Situatia sta la fel si pentru un sistem de operare Windows cu rol de Remote Access Server. Fiecare utilizator mobil care se conecteaza trebuie sa aiba un cont in domeniu si, deci o licenta de acces client.
Datorita celor relatate si nu numai, am ales varianta cu server Linux si clienti Windows. Alte motive ar fi robustetea Linux‑ului, potrivirea foarte buna pentru rolul de router/firewall software si rezistentei la atacuri tip virusi, worms etc.
4.4. Noutate: IPsec si NAT
Network Address Translation, cunoscut si sub numele de mascaradare este o metoda de alocare a adreselor IP in mod dinamic, tipic in situatii in care numarul de calculatoare care vor sa acceseze internetul este mai mare decat numarul de IP‑uri routabile alocate pentru o anumita locatie.
O incercare de a aplica NAT asupra pachetelor IPsec intre doua gateway‑uri securizate creeaza un asa zis conflict de "interese" :
IPsec vrea sa autentifice pachetele si sa asigure ca sunt nemodificate de la sursa la destinatie;
NAT‑ul rescrie headerele pachetelor;
Autentificarea IPsec esueaza daca pachetele sunt rescrise intr‑un punct dintre cele doua gateway‑uri.
Nu de mult insa, s‑a pus la punct un nou standard, numit IPsec NAT Traversal (NAT-T). Acest standard e descris in drafturi ca "Encapsularea pachetelor IPsec in UDP" (draft-ietf-ipsec-udp-encaps-02.txt) si "Negocierea NAT‑Traversal in IKE" (draft‑ietf‑ipsec-nat-t-ike-02-txt). IPsec NAT‑T defineste atat schimbarile din procesul de negociere cat si metodele diferite de trimitere a datelor protejate IPsec.
Gateway‑urile capabile de NAT‑T determina automat in timpul negocierilor IPsec urmatoarele:
daca atat initiatorul (de obicei clientul) cat si partea care raspunde (de obicei serverul) stiu NAT‑T.
daca exista vreun NAT intre ei.
Daca ambele conditii sunt adevarate, cei doi folosesc IPsec NAT‑T pentru a trimite trafic protejat prin NAT. Daca una dintre parti nu suporta NAT‑T atunci nu se poate realiza conexiunea. Daca nu exista nici un nat intre parti atunci se recurge la metoda clasica fara NAT‑T.
Dupa cum spuneam acest standard este foarte nou, Microsoft introducand aceasta tehnologie incepand cu Windows Server 2003, pentru Windows XP si 2000 fiind nevoie de un patch descarcabil de pe Windows Update Catalog in sectiunea Recommended Updates, pentru a suporta NAT‑T.
In implementarile noastre vom folosi pentru Linux FreeS/WAN, iar pentru Windows clientii inclusi implicit in acest sistem de operare. Daca, deci, pe Windows nu este necesara o instalare de soft 3rd party, pentru versiunile de kernel 2.2 si 2.4 trebuie sa instalam FreeS/WAN pentru a avea o arhitectura IPsec. Kernelurile viitoare, incepand cu 2.6 au deja inclus suportul pentru IPsec, nemaifiind necesara instalarea vreunui pachet.
5.1. Compatibilitate Linux - Windows
Sistemul de operare Windows, incepand de la versiunea Windows 2000 are inclus suport pentru IPsec. Este vorba de un suport nativ, nefiind necesara instalarea altor aplicatii separate. Am putea chiar zice ca avem IPsec gratis in Windows 2000/XP, dar nu este adevarat, pretul fiind inclus in licenta pentru sistemul de operare.
La Linux, in schimb, exista pachetul FreeS/WAN, care, cu toate ca nu vine precompilat in toate distributiile de Linux, se poate descarca si folosi in sistem Open Licence. Din acest motiv au aparut numeroase alte variante de implementari IPsec pentru UNIX/Linux, toate bazate pe FreeSwan: SuperFreeSWAN, OpenSwan, StrongSwan etc.
Ca diferenta majore intre cele doua implementari (Windows, Linux), Windows se fereste sa foloseasca IPsec pur cum face FreeSwan atat de bine, si mai adauga un protocol numit L2TP, implementarea Microsoft numindu-se L2TP/IPSec. Motivele pentru care Microsoft face aceasta alegere sunt variate ajungindu-se pana la partea financiara. Ca motive tehnice ar fi: IPsec nu ofera posibilitatea oferirii de IP-uri private virtuale partilor (ex. DHCP), acestea trebuind sa fie setate static. De asemenea, IPsec autentifica la nivel de masina, nu la nivel de utilizator, ceea ce Microsoft considera inacceptabil.
Cu IPsec/L2TP, in schimb, se poate folosi un server DHCP care asigneaza configuratia TCP/IP automat, catre toti clientii.
IPsec este un standard recunoscut si teoretic toate implementarile sale pe sisteme de operare sau hardware dedicat ar trebui sa interopereze. Exista insa mici probleme de care ne lovim la crearea unui tunel intre Windows si Linux.
Printre aceste probleme, principala este metoda de autentificare. Windows suporta certificate X509 si chei secrete. Linux cu FreeSwan suporta par default doar RSA si chei secrete. Cum pe Windows este mai greu sa intervenim, neavand acces la surse, modificarile se fac pe partea Linux, unde se adauga suportul pentru certificate X509.
5.2. Instalare si configurare pe Linux
Pentru a instala pachetul FreeS/WAN trebuie indeplinite urmatoarele conditii:
un Linux cu versiunile de kernel 2.2 sau 2.4
acces de root
alegerea corecta a versiunii de FreeS/WAN, in functie de necesitati
In momentul elaborarii acestui proiect cea mai buna versiune a fost 1.99 cu patch‑uri pentru certificate X509 si NAT‑T aplicate. Nu e suficient ca FreeS/WAN sa aiba patch‑ul de NAT‑T. Si kernelul trebuie sa suporte acest lucru. Este, deci, nevoie de aplicarea unui patch si acestuia, iar apoi recompilare.
Am adoptat varianta de creare de rpm‑uri (folosim Red Hat Linux) pentru build‑urile pe care le facem, de kernel si de FreeS/WAN, pentru a le putea instala usor mai apoi pe alte server fara a mai recompila.
Avand sursele kernelului sub un symbolic link in:
/usr/src/linux
executam urmatoarele comenzi:
# make menuconfig
# make dep
# make bzImage
# make modules
Apoi mergem in directorul unde avem sursele pentru FreeS/WAN si executam:
# make menumod
Aceasta comanda aplica un patch ESP_IN_UDP necesar pentru suportul de NAT‑Traversal in sursele kernelului. Dupa ce alegem optiunile dorite in meniul de configurare executam:
# make minstall
Pentru a avea NAT‑T in kernel ii facem un build:
# make bzImage
Apoi rebootam cu noul kernel. In acest moment avem totul instalat, putem trece la configurarea conexiunilor. Fisierele cele mai importante de configurare pentru FreeS/WAN sunt
/etc/ipsec.conf si /etc/ipsec.secrets
In /etc/ipsec.conf se trec detalii referitoare la capetele tunelurilor ce urmeaza a fi stabilite. Iata un exemplu pentru acest fisier:
# basic configuration
config setup
# %defaultroute is okay for most simple cases.
interfaces=%defaultroute
# Debug-logging controls: 'none' for (almost) none, 'all' for lots.
klipsdebug=none
plutodebug=none
# Use auto= parameters in conn descriptions to control startup actions.
plutoload=%search
plutostart=%search
# Close down old connection when new one using same ID shows up.
uniqueids=yes
nat_traversal=yes
conn %default
keyingtries=0
disablearrivalcheck=no
authby=rsasig
leftrsasigkey=%cert
rightrsasigkey=%cert
compress=yes
conn bit-psro
left=11.22.33.44
leftsubnet=192.168.1.0/24
leftnexthop=11.22.33.1
right=55.66.77.88
rightsubnet=192.168.3.0/23
rightnexthop=55.66.77.1
authby=rsasig
auto=start
In /etc/ipsec.secrets se trec frazele secrete sau fisierele ce contin semnaturile digitale. Acest fisier trebuie sa aiba drept de citire doar pentru super‑user (root).
Pentru tuneluri intre masini Linux putem folosi semnaturi RSA, insa cand vrem sa permitem si conexiuni de la masini Windows trebuie sa avem suport pentru X509.
Tot pe Linux, pentru ca e GPL, instalam si OpenSSL (daca nu e instalat deja) si ne cream propria CA. Apoi generam certificatele pentru toate hosturile pe care le vom configura si le semnam cu aceeasi CA.
5.3. Configurare pe Windows
Procedura importare certificate
In Windows exista o baza de date ce contine certificate autoritatilor (Certificate Authority - CA) radacina. Aici pot fi importate certificate emise de o autoritate proprie unei corporatii catre utilizatori pentru diferite scopuri: autentificarea e-mailurilor, autentificare IPSec etc.
Exista mai multe sectiuni: Computer Account, User Account si Service Account.
Certificatele se distribuie diferitilor utilizatori sau diferitelor masini in mai multe formate, fiind fisiere cu una din extensiile: .cer, .crt, .pfx, .p12 etc.
Prin dublu-click pe un astfel de fisier, certificatele sunt adaugate in contul utilizatorului curent logat pe masina in acel moment. Este cazul certificatelor (Digital IDs) pentru semnarea e-mailurilor. Nu este insa cazul autentificarii IPsec, care Microsoft considera ca trebuie facuta la nivel de masina. Trebuie, deci ca PC-ul de pe care se face o conectare VPN prin IPSec, sa aiba un certificat acceptat de serverul VPN.
Aceasta procedura descrie modul in care se pot importa certificate pentru PC-ul local (Local Computer).
Figura
Figura
Acum aveti in baza de date pt. Computer Account un certificat al autoritatii ce a eliberat certificatul (in Trusted Root Certification Authorities -> Certificates in cazul nostru se cheama Pointersoft CA), cat si o cheie privata in Personal -> Certificates
Windows XP/2000 are inclus by-default un client de VPN cu suport pentru PPTP si L2TP/IPSec.
Pentru a crea conexiunea catre serverul companiei se urmeaza pasii urmatori (dup ace in prealabil ati instalat certificatul corespunzator - vezi proced_Instalare_Certificate.doc):
Figura
Figura
Figura
(Nu este necesara aceasta optiune, deoarece criptarea se face la primul nivel - IPSec, si ar fi inutile doua niveluri de criptare)
Figura
5.4. IPsec pur vs L2TP/IPsec
5.5. Certificate digitale sau fraze secrete?
Trei motive principale ne fac sa alegem certificatele digitale:
cu certificate digitale putem sti cine se conecteaza si putem controla accesul
frazele secrete nu sunt la fel de sigure ca certificatele digitale
daca se fura un certificat digital, il revocam, ceilalti utilizatori neavand de suferit; daca insa se afla fraza secreta (care este unica pentru toti utilizatorii mobili), atunci trebuie sa o schimbam, si trebuie deci sa o distribuim tuturor utilizatorilor.
5.6. Rutare
Serverul VPN este un router de nivel 3 si trebuie configurat corespunzator pentru a face toate locatiile accesibile. Mai exact, un server VPN ar avea nevoie de urmatoarele:
ruta implicita care indica catre un firewall sau un router conectat direct la internet. Aceasta ruta face ca toate locatiile din internet sa fie accesibile.
una sau mai multe rute care insumeaza spatiul de adrese din intranet, ruta care sa indica catre un router intern.
Sunt si situatii particulare in care nu e nevoie de o configuratie speciala suplimentara. De exemplu atunci cand intranetul e format dintr‑un singur subnet (192.168.0.0/255.255.255.0).
Pe de alta parte, asigurarea accesibilitatii clientilor VPN din intranet depinde de cum este configurat serverul VPN sa ofere adrese IP clientilor. Acestea pot fi:
o clasa de adrese din acelasi subnet cu al intranetului
o clasa de adrese diferita de cea a intranetului
In primul caz serverul VPN devine un asa numit "arp proxy", ca si cum interfata lui ethernet ar avea toate adresele MAC ale clientilor VPN conectati la un moment dat la server. Cand un PC din LAN vrea sa comunice cu un PC conectat prin VPN care are un IP din acelasi subnet cu el (se afla sub acelasi mask), trimite un arp request, care este de fapt un broadcast. Serverul VPN recunoaste IP‑ul din acest arp request si trimite la randul lui un arp reply pretinzand ca pachetele pentru IP‑ul cautat trebuie trimise catre MAC‑ul intefetei lui Ethernet. Cand primeste pachetul il redirectioneaza clientului VPN, deoarece are cate o ruta peer‑to‑peer (adica cu mask‑ul 255.255.255.255) pentru fiecare IP al clientilor conectati.
In cel de‑al doilea caz lucrurile sunt mai simple din punct de vedere conceptual, fiind o situatie tipica de rutare: PC‑ul din LAN "vede" ca IP‑ul clientului VPN nu este in acelasi subnet cu el si nu mai trimite arp request, ci il trimite direct routerului default gateway pe care il are configurat. Apoi acest router, fie el chiar serverul VPN dar nu e neaparat sa fie asa, avand configurata ruta pentru aceasta clasa de adrese plaseaza pachetele pe ruta corecta.
Split tunneling
Semnificatia acestui termen este urmatoarea: La nivelul clientului de VPN se pot intampla doua lucruri: se adauga o ruta implicita pentru destinatiile necunoscute (internet) prin tunelul VPN, sau, ca o a doua varianta, nu se modifica ruta implicita, adaugandu‑se doar o ruta pentru clasa de adrese din care face parte IP‑ul alocat clientului. Diferenta dintre cele doua cazuri este semnificativa. Prima varianta este considerata cea mai sigura pentru ca in timpul conexiunii la serverul VPN, nu se mai pot stabili conexiuni cu clientul din internet. Mai mult decat atat, administratorul poate sa aplice politici de acces web, ftp, mail si asupra clientilor VPN. Singurul dezavantaj este ca serverul trebuie sa aiba o latime de banda suficienta pentru a accepta traficul internet al tuturor clientilor VPN. De exemplu, atunci cand utilizatorul conectat fiind la VPN‑ul corporatiei, deschide un browser si doreste sa acceseze o pagina web, tot traficul trece prin serverul VPN, putandu‑se face aici tot felul de filtrari sau contorizari ale accesului. Se poate chiar configura un proxy de http si ftp transparent, nefiind necesara o configuratie pe partea de client pentru acest lucru. In cealalta varianta (split tunnelling) este imperios necesara prezenta firewall‑ului pe partea de client. Daca acest firewall nu este prezent si securitatea sistemului de operare al clientului este compromisa printr‑un atac din internet, atacatorul poate obtine usor acces si asupra resurselor din interiorul corporatiei.
5.7. Chestiuni de firewall si NAT
Standardul IPsec foloseste urmatoarele protocoale IP si porturi:
protocolul UDP (17) portul 500 pentru negocierea parametrilor (IKE)
protocolul ESP (50) pentru traficul criptat propriu zis
protocolul UDP (17) portul 4500 pentru NAT‑T
Mai exact, in cazul scenariului retea la retea, presupunand ca ip‑urile celor doua capete ale tunelului sunt fixe, trebuie permise in firewall protocolul ESP si protocolul UDP portul 500 pe ambele gateway‑uri
Pentru scenariul "acces de la distanta" lucrurile nu mai sunt la fel de simple. Pe partea de server VPN trebuie permise toate cele 3 enumerate mai sus pentru a acoperi ambele cazuri: cand clientul se afla in spatele unui NAT sau are un IP routabil (Dial‑up). Cand utilizatorul se conecteaza prin Dial‑up firewall‑ul personal trebuie sa permita conexiuni pe UDP 500 si ESP atat pe directia inbound cat si outbound. Cand se conecteaza din spatele NAT, atat firewal‑ul personal (daca e prezent), cat si cel al NAT‑ului, trebuie sa permita doar: UDP 500 si UDP 4500 deoarece ESP‑ul este encapsulat in UDP 4500.
Ce este interesant pentru conexiunile VPN prin IPsec din spatele NAT‑ului este ca oricat de multi utilizatori se pot conecta simultan din spatele aceluiasi IP. Acest lucru nu este suportat de PPTP.
L2TP foloseste UDP 1701, dar nu avem de‑a face cu el decat pe interfetele ipsec din Linux si numai daca vrem sa filtram pe ele.
5.8. Considerente practice pentru implementare
Este foarte important sa alegem topologia corecta de VPN pe care urmeaza sa o implementam. In cele mai multe cazuri va fi suficient un tunel retea la retea, care va securiza tot traficul intre oricare doua noduri din cele doua retele. Pot aparea si situatii cand nu vrem sa permitem tuturor membrilor unei retele acces la cealalta retea remote. Aici se poate lucra din firewall cu acces bazat pe ip‑ul sursa. Cand, insa, este nevoie de acces doar de la un singur nod al unei retele catre cealalta retea ar fi inpractic sa construim un tunel intre retele. Aici e bine sa folosim topologia "remote access"
Pentru topologia retea la retea cel mai simplu si recomandat este sa se foloseasca tuneluri IPsec pure cu autentificare masina la masina. Pentru topologia acces de la distanta trebuie sa putem aloca clientilor ip‑uri virtuale, acestia trebuie sa poata initia conexiunea chiar cu drepturi de simplu user si mai trebuie sa existe un feedback din partea conexiunii catre utilizator, adica el trebuie sa stie daca e conectat sau nu. De aceea recomand folosirea L2TP/IPsec pentru acest scenariu. Pe parte de client Windows instalarea nu este necesara deoarece Windows are client de VPN preinstalat, iar configurarea este foarte simpla, setarile putand fi distribuite utilizatorului sub forma unui kitde instalare (Connection Manager Administration Kit).
5.9. Performante ale implementarii FreeS/WAN
Performantele acestei implementari sunt potrivite pentru cele mai multe aplicatii. La operare normala, principalul factor de luat in seama este incarcarea pe procesor pentru criptarea, decriptarea si autentificarea pechetelor IPsec.
Se poate gasi o formula care face legatura intre viteza procesorului si rata de procesare IPsec posibila. Nu este exacta pentru ca ar fi greu de gasit asa ceva, dar este suficient de corecta pentru a putea face niste estimari pentru necesarul hardware pentru un caz aparte. Tabelul urmator contine numarul de cicli utlilizati dintr‑un procesor Pentium II per fiecare octet procesat. Pentru criptare s‑a folosit algoritmul 3DES.
Tabel
|
IPsec |
autentificare |
criptare |
cicli/byte |
|
|
fara IPsec |
nu |
nu |
nu | |
|
IPsec fara crypto |
da |
nu |
nu | |
|
IPsec, doar autentificare |
da |
SHA-1 |
nu | |
|
IPsec si cu criptare |
da |
da |
da |
La 140 de cicli per octet procesat, un procesor la 140 Mhz poate procesa 8 Mbiti/s. Vitezele de procesare pentru alte procesoare sunt proportionale cu aceasta. Trebuie, insa luate in calcul si alte eventuale incarcari pe acelasi procesor. Urmatorul tabel arata o estimare mai practica:
Tabel
|
Interfata |
Viteza procesorului in Mhz |
|||
|
Type |
Mbit per |
Estimate |
PC utilizabil ca gw |
Minimum with other load (e.g. firewall) |
|
DSL |
25 MHz |
whatever you have |
133, or better if you have it |
|
|
cable modem |
75 MHz |
|||
|
any link, light load |
125 MHz |
200+, almost any surplus machine |
||
|
Ethernet |
250 MHz |
surplus 266 or 300 | ||
|
fast link, moderate load |
500 MHz |
800+, any current off-the-shelf PC |
||
|
T3 or E3 |
1125 MHz | |||
6.1. Hardware specializat
Folosirea hardware‑ului specializat este recomandata in acele scenarii in care numarul de conexiuni suportate simultan trebuie sa fie foarte mare, si administrarea ulterioara (dupa faza de configurare) sa nu fie foarte complicata. Principalul avantaj al acestor solutii este ca sunt cipuri special concepute pentru a face criptare si deci, performansele sunt pe masura. Dezavantajul lor principal este pretul foarte mare care poate fi prohibitiv pentru unii beneficiari (zeci de mii de dolari). Ar mai fi si dezavantajul limitarii in configurari, dar numai pentru produsele ieftine si mai putin renumite.
6.2. Alte solutii software
Mai exista si alte solutii software prin care se poate realiza un VPN. Respecta mai mult sau mai putin standardul IPsec asa cum este publicat in RFC‑uri, iar unele nu folosesc deloc IPsec ci alte metode non‑standard. Printre solutiile tip IPsec amintim: Kame, McAfee VPN, SSH Sentinel, isakmpd
6.3. Comparatie
Interoperabilitate intre solutii hardware dedicate si solutii software
Atunci cand facem planul unei solutii VPN trebuie sa anticipam incarcarea pe care aceasta solutie o va suporta imediat dupa punerea in functiune, dar si in viitorul apropiat.
Atunci cand nu este nevoie ca VPN-ul sa suporte mai mult de 100-200 conexiuni simultane, o solutie software (program instalat pe una din parti, sau pe amandoua) face fata. Problema se pune atunci cand sunt mai multi utilizatori, si cand un PC obisnuit (P3 - 800Mhz) deja nu mai face fata. Devine mai rentabila, in acest caz o solutie hardware dedicata, adica un VPN concentrator. Solutiile sunt numeroase, la fel si producatorii. Va prezint in tabelul de mai jos cateva din cele mai cunoscute solutii VPN si compatibilitatea dintre acestea:
|
FreeS/WAN VPN |
Road Warrior |
OE |
|||||
|
PSK |
RSA Secret |
X.509 |
NAT-Traversal |
Manual | |||
|
Cele mai compatibile |
|||||||
|
FreeS/WAN |
Da |
Da |
Da |
Da |
Da |
Da |
Da |
|
isakmpd (OpenBSD) |
Da |
Da |
Da |
Nu |
|||
|
Kame (FreeBSD, |
Da |
Da |
Da |
Da |
Nu |
||
|
McAfee VPN |
Da |
Da |
Da |
Da |
Nu |
||
|
Microsoft
|
Da |
Da |
Da |
Nu |
|||
|
SSH Sentinel |
Da |
Da |
Posibil |
Da |
Nu |
||
|
Safenet
SoftPK |
Da |
Da |
Da |
Nu |
|||
|
Altele |
|||||||
|
6Wind |
Da |
Nu |
|||||
|
Alcatel Timestep |
Da |
Nu |
|||||
|
Apple
Macintosh |
Posibil |
Da |
Posibil |
Posibil |
Nu |
||
|
AshleyLaurent
|
Da |
Nu |
|||||
|
Borderware |
Da |
Nu |
Nu |
||||
|
Check Point FW-1/VPN-1 |
Da |
Da |
Da |
Nu |
|||
|
Cisco with 3DES |
Da |
Posibil |
Da |
Nu |
|||
|
Equinux
VPN Tracker |
Da |
Da |
Da |
Posibil |
Nu |
||
|
F-Secure |
Da |
Posibil |
Da |
Da |
Nu |
||
|
Gauntlet GVPN |
Da |
Da |
Nu |
||||
|
IBM AIX |
Da |
Posibil |
Nu |
||||
|
IBM AS/400 |
Da |
Nu |
|||||
|
Intel Shiva |
Da |
Nu |
|||||
|
LanCom (formerly ELSA) |
Da |
Nu |
|||||
|
Linksys |
Posibil |
Nu |
Da |
Nu |
|||
|
Lucent |
Partial |
Nu |
|||||
|
Netasq |
Da |
Nu |
|||||
|
netcelo |
Da |
Nu |
|||||
|
Netgear fvs318 |
Da |
Nu |
|||||
|
Netscreen
100 |
Da |
Posibil |
Nu |
||||
|
Nortel Contivity |
Partial |
Da |
Da |
Nu |
|||
|
RadGuard |
Da |
Nu |
|||||
|
Raptor |
Da |
Da |
Nu |
||||
|
Redcreek Ravlin |
Da/Partial |
Nu |
|||||
|
SonicWall |
Da |
Posibil |
Nu |
Nu |
|||
|
Sun Solaris |
Da |
Da |
Da |
Nu |
|||
|
Symantec |
Da |
Nu |
|||||
|
Watchguard
|
Da |
Da |
Nu |
||||
|
Xedia Access
Point |
Da |
Nu |
|||||
|
Zyxel Zywall |
Da |
Nu |
|||||
|
PSK |
RSA Secret |
X.509 |
NAT-Traversal |
Manual | |||
|
FreeS/WAN VPN |
Road Warrior |
OE |
|||||
Tabel
Termenii din tabelul 3 semnifica:
Road Warrior = Utilizator mobil care de obicei are un ip dinamic in internet
Aplicatia practica consta in realizarea unei topologii VPN hibride cu conexiuni atat site‑to‑site cat si acces de la distanta pentru utilizatori mobili. Conexiunile site‑to‑site vor fi realizate intre: doua gateway‑uri cu Linux Red Hat 9 si unul din cele doua si un al treilea cu Windows XP Professional (Figura 25).
In ceea ce priveste accesul de la distanta al utilizatorilor mobili (Figura 26), acestia nu vor nevoiti sa instaleze aplicatii client speciale. Pentru a‑si configura conexiunea ei vor folosi Wizard‑ul "New Connection" din Control Pannel .
Pentru a putea accesa nodurile de acces (RAS) din spatele unui router/firewall cu NAT, trebuie aplicat un patch sistemului de operare Windows XP. Acest patch este datat 21 octombrie 2003, ceea ce evidentiaza noutatea acestei tehnologii VPN. Windows a introdus optiunea NAT‑Traversal abia incepand cu Windows Server 2003, pentru variantele precedente de sistem de operare tip server de la Microsoft neexistand nici macar patch‑uri pentru a suporta NAT‑T.
Componentele software pe partea de Linux sunt:
FreeSWAN 1.99 cu NAT si X509
L2tpd daemon
ppp daemon
iptables
Pentru Windows se foloseste suportul pentru IPsec implementat direct in sistemul de operare, nefiind nevoie de instalarea vreunei aplicatii software 3rd party. Este foarte important sa fie activat Internet Connection Firewall pe conexiunea ininitiala a clientului la internet prin ISP‑ul sau! Pentru conexiunea VPN nu trebuie activat ICF.
Aplicatiile utilizate prin acest VPN sunt:
solutia de groupware de la Microsoft: Exchange 2003 impreuna cu Outlook XP si 2003;
aplicatia de contabilitate si gestiune NeoManager;
conexiuni Remote Desktop pe un server terminal Windows Server 2003 Enterprise;
videoconferinta prin NetMeeting;
nu in ultimul rand administrare servere si statii de lucru Linux si Windows de la distanta.
Resursele folosite pentru crearea VPN‑ului (excluzand statiile de lucru, laptopurile si serverele care au alte scopuri decat gateway‑uri de securitate), sunt:
1 PC Cyrix 100 Mhz cu 64 MB RAM, Red Hat 9
1 PC Pentium 133 Mhz cu 96 MB RAM, RedHat 9
1 PC Celeron 1,2 Ghz cu 128 MB RAM, Windows XP Professional
Fisierul de configurare /etc/ipsec.conf de pe serverele Linux este urmatorul:
# basic configuration
config setup
# THIS SETTING MUST BE CORRECT or almost nothing will work;
# %defaultroute is okay for most simple cases.
interfaces='ipsec0=eth1'
# Debug-logging controls: 'none' for (almost) none, 'all' for lots.
klipsdebug=none
plutodebug=none
# Use auto= parameters in conn descriptions to control startup actions.
plutoload=%search
plutostart=%search
# Close down old connection when new one using same ID shows up.
uniqueids=no
nat_traversal=yes
# defaults for subsequent connection descriptions
# (these defaults will soon go away)
conn %default
keyingtries=0
disablearrivalcheck=no
authby=rsasig
leftrsasigkey=%dnsondemand
rightrsasigkey=%dnsondemand
compress=yes
# connection description for opportunistic encryption
# (requires KEY record in your DNS reverse map; see doc/opportunism.howto)
conn me-to-anyone
left=%defaultroute
right=%opportunistic
keylife=1h
rekey=no
# for initiator only OE, uncomment and uncomment this
# after putting your key in your forward map
#leftid=@myhostname.example.com
# uncomment this next line to enable it
#auto=route
# sample VPN connection
conn sample
# Left security gateway, subnet behind it, next hop toward right.
left=10.0.0.1
leftsubnet=172.16.0.0/24
leftnexthop=10.22.33.44
# Right security gateway, subnet behind it, next hop toward left.
right=10.12.12.1
rightsubnet=192.168.0.0/24
rightnexthop=10.101.102.103
# To authorize this connection, but not actually start it, at startup,
# uncomment this.
#auto=add
conn L2TP-CERT
authby=rsasig
pfs=no
left=213.157.161.143
leftnexthop=213.157.161.1
leftrsasigkey=%cert
leftcert=/etc/ipsec.d/pointersoft.ro.pem
leftprotoport=17/1701
#
#
right=%any
rightrsasigkey=%cert
rightprotoport=17/1701
auto=add
keyingtries=1
conn bit-psro
## include si subnetul depozit (192.168.2.0/24)
left=213.157.161.143
leftsubnet=192.168.1.0/24
leftnexthop=213.157.161.182
#
right=213.157.161.182
rightsubnet=192.168.3.0/23
rightnexthop=213.157.161.143
authby=secret
auto=add
Pe serverul al treilea, Windows XP Professional am configurat parametrii IPsec in mod GUI din Microsoft Management Console, folosind aceiasi parametri ca si pe Linux. Singura observatie este ca trebuie adaugate cate doua reguli pentru fiecare tunel.
Figura
Figura
Ce facem cu pachetele care se potrivesc cu regula pe care am setat‑o? Negociem securitatea. Adica le trimitem criptat. Daca nu putem sa trimitem criptat le face discard.
Figura
Autentificarea se face prin certificate:
Figura
Setarea capetelor tunelului:
Figura
Figura . Exemplificarea topologiei site‑la‑site
Figura . Exemplificarea topologiei mixte de site‑la‑site si acces de la distanta
Controlul accesului (en: Access Control)
Este un serviciu de securitate care impiedica utilizarea neautorizata a unei resurse, inclusiv prevenirea folosirii unei resurse in mod neautorizat. In contextul IPsec, resursa pentru care accesul este controlat poate fi:
Pentru un host, cicli masina sau date
Pentru un security gateway, o resea din spatele gateway‑ului sau latimea de banda din acea retea.
Anti‑replay
A se vedea "Integritate" mai jos
Autentificare
Acest termen este folosit informal pentru a se referi la combinatia a doua servicii de securitate distincte: autentificarea originii fatelor si integritate fara controlul conexiunii. A se vedeadefinitiile pentru acestea mai jos
Disponibilitate (en. Availability)
Privit ca un serviciu de securitate, se adreseaza problemelor de securitate generate de atacuri impotriva retelelor care nu permit sau care nu conosc serviciul. De exemplu, in contextul IPsec, folosirea mecanismelor de anti‑reply in AH si ESP suporta disponibilitatea.
Confidentialitate
Confidentialitatea este serviciul de securitate care protejeaza datele de accesari neautorizate. Principala problema a confidentialitatii in cele mai multe cazuri este divulgarea neautorizata a datelor de la nivelul aplicatie, dar dezvaluirea de caracteristici externe ale comunicatiei poate fi, de asemenea, o problema in unele cazuri. Confidentialitatea fluxului de date este serviciul care se adreseaza acestei ultime probleme, ascunzand adresele sursa si destinatie, lungimea mesajului, sau frecventa comunicatiei. In contextul IPsec, folosind ESP in modelul tip tunel, in special la nivelul unui security gateway, poate oferi un oarece nivel de confidentialitatea fluxului de date. (A se vedea, de asemenea, "Analiza traficului" mai jos).
Autentificarea originii datelor (en: Data Origin Authentication)
Autentificarea originii datelor este un serviciu de securitate care verifica identitatea presupusei surse a datelor primite. Acest serviciu este, de obicei, contopit cu serviciul de intergritate fara conexiune.
Criptarea (en: Encryption)
Criptarea este un mecanism de securitate folosit pentru a transforma datele dintr‑o forma inteligibila (plaintext) intr‑o forma neinteligibila (ciphertext), pentru a oferi confidentialitate. Procesul invers de transformare se numeste decriptare (en: decryption). De multe ori termenul de decriptare se refera generic la ambele procese.
Integritate (en: Integrity)
Integritatea este un serviciu de securitate care asigura ca modificarile aduse datelor pe parcursul rutei sunt detectabile. Integritatea se prezinta intr‑o gama variata de variante pentru a se potrivi cerintelor aplicatiei. IPsec suporta doua forme de integritate: fara conexiune, si o forma de integritatea secventelor partiale. Integritatea fara conexiune este un serviciu care detecteaza modificarile unei datagrame IP individuale, indiferent de ordinea datagramei intr‑un stream de trafic. Forma de integritatea secventelor partiale oferita in IPsec este referita ca integritatea anti‑reply, si detecteaza sosirea datagramelor IP duplicate (in cadrul unei ferestre date), Acesta este, spre deosebire de integritatea orientata pe conexiune, care impune cerinte de secventiere mai stricte asupra traficului, de exemplu de a putea detecta pierderea sau rearanjarea pachetelor. Cu toate ca serviciile de autentificare si integritate sunt discutate separat de cele mai multe ori, in practica ele sunt strans legate si aproape mereu oferite impreuna.
Protejat vs neprotejat
"Protejat" se refera la sistemele sau interfetele care sunt in interiorul granitei de protectie IPsec, si "neprotejat" se refera la sistemele sau interfetele care sunt in afara granitei de protectie IPsec. IPsec prevede o granita prin care traficul trece. Exista o nesimetrie a acestei granite care este reflectata in modelul de procesare. Datele care trebuie sa iasa, daca nu sunt ignorate sau lasate sa treaca sunt protejate prin aplicarea AH sau ESP si prin adaugarea headerelor corespunzatoare. Datele care vin spre noi (inbound data), daca nu sunt ignorate sau lasate sa treaca, sunt procesate prin indepartarea headerelor AH sau ESP. Conventia este ca traficul inbound sa fie considerat cel care intra intr‑o implementare IPsec dinspre interfata neprotejata. Traficul outbound intra din partea protejata a granitei, sau este intern generat de catre hostul pe care este implementat IPsec si iese prin interfata neprotejata. O implementare IPsec poate suporta mai mult de o interfata de fiecare parte a granitei. Interfata protejata poate fi interna, de exemplu intr‑o implementare IPsec pe un host care nu e router. Interfata protejata poate fi legata la o interfata socket layer a sistemului de operare.
Security Association (SA)
O conexiune unidirectionala logica, creata pentru securitate. Tot traficul care traverseaza o SA beneficiaza de aceeasi procesare. In IPsec, o SA este o abstractizare a nivelului internet implementat prin folosirea AH sau ESP. Informatiile de stare asociate cu o SA sunt reprezentate in SAD (Security Association Database)
Security Gateway
Un security gatewaz este un sistem intermediar care se comporta ca o interfata de comunicatie intre doua retele. Multimea de noduri si retele de pe partea externa a gateway‑ului de securitate se numeste "neprotejata", iar retelele si nodurile de pe partea interna sunt considerate ca "protejate". Subneturile si nodurile interne care comunica printr‑un SG sunt presupuse a fi de incredere din motivul ca partajeaza o administrare a securitatii comunca si locala. In contextul IPsec, o SG este un punct in care AH sau/si ESP sunt implementate pentru a "servi" o multime de host‑uri interne, oferindu‑le servicii de securitate atunci cand comunica cu host‑uri externe care au la randul lor IPsec implementat.
SPI
Prescurtare pentru Security Parameters Index. SPI este o valoare pe 32 de biti arbitrara folosita de un receptor pentru a identifica SA‑ul cu care trebuie sa se faca corespondenta pentru un pachet care tocmai a sosit. Pentru un SA de tip unicast, SPI poate fi folosit singur pentru a specifica o SA, sau poate fi folosit impreuna cu un tip de protocol IPsec. Informatii de adresa IP suplimentare sunt folosite pentru a identifica SA‑uri multicast. SPI este purtat in protocoalele AH si ESP pentru a permite sistemului destinatie sa aleaga ce SA va fi folosit pentru pachetul care tocmai a sosit. SPI are doar semnificatie locala, ca definit de initiatorul SA (de obicei destinatarul pachetului care poarta SPI‑ul); asadar un SPI este de obicei vazut ca un string de biti opac. Totusi, initiatorul unei SA poate alege sa interpreteze bitii dintr‑un SPI pentru a usura procesarea locala.
Analiza traficului (en: Traffic Analysis)
Analiza fluxului de trafic in retea cu scopul de afla informatie utila unui tert. Exemple de astfel de informatii sunt frecventa transmiterii datelor, identitatile partilor care discuta, marimea pachetelor, identificatori de flux etc.
Perfect Forward Secrecy
Se refera la faptul ca o singura cheie permite accesul la datele protejate de acea cheie. Pentru ca PFS sa existe, cheia folosita pentru a proteja transmisia datelor trebuie sa nu fie folosita pentru a deriva alte chei
ISAKMP
Ofera un cadru de lucru pentru autentificare si schimb de chei, dar nu le defineste. ISAKMP este destinat de a fi independent de schimbul de chei, mai exact, suporta mai multe metode de schimb de chei (key exchanges)
Oakley
Descrie o serie de metode de schimb de chei, numite moduri si detaliaza serviciile oferite de fiecare (de ex. PFS pentru chei, protejarea identitatii si autentificare).
SKEME
Descrie o tehnica versatila de schimb de chei care ofera anonimitate, rejectabilitate si regenerare rapida de chei.
Ceaparu M. - Comunicatia prin intermediul retelelor de calculatoare. Ed. Tehnica, 1996.
Stephen Northcutt - Inside Network Perimeter Security: The Definitive Guide to Firewalls, Virtual Private Networks (VPNs), Routers, and Intrusion Detection Systems
Oleg Kolesnikov - Building Linux Virtual Private Networks.
CISCO - Cisco - SAFE VPN IPSec Virtual Private Networks in Depth
FreeS/WAN HowTo
RFC‑urile: RFC 2401, RFC 2406
|
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 3119
Importanta: 
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved
