Analiza și protecția traficului de date într-o rețea de calculatoare [303806]

Universitatea „Politehnica” [anonimizat]-o rețea de calculatoare

Coordonator:

SL. Ing. Andy Vesa

Student: [anonimizat]

2019

ANEXA 1

ANEXA 2

Introducere

Lucrarea de diplomă a [anonimizat] 2019 și are scopul de a evidenția importanța asigurării securității rețelelor și mai ales a confidențialității datelor utilizatorilor săi. [anonimizat] o soluție de control a [anonimizat], [anonimizat].

[anonimizat], [anonimizat], tranzacții online etc. [anonimizat]/[anonimizat]. BEAST, POODLE, HeartBleed, [anonimizat]-the-middle sunt o parte infimă a atacurilor lansate de-a lungul anilor asupra rețelelor și sunt cel mai solid motiv pentru care securitatea datelor ar trebui să ocupe un loc important în preocupările organizațiilor.

Capitolul următor numit De la modelul ISO la protocolul SSL/TLS începe cu prezentarea stivei ISO, a celor șapte nivelurilor ale sale și a [anonimizat]/IP de negociere a [anonimizat], esențial înțelegerii funcționării aplicațiilor. [anonimizat]/TLS, [anonimizat]-ului web și criptarea datelor transmise între server și utilizator.

[anonimizat]. [anonimizat], 3DES, [anonimizat], cheile de criptare folosite și modul în care se realizează schimbul lor între participanții la conexiune.

Urmează capitolul Protecția comunicațiilor IP cu ajutorul soluției integrate F5 – Cisco în care sunt detaliate două produse aparținând celor doi furnizori F5 și Cisco. F5 [anonimizat]/[anonimizat]. Cele două permit organizațiilor gestionarea inteligentă a [anonimizat]. Fără vizibilitatea asupra SSL este imposibil de identificat și prevenit amenințările de masă.

Această secțiune a lucrării este esențială pentru înțelegerea scopului și modului de implementare a rețelei utilizate în partea practică a proiectului de diplomă. [anonimizat]nile virtuale adiacente, utilizate pentru managementul și configurarea celor două produse dar și pentru simularea traficului. Spre exemplu, configurarea firewall-ului Cisco este făcută exclusiv din Firepower Management Center, iar serviciul de TAP și utilizatorul rețelei sunt simulate prin două mașini virtuale Ubuntu. Toate sunt abordate în acest capitol.

Capitolul cinci, numit Vizibilitatea SSL cu ajutorul integrării tehnologiilor F5 SSL Orchestrator și Cisco Firepower Threat Defense conține înlănțuirea logică și detaliată a pașilor urmați pentru demonstrarea modului în care se obține vizibilitatea asupra traficului criptat. Începe prin prezentarea modului în care au fost instalate mașinile virtuale în ESXi, conexiunile dintre ele, adresarea IP, toate sintetizate într-o diagramă sugestivă. Configurarea FirePower Threat Defense și Firepower Management Center sunt descrise în prima parte a acestui capitol, cea de-a doua este dedicată mașinilor Ubuntu, iar a treia include setarea BIG-IP și configurarea lanțului de servicii de securitate din SSL Orchestrator. Ultimul subcapitol este numit și include Testarea soluției implementate.

Finalul proiectului de diplomă cuprinde concluziile și referințele bibliografice de rigoare.

Argumentarea necesității protejării rețelelor

1.1. Securitatea în Internet

Cât de sigure sunt datele transmise în Internet? Cât de vulnerabile sunt datele personale în fața hackerilor? Chiar și celor mai experimentați programatori le este greu să răspundă acestor întrebări. Am auzit de algoritmi de criptare standard utilizați pentru protecția datelor, cum sunt RSA și DSA și despre faptul că standardul guvernului American de Criptare a Datelor (DES- Data Encryption Standard) a fost înlocuit cu Standardul Avansat de Criptare (AES – Advanced Ecryption Standard). De asemenea, cu toții știm despre iconița din browsere care indică faptul că sesiunea este protejată de HTTPS (Hyper Transfer Protocol Secure). Însă în același timp am auzit de atacuri precum man-in-the-middle, side-channel și multe altele care ne compromit securitatea. Oricine cu un browser web a fost suprins de mesaje de genul “Acest site nu este sigur – cerificatul a expirat sau a fost emis de o autoritate de cerificare în care nu aveți încredere” ("This site's security cannot be trusted – either the certificate has expired, or it was issued by a certificate authority you have chosen not to trust."). Primul pas în protecția datelor noastre este înțelegerea pericolelor la care ne expunem dar și a modului în care ele funcționează pentru a ne putea proteja.

Când aplicațiile sunt compromise, impactul aspura organizației poate adopta diferite forme. Atacurile de tip Denial of Service au provocat cele mai mai probleme pentru organizații, 81% din cei care au răspuns studiului realizat de F5 Labs considerându-l de nivel 7 ca impact, pe o scară de la 1 la 10. Breșele de securitate privind informațiile sensibile sau confidențiale (precum proprietatea intelectuală sau schimburile comerciale) au ocupat al doilea loc, 77% din participanți aprecindu-l tot cu nota 7 din 10. În final, 64% au catalogat pierderea informațiilor de identitate ale propriilor clienți și angajați tot cu nota 7 din 10.

În timp ce 63% din participanții la studiu au zis ca folosesc întotdeauna SSL/TLS pentru aplicațiile lor web, doar 46% au spus ca folosesc criptarea SSL/TLS pentru majoritatea aplicațiilor lor (76-100%). Cu atât de multe standarde de criptare a nivelului transport (cum sunt SSL si TLS 1.0) încă utilizate, chiar dacă au fost retrase ca fiind nesigure, există un risc continuu de expunere la atacuri de tipul man-in-the-middle sau eavesdroppin. În plus, 47% din organizații au declarat că folosesc certificate self-signed ceea ce reduce încrederea în aplicațiile lor. Organizațiile ar trebui să se asigure că toate aplicațiile rulează niveluri corespunzătoare de criptare și că au certificate semnate de o a treia parte de încredere.

Odată cu intensificarea utilizării traficului criptat, infrastructura tradițională bazată pe firewall-uri, sisteme de protecție a accesului ilegal și celor de detecție a intruziunilor au început să fie depășite, întrucât aceste echipamente sunt oarbe dacă nu știu ce fel trafic le tranzitează.

1.2 Vulnerabilități și atacuri asupra SSL/TLS

În ultimii ani am experimentat o gamă variată de atacuri asupra mecanimelor SSL/TLS. Protocolul Transport Layer Security (TLS) asigură integritatea datelor transmise între două entități (client și server) și autentificarea comunicațiilor dintre acestea. Ca oricare altă tehnologie, protocoalele de criptare Secure Socket Layer și Transport Layer Security au avut și ele parte de defecte.

Aplicația BEAST (Browser Exploit Against SSL/TLS) a fost creată de Thai Duong și Juliano Rizzo și a fost prezentată la Conferința de Securitate EkoParty din 2011. Scopul său este compromiterea conexiunilor SSL/TLS folosite zilnic de milioane de browsere web.

BEAST se bazează pe vulnerabilitatea de tip man-in-the-middle care compromite cookie-urile SSL/TLS folosite de HTTPS, permițând accesarea neautorizată a conversațiilor criptate.

Pentru a crește viteza de transmitere a datelor criptate, pachetele sunt transmise folosind sistemul de criptare bazat pe blocuri (CBC- cypher-block chaining), în care fiecare bloc este criptat folosind informații din blocul precedent. Înainte de criptare, fiecare bloc este supus unei operații XOR cu un factor de inițializare ales aleatoriu. Astfel un atacator care vede traficul criptat poate prevede factorul de inițializare următor pentru că locația cookie-ului este previzibilă. Dacă atacatorul poate ghici mesajul în clar, poate presupune cookie-ul și poate vedea dacă cifrul se potrivește.

Acest atac are câteva limitări: atacatorul trebuie să fie în aceeași rețea pentru a lansa un atac de tip man-in-the-middle, trebuie să modifice traficul pentru a compara rezultatele ceea ce duce la necesitatea lansării mai multor cereri și astfel atacatorul poate ghici blocurile pe rând.

Aceasta este o vulnerabilitate a cifrurilor bloc care utilizează sistemul CBC, a fost identificată în TLS 1.0, dar a fost eliminată din următoarele versiuni.

Atacul POODLE (Padding Oracle On Downgraded Legacy Ecryption) a fost publicat în octombrie 2014. Acest tip de atac se bazează pe conexiunile criptate care eșuează și în urmă cărora serverele vor folosi protocoale mai vechi, cum ar SSL 3.0. Atacatorul determină apariția unei erori de conexiune și forțează browser-ul să utilizeze SSL 3.0. Ulterior este liber să profite de faptul că SSL 3.0 permite modificarea datelor de la finalul cifrului bloc, diminuând treptat securitatea cifrului. Pentru rularea atacului este necesar ca atacatorul să fie capabil să controleze conexiunea SSL de pe partea de client și trebuie să aibă vizibilitate asupra ciphertext-ului rezultat. Cel mai întâlnit mod de a îndeplini aceste condiții este lansarea în prealabil a unui atac man-in-the-middle.

Heartbleed este numele unei erori a librării de funcții criptografice OpenSSL care afectează protocoalele SSL/TLS și permite furtul de informații protejate. Permite atacatorilor să monitorizeze comunicațiile, compromite conținutul real al traficului, cheile de criptare și chiar să extragă date private despre utilizatori sau furnizorii de servicii de internet.

Comportamentul său constă în faptul că un calculator trimitea o cerere compromisă de heartbeet cu un conținut mic dar cu un număr mare în câmpul de lungime pentru a determina un răspuns al serverului care să permită atacatorilor să citească până la 64K octeți din memoria serverului, memorie care fusese probabil utilizată anterior de SSL. Spre exemplu, atunci când citim mailul Yahoo dar pentru o lungă perioadă de timp nu am făcut nimic pentru a încărca mai multă informație, browserul poate să trimită un mesaj către servele Yahoo în care să anunțe “Acesta este un mesaj de 40kb pe care îl vei primi. Retrimite-mi-l!”. Când Yahoo primește mesajul, alocă o regiune în memoria fizică unde, pe baza heartbeet-ului primit, reține că mesajul are o lungime de 40kb. Apoi reține datele criptate în buffer, le citește și le retrimite către browser. Acesta este comportamentul normal, însă în cazul vulnerabilității Heartbleed, calculatorul care a primit cererea heartbeat nu se asigură că cererea primită are exact lungimea anunțată. Astfel, dacă cererea a fost anunțată ca având 40kb, dar are doar 20kb, atunci calculatorul alocă 40kb de memorie, stochează cei 20kb primiți și trimite înapoi cei 20kb plus orice se întâmplă să fie în următorii 20kb de memorie. Cei din urmă pot reprezenta chei de criptare, date personale, informații clasificate etc.

Soluția a fost un patch scris în martie 2014 de Bodo Moeller și Adam Langley de la Google prin care se repara bugul. Cisco Systems și Juniper Networks au confirmat că și echipamentele lor au fost afectate de vulnerabilitatea Heartbleed.

Acestea sunt o parte infimă a atacurilor lansate zi de zi, unele cu succes, altele blocate de măsurile de securitate implementate.

Organizațiile trebuie să își protejeze bunurile critice de amenințările care provin atât din exterior cât și din interior, însă majoritatea traficului fiind criptat, controalele de securitate existente nu mai au capabilitatea de a decripta la nivelul necesar inspecției transmiunilor și protecției punctelor vulnerabile.

Preocupările legate de confidențialitate au generat o creștere a traficului criptat, 80% din paginile web fiind acum criptate SSL/TLS. Această creștere reprezintă o provocare întrucât atacatorii ascund diverse amenințări în traficul criptat și utilizează canale cifrate pentru a evita detectarea lor pe timpul transmiterii datelor. Ei selectează cifruri specifice bazându-se pe lacunele cunoscute ale produselor de securitate pentru a ocoli sau forța criptarea și decriptarea. Majoritatea organizațiilor nu dispun de un control centralizat pentru implementarea politicilor de decriptare de-a lungul dispozitivelor de inspecție întâlnite în lanțul de securitate. Echipele de securitate trebuie să recurgă la dispozitive intermediare sau la configurații manuale pentru a asigura o inspecție satisfăcătoare în lanțul de securitate, ceea ce conduce la creșterea latenței, complexității și riscurilor.

De la modelul ISO la protocolul SSL/TLS

Secure Socket Layer (SSL) protejează zi de zi milioane de date transmise pe internet, în special pe timpul tranzacțiilor online sau când sunt transmise informații care trebuie să rămână confidențiale. Utilizatorii au ajuns să asocieze securitatea lor cu iconița sub formă de lacăt specifică site-urilor web securizate SSL sau al adresei de culoare verde specifică site-urilor web protejate cu Extended Validation SSL. În plus, site-urile protejate cu SSL încep cu https și nu cu http.

Înainte de a oferi soluții problemei vizibilității SSL/TLS este importantă întelegerea acestui protocol complex, de aceea capitolul acesta oferă o viziune mai amplă asupra sa.

2.1 Modelul ISO

Modelul de referință OSI (Open System Interconnection Basic Reference Model) este o stivă conceptuală de protocoale organizată ierarhic pe șapte niveluri (layer) diferite și descrie funcționarea unui rețele independent de infrastructura pe care se sprijină. Fiecare nivel este gândit că având o sarcină bine conturată și poate comunica doar cu nivelurile adiacente. Cele șapte niveluri sunt: Aplicație (nivelul 7, superior), Prezentare, Sesiune, Transport, Rețea, Legătură de date, Fizic (nivelul 1, inferior).

Fig. 1 Modelul ISO

2.1.1 Nivelul Aplicație

Acesta este nivelul superior al stivei ISO, oferă cadrul necesar rulării aplicațiilor și gestionează comunicația între acestea. Nivelul Aplicație nu definește aplicația în sine, ci serviciile necesare funcționării sale, este o interfață care stă între software și rețea. Spre exemplu, în cazul protocolului aplicație HTTP, definește modalitatea prin care serverul web poate extrage conținutul unei pagini web de pe un server web.

2.1.2 Nivelul Prezentare

La acest nivel se negociază formatul datelor, cum ar fi textul ASCII sau al tipurilor de imagine, pentru a fi prezentate nivelului aplicație. Poate fi privit ca un translator pentru rețea, întrucât face conversia dintr-un format utilizat de nivelul aplicație într-un format cunoscut de stație și invers.

2.1.3 Nivelul Sesiune

La acest nivel se realizează gruparea mesajelor bidirecționale în sesiuni, pentru controlul comunicației între aplicații. Stabilește, menține, gestionează și închide conexiuni (sesiuni) între aplicații.

2.1.4 Nivelul Transport

Asemănător nivelului transport din stiva TCP/IP, asigură integritatea transmisiunilor prin faptul că protocoalele de la acest nivel sunt capabile să detecteze pachetele pierdute pe parcurs și să genereze automat o cerere de retransmitere. La baza acestei solicitări stă funcția nivelului transport de a segmenta și numerota pachetele, facilitându-i echipamentului destinație identificarea pachetelor pierdute sau a celor care au urmat căi diferite, să le ordoneze și eventual să emită o cerere de retransmitere a pachetelor lipsă.

2.1.5 Nivelul Rețea (IP)

Ca și la nivelul Internet al stivei TCP/IP, aici se realizează adresarea logică și rutarea, funcționează protocoale de rutare și sunt create circuite logice numite și circuite virtuale între echipamentele sursă și cele destinație. Circuitele asigură fiecărui pachet o rută pentru a ajunge la destinație. Este realizată gestionarea erorilor proprii, a secvențierii pachetelor și controlul congestiilor apărute.

Secvențierea este necesară pentru că fiecare nivel influențează și mărimea pachetelor transmise.

2.1.6 Nivelul legatură de date

Ca și nivelul cu același nume al stivei TCP/IP, definește protocoalele de transmitere a datelor printr-o legătură fizică. Se ocupă de adresarea fizică, topologia rețelei, acesul la rețea, sesizarea erorilor, transportul cadrelor cerute și controlul fluxului.

2.1.7 Nivelul fizic

Acesta este nivelul de bază, unde sunt definite caracteristicile fizice ale mediului de transmisie, viteza de transmisie, specificațiile mecanice, electrice, procedurale pentru menținerea legăturii fizice între sistemele finale.

2.1.8 Protocoale și tehnologii specifice stivei ISO

În tabelul de mai jos poate fi observată asocierea fiecărui nivel ale stivei ISO cu o parte din protocoalele specifice.

Tabel. 1 Asocierea nivelului ISO cu protocoalele și funcțiile specifice

2.3 Ce sunt secure sockets?

Internetul este o rețea de tip comutație de pachete. Acest lucru înseamnă că pentru ca două host-uri să comunice, ele trebuie să încapsuleze datele, adăugând fiecărui pachet adresa destinație și apoi să le trimită către un router. Router-ul analizează adresa destinație și ruteaza pachetele fie către host-ul țintă, fie către un alt router, pe care îl consideră mai aproape de destinație. Protocolul IP descrie modul în care este realizată încapsularea și cum sunt adresele atașate în header-ul pachetelor.

Un pachet poate și probabil va trece prin mai multe routere între emițător și destinatar. Conținutul pachetelor este sensibil – o parolă, un card de credit, numărul facturii-, iar emițătorul, cu siguranță, ar prefera ca doar destinatarul să poată citi conținutul și nici un alt echipamnet de pe cale. Chiar dacă emițătorul are încredere în rutere și în operatorii săi de internet, echipamentele pot fi compromise de atacatori și păcălite să trimită traficul original către o altă destinație. Pentru a afla prin câte echipamente diferite trece un pachet între propriul calculator și un server poate fi folosită facilitatea traceroute care există pe orice calculator capabil să se conecteze la internet și să listeze hop-urile prin care trece pachetul.

Conexiunea între un emițător și un receptor se numește priză (socket). Când un host, clientul, este pregătit să stabiliească o conexiune cu un altul, serverul, trimite un pachet de sincronizare (SYN – synchronize) către server. Dacă cel din urmă acceptă conexiunea, va răspunde cu un pachet de sincronizare și confirmare (SYN, ACK – synchronize and acknowledge). În final clientul anunță că a primit confirmarea cu un pachet ACK și astfel ambele părți sunt de acord cu realizarea conexiunii. Procesul de schimbare a celor trei pachete se numește TCP three-way handshake și este ilustrat în figura de mai jos. Conexiunea este asociată unei perechi de numere: port sursă, port destinație, atașate fiecărui pachet. Având în vedere că serverul ascultă întodeauna și așteaptă realizarea de conexiuni, trebuie să își anunțe porturile destinație. Depinde de fiecare protocol în parte cum se realizează acest lucru. Există protocoale care au asociate numere bine stabilite, cum ar fi SSH: 22, FTP: 20, 21, telnet:23, HTTPS:443 etc.

