Sistemul de Prevenire a Scurgerilor de Date, Bazat pe Informatiile Colectate din Retea

Listă de figuri

Figura 1.1 – Nivelele modelului de referință OSI și ale modelului TCP/IP 10

Figura 1.2 – Protocoale TCP/IP 12

Figura 1.3 – Lanț de comunicații HTTP folosind intermediari 13

Figura 1.4 – Modelul operațional FTP [1] 17

Figura 1.5 – Procesul Client/Server TCP/IP 19

Figura 2.1 – Clientul solicită pagina Google România (https://www.google.ro/) 22

Figura 2.2 – Diagramă de rețea – trebuie luate în considerare plângerile utilizatorului atunci când se decide locul de plasare al analizorului [2] 22

Figura 2.3 – Testarea unui hub [2] 24

Figura 2.4 – Setarea unui TAP fără agregare trafic și două sisteme Wireshark [2] 24

Figura 2.5 – TAP-urile cu agregare trafic combină traficul bidirecțional într-un singur port de ieșire [2] 25

Figura 2.6 – TAP de regenerare [2] 25

Figura 2.7 – TAP de agregare conexiune [2] 26

Figura 2.8 – Traficul de pe portul 4 este duplicat (spanned) la portul 1 [2] 27

Figura 2.9 – Wireshark decodează câmpurile VLAN dacă placa de rețea și driverul le înaintează [3] 27

Figura 2.10 – Plasarea analizorului pe fiecare parte a unui router [2] 28

Figura 2.11 – Se plasează analizorul aproape de client pentru a analiza traficul din perspectiva acestuia [2] 29

Figura 2.12 – Filtrele de captură sunt aplicate doar pachetelor care sosesc din rețea [2] 30

Figura 2.13 – Setarea filtrelor în opțiunile interfeței analizate 30

Figura 2.14 – Un flux de date video poate fi reasamblat folosind Follow UDP Stream [3] 32

Figura 2.15 – Valoarea numărului de index al stream-ului se găsește în antetul TCP 33

Figura 2.16 – Reasamblarea unei sesiuni HTTP furnizează detalii privind cererile și răspunsurile HTTP 33

Figura 2.17 – Reasamblarea unui clip video descărcat prin transfer FTP 34

Figura 2.18 – Adăugarea cheii RSA în setările SSL 35

Figura 3.1 – HTTP folosește un model cerere/răspuns [3] 37

Figura 3.2 – Încercări multiple nereușite de conexiune HTTP creează un tipar în Wireshark [3] 38

Figura 3.3 – Cererea POST a clientului este nereușită și indică o problemă a serverului web [3] 39

Figura 3.4 – Activarea opțiunii de reasamblare a fluxurilor TCP 39

Figura 3.5 – Clientul nu poate stabili o conexiune în modul pasiv [3] 41

Figura 4.1 – Arhitectura globală a sistemului de prevenire a scurgerilor de date, bazat pe informațiile colectate din rețea 43

Figura 4.2 – Arhitectura modulară a soluției de securitate – Software Blade Architecture [5] 44

Figura 4.3 – Setarea adresei IP pentru interfața de managemement a aplicației de securitate 44

Figura 4.4 – Instalare Security Gateway și Security Management 45

Figura 4.5 – Configurarea adreselor IP ale interfețelor de rețea 45

Figura 4.6 – Setarea adresei IP a gateway-ului rețelei externe 46

Figura 4.7 – Mașini virtuale realizate folosind VMware Workstation 10 46

Figura 4.8 – Instalarea SmartConsole R77 47

Figura 4.9 – Accesarea SmartDashboard 47

Figura 4.10 – Configurarea rețelelor în SmartDashboard 48

Figura 4.11 – Aplicațiile de securitate disponibile pentru gateway 48

Figura 4.12 – Setarea domeniului 49

Figura 4.13 – Activarea portalului web pentru DLP și specificarea serverului de mail pentru trimiterea de notificări 49

Figura 4.14 – Protocoale 49

Figura 4.15 – Finalizarea configurațiilor de bază 50

Figura 4.16 – Specificarea sursei transmisiunii 50

Figura 4.17 – Configurarea interfeței eth0 pentru serverul de mail din rețeaua internă 51

Figura 4.18 – Configurarea interfeței eth0 pentru serverul de mail din rețeaua externă 52

Figura 4.19 – Configurarea sistemului de nume de domeniu pentru serverul de mail intern 52

Figura 4.20 – Configurarea sistemului de nume de domeniu pentru serverul de mail extern 52

Figura 4.21 – Regula de fingerprint 53

Figura 4.22 – Specificarea locației din rețea unde se află depozitul pentru tehnica de fingerprint 53

Figura 4.23 – Scanarea directorului de fingerprint de la locația specificată 54

Figura 4.24 – Locul de setare a watermark-ului dorit 54

Figura 4.25 – Expedierea mail-ului de test 55

Figura 4.26 – Se primește pe mail notificarea DLP de la gateway 55

Figura 4.27 – Raportul incidentului înregistrat în SmartView Tracker 56

Figura 4.28 – Mail-ul în carantină în portalul de DLP 56

Figura 4.29 – Validarea și motivația utilizatorului pentru trimiterea acestui mail 57

Figura 4.30 – Confirmarea transferului 57

Figura 4.31 – Mail-ul recepționat de către serverul extern 58

Figura 4.32 – Documentul descărcat cu watermark inclus 58

Figura 4.33 – Clientul UserCheck instalat pe terminalul din rețeaua internă 59

Figura 4.34 – Cuvintele cheie 59

Figura 4.35 – Regula aplicată 59

Figura 4.36 – Transfer blocat de gateway 60

Figura 4.37 – Raportul în SmartView Tracker 60

Figura 4.38 – Activarea opțiunii de HTTPS Inspection 61

Figura 4.39 – Regula de inspecție a traficului HTTPS 61

Figura 4.40 – Crearea unui tip de date pe baza atributelor fișierului 62

Figura 4.41 – Raportul din SmartView Tracker la încărcarea pe un site securizat prin SSL a unui document ce a încălcat o regulă 62

Figura 4.42 – Serverul de FTP aflat pe mașina virtuală din rețeaua externă către care se va trimite documentul 63

Figura 4.43 – Clientul de FTP și notificarea apărută la transferarea documentului ce a încălcat regula 63

Figura 4.44 – Raportul din SmartView Tracker referitor la transferal FTP efectuat 64

Lista acronimelor

API – Application Programming Interface – Interfață de programare a aplicațiilor

ARP – Address Resolution Protocol – Protocolul de rezoluție a adresei

ATM – Asynchronous Transfer Mode – Mod de transfer asincron

CRC – Cyclic Redundancy Check – Control Redundant Ciclic

DHCP – Dynamic Host Configuration Protocol

DLP – Data Loss Prevention

DNS – Domain Name System – Sistem de nume de domeniu

DTP – Data Transfer Process – Procesul de transfer a datelor

FTP – File Transfer Protocol – Protocol de transfer de fișiere

GUI – Graphical User Interface

HTTP – Hypertext Transfer Protocol

HTTPS – Hypertext Transfer Protocol Secure

ICMP – Internet Control Message Protocol

IDS – Intrusion Detection System

IP – Internet Protocol – Protocolul Internet

IT – Information Technology

LAN – Local Area Network – Rețea locală

MAC – Media Access Control

MIME – Multipurpose Internet Mail Extensions

MTP – Mail Transfer Protocol – Protocolul de transfer a corespondenței

OSI – Open Systems Interconnection – Interconectarea Sistemelor Deschise

PC – Personal computer – Calculator personal

Pcap – Packet Capture

PI – Protocol Interpreter

RF – Radio Frequency – Frecvență radio

RFC – Request For Comments – Note de cercetare

RIP – Routing Information Protocol – Protocolul de rutare a informației

SMTP – Simple Mail Transfer Protocol – Protocolul simplu de transfer a corespondenței

SNMP – Simple Network Management Protocol

SPAN – Switched Port Analysis

SSID – Service Set Identifier

SSL – Secure Sockets Layer

TAP – Test Access Port

TCP – Transport Control Protocol – Protocolul de control al transmisiei

TLS – Transport Layer Security – Securitate la nivelul de transport

UDP – User Datagram Protocol – Protocolul Datagramelor Utilizator

URI – Uniform Resource Identifier – Identificator uniform de resurse

URL – Uniform Resource Locator – Localizator uniform de resurse

VLAN – Virtual Local Area Network – Rețea locală virtuală

WAN – Wide Area Network – Rețea de arie largă

WLAN – Wireless Local Area Network – Rețea locală fără fir

WWW – World Wide Web

Introducere

În lucrarea de față este realizată implementarea și testarea cu reguli personalizate a unui sistem de prevenire a scurgerilor de date, bazat pe informațiile colectate din rețea (în literatura de specialitate se folosește termenul de Data Loss Prevention – DLP). Aceasta ramură a securității informatice a cunoscut o dezvoltare considerabilă de la apariția ei, devenind între timp indispensabilă pentru companii, dată fiind multitudinea de intrumente disponibile pentru distribuirea de informație în exteriorul organizației.

Soluțiile disponibile în acest moment au devenit mult mai intuitive și convenabile, implementările lungi, dificultatea administrării și costurile ridicate asociate cu produsele tradiționale de DLP devenind rapid istorie. Interfețele de control centralizate și posibilitatea remedierii incidentelor în timp real au transformat această tehnologie în ceva ce poate fi implementat fără a fi nevoie de personal suplimentar și fără riscul introducerii de întârzieri în trimiterea de informații sau blocarea eronată a documentelor.

Tehnologia DLP este diferită de celelalte soluții de securitate cum ar fi firewall-uri sau sisteme de detecție/prevenire a intruziunilor prin faptul că spre deosebire de acestea, ce caută orice poate reprezenta o amenințare pentru organizație, atenția este concentrată spre identificarea informațiilor sensibile, conținut de nivel critic pentru organizație.

Companiile consumă foarte mult timp și bani pe pregătirea angajaților cu privire la politicile de securitate ale companiei și se poate asuma că scurgerile de date ca urmare a acțiunilor unui utilizator neatent ar trebuie să fie minime. Acest lucru nu este însă adevărat și se știe că majoritatea incidentelor de pierderi de date confidențiale sunt cauzate de astfel de utilizatori și acest lucru nu s-a schimbat în ciuda pregătirii angajaților. Monitorizarea traficului prezintă o imagine de ansamblu a cât de bine e respectată politica companiei, însă vizibilitatea nu e suficientă, pentru eliminarea scurgerilor de date atât neintenționate cât și intenționate fiind necesar controlul preventiv asigurat de DLP.

Pentru această lucrare s-au creat și testat reguli folosind configurația de mașini virtuale realizată pentru principalele protocoale responsabile de transferul de informație, și anume: SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol) și HTTP(S) (Hypertext Transfer Protocol (Secure)). Au fost de asemenea implementate cu succes diferitele tehnici disponibile în soluția de DLP utilizată, cum ar fi tehnica de fingerprinting ce permite scanarea unei locații din rețea și utilizarea acesteia pentru crearea de reguli.

Pentru transferul de mail au fost configurate două servere SMTP, unul în rețeaua internă și unul în rețeaua externă, astfel încât trimiterea mesajelor între ele să se poată realiza, iar soluția de DLP să poată folosi serverul intern pentru trimiterea de notificări utilizatorilor atunci când sunt încălcate reguli.

Rețele IP – Arhitecturi și protocoale

Prezentare generală

Modul de interacțiune al rețelelor din ziua de azi este controlat de suita de protocoale cunoscută sub numele de TCP/IP. Denumirea vine de la cele două protocoale cheie din acest standard care a fost în continuă dezvoltare și utilizare în ultimele 4 decenii. În acest timp a evoluat de la o tehnologie experimentală folosită pentru a conecta între ele un număr restrâns de calculatoare de cercetare la nucleul celei mai complexe rețele din istorie, și anume Internetul global, realizând legătura între miliarde de dispozitive.

IP (Internet Protocol – Protocolul Internet) este protocolul elementar la nivelul Rețea (nivelul trei) al modelului de referință OSI (Open Systems Interconnection – Interconectarea Sistemelor Deschise) și are ca funcție principală realizarea adresării (topologia logică) adică identificarea la nivel logic a dispozitivelor din rețea. O altă funcție importantă asigurată de acest protocol este aceea de rutare și anume determinarea căilor pentru interconectarea rețelelor.

TCP (Transport Control Protocol – Protocolul de control al transmisiei) este protocolul elementar la nivelul Transport (nivelul patru) și este responsabil de stabilirea și administrarea conexiunii logice, împărțirea datelor de la nivelul aplicație în segmente mai mici, detecția optimă și corecția erorilor și dimensionarea cantității de informație trimisă funcție de capacitatea de prelucrare a destinatarului.

IP și TCP sunt importante deoarece o mare parte din funcțiile critice ale TCP/IP sunt implementate la nivelele trei și patru. Suita de protocoale necesită însă diferite tehnologii și protocoale pentru a realiza o rețea funcțională care să furnizeze în mod adecvat utilizatorilor aplicațiile de care au nevoie. TCP/IP folosește propria sa arhitectură cu patru nivele (corespunde aproximativ modelului de referință OSI) și asigură un cadru pentru varietatea de protocoale ce constituie suita.

TCP/IP a fost dezvoltat inițial în anii 1970 ca o încercare de a defini un set de tehnologii pentru a utiliza o variantă timpurie a Internetului. Numele TCP/IP a apărut atunci când originalul protocol TCP a fost divizat în TCP și IP. Primele versiuni moderne ale acestor protocoale fundamentale au fost documentate în 1980 ca TCP versiunea 4 și IP versiunea 4.

