Universitatea “Politehnica” din Bucureşti

Facultatea de Electronică, Telecomunicaţii şi Tehnologia Informaţiei

Sistem de detecţie şi prevenire a intruziunilor într-o reţea

Proiect de diplomăPrezentat ca cerinţă parţială pentru obţinerea titului de

Inginer în domeniul Calculatoare şi Tehnologia Informaţieiprogramul de studii de licenţa Ingineria Informaţiei

2013

Conducător ştiinţific Absolvent

Conf.dr.ing. Mihai STANCIU Alin-Florentin Oprea

Cuprins

CUPRINS ............................................................................................................................................21.INTRODUCERE.................................................................................................................................12.PRINCIPIILE DETECŢIEI ŞI PREVENŢIEI INTRUZIUNILOR ...................................................................22.1 UTILIZAREA TEHNOLOGIILOR IDPS .......................................................................................................22.2 FUNCŢIILE CHEIE ALE TEHNOLOGIILOR IDPS............................................................................................32.3 METODOLOGII COMUNE DE DETECŢIE ...................................................................................................52.3.1 DETECŢIA BAZATĂ PE SEMNĂTURI ...........................................................................................................52.3.2 DETECTAREA ANOMALIILOR ...................................................................................................................62.3.3 ANALIZA PROTOCOALELOR DE TIP STATEFUL..............................................................................................72.4 TIPURI DE TEHNOLOGII IDPS...............................................................................................................82.5 INTRUZIUNILE ..................................................................................................................................93. TEHNOLOGII IDPS.........................................................................................................................123.1 COMPONENTE ŞI ARHITECTURĂ ......................................................................................................... 123.1.1 COMPONENTE TIPICE ..........................................................................................................................123.1.2 ARHITECTURA DE REŢEA ......................................................................................................................123.2 CAPABILITĂŢI DE SECURITATE ............................................................................................................133.2.1 CULEGEREA INFORMAŢIILOR ................................................................................................................133.2.2 CAPABILITĂŢI DE LOGARE.....................................................................................................................133.2.3 DETECŢIA..........................................................................................................................................143.2.4 PREVENŢIA........................................................................................................................................163.3 MANAGEMENT ..............................................................................................................................163.3.1 IMPLEMENTARE .................................................................................................................................163.3.2 OPERARE ŞI MENTENANŢA...................................................................................................................183.3.3 COMPETENŢE DE CONSTRUIRE ŞI MENTENANŢĂ.......................................................................................204. IDPS-URI LA NIVEL REŢEA............................................................................................................. 224.1 STIVA TCP/ IP............................................................................................................................... 224.2 COMPONENTE ŞI ARHITECTURĂ ......................................................................................................... 264.2.1 COMPONENTE TIPICE ..........................................................................................................................264.2.2 ARHITECTURA DE REŢEA ŞI LOCAŢIILE SENZORILOR ...................................................................................274.3 CAPABILITĂŢI DE SECURITATE ............................................................................................................304.3.1 CULEGEREA INFORMAŢIILOR ................................................................................................................304.3.2 CAPABILITĂŢI DE LOGARE.....................................................................................................................314.3.3 DETECŢIA..........................................................................................................................................314.3.4 PREVENŢIA........................................................................................................................................354.4 MANAGEMENT ..............................................................................................................................374.4.1 IMPLEMENTARE .................................................................................................................................375. IDPS-URI LA NIVEL DE HOST......................................................................................................... 395.1 COMPONENTE ŞI ARHITECTURĂ ......................................................................................................... 395.1.1 COMPONENTELE TIPICE .......................................................................................................................395.1.2 ARHITECTURA DE REŢEA .....................................................................................................................40

5.1.3 LOCAŢIA AGENŢILOR ...........................................................................................................................415.1.4 ARHITECTURA HOST-ULUI ....................................................................................................................415.2 CAPABILITĂŢILE DE SECURITATE......................................................................................................... 425.2.1 LOGARE............................................................................................................................................425.2.2 DETECŢIA..........................................................................................................................................425.2.3 PREVENŢIA........................................................................................................................................475.2.4 ALTE CAPABILITĂŢI .............................................................................................................................475.3 MANAGEMENT ..............................................................................................................................485.3.1 IMPLEMENTARE .................................................................................................................................485.3.2 OPERARE .........................................................................................................................................496. SOLUŢII PROFESIONALE IDPS .......................................................................................................506.1 ALEGEREA IDPS-ULUI...................................................................................................................... 506.2 CERINŢE PENTRU PREVENIREA EFICIENTĂ A INTRUZIUNILOR ..................................................................... 516.3 CARACTERISTICI CHEIE AL UNUI IDPS..................................................................................................527. SNORT..........................................................................................................................................557.1 PRIVIRE DE ANSAMBLU....................................................................................................................557.1.2 MODULUL SNIFFER....................................................................................................................... 567.1.3 MODULUL LOGGER ...................................................................................................................... 567.1.4 MODULUL NIDS................................................................................................................................577.1.5 MODULUL INLINE...............................................................................................................................597.2 CONFIGURARE ............................................................................................................................... 597.2.1 INCLUDE...........................................................................................................................................597.3 PREPROCESOARELE .........................................................................................................................627.3.1 FRAG3 .............................................................................................................................................637.3.2 SFPORTSCAN .....................................................................................................................................647.3.3 HTTP INSPECT ..................................................................................................................................647.3.4 PREPROCESORUL DE DATE SENSIBILE......................................................................................................647.4 SEMNĂTURI / REGULI...................................................................................................................... 667.4.1 SCRIEREREA REGULILOR ......................................................................................................................707.4.2 ANTETUL UNEI REGULI ........................................................................................................................707.4.3. OPŢIUNILE UNEI REGULI .....................................................................................................................717.4.4 PRAGUL UNEI REGULI..........................................................................................................................748. SISTEM PENTRU PREVENIREA SCURGERILOR DE DATE.................................................................748.1 SNORT – SISTEM DE DETECTARE ŞI PREVENŢIE A SCURGERILOR DE DATE...................................................... 748.2 IPTABLES.......................................................................................................................................758.3 ARHITECTURA DE REŢEA UTILIZATĂ..................................................................................................... 808.4. METODE DE DETECŢIE ŞI PREVENŢIE...................................................................................................818.5.FILTRAREA PROTOCOLULUI HTTP ŞI HTTPS............................................................................................ 828.6 FILTRAREA PROTOCOLULUI FTP ......................................................................................................... 868.7 FILTRAREA PROTOCOLULUI SMTP...................................................................................................... 878.8 LOGAREA ......................................................................................................................................899.CONCLUZII ......................................................................................................................................110.BIBLIOGRAFIE................................................................................................................................2

1

1.Introducere

În ziua de astăzi cu hackerii şi hoţii de identitate securitatea computerului a devenit tot mai instabilă, astfel pentru a fi mereu cu un pas în faţa atacurilor rău voitoare companiile �i nu numai au început sa investească în programe antivirus de reţea, firewall-uri, securitatea mesajelor provenite din po�ta electronică �i web pentru protecţia asupra posibilelor ameninţări externe. Cum prin simpla conectare a unui stick poate prezenta o teribilă ameninţare, problema detecţiei şi prevenirii intruziunilor a devenit una extrem de importantă în zilele noastre, problemă abordată şi în această lucrare.

Scopul principal al lucrării este acela de a veni in ajutorul staţiilor expuse la risc prin proiectarea unui software ce are rolul de a identifica atacurile rău voitoare asupra reţelelor şi resurselor acesteia, de a stopa intruziunile detectate şi de a imuniza sistemul. Informaţiile provenite in urma detecţiei se vor comunica staţiei centrale mai precis adminului printr-o anumita notificare, pentru a putea lua decizia optimă cât mai repede cu putinţă cu privire la starea reţelei.

2

2.Principiile detecţiei şi prevenţiei intruziunilor

Detectare intruziunilor reprezintă procesul de monitorizare a evenimentelor ce au loc într-un sistem informatic sau într-o reţea, precum şi analizarea acestora pentru semne ce indică incidente posibile ce sunt încălcări sau ameninţări iminente de încălcare a politicilor de securitate ale calculatorului, a politicilor acceptate de utilizare sau practicile de securitatestandard. Incindentele pot avea multe cauze, ca malware-urile(ex: worms, spyware), atacatori externi ce încearcă să obţină accesul neautorizat la sistem precum şi utilizatori autorizaţi ce întrebuinţează greşit privilegiile oferite sau încearcă să obţină unele adiţionale ce nu sunt autorizate. Cu toate că majoritatea incindentelor sunt de natură maliţioasă, multe altele nu sunt: de exemplu, o persoană poate introduce greşit adresa unui calculator, şi astfel, neintenţionat să acceseze un alt sistem fără autorizaţie.

Prevenirea intruziunilor presupune detectare şi încercarea de a opri incidente posibile detectate.

Un sistem de detecţie a intruziunilor este un software ce automatizează procesul de detecţie.

Un sistem de prevenire a intruziunilor este un software ce are toate capabilităţile sistemului de detecţie, dar care poate să încerce să oprească eventualele incindente.

Sistemele de detectare şi prevenire ( IDPS1) se concentrează în principal pe : identificarea posibilelor incidente; logare de informaţii despre acţiunile întreprinse; încercarea de stopare a incidentelor şi raportarea acestora la administratorii de

securitate.

Multe IDPS-uri, pe lângă logare, pot preveni ameninţările detectate în a-şi îndeplini scopul. Sunt folosite mai multe tehnici de acţiune în oprirea atacurilor: schimbarea mediului de securitate (de exemplu, reconfigurarea unui firewall) sau schimbarea conţinutului atacului.

2.1 Utilizarea tehnologiilor IDPS

Scopul principal al IDPS-urilor este identificarea posibilelor incindente.De exemplu, un IDPS poate detecta când un atacator a compromis cu succes un sistem prin exploatarea vulnerabilităţilor sale. Poate raporta apoi incindetul administratorilor de securitate, care pot iniţia acţiuni de răspuns pentru a minimiza daunele cauzate de incident2.

Multe astfel de sisteme pot fi configurate să identifice: violările politicilor de securitate(ex: setarea cu seturi de reguli asemănătoare unui

firewall, permiţănd identificarea traficului ce încalcă normele de securitatea ale unei

1 Pe parcursul lucrării se va folosi acest termen pentru a abrevia expresia consacrată din domeniu “Intrusion detection and prevention system”2 Dacă IDPS a prevenit cu succes atacul, administratorii de securitate tot doresc să fie notifica�i de atac.Este important de �tiut dacă �inta a avut o vulnerabilitate cunoscută pe care atacatorul ar fi putut să o exploateze.Asupra respectivei vulnerabilită�i pot fi lansate alte atacuri pe care IDPS nu le poate recunoa�te.

3

companii: monitorizarea transferurilor de fişiere şi recunoaşterea celor ce ar putea fi suspicioase, asemenea transferului unei baze de date într-un laptop);

activităţile de recunoaştere, ce indică de cele mai multe ori iminenţa unui posibil atac(ex: unele tool-uri de atac şi forme de malware - în special cel de tip worm) efectuează activităţi de recunoaştere ca scanarea de host-uri şi port-uri pentru identificarea unor ţinte pentru atacurile viitoare.Un IDPS poate bloca aceste acţiuni, notificând în acelaşi timp administratorii de securitatea, care pot interveni, dacă este nevoie, pentru a preveni incindente viitoare.Datorită frecvenţei foarte mari a activităţilor de recunoaştere în internet, detecţia acestora se concentrează în mod deosebit pe reţele interne.

Organizaţiile folosesc sistemele de detecţie şi prevenţie şi în alte scopuri, altele decât cele de bază:

identificarea problemelor politicilor de securitate: poate oferi indicaţii asupra calităţii controlului oferit de implementarea politicilor de securitate existente( ex: duplicarea regulilor firewall şi alertarea traficului ce ar fi trebuit blocat de către firewall, dar din cauza unor erori de configurare nu a fost blocat;

documentarea ameniţărilor existente asupra organizaţiei: logarea informaţiilor legate de ameninţările ce sunt detectate ajută la identificarea caracteristicilor şi frecvenţei diverselor atacuri asupra resurselor computaţionale ale organizaţiei.Astfel, pot fi adoptate măsurile adecvate pentru protejarea resurselor existente;

descurajarea diverselor persoane în a încălca politicile de securitate: acţiunea de monitorizare a tehnologiilor descurajează violarea normelor de securitate din cauza riscului de detecţie.

Din cauza dependenţei tot mai sporite faţă de sistemele informaţionale precum şi potenţialul impact al intruziunilor asupra acestor sisteme, IDPS-urile au devenit un plus necesar pentru infrastructura de securitate a oricărei organizaţii.

2.2 Funcţiile cheie ale tehnologiilor IDPS

Există multe tipuri de tehnologii, ce sunt diferenţiate în principal după tipurile de evenimente pe care le pot recunoaşte şi metodologiile pe care le utilizează pentru identificarea incidentelor. În plus faţă de monitorizarea şi analizarea evenimentelor pentru a identifica activităţile nedorite, toate tehnologiile efectuează de obicei următoarele funcţii:

Înregistrare informaţiilor referitoare la evenimentele observate. Informaţiile sunt de obicei înregistrate la nivel local, şi ar putea fi, de asemenea, trimise la sisteme separate, cum ar fi serverele centralizate de log, soluţiile informaţionale de securitate şi de management al evenimentelor (SIEM) sau soluţii şi sisteme enterprise de management;

4

Notificarea administratorilor de securitate despre evenimente importante observate. Această notificare, cunoscut sub numele de alertă, survine prin mai multe metode: email-uri, pagini de răspuns, mesajele de pe interfaţa cu utilizatorul a sistemului, prin trap-urile de tip SNMP( Simple Network Management Protocol) , mesaje syslog, ori programe şi script-uri definite de utilizator. Un mesaj de notificare include de obicei doar informaţii de bază cu privire la un eveniment, administratorii trebuie să acceseze IDPS-ul pentru informaţii suplimentare;

Întocmirea de rapoarte. Rapoartele rezumă evenimentele monitorizate sau oferă detalii cu privire la anumite evenimente de interes.

Unele IDPS-uri au posibilitatea de a-şi schimba profilul de securitate atunci când o nouă ameninţare este detectată. De exemplu, ar putea fi capabil să colecteze mai multe informaţii referitoare la o sesiune în special după ce este detectată activitatea malware în acea sesiune. Ar putea modifica, de asemenea, diverse setări atunci când anumite alerte sunt declanşate sau ce prioritate ar trebui asignată alertelor ulterioare detecţiei unei ameninţări deosebite.

Acţiunile de răspuns iniţiate în cazul detecţiei unor atacuri se grupează astfel:

Oprirea atacului fără vreo altă intervenţie.Acest lucru ar putea fi realizat după cum urmează:

o Terminarea conexiunii la reţea sau a sesiunii de utilizator care este utilizată pentru atac;

o Blocarea accesului la ţintă folosindu-se de adresa IP sau de un alt atribut al atacatorului;

o Blocarea oricărui acces la host-ul, serviciul, aplicaţia sau orice altă resursă vizată.

Schimbarea mediului de securitate. IDPS-ul putea schimba configuraţia altor controale sau dispozitive de securitate pentru a întrerupe un atac. Exemple comune sunt reconfigurarea unui dispozitiv de reţea (firewall, router, switch) pentru a bloca accesul către atacator sau ţintă, precum şi modificarea unui firewall de tip host-based pentru a bloca atacurile primite. Unele tehnologii pot provoca chiar instalarea unor patch-uri pe un anume host în cazul în care se detectează că acesta are vulnerabilităţi;

Schimbarea conţinutului atacului. Unele tehnologii pot elimina sau înlocui porţiuni maliţioase ale unui atac pentru a-l face benign. Un exemplu simplu este eliminarea unui fişier infectat ataşat unui email şi apoi să permită email-ului „curăţat” să ajungă la destinatar.Un exemplu mai complex este comportarea asemănătoare a unui proxy ce normalizează cererile primite, materializat prin îndepărtarea antetelor pachetelor.Acest lucru poate cauza împiedicarea unor diverse atacuri.

Un alt atribut al acestor tehnologii este faptul că acestea nu pot oferi o detecteţie caracterizată de o acurateţe maximă. Atunci când un IDPS identifică în mod incorect ca fiind rău intenţionată o activitate benignă, putem spune că a avut loc un fals pozitiv. Atunci când un IDPS nu reuşeşte să identifice o activitate malware, un rezultat de tip fals negativ a avut loc. Eliminare tuturor falsurilor pozitive şi negative nu este posibilă, în cele mai multe cazuri,

5

reducerea unuia duce la apariţia celuilalt. Multe organizaţii aleg să scadă apariţiile de falsuri negative, cu costul creşteri falsurilor pozitive, fapt ce duce la detecţia mai multor evenimente periculoase, făcându-se uz de mai multe resurse de analiză pentru a se face diferenţa între evenimentele fals pozitive şi cele malware. Modificarea configuraţiei unui IDPS pentru a îmbunătăţi precizia de detectare este cunoscută sub numele de tuning. Cele mai multe tehnologii IDPS oferă funcţionalităţi ce combat utilizarea tehnicile comune de evaziune.Evaziunea reprezintă modificarea formatului activităţilor malware, astfel încât „înfăţişarea” acestora se schimbă, dar efectul rămâne acelaşi. Atacatorii folosesc tehnici de evaziune pentru a încerca să prevină detecţia atacurilor realizată de IDPS-uri.De exemplu, un atacator ar putea codifica caractere text într-un anume mod, ştiind că ţinta ştie să interpreteze caracterele codificate, în speranţa că orice IDPS de monitorizare nu o face. Cele mai multe tehnologii IDPS pot depăşi tehnicile comune de evaziune prin duplicarea unor procesări speciale efectuate de către ţinte.În cazul în care IDPS-ul poate "vedea" activitatea în acelaşi mod în care o face ţinta, atunci tehnicile de evaziune vor fi ineficiente în încercarea de a ascunde atacurile.

2.3 Metodologii comune de detecţie

Sunt utilizate mai multe metodologii pentru a detecta incidentele.Principalele clase de detecţie sunt bazate pe:

Semnături; Anomalii Analiza protocoalelor de tip stateful

Cele mai multe tehnologii IDPS utilizează metodologii de detecţie multiple, fie separat, fie integrate, pentru asigurarea unei detecţii cât mai largi şi mai precise.

2.3.1 Detecţia bazată pe semnături

O semnătură reprezintă un model ce corespunde unei ameninţări cunoscute. Detecţia bazată pe semnături este procesul de comparare a semnăturior împotriva evenimentelor observate pentru a identifica posibilele incidente.Exemple de semnături:

O încercare de conexiune telnet cu numele de utilizator "root"(reprezintă o încălcare a politicii de securitate a unei organizaţii);

Un email cu un subiect de genul "Imagini gratuite!" şi un fişier ataşat cu numele "freepics.exe", care sunt caracteristici ale unei forme cunoscute de malware;

Un log al sistemului de operare, cu o valoare de cod de stare 645, ceea ce indică faptul că auditul gazdei a fost dezactivat.

Acest tip de detecţie este foarte eficient în detectarea ameninţărilor cunoscute, dar în mare parte ineficientă la detectarea ameninţărilor necunoscute anterior, ameninţărilor deghizate de utilizarea unor tehnici de evaziune, şi a multe variante de ameninţări cunoscute. De exemplu, în cazul în care un atacator a modificat malware-ul în exemplul precedent pentru a utiliza un nume de "freepics2.exe", o semnătură în căutarea lui "freepics.exe" nu l-ar potrivi.

6

Se poate spune că este cea mai simplă metodă de detectare, deoarece compară doar unitatea curentă de activitate, cum ar fi un pachet sau o intrare din loguri, cu o listă de semnături utilizând operatorii de comparare a şirurilor de caractere. Tehnologiile de detectare bazate pe semnături nu au capacitatea de a întelege reţelele sau protocoale de tip aplicaţie şi nu pot urmări şi înţelege starea comunicaţiilor complexe. De exemplu, acestea nu pot asocia o cerere cu răspunsul corespunzător. Le lipseşte capacitatea de a-şi aminti cererilor anterioare la procesarea celei actuale. Această limitare împiedică detectare atacurilor formate din mai multe evenimente, în cazul în care nici unul din evenimentele nu conţine o indicaţie clară a unui atac.

2.3.2 Detectarea anomaliilor

Detecţia anomaliilor reprezintă procesul de comparare a definiţiilor activităţilor ce sunt considerate normale cu definiţiile acelor evenimente observate pentru a identifica abaterile semnificative. Un IDPS ce foloseşte detectia anomaliilor deţine nişte profiluri ce reprezintă comportamentul normal al utilizatorilor, host-urilor din reţea, conexiunilor la reţea sau al aplicaţiilor. Profilurile sunt dezvoltate prin monitorizarea caracteristicilor activităţii tipice într-o perioadă de timp. De exemplu, un profil de reţea ar putea arăta ca activitatea web cuprinde o medie de 14% din banda de reţea în timpul orelor tipice de lucru. Sunt folosite apoi metode statistice pentru a compara caracteristicile activităţii curente cu pragurile specifice din profil, cum ar fi detectarea momentului în care activitatea web foloseşte mult mai multă lăţime de bandă decât este aşteptat, alertând apoi administratorul. Profilurile pot fi dezvoltate pentru mai multe atribute comportamentale, cum ar fi numărul de email-uri trimise de un utilizator, numărul de încercări de autentificare eşuate realizate de către un host, precum şi nivelul de utilizare al procesorului pentru un host într-o anumită perioadă de timp.

Beneficiul major al metodelor bazate pe detecţia anomaliilor este că acestea pot fi foarte eficiente în detectarea ameninţărilor necunoscute anterior. De exemplu, să presupunem că un calculator este infectat cu un nou tip de malware. Malware-ul poate consuma resursele de procesare ale computerului, trimiţând un numar mare de email-uri, iniţiază foarte multe conexiuni la reţea, fiind astfel caracterizat de un comportament total diferit faţă de profilul stabilit calculatorului respectiv.

Un profil iniţial este generat după o perioadă de timp(câteva zile, uneori săptămâni), numită perioadă de formare. Acesta poate fi static sau dinamic. Odată generat, un profil static râmăne neschimbat, cu excepţia cazului în care IDPS-ul va genera un nou profil. Un profil dinamic se ajustează în mod constant pe măsură ce sunt observate evenimente suplimentare. Deoarece sistemele de calcul şi reţelele se schimbă în timp, măsurile corespunzătoare unui comportament normal, de asemenea, se modifică; un profil static va deveni în cele din urmă inexact, aşa că va trebui regenerat periodic. Profilurile dinamice nu au această problemă, dar acestea sunt sensibile la tentativele de evaziune folosite de către atacatori. De exemplu, un atacator poate efectua ocazional un numar mic de activităţi malware, apoi creşte încet frecvenţa şi numărul activităţilor. În cazul în care rata de schimbare este suficient de mică,IDPS-ul ar putea crede activitatea de malware ca fiind un comportament normal şi să îl includă în profilul său. Activitatea de malware ar putea fi, de asemenea, obervată de către un IDPS în timp ce construieşte profilurile sale iniţiale. Includerea neintenţionată a activităţilor malware, ca parte a unui profil, este o problemă comună. În unele cazuri, administratori pot modifica profilul să excludă activitatea ce este cunoscută drept dăunătoare din profil.

7

O altă problemă cu construcţia profilurilor este că aceasta poate fi foarte dificilă, în unele cazuri, pentru a le face corecte, deoarece activitatea de calcul poate fi foarte complexă. Dacă o anume activitate de întreţinere ce efectuează transferuri de fişiere mari are loc doar o dată pe lună, s-ar putea să nu fie observată în timpul perioadei de formare; atunci când se va produce întreţinerea, este probabil să fie considerată o deviere semnificativă de la profil şi se va declanşa o alertă. Produsele IDPS ce se bazează pe acestă metodă produc de multe ori mai multe alarme false de tip fals pozitiv din cauza activităţilor benigne care se abat semnificativ de la profil, în special în mediile mai diverse sau dinamice. O altă problemă notabilă este acea că adesea este dificil pentru analişti să determine iniţial de ce un anumit tip de alertă a fost generată, iar apoi să o valideze(să nu constituie un fals pozitive), din cauza complexităţii evenimentelor şi a numărului de evenimente care ar fi putut să o cauzeze.

2.3.3 Analiza protocoalelor de tip stateful

Reprezintă procesul de compararea a profilurilor prestabilite ale definiţiilor, general acceptate, ale activităţilor benigne ale protocoalelor pentru fiecare stare de protocol împotriva evenimentelor observate pentru a identifica deviaţiile. Spre deosebire de detecţia anomaliilor, care foloseşte profiluri specifice host-urilor sau reţelei, această analiză se bazează pe profiluri universale, dezvoltate de diverşi furnizori ce specifică modul în care ar trebui să fie utilizate sau nu anumite protocoale.”Stateful” înseamnă că IDPS-ul este capabil să înţeleagă şi să urmărească starea protocoalelor specifice nivelului reţea, transport sau aplicaţie, în cazul celor care au noţiunea de stare. De exemplu, atunci când un utilizator începe o sesiune de FTP( File Transfer Protocol ), sesiunea este iniţial într-o stare neautentificată. Utilizatorii neautentificaţi ar trebui să efectueze doar câteva comenzi în această stare, cum ar fi vizualizarea informaţiilor de ajutor sau furnizarea de nume de utilizator şi parole. O parte importantă a înţelegerii stării este asocierea cererilor cu răspunsuri, astfel încât atunci când are loc o tentativă de autentificare FTP, IDPS-ul poate determina dacă acesta a fost de succes prin căutarea codului de stare în răspunsul corespunzător. Odată ce utilizatorul a fost autentificat cu succes, sesiunea este în stare autentificată, aşteptându-se de la utilizatori efectuarea oricărei comenzi dintr-un grup. Efectuarea celor mai multe dintre aceste comenzi în stare neautentificată vor fi considerat suspecte, dar în stare autentificată efectuarea celor mai multe dintre ele este considerată benignă.

Pot fi identificate secvenţe neaşteptate de comenzi, cum ar fi emiterea unei comenzi în mod repetat sau emiterea unei comenzi fără a emite în primul rând o comandă de care aceasta depinde. O altă caracteristică de urmărire este aceea că pentru protocoale care efectuează autentificare, poate fi urmărit autentificatorul pentru fiecare sesiune şi să fie înregistrat pentru activităţi suspecte. Acest lucru este util atunci când se investighează un incident. Unele IDPS-uri pot utiliza informaţiile autentificatorului pentru a defini activiţăti acceptate pentru diferite clase de utilizatori sau pentru anumiţi utilizatori.

Această analiză include, de obicei, controale rezonabile asupra unor comenzi individuale, cum ar fi lungimea minimă şi maximă de argumente. Dacă o comandă are, de obicei, un nume de utilizator ca argument format din maxim 20 de caractere, atunci un argument cu o lungime de 1000 de caractere este suspect. În cazul în care argumentul cu o lungime mare conţine date binare, gradul de suspiciune va creşte.

Sunt utilizate modele de protocol, ce sunt de obicei bazate în principal pe standardele de protocol de la furnizori de software şi organismele de standardizare (ex: Internet Engineering Task Force [IETF] Request for Comments [RFC]). Modelele de protocol iau în

8

considerare, de asemenea, diferenţele ce apar în diferitele implementări. Multe standarde nu oferă o descriere completă a protocolului, cauzând astfel variaţii între implementări. De asemenea, producătorii încalcă de multe ori standardele sau adaugă caracteristici proprietare, unele putând înlocui caracteristicile standard. Pentru protocoalele proprietare, detaliile complete nu sunt adesea disponibile, fapt ce va îngreuna furnizarea unor analize complete şi exacte de către tehnologiile IDPS. Pe măsură ce protocoalele sunt revizuite, iar vânzătorii modifică implementările, modelele proprii IDPS-urilor trebuie să fie actualizate pentru a reflecta aceste modificări.

Această metodă de analiză este o consumatoarea foarte mare de resurse, din cauza complexităţii analizei realizate şi supraîncărcarea ce rezultă din urmărirea simultană a mai multor sesiuni.De altfel, acest fapt reprezintă şi dezavantajul principal al acestei metode. O altă problemă serioasă este aceea că atacurile care nu încalcă caracteristicile de comportament general acceptat al protocolului nu sunt detectate(ex: efectuarea mai multor acţiuni benigne într-o perioadă scurtă de timp pentru a provoca o blocare a serviciului - DoS). Pe lângă acestea, modelul de protocol utilizat de un IDPS ar putea intra în conflict cu modul în care protocolul este implementat în diferite aplicaţii şi sisteme de operare.

2.4 Tipuri de tehnologii IDPS

Există mai multe tipuri de tehnologii IDPS, în funcţie de tipul de evenimente pe care le monitorizează şi de modul în care acestea sunt implementate, acestea sunt împărţite în următoarele patru grupe:

La nivel de reţea: monitorizează traficul de reţea pentru anumite segmente de reţea sau dispozitive, analizând activităţile protocoloalelor de reţea şi aplicaţie pentru a identifica activităţi suspecte. Se pot identifica diferite evenimente de interes. Este amplasat de cele mai multe ori la o graniţă între reţele, cum ar fi în apropierea firewall-urilor sau routerelor, serverelor de reţea virtuală privată (VPN), serverelor de acces de la distanţă şi reţelelor fără fir;

9

Figura 2.1 – Tehnologii IDPS

Fără fir: monitorizează traficul de reţea fără fir şi analizează protocoalele sale de reţea pentru a identifica activităţi suspecte care implică protocoalele înşăşi. Nu poate identifica activităţi suspecte ce implică protocoale de nivel aplicaţie sau de transport ( TCP, UDP), în traficul de reţea fără fir ce este transferat. Îşi desfăşoară activitatea de monitorizare, cel mai frecvent, în raza de acţiune a reţelei fără fir a unei organizaţii;

Analiza comportamentului de reţea (Network Behavior Analysis - NBA): examinează traficul de reţea pentru a identifica ameninţările care generează fluxuri de trafic neobişnuit, cum ar fi blocarea distribuită a unui serviciu (DDoS), anumite forme de malware( viermi, backdoors) şi încălcări ale politicii (ex: un sistem client ce furnizează servicii de reţea pentru alte sisteme). Sistemele NBA sunt cel mai adesea utilizate pentru a monitoriza fluxurile de pe reţelele interne ale unei organizaţii, şi sunt, de asemenea, uneori, utilizate pentru a monitoriza fluxurile între reţelele unei organizaţii şi reţelele externe;

La nivel de host: monitorizează caracteristicile unei singur host şi evenimentele care au loc în acel host pentru activităţi suspecte.Tipurile de caracteristici urmărite sunt: traficul de reţea(numai pentru gazda respectivă), logurile de sistem, procesele active, activităţile aplicaţiilor, accesul la fişiere precum şi modificarea acestora, schimbarea configuraţiei sistemului sau a unor aplicaţii. Sunt cel mai frecvent utilizate pe gazde critice, cum ar fi servere accesibile în exterior sau servere care conţin informaţii sensibile.

Unele forme de IDPS sunt mai mature decât altele pentru că au fost folosite mult mai mult timp. Cele la nivel reţea şi unele forme la nivel de host sunt disponibile pe piaţă de peste zece ani. Cele bazate pe analiza comportamentală a reţelei sunt o formă oarecum mai nouă ce a evoluat din produsele create special pentru a detecta atacuri de tip DDoS şi din produse dezvoltate pentru a monitoriza fluxurile de trafic în reţelele interne. Tehnologiile fără fir sunt un tip relativ nou, dezvoltat ca răspuns la popularitatea reţelelor locale wireless (WLAN) şi a ameninţărilor în creştere la adresa reţele WLAN şi clienţilor WLAN.

2.5 Intruziunile

Intruziunile sunt unele dintre cele mai mari ameninţări la adresa retelelor de calculatoare şi a sistemelor de calcul. Acestea exploatează slăbiciuni ale software-ului sau ale configuratiei sistemului pentru a-l deteriora. Printre aceştia regăsim: viruşii propriu-zişi, viruşi de macro şi de email, cai troieni şi viermi.

De numele acestor tipuri de ameninţări se leagă principalele unelte folosite de persoanele rău intenţionate în demersul lor de a obţine date sensibile care pot fi valorificate în vreun fel.

Viruşii sunt programe – cod executabil numit uneori malware – care se inserează în alt program executabil. Astfel, virusul se propagă atunci când este executat programul infectat. Virusul este pasiv deoarece are nevoie ca un utilizator sau un alt program să-l lanseze şi să execute programul infectat. Înainte de acest eveniment, virusul rămâne în stare adormită. La

10

activare codul este plasat în memoria centrală a calculatorului şi îşi îıncepe execuţia exact ca orice alt program.

De obicei, atunci când este activat, virusul îşi inserează copii ale sale în cele mai comune executabile pe care le poate găsi pe discul rigid al calculatorului victimă, proces numit auto-replicare. Programele infectate se răspândesc de obicei de la un calculator la altul prin copii pe medii de stocare sau prin descărcarea de pe Internet.

Cel mai adesea utilizatorii schimbă între ei documente, nu programe. Acestea pot fi ţinta virusilor de macro şi de e-mail. Macrodefiniţiile executate de aplicaţii cum sunt Microsoft Word, Excel sau Outlook pot fi şi ele infectate de viruşi. La deschiderea unui document infectat virusul se execută în background, fără ca utilizatorul să observe.

În mod asemănător, există viruşi care se pot ataşa la e-mail. De îndată ce destinatarul deschide conţinutul unui mesaj infectat, virusul este executat. De cele mai multe ori, încep să trimită email-uri care conţin copii ale lor fiecărui contact găsit în cartea de contacte a victimei.

Viruşii de email pot cauza pagube mari infrastructurii de email a Internet prin traficul enorm pe care îl generează ca urmare a replicării multiple. În unele cazuri au provocat căderea serverelor de email care nu au rezistat volumului imens de trafic.

Caii troieni constituie un tip aparte de malware care deschide porţi în sisteme pentru intruşi. Termenul de cal troian este utilizat pentru a descrie software care permite atacatorilor aflaţi la distanţă să ia controlul sistemului de calcul, să descarce fişiere, să instaleze aplicaţii, să modifice fişiere şi chiar să oprească de tot sistemul.

Caii troieni sunt programe instalate fără cunoştinţa încărcăturii ostile de către utilizatori în urma unei infectări a unui fişier sau a unei aplicaţii descărcate de pe Internet. Unul dintre cei mai faimoşi cai troieni, Back Orifice, este atât de puternic încât a ajuns să fie considerat program de gestiune de la distanţa a sistemelor de calcul.

Viermii se pot replica fără intervenţia utilizatorului. În timp ce viruşii sunt pasivi şi au nevoie de intervenţia utilizatorului pentru a se rula, viermii sunt activi. Din cauza faptului că nu au nevoie de intervenţia utilizatorului şi se pot replica şi activa autonom, ei sunt mult mai periculoşi. Aceştia sunt programe care folosesc erorile de programare (bug-uri) ale resurselor din reţea pentru a se replica. Ei se pot inocula în sistemele de calcul datorită erorilor din server, loc în care încep să scaneze reţeaua în căutarea altor calculatoare pe care să le infecteze. Proliferarea unui vierme este uimitoare. De exemplu, Code Red a avut nevoie de 15 minute pentru a infecta mii de calculatoare şi a atacat chiar site-ul oficial al Casei Albe a SUA. Pe lângă căutarea altor calculatoare pe care să le infecteze, viermii pot cauza pagube prin atacarea reţelei şi a componentelor sale. Un sondaj la nivel naţional în SUA, sponsorizat de către CA Incorporated şi de National Cyber Security Alliance (NCSA) a arătat că 83% dintre adulţii care se implică în legături sociale prin reţele de calculatoare au descărcat fişiere necunoscute, care le puteau expune PC-urile la atacuri.

Spyware-ul poate fi definit ca orice software care foloseşte conexiunea la Internet a unui utilizator în fundal. Termenul de spyware este, în majoritatea cazurilor, sinonim cu adware, şi poate fi un program de genul cailor troieni. Programele spyware pot colecta date sensibile (cum sunt: versiunea de sistem de operare rulată, tipul de răsfoitor de Web, dacă limbajul de scenarii poate fi executat, dimensiunea ecranului, plug-in-urile disponibile, informaţii de DNS din domeniu, pot trasa ruta spre sursă pentru a stabili unde se află calculatorul ţintă pe reţea) pe două căi: prin cookies şi instalându-se şi apoi executându-se.Programele care prezintă risc, în legătură cu codul ostil sunt numite generic ”riskware” şi constituie orice program legal care poate fi folosit de atacatori pentru a penetra calculatoarele.

Un rootkit poate fi considerat ca un cal troian introdus într-un sistem de operare.

11

Pentru ca un atacator să poată instala un rootkit el trebuie să aibă acces la nivelul de administrator la sistem înainte de a putea instala kit-ul respectiv. Rootkit-urile nu permit obţinerea accesului la sistem, ci dau posibilitatea de a pătrunde în sistem cu permisiuni de nivel maxim (root). O dată obţinut accesul la nivel de administrator, poate fi folosit un cal troian care să se deghizeze într-o funcţie sistem existentă pe sistemul compromis.

Un atac cibernetic de tip DoS ( Denial of Service) sau DDoS (Distributed Denial of Service) este o încercare frauduloasă de a indisponibiliza sau bloca resursele unui calculator. Deşi mijloacele şi obiectivele de a efectua acest atac sunt foarte diverse, în general acest atac este efectul eforturilor intense ale unei (sau a mai multor) atacatori de a împiedica un site web sau servicii din Internet de a funcţiona eficient, temporar sau nelimitat. Autorii acestor atacuri au de obicei drept ţintă site-uri sau servicii găzduite pe servere cu cerinţe înalte, cum ar fi băncile, gateway-uri pentru plăţi prin carduri de credit şi chiar servere în întregime. O metodă tradiţională de atac provoacă „saturarea” calculatorului ţintă (victimei) cu cereri de comunicare externe, astfel încât să nu mai poată reacţiona eficient la traficul Internet legitim, sau chiar să devină indisponibil.

În termeni generali, atacurile de tip DoS se realizează pe mai multe căi:

provocarea unui reset forţat al calculatorului sau al mai multor calculatoare; consumarea intensă a resurselor disponibile ale unui server, astfel încât acesta să nu

mai poată furniza servicii; blocarea comunicaţiilor dintre utilizatorii bine intenţionaţi şi calculatorul victimă,

astfel încât acesta să nu mai poată comunica adecvat;

Atacurile de tip Denial of Service sunt considerate încălcări ale politicii de utilizare corectă a Internetului elaborate de Internet Architecture Board. De asemenea aceste atacuri constituie deseori încălcări ale legislaţiei din ţara respectivă.

Câteva scopuri pentru care sunt folosite intruziunile sunt: obţinerea accesului de la distanţă; furtul de resurse; sabotajul; colectarea de date; ocolirea sistemului de control al accesului; eludarea detectării.

12

3. Tehnologii IDPS

3.1 Componente şi arhitectură

3.1.1 Componente tipice

Componentele tipice ale unei soluţii IDPS sunt:

Senzor sau agent. Senzorii şi agenţii monitorizează şi analizează activitatea de reţea.Termenul senzor este folosit de obicei pentru IDPS-urile care monitorizează reţelele, incluzându-le pe cele la nivel de reţea, fără fir, şi cele bazate pe tehnologii de analiză a comportamentului de reţea. Termenul agent este de obicei folosit pentru tehnologii IDPS la nivel de host.

Server de management. Un server de management este un dispozitiv care centralizează şi gestionează informaţiile primite de la senzori sau agenţi. Unele servere de management analizează informaţiile furnizate de către senzori sau agenţi, existând astfel posibilitatea de a identifica evenimente pe care senzorii sau agenţii nu le pot detecta. Potrivirea informaţiilor de la mai mulţi senzori sau agenti, pentru găsirea, de exemplu, a evenimentelor declanşate de aceeaşi adresă IP, este cunoscută sub numele de corelare. Serverele de management sunt disponibile atât ca instrumente hardware, dar ca şi produse software. Serverele de management sunt comune celor mai multe implementări IDPS, existând posibilitatea unor servere multiple, sau chiar două nivele de astfel de servere.

Server de baze de date. Un server de baze de date este un repozitoriu alcătuit din informaţii înregistrate de către senzori, agenţi, şi / sau servere de management.

Consolă. O consolă este un program care oferă o interfaţă pentru utilizatorii şi administratorii IDPS-ului. Acest software este de obicei instalat pe desktop-uri sau laptop-uri standard. Unele console sunt utilizate doar pentru administrare(configurare de senzori sau agenţi şi aplicarea unor actualizări de software), în timp ce alte console sunt folosite strict pentru monitorizare şi analiză. Unele console oferă atât administrare, cât şi monitorizare.

3.1.2 Arhitectura de reţea

Componentele pot fi conectate între ele prin intermediul reţelei standard a unei organizaţii sau printr-o reţea separată, concepută strict, din motive de securitate, pentru management, cunoscută sub numele de reţea de management. Dacă se utilizează o astfel de reţea, fiecare senzor sau agent are o interfaţă de reţea suplimentară, cunoscută sub numele de interfaţă de management care se conectează la reţeaua mai sus menţionată. De asemenea, în

13

cazul fiecărui senzor sau agent nu există nici un tip de flux de date între interfaţa de gestionare şi orice altă interfaţă de reţea a sa. Serverele de management, serverele de baze de date şi consolele sunt conectate numai la reţeaua de management. Această arhitectură izolează în mod eficient toate componentele de reţeaua de producţie. Beneficiile sunt date de ascunderea existenţei şi identităţii IDPS-ului faţă de atacatori, protejând astfel sistemul faţă de un atac. În acest fel se asigură că IDPS-ul are o lăţime de bandă adecvată pentru a funcţiona în condiţii nefavorabile (atacuri de tip DDoS asupra reţelelor monitorizate). Dezavantajele de a folosi o reţea de management includ costurile suplimentare investite în echipamente de reţea şi alte componente hardware (de exemplu, PC-uri pentru console) şi inconfortul dat de utilizarea unor computere separate pentru management şi monitorizare.

În cazul în care un IDPS este implementat fără o reţea de management separată, un alt mod de a îmbunătăţi securitatea este de a crea o reţea de gestionare virtuală folosind o reţea virtuală locală (VLAN) în cadrul reţelelor standard. Folosind un VLAN se conferă o protecţie suplimentară pentru comunicaţiile din cadrul IDPS-ului, dar nu comparabilă cu protecţia oferită de o reţea de gestiune separată. De exemplu, greşelile de configurare a VLAN-ului ar putea duce la expunerea unor date sensibile. O altă îngrijorare este dată de faptul că, în condiţii adverse, cum ar fi atacurile DDoS sau incidente majore de malware, dispozitivele de reţea partajate de reţelele primare ale organizaţiei şi VLAN-urile ar putea deveni complet saturate, impactând negativ asupra disponibilităţii şi performanţei unui IDPS.

3.2 Capabilităţi de securitate

3.2.1 Culegerea informaţiilor

Unele tehnologii IDPS oferă capacitatea de colectare de informaţii cu privire la host-urile sau reţelele monitorizate. Exemplele includ identificarea gazdelor, a sistemelor de operare şi aplicaţiilor pe care le folosesc, şi identificarea caracteristicilor generale ale reţelei.

3.2.2 Capabilităţi de logare

IDPS-urile efectuează de obicei logarea datelor legate de evenimentele detectate. Aceste date pot fi utilizate pentru a confirma validitatea alertelor, investigarea incidentelor, şi corelarea cu alte surse de logare. Câmpurile de date utilizate în mod obişnuit de către IDPS-uri includ data şi ora evenimentului, tipul de eveniment, evaluare importanţei( prioritate, severitate, impact, încredere) şi acţiunile de prevenire întreprinse (dacă este cazul). Anumite tipuri de IDPS loghează câmpuri de date suplimentare, cum ar fi capturi de trafic. Logurile sunt stocate la nivel local şi sunt trimise în acelaşi timp copii către servere centralizate de log.În general, logurile trebuie păstrate atât la nivel local, cât şi central pentru asusţine integritatea şi disponibilitatea datelor.De asemenea, sistemele ar trebui să aibă ceasurile sincronizate folosind protocolul NTP (Network Time Protocol) sau prin ajustări manuale frecvente, astfel încât logurile să fie înregistrate cu o oră şi dată cât mai exactă.

14

uc Use Case Model

Log

Timestamp

Tipul alertei/ ev enimentului

Rating( prioritate, sev eritate

,impact)

Detalii (IP,port, etc)

Actiunea intreprinsa

«include»

«include» «include» «include»«include»

Figura 3.1 – Câmpurile unui log

3.2.3 Detecţia

Tehnologii IDPS oferă de obicei, capabilităţi extinse de detecţie. Cele mai multe produse folosesc o combinaţie de tehnici, ce susţin, în general o detecţie mai precisă şi mai flexibililă în realizarea configuraţiei. Tipurile de evenimente detectate şi acurateţea detecţiei variază foarte mult de la o tehnologie la alta. Cele mai multe IDPS-uri au nevoie de tuning şi personalizare pentru a îmbunătăţi acurateţea, gradul de utilizare, precum şi eficienţa. Tehnologiile variază foarte mult prin direcţiile de tuning şi capabilităţile de personalizare. De obicei, cu cât tuning-ul şi capabilităţile de personalizare ale unui produs sunt mai viguroase, cu atât mai mult acurateţea detecţiei poate fi îmbunătăţită faţă de cea a configuraţiei implicite.Acest lucru trebuie tratat cu atenţie în evaluarea unor astfel de produse.Exemple de astfel de capacităţi sunt cele după cum urmează:

Praguri. Un prag este o valoare ce stabileşte limita între un comportament normal şi anormal. Pragurile specifică, de obicei, un nivel acceptabil maxim, cum ar fi Nîncercări eşuate de conectare în 60 de secunde, sau N caractere pentru lungimea unui nume de fişier. Pragurile sunt cel mai adesea utilizate de detecţia bazată pe anomalii şi cea bazată pe analiza protocoalelor de tip stateful;

Liste negre/albe. O listă neagră este o listă de entităţi discrete, cum ar fi gazde, adrese IP, numere de port TCP sau UDP, coduri ICMP, aplicaţii, nume de utilizatori, URL-uri, nume de fişiere sau extensii de fişiere, care au fost asociate anterior cu activităţii maliţioase. Listele negre, cunoscut şi sub numele de “liste fierbinţi”(hot lists), sunt de obicei folosite pentru a permite IDPS-urilor să recunoască şi să blocheze activităţile dăunătoare, şi pot fi de asemenea folosite pentru a atribui o prioritate mai mare alertelor ce au o corespondenţă în listele negre. Unele IDPS-uri generează liste negre dinamice, folosite pentru a bloca temporar ameninţările recent detectate. O listă albă este o listă de entităţi discrete, care sunt cunoscute a fi benigne. Listele albe sunt de obicei utilizate în mod granular, pentru a reduce sau ignora falsurile pozitive ce

15

implică activităţi benigne. Listele albe şi listele negre sunt cele mai frecvent utilizate în detecţia bazată pe semnături şi analiza protocoalelor stateful;

Setarea alertelor. Se permite administratorilor personalizarea fiecărui tip de alertă. Exemple de acţiuni care pot fi efectuate pe un tip de alertă includ următoarele:

o Oprirea sau pornirea3;o Setarea unei anume priorităţi sau nivel de severitate;o Specificarea informaţiilor ce ar trebui înregistrate şi a metodelor de

notificare(ex: email);o Specificarea acţiunilor de preventive ce ar trebui întreprinse.

Unele produse suprimă alertele în cazul în care un atacator generează mai multe alerte într-o perioadă scurtă de timp, şi poate, de asemenea, ignora temporar tot traficul viitor de la atacator. Se realizează acest lucru pentru a preveni copleşirea cu alerte a IDPS-ului;

Vizualizare şi editare de cod. Unele tehnologii permit administratorilor să vadă unele porţiuni sau tot codul ce realizează detecţia. Acest lucru este de obicei limitat la semnături, dar unele tehnologii permit administratorilor vizualizarea unor porţiuni suplimentare, cum ar fi programele ce efectuează analiza protocoalelor stateful. Vizualizarea codului îi poate ajuta pe analişti în a determina de ce au fost generate anumite alerte, ajutând la validarea alertelor şi identificarea falsurilor pozitive. Abilitatea de a edita codul şi scrie cod nou (ex: noi semnături) este necesară pentru o personalizarea completă în cazul anumitor tipuri de capacităţi de detectare. De exemplu, o anumită alertă ar putea fi generată de o serie complexă de evenimente care implică mai multe module de cod; configurarea unui IDPS să înţeleagă organizarea specifică unor caracteristici nu ar putea fii posibilă fără a edita codul. Editarea codului necesită abilităţi de programare şi de detecţie a intruziunilor; se folosesc de cele mai multe ori limbaje de programare proprietare, ceea ce ar necesita învăţarea unor noi limbaje de către programator. Bug-urile introduse în cod în timpul procesului de personalizare ar putea provoca sistemul să funcţioneze incorect sau deloc.Aşadar, administratorii ar trebui să trateze personalizarea codului ca pe orice altă modificare a codului sistemelor de producţie.

Administratorii ar trebui să revizuiască setările de tuning şi particularizare periodic pentru a se asigura că acestea sunt încă exacte. De exemplu, listele albe şi listele negre ar trebui verificate în mod regulat, iar toate intrările validate pentru a se asigura că acestea sunt în continuare corecte şi necesare. Pragurile şi setările alertelor ar putea avea nevoie de ajustări periodice pentru a compensa schimbările din reţea sau apariţia unor noi ameninţări. Modificările aduse codului de detecţie ar putea avea nevoie să fie reprodus ori de câte ori produsul este actualizat (ex: aplicarea de patch-uri).

3

În unele tehnologii IDPS, oprirea alertelor duce la dezactivarea capabilităţilor de detecţie; alte produse, continuă detecţia, dar nu vor genera mesaje de alertă.

16

3.2.4 Prevenţia

Cele mai multe IDPS-uri oferă posibilităţi multiple de prevenire; acestea variază în funcţie de tipul acestora. Administratori pot specifica în configuraţie capacitatea de prevenire pentru fiecare tip de alertă. Astfel, se poate activa/dezactiva prevenţia sau se poate specifica ce tip de capabilitate de prevenţie să se utilizeze. Unii senzori au un mod de învăţare sau simulare, care suprimă toate acţiunile de prevenire indicând doar momentul când s-ar fi cuvenit o acţiune de acest tip. Acest lucru permite administratorilor să monitorizeze şi să ajusteze configuraţia responsabilă înainte de a activa acţiunile de prevenire, ceea ce reduce riscul de blocare accidental al activităţilor benigne.

3.3 Management

3.3.1 Implementare

După ce IDPS-ul a fost ales, administratorii trebuie să implementeze o arhitectură, să testeze, poziţioneze şi să securizeze componentele.

3.3.1.1 Design-ul arhitecturii

Primul pas în implementarea unui astfel de sistem este design-ul arhitecturii. Consideraţiile arhitecturale includ:

Unde trebuie plasaţi senzorii/agenţii; Cât de sigură ar trebui să fie soluţia aleasă şi ce măsuri ar trebui luate pentru a atinge

nivelul cel mai înalt, prin poziţionare unor senzori multiplii ce monitorizează aceeaşi activitate în cazul în care unul dintre ei cade sau folosirea unor servere de management multiple, astfel încât un server de backup poate fi utilizat în cazul în care serverul primar nu mai este disponibil;

Unde vor fi amplasate celelalte componente IDPS (servere de management, servere de baze de date, console) şi câte componente din fiecare clasă sunt necesare pentru a atinge gradul de utilizare optim şi redundanţă;

Cu care alte sisteme IDPS-ul trebuie să interacţioneze, inclusiv următoarele:o Sisteme cărora li se furnizează date, cum ar fi software-uri de management al

evenimentelor şi al informaţiilor de securitate, servere de log centralizate, servere de e-mail;

o Sistemele ce iniţiază acţiuni de prevenire (firewall-uri, routere, switch-uri);o Sisteme care gestionează componentele IDPS, cum ar fi software-ul de

management de reţea (pentru o reţea de management) sau software-ul de management al patch-urilor (pentru păstrarea sistemelor de operare al consolelor şi aplicaţiilor actualizate).

Dacă va fi utilizată sau nu o reţea de management; dacă da, ce design va avea, în caz contrar, cum vor fi protejate comunicaţiile IDPS în cadrul reţelelor standard;

17

Ce alte controale şi tehnologii de securitate trebuie modificate pentru buna funcţionare a sistemului, cum ar fi schimbarea regulilor firewall-urilor pentru a permite componentelor să comunice.

3.3.1.2 Testarea şi amplasarea componentelor

Organizaţiile ar trebui să ia în considerare implementarea componentelor într-un mediu de testare în primul rând, pentru a reduce riscul de probleme de implementare ce pot perturba reţelele de producţie. Atunci când componentele sunt utilizate în reţelele de producţie, organizaţiile trebuie să activeze iniţial doar câţiva senzori sau agenţi, cu capacităţile de prevenire dezactivate. Pentru că o implementare nouă va genera, cel mai probabil, un număr mare de alarme false până când tuning-ul şi personalizarea sunt complete, activarea mai multor senzori sau agenţi deodată ar putea copleşi serverele de management şi consolele, ceea ce face dificil tuning-ul. Multe falsuri pozitive pot fi de acelaşi tip în cadrul senzorilor/agenţilor, astfel, este util identificarea acestora, în timpul procesului de testare sau atunci când sunt amplasaţi primii senzori sau agenţi, astfel încât aceste rezultate pot fi redresate înainte de extinderea pe scară largă. O implementare treptată a senzorilor sau a agenţilor este, de asemenea, de ajutor în identificarea potenţialelor probleme cu scalabilitate.Implementarea poate necesita scurte întreruperi de reţea sau de sistem pentru instalarea componentelor.

Componentele hard sunt de obicei uşor de instalat. Administratorii ar putea fi nevoiţi să efectueze actualizări de software sau actualizări de semnături. În general, trebuie conectate la o sursă de curent şi la reţea, pornite şi apoi efectuate anumite configurări de bază (ex: introducerea unei chei de licenţă de produs, atribuirea unui nume senzorului).

Componentele software necesită, de obicei, mai mult timp pentru implementare. Trebuie achiziţionat mai întâi hardware-ul adecvat, suficient de solid pentru a susţine IDPS-ul, care ar putea include plăci de reţea cu o lăţime de bandă mare. Apoi, administratorii trebuie să instaleze un sistem de operare compatibil pe care apoi să-l actualizeze, împreună cu toate serviciile, aplicaţiile şi software-urile instalate.

După amplasarea componentelor IDPS un efort considerabil ar putea fi necesar pentru a configura capabilităţile de detecţie şi prevenire, în funcţie de tipul sistemului. Fără parcurgerea acestui pas, sistemele ar putea fi limitate doar la detecţia unui număr mic de atacuri vechi şi uşor de identificat.

3.3.1.3 Securizarea componentelor

Asigurarea componente sistemului este foarte importantă, deoarece acestea sunt adesea vizate de atacatori. În cazul în care un atacator poate compromite un IDPS, acesta va fi inutil în detectarea atacurilor ulterioare împotriva altor host-uri. De asemenea, acestea conţin informaţii sensibile, cum ar fi configuraţiile host-urilor şi vulnerabilităţi cunoscute care ar putea fi de ajutor în planificarea atacurilor suplimentare. Următoarele specificaţii de securitate sunt recomandate:

Administratorii trebuie să creeze conturi separate pentru fiecare utilizator şi administrator, precum şi atribuirea numai a privilegiilor necesare;

Administratorii trebuie să configureze firewall-urile, routerele, precum şi alte dispozitive de filtrare a pachetelor pentru a limita accesul direct la toate componentele IDPS numai pentru acele gazde care au nevoie de un astfel de acces;

Administratorii trebuie să se asigure că toate comunicaţiile de management sunt protejate în mod corespunzător, fie fizic (reţeaua de management), fie logic(VLAN de

18

management), sau prin criptarea informaţiilor. În cazul în care criptarea este utilizată, ar trebui utilizaţi algoritmi de criptare recomandaţi de standardele international. Multe produse folosesc pentru criptare protocolul TLS( Transport Layer Security); pentru produsele care nu oferă suficientă protecţie prin criptare, organizaţiile ar trebui să ia în considerare utilizarea unei reţele private virtuale (VPN) sau alte metode de tunele criptate pentru a proteja traficul.

3.3.2 Operare şi mentenanţa

Aproape toate produsele de acest gen sunt proiectate pentru a fi exploatate şi întreţinute printr-o interfaţă grafică(GUI), cunoscută sub numele de consolă. Consola permite administratorilor configurarea şi actualizarea senzorilor şi serverelor de management, precum şi monitorizarea stării lor. Administratorii gestionează conturile de utilizator, personalizează rapoarte şi efectuează multe alte funcţii utilizând consola. Utilizatorii pot efectua multe funcţii prin consola, inclusiv monitorizarea şi analizarea datelor, precum şi generarea de rapoarte. Cele mai multe IDPS-uri permit administratorilor crearea de conturi de utilizator individuale pentru fiecare administrator şi utilizator şi acordarea fiecărui cont numai privilegiile necesare pentru rolul fiecărei persoane. Consola reflectă de multe ori acest lucru arătând diferite meniuri şi opţiuni bazate pe privilegiile contului autentificat.

Unele produse oferă o interfaţă în linie de comandă( CLI). Spre deosebire de interfeţele grafice, care sunt de obicei utilizate pentru gestionarea de la distanţă a senzorilor/ agenţilor şi serverelor de management, CLI-urile sunt de obicei utilizate pentru gestionarea locală a acestor componente. Uneori, este permisă realizarea unei conexiune criptate la distanţă de CLI, realizate prin SSH( Secure Shell) sau prin alte mijloace. Consolele sunt de obicei mult mai uşor de utilizat decât CLI-urile, dar oferă adesea doar o parte din funcţionalitatea acestora.

3.3.2.1 Utilizarea tipică

Cele mai multe console IDPS oferă multe caracteristici ce ajută utilizatorii în sarcinile lor zilnice. De exemplu, când un utilizator examinează o alertă, mai multe detalii şi informaţii sunt disponibile pe nivele. Acest lucru permite utilizatorilor observarea informaţiilor de bază pentru mai multe alerte o dată, dar este posibilă şi afişarea informaţiilor suplimentare despre evenimente speciale de interes. Unele produse oferă utilizatorilor informaţii detaliate de sprijin, cum ar fi capturi de pachete şi alertele aferente (ex: alte alerte pentru aceeaşi sursă sau destinaţie), precum şi documentaţia alertei în sine. În general, cu cât există mai multe date înregistrate, cu atât este mai uşor pentru analişti să determine ce s-a întâmplat.

Cele mai multe console oferă, de asemenea, diverse funcţii de raportare. De exemplu, administratorii sau utilizatorii pot utiliza consola pentru a genera anumite rapoarte la ore stabilite şi transferul acestora pe email sau pe alte căi către utilizatorii avizaţi. Rapoartele pot fi personalizate după cum este necesar(inclusiv generarea de rapoarte pentru incidente specifice). În cazul în care sistemul stochează logurile într-o bază de date sau într-un format de fişier uşor de interpretat (ex: valori separate prin virgulă într-un fişier text), interogările bazei de date sau script-urile pot fi folosite pentru a genera rapoarte personalizate, în special în cazul în care consola nu oferă o personalizare suficient de flexibilă.

19

3.3.2.2 Soluţii de mentenanţă

Administratorii ar trebui permanent să aplice următoarele soluţii se mentenanţă:

Monitorizarea componentelor pentru prevenirea problemelor operaţionale şi de securitate ce le-ar putea include;

Verificarea periodică a funcţionalităţi; Realizarea de evaluări periodice ale vulnerabilităţilor; Primirea de notificări ale unor eventuale probleme de securitate din parte

producătorilor componentelor IDPS(incluzând sistemele de operare, precum şi aplicaţiile non-IDPS) şi răpunsul corespunzător la aceste notificări;

Primirea de notificări din partea producătorilor IDPS-ului legate de update-urile pe care administratorii le pot testa şi apoi aplica sistemului.

3.3.2.3 Achiziţia şi aplicarea update-urilor

Există două tipuri de actualizări: actualizări de software şi actualizări de semnături. Actualizările de software rezolvă bug-urile în software sau adaugă noi funcţionalităţi, în timp ce actualizările semnăturilor adaugă capacităţi de detecţie noi sau rafinează capabilităţile de detecţie existente (ex: reducerea falsurilor pozitive). Actualizările de semnături cauzează modificări sau înlocuiri în codul programului, fiind astfel o formă specializată de actualizare a software-ului. Pentru alte IDPS-uri, semnăturile nu sunt scrise în cod, astfel încât un update de semnături reprezintă o modificare a datelor de configurare.

Actualizările de software pot include oricare sau toate componentele, inclusiv senzori, agenţi, servere de management şi console. Actualizările de software pentru senzori şi servere de management, în special pentru dispozitivele de tip appliance, sunt adesea aplicate prin înlocuirea unui CD existent, de pe care rulează software-ul, cu unul nou, urmat de repornirea dispozitivului. Multe IDPS-uri rulează software-ul direct de pe CD, astfel încât nu este necesară instalarea software-ului. Alte componente, cum ar fi agenţii, necesită intervenţia unui administrator pentru instalarea software-ului sau aplicarea patch-urilor, fie manual, pe fiecare dispozitiv sau automat, prin intermediul software-ului de management din sistem. Unii furnizori pun la dispoziţie pe site-urile proprii de web sau pe alte servere, actualizările de software şi semnăturile . Administratorii dispun deobicei de feature-uri ce downladează şi instalează asementea update-uri.

Este necesară o verificare a integrităţii actualizărilor înainte de aplicarea acestora, pentru că acestea ar fi putut fi, accidental sau intenţionat, modificate sau înlocuite. Metoda de verificare recomandată depinde de formatul actualizării, după cum urmează:

Fişierele descărcate de pe un site web sau server FTP. Administratorii ar trebui să compare sumele de control ale fişierelor, furnizate de către producător, cu sumele de control pe care le calculează local, după descărcare;

Actualizare descărcate automat printr-o interfaţa IDPS. Dacă o actualizare este descărcată ca un singur fişier sau un set de fişiere, sumele de control furnizate de vendor ar trebui comparate cu sumele de control generate de administrator ori interfaţa în sine ar trebui să efectueze un fel de verificare a integrităţii. În unele cazuri, actualizările ar putea fi descărcate şi instalate într-o singura acţiune, împiedicând

20

verificarea sumei de control; interfaţa ar trebuie să verifice integritatea fiecărei actualizări ca parte integrantă a acestei acţiuni de instalare;

Medii de stocare detaşabile(ex: CD-uri, DVD-uri). Furnizorul nu poate prevede o metodă specifică pentru clienţi pentru a verifica legitimitatea acestor medii, aparent trimise de către aceştia. Dacă verificarea reprezintă o preocupare, administratorii ar trebui să contacteze furnizorii pentru a determina modul în care acestea pot fi verificate, cum ar fi compararea sumelor de control furnizate de vendori cu sumele de control calculate local pentru fişierele de pe mediul de stocare sau verificarea semnăturilor digitale pentru conţinut pentru validare. Administratorii ar trebuie să ia în considerare şi scanare contra malware-uri, cu avertismentul că falsurile pozitive ar putea fi declanşate de către semnăturile IDPS-ului.

IDPS-urile sunt de obicei proiectate astfel încât aplicarea actualizărilor de software şi semnături nu va avea nici un efect asupra tuning-ului şi setărilor. Excepţie face personalizarea codului, care de cele mai multe ori trebui refăcută atunci când sunt instalate actualizări de cod de la furnizor. Pentru orice sistem, administratorii ar trebui să realizeze un backup periodic şi înainte de a aplica actualizările pentru a se asigura că setările existente nu sunt pierdute accidental.

Este recomandată testarea actualizărilor înainte de aplicarea acestora, cu excepţia situaţiilor de urgenţă ( ex: o semnătură identifică o nouă ameninţare activă care dăunează organizaţiei şi nu poate fi altfel detectată sau blocată). Este benefică existenţa cel puţin a unui senzor/agent(pentru fiecare tip) sau host, care să fie utilizat strict pentru testarea actualizărilor. Capabilităţile noi de detectare pot provoca de multe ori un număr mare de alerte, astfel încât testarea actualizări de semnaturi pe un singur senzor/agent, chiar şi pentru scurt timp, (încărcarea actualizării şi observarea modului în care funcţionează sistemul când sunt monitorizate activităţile tipice), poate ajuta la identificarea semnăturilor care sunt susceptibile a fi problematice şi ar trebui să fie într-un final dezactivate. În situaţii non-urgente, actualizările ar trebui să fie testate şi implementate folosind aceleaşi practici care sunt folosite pentru actualizarea altor dispozitive sau software-uri de securitate, cum ar fi firewall-urile şi software-urile antivirus. Când actualizările sunt implementate în producţie, administratorii ar trebui să fie pregătiţi pentru a dezactiva anumite semnături sau a efectua alte reconfigurări minore, după cum este necesar.

3.3.3 Competenţe de construire şi mentenanţă

Diferite competenţe sunt necesare pentru implementarea, operarea şi mentenanţa IDPS-urilor, incluzându-le pe cele ce urmează:

Administratorii ce implementează componentele trebuie să înţeleagă elementele de bază ale administrării sistemului , reţelei şi ale securităţii informaţiei;

Cei responsabili de tuning şi personalizare este necesar să aibă cunoştinţe destul de cuprinzătoare legate de securitatea informaţiei şi principiile unui sistem de prevenţie şi detecţie a intruziunilor într-o retea împreună cu întelegerea protocoalelor de reţea, a aplicaţiilor şi a sistemelor de operare ce urmează a fi monitorizate.De asemenea, este

21

recomandată o înţelegere a principiilor de răspuns la incidente, precum şi a politicilor şi procedurilor de răspuns la incidente ale organizaţiei;

Cunoştinte de programare ar putea fi, de asemenea, necesare pentru personalizări extinse de cod, scrierea de rapoarte şi alte sarcini.

Competenţele pot fi dezvoltate prin mai multe metode, ce includ training-uri, conferinţe tehnice, cărţi şi alte referinţe tehnice, precum şi programe de mentorat. Cunoaşterea produselor specifice ale unui IDPS poate fi realizată prin mai multe metode:

Training realizat de vendor. Mulţi producători de produse IDPS oferă una sau mai multe cursuri de formare pentru persoanele care vor administra sau folosi produsele proprii. Cursurile de formare sunt adesea de tip hands-on, permiţând participanţilor să înveţe cum să folosească tehnologia într-un mediu non-producţie;

Documentaţia produsului. Cele mai multe produse oferă mai multe manuale, cum ar fi un ghid de instalare, un ghid al utilizatorului şi ghid pentru administrator. Unele oferă, de asemenea, ghiduri sau baze de date separate, care oferă informaţii suplimentare pentru alerte şi semnături;

Suport Tehnic. Cei mai mulţi producători oferă suport tehnic pentru clienţii lor, fie ca parte a achiziţionării unui produs sau pentru o taxă suplimentară. Suportul este utilizat în principal pentru rezolvarea problemelelor şi clarificarea capabilităţilor produselor pentru utilizatorii săi şi administratori;

Servicii profesionale. Unii furnizori oferă servicii profesionale, ce sunt în esenţă servicii de consultanţă prestate de către vânzător. De exemplu, o organizaţie ar putea plăti un furnizor pentru a scrie semnături particularizate sau rapoarte sau pentru a ajuta administratorii în întelegerea modului de a regla şi personaliza senzorii în mod eficient;

Comunităţi de utilizatori. Unele produse au comunităţi de utilizatori activi, care de obicei funcţionează prin liste de mailing sau forumuri online. Utilizatorii pot face schimb de informaţii şi cod unul cu altul, ajutându-se reciproc în probleme de depanare. Deşi comunităţile de utilizatori pot fi o sursă de informare, cei care folosesc aceste mijloace trebuie să fie precauţi când le utilizează, deoarece postarea unor detalii legate de configurarea şi problemele unui IDPS aparţinând unei organizaţii, ar putea neintenţionat să dezvăluie informaţii sensibile legate de infrastructura de securitate, sistemul şi reţelele unei organizaţii.

22

4. IDPS-uri la nivel reţea

4.1 Stiva TCP/ IP

ARPANET, strămoşul tuturor reţelelor de calculatoare, a fost o reţea de cercetare sponsorizată de către DoD (U.S. Department of Defense). În cele din urmă, reţeaua aajuns să conecteze între ele, utilizând linii telefonice închiriate, sute de reţele universitare şi guvernamentale. După introducerea ulterioară a reţelelor prin satelit şi radio, interconectarea acestora cu protocoalele existente a pus diferite probleme. Era nevoie de o nouă arhitectură de referinţă.Astfel, posibilitatea de a interconecta fără probleme mai multe tipuri de reţele a reprezentat de la bun început un obiectiv de proiectare major. Această arhitectură a devenit cunoscută mai târziu sub numele de modelul de referinţă TCP/IP, dată după numele celor două protocoale fundamentale utilizate.

Astfel, TCP (Tranmission Control Protocol) are rolul de împărţire a datelor în pachete şi asigură transmiterea corectă a mesajelor între host-uri. Pachetele sunt numerotate, putându-se verifica primirea lor în forma în care au fost transmise şi reconstituirea mesajelor lungi, formate din mai multe pachete.

IP (Internet Protocol) asigură livrarea pachetelor numai dacă în funcţionarea reţelelor nu apar erori. Dacă un mesaj este prea lung, IP cere fragmentarea lui în mai multe pachete. Transmiterea pachetelor IP se face între calculatoare gazdă şi nu direct între programele de aplicaţie.

Spre deosebire de modelul de referinţă OSI, modelul TCP/IP este format din 4 niveluri:

Figura 4.1 – Stiva TCP /IP

23

Deşi două dintre niveluri au acelaşi nume ca la modelul OSI, nu trebuie confundate între ele pentru că fiecare nivel are funcţii total diferite pentru fiecare model în parte.

Figura 4.2 – Nivelele celor două modele arhitecturale de reţea

Nivelul aplicaţie

Modelul TCP/IP nu conţine nivelurile sesiune sau prezentare.Experienţa modelului OSI a dovedit că această viziune a fost corectă: în majoritatea aplicaţiilor, nivelurile

respective nu sunt de mare folos. Aceasta conţine toate protocoalele de nivel mai înalt. Aşa cum se vede în figura 4.3, primele protocoale de acest gen includeau terminalul virtual (TELNET), transferul de fişiere (FTP) şi poşta electronică (SMTP). Protocolul de terminal virtual permite unui utilizator de pe o maşină să se conecteze şi să lucreze pe o maşină aflată la distanţă. Protocolul de transfer de fişiere pune la dispoziţie o modalitate de a muta eficient date de pe o maşină pe alta. Poşta electronică a fost la origine doar un tip de transfer de fişiere, dar ulterior a fost dezvoltat un protocol specializat

(SMTP – Simple Mail Transfer Protocol)pentru acest serviciu. Pe parcursul anilor, la

aceste protocoale s-au adăugat multe altele, aşa cum sunt Serviciul Numelor de Domenii (Domain Name Service - DNS) pentru stabilirea corespondenţei dintre numele gazdelor şi adresele reţelelor, HTTP, folosit pentru aducerea paginilor de pe Web şi multe altele.

TCP/IP

Figura 4.3 - Protocoale Aplicaţie

24

Nivelul Transport

Nivelul transport este proiectat astfel încât să permită conversaţii între entităţile pereche din host-urile sursă şi, respectiv, destinaţie, la fel ca în nivelul transport OSI. În acest

sens au fost definite două protocoale end-to end. Primul din ele, TCP (Transmission Control Protocol), este un protocol sigur orientat pe conexiuni care permite ca un flux de octeţitrimişi de pe un host să ajungă fără erori pe orice alt host din inter-reţea. Orientarea pe conexiune nu semnifică faptul că există un circuit între computerele care comunică, ci faptul că segmentele nivelului Aplicaţie călătoresc bidirecţional între două gazde care sunt conectate logic pentru o anumită perioadă. Acest proces este

cunoscut sub denumirea de packet switching. Acest protocol fragmentează fluxul de octeţi în

mesaje discrete şi pasează fiecare mesaj nivelului internet. La destinaţie, procesul TCP receptor reasamblează mesajele primite într-un flux de ieşire. TCP tratează totodată controlul fluxului pentru a se asigura că un emiţător rapid nu inundă un receptor lent cu mai multe mesaje decât poate acesta să prelucreze.

Al doilea protocol din acest nivel, UDP (User Datagram Protocol), este un protocol nesigur, fără conexiuni, destinat aplicaţiilor care doresc să utilizeze propria lor secvenţiere şi control al fluxului, şi nu pe cele asigurate de TCP.

Protocolul UDP este de asemenea mult folosit pentru interogări rapide întrebare-răspuns, client-server şi pentru aplicaţii în care comunicarea promptă este mai importantă decât comunicarea cu acurateţe, aşa cum sunt aplicaţiile de transmisie a vorbirii şi a imaginilor video. Relaţia dintre IP, TCP şi UDP este prezentată în figura 4.5. De când a fost dezvoltat acest model, IP a fost implementat pe multe alte reţele.

Figura 4.5 – Relaţiile între protocoaleNivelul internet

Îngrijorarea principală a Departamentului de Apărare American dupa proeictarea ARPANET era că o parte din preţioasele sale gazde, rutere şi dispozitive de interconectare ar

TCP/IP

Figura 4.4 - Protocoale Transport

25

putea ceda dintr-un moment în altul. Astfel, un obiectiv major a fost ca reţeaua să poată supravieţui pierderii echipamentelor din subreţea fără a fi întrerupte conversaţiile existente. Cu alte cuvinte, DoD dorea ca, atâta timp cât funcţionau hostul sursă şi hostul destinaţie,conexiunile să rămână intacte, chiar dacă o parte din dispozitivele sau din liniile de transmisie erau brusc scoase din funcţiune. Mai mult, era nevoie de o arhitectură flexibilă, deoarece se aveau în vedere aplicaţii cu cerinţe divergente, mergând de la transferul de fişiere până la transmiterea vorbirii în timp real.Toate aceste cerinţe au condus la alegerea unei reţele cu

comutare de pachete bazată pe un nivel inter-reţea fără conexiuni.

Nivelul internet, este axul pe care se centrează întreaga arhitectură. Rolul său este de a permite gazdelor să emită pachete în orice reţea şi a face ca pachetele să circule independent până la destinaţie (chiar dacă aceasta face parte din altă reţea).Pachetele pot chiar să sosească într-o ordine diferită faţă de cea în care au fost trimise, caz în care rearanjarea cade în sarcina nivelurilor superioare. De observat că ,,internet” este folosit aici într-un sens generic, chiar daca acest nivel este prezent şi în Internet.Aici analogia este cu sistemul

de poştă (clasică). O persoană dintr-o anumită ţară poate depuneîntr-o cutie poştală mai multe scrisori internaţionale şi, cu puţin noroc, majoritatea scrisorilor

vor ajunge la adresa corectă din ţara de destinaţie. Probabil că scrisorile vor trece pe drum prin mai multe oficii de cartare, dar acest lucru se face transparent pentru utilizatori. Mai mult, faptul că fiecare ţară (adică fiecare reţea) are propriile timbre, propriile mărimi favorite de plicuri şi propriile reguli de livrare este ascuns beneficiarilor.Nivelul internet defineşte oficial un format de pachet şi un protocol numit IP (Internet Protocol). Sarcina nivelului internet este să livreze pachete IP către destinaţie. Problemele majore se referă la dirijarea pachetelor şi evitarea congestiei. În consecinţă, este rezonabil să spunem că nivelul internet din TCP/IP funcţionează asemănător cu nivelul reţea din OSI. Figura 4.5 arată această corespondenţă.

Nivelul Acces la reţea

Pe acest nivel sunt definite standardele şi tehnologiile Ethernet IEEE 802.3, precum CSMA/CD şi 10BASE-T.

Acest nivel se ocupă cu toate serviciile pe care le necesită un pachet IP pentru a realiza o legatură fizică, incluzând şi detalii legate de tehnologiile LAN şi WAN, de medii de transmisie, adică ceea ce fac nivelurile OSI legătură de date şi fizic.

TCP/IP

TCP/IP

Figura 4.6 - Protocoale IP

Figura 4.7 - Nivelul Acces la Reţea

26

Figura 4.8 - Protocoale TCP/IP

4.2 Componente şi arhitectură

4.2.1 Componente tipice

Un exemplu tipic de IDPS la nivel de reţea este compus din senzori, unul sau mai multe servere de management, multiple console, şi, opţional, unul sau mai multe servere de baze de date (dacă esete acceptată utilizarea lor). Toate aceste componente sunt similare cu alte tipuri de tehnologii IDPS, cu excepţia senzorilor. Un senzor specific acestui tip de sistem monitorizează şi analizează activitatea de reţea pe unul sau mai multe segmente de reţea. Cardurile de reţea, ce vor realiza monitorizarea vor fi în modul promiscuu, ceea ce înseamnă că vor accepta toate pachetele de intrare pe care le văd, indiferent de destinaţiile lor. Majoritatea implementărilor folosesc mulţi senzori, ajungându-se la implementari mari cu sute de senzori. Senzorii sunt disponibile în două formate:

De tip appliance. Acest tip este compus din hardware specializat şi software de tip senzor. Hardware-ul este de obicei optimizat pentru utilizarea senzorului, incluzând interfeţe de reţea specializate şi driver de captare eficientă a pachetelor, procesoare specializate sau alte componente hardware care ajută la analiză. Este utilizat de cele mai multe ori un sistem de operare personalizat ce nu este destinat a fi accesat direct de către administrator;

FTP HTTP SMTP DNS DNS TFTP

TCP UDP

IP

INTERNET LAN Alte LAN şi WAN

27

De tip software. Unii vendorii vând senzori compuşi doar din produse software. Administratorii îi pot instala doar pe host-uri ce îndeplinesc anumite cerinţe. Senzorul software poate include un sistem de operare specific, sau poate fi instalat într-unul standard ca orice altă aplicaţie.

4.2.2 Arhitectura de reţea şi locaţiile senzorilor

Organizaţiile ar trebui să ia în considerare utilizarea reţelelor de management pentru implementarea IDPS-urilor la nivel reţea dacă este posibil. În cazul în care un IDPS este implementat fără o reţea de management separată, organizaţiile trebuie să decidă dacă este nevoie sau nu de un VLAN pentru a proteja comunicaţiile interne.

În plus faţă de alegerea reţelei pentru componente, administratorii trebuie să decidă unde să fie amplasaţi senzori.Aceştia pot fi utilizaţi într-unul din cele două moduri:

Inline. Un senzor inline este implementat astfel încât traficul de reţea ce este monitorizat trebuie să treacă prin el, la fel ca fluxul de trafic asociat cu un firewall. De fapt, unii astfel de senzori sunt nişte dispozitive hibride de tip firewall / IDPS.

Figura 4.9 - Exemplu implementare senzori inline

Motivaţia principală pentru implementarea senzorilor inline este de a le permite

28

să oprească atacurile prin blocarea traficului în reţea. Senzori inline sunt de obicei plasaţi în locuri în care ar fi plasaţi firewall-uri sau alte dispozitive de securitate (la graniţa dintre reţelele interne, ce trebuie separate, şi cele externe). Senzori ce nu sunt hibrizi sunt de multe ori amplasaţi pe partea mai sigură a unei diviziuni de reţea pentru a avea mai puţin trafic de procesat şi pentru a reduce încărcătura unui firewall.Figura 4.9 prezintă o astfel de implementare.

Pasiv. Un senzor pasiv monitorizează o copie a traficului real de reţea. Senzori pasivi sunt de obicei implementaţi astfel încât să poată monitoriza locaţiile cheie ale unei reţele (diviziunile dintre reţelele) şi segmente de reţea cheie(activitatea într-o zonă demilitarizată - DMZ). Senzori pasivi pot monitoriza traficul, prin diverse metode, după cum urmează:

o Port de tip spanning. Multe switch-uri au un port de tip spanning; reprezintă un port care poate vedea tot traficul de reţea ce trece prin switch. Conectarea unui senzor la un astfel de port poate permite monitorizarea traficului din reţea. Deşi această metodă de monitorizare este relativ uşor şi ieftin de implementat, ea poate fi problematică. În cazul în care un switch este configurat sau reconfigurat incorect, portul de tip spanning ar putea să nu vadă tot traficul. O altă problemă cu aceste porturi este că utilizarea lor duce la un consum mare de resurse; atunci când un switch are de prelucrat un flux foarte mare de trafic, este posibil ca portul să nu vadă tot traficul, existând posibilitatea chiar să fie închis. De asemenea, multe switch-uri dispun doar de un singur port de acest tip, iar în cele mai multe cazuri trebuie conectate multe dispozitive de genul uneeltelor de monitorizare, analiză şi diagnosticare a traficului sau alte tipuri de senzori IDPS ce trebuie să analizeze acelaşi traffic.

o Network Tap. Reprezintă o conexiune directă între un senzor şi reţeaua fizică de trafic.Este oferit astfel senzorului o copie a tot traficului de reţea transportat de dispozitivele fizice.Instalarea, în general, implică o perioadă de nefuncţionare a reţelei, iar eventuale probleme cu această metodă ar putea cauza perioade de nefuncţionare suplimentare. De asemenea, spre deosebire de porturile de tip spanning, ce sunt de obicei, deja prezente într-o organizatie, aceste interceptoare trebuie să fie achiziţionate şi incluse ca add-ons la reţea.

o IDS4 de tip Load Balancer. Reprezintă un dispozitiv care agreghează şi direcţionează traficul de reţea către sisteme de monitorizare, inclusiv către senzori IDPS. Poate primi copii ale traficului de reţea de la unul sau mai multe porturi de tip spanning sau interceptoare de reţea, agregând traficul din diferite reţele (ex: reasamblează o sesiune care a fost împărţită între două reţele). Copii ale traficului sunt trimise apoi către unul sau mai multe dispozitive de ascultare, pe baza unui set de reguli stabilite de către un administrator. Regulile precizează ce tip de trafic direcţionează către fiecare dispozitiv de ascultare. Configuraţiile comune includ următoarele:

4 Intrusion Detection System

29

Trimiterea întregului trafic mai multor senzori. Acest lucru ar putea fi făcut pentru disponibilitate ridicată sau pentru a avea mai multe tipuri de senzori ce efectuează o analiză concomitentă ale aceleaşi activităţi.

Împărţirea dinamică a traficului între mai mulţi senzori în funcţie de volum. Acest lucru se face se realizează pentru a efectua o echilibrarea a sarcinilor, astfel încât nici un senzor să nu fie supraîncărcat.

Împărţirea traficului între mai mulţi senzori în funcţie de adrese IP, protocoale sau alte caracteristici. Acest lucru ar putea fi făcută pentru echilibrarea a sarcinii, având de exemplu un senzor dedicat activitătii web şi un alt senzor ce monitorizează toate celelalte activităţi. Divizarea traficului ar putea fi făcută pentru a efectua o analiză mai detaliată a anumitor tipuri de trafic (ex: activităţi ce implică cele mai importante hosturi).

30

Divizarea traficului între mai mulţi senzori poate determina o reducere a preciziei de detecţie în cazul în care evenimentele legate sau porţiuni ale unui singur eveniment sunt văzute de senzori diferiţi. De exemplu, să presupunem că doi senzori observă etape diferite ale unui atac; în cazul în care fiecare pas este considerat benign luat izolat, dar luaţi împreună, în ordine sunt rău intenţionate, atunci atacul s-ar putea să nu fie recunoscut.

Pentru a putea folosi un senzor în prevenţia intruziunilor acesta trebuie utilizat în mod inline, nu pasiv. Pentru că tehnicile pasive monitorizează doar o copie a traficului, ele nu oferă nici o metodă de încredere prin care să oprească traficul îna a ajunge la destinaţie. În unele cazuri, un senzor pasiv poate plasa pachete într-o reţea în încercarea de a perturbă o conexiune, dar astfel de metode sunt, în general, mai puţin eficiente decât metodele inline.

4.3 Capabilităţi de securitate

4.3.1 Culegerea informaţiilor

Unele IDPS-uri la nivel reţea oferă capabilităţi limitate de culegere a informaţiilor( colectarea de informaţii despre host-uri şi activitatea de reţea ce implică acele host-uri).Exemple de capabilităţi de culegere a informaţiilor sunt următoarele:

Identificarea host-urilor. Un senzor IDPS ar putea fi capabil să creeze o listă cu host-urile din reţeaua organizaţiei grupate prin adresa IP sau adresa MAC. Lista poate fi folosită ca un profil pentru a identifica host-urile noi din reţea.

Identificarea sistemelor de operare. Un sensor este capabil să identifice sistemele de operare şi versiunile acestora utilizate de către computerele organizaţiei prin diverse tehnici. De exemplu, senzorul poate urmări ce porturi sunt utilizate pe fiecare host, fapt ce ar putea indica un anumit sistem de operare sau o familie (ex: Windows, Unix).

O altă tehnică este de a analiza header-ul pachetului pentru anumite caracteristici neobişnuite sau combinaţii de caracteristici care sunt setate de anumite sisteme de operare; acest lucru este cunoscut sub numele de amprentare pasivă. Unii senzori pot identifica, de asemenea, versiuni ale aplicaţiilor, care în unele cazuri indică ce sistem de operare este în uz. Ştiind ce versiuni de sisteme de operare sunt în uz poate fi de ajutor în identificarea host-urilor potenţial vulnerabile.

Identificarea Aplicaţiilor. Pentru unele aplicaţii, un senzor poate identifica versiunile utilizate ţinând evidenţa porturilor folosite şi monitorizând unele caracteristici de comunicare ale aplicaţiei. De exemplu, atunci când un client stabileşte o conexiune cu un server, serverul ar putea spune clientului ce versiune a software-ului rulează şi invers. Informaţii privind versiunile apliaţiilor pot fi utilizate în identificarea aplicaţiilor potenţial vulnerabile şi a utilizării neautorizate a unor aplicaţii.

Figura 4.10 - Exemplu de implementare senzori pasivi

31

Identificarea caracteristicilor reţelei. Unii senzori IDPS pot colecta informaţii generale despre traficul de reţea legat de configurarea dispozitivelor şi host-urilor din reţea, cum ar fi numărul de hop-uri între două dispozitive. Această informaţie poate fi folosită pentru a detecta modificările ce pot apărea în configuraţia reţelei.

4.3.2 Capabilităţi de logare

IDPS-urile de nivel reţea efectuează de obicei un logging extins legat de evenimentele detectate. Aceste date pot fi utilizate pentru a confirma validitatea alertelor, pentru a investiga incidentele şi a corela evenimente cu alte surse de logare. Câmpurile de date înregistrate includ următoarele:

Timestamp (de obicei, data şi ora); ID-ul conexiunii sau al sesiunii (de obicei un număr consecutiv sau unic atribuit

fiecărei conexiuni TCP sau unor grupuri de pachete corespunzătoare protocoalelor fără conexiune);

Tipul evenimentului sau alertei5; Evaluare (prioritate, severitate, impactul, nivelul de încredere); Nivelul corespunzător protocolului:reţea, transport, sau aplicaţie; Adresele IP sursă şi destinaţie; Porturile TCP/UDP sursă şi destinaţie sau tipuri de ICMP şi codurile aferente; Numărul de octeţi transmişi; Datele decodate din încărcătura utilă( payload), cum ar fi cereri de aplicaţii şi

răspunsuri; Informaţiile de stare (ex: numele de utilizator autentificat);

Acţiunea de prevenţie întreprinsă( dacă este cazul).

4.3.3 Detecţia

În cadrul acestui tip de IDPS sunt oferite capabilităţi extinse şi largi de detecţie. Cele mai multe produse folosesc o combinaţie între detectare bazată pe semnături, cea bazată pe detecţia anomaliilor şi tehnicile analizei protocoalelor de tip stateful pentru a efectua o analiză în profunzime a protocoalelor comune; organizaţiile ar trebui să utilizeze sistemele care utilizează o astfel de combinaţie de tehnici. Metodele de detectie sunt strâns legate; un motor de analiză a protocoalelor de tip stateful ar putea împărţi activitatea analizată în solicitări şi răspunsuri, fiecare parte fiind examinată pentru anomalii şi comparată cu semnăturile activităţilor cunoscută a fi rău intenţionate. Unele produse folosesc aceleaşi tehnici şi oferă

5 În consolă, tipul evenimentul sau alertei face de cele mai multe ori legătura către informaţii de suport despre vulnerabilităţi / exploatări anume, cum ar fi referinţe către informaţii suplimentare şi numere CVE ( Common Vulnerabilities and Exposures)

32

aceeaşi funcţionalitate ca şi software-urile bazate pe analiza comportamentului de reţea (NBA).

4.3.3.1 Tipurile de evenimente detectate

Tipurile de evenimente cel mai frecvent detectate de senzori sunt:

Atacurile la nivelul aplicaţie al stivei TCP.(ex: banner grabbing, buffer overflow, format string attacks, password guessing , transmisie de malware). Sunt analizate majoritatea protocoalelor speficice nivelului aplicaţie. Includem aici: DHCP (Dynamic Host Configuration Protocol), DNS (Domain Name Server) , Finger, FTP (File Transfer Protocol), IMAP( Internet Message Access Protocol ), IRC( Internet Relay Chat ), NFS( Network File System), POP( Post Office Protocol ), HTTP6, RPC( Remote Call Procedura), SIP( Session Initiation Protocol), SMB( Server Message Bloc), SMTP( Simple Mail Transfer Protocol), SNMP( Simple Network Management Protocol), Telnet şi TFTP( Trivial File Transfer Protocol ), precum şi protocoalele specific bazelor de date, aplicaţii de mesagerie instant şi software-uri peer-to-peer de partajare de fişiere;

Atacurile la nivel transport (scanarea porturilor, fragmentare neobşinuită a pachetelor, inundaţii(floods) cu SYN). Protocoalele cel mai des analizate sunt TCP şi UDP;

Atacurile la nivel internet/reţea (adrese IP false, valorile ilegale în header-ul IP). Protocoalele cel mai des analizate sunt IPv4, ICMP, şi IGMP. Multe produse oferă support şi pentru analiza IPv6.Nivelul de analiză IPv6 diferă de la un produs la altul.Unele nu oferă nici un suport IPv6 sau doar alertează administratorii de prezenţa activităţii IPv6. Altele pot face o procesare de bază a activităţii IPv6 şi a traficului IPv6 tunelat, cum ar fi înregistrare adreseleor IP sursă şi destinaţie, precum şi extragerea încărcăturii utile (ex: HTTP, SMTP) pentru o analiză în profunzime. Unele produse pot face o analiză completă a protocolului IPv6, cum ar fi confirmarea validităţii opţiunilor IPv6, pentru identificarea utilizarării anormale a protocolului;

Servicii/aplicaţii neprevăzute ( ex: protocoale de tunelare, backdoors, host-uri ce rulează aplicaţii/servicii neautorizate). Acestea sunt, de obicei, detectate prin analiza protocoalelor de tip stateful, care poate determina dacă activitatea dintr-o conexiune este în concordanţă cu protocolul utilizat, sau prin metode de detectare a anomaliilor ce pot identifica modificări ale fluxurilor de reţea şi porturile deschise;

Încălcarea politicilor de securitate (ex: utilizarea de site-uri web nepotrivite, utilizarea aplicaţiilor interzise). Unele tipuri de încălcări ale politicii de securitate pot fi detectate prin IDPS-uri, permiţând administratorilor să precizeze caracteristicile

6 De�i aceste IPDS-uri pot analiza activitatea protocolului HTTP, nu pot efectua analize cu privire la utilizarea serviciilor de web, cum ar fi mesajele de tip SOAP( Simple Object Access Protocol) �i XML( Extensible Markup Language) transportate de HTTP. Tehnologii de securitate cunoscute ca gateway-uri XML sau firewall-uri XML au fost create special pentru a analiza activitatea serviciilor web. În plus fa�ă de furnizarea de func�ii de prevenire a intruziunilor, aceste tehnologii efectuează filtrarea, autentificarea �i autorizarea serviciilor, controlul accesului �i logare.

33

activităţilor care nu ar trebui permise, cum ar fi numere de porturi TCP/ UDP, adrese IP, nume de site-uri web, precum şi alte date ce pot fi identificate prin examinarea traficului de reţea.

Există posibilitatea monitorizării negocierii iniţiale efectuată la stabilirea comunicaţiilor criptate pentru a identifica software-ul client sau dacă serverul are vulnerabilitati cunoscute sau nu este configurat corect. Acest lucru poate include protocoale de nivel aplicaţie, cum ar fi SSH (Secure Shell) şi SSL( Secure Sockets Layer), şi protocoalele de nivel reţea/ internet folosite în reţelele virtuale(ex: IPsec – IP Security).

Senzori pot determina de multe ori dacă un atac are şanse de reuşită. De exemplu, aşa cum este descris în secţiunea 4.3.3.3, senzorii ar putea şti ce versiune de software de tip web server se execută pe fiecare dintre servere web ale organizaţiei. În cazul în care un atacator lansează un atac împotriva unui server de web, ce nu este vulnerabil la acest tip de atac, atunci senzorul ar putea produce o alertă cu o prioritate redusă; în cazul în care serverul este considerat a fi vulnerabil, atunci senzorul ar putea produce o alertă de înaltă prioritate. Senzorii sunt de obicei configuraţi să oprească toate atacurile indiferent dacă sunt sau nu susceptibile în a reuşi, dar sistemul ar putea loga evenimentele cu nivele de prioritate diferite, în funcţie de rezultatul lor, în cazul în care ar fi fost blocate.

4.3.3.2 Acurateţea detecţiei

Din punct de vedere istoric, IDPS-urile la nivel reţea au fost asociate cu rate ridicate al rezultatelor de tip fals pozitiv şi fals negativ. Cele mai multe dintre tehnologiile vechi s-au bazat în primul rând pe detecţia bazată pe semnături, caracterizată prin detectarea ameninţărilor relativ simple şi binecunoscute. Tehnologiile noi folosesc o combinaţie de metode pentru a creşte acurateţea şi intervalul detecţiei, şi, în general, ratele rezultatelor de tip fals pozitiv şi fals negativ au scăzut. O altă problemă comună cu precizia acestor IDPS-uri este faptul că acestea necesită de obicei un tuning şi o personalizare considerabilă pentru a lua în considerare caracteristicile mediului monitorizat.

Falsurile pozitive şi falsurile negative pentru senzori pot fi reduse oarecum din cauza complexităţii activităţilor monitorizate. Un singur senzor monitorizează adesea trafic ce implică sute sau mii de hosturi interne şi externe. Numărul şi varietatea de sisteme de operare şi aplicaţii în uz în reţeaua monitorizată poate fi imens, iar sistemele de operare şi aplicaţiile sunt în continuă schimbare. Acest lucru face imposibil pentru un senzor să înţeleagă tot ceea ce vede.

Chiar mai rău, senzorii trebuie să monitorizeze activitatea pentru mai multe combinaţii diferite de servere şi clienti. De exemplu, o organizaţie ar putea utiliza 10 tipuri şi versiuni de servere web, pe care utilizatorii le-ar putea accesa cu 50 de tipuri şi versiuni diferite de browsere web. Fiecare combinaţie de browser şi server ar putea avea caracteristici de comunicare unice (ex: secvenţa de comenzi, codurile de răspuns), lucru ce ar putea afecta acurateţea analizei. De asemenea, diferite configuraţii şi particularizări ar putea fi aplicate browserelor şi serverelor. Dispozitivele de control( firewall-uri, servere proxy) dintre servere şi clienţi ce modifică activitatea de reţea, ar putea provoca dificultăţi suplimentare pentru senzori.

În mod ideal, IDPS-urile la nivel reţea ar trebui să poată interpreta toată activitatea de reţea la fel cum endpoint-urile o fac. De exemplu, diferite tipuri de servere web pot interpreta aceeaşi cerere web în moduri diferite. Tehnicile speficie analizei protocoalelor stateful de

34

multe ori încercă să realizeze acest lucru prin replicarea prelucrării efectuate de tipuri comune de clienţi şi servere. Acest lucru permite senzorilor îmbunătăţirea preciziei de detecţie. Mulţi atacatorii fac uz de caracteristicile specifice de prelucrare ale clienţilor sau serverlor, cum ar fi manipularea codificării caracterelor, în atacurile lor sau în tehnicile de evaziune folosite. Organizaţiile trebuie să utilizeze aceste IDPS-uri deoarece pot combate utilizarea tehnicilor comune de evaziune.

4.3.3.3 Tunning şi customizare

Pentru a îmbunătăţi precizia de detecţie este nevoie de un tunning şi o personalizare mai în detaliu. Exemple de capabilităţi de personalizare şi tuning sunt pragurile pentru scanarea de porturi şi încercările de autentificare ale aplicaţiilor, listele negre şi listele albe pentru adrese IP şi nume de utilizator, precum şi setări de avertizare. Unele produse oferă şi funcţionalităţi de editare a codului, care este de obicei limitat la semnături, dar, în unele cazuri, este permis accesul la codul adiţional, ca în cazul programele utilizate pentru a efectua analiza protocoalelor de tip stateful.Se pot utiliza informaţiile legate de host-urile organizaţiei pentru a îmbunătăţi precizia de detecţie. De exemplu, s-ar putea permite administratorilor specificarea adreselor IP utilizate de serverele web ale organizaţiei, servere de mail, şi alte tipuri comune de host, precum şi tipurile de servicii oferite de fiecare host(tipul şi versiunea aplicaţie de server web). Acest lucru permite sistemului o prioritizare mai bună a alertelor; o alertă pentru un atac specific serviciului Apache având ca ţintă un server de web Apache ar avea o prioritate mai mare decât acelaşi atac îndreptat către un alt tip de server web. Pot fi importate rezultatele scanărilor vulnerabilităţilor şi apoi utilizate pentru a determina ce atacurile ar avea succes dacă nu ar fi blocate. Acest lucru permite luarea unor decizii mai bune şi precise cu privire la acţiunile de prevenire şi prioritizare a alertelor.

4.3.3.4 Limitări tehnologice

Deşi sunt oferite capabilităţi extinse de detectare, acestea au totuşi unele limitări importante. Trei dintre cele mai importante sunt:analiza traficul criptat din reţea, manipularea sarcinilor cu trafic intens şi rezistenţa atacurilor împotriva IDPS-ului însuşi. Aceste limitări sunt discutate mai jos.

Atacurile lansate prin traficul criptat nu pot fi detectate, inclusiv cele din reţelele private virtuale, din sesiunile SSH sau ce folosesc HTTP peste SSL (HTTPS). Aşa cum am menţionat anterior, există posibilitatea realizării unei analize a configurării iniţiale a conexiunilor criptate, care poate identifica dacă software-ul client sau serverul are vulnerabilităţi cunoscute sau nu este configurat corect. Pentru a se asigura că o analiză satisfăcătoare se face asupra traficului criptat, organizaţiile ar trebui să utilizeze sisteme ce pot analiza datele înainte ca acestea să fie criptate sau după ce au fost decriptate. Exemplele includ plasarea unor senzori în reţea pentru a monitoriza traficul necriptat (ex: traficul introdus într-o organizaţie prin intermediul unui gateway VPN şi decriptat apoi) şi utilizarea unui software la nivel de host pentru a monitoriza activitatea host-ului sursă sau destinaţie.

IDPS-urile la nivel reţea pot fi în imposibilitatea de a efectua o analiză completă sub sarcini mari. Senzori pasivi ar dropa unele pachete, existând posibilitatea trecerii unor incidente ca nedetectate, mai ales în cazul în care analiza protocoalelor stateful este în uz. Pentru senzorii inline, droparea pachetele sub sarcini mari provoacă perturbări în

35

disponibilitatea reţelei; întârzierile cauzate de prelucrarea pachetelor ar putea cauza o latenţă inacceptabil de mare. Pentru a evita acest lucru, organizaţiile ce folosesc senzori inline ar trebui să-i selecteze pe cei care pot recunoaste condiţiile unui trafic foarte mare, iar în acest caz să treacă anumite tipuri de trafic fără a efectua o analiza completă (parţială sau deloc) sau să dropeze traficul cu o prioritate redusă pentru a reduce sarcina . Multi furnizori încearcă să optimizeze senzori pentru a oferi performanţe mai bune la sarcini mari prin utilizarea unui hardware specializat (ex: plăci de reţea de mare lăţime de bandă) şi recompilarea componentelor software pentru a include setările şi personalizările făcute de către administratori. Deşi vânzătorii îşi evaluează senzorii la lăţimi de bandă maxime, capacitatea reală a oricărui produs depinde de mai mulţi factori:

Tipurile de protocoale în uz(aplicaţie, transport, reţea/internet) şi profunzimea analizei efectuate pentru fiecare protocol. Vendorii îşi evaluează produsele bazându-se pe capacitatea lor de a efectua analize rezonabile asupra unui mix "tipic" de protocoale. Nivelul de analiză pe care o organizaţie doreşte să o efectueze şi tipurile de protocoale utilizate pot varia considerabil faţă de condiţiile testate;

Longevitatea conexiuni. Un senzor poate avea un overhead mai scăzut pentru o conexiune pe termen lung, faţă de cazul unor mai multe conexiunii pe termen scurt;

Numărul de conexiuni simultan.

Senzorii sunt sensibili la diferite tipuri de atacuri. Atacatorii pot genera volume neobişnuit de mari de trafic caracteristice atacurilor de tip DDoS şi trafic anormal (pachete fragmentate neobişnuit), pentru a încerca să epuizeze resursele unui senzor sau să-i provocea dezactivarea. O altă tehnică de atac, cunoscut sub numele de orbire( blinding), generează trafic care să declanşeze mai multe alerte într-o perioadă scurtă de timp, fiind special conceput pentru a profita de configuraţiile tipice ale senzorilor. În multe cazuri, acest tip de trafic nu are ca obiectiv atacul unor ţinte. Scopul real este dezactivarea sistemului sau generarea unui număr foarte mare de alerte astfel încât alerte generate de atacul real vor trece neobservat. Mulţi senzori pot recunoaşte folosirea tehnicilor şi instrumentelor comune pentru declanşarea unor astfel de atacuri; astfel pot alerta administratori de incindenţa atacului, ignorând restul activităţilor pentru a reduce sarcina. Organizaţiile trebuie să selecteze produse care oferă caracteristici care le fac rezistente la eşec în cazul unor atacuri.

4.3.4 Prevenţia

Sunt oferite diverse capacităţi de prevenire, inclusiv următoarele (grupate în funcţie de tipul de senzor):

36

Pasiv

Încheierea sesiunii TCP curente. Un senzor pasiv poate determina încheierea unei sesiune TCP existente prin trimiterea de pachete TCP cu flag RESET setat catre ambele endpoint-uri; acest lucru este numit session sniping7.Senzorul face acest lucru pentru a face să pară că fiecare endpoint încercă să termine conexiunea. Scopul este acela ca unul dintre obiective să încheie conexiunea înainte ca un atac să reuşească. În multe cazuri însă, pachetele de resetare nu sunt primite la timp.De asemenea, din cauza faptului că această metodă este aplicabilă doar pentru TCP, nu poate fi folosită în cazul atacurilor bazate pe alte tipuri de pachete, incluzând UDP sau ICMP. Metodasession sniping nu mai este larg utilizată din cauză noilor metode mult mai eficiente.

Inline

Executarea de firewalling inline.Cei mai mulţi senzori ofera capabilităţile unui firewall, astfel poate dropa sau respinge activităţile suspecte;

Reducerea lăţimi de bandă. Dacă un anumit protocol este utilizat necorespunzător, ca în cazul unui atac DoS sau în distribuţia unor malware-uri, unii senzori de linie poate limita procentul de bandă de reţea pe care protocolul respectiv îl poate folosi. Acest lucru împiedică impactul negativ asupra lăţimii de bandă în cazul utilizării de către alte resurse;

Modificarea conţinutului maliţios. După cum este descris în secţiunea 1.2, unii senzori inline poate “curăţa” o parte dintr-un pachet, conţinutul rău intenţionat este înlocuit cu un conţinut benign, pachetele dezinfectate fiind trimise apoi la destinaţie. Un senzor care acţionează ca un proxy ar putea efectua o normalizarea automată a întregului trafic. Aceasta are ca efect eliminarea unor atacuri care implică antetele pachetelor şi unele antete aplicaţie, indifferent dacă IDPS-ul a detectat sau nu un atac. Unii senzori pot elimina ataşamente infectate din email-uri, precum şi alte elemente discrete de conţinut malware din traficul în reţea.

Pasiv & Inline

Reconfigurarea altor dispozitive de securitate. Mulţi senzori pot instrui diferite dispozitive de securitate de reţea, cum ar fi firewall-uri, routere, switch-uri pentru a se reconfigura singure spre a bloca anumite tipuri de activităţi sau să le plaseze pe alte rute. Acest lucru poate fi util în mai multe situaţii, cum ar fi păstrarea unui atacator extern în afara reţelei şi trimiterea în carantină a unui host care a fost compromis (ex: mutarea într-un VLAN carantină). Această tehnică de prevenire este utilă doar pentru traficul de reţea ce pot fi diferenţiat în funcţie de caracteristicile header-ului recunoscute de către dispozitive de securitate( adresele IP, numere de port;

Rularea unui program terţ sau script. Se poate rula un script specificat de către administrator când este detectată o anumită activitate malware. Acest lucru ar putea

7 Un senzor inline poate încerca această tehnică, dar este mult mai ineficientă decât celelalte acţiuni pe care le poate întreprinde; astfel, în practică aceasta tehnică este rar folosită de către un senzor inline

37

declanşa o acţiune de prevenire dorită de către administrator, cum ar fi reconfigurarea altor dispozitive de securitate pentru a bloca respectiva activitate. Programe terţele sau script-urile sunt cele mai frecvent utilizate atunci când sistemul nu are caracteristicile de prevenire dorite de către administratorii.

Cei mai mulţi senzori permite administratorilor specificare configuraţiei de prevenţie pentru fiecare tip de alertă. Aceasta include activarea sau dezactivarea prevenţiei, precum şi specificarea tipului de acţiune ce trebuie întreprinsă. Unii senzori au un mod de învăţare sau de simulare ce suprimă toate acţiunile de prevenire, indicând în schimb când ar fi fost necesară efectuarea unei acţiuni de prevenire. Acest lucru permite administratorilor să monitorizeze şi să ajusteze configuraţia capacităţilor de prevenţie înainte de a le activa, ceea ce reduce riscul de blocare accidental al activităţii benigne.

4.4 Management

4.4.1 Implementare

Odată ce un produs a fost selectat, administratorii trebuie să proiecteze o arhitectură, să efectueze testarea şi asigurarea, iar apoi să le implementeze. Următoarele reprezintă nişte completări la materialul prezentat în secţiunea 3.3.1:

Designul arhitecturii. O atenţie specială trebuie acordată locului în care senzorii ar trebui să fie plasaţi în reţea, numărului de senzori necesari, ce senzori ar trebui să fie pasivi sau de tip inline şi modulului în care senzorii pasivi ar trebui să fie conectaţi la reţea;

Testarea şi amplasarea componentelor. Implementarea unui astfel de sistem poate necesita căderi scurte ale reţelei scurte, în special atunci când sunt integraţi senzori inline. Totuşi, amplasarea senzorilor pasiv poate provoca de asemenea întreruperi din mai multe motive, incluzând instalarea interceptoarelor de reţea, a IDS-urilor de tip load-balancer şi reconfigurarea switch-urilor pentru a activa porturile de tip span;

Securizarea componentelor. Administratorii trebuie să se asigure că pentru senzori atât pasivi, cât şi cei inline nu au fost asignate adrese IP interfeţelor de reţea folosite pentru a monitoriza traficul, cu excepţia celor utilizate pentru management. Operarea unui senzor fără adrese IP alocate pentru interfeţele de monitorizare se numeşte funcţionare în mod invizibil(stealth mode). Acest mod îmbunătăţeşte securitatea senzorilor deoarece împiedică alte host-uri în a iniţia conexiuni cu aceştia. Astfel, sunt ascunşi faţă de atacatori, limitând expunerea lor la atacuri. Cu toate acestea, atacatorii ar putea fi în măsură să identifice existenţa unui senzor şi să determine ce produs este utilizat prin analiza caracteristicilor acţiunilor de prevenire. O astfel de analiză ar putea include monitorizarea reţelelor protejate şi determinarea a căror tipuri de

38

modelelor de scanare ar putea declanşa răspunsuri particulare şi ce valori sunt setate în anumite câmpuri din antetul pachetelor.

4.5 Operare şi mentenanţă

Operarea şi întreţinerea se realizează în acelaşi mod prezentat în general în secţiunea 3.3.2.

39

5. IDPS-uri la nivel de host

Un astfel de sistem monitorizează caracteristicile şi evenimentele din cadrul unui singur host pentru activităţi suspecte. Exemple de tipuri de caracteristici ce ar putea fi monitorizate sunt: traficul de reţea cu sau fără fir (numai pentru acel host), logurile de sistem, procesele active, accesul şi modificarea fişierelor sau modificările aduse configuraţiei sistemului sau aplicaţiilor.

5.1 Componente şi Arhitectură5.1.1 Componentele tipice

Cele mai multe IDPS-uri la nivel host au software-uri de detectare cunoscute sub numele de agenţi, instalaţi pe gazdele de interes. Fiecare agent monitorizează activitatea unui computer, iar în cazul în care toate capacităţile sunt activate, efectuează, de asemenea, acţiuni de prevenire. Agenţii transmit datele la servere de management, care pot utiliza opţional servere de baze de date pentru stocare. Consolele sunt utilizate pentru management şi monitorizare.

Unele sisteme utilizează dispozitive speciale care rulează software-ul agent în locul unei instalări individuale a software-ului agent pe gazdă. Fiecare dispozitiv este poziţionat pentru a monitoriza traficul de reţea ce merge la şi de la un anumit host. Din punct de vedere tehnic, acestea ar putea fi considerate sisteme de nivel reţea, deoarece acestea sunt utilizate în mod inline pentru a monitoriza traficul în reţea. Cu toate acestea, ele monitorizează obicei activitate unui tip specific de aplicaţie, cum ar fi un server web sau server de baze de date; astfel, acestea sunt mai specializate decât un IDPS standard de nivel reţea. De asemenea, software-ul care rulează pe dispozitiv are adesea funcţionalităţi identice sau similare cu cele ale agenţilor bazaţi pe host. De aceea, IDPS-uri la nivel de host ce folosesc aceste dispozitive sunt incluse în această secţiune.

Fiecare agent este de obicei proiectat pentru a proteja una dintre următoarele:

Un server. Pe lângă monitorizarea sistemului de operare al serverului (OS), agentul poate monitoriza, de asemenea, unele aplicaţii comune;

Un host client (desktop sau laptop). Agenţi proiectaţi pentru a monitoriza utilizatorii unui host de obicei monitorizează sistemul de operare şi aplicaţii comune client, cum ar fi clienti de email şi browsere Web;

O aplicaţie/ serviciu. Unii agenţi monitorizează o aplicaţie specifică, cum ar fi un program de server web sau un program de server de baze de date. Acest tip de agent este de asemenea cunoscut ca un dispozitiv IDPS.

Cele mai multe produse nu dispun de agenţi pentru alte tipuri de host-uri(firewall-uri, routere, switch-uri).

40

5.1.2 Arhitectura de reţea

Arhitectura de reţea este foarte simplă. Deoarece agenţii sunt conectaţi la dispozitivele existente în reţelele organizaţiei, componentele comunică prin intermediul acestor reţele în locul unei reţele de management separată. Comunicaţiile pot fi criptate, prevenind accesul nedorit la informaţii sensibile. Agenţii hardware sunt instalaţi inline, imediat în faţa dispozitivelor protejate. Figura 5.1 prezintă un exemplu de arhitectură.

Figura 5.1 - Arhitectura unui IDPS la nivel de host

41

5.1.3 Locaţia agenţilor

Agenţii IDPS bazaţi pe host sunt cel mai frecvent utilizaţi pentru protecţia unor host-uri critice, cum ar fi servere accesibile publicului şi servere care conţin informaţii sensibile. Agenţii se pot plia pe orice tip de host deoarece sunt disponibili pentru diferite sisteme de operare pentru servere şi desktop / laptop, precum şi pentru aplicaţii specifice serverelor. Unele organizaţii îi folosesc în primul rând pentru a analiza activităţi ce nu pot fi monitorizate prin alte controale de securitate. De exemplu, senzori IDPS bazaţi pe reţea nu pot analiza activitatea în reţele de comunicaţii criptate, dar cei instalaţi pe endpoint-uri pot vedea activitatea necriptată. Organizaţiile ar trebui să ia în considerare următoarele criterii suplimentare atunci când selectează locaţiile de implementare:

Costul pentru a implementa, menţine şi monitoriza agenţii; Sistemele de operare şi aplicaţiile suportate de către agenţi; Importanţa datelor şi serviciilor oferite de host; Capacitatea infrastructurii de a susţine agenţii (ex: bandă de reţea suficientă pentru a

transfera datele de avertizare către serverele centralizate şi a transfera actualizările de software şi politică de la servere la agenţi).

5.1.4 Arhitectura host-ului

Pentru a oferi funcţionalitatea de prevenire a intruziunilor, cei mai mulţi agenţi modifică arhitectura internă a host-urilor pe care sunt instalaţi. Aceast lucru se face de obicei printr-o pană de fixare(„shim”), reprezentată printr-un strat de cod plasat între straturile existente ale codului. Astfel, datele sunt interceptate la un punct în care aceastea ar fi fost în mod normal trecute de la o bucată de cod la alta. În acest mod sunt analizate şi se determină dacă ar trebuie permisă trecerea lor mai departe. Aceasta metodă poate fi folosită pentru mai multe tipuri de resurse:

Traficul de reţea Activitatea sistemului de fişiere Apeluri sistem Activitatea regiştrilor Windows Aplicaţii comune (ex: e-mail, web).

Unii agenţi nu modifică arhitectura internă. În schimb, ele monitorizează activitatea fără pene de fixare sau analizează urme ale activităţii derulate, cum ar fi logurile şi modificările de fişiere. Deşi mai puţin intruzive faţă de gazdă, reducând posibilitatea de a interfera cu operaţiunile normale ale gazdei, aceste metode sunt mai puţin eficiente în detectarea ameninţărilor şi de multe ori nu pot efectua vreo acţiune de prevenţie.

Una dintre cele mai importante decizii este reprezentată de alegerea tipului soluţie IDPS, ori de tip software, instalat pe gazdă, ori de tip appliance. Din perspectiva detecţiei şi a prevenţiei, instalarea de agenti pe gazde, este de preferat, deoarece agenţii au acces direct la caracteristicile gazdelor, de multe ori permiţându-le să efectueze o detecţie şi o prevenţie mai complexă şi exactă. Cu toate acestea, agenţii sunt suportaţi doar de câteva sisteme de operare comune; în cazul în care o gazdă nu utilizează un sistem de operare acceptat, agentul de tip

42

appliance poate fi utilizat. Un alt motiv pentru a utiliza acest tip este legat de performanţă, instalarea unui software consumator de resurse ar putea impacta negativ performanţele gazdei.

5.2 Capabilităţile de securitate

5.2.1 Logare

Logarea de date legată de evenimentele detectate este suportată şi aici. Aceste date pot fi utilizate pentru a confirma validitatea alertelor, pentru a investiga incidentele şi a corela evenimente cu cele din alte surse de logare. Câmpuri de date logate în mod obişnuit includ următoarele:

Timestamp (de obicei data şi ora) ; Evenimentul sau tipul alertei; Evaluare (ex: prioritate, severitate, impact, nivelul de încredere); Detalii specifice evenimentului logat, cum ar fi adresa IP şi portul, nume de fişiere şi

căii, precum şi ID-uri de utilizator; Acţiune de prevenţie întreprinsă (dacă este cazul).

5.2.2 Detecţia

Pentru detecţia celor mai multor tipuri de activităţi rău intenţionate sunt folosite de multe ori o combinaţie între tehnica bazată pe semnături pentru a identifica atacurile cunoscute şi cea bazată pe detectarea anomaliilor împreună cu politici sau seturi de reguli pentru a identifica atacurile necunoscute anterior.

5.2.2.1 Tipuri de evenimente detectate

Tipurile de evenimente detectate variază substanţial în funcţie de tehnicile de detectare folosite. Unele produse oferă mai multe tehnici de detectare, în timp ce altele se concentrează pe câteva sau una. De exemplu, se analizează doar traficul în reţea sau se verifică doar integritatea fişierelor critice. Tehnicile specifice utilizate în mod obişnuit sunt:

Analiza codului. Agenţii pot utiliza una sau mai multe din tehnicile de mai jos pentru a identifica activităţi maliţioase prin analizarea încercărilor de a executa cod. Toate aceste tehnici sunt utile în oprirea malware-urilor şi pot preveni şi alte atacuri, cum ar fi unele care ar permite accesul neautorizat, executarea de cod sau escaladarea unor privilegii.

o Analiza comportamentală a codului. Înainte de a fi rulat în mod normal, codul poate fi executat în primă fază într-un mediu virtual sau într-un sandbox, pentru o analiza a comportamentul său şi pentru o comparare cu profiluri sau reguli cunoscute a fi rău intenţionate sau nu. De exemplu, atunci când o bucată

43

de cod este executată, s-ar putea încerca obţinerea unor privilegii la nivel de administrator sau suprascrie un executabil de sistem;

o Detecţia buffer overflow. Încercările de a inunda bufferele sistemului pot fi detectate prin căutarea caracteristicilor specifice, cum ar fi anumite secvenţe de instrucţiuni ce încearcă să acceseze porţiuni de memorie, altele decât cele alocate pentru procesul respectiv;

o Monitorizarea apelurilor sistem. Agentul ştie ce aplicaţii şi procese ar trebui să utilizeze apelurile sistem şi ce alte acţiuni le este permis. De exemplu, un agent poate recunoaşte un proces care încearcă să intercepteze ce se tastează, cum ar fi un keylogger. Un alt exemplu este un agent ce limitează încărcarea obiectelor de tip COM( Component Object Model), permiţând unei aplicaţii PDA, dar nu şi altor aplicaţii, să acceseze agenda unui client de email. Poate fi restricţionată şi încărcarea unor anume drivere, prevenind astfel instalarea unor rootkit-uri şi a altor atacuri;

o Liste cu aplicaţii şi librării. Un agent poate monitoriza fiecare aplicaţie şi librărie (ex: DLL – librărie dinamică de legătură), pe care un utilizator sau un proces încearcă să le încarce şi compară aceste informaţii cu listele de aplicaţii autorizate şi neautorizate. Acest lucru poate fi folosit nu numai pentru a restricţiona utilizarea unor aplicaţii şi biblioteci, dar şi pentru utilizarea unor anume versiuni ale acestora.

Analiza traficului de reţea. Acest lucru este de multe ori similar cu ceea ce un IDPS de nivel reţea face, putând analiza atât traficul de reţea cu fir şi fără fir. În plus faţă de analiza protocoalelor specifice nivelului reţea, transport sau aplicaţie, pot fi incluse procesări speciale pentru aplicaţii comune, cum ar fi clienţi de email. Analiza traficului permite agentului să extragă fişiere trimise de aplicaţii, ce pot fi apoi verificate contra programelor malware;

Filtrarea traficului de reţea. Agenţii includ de multe ori un firewall tipic hostului, ce poate restricţiona traficul de intrare şi de ieşire pentru fiecare aplicaţie din sistem, prevenind accesul neautorizat şi încălcări ale politici de utilizare (ex: utilizarea de servicii externe nepotrivite). Unele dintre aceste firewall-uri pot genera şi folosi o listă de host-uri cu care gazda ar trebui să comunice în cadrul organizaţiei;

Monitorizarea sistemului de fişiere. Poate fi efectuată folosind mai multe tehnici, inclusiv cele enumerate mai jos. Administratorii ar trebui să fie conştienţi de faptul că unele produse îşi bazează monitorizarea pe nume de fişiere, aşa că, dacă utilizatorii sau atacatori modifică numele fişierelor, aceste tehnici ar deveni ineficiente;

o Verificarea integrităţii fişierelor. Acest lucru implică generarea periodică a unui digest sau a unei alte sume criptografice pentru fişiere critice, comparea cu valori de referinţă şi identificarea diferenţelor. Verificarea integrităţii fişierelor poate stabili doar faptul că un fişier a fost deja modificat, cum ar fi înlocuirea unui sistem binar cu un cal troian sau un rootkit;

44

o Verificarea atributelor fişierelor. Implică verificarea periodică a atributelor fişierelor importante, cum ar fi dreptul de proprietate şi permisiuni, pentru modificări. Ca şi în cazul integrităţii fişierelor, poate determină schimbarea doar după ce aceasta a avut loc;

o Încercările de acces la fişiere. Un agent cu o pană de fixare în sistem de fişiere poate monitoriza toate încercările de a acces la fişiere critice( ex: fişierele binare de sistem) şi opri încercările care sunt suspecte. Agentul are un set de politici privind accesul, astfel încât se compară aceste politici cu caracteristicile încercării curente, ce utilizator sau aplicaţie încearcă să acceseze fiecare fişier, ce tip de acces a fost solicitat (citire, scriere, executare)8. Acest lucru ar putea fi folosit pentru a preveni instalarea anumitor forme de malware, cum ar fi rootkit-urile şi caii troieni , sau a mai multor alte tipuri de activităţi rău intenţionate care implică accesul la fişier, modificarea, înlocuirea sau ştergerea.

Analiza logurilor. Se pot monitoriza şi analiza logurile sistemelor de operare şi a le aplicaţiilor pentru a identifica activităţi malware9. Aceste loguri pot conţine informaţii despre evenimentele de sistem, ce acţiuni operaţionale sunt efectuate de componentele sistemului de operare (ex: oprirea sistemului, începerea unui serviciu); înregistrările de audit conţin informaţii despre evenimente de securitate, cum ar fi încercările reuşite şi nereuşite de autentificare şi modificările aduse politicilor de securitate; evenimentele ce ţin de aplicaţii: acţiunile operaţionale semnificative efectuate( pornirea şi oprirea) , nefuncţionări, precum şi schimbări majore în configuraţie;

Monitorizarea configuraţiei reţelei. Există posibilitatea monitorizării configuraţiei curente a reţelei şi detectarea modificărilor. De obicei toate interfeţele de reţea de pe gazdă sunt monitorizate, prin cablu, fără fir, din VPN-uri şi conectate la modem. Exemple de modificări semnificative de configurare de reţea sunt plasarea interfeţei în mod promiscu, folosirea de porturi TCP / UDP suplimentare pe gazdă sau utilizarea unor protocoale de reţea suplimentare, cum ar fi protocoalele non-IP. Aceste modificări ar putea indica faptul că gazdă a fost deja compromisă şi este configurată pentru a fi utilizată în atacuri viitoare sau pentru transfer de date.

Deoarece aceste IDPS-uri au adesea cunoştinte extinse despre caracteristicile şi configuraţiile gazdelor, poate determina de multe ori dacă un atac împotriva gazdei va reuşi dacă nu este oprit. Agenţi pot folosi aceste cunostinte pentru a selecta acţiunile de prevenire şi de a atribui priorităţi adecvate alertelelor.

8 Pe sistemele Windows, multe setării de configuraţie constă într-un set special de fişiere numie registre.Unii agenţi au nişte pene introduse în aceşti regiştrii ce restricţionează accesul la porţiuni critice ale acestora, în special cele folosite în mod frecvent de malware-uri.9 Unele produse efectuează activităţi ce ţin doar de analiza şi managementul logurilor.Deşi acestea sunt referite a fi IPDS-uri bazate pe host, majoritatea sunt de fapt produse de tip SIEM(security information and event management).

45

5.2.2.2 Precizia detecţiei

Ca orice alte tehnologii, şi acest tip cauzează de multe ori falsuri pozitive şi negative. Cu toate acestea, precizia de detecţie constituie o problemă mai mare în acest caz deoarece multe din posibilele tehnici de detectare, cum ar fi analiza logurilor şi monitorizarea sistemului de fişiere nu au cunoştinţe legate de contextul sub care au avut loc evenimentele detectate. De exemplu, o gazdă poate fi repornită, o nouă aplicaţie poate fi instalată sau un sistem de fişiere poate fi înlocuit. Aceste acţiuni ar putea fi realizate prin activităţi rău intenţionate sau ar putea fi parte a funcţionării şi intreţinerii normale a gazdei. Evenimentele în sine sunt detectate corect, dar natura lor, benigne sau maliţioase, nu poate fi întotdeauna determinată fără un context suplimentar. Unele produse, în special cele destinate desktop-urilor / laptop -urilor, cer utilizatorilor furnizarea contextului, dacă o aplicaţie este actualizată sau nu de către utilizator. Dacă acesta nu răspunde la solicitare într-o anumită perioadă de timp (de obicei câteva minute), agentul alege o acţiune implicită (permitere / refuzare).

Sistemele care utilizează combinaţii de mai multe tehnici de detectare ar trebui să fie, în general, capabile de a realiza o detecţie mai precisă decât produsele ce utilizează una sau câteva tehnici. Deoarece fiecare tehnică poate monitoriza diferite aspecte ale unei gazde, folosirea mai multor tehnici permite agenţilor colectarea mai multor informaţii privind activităţile ce au loc. Acest lucru oferă o imagine mai completă a evenimentelor, şi poate oferi, de asemenea, contextul suplimentar care poate fi de ajutor în evaluarea intenţiei anumitor evenimente.

5.2.2.3 Tuning şi Personalizare

Ca şi în cazul celorlalte sisteme, este necesar tuning-ul şi o personalizare considerabilă. De exemplu, multe se bazează pe observarea activităţii gazdei şi dezvoltarea unor linii de bază sau profiluri de comportament aşteptat. Altele trebuie să fie configurate cu politici detaliate ce definesc exact comportamentul fiecărei aplicaţii. De indată ce intervin schimbări în mediul gazdă, administratorii trebuie să se asigure că politicile sunt actualizate pentru a lua aceste modificări în considerare. În general, nu este recomandată legarea automată cu sistemele de management al schimbărilor, dar administratorii pot revizui înregistrările de gestionare a schimbărilor regulat şi ajusta configuraţia gazdei şi politica de informare din cadrul sistemului pentru a preveni alarmele false.

Politicile pot fi stabilite per-gazdă sau pentru grupuri de gazde, fapt ce oferă flexibilitate. Se poate permite configurarea mai multor politici pe o gazdă pentru mai multe medii; acest lucru este cel mai util pentru gazde care funcţionează în mai multe medii, cum ar fi un laptop folosit atât în cadrul unei organizaţii cât şi din locaţii externe. Sunt folosite şi liste albe şi negre pentru host-uri ( ex: adresele IP ale altor gazde cu care o gazdă ar putea comunica), aplicaţii, porturi, nume de fişiere şi alte caracteristici ale gazdei. De fapt, unele produse actualizează automat agenţi cu cele mai recente informaţii legate de listele albe şi neagre, pe baza rapoartelor de la alţi agenţi ce au detectat o nouă activitate malware. O altă trăsătură comună este personalizarea fiecărei alerte, cum ar fi specificarea opţiuni de răspuns ce ar trebui luată în cazul alertei respective.

Complexitatea capabilităţilor bazate pe semnături variază foarte mult în funcţie de tehnicile de detectare folosite de fiecare produs.

46

5.2.2.4 Limitări tehnologice

Şi în cadrul acestui tip regăsim unele limitări importante. Unele dintre aceste limitări sunt descrise în Secţiunea 4.3.3.4. Alte limitări importante sunt:

Întârzieri în generarea alertelor. Deşi agenţii generează alerte în timp real pentru cele mai multe tehnici de detectare, unele tehnici sunt utilizate periodic pentru a identifica evenimentele care au avut loc deja. Astfel de tehnici pot fi aplicate numai pe oră sau chiar numai câteva ori pe zi, provocând întârzieri semnificative în identificarea unor evenimente;

Întârzieri în centralizarea rapoartelor. Multe IDPS-uri la nivel de host transmit datele de alertă către serverele de management în mod periodic, nu într-un mod real. Datele de alertă sunt de obicei transferate în loturi la fiecare 15 sau 60 de minute pentru a reduce overhead-ul componentelor şi a reţelei. Acest lucru poate provoca întârzieri în iniţierea acţiunilor de răspuns, mărind astfel impactul incidentelor care se răspândesc rapid( ex: infestări malware);

Utilizare resurselor gazdei. Spre deosebire de alte tehnologii, aceasta implică agenţi care rulează pe gazdele monitorizate. Aceşti agenţi pot consuma resurse considerabile ale gazdei, resurse ce includ memoria internă, procesorul şi discul. Operaţiunile agenţilor, în special acele pene, pot provoca încetiniri în fluxul operaţiunilor. Testarea şi evaluarea resurselor este recomandată a fi realizată înainte de o posibilă instalare a unui IDPS;

Conflicte cu controalele de securitate existente. Instalarea unui agent poate provoca dezactivarea automată a controalelor de securitate existente pe gazdă( firewall-uri personale), în cazul în care aceste controale sunt percepute ca o duplicare a funcţionalităţilor oferite de agent. Instalarea poate provoca conflicte şi cu alte controale de securitate, în special cu cele care folosesc penele pentru a intercepta activitatea gazdei (firewall-uri personale, clienţi VPN). Pentru a identifica eventualele conflicte implementatorii ar trebui să testeze întâi agenţii pe gazde pe care se execută acele controale de securitate;

Repornirea gazdelor. În cazul upgrade-urilor de tip software în cazul agenţilor, precum şi în cazul câtorva modificări de configurare, agentul poate necesita repornirea gazdelor monitorizate. Ca şi în cazul altor probleme menţionate anterior, implementatorii ar trebui să efectueze teste extinse înainte de selectarea produselor şi să ia în considerare impactul pe care repornirea ar putea să o aibă asupra eficacităţii agenţilor (ex: agenţii vor fi în imposibilitatea de a detecta cele mai recente ameninţări deoarece host-uri importante nu au putut fi repornite) .

47

5.2.3 Prevenţia

Sunt oferite diverse capacităţi de prevenire a intruziunilor. Deoarece capacităţile variază în funcţie de tehnicile de detectare folosite de fiecare produs, următoarele elemente descriu aceste capabilităţi de prevenţie în funcţie de tehnica de detectare folosită:

Analiza codului. Tehnicile de analiză de cod pot preveni executarea codului de către aplicaţii malware sau neautorizate. Pot fi oprite, de asemenea, aplicaţii de reţea ce invocă shell-uri, ce ar putea fi folosite pentru a efectua anumite tipuri de atacuri. Dacă este configurată şi reglată bine, analiză de cod pot fi foarte eficientă, în special în oprirea atacurilor necunoscute anterior;

Analiza traficului de reţea. Acest lucru poate opri traficul de reţea de intrare în a fi prelucrat de către gazdă şi traficul de reţea de ieşire să părăsească gazda. Acest lucru ar putea fi făcut pentru a opri atacurile specifice nivelelor reţea /internet, transport, sau aplicaţie (şi, în unele cazuri, atacuri ce includ protocoalele speficice reţelei wireless) sau pentru a opri utilizarea de aplicaţii şi protocoale neautorizate. Analiza poate identifica fişiere malware ce sunt descărcate sau transferate şi preveni aceste fişiere în a fi introduse în mediul gazdei. Traficul de reţea ar putea fi dropat sau respins, iar firewall-ul personal al gazdei (care ar putea fi inclus în agent) ar putea fi reconfigurat să evite traficul suplimentar legat de cel suspect. Analiza traficului de reţea este eficientă în stoparea a multor atacuri cunoscute şi necunoscute anterior;

Filtrarea traficului de reţea. Funcţionând ca un firewall la nivel de host, poate opri accesul neautorizat şi încălcările politicii de utilizare (ex: utilizarea de servicii externe nepotrivite). Acesta este eficace numai împotriva opririi activităţilor ce sunt identificabile prin adresa IP, portul TCP / UDP sau tipul şi codul în cazul protocolului ICMP;

Monitorizarea sistemului de fişiere. Acest lucru poate preveni fişierele în a fi accesate, modificate, înlocuite sau şterse, fapt ce ar putea opri instalarea unui malware,cal troian şi rootkit, precum şi alte atacuri ce implică accesul neautorizat la fişiere. Aceasta tehnică poate oferi un strat suplimentar de control al accesului pentru a suplimenta tehnologiile de control de acces existente pe gazdă.

Celelalte tehnici de detectare, analiza logurilor, monitorizarea configuraţiei reţelei, verificarea integrităţii fişierelor şi a atributelor, în general, nu sprijină acţiunile de prevenire, deoarece acestea identifică evenimentele după ce au avut loc.

5.2.4 Alte capabilităţi

Unele IDPS-uri de acest tip oferă capabilităţi non-IDPS, cum ar fi software antivirus, filtrarea spam-ului şi a conţinutului web sau de email. Exemple de aceste capacităţi sunt după cum urmează:

48

Restricţii asupra mediilor de stocare detaşabile. Se pot impune restricţii cu privire la utilizarea mediilor de stocare amovibile, bazate pe USB (stick-uri flash) sau tradiţionale ( CD, discheta). Acest lucru poate preveni transferul unor malware-uri sau fişiere, şi poate opri copierea unor fişiere sensibile;

Monitorizarea dispozitivelor audiovizualue. Căteva produse pot detecta activarea sau uzul unor dispozitive audiovizuale( microfoane, camere video sau telefoane bazate pe IP). Acest lucru ar putea indica compromiterea unei gazde de către un atacator;

Întărirea gazdei. De exemplu, în cazul în care o aplicaţie este reconfigurată, provocând dezactivarea unei funcţii de securitate, sistemul ar putea detecta acest lucru şi reactiva apoi aceea funcţie;

Monitorizarea stării proceselor. Unele produse monitorizează starea proceselor sau a serviciilor ce rulează, şi în cazul în care constată oprirea unuia, este repornit automat. Poate fi monitorizate, de asemenea, starea unor programe de securitate( software-ul antivirus);

Curăţarea traficului de reţea. Unii agenţi, în special cei de tip appliance, pot igieniza traficul de reţea pe care îl monitorizează. De exemplu, acesta ar putea acţiona ca un proxy şi reconstrui fiecare cerere şi răspuns ce este direcţionat prin ea. Acest lucru poate fi eficace la neutralizarea anumitor activităţi neobişnuite, în special în header-ul pachetului şi al protocoalelor aplicaţie. Igienizare poate împiedica atacurile de recunoaştere lansate asupra host-urilor sau poate scădea cantitatea de informaţii legată de host care poate fi achiziţionată prin această metodă. Exemplele includ ascunderea „amprentelor” sistemelor de operare ale servelor şi a mesajelor de eroare de aplicaţie. Este posibilă prevenţia afişării de informaţii sensibile, cum ar fi numere de securitate socială şi numere de card de credit, pe pagini web.

5.3 Management

5.3.1 Implementare

Odată ce un produs a fost selectat, administratorii trebuie să proiecteze o arhitectură, să efectueze testarea componentelor, să le asigure şi apoi să le implementeze. Următoarele elemente aduc completări la materialul prezentat în secţiunea 2.3.1:

Testarea componentelor şi amplasarea. După ce componentele au fost evaluate într-un mediu de testare, organizaţiile ar trebui să le pună în aplicare doar pe câteva host-uri din mediul de productie. Acest lucru permite administratorilor să efectueze activităţi de tuning şi personalizare pe host-uri în curs de pregătire pentru o implementare mai mare. Caracteristicile de prevenire trebuie să fie dezactivate în tot acest timp până la implementarea în masă până când agenţii au fost suficient setaţi şi personalizaţi;

49

Securizarea componentelor. Dacă serverele de management sau consolele trebuie să se autentifice la fiecare agent pentru a-i gestiona sau colecta datele, organizaţiile trebuie să se asigure că mecanismele de autentificare pot fi gestionate şi asigurate în mod corespunzător. De exemplu, în cazul în care este nevoie de parole, există probleme de securitate în cazul utilizării unei singure parole pentru toţii agenţii; în cazul în care se foloseşte o parolă separată pentru fiecare agent, parolele pot fi dificil de urmărit şi menţinut în cazul a sute sau mii de agenţi. În cazul în care cheile criptografice sunt folosite pentru autentificare, managementul cheiilor poate prezenta provocări în emiterea şi distribuirea lor.

5.3.2 Operare

Acest tip de IDPS ar trebui exploatat în conformitate cu recomandările prezentate în secţiunea 3.3.2. Singura excepţie este în actualizarea agenţilor. Unii agenţi pot verifica periodic serverul de management pentru actualizări, preluând şi instalând apoi automat anumite actualizări, dacă sunt disponibile. Alţi agenţi nu pot face acest lucru, fapt ce necesită ca un administrator să verifice manual transferul, instalarea şi aplicarea actualizărilor. În multe cazuri, capacitatea de update a unui agent este legată de tipul de sistem de operare pe care este implementat.

50

6. Soluţii profesionale IDPS

6.1 Alegerea IDPS-ului

Având în vedere oferta extrem de bogată existentă pe piaţă, alegerea echipamentului adecvat pentru sporirea securităţii nu este o activitate simplă. Trebuie analizaţi o multitudine de factori, identificate nevoile companiei, ce tipuri de ameninţări sunt relevante, ce arii sunt critice, dimensiunea organizaţiei, cantitatea de trafic generată, personalul IT specializat, bugetul, etc.

În primul rând trebuie stabilită direcţia principalăa companiei, în ce domeniu activează pentru a stabilifactorul de risc şi de ce nivel de protecţie este nevoie. În cazul unei instituţii militare factorul de risc estemaxim,necesitând astfel o securitatea maximă asiguratăde diverse echipamente specializate. În cazul unei instituţii educaţionale sau fundaţii de ajutorare, factorul de risc este scăzutşi atuncitrebuie o realizată o apărare mai mult împotriva uneltelor automate ce activează pe internet, un atacatorspecializat ar fi puţin probabil să încerce să pătrundă în reţea.

Software sau Hardware?

Toate IDPS-urile au o parte software, fie ele de tip hardware( appliance) sau software. Diferenţa între un hardware IDPS şisoftware IDPS este felul cum este comercializat. Un software este o aplicaţie ce poate fi instalată pe orice sistem ce respectă anumite cerinţe tehnice(CPU, memorie RAM, etc) şi are un sistem deoperare suportat de aplicaţie(Windows, Linux etc). Acestă soluţie este mai ieftină decât un hardware IDPS dinmai multe motive, cel mai evident este însăşi faptul că responsabilitatea hardware-ului şi a sistemuluide operare folosit cade în seama utilizatorului. Pot apărea diverse erori de configuraţie,incompatibilităţi cu hardware-ul folosit sau cu sistemul de operare şi de aceea instalarea necesită decele mai multe ori personal calificat. Hardware-ul IDPS este un echipament hardware robust, construit special pentru acestă funcţie,cu un sistem de operare de cele mai multe ori proprietar(de cele mai multe ori se porneşte de la un Linux ce este apoi modificat şi brand-uit) pe care rulează un software de IDPS special creat pentru hardware-ul respectiv. Acest tipse mai numeşte şi appliance. Avantajul constă într-un echipament robust, rezistent,caracterizat de performanţe ridicate unde suportul de la producător este pentru tot echipamentul şi nu pe componente, separate hardware şi software. Este privit de utilizator ca un black box,o cutie închisă, cu o anumită funcţionalitate şi care se poate configura în diferite moduri, fără a interfera cu hardware-ul sau software-ul de pe echipament. Estemai uşor de instalat pentru că nu necesită personal extrem de bine instruit pentru a obţine perfomanţe decente, dar este şi mult mai scump.În funcţie de cerinţe, personalul IT angajat, echipamentele ce trebuie protejate, de funcţionalităţiadiţionale şi de buget se dispune, se va alege între un IDPS hardware sau software.IDPS-urile hardware sunt de obicei mai bune şi performante decât cele software prin simplul fapt că sunt echipamente dedicate exclusiv acestui lucru.

51

6.2 Cerinţe pentru prevenirea eficientă a intruziunilor

• Funcţionare inline. Prevenirea eficinentă a intruziunilor este condiţionată de acest tip de funcţionare. Regăsim şi IDS-urile active, care pot comunica cuechipamentele de reţea şi pot introduce intrări în ACL-uri( access lists) dar acestea pot doar bloca total, dupăIP, întreaga comunicaţie. Alte IDS-uri pot încerca să termine forţat o sesiune TCP prin injectarea pachetelor TCP reset în reţea, dar aceasta metoda nu este deloc eficientă şi este valabilă doar pentru acest protocol;

• Fiabilitate şi disponibilitate. Echipamentul trebuie să fie fiabil, să nu se defecteze uşor. Orice oprire sau defectare înseamnă o posibilă oprire a activităţii în reţea. Atunci când dispozitivul îşiface update-urile cu noile definiţii este necesar ca acesta să nu trebuiască să fie restartat pentru a leactiva, acest lucru însemnând oprirea activităţii pe perioada de restart;

• Uptime-ul reţelei. Acesta trebuie să poată să lase traficul să treacă prin el şi în caz că pierde alimentarea cu energie. Astfel o eventuală defecţiune a sursei de curent înseamnă osecuritate scăzută dar nu şi oprirea activităţii. Bineînţeles, acest aspect trebuie să poate ficontrolat în funcţie de comportamentul dorit, în unele cazuri rare dorindu-se oprirea activităţiidecât continuarea într-un mediu nesigur;

• Întârzieri mici. Este de dorit ca impactul asupra vitezei reţelei să fie cât mai redus cuputinţă. Echipamentele de reţea oricât de performante ar fi adaugă întârzieri. Depinzând denivelul la care funcţionează echipamentul şi de rolul lui în reţea, întârzierile pot fi mai mari saumai mici. Un IDPS performant trebuie să introducă întârzieri în reţea cu puţin peste un switch de nivel 2/nivel 3 şi sub un echipament de nivel 4 obişnuit cum ar fi un firewall sau load-balancer;

• Performanţă ridicată. Vor fi îndeplinite specificaţiile din fişa tehnică cu toate semnăturileactive şi în condiţii real-life, pentru a fi siguri că următoarele semnături ce vor veni ulterior nuvor afecta performanţa reţelei prin suprasolicitarea echipamentului;

• Încrederea în semnături. Update-urile la semnături este de preferat să se facă în mod automat şi fără restartarea echipamentului. De aceea semnăturile trebuie să fie de încredereşi de calitate pentru a nu risca prăbuşirea reţelei din cauza unei semnături instalate în modautomat;

• Posibilitate de reglaj fin(tunning). Anumite semnături pot produce prea multe alerte false şi atuncidăunează reţelei şi opresc aplicaţiile legitime. Acestea ori trebuie oprite sau modificate ori host-urile cu pricina introduse în whitelist-uri pentru a nu mai fi verificate;

• Log-uri eficiente care să permită investigaţii ulterioare – Atunci când un incident grav seîntâmplă, chiar dacă IDPS-ul este blocat, tot trebuie realizată o investigaţie pentru o întelegere mai bună a evenimentelor petrecute.IDPS-ul trebuie să aibă log-urile cât mai clare şi uşor de sortat şi categorisit, iar la incidentele considerate critice să poată să facă captura traficului, să o stocheze, pentru o investigare ulterioară.

52

6.3 Caracteristici cheie al unui IDPS

•Rata de transfer a filtrării( firewall throughput). Principalul atribut pe care toţi producătorii îl trec în foile tehnice aleappliance-urilor pe care le produc este capacitatea de a filtra traficul. Este măsurată în Mb/sec şi poate începe de la valori joase de ordinul 25Mb/s şi până la câteva sute de GB/s. Este de avut în vedere cazul IDPS-urilor inline, unde, de obicei,această capacitate este traficul full-duplex şi nu traficul RX sau TX luatseparat. Un IDPS inline de 25Mb/s de obicei va filtra 12.5Mb/s RX plus 12.5Mb/s TX. Acest atribut este specific filtrării traficului, rata ce caracterizează abilitatea de a analiza traficul în vedereadetectării şi prevenirii intruziunilor este mult mai mică;

•Rata de transfer a prevenţiei intruziunilor(intrusion prevention throughput). Reprezintăcapacitatea de a filtra şi analiza traficul în vedereadetectării şi prevenirii intruziunilor. Este mai mică decât rata filtrării pentru că necesită mai multă putere de calcul, fiind necesară o analiză a protocoale de nivel superior şi capabilităţi de reţinereşi analiză a unor sesiuni întregi, etc;

•Numărul de interfeţe.IDPS-urile au nevoie de cel puţin două interfeţe, una de managementşi una de monitorizare. Cele cu două interfeţe nu pot fi folosite decât ca IDS, nu pot fi folosite inline. Pentru a-l folosiinline este necesară existenţa a cel puţin trei interfeţe, două de monitorizare şi una de administrare. Implementare cu trei interfeţe este setup-ul preferat de majoritatea cumpărătorilor.Dar cu cât dispune de mai multe interfeţe, cu atât mai bine. Se pot realiza senzori virtuali, combinând interfeţele două căte douăşi astfel dintr-un singur IDPS se pot realiza mai multe virtuale;

•Numărul de sesiuni. Reprezintă numărul de sesiuni TCP concurente ce pot fi monitorizate în acelaşitimp. Acesta este de ordinul a zeci şi sute de mii şi char milioane. Depinzând de tipul traficuluimonitorizat trebuie ales un IDPS adecvat. Este strâns legat de prima rată prezentată mai sus; cumpărătorul nu trebuie să îşi facă griji în mod special pentru numărul de sesiuni, acesta alegând IDPS-ul cu o rată de tranfer adecvată reţelei.

Acestea sunt cele mai importante caracteristici de luat în considerare în achiziţionarea unui IDPS. Alte caracteristici cum ar fi temperatura de funcţionare saulimitele de umiditatela care poate funcţiona aparatultrebuie luate în considerare în cazuri speciale când echipamentul trebuie săfuncţioneze în condiţii deosebite.

Din păcate realitatea este că anumite atribute ţin foarte mult de marketing; faptul că un echipament ce are rate de transfer specifice declarate a fi mari nu înseamnă automat că este un echipament bun.Chiar dacă atributele declarate pot fi mai mari decât realitatea, aceste atribute nu spun nimic despre capabilitatea echipamentului de a identifica şi preveniintruziunile.Aceasta capabilitate de a identifica şi preveni intruziunile este de departe cea mai importantă dintre toate şi extrem de greu de verificat. Aceasta depinde de calitatea semnăturilor pe care

53

le oferă producătorul, de calitatea algoritmului folosit pentru identificarea anomaliilor, de cât de bine poate distinge folosirea dubioasă a anumitor protocoale, etc.

Producătorii îşi reglează echipamentele astfel încât să treacă cu brio la testele efectuate cu propriile unelte de testare astfel că folosirea uneltelor oferite de producătorul respectivuluiechipament pentru a-l testa sunt inutile. La fel şi în ceea ce priveşte cele mai folosite unelte de testare terţe cum ar fi Nessus. Appliance-urile au definiţiile bine definite pentru o reuşită sigură în acest caz. Pentru a fi siguri că echipamentul ce urmează a fi achiziţionat oferă securitatea care este dorită, este necesară o testare internă, simulând postura atacatorului şi încercarea anumitorexploatărişi tehnici de evaziune cum ar fi fragmentarea pachetelor, atacuri false, pacheteduplicate, etc.

O multitudine de teste sunt foarte greu de realizat fără un laborator echipat;pentru teste cum arfi generarea unui trafic foarte mare pentru a verifica ratele de filtrare se pot apela la companiispecializate pentru a efectua aceste teste.Există companii cum ar fi 7safe(http://7safe.com), ICSA Labs(http://icsalabs.com) sau NSS Labs(http://nsslabs.com) care verifica IDPS-uri de la diferiţi vendori,testează în condiţii reale pentru îndeplinirea a celor declarate în fişa tehnică a echipamentului, dacă fac faţă la diferite atacuri, tehnici de evaziune, etc. Din păcate rapoartele de actualitate nu sunt gratis, ele necesitând investiţii mari. Cele vechi sunt gratis dar nu sunt inutile, ele furnizând detalii preţioase înceea ce priveşte un anumit brand sau tip de echipament. Dacă un anumit echipament ce acum 2 ani a fostconsiderat foarte bun, probabil că şi ultima versiune va tinde spre acel nivel.

NSS Labs este una dintre cele mai cunoscute companii care efectuează teste şi dă certificăridacă un produs corespunde cu cerinţele exigente ale acestora. Un appliance poate să obţină una din cele trei certificări: NSS Gold, NSS Approved şi NSS Tested. Astfel o trăsătură de luat în considerare în decizia achiziţionării unui IDPS ar fi certificările echipamentului. Dacă acesta are certificări de la firme specializate, de încredere atunci putem fi siguri că acel dispozitiv este unul performant şi de încredere.

6.4 Jucătorii importanţi de pe piaţa.

Cisco, Juniper, Sourcefire, Fortinet, McAfee sunt doar o parte din jucătorii importanţi de pepiaţa IDPS-urilor.

Aceştia crează appliance-uri profesionale, robuste, performante pentru companii de toatemărimile. Toate produsele lor şi nu numai arată extrem de bine pe hârtie dar problema constă încapacitatea lor de a opri atacuri în condiţii reale. Pentru clarificare, ori sunt testate individual ori se apelează la firmespecializate de testare.

Juniper IDP 800, Juniper IDP 200, Cisco IPS 4200 series, Cisco ASA 5500 series, Mcafee M-8000,Fortinet Fortigate series, Sourcefire 3D sunt doar câteva din appliance-urile care au certificarea NSSApproved, semn de recunoaştere al calităţii şi eficienţei.

Mcafee M-8000 a fost primul IDPS de 10Gb care a primit certificarea NSS Approved. Acesta atrecut cu brio toate testele NSS Labs. S-au încercat 622 de exploatări dintr-o gamă diversificată dedomenii, de la sisteme de operare până la aplicaţii, fiind blocate 618(99.4%), o rată mai mult decât excelentă. Au fost încercate şi 214 exploatări server-client, extrem de greu de detectat din cauza faptului că sunt atipice, iar clientul trebuie să iniţializeze sesiunea, dar şi în acest caz s-a comportat peste aşteptări, blocând 211 dintre ele(98.6%).

54

Multe IDPS-uri ştiu să blocheze foarte multe atacuri datorită definiţiilor uşor de scris o data ceatacul devine cunoscut, iar atacatorii încearcă un arsenal întreg de tehnici de evaziune pentru că exploatările vechi să meargă în continuare. Cele mai cunoscute tehnici de evaziune sunt fragmentareapachetelor în bucăţi cât mai mici, trimiterea lor în ordine aleatoare în speranţa căIDPS-ul nu va fi în stare să reconstruiască pachetul, folosirea de encoding-uri diferite în speranţa căacesta nu va şti să le descifreze, etc. M-8000 s-a descurcat excelent neputând fi păcalit prin nici o tehnică cunoscută.

SourceFire este unul din jucătorii importanţi de pe piaţă, iar appliance-urile lor folosesc cel maipopular software IDPS opensource din lume, SNORT. Appliance-urile SourceFire, că şi alte appliance-urihardware ale altor vendori, sunt echipamente hardware robuste şi fiabile, cu surse redundante, harddisk- uri raid şi alte facilitaţi ce fac appliance-urile rezistente la diferite probleme. Software-ul folositeste desigur Snort-ul, cu regulile şi definiţiile oficiale. Soluţia de la SourceFire este un pic mai complexă decât un simplu echipamentcu Snort instalat. Unul din cele mai importante lucruri este consola de management numită Sourcefire Defense Center (DC) sau Sourcefire Virtual Defense Center, unde se pot seta şi coordona celelalte IDPS-uri de la SourceFire. Pe această consola se pot vedea evenimentele în timp real , tuna definiţii şi trimite cătresenzori, etc . Toate IDPS-uri de la SourceFire sunt certificate de către NSS ( Tested)şi ICSA Labs fapt ce atestă calitatea şi eficienţa acestor IDPS-uri.

55

7. SNORT

7.1 Privire de ansamblu

SNORT este cel mai cunoscut şi folosit IDS/IPS OpenSource. A fost create de către Martin Roesch în 1998. În prezent, este dezvoltat şi comercializat de către compania SourceFire.Acesta poate fi instalat şi folosit gratuit, dar pentru acces imediat la regulile certificate este necesară o plată anuală. Totuşi, semnăturile oficiale noi se pot downloada gratis după 30 de zile de la lansare, ceea ce pentru aplicaţiile necritice este rezonabil. Există şi semnături neoficiale, dezvoltate de comunitate, având la bază semnăturile oficiale ale Snort-ului la care s-au adăugat mici îmbunatăţiri, tweak-uri sau chiar semnături şi idei trimise de către utilizatori. Cel mai cunoscut set de astfel de semnături se numeşte „Bleeding Snort”.

De asemenea există o multitudine de alte proiecte care au la baza Snort-ul, cum ar fi:

Snort Bait and Switch, proiect scris şi administrat de Will Metcalf şi care este folosit pentru a redirecta atacurile către un honeyspot sau decoy network;

Snort ClamAV. Reprezintă o variantă de Snort modificat care analizează traficul folosind baza de date a antivirusului opensource Clamav. Proiectul este administrat de Victor Julien.

SNORT este un produs cu tradiţie, cu peste 3 milioane de downloaduri fiind considerat “IDS – de factor standard”.

Snort nu este foarte greu de utilizat, dar există o mulţime de opţiuni în linie de comandă cu care se poate lucra, nefiind întotdeauna evident care dintre ele funcţionează bine împreună.

Există câteva concepte de bază care ar trebui înţelese legate de Snort. Snort poate fi configurat pentru a rula în mai multe moduri:

Modul sniffer, care citeşte pur şi simplu pachetele de pe reţea şi le afişează într-un flux continuu pe consolă( ecran);

Modul logger, în care loghează pachetele pe disc;

Modul de detecţia a intruziunilor în reţea( NIDS) alături de următorul mod, permite cele mai multe şi complexe configurări, permiţând analiza traficului de reţea pentru o comparare cu seturile de reguli definite de utilizator, îndeplinind mai multe acţiuni bazate pe ceea ce se vede;

Modul inline este de fapt modul IPS.

Snort-ul poate activa doar într-unul modurile prezentate mai sus, sau în mai multe simultan, chiar toate.

56

7.1.2 Modulul sniffer

La rulare există multiple posibilităţi de afişare, care pot fi rulate cu ajutorul opţiunilor din sintaxa aferentă liniei de comandă, descrise în tabelul de mai jos:

Opţiune Observaţii-v interactiv, afişarea doar a antetelor TCP/UDP/ICMP

-e Headere nivel legături de date

-d Headere aplicaţie

-a Afişare frame-uri ARP

-c Afişare date de tip char din payload ( nu le afişează în hexa)

-i eth0 Interfaţa pe care ascultă

-d Rulare ca daemon

-q Rulare în mod quiet (nu mai afişează mesajele de început şi summary de la exit)

Tabelul7.1 Opţiuni rulare SNORT ca sniffer

Exemplu de utilizare:

./snort –vd

Astfel instruim Snort-ul pentru afişarea pachetelor de date împreună cu header-urile aferente.

7.1.3 Modulul logger

Pentru a înregistra pe disc pachetele, trebuie specificat directorul de logare după care programul va intra automat în acest modul:

./snort –dev –l ./log

Desigur, acest lucru presupune că există un director numit log în directorul curent. Dacă nu, Snort va ieşi cu un mesaj de eroare. Când se rulează în acest mod, este colectat fiecare pachet ce este văzut şi pus într-o ierarhie de tip director pe baza adresei IP din pachete.

Dacă este specificată doar opţiunea –l, se poate observa că Snort utilizează uneori adresa endpoint-ului ca nume de director în care vor fi puse pachetele; uneori, se foloseşte adresa gazdei.

Pentru a colecta pachetele ce ţin de reţeaua internă aceasta trebuie specificată:

./snort -dev -l ./log -h 192.168.1.0/24

57

Această regulă instruieşte programul să afişeze headerele specifice nivelului legăturii de date şi aplicaţie, precum şi cele TCP / IP în directorul ./log, iar pachetele logate să fie specifice clasei C de IP-uri 192.168.1.0. Toate pachetele ce vor veni vor fi logate în subdirectoare în directorul specificat ce vor avea ca nume adresele remote( non-192.168.1.0)10.

În cazul unei reţele de mare viteză sau pentru o logare a pachetelor mai compactă pentru o analiză ulterioară, este de luat în considerare logarea în mod binar. Acest mod loghează pachetele într-un format tcpdump într-un singur fişier în directorul de logare:

./snort -l ./log –b

Se obervă schimbările ce intervin aici. Nu trebuie specificată o reţea deoarece modul binar concentrează într-un singur fişier, ceea ce elimină necesitatea de a îi spune cum să formateze structura directorulului de ieşire. În plus, nu este nevoie de rularea interactivă sau de specificarea opţiunilor -d sau –e, deoarece în modul binar întregul pachet este logat, nu doar secţiuni din el. Tot ceea ce este de făcut pentru a plasa Snort în modul logger este specificarea directorului de logare .

După ce pachetele au fost logate în binar, acestea pot fi citite cu orice sniffer caresuportă formatul binar tcpdump (ex: tcpdump sau ethereal). Snort poate citi, de asemenea, pachetele prin specificarea opţiunii –r.

Pachetele logate pot fi manipulate în nenumărate moduri prin rularea în modul logger sau NIDS a Snort-ului în conjuncţie cu interfaţă BPF, ce este disponibilăîn linie de comandă. De exemplu, dacă se vrea doar vizualizarea pachetelelor ICMP din fişierul de log, specificaţi pur şi simplu un filtru BPF în linie de comandă:

./snort -dvr packet.log icmp

7.1.4 Modulul NIDS

Un exemplu prin care se activează acest mod pentru a nu înregistra fiecare pachet este:

./snort -dev -l ./log -h 192.168.1.0/24 -c snort.conf

unde snort.conf este numele fişierului de configurare.Astfel vor fi aplicate regulile configurate aici pe fiecare pachet pentru a se decide dacă este necesară acţionarea în vreun fel bazându-se pe seturile de reguli din fişier.Dacă nu este specificat nici un director de ieşire, cel default este /var/log/snort.

O obervaţie ce trebuie menţionată este legată de modul interactiv în acest caz.Pentru o funcţionare îndelungată, este de evitat activarea acestei opţiuni din raţiuni de viteză.Ecranul este un mijloc încet de scriere a datelor, iar pachetele pot fi dropate până sunt afişate pe ecran.

De asemenea nu este necesară înregistrarea header-elor speficice legăturii de date, astfel se poate omite opţiunea –e:

10 În cazul în care sursa şi destinaţia sunt din reţeaua internă, acestea sunt logate într-un director a cărui nume este alcătuit din numărul mai mare de port implicat, iar în cazul unei egalităţi, de adresa sursă.

58

./snort -d -h 192.168.1.0/24 -l ./log -c snort.conf

Astfel se configură Snort-ul pentru a rula în modul de bază NIDS, logând pachetele ce se supun regulilor specificate în snort.conf folosind caractere ASCII sub o structură ierarhică a directorului.

7.1.4.1 Opţiuni de output

Există mai multe moduri disponibile de a configura ieşirea Snort-ului în modul NIDS. Logarea pachetelor şi a alertelor este realizată în mod implicit prin caractere ASCII şi sunt logate în mod full .Mecanismul de alertă full afişează mesajul de alertă împreună cu headerul pachetelor. Există mai multe alte moduri de ieşire a alertelor disponibile în linia de comandă, precum şidouă facilităţi de logare.

Modurile de alertă sunt ceva mai complexe. Există şapte moduri de alerte disponibile în linia de comandă: complet (full), rapid, prin socket-uri, consolă, syslog, cmg sau de nici un fel. Şase din aceste moduri sunt accesate cu opţiunea –A în linie de comandă. Acesteopţiuni sunt:

Opţiune Observaţii

-A fast Modul rapid.Se scrie alerta întru-un format simplu alcătuit din timestamp, mesajul de alertă, IP-uril şi porturile sursă şi destinaţie

-A full Modul complet.Este modul implicit folosit în cazul în care nu este specificat nimic.

-A unsock Sunt trimise alerte către un socket de Unix la care poate asculta alt program

-A none Sunt oprite alertele.

-A console Alertele de tip “fast-style” sunt trimise către consolă( ecran).

-A cmg Sunt generate alerte de tip “cmg style”

Tabelul7.2 – Modurile de alertă accesate cu opţiunea -A

7.1.4.2 Înţelegerea standardului ieşirii

Când Snort generează un mesaj de alertă, acesta va arăta în felul următor:

[**] [116:56:1] (snort_decoder): T/TCP Detected [**]

Primul număr reprezintă GID-ul( Generator ID); specifică user-ului ce componentă a generat alerta. Pentru o listă a acestor valori se poate consulta fişierul etc/generators din sursa Snort. În acest caz evenimentul a fost generat de component decode(116).

59

Al doilea număr este ID-ul Snort( uneori referit ca ID-ul semnăturii).Pentru o listă a SID-urilor de preprocesare se poate vizualiza fişierul etc/gen-msg.map.SID-urile regulilor sunt scrise împreună cu regulile. În acest caz 56 reprezintă un eveniment de tip T / TCP.

Al treilea număr este numărul de revizie.Acest număr este în principiu folosit la scrierea semnăturilor, la fiecare modificare a regulii acest număr ar trebui incrementat.

7.1.4.3 Schimbarea ordinii alertelor

Modul implicit pe care Snort îl foloseşte în aplicarea regulilor pe pachete poate nu fi propice pentru orice instalare. Regulile de pass sunt aplicate primele, apoi cele de drop, urmate de regulile de alertă, şi în ultimul rând regulile de log.

Sunt disponibile mai multe opţiuni ce permit ordinea de acţiune a unei reguli:

--alert-before-pass; forţează aplicarea regulilor de alertă în primul rând --treat-drop-as-alert; cauzează logarea ca alerte a acţiunilor de drop şi reject, precum

şi alte alerte associate.Se permite astfel utilizarea unei politici inline în modul pasiv / IDS. Regulile sdrop nu sunt încărcate.

--process-all-event; instruieşte Snort-ul să proceseze fiecare eveniment asociat unui pachet, întreprinzând acţiunile pe baza ordinii stabilite.Fără specificarea acestei opţiuni (caz implicit), doar evenimentele asociate primei acţiuni din ordinea stabilită sunt procesate.

7.1.5 Modulul Inline

Începând cu versiunea 2.3.0 Snort a înglobat oficial un IPS numit SNORT inline. SNORT inline obţine pachetele de la iptables în loc de libpcap, iar apoi pachetele prinse cu regulile lui SNORT sunt retransmise lui iptables pentru DROP (dropare + logare), REJECT (dropare + logare + anunţare sursă) sau SDROP (dropare fără logare) sau PASS.

Pentru putea folosi SNORT_inline trebuie recompilat iptables, iar SNORT trebuie compilat cu opţiunea –enable-inline. Recompilarea iptables presupune recompilarea kernelului Linux.

Pentru a rula sub acest mod se speficică opţiunea –Qîn momentul lansării în execuţie a programului.

7.2 Configurare

7.2.1 Include

Cuvântul cheieinclude permite ca alte fişiere de configurare să fie incluse în snort.confindicat în linie de comandă. Acesta funcţionează într-un mod asemănător ca cel din limbajul

60

de programare C(#include); citeşte conţinutul fişierului numit şi îl adaugă în locul în care declaraţia apare în fişier.

include <include file path/name>

7.2.2 Variabile

Trei tipuri de variabile pot fi regăsite în Snort: var portvar ipvar11

Următoarele declaraţii reprezintă exemple de folosire a acestor tipuri:

var RULES_PATH rules/portvar MY_PORTS [22,80,1024:1050]

ipvar MY_NET [192.168.1.0/24,10.1.1.0/24]alert tcp any any -> $MY_NET $MY_PORTS (flags:S; msg:"SYN

packet";)include $RULE_PATH/example.rule

7.2.2.1 Variabile IP. Liste IP

IP-urile pot fi specificate individual, într-o lista, sub forma unui bloc CIDR sau sub orice combinaţie între acestea trei. Dacă suportul IPv6 este activ, variabilele IP ar trebui specificate folosind ipvar în locul tipului var.Folosirea lui var pentru variabile IP este încă permisă pentru compatibilitate, dar în viitor nu va mai fi suportată.

IP-urile individuale, listele de IP şi blocurile CIDR pot fi negate cu ‘!’.Următorul exemplu va include IP-ul 1.1.1.1 şi pe cele de la 2.2.2.0 până la 2.2.2.255,

cu excepţia 2.2.2.2 şi 2.2.2.3.

[1.1.1.1,2.2.2.0/24, ![2.2.2.2,2.2.2.3]

Ordinea elementelor listei nu contează. Elementul anypoate fi folosit pentru a include orice IP; expresia “!any” nu este permisă.De asemenea, intervalele IP negate ce sunt mai generale decât intervale IP ce nu sunt negate, nu sunt permise.

Următoarele constituie nişte interval valide de variabile şi liste IP:

ipvar EXAMPLE [1.1.1.1,2.2.2.0/24,![2.2.2.2,2.2.2.3]]alert tcp $EXAMPLE any -> any any (msg:"Example"; sid:1;)

alert tcp [1.0.0.0/8,!1.1.1.0/24] any -> any any (msg:"Example";sid:2;)

11 Acest tip de variabilă este folosită pentru support IPv6.

61

Exemplele ce urmează redau nişte utilizări invalide:

utilizarea lui “!any” :

ipvar EXAMPLE anyalert tcp !$EXAMPLE any -> any any (msg:"Example";sid:3;)alert tcp $EXAMPLE any -> any any (msg:"Example";sid:3;)

contradicţii logice:

ipvar EXAMPLE [1.1.1.1,!1.1.1.1]

negaţii fără sens:

ipvar EXAMPLE [1.1.1.0/24,!1.1.0.0/16]

7.2.2.2 Variabile port. Liste de porturi

Este suportată reprezentarea porturilor sub forma unor intervale.Variabilele, intervalele sau listele pot fi toate negate cu “!”. De asemnea, prin “any” este specificat orice port. Nici aici nu este permisă declaraţia “!any”.Intervalul valid de porturi este de la 0 la 65535.

Listele de porturi trebuie închise între paranteze pătrate, iar intervalele trebuie specificate cu “:” ca în exemplul următor:

[10:50, 888:900]

Variabilele de tip port ar trebui specificate folosind portvar.Utilizarea lui var pentru porturi nu va mai fi suportată pe viitor. Dar pentru compatibilitate, poate fi folosită doar cu condiţia de a adăuga la începutul numelui “PORT_” sau la sfârşit “_PORT”.

Următorul exemplu ilustrează utilizările valide a ambelor variante:

portvar EXAMPLE1 80var EXAMPLE2_PORT [80:90]

var PORT_EXAMPLE2 [1]portvar EXAMPLE3 any

portvar EXAMPLE4 [!70:90]portvar EXAMPLE5 [80,91:95,100:200]

alert tcp any $EXAMPLE1 -> any $EXAMPLE2_PORT (msg:"Example"; sid:1;)

alert tcp any $PORT_EXAMPLE2 -> any any(msg:"Example"; sid:2;)

alert tcp any 90 -> any [100:1000,9999:20000] (msg:"Example"; sid:3;)

62

Utilizări greşite sunt urmărtoarele:

utilizarea lui “!any”:

portvar EXAMPLE5 !anyvar EXAMPLE5 !any

contradicţii logice:

portvar EXAMPLE6 [80,!80]

porturi în afara intervalului permis:

portvar EXAMPLE7 [65536]

declararea incorectă şi utilizarea acesteia ca port:

var EXAMPLE8 80alert tcp any $EXAMPLE8 -> any any (msg:"Example"; sid:4;)

variabilă port utilizată ca IP:

alert tcp $EXAMPLE1 any -> any any (msg:"Example"; sid:5;)

7.2.2.3 Modificatori de variabile

Variabilele prin numele lor pot fi modificate în mai multe feluri. Se poate define o meta-variabilă prin operatoru “$”.Acesta poate fi folosit împreuna cu operatori “?” şi “-“, aşa cum este descris în tabelul următor:

Sintaxa variabilei Descrierevar Se defineşte o meta-variabilă$(var) sau $var Se înlocuieşte cu conţinutul variabilei var$(var:-default) Se înlocuieşte conţinutul variabilei var cu “default” dacă aceasta este nedefinită$(var:?message) Se înlocuieste cu conţinutul variabilei sau se afişează un mesaj de eroare şi se

ieseTabelul 7.3 – Modificatori de variabile

7.3 Preprocesoarele

63

Preprocesoarele au fost introduse în versiunea 1.5. Acestea permit funcţionalităţi extinse. Codul acestora este rulat înainte ca motorul de detecţie să-şi intre în rol, dar după ce pachetul a fost decodat. Pachetul poate fi modificat sau analizat folosind mecanismele implementate. Preprocesoarele sunt încărcate şi configurate folosind cuvântul cheie preprocessor. Acesta se foloseşte astfel:

<name> Preprocessor: <Opţiuni>

Sunt disponibile spre activare şi configurare mai multe tipuri de preprocesoare, în funcţie de problemele pe care le tratează:

deframentarea IP : frag3; reasamblarea TCP : stream5; normalizarea pachetelor; date sensibile; specifice unor diverse protocoale: http, smtp, ftp, ssh ,pop, etc; atacurile de recunoştere: sfPortscan.

7.3.1 Frag3

Preprocesorul frag3 este un modul de defragmentare IP de tip target-based.Este folosit pentru următoarele scopuri:

o execuţie cât mai rapidă fără un management complex al datelor; modelarea target-based a tehnicilor anti-evaziune.

Frag3 foloseşte structurile date de tip sfxhashşi liste înlănţuite pentru managementul intern al datelor, lucru ce permite atingerea unor performanţe predictibile şi deterministice în orice mediu, lucru ce ajută la gestionarea mediilor fragmentate.

Analiza target-based este un concept relativ nou în detectare la nivel reţea a intruziunilor. Ideea de bază este aceea de a modela obiectivele actuale ale reţelei în locul modelării doar a protocoalelor şi căutării de atacuri în cadrul acestora. Când stivele IP sunt scrise pentru diferite sisteme de operare, acestea sunt de obicei implementate de către persoane care citesc RFC-uri care apoi scriu propria interpretare a ceea ce RFC-ul prezintă în cod. Din păcate, există ambiguităţi în definiţiile date de RFC-uri pentru unele din condiţiile de margine ce pot să apară, iar când acest lucru se întâmplă diferite persoane pun în aplicare anumite aspecte ale stivei IP proprii într-un mod diferit. Pentru un IDS aceasta este o problemă mare.

Într-un mediu în care atacatorul poate determina ce stil de defragmentare IP este utilizat de o anumită ţintă, atacatorul poate încerca să fragmenteze pachetele în aşa fel încât ţinta le va pune împreună într-o anumită manieră pe care sistemele pasive ce încearcă să modeleze traficulgazdă trebuie să ghicească în ce fel respectiva gazdă se va ocupă de suprapuneri şi cum le va retransmite. În cazul în care atacatorul are mai multe informaţii despre host-urile ţintă decât IDS, este posibil să treacă de controalele acestuia.De aici a pornit idea acestui tip de analiză.

64

7.3.2 sfPortscan

Acest modul dezvoltat de Sourcefire, este conceput pentru a detecta prima fază a unui atac asupra unei reţele: recunoaşterea.În acestă fază, un atacator determină ce tipuri de protocoale sau servicii sunt folosite de un anumit host. Acesta este momentul tradiţional în care are loc o scanare a porturilor. Această fază presupune că atacatorul nu are nici o informaţie legată de protocoalele sau serviciile suportate de către ţintă, în caz contrar, această etapă nu ar mai fi necesară. Din cauza acestui fapt, cele mai multe cereri trimise de către atacator vor fi negative(ceea ce înseamnă că porturile sunt închise). În natura unor reţele de comunicaţii legitime, răspunsurile negative din partea host-urilor sunt rare, dar şi mai rare sunt apariţiile multiple ale acestora într-un interval scurt de timp. Obiectivul principal al acestei detecţii este de a detecta şi urmări aceste răspunsuri negative.

7.3.3 HTTP Inspect

HTTP Inspect este un decodor generic http pentru aplicaţiile utilizatorului. Având un buffer de date, acesta va decoda acest buffer, va găsi câmpurile http pe care apoi le va normaliza. Inspectează atât cererile client, câtşi răspunsurile server.

Versiunea actuală are în vedere doar prelucrarea fără stări. Acest lucru înseamnă că inspectarea se face pachet cu pachet, existând posibilitatea unei înşelări în cazul în care pachetele nu sunt reasamblate. Aceasta funcţionează bine atunci când există un alt modul ce se ocupă cu reasamblarea, dar există limitări în analiza protocolului. Versiunile viitoare vor aveaun modul de procesare de tip stateful.

Acest modul permite utilizatorului o configuraţie variată. Utilizatorii pot configura serverele http individuale cu o varietate deopţiuni, lucru care ar trebui să permită utilizatorului emularea oricărui tip de server de web. Există două zone deconfigurare: global şi server.

7.3.4 Preprocesorul de date sensibile

Reprezintă un modul Snort ce realizează detecţia şi filtrarea datelor de tip PII( Personally Identifiable Information). Acest date includ numere de carduri de credit, coduri numerice personale şi adrese de email.Este disponibilă o sintaxă de expresii regulate care permit definirea unor pattern-uri proprii.

Dependinţe

Preprocesorul Stream5 trebuie să fie activat pentru ca acest modul să funcţioneze.

Configuraţie

Configuraţia acestui modul este împărţită în două: configurarea preprocesorului şi regulile.

Configurarea modului începe cu:

preprocessor sensitive_data:

65

Opţiune Argument Necesar Implicit Explicaţiialert_threshold < număr> Nu Alert_threshold 25 Preprocesorul va alerta orice combinaţie

PII detectată într-o sesiune.Opţiunea specifică câte trebuie detectate înainte de alertare.Ar trebui setată o valoare mai mare decât cea mai mare valorea individuală din regulile “sd_pattern”

mask_output - Nu Inactiv Acestă opţiune înlocuieşte toţi digiţii în afară de ultimii 4 cu “X”.Acestu lucru este realizat doar asupra numerelor de card de credit, pentru a preveni vizualizarea numerelor necriptate

ssn_file <nume de fişier> nu Inactiv Modulul poate fi updatat cu noi valori de SSN-uri prin furnizarea unui fişier de tip CSV.În mod implicit Snort-ul recunoaşte toate SSN-urile emise până în noiembrie 2009.

Tabelul 7.4 – Opţiunile pentru configurarea preprocesorului de date sensibile

Exemplu:

preprocessor sensitive_data: alert_threshold 25 \mask_output \

ssn_file ssn_groups_Jan10.csv

Configurarea regulilor

Regulile sunt utilizate pentru a specifica ce tip de date( PII) trebuie căutat de către preprocesor. O nouă opţiune este disponibilă o data cu introducerea acestui modul: sd_pattern.

Această opţiune specifică ce tip de date trebuie detectat.Este utilizată următoarea sintaxă:

sd_pattern:<count>, <pattern>;

count = 1 - 255pattern = any string

Opţiune Explicaţie

count Specifică de câte ori un pattern trebuie să regăsit pentru a se genera o alertă.Numărul este urmărit în toate pachetele dintr-o sesiune

pattern

credit_card Face match pe numere de card de credit de 15-16 digiţi.Aceste numere pot avea spaţii, puncte sau nimic între grupuri de digiţi.Astfel sunt acoperite tipurile de carduri Visa, MasterCard, Discover şi American Express.Numerele regăsite sunt verificate folosind algoritmul Luhn.

66

us_social Este specific numerelor sociale de securitate americane de 9 digiţi us_social_nodashes Pattern folosit pentru SSN-uri ce nu au delimitatori( ex: punct).email Folosit pentru email-uri.

Tabelul 7.5 – Opţiunile pentru configurarea sd_pattern

Dacă se doreşte folosirea unui alt pattern decât cele preconstruite, se poate defini unul propriu folosind o sintaxă regex disponibilă, dar destul de limitată.Sunt suportate următoarele caractere şi secvenţe:

Caracter/Secvenţă Utilizare\d potrivire pe orice digit\D potrivire pe orice non-digit\l potrivire pe orice literă\L potrivire pe orice character non-literă\w potrivire pe orice caracter alfanumeric\W potrivire pe orice caracter non-alfanumeric{ num } repetarea unui character sau secvenţe de un număr de ori.? marcarea ca opţional a caracterului sau secvenţei anterioare \\ potrivire pe semnul “\”\{, \} potrivire pe semnele “{“ , “}”\? potivire pe semnul “?”

Tabelul 7.6 – Sintaxa regex suportată

Orice alt carater folosit în patern va fi tratat ad literarum.

Exemplu de de regulă:

alert tcp $HOME_NET $HIGH_PORTS -> $EXTERNAL_NET $SMTP_PORTS (msg:"Credit Card numbers sent over email"; gid:138; sid:1000;

rev:1; sd_pattern:4,credit_card; metadata:service smtp;)

Opţiunea sd_patternnu este compatibilă cu alte opţiuni specifice compoziţiei unei reguli. Utilizarea acesteia împreună cu alte opţiuni va duce la apariţia unui mesaj de eroare. Regulile ce folosesc această opţiune trebuie să seteze valoarea GID-ului la 138.

7.4 Semnături / Reguli

Semnăturile reprezintă o parte esenţială a Snort-ului. Fără acestea detecţia nu ar mai fi posibilă. Acestea reprezintă, în mare parte, sample-uri de trafic maliţios care de îndată ce este identificat, va duce la producereaunei alerte sau întreprinderea unei anume acţiuni. Aceste reguli se gãsesc pe site-ul oficial al Snort-ului. Cele mai actuale definitii nu sunt gratis, dar sunt distribuite gratis la o lună de la lansare. Există şisemnãturi neoficiale, dezvoltate de comunitate, având la baza semnãturile oficiale ale Snort-ului la care s-au adãugat mici îmbunătăţiri.

67

Exista o mare diferenţă de abordare între semnăturile realizate pentru Snort şi semnăturilealtor IDPS-uri concurente. SourceFire încearcã să înţeleagã vulnerabilităţile pentru care apoi să scrie semnătura pentru aceasta, nu pentru exploatarea în sine. Astfel dacã sunt create mai multe variante de exploatări pentru aceiaşi vulnerabilitate, Snort-ul va fi capabil să le blocheze pe toate. Cel mai bunexemplu este viermele Conficker. Acesta a apãrut în21 Noiembrie 2008, la 2 luni dupã ce Microsoft a anunţat vulnerabilitatea MS08-067( remote codeexecution). Prima variantă a virusului putea fi detectată de Snort cu definiţiile din 2006 datorită asemănării cu o vulnerabilitate de atunci cu cea exploatată de Conficker:

August 7, 2006: Microsoft a lansat un buletin de securitate MS06-040 în legãtura cu ovulnerabilitate remote code execution găsită în Microsoft Windows Server Service;

August 9, 2006: Sourcefire a lansat reguli care să protejeze împotriva a toate exploatărilor vulnerabilităţii MS06-040;

Octombrie 23, 2008: Microsoft a lansat un buletin de securitate MS08-067 în legătura cu o vulnerabilitate remote code execution (similară to MS06-040) în Microsoft Windows Server Service;

Octombrie 23, 2008: Sourcefire a lansat un set de reguli care să protejeze împotriva a tuturo exploatărilorvulnerabilităţii MS08-067;

Noiembrie 21, 2008: Viermele Conficker.A este identificat. Regulile Sourcefire publicate atât în August 9, 2006 cât şi în Octombrie 23, 2008 sunt activate de Conficker.A din cauza similarităţii celor 2 vulnerabilităţi;

Noiembrie 29, 2008: Viermele Conficker.B este identificat. Aceasta variantă este corect identificată de semnăturile Snort iniţiale.

Martie 4, 2009: Viermele Conficker.C este identificat. Aceasta variantă este corect identificată de semnăturile Snort iniţiale.

În concluzie abordarea scrierii de definiţii pentru vulnerabilitatea în sine şi nu a exploatării este mult mai eficientă şi asigură protecţie pentru alte eventuale exploatări ale aceleaşi vulnerabilităţi.

Un alt exemplu în care este evidenţiată abordarea orientată pe vulnerabilitate a semnãturiloroficiale este modul cum a fost abordată vulnerabilitatea apăruta în comunicarea RPC cãtre serverul debaze de date ToolTalk. Această vulnerabilitate a apărut în sistemele de operare de la HP, IBM, SCO Group, SGI şi Sun şi permitea unui atacator remote să execute cod cu drepturi de super user.

SourceFire a identificat câmpurile vulnerabile din protocolul RPC, care era vulnerabilitatea şi în ce condiţii se manifesta, apoi a scris o semnătura pentru acest lucru. În continuare este descris acestproces:

68

Analiza pachetului RPC al unei exploatări ce încearcã să speculeze vulnerabilitatea în cauză

Identificarea Protocolului Octeţii 8 - 11 indică un RPC call, astfe avem o cãutare după conţinutul “00 00

00 00” pentru acei octeţi:

content:”|00 00 00 00|”; offset:8; depth:4;

Octeţii 12 -15 indică folosirea versiunii 2 a RPC:

content:”|00 00 00 02|”; offset:12; depth:4;

Octeţii 16 - 19 indică numărul programului RPC. Cel în cauza este “00 01 86 F3”, astfel ne putem duce la acea poziţie şi căuta apariţia acestui program:

content:”|00 01 86 F3|”; offset:16; depth:4;

Peste 2 câmpuri, adicã la 4 octeţi de la poziţia anterioară, indică numãrul procedurii RPC. Este de interes “00 00 00 07”:

content:”|00 00 00 07|”; distance:4; within:4;

Stare comunicaţiei

Vrem să identificăm doar sesiunile stabilite:

flow:to_server,established;

Figura 7.7- Exemplu pachet RPC

69

Câmpurile relevante

Trebuie căutată cantitatea de date de autorizare trimisă pentru a putea sări peste acestea. Este stocată într-un câmp de 4 octeţi. Acesta este citit şi se sare peste câte date sunt în câmpul respectiv:

byte_jump:4,4,relative,align;

Următorul câmp ce trebuie ignorat este câmpul de verificare. Mărimea acestuia este specificată ca şi în cazul de mai sus într-un cămp special.Este citită mărimea şi se sare peste numărul de octeţi specificat:

byte_jump:4,4,relative,align;

După aceşti paşi se ajunge în momentul în care se poate vedea câte date sunt trimise către program.Această informaţie se află în primii 4 octeţi, imediat după sfârşitul câmpului de verificare. Se citeşte dimensiunea datelor transmise către program, iar dacă această dimensiune este prea mare, mai maredecât ar trebui să primească în mod normal programul, poate reprezenta o posibilă încercare de overflow. În acest caz se verifică dacă sunt transmişi mai mult de 128 de octeţi; în cazul că da este generată o alertă.

byte_test:4,>,128,0,relative;

În concluzie, o regulă ce previne orice exploatare a vulnerabilităţii CVE-1999-0003 în cazul ToolTalk, arată în felul următor:

alert tcp $EXTERNAL_NET any -> $HOME_NET any \(msg:”RPC tooltalk TCP overflow attempt”; \

flow:to_server,established; \content:”|00 00 00 02|”; depth:4; offset:12;\content:”|00 01 86 F3|”; depth:4; offset:16; \content:”|00 00 00 07|”; within:4; distance:4; \

byte_jump:4,4,relative,align; \byte_jump:4,4,relative,align; \byte_test:4,>,128,0,relative; \

content:”|00 00 00 00|”; depth:4; offset:8; \reference:bugtraq,122; \reference:cve,1999-0003; \

classtype:misc-attack; sid:1965; rev:8;)

70

7.4.1 Scriererea Regulilor

Regulile sunt împărţite în două secţiuni logice:

1. Antetul: specifică acţiunea, protocolul, adresele IP şi măştile aferente sursă şi destinaţie, precum şi porturile sursă şi destinaţie;

2. Opţiunile: specifică mesajul de alertă precum şi alte informaţii legate de părţile pachetului ce ar trebui inspectate pentru a determina dacă trebuie întreprinsă acţiunea precizată.

7.4.2 Antetul unei reguli

Acţiunea regulii

Este indicat astfel Snort-ului ce trebuie să facă în eventualitatea unui pachet ce îndeplineşte condiţiile impuse. Există 5 acţiuni implicate definite:alertare, logare, permitere, activare şi intrarea în modul dinamic.În plus, dacă este rulat în mod inline, sunt disponibile alte 3 tipuri:dropare, respingere şi blocare fără log.

Nume Acţiunea realizatăalert generarea unei alerte folosind metoda de alertare selectată, urmată de o

logare a pachetuluilog logarea pachetuluipass ignorarea pachetuluiactivate alertare şi activarea unei alte regule dinamicedynamic inactivă până la activarea de către regula mai sus menţiontă, comportându-se

apoi ca o regulă de logarereject blocarea şi logarea pachetului, urmate de trimiterea unui pachet de reset în

cazul protocolului TCP, sau a unui de top port ICMP inaccesibil în cazul UDP drop blocarea şi logarea pachetuluisdrop blocare fără logare a pachetului

Tabelul 7.8 – Tipurile de acţiuni posibile

Pot fi definie tipuri de reguli proprii cărora li se poate asocia unul sau mai multe tipuri de ieşire.Pot fi utilizare acţiunile prezentate mai sus.

Următorul exemplu crează un tip ce va realiza doar o logare de tip tcpdump:

ruletype suspicious{type logoutput log_tcpdump: suspicious.log}

71

Protocoale

Există patru protocoale pe care Snort-ul le analizează pentru comportament suspicios:

TCP UDP ICMP IP

Pe viitor se urmăreşte şi implementarea altora: ARP, IGRP, GRE, OSPF, RIP, IPX, etc.

Adresele IP

Snort-ul nu are nici un mecanism de căutare a host-urilor după adrese IP în fişierul de configurare. Le regăsim în antetul regulilor. Sunt formate dintr-o adresă numeric de tip IP şi un bloc CIDR ce indică masca de reţea ce trebuie folosită în cazul inspectării pachetelor.Pot fi specificate şi sub forma unei liste sau folosind operatorul “any” pentru a defini orice adresă .

Porturile

Numerele de port pot fi specificate în mai multe moduri, prin “any”, definiţii statice sau intervale, folosind orice valoare dorită din intervalul 0 – 65535.

Operatorul direcţie

Se foloseşte pentru a identifica direcţia pachetului pe care regula trebuie aplicată( IP-ul şi portul sursă sunt considerate a fi cele din stânga, iar cele destinaţie, în dreapta operatorului). Este folosit sub două forme: ->, unidirecţional( de la sursă la destinaţie) şi <>, bidirecţional când se iau în considerare spre analiză perechi de adrese IP şi port. Nu poate fi folosit sub forma <-.

7.4.3. Opţiunile unei reguli

Reprezintă inima motorului de detecţie a intruziunilor al Snort-ului, coroborat cu uşurinţa utilizării, puterea şi flexibilitatea acestora.

Toate opţiunile sunt separate una de alta prin “ ; ”.Cuvintele cheie sunt separate de argument folosind “ : ”.

activate tcp !$HOME_NET any -> $HOME_NET 143 (flags:PA; \content:"|E8C0FFFFFF|/bin"; activates:1; \msg:"IMAP buffer overflow!";)dynamic tcp !$HOME_NET any -> $HOME_NET 143 (activated_by:1; count:50;)

72

În continuare sunt prezentate câteva din opţiunile disponibile:

msg: mesajul salvat în loguri şi alerte;

reference:regula include o referinţă externă care detaliază atacul (Exemplu: bugtrack, cve, nessus etc);

alert tcp any any -> any 21 (msg:"IDS287/ftp-wuftp260-venglin-linux"; flags:AP; content:"|31c031db 31c9b046 cd80

31c031db|"; reference:arachnids,IDS287;reference:bugtraq,1387;

reference:cve,CAN-2000-1574;)

gid: folosit pentru a identifica ce parte a Snort-ului generează evenimentul;

sid (signature id): identificator unic pentru regulă; este obligatoriu. Pentru sid există următoarele recomandări:

sid < 100 este rezervat; 100 < sid < 1.000.000 pentru regulile oficiale SourceFire; sid > 1.000.000 pentru regulile create de user.

rev (revision):identificator pentru numărul de revizie al regulii;

alert tcp any any -> any 25 (content:”CMA”; sid:1000001; rev:2;)

classtype: clasifică tipul de atac într-o clasă generică. Acestea sunt definite în classification.config;

alert tcp any any -> any 80 (sid:1000002; msg:”EXPLOIT ntpdx overflow”; dsize: >128; classtype:attempted-admin;

priority:10 );

flags testează flagurile TCP. Se foloseşte: S, F, R, A, P, U, 0(zero – niciun bit setat) sau combinaţii între acestea. Există 3 tipuri de modificatori:

+ testează biţii specificaţi, pot fi şi alţii în plus; ! testează ca biţii specificaţi să nu fie setaţi; * testează dacă oricare dintre biţii specificaţi sunt testaţi;

alert tcp any any -> any any (sid: 1000003; msg:”pachet tcp”; flags:SA+;)

minfrag setează un prag pentru dimensiunea minimă a unui fragment;

TTL: testează valoarea TTL din headerul IP;

73

alert icmp any any -> any any (msg:”PING with TTP 100″;ttl:100; sid: 1000004;)

tos: testează valoarea ToS din headerul IP;

alert icmp any any -> any any (msg:”tos diferit de 1″;tos:!1; sid: 1000005;)

fragbits: testeaza biţii MoreFragments şi Don’t Fragment din headerul IP;

alert icmp any any -> any any (msg:”Pachet cu biţii more fragment şi don’t fragment setaţi”;fragbits:MD+;sid:

1000006;)

id: testează valoarea ID din headerul IP;

dsize: testează dimensiunea încărcăturii pachetului;

Content: caută un pattern în payload-ul pachetului. Caracterele : ; \ “ trebuie precedate de “\”(backslash);

alert tcp any any -> any 111 (sid:1000007; content: “|00 01 86 a5|”; msg: “external mountd access”;)

nocase: valoarea căutată în pachet de ajutorul content este case-insensitive;

offset: setează un offset de la care se începe căutarea valorii opţiunii content;

depth: setează o adâncime în pachet până la care se caută valoarea opţiunii content;

http_client_body: reprezintă un modificator pentru opţiunea content care limitează căutarea în HTTP Body Client Request; preprocesorul Http Inspect trebuie să fie activ;

http_cookie: reprezintă un modificator pentru opţiunea content care limitează căutarea în câmpul HTTP Cookie Header din HTTP Client Request; preprocesorul HttpInspect trebuie să fie activ;

http_header: reprezintă un modificator pentru opţiunea content care limitează căutarea în Headerul HTTP din Client Request;

seq: testează valoarea Sequence No. din headerul TCP;

ack: testează valoarea Acknowledgment din headerul TCP;

74

itype: testează tipul ICMP;

icode: testează codul ICMP.

session: datele utilizatorului sunt extrase din sesiunile TCP şi printate în alerte.

log tcp any any <> any 23 (session:printable;sid:1000008;)

resp: activează un răspuns activ ce închide conexiunile considerate periculoase;

pcre: se foloseşte pcre (perl compatible regular expression) pentru testarea conţinutului unui pachet.

7.4.4 Pragul unei reguli

Se foloseşte pentru a reduce mesajele logate de regulile care se activează extrem de des. Există 3 categorii de praguri:

limit: alertează pentru primele n evenimente într-un interval de timp. Restul evenimentelor sunt ignorate pentru o perioadă de timp;

threshold: alertează la fiecare n evenimente într-o perioadă de timp; ambele: alertează o dată în intervalul de timp, dar doar după n evenimente.

Un threshold se poate include într-o regulă sau se poate defini de sine stătător referindu-se la sid-ul regulii.

8. Sistem pentru prevenirea scurgerilor de date

8.1 Snort – sistem de detectare şi prevenţie a scurgerilor de date

O bună aplicaţie a Snort-ului este prevenirea scurgerilor de datedintr-o instituţie. Snort-ul opreşte traficul în funcţie de anumite reguli. Acestea pot fi scrise în funcţie denecesităţile şi dorinţele fiecăruia. O problemă majorăo reprezintă poziţionarea IDPS-ului în cadrul reţelei pentru aoferi o eficienţă maximă. Pentru a preveni şi nu doar a detecta scurgerea de date este de preferabil opoziţionarea inline. Aceasta prezintă o serie de dezavantaje cum ar fi imposibilitatea decodăriiprotocoalelor care transmit datele criptat:ssh, https, imaps, pop3s, smtps. Oricine poate să acceseze orice aplicaţie care foloseşte protocolul https şi să uploadeze documente fără ca Snort-ul să îl poate detecta.Astfel, pentru o implementare eficientăşi transparentă pentru utilizatori a unei soluţii de prevenirea scurgerilor de date nu este de ajuns un singur echipament dotatcu Snort. În cazul tuturor echipamentelor trebuie blocate toate porturile inutile, iar accesul la portul 80 şi 443 să nuse facă direct, ci printr-un proxy cum ar fi Squid, etc.

75

Avantajele folosirii Snort-ului inline pentru prevenirea scurgerilor de date:

transparenţăfaţă de utilizatori: aceştia nu ştiu de existenta Snort-ului în reţea, nefiind necesare configurări speciale pe staţia de lucru;

implementare rapidă: un singur dispozitiv amplasat în punctul de interes este de ajuns pentru a acoperi toţi utilizatorii.

Dezavantajele folosirii Snort-ului inline pentru prevenirea scurgerilor de date:

imposibilitate inspectării protocoalelor ce folosesc criptarea datelor :https, pop3s, smtps, imaps, ssh vor trece fără a puteafi inspectate;

întârzieri în reţea: pentru a inspecta traficul, o serie de procesări au loc, cum ar fidecodarea şi normalizarea protocolului, inspectarea acestuia după semnături, toate acesteproceduri provocând întârzieri în reţea;

punct sensibil: dacă echipamentul Snort are probleme şi se defectează, întreg traficul va fioprit, un lucru nedorit de atlfel de nimeni.

8.2 Iptables

Pentru a implementa Snort-ul inline eficient la nivel de host este nevoie de configurarea serviciului iptables.

Acesta reprezintă un serviciu furnizat de firewall-ul din cadrul kernel-ului de Linux. Permite administratorului de sistem definirea unor tabele ce conţin lanţuri de reguli pentru tratarea pachetelor de reţea.Fiecare tabelă este asociată unui alt tip de procesare. Pachetele sunt procesate secvenţial, pe măsură ce parcurg lanţurile.O regulă dintr-un lanţ poate provoca un salt către alt lanţ, lucru ce se poate repeta în limita nivelului de îmbricare dorit

Ipptables foloseşte în mod implicit trei tabele :

1. Filter - este responsabilă cu filtrarea pachetelor.Are trei lanţuri predefinite în care se pot declara reguli de politică firewall: Forward : Filtrează pachete către servere protejate de firewall; Input : Filtrează pachetele destinate firewall-ului; Output : Filtrează pachetele expediate de firewall.

2. NAT – este responsabilă cu translatarea adreselor de reţea.

Figura 8.1 - Snort inline

76

3. MANGLE – este responsabilă cu modificarea biţilor QOS din headerul TCP

Are 2 lanţuri predefinite:

Pre-routing: face NAT atunci când adresa destinaţie a pachetului trebuie schimbată; Post-routing: face NAT atunci cand adresă sursă a pachetului trebuie schimbată.

Pentru fiecare regulă firewall creată trebuie specificată tabela şi lanţul de care va aparţine. La această regulă este o singură exceptie: cele mai multe reguli sunt legate de filtrare, astfel iptables presupune că orice lanţ definit fără o tabelă asociată va face parte din tabela filter. Tabela filter este, prin urmare, implicită.

Fiecare regulă firewall inspectează pachetele IP şi apoi încearcă să le identifice ca şi ţinte pentru o anumită operaţie.

Cele mai folosite ţinte sunt:

ACCEPT: iptables opreşte procesarea ulterioară; pachetul este trimis către aplicaţie sau sistem de operare pentru prelucrare;

DROP : iptables opreşte procesarea ulterioară; pachetul este blocat; LOG: informaţiile sunt trimise la daemonul syslog pentru logare; iptables continuă

procesarea pachetului; REJECT: funcţionează ca DROP, dar va trimite un mesaj de eroare la gazda care a a

trimis pachetul cum că pachetul a fost blocat; QUEUE: pachetele sunt în puse în aşteptare pentru o procesare ulterioară de către

modul sau altă aplicaţie externă; DNAT: Rescrie adresa IP destinaţie a pachetului; SNAT: Rescrie adresa IP sursa a pachetului MASQUERADE : Folosit pentru SNAT; în mod implicit adresa IP sursă este aceeaşi

cu cea utilizată de interfaţa firewall-ului

77

Figura 8.2 – Funcţionare Iptables

78

Tabelul 8.3 – Opţiuni configurare Iptables

Configurările necesare pentru ca modulul iptables să trasmită toate pachetele spre procesare către Snort se realizează în felul următor:

iptables -I OUTPUT 1 -p all -j QUEUEiptables -I INPUT 1 -p all -j QUEUE

Figura 8.4 – Funcţionare Iptables & Snort

Parametru Utilizare

-t <tabel> Dacă nu se specifică o tabelă, tabela filter este aleasă în mod implicit

-j <target> Salt la lanţul ţintă specificat în momentul pachet se potriveste cu regula actuală.

-A \ -append adăugarea unei reguli la sfârşitul regulii

-F Stergea tuturor regulilor din tabela selectată

-p <tipul protocolului> Potrivire cu protocoalele: icmp, tcp, udp sau toate(all)

-s <adresă ip> Potrivire cu adresa ip sursă

-d <adresă ip> Potrivire cu adresa ip destinaţie

-i <nume interfeţă> Potrivire cu interfaţa de reţea prin care intră pachetul

-o <nume interfaţă> Potrivire cu interfaţa de reţea prin care iese pachetul

-m –state <stare> Stările pot fi: ESTABLISHED, NEW, RELATED, INVALID

79

Prin aceste comenzi sunt introduse câte o regulă nouă în lanţurile INPUT şi OUTPUT din cadrul tabelei Filter în prima poziţie, reguli ce instruiesc modulul iptables să identifice toate pachetele, indiferent de protocol, ca ţinte QUEUE. Astfel, pachetele sunt dispuse într-o coadă, de unde sunt preluate de Snort pentru procesare. După inspectarea lor de către Snort, acestea le dispune tot într-o coadă, de unde sunt preluate de către modulul iptables, care, în funcţie de etichetarea realizată de Snort( allow / drop /reject) va realiza acţiunea pertinentă pentru fiecare pachet.

Pentru revenirea la funcţionarea normală a acestui model se dau următoarele comenzi ce şterg toate regulile din lanţurile selectate( tabela filter):

iptables -F INPUTiptables -F OUTPUT

Pentru apelarea oricăror comenzi legate de acest modul sunt necesare drepturi de administrator.Lansarea în execuţie

Atât Snort-ul, cât şi plugin-ul sunt lansaţi în execuţie de către un script: snorting.sh. Acesta are trei funcţionalităţi, configurabile prin cele trei opţiuni disponibile:

1. –start. Prin această opţiune este lansate în execuţie Snort-ul. Pe lângă acestea, este configurat şi serviciul Iptables, folosind comenzile prezentate în secţiunea de mai sus pentru lucrul cu Snort.

2. –stop. Cu ajutorul acestei opţiuni modulul Iptables este readus la starea normală de funcţionare.

3. –print <nr>. Cu ajutorul acestei opţiuni pot fi vizualizate ultimele alerte trimise de Snort către server-ul Syslog.

80

8.3 Arhitectura de reţea utilizată

Pentru implementarea şi testarea Snort-ului şi a plugin-ului prezentat în secţiunile următoare s-a folosit arhitectura de mai sus.Snort-ul a fost implementat în modul inline, la nivel de host (PC). Astfel, monitorizează tot traficul de la şi spre host-ul din imagine.Traficul va trece în mod transparent prin filtru fără a fi nevoie de configurări adiţionale pe echipamentele existente în reţea.

Drumul pe care un pachet îl parcuge prin Snort este redat mai jos:

Figura 8.5 - Arhitectura implementată

81

1. Pachetul intră în Decoder cu scopul de a identifica tipul de pachet şi ce protocoale sunt folosite fără însă a decoda şi datele la nivel de aplicaţie. Pachetele cu checksum greşit pot fi oprite;

2. Pachetele fragmentate trebuie asamblate înainte pentru ca regulile viitoare să fie aplicate eficient.Normalizarea pachetelor ajută motorul de căutare al Snort-ului să verifice pachetul mai rapid;

3. După ce au fost decodate, asamblate şi normalizate, pachetele ajung la motorul principal, undesunt verificate după nişte reguli;

4. Alertele generate de pachete se duc în pluginul de output pentru a fi furnizate administratoruluisau aplicaţiilor.

8.4. Metode de detecţie şi prevenţie

În cadrul Snort-ului există două etape în care se poate face prevenţia şi detecţia scurgerilor date:

1. În faza de preprocesare cu ajutorul preprocesorului specific datelor sensibile prezentat în secţiunile anterioare.Avantajul configurării acestui preprocesor este reprezentat de faptul că se evită trecerea pachetelor ce se potrivesc cu regulile preprocesorului prin motorul principal de detecţie al Snortului, scâzăndu-se astfel timpul de procesare precum şi utilizarea resurselor;

2. În cadrul motorului de detecţie;

Detecţie în ambele faze se bazează pe conţinut. Diferenţa majoră între acestea este dată de faptul că în cadrul celei de-a două există mult mai multe opţiuni disponibile pentru configurare şi scrierea regulilor. După cum s-a menţionat şi în prezentarea preprocesorului, opţiunea sd_pattern, punctul central al regulilor specifice acestuia, nu este compatibilă cu nici o altă opţiune.

În ambele cazuri, detecţia se realizează cu ajutorul expresiilor regulate. Pentru regulile generale, acest lucru se configurează cu ajutorul opţiunii pcre( perl compatible regular expressions), o librărie de funcţii ce implementează modele de potrivire folosind aceiaşi sintaxă şi semantică utilizată de Perl 5. Sintaxa utilizată oferă mai multe capabilităţi decât cele oferite de opţiunea sd_pattern.

Date Metodă folosită pentru detecţie Verificare validitate

Sd_pattern12 PCRE12 Sd_pattern PCRE

CNP Regexp Regexp Da Nu

12 Snort

Figura 8.6 - Drumul unui pachet prin Snort

82

Numere carduribancare

Regexp Regexp Da Nu

Email Regexp Regexp Da Da

Tabelul 8.7 – Detecţia şi verificarea datelor sensibile

Date Exemple Regexp

Sd_pattern PCRE

CNP \d{13} /[1-9]{1}[1-9]{2}(0[1-9]|1[0-2])(0[1-9]|[12]\d|3[01])(0[1-9]|[1-4]\d| 5[0-2]|99)\d{4}/

Card bancar( VISA) credit_card13 /4\d{3}(\s|-)?\d{4}(\s|-)?\d{4}(\s|-)?\d{4}/

Email Email2 /[a-zA-Z0-9_\.]+@[a-zA-Z]+\.[a-zA-Z]+/

Tabelul 8.8 – Expresii regulate folosite

8.5.Filtrarea protocolului http şi https

Majoritatea scurgerilor de date sunt accidentale şi au loc prin intermediul reţelelor de de socializare sau serviciilor de email gratis. Pentru o securitate sporită, accesul la acesteaar trebuie restricţionat. Blocarea acestora nu este extrem de greu de realizat. Atunci când se realizează o cerere http, host-ul şi URL-ul accesat este trimis de către browser server-ului printr-o cerere GET.

13 Predefinit

Figura 8.9 - Protocolul HTTP

83

GET /index.php HTTP/1.1Host: www.facebook.comUser-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110422 Ubuntu/10.04 (lucid) Firefox/3.6.17Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-us,en;q=0.5Accept-Encoding: gzip,deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7Keep-Alive: 115Connection: keep-alive

HTTP/1.1 200 OKCache-Control: private, no-cache, no-store, must-revalidateExpires: Sat, 01 Jan 2000 00:00:00 GMTP3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p"Pragma: no-cachepath=/; domain=.facebook.com; httponlyContent-Encoding: gzipContent-Type: text/html; charset=utf-8X-FB-Server: 10.146.68.118X-Cnection: closeTransfer-Encoding: chunkedDate: Mon, May 2013 19:30:45 GM

Pentru a bloca accesul în cauză site-ul respectiv este de ajuns să se blocheze Client Request-ul ce conţine cererea GET către site-ul în cauză. Pentru a nu filtra toate pachetele şi a evita întârzierile inutile, se va verifica doar antetul pachetelor http ce pleacă de la Client către portul 80 al server-ului web.

drop tcp any any -> any 80 (msg:"Facebook not allowed";content:"Host: www.facebook.com"; http_header;classtype:policy-violation; sid:1000007; rev:1;)

Este posibilă o filtrare după conţinut conform modelelor prezentate mai jos:

drop tcp my_ip any -> any $HTTP_PORTS (pcre:"/4\d{3}(\s|-)?\d{4}(\s|-)?\d{4}(\s|-)?\d{4}/"; msg:"VISA card number

detected over http "; classtype:policy-violation; sid:9000000;rev:1;)

drop tcp my_ip any -> any $HTTP_PORTS (pcre:"/5\d{3}(\s|-)?\d{4}(\s|-)?\d{4}(\s|-)?\d{4}/";msg:"MasterCard number

detected over http"; classtype:policy-violation; sid:9000001;rev:1;)

alert tcp my_ip any -> any $HTTP_PORTS (pcre:"/[a-zA-Z0-9_\.]+@[a-zA-Z]+\.[a-zA-Z]+/";msg:"Email address detected over

http"; classtype:policy-violation; sid:9000004; rev:1;)drop tcp my_ip any -> any $HTTP_PORTS (pcre:"/[1-9]{1}[1-

9]{2}(0[1-9]|1[0-2])(0[1-9]|[12]\d|3[01])(0[1-9]|[1-4]\d| 5[0-2]|99)\d{4}/";msg:"CNP detected over http"; classtype:policy-

violation; sid:9000006;rev:1;)

În cazul portului Https, care funcţionează cu encripţie, blocarea şi filtrarea este mai complicat de realizat.

84

Comunicaţia folosind Https-ul începe cu o negociere de protocol în care se stabileşte cheia de sesiune, după care totulfuncţionează criptat.Astfel o filtare după conţinut nu este posibilă.

Protocolul Https avea la început o mică problemă în sensul că nu comunica corectvaliditatea certificatului serverelor care aveau implementate serviciul de Virtual Hosting(mai multe domenii ce folosesc acelaşi IP). Astfel un site care folosea Https-ul era necesar să aibă un IP unic; nu era posibilă găzduirea mai multor site-uri Https pe acelaşi IP, iar validarea certificatului să funcţioneze în mod corect. Motivul principal este dat de faptul că atunci când primul pachet de Client Hello ajungea la server, acesta nu avea cum săştie ce sitese vrea servit pentru a furniza corect certificatul corect. Astfel a apărut nevoia ca un

Client Request să conţină şi acest amănunt pentru ca un server să poată găzdui mai multe site-uri HTTPS pe acelaşi IP şi să poată identifica din timp ce domeniu este accesat pentru a furniza certificatul corect.sdfsdfsdfsdAstfel în RFC4366 a apărut o extensie la TLS denumităServer Name Indication unde este specificatîn clar domeniul accesat.

Astfel se poate bloca accesul la site anume după aceasta extensie:

drop tcp any any -> any 443 (msg:"HTTPS Facebook not allowed"; content:"facebook.com"; ssl_state:client_hello;ssl_version:tls1.0,tls1.1,tls1.2; classtype:policy-violation; sid:1000008; rev:1;)

Din păcate nu este de ajuns pentru a bloca accesul la un site ce foloseşte SSL, în principiu dincauza browser-elor. Acestea, după ce se realizează 3-way-handshake-ul TCP, vor trimite un Client Hellofolosind protocolul TLS 1.0 sau TLS 1.1 sau chiar TLS 1.2, iar pentru că are extensia Server NameIndication va fi identificat de Snort şi dropat. Pentru că browser-ul nu primeşte înapoi „Server Hello” mai încearcă de câteva ori. Dacă nici după aceste încercări nu reuşeşte atunci va folosi o versiune inferioară de SSL cum ar fi SSL 2.0 şi 3.0, versiuni ce nu au extensia Server NameIndication.

Din această cauza Snort-ul va permite trecerea acestor pachete iar site-ul va putea fi încontinuare accesat. Din aceasta cauză trebuie blocate aceste versiuni ale protocolului SSL deoarece nu mai sunt foarte folosite, iar majoritatea server-elor şi clienţilor folosescversiunile mai noi. Alt motiv pentru blocareaacestora ar fi şi încurajarea folosirii protocoalelor sigure cum ar fi TLS 1.0, 1.1, 1.2. Pentru a realiza acest lucru trebuie activat decoder-ul Snort-ului care va ajuta la normalizarea şi decodareaprotocolului, precum şi la posibilitatea folosirii unor opţiuni specifice SSL-ului cum ar fi „ssl_version”, care ajută la identificarea versiunii

Figura 8.10 - Protocolul HTTPS

85

protocolului şi „ssl_state” folosită la identificarea tipului depachet din handshake-ul SSL(Server Hello, Client Hello, etc).

preprocessor ssl: ports { 443 }, trustservers,noinspect_encrypted

Astfel Snort este instruit să pornească preprocesarea pachetelor ssl de pe portul 443, să nu mai aştepte şi Server Reply-ul din sesiunea SSL pentru a considera comunicaţia criptată(trustservers) şi să nu inspecteze pachetele la nivel de aplicaţie pentru ca ele oricum sunt criptate şi pot genera falsuri pozitive(noinspect_encrypted ).

Astfel, pachetele vor fi decodate şi normalizate şi vom putea folosi funcţii ale snort-ului specifice SSL-ului.

Regula ce blocheaza pachetul Client Hello ce foloseste o versiune inferioara de ssl este:

drop tcp any any -> any 443 (msg:"SSL old versions not alowed"; ssl_state:client_hello; ssl_version:sslv3,sslv2;classtype:policy-violation; sid:1000009; rev:1;)

În cazul traficului browser-elor ce folosesc protocoalele TLS1.0,TLS1.1, TLS1.2 şi nuimplementează extensia Server Name Indication, acesta va fi blocat.

Primul pas este de a analiza handshake-ul ssl şi a vedea unde anume se află extensia respectivă şi cum putem face pentru a ajunge la ea. Se va analiza primul pachet din handshake, „Client Hello-ul”, şi se vaîncerca a ajunge la Server Name Indication, care conform RFC-ului are numărul 0.Dacă extensie cu numărul 0 există, atunci pachetul va fi lăsat să treacă, dacă nu, atunci pachetul va firespins.

Figura 8.11 Pachet Client Hello TLS 1.0

byte_jump:2,44,align;

Se va sări peste cei 44 de octeţi din payload, se vor citi 2 octeţi ce reprezintă lungimea

86

câmpului cu cifruri, se va transforma în număr întreg şi se va sări peste acel număr de octeţi care în cazulacesta este 72. Astfel ne vom poziţiona exact în fata câmpului Compression Methods Length.Va trebui citită lungimea acestui câmpului şi omişi acei octeţi

byte_jump:0,1,relative,align;

Se sare peste câmpul unde se descrie Extension Length-ul şi se caută în următorii doi octeţii dacă apare0000, numărul extensiei Server Name Indication:

content:!"|0000|"; distance:2; within:2;

Regula finală care blochează orice pachet client hello ce nu are extensia Server Name Indication este:

drop tcp any any -> any 443 (msg:"SSL without extension not allowed"; byte_jump:2,44,align;byte_jump:0,1,relative,align; content:!"|0000|"; distance:2; within:2; ssl_state:client_hello; ssl_version:tls1.0,tls1.1,tls1.2;classtype:policy-violation; sid:1000010; rev:1;

8.6 Filtrarea protocolului FTP

FTP-ul este un protocol extrem de răspândit şi popular folosit în transferul de date. Este folositmai ales în rândul creatorilor de site-uri, pentru a face upload-ul unor diverse documente ce vor fi apoi accesate deutilizatorii site-ului respectiv. Din neatenţie este foarte uşor să uploadezi şi documente ce nu ar trebuirăspândite publicului larg. Bineînţeles un atacator poate folosi acest protocol pentru a uploada script-urimaliţioase.

FTP-ul este un protocol foarte vechi, descris în RFC 959 din 1985, şi de aceea este puţin diferit faţă de alte protocoale TCP/IP folosite în prezent. Acesta nu lucrează pe un singurport, comenzile se trimit pe portul 21, iar transferul de date se executa fie pe portul 20 fie pe oricare alt port mai mare decât 1024. Altă problema ar fi în modul cum transfera FTP datele, ori foloseşte modulAsci ori foloseşte modul Binar pentru transfer.

FTP-ul poate funcţiona sub două moduri:

Pasiv

1. Clientul iniţiază transferul de pe un port mai mare de 1024 pe portul 21 al serverului, iar serverul îi va spune că va începe să asculte peun port peste 1024.

Figura 8.12 - FTP în mod Pasiv

87

2. Clientul se va conecta la acel nou port pecare va asculta serverul şi va transmite sauprimi date. Astfel datele ce trebuiesc filtratevor circula între client şi server pe porturi TCP mai mari decât 1024.nO regulă ce poate fi folosită pentru a fi filtra după conţinut este următoarea:

reject tcp any 1024: ->any 1024: (msg:"SecretString pasiv FTP"; content:"secret";classtype:policy-violation; sid:1000003; rev:1;)

Activ

1. Clientul iniţiază transferul de pe un port P mai mare decât 1024, în care îi spune server-ului că va ascultă pe un port P+1.

2. Serverul va iniţia apoi transferul folosind portul 20 conectându-se la client pe noul port pe care acesta ascultă.

Acest mod are probleme cu echipamentele de firewall-ul şi cu protocolul NAT,mulţi clienţi aflându-se în spatele altor echipamente de reţea( router, firewall, proxy), serverul neavând posibilitatea să ajungă niciodată el. Datele pot fi transferateatât binar cât şi în mod asci de aceea cea mai bună regulă este să fieverificat tot traficul raw pe portul 20

după cuvinte cheie:

reject tcp any 20,1024: -> any 20,1024: (msg:"Secret String FTP Activ"; content:"secret"; classtype:policy-violation;sid:1000004; rev:1;)

8.7 Filtrarea protocolului SMTP

Simple Mail Transfer Protocol (SMTP) este protocolul standard folosit pentru transmisia mesajelorelectronice. Serverele de mail comunică prin acest protocol pentru a transmite mesajele. Protocolul foloseşte caractere ASCI pentru transmiterea mesajelor făcând intercepţia şi decodarea acestora extrem de uşor. Portul folosit este 25.

Figura 8.13 - FTP în mod Activ

88

O regulă ce scanează tot traficul de SMTP în căutarea stringului „topsecret” este următoarea:

reject tcp any any ->any 25 (msg:"SMTP topsecret string"; content:"topsecret"; classtype:policy-violation; sid:1000005; rev:1;)

Problema vine atunci când vrem să transmitem şi date care nu sunt text, cum ar fi un executabil. Pentru a trece peste acestă problemă a apărut MIME(Multipurpose Internet Mail Extensions) în care sunt definitenişte standarde pentru codarea binar-text, cea mai populară astfel de codare fiind base64. Astfel oricemail cu attachment binar, va fi transformat în base64 şi apoi trimis.

Un mail cu attachment binar va fi encodat în base64 şi pus în corpul mail-lui, delimitat de niste tag-uri:

------=_NextPart_000_0061_01CC1B24.17E136F0Content-Type: application/octet-stream;

name="test_snort.bin"Content-Transfer-Encoding: base64

Content-Disposition: attachment;filename="test_snort.bin"

ADQAdG9wc2VjcmV0AAA=------=_NextPart_000_0061_01CC1B24.17E136F0—

Base64 foloseşte doar 64 de caractere, astfel 6 biţi per caracter sunt de ajuns în loc de 8biti cât sefolosesc în mod normal. Astfel un string trebuie scris în mod binar, împărţit în bucăţi de câte 6 biţi, şiapoi folosind tabelul de conversie Base64,se transformă fiecare calup de câte 6 biţi în caractere.

Pentru a encoda base64 stringul ”topsecret” se procedează astfel:

t o p s e c r e t

ASCI(Dec) 116 111 112 115 101 99 114 101 116

ASCI(Hexa) 74 6F 70 73 65 63 72 65 74

ASCII(Binar) 0111.0100 0110.1111 0111.000 0111.0011 0110.0011 0110.0011 0111.0010 0110.0101 0111.0100

Tabelul 8.14 – Codare“topsecret”

Conformalfabetului Base64 vom avea:

Bin 011101 000110 111101 110000 011100 110110 010101 100011 011100 100110 010101 110100

Base64(val) 29 6 61 48 28 54 21 35 28 38 21 52

Base64(enc) d G 9 w c 2 V j c m V 0

Tabelul 8.15 – Codare “topsecret” base64

89

Astfeltopsecretva fi codatîn Base64 sub forma dG9wc2VjcmV0.

Un caracter adăugat în faţa sau în spatele şirului de caractere căutat va schimba total codare acestuia, deci căutarea după şiruri codate nu este o soluţie. Singura soluţie este găsirea şi decodareatraficului base64 şi de-abia după aceea efectuată căutarea.

Snort-ul are incluse funcţii de decodare, singura problema rămânând doar calibrareaexactă a locului de unde să înceapă decodarea, o greşeala de 1 bit rezultând în nişte caractere decodate totaldiferit faţă de cele reale.

Regula următoare decodeazătraficul base64 calibrând pointer-ul exact de unde începe traficul codat şi apoi caută după caracterele „topsecret”:

reject tcp any any -> any 25 (msg:"SMTP base64"; content:"base64"; content:"|0d0a0d0a|";base64_decode:relative;base64_data; content:"topsecret"; within:14; classtype:policy-

violation; sid:1000006; rev:1;)

8.8 Logarea

Snort a fost configurat să realizeze urmatorul tip de logare:

Syslog : alertele sunt trimise sub acest standard către un server specializat;

Syslog-ul este un standard folosit pentru logarea datelor.Acesta separă software-ul ce a generat mesajul de sistemul ce îl stochează şi îl analizează.

Figura 8.16 - Alfabetul Base64

90

Câmpurile principale sunt: nivelul facilităţii, nivelul de severitate şi mesajul în sine.

Nivelul facilităţii este utilizat pentru a specifica ce tip de program a logat mesajul. Acest lucru permite ca în fişierul de configurare al unui sistem să se specifice cum să fie manipulate logurile după acest nivel.

Figura 8.17 - Nivele de securitate specifice Syslog

Figura 8.18 - Nivelele de facilitate Syslog

9.Concluzii

Problemele de securitate care afectează sistemele şi reţelele informatice impun utilizarea unor soluţii care să aibă în vedere diferitele tipuri de incidente şi ameninţări care pot duce la pierderea unor informaţii sensibile.

Sistemele de detecţie şi prevenţie a intruziunilor au devenit obligatorii pentruprotejarea împotriva diferitelor tipuri de malware, împotriva interceptării datelor confidenţiale transmise prin reţelele informatice, precum şi pentru protejarea reţelelor interne organizaţionale împotriva unor acţiuni externe ostile, mai ales în cazul instituţiilor militare, care sunt predispuse zilnic la astfel de acte datorită importanţei lor strategice în securitatea naţională şi mondială. Această lucrare a analizat aceste echipamentele din toate punctele de vedere, de la clasificare, metode de detecţie, tehnici de analiză a traficului până la criterii relevante ce pot influenta alegerea unui astfel de echipament şi cerinţele recomandate pentru blocarea eficientă a intruziunilor.

Fiecare IDPS şi gen de detec�ie are avantajele şi dezavantajele sale, iar pentru a detecta şi preveni cu succes atacurile informatice nu este de ajuns un singur tip de echipament, ci o combinaţie de mai multe echipamente şi tehnici de detecţie.

Snort este extrem de performant putând fi folosit cu succes în detecţia şi prevenirea scurgerilor de date, cu reţineri asupra traficului criptat, trafic ce va trece fără a putea fi decriptat. Avantajul lui este preţul şi posibilitatea de a crea reguli proprii care analizează traficul informatic la nivel de biţi. O alta problemă la Snort este însăşi faptul ca este open source, iar definiţiile şi configuraţiile implicite sunt le vedere, oricine le poate analiza, modifica şi testa, pentru a depista eventualele probleme şi arii neacoperite, folosindu-se de acestea în lansarea unui atac.

Sistemele de detec�ie �i prevenire a intruziunilor, reprezintă o variabilă foarte importantă în ecua�ia unui sistem bine protejat, pentru că una din cele mai importante resurse, poate chiar mai importantă decât cele materiale, este dată de infomaţie şi obţinerea ei. Într-o lume în care echilibrul mondial este dictat de puterea informaţiei, menţinerea confidenţialităţi acesteia este foarte importantă, deoarece aceasta dă valoarea unei informaţii.

2

10.Bibliografie

1. K. Scarfone, P. Hoffman, „Guide to Intrusion Detection and Prevention Systems( IDPS)”, NIST Special Publication 800-94, 2007;2. S. Northcutt, J.Novak, „Network Intrusion Detection, 3rd Edition”, New Riders Publishing, 2002;3. Snort Users Manual 2.9.4, Noiembrie 2012; 4. Sandip A. Kale, Prof.S.V. Kulkarni, „Data Leakage Detection: A Survey”;5. Andrew S. Tanenbaum, „Reţele de calculatoare, ediţia a treia”, Computer Press Agora, 1998;6. SourceFire VRT WhitePaper: SourceFire, SourceFire VRT WhitePaper, 20117. http://snort.org/8. http://nsslabs.com9. http://www.wikipedia.org/10. http://tutoriale.eajutor.ro/unix-linux/tutorial-iptables-firewall-linux-comenzi-de-baza.html