Securitatea In Retelele Tcp Ip

UNIVERSITATEA POLITEHNICĂ BUCUREȘTI

FACULTATEA DE ELECTRONICĂ, TELECOMUNICAȚII ȘI

TEHNOLOGIA INFORMAȚIEI

LUCRARE DE LICENȚĂ

Coordonator științific:

S.l. dr. ing. ADRIAN FLORIN PĂUN

Absolvent:

CONSTANTIN

MANEA

București

2013

1

SECURITATEA IN RETELELE

TCP/IP

2

3

CUPRINS:

1. Introducere

1.1 Tipuri de atacuri informatice

Considerații generale privind securitatea în rețelele IP

1.2.1 Servicii de Securitate

1.2.2 Mecanisme de securitate specific

1.2.3 Tehnici de securitate

1.2.3.1 Securitate prin firewall

1.2.3.2 Criptografia

1.2.3.3 Rețea Virtuală Privată

1.2.3.4 Securitatea la nivelul aplicație

2. Algoritmi de criptare

2.1 Introducere in criptografie

2.2 Algoritmi criptografici cu chei simerice

2.2.1 DES

2.2.2 Triplu DES

2.2.3 AES

2.2.4 IDEA

2.3 Algoritmi criptografici cu chei asimetrice

2.3.1 Algoritmul RSA

2.3.2 Algoritmul Diffie-Hellman

2.3.3 Semnaturi digitale

2.4 Concluzii

3. Securizarea comunicatiilor digitale prin intermediul VPN (Virtual Private

Network)

3.1 Tipuri de retele VPN

3.1.1 Remote VPN

3.1.2 Intranet VPN

3.1.3 Extranet VPN

3.2 Protocoale de tunelare

3.2.1 Protocoale de nivel 2 OSI

3.2.2 Protocoale de nivel 3 OSI

3.3 Standardizarea retelelor VPN – protocoalele ISAKMP si IPsec

3.3.1 Protocolul AH

3.3.2 Protocolul ESP

3.3.3 Protocolul IKE si IKEv2

3.4 Principalele avantaje ale rețelelor virtuale private

3.5 "Best practices" in retelele private virtuale

4. Metode de control al accesului la servicii prin schimb de chei de acces

4.1 SSL și TLS

4.2 Arhitectura TLS

4.2.1 Protocolul de Handshake TLS

4.3 Arhitectura SSL

4.3.1 Criptări folosite de SSL

4.3.1.1 Suite de cifruri cu chei RSA

4.3.2 Protocolul SSL de handshake

4

4.3.2.1 Autentificarea serverului

4.3.2.2 Autentificarea clientului

4.4 Atacuri rezolvate în SSL v3

4.5 Diferențe între SSL și TLS

4.6 Protocolul de login la distanță Secure Shell (SSH)

4.6.1 Arhitectura SSH

4.6.2 Protocolul SSH la nivel transport

4.6.3 Strategia SSH

5. Aplicatie: simularea unei retele VPN (remote VPN, Intranet VPN si Extranet

VPN)

Concluzii

Bibliografie

5

LISTA ACRONIME:

AAA= Authentication, Authorization and Accounting

AES =Advanced Encryption Standard

AH =Authentification Header

ASDL =Abstract-Type and Scheme-Definition Language

ATM =Asynchronous Transfer Mode

DES =Data Encryption Standard DSA =Digital Signature Algoritm DSS =Digital Signature Standard

ESP = Encapsulating Security Payload Protocol

ESP =Encapsulated Security Payload

FTP =File Transfer Protocol

GNS3 =Graphical Network Simulator

GRE =Generic Route Encapsulation

HMAC =Hash-Based Message Authentication Code

IDEA =International Data Encryption Algorithm

IETF =Internet Engineering Task Force

IKE =Internet Key Exchange

IP =Internet Protocol

IPsec =Internet Protocol Security

IPX =Internetwork Packet Exchange

ISAKMP =Internet Security Association and Key Management Protocol

ISDN =Integrated Services Digital Network

L2F =Layer 2 Forwarding

L2TP =Layer 2 Tunneling Protocol MD5 =Message Digest Algorithm 5

NAS =Network-attached Storage

NAT =Network Address Translation

NetBEUI =NetBIOS Enhanced User Interface

PGP =Pretty Good Privacy

PKCS = Public-Key Cryptography Standards

PPP =Point-to-Point Protocol

PPTP =Point-to-Point Tunneling Protocol

RSA = Rivest Shamir Adleman

S/MIME =Secure/Multipurpose Internet Mail Extensions

SHA =Secure Hash Algorithm SHA =Secure Hash Algorithm

SONET =Synchronous Optical Networking

SSL =Secure Sockets Layer

TCP/IP =Transmission Control Protocol/Internet Protocol

UDP =User Datagram Protocol

VLSI = Very Large Scale Integration

VPN =Virtual Private Network

WAN =Wide Area Network

6

1. INTRODUCERE

In primii ani ale existenței lor, rețelele de calculatoare au fost folosite de catre

cercetătorii din universități pentru trimiterea poștei electronice (serviciul de e-mail) sau pentru a permite conexiuni multiple la un server și de către funcționarii corporațiilor pentru a partaja imprimantele. În aceste condiții, problema securității nu atrăgea prea mult atenția. De aceea majoritatea protocoalelor de atunci nu aveau posibilitatea de a cripta datele (ex. Telnet, RIP, etc.).

Cu timpul, oamenii cu vazut potentialul extraordinar al retelelor de calculatoare si multiplele beneficii pe care le pot aduce: oamenii pot impartasi cunostinte, pot trimite poze, pot tine legatura cu persoanele dragi, putand chiar sa isi plateasca facturile sau sa plaseze comenzi de produse on-line, doar stand in fata computerului personal. Insa aceste beneficii aduc si o serie de consecinte negative. Potrivit buletinului de securitate Kaspersky numarul atacurilor informatice bazate pe browser (browser-based attacks) – cum ar fi phising, Java

exploits, cross-site scripting, etc. a crescut in 2012 de la 946,393,693 la 1 595 587 670.

Atunci cand oamenii folosesc Internet-ul aproape non-stop pentru a plati facturi, pentru a achizitiona diferite produse, pentru a posta poze personale sau pentru a trimite mesaje celor dragi si, in plus, folosesc parole simple si usor de ghicit la conturile pe care le detin, securitatea retelelor devine o mare problema potentiala.

Securitatea este un subiect vast si asigura o gama de imperfectiuni. In forma sa cea mai simpla ea asigura ca un raufacator nu va poate citi sau chiar modifica mesajele. De asemenea ea va poate garanta faptul ca atunci cand ati primit un mesaj de la persoana X, acel mesaj este intr-adevar de la acea persoana si nu de la un rauvoitor. Securitatea informatica este o arta. Trebuie asigurat un echilibru intre nevoia de comunicatii si conectivitate si, pe de

alta parte, necesitatea asigurarii confidentialitatii, integritatii si autenticitatii informatiilor.

Asa cum medicina incearca sa previna noi afectiuni in timp ce le trateaza pe cele actuale, securitatea informatica incearca sa previna potentiale atacuri in timp ce minimizeaza efectele atacurilor actuale.

7

1.1 Tipuri de atacuri informatice

Odata cu cresterea numarului de persoane care au avut acces la reteaua Internet a

crescut si numarul atacurilor. Primele atacuri au fost neintentionate, din pura curiozitate. De exemplu viermele Morris (creat de un student al universitatii Cornell pe nume Robert Tappan Morris in 1988) este considerat primul vierme distribuit pe Internet si totodata a atras prima condamnare la inchisoare din istoria SUA. Viermele Morris a fost scris (potrivit creatorului sau) pentru a masura Internetul, pentru a vedea cate calculatoare sunt conectate, si nu pentru a cauza distrugeri. Insa Morris nu a prevazut fiecare aspect al codului iar acest lucru a permis viermelui sau sa infesteze de mai multe ori un calculator ceea ce inseamna mai multe procese deschise ceea ce cauzeaza incetinirea substantiala a calculatorului pana la imposibilitatea de functionare. Dupa aceea au urmat Melissa Email Virus in 1999, in 2000 Mafiaboy DoS Attack, Love Bug Worm si a fost creat programul L0phtCrack, in 2001 Code Red DOS Attack a afectat 350.000 calculatoare si in 2004 o retea de botnets a lovit sistemele armatei SUA.

Astazi, sistemele informatice sunt amenintate atat din interior cat si din exterior, acest lucru fiind posibil deoarece, cu trecerea timpului, amenintarile devin din ce in ce mai sofisticate iar nivelul cunostintelor tehnice necesare pentru a le implementa scade. Pot fi persoane bine intentionate care fac diferite erori de operare sau persoane rau intentionate, care sacrifica timp si bani pentru penetrarea sistemelor informatice.

Dintre factorii tehnici care permit brese de securitate pot fi anumite erori ale software- ului de prelucrare sau de comunicare sau anumite defecte ale echipamentelor de calcul sau de comunicatie. De asemenea, lipsa unei pregatiri adecvate a administratorului, operatorilor si utilizatorilor de sisteme amplifica probabilitatea unor brese de securitate.

Un studiu din 2012 arata ca 70% dintre atacurile asupra unei retele sunt din interior. Ceea ce inseamna ca in aproape trei sferturi din cazuri atacurile asupra unei retele sunt accidentale ori s-au folosit de neglijenta angajatilor. Aceste tipuri de pericole pot fi inlaturate prin implementarea politicilor de securitate, asigurarea ca angajatii au inteles cum trebuiesc folosite resursele companiei si ca inteleg importanta parolelor de acces pe care le detin.

Restul de 30%, adica atacurile ce isi au originea in exterior, pot fi catalogate dupa cum

urmeaza:

– Virusi: constau in secvente de cod ce se ataseaza de programe sau fisiere executabile, de obicei la inceputul codului si cand este activat (atunci cand fisierul este executat sau la o anumita data si ora predefinita) verifica hard-disk-ul in cautarea altor

8

fisiere executable neinfestate inca. Pot avea efecte nedaunatoare, cum ar fi afisarea pe

ecran a unei poze, sau efecte daunatoare cum ar fi stergerea datelor de pe hard-disk. De asemenea pot fi programati sa isi modifice codul pentru a nu fi detectati.

– Viermi: sunt programe de sine statatoare ce ataca un sistem prin exploatarea unei

vulnerabilitati cunoscute, apoi scaneaza reteaua in cautarea unor noi sisteme pe care le ploate exploata si infesta iar in cele din urma executa codul daunator care de obicei consta in instalarea de "backdoors" pe sistem (modalitati prin care persoana care a creat sau folosit viermele poate avea acces la sistemul infestat ocolind sistemele de securitate.

– Cai troieni: sunt programe de sine statatoare ce desi par a indeplini o anumita functie legitima (un joc, un anumit program) executa in background secvente de cod ce exploateaza privilegiile utilizatorului ce l-a rulat. Desi programul legitim este inchis de utilizator, el ramane deschis si poate oferi creatorului sau acces pe calculatorul infestat, poate fura si trimite date sensibile (parole, conturi, etc), sterge sau corupe fisiere, opri programele antivirus/firewall sau incetini sau chiar opri activitatea retelei. – Atac de recunoastere: descoperirea si cartografierea neautorizata a sistemelor, serviciilor si vulnerabilitatilor unui sistem, ceea ce precede deseori alte tipuri de atacuri.

– Atac de tip acces: exploateaza vulnerabilitati cunoscute ale serviciilor de autentificare, FTP, servicii web, etc. pentru a capata acces la conturi web, baze de date sau alte informatii sensibile. De obicei implica un atac de tip dictionar (dictionary attack) sau de tip forta bruta (brute force) pentru a ghici parola de acces.

– Negarea serviciului: este poate cel mai des intalnit tip de atac si cel mai usor de realizat (de obicei cu ajutorul unor scripturi sau programe) si consta in trimiterea unui numar extrem de mare de cereri unui server/calculator pana cand acesta nu mai poate raspunde cererilor legitime.

9

1.2 Considerații generale privind securitatea în rețelele IP

Domeniul care se ocupă de studiul mecanismelor de protecție a informației în scopul

asigurării unui nivel de încredere în aceasta se numeste securitatea informatiei. Putem afirma că nivelul de încredere în informație depinde de nivelul mecanismelor de securitate care îi garantează protecția și de riscurile care apar asupra securității ei. Securitatea informației este un concept mai larg care se referă la asigurarea integrității, confidențialității și disponibilității

informației. [1]

1.2.1 Servicii de securitate

Din punctul de vedere al obiectivelor de securitate, se disting patru obiective majore

care sunt recunoscute de orice autor in domeniu. Fiecare din aceste servicii poate fi implementat la diverse nivele arhitecturale ale modelului OSI. Pentru a asigura securitatea unui nivel pot fi combinate unul sau mai multe servicii care la rândul lor pot fi compuse din câteva mecanisme.

Primul obiectiv este confidențialitatea informatiei, sau asigurarea faptului că informația rămâne accesibilă doar părților autorizate în acest sens. Acesta este cel mai vechi obiectiv al criptologiei. ilor unui sistem, ceea ce precede deseori alte tipuri de atacuri.

– Atac de tip acces: exploateaza vulnerabilitati cunoscute ale serviciilor de autentificare, FTP, servicii web, etc. pentru a capata acces la conturi web, baze de date sau alte informatii sensibile. De obicei implica un atac de tip dictionar (dictionary attack) sau de tip forta bruta (brute force) pentru a ghici parola de acces.

– Negarea serviciului: este poate cel mai des intalnit tip de atac si cel mai usor de realizat (de obicei cu ajutorul unor scripturi sau programe) si consta in trimiterea unui numar extrem de mare de cereri unui server/calculator pana cand acesta nu mai poate raspunde cererilor legitime.

9

1.2 Considerații generale privind securitatea în rețelele IP

Domeniul care se ocupă de studiul mecanismelor de protecție a informației în scopul

asigurării unui nivel de încredere în aceasta se numeste securitatea informatiei. Putem afirma că nivelul de încredere în informație depinde de nivelul mecanismelor de securitate care îi garantează protecția și de riscurile care apar asupra securității ei. Securitatea informației este un concept mai larg care se referă la asigurarea integrității, confidențialității și disponibilității

informației. [1]

1.2.1 Servicii de securitate

Din punctul de vedere al obiectivelor de securitate, se disting patru obiective majore

care sunt recunoscute de orice autor in domeniu. Fiecare din aceste servicii poate fi implementat la diverse nivele arhitecturale ale modelului OSI. Pentru a asigura securitatea unui nivel pot fi combinate unul sau mai multe servicii care la rândul lor pot fi compuse din câteva mecanisme.

Primul obiectiv este confidențialitatea informatiei, sau asigurarea faptului că informația rămâne accesibilă doar părților autorizate în acest sens. Acesta este cel mai vechi obiectiv al criptologiei. În rândul necunoscătorilor este încă larg răspândită opinia că noțiunea de criptografie este sinonimă cu confidențialitatea, sigur opinia este eronată pentru că criptografia se ocupă și de asigurarea multor alte obiective, ce vor fi enumerate în continuare, și care nu au nici o legătura cu păstrarea secretă a informației.

Integritatea face referire la asigurarea faptului că informația nu a fost alterată pe parcursul transmisiei sau de către un posibil adversar.

Autentificarea avand două coordonate distincte: autentificarea entităților și autentificarea informației. Autentificarea entităților se referă la existența unei garanții cu privire la identitatea unei anume entități. Autentificarea informației se referă la garantarea sursei de proveniență a informației – în mod implicit aceasta garantează și integritatea informației (este evident că asigurarea autenticității informației implică și asigurarea integrității acesteia). Autentificarea este în general strâns legată de un factor temporal, este evident că o informație stocată poate fi suspusă unui test de integritate pentru a se constata dacă a fost sau nu alterată dar nu poate fi supusă unui test de autenticitate dacă nu există o

10

garanție cu privire la momentul de timp la care entitatea de care este legată a depozitat-o

(deoarece în acest caz informația putea fi replicată și depusă de orice altă entitate).

Ultimul obiectiv este non-repudierea previne o entitate în a nega o acțiune întreprinsă (acțiune materializată desigur în transmisia unei informații). Aceasta înseamnă că dacă la un moment dat o entitate neagă ca ar fi emis o anume informație, entitatea care a primit informația respectivă poate demonstra unei părți neutre că informația provine într-adevăr de la

entitatea în cauză. [2]

1.2.2 Mecanisme de securitate specifice

OSI introduce opt mecanisme de securitate de bază, folosite individual sau combinat

pentru a construi servicii de securitate. Un exemplu bun ar fi, serviciul de nerepudiere cu probarea livrării poate fi realizat utilizând o combinatie potrivită a mecanismelor de integritate a datelor, semnătura digitală si notariat digital. În plus, un mecanism se poate baza pe un alt mecanism. De exemplu, mecanismul de autentificare a schimbului poate folosi mecanismul de criptare si, uneori, mecanismul de notariat (care presupune existenta unei a

treia părți, căreia i se acordă încredere).

Mecanismul de criptare are ca scop transformarea datelor astfel încât ele să devină

inteligibile numai de către entitatea autorizată (care, în general, păstrează o cheie secretă

pentru a le descifra) sau de a transforma datele într-o manieră unică, ce poate aparține numai

expeditorului. Numai entitatea autorizată, care deține o cheie secretă, le poate decripta și citi.

Acest mecanism este folosit pentru a furniza confidențialitate, dar el poate fi utilizat și pentru

asigurarea altor câtorva servicii de securitate. ISO acceptă în criptare atât algoritmi simetrici

cât si algoritmi nesimetrici (cu chei publice).

Mecanismul de semnătură digitală trebuie să garanteze că datele au fost produse chiar de către semnatar. Acest mecanism este deseori folosit de serviciile de integritate si

autentificare a originii datelor. Sunt definite două proceduri pentru acest mecanism:

• procedura de semnare a unei entităti de date; • procedura pentru verificarea semnăturii.

Folosinduse criptografia asimetrică, semnătura poate fi generată prin calcularea unei funcții

de dispersie pentru datele ce trebuie semnate, iar apoi, criptând valoarea rezultată folosindu-se

componenta privată a cheii asimetrice a semnatarului. Această valoare depinde de momentul

11

emiterii semnăturii, pentru a preveni falsificarea prin retransmitere a datelor respective,

precum și de conținutul mesajului. Semnătura trebuie produsă numai pe baza informațiilor

personale ale semnatarului (cheia sa privată a algoritmului de cifrare, de exemplu), în timp ce

procedura de verificare este făcută publică.

Mecanismul de control al accesului controlează accesul entităților la resurse,

presupunând cunoscută identitatea entității ce solicită accesul. Acțiunile se produc atunci când

este încercat un acces neautorizat, fie prin generarea unei alarme, fie prin simpla înregistrare a

incidentului. Politica de control al accesului poate fi bazată pe unul sau mai multe din

următoarele soluții:

• lista drepturilor de acces (entitate, resursă);

• parole;

• capabilități;

• etichete de securitate;

• durata accesului;

• timpul de încercare a accesului;

• ruta (calea de încercare a accesului).

Mecanismul de integritate a datelor are rolul de a asigura integritatea unităților de date (în întregime sau partial – numai un câmp), împiedicând modificarea, ștergerea sau

amestecarea datelor pe durata transmisiei. Acest mecanism presupune două proceduri:

• una pentru emisie. Expeditorul adaugă la unitatea de date o informație adițională care

depinde numai de datele transmise ("checkvalue" – o sumă de control criptată sau nu).

• una pentru receptie: partea receptoare generează aceeasi sumă de control care se compară cu cea primită.

Mecanismul de stampile de timp (time stamping) poate fi folosit pentru transmisiile

neorientate pe conexiune în scopul asigurării actualității datelor.

Mecanismul de autentificare mutuală este folosit pentru a dovedi, reciproc,

identitatea entităților. Se pot folosi pentru acestea parole sau tehnici criptografice (parole cifrate, cartele magnetice sau inteligente, caracteristici biometrice, biochimice). Când sunt folosite tehnicile criptografice, acestea sunt deseori combinate cu protocoale cu interblocare, "hand-shaking", pentru protectia împotriva înlocuirii (reluării) datelor. Principiul este următorul: entitatea A trimite identitatea sa (cifrată sau nu) entitătii B, care generează o valoare aleatoare si o trimite (cifrat sau nu) lui A. A trebuie să cifreze valoarea aleatoare cu cheia sa privată si să o trimită lui B, care va verifica corectitudinea acesteia.

12

Mecanismul de "umplere" a traficului este folosit pentru a asigura diferite nivele de

protecție împotriva analizei de trafic si implică una din următoarele metode:

• generarea unui trafic fals (rareori întrebuintată datorită costurilor pe care le implică);

• umplerea pachetelor de date transmise cu date redundante;

• transmiterea de pachete și spre alte destinații în afara celei dorite;

Mecanismul de control al rutării se bazează pe faptul că într-o rețea, anumite rute

pot fi considerate mai sigure față de altele; de aceea, acest mecanism permite a se alege, fie

într-un mod dinamic, fie într-un mod prestabilit, cele mai convenabile rute, în concordanță cu

criteriile de securitate (importanta datelor si confidentialitatea legăturii). Acest mecanism

trebuie folosit si ca suport pentru serviciile de integritate cu recuperarea datelor (de exemplu,

pentru a permite selecția unor rute alternative în vederea protejării în cazul unor atacuri ce ar perturba comunicația).

Mecanismul de notarizare. Acest mecanism presupune stabilirea unei a treia părți

(notar) în care au încredere toate entitățile, care au rolul de a asigura garanții în privința

integrității, originii sau destinatiei datelor. Atunci când se foloseste acest mecanism, datele

sunt transferate între entități prin intermediul notarului. [3]

1.2.3 Tehnici de securitate

Dupa momentul in care tehnicile de securitate au fost implementate intr-o retea,

informațiile nu vor mai putea fi accesate sau interceptate de persoane neautorizate și se va

impiedica falsificarea informațiilor transmise sau utilizarea clandestină a anumitor servicii

destinate unor categorii aparte de utilizatori ai rețelelor.

Tehnici specifice utilizate pentru implementarea securitatii unei retele:

• protecția fizică a dispozitivelor de rețea și a liniilor de transmisie la nivelul fizic;

• proceduri de blocare a accesului la nivelul rețele;

• transport securizat al datelor in spatiul public prin tunele de securizare sau VPN-uri;

• aplicarea unor tehnici de criptare a datelor.

Lipsa unei politici de securitate riguroasă poate duce ca diversele mecanisme de securitate sa poata fi aproape ineficiente intrucât nu ar corespunde strategiei si obiectivelor

pentru care a fost proiectată rețeaua. O politică corectă de securitate, include urmatoarele

nivele de securitate:

13

i) Primul nivel de securitate îl constituie un firewall pentru asigurarea unei

conexiuni sigure la Internet.

ii) Se poate folosi, de asemenea, transmisia datelor criptate printr-un tunnel de

securitate pe Internet prin crearea de rețele private virtuale. Criptarea datelor

conferă un al doilea nivel de securitate. Mai mult, se pot folosi asa numitele certificate

digitale pentru a se asigura comunicarea sigura cu partenerul dorit.

iii) Al treilea nivel de securitate este securitatea la nivelul aplicatie.

Desigur că uneori nu este nevoie de toate aceste măsuri de securitate; în funcție de importanța datelor vehiculate se poate opta fie pentru un nivel sau altul de securitate, fie

pentru toate trei la un loc. [4]

1.2.3.1 Securitate prin firewal

Firewall-ul este un sistem care impune o politică de control a accesului între două

rețele. Acesta reprezintă implementarea politicii de securitate în termeni de configurare a rețelei. Un firewall este un sistem plasat la granița dintre două rețele și posedă următoarele

proprietăți [5] :

• tot traficul dintre cele două rețele trebuie să treacă prin acesta;

• este permisă trecerea numai a traficului autorizat prin politica locală de securitate; • sistemul însuși este imun la încercările de penetrare a securității acestuia.

Cel care controlează accesul între Internet și o rețea privată este firewall-ul; fără el, fiecare stație din rețeaua privată este expusă atacurilor de penetrare inițiate din afara rețelei. Folosirea unui firewall pentru asigurarea securității rețelelor furnizează numeroase avantaje, ajutând și la creșterea nivelului de securitate al calculatoarelor componente dintre care vor fi enumerate doar cele mai importante: Concentrarea securității. Pentru a asigura securitatea unei rețele, un firewall poate fi o soluție mai puțin costisitoare din punctul de vedere al administrării în sensul că programele care trebuie modificate și software-ul adițional care trebuie instalat pot fi localizate (în totalitate sau în cea mai mare parte) în sistemul firewall, spre deosebire de situația în care acestea ar fi fost distribuit pe toate calculatoarele din rețea. Firewall-urile tind să fie mai ușor de implementat și administrat, software-ul specializat executându-se numai pe acestea.

14

Instituirea unei politici de acces în rețea. Un firewall furnizează mijloacele de

control al accesului într-o rețea privată. Unele calculatoare gazdă pot fi fi accesibile din

exterior, în timp ce altele pot fi protejate efectiv față de accesul nedorit

Protecția serviciilor vulnerabile. Dacă întregul trafic spre/dinspre Internet trece printr-un firewall, atunci există posibilitatea monitorizării acestuia și furnizării de statistici cu privire la folosirea rețelei. Colectarea de date privitoare la încercările de atac asupra rețelei permite verificarea rezistenței firewall-ului la asemenea încercări, iar realizarea de statistici este folositoare pentru analizarea riscurilor și pentru studiile de dezvoltare a rețelei. În afara avantajelor folosirii unui firewall există, de asemenea, o serie de dezavantaje și un număr de probleme de securitate, care nu pot fi rezolvate prin intermediul acestuia. Printre dezavantajele utilizării unui firewall se pot enumera: Restricționarea accesului la unele servicii. Un firewall impune, de cele mai multe ori, restricționarea sau blocarea accesului la unele servicii considerate vulnerabile, servicii care sunt însă solicitate intens de utilizatori (de

exemplu TELNET, FTP etc.)

Protecția scăzută față de atacurile provenite din interior. În general, un firewall nu asigură o protecție față de amenințările interne. Un firewall nu poate opri o persoană din interiorul rețelei de a copia informații și de a le furniza apoi celor interesați. Un firewall nu poate asigura protectie împotriva unor uși secrete existente într-o rețea, cum ar fi, de exemplu, permiterea nerestricționată a accesului prin modem la unele dintre calculatoarele interne. Este total nerecomandată investirea de resurse importante într-un firewall, dacă celelalte modalități posibile pentru furtul datelor sau pentru atac împotriva sistemului sunt neglijate.

Protecția scăzută față de viruși. Firewall-urile nu pot asigura protecție împotriva utilizatorilor care aduc local, din arhivele Internet, programe infectate de viruși. Din cauză că aceste programe pot fi codificate sau comprimate în mai multe moduri, un firewall nu le poate scana în scopul identificării semnăturilor virale. Această problemă a programelor infectate rămâne și va trebui rezolvată prin alte metode, din care cea mai recomandată ar fi instalarea unui software antivirus pe fiecare stație din rețea.

Viteza de comunicație cu exteriorul. Un firewall reprezintă o potențială limitare pentru traficul dintre rețeaua internă și exterior. Totuși, această limitare nu constituie o problemă în rețelele legate cu exteriorul prin linii de mare viteză.

Fiabilitatea protecției firewall. O rețea protejată prin firewall își concentrează securitatea într-un singur loc, spre deosebire de varianta distribuirii securității între mai multe sisteme. O compromitere a firewall-ului poate fi dezastruoasă pentru celelalte sisteme (mai puțin protejate) din rețea. Un contra-argument la acest dezavantaj constă în faptul că

15

incidentele de securitate apar, mai degrabă, pe măsură ce numărul de sisteme din rețea crește,

iar distribuirea securității între acestea face să crească modalitățile în care rețeaua poate fi atacată. În ciuda tuturor acestor probleme și dezavantaje, se recomandă ca protejarea resurselor unei rețele să se facă atât prin intermediul firewall-urilor, cât și al altor mijloace și

tehnici de securitate. [6]

1.2.3.2 Criptografia

"Criptografia înseamnă comunicare în prezența adversarilor". Ronald Rivest

Multe servicii și mecanisme de securitate folosite în Internet au la baza criptografia,

securizarea informației precum și autentificarea și restricționarea accesului într-un sistem informatic folosind metode matematice pentru transformarea datelor în intenția de a ascunde conținutul lor sau de a le proteja împotriva modificării.

Criptografia, folosită intr-un protocol de securitate, vrea să asigure dezideratele

mentionate mai sus, fundamentale pentru securitatea informatiei: confidențialitate, integritatea

datelor, autenticitatea si ne-repudierea. Criptarea este o metodă de protejare a informațiilor

sensibile stocate în sistemele de calcul, dar și a celor care sunt transmise pe liniile de

comunicație. Informațiile care sunt criptate ramân sigure chiar dacă sunt transmise printr-o rețea care nu oferă o securitate puternică. Cea mai populară metodă de protecție, atât pentru comunicații, cât și pentru datele cu caracter secret a devenit criptarea. Rețeaua Internet, spre

exemplu, oferă servicii de criptare utilizatorilor săi. Cu cat se avanseaza si se constientizeaza

beneficiile aduse de utilizarea criptării, a dezavantajelor lipsei de protecție a informatiilor și a faptului că tehnologia de criptare a devenit mai accesibilă, criptarea devine o metoda atractivă de protejare a datelor, indiferent că este vorba de date secrete transmise prin rețea sau date obișnuite stocate în sistemul de calcul. Este impresionant numarul mare de folosire a noțiunii de criptare-decriptare când este vorba de securitatea datelor. [6] Tehnologia de criptare asigurã cã mesajele nu sunt interceptate sau citite de altcineva decât destinatarul autorizat. Criptarea este folositã pentru a proteja date care sunt transportate printr-o retea publicã, si foloseste algoritmi matematici avansati pentru a cifra mesajele si documentele atasate. Existã mai multe tipuri de algoritmi de criptare, dar unii sunt mai siguri decât altii. În cei mai multi algoritmi, datele originale sunt criptate folosind o anumitã cheie de criptare, iar computerul

16

destinatar sau utilizatorul pot descifra mesajul folosind o cheie de decriptare specificã.[1]

Riscurile de securitate, ca orice alte riscuri de altfel, trebuie acoperite cu garanții de securitate. Atunci când obiectul manipulat este informația singura garanție poate fi oferită de către

criptografie, deci rolul acesteia este de a oferi garanții în fața riscurilor de securitate.

1.2.3.3 Rețea Virtuală Privată

O tehnologie de comunicații computerizata sigură, dar bazată pe o rețea publică poarta

numele de rețea privată virtuală, din cauza acestui fapt nu este foarte sigură. Tehnologia VPN este concepută tocmai pentru a crea într-o rețea publică o subrețea de confidențialitate aproape la fel de înaltă ca într-o rețea privată adevărată la care sunt legați numai utilizatori autorizați. În mod intenționat această subrețea, denumită totuși "rețea VPN", nu poate comunica cu celelalte sisteme sau utilizatori ai rețelei publice de bază. Utilizatorii unei rețele VPN pot căpăta astfel impresia că sunt conectați la o rețea privată dedicată, independentă, cu toate avantajele pentru securitate, rețea care în realitate este doar virtuală, ea de fapt fiind o subrețea înglobată fizic în rețeaua de bază. [7] Tehnologia VPN folosește o combinație de tunneling, criptare, autentificare și mecanisme și servicii de control al accesului, folosite pentru a transporta traficul pe Internet. Retelele private virtuale au fost create din dorinta de a avea o mai bună securitate asupra informatiilor transmise de către utilizatori prin retea. Tehnologiile VPN oferă o cale de a folosi infrastructurile rețelelor publice cum ar fi Internetul pentru a asigura acces securizat și privat la aplicații și resurse ale companiei.

1.2.3.4 Securitatea la nivelul aplicație

Se asigură implementarea tuturor serviciilor de securitate datorita nivlului aplicatiei,

chiar mai mult, unele, de exemplu, nerepudierea mesajelor poate fi realizată numai la acest nivel. Un avantajul major al asigurării securității la acest nivel este independența de sistemele de operare și de protocoalele utilizate pe nivelele inferioare. Dar obligatoriu, trebuie menționat faptul că la acest nivel securitatea este dependentă de aplicație, adica trebuie implementată individual pentru fiecare aplicație.

17

2. ALGORITMI DE CRIPTARE

Criptologia este considerată ca fiind cu adevărat o știință de foarte puțin timp. Aceasta