Această suită de protocoale a fost la un moment dat doar unul din diferitele seturi de protocoale ce puteau fi folosite pentru a furniza funcționalite la nivelele Rețea și Transport. În ziua de azi încă există alte variante de suite de protocoale pentru Internet, însă TCP/IP este standardul acceptat în mod universal la nivel global. Creșterea popularității sale se datorează unui număr de factori importanți. Unii factori sunt de natură istorică și anume faptul că Internetul și TCP/IP au fost dezvoltate împreună, cu TCP/IP furnizând mecanismul pentru a implementa Internetul, în vreme ce alți factori țin de caracteristicile suitei de protocoale. Acești factori sunt:

Sistem integrat de adresare: TCP/IP include (ca parte a IP, în primul rând) un sistem pentru identificarea și adresarea dispozitivelor, atât pe rețele de mici dimensiuni, cât și pe rețele extinse. Sistemul de adresare este proiectat să permită dispozitivelor să fie adresate fără a lua în considerare cum fiecare rețea constitutivă este construită. În timp, mecanismele de adresare ale TCP/IP s-au îmbunătățit pentru a satisface nevoile rețelelor în continuă expansiune, în special Internetul. Sistemul de adresare are de asemenea o capacitate de administrare centralizată pentru Internet, pentru a asigura că fiecare dispozitiv are o adresă unică.

Proiectat pentru rutare: Spre deosebire de alte protocoale de la nivelul Rețea, TCP/IP este special conceput pentru a facilita rutarea de informație peste o rețea de complexitate arbitrară. TCP/IP este conceptual mai concentrat pe conexiunea de rețele decât pe conexiunea de dispozitive. Routerele TCP/IP permit transmisia de date între dispozitive aflate în rețele diferite transportând informația pas cu pas, de la o rețea la următoarea.

Independența rețelelor conectate: TCP/IP operează în principal de la nivelul trei la nivelele superioare, și este capabil să funcționeze pe aproape orice tehnologie de nivel inferior, inclusiv LAN-uri (Local Area Network – Rețea locală), LAN-uri fără fir și WAN-uri (Wide Area Network – Rețea de arie largă) de diferite tipuri. Această flexibilitate înseamnă că o varietate de rețele diferite pot fi conectate între ele folosindu-se TCP/IP.

Scalabilitate: Una din cele impresionante caracteristici ale TCP/IP este cât de scalabile s-au dovedit a fi protocoalele sale. De-a lungul deceniilor și-a demonstrat această calitate pe măsură ce Internetul a ajuns de la o mică rețea cu câteva calculatoare la un conglomerat de rețele cu miliarde de dispozitive.

Standarde și proces de dezvoltare accesibile: Standardele TCP/IP nu sunt brevetate ci standarde accesibile, disponibile în mod liber publicului. Mai mult, procesul folosit pentru a dezvolta standardele TCP/IP este, de asemenea, complet accesibil. Standardele și protocoalele TCP/IP sunt dezvoltate și modificate folosind în mod unic procedurile RFC (Request for comments), cu toți cei interesați invitați să participe. Astfel se asigură faptul că oricine interesat de protocoalele TCP/IP primește șansa de a oferi informații pentru dezvoltarea lor, și, de asemenea, se asigură acceptarea la nivel mondial a suitei de protocoale.

Universalitate: Toată lumea folosește TCP/IP.

Arhitectura TCP/IP și modelul TCP/IP

Modelul TCP/IP

Dezvoltatorii suitei de protocoale TCP/IP au creat propriul lor model architectural care să ajute la descrierea componentelor și funcțiilor suitei. Indiferent de modelul pe care îl folosești pentru a reprezenta funcționarea unei rețele, funcțiile pe care modelul le reprezintă sunt, în mare parte, aceleași. Aceasta înseamnă că modelele OSI și TCP/IP sunt foarte similare chiar dacă ele nu prezintă funcționalitatea rețelei exact în același mod. Există o corespondență evidentă între nivele TCP/IP și nivelele OSI, doar că nu este întotdeauna o relație de "unu la unu". Deoarece modelul OSI este utilizat la scară largă, arhitectura TCP/IP este explicată atât în ceea ce privește nivele TCP/IP, cât și nivele OSI corespunzătoare.

Nivelele modelului TCP/IP

Modelul TCP/IP folosește patru nivele ce reprezintă echivalentul logic al celor șapte nivele al modelului de referință OSI, prezentate în figura 1.1.

Figura . – Nivelele modelului de referință OSI și ale modelului TCP/IP

Nivelul Acces la Rețea (Network Access Layer)

Acest nivel este responsabil de plasarea pachetelor TCP/IP pe mediul de transmisie și de primirea acestor pachete de pe mediu. TCP/IP a fost realizat să fie independent de metoda de acces la rețea, formatul frame-urilor și mediul de transmisie. În acest mod, TCP/IP poate fi utilizat pentru a conecta diferite tipuri de rețele. Acestea include tehnologiile LAN cum ar fi Ethernet și Token Ring și tehnologiile WAN cum ar fi X.25 și Frame Relay. Independența de orice tehnologie de rețea oferă TCP/IP abilitatea de a fi adaptat la noi tehnologii cum ar fi ATM (Asynchronous Transfer Mode – Mod de transfer asincron).

Nivelul Acces la Rețea cuprinde nivelul legătură de date și nivelul Fizic ale modelului OSI. Trebuie notat faptul că nivelul Rețea nu ține cont de serviciile de secvențiere și confirmare ce pot fi prezente în nivelul Legătură de Date. Este presupus un nivel Acces la Rețea instabil, și realizarea de comunicații de încredere prin stabilire de sesiune și secvențiere și confirmare de pachete este responsabilitatea nivelului Transport.

Nivelul Internet

Acest nivel corespunde nivelului rețea din modelul de referință OSI (și de aceea este numit, uneori, nivel Rețea chiar și în discuțiile despre modelul TCP/IP) și este responsabil de adresare, împachetarea datelor și de funcțiile de rutare. Protocoalele de bază ale acestui nivel sunt IP, ARP (Address Resolution Protocol – Protocolul de rezoluție a adresei) și ICMP (Internet Control Message Protocol).

IP este un protocol rutabil responsabil de adresarea IP, rutarea, fragmentarea și reasamblarea pachetelor de date.

ARP este responsabil de convertirea adresei IP de la nivelul Internet la o adresă fizică de la nivelul acces la rețea.

ICMP este responsabil de funcțiile de diagnosticare și raportarea de erori datorate livrării fără succes a pachetelor IP.

Nivelul Transport

Nivelul Transport (cunoscut și sub numele de nivel Transport Host-to-Host) are ca scop principal facilitarea comunicației între două echipamente terminale (end-to-end) peste o rețea de comunicații multiple. Este responsabil de conexiunile logice ce se realizează între dispozitive și permite ca datele să fie trimise fie în mod nestabil (fără nicio garanție că informația va ajunge la destinație) sau în mod sigur (în care protocolul ține evidența informației trimise și a celei recepționate pentru a se asigura de transferul cu succces al acesteia, și re-trimite daca este necesar). Protocoalele cheie de la acest nivel sunt TCP și UDP (User Datagram Protocol – Protocolul datagramelor utilizator).

TCP oferă un serviciu de comunicație unu-la-unu, orientat pe conexiune și fiabil. TCP este responsabil de stabilirea unei conexiuni TCP, secvențierea și confirmarea pachetelor trimise, și de recuperarea pachetelor pierdute pe durata transmisiei.

UDP oferă un serviciu de comunicații unu-la-unu sau unul la mai mulți, fără conexiune și nedemn de încredere. UDP este folosit atunci când cantitatea de date de transferat este redusă (informație ce poate fi pusă într-un singur pachet), atunci când nu este dorit overhead-ul stabilirii unei conexiuni TCP sau când aplicațiile sau protocoalele de nivel superior asigură livrare demnă de încredere.

Nivelul Transport cuprinde responsabilitățile nivelului Transport al modelului de referință OSI și unele sarcini ale nivelului Sesiune din OSI.

Nivelul Aplicație

Nivelul Aplicație oferă aplicațiilor abilitatea de a accesa serviciile oferite de celelalte nivele protocoalele folosite de aplicații pentru schimbul de informație. Sunt multe protocoale la nivelul Aplicație și noi protocoale sunt mereu în dezvoltare.

Cele mai cunoscute protocoale de la nivelul Aplicație sunt cele folosite pentru schimbul de informație:

HTTP (Hypertext Transfer Protocol) este folosit pentru a transfera fișierele ce construiesc paginile Web ale World Wide Web.

FTP (File Transfer Protocol – Protocol de transfer de fișiere) este folosit pentru transferul de fișiere interactiv.

SMTP (Simple Mail Transfer Protocol – Protocolul simplu de transfer a corespondenței) este folosit pentru transferul de mesaje electronice (electronic mail sau e-mail) și atașamente.

Telnet este un protocol de emulare de terminale și este folosit pentru conectarea de la distanță la gazde din rețea.

În plus, următoarele protocoale de la nivelul Aplicație facilitează utilizarea și gestionarea rețelelor TCP/IP:

DNS (Domain Name System – Sistem de nume de domeniu) este folosit pentru a translata numele gazdei într-o adresă IP.

RIP (Routing Information Protocol – Protocolul de rutare a informației) este un protocol de rutare folosit de routere pentru schimbul informației de rutare pe o rețea de comunicații multiple IP.

SNMP (Simple Network Management Protocol) este folosit între o consolă de gestionare a rețelei și dispozitivele de rețea (routere, bridge-uri, hub-uri inteligente) pentru a colecta și face schimb de informații de administrare a rețelei.

Protocoale TCP/IP

TCP/IP este o suită de protocoale și de aceea se discută foarte des în funcție de protocoalele pe care le cuprinde. Fiecare protocol aparține de un anumit nivel din modelul arhitectural TCP/IP prezentat mai devreme . Fiecare protocol TCP/IP realizează un anumit subset din funcționalitatea totală necesară pentru a implementa o rețea sau o aplicație TCP/IP. Ele lucrează împreună pentru a permite TCP/IP să funcționeze ca un întreg.

Există câteva protocoale TCP/IP care sunt cunoscute ca fiind nucleul suitei, deoarece ele sunt responsabile pentru operațiunile sale de bază. Cu siguranță trebuie incluse aici protocoalele principale de la nivelul Internet și Transport: IP, TCP și UDP. Aceste protocoale de bază suportă multe alte protocoale, pentru efectuarea unei varietăți de funcții la fiecare nivel al modelului TCP/IP.

În ansamblu, există multe sute de protocoale și aplicații TCP/IP și din acest motiv vor fi prezentate doar cele considerate mai importante. Reprezentăm protocoalele TCP/IP ce vor fi discutate în această scurtă prezentare (o parte din ele definite mai sus) folosind modelul arhitectural cu patru etaje prezentat anterior.

Figura . – Protocoale TCP/IP

Protocolul HTTP

Succesul World Wide Web este rezultatul eficienței și utilității întregului sistem hipermedia implementat. HTTP este unul din cele mai cunoscute protocoale de software din rețelistică și este cel care transferă efectiv documentele hipertext și alte fișiere între serverele web și clienții web (browserele). El definește modul în care se realizează transferul de informație și se află la nivelul Aplicație al modelului TCP/IP.

Prima versiune a HTTP, HTTP/0.9, a făcut parte din World Wide Web la începuturile acestuia și era un protocol foarte simplu de cerere/răspuns cu capacități limitate, care putea transfera doar fișiere text. Prima versiune utilizată la scară largă a fost HTTP/1.0, un protocol mai complet care permite transferul multor tipuri de fișiere și resurse. Versiunea curentă este HTTP/1.1, care a sporit performanțele versiunii HTTP/1.0 cu o serie de caracteristici care îmbunătățesc eficiența transferurilor de informație și care abordează multe din necesitățile World Wide Web-ului modern aflat în continuă expansiune.

În forma lui cea mai simplă, procesul HTTP implică un singur client HTTP, de obicei un browser web pe dispozitivul client, și un server HTTP, mai bine cunoscut sub numele de server web. După ce o conexiune TCP/IP este realizată, cei doi pași ai comunicației sunt:

Cererea clientului: Clientul HTTP trimite un mesaj de cerere formatat conform regulilor standardului HTTP – o Cerere HTTP. Acest mesaj specifică informațiile pe care clientul dorește să le primească, sau include informații ce vor fi furnizate serverului.

Răspunsul serverului: Serverul citește și interpretează cererea. Acționează conform cererii și creează un mesaj de Răspuns HTTP, pe care îl trimite clientului. Mesajul de răspuns precizează dacă cererea a avut succes, și conține de asemenea conținutul informației cerute de client, dacă acestuia îi este permis accesul.

Modelul operațional simplu de tip client/server al HTTP devine mai complex atunci când dispozitive intermediare cum ar fi servere de tip proxy, tunele sau porți de acces sunt introduse pe calea de comunicație dintre client și server. HTTP/1.1 este special proiectat cu caracteristici care să îi permită transmiterea eficientă a cererilor și a răspunsurilor prin aceste dispozitive intermediare. Întregul set de echipamente implicat într-o comunicație de acest fel este numit lanț de comunicații și este prezentat în figura 1.3.

Figura . – Lanț de comunicații HTTP folosind intermediari

Toate mesajele HTTP sunt create în funcție de o structură a mesajului pe care standardul o denumește format generic de mesaj. Acest format este bazat pe standardele RFC 822 și MIME (Multipurpose Internet Mail Extensions) pentru e-mail, dar nu urmează cu exactitate aceste formate. Fiecare mesaj HTTP începe cu start-line, apoi conține o serie de antete de mesaj (headere), urmate de o linie liberă și opțional un conținut al mesajului. Conținutul mesajului poate conține o resursă cum ar fi un fișier ce urmează a fi transmis între client și server, numit entitate.

Formatul generic al mesajului HTTP este următorul:

<start-line>
<message-headers>
<empty-line>
[<message-body>]
[<message-trailers>]

