Universitatea Politehnica din Bucureti

Facultatea de Electronic, Telecomunicaii i Tehnologia Informaiei

Sistem de detecie i prevenire a intruziunilor ntr-o

reea

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

Conductor tiinific

Absolvent

Conf.dr.ing. Mihai STANCIU

Alin-Florentin Oprea

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 po
ta 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.

2.Principiile deteciei i preveniei intruziunilor

Detectare intruziunilor reprezint procesul de monitorizare a evenimentelor ce au loc ntrun sistem informatic sau ntr-o reea, precum i analizarea acestora pentru semne ce indic
incidente posibile ce sunt nclcri sau ameninri iminente de nclcare a politicilor de
securitate ale calculatorului, a politicilor acceptate de utilizare sau practicile de securitate
standard. Incindentele pot avea multe cauze, ca malware-urile(ex: worms, spyware), atacatori
externi ce ncearc s obin accesul neautorizat la sistem precum i utilizatori autorizai ce
ntrebuineaz greit privilegiile oferite sau ncearc s obin unele adiionale ce nu sunt
autorizate. Cu toate c majoritatea incindentelor sunt de natur maliioas, multe altele nu
sunt: de exemplu, o persoan poate introduce greit adresa unui calculator, i astfel,
neintenionat s acceseze un alt sistem fr autorizaie.
Prevenirea intruziunilor presupune detectare i ncercarea de a opri incidente posibile
detectate.
Un sistem de detecie a intruziunilor este un software ce automatizeaz procesul de
detecie.
Un sistem de prevenire a intruziunilor este un software ce are toate capabilitile
sistemului de detecie, dar care poate s ncerce s opreasc eventualele incindente.
Sistemele de detectare i prevenire ( IDPS1) se concentreaz n principal pe :
identificarea posibilelor incidente;
logare de informaii despre aciunile ntreprinse;
ncercarea de stopare a incidentelor i raportarea acestora la administratorii de
securitate.
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.

2.1 Utilizarea tehnologiilor IDPS