cuprinde atât criptografia – scrierea secretizată – cât și criptanaliza. De asemenea, criptologia

reprezintă nu numai o artă veche, ci și o știința nouă: veche pentru că este utilizata de pe

timpul lui Iulius Cezar, dar nouă pentru că a devenit o temă de cercetare academico-științifică

abia începând cu anii 1970. Această disciplină este legată de multe altele, de exemplu de

teoria numerelor, algebră, teoria complexității, informatică.

Criptografia este definită ca fiind studiul tehnicilor matematice referitoare la aspecte de

securitatea informației precum confidențialitate, integritate, autentificarea entităților,

autentificarea provenienței datelor. [9]

2.1 Introducere in criptografie

Atunci când trimit o scrisoare prin poștă, majoritatea oamenilor obișnuiesc să sigileze

plicul. Dacă i-am întreba de ce fac asta, probabil că mare parte dintre ei ar spune fie că acționează din reflex sau că fac la fel ca toată lumea, fie că lipirea plicului împiedică scrisoarea să se rătăcească. Chiar dacă plicurile nu conțin informații personale sau strict secrete, mulți speră ca scrierile lor să nu fie citite decât de destinatar, motiv pentru care ei aleg să sigileze plicurile. Cu toate acestea, dacă cineva își dorește cu adevărat să citească conținutul unei scrisori care nu îi aparține, ar putea să o facă foarte ușor, rupând plicul. La fel se întâmplă și în cazul email-urilor, care ar putea fi citite cu ușurință de unii programatori iscusiți.

Pentru a evita astfel de neplăceri, am putea opta pentru criptografie, metoda de codare care ne asigură că scrisoare va rămâne inteligibilă pentru intruși, măcar o perioadă de timp, până când aceștia reușesc să găsească cheia.

Criptografia reprezintă o ramură a matematicii care se ocupă cu securizarea

informației precum și cu autentificarea și restricționarea accesului într-un sistem informatic.

În realizarea acestora se utilizează atât metode matematice (profitând, de exemplu, de

dificultatea factorizării numerelor foarte mari), cât și metode de criptare cuantică. Termenul criptografie este compus din cuvintele de origine greacă „ascuns" și „a scrie".

Prin sistem criptografic, sau simplu criptosistem, înțelegem un ansamblu format din

trei algoritmi, lucru sugerat in figura 2.1:

• un algoritm de generare a cheilor (cheie de criptare și cheie de decriptare)

18

• un algoritm de criptare – procesul prin care mesajul este transformat in mesaj cifrat,

utilizand un algoritm de criptare si o cheie de criptare specifică

• un algoritm de decriptare – proces invers criptării, prin care mesajul cifrat este tranformat in

mesajul initial, original, utilizând o funție de decriptare si o cheie de decriptare.

Figura 2.1. Sistem Criptografic

Elementele care au marcat cotitura semnificativă în dezvoltarea metodelor

criptografice :

• primul este legat de dezvoltarea rețelelor de calculatoare, al căror stimulent extraordinar s-a manifestat atât prin presiunea exercitată de tot mai mulți utilizatori cât și prin potențarea gamei de instrumente folosite efectiv în execuția algoritmilor de cifrare. Utilizarea calculatoarelor electronice a permis folosirea unor chei de dimensiuni mai mari, sporindu-se astfel rezistența la atacuri criptoanalitice. Când cheia secretă are o dimensiune convenabilă și este suficient de frecvent schimbată, devine practic imposibilă spargerea cifrului, chiar dacă se cunoaște algoritmul de cifrare.

• al doilea moment important în evoluția criptografiei moderne l-a constituit adoptarea unui principiu diferit de acela al cifrării simetrice. Whitfield Diffie și Martin Hellman au pus bazele criptografiei asimetrice cu chei publice. În locul unei singure chei secrete, criptografia asimetrică foloseste două chei diferite, una pentru cifrare, alta pentru descifrare. Deoarece este imposibilă deducerea unei chei din cealaltă, una din chei este făcută publică fiind pusă la îndemâna oricui dorește să transmită un mesaj cifrat. Doar destinatarul, care deține cea de-a

19

doua cheie, poate descifra și utiliza mesajul. Tehnica cheilor publice poate fi folosită și pentru

autentificarea mesajelor, fapt care i-a sporit popularitatea.

Criptografia stă la baza multor servicii și mecanisme de securitate folosite în Internet, securizarea informației precum și autentificarea și restricționarea accesului într-un sistem informatic folosind metode matematice pentru transformarea datelor în intenția de a ascunde conținutul lor sau de a le proteja împotriva modificării.

2.2 Algoritmi criptografici cu chei simerice

Criptografia cu chei simetrice se referă la metode de criptare în care atât trimițătorul

cât și receptorul folosesc aceeași cheie (sau, mai rar, în care cheile sunt diferite, dar într-o

relație ce la face ușor calculabile una din cealaltă). Acest tip de criptare a fost singurul

cunoscut publicului larg până în 1976.

Pentru asigurarea confidențialității datelor memorate in calculatoare sau transmise prin

retele se folosesc preponderent algoritmi criptografici cu cheie secretă (simetrici). Ei se

caracterizează prin aceea că atât pentru criptare cât și pentru decriptare este utilizată aceeași

cheie secretă. Cheia de criptare este necesar de păstrat in secret față de utilizatorii

neautorizati, pentru ca cel ce are acces la acesta cheie poate avea acces si la informația

secretă. Algoritmii criptografici simetrici se caracterizează printr-o viteza de cifrare foarte

mare, in comparație cu algoritmii criptografici asimetrici și sunt comozi la cifrarea blocurilor

mari de informație. Securitatea acestui tip de algoritm depinde in mare masură de lungimea

cheii si posibilitatea de a o păstra secreta.

Algoritmii criptografici cu chei simetrice se utilizează în special în cazul transferului unei cantități mari de date. În cadrul acestui tip de algoritmi se pot folosi cifruri secvențiale sau cifruri bloc [10]. Mesajul este criptat la nivel de octect de catre cifrurile secvențiale, pe rând, unul câte unul. Se utilizează un generator de numere pseudoaleatoare care este inițializat cu o cheie și generează ca rezultat o secvență de biți denumită cheie secvențială. Cifrarea se poate face si cu sincronizare (în cazul în care cheia secvențială depinde de textul în clar), respectiv fără sincronizare. Cele mai utilizate sunt cifrurile fără sincronizare. Pentru fiecare octet al textului în clar și cheia secvențială se aplică operația XOR (sau exclusiv). Fiind un algoritm simetric, la decriptare se utilizează operația XOR între biții textului cifrat și cheia secvențială, astfel obținându-se textul în clar. Cifrurile bloc criptează mesajul în blocuri de 64

20

sau 128 de biți. Se aplică o funcție matematică între un bloc de biți ai mesajului în clar și

cheie (care poate varia ca mărime), rezultând același număr de biți pentru mesajul criptat.

Funcția de criptare este realizată astfel încât să îndeplinească următoarele cerințe:

• știind un bloc de biți ai textului în clar și cheia de criptare, sistemul să poată genera

rapid un bloc al textului criptat;

• știind un bloc de biți ai textului criptat și cheia de criptare/decriptare, sistemul să

poată genera rapid un bloc al textului în clar;

• știind blocurile textului în clar și ale textului criptat, sistemului să-i fie dificil să genereze cheia.

Avantajul consta in faptul ca utilizarea cifrurilor în bloc este mai sigură decât utilizarea cifrurilor secvențiale, deoarece fiecare bloc este procesat în parte.

Dezavantajeste faptul ca algoritmii care folosesc cifruri bloc sunt mai lenți decât algoritmii care folosesc cifruri secvențiale.

2.2.1 Algoritmul DES

Standardul de Criptare a Datelor (în engleză Data Encryption Standard, DES) este un

cifru (o metodă de criptare a informației), selectat ca standard federal de procesare a

informațiilor în Statele Unite în 1976, și care s-a bucurat ulterior de o largă utilizare pe plan

internațional. Algoritmul a fost controversat inițial, având elemente secrete, lungimea cheii scurtă și fiind bănuit că ascunde de fapt o portiță pentru NSA.

DES a fost analizat intens de către profesionaliști în domeniu și a motivat înțelegerea

cifrurilor bloc și criptanaliza lor.

DES este astăzi considerat nesigur pentru multe aplicații. Acest lucru se datorează în

principiu cheii de 64 de biți (dintre care doar 56 de biti sunt folositi propriu-zis de algoritm,

restul de 8 fiind folositi ca biti de paritate), considerată prea scurtă; cheile DES au fost sparte

în mai puțin de 24 de ore.

De asemenea, există unele rezultate analitice care demonstrează slăbiciunile teoretice

ale cifrului, deși nu este fezabilă aplicarea lor. Se crede că algoritmul este practic sigur în forma Triplu DES, deși există atacuri teoretice și asupra acestuia.

DES este alcătuit din 16 pasi identici de procesare, numiti runde, care produc textul cifrat. În urma studiilor s-a concluzionat că numărul de runde este exponential proportional cu

21

timpul necesar aflării cheii secret folosind atacul de tip forță brută. Pe măsură ce crește

numărul de runde, securitatea algoritmului creste exponential.

Pașii de procesare sunt prezentati in figura 2.2:

1. Textul în clar este împărțit în blocuri de 64 biți.

2. Din cheia de 56 biți se generează 16 chei de 48 biți. Cheia de 56 biți folosită pentru

criptare este în realitate folosită doar la generarea primei sub-chei și nu este folosită în mod direct pentru criptarea datelor.

3. Textul în clar, o dată împărțit în blocuri, este supus unui proces de permutare bazat pe un table care specifică modul în care biții sunt permutați: bitul unul este mutat pe poziția bitului 40, bitul 2 pe poziția 23 etc.

4. După realizarea permutării, biții sunt trecuți prin cele 16 runde, folosind câte una din cele 16 sub-chei generate.

5. Cei 64 biți creați la pasul 3 sunt pasați unei runde, unde sunt împărțiți în 2 blocuri de câte 32 biți și procesați cu cheia corespunzătoare rundei respective.

6. Pasul 4 este repetat de 16 ori. Rezultatul unei runde este livrat următoarei runde.

7. După terminarea celei de-a 16-a runde, cele 2 jumătăți de câte 32 biți sunt lipite,

rezultând un bloc de 64 biți.

8. Blocul de 64 biți este din nou permutat, folosind funcția inversă celei de la pasul 3.

Faptul ca nu se ridică probleme deosebite într-o implementare software, este datorită

ca lungimii cheii de lucru și a operațiilor elementare pe care le folosește algoritmul; singura observație este că, datorită modulului de lucru (cu secvențe de date, cu tabele) practic algoritmul este lent într-o implementare software. Modul de concepere îl face însă perfect implementabil hard (într-un cip) ceea ce s-a și realizat, existând multiple variante de mașini hard de codificare.

22

Figura 2.2. Algorimul DES

23

2.2.2 Triplu DES

3DES, numit și Triple DES, este un cifru bloc care aplică de 3 ori DES, asa cum se

poate observa in figura 2.3. In momentul cand s-a observat că aceste chei de 56 biți folosite de

DES nu sunt suficiente pentru a proteja datele împotriva atacurilor de tip forță brută, 3DES a

fost soluția pentru mărirea spațiului cheilor fără a schimba algoritmul.

Figura 2.3. Algorimul Triplu DES

Triple DES, cu 3 chei diferite de 56 biți are o lungime a cheii de 168 biți. Datorită

atacurilor "meet-in-the-middle" (un atac generic, aplicabil mai multor sisteme criptografice),

securitatea efectivă este doar de 112 biți.

2.2.3 Algoritmul AES

AES (de la Advanced Encryption Standard – în limba engleză, Standard Avansat de

Criptare), cunoscut și sub numele de Rijndael, este un algoritm standardizat pentru criptarea simetrică, pe blocuri, folosit astăzi pe scară largă în aplicații și adoptat ca standard de

organizația guvernamentală americană NIST (National Institute of Standards and Technology

– Institutul National pentru Standarde si Tehnologie). Standardul oficializează algoritmul

dezvoltat de doi criptografi belgieni, Joan Daemen și Vincent Rijmen și trimis la NIST pentru

selecție sub numele Rijndael.

24

În propunerea avansată NIST, cei doi autori ai algoritmului Rijndael au definit un

algoritm de criptare pe blocuri în care lungimea blocului și a cheii puteau fi independente, de

128 de biți, 192 de biți, sau 256 de biți. Specificația AES standardizează toate cele trei

dimensiuni posibile pentru lungimea cheii, dar restricționează lungimea blocului la 128 de

biți. Astfel, intrarea și ieșirea algoritmilor de criptare și decriptare este un bloc de 128 de biți. În publicația FIPS numărul 197, operațiile AES sunt definite sub formă de operații pe matrice,

unde atât cheia, cât și blocul sunt scrise sub formă de matrice. La începutul rulării cifrului,

blocul este copiat într-un tablou denumit stare (în engleză state), primii patru octeți pe prima

coloană, apoi următorii patru pe a doua coloană, și tot așa până la completarea tabloului.

Algoritmul modifică la fiecare pas acest tablou de numere denumit stare, și îl furnizează apoi ca ieșire.

Pasii sunt urmatorii:

1) Pasul SubBytes

Figura 2.4 Pasul SubBytes

Pasul SubBytes este un cifru cu substituție, figura 2.4., fără punct fix, denumit

Rijndael S-box, care rulează independent pe fiecare octet din state. Această transformare este

neliniară și face astfel întreg cifrul să fie neliniar, ceea ce îi conferă un nivel sporit de securitate.

Fiecare octet este calculat astfel:

unde bi este bitul corespunzător poziției i din cadrul octetului, iar ci este bitul corespunzător

poziției i din octetul ce reprezintă valoarea hexazecimală 63, sau, pe biți, 01100011.

Maparea octeților se poate reține într-un tabel, explicitat în FIPS PUB 197, în care este

specificat rezultatul operației de mai sus efectuată pe fiecare din cele 256 de valori posibile

reprezentabile pe un octet.

25

2) Pasul ShiftRows

Figura 2.5 Pasul ShiftRows

Pasul ShiftRows, figura 2.5., operează la nivel de rând al matricii de stare state. Pasul

constă în simpla deplasare ciclică a octeților de pe rânduri, astfel: primul rând nu se

deplasează; al doilea rând se deplasează la stânga cu o poziție; al treilea rând se deplasează la

stânga cu două poziții; al patrulea se deplasează la stânga cu trei poziții. Rezultatul acestui pas este că fiecare coloană din tabloul state rezultat este compusă din octeți de pe fiecare coloană

a stării inițiale. Acesta este un aspect important, din cauză că tabloul state este populat inițial

pe coloane, iar pașii ulteriori, inclusiv AddRoundKey în care este folosită cheia de criptare,

operațiile se efectuează pe coloane.

3) Pasul MixColumns

Figura 2.6 Pasul MixColumns

În acest pas, figura 2.6., fiecare coloană a tabloului de stare este considerată un

polinom de gradul 4 peste corpul Galois . Fiecare coloană, tratată ca polinom, este

26

înmulțită, modulo cu polinomul . Operația se poate

scrie ca înmulțire de matrice astfel:

unde sunt elementele de pe un vector coloană rezultate în urma înmulțirii, iar sunt

elementele de pe același vector înaintea aplicării pasului.

Rezultatul are proprietatea că fiecare element al său depinde de toate elementele de pe coloana stării dinaintea efectuării pasului. Combinat cu pasul ShiftRows, acest pas asigură că

după câteva iterații, fiecare octet din stare depinde de fiecare octet din starea inițială (tabloul

populat cu octeții mesajului în clar). Acești doi pași, împreună, sunt principala sursă de

difuzie în algoritmul Rijndael. Coeficienții polinomului a(x) sunt toți 1, 2 și 3, din motive de performanță, criptarea fiind mai eficientă atunci când coeficienții sunt mici. La decriptare,

coeficienții pasului corespunzător acestuia sunt mai mari și deci decriptarea este mai lentă

decât criptarea. S-a luat această decizie pentru că unele din aplicațiile în care urma să fie

folosit algoritmul implică numai criptări, și nu și decriptări, deci criptarea este folosită mai

des.

4) Pasul AddRoundKey și planificarea cheilor

Figura 2.7 Pasul AddRoundKey

27

În pasul AddRoundKey, figura 2.7., se efectuează o operație de sau exclusiv pe biți

între octeții stării și cei ai cheii de rundă.

Pasul AddRoundKey este pasul în care este implicată cheia. El constă într-o simplă

operație de „sau" exclusiv pe biți între stare și cheia de rundă (o cheie care este unică pentru

fiecare iterație, cheie calculată pe baza cheii secrete). Operația de combinare cu cheia secretă

este una extrem de simplă și rapidă, dar algoritmul rămâne complex, din cauza complexității

calculului cheilor de rundă (Key Schedule), precum și a celorlalți pași ai algoritmului.

2.2.4 IDEA

International Data Encryption Algorithm (Algoritmul IDEA) este un cod bloc simetric

dezvoltat de Xuejia Lai și James Massey de la Institutul Federal al Tehnologiei din Elveția în anul 1990. El este patentat în Europa și în Statele Unite, dar poate fi utilizat gratuit în aplicații necomerciale. IDEA este unul dintre algoritmii care a fost propus pentru a înlocui DES. Acesta este unul dintre cei mai reușiți algoritmi din cei propuși (până în prezent nu a fost raportat nici un atac pentru decriptare reușit). De exemplu IDEA este inclus în PGP (Pretty Good Privacy) care a contribuit la răspândirea acestuia. IDEA este un cod bloc care folosește o cheie de 128 biți pentru a cripta blocuri de date de 64 de biți. Detaliile de proiectare a acestui algoritm sunt prezentate în cele ce urmează: Lungimea blocului: Lungimea blocului trebuie să fie destul de mare pentru a împiedica analiza statistică. In alta ordine de ider complexitatea implementării algoritmului de criptare crește exponențial cu lungimea blocului. Folosirea unui bloc de 64 biți este în general destul de puternică. Lungimea cheii: Lungimea cheii trebuie să fie destul de mare pentru a preveni căutarea exhaustivă. Confuzia: Legătura dintre mesajul original și cheie în mesajul criptat trebuie să fie cât mai complicată. Obiectivul este de a complica cât mai mult determinarea unor statistici din mesajul criptat care au legătură cu mesajul original. În acest scop IDEA folosește trei operații diferite spre deosebire de DES care se bazează pe operatorul XOR și pe cutiile S (S-boxes). Difuzia: Fiecare bit din mesajul original trebuie să influențeze toți biții mesajului criptat și orice schimbare din cheie să influențeze orice bit din mesajul criptat. Această tehnică ascunde structura statistică a mesajului original. Din acest punct de vedere, IDEA este foarte eficace.

28

Revenind la ultimele două puncte, confuzia este obținută prin trei operații diferite.

Fiecare dintre aceste operații este aplicată pe două segmente de intrare de 16 biți, producând o

singură ieșire pe 16 biți. Aceste operații sunt:

• XOR (sau-exclusiv) pe biți.

• Adunarea de întregi modulo 216 (modulo 65 536) cu intrări și ieșiri tratate ca întregi

pe 16 biți fără semn.

• Multiplicarea de întregi modulo 216+1 (modulo 65 537) cu intrări și ieșiri tratate ca întregi pe 16 biți fără semn.

IDEA este relative usor de implementat atât software cât și hardware. Implementarea hardware (de obicei în VLSI) este proiectată pentru a obține o viteză foarte mare, în schimb cea software este mult mai flexibilă și mai ieftină. Principii de proiectare a implementării

software:

• Se folosesc subblocuri: algoritmul poate opera cu subblocuri de 8, 16, 32 biți. Dimensiunea tipică este de 16 biți.

• Se folosesc operații simple: implementarea celor trei operații ce intervin în algoritmul IDEA se face pe baza operațiilor primitive la nivel de bit (adunare, deplasare, etc.).

Principii de proiectare a implementării hardware:

• Criptarea și decriptarea sunt similare. Ele diferă doar prin ordinea folosirii subcheilor

astfel încât același dispozitiv poate fi folosit atât pentru criptare, cât și pentru decriptare.

• Structură modulară: algoritmul trebuie să aibă o structură modulară care să faciliteze implementarea VLSI. IDEA este construit din două blocuri modulare de bază repetate de mai multe ori.

Schema bloc pentru criptarea IDEA este ilustrată în figura 2.8. Ca și în orice schemă de criptare, există două intrări: mesajul original și cheia de criptare. În acest caz, primul are lungimea de 64 biți, iar cheia este de 128 biți.

Urmărind partea stângă a figurii, se observă că algoritmul constă din 8 ture (runde) urmate de o transformare finală. Cei 64 biți de la intrare sunt divizați în 4 subblocuri de câte 16 biți. Fiecare tură are ca intrare 4 subblocuri de 16 biți producând la ieșire tot 4 subblocuri de 16 biți. Aceeași regulă este valabilă și pentru transformarea finală, diferența fiind doar la ieșire unde cele 4 subblocuri sunt concatenate pentru a forma mesajul criptat. De asemenea fiecare tură folosește șase subchei de 16 biți, iar transformarea finală doar 4 subchei, în total fiind folosite 52 subchei. În partea dreaptă a figurii se observă că toate aceste subchei sunt generate din cheia originală de 128 biți.

29

Figura 2.8. Schema bloc a algoritmului IDEA

30

2.3 Algoritmi criptografici cu chei asimetrice

Criptografia asimetrică este un tip de criptografie care utilizeaza o pereche de chei: o

cheie publică și o cheie privată. Un utilizator care deține o astfel de pereche își publică cheia

publică astfel încat oricine dorește să o poata folosi pentru a îi transmite un mesaj criptat.

Numai deținătorul cheii secrete (private) este cel care poate decripta mesajul astfel criptat.

Matematic, cele două chei sunt legate, însă cheia privată nu poate fi obținută din cheia

publică. In caz contrar, orcine ar putea decripta mesajele destinate unui alt utilizator, fiindcă oricine are acces la cheia publică a acestuia.

O analogie foarte potrivită pentru proces este folosirea cutiei poștale. Oricine poate pune în cutia poștală a cuiva un plic, dar la plic nu are acces decât posesorul cheii de la cutia poștală.

Cripografia asimetrică se mai numește criptografie cu chei publice.

Metodele criptografice în care se folosește aceeași cheie pentru criptare și decriptare

sunt metode de criptografie simetrică sau criptografie cu chei secrete. Sistemele de criptare cu chei simetrice folosesc o singură cheie, atât pentru criptare cât și pentru decriptare. Pentru a putea folosi această metodă atât receptorul cât și emițătorul ar trebui sa cunoască cheia secretă. Aceasta trebuie sa fie unica pentru o pereche de utilizatori, fapt care conduce la probleme din cauza gestionarii unui numar foarte mare de chei. Sistemele de criptare asimetrice inlatura acest neajuns. De asemenea, se elimina necesitatea punerii de acord asupra

unei chei comune, greu de transmis in conditii de securitate sporita intre cei 2 interlocutori.

Cele două mari ramuri ale criptografiei asimetrice sunt:

1.Criptarea cu cheie publică – un mesaj criptat cu o cheie publică nu poate fi

decodificat decat folosind cheia privată corespunzătoare. Metoda este folosită pentru a asigura

confidențialitatea.

2.Semnături digitale – un mesaj semnat cu cheia privata a emițătorului poate fi

verificat de catre oricine, prin acces la cheia publica corespunzatoare, astfel asigurandu-se

autenticitatea mesajului.

O analogie pentru semnăturile digitale ar fi sigilarea unui plic folosind un sigiliu personal. Plicul poate fi deschis de oricine, dar sigiliul personal este cel care verifică autenticitatea plicului.

O problema majoră în folosirea acestui tip de criptare este increderea (dovada) că cheia publica este corectă, autentică și nu a fost interceptată sau înlocuită de o a treia parte rău voitoare. În mod normal problema este rezolvată folosind infrastructura cu cheie publică

31

(PKI) în care una sau mai multe persoane asigură autenticitatea cheilor pereche. O altă

abordare folosită de PGP (Pretty Good Privacy) este cea a conceptului web of trust .

2.3.1 Algoritmul RSA

Algoritmul RSA a fost publicat pentru prima oară în 1977 de R. Rivest, A. Shamir și

L. Adleman în revista "Scientific American" Sistemele de tipul RSA fac parte din categoria sistemelor criptografice cu cheie publică. Securitatea algoritmului se bazează pe problema factorizării numerelor foarte mari. Algoritmul poate fi utilizat pentru operatii de: criptare/decriptare, semnare/verificare semnatura, asigurarea integritatii datelor (prin semnare), schimb de chei. El este întâlnit în servere și browsere de web, în clienți și servere de e-mail, reprezentând practic coloana vertebrală a sistemului de plăți electronice prin card-

uri de credit. [8] Algoritmul funcționează după cum urmează: [11]

• Se generează două numere prime p și q, de lungime biti. Deoarece mulțimea numerelor prime este suficient de densă, numerele prime pot fi generate alegând aleator numere întregi

de n/2 biți și testându-le cu ajutorul unui test probabilistic. Apoi, fie

de lungime n biți.

• Numărul e trebuie ales astfel încât să îndeplinească următoarele condiții:

iar e și

să fie relativ prime, sau altfel spus, să nu aibă factori primi în comun.

• Se calculează d cu ajutorul algoritmului euclidian extins, astfel încât acesta să fie multiplul

invers al lui e sau altfel spus

32

să fie divizibil cu

În practică, d se poate obține foarte simplu căutând rezolvarea

astfel încât d și x să fie numere întregi. Valorile d și e sunt numite exponentul privat, respectiv

exponentul public al algoritmului.

• Funcția de criptare/semnare arată astfel:

unde M reprezintă mesajul de criptat (un întreg pozitiv mai mic decât N). • Funcția de

decriptare/verificare arată astfel:

unde C reprezintă textul criptat. Cheia publică este reprezentată de perechea (N, e), iar cheia

privată de perechea (N, d). Numărul d mai este cunoscut și sub numele de "trap door", deoarece cunoașterea sa permite inversarea rapidă a funcției RSA. Viteza algoritmului RSA depinde în mare măsură de lungimea cheilor utilizate, de tipul de implementare, de procesorul pe care se rulează aplicația, dar și de protocolul ce trebuie implementat. Deseori, pentru a obține o viteză sporită în aplicațiile practice, sunt utilizați exponenți publici mici, acest fapt implicând însă și riscuri corespunzătoare. Există chiar grupuri întregi de utilizatori care folosesc același exponent public, doar modulul N fiind diferit. În acest caz există însă reguli stricte ce trebuiesc respectate pentru cele două numere prime p și q, astfel încât siguranța algoritmului să nu fie periclitată.

Utilizând, cum spuneam, exponenți publici mici, se obține o viteză mai mare de criptare și verificare în comparație cu procesele inverse de decriptare și semnare a datelor.

33

Utilizând algoritmii generali de calcul ai exponențialului, operațiile cu cheie publică consumă

un timp proporțional cu O(n²) iar operațiile cu cheie privată necesită aproximativ O(n³) , unde n reprezintă numărul de biți ai lui N. Tehnicile de multiplicare rapidă, necesită de obicei mai puțini pași, sunt însă destul de rar folosite datorită complexității lor, și a faptului că pentru lungimi tipice de chei, ele sunt totuși mai lente.

Dacă comparăm viteza algoritmului RSA cu cea a unui algoritm cu cheie simetrică (DES de exemplu), putem observa că în funcție de implementare (HW sau SW) cel din urmă este cu până la aproximativ 1000 de ori mai rapid decât RSA. Cu toate acestea, utilizarea RSA în algoritmi de distribuire de chei (simetrice) sau în alte aplicații, în care viteza este mai puțin importantă, prezintă avantaje de netăgăduit. Securitatea sistemelor RSA se bazează pe

presupunerea că funcția:

este unidirecțională, fiind computațional dificil de a se găsi mesajul inițial M în absența

exponentului de decriptare d. Există însă posibilitatea, cel puțin teoretică, de a încerca factorizarea lui N prin metoda forței brute sau prin alte metode, fapt ce ar duce la aflarea numerelor p și q. Apoi utilizând algoritmul euclidian extins se poate calcula exponentul de

decriptare d, ceea ce ar duce la compromiterea cheii private și la descifrarea textului criptat.

Încă de la publicarea sa, algoritmul RSA a fost studiat de o mulțime de cercetători, fiind supus la nenumărate teste. Cu toate că de-a lungul celor mai bine de 25 de ani de utilizare au rezultat diverse vulnerabilități, algoritmul s-a dovedit suficient de rezistent (până în prezent) pentru a putea oferi un grad ridicat de securitate. Metodele de atac rezultate nu fac decât să ilustreze încă o dată pericolul utilizării RSA în condiții necorespunzătoare, programarea unei versiuni sigure de RSA nefiind deloc o problemă simplă.

În practică, RSA este foarte des utilizat împreună cu algoritmi cu cheie simetrică (de exemplu DES). Se generează o cheie DES, cu care se criptează mesajul. Apoi, cheia simetrică se criptează cu ajutorul cheii publice a persoanei căreia îi este destinat mesajul și se trimite destinatarului împreună cu mesajul criptat (acestea două formează un "plic digital" RSA). Destinatarul va decripta mai întâi cheia DES cu ajutorul cheii sale private, apoi mesajul, cu ajutorul cheii simetrice, obținută din prima decriptare. Cheia DES poate fi în continuare utilizată și ca o cheie de sesiune. Pentru semnarea unui mesaj, mai întâi se creează o amprentă digitală ("message digest") a acestuia cu ajutorul unei funcții hash. Aceasta se criptează cu ajutorul cheii private, rezultatul urmând a fi trimis destinatarului. Pentru verificarea semnăturii, se decriptează mesajul cu ajutorul cheii publice a semnatarului, obținând astfel

34

amprenta digitală, care va fi comparată cu cea obținută aplicând din nou funcția hash asupra

mesajului. Dacă cele două amprente sunt identice, rezultă faptul că semnătura digitală este autentică.

În momentul de față, RSA este utilizat într-o varietate de produse, platforme și standarde. El poate fi întâlnit în sisteme de operare, precum: Microsoft, Apple, Sun sau Novell, în componente hardware, precum: sisteme telefonice, card-uri de rețea sau smartcard- uri, în protocoale de comunicație, precum: S/MIME, SSL, IPSec, PKCS. El este în mod sigur cel mai răspândit algoritm cu cheie publică utilizat la ora actuală.

În ultimul timp a devenit clar că sistemele cu chei publice sunt un mecanism indispensabil atât pentru managementul cheilor cât și pentru comunicațiile sigure. Ceea ce este mai puțin clar este modalitatea de a alege cel mai bun sistem într-o anumită situație. Unul dintre criteriile cele mai des folosite pentru a alege îl constituie tehnica utilizată de algoritm. Fără o cunoaștere profundă a acesteia, a vulnerabilităților, dar mai ales a metodelor de atac, cu greu mai putem concepe astăzi programarea unui versiuni robuste și sigure a unui algoritm criptografic.

Mai mult de două decenii de atacuri împotriva RSA au produs o serie de atacuri interesante, dar nu au fost găsite (până în prezent) metode astfel încât algoritmul să fie compromis. Se poate deci presupune că implementările RSA, ce respectă un set de reguli bine stabilit, pot furniza un grad ridicat de securitate.

2.3.2 Algoritmul Diffie-Hellman

Whitfield Diffie si Martin Hellman au propus acest algoritm care este utilizat exclusiv

pentru operatiile de schimbare de chei. Fiecare parte utilizeaza cheia sa privata si cheia publica a corespondentului pentru a crea o cheie simetrica pe care nici un alt utilizator nu o poate calcula. Protocolul începe cu fiecare parte care generează independent câte o cheie privată. În pasul următor, fiecare calculează câte o cheie publică, aceasta fiind o funcție matematică a cheilor private respective. Urmează schimbul de chei publice. În final, fiecare dintre cele două persoane calculează o funcție a propriei chei private și a cheii publice a celeilalte persoane. Matematica este cea care va face să se ajungă la aceeași valoare, care este derivată din cheile lor private.

35

Securitatea acestui algoritm consta în dificultatea calculării logaritmilor discreți.

Calculul acestor logaritmi pentru numere prime mari este considerat imposibil. În primul rând de definește a – rădăcina primitivă a unui număr prim p, ca fiind un număr a cărui puteri generează toți întregii de la 1 la p-1 prin aplicarea operatiei (mod p). Adică dacă a este

