Sistem de detecie i prevenire a intruziunilor

ntr-o reea

I.

Argumentul

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 si nu numai au nceput sa investeasc n programe antivirus de reea, firewalluri, securitatea mesajelor provenite din posta electronic si 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.

Principiile
intruziunilor

II.

deteciei

preveniei

Detectare intruziunilor reprezint procesul de monitorizare a evenimentelor ce au

loc ntr-un 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. Incidentele 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 incidentelor 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 ( IDPS) 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.

II.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
incidente.
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 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
4

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:
duplicarearegulilor 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;

II.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: emailuri, pagini de rspuns, mesajele de pe interfaa cu utilizatorul sistemului, prin trap-urile de
tip SNMP( Simple Network Management Protocol) , mesaje syslog, ori programe i scripturi 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; 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 deosebit . 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:

Terminarea conexiunii la reea sau a sesiunii de utilizator care este utilizat pentru
atac;
Blocarea accesului la int folosindu-se de adresa IP sau de un alt atribut al
atacatorului;
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 hostbased 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 detecie
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 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 tehnicilor
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.

II.3. Metodologii comune de detecie

Sunt utilizate mai multe metodologii pentru a detecta incidentele.Principalele clase
de detecie sunt bazate pe:
6

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.

II.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 semnturilor 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.

II.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
7

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.
II.3.3 Analiza protocoalelor de tip stateful

Reprezint procesul de comparare 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 IDPS- uri 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
8

revizuite, iar vnztorii modific implementrile, modelele proprii IDPS-urilor trebuie s

fie actualizate pentru a reflecta aceste modificri.

II.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;

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 (DoS), 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 DoS 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 clientilor WLAN.

II.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 propriuzii, 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.
9

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 esurselor 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 15minute 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.
Cteva scopuri pentru care sunt folosite intruziunile sunt:

obinerea accesului de la distan;

furtul de resurse;
sabotajul;
colectarea de date;
10

III.

ocolirea sistemului de control al accesului;

eludarea detectrii.

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).

III.1 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.

11

III.2 Preventia
Sunt oferite diverse capacitati de prevenire, inclusiv urmatoarele( grupate in functie
de tipul de senzor):
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;

12

Figura 4.9 - Exemplu implementare senzori inline

13

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
achetelor 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 pentrutraficul 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
declansa o actiune de prevenire dorita de catre administrator,cum ar fi
reconfigurarea altor dispozitive de securitate pentru a bloca respectiva activitate.

IV. Componente i Arhitectur

IV.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
14

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).
IV.1.1 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. In continuare ne este descris un exemplu de
arhitectura in care putem vedea mai bine cum lucreaza intre ele componentele unei retele
in cadrul unui IDPS la nivel de host.

15

Figura 5.1 - Arhitectura unui IDPS la nivel de host

16

IV.1.2 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 monitorizateprin 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).

V. Capabilitile de securitate
V.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).

V.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.
17

V.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.

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.

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.

V.2.2. Precizia deteciei

Ca orice alte tehnologii, i acest tip cauzeaz de multe ori falsuri pozitive i negativ.
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
18

detectate. De exemplu, o gazd poate fi repornit, o nou aplicaie poate fi instalat sau un
sistem de fiiere poate fi nlocuit. Aceste aciuni ar putea fi realizate prin activiti ru
intenionate sau ar putea fi parte a funcionrii i intreinerii normale a gazdei.
Evenimentele n sine sunt detectate corect, dar natura lor, benigne sau maliioase, nu poate
fi ntotdeauna determinat fr un context suplimentar. Unele produse, n special cele
destinate desktop- urilor / laptop -urilor, cer utilizatorilor furnizarea contextului, dac o
aplicaie este actualizat sau nu de ctre utilizator. Dac acesta nu rspunde la solicitare
ntr-o anumit perioad de timp (de obicei cteva minute), agentul alege o aciune implicit
(permitere / refuzare).
Sistemele care utilizeaz combinaii de mai multe tehnici de detectare ar trebui s
fie, n general, capabile de a realiza o detecie mai precis dect produsele ce utilizeaz una
sau cteva tehnici. Deoarece fiecare tehnic poate monitoriza diferite aspecte ale unei
gazde, folosirea mai multor tehnici permite agenilor colectarea mai multor informaii
privind activitile ce au loc. Acest lucru ofer o imagine mai complet a evenimentelor, i
poate oferi, de asemenea, contextul suplimentar care poate fi de ajutor n evaluarea
inteniei anumitor evenimente.

V.2.3 Limitri tehnologice

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;

19

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) .

V.2.4 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 gent)
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
recunoscute 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,

erificarea integritii fiierelor i a atributelor, n general, nu sprijin aciunile de prevenire,
deoarece acestea identific evenimentele dup ce au avut loc.
V.2.5 Alte capabiliti