Fig. 2 Procesul de negociere TCP

În general, protocoalele TCP și IP sunt implementate împreună și sunt cunoscute ca TCP/IP. Un socket (IP: port) se referă la o conexiune TCP stabilită, ambele părți, atât serverul cât și clientul având câte un socket după ce procesul de TCP three-way handshake este complet. Dacă oricare dintre părți transmite date printr-un socket, TCP se asigură că cealaltă parte primește pachetele în ordinea în care au fost trimise. Așa cum solicită protocolul IP, orice router intermediar va vedea aceste date.

2.4 Protocolul HTTP

HTTP sau HyperTest Transport Protocol este protocolul standard pentru comunicațiile web. Clienții web stabilesc socket-uri cu serverele web. HTTP folosește un portul destinație predefinit 80. După ce a fost stabilit socket-ul, conform regulilor stabilite prin protocolul HTTP, browserul web începe să solicite documente. HTTP a început ca un protocol simplu în care clientul genera comanda GET și o descriere a ceea ce dorește să primească, serverul răspundea fie cu ceea ce a cerut clientul, fie cu un mesaj de eroare în care se expunea motivul pentru care nu au fost returnate cele solicitate. În oricare dintre cazuri, apoi se închidea socket-ul. Dacă un alt client solicita alt document, crea un nou socket și solicita alt document. De-a lungul anilor, HTTP a fost regândit pentru a optimiza banda, viteza și capabilitățile de securitate.

HTTP a fost totodată și primul stimulent al SSL-ului. Inițial, SSL nu funcționa independent, a fost creat ca un plus pentru HTTP, și denumit HTTPS. Chiar dacă ulterior a fost detașat de HTTP, unele dintre funcționalitățile sale au fost optimizate pentru HTTP.

2.5 Protocolul SSL/TLS

SSL sau Secure Socket Layer a fost inițial dezvoltat de Netscape ca o modalitate de a folosi la acea vreme browser-ele pentru e-commerce. Deși a fost standardizat și redenumit ca Transport Layer Security (TLS), numele de SSL este mai ușor de recunoscut și uneori descrie mai bine ce face și cum poate fi utilizat. După ce a fost stabilit un socket între client și server, SSL definește un al doilea process de handshake care poate fi folosit pentru stabilirea unui canal securizat peste nivelul nesecurizat TCP.

Primul apărut a fost SSLv2, versiunea 1 nu a existat niciodată, apoi Netscape a lansat SSLv3 și l-a vândut IETF care imediat l-a numit TLS1.0 și i-a publicat primele specificații oficiale în RFC 2246. În 2006, TLS 1.1 era prezentat în RFC 4346, în 2008 a apărut TLS1.2 și a fost descris în RFC 5246, cel mai recent este TLS1.3, specificat în RFC 8446.

Pe scurt SSL criptează traficul pe care protocoalele de la nivelurile superioare ale stivei ISO le generează, astfel încât acestea să nu poată fi interceptate de posibili atacatori. De asemenea, autentifică conexiunea pentru ca ambele părți să fie sigure că transmit date celor cu care intenționează să comunice.

SSL este un protocol de securitate. Protocoalele descriu modul în care algoritmii trebuie utilizați. În acest caz, protocolul SSL determină variabilele criptării atât pentru datele transmise cât și pentru mediul de transmisie. Toate browserele au capabilitatea de a interacționa cu servere web securizate, utilizând protocolul SSL. Totuși, și browser-ul și server-ul au nevoie de un certificat SSL pentru a putea stabili o conexiune.

2.5.1 Ce sunt certificatele SSL și cum funcționează?

Unul dintre cele mai importante aspecte ale afacerilor online și nu numai îl reprezintă crearea unui mediu de încredere în care potențialii clienți să simtă că datele lor sunt în siguranță.

Certificatele digitale sunt credențiale electronice utilizate pentru a identifica în mediul online calculatoare, indivizi și alte entități din rețea. Certificatele digitale funcționează asemănător cărților de identitate, pașapoartelor sau permiselor de conducere. În general conțin identitatea deținătorului și cheia sa publică. Sunt emise de o Autoritate de Certificare care trebuie să valideze identitatea deținătorului înainte ca certificatul să fie emis și ulterior folosit. Cel mai des sunt utilizate pentru afacerile care necesită autentificare, criptare și semnare digitală, dar nu numai.

Certificatul poate avea una din următoarele patru întrebuințări:

Criptare. Un certificat emis în acest scop conține chei pentru criptare și decriptare.

Semnătură. Certificatul conține chei de criptare doar pentru semnarea datelor.

Semnătură și criptare. Certificatul poate îndeplini toate funcțiile, incluzând criptarea și decriptarea datelor, logarea inițială sau semnarea digitală.

Semnatură și logare cu smartcard. Un astfel de certificat este destinat logării inițiale cu un smartcard și semnarea digitală a datelor, nu poate fi utilizat pentru criptarea datelor.

SSL este probabil primul protocol care a utilizat certificatele digitale. Astăzi sunt larg răspândite, fiind utilizate oricând este nevoie de criptare și semnare. Certificatele SSL permit realizarea de conexiuni securizate, prin autentificarea identității site-ului web și criptarea datelor transmise între server și utilizator.

O Autoritate de Certificare eliberează certificate digitale care conțin cheia publică și identitatea deținătorului, cheia privată asociată nu este făcută publică, ea fiind păstrată de utilizatorul care a generat perechea de chei. Responsabilitatea Autorității este să verifice credențialele aplicantului astfel încât utilizatorii și părțile implicate să aibă încredere în informațiile certificatului emis de aceasta. În acest sens este utilizată o varietate de standarde și se fac numeroase teste.

Dacă utilizatorul are încredere în AC și poate verifica semnătura acesteia, atunci poate verifica și că o anumită cheie publică aparține într-adevăr celui pentru care a fost emis certificatul.

Pentru a obținte un certificat pentru un server, este necesară generarea unei perechi de chei și apoi a unui CSR (Certificate Signing Request). CSR-ul conține cheia publică și identitatea deținătorului într-un format potrivit pentru a fi trimis către AC pentru a obține certificatul.

Fig. 3 Generarea certificatului digital

CSR-ul este trimis către Autoritatea de Certificare care crează o structură de date care să se potrivească cheii private, fără a compromite cheia în sine. Certificatul este asociat unui lanț de certificate numit și lanț de încredere, în care este cuprins un număr de certificate direct proporțional cu structura ierarhică a AC-ului. Certificatul solicitantului este semnat de o Autoritatea emițătoare care la rândul său este semnat de Autoritatea de Certificare Rădăcină (Root CA). Certificatul radăcinei este semnat de Autoritatea în sine, iar browser-ul trebuie să aibă încredere în ea.

Odată primit certificatul SSL, se instalează pe server alături de un certificat intermediar prin care se certifică credibilitatea în certificatul SSL prin corelarea sa cu certificatul Autorității de Certificare. Instrucțiunile de instalare și testare ale certificatului sunt diferite în funcție de server.

Cea mai importantă parte a certificatului SSL este faptul că este semnat de o Autoritate de Cerificare de încredere. Oricine poate semna un certificat, doar că browserele vor avea încredere doar în certificatele care vin de la organizațiile aflate pe lista lor de Autorități de Certificare de încredere. Browser-ele vin cu o lista preinstalată de AC-uri cunoscute ca Trusted Root CA store. Pentru a fi adăugate în Trusted Root CA store și să devină o Autoritate de Certificare, o companie trebuie să fie conformă cu standardele de securitate și autenticitate stabilite de browsere.

Un certificat SSL eliberat de o AC unei organizații și domeniului său, verifică faptul că o a treia entitate a confirmat identitatea acelei organizații. Din moment ce browserul are încredere în AC, browserul va avea încredere și în identitatea organizației. Browserul poate astfel să îi arate utilizatorului că un site web este sigur și utilizatorul la rândul să să se simtă în siguranță și chiar să introducă informații confidențiale. Aplicația sau clientul trebuie să aibă certificatul fiecărei Autorități de Certificare din lanț, începând de la Autoritatea emitentă până la cea rădăcină.

2.5.2 Cum crează un certificat SSL o conexiune sigură?

Când un browser încearcă să acceseze un site care este securizat SSL, browserul și serverul web stabilesc o conexiune SSL utilizând un process numit SSL handshake. Acest proces este transparent pentru utilizator.

În principiu sunt utilizate trei chei pentru stabilirea unei sesiuni SSL: una publică, una privată și una de sesiune. Orice este criptat cu cheia publică poate fi decriptat cu cheia privată și invers.

Deoarece procesul de criptare și decriptare cu cheile privată, respectiv publică necesită multă putere de procesare, ele sunt utilizate doar în procesul de SSL handshake pentru a crea o cheie de sesiune simetrică. După ce sesiunea securizată a fost stabilită, cheia de sesiune va fi utilizată pentru a securiza întreaga transmisiune de date.

Fig. 4 Conexiunea browser web- server web

Browserul se conectează la serverul web securizat cu SSL (https). Browserul solicită serverului să se autentifice (pasul 1). Serverul îi trimite o copie a certificatului SSL propriu, incluzând cheia sa publică (pasul 2).

Browserul compară certificatul rădăcină cu intrările din lista sa de AC-uri de încredere și dacă certificatul este valabil, nerevocat și rubrica Common Name este validă pentru site-ul în cauză. Dacă browserul are încredere în certificat, crează, criptează și trimite înapoi o cheie simetrică de sesiune utilizând cheia publică a serverului (pasul 3).)

Serverul decriptează cheia simetrică de sesiune utilizând cheia sa privată și trimite înapoi un mesaj de luare la cunoștință (acknowledgement) criptat cu cheia de sesiune, pentru începerea transmisiunii criptate (pasul 4).

Acum, atât serverul cât și browserul criptează toate transmisiunile cu cheia de sesiune (pasul 5).

Protectie împotriva atacatorilor cu ajutorul criptării

3.1 Procesul de criptare

Criptarea se referă la procesul de transformare a conținutului unui mesaj în clar într-un format codat care să poate fi descifrat doar de un destinatar autorizat, procesul invers se numește decriptare. Funcția matematică cu care se realizează cele două procese se numește algoritm de criptare și folosește o cheie de criptare care poate fi un text sau un număr. Dacă unui text îi este aplicat același algoritm dar o cheie diferită se obțin două texte codate diferit. Așadar, este necesară modificarea într-un mod reversibil astfel încât cel care deține cheia să îl poată descifra corect, totul poate fi privit că fiind un lacăt care poate fi deschis doar cu o anumită cheie.

Când sunt folosite calculatoare pentru criptografie, mesajele și cheile sunt niște numere. Mesajul este convertit într-un șir de numere, combinate cu o cheie numerică într-un mod anume în funcție de algoritmul de criptare. Astfel, un atacator fără cheie poate încerca toate combinațiile de chei până când cheia corectă este aflată. Totuși pentru a-și da seama că a folosit combinația perfectă, atacatorul trebuie să știe la ce să se aștepte să găsească în conținutul mesajului.

Referitor la cazul în care avem trafic HTTP, primele trei caractere ale primei cereri este foarte posibil să fie GET, ceea ce simplifică munca atacatorului care poate aplica o cheie de criptare și dacă primele caractere sunt GET atunci a găsit soluția, dacă nu, trece mai departe.

Acest tip de atac este un o criptanaliză prin forță brută deoarece constă în parcurgerea tuturor cheilor posibile. Pentru a rezista unor astfel de atacuri, cheile trebuie să fie suficient de lungi și algoritmul să accepte o gama largă de posibile chei astfel încât atacatorul să trebuiască să încerce de foarte multe ori înainte de a găsi combinația corectă. Nu există o soluție anume pentru atacurile brute force, ceea ce trebuie făcut este întârzierea cât mai îndelungată a atacatorului de a găsi combinația necesară.

3.2 Algoritmi de criptare

Există două mari clase de algoritmi – cu chei simetrice și cu chei publice, diferența între ele făcându-se la nivelul gestionării cheilor la criptare și la decriptare. Aceștia pot păstra securitatea informațiilor de-a lungul unei comunicații, totuși s-a demonstrat că nici un algoritm nu este infailibil și că mai devreme sau mai târziu acesta poate fi spart.

Un alt criteriu pe baza căruia se poate face departajarea între algoritmii de criptare este după felul în care procesează textul la criptare și la decriptare. Dacă textul în clar este împărțit în blocuri de lungime fixă și apoi criptate pe rând, algoritmii se numesc cifruri bloc. Pentru cazurile în care textul în clar nu este multiplu întreg de lungimea blocului, se completează blocul cu caractere până la lugimea folosită. Acest proces se numește padding (eng. – a captusi), iar cea mai simplă metodă este aceea a completării cu caractere zero sau spații. Modurile de operare ale cifrurilor bloc sunt ECB (electronic code block) și CBC (chipher block chaining).

Pe lângă cifrurile bloc, mai sunt și cifrurile stream care cripteaza mesaje folosind blocuri de un caracter sau chiar de un bit lungime.

3.3 Criptarea simetrică

În cazul criptării simetrice este utilizată aceeași cheie și pentru criptare și pentru decriptare, aceasta și algoritmul fiind selectate și cunoscute în prealabil de ambele părți, de asemenea în unele cazuri operațiunile de decriptare sunt aceleași ca la criptare doar că în ordine inversă, alteori algoritmul de decriptare este diferit. În toate cazurile, emițătorul și receptorul trebuie să decidă ce cheie vor folosi înainte ca orice transmisiune criptată să aibă loc. Schimbul de chei tinde să fie cea mai dificilă parte, deoarece nu întotdeauna acestea pot fi transmise în mod sigur.

3.3.1 Algoritmi de criptare DES

Standardul de Criptare a Datelor (Data Encryption Standard) este o metodă de criptare dezvoltată de IBM sub numele de Lucifer și ulterior adoptată de NSA sub numele actual, între anii 1973-1974. A fost folosit ca standard federal de procesare a informațiilor în Statele Unite ale Americii începând cu 1976, fiind primul algoritm public de criptare. Deși DES este astăzi considerat nesigur încă are o arie largă de utilizare și reprezintă un punct de referință în studiul algoritmilor de criptare simetrici.

DES este un algoritm de criptare pe blocuri ce acționează asupra grupurilor de 64 biți pe care le criptează cu ajutorul unei chei de 64 de biți din care doar 56 sunt folosiți, restul fiind utilizați ca biți de paritate.Fiind aplicat asupra unor blocuri, acesta este generic denumit algoritm de tip ECB (Electronic Code Book). La baza procesului stau o serie de permutări fixe – înlocuirea bit-ului 34 cu bitul 28, apoi bitul 28 cu bitul 17 și tot așa – rotații și XOR-uri, în total fiind un număr de 16 pași de procesare. Sursa securității sale provine de la ceea ce standardul numește cutiile S (S boxes) care presupun că 6 biți de intrare devin 4 biți de ieșire, dar nereversibili fără cheie. Fără ele, cifrul ar fi liniar și ușor de spart.

Problema care apare odată cu utilizarea DES este că două blocuri identice de text, criptate cu aceeași cheie, produc același output, ceea ce facilitează accesul la date al posibililor atacatori.

Cu suficiente resurse, printr-un atac brute force, DES poate fi spart, motiv pentru care s-a evidențiat necesitatea unui algoritm care să-l înlocuiască. În 1999, distributed.net a spart DES în 39 de zile, de atunci și până acum Frontier Foundation’s Deep Crack a reușit să reducă acest timp la 22 de ore. La sfârșitul anilor 1980, au început să apară și alți algoritmi simetrici precum Blowfish, SAFER, FEAL, NewDES, RC5, mulți dintre ei păstrând blocul de 64 de biți și cheile de 64 sau 128 biți.

În cazul DES, soluția împotriva atacurilor de tip forță brută și totodată a păstrării aloritmului de bază, a fost extinderea spațiului dedicat cheilor. Pe aceste considerente a apărut 3DES, numit și algoritmul Triplu DES.

3.3.2 Aloritmul de criptare 3DES

Triplu DES este tot un algoritm de criptare simetric și se bazează pe algoritmul DES doar că folosește o cheie de 168 de biți. Este denumit așa deoarece își împarte cheile în trei blocuri de câte 56 de biți și repetă de trei ori pașii pe care îi realizează DES. Funcționează după regula: DES (k3; DES (k2; DES (k1; M))), unde M este blocul în clar, iar k1, k2, și k3 sunt cheile DES. 3DES criptează cu prima cheie, decripteaza cu a doua ceea ce a fost criptat cu prima și apoi recriptează cu următoarea. Există mai multe variante de implementare și anume: cu toate cheile diferite, cu prima și ultima cheie la fel sau cea în care toate cheile sunt la fel, cea mai sigură rămâne prima enunțată.

A fost unul dintre cei mai utilizați algoritmi de criptare până la apariția AES, fiind folosit de nume precum Microsoft Office, Mozilla Firefox și sistemul de plăți EMV.

NIST (National Institute of Standards and Technology) a propus ca toate formele de 3DES să fie considerate nesigure din 2023.

3.3.3 Algoritmul de criptare AES

Rijndael este o familie de cifruri pe bază de blocuri pentru criptarea simetrică, dezvoltată de criptografii belgieni Vincent Rijmen și Joen Daemen. A fost prezentată la o competiție organizată de NIST pentru selectarea unui standard de criptare avansat (AES) care să înlocuiască 3DES. În 2001, Rijndael a câștigat concursul și versiunile de 128, 192 și 256 de biți ale Rijndael au fost oficial alese ca standard avansat de criptare.

Algoritmul defint de Rijndael permite criptarea pe blocuri în care lungimea blocului și a cheii pot fi independente, de 128, 192 sau 256 de biți, dar restricționează lungimea blocului care trebuie să fie de 128 de biți. Așadar, atât intrarea cât și ieșirea algoritmilor de criptare va fi un bloc de 128 de biți.

Faza de criptare poate fi împărțită în trei: etapa inițială, principală și finală. Toate etapele utilizează aceleași sub-operații în diferite combinații. Etapa inițială cuprinde: AddRoundKey, etapa principală: SubBytes, ShiftRows, MixColumns, AddRoundKey, iar cea finală: SubBytes, ShiftRows, AddRoundKey. Cele trei etape sunt repetate de un anumit număr de ori în funcție de varianta de AES: aes-128 repetă de 9 ori etapa principala, AES-192 de 11 iar AES-256 de 13. Față de protocolul DES, decriptarea nu se face la fel cum s-a făcut criptarea.