rădăcina primitivă a unui număr p atunci numerele:

sunt distincte și constau din întregii de la 1 la p-1 într-o anumită permutare.

Pentru un întreg b și o rădăcină primitivă a a unui număr p se poate găsi un unic

exponent astfel încât:

Exponentul i se calculează prin logaritm discret (prezentat în literatura de specialitate

ca fiind deosebit de dificil de determinat).

Metoda Diffie-Hellamn, precum și variantele ei sunt utilizate în câteva protocoale de

securitate a retelelor, și la Pretty Good Privacy pentru criptarea e-mail-urilor și a unor fișiere.

2.3.3 Semnaturi digitale

Standardul pentru semnături digitale (DSS – Digital Signature Standard) a fost adoptat

în 1991, fiind revizionat în 1993. El folosește Secure Hash Algorithm (SHA) și prezintă o tehnică nouă pentru semnături digitale prin Digital Signature Algoritm (DSA). Spre deosebire de RSA acest algoritm este proiectat doar pentru furnizarea semnăturilor digitale nu și pentru funcții de criptare și decriptare, dar totuși este o metodă care folosește chei publice.

Figura 2.9 evidentiaza diferenta dintre modul de generare a semnăturilor digitale folosite de DSS și algoritmul RSA, creandu-se astfel o paralela intre cele 2. În RSA, partea de mesaj care se dorește a reprezenta în final semnătura, este trecută printr-o funcție de amestecare (hash function) producând un cod amestecat (hash code) de lungime fixă, acesta fiind mai apoi criptat cu cheia privată a expeditorului formând semnătura digitală. Atât mesajul propriu-zis cât și semnătura digitală sunt transmise destinatarului. Destinatarul produce pe baza mesajului (fără partea care include semnătura) codul amestecat. De asemenea destinatarul decriptează semnătura folosind cheia publică a sursei. Dacă codul amestecat rezultat și semnătura obținută prin decriptare coincid, atunci semnătura este validată.

36

Deoarece numai sursa cunoaște cheia sa privată rezultă că numai ea poate produce o

semnătură validă.

Figura 2.9 Cele două abordări a semnăturilor digitale

Funcții de amestecare sunt folosite de asemenea si de Algoritmul DSS. Codul

amestecat produs este folosit ca intrare într-o "funcție-semnătură" împreună cu un număr k generat aleator. "Funcția-semnătură" mai depinde și de cheia privată a sursei KRa precum și de un set de parametri cunoscuți participanților. Se consideră că acest set de parametrii constituie o cheie globală KUG. Rezultatul este o semnătură care constă din două componente notate s și r. La destinație un cod amestecat este generat pe baza mesajului recepționat. Acesta și semnătura servesc ca intrare funcției de verificare. Aceasta depinde de asemenea de cheia publică a sursei KUa și de cheia publică globală. Dacă ieșirea produsă de funcția de verificare coincide cu r (o parte din semnătură) atunci semnătura este validă.

37

2.4 Concluzii

Criptografia cu chei simetrice și cea cu chei publice prezintă atat avantaje și

dezavantaje. Deoarece în cadrul criptografiei simetrice este utilizată aceeași cheie atât pentru criptare, cât și pentru decriptare, securitatea acestei criptări este redusă, depinzând în mod evident de împiedicarea obținerii cheii secrete de către o terță parte. De cele mai multe ori este necesară securizarea schimbului de chei înainte de începerea propriu-zisă a interschimbului de date criptate. În cazul algoritmilor asimetrici securitatea este asigurată prin folosirea cheii private și utilizarea certificatelor digitale. Algoritmii asimetrici sunt ecuații matematice complexe care operează cu numere foarte mari, ceea ce implică o relativă încetineală a procesului. Algoritmii simetrici sunt de obicei mult mai rapizi, având însă problema partajării cheii de criptare. Un astfel de algoritm este cu atât mai sigur, cu cât lungimea cheii este mai mare (numărul cheilor care ar putea fi testate de o persoană neautorizată crește). În practică se preferă combinarea celor două forme de criptografie, pentru optimizarea performanțelor. In tabelele de mai jos (Tabel 1 si Tabel 2) sunt evidentiate in paralel avantajele si dezavantajele

celor doua chei:

Tabel 1

Chei

simetrice

Avantaje

Cheile folosite pentru algoritmii

simetrici sunt relativ scurte

Algoritmii folosiți permit

gestionarea unor volume mari de date, cu viteză reletiv bună.

Exista implementari hard care

pentru unele sisteme de criptare

pot asigura rate de criptare de

sute de mega-octeti pe secunda

Prin compunere pot conduce la

sistme de criptare puternice

Pot fi folosite ca baza de

constructie a diverselor

mecanisme de criptare, cum ar fi

generatori de numere pseudo-

aleatoare, generatori de functii de

dispersie, scheme de semnatura

Dezavantaje

Într-o comunicație cheia trebuie sa

ramana permament secreta în (cel putın)

doua locuri distincte

Cu cat lungimea unui mesaj criptat este

mai mare, cu atat el este mai usor de

spart

Necesita un canal sigur de comunicare,

cel putin pentru transmiterea cheii. Acest

lucru devine dificil mai ales pentru

sistemele care necesita schimbari

frecvente ale cheilor de

criptare/decriptare

In retele mari, o gestionare a cheilor

devine extrem de dificila

38

Avantaje Dezavantaje

Tabel 2

Conduc la aplicatii de mare ıntindere: Sunt necesare chei de lungimi mult mai

semnaturi electronice, algoritmi de mari

autentifi- care, componente de comert

electronic

In functie de modul de utilizare, o Nu se poate garanta securitatea absoluta a pereche de chei (publica,privata) poate nici unei scheme de criptare cu cheie

fi pastrata o perioada mai lunga de timp publica

Sistemele cu cheie publica sunt simplu Implementarea trebuie realizata cu foarte

Cheie

publica

de definit si elegante matematic

mare grija. Sisteme cu grad ridicat teoretic de securitate pot fi sparte usor printr-o

implementare neglijenta

Sistemul este ideal pentru transmiterea Viteza algoritmilor cu chei publice este de

informatiei prin canale nesigure câteva ori mai mică decat a celor cu chei

simetrice

Doar cheia de decriptare trebuie tinuta

secreta, la un singur punct (destinatar)

39

3. SECURIZAREA COMUNICATIILOR DIGITALE PRIN

INTERMEDIUL VPN (VIRTUAL PRIVATE NETWORK)

O tehnologie de comunicații cumputerizată sigură, dar bazată pe o rețea publică este o

rețea privată virtuală,și de aceea nu foarte sigură. Tehnologia VPN este concepută tocmai pentru a crea într-o rețea publică o subrețea de confidențialitate aproape la fel de înaltă ca într- o rețea privată adevărată la care sunt legați numai utilizatori autorizați. Tehnologia VPN este concepută tocmai pentru a crea într-o rețea publică o subrețea de confidențialitate aproape la fel de înaltă ca într-o rețea privată adevărată la care sunt legați numai utilizatori autorizați. În mod intenționat această subrețea, denumită totuși "rețea VPN", nu poate comunica cu celelalte sisteme sau utilizatori ai rețelei publice de bază. Utilizatorii unei rețele VPN pot căpăta astfel impresia că sunt conectați la o rețea privată dedicată, independentă, cu toate avantajele pentru securitate, rețea care în realitate este doar virtuală, ea de fapt fiind o subrețea înglobată fizic în rețeaua de bază.

O rețea privată virtuală este o rețea partajată în care datele private sunt segmentate de restul traficului, astfel încât numai destinatarul real are acces la ele, un exemplu general este ilustrat în figura următoare. Figura 3.1. prezintă o rețea VPN în care întreprinderile A și B nu se "văd" și nu se deranjează reciproc, deși ambele folosesc aceeași rețea fizică publică.

Figura 3.1 Rețele private virtuale

40

Rețelele VPN oferă multe aventaje: extinde aria geografică de conectivitate, sporește

securitatea, reduce costurile operaționale, crește productivitatea, simplifică topologia rețelei, oferă oportunități de lucru într-o rețea globală, permite confidențialitatea datelor schimbate între punctele de lucru aflate la distanță și altele. În plus, VPN -urile securizate sunt mai ieftine decât liniile închiriate dedicate.

Un aspect important, vital al securității datelor este faptul că datele, în cursul lor spre destinatar, sunt protejate prin tehnologii de criptare. Un punct slab este ca rețelelor private le lipsește securitatea datelor, permițând astfel intrarea în rețea și citirea datelor. În schimb, rețelele private virtuale bazate pe IP Sec utilizează criptarea pentru a secretiza date, crescând astfel rezistența rețelei din punct de vedere al furtului datelor.

3.1 Tipuri de retele VPN

Sunt trei tipuri principale de retele VPN, figura 3.2.:

– VPN-urile cu acces de la distanță (Remote Access VPN) permit utilizatorilor dial-up

să se conecteze securizat la un site central printr-o rețea publică.

– VPN-urile intranet (Intranet VPN) permit extinderea rețelelor private prin Internet sau alt serviciu de rețea publică într-o manieră securizată. Acestea sunt denumite și VPN-uri „site-to-site" sau „LAN-to-LAN".

– VPN-urile extranet (Extranet VPN) permit conexiuni securizate între partenerii de afaceri, furnizori și clienți, în general în scopul realizării comerțului electronic. VPN-urile extranet sunt o extensie a VPN-urilor intranet la care se adaugă firewall-uri pentru protecția rețelei interne.

41

Figura 3.2 Tipuri de rețele VPN

3.1.1 Remote VPN

VPN-urile de tip acces de la distanță (remote access), numite și rețele virtuale private

cu dial-up, este un tip de conexiune utilizator-către-LAN (figura 3.3) folosită cel mai adesea de companii ce au angajați cu necesități de conectare la resursele rețelei companiei din diverse locatii.

Figura 3.3 Remote VPN

42

De regulă în momentul când se dorește accesul mai multor utilizatori la rețeaua locală,

se apeleaza la o companie de out-sourcing ce folosește un server de acces în rețea pentru a acorda drepturi utilizatorilor și calculatoarelor acestora.

In general, în cazul implementarii unei tehnologii VPN între sediile companiei, este de preferat să se apeleze la același ISP pentru toate locațiile. Apropierea geografică de regulă nu are nici o legatura cu "apropierea pe Internet".

Prin utilizarea de echipamente dedicate și criptare pe scară largă, o companie poate conecta multe locații (sucursale) fixe pe o rețea publică cum ar fi Internetul.

3.1.2 Intranet VPN

Rețeaua virtuală privată între sediile și departamentele aceleiași firme. Intranet-ul

este definit ca o legătura semi-permanentă peste o rețea publică între un WAN și o filială a companiei. Aceste tipuri de conexiuni LAN-LAN (Fig. 3.4) se presupune că au cel mai mic risc din punct de vedere al securității pentru ca firmele au încredere în filialele lor. În astfel de cazuri compania are control asupra rețelei/nodurilor destinație cât și asupra celei sursă. Administratorii de sistem trebuie să decidă dacă aceasta situație este întâlnită și în propria firmă.

Cantități mari de date sunt schimbate frecvent între LAN-uri într-o rețea privată, deci importantă este viteza de transmisie și interoperabilitatea. LAN-urile care sunt conectate prin intermediul unor baze de date centralizate sau prin alte resurse de calcul răspândite în rețeaua firmei ar trebui să fie considerate ca făcând parte din aceeași rețea. Motivul principal pentru care majoritatea organizațiilor se orientează către tehnologia VPN este costul redus al acestei implementari.

Figura 3.4 Intranet VPN

43

3.1.3 Extranet VPN

Rețeaua virtuală privată care este relativ izolată față de intranet. Extranetul este

destinat comunicării cu partenerii, clienții, furnizorii și cu angajații la distanță. Securizarea unei rețele de dimensiuni mari necesită îndrumări și instrumente adecvate. Un extranet VPN trebuie să ofere o ierarhie a securității și accesarea datelor confidențiale să se facă sub cel mai strict control. Principalul obiectiv al unui Extranet sau al VPN-ului între companii este să se asigure ca datele secrete ajung intacte și exact cui îi sunt adresate fără a exista riscul de a expune resursele protejate unor eventuale amenințări, așa ca firmele ar trebui să ia în considerare cele mai avansate soluții de VPN.

Figura 3.5 Extranet VPN

Un Extranet VPN, figura 3.5. sigur, în care o companie împarte informații cu clienții,

partenerii, furnizorii și angajații aflați la distanță prin intermediul rețelei publice stabilind legături unidirecționale de la un capăt la altul printr-un server VPN. Acest tip de sistem permite unui administrator de rețea să definească drepturi specifice, cum ar fi cele ce ar permite unui membru din conducerea unei firme partenere să acceseze diferite/anumite rapoarte de vânzări de pe un server protejat. Acest tip de acces nu este posibil cu orice tip de soluție VPN.

Într-o situație reală de interconectare între parteneri de afaceri, administratorii trebuie să caute o soluție de VPN care să filtreze accesul la resurse în funcție de cât mai multe parametrii posibili, inclusiv sursa, destinația, utilizarea aplicației, tipul de criptare și

44

autentificare folosit, și identitățile individuale și de grup. Managerii de sistem trebuie să

identifice utilizatorii individual, nu numai adresele IP, fie prin parole, token card, smart card, sau orice alta metode de autentificare. Parolele sunt de obicei suficiente pentru o aplicație obișnuită de birou, dar nu sunt la fel de sigure precum token-urile sau smart card-urile.

Rețelele private virtuale folosesc Internetul pentru a conecta mai multe rețele LAN între ele, printr-o conexiune sigură. Conexiunile VPN realizează acest lucru cu două procese importante: crearea de tunele și securizarea. Mai întâi, o rețea VPN creează un circuit ,,virtual" între cele două puncte conectate, prin intermediul Internetului. Apoi, folosește metoda creării de tunele pentru a înfășura datele în protocolul (limbajul) Internetului – TCP/IP – astfel încât să poată fi transportate cu ușurință. Prin securizare se înțele criptarea și încapsularea pachetelor trimise, astfel încât numai destinatarul căreia i se adresează să le poată decodifica și citi.

3.2 Protocoale de tunelare

Pentru a se face posibila implementarea rețelei VPN este necesară crearea unui tunel

printr-o rețea publică pentru transferul datelor. Tunelarea este definita ca fiind o metodă de folosire a infrastructurii unei inter-rețele pentru transferul datelor dintr-o rețea peste o altă rețea. Datele de transferat pot fi cadrele (sau pachetele) altui protocol. În loc de a transmite cadrul în forma în care a fost produs de nodul sursă, protocolul de tunelare încapsulează cadrul într-un antet adițional. Acesta conține informații de rutare astfel încât încărcătura încapsulată poate traversa inter-rețeaua intermediară. Pachetele încapsulate sunt apoi rutate între capetele tunelului prin inter-rețea. Calea logică pe care pachetele încapsulate o urmează în inter-rețea se numește tunel. Odată ce cadrele încapsulate ajung la destinație prin inter- rețea, cadrul este decapsulat și trimis la destinația sa finală. De notat că tunelarea include întregul proces: încapsulare, transmitere și decapsulare a pachetelor.

45

Figura 3.3 Protocoale folosite pentru VPN

În esență, tunelarea este procesul prin care se introduce întreg pachetul IP în interiorul

unui alt pachet, cu antete distincte, acesta fiind trimis ulterior prin rețea. Protocolul pachetului rezultat în urma tunelării este recunocut de către rețea și de către ambele noduri sursă și

destinație, la nivelul interfețelor de tunelare, prin care pachetele intră și ies din rețea.

Tehnologia de tunelare poate fi bazată pe un protocol de tunelare pe nivel 2 sau 3. Aceste nivele corespund modelului de referință OSI (figura 3.3.).

3.2.1 Protocoale de nivel 2 OSI

Protocoalele de tunelare de nivel 2 corespund nivelului legătură de date, și folosesc

cadre ca unitate de schimb. Ele încapsulează încărcătura într-un cadru PPP pentru a fi transmis peste inter- rețea. Pentru tehnologiile de nivel 2, cum ar fi PPTP sau L2TP, un tunel este asemănător cu o sesiune; ambele capete ale tunelului trebuie să cadă de acord asupra tunelului și să negocieze variabilele de configurare, cum ar fi atribuirea adreselor, criptarea, comprimarea. În cele mai multe cazuri, datele transferate prin tunel sunt trimise folosind un protocol bazat pe datagrame. Pentru gestionarea tunelului se folosește un protocol de menținere a tunelului. Pentru protocoalele de nivel 2, un tunel trebuie creat, menținut și

distrus. [12]

46

Layer 2 forwarding este un protocol de tip forwarding, folosit pentru tunelarea

protocoalelor de nivel înalt într-un protocol de nivel 2. Un exemplu este folosirea ca protocoale L2: HDLC, HDLC asincron sau cadre SLIP. Deși această soluție facilitează conectivitatea pe linii de acces în rețele cu comutație de circuite, informația din fluxul L2F nu este criptată. Acest protocol a fost creat de Cisco. Combinat cu PPTP, constituie componentă a L2TP.

Point to point tunneling protocol, reprezintă o extensie a Point-to-Point Protocol (PPP), care încapsulează datele, IPX sau NetBEUT în pachetele IP. Acest protocol este folosit în mod fundamental de echipamentele ISP, deoarece duce la un numitor comun participanții la sesiuni de comunicații. Este cea mai cunoscută dintre opțiunile pentru securitatea transferului de date în rețeaua VPN. Dezvoltat de Microsoft și inclus în Windows NT v 4.0 pentru a fi folosit cu serviciul de rutare și acces de la distanță. Acesta permite traficului IP, IPX și NetBEUI să fie criptat și încapsulat într-un antet IP pentru a fi transmis peste o inter- rețea IP de corporație sau publică (Internet).

PPTP suportă criptare pe 128 de biți și 40 de biți și poate folosi orice schemă de autentificare suportată de PPP. Ca și L2F, PPTP permite tunneling-ul unor cadre PPP de la clientul îndepărtat între un NAS și un VPN gateway/concentrator.

Layer 2 Tunneling Protocol, este o combinație dintre un protocol al firmei Cisco Systems (L2F) și cel al firmei Microsoft denumit Point-to-Point Tunneling Protocol (PPTP). Un tunel L2TP este creat incapsuland un cadru L2TP in interiorul unui pachet UDP, cel din urma fiind incapsulat in interiorul unui pachet IP a carui adrese sursa si destinatie definesc capetele tunelului.

Fiind conceput pentru a suporta orice alt protocol de rutare, incluzând IP, IPX și AppleTalk, acest L2TP poate fi rulat pe orice tip de rețea WAN, inclusiv ATM, X.25 sau SONET. Cea mai importantă trăsătură a L2TP este folosirea protocolului Point-to-Point, inclus de Microsoft ca o componentă a sistemelor de operare Windows 95, Windows 98 și Windows NT. Astfel că orice client PC care rulează Windows este echipat implicit cu o funcție de tunneling, iar Microsoft furnizează și o schemă de criptare denumită Point-to-Point Encryption. În afara capacității de creare a unei VPN, protocolul L2TP poate realiza mai multe tunele simultan, pornind de la același client.

Următorul tabel (tabel 3.1) ne oferă o comparație intre cele mai predominante

protocoale de tunelare cu acces la distanță (remote acces), L2TP, PPTP și L2F:

47

Transport

Criptare

Autentificare

PPTP

IP/GRE

Criptare Microsoft

PPP (MPPE)

Autentificare PPP

(utilzator)

L2F

IP/UDP, FR, ATM Criptare Microsoft

PPP (MPPE); IPsec

opțional

Autentificare PPP

(utilzator); IPsec

opțional (pachet)

L2TP

IP/UDP, FR, ATM Criptare Microsoft

PPP (MPPE/ECP);

IPsec opțional

Autentificare PPP

(utilzator); IPsec

opțional (pachet)

Tabel 3.1 Comparație intre protocoale de tunelare cu acces la distanta

3.2.2 Protocoale de nivel 3 OSI

Protocoalele de nivel 3 corespund nivelului rețea, folosesc pachete IP și sunt exemple

de protocoale care încapsulează pachete IP într-un antet IP adițional înainte de a le transmite peste o inter-rețea IP. Tehnologiile de tunelare pe nivel 3 pleacă de la premiza că toate chestiunile de configurare au fost efectuate, de multe ori manual. Pentru aceste protocoale, poate să nu existe faza de menținere a tunelului. Tunelul odată stabilit, datele tunelate pot fi trimise. Clientul sau serverul de tunel folosește un protocol de transfer de date de tunel pentru

a pregăti datele pentru transfer. De exemplu, când clientul de tunel trimite informația utilă

către serverul de tunel, clientul de tunel adaugă un antet de protocol de transfer de date de

tunel la informația utilă. Apoi clientul trimite informația încapsulată rezultată prin inter-rețea, care o dirijează către serverul de tunel. Serverul de tunel acceptă pachetul, elimină antetul de protocol de transfer de date și transmite informația utilă la rețeaua țintă. Informația trimisă între serverul de tunel și client se comportă similar.

Generic Routing Encapsulation este un protocol de tunelare dezvoltat de Cisco care poate încapsula o mare varietate de tipuri de pachete ale protocoalelor de rețea în interiorul tunelelor IP, creând o legătură virtuală punct la punct, între routere aflate la distanță, peste o rețea IP.

Pentru rutarea cu adrese private, se încapsulează pachetele IP transmise în Internet cu antete suplimentare prin așa-numitul mecanism GRE, descris în RFC 1701. Pachetului inițial

48

(payload packet /original packet) i se adaugă un antet GRE (GRE Header) și un antet de

expediere privind modul de transfer specificat conform protocolului de rețea (delivery header).

În antetul GRE se specifică ruta pe care se va trimite forțat pachetul la destinație, fără a se lua alte decizii de rutare în routerele intermediare.

GRE asigură transparența adreselor intermediare și securitatea transmisiei, prin realizarea unui așanumit "tunel de transmisie" (tunnelling) .

Uzual este cazul încapsulării pachetelor IP pentru transmisii cu IP (IP over IP) conform RFC 1702, standard definit pentru GRE. Adresele IP private pot fi utilizate în încapsularea GRE astfel încât cadrul să fie interpretat ca fiind încapsulat GRE și routerele 'de la distanță' să extragă adresa de destinație privată din pachetul original.

Tunelarea are implicații importante pentru VPN-uri. Astfel se pot transmite pachete care utilizează adrese IP private în interiorul unui pachet care utilizează adrese IP reale, în acest fel se poate extinde rețeaua privată prin Internet. Dar se poate transmite și un pachet care nu este suportat de protocolul Internet (precum NetBeui) în interiorul unui pachet IP iar acesta poate fi apoi transmis cu ușurință prin Internet.

Deși VPN-urile construite peste Internet folosind GRE sunt posibile, sunt foart rar folosite de companii datorită riscurilor și lipsei de mecanisme de securitate.

Internet Protocol Security sau IPSec, este o suită de protocoale care asigură securitatea unei rețele virtuale private prin Internet.

Orice persoana care folosește VPN este preocupata de securizarea datelor când

traversează o rețea publică. Totodată, dezvoltarea VPN-urilor pe baza rețelei publice Internet poate însemna reducerea costurilor semnificativ de mult comparativ cu liniile închiriate. Serviciile IPSec permit autentificare, integritate, controlul accesului și confidențialitare. Cu IPSec, schimbul de informații între locațiile la distanță poate fi criptat și verificat. Cu IPsec pot fi dezvoltate soluții atât la distanță, cât și site-to-site.

IPSec este poate cel mai autorizat protocol pentru păstrarea confidențialității și autenticității pachetelor trimise prin IP. Protocolul funcționează cu o largă varietate de scheme de criptare standard și negocieri ale proceselor, ca și pentru diverse sisteme de securitate, incluzând semnături digitale, certificate digitale, chei publice sau autorizații. Încapsulând pachetul original de date într- destinație. Deoarece nu există modalități de autentificare sau criptare licențiate, IPSec se detașează de celelalte protocoale prin interoperabilitate. El va lucra cu majoritatea sistemelor și standardelor, chiar și în paralel cu alte protocoale VPN. De exemplu, IPSec poate realiza negocierea și autentificarea criptării în timp ce o rețea virtuală

49

de tip L2TP primește un pachet, inițiază tunelul și trimite pachetul încapsulat către celălalt

terminal VPN.

IPSec folosește un algoritm pentru schimbarea cheilor între părți, numit Internet Key Exchange (IKE), care permite calculatoarelor să aleaga o cheie de sesiune în mod securizat, folosind protocoalele ISAKMP pentru crearea de Security Associations și OAKLEY bazat pe algoritmul Diffie-Hellman pentru schimbarea cheilor între cele două părți. IKE se poate folosi în conjuncție cu Kerberos, certificate X.509v3 sau chei preshared.

Pentru a securiza comunicația în rețea cu IPSec între calculatoarele Windows se foloseste o colecție de reguli, politici și filtre pentru a permite în mod selectiv doar comunicația pentru anumite protocoale.

Politicile de IPSec pot fi create și aplicate cu Group Policy pentru calculatoarele din domeniu. Pentru calculatoare care nu sunt în domeniu, de exemplu serverele bastion, politicile pot fi aplicate cu script-uri linie de comandă.

Implementarea unei soluții VPN de comunicație reliefează unele probleme specifice, probleme ce apar din cauza absenței standardelor. Internet Engineering Task Force (IETF) a stabilit un grup de lucru dedicat definirii standardelor și protocoalelor legate de securitatea Internetului. Unul dintre cele mai importante scopuri ale acestui grup de lucru este finalizarea standardului IPSec, care definește structura pachetelor IP și considerentele legate de securitatea în cazul soluțiilor VPN.

In ultimi ani in cadrul IETF, grupul de lucru IPSec a înregistrat mari progrese în adăugarea de tehnici de securitate criptografice la standardele pentru infrastructura Internet. Arhitectura de securitate specificată pentru IP ofera servicii de securitate ce suportă combinații de autentificare, integritate, controlul accesului și confidențialitate.

Tunele GRE cu protecție IPSec. GRE este un protocol de tunelare dezvoltat de Cisco care poate înmagazina o multitudine de tipuri de pachete ale protocoalelor de rețea în interiorul tunelelor IP, creând o legătură virtuală punct la punct, între routere aflate la distanță, peste o rețea IP.

Tunelele GRE sunt create să fie complete, fără o stare persistentă, astfel fiecare capăt de tunel nu încapsuleaza nicio informație despre starea și disponibilitatea capătului de tunel de la distanță. O urmare a faptului acesta este că ruter-ul din capătul de tunel nu are abilitatea de a marca protocolul liniei interfeței tunelului GRE ca fiind inaccesibil dacă ruter-ul de la distanță, din celălalt capăt, nu este funcțional. Posibilitatea de a exprima că interfața este nefuncțională către celălalt capăt este eficientă pentru retragerea rutelor care o folosesc ca și interfață de ieșire, din tabela de rutare (în special rutele statice).

50

De cele mai multe ori, o interfață de tunel GRE este funcțională din momentul în care

este configurată și rămâne așa cât timp este o adresă sursă a tunelului validă. Adresa IP destinație a tunelului trebuie să fie mereu rutabilă. Acest lucru este adevărat chiar dacă celălalt capăt al tunelului nu a fost configurat. Astfel, o rută statică a pachetelor via interfața tunelului GRE rămâne în vigoare chiar dacă pachetele tunelului GRE nu găsesc celălalt capăt de tunel.

Construirea unei rețele virtuale private folosind IPSec pentru conectivitatea dintre

capete are câteva limitări:

-IPSec poate cripta/decripta doar traficul IP

-traficul IP destinat unei adrese de difuzare nu poate fi procesat de IPSec, ceea ce

înseamnă că nu poate traversa tunelul.

-de asemenea, rutarea dinamică folosind procoale ca EIGRP, OSPF, RIPv2 nu pot fi configurate între două capete IPSec.

Aceste probleme se pot rezolva prin configurarea unui tunel GRE între cele două noduri și aplicarea ulterioară a protecției IPSec pe acest tunel. Este în esență că GRE incadrează orice informație utilă dintr-un pachet unicast destinat unui capăt GRE.

In momentul cand se utilizează GRE îmbinat cu IPSec se poate folosi atât modul tunel cât și cel transport (modul tunel va adăuga un antet IP pachetelor GRE, în timp ce modul transport va folosi antetul original GRE).

Teoretic, modul transport se recomanda in momentul când se utilizează combinarea dintre IPSec și GRE pentru că deja protocolul de încapsulare GRE adaugă un antet IP nou pachetului util. Totuși, această situație presupune existența unor adrese IP sursă și destinație care sunt accesibile prin calea IP dintre noduri.

Utilizarea protocolului GRE împreună cu IPSec face configurarea echipamentelor VPN mai simplă. În situația tradițională IPSec era nevoie de o politică anume care să specifice subrețelele protejate pentru ca traficul dintre acestea să fie criptat/decriptat și de fiecare dată când o subrețea era adăugată trebuia să fie reînnoită structura la ambele capete. În cazul utilizării GRE, regulile trebuie să corespundă doar traficului dintre adresele de capăt GRE (tot ce trece prin tunelul GRE este criptat).

Unul din multiplele motive pentru care este bine sa folosesti GRE combinat cu IPSec este faptul ca exista astfel posibilitatea de a rula protocoale dinamice între locații pentru a anunța subrețelele protejate. Rutarea dinamică ajută implicit și în situații de eșec a transferului, in acest fel se pot detecta interfețele care nu mai funcționează și nu mai participă în VPN.

51

3.3 Standardizarea retelelor VPN – protocoalele ISAKMP si IPsec

ISAKMP (Internet Security Association and Key Management Protocol – Protocolul

pentru Managementul Cheilor si Asociatia Securitatii Internetului) , un protocol cheie în arhitectura IPsec, combina conceptele de securitate ale autentificarii, gestionarea cheilor și asocieri de securitate pentru a stabili nivelul de securitate necesar pentru guverne, comunicatii comerciale și private de pe Internet .

ISAKMP definește procedurile și formatele de pachete pentru a stabili, negocia,

modifica și șterge asocierile de securitate (SAs). Acestea conțin toate informațiile necesare

pentru executarea diferitelor servicii de securitate de rețea, cum ar fi serviciile de la nivelul IP

(cum ar fi autentificarea antetului și încapsulare incarcaturii), nivelul transport sau servicii de

la nivelul aplicație, sau auto-protecția traficului de negociere. ISAKMP definește incarcaturi

pentru schimbul de generare a cheii și datele de autentificare. Aceste formate oferă un cadru

coerent pentru transferul cheilor și autentificarea datelor independente de tehnica de generare a cheilor, algoritmul de criptare și mecanism de autentificare.

ISAKMP este diferit de protocoale de schimb de chei, în scopul de a separa detaliile de management ale asocierilor de securitate (și de gestionare a cheilor) de detaliile de schimb

de chei. Pot exista mai multe protocoale diferite de schimb de chei, fiecare cu proprietăți

diferite de securitate. Cu toate acestea, este necesar un cadru comun de acord cu formatul

atributelor asocierilor de securitate și pentru negocierea, modificarea și ștergerea asocierilor. ISAKMP servește ca acest cadru comun.

Separarea funcționalitatii în trei părți adaugă complexitate analizei securitatii unei

implementari ISAKMP complete. Cu toate acestea, separarea este esențială pentru

interoperabilitate între sisteme cu cerințele de securitate diferite și ar trebui să simplifice, de asemenea, analiza evoluției ulterioare a unui server ISAKMP.

ISAKMP este destinat să sprijine negocierile asocierilor pentru protocoale de

securitate la toate nivelurile stivei de rețea (de exemplu, IPSEC, TLS, TLSP, OSPF, etc). Prin

centralizarea managementului asocierilor de securitate, ISAKMP reduce cantitatea de

functionalitate duplicat în fiecare protocol de securitate.

IPSec a apărut în cadrul efortului de standardizare pentru IPv6 și reprezintă singura soluție deschisă pentru securizarea conexiunilor pe Internet. IPSec poate fi configurat pentru două moduri distincte: modul tunel și modul transport. În modul tunel, IPSec încapsulează pachetele IPv4 în cadre IP securizate, pentru transferul informației, între două sisteme

52

firewall, de exemplu. În modul transport, informația este încapsulată altfel încât ea poate fi

securizată între punctele terminale ale conexiunii, deci "ambalajul" nu ascunde informația de rutare cap-la-cap. Modul tunel este cea mai sigură metodă de securizare, însă crește gradul de încărcare a sesiunii de comunicație, prin mărirea dimensiunilor pachetelor.