Cererile HTTP sunt modalitatea prin care clienții HTTP cer serverelor să realizeze un anumit tip de acțiune, cum ar fi trimiterea unui fișier sau procesarea datelor de intrare ale utilizatorului. Fiecare mesaj de cerere începe cu request line care conține trei tipuri de informație esențiale: metoda (tipul de acțiune) cerută de client, URI-ul (Uniform Resource Identifier – Identificator uniform de resurse) resursei asupra căreia se dorește efectuare acțiunii și versiunea HTTP folosită de client. După linia de cerere urmează o serie de antete de mesaj asociate cererii, urmate de o linie liberă și apoi opțional, conținutul cererii.

Fiecare cerere HTTP trimisă de un client are ca rezultat unul sau mai multe răspunsuri HTTP ale serverului. Fiecare mesaj de răspuns începe cu un status line care conține numărul versiunii serverului HTTP, un cod numeric denumit status code și un text denumit reason phrase ce indică rezultatul procesării cererii clientului. Mesajul conține apoi antete asociate răspunsului, urmate de o linie liberă și opțional conținutul mesajului. De vreme ce majoritatea cererilor HTTP interoghează serverul pentru trimiterea unui fișier sau a unui alt tip de resursă, multe răspunsuri HTTP transportă o entitate în conținutul mesajului.

Fiecare cerere a unui client HTTP specifică un anumit tip de acțiune spre a fi realizată de server. În HTTP, aceste acțiuni nu sunt denumite comenzi ci mai degrabă metode. Cele mai comune trei metode HTTP sunt GET, care solicită unui server să returneze o resursă; HEAD, care returnează doar antetele asociate cu o resursă; și PUT, care permite unui client să trimită date unui server pentru procesare.

Deoarece numărul metodelor suportate de protocol este mic se poate crea impresia că protocolul este destul de limitat. De fapt, o mare parte din funcționalitatea din HTTP este implementate în antetele de mesaj (message headers) care redau detalii importante între clienți și servere. Unele antete pot apărea doar în cererile HTTP, altele doar în răspunsurile HTTP și unele în oricare din tipurile de mesaj.

Antete generale HTTP: pot apărea fie într-o cerere HTTP, fie într-un răspuns HTTP. Sunt folosite pentru a transmite informații despre mesaj în sine, spre deosebire de conținutul său. Se utilizează pentru funcții cum ar fi specificarea datei și a orei unui mesaj, control asupra modalității de menținere într-o zonă temporară de servire (cache) a unui mesaj, și pentru a indica metoda de codificare folosită pentru transfer.

Antete de cerere HTTP: sunt folosite numai în mesajele de cerere HTTP și permit unui client să furnizeze informații despre el însuși unui server, și să asigure mai multe detalii despre o cerere și control peste cum va fi realizată aceasta.

Antete de răspuns HTTP: apar în mesajele de răspuns HTTP unde furnizează informații adiționale despre caracteristicile și cerințele serverului HTTP, și rezultatele procesării cererii clientului.

Antete de entitate HTTP: apar în orice tip de mesaj ce conține o entitate în conținutul mesajului și descriu natura entității, inclusiv tipul, limbajul și codarea ei, pentru a facilita prelucrarea și prezentarea corectă a entității de către dispozitivul ce o primește.

Chiar dacă HTTP este, de obicei, asociat cu hipertext, mesajele sale pot transporta o varietate de diferite tipuri de fișiere, inclusiv imagini, audio, video și multe altele. Pentru a indica tipul de entitate conținută de un mesaj HTTP, transmițătorul trebuie să identifice tipul și subtipul conținutului. Pentru aceasta se folosește antetul HTTP Content-Type, ce a fost împrumutat din specificațiile MIME (chiar dacă împrumută mai multe concepte și tipuri de antete de la acesta, protocolul nu este conform cu MIME).

HTTP suportă două nivele de codare pentru transferul de date. Prima este codarea de conținut, ce este utilizată în anumite circumstanțe pentru a transforma entitatea transportată în mesaj HTTP; a doua este codarea de transfer, ce este folosită pentru a coda un întreg mesaj HTTP pentru a îi asigura transportul în siguranță. Codările de conținut sunt des utilizate atunci când entitățile sunt comprimate pentru a îmbunătăți eficiența comunicației; codarea de transfer este utilizată în principal pentru a se ocupa de problema identificării sfârșitului unui mesaj.

De vreme ce HTTP/1.1 folosește conexiuni ce permit ca cereri și răspunsuri multiple să fie trimise pe o conexiune TCP, clienții și serverele au nevoie de o modalitate de a identifica unde un mesaj se termină și altul începe. Soluția simplă constă în a utiliza antetul Content-Length pentru a indica dimensiunea unui mesaj, dar această metodă funcționează doar atunci când lungimea mesajului poate fi determinată cu ușurință în avans. Pentru conținut dinamic și alte cazuri unde lungimea mesajului nu poate fi calculată în mod simplu înainte de trimiterea datelor, codarea de transfer specială chunked poate fi folosită, unde conținutul mesajului este trimis pe bucăți, cu fiecare parte precedată de lungimea ei. Când această metodă de codare este folosită, transmițătorul mesajului poate muta anumite antete de la începutul mesajului la finalul acestuia, unde sunt cunoscute sub numele de trailers. Acestea sunt interpretate în același mod ca antetele normale de către recipient. Antetul special trailer este folosit în mesaje pentru a comunica recipientului să caute pentru trailers după partea de conținut al mesajului.

HTTP include o proprietate numită content negotiation care permite selectarea unei variații particulare a unei resurse ce are mai mult decât o singură reprezentare. Există două tehnici de negociere: server-driven (aceasta este metoda de negociere cea mai des utilizată în HTTP), unde clientul include antetele în care indică ce dorește în cererea sa, iar serverul alege varianta optimă; și agent-driven, unde serverul trimite clientului o listă cu alternativele de resurse disponibile și clientul alege una. Un client ce trimite o cerere poate include până la patru antete diferite care furnizează informații despre cum serverul ar trebui să completeze cererea sa.

Una din cele mai importante caracteristici ce îmbunătățesc eficiența de funcționare a HTTP se numește caching – stocarea temporară a resurselor recent cerute. Dacă aceeași resursă este necesară din nou după o perioadă scurtă de timp, aceasta poate fi preluată din cache pentru a nu cere din nou serverului trimiterea ei, rezultând o economie de timp și bandă utilizată. Această metodă poate fi utilizată de clienți, servere și intermediari. Cu cât cache-ul este mai aproape de utilizator, cu atât beneficiile sunt mai mari, iar cu cât este mai departe de acesta, un număr mai mare de utilizatori se pot folosi de el.

Unul din cele mai importante tipuri de dispozitive intermediare în HTTP este serverul proxy, ce acționează ca un intermediar între client și server, ocupându-se atât de cereri, cât și de răspunsuri. Un server proxy poate transporta mesajele neschimbate sau le poate modifica pentru a implementa anumite caracteristici și capabilități. Sunt folosite deseori pentru a îmbunătăți securitatea și/sau performanțele accesului web.

HTTP este în mod inerent un protocol stateless, deoarece un server tratează fiecare cerere de la un client în mod independent, ignorând toate cererile anterioare. Această caracteristică a HTTP nu este o problemă pentru majoritatea utilizărilor World Wide Web, dar este o problemă pentru aplicațiile interactive cum ar fi cumpărăturile online unde serverul trebuie să țină evidența datelor utilizatorului pe o perioadă de timp. Pentru a suporta aceste aplicații, majoritatea implementărilor HTTP includ o opțiune numită state management. Când este activată, un server trimite unui client o cantitate mică de informație denumită cookie, ce este stocată pe dispozitivul clientului. Datele din cookie sunt returnate serverului la fiecare cerere ulterioară, permițând serverului să o actualizeze și să o trimită înapoi clientului. Cookie-urile permit serverelor să păstreze date între cereri.

Protocolul SMTP

Cea mai importantă componentă a sistemului de mesagerie electronică din TCP/IP este protocolul SMTP. Acesta a derivat din protocolul precedent MTP (Mail Transfer Protocol – Protocolul de transfer a corespondenței), și reprezintă mecanismul folosit pentru livrarea de mail între sisteme TCP/IP și utilizatori. Singura parte din sistemul de e-mail unde nu se folosește SMTP este pasul final de preluare a mesajului de către un client de e-mail.

La începutul implementării SMTP, mail-ul era livrat folosind procesul oarecum ineficient de relocare de la server la server în rețeaua de comunicații multiple. Această modalitate nu mai este folosită deoarece atunci când un server SMTP are de livrat mail unui utilizator, acesta determină ce server se ocupă de mesageria electronică a respectivului client folosind DNS și trimite informația direct acestui server.

Serverele SMTP trimit și primesc e-mail. Dispozitivul ce trimite mail are rolul de client în tranzacție, iar cel care primește mail are rol de server în aceasta. Pentru a evita confuzia, se utilizează denumirile de transmițător SMTP pentru dispozitivul ce trimite mail și destinatar SMTP pentru cel ce primește mesajul (aceștia sunt termenii ce au fost folosiți când SMTP a fost creat).

O sesiune SMTP constă în trei faze fundamentale:

Sesiunea este stabilită prin crearea unei conexiuni TCP/IP și prin schimbul informațiilor de identitate între transmițătorul și destinatarul SMTP folosind comanda HELO.

Odată inițializată sesiunea, tranzacția de mail poate avea loc.

Când transmițătorul nu mai necesită existența sesiunii o termină folosind comanda QUIT.

Dacă extensiile SMTP sunt suportate, transmițătorul SMTP folosește comanda EHLO (hello extins) în loc de HELO, și astfel destinatarul SMTP îi trimite acestuia o listă de extensii pe care le poate utiliza.

Tranzacția de mail SMTP se realizează efectiv în trei pași:

Inițierea tranzacției și identificarea transmițătorului: transmițătorul SMTP comunică destinatarului SMTP că dorește să înceapă transmiterea unui mesaj și îi oferă acestuia adresa de mail ce se află la originea mail-ului.

Identificarea recipientului: transmițătorul comunică destinatarului adresa/adresele de e-mail a recipienților doriți.

Transferul de mail: transmițătorul transferă mesajul e-mail recipientului. Acesta este un mesaj e-mail complet ce respectă specificația RFC 822.

SMTP a fost proiectat într-o perioadă când securitatea pe internet nu reprezenta o problemă și de aceea protocolul de bază nu include niciun fel de mecanism de securitate. De vreme ce atacurile asupra e-mail-ului sunt foarte dese acum, majoritatea serverelor moderne de SMTP încorporează una sau mai multe soluții de securitate pentru a evita problemele.

Transmițătorul SMTP realizează operațiuni folosind un set de comenzi SMTP. Fiecare comandă este identificată folosind un cod de patru litere. De vreme ce SMTP suportă un număr limitat de funcții, are un set de comenzi restrâns. De fiecare dată când transmițătorul SMTP emite o comandă primește un răspuns de la destinatarul SMTP. Răspunsurile SMTP folosesc un cod de replică format din trei cifre și o linie de text descriptiv. O extensie SMTP specială pentru coduri de stare îmbunătățite este de asemenea definită. Când este activată, extensia permite obținerea de informații detaliate ale rezultatelor de la recipientul SMTP, după procesarea unei comenzi.

Protocolul FTP

Cel mai important protocol de transfer general de fișiere din TCP/IP este protocolul simplu denumit FTP. Necesitatea transferului fișierelor de orice tip între dispozitive este atât de importantă încât istoria FTP a început acum mai mult de 40 de ani. FTP folosește TCP, pentru a asigura transportul sigur, fără pierderi de date. Protocolul folosește un set de comenzi FTP trimise de la un client FTP la un server FTP pentru a realiza operațiunile de transfer de fișiere. Serverul FTP trimite clientului răspunsuri care indică succesul sau eșecul comenzilor.

Standardele care definesc FTP îi descriu funcționalitatea globală folosind un model conceptual simplu denumit modelul FTP. Modelul definește rolurile dispozitivelor ce participă în transferul de fișiere și cele două canale de comunicație care sunt stabilite între ele. Descrie, de asemenea, componentele FTP ce administreaza aceste canale și definește terminologia folosită pentru acestea.

FTP este un portocol de tip clasic client/server. Cu toate acestea, nu se face referință la client folosind acest termen ci mai degrabă acesta este denumit utilizator deoarece persoana care emite comenzi FTP lucrează pe mașina client. Software-ul FTP ce fincționează pe un dispozitiv este denumit proces. Software-ul FTP aflat pe server se numește Server-FTP process iar cel aflat pe client User-FTP process.

Un concept fundamental în înțelegerea FTP este că în timp ce folosește TCP ca multe alte aplicații, nu folosește o singură conexiune TCP pentru toată comunicația așa cum fac majoritatea protocoalelor. Modelul FTP este proiectat în jurul a două canale logice de comunicare dintre Server-FTP process și User-FTP process.

Conexiunea de control: aceasta este conexiunea logică principală TCP ce este creată atunci când o sesiune FTP este stabilită. Este menținută pe durata sesiunii FTP și este folosită numai pentru transmiterea informațiilor de control, cum ar fi comenzi și răspunsuri FTP. Nu este folosită pentru a transmite fișiere.

Conexiunea de date: de fiecare dată când date sunt transmise de la server la client sau viceversa, o conexiune de date TCP separată este stabilită între ele. Datele sunt transferate pe această conexiune. Când transferul de fișiere este complet conexiunea este terminată.

Modelul operațional FTP este prezentat în figura 1.4.

Figura . – Modelul operațional FTP [1]

De vreme ce informațiile de control și datele sunt transmise folosind canale diferite, modelul FTP împarte software-ul de pe fiecare dispozitiv în două componente logice de protocol ce sunt responsabile de fiecare canal. Protocol Interpreter (PI) este software-ul responsabil de administrarea conexiunii de control, emite și primește comenzi și răspunsuri. Data Transfer Process
(DTP) este însărcinat cu trimiterea și primirea efectivă a datelor între client și server. Pe lângă aceste două elemente, User-FTP process include și o a treia componentă, o interfață cu utilizatorul ce nu este prezentă și pe server.