Încă din 2003, toate cele trei variante ale algoritmului Rijndael sunt considerate suficient de sigure încât să fie folosite pentru criptarea informațiilor guvernamentale americane, pentru cele TOP SECRET este folosit doar AES-256.

Există un număr foarte mare de algoritmi de criptare pe bază de blocuri. Doi algoritmi amintiți în standardul TLS sunt IDEA și RC2, însă odată cu TLS1.2, nu mai sunt considerați singuri. AES nu e specificat în RFC 2246 deoarece acesta nu fusese încă numit de NIST că fiind noul standard. RFC3268 publicat în 2002 adaugă și AES pentru SSL/TLS. De departe 3DES și AES rămân algoritmii cei mai utilizați în SSL/TLS.

3.4 Criptarea asimetrica – algoritmul RSA

Criptarea asimetrică este o formă mai complicată a celei simetrice. Inițial schema cheilor publice a apărut că soluție pentru securizarea schimbului de chei. Procesul a fost publicat în 1977 de Diffie și Hellman.

Algoritmii de criptare cu chei asimetrice sau publice folosesc două chei diferite pentru criptare și decriptare, una dintre ele este privată, iar cealaltă este publică, una este folosită pentru codarea mesajului în clar, iar cealaltă pentru decriptarea mesajului codat. Cele două chei sunt corelate din punct de vedere matematic, nu există posibilitatea criptării și decriptării mesajului doar cu una dintre ele. Așa cum le este și denumirea, cheia privată rămâne secretă, iar cheia publică poate fi cunoscută și de alte entități fără a se compromite securitatea comunicației. Generarea ambelor chei este simplă, însă găsirea cheii private asociate pornind de la cheia publică este aproape imposibilă.

Din aceste considerente, algoritmii de criptare asimetrici nu impun utilizarea unui canal de comunicație securizat între parteneri, ca în cazul celor simetrici unde este necesar. Considerând că cei doi participanți în transmiterea mesajelor sunt Ana și Matei, Ana va cripta mesajul folosind cheia publică a lui Matei, iar Matei va fi singurul care va putea decripta mesajul, folosindu-și cheia privată.

Algoritmii asimetrici pot fi folosiți și ca metodă de verificare a autenticității unui mesaj, utilizând semnătură digitală care poate fi creată folosind cheia privată și ulterior verificată de către oricine deține cheia publică.

Primul algoritm cu chei publice gândit a fi utilizat atât pentru criptare cât și pentru semnătura electronică a fost algoritmul Rivest-Shamir-Adleman (RSA), dezvoltat în 1977 de 3 ingineri cu același nume, de la MIT. Martin Gardner spunea că va da 100$ primei persoane care va reuși să spargă cifrul pe care se baza RSA. Această afirmație se bazează pe puterea criptografică de care dispune RSA-ul care provine din dificultatea problemei factorizării numerelor întregi.

Algoritmul este unul de criptare pe bază de blocuri și a fost creat pentru a rezolva două probleme. Prima este aceea a distribuirii celor două chei întrucât se punea problema deținerii unor comunicații securizate fără a fi nevoit să ai încredere într-un distribuitor de chei separat, iar cea de-a două e cea a utilizării semnăturilor digitale, ai anume cum putea fi verificat că mesajul ajunge intact de la emițător la destinatar.

Cu RSA, fiecare utilizator al acestui sistem de criptare are câte o pereche de chei, cea privată pe care o păstrează secretă și cea publică pe care o trimite celor de la care dorește să primească date criptate.

Cheile de criptare sunt generate după anumiți pași care presupun generarea a două numere prime, de preferință mari, p și q; apoi se calculează n = pq si Φ = (p-1)(q-1); se alege un întreg aleator e, unde1 < e < Φ astfel încât cmmdc(e, Φ) = 1. Perechea (n, e) este cheia publică. Folosind algoritmul lui Euclid extins, se calculează întregul d, unicul cu proprietatea că de ≡ 1mod Φ. (n, d) constituie cheia secretă.

Folosind cheile invers, algoritmul poate fi folosit și pentru semnătura electronică. Astfel dacă o entitate criptează un mesaj cu cheia sa secretă și atașează rezultatul mesajului său, atunci oricine poate verifica, decriptând cu cheia publică a semnatarului și comparând rezultatul cu mesajul clar că într-adevăr acea entitate este autorul mesajului.

Viteza RSA este mai redusă față de cea a algoritmilor de criptare cu cheie secretă din cauza faptului că exponențierea modulo n care stă la baza sa necesită operații costisitoare din punct de vedere al timpului de calcul și al resurselor necesare. Pentru comunicațiile în care viteză de criptare și decriptare sunt esențiale, RSA este folosit doar la începutul comunicației pentru transmiterea cheii secrete care va fi folosită în algoritmi precum 3DES sau AES. Cheile de criptare RSA cele mai sigure au lungime mai mare de 1024 biți.

Protocoale de securitate care folosesc RSA sunt: IPSEC/IKE pentru securizarea datelor IP, TLS/SSL pentru securizarea transportului de date (web), PGP pentru securizarea email-urilor, SSH destinat securizării conexiunilor la terminal, SILC pentru securizarea serviciilor pentru conferințe.

Protecția comunicațiilor IP cu ajutorul soluției integrate F5 – Cisco

Implementarea protocoalelor SSL și a succesorului său TLS a fost adoptată de marea majoritate a organizațiilor ca soluție pentru securizarea comunicațiilor IP. SSL asigură confidențialitate și securitate comunicațiilor, însă în același timp crează și dificultăți pentru echipamentele dedicate inspecției și criptării traficului. Pe scurt, comunicațiile criptate nu pot fi văzute în clar și astfel ajung să treacă fără a fi inspectate, creând puncte oarbe în sistemul de securitate. Devin riscuri considerabile pentru o organizație întrucât atacatorii ar putea ascunde trafic periculos în interiorul traficului criptat. Decriptarea traficului SSL/TLS de către echipamentele de inspecție poate conduce către o scăderea considerabilă a performanțelor acestora, mai ales când vine vorba de certificatele de 2048 de biți.

Principalele avantaje ale acestei soluții:

Modelele de implementare flexibile care pot fi integrate până și în cele mai complexe arhitecturi, permit reducerea complexității stivei de securitate și furnizează vizibilitate SSL asupra infrastructurii.

Decriptare și recriptarea centralizată este realizată la viteză optimă, eliminându-se latențele determinate de procesele de decriptare/recriptare realizate la trecerea prin fiecare echipament de inspecție, în plus este îmbunătățită experiența utilizatorilor.

Înlățuirea dinamică a serviciilor de securitate, ceea ce permite managementul traficului cu ajutorul politicilor, astfel fiind stabilit dacă traficului îi este permis să treacă sau trebuie decriptat și trimis către un echipament de securitate sau serviciu.

Monitoare de verificare a funcționalității care permit realizarea fiabilității și toleranță la erori.

Capabilități de sandboxing avansate pentru analiză statică și dinamică care ajută la descoperirea de noi amenințări și la ajutarea echipelor de securitate să înțeleagă, prioritizeze și să blocheze sarcinile sofisticate.

F5 BIG-IP

4.1.1 Noțiunea de Proxy

Un proxy este o soluție hardware sau software, care se interpune între calculatorul utilizatorului și serviciul pe care acesta îl acesează în internet. Astfel clientul (browser-ul) se conectează la proxy, care se conectează apoi în numele clientului la server-ul web. La rândul său, serverul web trimite răspunsul către proxy care îl trimite apoi către client. Mai mult utilizate pentru traficul de tip HTTP, servere proxy există și pentru alte tipuri de protocoale.

Un proxy în mod transparent recepționează traficul fără a fi necesare configurații suplimentare din partea clientului, acesta nu resimte existența proxy-ului în rețea. În cazul acestui tip de implementare, proxy-ul transparent poate recepționa toate tipurile de trafic TCP și TLS. De asemenea poate procesa UDP și să îl direcționeze către alte tipuri de trafic IP. Proxy-ul explicit suportă doar HTTP(s) conform RFC2616. În plus, proxy-ul transparent suportă rutarea bazată pe politici (PBR) și protocolul Web Cache Communication (WCCP) care depind de serviciile de rețea să suporte ambele protocoale. Față de acesta, proxy-ul explicit presupune setarea manuală a browser-ului pentru Proxy Auto-Config (PAC) și protocolul Web Proxy Autodiscovery (WPAD) care presupun configurarea suplimentară de iRule-uri pentru generarea de conținut PAC/WPAD

4.1.2 Arhitectura packet-based față de arhitectura full-proxy

Un echipament de rețea cu un design packet-based este situat în interiorul rețelei, în mijlocul traficului de comunicații, fără a reprezenta un endpoint pentru aceasta, un astfel de exemplu pot fi routerele.

Față de design-ul packet-based, unde este suficientă o înțelegere minimală a traficului care traversează proxy-ul, într-o arhitectură full proxy, serverul cunoaște și înțelege protocoalele, fiind el însuși un endpoint și un generator al acestora. F5-BIG-IP poate realiza și inspecta schimbul de pachete până la nivelul aplicație al stivei ISO.

Un server full proxy menține două conexiuni separate de nivel transport – una pentru partea de client și una pentru partea de server. Un echipament full-proxy, așa cum este BIG-IP, crează o breșă între cele două conexiuni pentru a vizualiza și modifica conținutul traficului care îl tranzitează. Astfel sunt granular prevenite problemele de disponibilitate, performanță și securitate care pot fi specifice fiecăreia dintre cele două zone, client și server. În mare parte tehnicile de accelerare și optimizare utilizate în partea de client sunt diferite față de cele din partea de servere pentru că și situațiile care determina problemele de performanță și disponibilitate sunt diferite. O soluție ar fi utilizarea BIG-IP pentru a degreva serverele de aplicații de funcțiile intens consumatoare de resurse, cum ar fi compresia datelor și criptarea SSL.

Există echipamente de rețea care inițial permit tot traficul pentru ca ulterior să restricționeze ceea ce este considerat inutil sau periculos, în contrast cu acestea BIG-IP este un echipament de tip “default deny”, întâi blochează și apoi permite doar dacă sunt configurate obiecte specifice și capabilități de procesare a diferitelor scenarii de tranzitare a traficului.

4.1.3 Ce presupune BIG-IP System?

În centrul produsului BIG-IP F5 este TMOS (Sistem de operare pentru gestionarea traficului).

TMOS este sistemul de operare implementat în toate echipamentele F5. Are două componente. Prima componentă este un sistem de operare Linux responsabil pentru managementul echipamentului. Această componentă permite utilizarea CLI și a GUI de către utilizatori și este responsabilă de comunicarea cu alte soluții de management existente (SMTP, SYSLOG, SNTP etc.). Managementul poate fi accesat prin SSH pentru CLI sau HTTPS pentru GUI.

A doua componentă a TMOS este TMM (Trafic Management Microkernel). TMM este optimizat pentru procesarea traficului și rulează pe fiecare nucleu de procesare de pe platforma hardware. Dat fiind că este optimizat pentru procesarea traficului, acesta este independent de componenta de management sau de spațiul utilizator și nu este niciodată necesar ca procesarea traficului să depășească TMM. Fiecare proces TMM este responsabil pentru sesiunile furnizate către el, neexistând comunicare între două procese TMM. Fiecare configurație făcută prin management este verificată și aplicată tuturor instanțelor TMM.

Arhitectura TMOS este prezentată în următoarea imagine:

Fig. 5 Arhitectura TMOS

4.2 Vizibilitatea SSL cu ajutorul F5

Arhitectura full proxy a F5-ului permite echipamentului să insereze o zona de decriptare, de texte în clar între client și serverul web, creând un punct agregat de vizibilitate pentru serviciile de securitate.

Fig. 6 Separarea zonei client de cea de server printr-o zonă de decriptare

Sistemul F5 stabilește două conexiuni independente, una cu clientul și una cu serverul web. Când utilizatorul inițializează o conexiune HTTPS cu serverul web, sistemul F5 o interceptează, decriptează traficul criptat venit de la client, îl redirecționează către Cisco Firepower Threat Defense pentru inspecție, iar apoi recriptează același trafic pe care ulterior îl trimite către serverul web. Același process are loc și pentru traficul HTTPS de răspuns de la server către client, este interceptat, decriptat, inspectat, recriptat și trimis către client.

Fig. 7 Arhitectura full-proxy a F5-ului

4.2.1 Ce este F5 Herculon SSL Orchestrator?

F5 Herculon SSL Orchestrator este o soluție all-in-one special concepută pentru optimizarea infrastructurii SSL, ce oferă vizibilitate asupra traficului criptat de tip SSL/TLS și îmbunătățește eficiența utilizării investițiilor în securitate existente. Soluția centralizează și consolidează inspecția SSL în cadrul arhitecturilor de securitate complexe, permițând încărcarea unor opțiuni flexibile de decriptare și recriptare a traficului, realizat de utilizatori către și dinspre aplicațiile web și internet. Are la bază managementul bazat pe politici precum și redirecționarea traficului către echipamente de securitate third-party, cum ar fi firewall-urile, sistemelor de prevenire a intruziunilor (IPS) și sistemele de prevenire a pierderii datelor (DLP) și anti-malware. Principalele funcționalități sunt:

Înlănțuirea dinamică a serviciilor de securitate pentru sprijinirea politicilor bazate pe context (context-policy based), reducerea încărcării administrative și utilizarea eficientă a resurselor.

Managementul centralizat al funcțiilor SSL de decriptare și recriptare.

Inspecția întregului trafic împotriva infiltrărilor de malware și date datorită design-ului pe mai multe niveluri.

Moduri de implementare flexibile pentru integrarea ușoară a ultimelor tehnologii de criptare din cadrul infrastructurii de securitate existente

Disponibilitate ridicată cu cele mai bune capabilități de balansare a traficului, monitorizare a functionalitii și traficului SSL.

Fig. 8 Soluția SSL Herculon Orchestrator

4.2.2 Terminologia specifica solutiei Herculon SSL Orchestrator

Fiind o soluție aparte față de F5 BIG-IP, Herculon SSL Orchestrator este necesarea înțelegerea terminologiei specifice.

Certficatul emis de Autoritatea de Certificare. Implementarea Herculon SSL Orchestrator presupune un certificate emis de Autoritatea de Certificare care să conțină o cheie publică (PKI) care să se potrivească cu cheia privată a proxy-ului SSL. Clienții TLS trebuie să aibă încredere în acest certificat pentru a semna certificatele serverului.

Zona de decriptare. Se referă la zona de rețea aflată între F5 BIG-IP și echipamentele prin care trec datele în mod decriptat pentru inspecție. Practic, la finalul oricărui service chain (lanț de servicii) poate fi plasat încă un serviciu inline, pentru inspecția sumplimentară. Nu poate fi configurată o zona de decriptare în cazul în care un sigur sistem BIG-IP gestionează atât traficul de intrare cât si cel de ieșire pentru că practic decriptarea nu există.

Echipamentul de ieșire. Sistemul BIG-IP de ieșire este echipamentul care primește traficul după ce o conexiune traversează lanțul de servicii de securitate (service chain) și apoi este rutat către destinația finală. În cazul în care traficul în ambele direcții este gestionat de același sistem BIG-IP, termenul ieșire se referă la VLAN-ul prin care traficul iese din BIG-IP către Internet.

Serviciul ICAP. Fiecare serviciu ICAP folosește protocolul ICAP pentru direcționarea traficului HTTP către unul sau mai multe device-uri Content Adaptation pentru inspecție și posibile modificări. ICAP poate fi adăugat la orice lanț de servicii TCP, dar doar traficul HTTP este trimis către el, întrucât ICAP nu este suportat și pentru alte protocoale. Utilizând SSL Orchestrator pot fi configurate până la zece servicii ICAP.

Echipamente de intrare. Sistemul BIG-IP de intrare este acela către care toți clienții trimit trafic. În cazul în care atât traficul de intrare cât și cel de ieșire este manipulat de același sistem BIG-IP, intrare se referă la VLAN-ul/urile către care clienții trimit traficul. Sistemul BIG-IP de intrare (sau VLAN-urile de intrare) decripteaza traficul și apoi pe baza protocolului, sursei, destinației, s.a.m.d, îl clasifică și apoi, în funcție de lanțul de servicii configurat, îl trimite către fiecare conexiune pentru inspecție (sau permite ocolirea lanțului de servicii în funcție de selecția făcută).

Serviciul inline. Serviciile inline trec traficul prin unul sau mai multe echipamente de inspecție de nivel date (Bump-in-the-wire) sau de nivel IP. Fiecare echipament de inspecție comunică cu echipamentul BIG-IP de intrare prin două vlan-uri numite Inward și Outward care transportă traficul prin intranet, respectiv internet. Utilizând Herculon SSL Orchestrator pot fi definite până la zece servicii inline.

Serviciul receive-only. Serviciile receive-only se referă la serviciile care doar primesc traficul pentru inspecție fără a-l trimite înapoi la sistemul BIG-IP. Fiecare serviciu receive-only oferă o copie pachet cu pachet a traficului care trece prin toate echipamentele de inspecție. Pot fi configurate până la zece servicii receive-only.

Lanțul de servicii de securitate. Acesta procesează anumite conexini pe baza regulilor de clasificare care se uită la protocol, adresa sursă și destinație etc. Acest lanț de servicii permite definirea a patru tipuri de servicii (servicii nivel date inline, servicii nivel IP inline, servicii receive-only și servicii ICAP), precum și a oricărui tip de zonă de decriptare între servicii de intare și ieșire separate).

Regulile de configurare a lanțului de securitate. Fiecare regulă de clasificare din lanțul de servicii va procesa conexiunile de intrare în funcție de lanțul de servicii configurat (mai multe reguli de clasificare pot trimite trafic către același lanț). Fiecare regulă de clasificare are patru filtre. Filtrele pot fi aplicate pe baza adresei IP sursă, pe baza destinației (care poate fi adresa IP, categoria IP Intelligence, IP Geolocation, numele de domeniu, categoria URL Filtering sau port-ul serverului) și pe baza protocolului aplicație (pe baza portului sau a protocolului identificat). În cauzul în care anumite filtre se suprapun, prioritate vor avea regulile mai specifice pentru conexiunea respectivă.