Controlul securității se poate face la oricare dintre cele patru nivele ale stivei TCP/IP; datele sunt pregătite pentru transport și sunt tranzitate de la cel mai înalt la cel mai jos nivel, adăugându-se treptat noi informații. Astfel, nivelele de mai sus nu pot asigura protecție totală pentru nivelele de jos pentru că acestea adaugă informații după ce s-au aplicat măsurile de securitate mai sus. Controlul la nivel rețea a devenit foarte utilizat în rețelele de date pentru că propune o soluție mai balansată și are marele avantaj de a priva utilizatorul de implicarea în configurarea echipamentelor.

La ora actuală există două tipuri de antete ce pot fi atașate la un pachet IP pentru realizarea securității: Authentification Header și Encapsulated Security Payload, definite după

cum urmează:

• Authentification Header este folosit pentru a furniza integritatea și autentificarea originii pentru orice datagramă IP, fără ca aceste atribute să fie orientate pe conexiune. Această proprietate este denumită generic "autentificare".

• Encapsulated Security Payload furnizează autentificarea și criptarea datagramelor IP folosind algoritmul de criptare stabilit de către utilizator. În autentificarea ESP, sumarul de mesaj este inserat la sfîrșitul pachetului (în timp ce în AH, sumarul se află în interiorul cîmpului de autentificare).

Standardul IPSec stabilește că înainte de orice transfer de date trebuie negociată o asociere de securitate (Security Association – SA) între cele două noduri VPN (de tip gateway sau client), care să conține toate informațiile necesare pentru execuția diferitelor servicii de securitate pe rețea, cum sunt serviciile corespunzătoare nivelului IP (autentificarea antetului și încapsularea datelor), serviciile nivelurilor de transport sau aplicație, precum și autoprotecția traficului de date din negociere.

IPSec poate fi privit ca un nivel intermediar sub stiva TCP/IP. Acest nivel este controlat de o politică de securitate pe fiecare mașină și de o asociere de securitate negociată între emițător și receptor. Politica constă într-un set de filtre și un set de profile de securitate asociate. Dacă un pachet are adresa, protocolul și numărul de port corespunzătoare unui filtru, atunci pachetul este tratat conform profilului de securitate asociat.

În afara protocoalelor de securitate prezentate anterior, IPSec mai conține și protocolul Internet Key Exchange (IKE). IPSec folosește IKE pentru a negocia setările de conexiune

53

IPsec, pentru a autentifica vecinii unul cu celălalt, pentru a defini parametrii IPSec pentru

conexiuni private, pentru a negocia cheile secrete și pentru a administra, îmbunătăți și șterge canalele de comunicație IPSec.

3.3.1 Protocolul AH

Authentification Header (unul dintre protocalele de securitate IPSec) ofera siguranta

integritatii datelor și autentificarii utilizatorilor. In mod pțional se poate oferi protecția accesului și împotriva atacurilor de replicare, iar aceasta nu poate cripta nicio porțiune din pachet. În versiunea inițială IPSec, AH și ESP erau des utilizați împreună (ESP nu asigura autentificarea), dar în cea de-a doua versiune, AH devine mai puțin semnificativ, până la stadiul îm care unele sisteme nu mai suportă AH. Totuși, acest protocol este valoros pentru că poate autentifica porțiuni de pachet pe care ESP nu poate.

AH se prezinta sub forma a două moduri: transport și tunel. În modul tunel, AH crează un nou antet IP pentru fiecare pachet iar în modul transport nu. În arhitecturile IPSec care utilizează o poartă(gateway), sursa și destinația adevărată a pachetelor trebuie să fie modificate pentru a fi adresa IP a porții. Modul transport este utilizat în general în arhitecturile stație-la-stație, deoarece aceasta nu poate modifica antetul original IP sau să creeze un alt antet.

Procesul NAT impreună cu protocolul AH nu poate avea loc. AH protejează întregul pachet IP, incluzând câmpurile invariante ale antetului (adresele IP sursă și destinație), printr- un sumar de mesaj pentru a produce un hash cifrat. Receptorul va folosi acest hash pentru a autentifica pachetul, deci dacă orice câmp din pachetul IP original este modificat, autentificarea va eșua și pachetul va fi aruncat.

Procesul de protejare a integrității are ca si prim pas este crearea unui hash folosindu- se de un algoritm de control cifrat, care mai poarta si denumirea de algoritm MAC (cod de autentificare a mesajului). De cele mai multe ori hash-urile sunt confundate cu cu criptarea. Algoritmii hash produc o „amprentă" a unei informații, astfel încât aceste date vor produce de fiecare dată aceeași valoare. Dacă un singur bit se schimbă, atunci și amprenta va fi diferită. Acești algoritmi sunt utilizați pentru a asigura integritatea prin faptul că ne asigură că datele nu au fost modificate în tranzit. Verificarea se face prin adăugarea hash-ului datelor trimise iar la destinație se rulează același algoritm asupra datelor, obținându-se același hash (dacă datele

54

nu au fost modificate). Cei mai importanți algoritmi hash sunt MD5 și SHA-1. Ambele preiau

la intrare date de lungime arbitrară și produc la ieșire o amprentă de 128 biți, respectiv 160. SHA-1 conține măsuri adiționale de securitate, cum ar fi o rundă în plus pentru calularea valorii.

Pentru a preveni un atac de interceptare a transmisiei se introduce în algoritm și o cheie secretă, cunoscută de capetele de tunel. Astfel, valoarea aleatoare procesată (cheia) va furniza autentificarea mesajului, mecanismul care dă o astfel de integritate se numește Cod de autentificare a mesajului (MAC). Atunci când MAC-urile se utilizează cu algoritmii de tip hash, va purta numele de HMAC. IPSec folosește algoritmi de autenticitate HMAC, care execută două hash-uri acordate. Ca și exemplu, cei mai utilizați algoritmi sunt HMAC-MD5 și HMAC-SHA-1. Un alt algoritm cunoscut MAC este AES Cipher Block Chaining MAC (AES-XBC-MC-96).

3.3.2 Protocolul ESP

Al doilea protocol de securitate folosit de IPSec este ESP. Începând cu a doua variantă

IPSec, protocolul poate performa autentificarea, pentru protejarea integrității, deși nu și pentru antetul IP extrem (cel mai din afară). ESP-ul mai are si o alta optiune si anume aceea de a oferi posibilitatea de a dezactiva criptarea prin algoritmul Null ESP.

Protocolul ESP se gaseste sub forma a două moduri: tunel și transport. În primul mod, ESP realizeaza un antet IP nou pentru fiecare pachet care afișează limitele de tunel ESP, dar arata atat sursa cat și destinația pachetului. În situație de fata se poate realiza criptarea și protejarea integrității atât a datelor cât și a antetului original IP al fiecărui pachet. Dacă se utilizează și autentificarea, fiecare pachet va avea o secțiune de autentificare ESP la sfârșit. În modul transport, ESP utilizează antetul original IP, în loc să creeze unul nou. În acest caz, ESP poate doar să cripteze și să asigure integritatea doar a anumitor componente ESP și a informației utile din pachet, nu și a antetelor IP.Acest mod este incompatibil cu NAT, pentru că NAT modifică pachetul TCP și trebuie să recalculeze suma de verificare pentru verificarea integrității. Pe de altă parte, autentificarea ESP va eșua dacă NAT actualizează suma de verificare TCP iar dacă NAT nu face actualizarea (de exemplu, dacă informația utilă este criptată), va eșua verificarea TCP. În modul tunel, ESP și NAT pot funcționa împreună pentru

55

că adresa originală IP și informația de transport sunt incluse în informația utilă. Astfel, NAT

poate avea loc dacă maparea este de tip unu-la-unu.

Tabelul (tabel 3.2) de mai jos prezintă principalele caracteristici ale celor două

moduri:

AH

ES P

ESP cu autentificare

Mod transport

Autentifică unitatea de date IP

și, selectiv, parți ale header-ului

IP și extensiile header-ului

IPv6.

Criptează unitatea de date IP si

toate extensiile header-ului IPv6

care urmează după header-ul ESP.

Criptează unitatea de date IP si

Mod tunel

Autentifică întregul pachet

original IP plus, selectiv, parți ale

noului header și extensiile noului

header IPv6.

Criptează pachetul IP original

Criptează pachetul IP original;

toate extensiile header-ului IPv6 autentifică pachetul IP original.

care urmează după header-ul ESP; autentifică unitatea de date IP.

Tabel 3.2 Moduri de utilizare a IP Security

In cazul protocolului ESP se utilizează criptografia simetrică. Totusi, amandoua capete

ale conexiunii IPsec, protejată de ESP, trebuie sa utilizeze aceeași cheie pentru criptare și decriptare a pachetelor. Algoritmii de criptare recomandati de ESP sunt: AES, DES și 3DES.

ESP adaugă un antet și un subsol porțiunii de informație a fiecărui pachet. Fiecare

antet ESP conține două câmpuri:

•SPI – fiecare capăt a fiecărei conexiuni IPsec are o valoare SPI arbitrar aleasă, care

se comportă ca un identificator unic. Destinatarul folosește această valoare, adresa IP

destinație și (opțional) tipul protocolului IPSec (în cazul de față, ESP), pentru a determina ce SA este folosită.

• Numărul de secvență – fiecărui pachet îi este asignat un număr secvențial și doar pachete dintr-o anumită fereastră sunt acceptate.

56

Informația utilă reprezinta următoarea parte a pachetului, formată din Date (criptate)

și Vectorul de Inițializare, acesta fiind necriptat. Valoadea acestui vector este diferita în fiecare pachet, deci dacă două pachete au același conținut, vectorul de initializare va cauza criptarea diferită a acestora.

Partea a treia a unui pachet o constituie informația suplimentară de la sfârșit, care conține cel puțin două câmpuri (opțional mai poate conține încă unul).

3.3.3 Protocolul IKEv1 si IKEv2

1) IKEv1

Protocolul IKE are trei obiective principale: să negocieze, să creeze și să administreze

Asocierile de Securitate (SA). SA face referire la un termen generic pentru un grup de valori care definesc caracteristicile IPSec și protecțiile aplicate unei conexiuni; acestea pot fi create și manual, folosind valori decise în avans de cele două părți, dar nu pot fi

reînnoite. O asociere de securitate, mai comun referită ca SA, este un bloc de bază pentru IPSec. Aceasta reprezintă o intrare în baza de date SA (SABD), care conține informații despre securitatea negociată între două părți pentru IKE sau IPSec. Sunt

două tipuri de SA:

• IKE sau ISAKMP SA -sunt folosite pentru traficul de control, cum ar fi negocierea

algoritmilor pentru criptarea traficului IKE și autentificarea utilizatorilor. Este o singură IKE SA între participanți și de obicei are mai puțin trafic și o durată de viață mai mare decât IPSec SA.

• IPSec SA – sunt folosite pentru a negocia algoritmii de criptare pentru traficul IP, bazându-se pe definirea regulilor de stabilire a traficului ce va fi protejat. Pentru că sunt

unidirecționale, cel puțin două sunt necesare (traficul de intrare și de ielire)

O problema pe care o ridica IKE este problema cu dispotitivele NAT, care modifică

transparent pachetele de ieșire. Prima problemă se refara la faptul că unele echipamente ar putea depinde de negocierea IKE făcută de pachetele de intrare trimise de pe portul 500 UDP. Dacă se introduce un proces NAT, portul pachetului final nu va fi, cu siguranță, cel așteptat deci negocierea nu va începe. Alt eveniment neplăcut apare când IKE include adresele IP ca

57

parte a procesului de autentificare, care depinde de modul IKE folosit. Dacă autentificarea se

bazează pe adresa IP, schimbările făcute de NAT vor cauza eșuarea procesului IKE.

Principala funcție a protocolului IKE consta in faptul ca ambele tipuri de SA sunt stabilite între participanții IPSec folosind protocolul IKE. Acest protovol operează în două

faze pentru a stabili aceste asociații de securitate:

Prima faza este schimbul în prima etapă, faza in care se stabilesc chei pentru sesiunea respectivă si asigurarea autentificarii reciproce a celor două capete IKE. Această fază creează o ISAKMP SA (asociere de securitate pentru IKE) care odată ce a fost stabilită, toate comunicațiile IKE dintre inițiator și cel care răspunde sunt protejate cu criptare și cu o verificare a integrității prin autentificare. Există o diferență între ISAKMP și IKE care trebuie prezizata: ISAKMP definește cum capetele IPSec comunică, cum realizează schimbul de mesaje și starea tranzițiilor prin care trec pentru a stabili conexiunea (mai exact arată scopul autentificării și schimbului de informații pentru interschimbul de cheie) iar IKE definește cum se realizează schimbul de cheie.

Etapa unu (cunoscută și ca IKE SA) reprezintă momentul în care cele două capete IPSec negociază cu succes un canal sigur prin care pot fi stabilite și transmise apoi SA-urile IPSec. Astfel, se garantează criptarea bidirecțională și autentificarea pentru alte schimburi IKE. Această fază poate fi realizată în două moduri: principal și agresiv.

Modul principal trateaza stabilirea unei IKE SA prin trei perechi de mesaje. În prima pereche de mesaje, fiecare capăt recomanda parametrii folosiți de SA. Patru parametrii dintre

aceștia sunt obligatorii și alcătuiesc așa numita suită de protecție:

• Algoritmul de criptare – specifică algoritmul care criptează datele: DES, 3DES, AES.

• Algoritmul de protecție a integrității -indică ce algoritmi de tip hash de pot folosi:

HMAC-MD5 sau HMAC-SHA-1

• Metoda de autentificare – sunt 3 posibilități de autentificare a utilizatorilor (chei

prestabilite, semnături digitale, criptare cu cheie publică)

• DH Group – este folosit pentru generarea unui secret comun într-o manieră sigură, astfel încât un observator a etapei 1 IKE să nu îl poată determina.

A doua pereche de mesaje execută un schimb de cheie prin DH, folosind parametrii negociați la primul pas. Conținutul acestei perechi de mesaje variază în funcție de metoda de autentificare. În cea de-a treia pereche de mesaje, fiecare capăt este autentificat (și aici contează metoda de autentificare folosită). În cazul cheilor prestabilite (figura 3.4),

58

rezumatele de autentificare se schimbă acum iar în cazul celorlalte două posibilități acesta

sunt folosite (au fost schimbate în timpul perechii de mesaje anterioare).

Metoda mai rapidă a modului principal este oferită de modul agresiv. Se negociază stabilirea IKE SA prin trei mesaje în locul celor trei perechi din modul principal. Primele două mesaje negociază parametrii IKE SA și realizează un schimb de cheie; al doilea și al treilea mesaj autentifică utilizatorii.

În primul mesaj prima stație trimite trei informatii: toți parametrii suitei de protecție ,

porțiunea sa de schimb de cheie DH care este un număr folosit o singură dată (nonce) și identitatea sa. În al doilea mesaj, cealaltă stație trimite patru informatii: parametrii suitei sale de protecție, proțiunea sa de DH, care este un numărul folosit o singură dată (nonce), identitatea sa și informația utilă de autentificare. Al treilea mesaj este utilizat pentru ca prima stație să trimită propria sa informație de autentificare.

Figura 3.4 Mecanismul de criptarea a datelor IPSec utilizând chei publice și chei private.

A doua faza se refera la schimbul în etapa a doua care furnizează negocierea și

stabilirea asociațiilor de securitate IPSec (IPSec SA) folosing ESP sau AH pentru protejarea

traficului IP. Scopul celei de-a doua etape este stabilirea asocierilor de securitate pentru o

59

conexiune IPsec actuală (IPSec SA). O conexiune IPSec între două sisteme necesită două

IPSec SA, pentru că acestea sunt unidirecționale. Aceste perechi sunt create prin intermediul

unui singur mod, modul rapid, care folosește trei mesaje pentru a stabili SA. Comunicațiile din acest mod sunt criptate prin metoda spacificată în IKE SA-ul stabilit în faza 1.

În primul mesaj, prima stație trimite trei informatii: cheile, numerele unice și sugestiile de parametri IPSec SA. Numerele unice se folosesc ca si măsură împotriva atacurilor de replicare.

În al doilea mesaj, cealaltă stație trimite cheile, numerele și selecțiile parametrilor IPSec SA și în plus procedurile hash de autentificare.

Al treilea mesaj este folosit doar pentru ca prima stație să trimită procedura hash pentru autentificare. După ce a doua stație validează al treilea mesaj, se poate spune că s-a

stabilit o asocieere de securitate IPSec, cele active fiind reținute într-o bază de date (SADB).

IKE SA și IPSec SA au o limită de viață, care nu poate fi mărită după ce SA a fost creată. Dacă o SA este aproape de sfârșitul duratei de viață, capetele ar trebui să creeze una nouă, printr-un proces de restabilire a cheii. Durata de viață a unei SA spune cât de des ar trebui fiecare SA să fie restabilită, bazându-se fie pe un anumit timp scurs fie pe cantitatea de trafic din rețea.

In mod asemanator cu modelu TCP/IP, IPSec are o multitudine de componente implicate și caracterizează un set complet de interacțiuni de-a lungul acestora. Structura protocolului asigură avantajul modularizării: când are loc o schimbare a unei componente, celelalte nu se schimbă implicit. Dezavantajul modularizării este că greu de explicat fără scheme, pur și simplu pentru că multe componente trebuie să lucreze împreună pentru ca protocolul să opereze.

Arhitectura IPSec presupune:

Nucleul (IPSec driver or core engine) – această componentă realizează criptarea,

decriptarea, autentificarea și verificarea semnăturii; de asemenea este responsabil pentru

coordonarea efortului altor componente IPSec pentru a asigura că poate îndeplini sarcinile.

Agentul de politică (IPSec Policy Agent) – este funcșia cognitivă a protocolului și examinează setările IPSec ale sistemului specificând ce trafic ar trebui protejat; nu protejeajă datele ci doar avertizeată ca un anumit trafic ar trebui protejat.

ISAKMP – este negociatorul setărilor de securitate ale Internetului; atunci când două stații vor să comunice, ISAKMP negociază grupul desetări folosite pentru criptare și autentificare.

60

IKE (Internet Key Exchange) – pentru că IPSecul folosește chei secrete împărțite,

trebuie să fie un mecanism care să conecteze echipamentele și să se pună de acord asupra unei chei; acesta depinde de setările furnizate de ISAKMP. In figura 3.4 este prezentata

Interacțiunea componentelor:

Figura 3.4 Interacțiunea IPSec

In momentul pornirii unui echipament se aplică politica locală sau de grup, dar se

poate aplica periodic în timp ce activează în rețea. Orice politică IPSec este preluată de angentul de politică IPSec. Atunci când există mai multe reguli stabilite, agentul monitorizează comuniația cu protocolul TCP/IP din toate aplicațiile, caută traficul care se potrivește acestora, adică acela care trebuie protejat.

Agentul de politică îi va comunica dispozitivului IPSec tipul de protecție de care este nevoie in momentul in care traficul de rețea (care necesită protecție) este identificat. Apoi, urmand ca echipamentul IPSec sa determine dacă există o Asociere de Securitate care poate fi folosită pentru a proteja traficul; dacă nicio SA nu există, funcția IKE va fi contactată; aceasta va folosi ISAKMP pentru a negocia autentificarea reciprocă și pentru a stabilit cheia. Apoi, IKE va furniza o SA activă către IPSec driver, care va proteja traficul. Astfel, traficul protejat va fi returnat către protocolul TCP/IP pentru procesare.

Cea mai importanta caracteristica referitoare la IPSec este faptul ca acesta este un standard Internet acceptat și că în momentul actual un număr din ce in ce mai de utilizatori și furnizori de servicii cooperează pentru a furniza o gamă completă de soluții IPSec. Folosind capacitatea de tunelare a IPSec, se pot implementa rețele virtuale private.

61

2) IKEv2

IKEv2 (descris in Anexa A din RFC 4306) vine cu urmatoarele imbunatatiri:

• NAT traversal: încapsulare lui IKE și ESP în portul UDP 4500 permite acestor

protocoale să treacă printr-un dispozitiv sau firewall ce efectueaza NAT.

• Schimbul de mesaj simplu: IKEv2 are un mecanism de schimb inițial de patru mesaj

în timp ce IKE furniza opt mecanisme distincte de schimb initiale, fiecare dintre care avand

avantaje și dezavantaje.

• Mecanisme criptografice mai puține: IKEv2 utilizează mecanisme criptografice

pentru a proteja pachetele sale, care sunt foarte asemănătoare cu ceea folosite de IPsec pentru încapsularea incarcaturii de securitate (ESP) pentru a proteja pachetele IPsec. Acest lucru a dus la implementari simple si certificari de criterii comune, care necesită fiecare implementare criptografică a fi validate separat.

• Fiabilitate și managementul starii: IKEv2 utilizează numere de secvență și confirmari

pentru a oferi fiabilitate și pentru a mandata unele erori la procesare. IKE ar putea ajunge într-

o stare moarta din cauza lipsei de măsuri de fiabilitate, în situatia în care ambele părți se așteptau ca cealaltă să inițieze o acțiune .

• Rezistența la atacul de tip DoS (Denial of Service – Refuzul Serviciului) : IKEv2 nu

efectuează procesarea până când nu determină dacă există de fapt un solicitant. Aceasta

tactica a rezolvat problemele cu atacurile DoS suferite de IKE care efectua o mulțime de

prelucrari criptografice din locații fantoma

3.4 Principalele avantaje ale rețelelor virtuale private

Reducerea costurilor – furnizorii de VPN pot înșira o mulțime de beneficii pe care le

aduce tehnologia, multe apărând odată cu dezvoltarea ei. Poate cel mai puternic argument folosit este reducerea costurilor. Rețelele virtuale private sunt mult mai ieftine decât rețelele private proprietare ale companiilor; se reduc costurile de operare a rețelei (linii închiriate, echipamente, administratori rețea). Dacă folosiți Internetul pentru a distribui servicii de rețea la mare distanță, atunci puteți evita achiziția de linii închiriate, extrem de scumpe, între reprezentanțe și firmă, dar și costurile convorbirilor interurbane pe modemuri dial-up sau ISDN. Reprezentanța va trebui să se conecteze numai local, la un provider Internet, pentru a ajunge în rețeaua firmei mamă. Economii se fac și relativ la lipsa necesității investițiilor în

62

echipament WAN adițional, singura achiziție fiind legată de îmbunătățirea capacităților de

conectare la Internet a serverului.

Integrare, simplitate, ușor de implementat – rețeaua virtuală privată poate fi imediat realizată peste conexiunea deja existentă la Internet, nefiind necesară o infrastructură separată. Se simplifică topologia rețelei companiei private. De asemenea, prin aceeași conexiune se pot integra mai multe aplicații: transfer de date, Voice over IP, Videoconferințe.

Ușurința administrării – in cazul unei interconectări complete a sucursalelor unei firme, liniile private pot deveni un coșmar. Trebuie instalate și administrate linii între fiecare două sucursale. Folosind Internetul, nu trebuie decât să asiguri fiecarei sucursale acces la Internet. În cazul accesului utilizatorilor de la distanță, problemele de administrare sunt transferate complet ISP.

Ignorarea învechirii morale a tehnologiei – riscul învechirii morale a tehnologiei se transferă de la corporație la ISP. Accesul la distanță prin Internet permite utilizatorilor să folosească tehnologii de acces variate, inclusiv ISDN și modemuri. Cum apar tehnologii de acces de viteză mare, cum ar fi ASDL, ATM, organizația va putea profita de ele fără a face investiții în echipamente. ISP suportă majoritatea costurilor schimbării tehnologiilor.

Mobilitate – angajații mobili precum și partenerii de afaceri (distribuitori sau furnizori) se pot conecta la rețeaua companiei într-un mod sigur, indiferent de locul în care se află.

Scalabilitate – afacerea companiei crește, deci apare o nevoie permanentă de angajați mobili și conexiuni securizate cu partenerii strategici si distribuitorii. Pe măsură ce cererea de acces la distanță crește, organizația nu va avea nevoie să cumpere și să instaleze echipamente de comunicație noi. E nevoie doar de comandarea unui nou cont de acces la un ISP.

Securitate – Rețeaua virtuală privată asigură un nivel ridicat de securitate a informațiilor transmise prin utilizarea unor protocoale avansate de autentificare și criptare. Informațiile care circulă prin VPN sunt protejate prin diferite tehnologii de securitate (criptare, autentificare, IPSec). Nu trebuie să vă temeți că datele traficate prin VPN pot fi compromise.

Conectivitate globală – pe măsură ce economia continuă să se globalizeze, rețelele de firmă trebuie să crească în afara granițelor statale. Infrastructura cu fibră optică pentru linii private de calitate nu este disponibilă în multe țări. Internetul, pe de altă parte, este ideal pentru conectivitate internațională. Protocolul Internetului (IP) poate rula pe orice

infrastructură de comunicație. [13]

63

3.5 "Best practices" in retelele private virtuale

Securitatea VPN se bazează foarte mult pe autentificare și criptare. Aceasta este

considerata cele mai bune practici pentru a utiliza întotdeauna cea mai bună autentificare posibila, în cele mai multe cazuri aceasta fiind L2TP peste IPSec cu utilizarea de carduri inteligente. Din nou, dacă solutia cardurilor inteligente nu sunt fezabile, atunci ar trebui să fie utilizate certificatele de autentificare.

Adresele IP ar trebui să fie întotdeauna atribuite de catre serverul VPN, dacă este posibil.

Trafic trebuie să fie întotdeauna monitorizat în timp real. Toate computerele care

utilizează VPN ar trebui să rămână întotdeauna la curent cu actualizările critice și definițiile

antivirus.

Și toti utilizatorii ar trebui să fie educați în ceea ce priveste activitățile ce sunt permise

a fi realizate pe computerele client, inclusiv ceea ce programe pot fi instalate.

64

4. METODE DE CONTROL AL ACCESULUI LA SERVICII

PRIN SCHIMB DE CHEI DE ACCES

4.1 SSL și TLS

Protocoale criptografice care asigură posibilitatea realizării de comunicații sigure prin

Internet pentru web, e-mail, Internet fax și pentru alte transferuri de date sunt Transport Layer

Security (TLS) și predecesorul său, Secure Sockets Layer (SSL). Intre SSL 3.0 și TLS 1.0

există anumite deosebiri, dar în esență protocolul rămane același. Protocolul a fost creat inițial

de Netscape Communications Corporation ca parte integrantă a browserului său web (pe

partea de client) și a web server-ului. Ulterior a fost acceptat și de Microsoft și alți

dezvoltatori de aplicați client/server pentru Internet. A devenit un standard de facto pentru

Internet iar mai apoi prin crearea TLS a devenit un standard Internet pentru securitatea web

dezvoltat de IETF (Internet Engineering Task Force). Modul în care poate fi folosit protocol SSL/TLS ca și tehnologie de securitate de bază pentru protecția tranzacțiilor online este

prezentat în lucrarea.

Protocolul TLS permite aplicațiilor client/sever să comunice, dar fiind împiedicată

ascultarea liniilor, modificarea datelor și falsificarea mesajelor. TLS oferă autentificare la

capetele unei comunicații și confidențialitatea comunicațiilor prin Internet. De cele mai multe

ori, doar serverul se autentifică – clientul rămanand neautentificat; astfel utilizatorul final (o

persoană sau o aplicație cum ar fi un web browser) poate fi sigur că la capătul celălalt al liniei

de comunicație este cine trebuie. In cazul autentificării la ambele capete (autentificare

mutuală) ambele entități implicate în procesul de comunicare primesc asigurări în legătura cu

entitatea cu care comunică. Pentru a se face posibila autentificarea căii mutuale trebuie

implementata o infrastructura cu chei publice (PKI) la clienți.

TLS lucreaza sub nivelurile protcoalelor de aplicație cum este HTTP, FTP, SMTP și

NNTP si deasupra protocoalelor de transport TCP și UDP. Poate fi folosit cu orice protocol

care folosește conexiuni sigure (cum este TCP), dar cel mai des este folosit împreună cu HTTP pentru a forma HTTPS. HTTPS este folosit pentru a securiza paginile World Wide

Web din aplicații cum ar fi cele de comerț electronic. TLS este folosit de asemenea și în

SMTP așa cum este specificat în RFC 3207. Aceste aplicații folosesc certificate pentru chei

publice pentru a verifica identitatea entităților implicate în comunicație.

65

TLS implică trei faze importante:

• Criptarea traficului cu metode simetrice.

•Negociere între entități pentru funcționarea algoritmului;

• Schimbul de chei bazat pe criptare cu chei publice și autentificare pe bază de

certificat;

4.2 Arhitectura TLS

Protocolul TLS Handshake și protocolul TLS Record formeaza TLS, aceste doua

protocoale sunt suprapuse, primul fiind deasupra ultimului.

Protocolul TLS Record furnizează încapsularea sigură a canalului de comunicație

pentru a fi folosit de protocoalele de le nivelurile superioare. Acest protocol realizează o

conexiune sigură și rulează deasupra nivelurilor TCP și IP. Protocolul ia mesajele ce trebuie

transmise, fragmentează datele în blocuri ce pot fi gestionate ușor, opțional poate comprima

datele, aplică o funcție MAC (de ex. HMAC) pentru integritatea datelor, criptează datele

folosind un algoritm simetric (pentru confidențialitate) și transmite rezultatul la destinație. Cand se ajunge la destinație, datele sunt decriptate, se verifică MAC-ul, opțional se face decompresia, se reasamblează blocurile de date și sunt transmise la procesele de aplicație de

la nivelul superior.

Pentru criptarea simetrică și pentru HMAC, cheile sunt generate în mod unic pentru

fiecare sesiune și sunt bazate pe o informație secretă negociată de protocolul TLS Handshake.

Referitor la protocolul TLS Handshake, acesta permite serverului și clientului să se

autentifice unul față de altul, negociază algoritmii criptografici ce vor fi folosiți, stabilește

cheile criptografice și în final stabilește o conexiune sigură pentru protocolul TLS Record care

realizează serviciile de comunicație sigură pentru protocoalele de aplicație de la nivelul superior.

66

4.2.1 Protocolul de Handshake TLS

Protocolul de autentificare în TLS poarta denumirea de Protocolul Handshake. Aceste

două entități implicate executata operațiile urmatoare:

•Schimbul de mesaje hello pentru stabilirea algoritmilor, schimbul de valori aleatoare,

verificarea faptului că nu este vorba de reluarea unei sesiuni anterioare.

• Schimbul parametrilor criptografici necesari pentru a permite clientului și serverului să stabilească un secret (numit "secret master").

• Schimbul de certificate și informație criptografică pentru a permite clientului și

serverului să se autentifice unul față de altul.

• Generarea secretelor de sesiune din secretul master prin schimbul de valori aleatoare.

• Verificarea faptului că cealaltă entitate a calculat aceeași parametri de securitate

pentru a confirma faptul că handshake-ul s-a încheiat fără să fi intervenit un atacator.

• Canalul sigur stabilit este transmis protocolului TLS Record pentru a procesa

comunicațiile de la nivelul de aplicație. Aceste operații sunt realizate prin schimbul a patru

mesaje descrise mai jos.

4.3 Arhitectura SSL

Protocolul SSL rulează deasupra protocolului TCP/IP și sub protocoalele de nivel înalt

ca și HTTP si IMAP. El folosește TCP/IP pentru protocoalele de nivel înalt și după ce permite autentificarea unui server de SSL la un client de SSL si autentificarea clientului la server,

stabilește o conexiune encriptată intre cele doua mașini. Aceste capabilități reușesc să resolve

probleme fundamentale ale comunicațiilor Internet și al altor rețele TCP/IP :

Autentificarea serverului SSL: permite unui utilizator să confirme identitatea

serverului. Programulul de verificare al clientului foloșeste tehnici standard de criptografiere prin chei publice, prin care poate verifica dacă certificatul serverul și numarul de identificare public sunt valide. Aceste autentificari sunt importante daca de exemplu clientul trimite un numar de card serverului și vrea să verifice identitatea serverului primită ca raspuns.

Autentificarea clientului SSL : permite unui server să confirme identitatea clientului. Folosind aceleași tehnici ca și cele pentru autentificarea serverului, programulul de verificare al serverului verifică daca certificatul și numărul de identificare public al clientului sunt valide.

67

Conexiune encriptata SSL : trebuie ca totalitatea informatiile trimise între client si

server să fie criptate de programul transmițător și decriptate de programul receptor, aceasta

oferind un mare grad de confidențialitate. Confidențialitatea este importantă pentru amandouă