20

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:

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
configurat, 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.

V. 3 Management
V.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.
Testarea componentelor i amplasarea. Dup ce componentele au fost evaluate ntr-un
mediu de testare, organizaiile ar trebui s le pun n aplicare doar pe cteva host- uri 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 totacest timp pn la plementarea
n mas pn cnd agenii au fost suficient setai i personalizai;

21

VI. Soluii profesionale IDPS

VI.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 ultitudine 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
plicaie(Windows, Linux etc). Acest soluie este mai ieftin dect un hardware IDPS in
mai 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.

VI. 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;
22

 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.

VI. 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 reveni intruziunile.Aceasta
capabilitate de a identifica i preveni intruziunile este de departe cea mai important dintre
23

toate i extrem de greu de verificat. Aceasta depinde de calitatea semnturilor pe care 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.

VI .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 applianceurile 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 dintro gam diversificat dedomenii, de la sisteme de operare pn la aplicaii, fiind blocate
18(99.4%), o rat mai mult dect excelent. Au fost ncercate i 214 exploatri serverclient, 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%).
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 applianceurile 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
echipament cu 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.

24

VII . SNORT
VII.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.

Modul 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:
Optiune

Observatii

-v

-interactiv, afisarea
TCP/UDP/ICMP

-e

-Headere nivel legaturi de date

-d

Headere aplicatie

-a

-Afisare frame-uri ARP

-c

-Afisare date de tip char din payload( nu le

afiseaza in (hexa)

-i eth0

-Interfata pe care asculta

-d

-Rulare ca daemon

-q

-Rulare in mod quiet( nu mai afiseaza

mesajele de inceput si summary de la exit)

doar

antetelor

Tabelul 7.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.
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.

25

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
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 sub
directoare 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

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.
26

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:
./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.
VII.1.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.
VII.1.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).
Al doilea numr este ID-ul Snort( uneori referit ca ID-ul semnturii).Pentru o list a SIDurilor 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.
VII.1.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

27

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

VII.1.4 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), EJECT
(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.

VII.2 Configurare
VII.2.1 Include

Cuvntul cheie include 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 imbajul de programare C(#include); citete coninutul fiierului numit i l adaug n
locul n care declaraia apare n fiier:
include <include file path/name>
VII.2.2 Variabile

Trei tipuri de variabile pot fi regsite n Snort:

var

portvar

ipvar

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

28

VII .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.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;)
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]

VII.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.

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;
29

reasamblarea TCP : stream5;

normalizarea pachetelor;

date sensibile;

specifice unor diverse protocoale: http, smtp, ftp, ssh ,pop, etc;

atacurile de recunotere: sfPortscan.

VII .3 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.
VII.3.1 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
ctreatacator 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.

30

VII.3.2 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.
VII.3.3 Preprocesorul de date sensibile

Reprezint un modul Snort ce realizeaz detecia i filtrarea datelor de tip