SNAT. SNAT (Secure Network Address Translation – translatarea securizată a adresei de rețea) este caracteristică care definiște adresa IP rutabilă cu care BIG-IP înlocuiește adresa IP sursă a clientului atunci când acesta se conectează la rețeaua externă. Un pool SNAT este o plajă de adrese translatate care pot fi asociate uneia sau mai multor adrese IP inițiale. Adresele translatate dintr-un pool SNAT nu pot fi adrese self IP.

Grupul de Sync-Failover. Grupul Sync-Failover este alcătuit din device-uri BIG-IP care își sincronizează configurația și se înlocuiesc reciproc când unul dintre ele nu mai este funcțional. În design-ul Herculon SSL Orchestrator grupul de Sync-Failover poate fi alcătuit din maximum 2 echipamente.

4.2.3 Orchestrarea SSL utilizând lanțul de servicii de securitate

O stivă de securitate tipică constă în mai multe sisteme avansate de protecție anti-malware. Începe cu un firewall dar de cele mai multe ori nu se oprește aici, se adaugă sisteme de detectare/prevenire a intruziunilor (IDS/IPS), firewall-uri pentru aplicații web, sisteme de prevenire a pierderii datelor (DLP – data loss prevention) și așa mai departe. Pentru a soluționa provocări de securitate specifice, administratorii sunt nevoiți să adapteze și să combine manual toate echipamentele de securitate pentru a crea o stivă de securitate solidă formată din mai multe servicii. În acest caz, toate sesiunile sunt clasate ca având același nivel de securitate, întrucât legarea lor se face la nivel de hardware.

SSL Orchetrator poate balansa, monitoriza și înlănțui dinamic serviciile de securitate, incluzând firewall-uri, DLP-uri, firewall-uri pentru aplicațiile web și anti-virus malware și poate determina, în funcție de politica definită, dacă să îi permită traficului să treacă sau să îl decripteze și să îl trimită către un serviciu de securitate. Distribuirea traficului pe baza politicilor permite o mai bună utilizare a infrastructurii de securitate existente și ajută la reducerea costurilor administrative.

Fig. 9 Lanțul de servicii de securitate SSL Orchestrator

Soluția F5 SSL Visibility oferă o modalitate de a aplica diferite lanțuri de servicii bazate pe un context provenit dintr-un motor foarte puternic de clasificare. Contextul derivă din:

Adresa IP sursa/ subretea.

Adresa IP destinație/subrețea.

Categoria IP Intelligence.

IP Geolocation.

Numele echipamentului și domeniul.

Categoria URL Filtering.

Portul destinație.

Protocolul.

4.2.4 Dimensiunarea implementării

Principalul avantaj al implementării sistemului F5 într-o arhitectură de securitate este că acum traficul prin cablu poate fi clasificat fie ca trafic de interes, care trebuie decriptat de sistemul F5 pentru ca mai apoi să fie inspectat de Cisco Firepower Threat Defense, fie ca trafic care nu este de interes, și îi este permis să treacă fără modificări sau să fie procesat diferit în funcție de politica companiei.

De aceea, trebuie luat în considerare întregul volum de trafic pentru a alege sistemul F5 potrivit. În funcție de modul de implementare ales, sunt necesare cel puțin două interfețe din F5 pentru fiecare firewall configurat în modul inline și cel puțin o interfață pentru firewall-ul configurat în modul TAP.

Herculon SSL Orchestrator este livrat cu un modulul de bază instalat care permite atât interceptarea SSL cât și capabilități de înlănțuire a serviciilor. Pentru a rula aplicația SSL Orchestraotr pe un system BIG-IP, acesta trebuie să ruleze cel puțin TMOS 13.0, iar BIG-IP Local Trafic Manager (LTM) trebuie să fie echipat cu o licență add-on de tip forward proxy. În plus pot fi adăugate subscripții de URL Filtering pentru a utiliza baza de date pentru filtrare, IP Intelligence pentru a detecta atacatorii și traficul malițios, un modul de Securitate hardware (HSM) pentru protecția și managementul cheilor digitale pentru o autentificare mai sigură.

Cisco Firepower poate fi implementat ca Firepower Threat Defense pe platformele ASA 5000x și Firepower 2100/4100/9300 sau ca servicii de FirePOWER pe un modul FirePower separate pe platformele ASA 5500x.

4.2.5 Scalarea orizontală

Abilitatea sistemului BIG-IP de a balansa și dirija traficul către mai multe echipamente de securitate dintr-un pool de servicii permite platformei de securitate Cisco să fie scalabilă pe orizontală fără a mai fi necesară adăugarea de noi funcționalități. Pentru ca serviciul să nu fie doar fault-tolerant ci să aibă și o disponibilitate mare, este recomandată mărirea throughput-ului.

Se obișnuiește configurarea unui singur pool de Cisco Firepower NGFW cu sistemului BIG-IP care balansează traficul HTTP în clar și traficul HTTPS decriptat către toți membrii din pool. Dacă este necesară crearea mai multor pool-uri cu firewall-uri, fiecare fiind responsabil de un anumit tip de trafic, se poate face cu ajutorul regulilor de clasificare a lanțului de servicii TCP din SSL Orchestrator. Aceste reguli clasifică traficul pe baza informațiilor de rețea definite de utilizator, geolocația IP, categoria URL, protocol sau IP Intelligence alături de alți factori, și distribuie traficul astfel clasificat către lanțul de servicii din care face parte FTD-ul.

Fig. 10 Pool-uri de servicii FTD

4.2.6 Excluderea traficului din inspecția SSL

Așa cum a fost menționat mai sus, sistemul BIG-IP poate fi configurat să facă diferența între traficul care este de interes și care nu, în scopul procesării sale din punct de vedere al securității. Exemple de trafic care nu prezintă interes și pot excluse din inspecție ar putea fi:

VLAN-urile de invitati (guest).

Sursele de update de software de încrede cum ar fi update-urile Microsoft Windows.

Soluțiile de backup de încredere.

De asemnea, traficul poate fi exceptat pe baza numelui de domeniu sau categoriei URL.

Regulile de clasificare din lanțul de servicii ale sistemelor BIG-IP și Herculon permit administratorilor să implementeze politici de utilizare a internetului în organizație, să asigure confidențialitatea și să respecte reglementările în vigoare.

Excluderile bazate pe categoria URL pot include permisiuni de trecere fără decriptare pentru traficul de la surse cunoscute de genul:

Financiare.

Sănătate.

Servicii guvernamentale.

4.2.7 Modalități de implementare

4.2.7.1 Certificate

Un certificate SSL – de preferat de la o Autoritate de Certificare secundară – și cheia privată a sistemului BIG-IP sunt necesare pentru generarea și prezentarea certificatelor către utilizatorul final care a solicitat site-ul HTTPS care a fost interceptat.

Pentru ca utilizatorii unei rețele să nu întâmpine erori de certificate din partea browser-elor atunci când accesează site-uri de tip SSL, certificatul rădăcină trebuie încărcat în browser sau în sistemul de operare al clientului final.

4.2.7.2 Adresarea IP

Când un echipament Cisco Threat Defense este implementat ca un echipament de nivel IP, este recomandată configurarea de adrese IP pentru VLAN-urile de pe intrare și de pe ieșire conform adresării furnizate de SSL Orchestrator, derivate din blocul 192.19.0.0 stabilit prin RFC2544. Acest model de adresare reduce cazurile de coliziuni de adrese.

4.2.7.3 Implementarea

Preocupările de securitate privind compromiterea cheilor de criptare au determinat site-urile să renunțe la utilizarea RSA și să se orienteze către alte protocoale de criptare. RSA ca și protocol utilizat în schimbul perechilor de chei publică-privată, utilizează perechea de chei a serverului pentru a negocia cheile simetrice utilizate în criptarea sesiunii, existând astfel posibilitatea de compromitere a cheii private a serverului (vulnerabilitatea Heartbleed) precum și compromiterea oricărui mesaj, prezent sau trecut, care a utilizat sau utilizează această cheie. Din aceste considerente a început tranziția către tehnologiile de criptare care au la bază protocolul Diffie-Hellman care nu expune datele în cazul în care a fost compromisă cheia privată. În plus, definind cheile Diffie-Hellman ca fiind temporare, se obține serviciul de perfect forward secrecy – PFS. Preocupările de securitate privind compromiterea cheilor de criptare au determinat site-urile să renunțe la utilizarea RSA și să se orienteze către alte protocoale de criptare.

O consecință interesantă a acestei evoluții este faptul că tehnologiile inspecției SSL passive – sistemele care există acum pe piață și care pot fi atașate unui port span pentru a decripta pasiv comunicațiile SSL/TLS – nu mai funcționează. Aceste tehnologii se bazează pe schimbul cheilor bazat pe RSA între client și server și pentru acest lucru trebuie să dețină o copie a cheii private a serverului. Dacă serverul și clientul aleg un cifru PFS, sistemele SSL passive nu au nici o șansă să decripteze datele. Astăzi, multe site-uri și multe browsere preferă cifrurile PFS în locul celor non-PFS, cum este și protocolul RSA. În plus, noul TLS 1.3 va elimina complet schimburile de chei non-PFS, facând sistemele SSL pasive tot nefuncționale. Cu alte cuvinte, realizarea vizibilității SSL când va veni vorba de cifruri bazate pe PFS va fi posibilă prin plasare unui sistem de interceptare în linie cu fluxul de date.

Din aceste considerente, există mai multe modalități de implementare pentru integrarea sistemelor F5 cu firewall-urile Cisco Firepower și realizarea protecției avansate împotriva amenințărilor.

4.2.7.4 Unul sau două sisteme F5

Soluția F5 SSL Visibility în linie cu Cisco Firepower NGFW poate fi realizată cu unul sau două sisteme BIG-IP sau Herculon.

Prima opțiune: un singur F5 în linie cu Cisco Firepower NGFW. Soluția implică un singur sistem F5 configurat pentru a realiza atât decriptarea cât și recriptarea traficului SSL, în timp ce firewall-urile sunt configurate pentru modul inline și configurate ca pool de servicii nivel IP pe sistemul F5.

A doua opțiune este conectarea a două sisteme F5 în line cu Cisco Firepower NGFW. Deși este suficient un singur F5 pentru furnizarea tuturor functionalităților și capabilităților necesare implementării soluției de SSL visibility, în unele cazuri există solicitări pentru configurarea unui al doilea sistem F5 către exterior, când este necesară creșterea ratei SSL a soluției sau când politicile de securitate ale organizației solicită implementare a două sisteme pentru redundanță.

Când sunt utilizate două sisteme F5 pentru soluția de SSL visibility, sistemul de intrare de pe partea de client va decripta traficul web din partea clientului, în timp ce sistemul de ieșire de pe partea serverului va recripta același trafic înainte de a-l trimite către serverul web, crescând rata SSL.

4.2.7.5 Pool de servicii

Implementarea SSL visibility utilizând două sisteme F5 permite două modalități de configurare a firewall-urilor Cisco Firepower.

Ca un pool de servicii pe sistemul F5 de intrare. Avantajul implementării firewall-urilor într-un pool de servicii este că sistemul F5 de intrare poate să distribuie traficul pe baza politicilor de înlănțuire definite.

Ca pool de servicii între sistemul F5 de intrare si cel de ieșire. În timp ce acest model de configurare permite sistemului F5 să distribuie traficul care a trecut prin lanțurile de servicii către firewall-urile cuprinse între cele două F5 din zona de decriptare, are dezavantajul că limitează implementarea politicilor întrucât pool-ul de firewall-uri nu mai face parte din nici un lanț de servicii. În plus, complică design-ul de failover. Cele două firewall-uri trebuie acum configurate în modul fail open, întrucât zona de decriptare nu are nici un mod implicit de a detectare a defecțiunilor apărute.

Ambele modalități de implementare sunt valide pentru fluxurile de trafic către exterior. De asemenea, pot fi alocate în orice punct de schimb de date din data center unde traficul criptat circulă dintr-o zona de securitate în alta.

4.2.7.6 Recomandări privind arhitectura

O serie de recomandări arhitecturale pot optimiza performanta, disponibilitatea și securitatea. Recomandările F5 includ:

Implementarea sistemelor F5 ca făcând parte dintr-un grup de sync/failover, ceea ce presupune o pereche de echipamente active-standby, cu o adresă floating IP pentru High Availability (HA).

Fiecare firewall Ciso Firepower din pool-ul de servicii trebuie să fie dual-homed pe VLAN-urile de intrare și de ieșire cu fiecare sistem F5 din grupul de sync/failover.

Redundanța interfețelor poate fi realizată folosind protocolul Link Aggregation Control (LACP). LACP gestionează interfețele fizice conectate ca fiind o singură interfață virtuală și detectează orice disfuncționalitate a oricărei interfețe din acest grup.

Sistemele F5 nu au nevoie de conexiuni fizice către firewall-urile Cisco Firepower, fiind necesară totuși existența unei conexiuni nivel IP pentru a distribui traficul către firewall-uri. În ceea ce privește rețelele lente, este bine ca firewall-urile să nu fie la mai mult de un hop distanță. Când echipamentele de inspecție nu sunt direct conectate de F5, este recomandat ca doar echipamentele de inspecție să aibă acces la datele necriptate, iar acest lucru se poate face prin VLAN-uri. Din același motiv adresele rezervate de SSL Orchestrator furnizează un plus de securitate la nivel de rețea din stiva ISO.

4.3 Tehnologia Cisco Firepower

Cisco a achiziționat Sourcefire în 2013. Până la acel moment, Sourcefire a fost unul dintre liderii de top din industria securității cibernetice, fiind cunoscut pentru sistemul sau de detectie a intruziunilor (IDS – intrusion prevension system), sistemul de prevenție a intruziunilor și pentru soluțiile de tip Next-Generation Firewall. Sistemul de prevenție a intruziunilor era bazat pe Snort, un sistem de detectare și prevenție a intruziunilor în rețea de tip open source. Martin Roesch, creatorul Snort a fondat Sourcefire în 2001.

După achiziția Sourcefire, Cisco a introdus tehnologiile sale în diferite appliance-uri Cisco existente, cum ar fi seriile ASA 5500-X și routerele cu servicii integrate (Integrated Services Router – ISR). De asemenea, Cisco a lansat și platforme hardware noi, cum sunt seriile Firepower 2100, 4100 și 9300 care folosesc tehnologiile Sourcefire.

4.3.1 Evoluția Firepower

Implementarea sistemului Firepower constă în două tipuri de aplliance-uri: un senzor și o aplicație de management. În principiu, senzorul inspectează traficul din rețea și trimite orice eveniment către aplicația de management. O aplicație de management, așa cum îi spune și numele gestionează toate tipurile de politici de securitate aparținând senzorului. În figura de mai jos este schema de principiu pentru implementarea sistemului Firepower.

Fig. 11 Diagrama bloc de implementare a sistemului Firepower

Sourcefire a avut inițial două versiuni de software; versiunea 4.x, pentru IPS și versiunea 5.x cu funcționalități NGFW. În funcție de versiunea de software, aplicația de management avea două nume diferite. În versiunea 4.x se numea Sourcefire Defense Center, iar în versiunea 5.x era cunoscută drept FireSIGHT sau FireSIGHT Management Center (FMC). De asemenea, senzorul era numit sensor 3D în verisunea 4.x iar în 5.x era FirePOWER Appliance. Așadar, în versiunea 4.x, Sourcefire Defense Center gestiona senzorii 3D, în timp ce în versiunea 5.x, FireSIGHT Management Center face management pentru appliance-urile FirePOWER.

Pentru a simplifica nomenclatura și pentru a păstra reputația brand-ului, Cisco a înlocuit tehnologiile Sourcefire cu un singur cuvânt, Firepower. Cisco nu a schimbat retrospectiv numele din FirePOWER în Firepower pentru software-ul și hardware-ul Sorcefire original, a utilizat noua nomenclatură doar pentru cele de după achiziția Sourcefire.

În figura de mai jos este prezentată evoluția Firepower Threat Defense (FTD) de la preachiziție la post integrare

Fig. 12 Evoluția tehnologiei FTD

Câteva exemple de produse Firepower noi sunt Cisco Firepower 9300 appliance hardware și Cisco FTD software.

În tabelul de mai jos sunt prezentate diferite nume ale aplicației de management corespunzătoare diferitelor versiuni de software.

Tabel 2 Corespondența echipament- aplicație de management

4.3.2 FirePOWER versus Firepower TThreat Defense (FTD)

Serviciile FirePOWER se referă la feature-urile similare software-urilor din perioada pre achiziție, cum sunt Next Generation Intrusion Prevention System Virtual (NGIPSv). În FTD, Cisco agregă toate specificațiile Sourcefire FirePOWER, cele aparținând firewall-ului ASA, dar și unele feature-uri noi, într-o singură imagine software complexă.

În figura de mai jos este ilustrată agregarea software-ului Cisco ASA cu software-ul FirePOWER în codul FTD. Datorită acestei convergențe, serviciile FirePOWER nu mai rulează pe un modul separat, ceea ce reduce încărcarea și crește eficiența.

Fig. 13 Reprezentarea logică a software-ului FTD

4.3.3 Componenetele software ale sistemului Firepower

Sistemul Firepower oferă o multitudine de feature-uri de securitate. Față de tradiționalul software al firewall-ului Cisco ASA, capabilitățile Firepower sunt livrate ca multiple componente software:

Firepower Core Software: Partea centrală a software-ului include motorul Snort pentru detectarea și prevenirea intruziunilor, un server web pentru interfață grafică (GUI – graphical user interface), o bază de date pentru stocarea evenimentelor, firmware și hardware etc. Imaginea software a sitemului Firepower depinde de platforma hardware utilizată.

Patch-uri si hotfix-uri de software: Cisco emite periodic patch-uri de software pentru a preveni orice tip de vulnerabilitate de Securitate și pentru a remedia orice defect apărut în sistemul Firepower. Când apare o problem care necesită soluționare înainte de lansarea update-ului de mentenanța stabilit, Cisco poate lansa un hotfix specific.

Snort/Reguli Sourcefire: Snort utilizează un set special de reguli pentru a detecta și preveni tentativele de intruziune. Fiecare regulă este specifică anumitor condiții. Când un pachet trece printr-un sensor și se potrivește pe o condiție din regulile Snort, acesta ia măsurile necesare.

Bază de date pentru vulnerabilitătâți (Vulnerability database – VDB). Aceasta stochează informații despre vulnerabilități și amprente pentru diverse aplicații, servicii și sisteme de operare. Firepower utilizează amprentele pentru a descoperi aplicațiile, serviciile și sistemul de operare care rulează pe echipamentul gazdă pentru ca apoi să coreleze datele despre aplicații și rețea cu informațiile despre vulnerabilități din baza de date.

