Documente Academic
Documente Profesional
Documente Cultură
442A OPREA Florentin-Alin PDF
442A OPREA Florentin-Alin PDF
Proiect de diplom
Prezentat ca cerin parial pentru obinerea titului de
Inginer n domeniul Calculatoare i Tehnologia Informaiei
programul de studii de licena Ingineria Informaiei
2013
Cuprins
CUPRINS ............................................................................................................................................ 2
1.INTRODUCERE.................................................................................................................................1
2.PRINCIPIILE DETECIEI I PREVENIEI INTRUZIUNILOR ................................................................... 2
2.1 UTILIZAREA TEHNOLOGIILOR IDPS .......................................................................................................2
2.2 FUNCIILE CHEIE ALE TEHNOLOGIILOR IDPS............................................................................................ 3
2.3 METODOLOGII COMUNE DE DETECIE ................................................................................................... 5
2.3.1 DETECIA BAZAT PE SEMNTURI ...........................................................................................................5
2.3.2 DETECTAREA ANOMALIILOR ...................................................................................................................6
2.3.3 ANALIZA PROTOCOALELOR DE TIP STATEFUL ..............................................................................................7
2.4 TIPURI DE TEHNOLOGII IDPS...............................................................................................................8
2.5 INTRUZIUNILE ..................................................................................................................................9
3. TEHNOLOGII IDPS......................................................................................................................... 12
3.1 COMPONENTE I ARHITECTUR ......................................................................................................... 12
3.1.1 COMPONENTE TIPICE ..........................................................................................................................12
3.1.2 ARHITECTURA DE REEA ......................................................................................................................12
3.2 CAPABILITI DE SECURITATE ............................................................................................................ 13
3.2.1 CULEGEREA INFORMAIILOR ................................................................................................................13
3.2.2 CAPABILITI DE LOGARE.....................................................................................................................13
3.2.3 DETECIA..........................................................................................................................................14
3.2.4 PREVENIA........................................................................................................................................16
3.3 MANAGEMENT .............................................................................................................................. 16
3.3.1 IMPLEMENTARE .................................................................................................................................16
3.3.2 OPERARE I MENTENANA ...................................................................................................................18
3.3.3 COMPETENE DE CONSTRUIRE I MENTENAN .......................................................................................20
4. IDPS-URI LA NIVEL REEA............................................................................................................. 22
4.1 STIVA TCP/ IP ............................................................................................................................... 22
4.2 COMPONENTE I ARHITECTUR ......................................................................................................... 26
4.2.1 COMPONENTE TIPICE ..........................................................................................................................26
4.2.2 ARHITECTURA DE REEA I LOCAIILE SENZORILOR ...................................................................................27
4.3 CAPABILITI DE SECURITATE ............................................................................................................ 30
4.3.1 CULEGEREA INFORMAIILOR ................................................................................................................30
4.3.2 CAPABILITI DE LOGARE.....................................................................................................................31
4.3.3 DETECIA..........................................................................................................................................31
4.3.4 PREVENIA........................................................................................................................................35
4.4 MANAGEMENT .............................................................................................................................. 37
4.4.1 IMPLEMENTARE .................................................................................................................................37
5. IDPS-URI LA NIVEL DE HOST ......................................................................................................... 39
5.1 COMPONENTE I ARHITECTUR ......................................................................................................... 39
5.1.1 COMPONENTELE TIPICE .......................................................................................................................39
5.1.2 ARHITECTURA DE REEA .....................................................................................................................40
5.1.3 LOCAIA AGENILOR ...........................................................................................................................41
5.1.4 ARHITECTURA HOST-ULUI ....................................................................................................................41
5.2 CAPABILITILE DE SECURITATE......................................................................................................... 42
5.2.1 LOGARE............................................................................................................................................42
5.2.2 DETECIA..........................................................................................................................................42
5.2.3 PREVENIA........................................................................................................................................47
5.2.4 ALTE CAPABILITI .............................................................................................................................47
5.3 MANAGEMENT .............................................................................................................................. 48
5.3.1 IMPLEMENTARE .................................................................................................................................48
5.3.2 OPERARE .........................................................................................................................................49
6. SOLUII PROFESIONALE IDPS ....................................................................................................... 50
6.1 ALEGEREA IDPS-ULUI ...................................................................................................................... 50
6.2 CERINE PENTRU PREVENIREA EFICIENT A INTRUZIUNILOR ..................................................................... 51
6.3 CARACTERISTICI CHEIE AL UNUI IDPS.................................................................................................. 52
7. SNORT.......................................................................................................................................... 55
7.1 PRIVIRE DE ANSAMBLU.................................................................................................................... 55
7.1.2 MODULUL SNIFFER....................................................................................................................... 56
7.1.3 MODULUL LOGGER ...................................................................................................................... 56
7.1.4 MODULUL NIDS................................................................................................................................57
7.1.5 MODULUL INLINE...............................................................................................................................59
7.2 CONFIGURARE ............................................................................................................................... 59
7.2.1 INCLUDE ...........................................................................................................................................59
7.3 PREPROCESOARELE ......................................................................................................................... 62
7.3.1 FRAG3 .............................................................................................................................................63
7.3.2 SFPORTSCAN .....................................................................................................................................64
7.3.3 HTTP INSPECT ..................................................................................................................................64
7.3.4 PREPROCESORUL DE DATE SENSIBILE......................................................................................................64
7.4 SEMNTURI / REGULI ...................................................................................................................... 66
7.4.1 SCRIEREREA REGULILOR ......................................................................................................................70
7.4.2 ANTETUL UNEI REGULI ........................................................................................................................70
7.4.3. OPIUNILE UNEI REGULI .....................................................................................................................71
7.4.4 PRAGUL UNEI REGULI ..........................................................................................................................74
8. SISTEM PENTRU PREVENIREA SCURGERILOR DE DATE................................................................. 74
8.1 SNORT SISTEM DE DETECTARE I PREVENIE A SCURGERILOR DE DATE...................................................... 74
8.2 IPTABLES ....................................................................................................................................... 75
8.3 ARHITECTURA DE REEA UTILIZAT ..................................................................................................... 80
8.4. METODE DE DETECIE I PREVENIE ................................................................................................... 81
8.5.FILTRAREA PROTOCOLULUI HTTP I HTTPS ............................................................................................ 82
8.6 FILTRAREA PROTOCOLULUI FTP ......................................................................................................... 86
8.7 FILTRAREA PROTOCOLULUI SMTP...................................................................................................... 87
8.8 LOGAREA ...................................................................................................................................... 89
9.CONCLUZII ......................................................................................................................................1
10.BIBLIOGRAFIE................................................................................................................................2
1.Introducere
n ziua de astzi cu hackerii i hoii de identitate securitatea computerului a
devenit tot mai instabil, astfel pentru a fi mereu cu un pas n faa atacurilor ru
voitoare companiile i nu numai au nceput sa investeasc n programe antivirus de
reea, firewall-uri, securitatea mesajelor provenite din pota electronic i web
pentru protecia asupra posibilelor ameninri externe. Cum prin simpla conectare a
unui stick poate prezenta o teribil ameninare, problema deteciei i prevenirii
intruziunilor a devenit una extrem de important n zilele noastre, problem abordat i
n aceast lucrare.
Scopul principal al lucrrii este acela de a veni in ajutorul staiilor expuse la
risc prin proiectarea unui software ce are rolul de a identifica atacurile ru voitoare
asupra reelelor i resurselor acesteia, de a stopa intruziunile detectate i de a imuniza
sistemul. Informaiile provenite in urma deteciei se vor comunica staiei centrale mai
precis adminului printr-o anumita notificare, pentru a putea lua decizia optim ct mai
repede cu putin cu privire la starea reelei.
1
2.Principiile deteciei i preveniei intruziunilor
Multe IDPS-uri, pe lng logare, pot preveni ameninrile detectate n a-i ndeplini
scopul. Sunt folosite mai multe tehnici de aciune n oprirea atacurilor: schimbarea mediului
de securitate (de exemplu, reconfigurarea unui firewall) sau schimbarea coninutului atacului.
1
Pe parcursul lucrrii 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 notificai
de atac.Este important de tiut dac inta a avut o vulnerabilitate cunoscut pe care atacatorul ar fi putut s o
exploateze.Asupra respectivei vulnerabiliti pot fi lansate alte atacuri pe care IDPS nu le poate recunoate.
2
companii: monitorizarea transferurilor de fiiere i recunoaterea celor ce ar putea fi
suspicioase, asemenea transferului unei baze de date ntr-un laptop);
activitile de recunoatere, ce indic de cele mai multe ori iminena unui posibil
atac(ex: unele tool-uri de atac i forme de malware - n special cel de tip worm)
efectueaz activiti de recunoatere ca scanarea de host-uri i port-uri pentru
identificarea unor inte pentru atacurile viitoare.Un IDPS poate bloca aceste aciuni,
notificnd n acelai timp administratorii de securitatea, care pot interveni, dac este
nevoie, pentru a preveni incindente viitoare.Datorit frecvenei foarte mari a
activitilor de recunoatere n internet, detecia acestora se concentreaz n mod
deosebit pe reele interne.
Organizaiile folosesc sistemele de detecie i prevenie i n alte scopuri, altele dect cele
de baz:
3
Notificarea administratorilor de securitate despre evenimente importante
observate. Aceast notificare, cunoscut sub numele de alert, survine prin mai multe
metode: email-uri, pagini de rspuns, mesajele de pe interfaa 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 informaii de baz cu privire la un eveniment, administratorii
trebuie s acceseze IDPS-ul pentru informaii suplimentare;
Oprirea atacului fr vreo alt intervenie.Acest lucru ar putea fi realizat dup cum
urmeaz:
o Terminarea conexiunii la reea 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 oricrui acces la host-ul, serviciul, aplicaia sau orice alt resurs
vizat.
Schimbarea coninutului atacului. Unele tehnologii pot elimina sau nlocui poriuni
maliioase ale unui atac pentru a-l face benign. Un exemplu simplu este eliminarea
unui fiier infectat ataat unui email i apoi s permit email-ului curat s ajung
la destinatar.Un exemplu mai complex este comportarea asemntoare a unui proxy ce
normalizeaz cererile primite, materializat prin ndeprtarea antetelor pachetelor.Acest
lucru poate cauza mpiedicarea unor diverse atacuri.
Un alt atribut al acestor tehnologii este faptul c acestea nu pot oferi o detecteie
caracterizat de o acuratee maxim. Atunci cnd un IDPS identific n mod incorect ca fiind
ru intenionat o activitate benign, putem spune c a avut loc un fals pozitiv. Atunci cnd un
IDPS nu reuete 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,
4
reducerea unuia duce la apariia celuilalt. Multe organizaii aleg s scad apariiile de falsuri
negative, cu costul creteri falsurilor pozitive, fapt ce duce la detecia mai multor evenimente
periculoase, fcndu-se uz de mai multe resurse de analiz pentru a se face diferena ntre
evenimentele fals pozitive i cele malware. Modificarea configuraiei unui IDPS pentru a
mbunti precizia de detectare este cunoscut sub numele de tuning.
Cele mai multe tehnologii IDPS ofer funcionaliti ce combat utilizarea tehnicile
comune de evaziune.Evaziunea reprezint modificarea formatului activitilor malware, astfel
nct nfiarea acestora se schimb, dar efectul rmne acelai. Atacatorii folosesc tehnici
de evaziune pentru a ncerca s previn detecia 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 sperana c orice IDPS de monitorizare nu o face. Cele
mai multe tehnologii IDPS pot depi tehnicile comune de evaziune prin duplicarea unor
procesri speciale efectuate de ctre inte.n cazul n care IDPS-ul poate "vedea" activitatea n
acelai mod n care o face inta, atunci tehnicile de evaziune vor fi ineficiente n ncercarea de
a ascunde atacurile.
Cele mai multe tehnologii IDPS utilizeaz metodologii de detecie multiple, fie
separat, fie integrate, pentru asigurarea unei detecii ct mai largi i mai precise.
Acest tip de detecie este foarte eficient n detectarea ameninrilor cunoscute, dar n
mare parte ineficient la detectarea ameninrilor necunoscute anterior, ameninrilor
deghizate de utilizarea unor tehnici de evaziune, i a multe variante de ameninri 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 semntur n cutarea lui "freepics.exe" nu l-ar potrivi.
5
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
semnturi utiliznd operatorii de comparare a irurilor de caractere. Tehnologiile de detectare
bazate pe semnturi nu au capacitatea de a ntelege reelele sau protocoale de tip aplicaie i
nu pot urmri i nelege starea comunicaiilor complexe. De exemplu, acestea nu pot asocia o
cerere cu rspunsul corespunztor. Le lipsete 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 conine o indicaie clar a
unui atac.
6
O alt problem cu construcia 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 ntreinere ce efectueaz transferuri de fiiere mari are loc doar o
dat pe lun, s-ar putea s nu fie observat n timpul perioadei de formare; atunci cnd se va
produce ntreinerea, este probabil s fie considerat o deviere semnificativ de la profil i se
va declana o alert. Produsele IDPS ce se bazeaz pe acest metod produc de multe ori mai
multe alarme false de tip fals pozitiv din cauza activitilor 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 analiti s determine iniial de ce un anumit tip de alert a fost
generat, iar apoi s o valideze(s nu constituie un fals pozitive), din cauza complexitii
evenimentelor i a numrului de evenimente care ar fi putut s o cauzeze.
7
considerare, de asemenea, diferenele ce apar n diferitele implementri. Multe standarde nu
ofer o descriere complet a protocolului, cauznd astfel variaii ntre implementri. De
asemenea, productorii ncalc de multe ori standardele sau adaug caracteristici proprietare,
unele putnd nlocui caracteristicile standard. Pentru protocoalele proprietare, detaliile
complete nu sunt adesea disponibile, fapt ce va ngreuna furnizarea unor analize complete i
exacte de ctre tehnologiile IDPS. Pe msur ce protocoalele sunt revizuite, iar vnztorii
modific implementrile, modelele proprii IDPS-urilor trebuie s fie actualizate pentru a
reflecta aceste modificri.
Aceast metod de analiz este o consumatoarea foarte mare de resurse, din cauza
complexitii analizei realizate i suprancrcarea ce rezult din urmrirea 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 aciuni benigne
ntr-o perioad scurt de timp pentru a provoca o blocare a serviciului - DoS). Pe lng
acestea, modelul de protocol utilizat de un IDPS ar putea intra n conflict cu modul n care
protocolul este implementat n diferite aplicaii i sisteme de operare.
Exist mai multe tipuri de tehnologii IDPS, n funcie de tipul de evenimente pe care le
monitorizeaz i de modul n care acestea sunt implementate, acestea sunt mprite n
urmtoarele patru grupe:
8
Figura 2.1 Tehnologii IDPS
Unele forme de IDPS sunt mai mature dect altele pentru c au fost folosite mult mai mult
timp. Cele la nivel reea i unele forme la nivel de host sunt disponibile pe pia de peste zece
ani. Cele bazate pe analiza comportamental a reelei 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 reelele interne. Tehnologiile fr fir sunt
un tip relativ nou, dezvoltat ca rspuns la popularitatea reelelor locale wireless (WLAN) i a
ameninrilor n cretere la adresa reele WLAN i clienilor WLAN.
2.5 Intruziunile
Intruziunile sunt unele dintre cele mai mari ameninri la adresa retelelor de
calculatoare i a sistemelor de calcul. Acestea exploateaz slbiciuni ale software-ului sau ale
configuratiei sistemului pentru a-l deteriora. Printre acetia regsim: viruii propriu-zii, virui
de macro i de email, cai troieni i viermi.
De numele acestor tipuri de ameninri se leag principalele unelte folosite de
persoanele ru intenionate n demersul lor de a obine date sensibile care pot fi valorificate n
vreun fel.
Viruii sunt programe cod executabil numit uneori malware care se insereaz n alt
program executabil. Astfel, virusul se propag atunci cnd 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 rmne n stare adormit. La
9
activare codul este plasat n memoria central a calculatorului i i ncepe execuia exact ca
orice alt program.
De obicei, atunci cnd este activat, virusul i insereaz copii ale sale n cele mai
comune executabile pe care le poate gsi pe discul rigid al calculatorului victim, proces
numit auto-replicare. Programele infectate se rspndesc de obicei de la un calculator la altul
prin copii pe medii de stocare sau prin descrcarea de pe Internet.
Cel mai adesea utilizatorii schimb ntre ei documente, nu programe. Acestea pot fi
inta virusilor de macro i de e-mail. Macrodefiniiile executate de aplicaii cum sunt
Microsoft Word, Excel sau Outlook pot fi i ele infectate de virui. La deschiderea unui
document infectat virusul se execut n background, fr ca utilizatorul s observe.
n mod asemntor, exist virui care se pot ataa la e-mail. De ndat ce destinatarul
deschide coninutul unui mesaj infectat, virusul este executat. De cele mai multe ori, ncep s
trimit email-uri care conin copii ale lor fiecrui contact gsit n cartea de contacte a victimei.
Viruii de email pot cauza pagube mari infrastructurii de email a Internet prin traficul
enorm pe care l genereaz ca urmare a replicrii multiple. n unele cazuri au provocat cderea
serverelor de email care nu au rezistat volumului imens de trafic.
Caii troieni constituie un tip aparte de malware care deschide pori n sisteme pentru
intrui. Termenul de cal troian este utilizat pentru a descrie software care permite atacatorilor
aflai la distan s ia controlul sistemului de calcul, s descarce fiiere, s instaleze aplicaii,
s modifice fiiere i chiar s opreasc de tot sistemul.
Caii troieni sunt programe instalate fr cunotina ncrcturii ostile de ctre
utilizatori n urma unei infectri a unui fiier sau a unei aplicaii descrcate de pe Internet.
Unul dintre cei mai faimoi cai troieni, Back Orifice, este att de puternic nct a ajuns s fie
considerat program de gestiune de la distana a sistemelor de calcul.
Viermii se pot replica fr intervenia utilizatorului. n timp ce viruii sunt pasivi i au
nevoie de intervenia utilizatorului pentru a se rula, viermii sunt activi. Din cauza faptului c
nu au nevoie de intervenia utilizatorului i se pot replica i activa autonom, ei sunt mult mai
periculoi. Acetia sunt programe care folosesc erorile de programare (bug-uri) ale resurselor
din reea pentru a se replica. Ei se pot inocula n sistemele de calcul datorit erorilor din
server, loc n care ncep s scaneze reeaua n cutarea 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 lng cutarea altor calculatoare pe care s le infecteze, viermii pot cauza pagube
prin atacarea reelei i a componentelor sale. Un sondaj la nivel naional n SUA, sponsorizat
de ctre CA Incorporated i de National Cyber Security Alliance (NCSA) a artat c 83%
dintre adulii care se implic n legturi sociale prin reele de calculatoare au descrcat fiiere
necunoscute, care le puteau expune PC-urile la atacuri.
Spyware-ul poate fi definit ca orice software care folosete 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 rsfoitor de Web, dac
limbajul de scenarii poate fi executat, dimensiunea ecranului, plug-in-urile disponibile,
informaii de DNS din domeniu, pot trasa ruta spre surs pentru a stabili unde se afl
calculatorul int pe reea) pe dou ci: prin cookies i instalndu-se i apoi executndu-se.
Programele care prezint risc, n legtur 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.
10
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
obinerea accesului la sistem, ci dau posibilitatea de a ptrunde n sistem cu permisiuni de
nivel maxim (root). O dat obinut accesul la nivel de administrator, poate fi folosit un cal
troian care s se deghizeze ntr-o funcie 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.
Dei 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 funciona eficient, temporar sau nelimitat. Autorii acestor atacuri
au de obicei drept int site-uri sau servicii gzduite pe servere cu cerine nalte, cum ar fi
bncile, gateway-uri pentru pli prin carduri de credit i chiar servere n ntregime. O metod
tradiional de atac provoac saturarea calculatorului int (victimei) cu cereri de
comunicare externe, astfel nct s nu mai poat reaciona eficient la traficul Internet legitim,
sau chiar s devin indisponibil.
Atacurile de tip Denial of Service sunt considerate nclcri ale politicii de utilizare
corect a Internetului elaborate de Internet Architecture Board. De asemenea aceste atacuri
constituie deseori nclcri ale legislaiei din ara respectiv.
Cteva scopuri pentru care sunt folosite intruziunile sunt:
obinerea accesului de la distan;
furtul de resurse;
sabotajul;
colectarea de date;
ocolirea sistemului de control al accesului;
eludarea detectrii.
11
3. Tehnologii IDPS
Server de baze de date. Un server de baze de date este un repozitoriu alctuit din
informaii nregistrate de ctre senzori, ageni, i / sau servere de management.
Componentele pot fi conectate ntre ele prin intermediul reelei standard a unei
organizaii sau printr-o reea separat, conceput strict, din motive de securitate, pentru
management, cunoscut sub numele de reea de management. Dac se utilizeaz o astfel de
reea, fiecare senzor sau agent are o interfa de reea suplimentar, cunoscut sub numele de
interfa de management care se conecteaz la reeaua mai sus menionat. De asemenea, n
12
cazul fiecrui senzor sau agent nu exist nici un tip de flux de date ntre interfaa de gestionare
i orice alt interfa de reea a sa. Serverele de management, serverele de baze de date i
consolele sunt conectate numai la reeaua de management. Aceast arhitectur izoleaz n
mod eficient toate componentele de reeaua de producie. Beneficiile sunt date de ascunderea
existenei i identitii IDPS-ului fa de atacatori, protejnd astfel sistemul fa de un atac. n
acest fel se asigur c IDPS-ul are o lime de band adecvat pentru a funciona n condiii
nefavorabile (atacuri de tip DDoS asupra reelelor monitorizate). Dezavantajele de a folosi o
reea de management includ costurile suplimentare investite n echipamente de reea 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 fr o reea de management separat, un alt
mod de a mbunti securitatea este de a crea o reea de gestionare virtual folosind o reea
virtual local (VLAN) n cadrul reelelor standard. Folosind un VLAN se confer o protecie
suplimentar pentru comunicaiile din cadrul IDPS-ului, dar nu comparabil cu protecia
oferit de o reea de gestiune separat. De exemplu, greelile de configurare a VLAN-ului ar
putea duce la expunerea unor date sensibile. O alt ngrijorare este dat de faptul c, n
condiii adverse, cum ar fi atacurile DDoS sau incidente majore de malware, dispozitivele de
reea partajate de reelele primare ale organizaiei i VLAN-urile ar putea deveni complet
saturate, impactnd negativ asupra disponibilitii i performanei unui IDPS.
13
uc Use Case Model
Log
include
include
include include include
Timestamp
Rating( Actiunea
Tipul alertei/ prioritate, intreprinsa
Detalii (IP,port,
ev enimentului sev eritate
etc)
,impact)
3.2.3 Detecia
Tehnologii IDPS ofer de obicei, capabiliti extinse de detecie. Cele mai multe produse
folosesc o combinaie de tehnici, ce susin, n general o detecie mai precis i mai flexibilil
n realizarea configuraiei. Tipurile de evenimente detectate i acurateea deteciei variaz
foarte mult de la o tehnologie la alta. Cele mai multe IDPS-uri au nevoie de tuning i
personalizare pentru a mbunti acurateea, gradul de utilizare, precum i eficiena.
Tehnologiile variaz foarte mult prin direciile de tuning i capabilitile de personalizare. De
obicei, cu ct tuning-ul i capabilitile de personalizare ale unui produs sunt mai viguroase,
cu att mai mult acurateea deteciei poate fi mbuntit fa de cea a configuraiei
implicite.Acest lucru trebuie tratat cu atenie n evaluarea unor astfel de produse.Exemple de
astfel de capaciti sunt cele dup cum urmeaz:
Liste negre/albe. O list neagr este o list de entiti discrete, cum ar fi gazde, adrese
IP, numere de port TCP sau UDP, coduri ICMP, aplicaii, nume de utilizatori, URL-
uri, nume de fiiere sau extensii de fiiere, care au fost asociate anterior cu activitii
maliioase. Listele negre, cunoscut i sub numele de liste fierbini(hot lists), sunt de
obicei folosite pentru a permite IDPS-urilor s recunoasc i s blocheze activitile
duntoare, 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 ameninrile recent detectate. O list alb
este o list de entiti discrete, care sunt cunoscute a fi benigne. Listele albe sunt de
obicei utilizate n mod granular, pentru a reduce sau ignora falsurile pozitive ce
14
implic activiti benigne. Listele albe i listele negre sunt cele mai frecvent utilizate
n detecia bazat pe semnturi i analiza protocoalelor stateful;
3
n unele tehnologii IDPS, oprirea alertelor duce la dezactivarea capabilitilor de detecie; alte produse, continu detecia, dar nu
vor genera mesaje de alert.
15
3.2.4 Prevenia
Cele mai multe IDPS-uri ofer posibiliti multiple de prevenire; acestea variaz n funcie
de tipul acestora. Administratori pot specifica n configuraie capacitatea de prevenire pentru
fiecare tip de alert. Astfel, se poate activa/dezactiva prevenia sau se poate specifica ce tip de
capabilitate de prevenie s se utilizeze. Unii senzori au un mod de nvare sau simulare, care
suprim toate aciunile de prevenire indicnd doar momentul cnd s-ar fi cuvenit o aciune de
acest tip. Acest lucru permite administratorilor s monitorizeze i s ajusteze configuraia
responsabil nainte de a activa aciunile de prevenire, ceea ce reduce riscul de blocare
accidental al activitilor benigne.
3.3 Management
3.3.1 Implementare
16
Ce alte controale i tehnologii de securitate trebuie modificate pentru buna funcionare
a sistemului, cum ar fi schimbarea regulilor firewall-urilor pentru a permite
componentelor s comunice.
3.3.1.2 Testarea i amplasarea componentelor
17
management), sau prin criptarea informaiilor. n cazul n care criptarea este utilizat,
ar trebui utilizai algoritmi de criptare recomandai de standardele international. Multe
produse folosesc pentru criptare protocolul TLS( Transport Layer Security); pentru
produsele care nu ofer suficient protecie prin criptare, organizaiile ar trebui s ia n
considerare utilizarea unei reele private virtuale (VPN) sau alte metode de tunele
criptate pentru a proteja traficul.
3.3.2 Operare i mentenana
Cele mai multe console IDPS ofer multe caracteristici ce ajut utilizatorii n sarcinile
lor zilnice. De exemplu, cnd un utilizator examineaz o alert, mai multe detalii i informaii
sunt disponibile pe nivele. Acest lucru permite utilizatorilor observarea informaiilor de baz
pentru mai multe alerte o dat, dar este posibil i afiarea informaiilor suplimentare despre
evenimente speciale de interes. Unele produse ofer utilizatorilor informaii detaliate de
sprijin, cum ar fi capturi de pachete i alertele aferente (ex: alte alerte pentru aceeai surs sau
destinaie), precum i documentaia alertei n sine. n general, cu ct exist mai multe date
nregistrate, cu att este mai uor pentru analiti s determine ce s-a ntmplat.
Cele mai multe console ofer, de asemenea, diverse funcii 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 ci ctre utilizatorii avizai. 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 fiier uor de interpretat (ex: valori separate prin virgul ntr-un fiier text), interogrile
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.
18
3.3.2.2 Soluii de mentenan
19
verificarea sumei de control; interfaa ar trebuie s verifice integritatea fiecrei
actualizri ca parte integrant a acestei aciuni de instalare;
20
recomandat o nelegere a principiilor de rspuns la incidente, precum i a politicilor
i procedurilor de rspuns la incidente ale organizaiei;
Competenele pot fi dezvoltate prin mai multe metode, ce includ training-uri, conferine
tehnice, cri i alte referine tehnice, precum i programe de mentorat. Cunoaterea
produselor specifice ale unui IDPS poate fi realizat prin mai multe metode:
Training realizat de vendor. Muli productori 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, permind participanilor s
nvee cum s foloseasc tehnologia ntr-un mediu non-producie;
Documentaia 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 informaii
suplimentare pentru alerte i semnturi;
Suport Tehnic. Cei mai muli productori ofer suport tehnic pentru clienii lor, fie ca
parte a achiziionrii unui produs sau pentru o tax suplimentar. Suportul este utilizat
n principal pentru rezolvarea problemelelor i clarificarea capabilitilor produselor
pentru utilizatorii si i administratori;
21
4. IDPS-uri la nivel reea
4.1 Stiva TCP/ IP
22
Dei dou dintre niveluri au acelai nume ca la modelul OSI, nu trebuie confundate
ntre ele pentru c fiecare nivel are funcii total diferite pentru fiecare model n parte.
Figura 4.2 Nivelele celor dou modele arhitecturale de reea
Nivelul aplicaie
23
Nivelul Transport
Nivelul transport este proiectat astfel nct s permit conversaii ntre entitile
pereche din host-urile surs i, respectiv, destinaie, 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 octei
trimii de pe un host s ajung fr erori pe orice
alt host din inter-reea. Orientarea pe conexiune nu
semnific faptul c exist un circuit ntre
TCP/IP computerele care comunic, ci faptul c
segmentele nivelului Aplicaie cltoresc
bidirecional ntre dou gazde care sunt conectate
logic pentru o anumit perioad. Acest proces este
Figura 4.4 - Protocoale Transport cunoscut sub denumirea de packet switching.
Acest protocol fragmenteaz fluxul de octei n
mesaje discrete i paseaz fiecare mesaj nivelului internet. La destinaie, procesul TCP
receptor reasambleaz mesajele primite ntr-un flux de ieire. TCP trateaz totodat controlul
fluxului pentru a se asigura c un emitor rapid nu inund un receptor lent cu mai multe
mesaje dect poate acesta s prelucreze.
Al doilea protocol din acest nivel, UDP (User Datagram Protocol), este un protocol
nesigur, fr conexiuni, destinat aplicaiilor care doresc s utilizeze propria lor secveniere
i control al fluxului, i nu pe cele asigurate de TCP.
Protocolul UDP este de asemenea mult folosit pentru interogri rapide ntrebare-
rspuns, client-server i pentru aplicaii n care comunicarea prompt este mai important
dect comunicarea cu acuratee, aa cum sunt aplicaiile de transmisie a vorbirii i a
imaginilor video. Relaia dintre IP, TCP i UDP este prezentat n figura 4.5. De cnd a fost
dezvoltat acest model, IP a fost implementat pe multe alte reele.
24
putea ceda dintr-un moment n altul. Astfel, un obiectiv major a fost ca reeaua s poat
supravieui pierderii echipamentelor din subreea fr a fi ntrerupte conversaiile existente.
Cu alte cuvinte, DoD dorea ca, atta timp ct funcionau hostul surs i hostul destinaie,
conexiunile s rmn intacte, chiar dac o parte din dispozitivele sau din liniile de transmisie
erau brusc scoase din funciune. Mai mult, era nevoie de o arhitectur flexibil, deoarece se
aveau n vedere aplicaii cu cerine divergente, mergnd de la transferul de fiiere pn la
transmiterea vorbirii n timp real.Toate aceste cerine au condus la alegerea unei reele cu
comutare de pachete bazat pe un nivel
inter-reea fr conexiuni.
Nivelul internet, este axul pe care
se centreaz ntreaga arhitectur. Rolul su
este de a permite gazdelor s emit pachete
n orice reea i a face ca pachetele s
circule independent pn la destinaie (chiar
dac aceasta face parte din alt
TCP/IP
reea).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
Figura 4.6 - Protocoale IP generic, chiar daca acest nivel este prezent
i n Internet.Aici analogia este cu sistemul
de pot (clasic). O persoan dintr-o anumit ar poate depune
ntr-o cutie potal mai multe scrisori internaionale i, cu puin noroc, majoritatea scrisorilor
vor ajunge la adresa corect din ara de destinaie. 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 reea) are propriile timbre, propriile mrimi favorite
de plicuri i propriile reguli de livrare este ascuns beneficiarilor.Nivelul internet definete
oficial un format de pachet i un protocol numit IP (Internet Protocol). Sarcina nivelului
internet este s livreze pachete IP ctre destinaie. Problemele majore se refer la dirijarea
pachetelor i evitarea congestiei. n consecin, este rezonabil s spunem c nivelul internet
din TCP/IP funcioneaz asemntor cu nivelul reea din OSI. Figura 4.5 arat aceast
coresponden.
25
FTP HTTP SMTP DNS DNS TFTP
TCP UDP
IP
Alte LAN i
INTERNET LAN
WAN
Un exemplu tipic de IDPS la nivel de reea este compus din senzori, unul sau mai
multe servere de management, multiple console, i, opional, 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 excepia senzorilor. Un senzor specific acestui tip de sistem
monitorizeaz i analizeaz activitatea de reea pe unul sau mai multe segmente de reea.
Cardurile de reea, ce vor realiza monitorizarea vor fi n modul promiscuu, ceea ce nseamn
c vor accepta toate pachetele de intrare pe care le vd, indiferent de destinaiile lor.
Majoritatea implementrilor folosesc muli senzori, ajungndu-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, incluznd
interfee de reea 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 ctre administrator;
26
De tip software. Unii vendorii vnd senzori compui doar din produse software.
Administratorii i pot instala doar pe host-uri ce ndeplinesc anumite cerine. Senzorul
software poate include un sistem de operare specific, sau poate fi instalat ntr-unul
standard ca orice alt aplicaie.
Inline. Un senzor inline este implementat astfel nct traficul de reea 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 nite dispozitive hibride de tip firewall / IDPS.
27
s opreasc atacurile prin blocarea traficului n reea. Senzori inline sunt de obicei
plasai n locuri n care ar fi plasai firewall-uri sau alte dispozitive de securitate (la
grania dintre reelele interne, ce trebuie separate, i cele externe). Senzori ce nu sunt
hibrizi sunt de multe ori amplasai pe partea mai sigur a unei diviziuni de reea pentru
a avea mai puin trafic de procesat i pentru a reduce ncrctura unui firewall.Figura
4.9 prezint o astfel de implementare.
Pasiv. Un senzor pasiv monitorizeaz o copie a traficului real de reea. Senzori pasivi
sunt de obicei implementai astfel nct s poat monitoriza locaiile cheie ale unei
reele (diviziunile dintre reelele) i segmente de reea cheie(activitatea ntr-o zon
demilitarizat - DMZ). Senzori pasivi pot monitoriza traficul, prin diverse metode,
dup cum urmeaz:
4
Intrusion Detection System
28
Trimiterea ntregului trafic mai multor senzori. Acest lucru ar
putea fi fcut pentru disponibilitate ridicat sau pentru a avea mai
multe tipuri de senzori ce efectueaz o analiz concomitent ale
aceleai activiti.
29
Divizarea traficului ntre mai muli senzori poate determina o reducere a
preciziei de detecie n cazul n care evenimentele legate sau poriuni ale unui singur
eveniment sunt vzute de senzori diferii. 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 luai mpreun, n ordine sunt ru intenionate, atunci atacul s-ar putea
s nu fie recunoscut.
Pentru a putea folosi un senzor n prevenia 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 destinaie. n
unele cazuri, un senzor pasiv poate plasa pachete ntr-o reea n ncercarea de a perturb o
conexiune, dar astfel de metode sunt, n general, mai puin eficiente dect metodele inline.
4.3 Capabiliti de securitate
30
Identificarea caracteristicilor reelei. Unii senzori IDPS pot colecta informaii
generale despre traficul de reea legat de configurarea dispozitivelor i host-urilor din
reea, cum ar fi numrul de hop-uri ntre dou dispozitive. Aceast informaie poate fi
folosit pentru a detecta modificrile ce pot aprea n configuraia reelei.
4.3.3 Detecia
n cadrul acestui tip de IDPS sunt oferite capabiliti extinse i largi de detecie. Cele
mai multe produse folosesc o combinaie ntre detectare bazat pe semnturi, cea bazat pe
detecia anomaliilor i tehnicile analizei protocoalelor de tip stateful pentru a efectua o analiz
n profunzime a protocoalelor comune; organizaiile ar trebui s utilizeze sistemele care
utilizeaz o astfel de combinaie de tehnici. Metodele de detectie sunt strns legate; un motor
de analiz a protocoalelor de tip stateful ar putea mpri activitatea analizat n solicitri i
rspunsuri, fiecare parte fiind examinat pentru anomalii i comparat cu semnturile
activitilor cunoscut a fi ru intenionate. Unele produse folosesc aceleai tehnici i ofer
5
n consol, tipul evenimentul sau alertei face de cele mai multe ori legtura ctre informaii de suport
despre vulnerabiliti / exploatri anume, cum ar fi referine ctre informaii suplimentare i numere CVE (
Common Vulnerabilities and Exposures)
31
aceeai funcionalitate ca i software-urile bazate pe analiza comportamentului de reea
(NBA).
4.3.3.1 Tipurile de evenimente detectate
32
activitilor 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 reea.
Din punct de vedere istoric, IDPS-urile la nivel reea 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 rnd pe detecia bazat pe semnturi, caracterizat prin detectarea
ameninrilor relativ simple i binecunoscute. Tehnologiile noi folosesc o combinaie de
metode pentru a crete acurateea i intervalul deteciei, i, n general, ratele rezultatelor de tip
fals pozitiv i fals negativ au sczut. 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
complexitii activitilor monitorizate. Un singur senzor monitorizeaz adesea trafic ce
implic sute sau mii de hosturi interne i externe. Numrul i varietatea de sisteme de operare
i aplicaii n uz n reeaua monitorizat poate fi imens, iar sistemele de operare i aplicaiile
sunt n continu schimbare. Acest lucru face imposibil pentru un senzor s neleag tot ceea
ce vede.
Chiar mai ru, senzorii trebuie s monitorizeze activitatea pentru mai multe combinaii
diferite de servere i clienti. De exemplu, o organizaie 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 combinaie de browser i server ar putea avea caracteristici de
comunicare unice (ex: secvena de comenzi, codurile de rspuns), lucru ce ar putea afecta
acurateea analizei. De asemenea, diferite configuraii i particularizri ar putea fi aplicate
browserelor i serverelor. Dispozitivele de control( firewall-uri, servere proxy) dintre servere
i clieni ce modific activitatea de reea, ar putea provoca dificulti suplimentare pentru
senzori.
n mod ideal, IDPS-urile la nivel reea ar trebui s poat interpreta toat activitatea de
reea la fel cum endpoint-urile o fac. De exemplu, diferite tipuri de servere web pot interpreta
aceeai cerere web n moduri diferite. Tehnicile speficie analizei protocoalelor stateful de
33
multe ori ncerc s realizeze acest lucru prin replicarea prelucrrii efectuate de tipuri comune
de clieni i servere. Acest lucru permite senzorilor mbuntirea preciziei de detecie. Muli
atacatorii fac uz de caracteristicile specifice de prelucrare ale clienilor sau serverlor, cum ar fi
manipularea codificrii caracterelor, n atacurile lor sau n tehnicile de evaziune folosite.
Organizaiile trebuie s utilizeze aceste IDPS-uri deoarece pot combate utilizarea tehnicilor
comune de evaziune.
Dei sunt oferite capabiliti extinse de detectare, acestea au totui unele limitri
importante. Trei dintre cele mai importante sunt:analiza traficul criptat din reea, manipularea
sarcinilor cu trafic intens i rezistena atacurilor mpotriva IDPS-ului nsui. Aceste limitri
sunt discutate mai jos.
Atacurile lansate prin traficul criptat nu pot fi detectate, inclusiv cele din reelele
private virtuale, din sesiunile SSH sau ce folosesc HTTP peste SSL (HTTPS). Aa cum am
menionat anterior, exist posibilitatea realizrii unei analize a configurrii iniiale a
conexiunilor criptate, care poate identifica dac software-ul client sau serverul are
vulnerabiliti cunoscute sau nu este configurat corect. Pentru a se asigura c o analiz
satisfctoare se face asupra traficului criptat, organizaiile 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 reea pentru a monitoriza traficul necriptat (ex: traficul
introdus ntr-o organizaie prin intermediul unui gateway VPN i decriptat apoi) i utilizarea
unui software la nivel de host pentru a monitoriza activitatea host-ului surs sau destinaie.
IDPS-urile la nivel reea pot fi n imposibilitatea de a efectua o analiz complet sub
sarcini mari. Senzori pasivi ar dropa unele pachete, existnd 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 perturbri n
34
disponibilitatea reelei; ntrzierile cauzate de prelucrarea pachetelor ar putea cauza o laten
inacceptabil de mare. Pentru a evita acest lucru, organizaiile ce folosesc senzori inline ar
trebui s-i selecteze pe cei care pot recunoaste condiiile unui trafic foarte mare, iar n acest
caz s treac anumite tipuri de trafic fr a efectua o analiza complet (parial sau deloc) sau
s dropeze traficul cu o prioritate redus pentru a reduce sarcina . Multi furnizori ncearc s
optimizeze senzori pentru a oferi performane mai bune la sarcini mari prin utilizarea unui
hardware specializat (ex: plci de reea de mare lime de band) i recompilarea
componentelor software pentru a include setrile i personalizrile fcute de ctre
administratori. Dei vnztorii i evalueaz senzorii la limi de band maxime, capacitatea
real a oricrui produs depinde de mai muli factori:
Senzorii sunt sensibili la diferite tipuri de atacuri. Atacatorii pot genera volume neobinuit
de mari de trafic caracteristice atacurilor de tip DDoS i trafic anormal (pachete fragmentate
neobinuit), 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
declaneze mai multe alerte ntr-o perioad scurt de timp, fiind special conceput pentru a
profita de configuraiile 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 numr
foarte mare de alerte astfel nct alerte generate de atacul real vor trece neobservat. Muli
senzori pot recunoate folosirea tehnicilor i instrumentelor comune pentru declanarea unor
astfel de atacuri; astfel pot alerta administratori de incindena atacului, ignornd restul
activitilor pentru a reduce sarcina. Organizaiile trebuie s selecteze produse care ofer
caracteristici care le fac rezistente la eec n cazul unor atacuri.
4.3.4 Prevenia
35
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 reueasc. 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, incluznd UDP sau ICMP. Metoda
session sniping nu mai este larg utilizat din cauz noilor metode mult mai eficiente.
Inline
Rularea unui program ter sau script. Se poate rula un script specificat de ctre
administrator cnd este detectat o anumit activitate malware. Acest lucru ar putea
7
Un senzor inline poate ncerca aceast tehnic, dar este mult mai ineficient dect celelalte aciuni pe
care le poate ntreprinde; astfel, n practic aceasta tehnic este rar folosit de ctre un senzor inline
36
declana o aciune de prevenire dorit de ctre administrator, cum ar fi reconfigurarea
altor dispozitive de securitate pentru a bloca respectiva activitate. Programe terele sau
script-urile sunt cele mai frecvent utilizate atunci cnd sistemul nu are caracteristicile
de prevenire dorite de ctre administratorii.
Cei mai muli senzori permite administratorilor specificare configuraiei de prevenie pentru
fiecare tip de alert. Aceasta include activarea sau dezactivarea preveniei, precum i
specificarea tipului de aciune ce trebuie ntreprins. Unii senzori au un mod de nvare sau
de simulare ce suprim toate aciunile de prevenire, indicnd n schimb cnd ar fi fost
necesar efectuarea unei aciuni de prevenire. Acest lucru permite administratorilor s
monitorizeze i s ajusteze configuraia capacitilor de prevenie nainte de a le activa, ceea
ce reduce riscul de blocare accidental al activitii benigne.
4.4 Management
4.4.1 Implementare
37
modelelor de scanare ar putea declana rspunsuri particulare i ce valori sunt setate n
anumite cmpuri din antetul pachetelor.
38
5. IDPS-uri la nivel de host
Un astfel de sistem monitorizeaz caracteristicile i evenimentele din cadrul unui
singur host pentru activiti suspecte. Exemple de tipuri de caracteristici ce ar putea fi
monitorizate sunt: traficul de reea cu sau fr fir (numai pentru acel host), logurile de sistem,
procesele active, accesul i modificarea fiierelor sau modificrile aduse configuraiei
sistemului sau aplicaiilor.
Cele mai multe IDPS-uri la nivel host au software-uri de detectare cunoscute sub
numele de ageni, instalai pe gazdele de interes. Fiecare agent monitorizeaz activitatea unui
computer, iar n cazul n care toate capacitile sunt activate, efectueaz, de asemenea, aciuni
de prevenire. Agenii transmit datele la servere de management, care pot utiliza opional
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 instalri individuale a software-ului agent pe gazd. Fiecare dispozitiv este poziionat
pentru a monitoriza traficul de reea ce merge la i de la un anumit host. Din punct de vedere
tehnic, acestea ar putea fi considerate sisteme de nivel reea, deoarece acestea sunt utilizate n
mod inline pentru a monitoriza traficul n reea. Cu toate acestea, ele monitorizeaz obicei
activitate unui tip specific de aplicaie, cum ar fi un server web sau server de baze de date;
astfel, acestea sunt mai specializate dect un IDPS standard de nivel reea. De asemenea,
software-ul care ruleaz pe dispozitiv are adesea funcionaliti identice sau similare cu cele
ale agenilor bazai pe host. De aceea, IDPS-uri la nivel de host ce folosesc aceste dispozitive
sunt incluse n aceast seciune.
Fiecare agent este de obicei proiectat pentru a proteja una dintre urmtoarele:
Un host client (desktop sau laptop). Ageni proiectai pentru a monitoriza utilizatorii
unui host de obicei monitorizeaz sistemul de operare i aplicaii comune client, cum
ar fi clienti de email i browsere Web;
Cele mai multe produse nu dispun de ageni pentru alte tipuri de host-uri(firewall-uri,
routere, switch-uri).
39
5.1.2 Arhitectura de reea
Arhitectura de reea este foarte simpl. Deoarece agenii sunt conectai la dispozitivele
existente n reelele organizaiei, componentele comunic prin intermediul acestor reele n
locul unei reele de management separat. Comunicaiile pot fi criptate, prevenind accesul
nedorit la informaii sensibile. Agenii hardware sunt instalai inline, imediat n faa
dispozitivelor protejate. Figura 5.1 prezint un exemplu de arhitectur.
40
5.1.3 Locaia agenilor
Agenii IDPS bazai pe host sunt cel mai frecvent utilizai pentru protecia unor host-uri
critice, cum ar fi servere accesibile publicului i servere care conin informaii sensibile.
Agenii se pot plia pe orice tip de host deoarece sunt disponibili pentru diferite sisteme de
operare pentru servere i desktop / laptop, precum i pentru aplicaii specifice serverelor.
Unele organizaii i folosesc n primul rnd pentru a analiza activiti ce nu pot fi monitorizate
prin alte controale de securitate. De exemplu, senzori IDPS bazai pe reea nu pot analiza
activitatea n reele de comunicaii criptate, dar cei instalai pe endpoint-uri pot vedea
activitatea necriptat. Organizaiile ar trebui s ia n considerare urmtoarele criterii
suplimentare atunci cnd selecteaz locaiile de implementare:
Costul pentru a implementa, menine i monitoriza agenii;
Sistemele de operare i aplicaiile suportate de ctre ageni;
Importana datelor i serviciilor oferite de host;
Capacitatea infrastructurii de a susine agenii (ex: band de reea suficient pentru a
transfera datele de avertizare ctre serverele centralizate i a transfera actualizrile de
software i politic de la servere la ageni).
5.1.4 Arhitectura host-ului
41
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 performanele gazdei.
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. Cmpuri de date logate n mod obinuit includ
urmtoarele:
5.2.2 Detecia
Pentru detecia celor mai multor tipuri de activiti ru intenionate sunt folosite de
multe ori o combinaie ntre tehnica bazat pe semnturi pentru a identifica atacurile
cunoscute i cea bazat pe detectarea anomaliilor mpreun cu politici sau seturi de reguli
pentru a identifica atacurile necunoscute anterior.
Analiza codului. Agenii pot utiliza una sau mai multe din tehnicile de mai jos pentru
a identifica activiti maliioase prin analizarea ncercrilor 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.
42
de cod este executat, s-ar putea ncerca obinerea unor privilegii la nivel de
administrator sau suprascrie un executabil de sistem;
Analiza traficului de reea. Acest lucru este de multe ori similar cu ceea ce un IDPS
de nivel reea face, putnd analiza att traficul de reea cu fir i fr fir. n plus fa de
analiza protocoalelor specifice nivelului reea, transport sau aplicaie, pot fi incluse
procesri speciale pentru aplicaii comune, cum ar fi clieni de email. Analiza
traficului permite agentului s extrag fiiere trimise de aplicaii, ce pot fi apoi
verificate contra programelor malware;
Filtrarea traficului de reea. Agenii includ de multe ori un firewall tipic hostului, ce
poate restriciona traficul de intrare i de ieire pentru fiecare aplicaie din sistem,
prevenind accesul neautorizat i nclcri 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 organizaiei;
43
o Verificarea atributelor fiierelor. Implic verificarea periodic a atributelor
fiierelor importante, cum ar fi dreptul de proprietate i permisiuni, pentru
modificri. Ca i n cazul integritii fiierelor, poate determin schimbarea
doar dup ce aceasta a avut loc;
8
Pe sistemele Windows, multe setrii de configuraie const ntr-un set special de fiiere numie
registre.Unii ageni au nite pene introduse n aceti regitrii ce restricioneaz accesul la poriuni critice ale
acestora, n special cele folosite n mod frecvent de malware-uri.
9
Unele produse efectueaz activiti ce in doar de analiza i managementul logurilor.Dei acestea sunt
referite a fi IPDS-uri bazate pe host, majoritatea sunt de fapt produse de tip SIEM(security information and event
management).
44
5.2.2.2 Precizia deteciei
Ca orice alte tehnologii, i acest tip cauzeaz de multe ori falsuri pozitive i negative.
Cu toate acestea, precizia de detecie constituie o problem mai mare n acest caz deoarece
multe din posibilele tehnici de detectare, cum ar fi analiza logurilor i monitorizarea
sistemului de fiiere nu au cunotine legate de contextul sub care au avut loc evenimentele
detectate. De exemplu, o gazd poate fi repornit, o nou aplicaie poate fi instalat sau un
sistem de fiiere poate fi nlocuit. Aceste aciuni ar putea fi realizate prin activiti ru
intenionate sau ar putea fi parte a funcionrii i intreinerii normale a gazdei. Evenimentele
n sine sunt detectate corect, dar natura lor, benigne sau maliioase, nu poate fi ntotdeauna
determinat fr un context suplimentar. Unele produse, n special cele destinate desktop-
urilor / laptop -urilor, cer utilizatorilor furnizarea contextului, dac o aplicaie este actualizat
sau nu de ctre utilizator. Dac acesta nu rspunde la solicitare ntr-o anumit perioad de
timp (de obicei cteva minute), agentul alege o aciune implicit (permitere / refuzare).
Sistemele care utilizeaz combinaii de mai multe tehnici de detectare ar trebui s fie,
n general, capabile de a realiza o detecie mai precis dect produsele ce utilizeaz una sau
cteva tehnici. Deoarece fiecare tehnic poate monitoriza diferite aspecte ale unei gazde,
folosirea mai multor tehnici permite agenilor colectarea mai multor informaii privind
activitile 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 inteniei
anumitor evenimente.
45
5.2.2.4 Limitri tehnologice
i n cadrul acestui tip regsim unele limitri importante. Unele dintre aceste limitri
sunt descrise n Seciunea 4.3.3.4. Alte limitri importante sunt:
ntrzieri n generarea alertelor. Dei agenii 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 cteva ori pe zi, provocnd ntrzieri semnificative n identificarea
unor evenimente;
Utilizare resurselor gazdei. Spre deosebire de alte tehnologii, aceasta implic ageni
care ruleaz pe gazdele monitorizate. Aceti ageni pot consuma resurse considerabile
ale gazdei, resurse ce includ memoria intern, procesorul i discul. Operaiunile
agenilor, n special acele pene, pot provoca ncetiniri n fluxul operaiunilor. Testarea
i evaluarea resurselor este recomandat a fi realizat nainte de o posibil instalare a
unui IDPS;
46
5.2.3 Prevenia
Analiza codului. Tehnicile de analiz de cod pot preveni executarea codului de ctre
aplicaii malware sau neautorizate. Pot fi oprite, de asemenea, aplicaii de reea 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 reea. Acest lucru poate opri traficul de reea de intrare n a fi
prelucrat de ctre gazd i traficul de reea de ieire s prseasc gazda. Acest lucru
ar putea fi fcut pentru a opri atacurile specifice nivelelor reea /internet, transport, sau
aplicaie (i, n unele cazuri, atacuri ce includ protocoalele speficice reelei wireless)
sau pentru a opri utilizarea de aplicaii i protocoale neautorizate. Analiza poate
identifica fiiere malware ce sunt descrcate sau transferate i preveni aceste fiiere n
a fi introduse n mediul gazdei. Traficul de reea 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 reea este
eficient n stoparea a multor atacuri cunoscute i necunoscute anterior;
Unele IDPS-uri de acest tip ofer capabiliti non-IDPS, cum ar fi software antivirus,
filtrarea spam-ului i a coninutului web sau de email. Exemple de aceste capaciti sunt dup
cum urmeaz:
47
Restricii asupra mediilor de stocare detaabile. Se pot impune restricii cu privire
la utilizarea mediilor de stocare amovibile, bazate pe USB (stick-uri flash) sau
tradiionale ( CD, discheta). Acest lucru poate preveni transferul unor malware-uri sau
fiiere, i poate opri copierea unor fiiere sensibile;
Curarea traficului de reea. Unii ageni, n special cei de tip appliance, pot igieniza
traficul de reea pe care l monitorizeaz. De exemplu, acesta ar putea aciona ca un
proxy i reconstrui fiecare cerere i rspuns ce este direcionat prin ea. Acest lucru
poate fi eficace la neutralizarea anumitor activiti neobinuite, n special n header-ul
pachetului i al protocoalelor aplicaie. Igienizare poate mpiedica atacurile de
recunoatere lansate asupra host-urilor sau poate scdea cantitatea de informaii legat
de host care poate fi achiziionat prin aceast metod. Exemplele includ ascunderea
amprentelor sistemelor de operare ale servelor i a mesajelor de eroare de aplicaie.
Este posibil prevenia afirii de informaii sensibile, cum ar fi numere de securitate
social i numere de card de credit, pe pagini web.
5.3 Management
5.3.1 Implementare
48
Securizarea componentelor. Dac serverele de management sau consolele trebuie s
se autentifice la fiecare agent pentru a-i gestiona sau colecta datele, organizaiile
trebuie s se asigure c mecanismele de autentificare pot fi gestionate i asigurate n
mod corespunztor. De exemplu, n cazul n care este nevoie de parole, exist
probleme de securitate n cazul utilizrii unei singure parole pentru toii agenii; n
cazul n care se folosete o parol separat pentru fiecare agent, parolele pot fi dificil
de urmrit i meninut n cazul a sute sau mii de ageni. n cazul n care cheile
criptografice sunt folosite pentru autentificare, managementul cheiilor poate prezenta
provocri n emiterea i distribuirea lor.
5.3.2 Operare
49
6. Soluii profesionale IDPS
Toate IDPS-urile au o parte software, fie ele de tip hardware( appliance) sau software.
Diferena ntre un hardware IDPS isoftware IDPS este felul cum este comercializat. Un
software este o aplicaie ce poate fi instalat pe orice sistem ce respect anumite cerine
tehnice(CPU, memorie RAM, etc) i are un sistem deoperare suportat de aplicaie(Windows,
Linux etc). Acest soluie este mai ieftin dect un hardware IDPS dinmai multe motive, cel
mai evident este nsi faptul c responsabilitatea hardware-ului i a sistemuluide operare
folosit cade n seama utilizatorului. Pot aprea diverse erori de configuraie,incompatibiliti
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 funcie,cu un sistem de operare de cele mai multe ori proprietar(de cele
mai multe ori se pornete 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 numete i
appliance. Avantajul const ntr-un echipament robust, rezistent,caracterizat de performane
ridicate unde suportul de la productor 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 funcionalitate i care se poate configura n diferite moduri, fr a interfera cu
hardware-ul sau software-ul de pe echipament. Estemai uor de instalat pentru c nu necesit
personal extrem de bine instruit pentru a obine perfomane decente, dar este i mult mai
scump.n funcie de cerine, personalul IT angajat, echipamentele ce trebuie protejate, de
funcionalitiadiionale i de buget se dispune, se va alege ntre un IDPS hardware sau
software.IDPS-urile hardware sunt de obicei mai bune i performante dect cele software prin
simplul fapt c sunt echipamente dedicate exclusiv acestui lucru.
50
6.2 Cerine pentru prevenirea eficient a intruziunilor
Funcionare inline. Prevenirea eficinent a intruziunilor este condiionat de acest tip de
funcionare. Regsim i IDS-urile active, care pot comunica cuechipamentele de reea i pot
introduce intrri n ACL-uri( access lists) dar acestea pot doar bloca total, dup
IP, ntreaga comunicaie. Alte IDS-uri pot ncerca s termine forat o sesiune TCP prin
injectarea pachetelor TCP reset n reea, dar aceasta metoda nu este deloc eficient i este
valabil doar pentru acest protocol;
Uptime-ul reelei. Acesta trebuie s poat s lase traficul s treac prin el i n caz c pierde
alimentarea cu energie. Astfel o eventual defeciune a sursei de curent nseamn osecuritate
sczut dar nu i oprirea activitii. Bineneles, acest aspect trebuie s poate fi
controlat n funcie de comportamentul dorit, n unele cazuri rare dorindu-se oprirea activitii
dect continuarea ntr-un mediu nesigur;
ntrzieri mici. Este de dorit ca impactul asupra vitezei reelei s fie ct mai redus cu
putin. Echipamentele de reea orict de performante ar fi adaug ntrzieri. Depinznd de
nivelul la care funcioneaz echipamentul i de rolul lui n reea, ntrzierile pot fi mai mari
saumai mici. Un IDPS performant trebuie s introduc ntrzieri n reea cu puin peste un
switch de nivel 2/nivel 3 i sub un echipament de nivel 4 obinuit cum ar fi un firewall sau
load-balancer;
Performan ridicat. Vor fi ndeplinite specificaiile din fia tehnic cu toate semnturile
active i n condiii real-life, pentru a fi siguri c urmtoarele semnturi ce vor veni ulterior nu
vor afecta performana reelei prin suprasolicitarea echipamentului;
Posibilitate de reglaj fin(tunning). Anumite semnturi pot produce prea multe alerte false
i atunciduneaz reelei i opresc aplicaiile 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 investigaii ulterioare Atunci cnd un incident grav se
ntmpl, chiar dac IDPS-ul este blocat, tot trebuie realizat o investigaie pentru o ntelegere
mai bun a evenimentelor petrecute.IDPS-ul trebuie s aib log-urile ct mai clare i uor de
sortat i categorisit, iar la incidentele considerate critice s poat s fac captura traficului, s
o stocheze, pentru o investigare ulterioar.
51
6.3 Caracteristici cheie al unui IDPS
Rata de transfer a filtrrii( firewall throughput). Principalul atribut pe care toi
productorii l trec n foile tehnice aleappliance-urilor pe care le produc este capacitatea de a
filtra traficul. Este msurat n Mb/sec i poate ncepe de la valori joase de ordinul 25Mb/s i
pn la cteva 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 filtrrii traficului, rata ce caracterizeaz abilitatea de a analiza traficul n
vedereadetectrii i prevenirii intruziunilor este mult mai mic;
Din pcate 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 dect 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
semnturilor pe care
52
le ofer productorul, de calitatea algoritmului folosit pentru identificarea anomaliilor, de ct
de bine poate distinge folosirea dubioas a anumitor protocoale, etc.
Productorii i regleaz echipamentele astfel nct s treac cu brio la testele efectuate
cu propriile unelte de testare astfel c folosirea uneltelor oferite de productorul
respectivuluiechipament pentru a-l testa sunt inutile. La fel i n ceea ce privete cele mai
folosite unelte de testare tere cum ar fi Nessus. Appliance-urile au definiiile bine definite
pentru o reuit sigur n acest caz. Pentru a fi siguri c echipamentul ce urmeaz a fi
achiziionat ofer securitatea care este dorit, este necesar o testare intern, simulnd postura
atacatorului i ncercarea anumitorexploatrii tehnici de evaziune cum ar fi fragmentarea
pachetelor, atacuri false, pacheteduplicate, etc.
O multitudine de teste sunt foarte greu de realizat fr 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 diferii vendori,testeaz n condiii reale pentru ndeplinirea a
celor declarate n fia tehnic a echipamentului, dac fac fa la diferite atacuri, tehnici de
evaziune, etc. Din pcate rapoartele de actualitate nu sunt gratis, ele necesitnd investiii mari.
Cele vechi sunt gratis dar nu sunt inutile, ele furniznd detalii preioase nceea ce privete un
anumit brand sau tip de echipament. Dac un anumit echipament ce acum 2 ani a fost
considerat 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
certificridac un produs corespunde cu cerinele exigente ale acestora. Un appliance poate s
obin una din cele trei certificri: NSS Gold, NSS Approved i NSS Tested. Astfel o trstur
de luat n considerare n decizia achiziionrii unui IDPS ar fi certificrile echipamentului.
Dac acesta are certificri de la firme specializate, de ncredere atunci putem fi siguri c acel
dispozitiv este unul performant i de ncredere.
Cisco, Juniper, Sourcefire, Fortinet, McAfee sunt doar o parte din juctorii importani
de pepiaa IDPS-urilor.
Acetia creaz appliance-uri profesionale, robuste, performante pentru companii de
toatemrimile. Toate produsele lor i nu numai arat extrem de bine pe hrtie dar problema
const ncapacitatea lor de a opri atacuri n condiii 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 cteva din appliance-urile
care au certificarea NSSApproved, semn de recunoatere al calitii i eficienei.
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 exploatri dintr-o gam
diversificat dedomenii, de la sisteme de operare pn la aplicaii, fiind blocate 618(99.4%), o
rat mai mult dect excelent. Au fost ncercate i 214 exploatri server-client, extrem de greu
de detectat din cauza faptului c sunt atipice, iar clientul trebuie s iniializeze sesiunea, dar i
n acest caz s-a comportat peste ateptri, blocnd 211 dintre ele(98.6%).
53
Multe IDPS-uri tiu s blocheze foarte multe atacuri datorit definiiilor uor de scris o
data ceatacul devine cunoscut, iar atacatorii ncearc un arsenal ntreg de tehnici de evaziune
pentru c exploatrile vechi s mearg n continuare. Cele mai cunoscute tehnici de evaziune
sunt fragmentareapachetelor n buci ct mai mici, trimiterea lor n ordine aleatoare n
sperana cIDPS-ul nu va fi n stare s reconstruiasc pachetul, folosirea de encoding-uri
diferite n sperana cacesta nu va ti s le descifreze, etc. M-8000 s-a descurcat excelent
neputnd fi pcalit prin nici o tehnic cunoscut.
SourceFire este unul din juctorii importani 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 facilitai ce fac appliance-urile
rezistente la diferite probleme. Software-ul folositeste desigur Snort-ul, cu regulile i
definiiile oficiale. Soluia de la SourceFire este un pic mai complex dect 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 definiii i trimite ctresenzori, etc . Toate IDPS-uri de
la SourceFire sunt certificate de ctre NSS ( Tested)i ICSA Labs fapt ce atest calitatea i
eficiena acestor IDPS-uri.
54
7. SNORT
SNORT este cel mai cunoscut i folosit IDS/IPS OpenSource. A fost create de ctre
Martin Roesch n 1998. n prezent, este dezvoltat i comercializat de ctre compania
SourceFire.Acesta poate fi instalat i folosit gratuit, dar pentru acces imediat la regulile
certificate este necesar o plat anual. Totui, semnturile oficiale noi se pot downloada
gratis dup 30 de zile de la lansare, ceea ce pentru aplicaiile necritice este rezonabil. Exist i
semnturi neoficiale, dezvoltate de comunitate, avnd la baz semnturile oficiale ale Snort-
ului la care s-au adugat mici mbunatiri, tweak-uri sau chiar semnturi i idei trimise de
ctre utilizatori. Cel mai cunoscut set de astfel de semnturi se numete 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 ctre 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.
Modul sniffer, care citete pur i simplu pachetele de pe reea i le afieaz ntr-un
flux continuu pe consol( ecran);
Snort-ul poate activa doar ntr-unul modurile prezentate mai sus, sau n mai multe
simultan, chiar toate.
55
7.1.2 Modulul sniffer
La rulare exist multiple posibiliti de afiare, care pot fi rulate cu ajutorul opiunilor
din sintaxa aferent liniei de comand, descrise n tabelul de mai jos:
Opiune Observaii
-v interactiv, afiarea doar a antetelor TCP/UDP/ICMP
-e Headere nivel legturi de date
-d Headere aplicaie
-a Afiare frame-uri ARP
-c Afiare date de tip char din payload ( nu le afieaz n
hexa)
-i eth0 Interfaa pe care ascult
-d Rulare ca daemon
-q Rulare n mod quiet (nu mai afieaz mesajele de
nceput i summary de la exit)
Tabelul7.1 Opiuni rulare SNORT ca sniffer
Exemplu de utilizare:
./snort vd
Pentru a nregistra pe disc pachetele, trebuie specificat directorul de logare dup care
programul va intra automat n acest modul:
Desigur, acest lucru presupune c exist un director numit log n directorul curent.
Dac nu, Snort va iei cu un mesaj de eroare. Cnd se ruleaz n acest mod, este colectat
fiecare pachet ce este vzut i pus ntr-o ierarhie de tip director pe baza adresei IP din pachete.
Dac este specificat doar opiunea l, se poate observa c Snort utilizeaz uneori
adresa endpoint-ului ca nume de director n care vor fi puse pachetele; uneori, se folosete
adresa gazdei.
Pentru a colecta pachetele ce in de reeaua intern aceasta trebuie specificat:
56
Aceast regul instruiete programul s afieze headerele specifice nivelului legturii
de date i aplicaie, 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 reele 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 fiier n directorul de logare:
./snort -l ./log b
Un exemplu prin care se activeaz acest mod pentru a nu nregistra fiecare pachet este:
unde snort.conf este numele fiierului de configurare.Astfel vor fi aplicate regulile configurate
aici pe fiecare pachet pentru a se decide dac este necesar acionarea n vreun fel bazndu-se
pe seturile de reguli din fiier.Dac nu este specificat nici un director de ieire, cel default este
/var/log/snort.
O obervaie ce trebuie menionat este legat de modul interactiv n acest caz.Pentru o
funcionare ndelungat, este de evitat activarea acestei opiuni din raiuni de vitez.Ecranul
este un mijloc ncet de scriere a datelor, iar pachetele pot fi dropate pn sunt afiate pe ecran.
De asemenea nu este necesar nregistrarea header-elor speficice legturii de date,
astfel se poate omite opiunea e:
10
n cazul n care sursa i destinaia sunt din reeaua intern, acestea sunt logate ntr-un director a crui
nume este alctuit din numrul mai mare de port implicat, iar n cazul unei egaliti, de adresa surs.
57
./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, lognd pachetele ce
se supun regulilor specificate n snort.conf folosind caractere ASCII sub o structur ierarhic
a directorului.
Exist mai multe moduri disponibile de a configura ieirea 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 afieaz mesajul de alert mpreun cu headerul
pachetelor. Exist mai multe alte moduri de ieire a alertelor disponibile n linia de comand,
precum idou faciliti 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 opiunea A n linie de comand. Aceste
opiuni sunt:
Opiune Observaii
-A fast Modul rapid.Se scrie alerta ntru-un format simplu
alctuit din timestamp, mesajul de alert, IP-uril i
porturile surs i destinaie
-A full Modul complet.Este modul implicit folosit n cazul n
care nu este specificat nimic.
-A unsock Sunt trimise alerte ctre un socket de Unix la care
poate asculta alt program
-A none Sunt oprite alertele.
58
Al doilea numr este ID-ul Snort( uneori referit ca ID-ul semnturii).Pentru o list a
SID-urilor de preprocesare se poate vizualiza fiierul 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 numr este numrul de revizie.Acest numr este n principiu folosit la
scrierea semnturilor, la fiecare modificare a regulii acest numr ar trebui incrementat.
ncepnd cu versiunea 2.3.0 Snort a nglobat oficial un IPS numit SNORT inline.
SNORT inline obine 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 + anunare surs) sau SDROP (dropare fr logare) sau PASS.
Pentru putea folosi SNORT_inline trebuie recompilat iptables, iar SNORT trebuie
compilat cu opiunea enable-inline. Recompilarea iptables presupune recompilarea
kernelului Linux.
Pentru a rula sub acest mod se speficic opiunea Qn momentul lansrii n execuie a
programului.
7.2 Configurare
7.2.1 Include
Cuvntul cheieinclude permite ca alte fiiere de configurare s fie incluse n snort.conf
indicat n linie de comand. Acesta funcioneaz ntr-un mod asemntor ca cel din limbajul
59
de programare C(#include); citete coninutul fiierului numit i l adaug n locul n care
declaraia apare n fiier.
7.2.2 Variabile
IP-urile pot fi specificate individual, ntr-o lista, sub forma unui bloc CIDR sau sub
orice combinaie 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 !.
Urmtorul exemplu va include IP-ul 1.1.1.1 i pe cele de la 2.2.2.0 pn la 2.2.2.255,
cu excepia 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]
11
Acest tip de variabil este folosit pentru support IPv6.
60
Exemplele ce urmeaz redau nite utilizri invalide:
contradicii logice:
negaii fr sens:
[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
condiia de a aduga la nceputul numelui PORT_ sau la sfrit _PORT.
Urmtorul exemplu ilustreaz utilizrile valide a ambelor variante:
portvar EXAMPLE1 80
var 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;)
61
Utilizri greite sunt urmrtoarele:
contradicii logice:
var EXAMPLE8 80
alert tcp any $EXAMPLE8 -> any any (msg:"Example"; sid:4;)
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 -, aa
cum este descris n tabelul urmtor:
7.3 Preprocesoarele
62
Preprocesoarele au fost introduse n versiunea 1.5. Acestea permit funcionaliti
extinse. Codul acestora este rulat nainte ca motorul de detecie s-i intre n rol, dar dup ce
pachetul a fost decodat. Pachetul poate fi modificat sau analizat folosind mecanismele
implementate. Preprocesoarele sunt ncrcate i configurate folosind cuvntul cheie
preprocessor. Acesta se folosete astfel:
deframentarea IP : frag3;
reasamblarea TCP : stream5;
normalizarea pachetelor;
date sensibile;
specifice unor diverse protocoale: http, smtp, ftp, ssh ,pop, etc;
atacurile de recunotere: sfPortscan.
7.3.1 Frag3
Frag3 folosete structurile date de tip sfxhashi liste nlnuite pentru managementul intern
al datelor, lucru ce permite atingerea unor performane 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 reea a intruziunilor.
Ideea de baz este aceea de a modela obiectivele actuale ale reelei n locul modelrii doar a
protocoalelor i cutrii de atacuri n cadrul acestora. Cnd stivele IP sunt scrise pentru
diferite sisteme de operare, acestea sunt de obicei implementate de ctre persoane care citesc
RFC-uri care apoi scriu propria interpretare a ceea ce RFC-ul prezint n cod. Din pcate,
exist ambiguiti n definiiile date de RFC-uri pentru unele din condiiile de margine ce pot
s apar, iar cnd acest lucru se ntmpl 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 aa fel nct
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 informaii
despre host-urile int dect IDS, este posibil s treac de controalele acestuia.De aici a pornit
idea acestui tip de analiz.
63
7.3.2 sfPortscan
Acest modul dezvoltat de Sourcefire, este conceput pentru a detecta prima faz a unui
atac asupra unei reele: recunoaterea.n acest faz, un atacator determin ce tipuri de
protocoale sau servicii sunt folosite de un anumit host. Acesta este momentul tradiional n
care are loc o scanare a porturilor. Aceast faz presupune c atacatorul nu are nici o
informaie legat de protocoalele sau serviciile suportate de ctre int, n caz contrar, aceast
etap nu ar mai fi necesar. Din cauza acestui fapt, cele mai multe cereri trimise de ctre
atacator vor fi negative(ceea ce nseamn c porturile sunt nchise). n natura unor reele de
comunicaii legitime, rspunsurile negative din partea host-urilor sunt rare, dar i mai rare
sunt apariiile multiple ale acestora ntr-un interval scurt de timp. Obiectivul principal al
acestei detecii este de a detecta i urmri aceste rspunsuri negative.
HTTP Inspect este un decodor generic http pentru aplicaiile utilizatorului. Avnd un
buffer de date, acesta va decoda acest buffer, va gsi cmpurile http pe care apoi le va
normaliza. Inspecteaz att cererile client, cti rspunsurile server.
Versiunea actual are n vedere doar prelucrarea fr stri. Acest lucru nseamn c
inspectarea se face pachet cu pachet, existnd posibilitatea unei nelri n cazul n care
pachetele nu sunt reasamblate. Aceasta funcioneaz bine atunci cnd exist un alt modul ce
se ocup cu reasamblarea, dar exist limitri n analiza protocolului. Versiunile viitoare vor
aveaun modul de procesare de tip stateful.
Acest modul permite utilizatorului o configuraie variat. Utilizatorii pot configura
serverele http individuale cu o varietate deopiuni, lucru care ar trebui s permit utilizatorului
emularea oricrui tip de server de web. Exist dou zone deconfigurare: global i server.
Dependine
Configuraie
preprocessor sensitive_data:
64
Opiune Argument Necesar Implicit Explicaii
alert_threshold < numr> Nu Alert_threshold 25 Preprocesorul va alerta orice combinaie
PII detectat ntr-o sesiune.Opiunea
specific cte trebuie detectate nainte
de alertare.Ar trebui setat o valoare
mai mare dect cea mai mare valorea
individual din regulile sd_pattern
mask_output - Nu Inactiv Acest opiune nlocuiete toi digiii 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 fiier> nu Inactiv Modulul poate fi updatat cu noi valori
de SSN-uri prin furnizarea unui fiier de
tip CSV.n mod implicit Snort-ul
recunoate toate SSN-urile emise pn
n noiembrie 2009.
Tabelul 7.4 Opiunile pentru configurarea preprocesorului de date sensibile
Exemplu:
Configurarea regulilor
Regulile sunt utilizate pentru a specifica ce tip de date( PII) trebuie cutat de ctre
preprocesor. O nou opiune este disponibil o data cu introducerea acestui modul:
sd_pattern.
Aceast opiune specific ce tip de date trebuie detectat.
Este utilizat urmtoarea sintax:
sd_pattern:<count>, <pattern>;
count = 1 - 255
pattern = any string
Opiune Explicaie
count Specific de cte ori un pattern trebuie s regsit pentru a se genera o alert.Numrul este
urmrit n toate pachetele dintr-o sesiune
credit_card Face match pe numere de card de credit de 15-16 digii.Aceste numere
pot avea spaii, puncte sau nimic ntre grupuri de digii.Astfel sunt
pattern acoperite tipurile de carduri Visa, MasterCard, Discover i American
Express.Numerele regsite sunt verificate folosind algoritmul Luhn.
65
us_social Este specific numerelor sociale de securitate americane de 9 digii
us_social_nodashes Pattern folosit pentru SSN-uri ce nu au delimitatori( ex: punct).
email Folosit pentru email-uri.
Tabelul 7.5 Opiunile pentru configurarea sd_pattern
Dac se dorete folosirea unui alt pattern dect cele preconstruite, se poate defini unul
propriu folosind o sintax regex disponibil, dar destul de limitat.Sunt suportate urmtoarele
caractere i secvene:
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 secvene de un numr de ori.
? marcarea ca opional a caracterului sau secvenei anterioare
\\ potrivire pe semnul \
\{, \} potrivire pe semnele { , }
\? potivire pe semnul ?
Tabelul 7.6 Sintaxa regex suportat
Exemplu de de regul:
66
Exista o mare diferen de abordare ntre semnturile realizate pentru Snort i
semnturilealtor IDPS-uri concurente. SourceFire ncearc s neleag vulnerabilitile pentru
care apoi s scrie semntura pentru aceasta, nu pentru exploatarea n sine. Astfel dac sunt
create mai multe variante de exploatri pentru aceiai vulnerabilitate, Snort-ul va fi capabil s
le blocheze pe toate. Cel mai bunexemplu este viermele Conficker. Acesta a aprut n21
Noiembrie 2008, la 2 luni dup ce Microsoft a anunat vulnerabilitatea MS08-067( remote
codeexecution). Prima variant a virusului putea fi detectat de Snort cu definiiile din 2006
datorit asemnrii cu o vulnerabilitate de atunci cu cea exploatat de Conficker:
August 7, 2006: Microsoft a lansat un buletin de securitate MS06-040 n legtura cu o
vulnerabilitate remote code execution gsit n Microsoft Windows Server Service;
August 9, 2006: Sourcefire a lansat reguli care s protejeze mpotriva a toate
exploatrilor vulnerabilitii MS06-040;
Octombrie 23, 2008: Microsoft a lansat un buletin de securitate MS08-067 n legtura
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 exploatrilorvulnerabilitii MS08-067;
Noiembrie 21, 2008: Viermele Conficker.A este identificat. Regulile Sourcefire
publicate att n August 9, 2006 ct i n Octombrie 23, 2008 sunt activate de
Conficker.A din cauza similaritii celor 2 vulnerabiliti;
Noiembrie 29, 2008: Viermele Conficker.B este identificat. Aceasta variant este
corect identificat de semnturile Snort iniiale.
Martie 4, 2009: Viermele Conficker.C este identificat. Aceasta variant este corect
identificat de semnturile Snort iniiale.
67
Figura 7.7- Exemplu pachet RPC
Stare comunicaiei
flow:to_server,established;
68
Cmpurile relevante
Trebuie cutat cantitatea de date de autorizare trimis pentru a putea sri peste
acestea. Este stocat ntr-un cmp de 4 octei. Acesta este citit i se sare peste
cte date sunt n cmpul respectiv:
byte_jump:4,4,relative,align;
Urmtorul cmp ce trebuie ignorat este cmpul de verificare. Mrimea acestuia
este specificat ca i n cazul de mai sus ntr-un cmp special.Este citit
mrimea i se sare peste numrul de octei specificat:
byte_jump:4,4,relative,align;
Dup aceti pai se ajunge n momentul n care se poate vedea cte date sunt
trimise ctre program.Aceast informaie se afl n primii 4 octei, imediat
dup sfritul cmpului de verificare. Se citete dimensiunea datelor
transmise ctre program, iar dac aceast dimensiune este prea mare, mai
maredect ar trebui s primeasc n mod normal programul, poate reprezenta
o posibil ncercare de overflow. n acest caz se verific dac sunt transmii
mai mult de 128 de octei; n cazul c da este generat o alert.
byte_test:4,>,128,0,relative;
69
7.4.1 Scriererea Regulilor
Aciunea regulii
Pot fi definie tipuri de reguli proprii crora li se poate asocia unul sau mai multe tipuri
de ieire.Pot fi utilizare aciunile prezentate mai sus.
Urmtorul exemplu creaz un tip ce va realiza doar o logare de tip tcpdump:
ruletype suspicious
{
type log
output log_tcpdump: suspicious.log
}
70
Protocoale
TCP
UDP
ICMP
IP
Pe viitor se urmrete i implementarea altora: ARP, IGRP, GRE, OSPF, RIP, IPX, etc.
Adresele IP
Porturile
Numerele de port pot fi specificate n mai multe moduri, prin any, definiii statice
sau intervale, folosind orice valoare dorit din intervalul 0 65535.
Operatorul direcie
Se folosete pentru a identifica direcia pachetului pe care regula trebuie aplicat( IP-ul i
portul surs sunt considerate a fi cele din stnga, iar cele destinaie, n dreapta operatorului).
Este folosit sub dou forme: ->, unidirecional( de la surs la destinaie) i <>, bidirecional
cnd se iau n considerare spre analiz perechi de adrese IP i port. Nu poate fi folosit sub
forma <-.
7.4.3. Opiunile unei reguli
71
n continuare sunt prezentate cteva din opiunile disponibile:
sid (signature id): identificator unic pentru regul; este obligatoriu. Pentru sid exist
urmtoarele recomandri:
sid < 100 este rezervat;
100 < sid < 1.000.000 pentru regulile oficiale SourceFire;
sid > 1.000.000 pentru regulile create de user.
classtype: clasific tipul de atac ntr-o clas generic. Acestea sunt definite n
classification.config;
alert tcp any any -> any any (sid: 1000003; msg:pachet
tcp; flags:SA+;)
72
alert icmp any any -> any any (msg:PING with TTP
100;ttl:100; sid: 1000004;)
alert icmp any any -> any any (msg:tos diferit de 1;tos:!1;
sid: 1000005;)
alert icmp any any -> any any (msg:Pachet cu biii more
fragment i dont fragment setai;fragbits:MD+;sid:
1000006;)
alert tcp any any -> any 111 (sid:1000007; content: |00 01 86
a5|; msg: external mountd access;)
73
itype: testeaz tipul ICMP;
session: datele utilizatorului sunt extrase din sesiunile TCP i printate n alerte.
Un threshold se poate include ntr-o regul sau se poate defini de sine stttor referindu-se
la sid-ul regulii.
74
Figura 8.1 - Snort inline
8.2 Iptables
75
3. MANGLE este responsabil cu modificarea biilor QOS din headerul TCP
Pre-routing: face NAT atunci cnd adresa destinaie 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 lanul de care va aparine.
La aceast regul este o singur exceptie: cele mai multe reguli sunt legate de filtrare, astfel
iptables presupune c orice lan definit fr o tabel asociat va face parte din tabela filter.
Tabela filter este, prin urmare, implicit.
ACCEPT: iptables oprete procesarea ulterioar; pachetul este trimis ctre aplicaie
sau sistem de operare pentru prelucrare;
DROP : iptables oprete procesarea ulterioar; pachetul este blocat;
LOG: informaiile sunt trimise la daemonul syslog pentru logare; iptables continu
procesarea pachetului;
REJECT: funcioneaz 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 ateptare pentru o procesare ulterioar de ctre
modul sau alt aplicaie extern;
DNAT: Rescrie adresa IP destinaie a pachetului;
SNAT: Rescrie adresa IP sursa a pachetului
MASQUERADE : Folosit pentru SNAT; n mod implicit adresa IP surs este aceeai
cu cea utilizat de interfaa firewall-ului
76
Figura 8.2 Funcionare Iptables
77
Parametru Utilizare
-t <tabel> Dac nu se specific o tabel, tabela filter este aleas n mod implicit
-j <target> Salt la lanul int specificat n momentul pachet se potriveste cu regula actual.
-A \ -append adugarea unei reguli la sfritul 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 destinaie
-i <nume interfe> Potrivire cu interfaa de reea prin care intr pachetul
-o <nume interfa> Potrivire cu interfaa de reea prin care iese pachetul
-m state <stare> Strile pot fi: ESTABLISHED, NEW, RELATED, INVALID
78
Prin aceste comenzi sunt introduse cte o regul nou n lanurile INPUT i OUTPUT
din cadrul tabelei Filter n prima poziie, 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 ctre Snort,
acestea le dispune tot ntr-o coad, de unde sunt preluate de ctre modulul iptables, care, n
funcie de etichetarea realizat de Snort( allow / drop /reject) va realiza aciunea pertinent
pentru fiecare pachet.
Pentru revenirea la funcionarea normal a acestui model se dau urmtoarele comenzi
ce terg toate regulile din lanurile selectate( tabela filter):
iptables -F INPUT
iptables -F OUTPUT
Pentru apelarea oricror comenzi legate de acest modul sunt necesare drepturi de
administrator.
Lansarea n execuie
Att Snort-ul, ct i plugin-ul sunt lansai n execuie de ctre un script: snorting.sh.
Acesta are trei funcionaliti, configurabile prin cele trei opiuni disponibile:
1. start. Prin aceast opiune este lansate n execuie Snort-ul. Pe lng acestea, este
configurat i serviciul Iptables, folosind comenzile prezentate n seciunea de mai sus
pentru lucrul cu Snort.
2. stop. Cu ajutorul acestei opiuni modulul Iptables este readus la starea normal de
funcionare.
3. print <nr>. Cu ajutorul acestei opiuni pot fi vizualizate ultimele alerte trimise de
Snort ctre server-ul Syslog.
79
8.3 Arhitectura de reea utilizat
80
1. Pachetul intr n Decoder cu scopul de a identifica tipul de pachet i ce protocoale
sunt folosite fr ns a decoda i datele la nivel de aplicaie. Pachetele cu
checksum greit pot fi oprite;
2. Pachetele fragmentate trebuie asamblate nainte pentru ca regulile viitoare s fie
aplicate eficient.Normalizarea pachetelor ajut motorul de cutare al Snort-ului s
verifice pachetul mai rapid;
3. D
u Figura 8.6 - Drumul unui pachet prin Snort
p ce au fost decodate, asamblate i normalizate, pachetele ajung la motorul
principal, undesunt verificate dup nite reguli;
4. Alertele generate de pachete se duc n pluginul de output pentru a fi furnizate
administratoruluisau aplicaiilor.
n cadrul Snort-ului exist dou etape n care se poate face prevenia i detecia
scurgerilor date:
Detecie n ambele faze se bazeaz pe coninut. Diferena major ntre acestea este
dat de faptul c n cadrul celei de-a dou exist mult mai multe opiuni disponibile pentru
configurare i scrierea regulilor. Dup cum s-a menionat i n prezentarea preprocesorului,
opiunea sd_pattern, punctul central al regulilor specifice acestuia, nu este compatibil cu nici
o alt opiune.
n ambele cazuri, detecia se realizeaz cu ajutorul expresiilor regulate. Pentru regulile
generale, acest lucru se configureaz cu ajutorul opiunii pcre( perl compatible regular
expressions), o librrie de funcii ce implementeaz modele de potrivire folosind aceiai
sintax i semantic utilizat de Perl 5. Sintaxa utilizat ofer mai multe capabiliti dect cele
oferite de opiunea sd_pattern.
12
Snort
81
Numere Regexp Regexp Da Nu
carduribancare
Email Regexp Regexp Da Da
Tabelul 8.7 Detecia i verificarea datelor sensibile
13
Predefinit
82
GET /index.php HTTP/1.1 HTTP/1.1 200 OK
Host: www.facebook.com Cache-Control: private, no-cache, no-store, must-
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en- revalidate
US; rv:1.9.2.17) Gecko/20110422 Ubuntu/10.04 Expires: Sat, 01 Jan 2000 00:00:00 GMT
(lucid) Firefox/3.6.17 P3P: CP="Facebook does not have a P3P policy.
Accept: Learn why here: http://fb.me/p3p"
text/html,application/xhtml+xml,application/xml;q= Pragma: no-cache
0.9,*/*;q=0.8 path=/; domain=.facebook.com; httponly
Accept-Language: en-us,en;q=0.5 Content-Encoding: gzip
Accept-Encoding: gzip,deflate Content-Type: text/html; charset=utf-8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 X-FB-Server: 10.146.68.118
Keep-Alive: 115 X-Cnection: close
Connection: keep-alive Transfer-Encoding: chunked
Date: 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 conine cererea GET ctre site-ul n cauz. Pentru a nu filtra toate pachetele i a
evita ntrzierile inutile, se va verifica doar antetul pachetelor http ce pleac de la Client ctre
portul 80 al server-ului web.
Este posibil o filtrare dup coninut conform modelelor prezentate mai jos:
n cazul portului Https, care funcioneaz cu encripie, blocarea i filtrarea este mai complicat
de realizat.
83
Comunicaia folosind Https-ul ncepe cu o negociere de protocol n care se stabilete
cheia de sesiune, dup care totulfuncioneaz criptat.Astfel o filtare dup coninut nu este
posibil.
Protocolul Https avea la nceput o mic problem n sensul c nu comunica corect
validitatea certificatului serverelor care aveau implementate serviciul de Virtual Hosting(mai
multe domenii ce folosesc acelai IP). Astfel un site care folosea Https-ul era necesar s aib
un IP unic; nu era posibil gzduirea mai multor site-uri Https pe acelai IP, iar validarea
certificatului s funcioneze n mod corect. Motivul principal este dat de faptul c atunci cnd
primul pachet de Client Hello ajungea la server, acesta nu avea cum stie ce site
se vrea servit pentru a furniza corect certificatul corect. Astfel a aprut nevoia ca un
Client Request s conin i acest amnunt pentru ca un server s poat gzdui mai multe site-
uri HTTPS pe acelai IP i s poat identifica din timp ce domeniu este accesat pentru a
furniza certificatul corect.
sdfsdf
sdfsdAstfel n RFC4366 a aprut o extensie la TLS denumitServer Name Indication unde
este specificatn 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 pcate nu este de ajuns pentru a bloca accesul la un site ce folosete 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 primete napoi Server Hello mai ncearc de cteva ori. Dac nici dup aceste
ncercri nu reuete 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 n
continuare accesat. Din aceasta cauz trebuie blocate aceste versiuni ale protocolului SSL
deoarece nu mai sunt foarte folosite, iar majoritatea server-elor i clienilor 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
opiuni specifice SSL-ului cum ar fi ssl_version, care ajut la identificarea versiunii
84
protocolului i ssl_state folosit la identificarea tipului depachet din handshake-ul
SSL(Server Hello, Client Hello, etc).
Astfel Snort este instruit s porneasc preprocesarea pachetelor ssl de pe portul 443, s
nu mai atepte i Server Reply-ul din sesiunea SSL pentru a considera comunicaia
criptat(trustservers) i s nu inspecteze pachetele la nivel de aplicaie pentru ca ele oricum
sunt criptate i pot genera falsuri pozitive(noinspect_encrypted ).
Astfel, pachetele vor fi decodate i normalizate i vom putea folosi funcii 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;)
byte_jump:2,44,align;
Se va sri peste cei 44 de octei din payload, se vor citi 2 octei ce reprezint lungimea
85
cmpului cu cifruri, se va transforma n numr ntreg i se va sri peste acel numr de octei
care n cazulacesta este 72. Astfel ne vom poziiona exact n fata cmpului Compression
Methods Length.Va trebui citit lungimea acestui cmpului i omii acei octei
byte_jump:0,1,relative,align;
Se sare peste cmpul unde se descrie Extension Length-ul i se caut n urmtorii doi
octeii dac apare0000, numrul extensiei Server Name Indication:
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;
Pasiv
86
Activ
Simple Mail Transfer Protocol (SMTP) este protocolul standard folosit pentru
transmisia mesajelorelectronice. Serverele de mail comunic prin acest protocol pentru a
transmite mesajele. Protocolul folosete caractere ASCI pentru transmiterea mesajelor fcnd
intercepia i decodarea acestora extrem de uor. Portul folosit este 25.
87
O regul ce scaneaz tot traficul de SMTP n cutarea stringului topsecret este
urmtoarea:
Problema vine atunci cnd vrem s transmitem i date care nu sunt text, cum ar fi un
executabil. Pentru a trece peste acest problem a aprut MIME(Multipurpose Internet Mail
Extensions) n care sunt definitenite 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.17E136F0
Content-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 folosete doar 64 de caractere, astfel 6 bii per caracter sunt de ajuns n loc de
8biti ct sefolosesc n mod normal. Astfel un string trebuie scris n mod binar, mprit n
buci de cte 6 bii, iapoi folosind tabelul de conversie Base64,se transform fiecare calup
de cte 6 bii 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
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
88
Figura 8.16 - Alfabetul Base64
Un caracter adugat n faa sau n spatele irului de caractere cutat va schimba total
codare acestuia, deci cutarea dup iruri codate nu este o soluie. Singura soluie este gsirea
i decodareatraficului base64 i de-abia dup aceea efectuat cutarea.
Snort-ul are incluse funcii de decodare, singura problema rmnnd doar calibrarea
exact a locului de unde s nceap decodarea, o greeala de 1 bit rezultnd n nite caractere
decodate totaldiferit fa de cele reale.
Regula urmtoare decodeaztraficul base64 calibrnd pointer-ul exact de unde ncepe
traficul codat i apoi caut dup caracterele topsecret:
Syslog : alertele sunt trimise sub acest standard ctre un server specializat;
89
Cmpurile principale sunt: nivelul facilitii, nivelul de severitate i mesajul n sine.
Nivelul facilitii este utilizat pentru a specifica ce tip de program a logat mesajul. Acest
lucru permite ca n fiierul de configurare al unui sistem s se specifice cum s fie manipulate
logurile dup acest nivel.
90