parțile intr-o tranzacție privată. Chiar mai mult, toate datele trimise in timpul unei conexiuni

SSL sunt protejate cu un mecanism de detectare a coruperilor de date care sunt automat

determinate dacă pachetele au fost modificate pe parcursul transportului.

Protocolul SSL contine două subprotocoale : protocolul SSL de înregistrare și protocolul SSL de handshake. Protocolul de înregistrare definește formatul folosit pentru transmiterea datelor. Protocolul de handshake implică folosirea protocolului de ănregistrare pentru a schimba o serie de mesaje intre serverul SSL și clientul SSL prima data cand stabilesc o conexiune SSL. Acest schimb de mesaje este planuit pentru a facilita urmatoarele

actiuni :

• Autentifică serverul pentru client

• Permite clientului și serverului sa selecteze algoritmii de criptare, de cifrare,

amandouă metodele fiind disponibile

• Opțional autentifică clientul la server

• Folosește tehnici de criptare prin chei publice pentru a proteja secretele

• Stabilește o conexiune SSL criptată.

4.3.1 Criptări folosite de SSL

Protocolul SSL poate suporta o o gama larga de algoritmi de criptare sau cifruri,

folosite in operații cum ar fi : autentificarea serverului la client si vice-versa, transmiterea certificatelor, stabilirea cheilor pentru sesiuni. Clienții și serverele pot avea suite de cifruri sau

seturi de cifruri. Aceasta depinzând de factori cum ar fi versiunea de SSL suportată, politicile

companiilor privind criptarea și restrictiile guvernamentale asupra programelor de criptare folosite de SSL. Una din importantele functii este faptul ca protocolul de handshake determină felul in care serverul și clientul stabilesc suita de cifruri pe care le vor folosi pentru autentificare, pentru transmiterea certificatelor. Mai jos se observa mai mulți algoritmi de

criptare:

• DES – un algoritm de criptare folosit de guvernul SUA.

• DSA – parte din autentificarea digitală standard folosita de guvernul SUA. • KEA – un algoritm folosit pentru interschimbarea.

68

• MD4 – algoritm dezvoltat de Rivest.

• RC2 si RC4 – cifru de criptare Rivest dezvoltate pentru "RSA Data Security".

• RSA – algoritm de chei publice folosit pentru criptare și autentificare dezvoltatat de

Rivest, Shamir si Adleman.

• RSA key exchange – algoritm de interschimbare de chei pentru SSL bazat pe algoritmul RSA.

• SHA-1 – functie de hashing folosită de guvernul SUA • Triple DES – DES aplicat de 3 ori.

In algoritmii ca KEA si RSA, interschimbarea de chei guvernează calea prin care

serverul și clientul determină cheile simetrice pe care le vor folosi dealungul unei sesiuni SSL. Cele mai folosite suite de cifruri SSL folosesc RSA. Protocoalele SSL 2.0 si 3.0 suportă seturi de suite de cifruri. Administratorii pot determina care din suitele de cifruri se folosesc și care

nu pentru client și server. In momentul in care un server și client fac schimb de informațiipe durata protocolului handshake, se remarca de ambele parțile cea mai bună suită de cifruri pe

care o au in comun și o vor folosi pentru sesiune SSL. Deciziile privind care din suita de

cifruri depind de sensibilitatea datelor implicate, de viteza cifrului și de aplicabilitatea regulilor de export. Dupa legile guvernului SUA, se restrictionează criptarea pe mai mult de 40 biti daca se comunica cu cineva din afara SUA (daca serverul implicat are un ID special atunci se inlatura restrictia). Pentru a servi o cat mai mare arie de utilizatori, administratorii ar putea să folosească cât mai multe suite de cifruri. Cand un client sau server din SUA vrea să negocieze cu un client sau server tot din SUA vor folosi cel mai bun cifru, iar cand un client/server din SUA va negocia cu un client/server din afara SUA vor folosi acele cifruri care sunt permise de legile SUA. Pentru ca cifrurile pe 40 de biti pot fi sparte relativ usor,

administratorii care sunt ingrijorați de spargeri si cei care sunt dintr-o tara care permite

folosirea legală de cifruri puternice nu vor folosi cifrurile pe 40 de biti.

4.3.1.1 Suite de cifruri cu chei RSA

In tabelul de mai jos (Tabelul 4.1) sunt evidentiate suitele de cifruri suportate de SSL

si cele care utilizeaza algoritmul RSA. Tabelul contine cifruri care sunt suportate de SSL 2.0 si SSL 3.0, aceasta doar daca nu sunt indicatii privind contrariul. Cifrurile sunt aranjate in ordine descrescatoare, de la cele mai tari la cele mai slabe.

69

Puterea cifrului si recomandarile sale

Cele mai tari cifruri : premise doar in SUA.

Este folosit de banci si instituții care folosesc

date importante.

Cifruri puternice : premise doar pe teritoriul

SUA. Aceste cifruri suportă criptare destul de bună pentru majoritatea afacerilor și nevoilor guvernamentale.

Suitele de cifruri exportabile : aceste cifruri

nu sunt asa de bune ca cele de mai sus, dar

pot fi exportate in majoritatea țărilor (a se

nota ca Franta le permite pentru SSL, dar nu

și pentru S/MIME).

Cele mai slabe cifruri. Aceste suite de cifruri

Suite de cifruri

Triple DES, care sunt criptate pe 168 biti, cu

mesaje de autentificare SHA 1. Este cel mai

puternic cifru suportat de SSL, dar nu este asa

de rapid ca RC4. Triple DES foloseste de 3 ori mai mult timp decat un simplu DES. Pentru ca are o marime așa de mare (168 biti), sunt aproximativ 3.7 * 1040.

RC4 pe 128 de biți si mesaj de autentificare

MD4. Sunt dupa Triple DES cele mai

puternice criptari. Permit aproximativ 3.4 * 1038 Sunt foarte dificil de spart. RC4 sunt cele mai rapide dintre cifrurile suportate de SSL.

RC2 pe 128 de biți si cu mesaj de

autentificare MD4. Sunt ca si RC4, dar sunt

mai lente putin.

DES pe 46 de biți si cu mesaj de autentificare

SHA 1. Este mai puternic decat criptarea pe

40 de biți dar nu asa de puternic ca cel pe 128

de biti. Datorita celor 46 de biti, DES are

aproximativ 7.2 * 1016 SSL 2.0 foloseste

MD4 in loc de SHA 1 pentru autentificarea mesajelor.

RC4 pe 40 de biți și mesaj de autentificare

MD4. RC4 pe 40 de biți permite aproximativ

1.1 * 1012 chei posibile. RC4 sunt cele mai rapide cifruri dintre cele suportate.

RC2 pe 40 de biți și mesaj de autentificare

MD4. RC2 permite la fel de multe chei ca și

RC4, dar este mai puțin rapid.

70

prevad autentificare si detectie de coruperi de

date, dar nu au criptare. Administratorii de

servere trebuie sa fie precauți în a folosi

aceste cifruri pentru ca datele nu sunt criptate

și pt fi accesate de hackeri.

Fără criptare si cu mesaj de autentificare

MD4. Aceste cifruri folosesc MD4 pentru a detecta coruperea datelor. Se foloseste cand

serverul și clientul nu au nici un cifru comun.

Tabelul 4.1 Suitele de cifruri suportate de SSL

4.3.2 Protocolul SSL de handshake

O combinație de criptare cu chei publice și chei sim etrice se foloseste pentru

Protocolul SSL . fiecare dintre cele doua criptari are avantaje si dezavantaje, astefel criptarea

cu chei publice are tehnici mai bune de autentificare, iar criptarea cu chei simetrice este mai rapidă decât criptarea cu chei publice. Sesiune SSL mereu porneste cu un schimb de mesaje numit SSL "handshake". Protocolul "handshake" permite serverului să se autentifice clientului folosind tehnici cu chei publice, apoi permite clientului și serverului sa coopereze la creearea unor chei simetrice folosite la criptare rapidă, decriptare și detectie de erori in timpul sesiunii care urmeaza. In mod optional, protocolul de "handshake" ii lasa optiunea clientului să se

autentifice la server. Mai jos se pot observa pașii derularii unui protocol "handshake" :

1. Clientul trimite serverului numarul versiunii de SSL, setările cifrului, date generate

aleator și alte informații pe care serverul le folosește pentru a comunica cu clientul folosind

SSL.

2. Serverul trimite clientului numărul versiunii de SSL, setările cifrului, date generate

aleator și alte informații pe care clientul le folosește pentru a comunica cu serverul folosind

SSL. Deasemenea serverul iși trimite certificatul și dacă clientul cere serverului o resursă care

are nevoie de autentificarea clientului, atunci cere și certificatul clientului.

3. Clientul folosește unele informații trimise de server pentru autentificarea serverului

(vezi mai jos "Autentificarea serverului"). Daca serverul nu poate fi autentificat, utilizatorul este avertizat de problema și informat că o conexiune criptată și autentificată nu poate fi

stabilită. Dacă serverul poate fi autentificat cu success atunci se trece la pasul

4. Folosind toate datele generate in protocolul "handshake" până acum, clientul (cu cooperarea serverului, depinzând de cifrul folosit) creează ceea ce este numit "premaster

secret" pentru sesiune, il criptează cu cheia publică a serverului (obținuta de pe certificatul

serverului, trimis la pasul 2), și trimite "premaster secret" spre server.

71

5. Dacă serverul a cerut autentificarea clientului (pas optional in "handshake"), clientul

deasemenea iși pune semnatura pe o data, care este unică in acest "handshake" și este știută și de server. In acest caz clientul trimite data semnata si certificatul sau spre server impreuna cu "premaster secret"-ul criptat.

6. Dacă serverul a cerut autentificarea clientului, serverul incearcă să autentifice clientul (vezi "Autentificarea Clientului" mai jos). Dacă clentul nu poate fi autentificat, sesiunea se termină. Dacă clientul poate fi autentificat cu success, serverul iși folosește cheia privată pentru decriptarea "premaster secret"-ului, apoi dupa o serie de pași (pe care clientul îi parcurge deasemenea, pornind de la același "premaster secret") generează "master secret"-ul.

7. Clientul și serverul folosesc "master secret"-ul pentru a genera "session keys", care sunt chei simetrice folosite la criptarea si decriptarea informatiilor schimbate in timpul sesiunii SSL și pentru a verifica integritatea acestora, care inseamnă a detecta orice schimbări in date provenite in timpul transmiterii acestora.

8. Clientul trimite un mesaj serverului informandu-l ca in viitor mesajele primite vor fi criptate cu cheia sesiunii (session key). Apoi trimite separat, un mesaj criptat care indica

terminarea porțiunii de "handshake" a clientului.

9. Serverul trimite un mesaj clientului informandu-l ca in viitor mesajele primite vor fi

criptate cu cheia sesiunii (session key). Apoi trimite separat, un mesaj criptat care indică

terminarea porțiunii de "handshake" a serverului.

10. Protocolul "handshake" este acum complet si sesiune SSL a inceput. Clientul și

serverul folosesc aceleași "session keys" pentru a cripta și decripta datele ce și le vor trimite unul altuia si pentru a verifica integritatea lor.

Dacă doresti sa verifici dacă certificatul clientului este prezent in directorul LDAP la

locul rezervat lui, o poti realiza inainte de a continua cu sesiunea, configurand serverele

Netscape. Aceasta opțiune de configurare lasa o cale de a te asigura că certificatul clientlui nu

a fost revocat. Este important faptul că autentificarea clientului și serverului implică criptarea

unor parți din date cu o cheie dintr-o pereche de chei private și decriptarea folosind cealalta

cheie.

In cazul autentificarii serverului, clientul criptează "premaster secret"-ul cu cheia publică a serverului. Doar cheia privată corespunzatoare poate decripta corect secretul, prin

aceasta clientul având siguranța ca identitatea asociată cu cheia publică este defapt serverul cu

care clientul este conectat. Altfel, serverul nu poate decripta "premaster secret"-ul si nu poate

genera chei simetrice necesare pentru sesiune, și sesiunea se va termina.

72

In cazul autentificării clientului, clientul cripteaza date aleatoare cu cheia privată si

crează semnatura digitala. Cheia publica din certificatul clientului poate valida corect semnatura digitala doar daca cheia private corespunzatoare a fost folosită. Altfel, serverul nu poate valida semnatura digitală si sesiunea se termină.

4.3.2.1Autentificarea serverului

Programul client SSL are nevoie mereu de autentificarea serverului, sau validarea

criptografica realizataa de catre client asupre identității serverului. Pentru a autentifica

identitatea acelui pe care certificatul afirma ca il reprezintă, clientul folosește certificatul de la

Pasul 3. Legatura dintre o cheie publică și serverul identificat de certificatul care conține cheia

publică se poate autentifica in moemntul in care un client SSL primeste un raspuns de "da" la

urmatoarele 4 intrebări, prezentate in figura 4.1. Chiar daca cele 4 intrebări nu sunt parte tehnica a protocolului SSL, este de datoria clientului să poată să realizeze acești pași, care pot asigura de identitatea serverului și pot ajuta impotriva atacurilor cunoscute.

Figura 4.1 Autentificarea legaturăturii dintre o cheie publica și server

73

Un client SSL trece prin urmatorii pași pentru a autentifica identitatea serverului :

1. Este data de astazi in perioada de valabilitate? Clientul verifică perioada de

valabilitate a certificatului serverului. Dacă data curentă este in afara perioadei de valabilitate procesul de autentificare se oprește aici. Dacă data este bună clientul merge la Pasul 2.

2. Este CA-ul inițiat un CA valid? Fiecare program client SSL contine o listă de CA-

uri de incredere. Lista determină ce certificate de server vor fi acceptate. Daca DN (numele

distins – denumire acceptată) al CA-ului inițiat se potrivește cu DN-ul unui CA de pe CA de incredere, atunic raspunsul este "da" și se trece la Pasul 3. Daca CA-ul nu este pe listă atunci serverul nu va fi acceptat doar daca clientul poate verifica un certificate care se "inrudește" cu unul de lista de incredere.

3. Cheia publică initiata validează semnatura digitala a initiatorului? Clientul folosește cheia publică de pe certificatul de autentificare CA (aflat la pasul 2) pentru a valida semnatura

digitală a CA-ului. Daca informația de pe certificatul serverului a fost schimbată de când a

fost semnată de CA sau daca cheia publică de pe certificate nu corespunde cu cheia private

folosită de CA să semneze certificatul serverului, clientul nu va autentifica identitatea serverului. Dacă semnatura digitală CA poate fi validată, serverul recunoaște certificatul clientului ca o validă "scrisoare de introducere" de la acel CA și trece la pașii următori. Din acest punct,clientul a determinat ca certificatul serverului este valid. Este de responsabilitatea cientului să treacă la Pasul 4 înaintea Pasului 5.

4. Coicide numele domeniului specificat in certificat cu numele domeniului real al serverului? Acest pas confirmă ca serverul este cu adevarat localizat la aceeași adresă specificată de numele domeniului din certificatul lui. Chiar daca Pasul 4 nu este o parte

tehnică a protocolului SSL, este singura protecție impotriva atacului de securitate "man in the

middle attack". Clientul trebuie să refuze să autentifice serverul sau să stabilească o conexiune

dacă domeniul serverului nu se potrivește. Daca numele actual al domeniului se identifică cu numele din certificate atunci se trece la Pasul 5.

5. Serverul este autentificat. Clientul a terminat SSL "handshake"-ul. Dacă clientul nu ajunge la pasul 4 pentru un motiv oarecare, identitatea serverului nu poate fi autentificata, și utilizatorul va fi anuntat de problemă si informat ca nu se poate stabili o conexiune autentificata. Dacă serverul dorește autentificare clientlui, serverul va initia "Autentificarea clientului".

După acesti pași, serverul poate sa iși folosescă cu success cheia privată sa decripteze "premaster secret"-ul trimis de client la Paul 4 al "handshake". Altfel sesiunea SSL se termină.

74

Aceasta aduce asigurări adiționale ca identitatea asociată cu cheia publica a serverului este a

serverului cu care clientul este conectat.

4.3.2.2 Autentificarea clientului

Configurarea Programuluil server SSL se poate face fie sa ceară autentificarea

clientului, fie sa valideze criptografic identitatea clientului. In momentul in care un server configurat in acest fel, cere autentificarea clientului, clientul trimite serverului certificatul și o data semnată digital pentru a se autentifica. Serverul folosește data semnată digital pentru a valida cheia publică de pe certificat și să autentifice identitatea pe care certificatul posesor spune că o reprezintă. Protocolul SSL cere clientului să creeze o semnatură digitală creand o mixtura din data generată aleator in timpul "handshake"-ului știută doar de client și server. Mixtura de date este criptată cu cheia privată care corespunde cheii publice din certificatul prezentat serverului. Pentru a autentifica legatura dintre cheia publica și persoana sau entitatea identificată de certificate care conține cheia publică, un program server SSL trebuie sa primească "da" la primele 4 intrebări din figura 4.2. Cea dea 4-a intrebare nu este o parte din protocol, dar serverele Netscape pot fi configurate să suporte și această verificare.

75

Figura 4.2 Autentificarea legăturii dintre cheia publică și persoana care conține cheia

publică.

Un server SSL trece prin urmatorii pași pentru a autentifica un client :

1. Cheia publică a utilizatotului validează semnatura digitală a acestuia? Serverul verifică dacă semnatura digitală a utilizatotului poate fi validată cu cheia publică din certificate. Dacă da, serverul stabilește că acea cheie publică este detinută de acel John Doe (necunoscut) se potrivește cu cheia privată folosită pentru crearea semnăturii digitale și că data nu a fost coruptă deoarece a fost semnată. In acest punct, legatura dintre cheia publică si DN-ul specificat nu a fost incă stabilită. Certificatul poate fi creat de altcineva incercand să inșele sa pară acel user. Pentru a valida legatura dintre cheia publica si DN, serverul trebuie sa treacă de pasul 3 si 4.

2. Este data de astăzi in perioada de valabilitate? Serverul peioada de valabiliate a certificatul clientului. Daca este bună se trece la Pasul 3. Dacă este expirat atunci se termină autentificarea cu "nu".

3. Este CA-ul inițiat un CA de incredere? Fiecare program server SSL deține o listă

de certificate CA de "incredere". Această listă determină care certificate le va accepta

serverul. Dacă DN al CA-ului inițiat se potrivește cu DN al CA-ului unui CA din lista celor de

incredere atunci raspunsul este "da" și se trece la Pasul 4. Dacă CA-ul nu este pe lista atunci

clientul nu va fi acceptat doar daca serverul poate verifică un certificate care se "inrudeste" cu unul de lista de incredere. Administratorii pot controla care certificate sunt de incredere și care nu.

4. Initiind cheia publică CA se validează semnatura digitală a initiațorului? Serverul

folosește cheia publică de pe certificatul CA pentru a valida semnatura digitală a CA-ului.

Daca informația de pe certificate a fost schimbată de cand a fost semnată de CA sau cheia publică de pe certificatul CA nu corespunde cu cheia privată folosită de CA sa semneze certificatul, serverul nu va autentifica identitatea clientului. Dacă semnatura digitala a CA-ului poate fi validată, serverul tratează certificatul userului ca fiind o scrisoare de introducere validă de la CA si pornește mai departe. Din acest punct protocolul SSL permite serverului să considere clientul autentificat și sa treacă la Pasul 6. Serverele Netscape pot fi configurate

opțional să treacă prin Pasul 4 inaintea Pasului 6.

76

4. Este certificatul utilizatorului present în intrarea LDAP a utilizatorului? Acest pas

opțional permite o modalitate de a refuza un certificat de utilizator chiar dacă trece de

celelalte teste. Serverul Netscape de certificare poate șterge automat un certificat revocat din

intrarea LDAP a utilizatotului. Toate serverele care sunt setate sa treacă prin acest pas vor refuza autentificarea certificatului sau să stabileasca o conexiune. Daca certificatul utilizatorului din director este identic cu certificatul utilizatorului present in "handshake" se trece la Pasul 5.

5. Este clientul autentificat autorizat să acceseze resursa dorită? Serverul verifică ce resurse sunt permise clientului să acceseze in conformitate cu lista controlului de accese a serverului (ACLs) și stabilește o conexiune cu acces adecvat. Daca serverul nu ajunge la Pasul 5 din orice motiv, utilizatorul nu poate fi autentificat si nu i se permite să acceseze resuresele serverului care necesită autentificare.

4.4 Atacuri rezolvate în SSL v3

Handshake-ul inițial nu este protejat in versiunea 2 a SSL, astfel un atacator activ

poate elimina din cererea initiala cifrurile cu criptare puternică, ceea ce cauzează alegerea unei criptări mai slabe între partile ce comunică. În versiunea 3 atacul a fost ameliorat prin adaugarea unui mesaj de final la sfârșitul handshake-ului în care fiecare parte trimite un rezumat al mesajelor din handshake.

Versiunea 3 a SSL a fost imbunatatita, astfel adaugandu-se un mesaj de terminare care să indice că nu mai există date de transferat. Versiunea 2 fiind bazata pe închiderea conexiunii de catre protocolul TCP, acesta nu este protejat criptografic si un atacator ar putea trimite un

mesaj fals care să cauzeze închiderea conexiunii, fară ca aplicația să-și dea seama că aceasta a

fost închisă anormal.

4.5 Diferențe între SSL și TLS

Dupa cum se poate observa , TLS a fost creat de catre IETF ca raspuns la multitudinea

de protocoale incompatibile care serveau aceluiași scop si anume comunicarea securizată prin

rețea. Modificările aduse de TLS nu sunt substanțiale si multă lume îl privește mai degrabă ca

77

o actualizare minoră a SSL. Diferențele între cele două protocoale sunt rezumate în cele ce

urmeaza:

• Numărul de versiune: pentru TLS, numarul de versiune este 1.3, fata de 3.0 pentru

SSL, ceea ce întarește convingerea unora ca TLS este doar o actualizare minoră a SSL.

• MAC: TLS folosește ultima versiune de HMAC, iar acesta acoperă și câmpul de versiune.

• Mesajul CERTIFICATE_VERIFY: Funcția de dispersie este calculată doar după

mesajele de handshake

• Coduri de avertizare: TLS definește mai multe coduri de avertizare decât SSL.

•Cifruri: TLS nu are suport pentru schimbul de chei Fortezza si pentru criptarea

Fortezza.

• Padding: TLS permite padding cu un numar variabil de octeti (maxim 244)

4.6 Protocolul de login la distanță Secure Shell (SSH)

Protocolul Secure Shell (SSH) este o suită de protocoloale de autentificare, bazat pe

criptografia cu chei publice, care lasa permisiunea unui utilizator să se conecteze la un server

la distanță de pe o mașină client printr-o rețea nesigură, pentru a executa în siguranță comenzi

pe mașina de la distanța și pentru a muta fișiere de la o mașină la alta. Protocolul este un

standard industrial de facto și este folosit pe scară largă în sistemele UNIX sau Linux. Partea

de client a protocolului poate rula și pe alte platforme cu alte sisteme de operare. Motivul pentru care protocolul rulează în principal pe sisteme UNIX/Linux este arhitectura deschisă a acestor sisteme de operare care oferă sesiuni de comenzi interactive pentru utilizatori la

distanță.

Ideea principala a protocolului SSH este că un utilizator pe o mașina client descarcă o

cheie publică de pe un server de la distanță și stabilește un canal de comunicație sigur între el (clientul) și server folosind cheia publică descărcată și anumite informații criptografice ale

utilizatorului. Parola poate fi criptată folosind cheia publică a serverului și transmisă la server

doar in momentul in care informațiile criptografice reprezintă o parolă

78

4.6.1 Arhitectura SSH

Protocolul SSH lucreaza între două calculatoare, calculatoare intre care nu există nicio

relație de încredere printr-o rețea de comunicație nesigură. Unul este serverul (host-ul) de la distanță iar celălalt este clientul de la care utilizatorul se conectează la server folosind

protocolul SSH. Suita de protocoale SSH este formată din trei componente majore:

• Protocolul SSH la nivel transport care oferă clientului serviciul de autentificare al serverului. Acest protocol se bazează pe chei publice. Acest protocol primește la intrare la partea de server o pereche de chei (privată/publică). La ieșire protocolul va realiza un canal

sigur (în ceea ce privește confidențialitatea și integritatea datelor) autentificat unilateral de la

server la client. Acest protocol va rula peste o conexiune TCP (Transmission Control

Protocol) și IP (Internet Protocol), dar poate rula și peste alte fuxuri de date sigure.

• Protocolul SSH de autentificare al utilizatorului rulează peste canalul autentificat unilateral stabilit de componenta precedentă. Acesta suportă numeroase protocoale de

autentificare unilaterală pentru realizarea autentificării entităților de la client la server. Pentru

ca această direcție de autentificare să fie posibilă, serverul de la distanță trebuie să aibă

informații apriori despre informațiile criptografice ale utilizatorului, adică utilizatorul trebuie

să fie cunoscut de server. Aceste protocoale pot fi bazate pe chei publice sau pe parole.

Rezultatul execuției unui protocol din această suită, împreună cu rezultatul protocolului SSH

de la nivel transport, este un canal sigur autentificat mutual între server și un anumit utilizator

pe partea de client.

• Protocolul de conexiune SSH rulează peste canalul sigur autentificat mutual stabilit de cele două componente precedente. Acest protocol este cel care realizează o serie de canale

logice sigure ce pot fi folosite pentru o serie de operații de comunicație.

In prezenta lucrare este evidentiat doar protocolul SSH la nivel transport, acesta

fiind protocolul de autentificare.

4.6.2 Protocolul SSH la nivel transport

Protocolul SSH la nivel transport folosește schimbul de chei Diffie-Hellman și prin

semnarea de către server a cheilor transmise se realizează autentificare unilaterală a serverului

față de client.

79

Fiecare server (host) are o pereche de chei – publică și privată. Pentru a putea folosi

mai mulți algoritmi un server poate avea mai multe perechi de astfel de chei. Dacă un server

are astfel de chei, atunci trebuie să aibă cel puțin câte o pereche de chei pentru fiecare

algoritm asimetric precizat de standardul Internet (DSS sau RSA în funcție de versiune).

In timpul fazei de schimb de chei se pot folosi cheile (publică și privată) serverului:

serverul folosește cheia privată pentru a semna mesajele ce țin de schimbul de chei; clientul

folosește cheia publică a serverului pentru a verifica faptul că schimbă mesaje cu serverul

corect. Pentru ca acest lucru să fie posibil, clientul trebuie să aibă informații apriori în legătură

cu cheia publică a serverului.

SSH contine două moduri diferite de realizarea a încrederii asupra cheii publice a

serverului:

• Clientul are o bază de date locală în care este făcută asocierea între fiecare server și cheia publică corespunzătoare. Această metodă nu necesită o infrastructură gestionată în mod

centralizat și prin urmare nu necesită un terț de încredere care să fie responsabil d e

coordonarea infrastructurii. Unul dintre dezavantajele majore ale acestui acestui mod este că

baza de date poate deveni foarte mare și greu de gestionat.

• Asocierea între numele serverului și cheia publică este certificată de o autoritate de

certificare (CA). Clientul trebuie să știe doar cheia publică a autorității de certificare și poate

verifica valabilitatea tuturor cheilor publice certificate de CA.

A doua modalitate simplifică problema gestiunii cheilor, din moment ce trebuie stocat

în siguranță doar o singură cheie publică (aici prin securitate se înțelege integritatea datelor).

Pe de altă parte fiecare cheie publică a serverelor trebuie să fie certificată în mod

corespunzător de catre CA înainte ca autentificarea să fie posibilă. De asemenea, există o mare încredere în infrastructura centralizată.

Momentan pe Internet nu există încă o infrastructură de chei publice implementată pe scară largă, primul model de încredere face protocolul mult mai utilizabil, pană la implementarea unei infrastructuri de chei publice (PKI), oferind un nivel de securitate mult

mai bun decat cel oferit de soluțiile mai vechi (de ex. comenzile UNIX rlogin, rsh, rftp etc.).

Metoda cea mai buna de obținere a unei chei publice este autentificate a unui server

este ca utilizatorul să aducă o copie a cheii publice și să o pună în mașina client înainte de

rularea protocolului de schimb de chei. Un bun exemplu ar fi urmatorul, utilizatorul poate salva pe un disc cheia publică a serverului. Pe sistemele UNIX și Linux, cheia publică a serverului folosită de mașina client este pusă într-un fișier cu numele $HOME/.ssh/known host. Utilizatorul trebuie să securizeze din punct de vedere fizic cheia publică a serverului în

80

ceea ce privește integritatea datelor. Pe sistemele Windows cheia publică a serverului există

doar în memoria sistemului și este descărcată în timp real de la server (printr-o legătură nesigură!).

O altă modalitatea de seama de obținere a cheii publice autentice a serverului este

folosirea autentificării prin voce într-o legătură telefonică. Cheia publică a serverului este

descărcată de utilizator pe mașina client printr-o legătură nesigură. O \amprentă"

hexazecimală a cheii publice este prezentată utilizatorului. Această "amprentă" este:

amprenta(cheie) = H(cheie)

unde, H este o funcție hash criptografică, de ex. SHA-1. În cazul SHA-1, întreaga amprentă

are 160 de biți și prin urmare poate fi spusă la telefon sub forma a 40 de caractere. Astfel,

utilizatorul poate da un telefon administratorului serverului care îi poate confirma

corectitudinea amprentei. Aici autentificarea se realizează prin voce și se pleacă de la premisa că utilizatorul și administartorul își cunosc unul altuia vocile.

Clientul initiaza intotdeauna protocolul pentru schimbul de chei. Serverul ascultă pe

un anumit port așteptand conexiuni. O serie de clienți se pot conecta la același server. Pentru a

obține cheia de sesiune protocolul SSH folosește protocolul pentru schimb de chei Diffie-

Hellman.

4.6.3 Strategia SSH

Una dintre caracteristicile cele mia importante ale protocolului SSH este de a

îmbunătăți securitatea prin Internet într-o manieră progresivă. Posibilitatea clientului de a

folosi orice metodă doreste pentru verificarea autenticității cheii publice a serverului

demonstrează strategia SSH de implementare rapidă și suportul pentru compatibilitate cu

versiuni anterioare.

Pana in momentul aparitie unei infrastructuri de chei publice pe Internet, securitatea îmbunătățită a SSH nu trebuia să fie atat de puternică. Motivul pentru care SSH este folosit pe serverele UNIX și Linux și implementat pe scară largă il reprezinta faptul ca este simplu de folosit si usor de implementat, aceast fiind si cel mai important atuu al SSH. Astefel putem observa că criptografia cu chei publice permite realizarea unor soluții simple. Cheia serverului prin mediul nesigur există doar sub forma de cheie publică, așa că gestiunea acestei componente devine mult mai simplă. Problema devine mult mai complicată dacă protocolul se bazează pe tehnici criptografice simetrice.

81

5. SIMULAREA UNEI RETELE CARE IMPLEMENTEAZA

SECURITATEA TRANSMISIILOR OFERITA DE VPN

Utilizarea unei retele compusa din echipamente reale este foarte scumpa drept urmare

acest proiect va folosi un simulator ce lucreaza cu sisteme de operare reale ale echipamentelor de retea folosite. Ne vom concentra pe modul de configurare, analiza performantei retelei si influenta politicilor de securitate asupra acesteia. Rezultatul obtinut va oferi o mai buna intelegere a procesului de configurare a echipamentelor si in special a celor produse de Cisco.

Simularile software sunt des utilizate in toate domeniile. Multe produse, atat hardware dar si software, sunt pretestate in aplicatii software. Avantajele utilizarii simulatoarelor

software sunt evidente:

– Mai putin timp pentru dezvoltarea produselor hardware si software;

– Abilitatea de a testa diferite scenarii pentru prototipurile hardware si

software fara dezavantajul costului sau al timpului pierdutl

– Prezicerea potentialelor probleme inainte de productia in masa.

Topologia de retea va fi dezvoltata si simulata folosind aplicatia de simulare GNS3 (impreuna cu Wireshark). Programul de simulare GNS3 ofera posibilitatea modificarii configuratiei unui echipament si observarea imediata a efectelor. Aceste simulari ofera mijloacele de testare pentru diverse schimbari ce ar putea avea loc inainte de implementarea reala, analiza fiabilitatii componentelor si efectelor defectarii uneia, planificarea scalabilitatii si multe altele.

Scopul studiului meu este acela de a crea trei tunele diferite: GRE, IPSec si GRE over IPSec folosind GNS3. In cele din urma vom compara avantajele si dezavantajele fiecarui tip de tunel.