PII(Personally dentifiable 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.Exista o mare diferen de abordare ntre semnturile realizate pentru Snort i
semnturile altor 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 MS08067( 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;

31

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.
VII.3.4 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.
VII .3.5 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.
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.

32

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 <-.
VII .3.6 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;)

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

fi decodarea i normalizarea protocolului, inspectarea acestuia dup semnturi, toate

acesteproceduri provocnd ntrzieri n reea;
33

punct sensibil: dac echipamentul Snort are probleme i se defecteaz, ntreg

traficul va fioprit, un lucru nedorit de atlfel de nimeni.

VIII. Sistem pentru prevenirea scurgerilor de

date

VIII.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 De
necesitile i dorinele fiecruia. O problem majoro reprezint poziionarea IDPS-ului n
cadrul reelei pentru a oferi 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 decodrii protocoalelor 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 eficient i 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.
Avantajele folosirii Snort-ului inline pentru prevenirea scurgerilor de date:
transparen fa 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
aceste proceduri provocnd ntrzieri n reea;
punct sensibil: dac echipamentul Snort are probleme i se defecteaz, ntreg
traficul va fi oprit, un lucru nedorit de nimeni altfel.

34

35

VIII. 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.

O bun aplicaie a Snort-ului este prevenirea scurgerilor de date dintr-o instituie. Snort-ul
oprete traficul n funcie de anumite reguli. Acestea pot fi scrise n funcie de necesitile
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
eficient i 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.

36

Figura 8.2 Funcionare Iptables

37

VIII.3 . 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.

VIII .4.Filtrarea protocolului http i https

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

VIII .5 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
38

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 peun port mai mare de 1024 pe portul 21 al serverului, iar
serverul i va spune c va ncepe s asculte peun port peste 1024.
2. Clientul se va conecta la acel nou port pecare va asculta serverul i va transmite sau
primi date. Astfel datele ce trebuiesc filtratevor circula ntre client i server pe porturi TCP
mai mari dect 1024.
Activ
1. Clientul iniiaz transferul de pe un port P mai mare dect 1024, n care i spune serverlui 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 fie verificat tot
traficul raw pe portul 20 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
IME(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.
Simple Mail Transfer Protocol (SMTP) este protocolul standard folosit pentru transmisia
mesajelorelectronice. Serverele de mail comunic prin acest protocol pentru a transmite
39

mesajele. Protocolul folosete caractere ASCI pentru transmiterea mesajelor fcnd

intercepia i decodarea acestora extrem de uor. Portul folosit este 25.

VIII .6 Filtrarea protocolului SMTP

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;)

VIII .7 Logarea
Snort a fost configurat s realizeze urmatorul tip de logare:

Syslog : alertele sunt trimise sub acest standard ctre un server specializat; Syslogul este un standard folosit pentru logarea datelor.Acesta separ software-ul ce a
generat mesajul de sistemul ce l stocheaz i l analizeaz.

40

IX .

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 detectie si prevenire a intruziunilor, reprezint o variabil foarte
important n ecuatia 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.

41

X . 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

42

CUPRINS
Sistem de detecie i prevenire a intruziunilor ntr-o..........................................2
reea................................................................................................................... 2
I.

Argumentul.................................................................................................. 3

II.

Principiile deteciei i preveniei intruziunilor...............................................4

II.1

Utilizarea tehnologiilor IDPS...................................................................4

II.2 Funciile cheie ale tehnologiilor IDPS.........................................................5

II.3. Metodologii comune de detecie..............................................................6
II.3.1 Detecia bazat pe semnturi.........................................................................7
II.3.2 Detectarea anomaliilor........................................................................7
II.3.3 Analiza protocoalelor de tip stateful....................................................8
II.4 Tipuri de tehnologii IDPS........................................................................... 9
II.5 Intruziunile................................................................................................ 9
III. Capabiliti de logare.................................................................................. 11
III.1 Detecia..................................................................................................... 11
III.2 Preventia................................................................................................ 12
IV. Componente i Arhitectur.........................................................................14
IV.1 Componentele tipice............................................................................. 14
IV.1.1 Arhitectura de reea........................................................................15
IV.1.2 Locaia agenilor.............................................................................. 17
V. Capabilitile de securitate..........................................................................17
V.1. Logare.................................................................................................... 17
V.2. Detecia................................................................................................. 17
V.2.1 Tipuri de evenimente detectate........................................................18
V.2.2. Precizia deteciei.............................................................................. 18
V.2.3 Limitri tehnologice...........................................................................19
V.2.4 Prevenia........................................................................................... 20
V.2.5 Alte capabiliti................................................................................. 20
V. 3 Management.......................................................................................... 21
V.3.1 Implementare.................................................................................... 21
43

VI. Soluii profesionale IDPS.........................................................................22

VI.1 Alegerea IDPS-ului.................................................................................. 22
VI. 2 Cerine pentru prevenirea eficient a intruziunilor................................22
VI. 3 Caracteristici cheie al unui IDPS............................................................23
VI .4 Juctorii importani de pe piaa............................................................24
VII . SNORT.................................................................................................... 25
VII.1 Privire de ansamblu.............................................................................. 25
VII.1.1 Opiuni de output............................................................................ 27
VII.1.2 nelegerea standardului ieirii........................................................27
VII.1.3 Schimbarea ordinii alertelor...........................................................27
VII.1.4 Modulul Inline.................................................................................. 28
VII.2 Configurare........................................................................................... 28
VII.2.1 Include............................................................................................ 28
VII.2.2 Variabile.......................................................................................... 28
VII .2.2.1 Variabile IP. Liste IP.....................................................................29
VII.2.2.2 Variabile port. Liste de porturi......................................................29
VII .3 Frag3.................................................................................................... 30
VII.3.1 sfPortscan....................................................................................... 30
VII.3.2 HTTP Inspect................................................................................... 31
VII.3.3 Preprocesorul de date sensibile......................................................31
VII.3.4 Scriererea Regulilor........................................................................32
VII .3.5 Antetul unei reguli..........................................................................32
VII .3.6 Opiunile unei reguli.......................................................................33
VIII. Sistem pentru prevenirea scurgerilor de date...........................................34
VIII.1 Snort sistem de detectare i prevenie a scurgerilor de....................34
date............................................................................................................... 34
VIII. 2 Iptables............................................................................................... 37
VIII.3 . Metode de detecie i prevenie.........................................................38
VIII .4.Filtrarea protocolului http i https.......................................................39
VIII .5 Filtrarea protocolului FTP....................................................................39
VIII .6 Filtrarea protocolului SMTP..................................................................40
VIII .7 Logarea............................................................................................... 40
44

IX . Concluzii.................................................................................................... 41
X . Bibliografie................................................................................................ 42

45