O sesiune FTP începe cu stabilirea unei conexiuni de control între un client și un server FTP. După ce conexiunea FTP este realizată, utilizatorul trebuie să se autentifice cu serverul, folosind un schimb simplu de user/parolă între client și server. Această soluție furnizează o securitate rudimentară și pentru protecție sporită este necesară implementarea acesteia folosind o extensie de securitate FTP sau o altă metodă.

Multe servere FTP suportă anonymous FTP, ce permite unui vizitator ce nu are cont pe server acces limitat la resursele acestuia. Această metodă este des folosită de organizații care doresc să facă fișiere disponibile publicului în diferite scopuri: suport tehnic, distribuție, etc.

FTP suportă două modele diferite pentru stabilirea conexiunilor de date între client și server. În conexiunile normale sau active de date, serverul inițiază conexiunea când clientul cere un transfer, și clientul răspunde; într-o conexiune de date pasivă, clientul comunică serverului că va iniția conexiunea, și serverul răspunde. De vreme ce TCP este bidirecțional, datele pot circula în ambele sensuri, în amândouă cazurile. Diferența fundamentală între cele două moduri ține de securitate. În particular, modul pasiv este utilizat deoarece multe dispozitive client nu sunt capabile să accepte conexiuni de la servere.

FTP include trei moduri diferite de transmisie: stream, block și compressed. În modul stream, datele sunt trimise ca o secvență continuă de octeți; în modul block, datele sunt formatate în blocuri cu antete; în modul compressed, octeții sunt compactați folosindu-se codare run-length. Modul stream este cel mai des utilizat.

FTP definește patru tipuri de date: ASCII, EBCDIC, image și local. ASCII și EBCDIC sunt folosite pentru fișiere text în seturile de caractere ASCII și EBCDIC. Tipul image este folosit pentru fișiere fără o structură specifică și tipul local pentru reprezentare locală. Tipul ASCII este important deoarece permite fișierelor text să fie transferate cu succes între sisteme de fișiere care pot folosi metode diferite pentru indicarea sfârșitului unei linii în text. Tipul image, numit de asemenea binar, este folosit pentru fișiere care trebuie trimise și primite octet cu octet fără nicio transformare, cum ar fi fișiere executabile, grafice și fișiere cu formate arbitrare.

Procesul FTP este controlat prin emiterea de comenzi de protocol de la clientul FTP la serverul FTP. Fiecare comandă are un cod de trei sau patru litere care îi indică funcția. Comenzile sunt organizate în trei grupuri: comenzile de control al accesului folosite pentru logare și controlul sesiunii generale; comenzile de transfer ai parametrilor care controlează cum sunt efectuate transferurile; și comenzi de serviciu FTP care sunt folosite pentru a realiza efectiv transferurile.

Serviciile și operațiunile client/server ale TCP/IP

Conceptual, putem clasifica serviciile TCP/IP în două grupuri: servicii furnizate altor protocoale și servicii furnizate direct utilizatorilor.

Servicii furnizate altor protocoale

Primul grup de servicii constă în funcțiile de bază implementate de principalele protocoale TCP/IP cum ar fi TCP, IP și UDP. Aceste servicii sunt concepute pentru a realiza funcțiile de internetworking ale suitei de protocoale. De exemplu, la nivelul Rețea, IP asigură funcțiile de adresare, livrare, fragmentare și reasamblare. La nivelul Transport, TCP și UDP se ocupă de încapsularea datelor utilizatorilor și de controlul conexiunii între dispozitive. Alte protocoale asigură funcțiile de gestionare și rutare. Protocoalele de la nivelele superioare folosesc aceste servicii, permițându-le să se concentreze pe ce au fost proiectate să realizeze.

Serviciile furnizate direct utilizatorilor

Aceste servicii permit aplicațiilor rulate de utilizatori să folosească puterea Internetului și a celorlalte rețele TCP/IP. De exemplu, WWW (World Wide Web) este, în mod discutabil, cea mai importantă aplicație de Internet. Serviciile WWW sunt furnizate prin HTTP, un protocol de la nivelul Aplicație al suitei TCP/IP. HTTP, la rândul său, folosește servicii furnizate de protocoalele de pe nivele inferioare ale suitei.

Modelul structural client/server al TCP/IP

O caracteristică definitorie importantă a serviciilor TCP/IP este că funcționează în modelul structural client/server. Acest termen se referă la un sistem unde un număr relativ mic de servere oferă servicii unui număr mult mai mare de utilizatori. Așa cum modelul client/server se aplică părții de hardware, același concept poate fi aplicat și părții de software și protocoale, lucru ce a fost realizat în proiectarea protocoalelor și aplicațiilor TCP/IP.

Protocoalele TCP/IP nu sunt setate astfel încât două dispozitive care vor să comunice să folosească software identic. În schimb, o decizie conștientă a fost făcută pentru a realiza funcția de comunicare folosind perechi potrivite, complementare de software de client și software de server. Clientul inițiază comunicarea trimițând o cerere la un server pentru date sau alte informații. Serverul trimite un răspuns clientului oferind acestuia ce a cerut sau un răspuns alternative cum ar fi un mesaj de eroare sau informații despre unde ar putea găsi informațiile cerute. Majoritatea funcțiilor TCP/IP funcționează în acest fel, modalitate prezentată în figura 1.5.

Figura . – Procesul Client/Server TCP/IP

Majoritatea protocoalelor TCP/IP implică comunicare între două dispozitive, dar cele două rareori acționează în calitate de parteneri în aceasta; unul joacă rolul clientului, iar celălalt rolul serverului. În graficul de mai sus avem un caz comun de tranzacție World Wide Web folosind protocolul HTTP. Browser-ul este un client HTTP care inițiază legătura cu o cerere pentru un fișier sau alte resurse trimisă prin Internet unui site, care are rolul de server HTTP. Serverul răspunde apoi clientului cu informația solicitată. Serverele răspund în general mai multor clienți simultan.

Modul de operare client/server în TCP/IP are numeroase avantaje. Așa cum hardware-ul clientului și cel al serverului pot fi adaptate pentru sarcini foarte diferite, software-ul acestora poate, de asemenea, să fie optimizat să efectueze sarcinile în cel mai eficient mod posibil. Ca exemplu, pentru a lua informație de pe Web, browser-ul Web al clientului trimite cereri unui server Web. Serverul Web răspunde apoi cu conținutul solicitat (în acest mod simplu se prezintă procesul utilizatorului). Browser-ul Web a fost creat pentru a asigura interfața pentru utilizator și pentru a comunica cu servere Web.

Rolurile clientului și serverului din TCP/IP

Termenii “client” și “server” pot crea confuzie în TCP/IP deoarece ei sunt utilizați în mai multe moduri diferite, uneori simultan:

Roluri hardware: Termenii “client” și “server” se referă, de obicei, la rolurile principale avute de hardware-ul de rețea. Un calculator “client” este, de obicei, un PC (Personal computer – Calculator personal) sau Macintosh folosit de o persoană și care inițiază conversații, în primul rând, prin transmiterea de cereri. Un “server” este o mașină de putere foarte mare dedicată răspunderii solicitărilor clienților și este localizat într-o sală de calculatoare unde doar administratorul are control.

Roluri software: Un browser Web reprezintă software al clientului în timp ce software-ul serverului Web este complet diferit. Software-ul clientului este de obicei găsit pe hardware-ul acestuia și analog software-ul serverului pe hardware-ul serverului, dar nu întotdeauna. Unele dispozitive pot rula atât software de client, cât și de server.

Roluri tranzacționale: În orice schimb de informație, clientul este, în mod obișnuit, cel care inițiază comunicarea sau trimite o interogare; serverul răspunde, furnizând, de obicei, infomația. Analog, de obicei, software-ul clientului este cel care inițiază tranzacția, dar nu este o regulă.

Sisteme de colectare a traficului din rețea

Analiza rețelei este procesul de ascultare și analizare a traficului din rețea. Aceasta oferă o inspecție în detaliu a comunicațiilor ce au loc în rețea pentru identificarea problemelor ce cauzează scăderea perfomanțelor, localizează breșele de securitate, evaluează comportamentul aplicațiilor și realizează planificarea capacității. Analiza rețelei (sau altfel denumită analiza protocolului) este un process utilizat de specialiștii IT ce sunt responsabili de securitatea și performanțele rețelei.

Din perspectiva unui analist de rețea trebuie înțelese rolurile dispozitivelor și ale protocoalelor și cum interacționează acestea. De exemplu, cum oferă mai exact un server DHCP (Dynamic Host Configuration Protocol) o adresă IP și informații de configurare unui client DHCP?, ce se întâmplă dacă serverul de nume nu este activ?, cum află utilizatorul adresa IP de destinație când încearcă să acceseze de exemplu www.google.com?, etc. Vizualizarea în acțiune a acestor procese la nivel de pachete este o cale rapidă de a înțelege modul de lucru al rețelei și cum trebuie să funcționeze ansamblul de hardware și software.

Instrumentele pentru analizarea rețelei sunt denumite deseori “snifferi” și pot fi vândute sau distribuite ca soluții hardware plus software sau doar ca soluții software. Un analizor de rețea open source foarte popular este Wireshark. Acesta dispune de numeroase add-on-uri pentru a-și îmbunătăți capabilitățile.

În timpul unei sesiuni tipice de analiză a rețelei se îndeplinesc mai multe sarcini:

Capturarea de pachete la locațiile adecvate

Aplicarea de filtre pentru vizualizarea traficului de interes

Identificarea și examinarea anomaliilor din trafic

În figura 2.1 este prezentată o captură de pachete în Wireshark cu traficul de rețea corespunzător încărcării paginii www.google.ro într-un browser. Atunci când utilizatorul încearcă să deschidă în browser pagina www.google.ro, sistemul rezolvă mai întâi adresa de IP a acestui nume folosind protocolul DNS. Se poate observa cererea DNS pentru adresa IPv4, iar dacă serverul DNS trimite această informație se trece la realizarea conexiunii TCP și trimiterea unei cereri HTTP GET pentru accesarea paginii implicite a respectivului site web.

Dacă totul funcționează până în acest punct serverul HTTP trimite răspunsul 200 OK și pagina începe să fie descărcată. Apar apoi diferite cereri GET ale sistemului (sunt cerute diferite elemente grafice pentru construirea paginii).

Atunci când se inițiază descărcarea unui document de pe un site (se apasă link-ul de download) sistemul poate face mai întâi o interogare DNS pentru a găsi adresa IP a serverului de unde va descărca datele înainte de a realiza o nouă conexiune TCP la acea adresă și în final să trimită o cerere GET pentru fișier. Se poate urmări cum fișierul este transferat pe sistemul local.

Problemele apar atunci când comunicarea nu are loc în parametrii normali, vitezele de transfer sunt foarte mici și timpii de așteptare devin foarte mari. În astfel de situații trebuie analizat ce cauzează aceste probleme, dacă erorile apar de la adresa accesată sau este ceva local. Vizualizarea traficului indică întotdeauna unde își are originea problema, analiza de rețea fiind practic indispensabilă în funcționarea unei rețele. Ea ne permite să privim în interiorul sistemului de comunicare și să vedem cum pachetele sunt transferate dintr-o parte în alta. Putem vedea cum sunt trimise interogările DNS și răspunsurile la aceste interogări. Putem observa cum sistemul local trimite o cerere de conexiune TCP și putem să măsurăm cât timp îi ia destinației să răspundă și să ne creăm o impresie generală în legătură cu timpul dus-întors (round trip time) până la site-ul respectiv.

În concluzie, analiza de rețea oferă o inspecție în detaliu a rețelei de comunicații. Atunci când problemele de performanță afectează rețeaua presupunerile cu privire la cauze pot consuma foarte mult timp și conduc la concluzii incorecte ce cauzează costuri inutile și timp adițional pierdut. O întelegere completă a traficului în rețea este necesară pentru a plasa analizorul la locul potrivit și pentru a identifica posibilele cauze ale problemelor rețelei.