5.1 Utilitare pentru simulare si analiza rezultatelor

GNS3 (Graphical Network Simulator) este un simulator grafic de rețea ce permite

simularea unei rețele complexe, este o unealtă complementară pentru laboratoarele reale de rețelistică pentru ingineri de rețea, administratori, etc. GNS3 este o aplicatie grafica care permite utilizatorului sa creeze vizual o topologie de retea bazata pe rutere Cisco .

GNS3 are unele caracteristici cu adevărat utile în simularea de rețea, cu ar fi:

– Crearea unor topologi de rețea complexe

82

– Emularea platformelor IOS Cisco

– Conectarea rețelei simulate cu lumea reală – Captura pacheteleor cu ajutorul Wireshark

GNS3 este o interfata pentru Dynamips, ce comunica cu acesta prin intermediul unui hipervizor. Dynamips este o aplicatie gratuita open-source care emuleaza un sistem de operare Cisco care poate rula in Windows, Linux sau MacOS. Poate emula platformele: 1700, 2600, 3600, si 7200 si ruleaza imagini IOS standard. Dynamips permite utilizatorilor sai sa creeze rutere virtuale care ruleaza cu un sistem de operare Cisco utilizand resursele calculatorului gazda. Avantajul de a folosi Dynamips este ca acesta nu e un simulator, ci un emulator care ruleaza direct codul Sistemului de Operare Cisco. Pe langa comportamentul real al unui echipament Cisco acesta ne permite sa cream si o diversitate de topologii.

In ciuda faptului ca throughput-ul sau este de numai 1kbps si nu poate fi folosit in rețelele reale, acesta emulează pe deplin tot ceea ce este necesar pentru a simula și testa in mod corespunzător o rețea.

Este util in testarea configurațiilor, deasemenea este posibila captarea pachetelor din legaturile ruterelor virtuale. Cu Dynamips ruterele virtuale pot interactiona cu rutere reale ceea ce permite testarea unei topologii de dimensiuni mai mari. Un alt aspect important pentru utilizatori este captura traficului de retea cu ajutorul analizorului de pachete Wireshark.

Crearea unei topologii in GNS3 este simplă, in special pentru utilizatorii care sunt familiarizați si cu alte simulatoare de rețea cum ar fi Opnet sau Packet Tracer. Înainte de a folosi programul, utilizatorii au nevoie de imaginile IOS pentru a putea utiliza echipamentele.

Figura 5.1 prezintă spațiul de lucru în GNS3. Acesta este divizat in patru panouri, cel din stânga prezintă tipurile de noduri disponibile. Utilizatorul poate vedea simbolul ruterelor pentru diferite platforme, PIX Firewall, Ethernet swtich, etc. Panoul din dreapta prezintă sumarul topologiei. Secțiunea din mijloc contine două panouri. Cel superior reprezinta spațiul de lucru, este locul unde utilizatorul construieste topologia. Cel inferior este consola de gestionare pentru Dynagen.

GNS3 este intuitiv, dispozitivele fiind pur si simplu trase in spatiul de lucru pentru a putea fi folosite in topologie. Pentru inceput sunt configurate tipul de conexiune, folosing Ethernet, serial sau alte tipuri. Fiecare tip de ruter are propriul tip de conexiunie, de exemplu: ruterul Cisco 3640 suportă conexiunea Ethernet-switch (poate fi utilizat ca și comutator). Pentru a conecta fiecare ruter, acest program ne ofera butonul "add a link" (reprezentat cu simbolul unui conector Ethernet). Utilizatorul trebuie să aleagă conexiunea potrivită, bazându-se pe configurația care a fost aleasa pentru ruter.

83

Înainte de a începe simularea exista câteva setari ce trebuie realizate in GNS3. În

primul rând imaginile IOS trebuiesc încărcate. Fiecare model de ruter are imaginea sa, depinde de utilizator ce model dorește să ruleze in simulare. După aceasta, este necesar să fie definită valoarea "Idle PC" cu scopul de a reduce consumul de resurse al calculatorului atunci când rulează simularea.

Dupa aceasta ruterele sunt adăugate în spațiul de lucru. Pentru început trebuie configurate sloturile adaptor pentru a defini tipul de conexiune care va fi necesar in topologie. Apoi este necesară configurarea echipamentelor.

Fig. 5.1 – Interfata GNS3.

Wireshark este un program de tip open source, un analizor de pachete gratuit folosit

atat pentru analiza traficului dintr-o retea, identificarea si depanarea eventualelor probleme cat si in scopuri educative. Este scris in limbajul de programare C iar la baza are cunoscuta aplicatie tcpdump. Wireshark permite unui utilizator sa analizeze tot traficul dintr-o retea (Fig. 5.2) prin configurarea interfetei de retea in modul promiscuu. In acest mod, interfata primeste si proceseaza tot traficul, nu doar pe cel care ii este destinat.

Aplicatia cuprinde un set bogat de capabilitati cum ar fi:

– Inspectarea a sute de protocoale;

84

– Interfață pentru navigarea prin conținutul pachetelor (packet browser);

– Citire și scriere în diferite formate open-source și proprietare de fișiere:

tcpdump (libpcap), Pcap NG, Catapult DCT2000, Cisco Secure IDS iplog,

– Analiză offline și captura pachetelor live

– Portabilitate (există versiuni pentru Linux, Windows, OS X, Solaris, BSD

etc.); Datele capturate pot fi studiate printr-o interfață grafică sau în linie de

comandă;

– Multiple posibilități de filtrare a datelor capturate;

– Interfața poate fi personalizată, folosind reguli de colorare asupra listei de

pachete pentru o analiză rapidă și intuitivă;

– Exportul datelor în format XML, PostScript, CSV sau text simplu.

Fig. 5.2 – Analizorul de trafic Wireshark

85

Wireshark utilizeaza API-ul (Application Programming Interface) pcap pentru captura

pachetelor drept urmare, aplicatia functioneaza doar pentru retelele suportate de acest API. Un alt dezavantaj constă în faptul că, pentru a putea captura pachetele în format neprelucrat de la o interfață de rețea, Wireshark trebuie să ruleze cu drepturi de administrator. Acest lucru prezintă, evident, probleme de securitate pentru sistemul de pe care este rulată aplicația. O soluție a acestei probleme este aceea de a rula doar utilitarul tcpdump sau componenta dumpcap a aplicației la un nivel privilegiat pentru a putea captura traficul iar analiza acestuia urmând a se efectua ulterior cu Wireshark rulând la un nivel restricționat. De asemenea rularea aplicatiei Wireshark intr-o retea de dimensiuni mari cu o activitate incarcata poate produce fisiere de captura de dimensiuni foarte mari si poate consuma partial sau chiar total resursele sistemului, ceea ce ar putea duce la o incetinire a sistemului sau chiar la blocarea acestuia.

Dynagen este o interfata pentru Dynamips, ce comunica cu acesta printr-un hipervizor. O problema majora in folosirea Dynagen este aceea ca procesorul este utilizat 100% indiferent daca ruterul este in uz sau in stare de repaus.

În scopul de a creea topologii multiple ce premit utilizatorilor să configureze diverse scenarii si să invețe tehnici noi si tehnologii folosite in rețelistică un emulator este solutia potrivită.

5.2 Topologia retelei

Figura 5.3 – Topologia creata

86

In topologia de mai sus au fost create 3 tunele:

– GRE over IPSec intre HQ si Branch 2;

– IPSec intre HQ si Branch 1;

– GRE intre Branch 1 si Branch 2.

5.3 Configurarea echipamentelor de retea

In topologie sunt folosite:

– Cisco ASA 5520:

o RAM: 512 MiB

o Model interfata retea: e1000

o Initrd: asa842-initrd.gz o Kernel: asa842-vmlinuz

– Router Cisco c3640

o RAM: 128 MiB

o IOS: c3640-is-mz_120-7_t.image

o Model interfata retea: NM-1FE-TX

Configuratia completa a echipamentelor de retea se gaseste in Anexa 1.

Descrierea conexiunilor in reteaua simulata:

– Branch1-ASA: interfata Ethernet0 se conecteaza la ISP3; interfata Ethernet

1 se conecteaza la Branch1-R;

– Branch1-R: interfata Fastethernet 0/0 se conecteaza la Branch1-ASA;

interfata Fastethernet 1/0 se conecteaza la Host2;

– Branch2-ASA: interfata Ethernet 0 se conecteaza la ISP2; interfata

Ethernet 1 se conecteaza la Branch2-R;

– Branch2-R: interfata Fastethernet 0/0 se conecteaza la Branch2-ASA;

interfata Fastethernet 1/0 se conecteaza la Host3;

– HQ-ASA: interfata Ethernet 0 se conecteaza la ISP1; interfata Ethernet 1 se

conecteaza la HQ-R;

– HQ-R: interfata Fastethernet 0/0 se conecteaza la HQ-ASA; interfata

Fastethernet 1/0 se conecteaza la Host1;

– ISP1: interfata Fastethernet 0/0 se conecteaza la HQ-ASA; interfata

Fastethernet 1/0 se conecteaza la ISP2; interfata Fastethernet 2/0 se

conecteaza la ISP3;

– ISP2: interfata Fastethernet 0/0 se conecteaza la Branch2-ASA; interfata

Fastethernet 1/0 se conecteaza la ISP3; interfata Fastethernet 2/0 se

conecteaza la ISP1;

– ISP3: interfata Fastethernet 0/0 se conecteaza la Branch1-ASA; interfata

Fastethernet 1/0 se conecteaza la ISP1; interfata Fastethernet 2/0 se conecteaza la ISP2.

87

Branch1-

ASA

Branch1-R

Branch2-

ASA

Branch2-R

Asignarea adreselor

IP

Configurare OSPF

Asignarea adreselor

IP

Configurare OSPF

Asignarea adreselor

IP

Configurare OSPF

Asignarea adreselor

IP

interface GigabitEthernet0

nameif WAN

security-level 0

ip address 22.22.22.2 255.255.255.252

no shutdown

interface GigabitEthernet1

nameif LAN

security-level 100

ip address 192.168.2.1 255.255.255.252

no shutdown router ospf 1

network 22.22.22.0 255.255.255.252 area 0

network 192.168.2.0 255.255.255.252 area 0

log-adj-changes

interface FastEthernet0/0

ip address 192.168.2.2 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

no shutdown

interface FastEthernet1/0

ip address 10.10.2.1 255.255.255.0

no ip directed-broadcast

duplex auto speed auto

no shutdown router ospf 1

passive-interface FastEthernet1/0

network 10.10.2.0 0.0.0.255 area 0

network 172.28.3.0 0.0.0.3 area 0

network 192.168.2.0 0.0.0.3 area 0

interface GigabitEthernet0

nameif WAN

security-level 0

ip address 33.33.33.2 255.255.255.252

no shutdown

interface GigabitEthernet1

nameif LAN

security-level 100

ip address 192.168.3.1 255.255.255.252

no shutdown router ospf 1

network 33.33.33.0 255.255.255.252 area 0

network 192.168.3.0 255.255.255.252 area 0

log-adj-changes

interface FastEthernet0/0

ip address 192.168.3.2 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

no shutdown

interface FastEthernet1/0

88

ip address 10.10.3.1 255.255.255.0

no ip directed-broadcast

duplex auto speed auto

no shutdown

Configurare OSPF

router ospf 1

passive-interface FastEthernet1/0

network 10.10.3.0 0.0.0.255 area 0

network 172.28.2.0 0.0.0.3 area 0 network 172.28.3.0 0.0.0.3 area 0

network 192.168.3.0 0.0.0.3 area 0

HQ-ASA

HQ-R

ISP1

Asignarea adreselor

IP

Configurare OSPF

Asignarea adreselor

IP

Configurare OSPF

Asignarea adreselor

IP

interface GigabitEthernet0

nameif WAN

security-level 0

ip address 11.11.11.2 255.255.255.252

no shutdown

interface GigabitEthernet1

nameif LAN

security-level 100

ip address 192.168.1.1 255.255.255.252

no shutdown router ospf 1

network 11.11.11.0 255.255.255.252 area 0

network 192.168.1.0 255.255.255.252 area 0

log-adj-changes

interface FastEthernet0/0

ip address 192.168.1.2 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

no shutdown

interface FastEthernet1/0

ip address 10.10.1.1 255.255.255.0

no ip directed-broadcast

duplex auto speed auto

no shutdown router ospf 1

passive-interface FastEthernet1/0

network 10.10.1.0 0.0.0.255 area 0

network 172.28.2.0 0.0.0.3 area 0

network 192.168.1.0 0.0.0.3 area 0

interface FastEthernet0/0

ip address 11.11.11.1 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

no shutdown

interface FastEthernet1/0

ip address 77.77.77.1 255.255.255.252

89

no ip directed-broadcast

duplex auto speed auto

no shutdown

interface FastEthernet2/0

ip address 88.88.88.2 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

no shutdown

Configurare OSPF router ospf 1

network 11.11.11.0 0.0.0.3 area 0

network 77.77.77.0 0.0.0.3 area 0 network 88.88.88.0 0.0.0.3 area 0

ISP2

ISP3

Asignarea adreselor

IP

Configurare OSPF

Asignarea adreselor

IP

interface FastEthernet0/0

ip address 33.33.33.1 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

no shutdown

interface FastEthernet1/0

ip address 99.99.99.1 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

no shutdown

interface FastEthernet2/0

ip address 77.77.77.2 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

no shutdown router ospf 1

network 33.33.33.0 0.0.0.3 area 0 network 77.77.77.0 0.0.0.3 area 0 network 99.99.99.0 0.0.0.3 area 0

interface FastEthernet0/0

ip address 22.22.22.1 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

no shutdown

interface FastEthernet1/0

ip address 88.88.88.1 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

no shutdown

interface FastEthernet2/0

ip address 99.99.99.2 255.255.255.252

90

no ip directed-broadcast

duplex auto speed auto

no shutdown

Configurare OSPF router ospf 1

network 22.22.22.0 0.0.0.3 area 0

network 88.88.88.0 0.0.0.3 area 0 network 99.99.99.0 0.0.0.3 area 0

Tabel 5.1 Adresarea interfetelor si configuratia OSPF

In continuare se va analiza dimensiunea unui pachet de date "esantion" (ping)

circuland atat in text clar (netunelat) cat si prin cele trei tipuri de tuneluri.

Scenariul 1: Ping-ul nu trece prin niciun tunel. Nu este incapsulat si nici criptat. Din analiza pachetului se pot determina atat IP-urile sursa si destinatie cat si detaliile pachetului ICMP. Captarea s-a realizat pe interfata Fastethernet a ruterului ISP1. De asemenea se poate observa ca dimensiunea totala a pachetului este de 106 octeti.

Figura 5.4 – Ping Host1 – Host2 text clar

91

Scenariul 2: Tunel GRE intre Branch 1 si Branch 2.

Branch1-R Numele interfetei tunel

(virtuala)

Adresa IP a acesteia

Sursa reala a tunelului

Destinatia reala a tunelului

Branch2-R Numele interfetei tunel

(virtuala)

Adresa IP a acesteia

Sursa reala a tunelului

Destinatia reala a tunelului

interface Tunnel2

ip address 172.28.3.1 255.255.255.252

tunnel source 192.168.2.2

tunnel destination 192.168.3.2

interface Tunnel2

ip address 172.28.3.2 255.255.255.252

tunnel source 192.168.3.2

tunnel destination 192.168.2.2

Dupa configurarea tunelului GRE putem vizualiza pachetul "esantion" (echo-request)

circuland in retea incapsulat insa necriptat. Captarea s-a realizat pe interfata Fastethernet 0/0 a ruterului ISP3.

Figura 5.5 – Ping Host2 – Host3 tunel GRE

92

Din captura se poate observa atat dimensiunea totala a pachetului crescuta de la 106

octeti la 130 octeti cat si incapsularea pachetului de nivel 3 OSI (Nivelul Retea) intr-un altul ce are ca adrese IP sursa si destinatie capetele tunelului GRE. In figura 5.5 se poate observa doar mesajul Echo-request deoarece diferenta dintre acesta si Echo-reply consta numai in tipul mesajului ICMP (Echo-request continand in campul "Type" al header-ului codul 8 iar Echo-reply codul 0). Captura pachetului Echo-reply se gaseste in Anexa 2.

Scenariul 3: Tunel IPSec intre HQ si Branch 1.

Vom configura politica ISAKMP cu urmatorii parametri:

Vom folosi o politica ikev1 cu prioritatea 1 (cea mai mare)

HQ-ASA(config)# crypto ikev1 policy 1

Vom folosi autentificare cu chei simetrice

HQ-ASA(config-isakmp)#authentication pre-share

Ca algoritm de criptare se va folosi algoritmul AES cu chei de 256 biti.

HQ-ASA(config-isakmp)#encryption aes-256

Algoritmul pentru hash folosit va fi SHA

HQ-ASA(config-isakmp)#hash sha

Grupul Diffie-Hellman va fi 2

HQ-ASA(config-isakmp)#group 2

Durata de viata a unei asocieri va fi de 3600 secunde

HQ-ASA(config-isakmp)#lifetime 3600

Se configureaza tipul tunelului (Land to land)

HQ-ASA(config )#tunnel-group 22.22.22.2 type ipsec-l2l

Se intra in modul de configurare al atributelor tunelului

HQ-ASA(config)# tunnel-group 22.22.22.2 ipsec-attributes

Se configureaza cheia simetrica de autentificare

HQ-ASA(config-tunnel-ipsec)#ikev1 pre-shared-key licenta

Se configureaza transfor-set-ul ce contine algoritmii de criptare si hash pe care ii va folosi tunelul.

HQ-ASA(config)#crypto ipsec ikev1 transform-set HQ-Br1 esp-aes-256 esp-sha-hmac

Se creeaza lista de acces "HQ-Br1-Map" ce identifica traficul dintre HQ si Branch 1.

Branch1-LAN este un obiect ce contine subnet-ul 10.10.2.0 cu masca de retea 255.255.255.0 (toate adresele din Branch 1.

93

HQ-ASA(config)#access-list HQ-Br1-Map extended permit ip object HQ-LAN object

Branch1-LAN

Construim un crypto map pentru a ingloba toate blocurile construite:

Se vor selecta adresele IP catre Branch1

HQ-ASA(config)#crypto map HQ-Map 1 match address HQ-Br1-Map

Se seteaza celalalt capat al tunelului

HQ-ASA(config)#crypto map HQ-Map 1 set peer 22.22.22.2

Se configureaza algoritmii de criptare si hash folositi.

HQ-ASA(config)#crypto map HQ-Map 1 set ikev1 transform-set HQ-Br1

In final se aplica harta nou creata pe interfata externa a firewall-ului:

HQ-ASA(config)#crypto map HQ-Map interface WAN

Analog se va configura si Branch1-ASA. Odata tunelul configurat se poate testa

conexiunea. Vom trimite un mesaj ICMP Echo-request de la Host1 catre Host2.

Figura 5.6 – stabilirea tunelului IPSec

94

Figura 5.7 – Stabilirea asocierii IPSec intre cele doua echipamente.

Dupa stabilirea asocierii de securitate tunelul este functional. Putem trimite pachetul esantion de la Host1 catre Host2.

Dupa cum se poate observa in figura 5.8 IPSec cripteaza datele de la nivelul 3 OSI in

sus. In captura se pot observa adresele de nivel 2 (MAC) insa cele de nivel 3 (IP) sunt

adresele capetelor tunelului. Restul mesajului este criptat. De asemenea se poate observa ca

acum dimensiunea totala a mesajului a ajuns la 166 octeti. In figura 5.8 se poate observa doar mesajul Echo-request. Captura pachetului Echo-reply se gaseste in Anexa 3.

95

Figura 5.8 – Ping Host1 – Host2 prin tunel IPSec

96

Scenariul 4: tunel GRE over IPSec intre HQ si Branch2

Mai intai se configureaza protocolul GRE pe ruterele din cele doua sedii:

HQ-R

Numele interfetei tunel

(virtuala)

Adresa IP a acesteia

Sursa reala a tunelului

Destinatia reala a tunelului

interface Tunnel2

ip address 172.28.2.1 255.255.255.252

tunnel source 192.168.1.2

tunnel destination 192.168.3.2

Branch2-R Numele interfetei tunel

(virtuala)

Adresa IP a acesteia

Sursa reala a tunelului

Destinatia reala a tunelului

interface Tunnel1

ip address 172.28.2.2 255.255.255.252

tunnel source 192.168.3.2

tunnel destination 192.168.1.2

Apoi, asemanator Scenariului 3, se configureaza IPSec intre cele doua firewall-uri:

Vom configura politica ISAKMP cu urmatorii parametri:

Vom folosi o politica ikev1 cu prioritatea 1 (cea mai mare)

HQ-ASA(config)# crypto ikev1 policy 1

Vom folosi autentificare cu chei simetrice

HQ-ASA(config-isakmp)#authentication pre-share

Ca algoritm de criptare se va folosi algoritmul AES cu chei de 256 biti.

HQ-ASA(config-isakmp)#encryption aes-256

Algoritmul pentru hash folosit va fi SHA

HQ-ASA(config-isakmp)#hash sha

Grupul Diffie-Hellman va fi 2

HQ-ASA(config-isakmp)#group 2

Durata de viata a unei asocieri va fi de 3600 secunde

HQ-ASA(config-isakmp)#lifetime 3600

Se configureaza tipul tunelului (Land to land)

HQ-ASA(config )#tunnel-group 33.33.33.2 type ipsec-l2l

Se intra in modul de configurare al atributelor tunelului

HQ-ASA(config)# tunnel-group 33.33.33.2 ipsec-attributes

Se configureaza cheia simetrica de autentificare

HQ-ASA(config-tunnel-ipsec)#ikev1 pre-shared-key licenta

Se configureaza transfor-set-ul ce contine algoritmii de criptare si hash pe care ii va folosi tunelul.

HQ-ASA(config)#crypto ipsec ikev1 transform-set HQ-Br2 esp-aes-256 esp-sha-hmac

Se creeaza lista de acces "HQ-Br2-Map" ce identifica traficul dintre HQ si Branch 2.

Branch2-LAN-GRE este un obiect ce contine adresa 192.168.3.2 (capatul tunelului GRE din Branch 2).

HQ-ASA(config)#access-list HQ-Br2-Map extended permit ip object HQ-LAN -GRE object

Branch2-LAN -GRE

Construim un crypto map pentru a ingloba toate blocurile construite:

Se vor selecta adresele IP catre Branch2

HQ-ASA(config)#crypto map HQ-Map 2 match address HQ-Br2-Map

Se seteaza celalalt capat al tunelului

HQ-ASA(config)#crypto map HQ-Map 2 set peer 33.33.33.3

97

Se configureaza algoritmii de criptare si hash folositi.

HQ-ASA(config)#crypto map HQ-Map 2 set ikev1 transform-set HQ-Br2

In final se aplica harta nou creata pe interfata externa a firewall-ului:

HQ-ASA(config)#crypto map HQ-Map interface WAN

Analog se va configura si Branch2-ASA. Dupa stabilirea asocierii de securitate tunelul

este functional. Putem trimite pachetul esantion de la Host1 catre Host3.

Figura 5.9 Stabilirea asocierii IPSec intre cele doua echipamente

98

Figura 5.10 – Cele doua tunele (HQ catre Branch1 si catre Branch2) sunt active.

Dupa cum se poate observa in figura 5.11 IPSec cripteaza datele de la nivelul 3 OSI in

sus. In captura se pot observa adresele de nivel 2 (MAC) insa cele de nivel 3 (IP) sunt adresele capetelor tunelului. Restul mesajului (inclusiv protocolul GRE) este criptat. De asemenea se poate observa ca acum dimensiunea totala a mesajului a ajuns la 198 octeti. In figura 5.11 se poate observa doar mesajul Echo-request. Captura pachetului Echo-reply se gaseste in Anexa 4.

Figura 5.11 Host1 – Host3 tunel GRE over IPSec.

99

In continuare se va analiza schimbul de mesaje in cazul vizualizarii unui site atat

folosind protocolul SSLv3 cat si TLSv1.

Scenariul 5: Se creaza o pagina web de dimensiuni reduse (196 KO – Figura 5.12) si se

gazduieste pe un server Apache2. Acesta este configurat pentru a suporta numai protocolul SSLv3.

Figura 5.12 – Dimensiunea site-ului web.

Configurarea serverului (VirtualHost-ului) este urmatoarea:

<VirtualHost *:443>

SSLEngine on

SSLProtocol SSLv3

SSLCipherSuite HIGH:!aNULL:!MD5

SSLCertificateFile /etc/pki/tls/http/apachecert.pem

SSLCertificateKeyFile /etc/pki/tls/http/apachekey.pem

DocumentRoot "/var/www/html/https-ssl"

<Directory /var/www/html/https-ssl>

Order allow,deny

Allow from all

</Directory>

</VirtualHost>

Aceasta configuratie obliga orice client sa foloseasca protocolul SSLv3 (serverul nu

accepta alte protocoale). Port-ul utilizat este 443 (portul standard pentru HTTPS). Site-ul creat se afla la adresa "/var/www/html/https-ssl" si se poate gasi in Anexa 5. De asemenea

configuratia completa a serverului Apache (fisierul ssl.conf) se gaseste in Anexa 6.

100

In continuare se vor analiza pasii handshake-ului SSLv3:

Figura 5.13 – Mesajul "Client Hello"

Clientul initiaza conexiunea trimitand un mesaj serverului ce contine: protocolul

preferat de client (si versiunea acestuia); un numar format din data si ora clientului plus un numar de 28 octeti generat aleator ce va fi folosit ulterior impreuna cu numarul aleator al serverului pentru obtinerea cheilor de criptare; suita de cifruri (lista de cifruri disponibile clientului) si algoritmul de compresie suportat de catre client.

101

Figura 5.14 – Mesajul "Server Hello"

102

Serverul raspunde mesajului Hello de la client cu urmatoarele: protocolul suportat de

server; numarul sau aleator, care impreuna cu cel al clientului vor forma cheile de criptare; suita de cifruri (lista de cifruri disponibile serverului) si algoritmul de compresie suportat de catre server.

Tot in acest mesaj serverul introduce datele certificatului de securitate si anume: cheia publica a serverului si detaliile certificatului (destinatarul emiterii certificatului si perioada de validitate a acestuia).

Figura 5.15 – Mesajul "Server hello done"

Serverul trimite un mesaj de tipul "Server Hello Done" ce indica faptul ca serverul a

terminat schimbul de mesaje si asteapta clientul.

103

Figura 5.16 – Mesajul "Client key exchange"

Clientul trimite un mesaj „Schimb de chei client" după calcularea secret-ului

premaster folosind ambele valori aleatoare (al serverului si al sau). Secretul premaster este criptat cu cheia publică din certificatul serverului înainte de a fi transmis la server. Ambele

părți vor calcula secretul master la nivel local și vor extrage cheia de sesiune din el.

În cazul în care serverul poate decripta aceste date clientul este asigurat că serverul are

cheia privată corecta. Acest pas este crucial pentru a dovedi autenticitatea serverului. Numai serverul cu cheia privată care corespunde cheii publice din certificat poate decripta aceste date și poate continua negocierea protocolului.

Figura 5.17 – Mesajul "Change Chiper Spec"

104

Acest mesaj notifică serverul care toate mesajele care urmează dupa mesajul „Client

Finished" vor fi criptate folosind cheile și algoritmii negociati. Mesajul „Client Finished" este un hash al intregii conversatii si ofera autentificare clientului.

Scenariul 6: Aceeasi pagina web de dimensiuni reduse folosita in Scenariul 5 si se gazduieste

pe un server Apache2 configurat pentru a suporta numai protocolul TLSv1.

Figura 5.18 – Dimensiunea site-ului web.

Configurarea serverului (VirtualHost-ului) este urmatoarea:

<VirtualHost *:443>

SSLEngine on

SSLProtocol TLSv1

SSLCipherSuite HIGH:!aNULL:!MD5

SSLCertificateFile /etc/pki/tls/http/apachecert.pem

SSLCertificateKeyFile /etc/pki/tls/http/apachekey.pem

DocumentRoot "/var/www/html/https-tls"

<Directory /var/www/html/https-tls>

Order allow,deny

Allow from all

</Directory>

</VirtualHost>

Aceasta configuratie obliga orice client sa foloseasca protocolul TLSv1 (serverul nu

accepta alte protocoale). Port-ul utilizat este 443 (portul standard pentru HTTPS). Site-ul creat se afla la adresa "/var/www/html/https-tls" si se poate gasi in Anexa 7.

105

In continuare se vor analiza pasii handshake-ului TLSv1:

Figura 5.19 – Mesajul "Client Hello"

Clientul initiaza conexiunea trimitand un mesaj serverului ce contine: protocolul

preferat de client (si versiunea acestuia); un numar format din data si ora clientului plus un numar de 28 octeti generat aleator ce va fi folosit ulterior impreuna cu numarul aleator al serverului pentru obtinerea cheilor de criptare; suita de cifruri (lista de cifruri disponibile clientului) si algoritmul de compresie suportat de catre client.

106

Figura 5.20 – Mesajul "Server Hello"

Serverul raspunde mesajului Hello de la client cu urmatoarele: protocolul suportat de

server; numarul sau aleator, care impreuna cu cel al clientului vor forma cheile de criptare;

suita de cifruri (lista de cifruri disponibile serverului) si algoritmul de compresie suportat de catre server.

Tot in acest mesaj serverul introduce datele certificatului de securitate si anume: cheia publica a serverului si detaliile certificatului (destinatarul emiterii certificatului si perioada de validitate a acestuia).

107

Figura 5.21 – Mesajul "Server hello done"

Serverul trimite un mesaj de tipul "Server Hello Done" ce indica faptul ca serverul a

terminat schimbul de mesaje si asteapta clientul.

Figura 5.22 – Mesajul "Client key exchange"

Clientul trimite un mesaj „Schimb de chei client" după calcularea secret-ului

premaster folosind ambele valori aleatoare (al serverului si al sau). Secretul premaster este

108

criptat cu cheia publică din certificatul serverului înainte de a fi transmis la server. Ambele

părți vor calcula secretul master la nivel local și vor extrage cheia de sesiune din el.

În cazul în care serverul poate decripta aceste date clientul este asigurat că serverul are

cheia privată corecta. Acest pas este crucial pentru a dovedi autenticitatea serverului. Numai serverul cu cheia privată care corespunde cheii publice din certificat poate decripta aceste date și poate continua negocierea protocolului.

Figura 5.23 – Mesajul "Change Chiper Spec"

Acest mesaj notifică serverul care toate mesajele care urmează dupa mesajul „Client

Finished" vor fi criptate folosind cheile și algoritmii negociati. Mesajul „Client Finished" este un hash al intregii conversatii si ofera autentificare clientului.

109

CONCLUZII

In mai putin de o generatie, revolutia informatiei si introducerea calculatoarelor in

virtual, fiecare dimensiune a societatii a schimbat lumea. Predictiile unor importanti oameni in domeniul ingineriei se adeveresc si lumea se transforma astfel intr-un "sat global" unde nu mai exista granite pentru afaceri, comunicatii sau comert.

Informatia reprezinta moneda economiei Internet; tehnologiile de securitate a informatiei au un imens impact asupra modului in care organizatiile conduc afaceri electronice si, implicit, isi ating obiectivele strategice. Prezenta lucrare discuta importanta tehnologiilor de securitatea informatiei in societatea informatiei, si explicarea avantajelor adoptarii tehnologiilor de securitatea informatiilor.

Retelele private virtuale (VPN) au fost concepute din dorinta de a avea o mai buna securitate a informatiilor transmise de catre utilizatori prin intermediul unei retea de calculatoare.

Scopul propus de aceasta lucrare a fost implementarea cu ajutorul simulatorului GNS3 unei retele care utilizeaza diferitele protocoale de tunelare.

Din scenariul 1 am vazut ca un pachet cum arata un pachet de date (ping) ce este transmis in text clar – necriptat si netunelat. Am putut observa cum un analizor de trafic poate extrage toate informatiile din acel pachet (sursa, destinatie si tipul pachetului). De asemenea s-a putut observa ca dimensiunea totala a pachetului este de 106 octeti.

Din scenariul 2 am vazut ca tunelele GRE, desi ofera eficienta retelei si sunt usor de implementat au un mare dezavantaj in faptul ca nu cripteaza datele transmise prin asa numitul "tunel de transmisie". De asemenea am observat ca, in acest caz, dimensiunea totala a pachetului a crescut la 130 octeti. Diferenta de 24 octeti este data de header-ul IP adaugat de catre protocolul GRE.

In scenariul 3 si 4 am implementat un tunel IPSec si un tunel GRE cu protectie IPSec. Desi sunt mai greu de configurat, necesitand cunostinte avansate de retelistica, retelele virtuale private bazate pe IPSec utilizeaza criptarea pentru a secretiza datele pe care le transmit, astfel crescand rezistenta retelei din punctul de vedere al furtului de date. De asemenea se poate observa ca dimensiunea pachetului a crescut la 166 octeti, respectiv 198 octeti datorita datelor adaugate de protocolul IPSec.

110

In scenariul 5 si 6 am vazut cum arata schimbul de mesaje de la inceputul unei

sesiune HTTPS atat pentru cazul configurarii cu protocolul SSLv3 cat si pentru TLSv1.

Diferentele intre aceste protocoale sunt minime:

– Cifruri: TLS nu are suport pentru schimbul de chei Fortezza si pentru

criptarea Fortezza.

– Padding: TLS permite padding cu un numar variabil de octeti (maxim

244)

– MAC: TLS folosește ultima versiune de HMAC, iar acesta acoperă și

câmpul de versiune.

– Mesajul CERTIFICATE_VERIFY: Funcția de dispersie este calculată

doar după mesajele de handshake

– Coduri de avertizare: TLS definește mai multe coduri de avertizare decât

SSL.

In aceasta lucrare am incercat sa evidentiez clar procesul de configurare a diferitelor tipuri de tuneluri de securitate, dar si importanta deosebita care trebuie acordata problemei securitatii. Desi Internetul se confrunta cu amenintari de securitate din ce in ce mai avansate acest lucru nu a impiedicat raspandirea sa la scara globala. Fiind imposibilia inlaturarea in totalitate a unui atac tot ce ne ramane de facut este sa ingreunam incercarile atacatorilor de a obtine acces la informatii.

111

BIBLIOGRAFIE

1) Cisco Network Security Internet Technical Solution (e-Seminar)