Baza de date pentru geolocație (Geolocation database – GeoDB). Aceasta stochează informațiile geografice și adresele IP asociate. Spre exemplu, când Firepower afișează un o intruziune în GUI, poate fi văzut numele și steagul țării din care provine atacul. Această informație permite luarea rapidă a deciziilor, fără a mai fi necesar un reverse lookup pentru adresa IP.

Figura de mai jos ilustrează componentele software instalate pe Firepower.

Fig. 14 Componente software FTD

Componentele software ale Firepower

Baza de date pentru URL Fitering. Firepower poate cataloga site-urile web pe baza audienței țintă și a scopului business-ului. Pentru a oferi un control granular, sistemul permite controlarea accesului la un anumit tip de site pe baza reputației sau a unul nivel de risc cunoscut. Față de update-urile celorlalte componente software, orice update al bazei URL se face direct din Cisco Cloud, motiv pentru care FMC-ul trebuie să fie conectat la internet.

Security Intelligence Feed. Talos, echipa Cisco de threat intelligence, caută constant pe internet pentru identificarea de potențiale adrese IP periculoase, domenii și URL-uri. Pentru utilizatorii Firepower, Talos furnizează inteligence data prin Security Intelligence Feed. FMC-ul le poate descarca direct din Cloud.

Detectare malware locală. Cu licență de malware, FTD poate detecta virușii din fișiere. Astfel este blocată răspândirea malware în rețea. FTD utilizează ClanAV pentru a analiza local fișierele. FMC-ul conține semnăturile pentru cei mai recenți viruși prin intermediul update-urilor de detecție locală a malware-urilor.

4.3.4 Integrarea sistemului Firepower

Firepower poate fi integrat cu diverse produse și tehnologii, cum sunt Identity Service Engine (ISE), Microsoft Windows Active Directory Server, Event Streamer (eStreamer), Syslot Server sau F5 BIG-IP. Astfel, oferă oportunități nelimitate de monitorizare și securizare a rețelei.

4.3.5 Platformele hardware Firepower

În prezent, ultima versiune de software FTD este 6.4.0, lansată pe 24 aprilie, însă în cadrul lucrării practice am utilizat o mașină virtuală pe care am instalat versiunea 6.2.3 de software pentru a fi compatibilă cu mediul ESXi. Versiunea 6.2.3 este disponibilă pentru o largă varietate de platforme hardware, arhitectura internă a fiecărei platforme fiind diferită.

În tabelul de mai jos sunt prezentate platformele care suportă versiunea 6.2.3

Tabel 3 Platforme care suporta versiunea 6.2.3

4.3.6 Firepower Management Center

Pentru configurarea și gestionarea FTD-ului este necesar un manager. În funcție de scenariul de implementare și de modelul hardware, există varianta de manager on-box numit Firepower Device Manager sau de manager off-box, numită Firepower Management Center. FDM-ul permite managementul unui singur echipament în timp ce FMC permite gestionarea, monitorizarea și administrarea centralizată a mai multor FTD-uri.

FMC-ul este disponibil atât în varianta fizică, cât și în cea virtuală.

În figura de mai jos este exemplificată conectarea mai multor FTD-uri aflate în locații diferite și administrate de același FMC.

Fig. 15 Multiple FTD-uri administrate de FMC

FMC-ul are mai multe interfețe de utilizator, în funcție de scopul urmărit. Spre exemplu, GUI poate fi utilizat pentru aplicarea politicilor de securitate și monitorizarea evenimentelor, CLI poate fi utilizat pentru soluționarea avansată a problemelor și interfața bazată pe text (TUI) pentru configurarea anumitor componențe când sistemul de operare nu este încărcat sau instalat.

4.3.7 Implementarea FMC si FTD în mediu virtual

Atât Firepower Management Center (FMC) cât și Firepower Threat Defense pot fi virtualizate. Acesta este și modul de implementare pe care l-am utilizat în cazul lucrării de față.

Începând cu versiunea 6.1 software-ul Firepower suportă o varietate de medii virtuale, cum ar fi VMware, Kernel-based Virtual Machine (KVM) și serviciile web Amazon (Amazon Web Services – AWS).

Studiu de caz – Vizibilitatea SSL cu ajutorul integrării tehnologiilor F5 BIG-IP SSL Orchestrator și Cisco Firepower Threat Defense

5.1 Topologia retelei

Pentru a demonstra vizibilitatea SSL cu ajutorul echipamentele F5 SSL Orchestrator și Firepower Threat Defense, am ales că mediu virtual ESXi 6.5 în care am instalat echipamente virtuale cu imaginile software corespunzătoare, descărcate de pe site-urile oficiale Cisco și F5:

F5 Herculon SSL Orchestrator.

Cisco Firepower Threat Defense – Cisco_Firepower_Threat_Defense_Virtual-ESXi-6.2.3-83.

Cisco Firepower Management Center – Sourcefire_3D_Defense_Center_S3_Patch-6.2.3.10-59.sh.REL.tar.

2 x Ubuntu: unul pentru a simula clientul și unul ca echipament de mirroring.

Pentru a face administrarea apliance-urilor din serverul de VMware ESXi am utilizat clientul web de vSphere.

Precedent instalării mașinilor virtuale am creat șase POD-uri pe care le-am alocat în funcție de necesitate după cum poate fi observat în tabelul de mai jos.

Tabel 4 Alocarea POD-urilor in ESXi

Având imaginile software corespunzătoare, POD-urile distribuite corect și suficient spațiu pe disc, am instalat cele cinci mașini virtuale.

Declararea discului virtual poate fi făcută întru-unul din următoarele trei moduri: Thick provision Lazy Zeroed, Thick Provision Eager Zeroed și Thin Provision. Toate mașinile virtuale din laborator sunt provisionate Thin Provision, ceea ce presupune că alocarea spațiului pe disc se face în funcție de necesitate. Dimensiunea spațiului crește oricând este nevoie, până la limita specificată.

Resursele alocate fiecărei mașini sunt prezentate în tabelul de mai jos:

Tabel 5 Resurse alocate masinilor create

Rețeaua este construită în interiorul unei rețele existente, dar este total separată de aceasta, fiind de sine stătătoare. Tabelul de mai jos prezintă planul de adresare pentru toate mașinile virtuale instalate. Adresele IP au fost alese astfel încat să se încadreze în rețeaua părinte și să îndeplineasă cerințele SSL Orchestrator.

Tabel 6 F5 BIG-IP SSL Orchestrator

Tabel 7 Serviciul de nivel IP

Tabel 8 Serviciul de nivel date

Tabel 9 Serviciul TAP

Tabel 10 Utilizator

Tabel 11 Firepower Management Center

Diagrama de mai jos este utilă pentru o mai bună exemplificare și întelegere a topologiei fizice pe care se bazează integrarea servicilor F5 SSL Orchestrator si Cisco Firepower Threat Defense.

Fig. 16 Topologia fizică a rețelei

5.2 Firepower Threat Defense

5.2.1 Instalarea

De subliniat este faptul că pentru integrarea Cisco Firepower Threat Defense ca echipament de nivel IP în lanțul de servicii F5 SSL Orchestrator este recomandată utilizarea unui anumit plan de adresare. Astfel, interfețele de intrare și ieșire vor primi adrese dintr-o clasă de IP-uri prestabilită de F5, din blocul 192.19.0.0. Acest lucru reduce riscul apariției coliziunilor.

Planul de adresare IP utilizat este reprezentat în tabelele de mai jos:

Tabel 12 Serviciul de nivel IP

Tabel 13 Serviciul de nivel date

Pașii urmați pentru instalarea FTD au fost următorii:

Fig. 17 Etape instalare Firepower Threat Defense

După finalizarea procesului de instalare în ESXi, și pornirea mașinii virtuale FTD procesul de inițializare se încheie în aproximativ 20 minute. La sfârșitul procesului, este afișat prompt-ul de autentificare în care credențialele inițiale sunt: admin și Admin123.

Promptul > de la sfârșitul imaginii de mai sus confirmă faptul că instalarea este completă. Următorul pas este verificarea conectivității cu rețeaua și începerea procesului de înregistrare. Resursele alocate mașinii virtuale Firepower sunt importante pentru performanța sistemului, iar acest lucru poate fi verificat în vSphere Center în două locuri. Summary Page oferă o imagine de ansamblu asupra template-ului OVF instalat și a resurselor alocate. În figura de mai jos pot fi observate procesorul alocat, memoria, spațiul, adaptoarele de rețea etc.

Fig. 18 Resurse alocate pentru instalarea FTD

A doua posibilitate de vizualizare și modificare a setărilor este din Virtual Machine Settings Editor, în care se poate ajunge în două moduri, fie prin click dreapta pe numele mașinii și selectarea opțiunii Edit Settings, fie din pagina Getting Started și click pe Edit Virtual Machine Settings. În ambele cazuri apare aceeași fereastră conținând proprietățile mașinii virtuale.

Fig. 19 Proprietățile mașinii virtuale FTD

La instalarea unei mașini virtuale, VMware utilizează în mod implicit adaptoare de rețea (network adapter) de tipul E1000. Pe lângă acest model există și adaptoare de tipul VMXNET3 și VMXNET2, Firepower fiind compatibil doar cu primul dintre cele două. Diferența între adaptorul VMXNET3 și E1000 este legată de capacitatea de procesare a datelor (throughput), primul suportă 10Gbps iar cel de-al doilea 1Gbps. Este esențial ca adaptoarele mașinii virtuale să fie toate la fel, nu este însă obligatoriu ca toate mașinile dintr-o rețea virtuală să aibă același tip de adaptoare. Modificarea se poate face prin oprirea mașinii, accesarea paginii Edit Virtual Machine Settings, extinderea câmpului Network Adapter și schimbarea modelului din Network Type, urmând ca apoi mașina să fie repornită. În rețeaua construită pentru această lucrare nu există o mare cantitate de trafic, motiv pentru care toate mașinile virtuale au adaptoare de tipul E1000.

În cazul rețelelor de mici dimensiuni, administrarea FTD-ului poate fi făcută local cu ajutorul aplicației implicite numită Firepower Device Manager (FDM). Pentru rețelele medii și mari în care sunt instalate mai multe echipamente, este recomandată utilizarea Firepower Management Center care față de aplicația locală dispune de mai multe funcționalități și permite gestionarea și configurarea centralizată a mai multor echipamente. Pe lângă administrarea FTD-urilor, în acceași măsură este importantă și adaptarea rețelei astfel încât traficul de control dintre echipament și manager să fie securizat.

Înainte de începerea procesului de înregistrare, trebuie să ne asigurăm că FMC-ul și FTD-ul sunt localizate corect în rețea și există comunicație între ele.

Firepower Threat Defense utilizează interfața logică de management pentru traficul de control, respectiv pentru realizarea procesului de înregistrare la FMC și stabilirea unui tunel securizat cu acesta. Tunelul este apoi utilizat pentru configurarea FTD-ului, aplicarea politicilor și transfer al evenimentelor între FMC și FTD. IP-ul specificat în timpul procesului de instalare a FTD-ului este alocat interfeței logice de management.

Odată stabilită conexiunea între interfețele de management, FMC-ul poate administra FTD-ul indiferent de locația în care acesta se află, fie că este în rețeaua locală (LAN), fie că este în afară sa (wide area network – WAN).

În funcție de plasarea și configurarea interfețelor de management, rețeaua de management poate fi adaptată. Acestea pot fi în aceeași subrețea sau într-o subrețea diferită.

În cazul rețelei pe care am creat-o, managementul tuturor echipamentelor este în aceeași rețea, fiind conectate între ele prin intermediul unui switch virtual de nivel doi.

IP-ul interfeței de management poate fi configurat în procesul de instalare inițial sau ulterior din linia de comandă așa cum poate fi observant și în imaginea de mai jos.

5.2.2 Instalarea FMC și înregistrarea FTD la FMC

Pașii de instalare ai mașinii FMC sunt la fel cu cei utilizați în cazul FTD-ului, totuși ip-ul de management care ii este alocat inițial este 192.168.45.45. Astfel pentru conectarea la interfața web, calculatorul de management trebuie să fie capabil să acceseze această rețea sau tot din linie de comandă va fi schimbată adresa FMC-ului. În acest sens utilizând Secure Shell (SSH) dintr-un terminal de consolă (Putty, SecureCrt, TeraTerm) se accesează FMC-ul sau FTD-ul după caz, se adaugă credențialele pentru autentificare și autorizare și se rulează comanda configure-network din modul expert.

Fig. 20 Adresa de management a FTD-ului

Fig. 21 Adresa de management utilizata pentru FMC

Înainte de înregistrarea FTD-ului la FMC, este recomandată verificarea conectivității între cele două mașini virtuale, iar acest lucru poate fi realizat printr-o serie de comenzi date în consola fiecăreia. În figura de mai jos este reprezentată conexiunea dintre FTD și FMC.

Fig. 22 Conexiunea FTD – FMC

Pentru a testa existența comunicației între FTD-ul și FMC-ul din rețeaua creată, am utilizat comanda ping 10.202.101.44 în FMC. Ca urmare a faptului că nu există pachete pierdute putem stabili că există o rută atât către FTD cât și dinspre FTD iar cele două echipamente pot comunica la nivel ip.

Fig. 23 Verificarea conexiunii FMC – FTD

Verificarea tabelului de rutarea atât în FMC cât și în FTD se face cu comanda route –n. După cum poate fi observat în linia de comandă de mai jos, cele două mașini virtuale vor transmite pachetele pentru care nu au intrări în tabela de rutare către un gateway având adresa ip 10.202.101.1.

Fig. 24 Tabela de rutare a FMC-ului

Fig. 25 Tabela de rutare a FTD-ului

Pentru a vizualiza toate setările de rețea configurate pe FTD, se utilizează comanda show network.

Fig. 26 Setările de rețea configurate pe FTD

Vizualizarea statusului interfeței de management dar și a celorlalte interfețe ale mașinii virtuale se face cu ajutorul comenzii show interface ip brief.

Fig. 27 Vizulizarea statusului interfețelor FTD și FMC

După înregistrarea echipamentului în FMC, interfețele, ip-ul de management și rutele pot fi configurate sau modificate și din interfața grafică. Se accesează interfața grafică a FMC-ului, respectiv https://10.202.101.55, iar după autentificare se urmează calea Devices -> Device Management. Din tab-ul Device pot fi vizualizate setările generale, de sistem, cele de management și licențiere, din tab-ul Routing se configurează protocoalele de rutare sau rutele statice ce urmează a fi utilizate, iar din tab-ul Interfaces se vizualizează, activează sau modifică setările ce țin de interfețe.

Fig. 28 Meniul Device Management din FTD

Vizualizarea și modificarea setărilor generale ale FTD-ului din aplicația de management FMC

Fig. 29 Setarea rutelor și protocoalelor de rutare ale FTD-ului din aplicația FMC

Fig. 30 Setarea interfetelor FTD din aplicația FMC

5.2.3 Licențierea și înregistrarea FTD

Odată instalat FTD-ul și configurată interfața de management, se poate trece la licențierea, activarea functionalităților și înregistrarea FTD-ului în FMC. Procesul de înregistrare se realizează prin tunelul criptat ridicat între FMC și FTD, însă nu înainte de a licenția FMC-ul, fie prin metoda Clasic License fie cu ajutorul Smart License.

Tehnologiile Cisco Firepower oferă numeroase posibilități de protejare a rețelei împotriva activităților malițioase. Firepower vine cu o licență Base implicită care însă nu activează toate funcționalitățile de Securitate disponibile, pentru acest lucru sunt necesare licențe în plus.

Tabel 14 Descrierea licențelor disponibile pentru FTD

Licențierea FMC-ul din rețeaua creată este de tip Smart License, fiind înregistrat cu Cisco Smart Software Management. Inițial se accesează portalul cisco.com, ulterior pagină Cisco Smart Software Management. Din contul virtual al organizației se generează un nou token prin click pe butonul New Token, rezultând un token reprezentat de un șir de caractere aleatorii. Acesta se adaugă în secțiunea de licențiere a FMC-ului.

Fig. 31 Licențierea FMC-ului

După apăsarea butonului Apply Change, va începe procesul de înregistrare la Autoritatea Cisco de Licențiere, iar dacă acesta se va încheia cu succes va apărea un mesaj de confirmare, după cum poate fi observat și în imaginea de mai jos.

Fig. 32 Confirmarea licențierii corecte a FMC-ului

5.2.4 Înregistrarea sistemului Firepower

Înregistrarea Firepower Threat Defense este un process în doi pași, care începe în linia de comandă a FTD-ului unde se introduc informațiile necesare stabilirii conexiunii cu FMC-ul.

Pentru adăugarea FMC–ului în FTD, se da comanda configure manager add urmată de adresa ip a FMC-ului și a unei chei de înregistrare care va fi utilizată o singură dată pentru asigurarea securității comunicației. Sintaxa completă este configure manager add adresa_ip_FMC cheie_inregistrare. Înainte de înregistrarea la FMC, FTD-ul este administrat local, iar acest lucru poate fi observat din rezultatul comenzi show managers.

.

Fig. 33 FTD administrat local

Fig. 34 Înregistrarea FTD-ului la FMC

După încheierea procesului de înregistrare, dacă rezultatul comenzii show managers va arăta ca în imaginea următoare înseamnă că operațiunea a avut loc cu succes și se poate continua cu pasul doi.

Fig. 35 Verificarea modului de management

Următoarea etapă este adăugarea detaliilor de înregistrare a FTD-ului în interfața web a FMC-ului, utilizând aceeași cheie de înregistrare ca cea din etapa anterioară. După accesarea interfeței grafice a FMC-ului la adresa https://10.202.101.55, din meniul Devices se alege Device Management și apoi Add Device. Este important ca înainte de completarea câmpurilor din fereastra Add Device, FMC-ul să fie fost adăugat în FTD.

Fig. 36 Adăugarea senzorilor în FMC

În câmpul Host se adaugă adresa ip a interfeței de management a FTD-ului, în câmpul Display Name se introduce numele care va identifica echipamentul în FMC, iar în Registration Key va fi scrisă cheia de înregistrare, acceași cu cea din FTD.

Având în vedere că încă nu este configurată nici o politică, în câmpul Access Control Policy se selectează politica implicită, iar apoi se selectează licențele ce vor fi alocate FTD-ului.

Fig. 37 Adăugarea senzorului FTD_Lic în FMC

Dacă înregistrarea s-a făcut cu succes, echipamentul va fi afișat la accesarea tab-ului Devices -> Device Management.

Fig. 38 Vizualizarea senzorilor adăugați