Scopul principal al IDPS-urilor este identificarea posibilelor incindente.De exemplu,
un IDPS poate detecta cnd un atacator a compromis cu succes un sistem prin exploatarea
vulnerabilitilor sale. Poate raporta apoi incindetul administratorilor de securitate, care pot
iniia aciuni de rspuns pentru a minimiza daunele cauzate de incident2.
Multe astfel de sisteme pot fi configurate s identifice:
violrile politicilor de securitate(ex: setarea cu seturi de reguli asemntoare unui
firewall, permind identificarea traficului ce ncalc normele de securitatea ale unei

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 notifica
i
de atac.Este important de
tiut dac
inta a avut o vulnerabilitate cunoscut pe care atacatorul ar fi putut s o
exploateze.Asupra respectivei vulnerabilit
i pot fi lansate alte atacuri pe care IDPS nu le poate recunoa
te.

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:
identificarea problemelor politicilor de securitate: poate oferi indicaii asupra calitii
controlului oferit de implementarea politicilor de securitate existente( ex: duplicarea
regulilor firewall i alertarea traficului ce ar fi trebuit blocat de ctre firewall, dar din
cauza unor erori de configurare nu a fost blocat;
documentarea amenirilor existente asupra organizaiei: logarea informaiilor legate
de ameninrile ce sunt detectate ajut la identificarea caracteristicilor i frecvenei
diverselor atacuri asupra resurselor computaionale ale organizaiei.Astfel, pot fi
adoptate msurile adecvate pentru protejarea resurselor existente;
descurajarea diverselor persoane n a nclca politicile de securitate: aciunea de
monitorizare a tehnologiilor descurajeaz violarea normelor de securitate din cauza
riscului de detecie.
Din cauza dependenei tot mai sporite fa de sistemele informaionale precum i
potenialul impact al intruziunilor asupra acestor sisteme, IDPS-urile au devenit un plus
necesar pentru infrastructura de securitate a oricrei organizaii.

2.2 Funciile cheie ale tehnologiilor IDPS

Exist multe tipuri de tehnologii, ce sunt difereniate n principal dup tipurile de
evenimente pe care le pot recunoate i metodologiile pe care le utilizeaz pentru identificarea
incidentelor. n plus fa de monitorizarea i analizarea evenimentelor pentru a identifica
activitile nedorite, toate tehnologiile efectueaz de obicei urmtoarele funcii:
nregistrare informaiilor referitoare la evenimentele observate. Informaiile sunt
de obicei nregistrate la nivel local, i ar putea fi, de asemenea, trimise la sisteme
separate, cum ar fi serverele centralizate de log, soluiile informaionale de securitate
i de management al evenimentelor (SIEM) sau soluii i sisteme enterprise de
management;

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;

ntocmirea de rapoarte. Rapoartele rezum evenimentele monitorizate sau ofer

detalii cu privire la anumite evenimente de interes.
Unele IDPS-uri au posibilitatea de a-i schimba profilul de securitate atunci cnd o
nou ameninare este detectat. De exemplu, ar putea fi capabil s colecteze mai multe
informaii referitoare la o sesiune n special dup ce este detectat activitatea malware n acea
sesiune. Ar putea modifica, de asemenea, diverse setri atunci cnd anumite alerte sunt
declanate sau ce prioritate ar trebui asignat alertelor ulterioare deteciei unei ameninri
deosebite.
Aciunile de rspuns iniiate n cazul deteciei unor atacuri se grupeaz astfel:
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 mediului de securitate. IDPS-ul putea schimba configuraia altor
controale sau dispozitive de securitate pentru a ntrerupe un atac. Exemple comune
sunt reconfigurarea unui dispozitiv de reea (firewall, router, switch) pentru a bloca
accesul ctre atacator sau int, precum i modificarea unui firewall de tip host-based
pentru a bloca atacurile primite. Unele tehnologii pot provoca chiar instalarea unor
patch-uri pe un anume host n cazul n care se detecteaz c acesta are vulnerabiliti;
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.

2.3 Metodologii comune de detecie

Sunt utilizate mai multe metodologii pentru a detecta incidentele.Principalele clase de
detecie sunt bazate pe:
Semnturi;
Anomalii
Analiza protocoalelor de tip stateful
Cele mai multe tehnologii IDPS utilizeaz metodologii de detecie multiple, fie
separat, fie integrate, pentru asigurarea unei detecii ct mai largi i mai precise.

2.3.1 Detecia bazat pe semnturi

O semntur reprezint un model ce corespunde unei ameninri cunoscute. Detecia
bazat pe semnturi este procesul de comparare a semnturior mpotriva evenimentelor
observate pentru a identifica posibilele incidente.Exemple de semnturi:
O ncercare de conexiune telnet cu numele de utilizator "root"(reprezint o nclcare a
politicii de securitate a unei organizaii);
Un email cu un subiect de genul "Imagini gratuite!" i un fiier ataat cu numele
"freepics.exe", care sunt caracteristici ale unei forme cunoscute de malware;
Un log al sistemului de operare, cu o valoare de cod de stare 645, ceea ce indic faptul
c auditul gazdei a fost dezactivat.
Acest tip de 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.

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.

2.3.2 Detectarea anomaliilor

Detecia anomaliilor reprezint procesul de comparare a definiiilor activitilor ce
sunt considerate normale cu definiiile acelor evenimente observate pentru a identifica
abaterile semnificative. Un IDPS ce folosete detectia anomaliilor deine nite profiluri ce
reprezint comportamentul normal al utilizatorilor, host-urilor din reea, conexiunilor la reea
sau al aplicaiilor. Profilurile sunt dezvoltate prin monitorizarea caracteristicilor activitii
tipice ntr-o perioad de timp. De exemplu, un profil de reea ar putea arta ca activitatea web
cuprinde o medie de 14% din banda de reea n timpul orelor tipice de lucru. Sunt folosite
apoi metode statistice pentru a compara caracteristicile activitii curente cu pragurile
specifice din profil, cum ar fi detectarea momentului n care activitatea web folosete mult
mai mult lime de band dect este ateptat, alertnd apoi administratorul. Profilurile pot fi
dezvoltate pentru mai multe atribute comportamentale, cum ar fi numrul de email-uri trimise
de un utilizator, numrul de ncercri de autentificare euate realizate de ctre un host, precum
i nivelul de utilizare al procesorului pentru un host ntr-o anumit perioad de timp.
Beneficiul major al metodelor bazate pe detecia anomaliilor este c acestea pot fi
foarte eficiente n detectarea ameninrilor necunoscute anterior. De exemplu, s presupunem
c un calculator este infectat cu un nou tip de malware. Malware-ul poate consuma resursele
de procesare ale computerului, trimind un numar mare de email-uri, iniiaz foarte multe
conexiuni la reea, fiind astfel caracterizat de un comportament total diferit fa de profilul
stabilit calculatorului respectiv.
Un profil iniial este generat dup o perioad de timp(cteva zile, uneori sptmni),
numit perioad de formare. Acesta poate fi static sau dinamic. Odat generat, un profil static
rmne neschimbat, cu excepia cazului n care IDPS-ul va genera un nou profil. Un profil
dinamic se ajusteaz n mod constant pe msur ce sunt observate evenimente suplimentare.
Deoarece sistemele de calcul i reelele se schimb n timp, msurile corespunztoare unui
comportament normal, de asemenea, se modific; un profil static va deveni n cele din urm
inexact, aa c va trebui regenerat periodic. Profilurile dinamice nu au aceast problem, dar
acestea sunt sensibile la tentativele de evaziune folosite de ctre atacatori. De exemplu, un
atacator poate efectua ocazional un numar mic de activiti malware, apoi crete ncet
frecvena i numrul activitilor. n cazul n care rata de schimbare este suficient de mic,
IDPS-ul ar putea crede activitatea de malware ca fiind un comportament normal i s l
includ n profilul su. Activitatea de malware ar putea fi, de asemenea, obervat de ctre un
IDPS n timp ce construiete profilurile sale iniiale. Includerea neintenionat a activitilor
malware, ca parte a unui profil, este o problem comun. n unele cazuri, administratori pot
modifica profilul s exclud activitatea ce este cunoscut drept duntoare din profil.

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.

2.3.3 Analiza protocoalelor de tip stateful

Reprezint procesul de compararea a profilurilor prestabilite ale definiiilor, general
acceptate, ale activitilor benigne ale protocoalelor pentru fiecare stare de protocol mpotriva
evenimentelor observate pentru a identifica deviaiile. Spre deosebire de detecia anomaliilor,
care folosete profiluri specifice host-urilor sau reelei, aceast analiz se bazeaz pe profiluri
universale, dezvoltate de diveri furnizori ce specific modul n care ar trebui s fie utilizate
sau nu anumite protocoale.Stateful nseamn c IDPS-ul este capabil s neleag i s
urmreasc starea protocoalelor specifice nivelului reea, transport sau aplicaie, n cazul celor
care au noiunea de stare. De exemplu, atunci cnd un utilizator ncepe o sesiune de FTP( File
Transfer Protocol ), sesiunea este iniial ntr-o stare neautentificat. Utilizatorii neautentificai
ar trebui s efectueze doar cteva comenzi n aceast stare, cum ar fi vizualizarea informaiilor
de ajutor sau furnizarea de nume de utilizator i parole. O parte important a nelegerii strii
este asocierea cererilor cu rspunsuri, astfel nct atunci cnd are loc o tentativ de
autentificare FTP, IDPS-ul poate determina dac acesta a fost de succes prin cutarea codului
de stare n rspunsul corespunztor. Odat ce utilizatorul a fost autentificat cu succes,
sesiunea este n stare autentificat, ateptndu-se de la utilizatori efectuarea oricrei comenzi
dintr-un grup. Efectuarea celor mai multe dintre aceste comenzi n stare neautentificat vor fi
considerat suspecte, dar n stare autentificat efectuarea celor mai multe dintre ele este
considerat benign.
Pot fi identificate secvene neateptate de comenzi, cum ar fi emiterea unei comenzi n
mod repetat sau emiterea unei comenzi fr a emite n primul rnd o comand de care aceasta
depinde. O alt caracteristic de urmrire este aceea c pentru protocoale care efectueaz
autentificare, poate fi urmrit autentificatorul pentru fiecare sesiune i s fie nregistrat pentru
activiti suspecte. Acest lucru este util atunci cnd se investigheaz un incident. Unele IDPSuri pot utiliza informaiile autentificatorului pentru a defini activiti acceptate pentru diferite
clase de utilizatori sau pentru anumii utilizatori.
Aceast analiz include, de obicei, controale rezonabile asupra unor comenzi
individuale, cum ar fi lungimea minim i maxim de argumente. Dac o comand are, de
obicei, un nume de utilizator ca argument format din maxim 20 de caractere, atunci un
argument cu o lungime de 1000 de caractere este suspect. n cazul n care argumentul cu o
lungime mare conine date binare, gradul de suspiciune va crete.
Sunt utilizate modele de protocol, ce sunt de obicei bazate n principal pe standardele
de protocol de la furnizori de software i organismele de standardizare (ex: Internet
Engineering Task Force [IETF] Request for Comments [RFC]). Modelele de protocol iau n

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.

2.4 Tipuri de tehnologii IDPS

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:
La nivel de reea: monitorizeaz traficul de reea pentru anumite segmente de reea
sau dispozitive, analiznd activitile protocoloalelor de reea i aplicaie pentru a
identifica activiti suspecte. Se pot identifica diferite evenimente de interes. Este
amplasat de cele mai multe ori la o grani ntre reele, cum ar fi n apropierea
firewall-urilor sau routerelor, serverelor de reea virtual privat (VPN), serverelor de
acces de la distan i reelelor fr fir;

Figura 2.1 Tehnologii IDPS

Fr fir: monitorizeaz traficul de reea fr fir i analizeaz protocoalele sale de reea

pentru a identifica activiti suspecte care implic protocoalele ni. Nu poate
identifica activiti suspecte ce implic protocoale de nivel aplicaie sau de transport (
TCP, UDP), n traficul de reea fr fir ce este transferat. i desfoar activitatea de
monitorizare, cel mai frecvent, n raza de aciune a reelei fr fir a unei organizaii;
Analiza comportamentului de reea (Network Behavior Analysis - NBA):
examineaz traficul de reea pentru a identifica ameninrile care genereaz fluxuri de
trafic neobinuit, cum ar fi blocarea distribuit a unui serviciu (DDoS), anumite forme
de malware( viermi, backdoors) i nclcri ale politicii (ex: un sistem client ce
furnizeaz servicii de reea pentru alte sisteme). Sistemele NBA sunt cel mai adesea
utilizate pentru a monitoriza fluxurile de pe reelele interne ale unei organizaii, i
sunt, de asemenea, uneori, utilizate pentru a monitoriza fluxurile ntre reelele unei
organizaii i reelele externe;
La nivel de host: monitorizeaz caracteristicile unei singur host i evenimentele care
au loc n acel host pentru activiti suspecte.Tipurile de caracteristici urmrite sunt:
traficul de reea(numai pentru gazda respectiv), logurile de sistem, procesele active,
activitile aplicaiilor, accesul la fiiere precum i modificarea acestora, schimbarea
configuraiei sistemului sau a unor aplicaii. Sunt cel mai frecvent utilizate pe gazde
critice, cum ar fi servere accesibile n exterior sau servere care conin informaii
sensibile.
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

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.
n termeni generali, atacurile de tip DoS se realizeaz pe mai multe ci:
provocarea unui reset forat al calculatorului sau al mai multor calculatoare;
consumarea intens a resurselor disponibile ale unui server, astfel nct acesta s nu
mai poat furniza servicii;
blocarea comunicaiilor dintre utilizatorii bine intenionai i calculatorul victim,
astfel nct acesta s nu mai poat comunica adecvat;
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
3.1 Componente i arhitectur
3.1.1 Componente tipice
Componentele tipice ale unei soluii IDPS sunt:
Senzor sau agent. Senzorii i agenii monitorizeaz i analizeaz activitatea de
reea.Termenul senzor este folosit de obicei pentru IDPS-urile care monitorizeaz
reelele, incluzndu-le pe cele la nivel de reea, fr fir, i cele bazate pe tehnologii de
analiz a comportamentului de reea. Termenul agent este de obicei folosit pentru
tehnologii IDPS la nivel de host.
Server de management. Un server de management este un dispozitiv care
centralizeaz i gestioneaz informaiile primite de la senzori sau ageni. Unele servere
de management analizeaz informaiile furnizate de ctre senzori sau ageni, existnd
astfel posibilitatea de a identifica evenimente pe care senzorii sau agenii nu le pot
detecta. Potrivirea informaiilor de la mai muli senzori sau agenti, pentru gsirea, de
exemplu, a evenimentelor declanate de aceeai adres IP, este cunoscut sub numele
de corelare. Serverele de management sunt disponibile att ca instrumente hardware,
dar ca i produse software. Serverele de management sunt comune celor mai multe
implementri IDPS, existnd posibilitatea unor servere multiple, sau chiar dou nivele
de astfel de servere.
Server de baze de date. Un server de baze de date este un repozitoriu alctuit din
informaii nregistrate de ctre senzori, ageni, i / sau servere de management.
Consol. O consol este un program care ofer o interfa pentru utilizatorii i
administratorii IDPS-ului. Acest software este de obicei instalat pe desktop-uri sau
laptop-uri standard. Unele console sunt utilizate doar pentru administrare(configurare
de senzori sau ageni i aplicarea unor actualizri de software), n timp ce alte console
sunt folosite strict pentru monitorizare i analiz. Unele console ofer att
administrare, ct i monitorizare.

3.1.2 Arhitectura de reea

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.

3.2 Capabiliti de securitate

3.2.1 Culegerea informaiilor
Unele tehnologii IDPS ofer capacitatea de colectare de informaii cu privire la hosturile sau reelele monitorizate. Exemplele includ identificarea gazdelor, a sistemelor de
operare i aplicaiilor pe care le folosesc, i identificarea caracteristicilor generale ale reelei.

3.2.2 Capabiliti de logare

IDPS-urile efectueaz de obicei logarea datelor legate de evenimentele detectate.
Aceste date pot fi utilizate pentru a confirma validitatea alertelor, investigarea incidentelor, i
corelarea cu alte surse de logare. Cmpurile de date utilizate n mod obinuit de ctre IDPSuri includ data i ora evenimentului, tipul de eveniment, evaluare importanei( prioritate,
severitate, impact, ncredere) i aciunile de prevenire ntreprinse (dac este cazul). Anumite
tipuri de IDPS logheaz cmpuri de date suplimentare, cum ar fi capturi de trafic. Logurile
sunt stocate la nivel local i sunt trimise n acelai timp copii ctre servere centralizate de
log.n general, logurile trebuie pstrate att la nivel local, ct i central pentru a
susine integritatea i disponibilitatea datelor.De asemenea, sistemele ar trebui s aib
ceasurile sincronizate folosind protocolul NTP (Network Time Protocol) sau prin ajustri
manuale frecvente, astfel nct logurile s fie nregistrate cu o or i dat ct mai exact.

13

uc Use Case Model

Log

include

include
include

include

Timestamp

Tipul alertei/
ev enimentului

Rating(
prioritate,
sev eritate
,impact)

include

Detalii (IP,port,
etc)

Actiunea
intreprinsa

Figura 3.1 Cmpurile unui log

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:
Praguri. Un prag este o valoare ce stabilete limita ntre un comportament normal i
anormal. Pragurile specific, de obicei, un nivel acceptabil maxim, cum ar fi N
ncercri euate de conectare n 60 de secunde, sau N caractere pentru lungimea unui
nume de fiier. Pragurile sunt cel mai adesea utilizate de detecia bazat pe anomalii i
cea bazat pe analiza protocoalelor de tip stateful;
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, URLuri, 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;
Setarea alertelor. Se permite administratorilor personalizarea fiecrui tip de alert.
Exemple de aciuni care pot fi efectuate pe un tip de alert includ urmtoarele:
o Oprirea sau pornirea3;
o Setarea unei anume prioriti sau nivel de severitate;
o Specificarea informaiilor ce ar trebui nregistrate i a metodelor de
notificare(ex: email);
o Specificarea aciunilor de preventive ce ar trebui ntreprinse.
Unele produse suprim alertele n cazul n care un atacator genereaz mai
multe alerte ntr-o perioad scurt de timp, i poate, de asemenea, ignora temporar tot
traficul viitor de la atacator. Se realizeaz acest lucru pentru a preveni copleirea cu
alerte a IDPS-ului;
Vizualizare i editare de cod. Unele tehnologii permit administratorilor s vad unele
poriuni sau tot codul ce realizeaz detecia. Acest lucru este de obicei limitat la
semnturi, dar unele tehnologii permit administratorilor vizualizarea unor poriuni
suplimentare, cum ar fi programele ce efectueaz analiza protocoalelor stateful.
Vizualizarea codului i poate ajuta pe analiti n a determina de ce au fost generate
anumite alerte, ajutnd la validarea alertelor i identificarea falsurilor pozitive.
Abilitatea de a edita codul i scrie cod nou (ex: noi semnturi) este necesar pentru o
personalizarea complet n cazul anumitor tipuri de capaciti de detectare. De
exemplu, o anumit alert ar putea fi generat de o serie complex de evenimente care
implic mai multe module de cod; configurarea unui IDPS s neleag organizarea
specific unor caracteristici nu ar putea fii posibil fr a edita codul. Editarea codului
necesit abiliti de programare i de detecie a intruziunilor; se folosesc de cele mai
multe ori limbaje de programare proprietare, ceea ce ar necesita nvarea unor noi
limbaje de ctre programator. Bug-urile introduse n cod n timpul procesului de
personalizare ar putea provoca sistemul s funcioneze incorect sau deloc.Aadar,
administratorii ar trebui s trateze personalizarea codului ca pe orice alt modificare a
codului sistemelor de producie.
Administratorii ar trebui s revizuiasc setrile de tuning i particularizare periodic pentru
a se asigura c acestea sunt nc exacte. De exemplu, listele albe i listele negre ar trebui
verificate n mod regulat, iar toate intrrile validate pentru a se asigura c acestea sunt n
continuare corecte i necesare. Pragurile i setrile alertelor ar putea avea nevoie de ajustri
periodice pentru a compensa schimbrile din reea sau apariia unor noi ameninri.
Modificrile aduse codului de detecie ar putea avea nevoie s fie reprodus ori de cte ori
produsul este actualizat (ex: aplicarea de patch-uri).

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
Dup ce IDPS-ul a fost ales, administratorii trebuie s implementeze o arhitectur, s
testeze, poziioneze i s securizeze componentele.

3.3.1.1 Design-ul arhitecturii

Primul pas n implementarea unui astfel de sistem este design-ul arhitecturii.
Consideraiile arhitecturale includ:
Unde trebuie plasai senzorii/agenii;
Ct de sigur ar trebui s fie soluia aleas i ce msuri ar trebui luate pentru a atinge
nivelul cel mai nalt, prin poziionare unor senzori multiplii ce monitorizeaz aceeai
activitate n cazul n care unul dintre ei cade sau folosirea unor servere de management
multiple, astfel nct un server de backup poate fi utilizat n cazul n care serverul
primar nu mai este disponibil;
Unde vor fi amplasate celelalte componente IDPS (servere de management, servere de
baze de date, console) i cte componente din fiecare clas sunt necesare pentru a
atinge gradul de utilizare optim i redundan;
Cu care alte sisteme IDPS-ul trebuie s interacioneze, inclusiv urmtoarele:
o Sisteme crora li se furnizeaz date, cum ar fi software-uri de management al
evenimentelor i al informaiilor de securitate, servere de log centralizate,
servere de e-mail;
o Sistemele ce iniiaz aciuni de prevenire (firewall-uri, routere, switch-uri);
o Sisteme care gestioneaz componentele IDPS, cum ar fi software-ul de
management de reea (pentru o reea de management) sau software-ul de
management al patch-urilor (pentru pstrarea sistemelor de operare al
consolelor i aplicaiilor actualizate).
Dac va fi utilizat sau nu o reea de management; dac da, ce design va avea, n caz
contrar, cum vor fi protejate comunicaiile IDPS n cadrul reelelor standard;

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

Organizaiile ar trebui s ia n considerare implementarea componentelor ntr-un
mediu de testare n primul rnd, pentru a reduce riscul de probleme de implementare ce pot
perturba reelele de producie. Atunci cnd componentele sunt utilizate n reelele de
producie, organizaiile trebuie s activeze iniial doar civa senzori sau ageni, cu
capacitile de prevenire dezactivate. Pentru c o implementare nou va genera, cel mai
probabil, un numr mare de alarme false pn cnd tuning-ul i personalizarea sunt complete,
activarea mai multor senzori sau ageni deodat ar putea coplei serverele de management i
consolele, ceea ce face dificil tuning-ul. Multe falsuri pozitive pot fi de acelai tip n cadrul
senzorilor/agenilor, astfel, este util identificarea acestora, n timpul procesului de testare sau
atunci cnd sunt amplasai primii senzori sau ageni, astfel nct aceste rezultate pot fi
redresate nainte de extinderea pe scar larg. O implementare treptat a senzorilor sau a
agenilor este, de asemenea, de ajutor n identificarea potenialelor probleme cu scalabilitate.
Implementarea poate necesita scurte ntreruperi de reea sau de sistem pentru instalarea
componentelor.
Componentele hard sunt de obicei uor de instalat. Administratorii ar putea fi nevoii
s efectueze actualizri de software sau actualizri de semnturi. n general, trebuie conectate
la o surs de curent i la reea, pornite i apoi efectuate anumite configurri de baz (ex:
introducerea unei chei de licen de produs, atribuirea unui nume senzorului).
Componentele software necesit, de obicei, mai mult timp pentru implementare.
Trebuie achiziionat mai nti hardware-ul adecvat, suficient de solid pentru a susine IDPSul, care ar putea include plci de reea cu o lime de band mare. Apoi, administratorii
trebuie s instaleze un sistem de operare compatibil pe care apoi s-l actualizeze, mpreun cu
toate serviciile, aplicaiile i software-urile instalate.
Dup amplasarea componentelor IDPS un efort considerabil ar putea fi necesar pentru
a configura capabilitile de detecie i prevenire, n funcie de tipul sistemului. Fr
parcurgerea acestui pas, sistemele ar putea fi limitate doar la detecia unui numr mic de
atacuri vechi i uor de identificat.

3.3.1.3 Securizarea componentelor

Asigurarea componente sistemului este foarte important, deoarece acestea sunt
adesea vizate de atacatori. n cazul n care un atacator poate compromite un IDPS, acesta va fi
inutil n detectarea atacurilor ulterioare mpotriva altor host-uri. De asemenea, acestea conin
informaii sensibile, cum ar fi configuraiile host-urilor i vulnerabiliti cunoscute care ar
putea fi de ajutor n planificarea atacurilor suplimentare. Urmtoarele specificaii de securitate
sunt recomandate:
Administratorii trebuie s creeze conturi separate pentru fiecare utilizator i
administrator, precum i atribuirea numai a privilegiilor necesare;
Administratorii trebuie s configureze firewall-urile, routerele, precum i alte
dispozitive de filtrare a pachetelor pentru a limita accesul direct la toate componentele
IDPS numai pentru acele gazde care au nevoie de un astfel de acces;
Administratorii trebuie s se asigure c toate comunicaiile de management sunt
protejate n mod corespunztor, fie fizic (reeaua de management), fie logic(VLAN de
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

Aproape toate produsele de acest gen sunt proiectate pentru a fi exploatate i
ntreinute printr-o interfa grafic(GUI), cunoscut sub numele de consol. Consola permite
administratorilor configurarea i actualizarea senzorilor i serverelor de management, precum
i monitorizarea strii lor. Administratorii gestioneaz conturile de utilizator, personalizeaz
rapoarte i efectueaz multe alte funcii utiliznd consola. Utilizatorii pot efectua multe funcii
prin consola, inclusiv monitorizarea i analizarea datelor, precum i generarea de rapoarte.
Cele mai multe IDPS-uri permit administratorilor crearea de conturi de utilizator individuale
pentru fiecare administrator i utilizator i acordarea fiecrui cont numai privilegiile necesare
pentru rolul fiecrei persoane. Consola reflect de multe ori acest lucru artnd diferite
meniuri i opiuni bazate pe privilegiile contului autentificat.
Unele produse ofer o interfa n linie de comand( CLI). Spre deosebire de
interfeele grafice, care sunt de obicei utilizate pentru gestionarea de la distan a senzorilor/
agenilor i serverelor de management, CLI-urile sunt de obicei utilizate pentru gestionarea
local a acestor componente. Uneori, este permis realizarea unei conexiune criptate la
distan de CLI, realizate prin SSH( Secure Shell) sau prin alte mijloace. Consolele sunt de
obicei mult mai uor de utilizat dect CLI-urile, dar ofer adesea doar o parte din
funcionalitatea acestora.

3.3.2.1 Utilizarea tipic

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

Administratorii ar trebui permanent s aplice urmtoarele soluii se mentenan:
Monitorizarea componentelor pentru prevenirea problemelor operaionale i de
securitate ce le-ar putea include;
Verificarea periodic a funcionaliti;
Realizarea de evaluri periodice ale vulnerabilitilor;
Primirea de notificri ale unor eventuale probleme de securitate din parte
productorilor componentelor IDPS(incluznd sistemele de operare, precum i
aplicaiile non-IDPS) i rpunsul corespunztor la aceste notificri;
Primirea de notificri din partea productorilor IDPS-ului legate de update-urile pe
care administratorii le pot testa i apoi aplica sistemului.

3.3.2.3 Achiziia i aplicarea update-urilor

Exist dou tipuri de actualizri: actualizri de software i actualizri de semnturi.
Actualizrile de software rezolv bug-urile n software sau adaug noi funcionaliti, n timp
ce actualizrile semnturilor adaug capaciti de detecie noi sau rafineaz capabilitile de
detecie existente (ex: reducerea falsurilor pozitive). Actualizrile de semnturi cauzeaz
modificri sau nlocuiri n codul programului, fiind astfel o form specializat de actualizare a
software-ului. Pentru alte IDPS-uri, semnturile nu sunt scrise n cod, astfel nct un update de
semnturi reprezint o modificare a datelor de configurare.
Actualizrile de software pot include oricare sau toate componentele, inclusiv senzori,
ageni, servere de management i console. Actualizrile de software pentru senzori i servere
de management, n special pentru dispozitivele de tip appliance, sunt adesea aplicate prin
nlocuirea unui CD existent, de pe care ruleaz software-ul, cu unul nou, urmat de repornirea
dispozitivului. Multe IDPS-uri ruleaz software-ul direct de pe CD, astfel nct nu este
necesar instalarea software-ului. Alte componente, cum ar fi agenii, necesit intervenia
unui administrator pentru instalarea software-ului sau aplicarea patch-urilor, fie manual, pe
fiecare dispozitiv sau automat, prin intermediul software-ului de management din sistem. Unii
furnizori pun la dispoziie pe site-urile proprii de web sau pe alte servere, actualizrile de
software i semnturile . Administratorii dispun deobicei de feature-uri ce downladeaz i
instaleaz asementea update-uri.
Este necesar o verificare a integritii actualizrilor nainte de aplicarea acestora,
pentru c acestea ar fi putut fi, accidental sau intenionat, modificate sau nlocuite. Metoda de
verificare recomandat depinde de formatul actualizrii, dup cum urmeaz:
Fiierele descrcate de pe un site web sau server FTP. Administratorii ar trebui s
compare sumele de control ale fiierelor, furnizate de ctre productor, cu sumele de
control pe care le calculeaz local, dup descrcare;
Actualizare descrcate automat printr-o interfaa IDPS. Dac o actualizare este
descrcat ca un singur fiier sau un set de fiiere, sumele de control furnizate de
vendor ar trebui comparate cu sumele de control generate de administrator ori interfaa
n sine ar trebui s efectueze un fel de verificare a integritii. n unele cazuri,
actualizrile ar putea fi descrcate i instalate ntr-o singura aciune, mpiedicnd

19

verificarea sumei de control; interfaa ar trebuie s verifice integritatea fiecrei

actualizri ca parte integrant a acestei aciuni de instalare;
Medii de stocare detaabile(ex: CD-uri, DVD-uri). Furnizorul nu poate prevede o
metod specific pentru clieni pentru a verifica legitimitatea acestor medii, aparent
trimise de ctre acetia. Dac verificarea reprezint o preocupare, administratorii ar
trebui s contacteze furnizorii pentru a determina modul n care acestea pot fi
verificate, cum ar fi compararea sumelor de control furnizate de vendori cu sumele de
control calculate local pentru fiierele de pe mediul de stocare sau verificarea
semnturilor digitale pentru coninut pentru validare. Administratorii ar trebuie s ia
n considerare i scanare contra malware-uri, cu avertismentul c falsurile pozitive ar
putea fi declanate de ctre semnturile IDPS-ului.
IDPS-urile sunt de obicei proiectate astfel nct aplicarea actualizrilor de software i
semnturi nu va avea nici un efect asupra tuning-ului i setrilor. Excepie face personalizarea
codului, care de cele mai multe ori trebui refcut atunci cnd sunt instalate actualizri de cod
de la furnizor. Pentru orice sistem, administratorii ar trebui s realizeze un backup periodic i
nainte de a aplica actualizrile pentru a se asigura c setrile existente nu sunt pierdute
accidental.
Este recomandat testarea actualizrilor nainte de aplicarea acestora, cu excepia
situaiilor de urgen ( ex: o semntur identific o nou ameninare activ care duneaz
organizaiei i nu poate fi altfel detectat sau blocat). Este benefic existena cel puin a unui
senzor/agent(pentru fiecare tip) sau host, care s fie utilizat strict pentru testarea actualizrilor.
Capabilitile noi de detectare pot provoca de multe ori un numr mare de alerte, astfel nct
testarea actualizri de semnaturi pe un singur senzor/agent, chiar i pentru scurt timp,
(ncrcarea actualizrii i observarea modului n care funcioneaz sistemul cnd sunt
monitorizate activitile tipice), poate ajuta la identificarea semnturilor care sunt susceptibile
a fi problematice i ar trebui s fie ntr-un final dezactivate. n situaii non-urgente,
actualizrile ar trebui s fie testate i implementate folosind aceleai practici care sunt folosite
pentru actualizarea altor dispozitive sau software-uri de securitate, cum ar fi firewall-urile i
software-urile antivirus. Cnd actualizrile sunt implementate n producie, administratorii ar
trebui s fie pregtii pentru a dezactiva anumite semnturi sau a efectua alte reconfigurri
minore, dup cum este necesar.

3.3.3 Competene de construire i mentenan

Diferite competene sunt necesare pentru implementarea, operarea i mentenana
IDPS-urilor, incluzndu-le pe cele ce urmeaz:
Administratorii ce implementeaz componentele trebuie s neleag elementele de
baz ale administrrii sistemului , reelei i ale securitii informaiei;
Cei responsabili de tuning i personalizare este necesar s aib cunotine destul de
cuprinztoare legate de securitatea informaiei i principiile unui sistem de prevenie i
detecie a intruziunilor ntr-o retea mpreun cu ntelegerea protocoalelor de reea, a
aplicaiilor i a sistemelor de operare ce urmeaz a fi monitorizate.De asemenea, este

20

recomandat o nelegere a principiilor de rspuns la incidente, precum i a politicilor

i procedurilor de rspuns la incidente ale organizaiei;
Cunotinte de programare ar putea fi, de asemenea, necesare pentru personalizri
extinse de cod, scrierea de rapoarte i alte sarcini.
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;
Servicii profesionale. Unii furnizori ofer servicii profesionale, ce sunt n esen
servicii de consultan prestate de ctre vnztor. De exemplu, o organizaie ar putea
plti un furnizor pentru a scrie semnturi particularizate sau rapoarte sau pentru a ajuta
administratorii n ntelegerea modului de a regla i personaliza senzorii n mod
eficient;
Comuniti de utilizatori. Unele produse au comuniti de utilizatori activi, care de
obicei funcioneaz prin liste de mailing sau forumuri online. Utilizatorii pot face
schimb de informaii i cod unul cu altul, ajutndu-se reciproc n probleme de
depanare. Dei comunitile de utilizatori pot fi o surs de informare, cei care folosesc
aceste mijloace trebuie s fie precaui cnd le utilizeaz, deoarece postarea unor detalii
legate de configurarea i problemele unui IDPS aparinnd unei organizaii, ar putea
neintenionat s dezvluie informaii sensibile legate de infrastructura de securitate,
sistemul i reelele unei organizaii.

21

4. IDPS-uri la nivel reea

4.1 Stiva TCP/ IP
ARPANET, strmoul tuturor reelelor de calculatoare, a fost o reea de cercetare
sponsorizat de ctre DoD (U.S. Department of Defense). n cele din urm, reeaua a
ajuns s conecteze ntre ele, utiliznd linii telefonice nchiriate, sute de reele universitare i
guvernamentale. Dup introducerea ulterioar a reelelor prin satelit i radio, interconectarea
acestora cu protocoalele existente a pus diferite probleme. Era nevoie de o nou arhitectur de
referin.Astfel, posibilitatea de a interconecta fr probleme mai multe tipuri de reele a
reprezentat de la bun nceput un obiectiv de proiectare major. Aceast arhitectur a devenit
cunoscut mai trziu sub numele de modelul de referin TCP/IP, dat dup numele celor
dou protocoale fundamentale utilizate.
Astfel, TCP (Tranmission Control Protocol) are rolul de mprire a datelor n
pachete i asigur transmiterea corect a mesajelor ntre host-uri. Pachetele sunt numerotate,
putndu-se verifica primirea lor n forma n care au fost transmise i reconstituirea mesajelor
lungi, formate din mai multe pachete.
IP (Internet Protocol) asigur livrarea pachetelor numai dac n funcionarea reelelor
nu apar erori. Dac un mesaj este prea lung, IP cere fragmentarea lui n mai multe pachete.
Transmiterea pachetelor IP se face ntre calculatoare gazd i nu direct ntre programele de
aplicaie.
Spre deosebire de modelul de referin OSI, modelul TCP/IP este format din 4
niveluri:
Figura 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
Modelul TCP/IP nu conine nivelurile sesiune sau prezentare.Experiena modelului
OSI a dovedit c aceast viziune a fost corect: n majoritatea aplicaiilor, nivelurile
respective nu sunt de mare folos. Aceasta conine
toate protocoalele de nivel mai nalt. Aa cum se
vede n figura 4.3, primele protocoale de acest gen
includeau terminalul virtual (TELNET), transferul
de fiiere (FTP) i pota electronic (SMTP).
Protocolul de terminal virtual permite unui
utilizator de pe o main s se conecteze i s
lucreze pe o main aflat la distan. Protocolul de
transfer de fiiere pune la dispoziie o modalitate
TCP/IP
de a muta eficient date de pe o main pe alta.
Pota electronic a fost la origine doar un tip de
transfer de fiiere, dar ulterior a fost dezvoltat un
protocol specializat
(SMTP Simple Mail Transfer Protocol)
Figura 4.3 - Protocoale Aplicaie
pentru acest serviciu. Pe parcursul anilor, la
aceste protocoale s-au adugat multe altele, aa cum sunt Serviciul Numelor de Domenii
(Domain Name Service - DNS) pentru stabilirea corespondenei dintre numele gazdelor i
adresele reelelor, HTTP, folosit pentru aducerea paginilor de pe Web i multe altele.

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
computerele
care comunic, ci faptul c
TCP/IP
segmentele nivelului Aplicaie cltoresc
bidirecional ntre dou gazde care sunt conectate
logic pentru o anumit perioad. Acest proces este
cunoscut sub denumirea de packet switching.
Figura 4.4 - Protocoale Transport
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 ntrebarerspuns, 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.

Figura 4.5 Relaiile ntre protocoale

Nivelul internet
ngrijorarea principal a Departamentului de Aprare American dupa proeictarea
ARPANET era c o parte din preioasele sale gazde, rutere i dispozitive de interconectare ar
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
reea).Pachetele
pot chiar s soseasc ntr-o
TCP/IP
ordine diferit fa de cea n care au fost
trimise, caz n care rearanjarea cade n
sarcina nivelurilor superioare. De observat
c ,,internet este folosit aici ntr-un sens
generic,
chiar daca acest nivel este prezent
Figura 4.6 - Protocoale IP
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.

Nivelul Acces la reea

TCP/IP

Pe acest nivel sunt definite standardele i

tehnologiile Ethernet IEEE 802.3, precum CSMA/CD i
10BASE-T.
Acest nivel se ocup cu toate serviciile pe care le
necesit un pachet IP pentru a realiza o legatur fizic,
incluznd i detalii legate de tehnologiile LAN i WAN,
de medii de transmisie, adic ceea ce fac nivelurile OSI
legtur de date i fizic.

Figura 4.7 - Nivelul Acces la Reea

25

FTP

HTTP

SMTP

DNS

DNS

TCP

TFTP

UDP

IP

INTERNET

LAN

Alte LAN i
WAN

Figura 4.8 - Protocoale TCP/IP

4.2 Componente i arhitectur

4.2.1 Componente tipice
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.

4.2.2 Arhitectura de reea i locaiile senzorilor

Organizaiile ar trebui s ia n considerare utilizarea reelelor de management pentru
implementarea IDPS-urilor la nivel reea dac este posibil. n cazul n care un IDPS este
implementat fr o reea de management separat, organizaiile trebuie s decid dac este
nevoie sau nu de un VLAN pentru a proteja comunicaiile interne.
n plus fa de alegerea reelei pentru componente, administratorii trebuie s decid
unde s fie amplasai senzori.Acetia pot fi utilizai ntr-unul din cele dou moduri:
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.

Figura 4.9 - Exemplu implementare senzori inline

Motivaia principal pentru implementarea senzorilor inline este de a le permite

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:
o Port de tip spanning. Multe switch-uri au un port de tip spanning; reprezint
un port care poate vedea tot traficul de reea ce trece prin switch. Conectarea
unui senzor la un astfel de port poate permite monitorizarea traficului din reea.
Dei aceast metod de monitorizare este relativ uor i ieftin de implementat,
ea poate fi problematic. n cazul n care un switch este configurat sau
reconfigurat incorect, portul de tip spanning ar putea s nu vad tot traficul. O
alt problem cu aceste porturi este c utilizarea lor duce la un consum mare de
resurse; atunci cnd un switch are de prelucrat un flux foarte mare de trafic,
este posibil ca portul s nu vad tot traficul, existnd posibilitatea chiar s fie
nchis. De asemenea, multe switch-uri dispun doar de un singur port de acest
tip, iar n cele mai multe cazuri trebuie conectate multe dispozitive de genul
uneeltelor de monitorizare, analiz i diagnosticare a traficului sau alte tipuri
de senzori IDPS ce trebuie s analizeze acelai traffic.
o Network Tap. Reprezint o conexiune direct ntre un senzor i reeaua fizic
de trafic.Este oferit astfel senzorului o copie a tot traficului de reea transportat
de dispozitivele fizice.Instalarea, n general, implic o perioad de
nefuncionare a reelei, iar eventuale probleme cu aceast metod ar putea
cauza perioade de nefuncionare suplimentare. De asemenea, spre deosebire de
porturile de tip spanning, ce sunt de obicei, deja prezente ntr-o organizatie,
aceste interceptoare trebuie s fie achiziionate i incluse ca add-ons la reea.
o IDS4 de tip Load Balancer. Reprezint un dispozitiv care agregheaz i
direcioneaz traficul de reea ctre sisteme de monitorizare, inclusiv ctre
senzori IDPS. Poate primi copii ale traficului de reea de la unul sau mai multe
porturi de tip spanning sau interceptoare de reea, agregnd traficul din diferite
reele (ex: reasambleaz o sesiune care a fost mprit ntre dou reele). Copii
ale traficului sunt trimise apoi ctre unul sau mai multe dispozitive de
ascultare, pe baza unui set de reguli stabilite de ctre un administrator. Regulile
precizeaz ce tip de trafic direcioneaz ctre fiecare dispozitiv de ascultare.
Configuraiile comune includ urmtoarele:

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.

mprirea dinamic a traficului ntre mai muli senzori n

funcie de volum. Acest lucru se face se realizeaz pentru a efectua
o echilibrarea a sarcinilor, astfel nct nici un senzor s nu fie
suprancrcat.

mprirea traficului ntre mai muli senzori n funcie de

adrese IP, protocoale sau alte caracteristici. Acest lucru ar putea
fi fcut pentru echilibrarea a sarcinii, avnd de exemplu un senzor
dedicat activittii web i un alt senzor ce monitorizeaz toate
celelalte activiti. Divizarea traficului ar putea fi fcut pentru a
efectua o analiz mai detaliat a anumitor tipuri de trafic (ex:
activiti ce implic cele mai importante hosturi).

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

4.3.1 Culegerea informaiilor
Unele IDPS-uri la nivel reea ofer capabiliti limitate de culegere a informaiilor(
colectarea de informaii despre host-uri i activitatea de reea ce implic acele hosturi).Exemple de capabiliti de culegere a informaiilor sunt urmtoarele:
Identificarea host-urilor. Un senzor IDPS ar putea fi capabil s creeze o list cu hosturile din reeaua organizaiei grupate prin adresa IP sau adresa MAC. Lista poate fi
folosit ca un profil pentru a identifica host-urile noi din reea.
Identificarea sistemelor de operare. Un sensor este capabil s identifice sistemele de
operare i versiunile acestora utilizate de ctre computerele organizaiei prin diverse
tehnici. De exemplu, senzorul poate urmri ce porturi sunt utilizate pe fiecare host,
fapt ce ar putea indica un anumit sistem de operare sau o familie (ex: Windows, Unix).
Figura 4.10 - Exemplu de implementare senzori pasivi
O alt tehnic este de a analiza header-ul pachetului pentru anumite caracteristici
neobinuite sau combinaii de caracteristici care sunt setate de anumite sisteme de
operare; acest lucru este cunoscut sub numele de amprentare pasiv. Unii senzori pot
identifica, de asemenea, versiuni ale aplicaiilor, care n unele cazuri indic ce sistem
de operare este n uz. tiind ce versiuni de sisteme de operare sunt n uz poate fi de
ajutor n identificarea host-urilor potenial vulnerabile.
Identificarea Aplicaiilor. Pentru unele aplicaii, un senzor poate identifica versiunile
utilizate innd evidena porturilor folosite i monitoriznd unele caracteristici de
comunicare ale aplicaiei. De exemplu, atunci cnd un client stabilete o conexiune cu
un server, serverul ar putea spune clientului ce versiune a software-ului ruleaz i
invers. Informaii privind versiunile apliaiilor pot fi utilizate n identificarea
aplicaiilor potenial vulnerabile i a utilizrii neautorizate a unor aplicaii.

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.2 Capabiliti de logare

IDPS-urile de nivel reea efectueaz de obicei un logging extins legat de evenimentele
detectate. Aceste date pot fi utilizate pentru a confirma validitatea alertelor, pentru a investiga
incidentele i a corela evenimente cu alte surse de logare. Cmpurile de date nregistrate
includ urmtoarele:
Timestamp (de obicei, data i ora);
ID-ul conexiunii sau al sesiunii (de obicei un numr consecutiv sau unic atribuit
fiecrei conexiuni TCP sau unor grupuri de pachete corespunztoare protocoalelor fr
conexiune);
Tipul evenimentului sau alertei5;
Evaluare (prioritate, severitate, impactul, nivelul de ncredere);
Nivelul corespunztor protocolului:reea, transport, sau aplicaie;
Adresele IP surs i destinaie;
Porturile TCP/UDP surs i destinaie sau tipuri de ICMP i codurile aferente;
Numrul de octei transmii;
Datele decodate din ncrctura util( payload), cum ar fi cereri de aplicaii i
rspunsuri;
Informaiile de stare (ex: numele de utilizator autentificat);
Aciunea de prevenie ntreprins( dac este cazul).

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

Tipurile de evenimente cel mai frecvent detectate de senzori sunt:
Atacurile la nivelul aplicaie al stivei TCP.(ex: banner grabbing, buffer overflow,
format string attacks, password guessing , transmisie de malware). Sunt analizate
majoritatea protocoalelor speficice nivelului aplicaie. Includem aici: DHCP (Dynamic
Host Configuration Protocol), DNS (Domain Name Server) , Finger, FTP (File
Transfer Protocol), IMAP( Internet Message Access Protocol ), IRC( Internet Relay
Chat ), NFS( Network File System), POP( Post Office Protocol ), HTTP6, RPC(
Remote Call Procedura), SIP( Session Initiation Protocol), SMB( Server Message
Bloc), SMTP( Simple Mail Transfer Protocol), SNMP( Simple Network Management
Protocol), Telnet i TFTP( Trivial File Transfer Protocol ), precum i protocoalele
specific bazelor de date, aplicaii de mesagerie instant i software-uri peer-to-peer de
partajare de fiiere;
Atacurile la nivel transport (scanarea porturilor, fragmentare neobinuit a
pachetelor, inundaii(floods) cu SYN). Protocoalele cel mai des analizate sunt TCP i
UDP;
Atacurile la nivel internet/reea (adrese IP false, valorile ilegale n header-ul IP).
Protocoalele cel mai des analizate sunt IPv4, ICMP, i IGMP. Multe produse ofer
support i pentru analiza IPv6.Nivelul de analiz IPv6 difer de la un produs la
altul.Unele nu ofer nici un suport IPv6 sau doar alerteaz administratorii de prezena
activitii IPv6. Altele pot face o procesare de baz a activitii IPv6 i a traficului
IPv6 tunelat, cum ar fi nregistrare adreseleor IP surs i destinaie, precum i
extragerea ncrcturii utile (ex: HTTP, SMTP) pentru o analiz n profunzime. Unele
produse pot face o analiz complet a protocolului IPv6, cum ar fi confirmarea
validitii opiunilor IPv6, pentru identificarea utilizarrii anormale a protocolului;
Servicii/aplicaii neprevzute ( ex: protocoale de tunelare, backdoors, host-uri ce
ruleaz aplicaii/servicii neautorizate). Acestea sunt, de obicei, detectate prin analiza
protocoalelor de tip stateful, care poate determina dac activitatea dintr-o conexiune
este n concordan cu protocolul utilizat, sau prin metode de detectare a anomaliilor
ce pot identifica modificri ale fluxurilor de reea i porturile deschise;
nclcarea politicilor de securitate (ex: utilizarea de site-uri web nepotrivite,
utilizarea aplicaiilor interzise). Unele tipuri de nclcri ale politicii de securitate pot
fi detectate prin IDPS-uri, permind administratorilor s precizeze caracteristicile
6

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

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.
Exist posibilitatea monitorizrii negocierii iniiale efectuat la stabilirea comunicaiilor
criptate pentru a identifica software-ul client sau dac serverul are vulnerabilitati cunoscute
sau nu este configurat corect. Acest lucru poate include protocoale de nivel aplicaie, cum ar fi
SSH (Secure Shell) i SSL( Secure Sockets Layer), i protocoalele de nivel reea/ internet
folosite n reelele virtuale(ex: IPsec IP Security).
Senzori pot determina de multe ori dac un atac are anse de reuit. De exemplu, aa cum
este descris n seciunea 4.3.3.3, senzorii ar putea ti ce versiune de software de tip web server
se execut pe fiecare dintre servere web ale organizaiei. n cazul n care un atacator lanseaz
un atac mpotriva unui server de web, ce nu este vulnerabil la acest tip de atac, atunci senzorul
ar putea produce o alert cu o prioritate redus; n cazul n care serverul este considerat a fi
vulnerabil, atunci senzorul ar putea produce o alert de nalt prioritate. Senzorii sunt de
obicei configurai s opreasc toate atacurile indiferent dac sunt sau nu susceptibile n a
reui, dar sistemul ar putea loga evenimentele cu nivele de prioritate diferite, n funcie de
rezultatul lor, n cazul n care ar fi fost blocate.

4.3.3.2 Acurateea deteciei

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.

4.3.3.3 Tunning i customizare

Pentru a mbunti precizia de detecie este nevoie de un tunning i o personalizare
mai n detaliu. Exemple de capabiliti de personalizare i tuning sunt pragurile pentru
scanarea de porturi i ncercrile de autentificare ale aplicaiilor, listele negre i listele albe
pentru adrese IP i nume de utilizator, precum i setri de avertizare. Unele produse ofer i
funcionaliti de editare a codului, care este de obicei limitat la semnturi, dar, n unele
cazuri, este permis accesul la codul adiional, ca n cazul programele utilizate pentru a efectua
analiza protocoalelor de tip stateful.
Se pot utiliza informaiile legate de host-urile organizaiei pentru a mbunti precizia de
detecie. De exemplu, s-ar putea permite administratorilor specificarea adreselor IP utilizate
de serverele web ale organizaiei, servere de mail, i alte tipuri comune de host, precum i
tipurile de servicii oferite de fiecare host(tipul i versiunea aplicaie de server web). Acest
lucru permite sistemului o prioritizare mai bun a alertelor; o alert pentru un atac specific
serviciului Apache avnd ca int un server de web Apache ar avea o prioritate mai mare
dect acelai atac ndreptat ctre un alt tip de server web. Pot fi importate rezultatele
scanrilor vulnerabilitilor i apoi utilizate pentru a determina ce atacurile ar avea succes
dac nu ar fi blocate. Acest lucru permite luarea unor decizii mai bune i precise cu privire la
aciunile de prevenire i prioritizare a alertelor.

4.3.3.4 Limitri tehnologice

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:
Tipurile de protocoale n uz(aplicaie, transport, reea/internet) i profunzimea analizei
efectuate pentru fiecare protocol. Vendorii i evalueaz produsele bazndu-se pe
capacitatea lor de a efectua analize rezonabile asupra unui mix "tipic" de protocoale.
Nivelul de analiz pe care o organizaie dorete s o efectueze i tipurile de protocoale
utilizate pot varia considerabil fa de condiiile testate;
Longevitatea conexiuni. Un senzor poate avea un overhead mai sczut pentru o
conexiune pe termen lung, fa de cazul unor mai multe conexiunii pe termen scurt;
Numrul de conexiuni simultan.
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
Sunt oferite diverse capaciti de prevenire, inclusiv urmtoarele (grupate n funcie de
tipul de senzor):

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
Executarea de firewalling inline.Cei mai muli senzori ofera capabilitile unui
firewall, astfel poate dropa sau respinge activitile suspecte;
Reducerea limi de band. Dac un anumit protocol este utilizat necorespunztor,
ca n cazul unui atac DoS sau n distribuia unor malware-uri, unii senzori de linie
poate limita procentul de band de reea pe care protocolul respectiv l poate folosi.
Acest lucru mpiedic impactul negativ asupra limii de band n cazul utilizrii de
ctre alte resurse;
Modificarea coninutului maliios. Dup cum este descris n seciunea 1.2, unii
senzori inline poate cura o parte dintr-un pachet, coninutul ru intenionat este
nlocuit cu un coninut benign, pachetele dezinfectate fiind trimise apoi la destinaie.
Un senzor care acioneaz ca un proxy ar putea efectua o normalizarea automat a
ntregului trafic. Aceasta are ca efect eliminarea unor atacuri care implic antetele
pachetelor i unele antete aplicaie, indifferent dac IDPS-ul a detectat sau nu un atac.
Unii senzori pot elimina ataamente infectate din email-uri, precum i alte elemente
discrete de coninut malware din traficul n reea.
Pasiv & Inline
Reconfigurarea altor dispozitive de securitate. Muli senzori pot instrui diferite
dispozitive de securitate de reea, cum ar fi firewall-uri, routere, switch-uri pentru a se
reconfigura singure spre a bloca anumite tipuri de activiti sau s le plaseze pe alte
rute. Acest lucru poate fi util n mai multe situaii, cum ar fi pstrarea unui atacator
extern n afara reelei i trimiterea n carantin a unui host care a fost compromis (ex:
mutarea ntr-un VLAN carantin). Aceast tehnic de prevenire este util doar pentru
traficul de reea ce pot fi difereniat n funcie de caracteristicile header-ului
recunoscute de ctre dispozitive de securitate( adresele IP, numere de port;
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
Odat ce un produs a fost selectat, administratorii trebuie s proiecteze o arhitectur,
s efectueze testarea i asigurarea, iar apoi s le implementeze. Urmtoarele reprezint nite
completri la materialul prezentat n seciunea 3.3.1:
Designul arhitecturii. O atenie special trebuie acordat locului n care senzorii ar
trebui s fie plasai n reea, numrului de senzori necesari, ce senzori ar trebui s fie
pasivi sau de tip inline i modulului n care senzorii pasivi ar trebui s fie conectai la
reea;
Testarea i amplasarea componentelor. Implementarea unui astfel de sistem poate
necesita cderi scurte ale reelei scurte, n special atunci cnd sunt integrai senzori
inline. Totui, amplasarea senzorilor pasiv poate provoca de asemenea ntreruperi din
mai multe motive, incluznd instalarea interceptoarelor de reea, a IDS-urilor de tip
load-balancer i reconfigurarea switch-urilor pentru a activa porturile de tip span;
Securizarea componentelor. Administratorii trebuie s se asigure c pentru senzori
att pasivi, ct i cei inline nu au fost asignate adrese IP interfeelor de reea folosite
pentru a monitoriza traficul, cu excepia celor utilizate pentru management. Operarea
unui senzor fr adrese IP alocate pentru interfeele de monitorizare se numete
funcionare n mod invizibil(stealth mode). Acest mod mbuntete securitatea
senzorilor deoarece mpiedic alte host-uri n a iniia conexiuni cu acetia. Astfel, sunt
ascuni fa de atacatori, limitnd expunerea lor la atacuri. Cu toate acestea, atacatorii
ar putea fi n msur s identifice existena unui senzor i s determine ce produs este
utilizat prin analiza caracteristicilor aciunilor de prevenire. O astfel de analiz ar
putea include monitorizarea reelelor protejate i determinarea a cror tipuri de

37

modelelor de scanare ar putea declana rspunsuri particulare i ce valori sunt setate n

anumite cmpuri din antetul pachetelor.

4.5 Operare i mentenan

Operarea i ntreinerea se realizeaz n acelai mod prezentat n general n seciunea
3.3.2.

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.

5.1 Componente i Arhitectur

5.1.1 Componentele tipice
Cele mai multe IDPS-uri la nivel host au software-uri de detectare cunoscute sub
numele de 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 server. Pe lng monitorizarea sistemului de operare al serverului (OS), agentul
poate monitoriza, de asemenea, unele aplicaii comune;
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;
O aplicaie/ serviciu. Unii ageni monitorizeaz o aplicaie specific, cum ar fi un
program de server web sau un program de server de baze de date. Acest tip de agent
este de asemenea cunoscut ca un dispozitiv IDPS.
Cele mai multe produse nu dispun de 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.

Figura 5.1 - Arhitectura unui IDPS la nivel de host

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

Pentru a oferi funcionalitatea de prevenire a intruziunilor, cei mai muli ageni
modific arhitectura intern a host-urilor pe care sunt instalai. Aceast lucru se face de obicei
printr-o pan de fixare(shim), reprezentat printr-un strat de cod plasat ntre straturile
existente ale codului. Astfel, datele sunt interceptate la un punct n care aceastea ar fi fost n
mod normal trecute de la o bucat de cod la alta. n acest mod sunt analizate i se determin
dac ar trebuie permis trecerea lor mai departe. Aceasta metod poate fi folosit pentru mai
multe tipuri de resurse:
Traficul de reea
Activitatea sistemului de fiiere
Apeluri sistem
Activitatea regitrilor Windows
Aplicaii comune (ex: e-mail, web).
Unii ageni nu modific arhitectura intern. n schimb, ele monitorizeaz activitatea fr
pene de fixare sau analizeaz urme ale activitii derulate, cum ar fi logurile i modificrile de
fiiere. Dei mai puin intruzive fa de gazd, reducnd posibilitatea de a interfera cu
operaiunile normale ale gazdei, aceste metode sunt mai puin eficiente n detectarea
ameninrilor i de multe ori nu pot efectua vreo aciune de prevenie.
Una dintre cele mai importante decizii este reprezentat de alegerea tipului soluie IDPS,
ori de tip software, instalat pe gazd, ori de tip appliance. Din perspectiva deteciei i a
preveniei, instalarea de agenti pe gazde, este de preferat, deoarece agenii au acces direct la
caracteristicile gazdelor, de multe ori permindu-le s efectueze o detecie i o prevenie mai
complex i exact. Cu toate acestea, agenii sunt suportai doar de cteva sisteme de operare
comune; n cazul n care o gazd nu utilizeaz un sistem de operare acceptat, agentul de tip

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 Capabilitile de securitate

5.2.1 Logare
Logarea de date legat de evenimentele detectate este suportat i aici. Aceste date pot fi
utilizate pentru a confirma validitatea alertelor, pentru a investiga incidentele i a corela
evenimente cu cele din alte surse de logare. Cmpuri de date logate n mod obinuit includ
urmtoarele:

Timestamp (de obicei data i ora) ;

Evenimentul sau tipul alertei;
Evaluare (ex: prioritate, severitate, impact, nivelul de ncredere);
Detalii specifice evenimentului logat, cum ar fi adresa IP i portul, nume de fiiere i
cii, precum i ID-uri de utilizator;
Aciune de prevenie ntreprins (dac este cazul).

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.

5.2.2.1 Tipuri de evenimente detectate

Tipurile de evenimente detectate variaz substanial n funcie de tehnicile de detectare
folosite. Unele produse ofer mai multe tehnici de detectare, n timp ce altele se concentreaz
pe cteva sau una. De exemplu, se analizeaz doar traficul n reea sau se verific doar
integritatea fiierelor critice. Tehnicile specifice utilizate n mod obinuit sunt:
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.
o Analiza comportamental a codului. nainte de a fi rulat n mod normal,
codul poate fi executat n prim faz ntr-un mediu virtual sau ntr-un sandbox,
pentru o analiza a comportamentul su i pentru o comparare cu profiluri sau
reguli cunoscute a fi ru intenionate sau nu. De exemplu, atunci cnd o bucat

42

de cod este executat, s-ar putea ncerca obinerea unor privilegii la nivel de
administrator sau suprascrie un executabil de sistem;
o Detecia buffer overflow. ncercrile de a inunda bufferele sistemului pot fi
detectate prin cutarea caracteristicilor specifice, cum ar fi anumite secvene de
instruciuni ce ncearc s acceseze poriuni de memorie, altele dect cele
alocate pentru procesul respectiv;
o Monitorizarea apelurilor sistem. Agentul tie ce aplicaii i procese ar trebui
s utilizeze apelurile sistem i ce alte aciuni le este permis. De exemplu, un
agent poate recunoate un proces care ncearc s intercepteze ce se tasteaz,
cum ar fi un keylogger. Un alt exemplu este un agent ce limiteaz ncrcarea
obiectelor de tip COM( Component Object Model), permind unei aplicaii
PDA, dar nu i altor aplicaii, s acceseze agenda unui client de email. Poate fi
restricionat i ncrcarea unor anume drivere, prevenind astfel instalarea unor
rootkit-uri i a altor atacuri;
o Liste cu aplicaii i librrii. Un agent poate monitoriza fiecare aplicaie i
librrie (ex: DLL librrie dinamic de legtur), pe care un utilizator sau un
proces ncearc s le ncarce i compar aceste informaii cu listele de aplicaii
autorizate i neautorizate. Acest lucru poate fi folosit nu numai pentru a
restriciona utilizarea unor aplicaii i biblioteci, dar i pentru utilizarea unor
anume versiuni ale acestora.
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;
Monitorizarea sistemului de fiiere. Poate fi efectuat folosind mai multe tehnici,
inclusiv cele enumerate mai jos. Administratorii ar trebui s fie contieni de faptul c
unele produse i bazeaz monitorizarea pe nume de fiiere, aa c, dac utilizatorii
sau atacatori modific numele fiierelor, aceste tehnici ar deveni ineficiente;
o Verificarea integritii fiierelor. Acest lucru implic generarea periodic a
unui digest sau a unei alte sume criptografice pentru fiiere critice, comparea
cu valori de referin i identificarea diferenelor. Verificarea integritii
fiierelor poate stabili doar faptul c un fiier a fost deja modificat, cum ar fi
nlocuirea unui sistem binar cu un cal troian sau un rootkit;
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;
o ncercrile de acces la fiiere. Un agent cu o pan de fixare n sistem de
fiiere poate monitoriza toate ncercrile de a acces la fiiere critice( ex:
fiierele binare de sistem) i opri ncercrile care sunt suspecte. Agentul are un
set de politici privind accesul, astfel nct se compar aceste politici cu
caracteristicile ncercrii curente, ce utilizator sau aplicaie ncearc s
acceseze fiecare fiier, ce tip de acces a fost solicitat (citire, scriere,
executare)8. Acest lucru ar putea fi folosit pentru a preveni instalarea anumitor
forme de malware, cum ar fi rootkit-urile i caii troieni , sau a mai multor alte
tipuri de activiti ru intenionate care implic accesul la fiier, modificarea,
nlocuirea sau tergerea.
Analiza logurilor. Se pot monitoriza i analiza logurile sistemelor de operare i a le
aplicaiilor pentru a identifica activiti malware9. Aceste loguri pot conine informaii
despre evenimentele de sistem, ce aciuni operaionale sunt efectuate de componentele
sistemului de operare (ex: oprirea sistemului, nceperea unui serviciu); nregistrrile de
audit conin informaii despre evenimente de securitate, cum ar fi ncercrile reuite i
nereuite de autentificare i modificrile aduse politicilor de securitate; evenimentele
ce in de aplicaii: aciunile operaionale semnificative efectuate( pornirea i oprirea) ,
nefuncionri, precum i schimbri majore n configuraie;
Monitorizarea configuraiei reelei. Exist posibilitatea monitorizrii configuraiei
curente a reelei i detectarea modificrilor. De obicei toate interfeele de reea de pe
gazd sunt monitorizate, prin cablu, fr fir, din VPN-uri i conectate la modem.
Exemple de modificri semnificative de configurare de reea sunt plasarea interfeei n
mod promiscu, folosirea de porturi TCP / UDP suplimentare pe gazd sau utilizarea
unor protocoale de reea suplimentare, cum ar fi protocoalele non-IP. Aceste
modificri ar putea indica faptul c gazd a fost deja compromis i este configurat
pentru a fi utilizat n atacuri viitoare sau pentru transfer de date.
Deoarece aceste IDPS-uri au adesea cunotinte extinse despre caracteristicile i
configuraiile gazdelor, poate determina de multe ori dac un atac mpotriva gazdei va reui
dac nu este oprit. Ageni pot folosi aceste cunostinte pentru a selecta aciunile de prevenire i
de a atribui prioriti adecvate alertelelor.

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 desktopurilor / 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.

5.2.2.3 Tuning i Personalizare

Ca i n cazul celorlalte sisteme, este necesar tuning-ul i o personalizare
considerabil. De exemplu, multe se bazeaz pe observarea activitii gazdei i dezvoltarea
unor linii de baz sau profiluri de comportament ateptat. Altele trebuie s fie configurate cu
politici detaliate ce definesc exact comportamentul fiecrei aplicaii. De indat ce intervin
schimbri n mediul gazd, administratorii trebuie s se asigure c politicile sunt actualizate
pentru a lua aceste modificri n considerare. n general, nu este recomandat legarea
automat cu sistemele de management al schimbrilor, dar administratorii pot revizui
nregistrrile de gestionare a schimbrilor regulat i ajusta configuraia gazdei i politica de
informare din cadrul sistemului pentru a preveni alarmele false.
Politicile pot fi stabilite per-gazd sau pentru grupuri de gazde, fapt ce ofer
flexibilitate. Se poate permite configurarea mai multor politici pe o gazd pentru mai multe
medii; acest lucru este cel mai util pentru gazde care funcioneaz n mai multe medii, cum ar
fi un laptop folosit att n cadrul unei organizaii ct i din locaii externe. Sunt folosite i liste
albe i negre pentru host-uri ( ex: adresele IP ale altor gazde cu care o gazd ar putea
comunica), aplicaii, porturi, nume de fiiere i alte caracteristici ale gazdei. De fapt, unele
produse actualizeaz automat ageni cu cele mai recente informaii legate de listele albe i
neagre, pe baza rapoartelor de la ali ageni ce au detectat o nou activitate malware. O alt
trstur comun este personalizarea fiecrei alerte, cum ar fi specificarea opiuni de rspuns
ce ar trebui luat n cazul alertei respective.
Complexitatea capabilitilor bazate pe semnturi variaz foarte mult n funcie de
tehnicile de detectare folosite de fiecare produs.

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;
ntrzieri n centralizarea rapoartelor. Multe IDPS-uri la nivel de host transmit
datele de alert ctre serverele de management n mod periodic, nu ntr-un mod real.
Datele de alert sunt de obicei transferate n loturi la fiecare 15 sau 60 de minute
pentru a reduce overhead-ul componentelor i a reelei. Acest lucru poate provoca
ntrzieri n iniierea aciunilor de rspuns, mrind astfel impactul incidentelor care se
rspndesc rapid( ex: infestri malware);
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;
Conflicte cu controalele de securitate existente. Instalarea unui agent poate provoca
dezactivarea automat a controalelor de securitate existente pe gazd( firewall-uri
personale), n cazul n care aceste controale sunt percepute ca o duplicare a
funcionalitilor oferite de agent. Instalarea poate provoca conflicte i cu alte
controale de securitate, n special cu cele care folosesc penele pentru a intercepta
activitatea gazdei (firewall-uri personale, clieni VPN). Pentru a identifica eventualele
conflicte implementatorii ar trebui s testeze nti agenii pe gazde pe care se execut
acele controale de securitate;
Repornirea gazdelor. n cazul upgrade-urilor de tip software n cazul agenilor,
precum i n cazul ctorva modificri de configurare, agentul poate necesita repornirea
gazdelor monitorizate. Ca i n cazul altor probleme menionate anterior,
implementatorii ar trebui s efectueze teste extinse nainte de selectarea produselor i
s ia n considerare impactul pe care repornirea ar putea s o aib asupra eficacitii
agenilor (ex: agenii vor fi n imposibilitatea de a detecta cele mai recente ameninri
deoarece host-uri importante nu au putut fi repornite) .

46

5.2.3 Prevenia
Sunt oferite diverse capaciti de prevenire a intruziunilor. Deoarece capacitile
variaz n funcie de tehnicile de detectare folosite de fiecare produs, urmtoarele elemente
descriu aceste capabiliti de prevenie n funcie de tehnica de detectare folosit:
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;
Filtrarea traficului de reea. Funcionnd ca un firewall la nivel de host, poate opri
accesul neautorizat i nclcrile politicii de utilizare (ex: utilizarea de servicii externe
nepotrivite). Acesta este eficace numai mpotriva opririi activitilor ce sunt
identificabile prin adresa IP, portul TCP / UDP sau tipul i codul n cazul protocolului
ICMP;
Monitorizarea sistemului de fiiere. Acest lucru poate preveni fiierele n a fi
accesate, modificate, nlocuite sau terse, fapt ce ar putea opri instalarea unui
malware,cal troian i rootkit, precum i alte atacuri ce implic accesul neautorizat la
fiiere. Aceasta tehnic poate oferi un strat suplimentar de control al accesului pentru a
suplimenta tehnologiile de control de acces existente pe gazd.
Celelalte tehnici de detectare, analiza logurilor, monitorizarea configuraiei reelei,
verificarea integritii fiierelor i a atributelor, n general, nu sprijin aciunile de prevenire,
deoarece acestea identific evenimentele dup ce au avut loc.

5.2.4 Alte capabiliti

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;
Monitorizarea dispozitivelor audiovizualue. Cteva produse pot detecta activarea
sau uzul unor dispozitive audiovizuale( microfoane, camere video sau telefoane bazate
pe IP). Acest lucru ar putea indica compromiterea unei gazde de ctre un atacator;

ntrirea gazdei. De exemplu, n cazul n care o aplicaie este reconfigurat,

provocnd dezactivarea unei funcii de securitate, sistemul ar putea detecta acest lucru
i reactiva apoi aceea funcie;

Monitorizarea strii proceselor. Unele produse monitorizeaz starea proceselor sau a

serviciilor ce ruleaz, i n cazul n care constat oprirea unuia, este repornit automat.
Poate fi monitorizate, de asemenea, starea unor programe de securitate( software-ul
antivirus);
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
Odat ce un produs a fost selectat, administratorii trebuie s proiecteze o arhitectur,
s efectueze testarea componentelor, s le asigure i apoi s le implementeze. Urmtoarele
elemente aduc completri la materialul prezentat n seciunea 2.3.1:
Testarea componentelor i amplasarea. Dup ce componentele au fost evaluate ntrun mediu de testare, organizaiile ar trebui s le pun n aplicare doar pe cteva hosturi din mediul de productie. Acest lucru permite administratorilor s efectueze
activiti de tuning i personalizare pe host-uri n curs de pregtire pentru o
implementare mai mare. Caracteristicile de prevenire trebuie s fie dezactivate n tot
acest timp pn la implementarea n mas pn cnd agenii au fost suficient setai i
personalizai;

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
Acest tip de IDPS ar trebui exploatat n conformitate cu recomandrile prezentate n
seciunea 3.3.2. Singura excepie este n actualizarea agenilor. Unii ageni pot verifica
periodic serverul de management pentru actualizri, prelund i instalnd apoi automat
anumite actualizri, dac sunt disponibile. Ali ageni nu pot face acest lucru, fapt ce necesit
ca un administrator s verifice manual transferul, instalarea i aplicarea actualizrilor. n
multe cazuri, capacitatea de update a unui agent este legat de tipul de sistem de operare pe
care este implementat.

49

6. Soluii profesionale IDPS

6.1 Alegerea IDPS-ului
Avnd n vedere oferta extrem de bogat existent pe pia, alegerea echipamentului
adecvat pentru sporirea securitii nu este o activitate simpl. Trebuie analizai o multitudine
de factori, identificate nevoile companiei, ce tipuri de ameninri sunt relevante, ce arii sunt
critice, dimensiunea organizaiei, cantitatea de trafic generat, personalul IT specializat,
bugetul, etc.
n primul rnd trebuie stabilit direcia principala companiei, n ce domeniu activeaz
pentru a stabilifactorul de risc i de ce nivel de protecie este nevoie. n cazul unei instituii
militare factorul de risc estemaxim,necesitnd astfel o securitatea maxim asiguratde diverse
echipamente specializate. n cazul unei instituii educaionale sau fundaii de ajutorare,
factorul de risc este sczuti atuncitrebuie o realizat o aprare mai mult mpotriva uneltelor
automate ce activeaz pe internet, un atacatorspecializat ar fi puin probabil s ncerce s
ptrund n reea.
Software sau Hardware?
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;
Fiabilitate i disponibilitate. Echipamentul trebuie s fie fiabil, s nu se defecteze uor.
Orice oprire sau defectare nseamn o posibil oprire a activitii n reea. Atunci cnd
dispozitivul iface update-urile cu noile definiii este necesar ca acesta s nu trebuiasc s fie
restartat pentru a leactiva, acest lucru nsemnnd oprirea activitii pe perioada de restart;
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;
ncrederea n semnturi. Update-urile la semnturi este de preferat s se fac n mod
automat i fr restartarea echipamentului. De aceea semnturile trebuie s fie de ncredere
i de calitate pentru a nu risca prbuirea reelei din cauza unei semnturi instalate n mod
automat;
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;
Rata de transfer a preveniei intruziunilor(intrusion prevention throughput).
Reprezintcapacitatea de a filtra i analiza traficul n vedereadetectrii i prevenirii
intruziunilor. Este mai mic dect rata filtrrii pentru c necesit mai mult putere de calcul,
fiind necesar o analiz a protocoale de nivel superior i capabiliti de reinerei analiz a
unor sesiuni ntregi, etc;
Numrul de interfee.IDPS-urile au nevoie de cel puin dou interfee, una de
managementi una de monitorizare. Cele cu dou interfee nu pot fi folosite dect ca IDS, nu
pot fi folosite inline. Pentru a-l folosiinline este necesar existena a cel puin trei interfee,
dou de monitorizare i una de administrare. Implementare cu trei interfee este setup-ul
preferat de majoritatea cumprtorilor.Dar cu ct dispune de mai multe interfee, cu att mai
bine. Se pot realiza senzori virtuali, combinnd interfeele dou cte doui astfel dintr-un
singur IDPS se pot realiza mai multe virtuale;
Numrul de sesiuni. Reprezint numrul de sesiuni TCP concurente ce pot fi monitorizate
n acelaitimp. Acesta este de ordinul a zeci i sute de mii i char milioane. Depinznd de tipul
traficuluimonitorizat trebuie ales un IDPS adecvat. Este strns legat de prima rat prezentat
mai sus; cumprtorul nu trebuie s i fac griji n mod special pentru numrul de sesiuni,
acesta alegnd IDPS-ul cu o rat de tranfer adecvat reelei.
Acestea sunt cele mai importante caracteristici de luat n considerare n achiziionarea
unui IDPS. Alte caracteristici cum ar fi temperatura de funcionare saulimitele de
umiditatela care poate funciona aparatultrebuie luate n considerare n cazuri speciale cnd
echipamentul trebuie sfuncioneze n condiii deosebite.
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.

6.4 Juctorii importani de pe piaa.

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
7.1 Privire de ansamblu
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 Snortului 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.
SNORT este un produs cu tradiie, cu peste 3 milioane de downloaduri fiind considerat
IDS de factor standard.
Snort nu este foarte greu de utilizat, dar exist o mulime de opiuni n linie de comand
cu care se poate lucra, nefiind ntotdeauna evident care dintre ele funcioneaz bine mpreun.
Exist cteva concepte de baz care ar trebui nelese legate de Snort. Snort poate fi
configurat pentru a rula n mai multe moduri:
Modul sniffer, care citete pur i simplu pachetele de pe reea i le afieaz ntr-un
flux continuu pe consol( ecran);
Modul logger, n care logheaz pachetele pe disc;
Modul de detecia a intruziunilor n reea( NIDS) alturi de urmtorul mod, permite
cele mai multe i complexe configurri, permind analiza traficului de reea pentru o
comparare cu seturile de reguli definite de utilizator, ndeplinind mai multe aciuni
bazate pe ceea ce se vede;
Modul inline este de fapt modul IPS.
Snort-ul poate activa doar ntr-unul modurile prezentate mai sus, sau n mai multe
simultan, chiar toate.

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
-e
-d
-a
-c

interactiv, afiarea doar a antetelor TCP/UDP/ICMP

Headere nivel legturi de date
Headere aplicaie
Afiare frame-uri ARP
Afiare date de tip char din payload ( nu le afieaz n
hexa)
Interfaa pe care ascult
Rulare ca daemon
Rulare n mod quiet (nu mai afieaz mesajele de
nceput i summary de la exit)

-i eth0
-d
-q

Tabelul7.1 Opiuni rulare SNORT ca sniffer

Exemplu de utilizare:
./snort vd
Astfel instruim Snort-ul pentru afiarea pachetelor de date mpreun cu header-urile
aferente.

7.1.3 Modulul logger

Pentru a nregistra pe disc pachetele, trebuie specificat directorul de logare dup care
programul va intra automat n acest modul:
./snort dev l ./log
Desigur, acest lucru presupune c exist un director numit log n directorul curent.
Dac nu, Snort va 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:
./snort -dev -l ./log -h 192.168.1.0/24

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( non192.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
Se oberv schimbrile ce intervin aici. Nu trebuie specificat o reea deoarece modul
binar concentreaz ntr-un singur fiier, ceea ce elimin necesitatea de a i spune cum s
formateze structura directorulului de ieire. n plus, nu este nevoie de rularea interactiv sau
de specificarea opiunilor -d sau e, deoarece n modul binar ntregul pachet este logat, nu
doar seciuni din el. Tot ceea ce este de fcut pentru a plasa Snort n modul logger este
specificarea directorului de logare .
Dup ce pachetele au fost logate n binar, acestea pot fi citite cu orice sniffer care
suport formatul binar tcpdump (ex: tcpdump sau ethereal). Snort poate citi, de asemenea,
pachetele prin specificarea opiunii r.
Pachetele logate pot fi manipulate n nenumrate moduri prin rularea n modul logger
sau NIDS a Snort-ului n conjuncie cu interfa BPF, ce este disponibiln linie de comand.
De exemplu, dac se vrea doar vizualizarea pachetelelor ICMP din fiierul de log, specificai
pur i simplu un filtru BPF n linie de comand:
./snort -dvr packet.log icmp

7.1.4 Modulul NIDS

Un exemplu prin care se activeaz acest mod pentru a nu nregistra fiecare pachet este:
./snort -dev -l ./log -h 192.168.1.0/24 -c snort.conf
unde snort.conf este numele 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.

7.1.4.1 Opiuni de output

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
Modul complet.Este modul implicit folosit n cazul n
care nu este specificat nimic.
Sunt trimise alerte ctre un socket de Unix la care
poate asculta alt program
Sunt oprite alertele.

-A full
-A unsock
-A none
-A console

Alertele de tip fast-style sunt trimise ctre consol(

ecran).
Sunt generate alerte de tip cmg style

-A cmg

Tabelul7.2 Modurile de alert accesate cu opiunea -A

7.1.4.2 nelegerea standardului ieirii

Cnd Snort genereaz un mesaj de alert, acesta va arta n felul urmtor:
[**] [116:56:1] (snort_decoder): T/TCP Detected [**]
Primul numr reprezint GID-ul( Generator ID); specific user-ului ce component a
generat alerta. Pentru o list a acestor valori se poate consulta fiierul etc/generators din sursa
Snort. n acest caz evenimentul a fost generat de component decode(116).

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.

7.1.4.3 Schimbarea ordinii alertelor

Modul implicit pe care Snort l folosete n aplicarea regulilor pe pachete poate nu fi
propice pentru orice instalare. Regulile de pass sunt aplicate primele, apoi cele de drop,
urmate de regulile de alert, i n ultimul rnd regulile de log.
Sunt disponibile mai multe opiuni ce permit ordinea de aciune a unei reguli:
--alert-before-pass; foreaz aplicarea regulilor de alert n primul rnd
--treat-drop-as-alert; cauzeaz logarea ca alerte a aciunilor de drop i reject, precum
i alte alerte associate.Se permite astfel utilizarea unei politici inline n modul pasiv /
IDS. Regulile sdrop nu sunt ncrcate.
--process-all-event; instruiete Snort-ul s proceseze fiecare eveniment asociat unui
pachet, ntreprinznd aciunile pe baza ordinii stabilite.Fr specificarea acestei
opiuni (caz implicit), doar evenimentele asociate primei aciuni din ordinea stabilit
sunt procesate.

7.1.5 Modulul Inline

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.
include <include file path/name>

7.2.2 Variabile
Trei tipuri de variabile pot fi regsite n Snort:
var
portvar
ipvar11
Urmtoarele declaraii reprezint exemple de folosire a acestor tipuri:
var RULES_PATH rules/
portvar MY_PORTS [22,80,1024:1050]
ipvar MY_NET [192.168.1.0/24,10.1.1.0/24]
alert tcp any any -> $MY_NET $MY_PORTS (flags:S; msg:"SYN
packet";)
include $RULE_PATH/example.rule

7.2.2.1 Variabile IP. Liste IP

IP-urile pot fi specificate individual, ntr-o lista, sub forma unui bloc CIDR sau sub
orice 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]
Ordinea elementelor listei nu conteaz. Elementul anypoate fi folosit pentru a include
orice IP; expresia !any nu este permis.De asemenea, intervalele IP negate ce sunt mai
generale dect intervale IP ce nu sunt negate, nu sunt permise.
Urmtoarele constituie nite interval valide de variabile i liste IP:
ipvar EXAMPLE [1.1.1.1,2.2.2.0/24,![2.2.2.2,2.2.2.3]]
alert tcp $EXAMPLE any -> any any (msg:"Example"; sid:1;)
alert tcp [1.0.0.0/8,!1.1.1.0/24] any -> any any
(msg:"Example";sid:2;)
11

Acest tip de variabil este folosit pentru support IPv6.

60

Exemplele ce urmeaz redau nite utilizri invalide:

utilizarea lui !any :
ipvar EXAMPLE any
alert tcp !$EXAMPLE any -> any any (msg:"Example";sid:3;)
alert tcp $EXAMPLE any -> any any (msg:"Example";sid:3;)
contradicii logice:
ipvar EXAMPLE [1.1.1.1,!1.1.1.1]
negaii fr sens:
ipvar EXAMPLE [1.1.1.0/24,!1.1.0.0/16]

7.2.2.2 Variabile port. Liste de porturi

Este suportat reprezentarea porturilor sub forma unor intervale.Variabilele,
intervalele sau listele pot fi toate negate cu !. De asemnea, prin any este specificat orice
port. Nici aici nu este permis declaraia !any.Intervalul valid de porturi este de la 0 la
65535.
Listele de porturi trebuie nchise ntre paranteze ptrate, iar intervalele trebuie
specificate cu : ca n exemplul urmtor:
[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:

utilizarea lui !any:
portvar EXAMPLE5 !any
var EXAMPLE5 !any
contradicii logice:
portvar EXAMPLE6 [80,!80]
porturi n afara intervalului permis:
portvar EXAMPLE7 [65536]

declararea incorect i utilizarea acesteia ca port:

var EXAMPLE8 80
alert tcp any $EXAMPLE8 -> any any (msg:"Example"; sid:4;)
variabil port utilizat ca IP:
alert tcp $EXAMPLE1 any -> any any (msg:"Example"; sid:5;)

7.2.2.3 Modificatori de variabile

Variabilele prin numele lor pot fi modificate n mai multe feluri. Se poate define o
meta-variabil prin operatoru $.Acesta poate fi folosit mpreuna cu operatori ? i -, aa
cum este descris n tabelul urmtor:
Sintaxa variabilei
var
$(var) sau $var
$(var:-default)
$(var:?message)

Descriere
Se definete o meta-variabil
Se nlocuiete cu coninutul variabilei var
Se nlocuiete coninutul variabilei var cu default dac aceasta este nedefinit
Se nlocuieste cu coninutul variabilei sau se afieaz un mesaj de eroare i se
iese
Tabelul 7.3 Modificatori de variabile

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:
<name> Preprocessor: <Opiuni>
Sunt disponibile spre activare i configurare mai multe tipuri de preprocesoare, n
funcie de problemele pe care le trateaz:

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

7.3.1 Frag3
Preprocesorul frag3 este un modul de defragmentare IP de tip target-based.Este folosit
pentru urmtoarele scopuri:
o execuie ct mai rapid fr un management complex al datelor;
modelarea target-based a tehnicilor anti-evaziune.
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.

7.3.3 HTTP Inspect

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.

7.3.4 Preprocesorul de date sensibile

Reprezint un modul Snort ce realizeaz detecia i filtrarea datelor de tip PII(
Personally Identifiable Information). Acest date includ numere de carduri de credit, coduri
numerice personale i adrese de email.Este disponibil o sintax de expresii regulate care
permit definirea unor pattern-uri proprii.
Dependine
Preprocesorul Stream5 trebuie s fie activat pentru ca acest modul s funcioneze.
Configuraie
Configuraia acestui modul este mprit n dou: configurarea preprocesorului i
regulile.
Configurarea modului ncepe cu:
preprocessor sensitive_data:
64

Opiune
alert_threshold

mask_output

ssn_file

Argument
< numr>

<nume de fiier>

Necesar
Nu

Implicit
Alert_threshold 25

Explicaii
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

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

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:
preprocessor sensitive_data: alert_threshold 25 \
mask_output \
ssn_file ssn_groups_Jan10.csv

Configurarea regulilor
Regulile sunt utilizate pentru a specifica ce tip de date( PII) trebuie 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

pattern

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
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
email

Pattern folosit pentru SSN-uri ce nu au delimitatori( ex: punct).

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
\D

potrivire pe orice digit

potrivire pe orice non-digit

\l

potrivire pe orice liter

\L

potrivire pe orice character non-liter

\w

potrivire pe orice caracter alfanumeric

\W
{ num }

potrivire pe orice caracter non-alfanumeric

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

Orice alt carater folosit n patern va fi tratat ad literarum.
Exemplu de de regul:
alert tcp $HOME_NET $HIGH_PORTS -> $EXTERNAL_NET $SMTP_PORTS
(msg:"Credit Card numbers sent over email"; gid:138; sid:1000;
rev:1; sd_pattern:4,credit_card; metadata:service smtp;)
Opiunea sd_patternnu este compatibil cu alte opiuni specifice compoziiei unei
reguli. Utilizarea acesteia mpreun cu alte opiuni va duce la apariia unui mesaj de eroare.
Regulile ce folosesc aceast opiune trebuie s seteze valoarea GID-ului la 138.

7.4 Semnturi / Reguli

Semnturile reprezint o parte esenial a Snort-ului. Fr acestea detecia nu ar mai fi
posibil. Acestea reprezint, n mare parte, sample-uri de trafic maliios care de ndat ce este
identificat, va duce la producereaunei alerte sau ntreprinderea unei anume aciuni. Aceste
reguli se gsesc pe site-ul oficial al Snort-ului. Cele mai actuale definitii nu sunt gratis, dar
sunt distribuite gratis la o lun de la lansare. Exist isemnturi neoficiale, dezvoltate de
comunitate, avnd la baza semnturile oficiale ale Snort-ului la care s-au adugat mici
mbuntiri.

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.
n concluzie abordarea scrierii de definiii pentru vulnerabilitatea n sine i nu a exploatrii
este mult mai eficient i asigur protecie pentru alte eventuale exploatri ale aceleai
vulnerabiliti.
Un alt exemplu n care este evideniat abordarea orientat pe vulnerabilitate a
semnturiloroficiale este modul cum a fost abordat vulnerabilitatea apruta n comunicarea
RPC ctre serverul debaze de date ToolTalk. Aceast vulnerabilitate a aprut n sistemele de
operare de la HP, IBM, SCO Group, SGI i Sun i permitea unui atacator remote s execute
cod cu drepturi de super user.
SourceFire a identificat cmpurile vulnerabile din protocolul RPC, care era
vulnerabilitatea i n ce condiii se manifesta, apoi a scris o semntura pentru acest lucru. n
continuare este descris acestproces:

67

Figura 7.7- Exemplu pachet RPC

Analiza pachetului RPC al unei exploatri ce ncearc s speculeze vulnerabilitatea n
cauz
Identificarea Protocolului
Octeii 8 - 11 indic un RPC call, astfe avem o cutare dup coninutul 00 00
00 00 pentru acei octei:
content:|00 00 00 00|; offset:8; depth:4;
Octeii 12 -15 indic folosirea versiunii 2 a RPC:
content:|00 00 00 02|; offset:12; depth:4;
Octeii 16 - 19 indic numrul programului RPC. Cel n cauza este 00 01 86
F3, astfel ne putem duce la acea poziie i cuta apariia acestui program:
content:|00 01 86 F3|; offset:16; depth:4;
Peste 2 cmpuri, adic la 4 octei de la poziia anterioar, indic numrul
procedurii RPC. Este de interes 00 00 00 07:
content:|00 00 00 07|; distance:4; within:4;
Stare comunicaiei
Vrem s identificm doar sesiunile stabilite:
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;
n concluzie, o regul ce previne orice exploatare a vulnerabilitii CVE-1999-0003 n
cazul ToolTalk, arat n felul urmtor:
alert tcp $EXTERNAL_NET any -> $HOME_NET any \
(msg:RPC tooltalk TCP overflow attempt; \
flow:to_server,established; \
content:|00 00 00 02|; depth:4; offset:12;\
content:|00 01 86 F3|; depth:4; offset:16; \
content:|00 00 00 07|; within:4; distance:4; \
byte_jump:4,4,relative,align; \
byte_jump:4,4,relative,align; \
byte_test:4,>,128,0,relative; \
content:|00 00 00 00|; depth:4; offset:8; \
reference:bugtraq,122; \
reference:cve,1999-0003; \
classtype:misc-attack; sid:1965; rev:8;)

69

7.4.1 Scriererea Regulilor

Regulile sunt mprite n dou seciuni logice:
1. Antetul: specific aciunea, protocolul, adresele IP i mtile aferente surs i
destinaie, precum i porturile surs i destinaie;
2. Opiunile: specific mesajul de alert precum i alte informaii legate de prile
pachetului ce ar trebui inspectate pentru a determina dac trebuie ntreprins aciunea
precizat.

7.4.2 Antetul unei reguli

Aciunea regulii
Este indicat astfel Snort-ului ce trebuie s fac n eventualitatea unui pachet ce
ndeplinete condiiile impuse. Exist 5 aciuni implicate definite:alertare, logare, permitere,
activare i intrarea n modul dinamic.n plus, dac este rulat n mod inline, sunt disponibile
alte 3 tipuri:dropare, respingere i blocare fr log.
Nume
alert
log
pass
activate
dynamic
reject
drop
sdrop

Aciunea realizat
generarea unei alerte folosind metoda de alertare selectat, urmat de o
logare a pachetului
logarea pachetului
ignorarea pachetului
alertare i activarea unei alte regule dinamice
inactiv pn la activarea de ctre regula mai sus meniont, comportndu-se
apoi ca o regul de logare
blocarea i logarea pachetului, urmate de trimiterea unui pachet de reset n
cazul protocolului TCP, sau a unui de top port ICMP inaccesibil n cazul UDP
blocarea i logarea pachetului
blocare fr logare a pachetului
Tabelul 7.8 Tipurile de aciuni posibile

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
Exist patru protocoale pe care Snort-ul le analizeaz pentru comportament suspicios:

TCP
UDP
ICMP
IP

Pe viitor se urmrete i implementarea altora: ARP, IGRP, GRE, OSPF, RIP, IPX, etc.

Adresele IP
Snort-ul nu are nici un mecanism de cutare a host-urilor dup adrese IP n fiierul de
configurare. Le regsim n antetul regulilor. Sunt formate dintr-o adres numeric de tip IP i
un bloc CIDR ce indic masca de reea ce trebuie folosit n cazul inspectrii pachetelor.Pot fi
specificate i sub forma unei liste sau folosind operatorul any pentru a defini orice adres .
Porturile
Numerele de port pot fi specificate n mai multe moduri, prin any, 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

Reprezint inima motorului de detecie a intruziunilor al Snort-ului, coroborat cu
uurina utilizrii, puterea i flexibilitatea acestora.
Toate opiunile sunt separate una de alta prin ; .Cuvintele cheie sunt separate de
argument folosind : .
activate tcp !$HOME_NET any -> $HOME_NET 143 (flags:PA; \
content:"|E8C0FFFFFF|/bin"; activates:1; \
msg:"IMAP buffer overflow!";)
dynamic tcp !$HOME_NET any -> $HOME_NET 143 (activated_by:1;
count:50;)

71

n continuare sunt prezentate cteva din opiunile disponibile:

msg: mesajul salvat n loguri i alerte;

reference:regula include o referin extern care detaliaz atacul (Exemplu: bugtrack,

cve, nessus etc);
alert tcp any any -> any 21 (msg:"IDS287/ftp-wuftp260venglin-linux"; flags:AP; content:"|31c031db 31c9b046 cd80
31c031db|";
reference:arachnids,IDS287;reference:bugtraq,1387;
reference:cve,CAN-2000-1574;)

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

sid (signature id): identificator unic pentru regul; este obligatoriu. Pentru sid exist
urmtoarele recomandri:
sid < 100 este rezervat;
100 < sid < 1.000.000 pentru regulile oficiale SourceFire;
sid > 1.000.000 pentru regulile create de user.
rev (revision):identificator pentru numrul de revizie al regulii;
alert tcp any any -> any 25 (content:CMA; sid:1000001;
rev:2;)
classtype: clasific tipul de atac ntr-o clas generic. Acestea sunt definite n
classification.config;
alert tcp any any -> any 80 (sid:1000002; msg:EXPLOIT
ntpdx overflow; dsize: >128; classtype:attempted-admin;
priority:10 );
flags testeaz flagurile TCP. Se folosete: S, F, R, A, P, U, 0(zero niciun bit setat)
sau combinaii ntre acestea. Exist 3 tipuri de modificatori:
+ testeaz biii specificai, pot fi i alii n plus;
! testeaz ca biii specificai s nu fie setai;
* testeaz dac oricare dintre biii specificai sunt testai;
alert tcp any any -> any any (sid: 1000003; msg:pachet
tcp; flags:SA+;)
minfrag seteaz un prag pentru dimensiunea minim a unui fragment;
TTL: testeaz valoarea TTL din headerul IP;
72

alert icmp any any -> any any (msg:PING with TTP
100;ttl:100; sid: 1000004;)
tos: testeaz valoarea ToS din headerul IP;
alert icmp any any -> any any (msg:tos diferit de 1;tos:!1;
sid: 1000005;)

fragbits: testeaza biii MoreFragments i Dont Fragment din headerul IP;

alert icmp any any -> any any (msg:Pachet cu biii more
fragment i dont fragment setai;fragbits:MD+;sid:
1000006;)

id: testeaz valoarea ID din headerul IP;

dsize: testeaz dimensiunea ncrcturii pachetului;
Content: caut un pattern n payload-ul pachetului. Caracterele : ; \ trebuie precedate
de \(backslash);
alert tcp any any -> any 111 (sid:1000007; content: |00 01 86
a5|; msg: external mountd access;)
nocase: valoarea cutat n pachet de ajutorul content este case-insensitive;
offset: seteaz un offset de la care se ncepe cutarea valorii opiunii content;
depth: seteaz o adncime n pachet pn la care se caut valoarea opiunii content;
http_client_body: reprezint un modificator pentru opiunea content care limiteaz
cutarea n HTTP Body Client Request; preprocesorul Http Inspect trebuie s fie activ;
http_cookie: reprezint un modificator pentru opiunea content care limiteaz cutarea
n cmpul HTTP Cookie Header din HTTP Client Request; preprocesorul HttpInspect
trebuie s fie activ;
http_header: reprezint un modificator pentru opiunea content care limiteaz
cutarea n Headerul HTTP din Client Request;
seq: testeaz valoarea Sequence No. din headerul TCP;
ack: testeaz valoarea Acknowledgment din headerul TCP;

73

 itype: testeaz tipul ICMP;

icode: testeaz codul ICMP.
session: datele utilizatorului sunt extrase din sesiunile TCP i printate n alerte.
log tcp any any <> any 23 (session:printable;sid:1000008;)
resp: activeaz un rspuns activ ce nchide conexiunile considerate periculoase;

pcre: se folosete pcre (perl compatible regular expression) pentru testarea

coninutului unui pachet.

7.4.4 Pragul unei reguli

Se folosete pentru a reduce mesajele logate de regulile care se activeaz extrem de
des. Exist 3 categorii de praguri:
limit: alerteaz pentru primele n evenimente ntr-un interval de timp. Restul
evenimentelor sunt ignorate pentru o perioad de timp;
threshold: alerteaz la fiecare n evenimente ntr-o perioad de timp;
ambele: alerteaz o dat n intervalul de timp, dar doar dup n evenimente.
Un threshold se poate include ntr-o regul sau se poate defini de sine stttor referindu-se
la sid-ul regulii.

8. Sistem pentru prevenirea scurgerilor de date

8.1 Snort sistem de detectare i prevenie a scurgerilor de
date
O bun aplicaie a Snort-ului este prevenirea scurgerilor de datedintr-o instituie.
Snort-ul oprete traficul n funcie de anumite reguli. Acestea pot fi scrise n funcie
denecesitile i dorinele fiecruia. O problem majoro reprezint poziionarea IDPS-ului n
cadrul reelei pentru aoferi o eficien maxim. Pentru a preveni i nu doar a detecta scurgerea
de date este de preferabil opoziionarea inline. Aceasta prezint o serie de dezavantaje cum ar
fi imposibilitatea decodriiprotocoalelor care transmit datele criptat:ssh, https, imaps, pop3s,
smtps. Oricine poate s acceseze orice aplicaie care folosete protocolul https i s uploadeze
documente fr ca Snort-ul s l poate detecta.Astfel, pentru o implementare eficienti
transparent pentru utilizatori a unei soluii de prevenirea scurgerilor de date nu este de ajuns
un singur echipament dotatcu Snort. n cazul tuturor echipamentelor trebuie blocate toate
porturile inutile, iar accesul la portul 80 i 443 s nuse fac direct, ci printr-un proxy cum ar fi
Squid, etc.
74

Figura 8.1 - Snort inline

Avantajele folosirii Snort-ului inline pentru prevenirea scurgerilor de date:
transparenfa de utilizatori: acetia nu tiu de existenta Snort-ului n reea, nefiind
necesare configurri speciale pe staia de lucru;
implementare rapid: un singur dispozitiv amplasat n punctul de interes este de ajuns
pentru a acoperi toi utilizatorii.
Dezavantajele folosirii Snort-ului inline pentru prevenirea scurgerilor de date:
imposibilitate inspectrii protocoalelor ce folosesc criptarea datelor :https, pop3s,
smtps, imaps, ssh vor trece fr a puteafi inspectate;
ntrzieri n reea: pentru a inspecta traficul, o serie de procesri au loc, cum ar
fidecodarea i normalizarea protocolului, inspectarea acestuia dup semnturi, toate
acesteproceduri provocnd ntrzieri n reea;
punct sensibil: dac echipamentul Snort are probleme i se defecteaz, ntreg traficul
va fioprit, un lucru nedorit de atlfel de nimeni.

8.2 Iptables
Pentru a implementa Snort-ul inline eficient la nivel de host este nevoie de
configurarea serviciului iptables.
Acesta reprezint un serviciu furnizat de firewall-ul din cadrul kernel-ului de Linux.
Permite administratorului de sistem definirea unor tabele ce conin lanuri de reguli pentru
tratarea pachetelor de reea.Fiecare tabel este asociat unui alt tip de procesare. Pachetele
sunt procesate secvenial, pe msur ce parcurg lanurile.O regul dintr-un lan poate provoca
un salt ctre alt lan, lucru ce se poate repeta n limita nivelului de mbricare dorit
Ipptables folosete n mod implicit trei tabele :
1. Filter - este responsabil cu filtrarea pachetelor.
Are trei lanuri predefinite n care se pot declara reguli de politic firewall:
Forward : Filtreaz pachete ctre servere protejate de firewall;
Input : Filtreaz pachetele destinate firewall-ului;
Output : Filtreaz pachetele expediate de firewall.
2. NAT este responsabil cu translatarea adreselor de reea.

75

3. MANGLE este responsabil cu modificarea biilor QOS din headerul TCP

Are 2 lanuri predefinite:
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.

Fiecare regul firewall inspecteaz pachetele IP i apoi ncearc s le identifice ca i inte

pentru o anumit operaie.
Cele mai folosite inte sunt:

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

Tabelul 8.3 Opiuni configurare Iptables

Configurrile necesare pentru ca modulul iptables s trasmit toate pachetele spre
procesare ctre Snort se realizeaz n felul urmtor:
iptables -I OUTPUT 1 -p all -j QUEUE
iptables -I INPUT 1 -p all -j QUEUE
Figura 8.4 Funcionare Iptables & Snort

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

Figura 8.5 - Arhitectura implementat

Pentru implementarea i testarea Snort-ului i a plugin-ului prezentat n seciunile
urmtoare s-a folosit arhitectura de mai sus.Snort-ul a fost implementat n modul inline, la
nivel de host (PC). Astfel, monitorizeaz tot traficul de la i spre host-ul din imagine.Traficul
va trece n mod transparent prin filtru fr a fi nevoie de configurri adiionale pe
echipamentele existente n reea.
Drumul pe care un pachet l parcuge prin Snort este redat mai jos:

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
Figura 8.6 - Drumul unui pachet prin Snort
u
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.

8.4. Metode de detecie i prevenie

n cadrul Snort-ului exist dou etape n care se poate face prevenia i detecia
scurgerilor date:
1. n faza de preprocesare cu ajutorul preprocesorului specific datelor sensibile
prezentat n seciunile anterioare.Avantajul configurrii acestui preprocesor este
reprezentat de faptul c se evit trecerea pachetelor ce se potrivesc cu regulile
preprocesorului prin motorul principal de detecie al Snortului, sczndu-se astfel
timpul de procesare precum i utilizarea resurselor;
2. n cadrul motorului de detecie;
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.
Date

Metod folosit pentru detecie

12

Sd_pattern
CNP
12

Regexp

12

PCRE
Regexp

Verificare validitate
Sd_pattern
Da

Snort

81

PCRE
Nu

Numere
carduribancare

Regexp

Regexp

Da

Nu

Email

Regexp

Regexp

Da

Da

Tabelul 8.7 Detecia i verificarea datelor sensibile

Date

Exemple Regexp

CNP

Card bancar( VISA)

Sd_pattern

PCRE

\d{13}

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

credit_card13

/4\d{3}(\s|-)?\d{4}(\s|)?\d{4}(\s|-)?\d{4}/

Email2

Email

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

Tabelul 8.8 Expresii regulate folosite

8.5.Filtrarea protocolului http i https

Figura 8.9 - Protocolul HTTP

Majoritatea scurgerilor de date sunt accidentale i au loc prin intermediul reelelor de
de socializare sau serviciilor de email gratis. Pentru o securitate sporit, accesul la acestea
ar trebuie restricionat. Blocarea acestora nu este extrem de greu de realizat. Atunci cnd se
realizeaz o cerere http, host-ul i URL-ul accesat este trimis de ctre browser server-ului
printr-o cerere GET.

13

Predefinit

82

HTTP/1.1 200 OK
Cache-Control: private, no-cache, no-store, mustrevalidate
Expires: Sat, 01 Jan 2000 00:00:00 GMT
P3P: CP="Facebook does not have a P3P policy.
Learn why here: http://fb.me/p3p"
Pragma: no-cache
path=/; domain=.facebook.com; httponly
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
X-FB-Server: 10.146.68.118
X-Cnection: close
Transfer-Encoding: chunked
Date: Mon, May 2013 19:30:45 GM

GET /index.php HTTP/1.1

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

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.

drop tcp any any -> any 80 (msg:"Facebook not

allowed";content:"Host: www.facebook.com";
http_header;classtype:policy-violation; sid:1000007;
rev:1;)

Este posibil o filtrare dup coninut conform modelelor prezentate mai jos:
drop tcp my_ip any -> any $HTTP_PORTS (pcre:"/4\d{3}(\s|)?\d{4}(\s|-)?\d{4}(\s|-)?\d{4}/"; msg:"VISA card number
detected over http "; classtype:policy-violation;
sid:9000000;rev:1;)
drop tcp my_ip any -> any $HTTP_PORTS (pcre:"/5\d{3}(\s|)?\d{4}(\s|-)?\d{4}(\s|-)?\d{4}/";msg:"MasterCard number
detected over http"; classtype:policy-violation;
sid:9000001;rev:1;)
alert tcp my_ip any -> any $HTTP_PORTS (pcre:"/[a-zA-Z09_\.]+@[a-zA-Z]+\.[a-zA-Z]+/";msg:"Email address detected over
http"; classtype:policy-violation; sid:9000004; rev:1;)
drop tcp my_ip any -> any $HTTP_PORTS (pcre:"/[1-9]{1}[19]{2}(0[1-9]|1[0-2])(0[1-9]|[12]\d|3[01])(0[1-9]|[1-4]\d| 5[02]|99)\d{4}/";msg:"CNP detected over http"; classtype:policyviolation; sid:9000006;rev:1;)
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

Figura 8.10 - Protocolul HTTPS

Client Request s conin i acest amnunt pentru ca un server s poat gzdui mai multe siteuri 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 browserul 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).
preprocessor ssl: ports { 443 },
trustservers,noinspect_encrypted
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 snortului specifice SSL-ului.
Regula ce blocheaza pachetul Client Hello ce foloseste o versiune inferioara de ssl
este:
drop tcp any any -> any 443 (msg:"SSL old versions not
alowed"; ssl_state:client_hello; ssl_version:sslv3,sslv2;
classtype:policy-violation; sid:1000009; rev:1;)
n cazul traficului browser-elor ce folosesc protocoalele TLS1.0,TLS1.1, TLS1.2 i
nuimplementeaz extensia Server Name Indication, acesta va fi blocat.
Primul pas este de a analiza handshake-ul ssl i a vedea unde anume se afl extensia
respectiv i cum putem face pentru a ajunge la ea. Se va analiza primul pachet din
handshake, Client Hello-ul, i se vancerca a ajunge la Server Name Indication, care
conform RFC-ului are numrul 0.Dac extensie cu numrul 0 exist, atunci pachetul va fi
lsat s treac, dac nu, atunci pachetul va firespins.

Figura 8.11 Pachet Client Hello TLS 1.0

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:
content:!"|0000|"; distance:2; within:2;
Regula final care blocheaz orice pachet client hello ce nu are extensia Server Name
Indication este:
drop tcp any any -> any 443 (msg:"SSL without extension not
allowed"; byte_jump:2,44,align;
byte_jump:0,1,relative,align; content:!"|0000|"; distance:2;
within:2; ssl_state:client_hello;
ssl_version:tls1.0,tls1.1,tls1.2;
classtype:policy-violation; sid:1000010; rev:1;

8.6 Filtrarea protocolului FTP

FTP-ul este un protocol extrem de rspndit i popular folosit n transferul de date.
Este folositmai ales n rndul creatorilor de site-uri, pentru a face upload-ul unor diverse
documente ce vor fi apoi accesate deutilizatorii site-ului respectiv. Din neatenie este foarte
uor s uploadezi i documente ce nu ar trebuirspndite publicului larg. Bineneles un
atacator poate folosi acest protocol pentru a uploada script-urimaliioase.
FTP-ul este un protocol foarte vechi, descris n RFC 959 din 1985, i de aceea este
puin diferit fa de alte protocoale TCP/IP folosite n prezent. Acesta nu lucreaz pe un
singurport, comenzile se trimit pe portul 21, iar transferul de date se executa fie pe portul 20
fie pe oricare alt port mai mare dect 1024. Alt problema ar fi n modul cum transfera FTP
datele, ori folosete modulAsci ori folosete modul Binar pentru transfer.
FTP-ul poate funciona sub dou moduri:
Pasiv
1. Clientul iniiaz transferul de pe
un port mai mare de 1024 pe portul
21 al serverului, iar serverul i va
spune c va ncepe s asculte peun
port peste 1024.

86

Figura 8.12 - FTP n mod Pasiv

2. Clientul se va conecta la acel nou port pecare va asculta serverul i va transmite

sauprimi date. Astfel datele ce trebuiesc filtratevor circula ntre client i server pe
porturi TCP mai mari dect 1024.nO regul ce poate fi folosit pentru a fi filtra dup
coninut este urmtoarea:
reject tcp any 1024: ->
any 1024: (msg:"Secret
String pasiv FTP"; content:"secret";
classtype:policy-violation; sid:1000003; rev:1;)

Activ

1. Clientul iniiaz transferul de pe un

port P mai mare dect 1024, n care
i spune server-ului c va ascult pe
un port P+1.
2. Serverul va iniia apoi transferul
folosind portul 20 conectndu-se la
client pe noul port pe care acesta
ascult.
Acest mod are probleme cu echipamentele
de firewall-ul i cu protocolul NAT,muli
clieni aflndu-se n spatele altor
echipamente de reea( router, firewall,
proxy), serverul neavnd posibilitatea s
ajung niciodat el. Datele pot fi
transferateatt binar ct i n mod asci de
aceea cea mai bun regul este s
fieverificat tot traficul raw pe portul 20

Figura 8.13 - FTP n mod Activ

dup cuvinte cheie:

reject tcp any 20,1024: -> any 20,1024: (msg:"Secret String

FTP Activ"; content:"secret"; classtype:policy-violation;
sid:1000004; rev:1;)

8.7 Filtrarea protocolului SMTP

Simple Mail Transfer Protocol (SMTP) este protocolul standard folosit pentru
transmisia mesajelorelectronice. Serverele de mail comunic prin acest protocol pentru a
transmite mesajele. Protocolul 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:
reject tcp any any ->any 25 (msg:"SMTP topsecret string";
content:"topsecret"; classtype:policy-violation; sid:1000005;
rev:1;)
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

p
112

115

101

99

114

ASCI(Dec)

116

111

101

116

ASCI(Hexa)

74

6F

70

73

65

63

72

65

74

ASCII(Binar)

0111.0100

0110.1111

0111.000

0111.0011

0110.0011

0110.0011

0111.0010

0110.0101

0111.0100

Tabelul 8.14 Codaretopsecret

Conformalfabetului Base64 vom avea:
Bin

011101

000110

111101

110000

011100

110110

010101

100011

011100

100110

010101

110100

Base64(val)

29

61

48

28

54

21

35

28

38

21

52

Base64(enc)

Tabelul 8.15 Codare topsecret base64

88

Figura 8.16 - Alfabetul Base64

Astfeltopsecretva fi codatn Base64 sub forma dG9wc2VjcmV0.
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:
reject tcp any any -> any 25 (msg:"SMTP base64";
content:"base64"; content:"|0d0a0d0a|";base64_decode:relative;
base64_data; content:"topsecret"; within:14; classtype:policyviolation; sid:1000006; rev:1;)

8.8 Logarea
Snort a fost configurat s realizeze urmatorul tip de logare:
Syslog : alertele sunt trimise sub acest standard ctre un server specializat;

Syslog-ul este un standard folosit pentru logarea datelor.Acesta separ software-ul ce a

generat mesajul de sistemul ce l stocheaz i l analizeaz.

89

Cmpurile principale sunt: nivelul facilitii, nivelul de severitate i mesajul n sine.

Figura 8.17 - Nivele de securitate specifice Syslog

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

Figura 8.18 - Nivelele de facilitate Syslog

9.Concluzii

Problemele de securitate care afecteaz sistemele i reelele informatice impun

utilizarea unor soluii care s aib n vedere diferitele tipuri de incidente i ameninri care pot
duce la pierderea unor informaii sensibile.
Sistemele de detecie i prevenie a intruziunilor au devenit obligatorii pentru
protejarea mpotriva diferitelor tipuri de malware, mpotriva interceptrii datelor confideniale
transmise prin reelele informatice, precum i pentru protejarea reelelor interne
organizaionale mpotriva unor aciuni externe ostile, mai ales n cazul instituiilor militare,
care sunt predispuse zilnic la astfel de acte datorit importanei lor strategice n securitatea
naional i mondial. Aceast lucrare a analizat aceste echipamentele din toate punctele de
vedere, de la clasificare, metode de detecie, tehnici de analiz a traficului pn la criterii
relevante ce pot influenta alegerea unui astfel de echipament i cerinele recomandate pentru
blocarea eficient a intruziunilor.
Fiecare IDPS i gen de detec
ie are avantajele i dezavantajele sale, iar pentru a
detecta i preveni cu succes atacurile informatice nu este de ajuns un singur tip de
echipament, ci o combinaie de mai multe echipamente i tehnici de detecie.
Snort este extrem de performant putnd fi folosit cu succes n detecia i prevenirea
scurgerilor de date, cu reineri asupra traficului criptat, trafic ce va trece fr a putea fi
decriptat. Avantajul lui este preul i posibilitatea de a crea reguli proprii care analizeaz
traficul informatic la nivel de bii. O alta problem la Snort este nsi faptul ca este open
source, iar definiiile i configuraiile implicite sunt le vedere, oricine le poate analiza,
modifica i testa, pentru a depista eventualele probleme i arii neacoperite, folosindu-se de
acestea n lansarea unui atac.
Sistemele de detec
ie
i prevenire a intruziunilor, reprezint o variabil foarte
important n ecua
ia unui sistem bine protejat, pentru c una din cele mai importante
resurse, poate chiar mai important dect cele materiale, este dat de infomaie i obinerea
ei. ntr-o lume n care echilibrul mondial este dictat de puterea informaiei, meninerea
confidenialiti acesteia este foarte important, deoarece aceasta d valoarea unei informaii.

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