2) Bogdan Groza, "Introducere in Sisteme Criptografice cu Cheie Publica", Curs 3) Alexandru Isar, "Curs securitatea transmiterii informatiei prin internet", Curs

4) Asist. Razvan ZOTA, "Solutii de securitate pentru Internet", in Revista Informatica

Economica, nr.12/1999 69

5) Luminita S. , Ion B. , "Securitatea Retelelor de Comunicatii", Casa de editura

"Venus" Iasi 2008

6) http://www.securitatea-informatica.ro/securitatea-informatica/securitatea-si-

confidentialitatea-datelor-in-retelele-publice/

7) http://ro.wikipedia.org/wiki/Re%C8%9Bea_privat%C4%83_virtual%C4%83 8) Revista 52 Informatica Economică nr. 2(30)/2004 An Overview of the Attack

Methods Directed Against the RSA Algorithm

9) Bogdan Groza, „Introducere în SistemeleCriptografice cu Cheie Publică",

http://www.aut.upt.ro/~bgroza/iccp.pdf accesat la data 18.06.2012

10) Asist. Simona Ionescu, "Considerations on data encryption and decruption", in Revista

Informatica Economica, nr.2(30)/2004

11) Revista 52 Informatica Economică nr. 2(30)/2004 An Overview of the Attack

Methods Directed Against the RSA Algorithm

12) Martin W. Murhammer, "A Comprehensive Guide to Virtual Private Networks",

International Technical Support Organization 1999

13) http://www.netaccess.ro/retele_virtuale_private.html accesat la data 15.03.2012

http://ro.wikipedia.org/wiki/Vpn

http://en.wikipedia.org/wiki/Secure_Sockets_Layer

112

ANEXE

113

ANEXA 1

Configuratia completa a echipamentelor de retea

1 – Configuratie Branch1-ASA

Branch1-ASA# sh run

: Saved

:

ASA Version 8.4(2)

!

hostname Branch1-ASA

enable password 8Ry2YjIyt7RRXU24 encrypted

passwd 2KFQnbNIdI.2KYOU encrypted

names

!

interface GigabitEthernet0

nameif WAN

security-level 0

ip address 22.22.22.2 255.255.255.252

!

interface GigabitEthernet1

nameif LAN

security-level 100

ip address 192.168.2.1 255.255.255.252

!

ftp mode passive

same-security-traffic permit inter-interface

object network HQ-LAN

subnet 10.10.1.0 255.255.255.0

object network Branch1-LAN-GRE

host 192.168.2.2

object network Branch2-LAN-GRE

host 192.168.3.2

object network Branch1-WAN

host 22.22.22.2

object network Branch1-LAN

subnet 10.10.2.0 255.255.255.0

access-list WAN-IN extended permit ip object HQ-LAN object Branch1-LAN

access-list WAN-IN extended permit ip object Branch2-LAN-GRE object Branch1-LAN-

GRE

access-list WAN-IN extended deny ip any any

access-list HQ-Br1-Map extended permit ip object Branch1-LAN object HQ-LAN

pager lines 24

mtu WAN 1500 mtu LAN 1500

no failover

icmp unreachable rate-limit 1 burst-size 1

no asdm history enable

arp timeout 14400

nat (WAN,LAN) source static HQ-LAN HQ-LAN destination static Branch1-LAN Branch1-

LAN

114

nat (WAN,LAN) source static Branch2-LAN-GRE Branch2-LAN-GRE destination static

Branch1-LAN-GRE Branch1-LAN-GRE

nat (LAN,WAN) source static Branch1-LAN Branch1-LAN destination static HQ-LAN HQ-

LAN

nat (LAN,WAN) source static Branch1-LAN-GRE Branch1-LAN-GRE destination static

Branch2-LAN-GRE Branch2-LAN-GRE access-group WAN-IN in interface WAN

!

router ospf 1

network 22.22.22.0 255.255.255.252 area 0

network 192.168.2.0 255.255.255.252 area 0

log-adj-changes

!

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00

timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00

timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute

timeout tcp-proxy-reassembly 0:01:00

timeout floating-conn 0:00:00

dynamic-access-policy-record DfltAccessPolicy

user-identity default-domain LOCAL

no snmp-server location no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart warmstart

crypto ipsec ikev1 transform-set HQ-Br1 esp-aes-256 esp-sha-hmac

crypto map HQ-Br1 1 match address HQ-Br1-Map

crypto map HQ-Br1 1 set peer 11.11.11.2

crypto map HQ-Br1 1 set ikev1 transform-set HQ-Br1

crypto map HQ-Br1 interface WAN

crypto isakmp identity address

crypto ikev1 enable WAN

crypto ikev1 policy 1

authentication pre-share

encryption aes-256

hash sha group 2

lifetime 3600

telnet timeout 5

ssh timeout 5

console timeout 0

threat-detection basic-threat

threat-detection statistics access-list

no threat-detection statistics tcp-intercept

tunnel-group 11.11.11.2 type ipsec-l2l

tunnel-group 11.11.11.2 ipsec-attributes

ikev1 pre-shared-key *****

!!

prompt hostname context

115

no call-home reporting anonymous

call-home

profile CiscoTAC-1

no active

destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService

destination address email [anonimizat]

destination transport-method http

subscribe-to-alert-group diagnostic

subscribe-to-alert-group environment

subscribe-to-alert-group inventory periodic monthly

subscribe-to-alert-group configuration periodic monthly

subscribe-to-alert-group telemetry periodic daily

crashinfo save disable

Cryptochecksum:c279e6a4eae895911a15b94872d12856

: end

2. Configuratia Branch1-R

Branch1-R#sh run

Building configuration…

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname Branch1-R

!

ip subnet-zero

ip tcp synwait-time 5

!

interface Tunnel2

ip address 172.28.3.1 255.255.255.252

no ip directed-broadcast

ip mtu 1400

tunnel source 192.168.2.2

tunnel destination 192.168.3.2

!

interface FastEthernet0/0

ip address 192.168.2.2 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

!

interface FastEthernet1/0

ip address 10.10.2.1 255.255.255.0

no ip directed-broadcast

duplex auto

116

speed auto

!

router ospf 1

passive-interface FastEthernet1/0

network 10.10.2.0 0.0.0.255 area 0

network 172.28.3.0 0.0.0.3 area 0

network 192.168.2.0 0.0.0.3 area 0

!

ip classless

ip route 10.10.3.0 255.255.255.0 172.28.3.2

no ip http server

line con 0

exec-timeout 0 0 privilege level 15

logging synchronous transport input none

line aux 0

exec-timeout 0 0 privilege level 15

logging synchronous

line vty 0 4

login

!

end

3. Configuratia Branch2-ASA

Branch2-ASA# sh run

: Saved

:

ASA Version 8.4(2)

!

hostname Branch2-ASA

enable password 8Ry2YjIyt7RRXU24 encrypted

passwd 2KFQnbNIdI.2KYOU encrypted

names

!

interface GigabitEthernet0

nameif WAN

security-level 0

ip address 33.33.33.2 255.255.255.252

!

interface GigabitEthernet1

nameif LAN

security-level 100

ip address 192.168.3.1 255.255.255.252

!

ftp mode passive

same-security-traffic permit inter-interface

object network HQ-LAN-GRE

host 192.168.1.2

117

object network Branch1-LAN-GRE

host 192.168.2.2

object network Branch2-LAN-GRE

host 192.168.3.2

object network Branch2-WAN

host 33.33.33.2

access-list WAN-IN extended permit ip object HQ-LAN-GRE object Branch2-LAN-GRE access-list WAN-IN extended permit ip object Branch1-LAN-GRE object Branch2-LAN-

GRE

access-list WAN-IN extended deny ip any any

access-list HQ-Br2-Map extended permit ip object Branch2-LAN-GRE object HQ-LAN-GRE

pager lines 24

mtu WAN 1500 mtu LAN 1500

no failover

icmp unreachable rate-limit 1 burst-size 1

no asdm history enable

arp timeout 14400

nat (WAN,LAN) source static HQ-LAN-GRE HQ-LAN-GRE destination static Branch2-

LAN-GRE Branch2-LAN-GRE

nat (WAN,LAN) source static Branch1-LAN-GRE Branch1-LAN-GRE destination static

Branch2-LAN-GRE Branch2-LAN-GRE

nat (LAN,WAN) source static Branch2-LAN-GRE Branch2-LAN-GRE destination static HQ-

LAN-GRE HQ-LAN-GRE

nat (LAN,WAN) source static Branch2-LAN-GRE Branch2-LAN-GRE destination static

Branch1-LAN-GRE Branch1-LAN-GRE access-group WAN-IN in interface WAN

!

router ospf 1

network 33.33.33.0 255.255.255.252 area 0

network 192.168.3.0 255.255.255.252 area 0

log-adj-changes

!

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00

timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00

timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute

timeout tcp-proxy-reassembly 0:01:00

timeout floating-conn 0:00:00

dynamic-access-policy-record DfltAccessPolicy

user-identity default-domain LOCAL

no snmp-server location no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart warmstart

crypto ipsec ikev1 transform-set HQ-Br2 esp-aes-256 esp-sha-hmac

crypto map HQ-Map 1 match address HQ-Br2-Map

crypto map HQ-Map 1 set peer 11.11.11.2

crypto map HQ-Map 1 set ikev1 transform-set HQ-Br2

crypto map HQ-Map interface WAN

118

crypto isakmp identity address

crypto ikev1 enable WAN

crypto ikev1 policy 1

authentication pre-share

encryption aes-256

hash sha group 2

lifetime 3600

telnet timeout 5

ssh timeout 5

console timeout 0

threat-detection basic-threat

threat-detection statistics access-list

no threat-detection statistics tcp-intercept

tunnel-group 11.11.11.2 type ipsec-l2l

tunnel-group 11.11.11.2 ipsec-attributes

ikev1 pre-shared-key *****

!!

prompt hostname context

no call-home reporting anonymous

call-home

profile CiscoTAC-1

no active

destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService

destination address email [anonimizat]

destination transport-method http

subscribe-to-alert-group diagnostic

subscribe-to-alert-group environment

subscribe-to-alert-group inventory periodic monthly

subscribe-to-alert-group configuration periodic monthly

subscribe-to-alert-group telemetry periodic daily

crashinfo save disable

Cryptochecksum:0b182dc58f7c0ef80c98f462550342c3

: end

4. Configuratia Branch2-R

Branch2-R#sh run

Building configuration…

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname Branch2-R

!

ip subnet-zero

119

ip tcp synwait-time 5

!

interface Tunnel1

ip address 172.28.2.2 255.255.255.252

no ip directed-broadcast

ip mtu 1400

tunnel source 192.168.3.2

tunnel destination 192.168.1.2

!

interface Tunnel2

ip address 172.28.3.2 255.255.255.252

no ip directed-broadcast

ip mtu 1400

tunnel source 192.168.3.2

tunnel destination 192.168.2.2

!

interface FastEthernet0/0

ip address 192.168.3.2 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

!

interface FastEthernet1/0

ip address 10.10.3.1 255.255.255.0

no ip directed-broadcast

duplex auto speed auto

!

router ospf 1

passive-interface FastEthernet1/0

network 10.10.3.0 0.0.0.255 area 0 network 172.28.2.0 0.0.0.3 area 0 network 172.28.3.0 0.0.0.3 area 0

network 192.168.3.0 0.0.0.3 area 0

!

ip classless

ip route 10.10.1.0 255.255.255.0 172.28.2.1 ip route 10.10.2.0 255.255.255.0 172.28.3.1

no ip http server

!!

line con 0

exec-timeout 0 0 privilege level 15

logging synchronous transport input none

line aux 0

exec-timeout 0 0 privilege level 15

logging synchronous

120

line vty 0 4

login

!

end

5. Configuratia HQ-ASA HQ-ASA(config)# sh run

: Saved

:

ASA Version 8.4(2)

!

hostname HQ-ASA

enable password 8Ry2YjIyt7RRXU24 encrypted

passwd 2KFQnbNIdI.2KYOU encrypted

names

!

interface GigabitEthernet0

nameif WAN

security-level 0

ip address 11.11.11.2 255.255.255.252

!

interface GigabitEthernet1

nameif LAN

security-level 100

ip address 192.168.1.1 255.255.255.252

!

ftp mode passive

same-security-traffic permit inter-interface

object network HQ-LAN-GRE

host 192.168.1.2

object network HQ-WAN

host 11.11.11.2

object network Branch1-LAN

subnet 10.10.2.0 255.255.255.0

object network Branch2-LAN-GRE

host 192.168.3.2

object network HQ-LAN

subnet 10.10.1.0 255.255.255.0

object network RemoteUsers

subnet 10.20.1.0 255.255.255.0

object network Host1

host 10.10.1.100

access-list WAN-IN extended permit ip object Branch1-LAN object HQ-LAN

access-list WAN-IN extended permit ip object Branch2-LAN-GRE object HQ-LAN-GRE

access-list WAN-IN extended permit ip object RemoteUsers any

access-list WAN-IN extended deny ip any any

access-list HQ-Br1-Map extended permit ip object HQ-LAN object Branch1-LAN

access-list HQ-Br2-Map extended permit ip object HQ-LAN-GRE object Branch2-LAN-GRE

pager lines 24

mtu WAN 1500

121

mtu LAN 1500

ip local pool RemotePool 10.20.1.1-10.20.1.254

no failover

icmp unreachable rate-limit 1 burst-size 1

no asdm history enable

arp timeout 14400

nat (WAN,LAN) source static HQ-LAN HQ-LAN destination static Branch1-LAN Branch1-

LAN

nat (LAN,WAN) source static Branch1-LAN Branch1-LAN destination static HQ-LAN HQ-

LAN

nat (WAN,LAN) source static HQ-LAN-GRE HQ-LAN-GRE destination static Branch2-

LAN-GRE Branch2-LAN-GRE

nat (LAN,WAN) source static Branch2-LAN-GRE Branch2-LAN-GRE destination static HQ-

LAN-GRE HQ-LAN-GRE

nat (WAN,LAN) source static RemoteUsers RemoteUsers destination static Host1 Host1

access-group WAN-IN in interface WAN

!

router ospf 1

network 11.11.11.0 255.255.255.252 area 0

network 192.168.1.0 255.255.255.252 area 0

log-adj-changes

!

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00

timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00

timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute

timeout tcp-proxy-reassembly 0:01:00

timeout floating-conn 0:00:00

dynamic-access-policy-record DfltAccessPolicy

user-identity default-domain LOCAL

no snmp-server location no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart warmstart

crypto ipsec ikev1 transform-set HQ-Br1 esp-aes-256 esp-sha-hmac crypto ipsec ikev1 transform-set HQ-Br2 esp-aes-256 esp-sha-hmac

crypto ipsec ikev1 transform-set RemoteSet esp-aes-256 esp-sha-hmac

crypto dynamic-map HQ-Map-dynamic 1 set ikev1 transform-set RemoteSet

crypto dynamic-map HQ-Map-dynamic 1 set reverse-route

crypto map HQ-Map 1 match address HQ-Br1-Map

crypto map HQ-Map 1 set peer 22.22.22.2

crypto map HQ-Map 1 set ikev1 transform-set HQ-Br1

crypto map HQ-Map 2 match address HQ-Br2-Map

crypto map HQ-Map 2 set peer 33.33.33.2

crypto map HQ-Map 2 set ikev1 transform-set HQ-Br2

crypto map HQ-Map 3 ipsec-isakmp dynamic HQ-Map-dynamic

crypto map HQ-Map interface WAN

crypto isakmp identity address

crypto ikev1 enable WAN

crypto ikev1 policy 1

122

authentication pre-share

encryption aes-256

hash sha group 2

lifetime 3600

telnet timeout 5

ssh timeout 5

console timeout 0

threat-detection basic-threat

threat-detection statistics access-list

no threat-detection statistics tcp-intercept

username remoteuser password CxAh5EQ/8f4FVvNi encrypted privilege 15

tunnel-group 22.22.22.2 type ipsec-l2l

tunnel-group 22.22.22.2 ipsec-attributes

ikev1 pre-shared-key *****

tunnel-group 33.33.33.2 type ipsec-l2l

tunnel-group 33.33.33.2 ipsec-attributes

ikev1 pre-shared-key *****

tunnel-group RemoteGroup type remote-access

tunnel-group RemoteGroup general-attributes

address-pool RemotePool

tunnel-group RemoteGroup ipsec-attributes

ikev1 pre-shared-key *****

!!

prompt hostname context

no call-home reporting anonymous

call-home

profile CiscoTAC-1

no active

destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService

destination address email [anonimizat]

destination transport-method http

subscribe-to-alert-group diagnostic

subscribe-to-alert-group environment

subscribe-to-alert-group inventory periodic monthly

subscribe-to-alert-group configuration periodic monthly

subscribe-to-alert-group telemetry periodic daily

crashinfo save disable

Cryptochecksum:0f7dfcfe2d1c21004a349760d3638c70

: end

6. Configuratia HQ-R

HQ-R#sh run

Building configuration…

Current configuration:

!

version 12.0

service timestamps debug uptime

123

service timestamps log uptime

no service password-encryption

!

hostname HQ-R

!

ip subnet-zero

ip tcp synwait-time 5

!

interface Tunnel2

ip address 172.28.2.1 255.255.255.252

no ip directed-broadcast

ip mtu 1400

tunnel source 192.168.1.2

tunnel destination 192.168.3.2

!

interface FastEthernet0/0

ip address 192.168.1.2 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

!

interface FastEthernet1/0

ip address 10.10.1.1 255.255.255.0

no ip directed-broadcast

duplex auto speed auto

!

router ospf 1

passive-interface FastEthernet1/0

network 10.10.1.0 0.0.0.255 area 0

network 172.28.2.0 0.0.0.3 area 0

network 192.168.1.0 0.0.0.3 area 0

!

ip classless

ip route 10.10.3.0 255.255.255.0 172.28.2.2

no ip http server

!!

line con 0

exec-timeout 0 0 privilege level 15

logging synchronous transport input none

line aux 0

exec-timeout 0 0 privilege level 15

logging synchronous

line vty 0 4

login

!

124

end

7. Configuratia ISP1

ISP1#sh run

Building configuration…

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname ISP1

!

ip subnet-zero

ip tcp synwait-time 5

!

interface FastEthernet0/0

ip address 11.11.11.1 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

!

interface FastEthernet1/0

ip address 77.77.77.1 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

!

interface FastEthernet2/0

ip address 88.88.88.2 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

!

interface FastEthernet3/0

no ip address

no ip directed-broadcast

shutdown

duplex auto speed auto

!

router ospf 1

network 11.11.11.0 0.0.0.3 area 0 network 77.77.77.0 0.0.0.3 area 0 network 88.88.88.0 0.0.0.3 area 0

!

ip classless

no ip http server

125

!

!

line con 0

exec-timeout 0 0 privilege level 15

logging synchronous transport input none

line aux 0

exec-timeout 0 0 privilege level 15

logging synchronous

line vty 0 4

login

!

end

8. Configuratia ISP2

ISP2#sh run

Building configuration…

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname ISP2

!

ip subnet-zero

ip tcp synwait-time 5

!

interface FastEthernet0/0

ip address 33.33.33.1 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

!

interface FastEthernet1/0

ip address 99.99.99.1 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

!

interface FastEthernet2/0

ip address 77.77.77.2 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

!

126

interface FastEthernet3/0

no ip address

no ip directed-broadcast

shutdown

duplex auto speed auto

!

router ospf 1

network 33.33.33.0 0.0.0.3 area 0 network 77.77.77.0 0.0.0.3 area 0 network 99.99.99.0 0.0.0.3 area 0

!

ip classless

no ip http server

!!

line con 0

exec-timeout 0 0 privilege level 15

logging synchronous transport input none

line aux 0

exec-timeout 0 0 privilege level 15

logging synchronous

line vty 0 4

login

!

end

9. Configuratia ISP3

ISP3#sh run

Building configuration…

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname ISP3

!

ip subnet-zero

ip tcp synwait-time 5

!

interface FastEthernet0/0

ip address 22.22.22.1 255.255.255.252

no ip directed-broadcast

127

duplex auto

speed auto

!

interface FastEthernet1/0

ip address 88.88.88.1 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

!

interface FastEthernet2/0

ip address 99.99.99.2 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

!

router ospf 1

network 22.22.22.0 0.0.0.3 area 0 network 88.88.88.0 0.0.0.3 area 0 network 99.99.99.0 0.0.0.3 area 0

!

ip classless

no ip http server

!!

line con 0

exec-timeout 0 0 privilege level 15

logging synchronous transport input none

line aux 0

exec-timeout 0 0 privilege level 15

logging synchronous

line vty 0 4

login

!

end

128

ANEXA 2

Echo-reply in tunel GRE

129

ANEXA 3

Echo-reply in tunel IPSec

130

ANEXA 4

Echo-reply in tunel GRE over IPSec

131

ANEXA 5 Site-ul SSL

<HEAD> <TITLE>

LUCRARE DE LICENTA – CONSTANTIN MANEA (HTTPS – SSL)

</TITLE>

<CENTER>

<H1> UNIVERSITATEA POLITEHNICA BUCURESTI </H1>

<H2> FACULTATEA DE ELECTRONICA, TELECOMUNICATII SI TEHNOLOGIA

INFORMATIEI </H2> <IMG SRC=./UPB.jpg>

<H3>

<P align=left> Profesor Coordonator: </P>

<P align=left> Sl.dr.ing. ADRIAN FLORIN PAUN </P>

<P align=right> Absolvent: </P>

<P align=right> CONSTANTIN MANEA </P>

</H3>

</HEAD>

Figura 1. UPB.jpg

132

ANEXA 6

Site-ul TLS

<HEAD> <TITLE>

LUCRARE DE LICENTA – CONSTANTIN MANEA (HTTPS – TLS)

</TITLE>

<CENTER>

<H1> UNIVERSITATEA POLITEHNICA BUCURESTI </H1>

<H2> FACULTATEA DE ELECTRONICA, TELECOMUNICATII SI TEHNOLOGIA

INFORMATIEI </H2> <IMG SRC=./UPB.jpg>

<H3>

<P align=left> Profesor Coordonator: </P>

<P align=left> Sl.dr.ing. ADRIAN FLORIN PAUN </P>

<P align=right> Absolvent: </P>

<P align=right> CONSTANTIN MANEA </P>

</H3>

</HEAD>

Figura 2. UPB.jpg

133

ANEXA 7

Fisierul ssl.conf

[root@CentOS-1 https-ssl]# cat /etc/httpd/conf.d/ssl.conf

#

# This is the Apache server configuration file providing SSL support. # It contains the configuration directives to instruct the server how to

# serve pages over an https connection. For detailing information about these

# directives see <URL:http://httpd.apache.org/docs/2.2/mod/mod_ssl.html>

#

# Do NOT simply read the instructions in here without understanding

# what they do. They're here only as hints or reminders. If you are unsure # consult the online docs. You have been warned.

#

LoadModule ssl_module modules/mod_ssl.so

#

# When we also provide SSL we have to listen to the # the HTTPS port in addition.

#

Listen 443

Listen 1443

##

## SSL Global Context

##

## All SSL configuration in this context applies both to ## the main server and all SSL-enabled virtual hosts.

##

# Pass Phrase Dialog:

# Configure the pass phrase gathering process.

# The filtering dialog program (`builtin' is a internal

# terminal dialog) has to provide the pass phrase on stdout.

SSLPassPhraseDialog builtin

# Inter-Process Session Cache:

# Configure the SSL Session Cache: First the mechanism

# to use and second the expiring timeout (in seconds).

SSLSessionCache shmcb:/var/cache/mod_ssl/scache(512000)

SSLSessionCacheTimeout 300

# Semaphore:

# Configure the path to the mutual exclusion semaphore the

# SSL engine uses internally for inter-process synchronization.

SSLMutex default

# Pseudo Random Number Generator (PRNG):

134

# Configure one or more sources to seed the PRNG of the

# SSL library. The seed data should be of good random quality.

# WARNING! On some platforms /dev/random blocks if not enough entropy

# is available. This means you then cannot use the /dev/random device

# because it would lead to very long connection times (as long as

# it requires to make more entropy available). But usually those

# platforms additionally provide a /dev/urandom device which doesn't # block. So, if available, use this one instead. Read the mod_ssl User # Manual for more details.

SSLRandomSeed startup file:/dev/urandom 256

SSLRandomSeed connect builtin

#SSLRandomSeed startup file:/dev/random 512 #SSLRandomSeed connect file:/dev/random 512 #SSLRandomSeed connect file:/dev/urandom 512

#

# Use "SSLCryptoDevice" to enable any supported hardware

# accelerators. Use "openssl engine -v" to list supported

# engine names. NOTE: If you enable an accelerator and the

# server does not start, consult the error logs and ensure # your accelerator is functioning properly.

#

SSLCryptoDevice builtin #SSLCryptoDevice ubsec

##

## SSL Virtual Host Context

##

#<VirtualHost _default_:443>

# General setup for the virtual host, inherited from global configuration

#DocumentRoot "/var/www/html"

#ServerName www.example.com:443

# Use separate log files for the SSL virtual host; note that LogLevel # is not inherited from httpd.conf.

ErrorLog logs/ssl_error_log

TransferLog logs/ssl_access_log

LogLevel warn

# SSL Engine Switch:

# Enable/Disable SSL for this virtual host.

SSLEngine on

# SSL Protocol support:

# List the enable protocol levels with which clients will be able to

# connect. Disable SSLv2 access by default:

#SSLProtocol all

135

# SSL Cipher Suite:

# List the ciphers that the client is permitted to negotiate. # See the mod_ssl documentation for a complete list.

#SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW

# Server Certificate:

# Point SSLCertificateFile at a PEM encoded certificate. If

# the certificate is encrypted, then you will be prompted for a

# pass phrase. Note that a kill -HUP will prompt again. A new # certificate can be generated using the genkey(1) command.

SSLCertificateFile /etc/pki/tls/http/apachecert.pem

# Server Private Key:

# If the key is not combined with the certificate, use this # directive to point at the key file. Keep in mind that if

# you've both a RSA and a DSA private key you can configure

# both in parallel (to also allow the use of DSA ciphers, etc.)

SSLCertificateKeyFile /etc/pki/tls/http/apachekey.pem

# Server Certificate Chain:

# Point SSLCertificateChainFile at a file containing the

# concatenation of PEM encoded CA certificates which form the

# certificate chain for the server certificate. Alternatively

# the referenced file can be the same as SSLCertificateFile

# when the CA certificates are directly appended to the server # certificate for convinience.

#SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt

# Certificate Authority (CA):

# Set the CA certificate verification path where to find CA # certificates for client authentication or alternatively one

# huge file containing all of them (file must be PEM encoded)

#SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt

# Client Authentication (Type):

# Client certificate verification type and depth. Types are # none, optional, require and optional_no_ca. Depth is a

# number which specifies how deeply to verify the certificate # issuer chain before deciding the certificate is not valid.

#SSLVerifyClient require

#SSLVerifyDepth 10

# Access Control:

# With SSLRequire you can do per-directory access control based

# on arbitrary complex boolean expressions containing server # variable checks and other lookup directives. The syntax is a # mixture between C and Perl. See the mod_ssl documentation # for more details.

#<Location />

#SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \

136

# and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \

# and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \

# and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \

# and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 )\

# or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/

#</Location>

# SSL Engine Options:

# Set various options for the SSL engine.

# o FakeBasicAuth:

# Translate the client X.509 into a Basic Authorisation. This means that

# the standard Auth/DBMAuth methods can be used for access control. The

# user name is the `one line' version of the client's X.509 certificate.

# Note that no password is obtained from the user. Every entry in the user # file needs this password: `xxj31ZMTZzkVA'.

# o ExportCertData:

# This exports two additional environment variables: SSL_CLIENT_CERT and

# SSL_SERVER_CERT. These contain the PEM-encoded certificates of the

# server (always existing) and the client (only existing when client # authentication is used). This can be used to import the certificates # into CGI scripts.

# o StdEnvVars:

# This exports the standard SSL/TLS related `SSL_*' environment variables.

# Per default this exportation is switched off for performance reasons, # because the extraction step is an expensive operation and is usually

# useless for serving static content. So one usually enables the # exportation for CGI and SSI requests only.

# o StrictRequire:

# This denies access when "SSLRequireSSL" or "SSLRequire" applied even

# under a "Satisfy any" situation, i.e. when it applies access is denied # and no other module can change it.

# o OptRenegotiate:

# This enables optimized SSL connection renegotiation handling when SSL # directives are used in per-directory context.

#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire

<Files ~ "\.(cgi|shtml|phtml|php3?)$">

SSLOptions +StdEnvVars

</Files>

<Directory "/var/www/cgi-bin">

SSLOptions +StdEnvVars

</Directory>

# SSL Protocol Adjustments:

# The safe and default but still SSL/TLS standard compliant shutdown

# approach is that mod_ssl sends the close notify alert but doesn't wait for

# the close notify alert from client. When you need a different shutdown

# approach you can use one of the following variables:

# o ssl-unclean-shutdown:

# This forces an unclean shutdown when the connection is closed, i.e. no

# SSL close notify alert is send or allowed to received. This violates

137

# the SSL/TLS standard but is needed for some brain-dead browsers. Use

# this when you receive I/O errors because of the standard approach where # mod_ssl sends the close notify alert.

# o ssl-accurate-shutdown:

# This forces an accurate shutdown when the connection is closed, i.e. a

# SSL close notify alert is send and mod_ssl waits for the close notify # alert of the client. This is 100% SSL/TLS standard compliant, but in

# practice often causes hanging connections with brain-dead browsers. Use

# this only for browsers where you know that their SSL implementation # works correctly.

# Notice: Most problems of broken clients are also related to the HTTP

# keep-alive facility, so you usually additionally want to disable

# keep-alive for those clients, too. Use variable "nokeepalive" for this.

# Similarly, one has to force some clients to use HTTP/1.0 to workaround

# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and # "force-response-1.0" for this.

SetEnvIf User-Agent ".*MSIE.*" \

nokeepalive ssl-unclean-shutdown \

downgrade-1.0 force-response-1.0

# Per-Server Logging:

# The home of a custom SSL log file. Use this when you want a # compact non-error SSL logfile on a virtual host basis.

CustomLog logs/ssl_request_log \

"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

#</VirtualHost>

#<VirtualHost *:443>

# SSLEngine on

# SSLProtocol SSLv3

# SSLCipherSuite HIGH:!aNULL:!MD5

# SSLCertificateFile /etc/pki/tls/http/apachecert.pem