Odată cu introducerea în FTD a informațiilor despre FMC, portul TCP 8305 din FTD începe să asculte conexiunile de intrare, așteptând pachete de la FMC. Odată stabilită conexiunea, statusul portului 8305 se modifică în Established. Același lucru este valabil și la introducerea în FMC a datelor despre FTD. În imaginea de mai jos este dată comanda de verificare a statusului portului 8305.

Fig. 39 Verificare status port 8305 pe FTD

Fig. 40 Verificare status port 8305 pe FMC

5.2.5 Implementarea FTD in modul Routed

Firepower Threat Defense poate fi configurat pe de-o parte ca gateway pentru rețea, clienții fiind astfel forțați să treacă prin firewall pentru a comunica cu o subrețea diferită sau să iasă în Internet, iar pe de altă parte poate fi configurat în modul transparent devenind astfel nesesizabil pentru utilizatori, asemeni un echipament de nivel date. Pe scurt, FTD poate fi configurat în două moduri – Routed și Transparent. În rețeaua creată, FTD-ul este configurat să funcționeze în modul routed.

Oricare dintre opțiuni poate fi selectată în momentul instalării inițiale a firewall-ului. Pentru modificare, echipamentul trebuie scos din FMC prin ștergerea sa și apoi, din CLI aplicată comanda >configure firewall routed/transparent.

5.2.6 Configurarea interfețelor

FTD-ul permite configurarea statică a interfețelor cu adrese ip, poate să își obțină ip-urile de la un server DHCP sau chiar să devină el însuși un server DHCP pentru echipamentele din rețea. Pentru configurarea interfețelor cu adrese ip statice, din meniul Devices -> Device Management se face click pe iconița de editare din dreptul FTD-ului ce urmează a fi configurat. Din meniul Interfaces se face click pe iconița de editare din dreptul interfeței dorite.

Pentru topologia creată de mine, prin interfața GigabitEthernet0/0 traficul va circula de la FTD către F5 HERCULON, iar prin GigabitEthernet0/1 de la F5 Herculon către FTD. Interfețele GigabitEthernet0/2 și GigabitEthernet0/3 vor rămâne de nivel date și nu vor avea adrese ip, prima va fi utilizată pentru traficul dispre FTD către F5, iar cea de-a doua pentru traficul de întoarcere. În cazul firewall-urilor este obligatorie atribuirea de nume logice pentru fiecare dintre interfețe, acest lucru nu este valabil și pentru zonele de securitate.

Fig. 41 Configurarea interfețelor FTD

Ip-urile sunt alocate interfețelor conform cerințelor F5 SSL Orchestrator. Acestea trebuie să facă parte din subrețeaua 192.19.0.0 pentru ca ulterior echipamentul să fie adăugat în lanțul de serviciii de securitate, interfețele de nivel date doar vor fi activate.

Fig. 42 Vizualizarea interfețelor configurate

Fig. 43 Planul de adresare si interfețele FTD_Lic

5.2.7 Selectarea comportamentului implicit

Comportamentul implicit într-o politică de control acces stabilește cum va administra FTD-ul traficul care nu se potrivește pe nici o regulă de acces. Din pagina Policies -> Access Control poate fi create o politică nouă sau modificată cea implicită. În rețeaua creată am lucrat pe politică implicită numită Default_Access_Control_Policy pentru care am ales că acțiune Intrusion Prevention:Balanced Security and Connectivity ceea ce înseamnă că oricărui tip de trafic care nu se va potrivi pe o politică de acces îi va fi permis să treacă prin FTD după ce va fi inspectat.

Fig. 44 Politica de Control Acces FTD

5.2.8 Blocarea traficului folosind interfețe în modul inline

Un echipament FTD cu interfețele în modul inline poate bloca traficul, rămânând nesesizabil pentru utilizatorii din rețea. FTD suportă o mare varietate de acțiuni de blocare, cum ar fi simpla blocare a traficului, blocarea cu resetare, blocarea interactivă sau blocarea interactivă cu resetare, însă nici una dintre ele nu are efect dacă interfețele nu sunt configurate corespunzător.

Fig. 45 Configurarea regulilor pentru Politica de Control Acces

În tabelul de mai jos sunt descrise modurile FTD și capacitățile corespunzătoare de blocarea a traficului. Modul de implementare definește modul în care FTD funcționează ca firewall, iar modul interfeței descrie modul în care FTD-ul gestionează traficul în caz de activitate malițioasă.

Tabel 15 Modurile în care poate fi implementat FTD-ul

Un sistem de detectare și prevenire a intruziunilor detectează activititatile suspicioase și previne atacurile asupra rețelei. FTD-ul poate fi instalat atât că sistem de detecție (IDS – intrusion detection system) cât și ca sistem de prevenție (IPS – intrusion detection systems). Pentru a preveni în timp real orice posibilă intruziune, FTD-ul trebuie configurat în modul inline în care interfețele de intrare și ieșire sunt grupate, iar fiecare pereche trebuie asociată cu un inline set care este un grup logic format din una sau mai multe interfețe.

Fig. 46 Principiul configurării FTD-ului în modul inline

Față de modul Inline, configurarea FTD în modul pasiv, presupune că echipamentul doar detectează intruziunile, fără a le bloca.

FTD-ul utilizat în rețeaua creată funcționează că un sistem IPS, având interfețele Gigabitethernet0/2 și GigabitEthernet0/3 grupate într-un inline set numit INLINE_SET. Configurându-l astfel, traficul dinspre clienți spre servere va fi inspectat suplimentar, întrucât FTD-ul ca sistem IPS reprezintă un hop separat în lanțul de servicii de securitate de pe F5 SSL Orchestrator.

Configurarea interfețelor în modul inline se face din Devices->Device Management->Edit->Interfaces. Interfața GigabitEthernet0/2 va fi configurată cu numele logic de OUTSIDE_L2 fiind destinată traficului care pleacă din FTD către F5, în modul inline, pentru interfața GigabitEthernet0/3 de intrare a traficului în firewall, numele logic va fi INSIDE_L2 și va fi configurată tot în modul inline. Pentru ambele trebuie bifată căsuța Enabled pentru activare

Fig. 47 Configurarea interfețelor pentru funcționarea inline

Din acceași pagină, din tab-ul Inline Sets se dă click pe Add Inline Set, se inserează numele inline set-ului, se alege o pereche de interfețe și se adaugă în câmpul Selected Interface Pair, în final se apasă OK.

Din linie de comandă, vizualizarea rezultatului configurației aplicate anterior în FMC poate fi observat cu ajutorul comenzii show inline-set.

Fig. 48 Vizualizarea configuratiei pentru modul inline

5.2.9 Configurarea politicilor FTD

Implicit FTD activează o singură politică de prefilter care nu poate fi ștearsă, singura opțiune configurabila fiind acțiunea implicită asupra traficului care poate fi analizat sau blocat (Analyze All Tunnel Traffic sau Block All Tunnel Traffic).

Politica de control Access (Access Control policy – AC) este cea mai importantă politică a sistemului Firepower, tot traficul care intră în FTD este procesat de una sau mai multe reguli configurate aici. Politica de control determină dacă traficul va fi logat, permis sau blocat, fiind utilizată pentru implementarea listelor de Security Intelligence, regulilor IPS și politicilor de fișiere, pentru SSL, identificare, DNS și NAP. Această politică poate fi asociată cu listele de reguli de access de pe firewall (ACL), doar că față de permiterea sau blocarea traficului, aceasta oferă și multiple metode de inspecție a traficului. Implementarea se poate face în multe moduri, fie ca o singură politică este aplicată pe toate echipamentele, fie că există câte una separată pentru fiecare echipament sau grup de echipamente, cu condiția că pe oricare echipament poate să existe o singură politică.

Pentru că politica de Control Acces este cea mai importantă într-o implementare depinde de o serie de alte politici:

Prefilter Policy (Politica de prefiltrare). Este diponibilă doar pe FTD și permite configurarea de reguli care pot bloca sau permite traficul înaintea Politicii de Access Control. În plus pot fi adăugate nume zonele de tunel pentru traficul tunelar și pot fi create reguli de AC specifice acestuia.

Indentity Policy. (Politica de Identitate). Regulile din Politica de Access Control permit identificarea traficului pe baza identității utilizatorului. Pentru ca această politică să funcționeze trebuie asociată Politicii de Access Control.

SSL Policy (Politica SSL). În cazul în care se realizează, decriptarea traficului SSL trebuie făcută înainte că traficul să fie procesat de politica de Acces Control, mai ales când este necesară identificarea aplicațiilor din sesiunile criptate.

DNS Policy (Politica DNS). Fiecare Politică de Control Access are o politică DNS asociată. Aceasta inspectează traficul înainte de a fi procesat de Politica de Control Acces și poate fi configurată să permită, să bocheze sau să redirecționeze traficul.

Intrusion Policy (Politica de Intruziune). Anumite reguli din Politica de Control Access pot trimite traficul către Snort pentru inspecție prin intermediul acestei politici.

Network Analysis Policy (Politica de Analiză a Rețelei). Politica de Control Acces specifică una sau mai multe politici de Analita a rețelei cu setări care au impact asupra preprocesoarelor Snort și proceselor Politicii de Intruziune subsecvente.

File&Malware Policy (Politica de fisiere si malware). Traficul poate fi inspectat pentru fișiere periculoase tot prin intermediul regulilor din Politica de Control Acces.

Fig. 49 Meniul Access Control pentru configurarea Politicii de Control Acces

Crearea politicii de Control Acces se face din meniul Policies -> Access Control -> Access Control. Inițial nu există nici o politică, iar pentru crearea uneia se apasă butonul New Policy.

În fereastră deschisă se completează numele politicii, care în cazul de față este Default_Access_Control_Policy, iar opțional poate fi inserată o descriere. Fiind prima politică, câmpul Select Base Policy se setează pe None. Pentru acțiunea implicită a politicii există trei variante: Block All Traffic (blocarea traficului). Daca traficul nu se potriveste pe nici una din regulile din Politica de Control Acces, atunci acesta va fi blocat.

Intrusion Prevention (prevenirea intruziunilor). Traficul care nu se potrivește pe nici una dintre reguli va fi procesat de regulile Snort din politica de Intruziune.

Network Descovery (descoperirea rețelei). Traficului care nu se potrivește pe nici una din reguli îi va fi permis să traverseze echipamentul și poate fi subiect de analiză pentru politică de Network Discovery.

Politica de Control Access creată pe FTD-ul din această lucrare se numește Default_Access_Control Policy, comportamentul implicit este Intrusion Prevention și este aplicată echipamentului FTD_Lic, parte a lanțului de servicii de securitate de pe BIG IP SSLO.

Fig. 50 Crerea Politicii de Control Acces

Modificarea echipamentelor asociate politicii se poate face din Policy Assignements. Deoarece fiecărui echipament trebuie să îi fie asociată o politică de Acces, dezasocierea unui echipament de la politică va necesita automat asocierea lui cu o altă politică.

Din meniul de Security Intelligence se configurează diferite liste de Security Intelligence care au scopul de a bloca sau cataloga traficul în liste negre (black lists) pe baza de DNS, URL sau IP.

Fig. 51 Politica de Control Access

Utilizând Security Intelligence avem opțiunea de a adauga cereri DNS, adrese URL sau adrese IP în liste albe sau în liste negre (whitelist sau blacklist). Dacă listele negre sunt intuitive, liste albe au rolul de a suprascrie întrări din listele negre și de a preveni un eventual impact asupra traficului critic. Spre exemplu, pentru cazul unei liste de IP-uri, ce s-ar întâmpla dacă adresa IP a unui router central al rețelei ar fi deodată introdusă într-o lista neagră și IPS-ul ar bloca tot traficul spre și dispre el. Pentru a preveni acest lucru, IP-ul ar putea fi introdus intr-o lista albă.

După accesarea meniului Security Intelligence, așa cum este ilustrat și în imaginea de mai jos, există mai multe secțiuni. Prima se numește Available Objects (obiecte disponibile), iar cea de-a două Available Zones (zone disponibile), următoarele două sunt Whitelist și Blacklist care la rândul lor sunt împărțite în două secțiuni, Network și URL.

Fig. 52 Configurarea Security Intelligence

În coloana de Available Objects, împărțită în Network și URL sunt incluse diferite categorii Security Intelligence, populate ca urmare a informațiilor pe care FMC-ul le încarcă periodic.

Fig. 53 Categoriile Security Intelligence

Pentru protecția împotriva tuturor tipurilor de atacuri cunoscute, în politica creată, atât pentru zonele de intrare cât și pentru cele de ieșire a traficului, sunt trecute în lista neagră toată obiectele disponibile din lista de Available Objects. Ca opțiune, obiectele clasificate că fiind malițiose pot fi blocate sau doar monitorizate. În cazul de față, dacă vor fi identificate, vor fi blocate și un mesaj corespunzător va fi afișat în acest sens prin bifarea opțiunii de Logging.

Fig. 54 Configurarea Security Intelligence

Din meniul HTTP Responses poate fi aleasă pagina care va fi returnată utilizatorului în momentul în care conexiunea va fi refuzată din motiv de securitate. Poate fi folosită opțiunea implicită sau o pagină special creată în acest sens. În cazul de față, pagina returnată pentru traficul blocat se va configura pe F5.

Fig. 55 Configurarea HTTP Responses

Din meniul Rules se configurează regulile Politicii de Control Access care vor fi aplicate de sus în jos. Deși sunt două categorii Mandatory și Default, acestea au rol organizatoric, iar parcurgerea regulilor se va face la fel, fără a se ține cont de categorie.

Adăugarea regulilor se face apăsând butonul Add Rule. Prima regulă pe care am adăugat-o a fost pentru traficul IP. Numele regulii este Default_Rule și pentru că ea să fie activată, căsuța Enabled trebuie bifată. Câmpul Action oferă ca opțiuni Allow, Trust, Monitor, Block, Block with Reset, Interactive și Interactive Block with Reset. Scopul acestei reguli este permiterea traficului și inspecția acestuia, din acest motiv, din toate opțiunile am selectat Allow.

Din câmpul Available se aleg zona sursă și zona destinație pentru traficul de interes din această politică. După cum poate fi observat în imaginea de mai jos, politica este destinată traficului de nivel IP din zona internă către cea externă.

Fig. 56 Configurare reguli pentru Politica de Control Acces

Din următorul meniu, numit Networks, se stabilește pentru care clase de ip-uri din zona declarată anterior sursă sau destinație se aplică regulă. Interesul în configurația creată este că tot traficul ip să fie subiectul inspecției, de aceea pentru sursă și destinație am ales any-ipv4.

Fig. 57 Configurare reguli pentru Politica de Control Acces

Cele trei taburi aflate în dreapta în imaginea de mai sus, numite Inspection, Logging și Comments nu au impact asupra regulii configurate. Din meniul Inspection este controlată inspecția fișierelor și intruziunilor pentru regulile care au această capabilitate. Pentru această regulă, câmpul Intrusin Policy este completat cu Politica de Intruziune creată anterior, numită Intrusion_Policy.

Fig. 58 Configurare regulii de inspecție pentru Politica de Control Acces

Din câmpul Logging este controlată logarea conexiunilor și evenimentele generate de fișiere pentru regula în cauza. Odată pornită, sunt înregistrate informații privind conexiunile din rețea care se potrivesc regulii configurate. Pentru regulă creată am ales logarea evenimentul atunci când începe, o altă varianta este logarea să atunci când se încheie.

Fig. 59 Configurarea modului de logare pentru Politica de Control Acces

Cea de-a doua regulă creată se numește Default_Rule_Inline_Sets, se aplică traficului de nivel date și are parametrii configurați ca în cazul traficului de nivel ip.

După finalizarea configurării politicii de Control Acces aceasta trebuie salvată și trimisă către echipament cu ajutorul opțiunii Deploy.

După încărcarea politicii pe echipament și generarea traficului dinspre clienți spre exterior, informațiile despre conexiuni se pot vizualiza din câmpul Analysis -> Connections -> Events.

Fig. 60 Vizualizare traficului care tranzitează și este inspectat de FTD

5.3 Serviciul de TAP și Ubuntu Client

Pe lângă mașinile FTD și FMC, rețeaua mai cuprinde și două mașini virtuale Ubuntu. Una dintre ele este folosită ca serviciu de TAP în lanțul de servicii de securitate și este numită Ubuntu_TAP-Destination_Lic, iar cealaltă simulează utilizatorul aflat în rețeaua internă a echipamentului F5, pe partea de client și se numește Ubuntu_Client_Lic.

În tabelul de mai jos sunt sumarizate caracteristicile de rețea ale celor două mașini virtuale Ubuntu.

Tabel 16 Adresare IP – Ubuntu

Fig. 61 Mașinile Ubuntu pentru simularea utilizatorului și a serviciul de TAP

Pentru a-și îndeplini rolul, pe mașină Ubuntu_TAP_Destination am instalat aplicația gratuită Wireshark care permite monitorizarea traficului în timp real. IP-ul acestei mașini este 2.2.2.3, însă în cazul serviciului de TAP, importantă este adresa MAC, care în acest caz este 00:50:56:A0:06:6E.

Fig. 62 Vizualizarea traficului din aplicația Wireshark instalată pe Ubuntu_TAP_Destination_Lic

Din mașina Ubuntu_Client_Lic se generează traficul care va trece prin F5, va fi decriptat, trimis prin diferite lanțuri de servicii, inspectat, retrimis către F5 care îl va recripta și îl va trimite către destinație.

5.4 Configurarea F5

5.4.1 Instalarea F5 SSL Orchestrator

După alocarea în ESXi a resurselor necesare și instalarea imaginii F5 SSL Orchestrator, prima conectare la echipament se face prin consolă. Autentificarea se face cu utilizatorul root și parolă default. Pentru schimbarea adresei IP de management inițiale a BIG IP se folosește utilitarul de Configuration Utility în care se intră tastand comandă config.

În setările inițiale se configurează adresa IP, masca de rețea și adresa gateway-ului pentru portul de management. Odată ce adresa IP este configurată pentru platformă, se poate utiliza Configuration Utility din browser pentru a obține licența corespunzătoare software-ului BIG-IP.Pașii pentru licențierea sistemului F5 SSL Orchestrator sunt următorii:

Folosind un browser web, se accesează adresa IP atribuită sistemului BIG IP, utilizând formatul https: // <adresa_ip>, unde <adresa_ip> este adresa IP atribuită, în cazul de față mașina virtuală se va accesa astfel: https://10.202.101.100

Conectarea în brower se face folosind utilizatorul admin și parola admin. După pornirea utilitarului de configurare, primul pas este licențierea echipamentului.