Figura . – Clientul solicită pagina Google România (https://www.google.ro/)

Captura de trafic

Motivul principal pentru care oamenii evită analiza traficului din rețea îl constituie confuzia totală creată de mulțimea de pachete ce traversează permanent prin aceasta. În cazul unei rețele mari unde mulți utilizatori se plâng de performanțe scăzute, plasarea analizorului la locul potrivit este la fel de importantă ca aplicarea filtrelor pentru concentrarea pe traficul de interes și interpretarea corectă a acestuia. În diagram 2.2, clientul A se plânge de performanțe scăzute.

Figura 2.2 – Diagramă de rețea – trebuie luate în considerare plângerile utilizatorului atunci când se decide locul de plasare al analizorului [2]

Se începe prin plasarea analizorului cât mai aproape de clientul A pentru a identifica problemele de trafic din perspectiva acestuia. Prin capturarea la această locație se poate măsura timpul dus-întors și se pot identifica pierderile de pachete în punctul unde clientul A se conectează în rețea. Dacă toți cei care se conectează la serverul A notifică probleme este de dorit în continuare captura de trafic din perspectiva clientului. Dacă se descoperă că problema este pierderea de pachete analizorul se poate muta mai aproape de server până când este descoperită locația unde pachetele sunt aruncate. O opțiune simplă pentru capturarea de trafic este rularea analizorului ales pe sistemul de la și către care se dorește analiza traficului.

Captura de trafic pe rețele IP

Atunci când în rețea se află switch-uri ce controlează și izolează traficul acestea permit astfel utilizarea mai eficientă a lățimii de bandă. Aceasta este o tehnică foarte bună pentru reducerea traficului inutil pe porturile conectate, dar care creează complicații pentru analistul de protocol. Atunci când analizorul se conectează la un port al switch-ului (de exemplu Wireshark) se pot vedea implicit doar patru tipuri de trafic:

Trafic broadcast

Trafic multicast (dacă este transmis de către switch)

Trafic de la și către propria adresă hardware

Trafic către o adresă hardware necunoscută

Traficul de la un dispozitiv conectat la un switch circulă direct spre dispozitivul destinație aflat pe un alt port de switch. În figura de mai sus traficul de la clientul A traversează prin Switch A, Router A, Router B și Switch C pe drumul către Server A. Traficul acestuia nu mai este pe trimis pe niciunul din celelalte porturi ale switch-ului A. Dacă analizorul este conectat în Switch A nu se vor putea asculta comunicațiile clientului A deoarece switch-ul izolează conversațiile locale pe baza adreselor hardware.

Există mai multe metode de a captura trafic pe o rețea IP:

Tehnologia Hub

Racordarea la trafic half sau full duplex

Configurație de tip SPAN port pe switch

Instalarea analizorului pe sistemul țintă

Tehnologia Hub

Hub-urile standard pot fi folosite pentru a monitoriza traficul din rețelele half-duplex prin conectarea hub-ului in-line între dispozitivele half-duplex. Hub-urile sunt dispozitive simple care trimit biții ce sosesc pe un port pe toate celelalte porturi pe care le are. Rețelele half-duplex au devenit rare în zilele noastre așa că această variantă este bună doar pentru foarte puține cazuri. Trebuie evitată plasarea hub-urilor în full duplex deoarece acesta va cauza probleme grave în comunicațiile dintr-o rețea.

Dacă se planifică folosirea unui hub pentru monitorizarea de rețele half duplex este recomandată verificarea acestuia. Mulți producători au vândut dispozitive descrise ca fiind hub-uri dar care erau, de fapt, switch-uri. Pentru a testa un presupus hub se conectează două stații de test half duplex și analizorul la hub ca în figura 2.3. Dacă analizorul poate vedea traficul de ping atunci dispozitivul chiar este hub și trimite trafic pe toate porturile. Dacă acest trafic nu apare este foarte probabil ca hub-ul să fie de fapt un switch și nu ar trebui folosit pentru monitorizarea traficului.

Figura . – Testarea unui hub [2]

Utilizarea unui Test Access Port (TAP) pe rețelele full-duplex

TAP-urile de rețea pot fi folosite pe rețelele half și full duplex pentru a asculta traficul dintre un client sau server și un switch sau router. Sunt dispozitive pasive care sunt plasate in-line (pe traseu) între dispozitive. Spre deosebire de porturile de switch spanate, TAP-urile pot înainta pachete care conțin erori de la nivelul fizic (cum ar fi erori CRC – Cyclic Redundancy Check sau Control Redundant Ciclic) la portul/porturile de monitorizare.

TAP-urile nu introduc întârzieri și nu modifică conținutul traficului ce trece prin ele. Adițional ele realizează așa numitul fail open adică nu întrerup traficul dacă alimentarea la TAP este pierdută. Procedurile de instalare a TAP-ului variază în funcție de caracteristicile acestuia.

Există următoare tipuri de TAP-uri:

TAP-uri fără agregare trafic: trimit la ieșire comunicațiile full duplex pe două porturi separate. Un dispozitiv ce rulează analizorul are nevoie de două plăci de rețea pentru a primi trafic de la cele două porturi de monitorizare. Analizorul trebuie configurat pentru a captura pe ambele interfețe simultan. Alternativ, două dispozitive separate ce rulează analizorul pot fi conectate la cele două porturi.

Figura . – Setarea unui TAP fără agregare trafic și două sisteme Wireshark [2]

TAP-uri cu agregare trafic: combină traficul bidirecțional într-un singur port de ieșire. Dispozitivele cu o singură placă de rețea pot fi conectate la acest tip de TAP pentru a asculta comunicațiile full duplex. Un singur analizor și un singur adaptor sunt necesare pentru a asculta traficul.

Figura . – TAP-urile cu agregare trafic combină traficul bidirecțional într-un singur port de ieșire [2]

TAP-uri regeneratoare: sunt folosite când avem mai multe tipuri de analizoare de trafic. De exemplu se poate analiza traficul cu Wireshark și se poate realiza detectarea intruziunilor cu un alt instrument cum ar fi Snort sau Suricata. Aceste TAP-uri au mai multe porturi de ieșire permițând conexiunea a două sau mai multe dispozitive de monitorizare. În figura 2.6 este prezentat un TAP regenerator cu porturi de fibră. Porturile din dreapta sunt porturile de in-line. Dacă s-ar monitoriza traficul dintre un server și un switch unul din aceste porturi s-ar conecta la server și al doilea la switch.

Figura . – TAP de regenerare [2]

TAP-uri de tip agregare conexiune: sunt folosite atunci când există mai mult de un link de monitorizat. De exemplu, dacă se dorește monitorizarea traficului către și de la două servere separate. În loc sa fie folosite mai multe TAP-uri, un singur TAP de acest tip poate fi conectat la ambele servere. El combină traficul de pe aceste link-uri și trimite stream-ul pe unul sau mai multe porturi de monitorizare.

Figura . – TAP de agregare conexiune [2]

TAP-uri inteligente: pot lua decizii pe traficul primit, furnizează timestamps pentru fiecare pachet primit, filtrează pachete, etc. Caracteristicile disponibile depind de producătorul ales.

Folosirea agenților pentru captura de la distanță: agenții de analizor sunt folosiți de analizorii distribuiți. Acești agenți sunt, de obicei, programe software care sunt încărcate pe switch-uri permițându-le acestora să capteze trafic de la toate porturile și să trimită datele către o consolă de management. Agenți de analizor pot permite controlarea traficului comutat din o locație centrală. Această caracteristică face ca switch-ul să aibă un cost mult mai ridicat.

Configurare pentru port spanning/port mirroring pe un switch

Unii producători numesc această tehnică port spanning (SPAN vine de la switched port analysis), iar alții o numesc port mirroring. În continuare voi folosi termenul de port spanning. De asemenea Cisco folosește termenul de port snooping când se referă la această caracteristică pentru switch-urile Catalyst 8500.

Într-un mediu IP tehnica port spanning este folosită pentru a configura un switch să trimită o copie a traficului oricărui port la un port de monitorizare – portul la care sistemul analizor, ca de exemplu Wireshark, este conectat. Această metodă de analiză a rețelelor IP poate fi folosită doar daca switch-ul suportă această funcționalitate.

Terminologie SPAN:

Port SPAN sursă: este portul care este monitorizat de tehnica SPAN. În figura 2.8 acest rol este jucat de portul 4.

VLAN SPAN sursă: este un VLAN (Virtual Local Area Network – Rețea locală virtuală) al cărei trafic este monitorizat de tehnica SPAN.

Port SPAN destinație sau portul de monitorizare: este portul care monitorizează porturile sursă. În figura 2.8 acest rol este jucat de portul 1.

Trafic de intrare (ingress traffic): este traficul care ajunge în switch. Unele switch-uri cer definirea tipului de monitorizare a traficului la un port: ingress și egress sau doar ingress.

Trafic de ieșire (egress traffic): este traficul care pleacă de la switch. Unele switch-uri cer definirea tipului de monitorizare a traficului de la un port: ingress și egress sau doar egress.

Figura .8 – Traficul de pe portul 4 este duplicat (spanned) la portul 1 [2]

SPAN pe VLAN-uri

Se poate folosi un TAP sau se poate duplica traficul de pe un port pentru a se asculta traficul de pe un VLAN. Pentru a duplica traficul de la și către dispozitivele dintr-un VLAN se duplică traficul portului unuia dintre aceste dispozitive. Portul destinație se definește ca fiind cel la care analizorul este conectat pe switch. Pentru a vedea tag-urile VLAN, interfața analizorului conectată la switch nu trebuie configurată ca un membru al VLAN-ului. Chiar și așa, acestea nu pot fi întotdeauna vizualizate deoarece sisteme de operare și drivere diferite manipulează aceste tag-uri în moduri distincte.

Dacă tag-ul VLAN este controlat de placa de rețea sau de driverul de pe sistemul pe care se află analizorul, tag-ul nu va fi trimis analizorului și acesta nu va putea fi vizualizat când este analizat traficul. Dacă placa de rețea sau driverul trimit tag-ul VLAN la nivel superior pe sistemul analizorului se va putea vizualiza și analiza câmpul tag-ului VLAN. În figura 2.9 exemplu din Wireshark.

Figura . – Wireshark decodează câmpurile VLAN dacă placa de rețea și driverul le înaintează [3]

Captura traficului în rețelele rutate

Routerele izolează traficul în funcție de adresa de rețea, cum ar fi o adresă IP. Dacă analizorul este plasat pe o parte a routerului se va putea vizualiza doar traficul destinat acelei rețele sau care vine din aceasta. Figura 2.10 este constituită din două rețele (10.1.0.0, 10.2.0.0 și 10.3.0.0, subnetizate 255.255.0.0). Traficul dintre clienți și servere din rețeaua 10.1.0.0 nu va fi vizibil analizorului din rețeaua 10.2.0.0.

Analizorul din rețeaua 10.1.0.0 este configurat prin port spanning să asculte portul ce se conectează la Router A. Astfel îi este permis să asculte traficul de la și către clienții A, B, C și rețeaua 10.2.0.0.

Analizorul din rețeaua 10.2.0.0 este conectat la un TAP fără agregare trafic care conectează Server B la Switch C. Acest analizor este capabil să vadă doar traficul de la și către Server B din rețeaua locală și din cele distante.

Figura . – Plasarea analizorului pe fiecare parte a unui router [2]

Captura traficului în rețelele wireless

Pentru analiza unui mediu WLAN (Wireless Local Area Network – Rețea locală fără fir) se începe de la nivelul de jos și ne deplasăm în sus prin stiva de protocoale. A începe de jos într-un mediu WLAN înseamnă analiza puterii semnalelor de radiofrecvență (RF – radio frequency) și căutarea de eventuale interferențe.

Analizorul nu poate identifica energie de radiofrecvență sau interferențe nemodulate. Se va folosi un analizor de spectru pentru identificarea acestor probleme. Locația analizorului într-o rețea wireless este similară cu cea dintr-o rețea cu fir, adică se începe cât mai aproape posibil de utilizatorul care are probleme de performanță. Trebuie aflate puterea semnalului, rata de pierdere a pachetelor, rata de reîncercare a WLAN și timpul de latență pentru traseu dus-întors la locația unde se află acesta.

În figura 2.11 este prezentată o porțiune a unei rețele unde un utilizator, clientul C, se plânge de probleme de performanțe. Se plasează analizorul aproape de acest client. După ce se stabilește că nu interferența este cauza acestor probleme, se trece la nivelul de pachete pentru examinarea traficului de pe un WLAN cum ar fi procesul de realizare a conexiunii și autentificarea. Se vor examina înainte de inspectarea pachetelor de date, procesele de control și management ale WLAN pentru certitudinea că totul funcționează în parametrii normali. Pentru a analiza efectiv traficul de pe un WLAN, sistemul analizorului ar trebui să aibă o placă de rețea wireless care poate fi setată atât pentru modul de lucru promiscuous cât și monitorizare.

Figura 2.11 – Se plasează analizorul aproape de client pentru a analiza traficul din perspectiva acestuia [2]

Modurile de lucru promiscuous și monitorizare sunt diferite. Modul de lucru promiscuous permite unei plăci de rețea să capteze trafic care este adresat altor dispozitive din rețea și nu doar adresei hardware locale. Utilizând doar acest mod de lucru (fără modul monitor), un adaptor wireless 802.11 captează doar pachete ale SSID-ului (Service Set Identifier) la care este conectat. Deși poate primi, la nivel radio, pachete de la alte SSID-uri, acele pachete nu sunt trimise gazdei.

Pentru a capta tot traficul pe care adaptorul îl poate primi, adaptorul trebuie pus în modul de lucru monitorizare, numit și rfmon mode. În acest mod adaptorul nu va suporta comunicații generale de rețea (browsing web, email, etc). El furnizează pachetele primite unui mecanism de captură de pachete și nu rețelei (toate pachetele de la toate SSID-urile de pe canalul selectat în mod curent sunt trimise analizorului). Acest mod de lucru nu este suportat de WinPcap (nu funcționează cu Wireshark sau Tshark pe Windows) și este suportat, pentru anumite plăci de rețea, pe versiuni de Linux, FreeBSD, NetBSD, OpenBSD și Mac.

Se pot captura date pe adaptorul WLAN nativ cât timp acesta este afișat în lista de interfețe din analizor. Se poate întâmpla ca fișierele de urmărire să conțină doar pachete de date (fără pachetele de control și management ale WLAN) și au un antet Ethernet pe fiecare pachet. Acestea sunt antete Ethernet false aplicate pachetului în locul antetului 802.11. Aceste antete false sunt atașate de către placa de rețea 802.11 nativă după îndepărtarea antetului 802.11 original. Aceste adaptoare nu vor trimite mai departe cadrele de control sau de management.

Bibliotecile pcap, libpcap, WinPcap

Pcap (Packet Capture library – biblioteca capturii de pachete) furnizează o interfață de nivel înalt sistemelor de capturare de pachete. Toate pachetele din rețea, chiar și cele destinate altor gazde, sunt accesibile prin acest mecanism. Permite de asemenea salvarea pachetelor capturate și citirea ulterioară a acestora.

Biblioteca libcap este interfața standard la nivel de legătură de date pentru capturarea traficului, folosită de gazdele cu sisteme de operare UNIX, iar WinPcap este portarea pe Windows a acesteia. WinPcap este alcătuit din un driver care furnizează acces la rețea și versiunea de Windows a API (application programming interface – interfață de programare a aplicațiilor).

WinPcap permite aplicațiilor să captureze și să transmită pachete în rețea evitând stiva de protocoale, și are în plus caracteristici utile, printre care filtrare de pachete la nivel kernel, un motor de statistici de rețea și suport pentru captură de pachete la distanță. Datorită caracteristicilor lui, WinPcap este soluția de captură de pachete și filtrare a multor instrumente comerciale de rețea de tip open source, printre care analizoare de protocol, monitorizoare de rețea, sisteme de detectare a intruziunilor în rețea, snifferi, generatori de trafic, [4].

Filtrarea traficului

Rolul filtrelor de captură este de a limita pachetele salvate în locația temporară în timpul capturii sau într-un alt director când se salvează fișierul de urmărire. Filtrele de captură nu pot fi aplicate fișierelor de urmărire existente, ele sunt aplicate doar pentru procesele de captură ce se află în desfășurare. Filtrele de captură sunt foarte utile în limitarea numărului de pachete captate atunci când rețeaua în cauză este foarte încărcată sau se dorește urmărirea unui anumit tip de trafic. Pachetele care trec de criteriile filtrului de captură sunt trimise motorului de capturare al analizorului ca în figura 2.12.

Figura . – Filtrele de captură sunt aplicate doar pachetelor care sosesc din rețea [2]

Atunci când traficul este filtrat cu filtre de captură, pachetele aruncate nu mai pot fi recuperate deoarece ele au fost îndepărtate înainte de a fi transmise motorului de captură. Analizorul Wireshark include un set de filtre implicite păstrate în directorul programului. Cateva dintre acestea sunt:

port 80 – filtrul lasă să treacă doar traficul HTTP

No ARP and no DNS – sunt excluse protocoalele ARP și DNS din rezultatele analizării

tcp – se afișează numai protocolul TCP

udp – se afișează numai protocolul UDP

Figura . – Setarea filtrelor în opțiunile interfeței analizate

Pot fi create cu ușurință noi filtre de captură și pot fi înlocuite cele implicite. Acestea sunt compuse din identificatori și calificatori.

Identificatorul este elementul pentru care se filtrează. Într-un filtru de captură de trafic de la sau spre portul 53, ‘’53’’ este identificatorul. Acesta poate fi un număr decimal sau hexazecimal sau un cod ASCII.

Sunt trei tipuri de calificatori folosiți în filtrele de captură:

Calificatorul de tip: indică tipul de nume sau număr la care se referă identificatorul. De exemplu, într-un filtru de captură de trafic de la sau spre portul 53, ‘’port’’ este calificatorul de tip. Host, net și port sunt trei calificatori de tip.

Calificatorul Dir (direcție): este folosit pentru a indica fluxul de trafic dorit. Doi calificatori de direcție des utilizați sunt dst și src. Dacă un calificator de direcție nu este prevăzut, se presupune că dst sau src este dorit.

Calificatorul Proto (protocol): este utilizat pentru a limita traficul capturat la un anumit protocol cum ar fi tcp sau udp. De exemplu avem udp net 10.2 unde udp este calificatorul de protocol, net este calificatorul de tip și 10.2 este identificatorul. Dacă ar fi creat un filtru de captură net 10.2 atunci toate protocoalele spre sau de la adresele IP care încep cu 10.2 ar fi capturate.

Pentru combinarea filtrelor de captură se folosesc operatori. Există trei operatori primari disponibili:

Negarea (not sau !)

Concatenarea (and sau &)

Alternarea (or sau |)

Acești operatori permit realizarea unor filtre de captură mai specifice. Filtrul de captură host 192.168.1.103 and tcp dst 53 va captura tot traficul trimis la portul 53 spre sau de la adresa 192.168.1.103. Dacă 192.168.1.103 este un client în rețea, acest filtru va afișa interogările DNS trimise la portul 53. Când se folosește operatorul and, pachetele trebuie să respecte ambele cerințe pentru a trece prin filtru.

Dacă este folosit operatorul or interpretarea este total diferită. În acest caz fiecare pachet trebuie să respecte doar una din condiții pentru a trece prin filtru. Filtru host 192.168.1.103 or tcp dst 53 va captura tot traficul spre sau de la 1092.168.1.103 indiferent de porturile de destinație și orice trafic trimis la portul 53 indiferent de adresele IP folosite.

Filtrul de captură not net 10.2.0.0/16 capturează trafic doar de la sau spre adresele IP care nu încep cu 10.2.

În concluzie, filtrele de captură sunt folosite pentru a reduce număr de pachete capturate și prin urmare permit analizarea traficului de interes. Filtrele de captură folosesc sintaxa tcpdump și nu sunt interschimbabile cu filtrele de afișare. Nu se pot aplica filtre de captură fișierelor de urmărire existente și nu se pot recupera pachete care nu au respectat filtrul de captură deja aplicat.

Filtrele de captură pot fi realizate pe baza unui protocol, adresă sau număr specific de port. Filtrele de captură sunt compuse din calificatori de tip, direcție și protocol sau primitive.

Se poate defini de asemenea un filtru de captură bazat pe un offset și valoare byte dacă se dorește acest lucru. Operatori cum ar fi and, or și not permit combinarea filtrelor de captură pentru o selectivitate mai complexă privind traficul capturat.

Urmărirea fluxurilor de date și reasamblarea informațiilor

Analizorul Wireshark oferă posibilitatea urmăririi unui stream (flux de comunicație). Acest proces constă în reasamblarea comunicațiilor (mai puțin antetele MAC, de rețea și de transport). Prin această tehnică se pot vizualiza comenzile și datele transferate într-o conversație. Analizorul segmentează antetul legăturii de date, antetul IP și antetul TCP sau UDP și utilizează un cod al culorilor pentru a diferenția traficul clientului, respectiv al serverului (implicit, culorile sunt roșu pentru traficul de la client – gazda ce inițiază conversația și albastru pentru traficul de la server).

Pot fi reasamblate fluxuri de date UDP, TCP și SSL (Secure Sockets Layer). Fluxurile de date SSL afișează datele reasamblate numai după ce sunt decriptate. La unele comunicații, cum ar fi transferuri de date FTP, se poate reconstrui fișierul original transferat prin salvarea datelor reasamblate. Se poate utiliza identificatorul de fișier pentru a determina ce tip de fișier a fost transferat.

Urmărirea și reasamblarea traficului UDP

Cât timp traficul are un antet UDP opțiunea de a urmări fluxul de date UDP (Follow UDP Stream) este disponibilă.

Un exemplu în care se folosește reasamblarea fluxului UDP este procesul de reasamblare a unui stream video multicast. Cât timp datele video nu sunt criptate, acestea se pot reasambla și salva într-un format video și viziona din nou.

Figura .14 – Un flux de date video poate fi reasamblat folosind Follow UDP Stream [3]

Figura 2.14 prezintă pe fundal un flux UDP la a cărui reasamblare s-a folosit un filtru de afișare creat pentru conversația UDP (ip.src==192.168.1.12 and ip.dst==239.255.0.1) and (udp.port eq 1024 and udp.port eq 8001). În fereastra Stream Content datele pot fi salvate și apoi clipul poate fi vizionat folosind un soft de rulare a videoclipurilor care să fie capabil să detecteze formatul acestuia.

Urmărirea și reasamblarea traficului TCP

Pot fi reasamblate sesiune de browsing web, sesiuni de canal de comandă FTP, sesiuni de canal de transfer de date FTP sau orice altă comunicație bazată pe TCP.

În unele cazuri, vor apărea comenzi și antetele aplicației ce prefațează datele transferate. De exemplu, atunci când se reasamblează o sesiune de browsing web HTTP, se vor vizualiza cererile GET de la clienți și codurile de răspuns HTTP de la server și datele care sunt transferate.

Când se urmărește un stream TCP se folosește un filtru de afișare bazat pe numărul de index al stream-ului respectiv. Formatul filtrului este tcp.stream eq x. Sintaxa acestui filtru este de asemenea folosită în cazul SSL. Locația valorii acestui index este prezentată în figura 2.15.

Figura . – Valoarea numărului de index al stream-ului se găsește în antetul TCP

Figura . – Reasamblarea unei sesiuni HTTP furnizează detalii privind cererile și răspunsurile HTTP

Figura 2.16 prezintă o sesiune de navigare web reasamblată. Putem vedea ce browser este folosit pentru sesiunea de browsing (Chrome) și site-ul țintă (google.ro). Când se analizează sau se depanează comunicații HTTP, urmărirea traficului TCP poate fi foarte folositoare pentru a examina comenzile și răspunsurile.

Dacă se dorește reasamblarea datelor dintr-o comunicație HTTP o variantă este File Export – Objects – HTTP pentru extragerea datelor descărcate în întreaga sesiune HTTP. În unele cazuri însă este necesară căutarea plin fluxul de date pentru a găsi un fișier încorporat. Se poate folosi o extensie de document sau un identificator de document pentru a determina tipul fișierului transferat.

Reasamblarea fișierelor transferate folosind FTP este un proces simplu. Primul pas este localizarea canalului de date FTP. Datele FTP pot fi trimise pe orice număr de port. Aplicând filtru de afișare ftp.response.code==227 || ftp.request.command=="PORT" putem vizualiza traficul de pe canalul de comandă FTP care va indica portul folosit pentru transferul de date. Codul de răspuns 227 indică faptul că un canal de date FTP pasiv este stabilit. Pachetele care corespund celor două filtre conțin adresa IP și numărul de port al canalului de date.

Figura 5.3 prezintă pe fundal o sesiune FTP pentru care s-a folosit un filtru de afișare (ip.src==192.168.0.188 and ip.dst==192.168.0.198). Serverul de FTP de pe care s-a descărcat clipul video a fost creat pe o mașina virtuală Windows XP cu adresa IP 192.168.0.188. Descărcarea a avut loc de pe calculatorul cu adresa IP 192.168.0.198.

În fereastra Stream Content datele pot fi salvate și apoi clipul poate fi vizionat folosind un soft de rulare a videoclipurilor care să fie capabil să detecteze formatul acestuia (VLC Player a detectat automat tipul formatului video).

Atunci când se urmărește un flux de date, Wireshark aplică un filtru de afișare pentru conversație bazat pe indexul fluxului TCP. Acest filtru trebuie scos pentru a putea vedea conținutul întregii capturi.

Figura . – Reasamblarea unui clip video descărcat prin transfer FTP

Urmărirea și reasamblarea traficului SSL

Comunicațiile SSL pot fi decriptate dacă se cunosc cheile de decriptare RSA. Dacă protocolul SSL nu este configurat cu o legătură către cheia RSA, atunci când este urmărit fluxul SSL informațiile nu sunt disponibile. Dacă în schimb sunt introduse informațiile cheii RSA în secțiunea protocolului SSL și anume adresa IP a unei gazde din fișierul de urmărire, numărul de port al traficului ce trebuie decriptat, tipul de trafic (după decriptare), calea către cheia RSA și numele acesteia, se pot vizualiza conținutul sesiunii HTTP, cererile și răspunsurile HTTP.

Figura . – Adăugarea cheii RSA în setările SSL

În concluzie, urmărirea fluxurilor este un proces util pentru a vizualiza comenzile și datele transferate. Analizorul segmentează antetul legăturii de date, antetul IP, antetul TCP sau UDP și folosește un cod al culorilor pentru a diferenția între traficul clientului și cel al serverului.

Se pot reasambla fluxuri UDP, TCP și SSL. Fluxurile SSL afișează date reasamblate doar după ce acestea sunt decriptate.

Concluzii

Înainte de a putea analiza traficul rețelei, acesta trebuie capturat. Folosirea unui TAP la locații potrivite din rețea poate ajuta la capturarea traficului cel mai util în procesul de analiză.

Atunci când se lucrează pe rețele de comutație (cea mai comună configurație de rețea) există opțiunea rulării locale a analizorului, SPAN port pe switch sau folosirea unui TAP full duplex. Există, de asemenea, mai multe opțiuni pentru captură de la distanță: se poate folosi software open source sau comercial de copiere la distanță sau Remote SPAN (dacă switch-ul suportă această funcție), sau rpcapd care este inclus la descărcarea WinPcap.

Atunci când este capturat trafic de pe o rețea wireless ar trebui folosit un adaptor/driver care să funcționeze în modul de lucru monitorizare pentru a asculta traficul pe toate SSID-urile aflate în raza de acțiune. Dacă este folosit un adaptor nativ pentru captura de trafic WLAN, acesta poate substitui antetul 802.11 cu un antet Ethernet II și să nu captureze/afișeze trafic de management sau control sau trafic de la alte dispozitive WLAN.

Dacă este nevoie de captura unei cantități mari de trafic este de preferat salvarea pe seturi de fișiere pentru a face fișierele de urmărire mai ușor de gestionat. Dacă interfața grafică de utilizator (GUI – Graphical User Interface) nu poate face față traficului se poate folosi un instrument de captură cu linie de comandă cum ar fi Tshark sau Dumpcap.

Bibliotecile pcap permit salvarea și citirea ulterioară a capturilor de date pentru analiza și identificarea problemelor din rețea.

Filtrele de captură sunt foarte utile în limitarea numărului de pachete captate atunci când rețeaua în cauză este foarte încărcată sau se dorește urmărirea unui anumit tip de trafic.

Urmărirea fluxurilor este un proces util pentru a vizualiza comenzile și datele transferate. Analizorul segmentează antetul legăturii de date, antetul IP, antetul TCP sau UDP și folosește un cod al culorilor pentru a diferenția între traficul clientului și cel al serverului.

Se pot reasambla fluxuri UDP, TCP și SSL. Fluxurile SSL afișează date reasamblate doar după ce acestea sunt decriptate.

Sisteme de decodare și prelucrare a datelor colectate

Datele colectate provin din trafic de rețea captat prin intermediul sistemelor de colectare.

Analiza traficului

Analiza traficului HTTP

Transmisiile obișnuite HTTP folosesc un model de comunicație de tipul cerere/răspuns. Clienții fac cereri serverelor HTTP iar acestea răspund cu un cod de stare (Status Code).

Figura 3.1 prezintă accesarea paginii www.facebook.com. Clientul realizează conexiunea TCP de la portul 65121 la portul 80 (ce este listat ca http deoarece rezolvarea numelor de transport este activată). În mod implicit, Wireshark este configurat pentru analiza de trafic HTTP pe 9 porturi: 80, 3128, 3132, 5985, 8080, 8088, 11371, 1900 și 2869. Comunicațiile HTTP pot folosi și alte porturi, pe lângă cele menționate. Dacă se capturează trafic HTTP pe un alt port, numărul portului trebuie adăugat în preferințele HTTP.

Figura .1 – HTTP folosește un model cerere/răspuns [3]

După ce conexiunea TCP este realizată cu succes, clientul face o cerere HTTP GET. Serverul răspunde cu codul de stare 200 OK și începe să trimită clientului conținutul paginii implicite a site-ului.

Registrul de coduri de stare HTTP este actualizat la adresa www.iana.org/assignments/http-status-codes.

Pentru cea mai bună vizualizare a traficului HTTP în lista de pachete trebuie dezactivată opțiunea de reasamblarea a fluxurilor TCP din preferințele acestui protocol. Această setare permite să fie afișate toate cererile HTTP GET și toate codurile de răspuns HTTP în analizor.

Dacă un client HTTP a accesat recent o pagină și această pagină se află în cache-ul local, clientul poate trimite parametrul IfModified-Since și poate furniza data și ora descărcării anteriaore a paginii. Dacă serverul răspunde cu 304 Not Modified acesta nu va trimite pagina care se află deja în cache. Acesta este un lucru important de reținut atunci când se analizează performanțele HTTP. Dacă un client se plânge de acces lent numai atunci când accesează prima dată o pagină, este posibil ca pagina să fie încărcată din cache și să nu se vizualizeze de fapt descărcarea unei pagini.

Problemele comunicației HTTP pot apărea datorită erorilor în procesul de rezolvare a adresei IP a numelui site-ului, în procesul de conexiune TCP, cereri HTTP pentru pagini inexistente, pierderea de pachete, precum și congestia serverului HTTP la client sau la server.

Oricine a introdus la un moment dat o adresă greșită pentru un site web. Dacă numele acestuia nu poate fi translatat în adresă IP, nu poate fi accesat. Aceasta ar genera o eroare de nume DNS. Traficul DNS este important atunci când se analizează probleme de browsing web.

O altă problemă de conexiune HTTP poate apărea atunci când daemon-ul HTTP nu rulează pe serverul web. Când daemon-ul HTTP nu rulează pe server, serverul răspunde cu TCP RST/ACK la SYN-ul clientului. Conexiunea nu poate fi stabilită.

Figura .2 – Încercări multiple nereușite de conexiune HTTP creează un tipar în Wireshark [3]

Dacă clientul HTTP se conectează cu succes la serverul HTTP, dar apoi solicită o pagină inexistentă, serverul generează erorile HTTP de tipul 404 Not Found.

Anumite servicii de redirecționare vor înlocui mesajul standard 404 Not Found cu linkuri sugestive sau pot redirecționa clientul HTTP către un cu totul alt site.

În figura 3.3 se încearcă completarea unui formular online. La apăsara butonului de validare a datelor introduse sistemul clientului pare să stagneze. În acest caz putem vizualiza traficul HTTP și observa codul de stare 403 Forbidden de la server. Dacă urmărim fluxul TCP se afișează etichete HTML cu mai multe informații referitoare la problemă:

The page cannot be displayed – you have attempted to execute a CGI, ISAPI, or other executable program from a directory that does not allow programs to be executed."

Nu pare a fi o eroare din partea clientului și nu există erori de transport TCP. Problema este la server.

Atunci când se depanează trafic web, se caută mai întâi erori TCP și apoi se trece la traficul HTTP.

Figura .3 – Cererea POST a clientului este nereușită și indică o problemă a serverului web [3]

Analiza navigării pe web include și analiza comunicațiilor HTTPS Hypertext Transfer Protocol Secure. La începutulul unei sesiuni securizate de HTTP se realizează conexiunea TCP urmată de procesul de securizare.

RFC 2818 definește utilizarea HTTP peste TLS (Transport Layer Security – Securitate la nivelul de transport) pentru comunicații protejate. RFC 2246 detaliază TLS versiunea 1.0 ce este bazată pe versiunea 3.0 a SSL. Deși sunt diferențe minime între acestea, cele două nu sunt interoperabile.

Când se lucrează cu trafic HTTPS opțiunea de reasamblare a fluxurilor TCP trebuie să fie activată. Astfel se pot vizualiza și filtra pachetele TLS utilizate pentru realizarea conexiunii.

Figura . – Activarea opțiunii de reasamblare a fluxurilor TCP

Concluzii:

HTTP utilizează un model cerere/răspuns pentru a transfera date între gazde. Comunicațiile HTTP folosesc TCP pe post de mecanism de transport. Cel mai des utilizat număr de port pentru HTTP este 80.

Clientul trimite comenzi cum ar fi GET și POST către serverul HTTP. Serverul HTTP trimite un cod de răspuns numeric. Codurile mai mari de 399 identifică probleme ale clientului și ale serverului.

Atunci când se analizează comunicații HTTP, dacă apare modificatorul de cerere IfModified-Since înseamnă că o pagină se află în cache-ul clientului. Dacă serverul răspunde cu codul 304 Not Modified, clientul va încărca pagina din cache în loc să folosească rețeaua. Aceasta va afecta analiza timpului de încărcare a paginilor web.

Sesiunile de browsing web pot fi lente datorită problemelor TCP, interdependența cu alte site-uri web (cum ar fi agenții de publicitate) și site-uri web ne-optimizate. Wireshark permite reconstruirea paginilor web și exportarea obiectelor HTTP.

Traficul HTTPS folosește TLS pentru a crea o conexiune sigură pentru traficul HTTP. Aceste conexiuni încep cu o conexiune TCP care este urmată de o inițiere a conexiunii securizată (three-way handshake). Pe parcursul acestui proces de conexiune, clientul și serverul negociază parametrii de securitate cum ar fi suita de cifre ce va fi folosită pentru comunicațiile securizate.

Wireshark poate decripta sesiuni HTTPS cât timp există cheia de decriptare și analizorul este configurat să aplice acea cheie conversației HTTPS.

Analiza traficului SMTP

SMTP este aplicația standard pentru trimiterea de e-mail, și în mod implicit, acest tip de comunicații nu sunt securizate. Portul utilizat pentru comunicațiile SMTP este portul cu numărul 25, dar SMTP poate fi configurat (ca multe alte aplicații) să utilizeze un alt port. Un număr din ce în ce mai mare de furnizori de internet și configurații firewall blochează conexiunile SMTP pe portul 25 – aceasta s-a întâmplat, în mare parte, pentru a încerca stoparea trecerii mesajelor de tip spam prin rețelele furnizorilor. Mesajele SMTP sunt livrate în formatul Internet Message Format.

Problemele comunicației SMTP pot începe de la procesul de conexiune TCP și poate fi de asemenea afectată de un timp de latență mare și pierdere de pachete. Dacă serverul SMTP răspunde cu coduri numerice mai mari ca 399, acesta indică o problemă în procesul de transmitere al mail-ului.

Analiza traficului FTP

Într-o comunicație tipică FTP, un canal de comandă este stabilit pe portul 21 al serverului FTP. Pentru a transfera date (cum ar fi directoare sau fișiere), un alt canal este activat alocându-se numere de port în mod dinamic chiar dacă în documentații se specifică ca portul 20 să fie folosit pentru canalul de date.

Clientul FTP trimite comanda USER (toate comenzile FTP sunt scrise cu majuscule) urmată de un nume de utilizator apoi comanda PASS urmată de parolă. Chiar dacă numele de utilizator introdus este greșit serverul răspunde cu 331 Password Required pentru numele de utilizator. Dacă parola este incorectă, serverul răspunde cu 530 Password Not Accepted. Odată ce utilizatorul s-a logat, acesta poate folosi comenzi pentru a examina conținutul unui director, să schimbe directoarele sau să lanseze un canal secundar pentru transfer de date.

Transferul de date ar eloc pe o conexiune separată de cea de comandă. Datele transferate pot fi un fișier sau conținutul unui director. Există două modalități pentru transferul de date – modul pasiv și modul activ.

Problemele comunicației FTP încep cu handshake-ul TCP. Dacă un server nu are daemonul de FTP activ, acesta răspunde la pachetele TCP SYN pe portul FTP cu un răspuns TCP RST. Dacă serverul FTP este configurat să folosească un alt port decât cel folosit de client, conexiunea FTP nu poate fi stabilită corespunzător. În plus, dacă un firewall blochează suportul pentru modul pasiv de transfer, încercarea de conexiune va eșua cum arată și figura 3.5. În acest exemplu clientul trimite comanda PASV și serverul răspunde cu adresa sa IP și un număr de port pentru conexiune în modul pasiv. Aceasta indică faptul că serverul suportă acest tip de transfer.

Figura . – Clientul nu poate stabili o conexiune în modul pasiv [3]

Clientul încearcă să realizeze conexiunea pe portul furnizat dar serverul nu răspunde la tentativele de conexiune. Dacă portul este deschis, serverul ar trebui să răspundă cu un SYN/ACK. Dacă portul este închis serverul ar trebui să răspundă cu un răspuns TCP RST. Dacă niciun răspuns nu este recepționat, un firewall aflat pe traseu sau pe server ar putea bloca eforturile de conectare la acest port. După 5 încercări de realizare a conexiunii, clientul renunță și închide canalul de comandă.

Data Loss Prevention (DLP) – Prevenirea scurgerilor de date

În prezent, accesul la informație și transferarea datelor sunt mai ușor de realizat decât oricând, iar o mare parte din aceste date prezintă diferite nivele de sensibilitate. Anumite informații sunt confidențiale în mod implicit prin apartenența lor la diferite organizații și nu sunt destinate publicului. Unele date sunt sensibile din cauza cerințelor juridice, legilor naționale și reglementărilor internaționale. Deseori valoarea informației este dependentă de păstrarea confidențialității acesteia (trebuie avute în vedere proprietatea intelectuală și concurența).

Scurgerile de date dintr-o companie pot fi jenante sau mai rău pot duce la pierderea avantajului față de concurență și pierderea de conturi. Atunci când o organizație acționează în non-conformitate cu actele de confidențialitate și alte legi integritatea acesteia poate fi în pericol.

Având în vedere creșterea evenimentelor de pierderi de date, companiile nu au de ales și trebuie să ia măsuri pentru pentru a proteja datele sensibile. Date confidențiale despre angajator și client, documente legale, proprietate intelectuală, toate sunt expuse. Provocarea constă în abordarea eficientă a acestei probleme fără a afecta productivitatea angajaților sau creșterea numărului de persoane din departamentul IT. Tehnologia evoluează, dar în final este ineficientă în a înțelege intențiile utilizatorului.

Cu toate intrumentele disponibile pentru distribuirea de informație este foarte ușor de făcut o greșeală ce nu poate fi remediată. Pentru ca situația să devină și mai complexă, pe lângă severitatea scurgerilor de date, acum există soluții ce fac ca acest lucru să se realizeze și mai ușor: servere cloud, Google Docs și abuz simplu și neintenționat față de reglementările companiei, cum ar fi un angajat ce își ia laptopul de la serviciu acasă. De fapt, cele mai multe cazuri de scurgeri de date sunt accidentale.

Termenul de DLP a apărut pe piață prima dată în 2006 și a început să devină popular la începutul lui 2007. La fel ca și alte produse de securitate cum ar fi firewall-uri și sisteme de detectare a intruziunilor (Intrusion Detection System – IDS), soluțiile de DLP au avut o creștere considerabilă în ultimii ani, implementările lungi, dificultatea administrării și costurile ridicate asociate cu produsele tradiționale de DLP devenind rapid istorie. [6]

DLP este cea mai bună soluție pentru prevenirea scurgerilor de date accidentale prin aplicarea unei politici corporative ce funcționează în mod automat și ce va captura datele sensibile înainte ca acestea să părăsească organizația. Se realizează identificarea, monitorizarea și protejarea transferului de date prin inspecția în profunzime a conținutului și analiza parametrilor de tranzacție (cum ar fi sursă, destinație, tip de date, protocolul utilizat). Pe scurt, tehnologia DLP detectează și previne transmisia neautorizată de informații confidențiale.

Tehnologia DLP mai este cunoscută și sub alte denumiri cum ar fi Data Leak Prevention, Information Leak Detection and Prevention, Information Leak Prevention, Content Monitoring and Filtering, și Extrusion Prevention. În termeni simpli, este o tehnologie ce permite vizibilitate la nivel de conținut în o rețea prin extragerea informației de nivel aplicație din traficul analizat, programul implementat bazându-se pe datele obținute din trafic. [7]

Program de prevenire a scurgerilor de date, bazat pe informațiile colectate din rețea

Soluția de prevenire a scurgerilor de date de la Check Point

Modulul software pentru prevenirea scurgerilor de date de la Check Point (DLP Software Blade) combină tehnologia și procesele pentru a revoluționa această tehnică, ajutând întreprinderile în a proteja, preventiv, informații sensibile de la pierderea accidentală, în educarea utilizatorilor cu privire la politicile adecvate de manipulare a datelor și oferindu-le posibilitatea de a remedia incidente în timp real.

Figura . – Arhitectura globală a sistemului de prevenire a scurgerilor de date, bazat pe informațiile colectate din rețea

Modulul de DLP face parte din Check Point Security Gateway R77, aplicația de securitate cu structură modulară controlată de sistemul de operare denumit Gaia. Arhitectura modulară oferită este diferită deoarece oferă specialiștilor IT posibilitatea personalizării unei soluții de securitate pe o singură platformă comună care poate fi ușor extinsă sau modificată în funcție de cerințe. Oferă un grad mare de flexibilitate fără a scădea performanțele.

Un software blade este o aplicație de securitate cum ar fi un firewall, un sistem de prevenire a intruziunilor, un sistem de prevenire a scurgerilor de date (DLP), filtrare URL și multe altele, ce este independentă, modulară și gestionată la nivel central. Ele permit organizațiilor să realizeze o configurație de securitate ce are ca obiectiv combinația potrivită de protecție și de investiție în această soluție.

Figura . – Arhitectura modulară a soluției de securitate – Software Blade Architecture [5]

Instalare și configurare Security Gateway R77

În figura 4.3 este prezentat pasul din instalarea inițială unde se configurează interfața de management a aplicației de securitate prin intermediul căreia se accesează ulterior interfața web și consolele de control, configurare și monitorizare ale modulelor de securitate.

Figura .3 – Setarea adresei IP pentru interfața de managemement a aplicației de securitate

În implementarea virtuală realizată în VMware Workstation 10, serverul de management al securității și gateway-ul de securitate s-au instalat pe aceeași mașină virtuală.

Figura . – Instalare Security Gateway și Security Management

În figura 4.5 este prezentată interfața web a soluției de securitate de la Check Point, mai exact configurarea interfețelor de rețea, iar in figura 4.6 setarea gateway-ului pentru acces la Internet.

Figura . – Configurarea adreselor IP ale interfețelor de rețea

Figura . – Setarea adresei IP a gateway-ului rețelei externe

Figura . – Mașini virtuale realizate folosind VMware Workstation 10

Au fost folosite cinci mașini virtuale în VMware, pentru care s-au setat în mod corespunzător adaptoarele de rețea și anume:

Mașina virtuală ce conține soluția de securitate are nevoie de trei adaptoare de rețea: unul pentru management (VMnet1), unul pentru rețeaua internă (VMnet3) și unul pentru rețeaua externă (modul Bridged a fost ales).

Serverul de mail din rețeaua internă are un adaptor de rețea și anume VMnet3

Pentru testarea politicilor de DLP s-au configurat două mașini virtuale pe post de utilizator și destinație, cea internă cu sistemul de operare Windows XP (VMnet3) iar cea externă cu sistemul de operare Windows 7 (Bridged)

Pentru SMTP s-a configurat și un server de mail în rețeaua externă care să primească mesaje de la serverul de mail din interiorul rețelei protejate.

Pentru administrarea politicilor de securitate, monitorizarea evenimentelor din rețea, instalarea de actualizări pentru produse, administrarea unui mediu cu mai multe domenii, etc, se folosesc console ce se acesează folosind credențialele mașinii virtuale și adresa IP a interfeței de management.

Figura . – Instalarea SmartConsole R77

Pentru crearea și administrarea politicilor de securitate se utilizează consola denumită SmartDashboard.

Figura . – Accesarea SmartDashboard

În SmartDashboard a fost actualizată topologia porții de securitate pentru recunoașterea rețelei interne și a celei externe și introduse principalele elementele din rețea.

Figura . – Topologia rețelelor în SmartDashboard

Activarea și configurarea modulului de DLP

Pentru utilizarea soluției de prevenire a scurgerilor de date se selecteză software blade-ul de Data Loss Prevention după care se trece la o serie de configurări inițiale ce pot fi ulterior modificate.

Figura . – Aplicațiile de securitate disponibile pentru gateway

Se setează domeniul ce se dorește a fi protejat (s-a setat domeniul test.ro adică domeniul configurat pentru serverul de mail din rețeaua internă).

Figura . – Setarea domeniului

Se specifică apoi dacă se dorește un portal web pentru rezolvarea incidentelor apărute și unde sunt plasate în carantină mail-urile ce au fost blocate de o anumită politică de securitate. Se specifică, de asemenea, ce server de mail va fi folosit de gateway pentru trimiterea notificărilor de securitate (se va folosi pe acest post serverul de mail din rețeaua internă).

Figura . – Activarea portalului web pentru DLP și specificarea serverului de mail pentru trimiterea de notificări

Se precizează pentru ce protocoale se va implementa soluția de DLP.

Figura . – Protocoale

Figura . – Finalizarea configurațiilor de bază

Odată ce acești pași au fost efectuați se poate trece la implementarea politicilor de securitate dorite și activarea altor opțiuni sau modificarea celor specificate în configurarea inițială.

Crearea, implementarea și monitorizarea regulilor de DLP

Politica DLP definește ce date vor fi protejate de la a fi transmise în afara rețelei externe, incluzând: conținutul email-ului, recipienții acestuia, atașamentele (chiar și arhivate), transferurile FTP spre exteriorul rețelei, postări web, mail web și altele. Politica dictează acțiunea pe care modulul DLP o ia atunci când o transmisie este capturată.

O regulă DLP este constituită din:

Tipurile de date ce trebuie protejate: unele complexe, altele simple cum ar fi chiar un cuvânt. Se pot adăuga oricât de multe tipuri de date în funcție de necesități.

O sursă a transmisiei: implicit, întreaga rețea internă (politica va verifica toate transmisiunile de date, ce vin de la orice utilizator din rețeaua internă, ce conțin tipurile de date definite) sau un anumit utilizator, grup, sau rețea.

Figura . – Specificarea sursei transmisiunii

O destinație: implicit, orice se află în afara organizației . Se pot alege ca destinații orice obiecte de rețea definite în SmartDashboard și se poate proteja transferul de date între utilizatori interni.

Un protocol: implicit, oricare, dar se poate alege ca regula să se aplice doar postărilor HTTP, doar transferurilor FTP, etc.

Acțiunea ce se va lua: răspunsul DLP atunci când o regulă se încalcă: detectarea și logarea, informarea expeditorului, amânarea pâna la decizia utilizatorului de a trimite sau nu informațiile sensibile și specificarea motivației pentru care face acest lucru, sau blocarea transmisiunii.

Tipul de urmărire: atunci când o transmisiune încalcă o regulă, în mod implicit este logată ca incident în consola de monitorizare SmartView Tracker. Se pot adăuga notificări pe mail și alte metode de urmărire.

Nivelul de severitate al regulii

Intervalul de timp pentru care regula DLP să fie activă.

S-au creat și implementat reguli personalizate pentru prevenirea scurgerilor de date din rețeaua internă și regulile s-au testat pentru toate cele trei protocoale (FTP, HTTP și SMTP), folosind o gamă largă de tipuri de date și toate tipurile de acțiuni asupra datelor ce au încălcat o regulă.

Clientul numit UserCheck se instalează pe terminale în scopul comunicării cu gateway-ul și afișarea notificărilor de interacțiune pentru utilizatori. Aceștia aleg o opțiune în mesajul de notificare pentru un răspuns în timp real. Notificările de incidente DLP pot fi trimise pe email (doar pentru incidente SMTP) sau pot apare în clientul de UserCheck în bara de sistem (pentru SMTP, HTTP și FTP).

Trafic SMTP

Testarea regulilor pentru traficul SMTP s-a realizat configurând două servere de mail, ambele pe sistemul de operare Ubuntu 14.04. S-a configurat pe cele două mașini virtuale soluția open source de server de email, iRedMail. S-au setat domeniile de nume intern, test.ro, și cel extern, extern.ro.

Ambele mașini au primit adrese statice în rețelele internă, respectiv externă, și au fost setate pentru a accepta transmisiuni SMTP de la una la alta.

Figura . – Configurarea interfeței eth0 pentru serverul de mail din rețeaua internă

Figura . – Configurarea interfeței eth0 pentru serverul de mail din rețeaua externă

Figura . – Configurarea sistemului de nume de domeniu pentru serverul de mail intern

Figura . – Configurarea sistemului de nume de domeniu pentru serverul de mail extern

Figura . – Regula de fingerprint

În figurile ce urmează se va testa regula de fingerprint definită (figura 4.21) folosind protocolul SMTP. Tehnica de fingerprint folosește un depozit (repository) ce este o locație din rețea care conține fișiere ce nu trebuie să părăsească organizația. Modulul DLP scanează aceste fișiere și generează o semnătură unică pentru fiecare. Când un fișier trece prin gateway, acesta este scanat și o semnătură este generată. Această semnătură este comparată cu semnăturile fișierelor din depozit și dacă se potrivesc, fișierului scanat nu i se permite ieșirea din rețeaua internă (în funcție de tipul de acțiune ales pentru regulă).

Figura . – Specificarea locației din rețea unde se află depozitul pentru tehnica de fingerprint

Figura . – Scanarea directorului de fingerprint de la locația specificată

Acțiune specificată este de Ask User deci se va primi un mail de la gateway pentru a confirma acest transfer. Adițional, specificăm că dorim adăugarea unui watermark documentului după ce acesta trece prin gateway pentru a face clar că acest fișier este confidențial.

Figura . – Locul de setare a watermark-ului dorit

Folosind interfața web a serverului de mail din rețeaua internă se trimite un mail ce conține un fișier din fingerprint repository spre serverul extern.

Figura . – Expedierea mail-ului de test

Figura . – Se primește pe mail notificarea DLP de la gateway

Figura . – Raportul incidentului înregistrat în SmartView Tracker

Figura . – Mail-ul în carantină în portalul de DLP

Figura . – Validarea și motivația utilizatorului pentru trimiterea acestui mail

Figura . – Confirmarea transferului

Figura . – Mail-ul recepționat de către serverul extern

Figura . – Documentul descărcat cu watermark inclus

Trafic HTTP/HTTPS

Vom aplica o regulă ce conține cuvinte cheie definite în tipul de date și vom observa notificările ce apar în bara sistemului atunci când se încearcă postarea sau încărcarea pe web prin protocolul HTTP a unui comentariu sau document ce conține cel puțin unul din acele cuvinte cheie.

Figura . – Clientul UserCheck instalat pe terminalul din rețeaua internă

Figura . – Cuvintele cheie

Figura . – Regula aplicată

Atunci când se încearcă încărcarea prin http a unui document ce conține un cuvânt cheie, modulul DLP blochează acest transfer fără opțiunea de a da o motivație deoarece a fost selectată opțiunea de blocare a transferurilor.

Figura . – Transfer blocat de gateway

Figura . – Raportul în SmartView Tracker

Se poate activa pe gateway și inspecția traficului HTTPS pentru a inspecta trafic ce este criptat de protocolul SSL. SSL securizează comunicația între clienții ce folosesc un browser web și serverele web. Furnizează confidențialitatea și integritatea datelor prin criptarea traficului. Porțile de securitate fără inspecție HTTPS activată nu observă traficul trimis prin tunelul criptat SSL. Aceasta face ca acea rețea să fie vulnerabilă la atacurile de securitate și la pierderea de informații confidențiale.

Există două tipuri de inspecție HTTPS:

Inspecție HTTPS pentru traficul de intrare: pentru a proteja serverele de cereri malicioase ce provin din Internet sau o rețea externă.

Inspecție HTTPS pentru traficul de ieșire: pentru a proteja organizația de trafic malicios trimis de un client din rețeaua internă către o destinație din afara organizației.

În cazul inspecției HTTPS pentru traficul de ieșire, când un client al organizației inițiază o conexiune HTTPS la un site securizat, poarta de securitate interceptează cererea, stabilește o conexiune securizată la site-ul web solicitat și validează certificatul serverului acestuia. Creează un nou certificat SSL pentru comunicația dintre gateway și client, trimite clientului noul certificat și continuă negocierea SSL cu acesta.

Folosind cele două conexiuni SSL decriptează datele criptate de la client, inspectează conținutul decriptat cu politica de securitate și criptează din nou datele pentru a păstra confidențialitatea pentru restul drumului până la serverul web destinație.

Figura . – Activarea opțiunii de HTTPS Inspection

Figura . – Regula de inspecție a traficului HTTPS

Pentru verificarea inspecției HTTPS va fi creată o regulă nouă pentru HTTP ce va verifica proprietățile documentului și va decide pe baza acestora dacă să blocheze sau nu fișierul ce se vrea a fi încărcat pe soluția de web mail securizat de la yahoo. Am stabilit ca fișierele de tip pdf și cu o dimensiune mai mare de 1000kB să fie blocate.

Figura . – Crearea unui tip de date pe baza atributelor fișierului

Figura .41 – Raportul din SmartView Tracker la încărcarea pe un site securizat prin SSL a unui document ce a încălcat o regulă

Trafic FTP

Pentru testarea regulilor de prevenire a scurgerilor de date pe protocolul FTP s-au utilizat FileZilla Server și Filezilla Client. Regula testată în cele ce urmează specifică ca atunci când într-un document există un tipar (un cuvânt sau o expresie ce se repetă de un anumit număr de ori, ce se precizează în crearea tipului de date) utilizatorul va fi informat la expediere că transmite informații confidențiale.

Figura .42 – Serverul de FTP aflat pe mașina virtuală din rețeaua externă către care se va trimite documentul

Figura .43 – Clientul de FTP și notificarea apărută la transferarea documentului ce a încălcat regula

Figura . – Raportul din SmartView Tracker referitor la transferal FTP efectuat

Concluzii

În urma implementării și testării cu reguli personalizate a soluției de prevenire a scurgerilor de date de la Check Point pot concluziona eficiența și importanța crucială pe care o joacă un sistem DLP în cadrul unei organizații. Soluția este eficientă prin simplitatea și rapiditatea cu care se remediază incidentele apărute în rețea și prin interfețele de administrare și creare de reguli foarte complexe dar în același timp intuitive.

HTTP(S), FTP sau SMTP, indiferent care dintre aceste protocoale este utilizat pentru transferul de date în afara rețelei, identicarea tipurilor de date ce au fost definite ca fiind confidențiale în reguli s-a realizat cu succes iar răspunsul modulului de DLP a fost prompt.

Pe viitor doresc specializarea pe această ramură a securității informatice și implementarea de astfel de soluții la companiile ce solicită acest lucru, având deja experiență în acest sens.

Anexe

Anexa 1 – Diagramă cuprins

Anexa 2 – Diagrama logică de lucru a sistemului de prevenire a scurgerilor de date, bazat pe informațiile colectate din rețea

Anexa 3 – Tabel centralizator al adreselor IP utilizate

Anexa 4 – Tabel centralizator al adreselor IP utilizate al resurselor hardware și software utilizate

Anexe

Anexa 1 – Diagramă cuprins

Anexa 2 – Diagrama logică de lucru a sistemului de prevenire a scurgerilor de date, bazat pe informațiile colectate din rețea

Anexa 3 – Tabel centralizator al adreselor IP utilizate

Anexa 4 – Tabel centralizator al adreselor IP utilizate al resurselor hardware și software utilizate