# SSLCertificateKeyFile /etc/pki/tls/http/apachekey.pem

# DocumentRoot "/var/www/html/https-ssl"

#<Directory /var/www/html/https-ssl>

# Order allow,deny

# Allow from all

#</Directory>

#</VirtualHost>

<VirtualHost *:443>

SSLEngine on

SSLProtocol TLSv1

SSLCipherSuite HIGH:!aNULL:!MD5

SSLCertificateFile /etc/pki/tls/http/apachecert.pem

SSLCertificateKeyFile /etc/pki/tls/http/apachekey.pem

DocumentRoot "/var/www/html/https-tls"

<Directory /var/www/html/https-tls>

Order allow,deny

138

Allow from all

</Directory>

</VirtualHost>

<VirtualHost *:80>

SSLEngine off

DocumentRoot "/var/www/html/http"

<Directory /var/www/html/http>

Order allow,deny

Allow from all

</Directory>

</VirtualHost>

139

BIBLIOGRAFIE

1) Cisco Network Security Internet Technical Solution (e-Seminar)

2) Bogdan Groza, "Introducere in Sisteme Criptografice cu Cheie Publica", Curs 3) Alexandru Isar, "Curs securitatea transmiterii informatiei prin internet", Curs

4) Asist. Razvan ZOTA, "Solutii de securitate pentru Internet", in Revista Informatica

Economica, nr.12/1999 69

5) Luminita S. , Ion B. , "Securitatea Retelelor de Comunicatii", Casa de editura

"Venus" Iasi 2008

6) http://www.securitatea-informatica.ro/securitatea-informatica/securitatea-si-

confidentialitatea-datelor-in-retelele-publice/

7) http://ro.wikipedia.org/wiki/Re%C8%9Bea_privat%C4%83_virtual%C4%83 8) Revista 52 Informatica Economică nr. 2(30)/2004 An Overview of the Attack

Methods Directed Against the RSA Algorithm

9) Bogdan Groza, „Introducere în SistemeleCriptografice cu Cheie Publică",

http://www.aut.upt.ro/~bgroza/iccp.pdf accesat la data 18.06.2012

10) Asist. Simona Ionescu, "Considerations on data encryption and decruption", in Revista

Informatica Economica, nr.2(30)/2004

11) Revista 52 Informatica Economică nr. 2(30)/2004 An Overview of the Attack

Methods Directed Against the RSA Algorithm

12) Martin W. Murhammer, "A Comprehensive Guide to Virtual Private Networks",

International Technical Support Organization 1999

13) http://www.netaccess.ro/retele_virtuale_private.html accesat la data 15.03.2012

http://ro.wikipedia.org/wiki/Vpn

http://en.wikipedia.org/wiki/Secure_Sockets_Layer

ANEXE

113

ANEXA 1

Configuratia completa a echipamentelor de retea

1 – Configuratie Branch1-ASA

Branch1-ASA# sh run

: Saved

:

ASA Version 8.4(2)

!

hostname Branch1-ASA

enable password 8Ry2YjIyt7RRXU24 encrypted

passwd 2KFQnbNIdI.2KYOU encrypted

names

!

interface GigabitEthernet0

nameif WAN

security-level 0

ip address 22.22.22.2 255.255.255.252

!

interface GigabitEthernet1

nameif LAN

security-level 100

ip address 192.168.2.1 255.255.255.252

!

ftp mode passive

same-security-traffic permit inter-interface

object network HQ-LAN

subnet 10.10.1.0 255.255.255.0

object network Branch1-LAN-GRE

host 192.168.2.2

object network Branch2-LAN-GRE

host 192.168.3.2

object network Branch1-WAN

host 22.22.22.2

object network Branch1-LAN

subnet 10.10.2.0 255.255.255.0

access-list WAN-IN extended permit ip object HQ-LAN object Branch1-LAN

access-list WAN-IN extended permit ip object Branch2-LAN-GRE object Branch1-LAN-

GRE

access-list WAN-IN extended deny ip any any

access-list HQ-Br1-Map extended permit ip object Branch1-LAN object HQ-LAN

pager lines 24

mtu WAN 1500 mtu LAN 1500

no failover

icmp unreachable rate-limit 1 burst-size 1

no asdm history enable

arp timeout 14400

nat (WAN,LAN) source static HQ-LAN HQ-LAN destination static Branch1-LAN Branch1-

LAN

114

nat (WAN,LAN) source static Branch2-LAN-GRE Branch2-LAN-GRE destination static

Branch1-LAN-GRE Branch1-LAN-GRE

nat (LAN,WAN) source static Branch1-LAN Branch1-LAN destination static HQ-LAN HQ-

LAN

nat (LAN,WAN) source static Branch1-LAN-GRE Branch1-LAN-GRE destination static

Branch2-LAN-GRE Branch2-LAN-GRE access-group WAN-IN in interface WAN

!

router ospf 1

network 22.22.22.0 255.255.255.252 area 0

network 192.168.2.0 255.255.255.252 area 0

log-adj-changes

!

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00

timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00

timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute

timeout tcp-proxy-reassembly 0:01:00

timeout floating-conn 0:00:00

dynamic-access-policy-record DfltAccessPolicy

user-identity default-domain LOCAL

no snmp-server location no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart warmstart

crypto ipsec ikev1 transform-set HQ-Br1 esp-aes-256 esp-sha-hmac

crypto map HQ-Br1 1 match address HQ-Br1-Map

crypto map HQ-Br1 1 set peer 11.11.11.2

crypto map HQ-Br1 1 set ikev1 transform-set HQ-Br1

crypto map HQ-Br1 interface WAN

crypto isakmp identity address

crypto ikev1 enable WAN

crypto ikev1 policy 1

authentication pre-share

encryption aes-256

hash sha group 2

lifetime 3600

telnet timeout 5

ssh timeout 5

console timeout 0

threat-detection basic-threat

threat-detection statistics access-list

no threat-detection statistics tcp-intercept

tunnel-group 11.11.11.2 type ipsec-l2l

tunnel-group 11.11.11.2 ipsec-attributes

ikev1 pre-shared-key *****

!!

prompt hostname context

115

no call-home reporting anonymous

call-home

profile CiscoTAC-1

no active

destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService

destination address email [anonimizat]

destination transport-method http

subscribe-to-alert-group diagnostic

subscribe-to-alert-group environment

subscribe-to-alert-group inventory periodic monthly

subscribe-to-alert-group configuration periodic monthly

subscribe-to-alert-group telemetry periodic daily

crashinfo save disable

Cryptochecksum:c279e6a4eae895911a15b94872d12856

: end

2. Configuratia Branch1-R

Branch1-R#sh run

Building configuration…

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname Branch1-R

!

ip subnet-zero

ip tcp synwait-time 5

!

interface Tunnel2

ip address 172.28.3.1 255.255.255.252

no ip directed-broadcast

ip mtu 1400

tunnel source 192.168.2.2

tunnel destination 192.168.3.2

!

interface FastEthernet0/0

ip address 192.168.2.2 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

!

interface FastEthernet1/0

ip address 10.10.2.1 255.255.255.0

no ip directed-broadcast

duplex auto

116

speed auto

!

router ospf 1

passive-interface FastEthernet1/0

network 10.10.2.0 0.0.0.255 area 0

network 172.28.3.0 0.0.0.3 area 0

network 192.168.2.0 0.0.0.3 area 0

!

ip classless

ip route 10.10.3.0 255.255.255.0 172.28.3.2

no ip http server

line con 0

exec-timeout 0 0 privilege level 15

logging synchronous transport input none

line aux 0

exec-timeout 0 0 privilege level 15

logging synchronous

line vty 0 4

login

!

end

3. Configuratia Branch2-ASA

Branch2-ASA# sh run

: Saved

:

ASA Version 8.4(2)

!

hostname Branch2-ASA

enable password 8Ry2YjIyt7RRXU24 encrypted

passwd 2KFQnbNIdI.2KYOU encrypted

names

!

interface GigabitEthernet0

nameif WAN

security-level 0

ip address 33.33.33.2 255.255.255.252

!

interface GigabitEthernet1

nameif LAN

security-level 100

ip address 192.168.3.1 255.255.255.252

!

ftp mode passive

same-security-traffic permit inter-interface

object network HQ-LAN-GRE

host 192.168.1.2

117

object network Branch1-LAN-GRE

host 192.168.2.2

object network Branch2-LAN-GRE

host 192.168.3.2

object network Branch2-WAN

host 33.33.33.2

access-list WAN-IN extended permit ip object HQ-LAN-GRE object Branch2-LAN-GRE access-list WAN-IN extended permit ip object Branch1-LAN-GRE object Branch2-LAN-

GRE

access-list WAN-IN extended deny ip any any

access-list HQ-Br2-Map extended permit ip object Branch2-LAN-GRE object HQ-LAN-GRE

pager lines 24

mtu WAN 1500 mtu LAN 1500

no failover

icmp unreachable rate-limit 1 burst-size 1

no asdm history enable

arp timeout 14400

nat (WAN,LAN) source static HQ-LAN-GRE HQ-LAN-GRE destination static Branch2-

LAN-GRE Branch2-LAN-GRE

nat (WAN,LAN) source static Branch1-LAN-GRE Branch1-LAN-GRE destination static

Branch2-LAN-GRE Branch2-LAN-GRE

nat (LAN,WAN) source static Branch2-LAN-GRE Branch2-LAN-GRE destination static HQ-

LAN-GRE HQ-LAN-GRE

nat (LAN,WAN) source static Branch2-LAN-GRE Branch2-LAN-GRE destination static

Branch1-LAN-GRE Branch1-LAN-GRE access-group WAN-IN in interface WAN

!

router ospf 1

network 33.33.33.0 255.255.255.252 area 0

network 192.168.3.0 255.255.255.252 area 0

log-adj-changes

!

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00

timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00

timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute

timeout tcp-proxy-reassembly 0:01:00

timeout floating-conn 0:00:00

dynamic-access-policy-record DfltAccessPolicy

user-identity default-domain LOCAL

no snmp-server location no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart warmstart

crypto ipsec ikev1 transform-set HQ-Br2 esp-aes-256 esp-sha-hmac

crypto map HQ-Map 1 match address HQ-Br2-Map

crypto map HQ-Map 1 set peer 11.11.11.2

crypto map HQ-Map 1 set ikev1 transform-set HQ-Br2

crypto map HQ-Map interface WAN

118

crypto isakmp identity address

crypto ikev1 enable WAN

crypto ikev1 policy 1

authentication pre-share

encryption aes-256

hash sha group 2

lifetime 3600

telnet timeout 5

ssh timeout 5

console timeout 0

threat-detection basic-threat

threat-detection statistics access-list

no threat-detection statistics tcp-intercept

tunnel-group 11.11.11.2 type ipsec-l2l

tunnel-group 11.11.11.2 ipsec-attributes

ikev1 pre-shared-key *****

!!

prompt hostname context

no call-home reporting anonymous

call-home

profile CiscoTAC-1

no active

destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService

destination address email [anonimizat]

destination transport-method http

subscribe-to-alert-group diagnostic

subscribe-to-alert-group environment

subscribe-to-alert-group inventory periodic monthly

subscribe-to-alert-group configuration periodic monthly

subscribe-to-alert-group telemetry periodic daily

crashinfo save disable

Cryptochecksum:0b182dc58f7c0ef80c98f462550342c3

: end

4. Configuratia Branch2-R

Branch2-R#sh run

Building configuration…

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname Branch2-R

!

ip subnet-zero

119

ip tcp synwait-time 5

!

interface Tunnel1

ip address 172.28.2.2 255.255.255.252

no ip directed-broadcast

ip mtu 1400

tunnel source 192.168.3.2

tunnel destination 192.168.1.2

!

interface Tunnel2

ip address 172.28.3.2 255.255.255.252

no ip directed-broadcast

ip mtu 1400

tunnel source 192.168.3.2

tunnel destination 192.168.2.2

!

interface FastEthernet0/0

ip address 192.168.3.2 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

!

interface FastEthernet1/0

ip address 10.10.3.1 255.255.255.0

no ip directed-broadcast

duplex auto speed auto

!

router ospf 1

passive-interface FastEthernet1/0

network 10.10.3.0 0.0.0.255 area 0 network 172.28.2.0 0.0.0.3 area 0 network 172.28.3.0 0.0.0.3 area 0

network 192.168.3.0 0.0.0.3 area 0

!

ip classless

ip route 10.10.1.0 255.255.255.0 172.28.2.1 ip route 10.10.2.0 255.255.255.0 172.28.3.1

no ip http server

!!

line con 0

exec-timeout 0 0 privilege level 15

logging synchronous transport input none

line aux 0

exec-timeout 0 0 privilege level 15

logging synchronous

120

line vty 0 4

login

!

end

5. Configuratia HQ-ASA HQ-ASA(config)# sh run

: Saved

:

ASA Version 8.4(2)

!

hostname HQ-ASA

enable password 8Ry2YjIyt7RRXU24 encrypted

passwd 2KFQnbNIdI.2KYOU encrypted

names

!

interface GigabitEthernet0

nameif WAN

security-level 0

ip address 11.11.11.2 255.255.255.252

!

interface GigabitEthernet1

nameif LAN

security-level 100

ip address 192.168.1.1 255.255.255.252

!

ftp mode passive

same-security-traffic permit inter-interface

object network HQ-LAN-GRE

host 192.168.1.2

object network HQ-WAN

host 11.11.11.2

object network Branch1-LAN

subnet 10.10.2.0 255.255.255.0

object network Branch2-LAN-GRE

host 192.168.3.2

object network HQ-LAN

subnet 10.10.1.0 255.255.255.0

object network RemoteUsers

subnet 10.20.1.0 255.255.255.0

object network Host1

host 10.10.1.100

access-list WAN-IN extended permit ip object Branch1-LAN object HQ-LAN

access-list WAN-IN extended permit ip object Branch2-LAN-GRE object HQ-LAN-GRE

access-list WAN-IN extended permit ip object RemoteUsers any

access-list WAN-IN extended deny ip any any

access-list HQ-Br1-Map extended permit ip object HQ-LAN object Branch1-LAN

access-list HQ-Br2-Map extended permit ip object HQ-LAN-GRE object Branch2-LAN-GRE

pager lines 24

mtu WAN 1500

121

mtu LAN 1500

ip local pool RemotePool 10.20.1.1-10.20.1.254

no failover

icmp unreachable rate-limit 1 burst-size 1

no asdm history enable

arp timeout 14400

nat (WAN,LAN) source static HQ-LAN HQ-LAN destination static Branch1-LAN Branch1-

LAN

nat (LAN,WAN) source static Branch1-LAN Branch1-LAN destination static HQ-LAN HQ-

LAN

nat (WAN,LAN) source static HQ-LAN-GRE HQ-LAN-GRE destination static Branch2-

LAN-GRE Branch2-LAN-GRE

nat (LAN,WAN) source static Branch2-LAN-GRE Branch2-LAN-GRE destination static HQ-

LAN-GRE HQ-LAN-GRE

nat (WAN,LAN) source static RemoteUsers RemoteUsers destination static Host1 Host1

access-group WAN-IN in interface WAN

!

router ospf 1

network 11.11.11.0 255.255.255.252 area 0

network 192.168.1.0 255.255.255.252 area 0

log-adj-changes

!

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00

timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00

timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute

timeout tcp-proxy-reassembly 0:01:00

timeout floating-conn 0:00:00

dynamic-access-policy-record DfltAccessPolicy

user-identity default-domain LOCAL

no snmp-server location no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart warmstart

crypto ipsec ikev1 transform-set HQ-Br1 esp-aes-256 esp-sha-hmac crypto ipsec ikev1 transform-set HQ-Br2 esp-aes-256 esp-sha-hmac

crypto ipsec ikev1 transform-set RemoteSet esp-aes-256 esp-sha-hmac

crypto dynamic-map HQ-Map-dynamic 1 set ikev1 transform-set RemoteSet

crypto dynamic-map HQ-Map-dynamic 1 set reverse-route

crypto map HQ-Map 1 match address HQ-Br1-Map

crypto map HQ-Map 1 set peer 22.22.22.2

crypto map HQ-Map 1 set ikev1 transform-set HQ-Br1

crypto map HQ-Map 2 match address HQ-Br2-Map

crypto map HQ-Map 2 set peer 33.33.33.2

crypto map HQ-Map 2 set ikev1 transform-set HQ-Br2

crypto map HQ-Map 3 ipsec-isakmp dynamic HQ-Map-dynamic

crypto map HQ-Map interface WAN

crypto isakmp identity address

crypto ikev1 enable WAN

crypto ikev1 policy 1

122

authentication pre-share

encryption aes-256

hash sha group 2

lifetime 3600

telnet timeout 5

ssh timeout 5

console timeout 0

threat-detection basic-threat

threat-detection statistics access-list

no threat-detection statistics tcp-intercept

username remoteuser password CxAh5EQ/8f4FVvNi encrypted privilege 15

tunnel-group 22.22.22.2 type ipsec-l2l

tunnel-group 22.22.22.2 ipsec-attributes

ikev1 pre-shared-key *****

tunnel-group 33.33.33.2 type ipsec-l2l

tunnel-group 33.33.33.2 ipsec-attributes

ikev1 pre-shared-key *****

tunnel-group RemoteGroup type remote-access

tunnel-group RemoteGroup general-attributes

address-pool RemotePool

tunnel-group RemoteGroup ipsec-attributes

ikev1 pre-shared-key *****

!!

prompt hostname context

no call-home reporting anonymous

call-home

profile CiscoTAC-1

no active

destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService

destination address email [anonimizat]

destination transport-method http

subscribe-to-alert-group diagnostic

subscribe-to-alert-group environment

subscribe-to-alert-group inventory periodic monthly

subscribe-to-alert-group configuration periodic monthly

subscribe-to-alert-group telemetry periodic daily

crashinfo save disable

Cryptochecksum:0f7dfcfe2d1c21004a349760d3638c70

: end

6. Configuratia HQ-R

HQ-R#sh run

Building configuration…

Current configuration:

!

version 12.0

service timestamps debug uptime

123

service timestamps log uptime

no service password-encryption

!

hostname HQ-R

!

ip subnet-zero

ip tcp synwait-time 5

!

interface Tunnel2

ip address 172.28.2.1 255.255.255.252

no ip directed-broadcast

ip mtu 1400

tunnel source 192.168.1.2

tunnel destination 192.168.3.2

!

interface FastEthernet0/0

ip address 192.168.1.2 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

!

interface FastEthernet1/0

ip address 10.10.1.1 255.255.255.0

no ip directed-broadcast

duplex auto speed auto

!

router ospf 1

passive-interface FastEthernet1/0

network 10.10.1.0 0.0.0.255 area 0

network 172.28.2.0 0.0.0.3 area 0

network 192.168.1.0 0.0.0.3 area 0

!

ip classless

ip route 10.10.3.0 255.255.255.0 172.28.2.2

no ip http server

!!

line con 0

exec-timeout 0 0 privilege level 15

logging synchronous transport input none

line aux 0

exec-timeout 0 0 privilege level 15

logging synchronous

line vty 0 4

login

!

124

end

7. Configuratia ISP1

ISP1#sh run

Building configuration…

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname ISP1

!

ip subnet-zero

ip tcp synwait-time 5

!

interface FastEthernet0/0

ip address 11.11.11.1 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

!

interface FastEthernet1/0

ip address 77.77.77.1 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

!

interface FastEthernet2/0

ip address 88.88.88.2 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

!

interface FastEthernet3/0

no ip address

no ip directed-broadcast

shutdown

duplex auto speed auto

!

router ospf 1

network 11.11.11.0 0.0.0.3 area 0 network 77.77.77.0 0.0.0.3 area 0 network 88.88.88.0 0.0.0.3 area 0

!

ip classless

no ip http server

125

!

!

line con 0

exec-timeout 0 0 privilege level 15

logging synchronous transport input none

line aux 0

exec-timeout 0 0 privilege level 15

logging synchronous

line vty 0 4

login

!

end

8. Configuratia ISP2

ISP2#sh run

Building configuration…

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname ISP2

!

ip subnet-zero

ip tcp synwait-time 5

!

interface FastEthernet0/0

ip address 33.33.33.1 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

!

interface FastEthernet1/0

ip address 99.99.99.1 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

!

interface FastEthernet2/0

ip address 77.77.77.2 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

!

126

interface FastEthernet3/0

no ip address

no ip directed-broadcast

shutdown

duplex auto speed auto

!

router ospf 1

network 33.33.33.0 0.0.0.3 area 0 network 77.77.77.0 0.0.0.3 area 0 network 99.99.99.0 0.0.0.3 area 0

!

ip classless

no ip http server

!!

line con 0

exec-timeout 0 0 privilege level 15

logging synchronous transport input none

line aux 0

exec-timeout 0 0 privilege level 15

logging synchronous

line vty 0 4

login

!

end

9. Configuratia ISP3

ISP3#sh run

Building configuration…

Current configuration:

!

version 12.0

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname ISP3

!

ip subnet-zero

ip tcp synwait-time 5

!

interface FastEthernet0/0

ip address 22.22.22.1 255.255.255.252

no ip directed-broadcast

127

duplex auto

speed auto

!

interface FastEthernet1/0

ip address 88.88.88.1 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

!

interface FastEthernet2/0

ip address 99.99.99.2 255.255.255.252

no ip directed-broadcast

duplex auto speed auto

!

router ospf 1

network 22.22.22.0 0.0.0.3 area 0 network 88.88.88.0 0.0.0.3 area 0 network 99.99.99.0 0.0.0.3 area 0

!

ip classless

no ip http server

!!

line con 0

exec-timeout 0 0 privilege level 15

logging synchronous transport input none

line aux 0

exec-timeout 0 0 privilege level 15

logging synchronous

line vty 0 4

login

!

end

128

ANEXA 2

Echo-reply in tunel GRE

129

ANEXA 3

Echo-reply in tunel IPSec

130

ANEXA 4

Echo-reply in tunel GRE over IPSec

131

ANEXA 5 Site-ul SSL

<HEAD> <TITLE>

LUCRARE DE LICENTA – CONSTANTIN MANEA (HTTPS – SSL)

</TITLE>

<CENTER>

<H1> UNIVERSITATEA POLITEHNICA BUCURESTI </H1>

<H2> FACULTATEA DE ELECTRONICA, TELECOMUNICATII SI TEHNOLOGIA

INFORMATIEI </H2> <IMG SRC=./UPB.jpg>

<H3>

<P align=left> Profesor Coordonator: </P>

<P align=left> Sl.dr.ing. ADRIAN FLORIN PAUN </P>

<P align=right> Absolvent: </P>

<P align=right> CONSTANTIN MANEA </P>

</H3>

</HEAD>

Figura 1. UPB.jpg

132

ANEXA 6

Site-ul TLS

<HEAD> <TITLE>

LUCRARE DE LICENTA – CONSTANTIN MANEA (HTTPS – TLS)

</TITLE>

<CENTER>

<H1> UNIVERSITATEA POLITEHNICA BUCURESTI </H1>

<H2> FACULTATEA DE ELECTRONICA, TELECOMUNICATII SI TEHNOLOGIA

INFORMATIEI </H2> <IMG SRC=./UPB.jpg>

<H3>

<P align=left> Profesor Coordonator: </P>

<P align=left> Sl.dr.ing. ADRIAN FLORIN PAUN </P>

<P align=right> Absolvent: </P>

<P align=right> CONSTANTIN MANEA </P>

</H3>

</HEAD>

Figura 2. UPB.jpg

133

ANEXA 7

Fisierul ssl.conf

[root@CentOS-1 https-ssl]# cat /etc/httpd/conf.d/ssl.conf

#

# This is the Apache server configuration file providing SSL support. # It contains the configuration directives to instruct the server how to

# serve pages over an https connection. For detailing information about these

# directives see <URL:http://httpd.apache.org/docs/2.2/mod/mod_ssl.html>

#

# Do NOT simply read the instructions in here without understanding

# what they do. They're here only as hints or reminders. If you are unsure # consult the online docs. You have been warned.

#

LoadModule ssl_module modules/mod_ssl.so

#

# When we also provide SSL we have to listen to the # the HTTPS port in addition.

#

Listen 443

Listen 1443

##

## SSL Global Context

##

## All SSL configuration in this context applies both to ## the main server and all SSL-enabled virtual hosts.

##

# Pass Phrase Dialog:

# Configure the pass phrase gathering process.

# The filtering dialog program (`builtin' is a internal

# terminal dialog) has to provide the pass phrase on stdout.

SSLPassPhraseDialog builtin

# Inter-Process Session Cache:

# Configure the SSL Session Cache: First the mechanism

# to use and second the expiring timeout (in seconds).

SSLSessionCache shmcb:/var/cache/mod_ssl/scache(512000)

SSLSessionCacheTimeout 300

# Semaphore:

# Configure the path to the mutual exclusion semaphore the

# SSL engine uses internally for inter-process synchronization.

SSLMutex default

# Pseudo Random Number Generator (PRNG):

134

# Configure one or more sources to seed the PRNG of the

# SSL library. The seed data should be of good random quality.

# WARNING! On some platforms /dev/random blocks if not enough entropy

# is available. This means you then cannot use the /dev/random device

# because it would lead to very long connection times (as long as

# it requires to make more entropy available). But usually those

# platforms additionally provide a /dev/urandom device which doesn't # block. So, if available, use this one instead. Read the mod_ssl User # Manual for more details.

SSLRandomSeed startup file:/dev/urandom 256

SSLRandomSeed connect builtin

#SSLRandomSeed startup file:/dev/random 512 #SSLRandomSeed connect file:/dev/random 512 #SSLRandomSeed connect file:/dev/urandom 512

#

# Use "SSLCryptoDevice" to enable any supported hardware

# accelerators. Use "openssl engine -v" to list supported

# engine names. NOTE: If you enable an accelerator and the

# server does not start, consult the error logs and ensure # your accelerator is functioning properly.

#

SSLCryptoDevice builtin #SSLCryptoDevice ubsec

##

## SSL Virtual Host Context

##

#<VirtualHost _default_:443>

# General setup for the virtual host, inherited from global configuration

#DocumentRoot "/var/www/html"

#ServerName www.example.com:443

# Use separate log files for the SSL virtual host; note that LogLevel # is not inherited from httpd.conf.

ErrorLog logs/ssl_error_log

TransferLog logs/ssl_access_log

LogLevel warn

# SSL Engine Switch:

# Enable/Disable SSL for this virtual host.

SSLEngine on

# SSL Protocol support:

# List the enable protocol levels with which clients will be able to

# connect. Disable SSLv2 access by default:

#SSLProtocol all

135

# SSL Cipher Suite:

# List the ciphers that the client is permitted to negotiate. # See the mod_ssl documentation for a complete list.

#SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW

# Server Certificate:

# Point SSLCertificateFile at a PEM encoded certificate. If

# the certificate is encrypted, then you will be prompted for a

# pass phrase. Note that a kill -HUP will prompt again. A new # certificate can be generated using the genkey(1) command.

SSLCertificateFile /etc/pki/tls/http/apachecert.pem

# Server Private Key:

# If the key is not combined with the certificate, use this # directive to point at the key file. Keep in mind that if

# you've both a RSA and a DSA private key you can configure

# both in parallel (to also allow the use of DSA ciphers, etc.)

SSLCertificateKeyFile /etc/pki/tls/http/apachekey.pem

# Server Certificate Chain:

# Point SSLCertificateChainFile at a file containing the

# concatenation of PEM encoded CA certificates which form the

# certificate chain for the server certificate. Alternatively

# the referenced file can be the same as SSLCertificateFile

# when the CA certificates are directly appended to the server # certificate for convinience.

#SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt

# Certificate Authority (CA):

# Set the CA certificate verification path where to find CA # certificates for client authentication or alternatively one

# huge file containing all of them (file must be PEM encoded)

#SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt

# Client Authentication (Type):

# Client certificate verification type and depth. Types are # none, optional, require and optional_no_ca. Depth is a

# number which specifies how deeply to verify the certificate # issuer chain before deciding the certificate is not valid.

#SSLVerifyClient require

#SSLVerifyDepth 10

# Access Control:

# With SSLRequire you can do per-directory access control based

# on arbitrary complex boolean expressions containing server # variable checks and other lookup directives. The syntax is a # mixture between C and Perl. See the mod_ssl documentation # for more details.

#<Location />

#SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \

136

# and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \

# and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \

# and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \

# and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 )\

# or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/

#</Location>

# SSL Engine Options:

# Set various options for the SSL engine.

# o FakeBasicAuth:

# Translate the client X.509 into a Basic Authorisation. This means that

# the standard Auth/DBMAuth methods can be used for access control. The

# user name is the `one line' version of the client's X.509 certificate.

# Note that no password is obtained from the user. Every entry in the user # file needs this password: `xxj31ZMTZzkVA'.

# o ExportCertData:

# This exports two additional environment variables: SSL_CLIENT_CERT and

# SSL_SERVER_CERT. These contain the PEM-encoded certificates of the

# server (always existing) and the client (only existing when client # authentication is used). This can be used to import the certificates # into CGI scripts.

# o StdEnvVars:

# This exports the standard SSL/TLS related `SSL_*' environment variables.

# Per default this exportation is switched off for performance reasons, # because the extraction step is an expensive operation and is usually

# useless for serving static content. So one usually enables the # exportation for CGI and SSI requests only.

# o StrictRequire:

# This denies access when "SSLRequireSSL" or "SSLRequire" applied even

# under a "Satisfy any" situation, i.e. when it applies access is denied # and no other module can change it.

# o OptRenegotiate:

# This enables optimized SSL connection renegotiation handling when SSL # directives are used in per-directory context.

#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire

<Files ~ "\.(cgi|shtml|phtml|php3?)$">

SSLOptions +StdEnvVars

</Files>

<Directory "/var/www/cgi-bin">

SSLOptions +StdEnvVars

</Directory>

# SSL Protocol Adjustments:

# The safe and default but still SSL/TLS standard compliant shutdown

# approach is that mod_ssl sends the close notify alert but doesn't wait for

# the close notify alert from client. When you need a different shutdown

# approach you can use one of the following variables:

# o ssl-unclean-shutdown:

# This forces an unclean shutdown when the connection is closed, i.e. no

# SSL close notify alert is send or allowed to received. This violates

137

# the SSL/TLS standard but is needed for some brain-dead browsers. Use

# this when you receive I/O errors because of the standard approach where # mod_ssl sends the close notify alert.

# o ssl-accurate-shutdown:

# This forces an accurate shutdown when the connection is closed, i.e. a

# SSL close notify alert is send and mod_ssl waits for the close notify # alert of the client. This is 100% SSL/TLS standard compliant, but in

# practice often causes hanging connections with brain-dead browsers. Use

# this only for browsers where you know that their SSL implementation # works correctly.

# Notice: Most problems of broken clients are also related to the HTTP

# keep-alive facility, so you usually additionally want to disable

# keep-alive for those clients, too. Use variable "nokeepalive" for this.

# Similarly, one has to force some clients to use HTTP/1.0 to workaround

# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and # "force-response-1.0" for this.

SetEnvIf User-Agent ".*MSIE.*" \

nokeepalive ssl-unclean-shutdown \

downgrade-1.0 force-response-1.0

# Per-Server Logging:

# The home of a custom SSL log file. Use this when you want a # compact non-error SSL logfile on a virtual host basis.

CustomLog logs/ssl_request_log \

"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

#</VirtualHost>

#<VirtualHost *:443>

# SSLEngine on

# SSLProtocol SSLv3

# SSLCipherSuite HIGH:!aNULL:!MD5

# SSLCertificateFile /etc/pki/tls/http/apachecert.pem

# SSLCertificateKeyFile /etc/pki/tls/http/apachekey.pem

# DocumentRoot "/var/www/html/https-ssl"

#<Directory /var/www/html/https-ssl>

# Order allow,deny

# Allow from all

#</Directory>

#</VirtualHost>

<VirtualHost *:443>

SSLEngine on

SSLProtocol TLSv1

SSLCipherSuite HIGH:!aNULL:!MD5

SSLCertificateFile /etc/pki/tls/http/apachecert.pem

SSLCertificateKeyFile /etc/pki/tls/http/apachekey.pem

DocumentRoot "/var/www/html/https-tls"

<Directory /var/www/html/https-tls>

Order allow,deny

138

Allow from all

</Directory>

</VirtualHost>

<VirtualHost *:80>

SSLEngine off

DocumentRoot "/var/www/html/http"

<Directory /var/www/html/http>

Order allow,deny

Allow from all

</Directory>

</VirtualHost>