Licențierea echipamentului se face accesând pagina din meniul System ->License. În pagina de licențiere, se face click pe Activate, iar ca metodă de activare (Activation Method) se alege Manual, urmând apăsarea butonului Next. Se copiază fișierul generat în pagina de licențiere F5, https://secure.f5.com. În pagina Licensing, pe rândul care afișează Activate F5 product registration key, se apasă pe Activate License. Licența se introduce în câmpul Enter your dossier, apoi se apasă pe Next. Dispozitivul va reîncărca modulele necesare și Configuration utility va continua.

În pagina Resource Provisioning, Local Traffic Manager și SSL Orchestrator trebuie să fie Licensed, iar modul Provisioning trebuie să fie setat pe Nominal, pentru ca funcționalitatea de SSL Orchestrator să fie activată.

În plus mai pot fi licențiate și alte module. După licențiere, trebuie configurat numele echipamentului (hostname), fusul orar (timezone) și administratorul (user administration). Numele echipamentului utilizat este F5.Simona.Lic.

Fig. 63 Licențierea și alocarea resurselor pentru modulele din F5

Următorul pas este configurarea părții de rețea pentru F5 SSL Orchestrator. Acest lucru presupune definirea interfețelor utilizate, crearea vlan-urilor și definirea adreselor IP utilizate pentru fiecare vlan din fiecare domeniu. Toată configurația poate fi realizată din interfață grafică sau din linia de comandă. Interconectarea interfețelor este prezentată în tabelul următor:

Fig. 17 Interconectarea interfețelor F5

Crearea Vlan-urilor se face din meniul Network de unde se selectează VLANs. Se apasă butonul Create care va deschide pagina de setare a numelui, partiției, tag-ului și interfeței fizice asociate.

Pentru fiecare interfață fizică am creat un vlan separat, după cum poate fi observat și în imaginea următoare. În dreptul fiecărui vlan, în partea dreaptă, în coloana Untagged Interface este notată interfața fizică care face parte din acel vlan.

Fig. 64 Vizualizarea vlan-urilor din meniul VLANs

Fiecare VLAN din configurația BIG-IP va avea configurate adrese IP. Există două tipuri de adrese IP care vor fi definite pe fiecare vlan: self ip și floating ip address. Adresele self IP sunt adrese IP atribuite unui VLAN pe un anumit dispozitiv; această adresă IP va fi întotdeauna pe acel dispozitiv și pe acel VLAN în particular.

Pe de altă parte, floating IP address este adresa IP folosită în implementările HA, unde adresa IP este atribuită pe vlan-ul specific de pe dispozitivul activ. Acest tip de adrese se va muta de la un dispozitiv la altul și va fi utilizat pe calea de întoarcere a traficului provenit de la servere. Adresele IP sunt configurate din Network, Self IP și Create. Se definește numele, adresa IP, masca de rețea, vlan-ul, port lockdown și traffic group-ul.

Fig. 65 Configurare vlan

F5 BIG-IP este un echipament de tip default deny. Pentru a transfera traficul, trebuie definiți listeners of virtual servers. Din acest motiv, un dispozitiv F5 nu va răspunde niciodată la traficul care are ca destinație o adresa self IP. Dacă traficul de management sau alt tip de trafic trebuie transmis prin intermediul acestor adrese IP, Port Lockdown trebuie configurat să permită trafic specific. Setarea implicită nu va permite nici un tip de trafic, cu excepția icmp.

O adresă IP poate fi configurată ca floating IP address selectând floating option din Traffic Group. Într-o implementare High Availability pot exista mai mult de două dispozitive. Fiecare dispozitiv poate fi Active pentru un anumit serviciu și backup pentru altul. Grupurile de trafic reprezintă un mecanism care specifică pentru ce vlan/service/adresa IP va fi activ un dispozitiv. Adresele floating IP sunt definite o singură dată pe dispozitivul activ. Configurația va fi sincronizată cu dispozitivul de standby. Este recomandată configurarea unui ip floating chiar dacă implementarea nu este de tip High Availability, astfel ip-ul rămâne rezervat pentru o posibilă astfel de implementare. În tabelul și imaginea de mai jos sunt prezentate ip-urile și vlan-urile corespunzătoare topologiei create, precum și tipul ip-urilor. Restul adreselor ip afișate sunt configurate automat la configurarea SSL.

Tabel 18 Planul de adresare F5

În imaginea de mai jos este ușor de observat că SSL Orchestrator alege pentru serviciile din lanțul de servicii de Securitate adrese ip din clasa 192.19.0.0/16, clasă rezervată în acest scop.

Fig. 66 Planul de adresare F5 SSL Orchestrator

5.4.2 Configurarea SSL Orchestrator

Majoritatea configurațiilor de tip forward proxy existente în rețelele companiilor vor utiliza o singură platformă F5 care să fie responsabilă de realizarea vizibilității SSL. Pornind de la acestă idee o singură platforma SSL Orchestrator reușește să creeze și să susțină un lanț robust de servicii de Securitate.

În rețeaua creată, pentru exemplificarea vizibilității asupra traficului SSL, am configurat o parte din serviciile de securitate care pot fi incluse în lanțul de servicii și anume serviciul de nivel date, de nivel IP și serviciul TAP. Astfel, un client conectat în rețeaua internă va avea acces la resurse din internet prin SSLO care va decripta traficul și îl va trimite spre inspecție către serviciile de securitate.

Clientul face parte din rețeaua 10.202.121.0/24 și are adresa ip 10.202.121.44. Această rețea este atașată interfeței 1.2 a BIG-IP.

Echipamentul de nivel 3 este un firewall virtual Cisco Firepower Threat Defense, versiunea 6.2.3. Interfața GigabitEthernet0/0 (OUTSIDE) are ip-ul 198.19.64.161/25, este utilizată pentru traficul de ieșire din FTD și este conectată în interfața 1.5 (IN_L3_FROM_FTD) din F5. Interfața GigabitEthernet0/1 (INSIDE) are ip-ul 198.19.64.61/25, este utilizată pentru traficul de intrare în firewall și este conectată în interfața 1.4 (OUT_L3_TO_FTD) din F5.

Echipamentul de nivel date va fi un firewall virtual Cisco Firepower Threat Defense 6.2.3 cu două dintre interfețe configurate în modul inline. Interfața de intrare GigabitEthenet0/2 (trafic către FTD) va fi conectată în interfața 1.6 din BIG IP, iar cea de ieșire GigabitEthernet0/3 (tarfic dinspre FTD) în interfața 1.7 din F5.

Serviciul TAP va fi reprezentat printr-o mașină Ubuntu configurată cu o singură interfață atașată în portul 1.3 din BIG-IP.

Rețeaua externă va fi 10.202.111.0/24 și va fi atașată portului 1.1 din BIG-IP, având adresa ip a gateway-ul 10.202.111.1.

Pentru obținerea vizibilității asupra traficului SSL cu ajutorul F5 BIG-IP SSL Orchestrator este necesară parcurgerea mai multor pași.

Prima cerință a echipamentului F5 este ca serverul Network Time Protocol (NTP), Domain Name Server (DNS) și rutarea să fie configurate. Configurarea serverului de NTP se poate face din linie de comandă sau din interfață grafică accesând meniul System->Configuration ->Device->NTP. Serverul NTP utilizat de F5 în rețeua în cauză este 91.195.144.112.

Fig. 67 Configurare server NTP

Pentru adăugarea NTP din linie de comandă, este necesară logarea în tmsh și apoi inserarea comenzii modify /sys ntp servers add {ip_addr ip_addr….}, verificarea se face cu list /sys ntp servers.

Serverul de DNS se configurează din System->Configuration->Device->DNS. În această rețea voi folosi serverul DNS aparținând Google și anume 8.8.8.8.

Fig. 68 Configurare server DNS

Cea de-a treia cerință înainte de configurarea lanțului de servicii de securitate este configurarea rutei default. Din meniul principal, se alege Network->Routes și apoi se face click pe iconița de adăugare. Traficul pentru care F5 nu găsește o intrare în tabela de rutare va fi transmis către gateway-ul cu adresa 10.202.111.1.

Fig. 69 Configurare rută default

Configurarea SSL Orchestrator se face alegând din meniul principal opțiunea SSL Orchestrator urmată de Configuration și Add.

Fig. 70 Configurare SSL Orchestrator

SSLO crează configurații discrete bazate pe topologia aleasă. Există șase opțiuni de topologii: L3 Explicit Proxy, L3 Outbound, L3 Inbound, L2 Inbound, L2 Outbound și Existing Application.

Pentru această rețea este folosită topologia L3 Outbound Transparent Proxy în care așa cum poate fi observat și în diagrama de mai jos traficul intră în BIG-IP, este decriptat și apoi transmis către echipamentele de securitate, în final traficul este recriptat și trimis către aplicații.

Fig. 71 Topologia L3 Outbound Transparent Proxy

Configurarea SSLO presupune urmarea a șase pași: alegerea topologiei, adăugarea certificatelor, crearea serviciilor, gruparea serviciilor în lanțuri de servicii de securitate, setarea politicilor de securitate și configurarea regulilor de interceptare.

Fig. 72 Pașii de configurare SSL Orchestrator

În această lucrare topologia SSLO este de tipul L3 Outbound. Numele întregului lanț de servicii este ssl_F5_lic și se aplică pentru traficul ipv4 de tip TCP. După completarea câmpurilor se apasă Save&Next.

Fig. 73 Selectare si configurarea topologiei F5 SSL Orchestrator

În pagina SSL Configuration sunt specificate setările pentru topologia aleasă, în acest caz forward proxy, precum și opțiunile SSL de control asupra rețelelor clienților și serverelor.

Fig. 74 Configurarea profilelor de client si server

Profilul SSL cuprinde setările pentru partea de clienți și setările pentru partea de servere:

Cypher type (tipul cifrului). Acesta poate fi de tipul Cypher Group sau Cypher string. Pentru această implementare vom selecta Cipher String și vom insera Default, această configurație fiind valabilă pentru majoritatea tipurilor de implementări.

Certificate Key Chain. În lanțul cheilor de certificare sunt conținute certificatele și cheile private utilizate ca șablon pentru certificatele pe care le va emite F5-ul. În timp ce regenerarea imediată a certificatelor de server este în general ușoară, crearea de chei private este o operație care necesită o utilizare mai intensă a procesorului. Din acest motiv mecanismul SSL Forward Proxy emite certificate de server doar pentru cheia privată definită. Această setare permite utilizatorilor posibilitatea de a-și aplica propriul șablon de chei private și opțional să salveze cheia în FIPS-certified HSM pentru o mai mare siguranță.

CA Certificate Key Chain (Lanțul cheilor și certificatelor Autorității de Certificare). F5 SSL trebuie să resemneze certificatul serverului adresat clienților utilizând un certificat local al Autorității de Certificare, iar la rândul lor clienții trebuie să aibă încredere în Autoritatea locală. Această setare definește certificatul Autorității locale și cheia privată utilizate pentru operațiunea de resemnare. Training_CA este certificatul Autorității locale de Cerificare iar Herculon_SubCA este certificatul F5-ului de autoritatea locală.

Configurația pentru rețeaua de servere este asemănătoare celei de pe partea de clienți:

Cypher Type. Ca și în partea de client, se alege Cipher String și se completează cu DEFAULT.

Trusted Certificate Autority (Autoritatea de Certificare). Browserele furnizorilor își reactualizează periodic lista certificatelor provenite de la Autoritățile de Certificare pentru a ține pasul cu tendințele din industria de securitate, dar și pentru a adauga sau șterge Autoritățile de Certificare. BIG-IP vine cu o lista de certificate ale Autorităților de Certificare în care sunt certificatele din browserele furnizorilor, iar ea poate fi extinsă prin accesarea site-ului F5 Downloads. Pentru cazul de față se va utiliza ca.bundle.crt.

După completarea tutuor câmpurilor se va apăsa Save&Next.

Fig. 75 Configurarea profilului de server pentru SSLO

După salvarea configurației, următoarea pagină este Services List. Aici sunt definite serviciile de securitate care vor fi atașate lanțului SSLO pentru care există un catalog cu reprezentarea lor grafică.

Fig. 76 Serviciile care pot fi introduse în lanțul de securitate

Crearea unui serviciu de nivel 2 se face selectând din catalog serviciul L2 Inline și apoi apăsând butonul Add.

Câmpul Name se va completă cu numele cu care va fi afișat serviciul în F5.

În Network Configuration (Configurarea rețelei) se definesc interfețele de rețea care vor transmite traficul ce trebuie inspectat către serviciul inline, respectiv vor primi traficul inpectat.

Ratio. Serviciile inline sunt implicit balansate, iar această opțiune definește rația pentru fiecare dintre membrii pool-ului.

From BIGIP Vlan este câmpul în care se adaugă interfața prin care va trece traficul către serviciul inline. Având în vedere că anterior configurării serviciului am creat vlan-urile necesare, se alege Use Existing și din lista afișată se selectează OUT_L2_TO_FTD asociat interfeței 1.6 din F5. Pentru traficul de întoarcere de la echipamentul de nivel date, în cazul de față FTD, în câmpul

To BIGIP Vlan se completeeza cu vlan-ul IN_L2_FROM_FTD, asociat interfeței 1.7 din F5. La final se apasă Done.

Service action down. SSL monitorizează implicit pool-urile de echipamente de Securitate în care se face balansarea, iar dacă unul dintre membri pică, poate să continue să trimită trafic către serviciu (Ignore) sau poate să reseteze tot traficul (Reset, Drop). Vom alege opțiunea Ignore.

Enable Port Map. Această setare permite SSLO să remapeze portul traficului HTTPS care tranzitează acest serviciu. Această opțiune este utilă când un serviciu de securitate definește traficul de pe portul 443 ca trafic HTTPS criptat și în mod implicit îl ignoră. Spre exemplu remaparea traficului HTTPS pe portul 8080 permite serviciului de securitate să inspecteze traficul. În cazul de față nu se va face remapare.

IRules. iRule-ul definit pe serviciu afectează doar traficul care tranzitează acel serviciu, este important faptul că deși aceste iRule-uri nu trebuie utilizate pentru controlul traficului, trebuie folosite pentru a vedea sau modifica traficul de la nivel aplicație. Spre exemplu un iRule aplicat în acest caz ar putea fi utilizat pentru a vedea sau modifica traficul HTTP spre sau dinspre serviciu. În cazul de față nu va fi adăugat nici un iRule. La final se apasă Save.

Fig. 77 Configurarea serviciului de nivel date

Serviciul de nivel IP care în cazul rețelei create este Firepower Threat Defense, se adaugă apăsând pe serviciul Generic Inline Layer 3 din catalog.

La fel ca la serviciul de nivel 2, câmpul Name se completează cu numele ce va fi afișat în F5.

Setarea IP Familiy stabilește familia IP care va fi folosită de acest serviciu, se va alege IPv4.

Când opțiunea Auto Manage Address este activată, se generează un set de ip-uri unice, nerutabile care să fie folosite pentru serviciul de securitate. Dacă este dezactivată, adresele ip trebuie configurate manual, recomandat este să rămână pe modul enabled.

To Service Configuration se referă la traficul dinspre F5 către interfața de intrare a serviciului de securitate, adică a FTD-ului.

To Service cu opțiunea Auto Manage Address această adresă ip va fi predefinită, astfel interfața de intrare a serviciului trebuie să facă parte din aceeași subrețea. În cazul de față ip-ul predefinit este 198.19.64.7/25, iar interfața din FTD va primi 198.19.64.61/25.

VLAN va fi completat cu un vlan existent, configurat anterior și anume OUT_L3_TO_FTD asociat interfeței 1.4 din F5.

Service Down Action are acceași utilizare ca în cazul serviciului de nivel date și va rămâne setat pe Ignore.

L3 Devices definește adresa ip de pe partea de intrare a traficului în serviciul de nivel IP. Pot fi definite mai multe adrese ip între care să se facă balansarea. Ip-ul folosit pe interfața FTD este 198.19.64.61/25.

Fig. 78 Configurarea serviciului de nivel IP

From Service Configuration definește conexiunea dinspre FTD către SSLO.

From Service cu opțiunea de Auto Manage Addresses activată stabilește adresa ip pentru interfața de F5, în acest caz 198.19.64.245/25. La rândul său adresa de pe interfața FTD de ieșire trebuie să facă parte din aceeași subrețea.

VLAN va fi completat cu numele IN_L3_FROM_FTD, acesta fiind vlan-ul asociat cu interfața 1.5 din FTD

Manage SNAT Settings este opțiunea de activare a SNAT (source NAT) pentru un serviciu de nivel IP sau HTTP. Principala utilizare a sa este scalarea SSLO orizontală, unde echipamentele SSLO independente sunt scalate în spatele unui balansor separat dar împart aceleași servicii de nivel IP/HTTP inline. SNAT permite echipamentului de nivel IP/ HTTP să știe către care SSLO să trimită pachetele pentru rutare. Scalarea SSLO necesită ca opțiunea Auto Manage să fie dezactivată pentru a putea aloca câte un spațiu de adrese separate pentru fiecare SSLO. În cazul de față va rămâne setat pe None.

Câmpul iRules are aceeași utilizare ca cel de la serviciul de nivel date și rămâne necompletat. În final se apasă Save.

Fig. 79 Configurarea serviciului de nivel IP

Serviciul de TAP constă într-un echipament pasiv care doar primește o copie a traficului fără a-l retrimite înapoi către F5. Pentru configurare se selectează serviciul TAP din catalog.

După completarea câmpului Name, în câmpul Mac Address se trece adresa MAC dacă serviciul nu este direct conectat în F5 sau o adresa IP arbitrară dacă echipamentul este direct conectat. Rolul de serviciu de TAP aparține unei mașini virtuale care rulează Ubuntu și pe care am instalat aplicația de monitorizare Wireshark.

Opțiunea VLAN definește interfață F5 conectată în serviciul TAP. Vlan-ul va fi SEND_ONLY iar interfața 1.3. Setarea Enable Port Remap va rămâne dezactivată. La final se apasă Save&Next.

Fig. 80 Configurarea serviciului de TAP

Fig. 81 Pașii de configurare SSL Orchestrator

După stabilirea serviciilor ce vor fi utilizate, următorul pas este configurarea Service Chain care permite structurarea serviiilor în liste. În funcție de cerințele mediului, lanțurile de servicii pot conține seturi de servicii noi sau care au mai fost utilizate și diferite tipuri de trafic care pot fi asociate la diferite lanțuri de servicii. Spre exemplu traficul HTTP ar trebui să treacă prin toate serviciile, în timp ce traficul non-HTTP să traziteze doar un subset, iar traficul destinat serviciilor bancare să nu fie decriptat dar totuși să treacă printr-un set redus de servicii.

Fig. 82 Inspecția traficului HTTP

Pentru crearea lanțului de servicii se apasă Add și se completează corespunzător câmpurile disponibile astfel:

Name – definește numele lanțului de servicii.

Services – aici pot fi selectate oricâte servicii sunt necesare, iar pentru acest lucru trebuie selectate și mutate în coloana Selected Service Chain Order unde pot fi ordonate în funcție de necesități. La final se salvează apăsând Save.

Fig. 83 Configurarea lanțurilor de servicii de securitate

Pentru exemplificarea cât mai evidentă a vizibilității SSL cu ajutorul F5 și FTD, în topologia creată am configurat șase tipuri de lanțuri de servicii de Securitate, fiecare dintre ele este o combinație unică de servicii și este destinat unui anumit tip de trafic. În imaginea de mai jos se pot observă lanțurile de servicii configurate.

Fig. 84 Lanțurile de securitate configurate pe F5 SSLO

Security Policy. Politicile de Securitate sunt seturi de reguli ce guvernează modul în care SSLO procesează traficul: să permită sau nu traficul, să decripteze sau nu traficul și prin care lanț de servicii să fie trimis traficul.

În imaginea de mai jos sunt prezentate o parte din politicile configurate pentru această topologie. Astfel, pentru traficul din domeniul financiar și cel medical traficul va trece prin SSLO fără să fie inspectat, site-urile cu specific din aria automobilelor vor fi blocate fără inspecția traficului, pentru mass-media traficul va fi trimis către servciul de TAP, iar pentru site-urile guvernamentale către serviciul de nivel date. Restul traficului va fi afișat în TAP și inspectat de FTD.

Fig. 85 Politici de securitate

Crearea unei noi reguli se face apăsând Add urmată de atribuirea unui nume în câmpul Name. Din Conditions se alege SNI Category și apoi tipul de trafic. Din câmpul Action se poate alege Reject sau Allow, respectiv respinge sau permite. Din SSL Forward Proxy Action selectarea opțiunii Bypass presupune trecerea neinspectată a traficului, iar pentru cazul contrar se alege Intercept. Regula trebuie asociată lanțului de servicii, lucru realizat din câmpul Service Chain. La final se apasă Save&Next.

5.5 Testarea soluției implementate

După instalarea tuturor mașinilor virtuale, asigurarea comunicației dintre ele, configurarea lor și integrarea în lanțul de servicii de Securitate al F5 SSL Orchestrator, este importantă reluarea întregului parcurs al traficului prin rețea, pentru demonstrarea vizibilității pe care o oferă asupra traficului criptat.

Fig. 86 Topologia rețelei

Testarea soluției poate fi realizată prin deschiderea browserului pe mașina client și accesarea unei pagini web de tip https, spre exemplu https://www.google.com. Odată ce site-ul s-a deschis în browser, poate fi deschis certificatul site-ului și verificat dacă a fost semnat de Autoritatea de Certificare setată pe sistemul F5. Aceasta confirmă că funcționalitatea de SSL forwarding Proxy a fost activate pe SSL Orchestrator și funcționează corect.

Fig. 87 Certificarea site-ului cu certificatul SSL Orchestrator

În funcție de lanțul de servicii de securitate asociat unui anumit tip de trafic și configurat în Security Policies din SSL Orchestrator, traficul va fi trimis decriptat sau nu către FTD, către serviciul de TAP sau către ambele, iar apoi firewall-ul îl va inspecta și îl va trimite către F5 care îl va recripta și trimite către destinație.

Așa cum poate fi observat din captura de mai jos, făcută dinspre utilizatorul Ubuntu_Client_Lic (10.202.121.44) către site-ul http://www.upt.ro pot fi extrase mai mult decât suficiente informații încât să ne dăm seama ce pagină vrea utilizatorul să acceseze, de pe ce sistem de operare îl accesează și ce browser folosește. În plus putem vedea și informații despre protocolul utilizat de pagină web accesată, în acest caz HTTP 1.1. Comanda pe care am folosit-o pentru a vedea traficul de pe interfața OUT_L3_TO_FTD, adică dinspre F5 către FTD pentru traficul făcut de utilizator către pagină www.upt.ro este tcpdump –Xi OUT_L3_TO_FTD dst host www.upt.ro. Accesul în linia de comandă l-am făcut cu utilitarul Putty, iar credențialele utilizate au fost root cu parola default.

Fig. 88 Captură trafic decriptat

Traficul către pagina web www.upt.ro se potrivește pe regula din F5 potrivit căreia tot traficul care nu ține de domeniul financiar, medical, guvernamental, al știrilor și mașinilor va fi interceptat, adică decriptat și trimis către serviciul IP al FTD-ului pentru inspecție.

Fig. 89 Reguli SSL Orchetsrator

Atunci când se accesează site-ul www.medlife.ro, traficul criptat arată că în captura de mai jos, de remarcat fiind și faptul că serviciul către care este trimis traficul este ssloS_INLINE_L3_SERVICE.

Fig. 90 Captură trafic criptat

Potrivit regulii din politica de securitate Din SSL Orchestrator, site-urile dedicate autovehiculor, vor fi blocate. Astfel, de pe masina virtuala Ubuntu_Client_Lic, link-uri precum https://www.audi.com sau https://www.bmw.com vor fi inaccesibile.

Fig. 91 Conexiune blocată de regulile SSL Orchestrator

Mai departe, traficul ajunge în FTD pentru inspecție. Conexiunile sunt afișate detaliat în pagina Connection Events. Folosind comanda nslookup din Windows putem afla cu ușurință că ip-ul site-urilor, spre exemplu adresa https://ing.ro este asociată ip-ului 193.17.195.60, https://www.garantibank.ro are 217.68.219.10, http://www.upt.ro 193.226.10.230 etc. Sunt afișate data la care s-a realizat traficul, dacă a fost permis, ce adresa ip a inițiat traficul, către cine, țara unde se află serverul pentru conținutul paginii web, traseul traficului prin echipament, dar și informații despre politica aplicată și regula corespunzătoare ei și despre tipul de analiză și inspecție realizat. Este permisă adăugarea de câmpuri suplimentare dacă sunt necesare mai multe date legate de trafic.

Fig. 92 Afișarea conexiunilor in timp real in FTD

Eficiența inspecției de pe firewall am testat-o accesând pagina https://2016.eicar.org/85-0-Download.html care conține fișiere pentru testarea produselor de securitate împotriva diverselor atacuri.

Fig. 93 Descarcarea unui fisier malițios

Accesul pe pagină a fost făcut fără nici un fel de restricții, iar acest lucru poate fi obervat și în conexiunile din FTD.

Fig. 94 Conexiune permisă către site-ul 2016.eicar.com

Dupa descarcarea fisierului si reaccesare paginii, aceasta a devinit indisponibila.

Fig. 95 Pagină blocată din motive de securitate

FTD afișează destinatarul că fiind blocat, din cauza detectării prin politica de intruziune a unui fișier nesigur.

Fig. 96 Trafic blocat de FTD

Pe aplicația Wireshark instalată pe Ubuntu_TAP_Client detaliile despre conexiuni sunt mult mai exacte, ceea ce oferă posibilitatea analizei extrem de minuțioase a pachetelor, cu condiția ca ele să nu fie criptate, iar la acest capitol SSL Orchestrator este cel care se ocupă.

Fig. 97 Captură trafic decriptat cu Wireshark

Concluzii

Această lucrare de diplomă este o analiză teoretică dar mai ales practică a modului în care poate fi îmbunătățită securitatea rețelelor prin integrarea mai multor echipamente fizice și virtuale într-un lanț de servicii de securitate către care mai apoi, în mod organizat, să fie trimis traficul în funcție de categoria din care face parte sau și de necesitatea de a fi inspectat.

Concluziile studiul teoretic pe care l-am realizat sunt că implementarea protocoalelor SSL și a succesorului său TLS a fost adoptată de marea majoritate a organizațiilor că soluție pentru securizarea comunicațiilor IP. SSL/TLS asigură confidențialitate și securitate comunicațiilor, însă în același timp crează și dificultăți pentru echipamentele dedicate inspecției și criptării traficului. Pe scurt, comunicațiile criptate nu pot fi văzute în clar și astfel ajung să treacă fără a fi inspectate, creând puncte oarbe în sistemul de securitate. Devin riscuri considerabile pentru o organizație întrucât atacatorii ar putea ascunde trafic periculos în interiorul traficului criptat. Decriptarea traficului SSL/TLS de către echipamentele de inspecție poate conduce către o scăderea considerabilă a performanțelor acestora, mai ales când vine vorba de certificatele de 2048 de biți.

Integrarea F5 cu soluția Cisco Advanced Malware Protection (AMP) poate rezolva cele două provocări SSL/TLS. F5 Herculon SSL Orchestrator centralizează inspecția traficului SSL de-a lungul arhitecturilor complexe de securitate, permițând implementarea flexibilă a decriptării și recriptării traficului utilizătorilor. De asemenea, permite orchestrarea inteligentă a traficului utilizând un lanț de servicii dinamic și un management bazat pe politici. Traficul decriptat este apoi inspectat de unul sau mai mai multe firewall-uri Cisco (Next-Generation Firewall – NGFW), care au capabilitatea de a preveni amenințările inițial nevăzute și bloca atacurile zero-day. Firewall-ul Cisco Firepower Treat Defense elimina punctele oarbe introduse de SSL și închide breșele care ar putea crea oportunități adversarilor.

Integrarea celor două soluții, F5 și Cisco, permite organizațiilor gestionarea inteligentă a traficului SSL și totodată oferă vizibilitate asupra unui vector cheie pe care atacatorii îl utilizează adesea în exploatarea vulnerabilităților, stabilirea canalelor de comandă și control și furtul datelor. Fără vizibilitatea asupra SSL este imposibil de identificat și prevenit amenințările de masă.

Partea practică este reprezentată de o rețea virtuală dezvoltată într-un laborator, formată din mașinile virtuale Ubuntu, Firepower Management Center, Firepower Threat Defense și F5 SSL Orchestrator. Topologia rețelei este gândită astfel încât să fie asemănătoare celei dintr-o organizație în care utilizatorii au acces la internet trecând prin infrastructura de securitate. Peste topologia fizică, prin intermediul funcționalităților F5 SSL Orchestrator am creat o topologie logică în care traficul este împărțit pe categorii și direcționat către lanțul de servicii de securitate corespunzător. Cu ajutorul mașinii Firepower Management Center în care am înregistrat firewall-ul Cisco Firepower Threat Defense, am configurat atât platforma echipamentului cât și politicile și regulile pentru securizarea rețelei.

Am ales această temă deoarece mă pasionează domeniul dar și pentru că din punctul meu de vedere securitatea traficului care traversează internetul își pune amprenta începând de la simplul utilizator de internet până la marile companii din intreaga lume. În plus a reprezentat o provocare să instalez și să configurez SSL Orchestrator, fiind un produs nou pentru mine.

Proiectul realizat poate fi îmbunătățit prin configurarea de reguli mult mai granulare, specifice fiecărui tip de trafic, adăugarea de servicii suplimentare și a unei mai mari diversități de echipamente. Îmi propun să continui studiul în acest sens și să aplic ceea ce am învățat prin acest proiect în rețelele pe care le voi configura în viitor.

Bibliografie

***, Basics of Digital Certificates and Certificate Authority, https://sites.google
.com/site/ddmwsst/digital-certificates.

***, F5 Herculon SSL Orchestrator: Setup, Version 13.0-2.3, F5 Networks, 2017.

***, F5 Networks – SSL Orchestrator 5.1 (14.1). Lab Guide, 2018.

***, F5 Networks Training, F5-Administering BIG-IP v11 – Student Guide, United Kindom, 2014.

***, F5 SSL Orchestrator and Dynamic Service Chains, https://www.f5.com/content
/dam/f5/corp/global/pdf/products/ssl-orchestrator-overview.pdf.

***, https://en.wikipedia.org/wiki/Forward_secrecy.

***, https://resources.infosecinstitute.com/ssl-attacks/#gref.

***, https://ro.wikipedia.org/wiki/Disjunc%C8%9Bie_exclusiv%C4%83.

***, https://software.cisco.com/download/home/286259687/type/286271056/release
/6.2.3.10.

***, https://software.cisco.com/download/home/286306503/type/286306337/release/6.2.3.

***, https://www.digicert.com/ssl/.

***, https://www.digicert.com/ssl/.

***, https://www.digicert.com/ssl/.

***, https://www.romarg.ro/certificate-ssl/validare-domeniu.html.

***, https://www.snort.org/faq/what-is-snort.

***, Modelul OSI; Conversii de date, http://www.cs.ucv.ro/~luci/RC_CN/new/lucra
rea1.pdf.

***, Raport cu privire la alertele de securitate cibernetică procesate de CERT-RO în anul 2016, https://www.cert.ro/vezi/document/raport-alerte-cert-ro-2016.

***, RFC 791 – Internet Protocol, 1981.

***, SSL 3.0 Protocol Vulnerability and POODLE Attack, 2016, https://www.us-cert.gov
/ncas/alerts/TA14-290A.

***, The Advanced Encryption Standard Algorithm, https://www.commonlounge.com/
discussion/e32fdd267aaa4240a4464723bc74d0a5.

***, The F5 SSL Orchestrator and Cisco Firepower Solution: SSL Visibility with Service Chaining for Advanced Malware Protection, F5 Networks, 2018.

***, The F5 SSL Orchestrator and Palo Alto Networks Next-Gen Firewall Solution: SSL Visibility with Service Chaining for Advanced Threat Analysis and Prevention, F5 Networks, 2017.

***, What is an SSL Certificate and How Does it Work, https://www.digicert.com/ssl/.

Alex Tatistcheff, Todd Lammle, Cisco Firepower 6.x with Firepower Threat Defense, Cisco Press.

Alexis Kleinman, The Heartbleed Bug Goes Even Deeper Than We Realized — Here’s What You Should Do, 2014, https://www.huffpost.com/entry/heartbleed-routers_n_5132306?
guccounter=1&guce_referrer=aHR0cHM6Ly9yby53aWtpcGVkaWEub3JnLw&guce_referrer_sig=AQAAAEPdD1vLY6rXu6_F43daMwgaWR5qL4OXoFx0lBollwRadAW9UFwpVSO7p0NzOZe4Cto1Qv_diinld8bvv-hQtYGNnh9_RXsPkMeqs1ZUiL
JBX1TvHrM65H1DeaRMXzgTinS7DFz4pwf56qz-l5ZKa2ofe3bR79_EP9PitCcdfcZB.

Andrei Dumitrescu, Servere Proxy. Ce sunt si la ce se folosesc, https://www.cr
ystalmind.ro/wordpress/servere-proxy-ce-sunt-si-la-ce-se-folosesc/.

Ann-Marie de Veer, Heartbleed: NSA's Bloodletting of Vulnerabilities, 2014, https://deveer.org.uk/dvm/index.php/Heartbleed:_NSA%27s_Bloodletting_of_Vulnerabilities.

Diana-Costinela DRAGU, Vulnerabilitate a protocolului OpenSSL – Heartbleed Bug, http://www.securitatea-informatiilor.ro/stiri-de-ultima-ora/vulnerabilitate-a-protocolului-openssl-heartbleed-bug/.

E. Rescorla, Internet Engineering Task Force, RFC8446 – The Transport Layer Security (TLS) Protocol Version 1.3, 2018, https://tools.ietf.org/html/rfc8446.

E. Rescorla, T. Dierks, Network Working Group, RFC2246 – The Transport Layer Security (TLS) Protocol, Version 1.1, 2006, https://www.ietf.org/rfc/rfc4346.txt.

Frank M. Groom; Stephan S. Jones; Kevin Groom, Network and Data Security for Non-Engineers, Ed. Auerbach Publications, 2016.

Ilya Grigorik, HTTP Protocols, OReilly Media Inc., 2017, https://learning.oreilly.
com/library/view/http-protocols/9781492030478/#toc.

Ioan-Cosmin Mihai, Algoritmul de criptografie AES, http://www.securitatea-inform
atiilor.ro/solutii-de-securitate-it/algoritmul-de-criptografie-aes/.

Jasmin Henry, 3DES is officially retrired, 2018 https://www.cryptomathic.com/news-eve
nts/blog/3des-is-officially-being-retired.

Jazib Frahim; Qiang Huang, SSL Remote Access VPN, cap. 2, Cisco Press, 2008, https://
learning.oreilly.com/library/view/sslremote-access/9780768681956/ch02.html.

Josh Fruhlinger, What is the Heartbleed bug, how does it work and how was it fixed?, https://www.csoonline.com/article/3223203/what-is-the-heartbleed-bug-how-does-it-work-and-how-was-it-fixed.html.

Josh Lake, What is DES encryption and how does DES work, 2019, https://www.comparitech.com/blog/information-security/3des-encryption/.

Joshua Davies, Implementing SSL/TLS using Cryptography and PKI, Ed Wiley, Indianopolis, 2011.

Nazmul Rajib, Cisco Firepower Threat Defense (FTD), Configuration and Troubleshooting Best Practices for the Next-Generation Firewall (NGFW), Next-Generation Intrusion Prevention System (NGIPS) and Advanced Malware Protection (AMP), Cisco Press, Indianopolis, 2017

Network Working Group, RFC 2616- Hypertext Transfer Protocol – HTTP/1.1, ultima versiune 02.03.2013, https://datatracker.ietf.org/doc/rfc2616/.

R. Fielding, UC Irvine, J. Gettys, RFC 2616- Hypertext Transfer Protocol – HTTP/1.1, 1999, https://www.ietf.org/rfc/rfc2616txt.

Ray Pompon, 2018 Application Protection Report, https://www.f5.com/content/dam/f5-labs-v2/article/pdfs/F5Labs_2018_Application_Protection_Report.pdf.

Troy Hunt, Everything you need to know about the Heartbleed SSL bug, 2014, https://www.troyhunt.com/everything-you-need-to-know-about3/.

Valentin DIDE, Vulnerabilitatea HTTPS, http://www.securitatea-informatiilor.ro/vuln
erabilitati-informatice/vulnerabilitatea-https/.

Wen Liu, OSI Model Reference Chart, 2016, https://learningnetwork.cisco.com/docs/DOC-30382.

Wendell Odom, CCNENT/CCNA ICND1 100-105 Official Certification Guide, Ed. CiscoPress, Indianopolis, 2016.

Zoran Constantiescu, Gabriela Moise, Criptarea Informatiei – Ghid practic, Ed. Universității Petrol-Gaze, Ploiești, 2013.

DECLARATIE DE AUTENTICITATE