Sistem de detec ție și prevenire a intruziunilor într-o [609208]
Universitatea “Politehnica” din Bucure ști
Facultatea de Electronic ă, Telecomunica ții și Tehnologia Informa ției
Sistem de detec ție și prevenire a intruziunilor într-o
rețea
Proiect de diplom ă
Prezentat ca cerin ță parțială pentru ob ținerea titului de
Inginer în domeniul Calculatoare și Tehnologia Informa ției
programul de studii de licen ța Ingineria Informa ției
2013 Conducător științific Absolvent: [anonimizat].dr.ing. Mihai STANCIU Alin-Florentin Oprea
Cuprins
CUPRINS …………………………………………………………………………………………………………………………..2
1.INTRODUCERE…………………………………………………………………………………………………………………1
2.PRINCIPIILE DETEC ȚIEI ȘI PREVEN ȚIEI INTRUZIUNILOR ………………………………………………………….2
2.1 U TILIZAREA TEHNOLOGIILOR IDPS ………………………………………………………………………………………….2
2.2 F UNCȚIILE CHEIE ALE TEHNOLOGIILOR IDPS………………………………………………………………………………..3
2.3 M ETODOLOGII COMUNE DE DETEC ȚIE………………………………………………………………………………………5
2.3.1 D ETECȚIA BAZATĂ PE SEMN ĂTURI ……………………………………………………………………………………………..5
2.3.2 D ETECTAREA ANOMALIILOR …………………………………………………………………………………………………….6
2.3.3 A NALIZA PROTOCOALELOR DE TIP STATEFUL ………………………………………………………………………………….7
2.4 T IPURI DE TEHNOLOGII IDPS…………………………………………………………………………………………………8
2.5 I NTRUZIUNILE ………………………………………………………………………………………………………………….9
3. TEHNOLOGII IDPS………………………………………………………………………………………………………….12
3.1 C OMPONENTE ȘI ARHITECTUR Ă…………………………………………………………………………………………… 12
3.1.1 C OMPONENTE TIPICE …………………………………………………………………………………………………………..12
3.1.2 A RHITECTURA DE RE ȚEA……………………………………………………………………………………………………….12
3.2 C APABILIT ĂȚI DE SECURITATE ………………………………………………………………………………………………13
3.2.1 C ULEGEREA INFORMA ȚIILOR ………………………………………………………………………………………………….13
3.2.2 C APABILITĂȚI DE LOGARE ………………………………………………………………………………………………………13
3.2.3 D ETECȚIA…………………………………………………………………………………………………………………………14
3.2.4 P REVENȚIA……………………………………………………………………………………………………………………….16
3.3 M ANAGEMENT ………………………………………………………………………………………………………………16
3.3.1 I MPLEMENTARE …………………………………………………………………………………………………………………16
3.3.2 O PERARE ȘI MENTENAN ȚA…………………………………………………………………………………………………….18
3.3.3 C OMPETEN ȚE DE CONSTRUIRE ȘI MENTENAN ȚĂ……………………………………………………………………………20
4. IDPS-URI LA NIVEL RE ȚEA………………………………………………………………………………………………. 22
4.1 S TIVA TCP/ IP………………………………………………………………………………………………………………. 22
4.2 C OMPONENTE ȘI ARHITECTUR Ă…………………………………………………………………………………………… 26
4.2.1 C OMPONENTE TIPICE …………………………………………………………………………………………………………..26
4.2.2 A RHITECTURA DE RE ȚEA ȘI LOCAȚIILE SENZORILOR ………………………………………………………………………..27
4.3 C APABILIT ĂȚI DE SECURITATE ………………………………………………………………………………………………30
4.3.1 C ULEGEREA INFORMA ȚIILOR ………………………………………………………………………………………………….30
4.3.2 C APABILITĂȚI DE LOGARE ………………………………………………………………………………………………………31
4.3.3 D ETECȚIA…………………………………………………………………………………………………………………………31
4.3.4 P REVENȚIA……………………………………………………………………………………………………………………….35
4.4 M ANAGEMENT ………………………………………………………………………………………………………………37
4.4.1 I MPLEMENTARE …………………………………………………………………………………………………………………37
5. IDPS-URI LA NIVEL DE HOST…………………………………………………………………………………………… 39
5.1 C OMPONENTE ȘI ARHITECTUR Ă…………………………………………………………………………………………… 39
5.1.1 C OMPONENTELE TIPICE ………………………………………………………………………………………………………..39
5.1.2 ARHITECTURA DE RE ȚEA………………………………………………………………………………………………………40
5.1.3 L OCAȚIA AGENȚILOR……………………………………………………………………………………………………………41
5.1.4 A RHITECTURA HOST -ULUI ……………………………………………………………………………………………………..41
5.2 CAPABILIT ĂȚILE DE SECURITATE …………………………………………………………………………………………… 42
5.2.1 L OGARE …………………………………………………………………………………………………………………………..42
5.2.2 D ETECȚIA…………………………………………………………………………………………………………………………42
5.2.3 P REVENȚIA……………………………………………………………………………………………………………………….47
5.2.4 A LTE CAPABILIT ĂȚI……………………………………………………………………………………………………………..47
5.3 M ANAGEMENT ………………………………………………………………………………………………………………48
5.3.1 I MPLEMENTARE …………………………………………………………………………………………………………………48
5.3.2 OPERARE ………………………………………………………………………………………………………………………..49
6. SOLUȚII PROFESIONALE IDPS ………………………………………………………………………………………….50
6.1 A LEGEREA IDPS- ULUI………………………………………………………………………………………………………. 50
6.2 C ERINȚE PENTRU PREVENIREA EFICIENT Ă A INTRUZIUNILOR …………………………………………………………… 51
6.3 C ARACTERISTICI CHEIE AL UNUI IDPS……………………………………………………………………………………..52
7. SNORT…………………………………………………………………………………………………………………………55
7.1 PRIVIRE DE ANSAMBLU ……………………………………………………………………………………………………..55
7.1.2 M ODULUL SNIFFER ……………………………………………………………………………………………………….. 56
7.1.3 M ODULUL LOGGER ………………………………………………………………………………………………………. 56
7.1.4 M ODULUL NIDS………………………………………………………………………………………………………………..57
7.1.5 M ODULUL INLINE ……………………………………………………………………………………………………………….59
7.2 C ONFIGURARE ………………………………………………………………………………………………………………. 59
7.2.1 I NCLUDE ………………………………………………………………………………………………………………………….59
7.3 P REPROCESOARELE ………………………………………………………………………………………………………….62
7.3.1 F RAG3 ……………………………………………………………………………………………………………………………63
7.3.2 SFPORTSCAN …………………………………………………………………………………………………………………….64
7.3.3 HTTP I NSPECT ………………………………………………………………………………………………………………….64
7.3.4 P REPROCESORUL DE DATE SENSIBILE …………………………………………………………………………………………64
7.4 S EMNĂTURI / REGULI ………………………………………………………………………………………………………. 66
7.4.1 S CRIEREREA REGULILOR ……………………………………………………………………………………………………….70
7.4.2 A NTETUL UNEI REGULI …………………………………………………………………………………………………………70
7.4.3. O PȚIUNILE UNEI REGULI ………………………………………………………………………………………………………71
7.4.4 P RAGUL UNEI REGULI …………………………………………………………………………………………………………..74
8. SISTEM PENTRU PREVENIREA SCURGERILOR DE DATE………………………………………………………..74
8.1 S NORT –SISTEM DE DETECTARE ȘI PREVEN ȚIE A SCURGERILOR DE DATE ……………………………………………… 74
8.2 I PTABLES ………………………………………………………………………………………………………………………75
8.3 A RHITECTURA DE RE ȚEA UTILIZAT Ă……………………………………………………………………………………….. 80
8.4. M ETODE DE DETEC ȚIE ȘI PREVEN ȚIE………………………………………………………………………………………81
8.5.F ILTRAREA PROTOCOLULUI HTTP ȘI HTTPS ……………………………………………………………………………….. 82
8.6 F ILTRAREA PROTOCOLULUI FTP …………………………………………………………………………………………… 86
8.7 F ILTRAREA PROTOCOLULUI SMTP………………………………………………………………………………………… 87
8.8 L OGAREA ……………………………………………………………………………………………………………………..89
9.CONCLUZII ……………………………………………………………………………………………………………………..1
10.BIBLIOGRAFIE………………………………………………………………………………………………………………..2
11.Introducere
În ziua de ast ăzi cu hackerii și hoții de identitate securitatea computerului a
devenit tot mai instabil ă, astfel pentru a fi mereu cu un pas în fa ța atacurilor r ău
voitoare companiile i nu numai au început sa investeasc ă în programe antivirus de
rețea, firewall-uri, securitatea mesajelor provenite din po ta electronic ă i web
pentru protec ția asupra posibilelor amenin țări externe. Cum prin simpla conectare a
unui stick poate prezenta o teribil ă amenințare, problema detec ției și prevenirii
intruziunilor a devenit una extrem de important ă în zilele noastre, problem ă abordată și
în această lucrare.
Scopul principal al lucr ării este acela de a veni in ajutorul sta țiilor expuse la
risc prin proiectarea unui software ce are rolul de a identifica atacurile r ău voitoare
asupra rețelelor și resurselor acesteia, de a stopa intruziunile detectate și de a imuniza
sistemul. Informa țiile provenite in urma detec ției se vor comunica sta ției centrale mai
precis adminului printr-o anumita notificare, pentru a putea lua decizia optim ă cât mai
repede cu putin ță cu privire la starea re țelei.
22.Principiile detec ției și prevenției intruziunilor
Detectare intruziunilor reprezintă procesul de monitorizare a evenimentelor ce au loc într-
un sistem informatic sau într-o re țea, precum și analizarea acestora pentru semne ce indic ă
incidente posibile ce sunt înc ălcări sau amenin țări iminente de înc ălcare a politicilor de
securitate ale calculatorului, a politicilor acceptate de utilizare sau practicile de securitate
standard. Incindentele pot avea multe cauze, ca malware-urile(ex: worms, spyware), atacatori
externi ce încearc ă să obțină accesul neautorizat la sistem precum și utilizatori autoriza ți ce
întrebuințează greșit privilegiile oferite sau încearc ă să obțină unele adi ționale ce nu sunt
autorizate. Cu toate c ă majoritatea incindentelor sunt de natur ă malițioasă, multe altele nu
sunt: de exemplu, o persoan ă poate introduce gre șit adresa unui calculator, și astfel,
neintenționat să acceseze un alt sistem f ără autorizație.
Prevenirea intruziunilor presupune detectare și încercarea de a opri incidente posibile
detectate.
Un sistem de detec ție a intruziunilor este un software ce automatizeaz ă procesul de
detecție.
Un sistem de prevenire a intruziunilor este un software ce are toate capabilit ățile
sistemului de detec ție, dar care poate s ă încerce s ă oprească eventualele incindente.
Sistemele de detectare și prevenire ( IDPS1) se concentreaz ă în principal pe :
identificarea posibilelor incidente;
logare de informa ții despre ac țiunile întreprinse;
încercarea de stopare a incidentelor și raportarea acestora la administratorii de
securitate.
Multe IDPS-uri, pe lâng ă logare, pot preveni amenin țările detectate în a- și îndeplini
scopul. Sunt folosite mai multe tehnici de ac țiune în oprirea atacurilor: schimbarea mediului
de securitate (de exemplu, reconfigurarea unui firewall) sau schimbarea con ținutului atacului.
2.1 Utilizarea tehnologiilor IDPS
Scopul principal al IDPS-urilor este identificarea posibilelor incindente.De exemplu,
un IDPS poate detecta când un atacator a compromis cu succes un sistem prin exploatarea
vulnerabilit ăților sale. Poate raporta apoi incindetul administratorilor de securitate, care pot
iniția acțiuni de răspuns pentru a minimiza daunele cauzate de incident2.
Multe astfel de sisteme pot fi configurate s ă identifice:
violările politicilor de securitate(ex: setarea cu seturi de reguli asem ănătoare unui
firewall, permi țănd identificarea traficului ce încalc ă normele de securitatea ale unei
1Pe parcursul lucr ării se va folosi acest termen pentru a abrevia expresia consacrat ă din domeniu
“Intrusion detection and prevention system”
2 Dacă IDPS a prevenit cu succes atacul, administratorii de securitate tot doresc s ă fie notifica i
de atac.Este important de tiut dacă inta a avut o vulnerabilitate cunoscut ă pe care atacatorul ar fi putut s ă o
exploateze.Asupra respectivei vulnerabilit ăi pot fi lansate alte atacuri pe care IDPS nu le poate recunoa te.
3companii: monitorizarea transferurilor de fi șiere și recunoașterea celor ce ar putea fi
suspicioase, asemenea transferului unei baze de date într-un laptop);
activitățile de recunoa ștere, ce indic ă de cele mai multe ori iminen ța unui posibil
atac(ex: unele tool-uri de atac și forme de malware – în special cel de tip worm)
efectueaz ă activități de recunoa ștere ca scanarea de host-uri și port-uri pentru
identificarea unor ținte pentru atacurile viitoare.Un IDPS poate bloca aceste ac țiuni,
notificând în acela și timp administratorii de securitatea, care pot interveni, dac ă este
nevoie, pentru a preveni incindente viitoare.Datorit ă frecvenței foarte mari a
activităților de recunoa ștere în internet, detec ția acestora se concentreaz ă în mod
deosebit pe re țele interne.
Organizațiile folosesc sistemele de detec ție și prevenție și în alte scopuri, altele decât cele
de bază:
identificarea problemelor politicilor de securitate: poate oferi indica ții asupra calit ății
controlului oferit de implementarea politicilor de securitate existente( ex: duplicarea
regulilor firewall și alertarea traficului ce ar fi trebuit blocat de c ătre firewall, dar din
cauza unor erori de configurare nu a fost blocat;
documentarea ameni țărilor existente asupra organiza ției: logarea informa țiilor legate
de amenin țările ce sunt detectate ajut ă la identificarea caracteristicilor și frecvenței
diverselor atacuri asupra resurselor computa ționale ale organiza ției.Astfel, pot fi
adoptate m ăsurile adecvate pentru protejarea resurselor existente;
descurajarea diverselor persoane în a înc ălca politicile de securitate: ac țiunea de
monitorizare a tehnologiilor descurajeaz ă violarea normelor de securitate din cauza
riscului de detec ție.
Din cauza dependen ței tot mai sporite fa ță de sistemele informa ționale precum și
potențialul impact al intruziunilor asupra acestor sisteme, IDPS-urile au devenit un plus
necesar pentru infrastructura de securitate a oric ărei organiza ții.
2.2 Funcțiile cheie ale tehnologiilor IDPS
Există multe tipuri de tehnologii, ce sunt diferen țiate în principal dup ă tipurile de
evenimente pe care le pot recunoa ște și metodologiile pe care le utilizeaz ă pentru identificarea
incidentelor. În plus fa ță de monitorizarea și analizarea evenimentelor pentru a identifica
activitățile nedorite, toate tehnologiile efectueaz ă de obicei urm ătoarele func ții:
Înregistrare informa țiilor referitoare la evenimentele observate . Informațiile sunt
de obicei înregistrate la nivel local, și ar putea fi, de asemenea, trimise la sisteme
separate, cum ar fi serverele centralizate de log, solu țiile informa ționale de securitate
și de management al evenimentelor (SIEM) sau solu ții și sisteme enterprise de
management;
4Notificarea administratorilor de securitate despre evenimente importante
observate . Această notificare, cunoscut sub numele de alert ă, survine prin mai multe
metode: email-uri, pagini de r ăspuns, mesajele de pe interfa ța cu utilizatorul a
sistemului, prin trap-urile de tip SNMP( Simple Network Management Protocol) ,
mesaje syslog, ori programe și script-uri definite de utilizator. Un mesaj de notificare
include de obicei doar informa ții de bază cu privire la un eveniment, administratorii
trebuie să acceseze IDPS-ul pentru informa ții suplimentare;
Întocmirea de rapoarte . Rapoartele rezum ă evenimentele monitorizate sau ofer ă
detalii cu privire la anumite evenimente de interes.
Unele IDPS-uri au posibilitatea de a- și schimba profilul de securitate atunci când o
nouă amenințare este detectat ă. De exemplu, ar putea fi capabil s ă colecteze mai multe
informații referitoare la o sesiune în special dup ă ce este detectat ă activitatea malware în acea
sesiune. Ar putea modifica, de asemenea, diverse set ări atunci când anumite alerte sunt
declanșate sau ce prioritate ar trebui asignat ă alertelor ulterioare detec ției unei amenin țări
deosebite.
Acțiunile de r ăspuns inițiate în cazul detec ției unor atacuri se grupeaz ă astfel:
Oprirea atacului f ără vreo altă interven ție.Acest lucru ar putea fi realizat dup ă cum
urmează:
oTerminarea conexiunii la re țea sau a sesiunii de utilizator care este utilizat ă
pentru atac;
oBlocarea accesului la țintă folosindu-se de adresa IP sau de un alt atribut al
atacatorului;
oBlocarea oric ărui acces la host-ul, serviciul, aplica ția sau orice alt ă resursă
vizată.
Schimbarea mediului de securitate . IDPS-ul putea schimba configura ția altor
controale sau dispozitive de securitate pentru a întrerupe un atac. Exemple comune
sunt reconfigurarea unui dispozitiv de re țea (firewall, router, switch) pentru a bloca
accesul către atacator sau țintă, precum și modificarea unui firewall de tip host-based
pentru a bloca atacurile primite. Unele tehnologii pot provoca chiar instalarea unor
patch-uri pe un anume host în cazul în care se detecteaz ă că acesta are vulnerabilit ăți;
Schimbarea con ținutului atacului . Unele tehnologii pot elimina sau înlocui por țiuni
malițioase ale unui atac pentru a-l face benign. Un exemplu simplu este eliminarea
unui fișier infectat ata șat unui email și apoi să permită email-ului „cur ățat” să ajungă
la destinatar.Un exemplu mai complex este comportarea asem ănătoare a unui proxy ce
normalizeaz ă cererile primite, materializat prin îndep ărtarea antetelor pachetelor.Acest
lucru poate cauza împiedicarea unor diverse atacuri.
Un alt atribut al acestor tehnologii este faptul c ă acestea nu pot oferi o detecte ție
caracterizat ă de o acurate țe maximă. Atunci când un IDPS identific ă în mod incorect ca fiind
rău intenționată o activitate benign ă, putem spune c ă a avut loc un fals pozitiv. Atunci când un
IDPS nu reu șește să identifice o activitate malware, un rezultat de tip fals negativ a avut loc.
Eliminare tuturor falsurilor pozitive și negative nu este posibil ă, în cele mai multe cazuri,
5reducerea unuia duce la apari ția celuilalt. Multe organiza ții aleg să scadă aparițiile de falsuri
negative, cu costul cre șteri falsurilor pozitive, fapt ce duce la detec ția mai multor evenimente
periculoase, f ăcându-se uz de mai multe resurse de analiz ă pentru a se face diferen ța între
evenimentele fals pozitive și cele malware. Modificarea configura ției unui IDPS pentru a
îmbunătăți precizia de detectare este cunoscut ă sub numele de tuning.
Cele mai multe tehnologii IDPS ofer ă funcționalități ce combat utilizarea tehnicile
comune de evaziune.Evaziunea reprezint ă modificarea formatului activit ăților malware, astfel
încât „înfățișarea” acestora se schimb ă, dar efectul r ămâne acela și. Atacatorii folosesc tehnici
de evaziune pentru a încerca s ă prevină detecția atacurilor realizat ă de IDPS-uri.De exemplu,
un atacator ar putea codifica caractere text într-un anume mod, știind că ținta știe să
interpreteze caracterele codificate, în speran ța că orice IDPS de monitorizare nu o face. Cele
mai multe tehnologii IDPS pot dep ăși tehnicile comune de evaziune prin duplicarea unor
procesări speciale efectuate de c ătreținte.În cazul în care IDPS-ul poate "vedea" activitatea în
același mod în care o face ținta, atunci tehnicile de evaziune vor fi ineficiente în încercarea de
a ascunde atacurile.
2.3 Metodologii comune de detec ție
Sunt utilizate mai multe metodologii pentru a detecta incidentele.Principalele clase de
detecție sunt bazate pe:
Semnături;
Anomalii
Analiza protocoalelor de tip stateful
Cele mai multe tehnologii IDPS utilizeaz ă metodologii de detec ție multiple, fie
separat, fie integrate, pentru asigurarea unei detec ții cât mai largi și mai precise.
2.3.1 Detec ția bazată pe semnături
O semnătură reprezint ă un model ce corespunde unei amenin țări cunoscute. Detec ția
bazată pe semnături este procesul de comparare a semn ăturior împotriva evenimentelor
observate pentru a identifica posibilele incidente.Exemple de semn ături:
O încercare de conexiune telnet cu numele de utilizator "root"(reprezint ă o încălcare a
politicii de securitate a unei organiza ții);
Un email cu un subiect de genul "Imagini gratuite!" și un fișier atașat cu numele
"freepics.exe", care sunt caracteristici ale unei forme cunoscute de malware;
Un log al sistemului de operare, cu o valoare de cod de stare 645, ceea ce indic ă faptul
că auditul gazdei a fost dezactivat.
Acest tip de detec ție este foarte eficient în detectarea amenin țărilor cunoscute, dar în
mare parte ineficient ă la detectarea amenin țărilor necunoscute anterior, amenin țărilor
deghizate de utilizarea unor tehnici de evaziune, și a multe variante de amenin țări cunoscute.
De exemplu, în cazul în care un atacator a modificat malware-ul în exemplul precedent pentru
a utiliza un nume de "freepics2.exe", o semn ătură în căutarea lui "freepics.exe" nu l-ar potrivi.
6Se poate spune c ă este cea mai simpl ă metodă de detectare, deoarece compar ă doar
unitatea curent ă de activitate, cum ar fi un pachet sau o intrare din loguri, cu o list ă de
semnături utilizând operatorii de comparare a șirurilor de caractere. Tehnologiile de detectare
bazate pe semn ături nu au capacitatea de a întelege re țelele sau protocoale de tip aplica ție și
nu pot urm ări și înțelege starea comunica țiilor complexe. De exemplu, acestea nu pot asocia o
cerere cu r ăspunsul corespunz ător. Le lipse ște capacitatea de a- și aminti cererilor anterioare la
procesarea celei actuale. Aceast ă limitare împiedic ă detectare atacurilor formate din mai
multe evenimente, în cazul în care nici unul din evenimentele nu con ține o indica ție clară a
unui atac.
2.3.2 Detectarea anomaliilor
Detecția anomaliilor reprezint ă procesul de comparare a defini țiilor activit ăților ce
sunt considerate normale cu defini țiile acelor evenimente observate pentru a identifica
abaterile semnificative. Un IDPS ce folose ște detectia anomaliilor de ține niște profiluri ce
reprezintă comportamentul normal al utilizatorilor, host-urilor din re țea, conexiunilor la re țea
sau al aplica țiilor. Profilurile sunt dezvoltate prin monitorizarea caracteristicilor activit ății
tipice într-o perioad ă de timp. De exemplu, un profil de re țea ar putea ar ăta ca activitatea web
cuprinde o medie de 14% din banda de re țea în timpul orelor tipice de lucru. Sunt folosite
apoi metode statistice pentru a compara caracteristicile activit ății curente cu pragurile
specifice din profil, cum ar fi detectarea momentului în care activitatea web folose ște mult
mai multă lățime de band ă decât este a șteptat, alertând apoi administratorul. Profilurile pot fi
dezvoltate pentru mai multe atribute comportamentale, cum ar fi num ărul de email-uri trimise
de un utilizator, num ărul de încerc ări de autentificare e șuate realizate de c ătre un host, precum
și nivelul de utilizare al procesorului pentru un host într-o anumit ă perioadă de timp.
Beneficiul major al metodelor bazate pe detec ția anomaliilor este c ă acestea pot fi
foarte eficiente în detectarea amenin țărilor necunoscute anterior. De exemplu, s ă presupunem
că un calculator este infectat cu un nou tip de malware. Malware-ul poate consuma resursele
de procesare ale computerului, trimi țând un numar mare de email-uri, ini țiază foarte multe
conexiuni la re țea, fiind astfel caracterizat de un comportament total diferit fa ță de profilul
stabilit calculatorului respectiv.
Un profil ini țial este generat dup ă o perioad ă de timp(câteva zile, uneori s ăptămâni),
numită perioadă de formare. Acesta poate fi static sau dinamic. Odat ă generat, un profil static
râmăne neschimbat, cu excep ția cazului în care IDPS-ul va genera un nou profil. Un profil
dinamic se ajusteaz ă în mod constant pe m ăsură ce sunt observate evenimente suplimentare.
Deoarece sistemele de calcul și rețelele se schimb ă în timp, m ăsurile corespunz ătoare unui
comportament normal, de asemenea, se modific ă; un profil static va deveni în cele din urm ă
inexact, a șa că va trebui regenerat periodic. Profilurile dinamice nu au aceast ă problemă, dar
acestea sunt sensibile la tentativele de evaziune folosite de c ătre atacatori. De exemplu, un
atacator poate efectua ocazional un numar mic de activit ăți malware, apoi cre ște încet
frecvența și numărul activit ăților. În cazul în care rata de schimbare este suficient de mic ă,
IDPS-ul ar putea crede activitatea de malware ca fiind un comportament normal și să îl
includă în profilul s ău. Activitatea de malware ar putea fi, de asemenea, obervat ă de către un
IDPS în timp ce construie ște profilurile sale ini țiale. Includerea neinten ționată a activităților
malware, ca parte a unui profil, este o problem ă comună. În unele cazuri, administratori pot
modifica profilul s ă excludă activitatea ce este cunoscut ă drept dăunătoare din profil.
7O altă problemă cu construc ția profilurilor este c ă aceasta poate fi foarte dificil ă, în
unele cazuri, pentru a le face corecte, deoarece activitatea de calcul poate fi foarte complex ă.
Dacă o anume activitate de între ținere ce efectueaz ă transferuri de fi șiere mari are loc doar o
dată pe lună, s-ar putea s ă nu fie observat ă în timpul perioadei de formare; atunci când se va
produce între ținerea, este probabil s ă fie considerat ă o deviere semnificativ ă de la profil și se
va declan șa o alertă. Produsele IDPS ce se bazeaz ă pe acestă metodă produc de multe ori mai
multe alarme false de tip fals pozitiv din cauza activit ăților benigne care se abat semnificativ
de la profil, în special în mediile mai diverse sau dinamice. O alt ă problemă notabilă este acea
că adesea este dificil pentru anali ști să determine ini țial de ce un anumit tip de alert ă a fost
generată, iar apoi s ă o valideze(s ă nu constituie un fals pozitive), din cauza complexit ății
evenimentelor și a numărului de evenimente care ar fi putut s ă o cauzeze.
2.3.3 Analiza protocoalelor de tip stateful
Reprezint ă procesul de compararea a profilurilor prestabilite ale defini țiilor, general
acceptate, ale activit ăților benigne ale protocoalelor pentru fiecare stare de protocol împotriva
evenimentelor observate pentru a identifica devia țiile. Spre deosebire de detec ția anomaliilor,
care folose ște profiluri specifice host-urilor sau re țelei, aceast ă analiză se bazeaz ă pe profiluri
universale, dezvoltate de diver și furnizori ce specific ă modul în care ar trebui s ă fie utilizate
sau nu anumite protocoale.”Stateful” înseamn ă că IDPS-ul este capabil s ă înțeleagă și să
urmărească starea protocoalelor specifice nivelului re țea, transport sau aplica ție, în cazul celor
care au no țiunea de stare. De exemplu, atunci când un utilizator începe o sesiune de FTP( File
Transfer Protocol ), sesiunea este ini țial într-o stare neautentificat ă. Utilizatorii neautentifica ți
ar trebui s ă efectueze doar câteva comenzi în aceast ă stare, cum ar fi vizualizarea informa țiilor
de ajutor sau furnizarea de nume de utilizator și parole. O parte important ă a înțelegerii st ării
este asocierea cererilor cu r ăspunsuri, astfel încât atunci când are loc o tentativ ă de
autentificare FTP, IDPS-ul poate determina dac ă acesta a fost de succes prin c ăutarea codului
de stare în r ăspunsul corespunz ător. Odată ce utilizatorul a fost autentificat cu succes,
sesiunea este în stare autentificat ă, așteptându-se de la utilizatori efectuarea oric ărei comenzi
dintr-un grup. Efectuarea celor mai multe dintre aceste comenzi în stare neautentificat ă vor fi
considerat suspecte, dar în stare autentificat ă efectuarea celor mai multe dintre ele este
considerat ă benignă.
Pot fi identificate secven țe neașteptate de comenzi, cum ar fi emiterea unei comenzi în
mod repetat sau emiterea unei comenzi f ără a emite în primul rând o comand ă de care aceasta
depinde. O alt ă caracteristic ă de urmărire este aceea c ă pentru protocoale care efectueaz ă
autentificare, poate fi urm ărit autentificatorul pentru fiecare sesiune și să fie înregistrat pentru
activități suspecte. Acest lucru este util atunci când se investigheaz ă un incident. Unele IDPS-
uri pot utiliza informa țiile autentificatorului pentru a defini activi țăti acceptate pentru diferite
clase de utilizatori sau pentru anumi ți utilizatori.
Această analiză include, de obicei, controale rezonabile asupra unor comenzi
individuale, cum ar fi lungimea minim ă și maximă de argumente. Dac ă o comand ă are, de
obicei, un nume de utilizator ca argument format din maxim 20 de caractere, atunci un
argument cu o lungime de 1000 de caractere este suspect. În cazul în care argumentul cu o
lungime mare con ține date binare, gradul de suspiciune va cre ște.
Sunt utilizate modele de protocol, ce sunt de obicei bazate în principal pe standardele
de protocol de la furnizori de software și organismele de standardizare (ex: Internet
Engineering Task Force [IETF] Request for Comments [RFC]). Modelele de protocol iau în
8considerare, de asemenea, diferen țele ce apar în diferitele implement ări. Multe standarde nu
oferă o descriere complet ă a protocolului, cauzând astfel varia ții între implement ări. De
asemenea, produc ătorii încalc ă de multe ori standardele sau adaug ă caracteristici proprietare,
unele putând înlocui caracteristicile standard. Pentru protocoalele proprietare, detaliile
complete nu sunt adesea disponibile, fapt ce va îngreuna furnizarea unor analize complete și
exacte de c ătre tehnologiile IDPS. Pe m ăsură ce protocoalele sunt revizuite, iar vânz ătorii
modifică implement ările, modelele proprii IDPS-urilor trebuie s ă fie actualizate pentru a
reflecta aceste modific ări.
Această metodă de analiz ă este o consumatoarea foarte mare de resurse, din cauza
complexit ății analizei realizate și supraînc ărcarea ce rezult ă din urmărirea simultan ă a mai
multor sesiuni.De altfel, acest fapt reprezint ă și dezavantajul principal al acestei metode. O
altă problemă serioasă este aceea c ă atacurile care nu încalc ă caracteristicile de comportament
general acceptat al protocolului nu sunt detectate(ex: efectuarea mai multor ac țiuni benigne
într-o perioad ă scurtă de timp pentru a provoca o blocare a serviciului – DoS). Pe lâng ă
acestea, modelul de protocol utilizat de un IDPS ar putea intra în conflict cu modul în care
protocolul este implementat în diferite aplica ții și sisteme de operare.
2.4 Tipuri de tehnologii IDPS
Există mai multe tipuri de tehnologii IDPS, în func ție de tipul de evenimente pe care le
monitorizeaz ă și de modul în care acestea sunt implementate, acestea sunt împ ărțite în
următoarele patru grupe:
La nivel de re țea: monitorizeaz ă traficul de re țea pentru anumite segmente de re țea
sau dispozitive, analizând activit ățile protocoloalelor de re țea și aplicație pentru a
identifica activit ăți suspecte. Se pot identifica diferite evenimente de interes. Este
amplasat de cele mai multe ori la o grani ță între rețele, cum ar fi în apropierea
firewall-urilor sau routerelor, serverelor de re țea virtuală privată (VPN), serverelor de
acces de la distan ță și rețelelor fără fir;
9Figura 2.1 – Tehnologii IDPS
Fără fir: monitorizeaz ă traficul de re țea fără fir și analizeaz ăprotocoalele sale de re țea
pentru a identifica activit ăți suspecte care implic ă protocoalele în șăși. Nu poate
identifica activit ăți suspecte ce implic ă protocoale de nivel aplica ție sau de transport (
TCP, UDP), în traficul de re țea fără fir ce este transferat. Î și desfășoară activitatea de
monitorizare, cel mai frecvent, în raza de ac țiune a rețelei fără fir a unei organiza ții;
Analiza comportamentului de re țea(Network Behavior Analysis – NBA):
examineaz ă traficul de re țea pentru a identifica amenin țările care genereaz ă fluxuri de
trafic neobi șnuit, cum ar fi blocarea distribuit ă a unui serviciu (DDoS), anumite forme
de malware( viermi, backdoors) și încălcări ale politicii (ex: un sistem client ce
furnizează servicii de re țea pentru alte sisteme). Sistemele NBA sunt cel mai adesea
utilizate pentru a monitoriza fluxurile de pe re țelele interne ale unei organiza ții, și
sunt, de asemenea, uneori, utilizate pentru a monitoriza fluxurile între re țelele unei
organizații și rețelele externe;
La nivel de host: monitorizeaz ă caracteristicile unei singur host și evenimentele care
au loc în acel host pentru activit ăți suspecte.Tipurile de caracteristici urm ărite sunt:
traficul de re țea(numai pentru gazda respectiv ă), logurile de sistem, procesele active,
activitățile aplicațiilor, accesul la fi șiere precum și modificarea acestora, schimbarea
configura ției sistemului sau a unor aplica ții. Sunt cel mai frecvent utilizate pe gazde
critice, cum ar fi servere accesibile în exterior sau servere care con țin informa ții
sensibile.
Unele forme de IDPS sunt mai mature decât altele pentru c ă au fost folosite mult mai mult
timp. Cele la nivel re țea și unele forme la nivel de host sunt disponibile pe pia ță de peste zece
ani. Cele bazate pe analiza comportamental ă a rețelei sunt o form ă oarecum mai nou ă ce a
evoluat din produsele create special pentru a detecta atacuri de tip DDoS și din produse
dezvoltate pentru a monitoriza fluxurile de trafic în re țelele interne. Tehnologiile f ără fir sunt
un tip relativ nou, dezvoltat ca r ăspuns la popularitatea re țelelor locale wireless (WLAN) și a
amenințărilor în cre ștere la adresa re țele WLAN și clienților WLAN.
2.5 Intruziunile
Intruziunile sunt unele dintre cele mai mari amenin țări la adresa retelelor de
calculatoare și a sistemelor de calcul. Acestea exploateaz ă slăbiciuni ale software-ului sau ale
configuratiei sistemului pentru a-l deteriora. Printre ace știa regăsim: virușii propriu-zi și, viruși
de macro și de email, cai troieni și viermi.
De numele acestor tipuri de amenin țări se leagă principalele unelte folosite de
persoanele r ău intenționate în demersul lor de a ob ține date sensibile care pot fi valorificate în
vreun fel.
Virușiisunt programe – cod executabil numit uneori malware – care se insereaz ă în alt
program executabil. Astfel, virusul se propag ă atunci când este executat programul infectat.
Virusul este pasiv deoarece are nevoie ca un utilizator sau un alt program s ă-l lanseze și să
execute programul infectat. Înainte de acest eveniment, virusul r ămâne în stare adormit ă. La
10activare codul este plasat în memoria central ă a calculatorului și își îıncepe execu ția exact ca
orice alt program.
De obicei, atunci când este activat, virusul î și insereaz ă copii ale sale în cele mai
comune executabile pe care le poate g ăsi pe discul rigid al calculatorului victim ă, proces
numit auto-replicare. Programele infectate se r ăspândesc de obicei de la un calculator la altul
prin copii pe medii de stocare sau prin desc ărcarea de pe Internet.
Cel mai adesea utilizatorii schimb ă între ei documente, nu programe. Acestea pot fi
ținta virusilor de macro și de e-mail. Macrodefini țiile executate de aplica ții cum sunt
Microsoft Word, Excel sau Outlook pot fi și ele infectate de viru și. La deschiderea unui
document infectat virusul se execut ă în background, f ără ca utilizatorul s ă observe.
În mod asem ănător, există viruși care se pot ata șa la e-mail. De îndat ă ce destinatarul
deschide con ținutul unui mesaj infectat, virusul este executat. De cele mai multe ori, încep s ă
trimită email-uri care con țin copii ale lor fiec ărui contact g ăsit în cartea de contacte a victimei.
Virușii de email pot cauza pagube mari infrastructurii de email a Internet prin traficul
enorm pe care îl genereaz ă ca urmare a replic ării multiple. În unele cazuri au provocat c ăderea
serverelor de email care nu au rezistat volumului imens de trafic.
Caii troieni constituie un tip aparte de malware care deschide por ți în sisteme pentru
intruși. Termenul de cal troian este utilizat pentru a descrie software care permite atacatorilor
aflați la distan ță să ia controlul sistemului de calcul, s ă descarce fi șiere, să instaleze aplica ții,
să modifice fi șiere și chiar să oprească de tot sistemul.
Caii troieni sunt programe instalate f ără cunoștința încărcăturii ostile de c ătre
utilizatori în urma unei infect ări a unui fi șier sau a unei aplica ții descărcate de pe Internet.
Unul dintre cei mai faimo și cai troieni, Back Orifice, este atât de puternic încât a ajuns s ă fie
considerat program de gestiune de la distan ța a sistemelor de calcul.
Viermii se pot replica f ără intervenția utilizatorului. În timp ce viru șii sunt pasivi și au
nevoie de interven ția utilizatorului pentru a se rula, viermii sunt activi. Din cauza faptului c ă
nu au nevoie de interven ția utilizatorului și se pot replica și activa autonom, ei sunt mult mai
periculoși. Aceștia sunt programe care folosesc erorile de programare (bug-uri) ale resurselor
din rețea pentru a se replica. Ei se pot inocula în sistemele de calcul datorit ă erorilor din
server, loc în care încep s ă scaneze re țeaua în căutarea altor calculatoare pe care s ă le
infecteze. Proliferarea unui vierme este uimitoare. De exemplu, Code Red a avut nevoie de 15
minute pentru a infecta mii de calculatoare și a atacat chiar site-ul oficial al Casei Albe a
SUA. Pe lâng ă căutarea altor calculatoare pe care s ă le infecteze, viermii pot cauza pagube
prin atacarea re țelei și a componentelor sale. Un sondaj la nivel na țional în SUA, sponsorizat
de către CA Incorporated și de National Cyber Security Alliance (NCSA) a ar ătat că 83%
dintre adul ții care se implic ă în legături sociale prin re țele de calculatoare au desc ărcat fișiere
necunoscute, care le puteau expune PC-urile la atacuri.
Spyware-ul poate fi definit ca orice software care folose ște conexiunea la Internet a
unui utilizator în fundal. Termenul de spyware este, în majoritatea cazurilor, sinonim cu
adware, și poate fi un program de genul cailor troieni. Programele spyware pot colecta date
sensibile (cum sunt: versiunea de sistem de operare rulat ă, tipul de r ăsfoitor de Web, dac ă
limbajul de scenarii poate fi executat, dimensiunea ecranului, plug-in-urile disponibile,
informații de DNS din domeniu, pot trasa ruta spre surs ă pentru a stabili unde se afl ă
calculatorul țintă pe rețea) pe dou ă căi: prin cookies și instalându-se și apoi executându-se.
Programele care prezint ă risc, în leg ătură cu codul ostil sunt numite generic ”riskware” și
constituie orice program legal care poate fi folosit de atacatori pentru a penetra calculatoarele.
Un rootkit poate fi considerat ca un cal troian introdus într-un sistem de operare.
11Pentru ca un atacator s ă poată instala un rootkit el trebuie s ă aibă acces la nivelul de
administrator la sistem înainte de a putea instala kit-ul respectiv. Rootkit-urile nu permit
obținerea accesului la sistem, ci dau posibilitatea de a p ătrunde în sistem cu permisiuni de
nivel maxim (root). O dat ă obținut accesul la nivel de administrator, poate fi folosit un cal
troian care s ă se deghizeze într-o func ție sistem existent ă pe sistemul compromis.
Un atac cibernetic de tip DoS ( Denial of Service ) sau DDoS (Distributed Denial of
Service )este o încercare frauduloas ă de a indisponibiliza sau bloca resursele unui calculator.
Deși mijloacele și obiectivele de a efectua acest atac sunt foarte diverse, în general acest atac
este efectul eforturilor intense ale unei (sau a mai multor) atacatori de a împiedica un site web
sau servicii din Internet de a func ționa eficient, temporar sau nelimitat. Autorii acestor atacuri
au de obicei drept țintă site-uri sau servicii g ăzduite pe servere cu cerin țe înalte, cum ar fi
băncile, gateway-uri pentru pl ăți prin carduri de credit și chiar servere în întregime. O metod ă
tradițională de atac provoac ă „saturarea” calculatorului țintă (victimei) cu cereri de
comunicare externe, astfel încât s ă nu mai poat ă reacționa eficient la traficul Internet legitim,
sau chiar s ă devină indisponibil.
În termeni generali, atacurile de tip DoS se realizeaz ă pe mai multe c ăi:
provocarea unui reset for țat al calculatorului sau al mai multor calculatoare;
consumarea intens ă a resurselor disponibile ale unui server, astfel încât acesta s ă nu
mai poată furniza servicii;
blocarea comunica țiilor dintre utilizatorii bine inten ționați și calculatorul victim ă,
astfel încât acesta s ă nu mai poat ă comunica adecvat;
Atacurile de tip Denial of Service sunt considerate înc ălcări ale politicii de utilizare
corectă a Internetului elaborate de Internet Architecture Board .De asemenea aceste atacuri
constituie deseori înc ălcări ale legisla ției din țara respectiv ă.
Câteva scopuri pentru care sunt folosite intruziunile sunt:
obținerea accesului de la distan ță;
furtul de resurse;
sabotajul;
colectarea de date;
ocolirea sistemului de control al accesului;
eludarea detect ării.
123. Tehnologii IDPS
3.1 Componente și arhitectur ă
3.1.1 Componente tipice
Componentele tipice ale unei solu ții IDPS sunt:
Senzor sau agent . Senzorii și agenții monitorizeaz ă și analizeaz ă activitatea de
rețea.Termenul senzor este folosit de obicei pentru IDPS-urile care monitorizeaz ă
rețelele, incluzându-le pe cele la nivel de re țea, fără fir, și cele bazate pe tehnologii de
analiză a comportamentului de re țea. Termenul agent este de obicei folosit pentru
tehnologii IDPS la nivel de host.
Server de management. Un server de management este un dispozitiv care
centralizeaz ă și gestioneaz ă informațiile primite de la senzori sau agen ți. Unele servere
de management analizeaz ă informațiile furnizate de c ătre senzori sau agen ți, existând
astfel posibilitatea de a identifica evenimente pe care senzorii sau agen ții nu le pot
detecta. Potrivirea informa țiilor de la mai mul ți senzori sau agenti, pentru g ăsirea, de
exemplu, a evenimentelor declan șate de aceea și adresă IP, este cunoscut ă sub numele
de corelare. Serverele de management sunt disponibile atât ca instrumente hardware,
dar ca și produse software. Serverele de management sunt comune celor mai multe
implement ări IDPS, existând posibilitatea unor servere multiple, sau chiar dou ă nivele
de astfel de servere.
Server de baze de date . Un server de baze de date este un repozitoriu alc ătuit din
informații înregistrate de c ătre senzori, agen ți, și / sau servere de management.
Consolă. O consol ă este un program care ofer ă o interfață pentru utilizatorii și
administratorii IDPS-ului. Acest software este de obicei instalat pe desktop-uri sau
laptop-uri standard. Unele console sunt utilizate doar pentru administrare(configurare
de senzori sau agen ți și aplicarea unor actualiz ări de software), în timp ce alte console
sunt folosite strict pentru monitorizare și analiză. Unele console ofer ă atât
administrare, cât și monitorizare.
3.1.2 Arhitectura de re țea
Componentele pot fi conectate între ele prin intermediul re țelei standard a unei
organizații sau printr-o re țea separat ă, conceput ă strict, din motive de securitate, pentru
management, cunoscut ă sub numele de re țea de management. Dac ă se utilizeaz ă o astfel de
rețea, fiecare senzor sau agent are o interfa ță de rețea suplimentar ă, cunoscut ă sub numele de
interfață de management care se conecteaz ă la rețeaua mai sus men ționată. De asemenea, în
13cazul fiec ărui senzor sau agent nu exist ă nici un tip de flux de date între interfa ța de gestionare
și orice alt ă interfață de rețea a sa. Serverele de management, serverele de baze de date și
consolele sunt conectate numai la re țeaua de management. Aceast ă arhitectur ă izolează în
mod eficient toate componentele de re țeaua de produc ție. Beneficiile sunt date de ascunderea
existenței și identității IDPS-ului fa ță de atacatori, protejând astfel sistemul fa ță de un atac. În
acest fel se asigur ă că IDPS-ul are o l ățime de band ă adecvată pentru a func ționa în condi ții
nefavorabile (atacuri de tip DDoS asupra re țelelor monitorizate). Dezavantajele de a folosi o
rețea de management includ costurile suplimentare investite în echipamente de re țea și alte
componente hardware (de exemplu, PC-uri pentru console) și inconfortul dat de utilizarea
unor computere separate pentru management și monitorizare.
În cazul în care un IDPS este implementat f ără o rețea de management separat ă, un alt
mod de a îmbun ătăți securitatea este de a crea o re țea de gestionare virtual ă folosind o re țea
virtuală locală (VLAN) în cadrul re țelelor standard. Folosind un VLAN se confer ă o protecție
suplimentar ă pentru comunica țiile din cadrul IDPS-ului, dar nu comparabil ă cu protec ția
oferită de o rețea de gestiune separat ă. De exemplu, gre șelile de configurare a VLAN-ului ar
putea duce la expunerea unor date sensibile. O alt ă îngrijorare este dat ă de faptul c ă, în
condiții adverse, cum ar fi atacurile DDoS sau incidente majore de malware, dispozitivele de
rețea partajate de re țelele primare ale organiza ției și VLAN-urile ar putea deveni complet
saturate, impactând negativ asupra disponibilit ății și performan ței unui IDPS.
3.2 Capabilit ăți de securitate
3.2.1 Culegerea informa țiilor
Unele tehnologii IDPS ofer ă capacitatea de colectare de informa ții cu privire la host-
urile sau re țelele monitorizate. Exemplele includ identificarea gazdelor, a sistemelor de
operare și aplicațiilor pe care le folosesc, și identificarea caracteristicilor generale ale re țelei.
3.2.2 Capabilit ăți de logare
IDPS-urile efectueaz ă de obicei logarea datelor legate de evenimentele detectate.
Aceste date pot fi utilizate pentru a confirma validitatea alertelor, investigarea incidentelor, și
corelarea cu alte surse de logare. Câmpurile de date utilizate în mod obi șnuit de către IDPS-
uri includ data și ora evenimentului, tipul de eveniment, evaluare importan ței( prioritate,
severitate, impact, încredere) și acțiunile de prevenire întreprinse (dac ă este cazul). Anumite
tipuri de IDPS logheaz ă câmpuri de date suplimentare, cum ar fi capturi de trafic. Logurile
sunt stocate la nivel local și sunt trimise în acela și timp copii c ătre servere centralizate de
log.În general, logurile trebuie p ăstrate atât la nivel local, cât și central pentru a
susține integritatea și disponibilitatea datelor.De asemenea, sistemele ar trebui s ă aibă
ceasurile sincronizate folosind protocolul NTP (Network Time Protocol) sau prin ajust ări
manuale frecvente, astfel încât logurile s ă fie înregistrate cu o or ă și dată cât mai exact ă.
14uc Use Case Model
Log
Timestamp
Tipul alertei/
ev enimentului
Rating(
prioritate,
sev eritate
,impact)
Detalii (IP,port,
etc)
Actiunea
intreprinsa«include»
«include» «include»«include»«include»
Figura 3.1 – Câmpurile unui log
3.2.3 Detec ția
Tehnologii IDPS ofer ă de obicei, capabilit ăți extinse de detec ție. Cele mai multe produse
folosesc o combina ție de tehnici, ce sus țin, în general o detec ție mai precis ă și mai flexibilil ă
în realizarea configura ției. Tipurile de evenimente detectate și acuratețea detecției variază
foarte mult de la o tehnologie la alta. Cele mai multe IDPS-uri au nevoie de tuning și
personalizare pentru a îmbun ătăți acuratețea, gradul de utilizare, precum și eficiența.
Tehnologiile variaz ă foarte mult prin direc țiile de tuning și capabilit ățile de personalizare. De
obicei, cu cât tuning-ul și capabilit ățile de personalizare ale unui produs sunt mai viguroase,
cu atât mai mult acurate țea detecției poate fi îmbun ătățită față de cea a configura ției
implicite.Acest lucru trebuie tratat cu aten ție în evaluarea unor astfel de produse.Exemple de
astfel de capacit ăți sunt cele dup ă cum urmeaz ă:
Praguri . Un prag este o valoare ce stabile ște limita între un comportament normal și
anormal. Pragurile specific ă, de obicei, un nivel acceptabil maxim, cum ar fi N
încercări eșuate de conectare în 60 de secunde, sau Ncaractere pentru lungimea unui
nume de fi șier. Pragurile sunt cel mai adesea utilizate de detec ția bazată pe anomalii și
cea bazată pe analiza protocoalelor de tip stateful;
Liste negre/albe . O listă neagră este o list ă de entități discrete, cum ar fi gazde, adrese
IP, numere de port TCP sau UDP, coduri ICMP, aplica ții, nume de utilizatori, URL-
uri, nume de fi șiere sau extensii de fi șiere, care au fost asociate anterior cu activit ății
malițioase. Listele negre, cunoscut și sub numele de “liste fierbin ți”(hot lists), sunt de
obicei folosite pentru a permite IDPS-urilor s ă recunoasc ă și să blocheze activit ățile
dăunătoare, și pot fi de asemenea folosite pentru a atribui o prioritate mai mare
alertelor ce au o coresponden ță în listele negre. Unele IDPS-uri genereaz ă liste negre
dinamice, folosite pentru a bloca temporar amenin țările recent detectate. O list ă albă
este o list ă de entități discrete, care sunt cunoscute a fi benigne. Listele albe sunt de
obicei utilizate în mod granular, pentru a reduce sau ignora falsurile pozitive ce
15implică activități benigne. Listele albe și listele negre sunt cele mai frecvent utilizate
în detecția bazată pe semnături și analiza protocoalelor stateful;
Setarea alertelor . Se permite administratorilor personalizarea fiec ărui tip de alert ă.
Exemple de ac țiuni care pot fi efectuate pe un tip de alert ă includ urm ătoarele:
oOprirea sau pornirea3;
oSetarea unei anume priorit ăți sau nivel de severitate;
oSpecificarea informa țiilor ce ar trebui înregistrate și a metodelor de
notificare(ex: email);
oSpecificarea ac țiunilor de preventive ce ar trebui întreprinse.
Unele produse suprim ă alertele în cazul în care un atacator genereaz ă mai
multe alerte într-o perioad ă scurtă de timp, și poate, de asemenea, ignora temporar tot
traficul viitor de la atacator. Se realizeaz ă acest lucru pentru a preveni cople șirea cu
alerte a IDPS-ului;
Vizualizare și editare de cod . Unele tehnologii permit administratorilor s ă vadă unele
porțiuni sau tot codul ce realizeaz ă detecția. Acest lucru este de obicei limitat la
semnături, dar unele tehnologii permit administratorilor vizualizarea unor por țiuni
suplimentare, cum ar fi programele ce efectueaz ă analiza protocoalelor stateful.
Vizualizarea codului îi poate ajuta pe anali ști în a determina de ce au fost generate
anumite alerte, ajutând la validarea alertelor și identificarea falsurilor pozitive.
Abilitatea de a edita codul și scrie cod nou (ex: noi semn ături) este necesar ă pentru o
personalizarea complet ă în cazul anumitor tipuri de capacit ăți de detectare. De
exemplu, o anumit ă alertă ar putea fi generat ă de o serie complex ă de evenimente care
implică mai multe module de cod; configurarea unui IDPS s ă înțeleagă organizarea
specifică unor caracteristici nu ar putea fii posibil ă fără a edita codul. Editarea codului
necesită abilități de programare și de detec ție a intruziunilor; se folosesc de cele mai
multe ori limbaje de programare proprietare, ceea ce ar necesita înv ățarea unor noi
limbaje de c ătre programator. Bug-urile introduse în cod în timpul procesului de
personalizare ar putea provoca sistemul s ă funcționeze incorect sau deloc.A șadar,
administratorii ar trebui s ă trateze personalizarea codului ca pe orice alt ă modificare a
codului sistemelor de produc ție.
Administratorii ar trebui s ă revizuiasc ă setările de tuning și particularizare periodic pentru
a se asigura c ă acestea sunt înc ă exacte. De exemplu, listele albe și listele negre ar trebui
verificate în mod regulat, iar toate intr ările validate pentru a se asigura c ă acestea sunt în
continuare corecte și necesare. Pragurile și setările alertelor ar putea avea nevoie de ajust ări
periodice pentru a compensa schimb ările din re țea sau apari ția unor noi amenin țări.
Modificările aduse codului de detec ție ar putea avea nevoie s ă fie reprodus ori de câte ori
produsul este actualizat (ex: aplicarea de patch-uri).
3În unele tehnologii IDPS, oprirea alertelor duce la dezactivarea capabilit ăților de detec ție; alte produse, continu ă detecția, dar nu
vor genera mesaje de alert ă.
163.2.4 Preven ția
Cele mai multe IDPS-uri ofer ă posibilități multiple de prevenire; acestea variaz ă în funcție
de tipul acestora. Administratori pot specifica în configura ție capacitatea de prevenire pentru
fiecare tip de alert ă. Astfel, se poate activa/dezactiva preven ția sau se poate specifica ce tip de
capabilitate de preven ție să se utilizeze. Unii senzori au un mod de înv ățare sau simulare, care
suprimă toate acțiunile de prevenire indicând doar momentul când s-ar fi cuvenit o ac țiune de
acest tip. Acest lucru permite administratorilor s ă monitorizeze și să ajusteze configura ția
responsabil ă înainte de a activa ac țiunile de prevenire, ceea ce reduce riscul de blocare
accidental al activit ăților benigne.
3.3 Management
3.3.1 Implementare
După ce IDPS-ul a fost ales, administratorii trebuie s ă implementeze o arhitectur ă, să
testeze, pozi ționeze și să securizeze componentele.
3.3.1.1 Design-ul arhitecturii
Primul pas în implementarea unui astfel de sistem este design-ul arhitecturii.
Considera țiile arhitecturale includ:
Unde trebuie plasa ți senzorii/agen ții;
Cât de sigur ă ar trebui s ă fie soluția aleasă și ce măsuri ar trebui luate pentru a atinge
nivelul cel mai înalt, prin pozi ționare unor senzori multiplii ce monitorizeaz ă aceeași
activitate în cazul în care unul dintre ei cade sau folosirea unor servere de management
multiple, astfel încât un server de backup poate fi utilizat în cazul în care serverul
primar nu mai este disponibil;
Unde vor fi amplasate celelalte componente IDPS (servere de management, servere de
baze de date, console) și câte componente din fiecare clas ă sunt necesare pentru a
atinge gradul de utilizare optim și redundan ță;
Cu care alte sisteme IDPS-ul trebuie s ă interacționeze, inclusiv urm ătoarele:
oSisteme c ărora li se furnizeaz ă date, cum ar fi software-uri de management al
evenimentelor și al informa țiilor de securitate, servere de log centralizate,
servere de e-mail;
oSistemele ce ini țiază acțiuni de prevenire (firewall-uri, routere, switch-uri);
oSisteme care gestioneaz ă componentele IDPS, cum ar fi software-ul de
management de re țea (pentru o re țea de management) sau software-ul de
management al patch-urilor (pentru p ăstrarea sistemelor de operare al
consolelor și aplicațiilor actualizate).
Dacă va fi utilizat ă sau nu o re țea de management; dac ă da, ce design va avea, în caz
contrar, cum vor fi protejate comunica țiile IDPS în cadrul re țelelor standard;
17Ce alte controale și tehnologii de securitate trebuie modificate pentru buna func ționare
a sistemului, cum ar fi schimbarea regulilor firewall-urilor pentru a permite
componentelor s ă comunice.
3.3.1.2 Testarea și amplasarea componentelor
Organizațiile ar trebui s ă ia în considerare implementarea componentelor într-un
mediu de testare în primul rând, pentru a reduce riscul de probleme de implementare ce pot
perturba re țelele de produc ție. Atunci când componentele sunt utilizate în re țelele de
producție, organiza țiile trebuie s ă activeze ini țial doar câ țiva senzori sau agen ți, cu
capacitățile de prevenire dezactivate. Pentru c ă o implementare nou ă va genera, cel mai
probabil, un num ăr mare de alarme false pân ă când tuning-ul și personalizarea sunt complete,
activarea mai multor senzori sau agen ți deodată ar putea cople și serverele de management și
consolele, ceea ce face dificil tuning-ul. Multe falsuri pozitive pot fi de acela și tip în cadrul
senzorilor/agen ților, astfel, este util identificarea acestora, în timpul procesului de testare sau
atunci când sunt amplasa ți primii senzori sau agen ți, astfel încât aceste rezultate pot fi
redresate înainte de extinderea pe scar ă largă. O implementare treptat ă a senzorilor sau a
agenților este, de asemenea, de ajutor în identificarea poten țialelor probleme cu scalabilitate.
Implementarea poate necesita scurte întreruperi de re țea sau de sistem pentru instalarea
componentelor.
Componentele hard sunt de obicei u șor de instalat. Administratorii ar putea fi nevoi ți
să efectueze actualiz ări de software sau actualiz ări de semn ături. În general, trebuie conectate
la o sursă de curent și la rețea, pornite și apoi efectuate anumite configur ări de bază (ex:
introducerea unei chei de licen ță de produs, atribuirea unui nume senzorului).
Componentele software necesit ă, de obicei, mai mult timp pentru implementare.
Trebuie achizi ționat mai întâi hardware-ul adecvat, suficient de solid pentru a sus ține IDPS-
ul, care ar putea include pl ăci de rețea cu o lățime de band ă mare. Apoi, administratorii
trebuie să instaleze un sistem de operare compatibil pe care apoi s ă-l actualizeze, împreun ă cu
toate serviciile, aplica țiileși software-urile instalate.
După amplasarea componentelor IDPS un efort considerabil ar putea fi necesar pentru
a configura capabilit ățile de detec ție și prevenire, în func ție de tipul sistemului. F ără
parcurgerea acestui pas, sistemele ar putea fi limitate doar la detec ția unui num ăr mic de
atacuri vechi și ușor de identificat.
3.3.1.3 Securizarea componentelor
Asigurarea componente sistemului este foarte important ă, deoarece acestea sunt
adesea vizate de atacatori. În cazul în care un atacator poate compromite un IDPS, acesta va fi
inutil în detectarea atacurilor ulterioare împotriva altor host-uri. De asemenea, acestea con țin
informații sensibile, cum ar fi configura țiile host-urilor și vulnerabilit ăți cunoscute care ar
putea fi de ajutor în planificarea atacurilor suplimentare. Urm ătoarele specifica ții de securitate
sunt recomandate:
Administratorii trebuie s ă creeze conturi separate pentru fiecare utilizator și
administrator, precum și atribuirea numai a privilegiilor necesare;
Administratorii trebuie s ă configureze firewall-urile, routerele, precum și alte
dispozitive de filtrare a pachetelor pentru a limita accesul direct la toate componentele
IDPS numai pentru acele gazde care au nevoie de un astfel de acces;
Administratorii trebuie s ă se asigure c ătoate comunica țiile de management sunt
protejate în mod corespunz ător, fie fizic (re țeaua de management), fie logic(VLAN de
18management), sau prin criptarea informa țiilor. În cazul în care criptarea este utilizat ă,
ar trebui utiliza ți algoritmi de criptare recomanda ți de standardele international. Multe
produse folosesc pentru criptare protocolul TLS( Transport Layer Security); pentru
produsele care nu ofer ă suficientă protecție prin criptare, organiza țiile ar trebui s ă ia în
considerare utilizarea unei re țele private virtuale (VPN) sau alte metode de tunele
criptate pentru a proteja traficul.
3.3.2 Operare și mentenan ța
Aproape toate produsele de acest gen sunt proiectate pentru a fi exploatate și
întreținute printr-o interfa ță grafică(GUI), cunoscut ă sub numele de consol ă. Consola permite
administratorilor configurarea și actualizarea senzorilor și serverelor de management, precum
și monitorizarea st ării lor. Administratorii gestioneaz ă conturile de utilizator, personalizeaz ă
rapoarte și efectueaz ă multe alte func ții utilizând consola. Utilizatorii pot efectua multe func ții
prin consola, inclusiv monitorizarea și analizarea datelor, precum și generarea de rapoarte.
Cele mai multe IDPS-uri permit administratorilor crearea de conturi de utilizator individuale
pentru fiecare administrator și utilizator și acordarea fiec ărui cont numai privilegiile necesare
pentru rolul fiec ărei persoane. Consola reflect ă de multe ori acest lucru ar ătând diferite
meniuri și opțiuni bazate pe privilegiile contului autentificat.
Unele produse ofer ă o interfață în linie de comand ă( CLI). Spre deosebire de
interfețele grafice, care sunt de obicei utilizate pentru gestionarea de la distan ță a senzorilor/
agenților și serverelor de management, CLI-urile sunt de obicei utilizate pentru gestionarea
locală a acestor componente. Uneori, este permis ă realizarea unei conexiune criptate la
distanță de CLI, realizate prin SSH( Secure Shell) sau prin alte mijloace. Consolele sunt de
obicei mult mai u șor de utilizat decât CLI-urile, dar ofer ă adesea doar o parte din
funcționalitatea acestora.
3.3.2.1 Utilizarea tipic ă
Cele mai multe console IDPS ofer ă multe caracteristici ce ajut ă utilizatorii în sarcinile
lor zilnice. De exemplu, când un utilizator examineaz ă o alertă, mai multe detalii și informații
sunt disponibile pe nivele. Acest lucru permite utilizatorilor observarea informa țiilor de baz ă
pentru mai multe alerte o dat ă, dar este posibil ă și afișarea informa țiilor suplimentare despre
evenimente speciale de interes. Unele produse ofer ă utilizatorilor informa ții detaliate de
sprijin, cum ar fi capturi de pachete și alertele aferente (ex: alte alerte pentru aceea și sursă sau
destinație), precum și documenta ția alertei în sine. În general, cu cât exist ă mai multe date
înregistrate, cu atât este mai u șor pentru anali ști să determine ce s-a întâmplat.
Cele mai multe console ofer ă, de asemenea, diverse func ții de raportare. De exemplu,
administratorii sau utilizatorii pot utiliza consola pentru a genera anumite rapoarte la ore
stabilite și transferul acestora pe email sau pe alte c ăi către utilizatorii aviza ți. Rapoartele pot
fi personalizate dup ă cum este necesar(inclusiv generarea de rapoarte pentru incidente
specifice). În cazul în care sistemul stocheaz ă logurile într-o baz ă de date sau într-un format
de fișier ușor de interpretat (ex: valori separate prin virgul ă într-un fi șier text), interog ările
bazei de date sau script-urile pot fi folosite pentru a genera rapoarte personalizate, în special
în cazul în care consola nu ofer ă o personalizare suficient de flexibil ă.
193.3.2.2 Solu ții de mentenan ță
Administratorii ar trebui permanent s ă aplice urm ătoarele solu ții se mentenan ță:
Monitorizarea componentelor pentru prevenirea problemelor opera ționale și de
securitate ce le-ar putea include;
Verificarea periodic ă a funcționalități;
Realizarea de evalu ări periodice ale vulnerabilit ăților;
Primirea de notific ări ale unor eventuale probleme de securitate din parte
producătorilor componentelor IDPS(incluzând sistemele de operare, precum și
aplicațiile non-IDPS) și răpunsul corespunz ător la aceste notific ări;
Primirea de notific ări din partea produc ătorilor IDPS-ului legate de update-urile pe
care administratorii le pot testa și apoi aplica sistemului.
3.3.2.3 Achizi ția și aplicarea update-urilor
Există două tipuri de actualiz ări: actualizări de software și actualizări de semn ături.
Actualizările de software rezolv ă bug-urile în software sau adaug ă noi funcționalități, în timp
ce actualiz ările semnăturilor adaug ă capacități de detec ție noi sau rafineaz ă capabilitățile de
detecție existente (ex: reducerea falsurilor pozitive). Actualiz ările de semn ături cauzeaz ă
modificări sau înlocuiri în codul programului, fiind astfel o form ă specializat ă de actualizare a
software-ului. Pentru alte IDPS-uri, semn ăturile nu sunt scrise în cod, astfel încât un update de
semnături reprezint ă o modificare a datelor de configurare.
Actualizările de software pot include oricare sau toate componentele, inclusiv senzori,
agenți, servere de management și console. Actualiz ările de software pentru senzori și servere
de management, în special pentru dispozitivele de tip appliance, sunt adesea aplicate prin
înlocuirea unui CD existent, de pe care ruleaz ă software-ul, cu unul nou, urmat de repornirea
dispozitivului. Multe IDPS-uri ruleaz ă software-ul direct de pe CD, astfel încât nu este
necesară instalarea software-ului. Alte componente, cum ar fi agen ții, necesit ă intervenția
unui administrator pentru instalarea software-ului sau aplicarea patch-urilor, fie manual, pe
fiecare dispozitiv sau automat, prin intermediul software-ului de management din sistem. Unii
furnizori pun la dispozi ție pe site-urile proprii de web sau pe alte servere, actualiz ările de
software și semnăturile . Administratorii dispun deobicei de feature-uri ce downladeaz ă și
instalează asementea update-uri.
Este necesar ă o verificare a integrit ății actualiz ărilor înainte de aplicarea acestora,
pentru că acestea ar fi putut fi, accidental sau inten ționat, modificate sau înlocuite. Metoda de
verificare recomandat ă depinde de formatul actualiz ării, după cum urmeaz ă:
Fișierele desc ărcate de pe un site web sau server FTP . Administratorii ar trebui s ă
compare sumele de control ale fi șierelor, furnizate de c ătre produc ător, cu sumele de
control pe care le calculeaz ă local, dup ă descărcare;
Actualizare desc ărcate automat printr-o interfa ța IDPS . Dacă o actualizare este
descărcată ca un singur fi șier sau un set de fi șiere, sumele de control furnizate de
vendor ar trebui comparate cu sumele de control generate de administrator ori interfa ța
în sine ar trebui s ă efectueze un fel de verificare a integrit ății. În unele cazuri,
actualizările ar putea fi desc ărcate și instalate într-o singura ac țiune, împiedicând
20verificarea sumei de control; interfa ța ar trebuie s ă verifice integritatea fiec ărei
actualizări ca parte integrant ă a acestei ac țiuni de instalare;
Medii de stocare deta șabile (ex: CD-uri, DVD-uri). Furnizorul nu poate prevede o
metodă specifică pentru clien ți pentru a verifica legitimitatea acestor medii, aparent
trimise de c ătre aceștia. Dacă verificarea reprezint ă o preocupare, administratorii ar
trebui să contacteze furnizorii pentru a determina modul în care acestea pot fi
verificate, cum ar fi compararea sumelor de control furnizate de vendori cu sumele de
control calculate local pentru fi șierele de pe mediul de stocare sau verificarea
semnăturilor digitale pentru con ținut pentru validare. Administratorii ar trebuie s ă ia
în considerare și scanare contra malware-uri, cu avertismentul c ă falsurile pozitive ar
putea fi declan șate de către semnăturile IDPS-ului.
IDPS-urile sunt de obicei proiectate astfel încât aplicarea actualiz ărilor de software și
semnături nu va avea nici un efect asupra tuning-ului și setărilor. Excep ție face personalizarea
codului, care de cele mai multe ori trebui ref ăcută atunci când sunt instalate actualiz ări de cod
de la furnizor. Pentru orice sistem, administratorii ar trebui s ă realizeze un backup periodic și
înainte de a aplica actualiz ările pentru a se asigura c ă setările existente nu sunt pierdute
accidental.
Este recomandat ă testarea actualiz ărilor înainte de aplicarea acestora, cu excep ția
situațiilor de urgen ță ( ex: o semn ătură identifică o nouă amenințare activă care dăunează
organizației și nu poate fi altfel detectat ă sau blocat ă). Este benefic ă existența cel puțin a unui
senzor/agent(pentru fiecare tip) sau host, care s ă fie utilizat strict pentru testarea actualiz ărilor.
Capabilitățile noi de detectare pot provoca de multe ori un num ăr mare de alerte, astfel încât
testarea actualiz ări de semnaturi pe un singur senzor/agent, chiar și pentru scurt timp,
(încărcarea actualiz ării și observarea modului în care func ționează sistemul când sunt
monitorizate activit ățile tipice), poate ajuta la identificarea semn ăturilor care sunt susceptibile
a fi problematice și ar trebui s ă fie într-un final dezactivate. În situa ții non-urgente,
actualizările ar trebui s ă fie testate și implementate folosind acelea și practici care sunt folosite
pentru actualizarea altor dispozitive sau software-uri de securitate, cum ar fi firewall-urile și
software-urile antivirus. Când actualiz ările sunt implementate în produc ție, administratorii ar
trebui să fie pregătiți pentru a dezactiva anumite semn ături sau a efectua alte reconfigur ări
minore, dup ă cum este necesar.
3.3.3 Competen țe de construire și mentenan ță
Diferite competen țe sunt necesare pentru implementarea, operarea și mentenan ța
IDPS-urilor, incluzându-le pe cele ce urmeaz ă:
Administratorii ce implementeaz ă componentele trebuie s ă înțeleagă elementele de
bază ale administr ării sistemului , re țelei și ale securit ății informa ției;
Cei responsabili de tuning și personalizare este necesar s ă aibă cunoștințe destul de
cuprinzătoare legate de securitatea informa ției și principiile unui sistem de preven ție și
detecție a intruziunilor într-o retea împreun ă cu întelegerea protocoalelor de re țea, a
aplicațiilor și a sistemelor de operare ce urmeaz ă a fi monitorizate.De asemenea, este
21recomandat ă o înțelegere a principiilor de r ăspuns la incidente, precum și a politicilor
și procedurilor de r ăspuns la incidente ale organiza ției;
Cunoștinte de programare ar putea fi, de asemenea, necesare pentru personaliz ări
extinse de cod, scrierea de rapoarte și alte sarcini.
Competen țele pot fi dezvoltate prin mai multe metode, ce includ training-uri, conferin țe
tehnice, c ărți și alte referin țe tehnice, precum și programe de mentorat. Cunoa șterea
produselor specifice ale unui IDPS poate fi realizat ă prin mai multe metode:
Training realizat de vendor . Mulți producători de produse IDPS ofer ă una sau mai
multe cursuri de formare pentru persoanele care vor administra sau folosi produsele
proprii. Cursurile de formare sunt adesea de tip hands-on, permi țând participan ților să
învețe cum să foloseasc ă tehnologia într-un mediu non-produc ție;
Documenta ția produsului. Cele mai multe produse ofer ă mai multe manuale, cum ar
fi un ghid de instalare, un ghid al utilizatorului și ghid pentru administrator. Unele
oferă, de asemenea, ghiduri sau baze de date separate, care ofer ă informații
suplimentare pentru alerte și semnături;
Suport Tehnic . Cei mai mul ți producători oferă suport tehnic pentru clien ții lor, fie ca
parte a achizi ționării unui produs sau pentru o tax ă suplimentar ă. Suportul este utilizat
în principal pentru rezolvarea problemelelor și clarificarea capabilit ăților produselor
pentru utilizatorii s ăi și administratori;
Servicii profesionale . Unii furnizori ofer ă servicii profesionale, ce sunt în esen ță
servicii de consultan ță prestate de c ătre vânzător. De exemplu, o organiza ție ar putea
plăti un furnizor pentru a scrie semn ături particularizate sau rapoarte sau pentru a ajuta
administratorii în întelegerea modului de a regla și personaliza senzorii în mod
eficient;
Comunit ăți de utilizatori . Unele produse au comunit ăți de utilizatori activi, care de
obicei func ționează prin liste de mailing sau forumuri online. Utilizatorii pot face
schimb de informa ții și cod unul cu altul, ajutându-se reciproc în probleme de
depanare. De și comunit ățile de utilizatori pot fi o surs ă de informare, cei care folosesc
aceste mijloace trebuie s ă fie precau ți când le utilizeaz ă, deoarece postarea unor detalii
legate de configurarea și problemele unui IDPS apar ținând unei organiza ții, ar putea
neintenționat să dezvăluie informa ții sensibile legate de infrastructura de securitate,
sistemul și rețelele unei organiza ții.
224. IDPS-uri la nivel re țea
4.1 Stiva TCP/ IP
ARPANET, str ămoșul tuturor re țelelor de calculatoare, a fost o re țea de cercetare
sponsorizat ă de către DoD (U.S. Department of Defense). În cele din urm ă, rețeaua a
ajuns să conecteze între ele, utilizând linii telefonice închiriate, sute de re țele universitare și
guvernamentale. Dup ă introducerea ulterioar ă a rețelelor prin satelit și radio, interconectarea
acestora cu protocoalele existente a pus diferite probleme. Era nevoie de o nou ă arhitectur ă de
referință.Astfel, posibilitatea de a interconecta f ără probleme mai multe tipuri de re țele a
reprezentat de la bun început un obiectiv de proiectare major. Aceast ă arhitectur ă a devenit
cunoscută mai târziu sub numele de modelul de referin ță TCP/IP, dat ă după numele celor
două protocoale fundamentale utilizate.
Astfel, TCP (Tranmission Control Protocol) are rolul de împărțire a datelor în
pachete și asigură transmiterea corect ă a mesajelor între host-uri. Pachetele sunt numerotate,
putându-se verifica primirea lor în forma în care au fost transmise și reconstituirea mesajelor
lungi, formate din mai multe pachete.
IP(Internet Protocol) asigur ă livrarea pachetelor numai dac ă în funcționarea re țelelor
nu apar erori. Dac ă un mesaj este prea lung, IP cere fragmentarea lui în mai multe pachete.
Transmiterea pachetelor IP se face între calculatoare gazd ă și nu direct între programele de
aplicație.
Spre deosebire de modelul de referin ță OSI, modelul TCP/IP este format din 4
niveluri:
Figura 4.1 – Stiva TCP /IP
23Deși două dintre niveluri au acela și nume ca la modelul OSI, nu trebuie confundate
între ele pentru c ă fiecare nivel are func ții total diferite pentru fiecare model în parte.
Figura 4.2 – Nivelele celor dou ă modele arhitecturale de re țea
Nivelul aplica ție
Modelul TCP/IP nu con ține nivelurile sesiune sau prezentare.Experien ța modelului
OSI a dovedit c ă această viziune a fost corect ă: în majoritatea aplica țiilor, nivelurile
respective nu sunt de mare folos. Aceasta con ține
toate protocoalele de nivel mai înalt. A șa cum se
vede în figura 4.3, primele protocoale de acest gen
includeau terminalul virtual (TELNET), transferul
de fișiere (FTP) și poșta electronic ă (SMTP).
Protocolul de terminal virtual permite unui
utilizator de pe o ma șină să se conecteze și să
lucreze pe o ma șină aflată la distanță. Protocolul de
transfer de fi șiere pune la dispozi ție o modalitate
de a muta eficient date de pe o ma șină pe alta.
Poșta electronic ă a fost la origine doar un tip de
transfer de fi șiere, dar ulterior a fost dezvoltat un
protocol specializat
(SMTP – Simple Mail Transfer Protocol)
pentru acest serviciu. Pe parcursul anilor, la
aceste protocoale s-au ad ăugat multe altele, a șa cum sunt Serviciul Numelor de Domenii
(Domain Name Service – DNS) pentru stabilirea coresponden ței dintre numele gazdelor și
adresele re țelelor, HTTP, folosit pentru aducerea paginilor de pe Web și multe altele.
TCP/IP
Figura 4.3 – Protocoale Aplica ție
24Nivelul Transport
Nivelul transport este proiectat astfel încât s ă permită conversa ții între entit ățile
pereche din host-urile surs ă și, respectiv, destina ție, la fel ca în nivelul transport OSI. În acest
sens au fost definite dou ă protocoale end-to end.
Primul din ele, TCP (Transmission Control
Protocol ), este un protocol sigur orientat pe
conexiuni care permite ca un flux de octe ți
trimiși de pe un host s ă ajungă fără erori pe orice
alt host din inter-re țea. Orientarea pe conexiune nu
semnifică faptul că există un circuit între
computerele care comunic ă, ci faptul c ă
segmentele nivelului Aplica ție călătoresc
bidirecțional între dou ă gazde care sunt conectate
logic pentru o anumit ă perioadă. Acest proces este
cunoscut sub denumirea de packet switching.
Acest protocol fragmenteaz ă fluxul de octe ți în
mesaje discrete și pasează fiecare mesaj nivelului internet. La destina ție, procesul TCP
receptor reasambleaz ă mesajele primite într-un flux de ie șire. TCP trateaz ă totodată controlul
fluxului pentru a se asigura c ă un emițător rapid nu inund ă un receptor lent cu mai multe
mesaje decât poate acesta s ă prelucreze.
Al doilea protocol din acest nivel, UDP (User Datagram Protocol) , este un protocol
nesigur, f ără conexiuni, destinat aplica țiilor care doresc s ă utilizeze propria lor secven țiere
și control al fluxului, și nu pe cele asigurate de TCP.
Protocolul UDP este de asemenea mult folosit pentru interog ări rapide întrebare-
răspuns, client-server și pentru aplica ții în care comunicarea prompt ă este mai important ă
decât comunicarea cu acurate țe, așa cum sunt aplica țiile de transmisie a vorbirii și a
imaginilor video. Rela ția dintre IP, TCP și UDP este prezentat ă în figura 4.5. De când a fost
dezvoltat acest model, IP a fost implementat pe multe alte re țele.
Figura 4.5 – Rela țiile între protocoale
Nivelul internet
Îngrijorarea principal ă a Departamentului de Ap ărare American dupa proeictarea
ARPANET era c ă o parte din pre țioasele sale gazde, rutere și dispozitive de interconectare ar
TCP/IP
Figura 4.4 – Protocoale Transport
25putea ceda dintr-un moment în altul. Astfel, un obiectiv major a fost ca re țeaua să poată
supraviețui pierderii echipamentelor din subre țea fără a fi întrerupte conversa țiile existente.
Cu alte cuvinte, DoD dorea ca, atâta timp cât func ționau hostul surs ă și hostul destina ție,
conexiunile s ă rămână intacte, chiar dac ă o parte din dispozitivele sau din liniile de transmisie
erau brusc scoase din func țiune. Mai mult, era nevoie de o arhitectur ă flexibilă, deoarece se
aveau în vedere aplica ții cu cerin țe divergente, mergând de la transferul de fi șiere până la
transmiterea vorbirii în timp real.Toate aceste cerin țe au condus la alegerea unei re țele cu
comutare de pachete bazat ă pe un nivel
inter-rețea fără conexiuni.
Nivelul internet , este axul pe care
se centreaz ă întreaga arhitectur ă. Rolul său
este de a permite gazdelor s ă emită pachete
în orice re țea și a face ca pachetele s ă
circule independent pân ă la destina ție (chiar
dacă aceasta face parte din alt ă
rețea).Pachetele pot chiar s ă sosească într-o
ordine diferit ă față de cea în care au fost
trimise, caz în care rearanjarea cade în
sarcina nivelurilor superioare. De observat
că ,,internet” este folosit aici într-un sens
generic, chiar daca acest nivel este prezent
și în Internet.Aici analogia este cu sistemul
de poștă (clasică). O persoan ă dintr-o anumit ă țară poate depune
într-o cutie po ștală mai multe scrisori interna ționale și, cu puțin noroc, majoritatea scrisorilor
vor ajunge la adresa corect ă din țara de destina ție. Probabil c ă scrisorile vor trece pe drum
prin mai multe oficii de cartare, dar acest lucru se face transparent pentru utilizatori. Mai
mult, faptul c ă fiecare țară (adică fiecare re țea) are propriile timbre, propriile m ărimi favorite
de plicuri și propriile reguli de livrare este ascuns beneficiarilor.Nivelul internet define ște
oficial un format de pachet și un protocol numit IP (Internet Protocol) . Sarcina nivelului
internet este s ă livreze pachete IP c ătre destina ție. Problemele majore se refer ă la dirijarea
pachetelor și evitarea congestiei. În consecin ță, este rezonabil s ă spunem c ă nivelul internet
din TCP/IP func ționează asemănător cu nivelul re țea din OSI. Figura 4.5 arat ă această
coresponden ță.
Nivelul Acces la re țea
Pe acest nivel sunt definite standardele și
tehnologiile Ethernet IEEE 802.3, precum CSMA/CD și
10BASE-T.
Acest nivel se ocup ă cu toate serviciile pe care le
necesită un pachet IP pentru a realiza o legatur ă fizică,
incluzând și detalii legate de tehnologiile LAN și WAN,
de medii de transmisie, adic ă ceea ce fac nivelurile OSI
legătură de date și fizic.
TCP/IP
TCP/IPFigura 4.6 – Protocoale IP
Figura 4.7 – Nivelul Acces la Re țea
26
Figura 4.8 – Protocoale TCP/IP
4.2 Componente și arhitectur ă
4.2.1 Componente tipice
Un exemplu tipic de IDPS la nivel de re țea este compus din senzori, unul sau mai
multe servere de management, multiple console, și, opțional, unul sau mai multe servere de
baze de date (dac ă esete acceptat ă utilizarea lor). Toate aceste componente sunt similare cu
alte tipuri de tehnologii IDPS, cu excep ția senzorilor. Un senzor specific acestui tip de sistem
monitorizeaz ă și analizeaz ă activitatea de re țea pe unul sau mai multe segmente de re țea.
Cardurile de re țea, ce vor realiza monitorizarea vor fi în modul promiscuu , ceea ce înseamn ă
că vor accepta toate pachetele de intrare pe care le v ăd, indiferent de destina țiile lor.
Majoritatea implement ărilor folosesc mul ți senzori, ajungându-se la implementari mari cu
sute de senzori. Senzorii sunt disponibile în dou ă formate :
De tip appliance .Acest tip este compus din hardware specializat și software de tip
senzor. Hardware-ul este de obicei optimizat pentru utilizarea senzorului, incluzând
interfețe de rețea specializate și driver de captare eficient ă a pachetelor, procesoare
specializate sau alte componente hardware care ajut ă la analiză. Este utilizat de cele
mai multe ori un sistem de operare personalizat ce nu este destinat a fi accesat direct
de către administrator;
FTP
HTTP
SMTP
DNS
DNS
TFTP
TCP
UDP
IP
INTERNET
LAN
Alte LAN și
WAN
27
De tip software . Unii vendorii vând senzori compu și doar din produse software.
Administratorii îi pot instala doar pe host-uri ce îndeplinesc anumite cerin țe. Senzorul
software poate include un sistem de operare specific, sau poate fi instalat într-unul
standard ca orice alt ă aplicație.
4.2.2 Arhitectura de re țea și locațiile senzorilor
Organizațiile ar trebui s ă ia în considerare utilizarea re țelelor de management pentru
implementarea IDPS-urilor la nivel re țea dacă este posibil. În cazul în care un IDPS este
implementat f ără o rețea de management separat ă, organiza țiile trebuie s ă decidă dacă este
nevoie sau nu de un VLAN pentru a proteja comunica țiile interne.
În plus fa ță de alegerea re țelei pentru componente, administratorii trebuie s ă decidă
unde să fie amplasa ți senzori.Ace știa pot fi utiliza ți într-unul din cele dou ă moduri:
Inline . Un senzor inline este implementat astfel încât traficul de re țea ce este
monitorizat trebuie s ă treacă prin el, la fel ca fluxul de trafic asociat cu un firewall. De
fapt, unii astfel de senzori sunt ni ște dispozitive hibride de tip firewall / IDPS.
Figura 4.9 – Exemplu implementare senzori inline
Motivația principal ă pentru implementarea senzorilor inline este de a le permite
28să oprească atacurile prin blocarea traficului în re țea. Senzori inline sunt de obicei
plasați în locuri în care ar fi plasa ți firewall-uri sau alte dispozitive de securitate (la
granița dintre re țelele interne, ce trebuie separate, și cele externe). Senzori ce nu sunt
hibrizi sunt de multe ori amplasa ți pe partea mai sigur ă a unei diviziuni de re țea pentru
a avea mai pu țin trafic de procesat și pentru a reduce înc ărcătura unui firewall.Figura
4.9 prezint ă o astfel de implementare.
Pasiv . Un senzor pasiv monitorizeaz ă o copie a traficului real de re țea. Senzori pasivi
sunt de obicei implementa ți astfel încât s ă poată monitoriza loca țiile cheie ale unei
rețele (diviziunile dintre re țelele) și segmente de re țea cheie(activitatea într-o zon ă
demilitarizat ă – DMZ). Senzori pasivi pot monitoriza traficul, prin diverse metode,
după cum urmeaz ă:
oPort de tip spanning . Multe switch-uri au un port de tip spanning; reprezint ă
un port care poate vedea tot traficul de re țea ce trece prin switch. Conectarea
unui senzor la un astfel de port poate permite monitorizarea traficului din re țea.
Deși această metodă de monitorizare este relativ u șor și ieftin de implementat,
ea poate fi problematic ă. În cazul în care un switch este configurat sau
reconfigurat incorect, portul de tip spanning ar putea s ă nu vadă tot traficul. O
altă problemă cu aceste porturi este c ă utilizarea lor duce la un consum mare de
resurse; atunci când un switch are de prelucrat un flux foarte mare de trafic,
este posibil ca portul s ă nu vadă tot traficul, existând posibilitatea chiar s ă fie
închis. De asemenea, multe switch-uri dispun doar de un singur port de acest
tip, iar în cele mai multe cazuri trebuie conectate multe dispozitive de genul
uneeltelor de monitorizare, analiz ă și diagnosticare a traficului sau alte tipuri
de senzori IDPS ce trebuie s ă analizeze acela și traffic.
oNetwork Tap . Reprezint ă o conexiune direct ă între un senzor și rețeaua fizic ă
de trafic.Este oferit astfel senzorului o copie a tot traficului de re țea transportat
de dispozitivele fizice.Instalarea, în general, implic ă o perioad ă de
nefuncționare a re țelei, iar eventuale probleme cu aceast ă metodă ar putea
cauza perioade de nefunc ționare suplimentare. De asemenea, spre deosebire de
porturile de tip spanning, ce sunt de obicei, deja prezente într-o organizatie,
aceste interceptoare trebuie s ă fie achizi ționate și incluse ca add-ons la re țea.
oIDS4de tip Load Balancer . Reprezint ă un dispozitiv care agregheaz ă și
direcționează traficul de re țea către sisteme de monitorizare, inclusiv c ătre
senzori IDPS. Poate primi copii ale traficului de re țea de la unul sau mai multe
porturi de tip spanning sau interceptoare de re țea, agregând traficul din diferite
rețele (ex: reasambleaz ă o sesiune care a fost împ ărțită între dou ă rețele). Copii
ale traficului sunt trimise apoi c ătre unul sau mai multe dispozitive de
ascultare, pe baza unui set de reguli stabilite de c ătre un administrator. Regulile
precizeaz ă ce tip de trafic direc ționează către fiecare dispozitiv de ascultare.
Configura țiile comune includ urm ătoarele:
4Intrusion Detection System
29Trimiterea întregului trafic mai multor senzori . Acest lucru ar
putea fi făcut pentru disponibilitate ridicat ă sau pentru a avea mai
multe tipuri de senzori ce efectueaz ă o analiză concomitent ă ale
aceleași activități.
Împărțirea dinamic ă a traficului între mai mul ți senzori în
funcție de volum . Acest lucru se face se realizeaz ă pentru a efectua
o echilibrarea a sarcinilor, astfel încât nici un senzor s ă nu fie
supraîncărcat.
Împărțirea traficului între mai mul ți senzori în func ție de
adrese IP, protocoale sau alte caracteristici . Acest lucru ar putea
fi făcută pentru echilibrarea a sarcinii, având de exemplu un senzor
dedicat activit ătii web și un alt senzor ce monitorizeaz ă toate
celelalte activit ăți. Divizarea traficului ar putea fi f ăcută pentru a
efectua o analiz ă mai detaliat ă a anumitor tipuri de trafic (ex:
activități ce implic ă cele mai importante hosturi).
30Divizarea traficului între mai mul ți senzori poate determina o reducere a
preciziei de detec ție în cazul în care evenimentele legate sau por țiuni ale unui singur
eveniment sunt v ăzute de senzori diferi ți. De exemplu, s ă presupunem c ă doi senzori
observă etape diferite ale unui atac; în cazul în care fiecare pas este considerat benign
luat izolat, dar lua ți împreun ă, în ordine sunt r ău intenționate, atunci atacul s-ar putea
să nu fie recunoscut.
Pentru a putea folosi un senzor în preven ția intruziunilor acesta trebuie utilizat în mod
inline, nu pasiv. Pentru c ă tehnicile pasive monitorizeaz ă doar o copie a traficului, ele nu
oferă nici o metod ă de încredere prin care s ă oprească traficul îna a ajunge la destina ție. În
unele cazuri, un senzor pasiv poate plasa pachete într-o re țea în încercarea de a perturb ă o
conexiune, dar astfel de metode sunt, în general, mai pu țin eficiente decât metodele inline.
4.3 Capabilit ăți de securitate
4.3.1 Culegerea informa țiilor
Unele IDPS-uri la nivel re țea oferă capabilități limitate de culegere a informa țiilor(
colectarea de informa ții despre host-uri și activitatea de re țea ce implic ă acele host-
uri).Exemple de capabilit ăți de culegere a informa țiilor sunt urm ătoarele:
Identificarea host-urilor . Un senzor IDPS ar putea fi capabil s ă creeze o list ă cu host-
urile din re țeaua organiza ției grupate prin adresa IP sau adresa MAC. Lista poate fi
folosită ca un profil pentru a identifica host-urile noi din re țea.
Identificarea sistemelor de operare . Un sensor este capabil s ă identifice sistemele de
operare și versiunile acestora utilizate de c ătre computerele organiza ției prin diverse
tehnici. De exemplu, senzorul poate urm ări ce porturi sunt utilizate pe fiecare host,
fapt ce ar putea indica un anumit sistem de operare sau o familie (ex: Windows, Unix).
O altă tehnică este de a analiza header-ul pachetului pentru anumite caracteristici
neobișnuite sau combina ții de caracteristici care sunt setate de anumite sisteme de
operare; acest lucru este cunoscut sub numele de amprentare pasiv ă. Unii senzori pot
identifica, de asemenea, versiuni ale aplica țiilor, care în unele cazuri indic ă ce sistem
de operare este în uz. Știind ce versiuni de sisteme de operare sunt în uz poate fi de
ajutor în identificarea host-urilor poten țial vulnerabile.
Identificarea Aplica țiilor. Pentru unele aplica ții, un senzor poate identifica versiunile
utilizate ținând eviden ța porturilor folosite și monitorizând unele caracteristici de
comunicare ale aplica ției. De exemplu, atunci când un client stabile ște o conexiune cu
un server, serverul ar putea spune clientului ce versiune a software-ului ruleaz ă și
invers. Informa ții privind versiunile aplia țiilor pot fi utilizate în identificarea
aplicațiilor poten țial vulnerabile și a utilizării neautorizate a unor aplica ții.Figura 4.10 – Exemplu de implementare senzori pasivi
31Identificarea caracteristicilor re țelei. Unii senzori IDPS pot colecta informa ții
generale despre traficul de re țea legat de configurarea dispozitivelor și host-urilor din
rețea, cum ar fi num ărul de hop-uri între dou ă dispozitive. Aceast ă informație poate fi
folosită pentru a detecta modific ările ce pot ap ărea în configura ția rețelei.
4.3.2 Capabilit ăți de logare
IDPS-urile de nivel re țea efectueaz ă de obicei un logging extins legat de evenimentele
detectate. Aceste date pot fi utilizate pentru a confirma validitatea alertelor, pentru a investiga
incidentele și a corela evenimente cu alte surse de logare. Câmpurile de date înregistrate
includ urm ătoarele:
Timestamp (de obicei, data și ora);
ID-ul conexiunii sau al sesiunii (de obicei un num ăr consecutiv sau unic atribuit
fiecărei conexiuni TCP sau unor grupuri de pachete corespunz ătoare protocoalelor f ără
conexiune);
Tipul evenimentului sau alertei5;
Evaluare (prioritate, severitate, impactul, nivelul de încredere);
Nivelul corespunz ător protocolului:re țea, transport, sau aplica ție;
Adresele IP surs ă și destinație;
Porturile TCP/UDP surs ă și destinație sau tipuri de ICMP și codurile aferente;
Numărul de octe ți transmiși;
Datele decodate din înc ărcătura utilă( payload), cum ar fi cereri de aplica ții și
răspunsuri;
Informațiile de stare (ex: numele de utilizator autentificat);
Acțiunea de preven ție întreprins ă( dacă este cazul).
4.3.3 Detec ția
În cadrul acestui tip de IDPS sunt oferite capabilit ăți extinse și largi de detec ție. Cele
mai multe produse folosesc o combina ție între detectare bazat ă pe semnături, cea bazat ă pe
detecția anomaliilor și tehnicile analizei protocoalelor de tip stateful pentru a efectua o analiz ă
în profunzime a protocoalelor comune; organiza țiile ar trebui s ă utilizeze sistemele care
utilizează o astfel de combina ție de tehnici. Metodele de detectie sunt strâns legate; un motor
de analiză a protocoalelor de tip stateful ar putea împ ărți activitatea analizat ă în solicitări și
răspunsuri, fiecare parte fiind examinat ă pentru anomalii și comparat ă cu semnăturile
activităților cunoscut ă a fi rău intenționate. Unele produse folosesc acelea și tehnici și oferă
5În consolă, tipul evenimentul sau alertei face de cele mai multe ori leg ătura către informa ții de suport
despre vulnerabilit ăți / exploat ări anume, cum ar fi referin țe către informa ții suplimentare și numere CVE (
Common Vulnerabilities and Exposures)
32aceeași funcționalitate ca și software-urile bazate pe analiza comportamentului de re țea
(NBA).
4.3.3.1 Tipurile de evenimente detectate
Tipurile de evenimente cel mai frecvent detectate de senzori sunt:
Atacurile la nivelul aplica ție al stivei TCP.(ex: banner grabbing, buffer overflow,
format string attacks, password guessing , transmisie de malware). Sunt analizate
majoritatea protocoalelor speficice nivelului aplica ție. Includem aici: DHCP (Dynamic
Host Configuration Protocol), DNS (Domain Name Server) , Finger, FTP (File
Transfer Protocol), IMAP( Internet Message Access Protocol ), IRC( Internet Relay
Chat ), NFS( Network File System), POP( Post Office Protocol ), HTTP6, RPC(
Remote Call Procedura), SIP( Session Initiation Protocol), SMB( Server Message
Bloc), SMTP( Simple Mail Transfer Protocol), SNMP( Simple Network Management
Protocol), Telnet și TFTP( Trivial File Transfer Protocol ), precum și protocoalele
specific bazelor de date, aplica ții de mesagerie instant și software-uri peer-to-peer de
partajare de fi șiere;
Atacurile la nivel transport (scanarea porturilor, fragmentare neob șinuită a
pachetelor, inunda ții(floods) cu SYN). Protocoalele cel mai des analizate sunt TCP și
UDP;
Atacurile la nivel internet/re țea(adrese IP false, valorile ilegale în header-ul IP).
Protocoalele cel mai des analizate sunt IPv4, ICMP, și IGMP. Multe produse ofer ă
support și pentru analiza IPv6.Nivelul de analiz ă IPv6 difer ă de la un produs la
altul.Unele nu ofer ă nici un suport IPv6 sau doar alerteaz ă administratorii de prezen ța
activității IPv6. Altele pot face o procesare de baz ă a activității IPv6 și a traficului
IPv6 tunelat, cum ar fi înregistrare adreseleor IP surs ă și destinație, precum și
extragerea înc ărcăturii utile (ex: HTTP, SMTP) pentru o analiz ă în profunzime. Unele
produse pot face o analiz ă completă a protocolului IPv6, cum ar fi confirmarea
validității opțiunilor IPv6, pentru identificarea utilizar ării anormale a protocolului;
Servicii/aplica ții neprevăzute ( ex: protocoale de tunelare, backdoors, host-uri ce
rulează aplicații/servicii neautorizate). Acestea sunt, de obicei, detectate prin analiza
protocoalelor de tip stateful, care poate determina dac ă activitatea dintr-o conexiune
este în concordan ță cu protocolul utilizat, sau prin metode de detectare a anomaliilor
ce pot identifica modific ări ale fluxurilor de re țea și porturile deschise;
Încălcarea politicilor de securitate (ex: utilizarea de site-uri web nepotrivite,
utilizarea aplica țiilor interzise). Unele tipuri de înc ălcări ale politicii de securitate pot
fi detectate prin IDPS-uri, permi țând administratorilor s ă precizeze caracteristicile
6Dei aceste IPDS-uri pot analiza activitatea protocolului HTTP, nu pot efectua analize cu privire la
utilizarea serviciilor de web, cum ar fi mesajele de tip SOAP( Simple Object Access Protocol) i XML(
Extensible Markup Language) transportate de HTTP. Tehnologii de securitate cunoscute ca gateway-uri XML
sau firewall-uri XML au fost create special pentru a analiza activitatea serviciilor web. În plus fa ă de
furnizarea de func ii de prevenire a intruziunilor, aceste tehnologii efectueaz ă filtrarea, autentificarea i
autorizarea serviciilor, controlul accesului i logare.
33activităților care nu ar trebui permise, cum ar fi numere de porturi TCP/ UDP, adrese
IP, nume de site-uri web, precum și alte date ce pot fi identificate prin examinarea
traficului de re țea.
Există posibilitatea monitoriz ării negocierii ini țiale efectuat ă la stabilirea comunica țiilor
criptate pentru a identifica software-ul client sau dac ă serverul are vulnerabilitati cunoscute
sau nu este configurat corect. Acest lucru poate include protocoale de nivel aplica ție, cum ar fi
SSH (Secure Shell) și SSL( Secure Sockets Layer), și protocoalele de nivel re țea/ internet
folosite în re țelele virtuale(ex: IPsec – IP Security).
Senzori pot determina de multe ori dac ă un atac are șanse de reu șită. De exemplu, a șa cum
este descris în sec țiunea 4.3.3.3, senzorii ar putea ști ce versiune de software de tip web server
se execută pe fiecare dintre servere web ale organiza ției. În cazul în care un atacator lanseaz ă
un atac împotriva unui server de web, ce nu este vulnerabil la acest tip de atac, atunci senzorul
ar putea produce o alert ă cu o prioritate redus ă; în cazul în care serverul este considerat a fi
vulnerabil, atunci senzorul ar putea produce o alert ă de înaltă prioritate. Senzorii sunt de
obicei configura ți să oprească toate atacurile indiferent dac ă sunt sau nu susceptibile în a
reuși, dar sistemul ar putea loga evenimentele cu nivele de prioritate diferite, în func ție de
rezultatul lor, în cazul în care ar fi fost blocate.
4.3.3.2 Acurate țea detecției
Din punct de vedere istoric, IDPS-urile la nivel re țea au fost asociate cu rate ridicate al
rezultatelor de tip fals pozitiv și fals negativ. Cele mai multe dintre tehnologiile vechi s-au
bazat în primul rând pe detec ția bazată pe semnături, caracterizat ă prin detectarea
amenințărilor relativ simple și binecunoscute. Tehnologiile noi folosesc o combina ție de
metode pentru a cre ște acurate țea și intervalul detec ției, și, în general, ratele rezultatelor de tip
fals pozitiv și fals negativ au sc ăzut. O altă problemă comună cu precizia acestor IDPS-uri
este faptul c ă acestea necesit ă de obicei un tuning și o personalizare considerabil ă pentru a lua
în considerare caracteristicile mediului monitorizat.
Falsurile pozitive și falsurile negative pentru senzori pot fi reduse oarecum din cauza
complexit ății activităților monitorizate. Un singur senzor monitorizeaz ă adesea trafic ce
implică sute sau mii de hosturi interne și externe. Num ărul și varietatea de sisteme de operare
și aplicații în uz în re țeaua monitorizat ă poate fi imens, iar sistemele de operare și aplicațiile
sunt în continu ă schimbare. Acest lucru face imposibil pentru un senzor s ă înțeleagă tot ceea
ce vede.
Chiar mai r ău, senzorii trebuie s ă monitorizeze activitatea pentru mai multe combina ții
diferite de servere și clienti. De exemplu, o organiza ție ar putea utiliza 10 tipuri și versiuni de
servere web, pe care utilizatorii le-ar putea accesa cu 50 de tipuri și versiuni diferite de
browsere web. Fiecare combina ție de browser și server ar putea avea caracteristici de
comunicare unice (ex: secven ța de comenzi, codurile de r ăspuns), lucru ce ar putea afecta
acuratețea analizei. De asemenea, diferite configura ții și particulariz ări ar putea fi aplicate
browserelor și serverelor. Dispozitivele de control( firewall-uri, servere proxy) dintre servere
și clienți ce modific ă activitatea de re țea, ar putea provoca dificult ăți suplimentare pentru
senzori.
În mod ideal, IDPS-urile la nivel re țea ar trebui s ă poată interpreta toat ă activitatea de
rețea la fel cum endpoint-urile o fac. De exemplu, diferite tipuri de servere web pot interpreta
aceeași cerere web în moduri diferite. Tehnicile speficie analizei protocoalelor stateful de
34multe ori încerc ă să realizeze acest lucru prin replicarea prelucr ării efectuate de tipuri comune
de clienți și servere. Acest lucru permite senzorilor îmbun ătățirea preciziei de detec ție. Mulți
atacatorii fac uz de caracteristicile specifice de prelucrare ale clien ților sau serverlor, cum ar fi
manipularea codific ării caracterelor, în atacurile lor sau în tehnicile de evaziune folosite.
Organizațiile trebuie s ă utilizeze aceste IDPS-uri deoarece pot combate utilizarea tehnicilor
comune de evaziune.
4.3.3.3 Tunning și customizare
Pentru a îmbun ătăți precizia de detec ție este nevoie de un tunning și o personalizare
mai în detaliu. Exemple de capabilit ăți de personalizare și tuning sunt pragurile pentru
scanarea de porturi și încercările de autentificare ale aplica țiilor, listele negre și listele albe
pentru adrese IP și nume de utilizator, precum și setări de avertizare. Unele produse ofer ă și
funcționalități de editare a codului, care este de obicei limitat la semn ături, dar, în unele
cazuri, este permis accesul la codul adi țional, ca în cazul programele utilizate pentru a efectua
analiza protocoalelor de tip stateful.
Se pot utiliza informa țiile legate de host-urile organiza ției pentru a îmbun ătăți precizia de
detecție. De exemplu, s-ar putea permite administratorilor specificarea adreselor IP utilizate
de serverele web ale organiza ției, servere de mail, și alte tipuri comune de host, precum și
tipurile de servicii oferite de fiecare host(tipul și versiunea aplica ție de server web). Acest
lucru permite sistemului o prioritizare mai bun ă a alertelor; o alert ă pentru un atac specific
serviciului Apache având ca țintă un server de web Apache ar avea o prioritate mai mare
decât acela și atac îndreptat c ătre un alt tip de server web. Pot fi importate rezultatele
scanărilor vulnerabilit ăților și apoi utilizate pentru a determina ce atacurile ar avea succes
dacă nu ar fi blocate. Acest lucru permite luarea unor decizii mai bune și precise cu privire la
acțiunile de prevenire și prioritizare a alertelor.
4.3.3.4 Limit ări tehnologice
Deși sunt oferite capabilit ăți extinse de detectare, acestea au totu și unele limit ări
importante. Trei dintre cele mai importante sunt:analiza traficul criptat din re țea, manipularea
sarcinilor cu trafic intens și rezistența atacurilor împotriva IDPS-ului însu și. Aceste limit ări
sunt discutate mai jos.
Atacurile lansate prin traficul criptat nu pot fi detectate, inclusiv cele din re țelele
private virtuale, din sesiunile SSH sau ce folosesc HTTP peste SSL (HTTPS). A șa cum am
menționat anterior, exist ă posibilitatea realiz ării unei analize a configur ării inițiale a
conexiunilor criptate, care poate identifica dac ă software-ul client sau serverul are
vulnerabilit ăți cunoscute sau nu este configurat corect. Pentru a se asigura c ă o analiză
satisfăcătoare se face asupra traficului criptat, organiza țiile ar trebui s ă utilizeze sisteme ce pot
analiza datele înainte ca acestea s ă fie criptate sau dup ă ce au fost decriptate. Exemplele
includ plasarea unor senzori în re țea pentru a monitoriza traficul necriptat (ex: traficul
introdus într-o organiza ție prin intermediul unui gateway VPN și decriptat apoi) și utilizarea
unui software la nivel de host pentru a monitoriza activitatea host-ului surs ă sau destina ție.
IDPS-urile la nivel re țea pot fi în imposibilitatea de a efectua o analiz ă completă sub
sarcini mari. Senzori pasivi ar dropa unele pachete, existând posibilitatea trecerii unor
incidente ca nedetectate, mai ales în cazul în care analiza protocoalelor stateful este în uz.
Pentru senzorii inline, droparea pachetele sub sarcini mari provoac ă perturbări în
35disponibilitatea re țelei; întârzierile cauzate de prelucrarea pachetelor ar putea cauza o laten ță
inacceptabil de mare. Pentru a evita acest lucru, organiza țiile ce folosesc senzori inline ar
trebui să-i selecteze pe cei care pot recunoaste condi țiile unui trafic foarte mare, iar în acest
caz să treacă anumite tipuri de trafic f ără a efectua o analiza complet ă (parțială sau deloc) sau
să dropeze traficul cu o prioritate redus ă pentru a reduce sarcina . Multi furnizori încearc ă să
optimizeze senzori pentru a oferi performan țe mai bune la sarcini mari prin utilizarea unui
hardware specializat (ex: pl ăci de rețea de mare l ățime de band ă) și recompilarea
componentelor software pentru a include set ările și personaliz ările făcute de către
administratori. De și vânzătorii își evalueaz ă senzorii la l ățimi de band ă maxime, capacitatea
reală a oricărui produs depinde de mai mul ți factori:
Tipurile de protocoale în uz(aplica ție, transport, re țea/internet) și profunzimea analizei
efectuate pentru fiecare protocol. Vendorii î și evalueaz ă produsele bazându-se pe
capacitatea lor de a efectua analize rezonabile asupra unui mix "tipic" de protocoale.
Nivelul de analiz ă pe care o organiza ție dorește să o efectueze și tipurile de protocoale
utilizate pot varia considerabil fa ță de condițiile testate;
Longevitatea conexiuni. Un senzor poate avea un overhead mai sc ăzut pentru o
conexiune pe termen lung, fa ță de cazul unor mai multe conexiunii pe termen scurt;
Numărul de conexiuni simultan.
Senzorii sunt sensibili la diferite tipuri de atacuri. Atacatorii pot genera volume neobi șnuit
de mari de trafic caracteristice atacurilor de tip DDoS și trafic anormal (pachete fragmentate
neobișnuit), pentru a încerca s ă epuizeze resursele unui senzor sau s ă-i provocea dezactivarea.
O altă tehnică de atac, cunoscut sub numele de orbire( blinding), genereaz ă trafic care s ă
declanșeze mai multe alerte într-o perioad ă scurtă de timp, fiind special conceput pentru a
profita de configura țiile tipice ale senzorilor. În multe cazuri, acest tip de trafic nu are ca
obiectiv atacul unor ținte. Scopul real este dezactivarea sistemului sau generarea unui num ăr
foarte mare de alerte astfel încât alerte generate de atacul real vor trece neobservat. Mul ți
senzori pot recunoa ște folosirea tehnicilor și instrumentelor comune pentru declan șarea unor
astfel de atacuri; astfel pot alerta administratori de incinden ța atacului, ignorând restul
activităților pentru a reduce sarcina. Organiza țiile trebuie s ă selecteze produse care ofer ă
caracteristici care le fac rezistente la e șec în cazul unor atacuri.
4.3.4 Preven ția
Sunt oferite diverse capacit ăți de prevenire, inclusiv urm ătoarele (grupate în func ție de
tipul de senzor):
36Pasiv
Încheierea sesiunii TCP curente. Un senzor pasiv poate determina încheierea unei
sesiune TCP existente prin trimiterea de pachete TCP cu flag RESET setat catre
ambele endpoint-uri; acest lucru este numit session sniping7.Senzorul face acest lucru
pentru a face s ă pară că fiecare endpoint încerc ă să termine conexiunea. Scopul este
acela ca unul dintre obiective s ă încheie conexiunea înainte ca un atac s ă reușească. În
multe cazuri îns ă, pachetele de resetare nu sunt primite la timp.De asemenea, din
cauza faptului c ă această metodă este aplicabil ă doar pentru TCP, nu poate fi folosit ă
în cazul atacurilor bazate pe alte tipuri de pachete, incluzând UDP sau ICMP. Metoda
session sniping nu mai este larg utilizat ă din cauză noilor metode mult mai eficiente.
Inline
Executarea de firewalling inline. Cei mai mul ți senzori ofera capabilit ățile unui
firewall, astfel poate dropa sau respinge activit ățile suspecte;
Reducerea l ățimi de band ă. Dacă un anumit protocol este utilizat necorespunz ător,
ca în cazul unui atac DoS sau în distribu ția unor malware-uri, unii senzori de linie
poate limita procentul de band ă de rețea pe care protocolul respectiv îl poate folosi.
Acest lucru împiedic ă impactul negativ asupra l ățimii de band ă în cazul utiliz ării de
către alte resurse;
Modificarea con ținutului mali țios.După cum este descris în sec țiunea 1.2, unii
senzori inline poate “cur ăța” o parte dintr-un pachet, con ținutul rău intenționat este
înlocuit cu un con ținut benign, pachetele dezinfectate fiind trimise apoi la destina ție.
Un senzor care ac ționează ca un proxy ar putea efectua o normalizarea automat ă a
întregului trafic. Aceasta are ca efect eliminarea unor atacuri care implic ă antetele
pachetelor și unele antete aplica ție, indifferent dac ă IDPS-ul a detectat sau nu un atac.
Unii senzori pot elimina ata șamente infectate din email-uri, precum și alte elemente
discrete de con ținut malware din traficul în re țea.
Pasiv & Inline
Reconfigurarea altor dispozitive de securitate . Mulți senzori pot instrui diferite
dispozitive de securitate de re țea, cum ar fi firewall-uri, routere, switch-uri pentru a se
reconfigura singure spre a bloca anumite tipuri de activit ăți sau să le plaseze pe alte
rute. Acest lucru poate fi util în mai multe situa ții, cum ar fi p ăstrarea unui atacator
extern în afara re țelei și trimiterea în carantin ă a unui host care a fost compromis (ex:
mutarea într-un VLAN carantin ă). Această tehnică de prevenire este util ă doar pentru
traficul de re țea ce pot fi diferen țiat în func ție de caracteristicile header-ului
recunoscute de c ătre dispozitive de securitate( adresele IP, numere de port;
Rularea unui program ter ț sau script . Se poate rula un script specificat de c ătre
administrator când este detectat ă o anumit ă activitate malware. Acest lucru ar putea
7Un senzor inline poate încerca aceast ă tehnică, dar este mult mai ineficient ă decât celelalte ac țiuni pe
care le poate întreprinde; astfel, în practic ă aceasta tehnic ă este rar folosit ă de către un senzor inline
37declanșa o acțiune de prevenire dorit ă de către administrator, cum ar fi reconfigurarea
altor dispozitive de securitate pentru a bloca respectiva activitate. Programe ter țele sau
script-urile sunt cele mai frecvent utilizate atunci când sistemul nu are caracteristicile
de prevenire dorite de c ătre administratorii.
Cei mai mul ți senzori permite administratorilor specificare configura ției de preven ție pentru
fiecare tip de alert ă. Aceasta include activarea sau dezactivarea preven ției, precum și
specificarea tipului de ac țiune ce trebuie întreprins ă. Unii senzori au un mod de înv ățare sau
de simulare ce suprim ă toate acțiunile de prevenire, indicând în schimb când ar fi fost
necesară efectuarea unei ac țiuni de prevenire. Acest lucru permite administratorilor s ă
monitorizeze și să ajusteze configura ția capacit ăților de preven ție înainte de a le activa, ceea
ce reduce riscul de blocare accidental al activit ății benigne.
4.4 Management
4.4.1 Implementare
Odată ce un produs a fost selectat, administratorii trebuie s ă proiecteze o arhitectur ă,
să efectueze testarea și asigurarea, iar apoi s ă le implementeze. Urm ătoarele reprezint ă niște
completări la materialul prezentat în sec țiunea 3.3.1:
Designul arhitecturii . O atenție special ă trebuie acordat ă locului în care senzorii ar
trebui să fie plasați în rețea, numărului de senzori necesari, ce senzori ar trebui s ă fie
pasivi sau de tip inline și modulului în care senzorii pasivi ar trebui s ă fie conecta ți la
rețea;
Testarea și amplasarea componentelor . Implementarea unui astfel de sistem poate
necesita c ăderi scurte ale re țelei scurte, în special atunci când sunt integra ți senzori
inline. Totu și, amplasarea senzorilor pasiv poate provoca de asemenea întreruperi din
mai multe motive, incluzând instalarea interceptoarelor de re țea, a IDS-urilor de tip
load-balancer și reconfigurarea switch-urilor pentru a activa porturile de tip span;
Securizarea componentelor. Administratorii trebuie s ă se asigure c ă pentru senzori
atât pasivi, cât și cei inline nu au fost asignate adrese IP interfe țelor de re țea folosite
pentru a monitoriza traficul, cu excep ția celor utilizate pentru management. Operarea
unui senzor f ără adrese IP alocate pentru interfe țele de monitorizare se nume ște
funcționare în mod invizibil (stealth mode). Acest mod îmbun ătățește securitatea
senzorilor deoarece împiedic ă alte host-uri în a ini ția conexiuni cu ace știa. Astfel, sunt
ascunși față de atacatori, limitând expunerea lor la atacuri. Cu toate acestea, atacatorii
ar putea fi în m ăsură să identifice existen ța unui senzor și să determine ce produs este
utilizat prin analiza caracteristicilor ac țiunilor de prevenire. O astfel de analiz ă ar
putea include monitorizarea re țelelor protejate și determinarea a c ăror tipuri de
38modelelor de scanare ar putea declan șa răspunsuri particulare și ce valori sunt setate în
anumite câmpuri din antetul pachetelor.
4.5 Operare și mentenan ță
Operarea și întreținerea se realizeaz ă în același mod prezentat în general în sec țiunea
3.3.2.
395. IDPS-uri la nivel de host
Un astfel de sistem monitorizeaz ă caracteristicile și evenimentele din cadrul unui
singur host pentru activit ăți suspecte. Exemple de tipuri de caracteristici ce ar putea fi
monitorizate sunt: traficul de re țea cu sau f ără fir (numai pentru acel host), logurile de sistem,
procesele active, accesul și modificarea fi șierelor sau modific ările aduse configura ției
sistemului sau aplica țiilor.
5.1 Componente și Arhitectur ă
5.1.1 Componentele tipice
Cele mai multe IDPS-uri la nivel host au software-uri de detectare cunoscute sub
numele de agenți, instalați pe gazdele de interes. Fiecare agent monitorizeaz ă activitatea unui
computer, iar în cazul în care toate capacit ățile sunt activate, efectueaz ă, de asemenea, ac țiuni
de prevenire. Agen ții transmit datele la servere de management, care pot utiliza op țional
servere de baze de date pentru stocare. Consolele sunt utilizate pentru management și
monitorizare.
Unele sisteme utilizeaz ă dispozitive speciale care ruleaz ă software-ul agent în locul
unei instal ări individuale a software-ului agent pe gazd ă. Fiecare dispozitiv este pozi ționat
pentru a monitoriza traficul de re țea ce merge la și de la un anumit host. Din punct de vedere
tehnic, acestea ar putea fi considerate sisteme de nivel re țea, deoarece acestea sunt utilizate în
mod inline pentru a monitoriza traficul în re țea. Cu toate acestea, ele monitorizeaz ă obicei
activitate unui tip specific de aplica ție, cum ar fi un server web sau server de baze de date;
astfel, acestea sunt mai specializate decât un IDPS standard de nivel re țea. De asemenea,
software-ul care ruleaz ă pe dispozitiv are adesea func ționalități identice sau similare cu cele
ale agenților bazați pe host. De aceea, IDPS-uri la nivel de host ce folosesc aceste dispozitive
sunt incluse în aceast ă secțiune.
Fiecare agent este de obicei proiectat pentru a proteja una dintre urm ătoarele:
Un server . Pe lângă monitorizarea sistemului de operare al serverului (OS), agentul
poate monitoriza, de asemenea, unele aplica ții comune;
Un host client (desktop sau laptop) . Agenți proiecta ți pentru a monitoriza utilizatorii
unui host de obicei monitorizeaz ă sistemul de operare și aplicații comune client, cum
ar fi clienti de email și browsere Web;
O aplicație/ serviciu . Unii agen ți monitorizeaz ă o aplicație specific ă, cum ar fi un
program de server web sau un program de server de baze de date. Acest tip de agent
este de asemenea cunoscut ca un dispozitiv IDPS.
Cele mai multe produse nu dispun de agen ți pentru alte tipuri de host-uri(firewall-uri,
routere, switch-uri).
405.1.2 Arhitectura de re țea
Arhitectura de re țea este foarte simpl ă. Deoarece agen ții sunt conecta ți la dispozitivele
existente în re țelele organiza ției, componentele comunic ă prin intermediul acestor re țele în
locul unei re țele de management separat ă. Comunica țiile pot fi criptate, prevenind accesul
nedorit la informa ții sensibile. Agen ții hardware sunt instala ți inline, imediat în fa ța
dispozitivelor protejate. Figura 5.1 prezint ă un exemplu de arhitectur ă.
Figura 5.1 -Arhitectura unui IDPS la nivel de host
415.1.3 Loca ția agenților
Agenții IDPS baza ți pe host sunt cel mai frecvent utiliza ți pentru protec ția unor host-uri
critice, cum ar fi servere accesibile publicului și servere care con țin informa ții sensibile.
Agenții se pot plia pe orice tip de host deoarece sunt disponibili pentru diferite sisteme de
operare pentru servere și desktop / laptop, precum și pentru aplica ții specifice serverelor.
Unele organiza ții îi folosesc în primul rând pentru a analiza activit ăți ce nu pot fi monitorizate
prin alte controale de securitate. De exemplu, senzori IDPS baza ți pe rețea nu pot analiza
activitatea în re țele de comunica ții criptate, dar cei instala ți pe endpoint-uri pot vedea
activitatea necriptat ă. Organiza țiile ar trebui s ă ia în considerare urm ătoarele criterii
suplimentare atunci când selecteaz ă locațiile de implementare:
Costul pentru a implementa, men ține și monitoriza agen ții;
Sistemele de operare și aplicațiile suportate de c ătre agenți;
Importanța datelor și serviciilor oferite de host;
Capacitatea infrastructurii de a sus ține agenții (ex: band ă de rețea suficient ă pentru a
transfera datele de avertizare c ătre serverele centralizate și a transfera actualiz ările de
software și politică de la servere la agen ți).
5.1.4 Arhitectura host-ului
Pentru a oferi func ționalitatea de prevenire a intruziunilor, cei mai mul ți agenți
modifică arhitectura intern ă a host-urilor pe care sunt instala ți. Aceast lucru se face de obicei
printr-o pană de fixare („shim”), reprezentat ă printr-un strat de cod plasat între straturile
existente ale codului. Astfel, datele sunt interceptate la un punct în care aceastea ar fi fost în
mod normal trecute de la o bucat ă de cod la alta. În acest mod sunt analizate și se determin ă
dacă ar trebuie permis ă trecerea lor mai departe. Aceasta metod ă poate fi folosit ă pentru mai
multe tipuri de resurse:
Traficul de re țea
Activitatea sistemului de fi șiere
Apeluri sistem
Activitatea regi ștrilor Windows
Aplicații comune (ex: e-mail, web).
Unii agen ți nu modific ă arhitectura intern ă. În schimb, ele monitorizeaz ă activitatea f ără
pene de fixare sau analizeaz ă urme ale activit ății derulate, cum ar fi logurile și modificările de
fișiere. Deși mai puțin intruzive fa ță de gazdă, reducând posibilitatea de a interfera cu
operațiunile normale ale gazdei, aceste metode sunt mai pu țin eficiente în detectarea
amenințărilor și de multe ori nu pot efectua vreo ac țiune de preven ție.
Una dintre cele mai importante decizii este reprezentat ă de alegerea tipului solu ție IDPS,
ori de tip software, instalat pe gazd ă, ori de tip appliance. Din perspectiva detec ției și a
prevenției, instalarea de agenti pe gazde, este de preferat, deoarece agen ții au acces direct la
caracteristicile gazdelor, de multe ori permi țându-le să efectueze o detec ție și o preven ție mai
complexă și exactă. Cu toate acestea, agen ții sunt suporta ți doar de câteva sisteme de operare
comune; în cazul în care o gazd ă nu utilizeaz ă un sistem de operare acceptat, agentul de tip
42appliance poate fi utilizat. Un alt motiv pentru a utiliza acest tip este legat de performan ță,
instalarea unui software consumator de resurse ar putea impacta negativ performan țele gazdei.
5.2 Capabilit ățile de securitate
5.2.1 Logare
Logarea de date legat ă de evenimentele detectate este suportat ă și aici. Aceste date pot fi
utilizate pentru a confirma validitatea alertelor, pentru a investiga incidentele și a corela
evenimente cu cele din alte surse de logare. Câmpuri de date logate în mod obi șnuit includ
următoarele:
Timestamp (de obicei data și ora) ;
Evenimentul sau tipul alertei;
Evaluare (ex: prioritate, severitate, impact, nivelul de încredere);
Detalii specifice evenimentului logat, cum ar fi adresa IP și portul, nume de fi șiere și
căii, precum și ID-uri de utilizator;
Acțiune de preven ție întreprins ă (dacă este cazul).
5.2.2 Detec ția
Pentru detec ția celor mai multor tipuri de activit ăți rău intenționate sunt folosite de
multe ori o combina ție între tehnica bazat ă pe semnături pentru a identifica atacurile
cunoscute și cea bazat ă pe detectarea anomaliilor împreun ă cu politici sau seturi de reguli
pentru a identifica atacurile necunoscute anterior.
5.2.2.1 Tipuri de evenimente detectate
Tipurile de evenimente detectate variaz ă substanțial în func ție de tehnicile de detectare
folosite. Unele produse ofer ă mai multe tehnici de detectare, în timp ce altele se concentreaz ă
pe câteva sau una. De exemplu, se analizeaz ă doar traficul în re țea sau se verific ă doar
integritatea fi șierelor critice. Tehnicile specifice utilizate în mod obi șnuit sunt:
Analiza codului . Agenții pot utiliza una sau mai multe din tehnicile de mai jos pentru
a identifica activit ăți malițioase prin analizarea încerc ărilor de a executa cod. Toate
aceste tehnici sunt utile în oprirea malware-urilor și pot preveni și alte atacuri, cum ar
fi unele care ar permite accesul neautorizat, executarea de cod sau escaladarea unor
privilegii.
oAnaliza comportamental ă a codului . Înainte de a fi rulat în mod normal,
codul poate fi executat în prim ă fază într-un mediu virtual sau într-un sandbox,
pentru o analiza a comportamentul s ău și pentru o comparare cu profiluri sau
reguli cunoscute a fi r ău intenționate sau nu. De exemplu, atunci când o bucat ă
43de cod este executat ă, s-ar putea încerca ob ținerea unor privilegii la nivel de
administrator sau suprascrie un executabil de sistem;
oDetecția buffer overflow . Încercările de a inunda bufferele sistemului pot fi
detectate prin c ăutarea caracteristicilor specifice, cum ar fi anumite secven țe de
instrucțiuni ce încearc ă să acceseze por țiuni de memorie, altele decât cele
alocate pentru procesul respectiv;
oMonitorizarea apelurilor sistem . Agentul știe ce aplica ții și procese ar trebui
să utilizeze apelurile sistem și ce alte ac țiuni le este permis. De exemplu, un
agent poate recunoa ște un proces care încearc ă să intercepteze ce se tasteaz ă,
cum ar fi un keylogger. Un alt exemplu este un agent ce limiteaz ă încărcarea
obiectelor de tip COM( Component Object Model), permi țând unei aplica ții
PDA, dar nu și altor aplica ții, să acceseze agenda unui client de email. Poate fi
restricționată și încărcarea unor anume drivere, prevenind astfel instalarea unor
rootkit-uri și a altor atacuri;
oListe cu aplica ții și librării. Un agent poate monitoriza fiecare aplica ție și
librărie (ex: DLL – libr ărie dinamic ă de legătură), pe care un utilizator sau un
proces încearc ă să le încarce și compară aceste informa ții cu listele de aplica ții
autorizate și neautorizate. Acest lucru poate fi folosit nu numai pentru a
restricționa utilizarea unor aplica ții și biblioteci, dar și pentru utilizarea unor
anume versiuni ale acestora.
Analiza traficului de re țea. Acest lucru este de multe ori similar cu ceea ce un IDPS
de nivel re țea face, putând analiza atât traficul de re țea cu fir și fără fir. În plus fa ță de
analiza protocoalelor specifice nivelului re țea, transport sau aplica ție, pot fi incluse
procesări speciale pentru aplica ții comune, cum ar fi clien ți de email. Analiza
traficului permite agentului s ă extragă fișiere trimise de aplica ții, ce pot fi apoi
verificate contra programelor malware;
Filtrarea traficului de re țea. Agenții includ de multe ori un firewall tipic hostului, ce
poate restric ționa traficul de intrare și de ieșire pentru fiecare aplica ție din sistem,
prevenind accesul neautorizat și încălcări ale politici de utilizare (ex: utilizarea de
servicii externe nepotrivite). Unele dintre aceste firewall-uri pot genera și folosi o list ă
de host-uri cu care gazda ar trebui s ă comunice în cadrul organiza ției;
Monitorizarea sistemului de fi șiere. Poate fi efectuat ă folosind mai multe tehnici,
inclusiv cele enumerate mai jos. Administratorii ar trebui s ă fie conștienți de faptul c ă
unele produse î și bazează monitorizarea pe nume de fi șiere, așa că, dacă utilizatorii
sau atacatori modific ă numele fi șierelor, aceste tehnici ar deveni ineficiente;
oVerificarea integrit ății fișierelor . Acest lucru implic ă generarea periodic ă a
unui digest sau a unei alte sume criptografice pentru fi șiere critice, comparea
cu valori de referin ță și identificarea diferen țelor. Verificarea integrit ății
fișierelor poate stabili doar faptul c ă un fișier a fost deja modificat, cum ar fi
înlocuirea unui sistem binar cu un cal troian sau un rootkit;
44oVerificarea atributelor fi șierelor. Implică verificarea periodic ă a atributelor
fișierelor importante, cum ar fi dreptul de proprietate și permisiuni, pentru
modificări. Ca și în cazul integrit ății fișierelor, poate determin ă schimbarea
doar după ce aceasta a avut loc;
oÎncercările de acces la fi șiere. Un agent cu o pan ă de fixare în sistem de
fișiere poate monitoriza toate încerc ările de a acces la fi șiere critice( ex:
fișierele binare de sistem) și opri încerc ările care sunt suspecte. Agentul are un
set de politici privind accesul, astfel încât se compar ă aceste politici cu
caracteristicile încerc ării curente, ce utilizator sau aplica ție încearc ă să
acceseze fiecare fi șier, ce tip de acces a fost solicitat (citire, scriere,
executare)8. Acest lucru ar putea fi folosit pentru a preveni instalarea anumitor
forme de malware, cum ar fi rootkit-urile și caii troieni , sau a mai multor alte
tipuri de activit ăți rău intenționate care implic ă accesul la fi șier, modificarea,
înlocuirea sau ștergerea.
Analiza logurilor . Se pot monitoriza și analiza logurile sistemelor de operare și a le
aplicațiilor pentru a identifica activit ăți malware9. Aceste loguri pot con ține informa ții
despre evenimentele de sistem, ce ac țiuni opera ționale sunt efectuate de componentele
sistemului de operare (ex: oprirea sistemului, începerea unui serviciu); înregistr ările de
audit conțin informa ții despre evenimente de securitate, cum ar fi încerc ările reușite și
nereușite de autentificare și modificările aduse politicilor de securitate; evenimentele
ce țin de aplica ții: acțiunile opera ționale semnificative efectuate( pornirea și oprirea) ,
nefuncționări, precum și schimbări majore în configura ție;
Monitorizarea configura ției rețelei. Există posibilitatea monitoriz ării configura ției
curente a re țelei și detectarea modific ărilor. De obicei toate interfe țele de rețea de pe
gazdă sunt monitorizate, prin cablu, f ără fir, din VPN-uri și conectate la modem.
Exemple de modific ări semnificative de configurare de re țea sunt plasarea interfe ței în
mod promiscu, folosirea de porturi TCP / UDP suplimentare pe gazd ă sau utilizarea
unor protocoale de re țea suplimentare, cum ar fi protocoalele non-IP. Aceste
modificări ar putea indica faptul c ă gazdă a fost deja compromis ă și este configurat ă
pentru a fi utilizat ă în atacuri viitoare sau pentru transfer de date.
Deoarece aceste IDPS-uri au adesea cuno știnte extinse despre caracteristicile și
configura țiile gazdelor, poate determina de multe ori dac ă un atac împotriva gazdei va reu și
dacă nu este oprit. Agen ți pot folosi aceste cunostinte pentru a selecta ac țiunile de prevenire și
de a atribui priorit ăți adecvate alertelelor.
8Pe sistemele Windows, multe set ării de configura ție constă într-un set special de fi șiere numie
registre .Unii agen ți au niște pene introduse în ace ști regiștrii ce restric ționează accesul la por țiuni critice ale
acestora, în special cele folosite în mod frecvent de malware-uri.
9Unele produse efectueaz ă activități ce țin doar de analiza și managementul logurilor.De și acestea sunt
referite a fi IPDS-uri bazate pe host, majoritatea sunt de fapt produse de tip SIEM(security information and event
management).
455.2.2.2 Precizia detec ției
Ca orice alte tehnologii, și acest tip cauzeaz ă de multe ori falsuri pozitive și negative.
Cu toate acestea, precizia de detec ție constituie o problem ă mai mare în acest caz deoarece
multe din posibilele tehnici de detectare, cum ar fi analiza logurilor și monitorizarea
sistemului de fi șiere nu au cuno ștințe legate de contextul sub care au avut loc evenimentele
detectate. De exemplu, o gazd ă poate fi repornit ă, o nouă aplicație poate fi instalat ă sau un
sistem de fi șiere poate fi înlocuit. Aceste ac țiuni ar putea fi realizate prin activit ăți rău
intenționate sau ar putea fi parte a func ționării și intreținerii normale a gazdei. Evenimentele
în sine sunt detectate corect, dar natura lor, benigne sau mali țioase, nu poate fi întotdeauna
determinat ă fără un context suplimentar. Unele produse, în special cele destinate desktop-
urilor / laptop -urilor, cer utilizatorilor furnizarea contextului, dac ă o aplicație este actualizat ă
sau nu de c ătre utilizator. Dac ă acesta nu r ăspunde la solicitare într-o anumit ă perioadă de
timp (de obicei câteva minute), agentul alege o ac țiune implicit ă (permitere / refuzare).
Sistemele care utilizeaz ă combinații de mai multe tehnici de detectare ar trebui s ă fie,
în general, capabile de a realiza o detec ție mai precis ă decât produsele ce utilizeaz ă una sau
câteva tehnici. Deoarece fiecare tehnic ă poate monitoriza diferite aspecte ale unei gazde,
folosirea mai multor tehnici permite agen ților colectarea mai multor informa ții privind
activitățile ce au loc. Acest lucru ofer ă o imagine mai complet ă a evenimentelor, și poate
oferi, de asemenea, contextul suplimentar care poate fi de ajutor în evaluarea inten ției
anumitor evenimente.
5.2.2.3 Tuning și Personalizare
Ca și în cazul celorlalte sisteme, este necesar tuning-ul și o personalizare
considerabil ă. De exemplu, multe se bazeaz ă pe observarea activit ății gazdei și dezvoltarea
unor linii de baz ă sau profiluri de comportament a șteptat. Altele trebuie s ă fie configurate cu
politici detaliate ce definesc exact comportamentul fiec ărei aplicații. De indat ă ce intervin
schimbări în mediul gazd ă, administratorii trebuie s ă se asigure c ă politicile sunt actualizate
pentru a lua aceste modific ări în considerare. În general, nu este recomandat ă legarea
automată cu sistemele de management al schimb ărilor, dar administratorii pot revizui
înregistrările de gestionare a schimb ărilor regulat și ajusta configura ția gazdei și politica de
informare din cadrul sistemului pentru a preveni alarmele false.
Politicile pot fi stabilite per-gazd ă sau pentru grupuri de gazde, fapt ce ofer ă
flexibilitate. Se poate permite configurarea mai multor politici pe o gazd ă pentru mai multe
medii; acest lucru este cel mai util pentru gazde care func ționează în mai multe medii, cum ar
fi un laptop folosit atât în cadrul unei organiza ții cât și din locații externe. Sunt folosite și liste
albe și negre pentru host-uri ( ex: adresele IP ale altor gazde cu care o gazd ă ar putea
comunica), aplica ții, porturi, nume de fi șiere și alte caracteristici ale gazdei. De fapt, unele
produse actualizeaz ă automat agen ți cu cele mai recente informa ții legate de listele albe și
neagre, pe baza rapoartelor de la al ți agenți ce au detectat o nou ă activitate malware. O alt ă
trăsătură comună este personalizarea fiec ărei alerte, cum ar fi specificarea op țiuni de răspuns
ce ar trebui luat ă în cazul alertei respective.
Complexitatea capabilit ăților bazate pe semn ături variaz ă foarte mult în func ție de
tehnicile de detectare folosite de fiecare produs.
465.2.2.4 Limit ări tehnologice
Și în cadrul acestui tip reg ăsim unele limit ări importante. Unele dintre aceste limit ări
sunt descrise în Sec țiunea 4.3.3.4. Alte limit ări importante sunt:
Întârzieri în generarea alertelor . Deși agenții genereaz ă alerte în timp real pentru
cele mai multe tehnici de detectare, unele tehnici sunt utilizate periodic pentru a
identifica evenimentele care au avut loc deja. Astfel de tehnici pot fi aplicate numai pe
oră sau chiar numai câteva ori pe zi, provocând întârzieri semnificative în identificarea
unor evenimente;
Întârzieri în centralizarea rapoartelor . Multe IDPS-uri la nivel de host transmit
datele de alert ă către serverele de management în mod periodic, nu într-un mod real.
Datele de alert ă sunt de obicei transferate în loturi la fiecare 15 sau 60 de minute
pentru a reduce overhead-ul componentelor și a rețelei. Acest lucru poate provoca
întârzieri în ini țierea acțiunilor de r ăspuns, mărind astfel impactul incidentelor care se
răspândesc rapid( ex: infest ări malware);
Utilizare resurselor gazdei . Spre deosebire de alte tehnologii, aceasta implic ă agenți
care ruleaz ă pe gazdele monitorizate. Ace ști agenți pot consuma resurse considerabile
ale gazdei, resurse ce includ memoria intern ă, procesorul și discul. Opera țiunile
agenților, în special acele pene, pot provoca încetiniri în fluxul opera țiunilor. Testarea
și evaluarea resurselor este recomandat ă a fi realizat ă înainte de o posibil ă instalare a
unui IDPS;
Conflicte cu controalele de securitate existente . Instalarea unui agent poate provoca
dezactivarea automat ă a controalelor de securitate existente pe gazd ă( firewall-uri
personale), în cazul în care aceste controale sunt percepute ca o duplicare a
funcționalităților oferite de agent. Instalarea poate provoca conflicte și cu alte
controale de securitate, în special cu cele care folosesc penele pentru a intercepta
activitatea gazdei (firewall-uri personale, clien ți VPN). Pentru a identifica eventualele
conflicte implementatorii ar trebui s ă testeze întâi agen ții pe gazde pe care se execut ă
acele controale de securitate;
Repornirea gazdelor . În cazul upgrade-urilor de tip software în cazul agen ților,
precum și în cazul câtorva modific ări de configurare, agentul poate necesita repornirea
gazdelor monitorizate. Ca și în cazul altor probleme men ționate anterior,
implementatorii ar trebui s ă efectueze teste extinse înainte de selectarea produselor și
să ia în considerare impactul pe care repornirea ar putea s ă o aibă asupra eficacit ății
agenților (ex: agen ții vor fi în imposibilitatea de a detecta cele mai recente amenin țări
deoarece host-uri importante nu au putut fi repornite) .
475.2.3 Preven ția
Sunt oferite diverse capacit ăți de prevenire a intruziunilor. Deoarece capacit ățile
variază în funcție de tehnicile de detectare folosite de fiecare produs, urm ătoarele elemente
descriu aceste capabilit ăți de preven ție în func ție de tehnica de detectare folosit ă:
Analiza codului . Tehnicile de analiz ă de cod pot preveni executarea codului de c ătre
aplicații malware sau neautorizate. Pot fi oprite, de asemenea, aplica ții de rețea ce
invocă shell-uri, ce ar putea fi folosite pentru a efectua anumite tipuri de atacuri. Dac ă
este configurat ă și reglată bine, analiz ă de cod pot fi foarte eficient ă, în special în
oprirea atacurilor necunoscute anterior;
Analiza traficului de re țea.Acest lucru poate opri traficul de re țea de intrare în a fi
prelucrat de c ătre gazdă și traficul de re țea de ieșire să părăsească gazda. Acest lucru
ar putea fi f ăcut pentru a opri atacurile specifice nivelelor re țea /internet, transport, sau
aplicație (și, în unele cazuri, atacuri ce includ protocoalele speficice re țelei wireless)
sau pentru a opri utilizarea de aplica ții și protocoale neautorizate. Analiza poate
identifica fi șiere malware ce sunt desc ărcate sau transferate și preveni aceste fi șiere în
a fi introduse în mediul gazdei. Traficul de re țea ar putea fi dropat sau respins, iar
firewall-ul personal al gazdei (care ar putea fi inclus în agent) ar putea fi reconfigurat
să evite traficul suplimentar legat de cel suspect. Analiza traficului de re țea este
eficientă în stoparea a multor atacuri cunoscute și necunoscute anterior;
Filtrarea traficului de re țea. Funcționând ca un firewall la nivel de host, poate opri
accesul neautorizat și încălcările politicii de utilizare (ex: utilizarea de servicii externe
nepotrivite). Acesta este eficace numai împotriva opririi activit ăților ce sunt
identificabile prin adresa IP, portul TCP / UDP sau tipul și codul în cazul protocolului
ICMP;
Monitorizarea sistemului de fi șiere. Acest lucru poate preveni fi șierele în a fi
accesate, modificate, înlocuite sau șterse, fapt ce ar putea opri instalarea unui
malware,cal troian și rootkit, precum și alte atacuri ce implic ă accesul neautorizat la
fișiere. Aceasta tehnic ă poate oferi un strat suplimentar de control al accesului pentru a
suplimenta tehnologiile de control de acces existente pe gazd ă.
Celelalte tehnici de detectare, analiza logurilor, monitorizarea configura ției rețelei,
verificarea integrit ății fișierelor și a atributelor, în general, nu sprijin ă acțiunile de prevenire,
deoarece acestea identific ă evenimentele dup ă ce au avut loc.
5.2.4 Alte capabilit ăți
Unele IDPS-uri de acest tip ofer ă capabilități non-IDPS, cum ar fi software antivirus,
filtrarea spam-ului și a conținutului web sau de email. Exemple de aceste capacit ăți sunt dup ă
cum urmeaz ă:
48Restricții asupra mediilor de stocare deta șabile . Se pot impune restric ții cu privire
la utilizarea mediilor de stocare amovibile, bazate pe USB (stick-uri flash) sau
tradiționale ( CD, discheta). Acest lucru poate preveni transferul unor malware-uri sau
fișiere, și poate opri copierea unor fi șiere sensibile;
Monitorizarea dispozitivelor audiovizualue . Căteva produse pot detecta activarea
sau uzul unor dispozitive audiovizuale( microfoane, camere video sau telefoane bazate
pe IP). Acest lucru ar putea indica compromiterea unei gazde de c ătre un atacator;
Întărirea gazdei . De exemplu, în cazul în care o aplica ție este reconfigurat ă,
provocând dezactivarea unei func ții de securitate, sistemul ar putea detecta acest lucru
și reactiva apoi aceea func ție;
Monitorizarea st ării proceselor . Unele produse monitorizeaz ă starea proceselor sau a
serviciilor ce ruleaz ă, și în cazul în care constat ă oprirea unuia, este repornit automat.
Poate fi monitorizate, de asemenea, starea unor programe de securitate( software-ul
antivirus);
Curățarea traficului de re țea.Unii agen ți, în special cei de tip appliance, pot igieniza
traficul de re țea pe care îl monitorizeaz ă. De exemplu, acesta ar putea ac ționa ca un
proxy și reconstrui fiecare cerere și răspuns ce este direc ționat prin ea. Acest lucru
poate fi eficace la neutralizarea anumitor activit ăți neobișnuite, în special în header-ul
pachetului și al protocoalelor aplica ție. Igienizare poate împiedica atacurile de
recunoaștere lansate asupra host-urilor sau poate sc ădea cantitatea de informa ții legată
de host care poate fi achizi ționată prin aceast ă metodă. Exemplele includ ascunderea
„amprentelor” sistemelor de operare ale servelor și a mesajelor de eroare de aplica ție.
Este posibil ă prevenția afișării de informa ții sensibile, cum ar fi numere de securitate
socială și numere de card de credit, pe pagini web.
5.3 Management
5.3.1 Implementare
Odată ce un produs a fost selectat, administratorii trebuie s ă proiecteze o arhitectur ă,
să efectueze testarea componentelor, s ă le asigure și apoi să le implementeze. Urm ătoarele
elemente aduc complet ări la materialul prezentat în sec țiunea 2.3.1:
Testarea componentelor și amplasarea . După ce componentele au fost evaluate într-
un mediu de testare, organiza țiile ar trebui s ă le pună în aplicare doar pe câteva host-
uri din mediul de productie. Acest lucru permite administratorilor s ă efectueze
activități de tuning și personalizare pe host-uri în curs de preg ătire pentru o
implementare mai mare. Caracteristicile de prevenire trebuie s ă fie dezactivate în tot
acest timp pân ă la implementarea în mas ă până când agen ții au fost suficient seta ți și
personaliza ți;
49Securizarea componentelor . Dacă serverele de management sau consolele trebuie s ă
se autentifice la fiecare agent pentru a-i gestiona sau colecta datele, organiza țiile
trebuie să se asigure c ă mecanismele de autentificare pot fi gestionate și asigurate în
mod corespunz ător. De exemplu, în cazul în care este nevoie de parole, exist ă
probleme de securitate în cazul utiliz ării unei singure parole pentru to ții agenții; în
cazul în care se folose ște o parol ă separată pentru fiecare agent, parolele pot fi dificil
de urmărit și menținut în cazul a sute sau mii de agen ți. În cazul în care cheile
criptografice sunt folosite pentru autentificare, managementul cheiilor poate prezenta
provocări în emiterea și distribuirea lor.
5.3.2 Operare
Acest tip de IDPS ar trebui exploatat în conformitate cu recomand ările prezentate în
secțiunea 3.3.2. Singura excep ție este în actualizarea agen ților. Unii agen ți pot verifica
periodic serverul de management pentru actualiz ări, preluând și instalând apoi automat
anumite actualiz ări, dacă sunt disponibile. Al ți agenți nu pot face acest lucru, fapt ce necesit ă
ca un administrator s ă verifice manual transferul, instalarea și aplicarea actualiz ărilor. În
multe cazuri, capacitatea de update a unui agent este legat ă de tipul de sistem de operare pe
care este implementat.
506. Soluții profesionale IDPS
6.1 Alegerea IDPS-ului
Având în vedere oferta extrem de bogat ă existentă pe piață, alegerea echipamentului
adecvat pentru sporirea securit ății nu este o activitate simpl ă. Trebuie analiza ți o multitudine
de factori, identificate nevoile companiei, ce tipuri de amenin țări sunt relevante, ce arii sunt
critice, dimensiunea organiza ției, cantitatea de trafic generat ă, personalul IT specializat,
bugetul, etc.
În primul rând trebuie stabilit ă direcția principal ăa companiei, în ce domeniu activeaz ă
pentru a stabilifactorul de risc și de ce nivel de protec ție este nevoie. În cazul unei institu ții
militare factorul de risc estemaxim,necesitând astfel o securitatea maxim ă asiguratăde diverse
echipamente specializate. În cazul unei institu ții educaționale sau funda ții de ajutorare,
factorul de risc este sc ăzutși atuncitrebuie o realizat ă o apărare mai mult împotriva uneltelor
automate ce activeaz ă pe internet, un atacatorspecializat ar fi pu țin probabil s ă încerce s ă
pătrundă în rețea.
Software sau Hardware?
Toate IDPS-urile au o parte software, fie ele de tip hardware( appliance) sau software.
Diferența între un hardware IDPS șisoftware IDPS este felul cum este comercializat. Un
software este o aplica ție ce poate fi instalat ă pe orice sistem ce respect ă anumite cerin țe
tehnice(CPU, memorie RAM, etc) și are un sistem deoperare suportat de aplica ție(Windows,
Linux etc). Acest ă soluție este mai ieftin ă decât un hardware IDPS dinmai multe motive, cel
mai evident este îns ăși faptul că responsabilitatea hardware-ului și a sistemuluide operare
folosit cade în seama utilizatorului. Pot ap ărea diverse erori de configura ție,incompatibilit ăți
cu hardware-ul folosit sau cu sistemul de operare și de aceea instalarea necesit ă decele mai
multe ori personal calificat. Hardware-ul IDPS este un echipament hardware robust, construit
special pentru acest ă funcție,cu un sistem de operare de cele mai multe ori proprietar(de cele
mai multe ori se porne ște de la un Linux ce este apoi modificat și brand-uit) pe care ruleaz ă
un software de IDPS special creat pentru hardware-ul respectiv. Acest tipse mai nume ște și
appliance. Avantajul const ă într-un echipament robust, rezistent,caracterizat de performan țe
ridicate unde suportul de la produc ător este pentru tot echipamentul și nu pe componente,
separate hardware și software. Este privit de utilizator ca un black box,o cutie închis ă, cu o
anumită funcționalitate și care se poate configura în diferite moduri, f ără a interfera cu
hardware-ul sau software-ul de pe echipament. Estemai u șor de instalat pentru c ă nu necesit ă
personal extrem de bine instruit pentru a ob ține perfoman țe decente, dar este și mult mai
scump.În func ție de cerin țe, personalul IT angajat, echipamentele ce trebuie protejate, de
funcționalitățiadiționale și de buget se dispune, se va alege între un IDPS hardware sau
software.IDPS-urile hardware sunt de obicei mai bune și performante decât cele software prin
simplul fapt c ă sunt echipamente dedicate exclusiv acestui lucru.
516.2 Cerin țe pentru prevenirea eficient ă a intruziunilor
• Funcționare inline. Prevenirea eficinent ă a intruziunilor este condi ționată de acest tip de
funcționare. Reg ăsim și IDS-urile active, care pot comunica cuechipamentele de re țea și pot
introduce intr ări în ACL-uri( access lists) dar acestea pot doar bloca total, dup ă
IP, întreaga comunica ție. Alte IDS-uri pot încerca s ă termine for țat o sesiune TCP prin
injectarea pachetelor TCP reset în re țea, dar aceasta metoda nu este deloc eficient ă și este
valabilă doar pentru acest protocol;
• Fiabilitate și disponibilitate. Echipamentul trebuie s ă fie fiabil, s ă nu se defecteze u șor.
Orice oprire sau defectare înseamn ă o posibilă oprire a activit ății în rețea. Atunci când
dispozitivul î șiface update-urile cu noile defini ții este necesar ca acesta s ă nu trebuiasc ă să fie
restartat pentru a leactiva, acest lucru însemnând oprirea activit ății pe perioada de restart;
• Uptime-ul re țelei. Acesta trebuie s ă poată să lase traficul s ă treacă prin el și în caz că pierde
alimentarea cu energie. Astfel o eventual ă defecțiune a sursei de curent înseamn ă osecuritate
scăzută dar nu și oprirea activit ății. Bineînțeles, acest aspect trebuie s ă poate fi
controlat în func ție de comportamentul dorit, în unele cazuri rare dorindu-se oprirea activit ății
decât continuarea într-un mediu nesigur;
• Întârzieri mici. Este de dorit ca impactul asupra vitezei re țelei să fie cât mai redus cu
putință. Echipamentele de re țea oricât de performante ar fi adaug ă întârzieri. Depinzând de
nivelul la care func ționează echipamentul și de rolul lui în re țea, întârzierile pot fi mai mari
saumai mici. Un IDPS performant trebuie s ă introducă întârzieri în re țea cu puțin peste un
switch de nivel 2/nivel 3 și sub un echipament de nivel 4 obi șnuit cum ar fi un firewall sau
load-balancer;
• Performan ță ridicată. Vor fi îndeplinite specifica țiile din fișa tehnică cu toate semn ăturile
active și în condi ții real-life, pentru a fi siguri c ă următoarele semn ături ce vor veni ulterior nu
vor afecta performan ța rețelei prin suprasolicitarea echipamentului;
• Încrederea în semn ături. Update-urile la semn ături este de preferat s ă se facă în mod
automat și fără restartarea echipamentului. De aceea semn ăturile trebuie s ă fie de încredere
și de calitate pentru a nu risca pr ăbușirea rețelei din cauza unei semn ături instalate în mod
automat;
• Posibilitate de reglaj fin(tunning). Anumite semn ături pot produce prea multe alerte false
și atuncidăunează rețelei și opresc aplica țiile legitime. Acestea ori trebuie oprite sau
modificate ori host-urile cu pricina introduse în whitelist-uri pentru a nu mai fi verificate;
• Log-uri eficiente care s ă permită investiga ții ulterioare – Atunci când un incident grav se
întâmplă, chiar dac ă IDPS-ul este blocat, tot trebuie realizat ă o investiga ție pentru o întelegere
mai bună a evenimentelor petrecute.IDPS-ul trebuie s ă aibă log-urile cât mai clare și ușor de
sortat și categorisit, iar la incidentele considerate critice s ă poată să facă captura traficului, s ă
o stocheze, pentru o investigare ulterioar ă.
526.3 Caracteristici cheie al unui IDPS
•Rata de transfer a filtr ării( firewall throughput) . Principalul atribut pe care to ți
producătorii îl trec în foile tehnice aleappliance-urilor pe care le produc este capacitatea de a
filtra traficul. Este m ăsurată în Mb/sec și poate începe de la valori joase de ordinul 25Mb/s și
până la câteva sute de GB/s. Este de avut în vedere cazul IDPS-urilor inline, unde, de obicei,
această capacitate este traficul full-duplex și nu traficul RX sau TX luatseparat. Un IDPS
inline de 25Mb/s de obicei va filtra 12.5Mb/s RX plus 12.5Mb/s TX. Acest atribut este
specific filtr ării traficului, rata ce caracterizeaz ă abilitatea de a analiza traficul în
vedereadetect ării și prevenirii intruziunilor este mult mai mic ă;
•Rata de transfer a preven ției intruziunilor(intrusion prevention throughput).
Reprezint ăcapacitatea de a filtra și analiza traficul în vedereadetect ării și prevenirii
intruziunilor. Este mai mic ă decât rata filtr ării pentru c ă necesită mai mult ă putere de calcul,
fiind necesar ă o analiză a protocoale de nivel superior și capabilit ăți de reținereși analiză a
unor sesiuni întregi, etc;
•Numărul de interfe țe.IDPS-urile au nevoie de cel pu țin două interfețe, una de
management și una de monitorizare. Cele cu dou ă interfețe nu pot fi folosite decât ca IDS, nu
pot fi folosite inline. Pentru a-l folosiinline este necesar ă existența a cel pu țin trei interfe țe,
două de monitorizare și una de administrare. Implementare cu trei interfe țe este setup-ul
preferat de majoritatea cump ărătorilor.Dar cu cât dispune de mai multe interfe țe, cu atât mai
bine. Se pot realiza senzori virtuali, combinând interfe țele două căte douăși astfel dintr-un
singur IDPS se pot realiza mai multe virtuale;
•Numărul de sesiuni . Reprezint ă numărul de sesiuni TCP concurente ce pot fi monitorizate
în acelașitimp. Acesta este de ordinul a zeci și sute de mii și char milioane. Depinzând de tipul
traficuluimonitorizat trebuie ales un IDPS adecvat. Este strâns legat de prima rat ă prezentat ă
mai sus; cump ărătorul nu trebuie s ă își facă griji în mod special pentru num ărul de sesiuni,
acesta alegând IDPS-ul cu o rat ă de tranfer adecvat ă rețelei.
Acestea sunt cele mai importante caracteristici de luat în considerare în achizi ționarea
unui IDPS. Alte caracteristici cum ar fi temperatura de func ționare saulimitele de
umiditate la care poate func ționa aparatultrebuie luate în considerare în cazuri speciale când
echipamentul trebuie s ăfuncționeze în condi ții deosebite.
Din păcate realitatea este c ă anumite atribute țin foarte mult de marketing; faptul c ă un
echipament ce are rate de transfer specifice declarate a fi mari nu înseamn ă automat c ă este un
echipament bun.Chiar dac ă atributele declarate pot fi mai mari decât realitatea, aceste atribute
nu spun nimic despre capabilitatea echipamentului de a identifica și
preveniintruziunile.Aceasta capabilitate de a identifica și preveni intruziunile este de departe
cea mai important ă dintre toate și extrem de greu de verificat. Aceasta depinde de calitatea
semnăturilor pe care
53le oferă producătorul, de calitatea algoritmului folosit pentru identificarea anomaliilor, de cât
de bine poate distinge folosirea dubioas ă a anumitor protocoale, etc.
Producătorii își reglează echipamentele astfel încât s ă treacă cu brio la testele efectuate
cu propriile unelte de testare astfel c ă folosirea uneltelor oferite de produc ătorul
respectivuluiechipament pentru a-l testa sunt inutile. La fel și în ceea ce prive ște cele mai
folosite unelte de testare ter țe cum ar fi Nessus. Appliance-urile au defini țiile bine definite
pentru o reu șită sigură în acest caz. Pentru a fi siguri c ă echipamentul ce urmeaz ă a fi
achiziționat ofer ă securitatea care este dorit ă, este necesar ă o testare intern ă, simulând postura
atacatorului și încercarea anumitorexploat ăriși tehnici de evaziune cum ar fi fragmentarea
pachetelor, atacuri false, pacheteduplicate, etc.
O multitudine de teste sunt foarte greu de realizat f ără un laborator echipat;pentru teste
cum arfi generarea unui trafic foarte mare pentru a verifica ratele de filtrare se pot apela la
companiispecializate pentru a efectua aceste teste.Exist ă companii cum ar fi
7safe(http://7safe.com), ICSA Labs(http://icsalabs.com) sau NSS Labs(http://nsslabs.com)
care verifica IDPS-uri de la diferi ți vendori,testeaz ă în condiții reale pentru îndeplinirea a
celor declarate în fi șa tehnică a echipamentului, dac ă fac față la diferite atacuri, tehnici de
evaziune, etc. Din p ăcate rapoartele de actualitate nu sunt gratis, ele necesitând investi ții mari.
Cele vechi sunt gratis dar nu sunt inutile, ele furnizând detalii pre țioase înceea ce prive ște un
anumit brand sau tip de echipament. Dac ă un anumit echipament ce acum 2 ani a fost
considerat foarte bun, probabil c ă și ultima versiune va tinde spre acel nivel.
NSS Labs este una dintre cele mai cunoscute companii care efectueaz ă teste și dă
certificăridacă un produs corespunde cu cerin țele exigente ale acestora. Un appliance poate s ă
obțină una din cele trei certific ări: NSS Gold, NSS Approved și NSS Tested. Astfel o tr ăsătură
de luat în considerare în decizia achizi ționării unui IDPS ar fi certific ările echipamentului.
Dacă acesta are certific ări de la firme specializate, de încredere atunci putem fi siguri c ă acel
dispozitiv este unul performant și de încredere.
6.4 Jucătorii importan ți de pe pia ța.
Cisco, Juniper, Sourcefire, Fortinet, McAfee sunt doar o parte din juc ătorii importan ți
de pepiața IDPS-urilor.
Aceștia crează appliance-uri profesionale, robuste, performante pentru companii de
toatemărimile. Toate produsele lor și nu numai arat ă extrem de bine pe hârtie dar problema
constă încapacitatea lor de a opri atacuri în condi ții reale. Pentru clarificare, ori sunt testate
individual ori se apeleaz ă la firmespecializate de testare.
Juniper IDP 800, Juniper IDP 200, Cisco IPS 4200 series, Cisco ASA 5500 series,
Mcafee M-8000,Fortinet Fortigate series, Sourcefire 3D sunt doar câteva din appliance-urile
care au certificarea NSSApproved, semn de recunoa ștere al calit ății și eficienței.
Mcafee M-8000 a fost primul IDPS de 10Gb care a primit certificarea NSS Approved.
Acesta atrecut cu brio toate testele NSS Labs. S-au încercat 622 de exploat ări dintr-o gam ă
diversificat ă dedomenii, de la sisteme de operare pân ă la aplicații, fiind blocate 618(99.4%), o
rată mai mult decât excelent ă. Au fost încercate și 214 exploat ări server-client, extrem de greu
de detectat din cauza faptului c ă sunt atipice, iar clientul trebuie s ă inițializeze sesiunea, dar și
în acest caz s-a comportat peste a șteptări, blocând 211 dintre ele(98.6%).
54Multe IDPS-uri știu să blocheze foarte multe atacuri datorit ă definițiilor ușor de scris o
data ceatacul devine cunoscut, iar atacatorii încearc ăun arsenal întreg de tehnici de evaziune
pentru că exploatările vechi s ă meargă în continuare. Cele mai cunoscute tehnici de evaziune
sunt fragmentareapachetelor în buc ăți cât mai mici, trimiterea lor în ordine aleatoare în
speranța căIDPS-ul nu va fi în stare s ă reconstruiasc ă pachetul, folosirea de encoding-uri
diferite în speran ța căacesta nu va ști să le descifreze, etc. M-8000 s-a descurcat excelent
neputând fi p ăcalit prin nici o tehnic ă cunoscut ă.
SourceFire este unul din juc ătorii importan ți de pe pia ță, iar appliance-urile lor
folosesc cel maipopular software IDPS opensource din lume, SNORT. Appliance-urile
SourceFire, c ă și alte appliance-urihardware ale altor vendori, sunt echipamente hardware
robuste și fiabile, cu surse redundante, harddisk- uri raid și alte facilita ți ce fac appliance-urile
rezistente la diferite probleme. Software-ul folositeste desigur Snort-ul, cu regulile și
definițiile oficiale. Solu ția de la SourceFire este un pic mai complex ă decât un simplu
echipamentcu Snort instalat. Unul din cele mai importante lucruri este consola de
management numit ă Sourcefire Defense Center (DC) sau Sourcefire Virtual Defense Center,
unde se pot seta și coordona celelalte IDPS-uri de la SourceFire. Pe aceast ă consola se pot
vedea evenimentele în timp real , tuna defini ții și trimite c ătresenzori, etc . Toate IDPS-uri de
la SourceFire sunt certificate de c ătre NSS ( Tested) și ICSA Labs fapt ce atest ă calitatea și
eficiența acestor IDPS-uri.
557. SNORT
7.1 Privire de ansamblu
SNORT este cel mai cunoscut și folosit IDS/IPS OpenSource. A fost create de c ătre
Martin Roesch în 1998. În prezent, este dezvoltat și comercializat de c ătre compania
SourceFire.Acesta poate fi instalat și folosit gratuit, dar pentru acces imediat la regulile
certificate este necesar ă o plată anuală. Totuși, semnăturile oficiale noi se pot downloada
gratis dup ă 30 de zile de la lansare, ceea ce pentru aplica țiile necritice este rezonabil. Exist ă și
semnături neoficiale, dezvoltate de comunitate, având la baz ă semnăturile oficiale ale Snort-
ului la care s-au ad ăugat mici îmbunat ățiri, tweak-uri sau chiar semn ături și idei trimise de
către utilizatori. Cel mai cunoscut set de astfel de semn ături se nume ște „Bleeding Snort”.
De asemenea exist ă o multitudine de alte proiecte care au la baza Snort-ul, cum ar fi:
Snort Bait and Switch, proiect scris și administrat de Will Metcalf și care este folosit
pentru a redirecta atacurile c ătre un honeyspot sau decoy network;
Snort ClamAV. Reprezint ă o variant ă de Snort modificat care analizeaz ă traficul
folosind baza de date a antivirusului opensource Clamav. Proiectul este administrat de
Victor Julien.
SNORT este un produs cu tradi ție, cu peste 3 milioane de downloaduri fiind considerat
“IDS – de factor standard”.
Snort nu este foarte greu de utilizat, dar exist ă o mulțime de op țiuni în linie de comand ă
cu care se poate lucra, nefiind întotdeauna evident care dintre ele func ționează bine împreun ă.
Există câteva concepte de baz ă care ar trebui în țelese legate de Snort. Snort poate fi
configurat pentru a rula în mai multe moduri:
Modul sniffer, care citește pur și simplu pachetele de pe re țea și le afișează într-un
flux continuu pe consol ă( ecran);
Modul logger , în care logheaz ă pachetele pe disc;
Modul de detec ția a intruziunilor în re țea( NIDS) al ături de urm ătorul mod, permite
cele mai multe și complexe configur ări, permițând analiza traficului de re țea pentru o
comparare cu seturile de reguli definite de utilizator, îndeplinind mai multe ac țiuni
bazate pe ceea ce se vede;
Modul inline este de fapt modul IPS.
Snort-ul poate activa doar într-unul modurile prezentate mai sus, sau în mai multe
simultan, chiar toate.
567.1.2 Modulul sniffer
La rulare exist ă multiple posibilit ăți de afișare, care pot fi rulate cu ajutorul op țiunilor
din sintaxa aferent ă liniei de comand ă, descrise în tabelul de mai jos:
Opțiune Observații
-v interactiv, afi șarea doar a antetelor TCP/UDP/ICMP
-e Headere nivel leg ături de date
-d Headere aplica ție
-a Afișare frame-uri ARP
-c Afișare date de tip char din payload ( nu le afi șează în
hexa)
-i eth0 Interfața pe care ascult ă
-d Rulare ca daemon
-q Rulare în mod quiet (nu mai afi șează mesajele de
început și summary de la exit)
Tabelul7.1 Op țiuni rulare SNORT ca sniffer
Exemplu de utilizare:
./snort –vd
Astfel instruim Snort-ul pentru afi șarea pachetelor de date împreun ă cu header-urile
aferente.
7.1.3 Modulul logger
Pentru a înregistra pe disc pachetele, trebuie specificat directorul de logare dup ă care
programul va intra automat în acest modul:
./snort –dev –l ./log
Desigur, acest lucru presupune c ă există un director numit log în directorul curent.
Dacă nu, Snort va ie și cu un mesaj de eroare. Când se ruleaz ă în acest mod, este colectat
fiecare pachet ce este v ăzut și pus într-o ierarhie de tip director pe baza adresei IP din pachete.
Dacă este specificat ă doar opțiunea –l, se poate observa c ă Snort utilizeaz ă uneori
adresa endpoint-ului ca nume de director în care vor fi puse pachetele; uneori, se folose ște
adresa gazdei.
Pentru a colecta pachetele ce țin de rețeaua intern ă aceasta trebuie specificat ă:
./snort -dev -l ./log -h 192.168.1.0/24
57Această regulă instruiește programul s ă afișeze headerele specifice nivelului leg ăturii
de date și aplicație, precum și cele TCP / IP în directorul ./log, iar pachetele logate s ă fie
specifice clasei C de IP-uri 192.168.1.0. Toate pachetele ce vor veni vor fi logate în
subdirectoare în directorul specificat ce vor avea ca nume adresele remote( non-
192.168.1.0)10.
În cazul unei re țele de mare vitez ă sau pentru o logare a pachetelor mai compact ă
pentru o analiz ă ulterioară, este de luat în considerare logarea în mod binar. Acest mod
loghează pachetele într-un format tcpdump într-un singur fi șier în directorul de logare:
./snort -l ./log –b
Se obervă schimbările ce intervin aici. Nu trebuie specificat ă o rețea deoarece modul
binar concentreaz ă într-un singur fi șier, ceea ce elimin ă necesitatea de a îi spune cum s ă
formateze structura directorulului de ie șire. În plus, nu este nevoie de rularea interactiv ă sau
de specificarea op țiunilor -dsau –e, deoarece în modul binar întregul pachet este logat, nu
doar secțiuni din el. Tot ceea ce este de f ăcut pentru a plasa Snort în modul logger este
specificarea directorului de logare .
După ce pachetele au fost logate în binar, acestea pot fi citite cu orice sniffer care
suportă formatul binar tcpdump (ex: tcpdump sau ethereal). Snort poate citi, de asemenea,
pachetele prin specificarea op țiunii –r.
Pachetele logate pot fi manipulate în nenum ărate moduri prin rularea în modul logger
sau NIDS a Snort-ului în conjunc ție cu interfa ță BPF, ce este disponibil ăîn linie de comand ă.
De exemplu, dac ă se vrea doar vizualizarea pachetelelor ICMP din fi șierul de log, specifica ți
pur și simplu un filtru BPF în linie de comand ă:
./snort -dvr packet.log icmp
7.1.4 Modulul NIDS
Un exemplu prin care se activeaz ă acest mod pentru a nu înregistra fiecare pachet este:
./snort -dev -l ./log -h 192.168.1.0/24 -c snort.conf
unde snort.conf este numele fi șierului de configurare.Astfel vor fi aplicate regulile configurate
aici pe fiecare pachet pentru a se decide dac ă este necesar ă acționarea în vreun fel bazându-se
pe seturile de reguli din fi șier.Dacă nu este specificat nici un director de ie șire, cel default este
/var/log/snort.
O obervație ce trebuie men ționată este legat ă de modul interactiv în acest caz.Pentru o
funcționare îndelungat ă, este de evitat activarea acestei op țiuni din ra țiuni de vitez ă.Ecranul
este un mijloc încet de scriere a datelor, iar pachetele pot fi dropate pân ă sunt afișate pe ecran.
De asemenea nu este necesar ă înregistrarea header-elor speficice leg ăturii de date,
astfel se poate omite op țiunea – e:
10În cazul în care sursa și destinația sunt din re țeaua intern ă, acestea sunt logate într-un director a c ărui
nume este alc ătuit din num ărul mai mare de port implicat, iar în cazul unei egalit ăți, de adresa surs ă.
58./snort -d -h 192.168.1.0/24 -l ./log -c snort.conf
Astfel se configur ă Snort-ul pentru a rula în modul de baz ă NIDS, logând pachetele ce
se supun regulilor specificate în snort.conf folosind caractere ASCII sub o structur ă ierarhică
a directorului.
7.1.4.1 Op țiuni de output
Există mai multe moduri disponibile de a configura ie șirea Snort-ului în modul NIDS.
Logarea pachetelor și a alertelor este realizat ă în mod implicit prin caractere ASCII și sunt
logate în mod full .Mecanismul de alert ă fullafișează mesajul de alert ă împreună cu headerul
pachetelor. Exist ă mai multe alte moduri de ie șire a alertelor disponibile în linia de comand ă,
precum șidouă facilități de logare.
Modurile de alert ă sunt ceva mai complexe. Exist ă șapte moduri de alerte disponibile
în linia de comand ă: complet (full), rapid, prin socket-uri, consol ă, syslog, cmg sau de nici un
fel. Șase din aceste moduri sunt accesate cu op țiunea –Aîn linie de comand ă. Aceste
opțiuni sunt:
Opțiune Observații
-A fast Modul rapid.Se scrie alerta întru-un format simplu
alcătuit din timestamp, mesajul de alert ă, IP-uril și
porturile surs ă și destinație
-A full Modul complet.Este modul implicit folosit în cazul în
care nu este specificat nimic.
-A unsock Sunt trimise alerte c ătre un socket de Unix la care
poate asculta alt program
-A none Sunt oprite alertele.
-A console Alertele de tip “fast-style” sunt trimise c ătre consol ă(
ecran).
-A cmg Sunt generate alerte de tip “cmg style”
Tabelul7.2 – Modurile de alert ă accesate cu op țiunea -A
7.1.4.2 În țelegerea standardului ie șirii
Când Snort genereaz ă un mesaj de alert ă, acesta va ar ăta în felul urm ător:
[**] [116:56:1] (snort_decoder): T/TCP Detected [**]
Primul num ăr reprezint ă GID-ul( Generator ID); specific ă user-ului ce component ă a
generat alerta. Pentru o list ă a acestor valori se poate consulta fi șierul etc/generators din sursa
Snort. În acest caz evenimentul a fost generat de component decode(116).
59Al doilea num ăr este ID-ul Snort( uneori referit ca ID-ul semn ăturii).Pentru o list ă a
SID-urilor de preprocesare se poate vizualiza fi șierul etc/gen-msg.map. SID-urile regulilor
sunt scrise împreun ă cu regulile. În acest caz 56 reprezint ă un eveniment de tip T / TCP.
Al treilea num ăr este num ărul de revizie.Acest num ăr este în principiu folosit la
scrierea semn ăturilor, la fiecare modificare a regulii acest num ăr ar trebui incrementat.
7.1.4.3 Schimbarea ordinii alertelor
Modul implicit pe care Snort îl folose ște în aplicarea regulilor pe pachete poate nu fi
propice pentru orice instalare. Regulile de pass sunt aplicate primele, apoi cele de drop,
urmate de regulile de alert ă, și în ultimul rând regulile de log.
Sunt disponibile mai multe op țiuni ce permit ordinea de ac țiune a unei reguli:
–alert-before-pass; forțează aplicarea regulilor de alert ă în primul rând
–treat-drop-as-alert; cauzează logarea ca alerte a ac țiunilor de drop și reject, precum
și alte alerte associate.Se permite astfel utilizarea unei politici inline în modul pasiv /
IDS. Regulile sdrop nu sunt înc ărcate.
–process-all-event; instruiește Snort-ul s ă proceseze fiecare eveniment asociat unui
pachet, întreprinzând ac țiunile pe baza ordinii stabilite.F ără specificarea acestei
opțiuni (caz implicit), doar evenimentele asociate primei ac țiuni din ordinea stabilit ă
sunt procesate.
7.1.5 Modulul Inline
Începând cu versiunea 2.3.0 Snort a înglobat oficial un IPS numit SNORT inline.
SNORT inline ob ține pachetele de la iptables în loc de libpcap, iar apoi pachetele prinse cu
regulile lui SNORT sunt retransmise lui iptables pentru DROP (dropare + logare), REJECT
(dropare + logare + anun țare sursă) sau SDROP (dropare f ără logare) sau PASS.
Pentru putea folosi SNORT_inline trebuie recompilat iptables, iar SNORT trebuie
compilat cu op țiunea –enable-inline. Recompilarea iptables presupune recompilarea
kernelului Linux.
Pentru a rula sub acest mod se speficic ă opțiunea –Qîn momentul lans ării în execu ție a
programului.
7.2 Configurare
7.2.1 Include
Cuvântul cheie include permite ca alte fi șiere de configurare s ă fie incluse în snort.conf
indicat în linie de comand ă. Acesta func ționează într-un mod asem ănător ca cel din limbajul
60de programare C( #include ); citește conținutul fișierului numit și îl adaugă în locul în care
declarația apare în fi șier.
include <include file path/name>
7.2.2 Variabile
Trei tipuri de variabile pot fi reg ăsite în Snort:
var
portvar
ipvar11
Următoarele declara ții reprezint ă exemple de folosire a acestor tipuri:
var RULES_PATH rules/
portvar MY_PORTS [22,80,1024:1050]
ipvar MY_NET [192.168.1.0/24,10.1.1.0/24]
alert tcp any any -> $MY_NET $MY_PORTS (flags:S; msg:"SYN
packet";)
include $RULE_PATH/example.rule
7.2.2.1 Variabile IP. Liste IP
IP-urile pot fi specificate individual, într-o lista, sub forma unui bloc CIDR sau sub
orice combina ție între acestea trei. Dac ă suportul IPv6 este activ, variabilele IP ar trebui
specificate folosind ipvar în locul tipului var.Folosirea lui varpentru variabile IP este înc ă
permisă pentru compatibilitate, dar în viitor nu va mai fi suportat ă.
IP-urile individuale, listele de IP și blocurile CIDR pot fi negate cu ‘!’.
Următorul exemplu va include IP-ul 1.1.1.1 și pe cele de la 2.2.2.0 pân ă la 2.2.2.255,
cu excepția 2.2.2.2 și 2.2.2.3.
[1.1.1.1,2.2.2.0/24, ![2.2.2.2,2.2.2.3]
Ordinea elementelor listei nu conteaz ă. Elementul anypoate fi folosit pentru a include
orice IP; expresia “!any” nu este permis ă.De asemenea, intervalele IP negate ce sunt mai
generale decât intervale IP ce nu sunt negate, nu sunt permise.
Următoarele constituie ni ște interval valide de variabile și liste IP:
ipvar EXAMPLE [1.1.1.1,2.2.2.0/24,![2.2.2.2,2.2.2.3]]
alert tcp $EXAMPLE any -> any any (msg:"Example"; sid:1;)
alert tcp [1.0.0.0/8,!1.1.1.0/24] any -> any any
(msg:"Example";sid:2;)
11Acest tip de variabil ă este folosit ă pentru support IPv6.
61Exemplele ce urmeaz ă redau niște utilizări 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;)
contradicții logice:
ipvar EXAMPLE [1.1.1.1,!1.1.1.1]
negații fără sens:
ipvar EXAMPLE [1.1.1.0/24,!1.1.0.0/16]
7.2.2.2 Variabile port. Liste de porturi
Este suportat ă reprezentarea porturilor sub forma unor intervale.Variabilele,
intervalele sau listele pot fi toate negate cu “!”. De asemnea, prin “any” este specificat orice
port. Nici aici nu este permis ă declarația “!any”.Intervalul valid de porturi este de la 0 la
65535.
Listele de porturi trebuie închise între paranteze p ătrate, iar intervalele trebuie
specificate cu “:” ca în exemplul urm ător:
[10:50, 888:900]
Variabilele de tip port ar trebui specificate folosind portvar. Utilizarea lui var pentru
porturi nu va mai fi suportat ă pe viitor. Dar pentru compatibilitate, poate fi folosit ă doar cu
condiția de a ad ăuga la începutul numelui “PORT_” sau la sfâr șit “_PORT”.
Următorul exemplu ilustreaz ă utilizările valide a ambelor variante:
portvar EXAMPLE1 80
var EXAMPLE2_PORT [80:90]
var PORT_EXAMPLE2 [1]
portvar EXAMPLE3 any
portvar EXAMPLE4 [!70:90]
portvar EXAMPLE5 [80,91:95,100:200]
alert tcp any $EXAMPLE1 -> any $EXAMPLE2_PORT
(msg:"Example"; sid:1;)
alert tcp any $PORT_EXAMPLE2 -> any any
(msg:"Example"; sid:2;)
alert tcp any 90 -> any [100:1000,9999:20000]
(msg:"Example"; sid:3;)
62Utilizări greșite sunt urm ărtoarele:
utilizarea lui “!any”:
portvar EXAMPLE5 !any
var EXAMPLE5 !any
contradicții logice:
portvar EXAMPLE6 [80,!80]
porturi în afara intervalului permis:
portvar EXAMPLE7 [65536]
declararea incorect ă și utilizarea acesteia ca port:
var EXAMPLE8 80
alert tcp any $EXAMPLE8 -> any any (msg:"Example"; sid:4;)
variabilă port utilizat ă ca IP:
alert tcp $EXAMPLE1 any -> any any (msg:"Example"; sid:5;)
7.2.2.3 Modificatori de variabile
Variabilele prin numele lor pot fi modificate în mai multe feluri. Se poate define o
meta-variabil ă prin operatoru “$”.Acesta poate fi folosit împreuna cu operatori “?” și “-“, așa
cum este descris în tabelul urm ător:
Sintaxa variabilei Descriere
var Se define ște o meta-variabil ă
$(var) sau $var Se înlocuie ște cu conținutul variabilei var
$(var:-default) Se înlocuie ște conținutul variabilei var cu “default” dac ă aceasta este nedefinit ă
$(var:?message) Se înlocuieste cu con ținutul variabilei sau se afi șează un mesaj de eroare și se
iese
Tabelul 7.3 – Modificatori de variabile
7.3 Preprocesoarele
63Preprocesoarele au fost introduse în versiunea 1.5. Acestea permit func ționalități
extinse. Codul acestora este rulat înainte ca motorul de detec ție să-și intre în rol, dar dup ă ce
pachetul a fost decodat. Pachetul poate fi modificat sau analizat folosind mecanismele
implementate. Preprocesoarele sunt înc ărcate și configurate folosind cuvântul cheie
preprocessor . Acesta se folose ște astfel:
<name> Preprocessor: <Op țiuni>
Sunt disponibile spre activare și configurare mai multe tipuri de preprocesoare, în
funcție de problemele pe care le trateaz ă:
deframentarea IP : frag3;
reasamblarea TCP : stream5;
normalizarea pachetelor;
date sensibile;
specifice unor diverse protocoale: http, smtp, ftp, ssh ,pop, etc;
atacurile de recuno ștere: sfPortscan.
7.3.1 Frag3
Preprocesorul frag3 este un modul de defragmentare IP de tip target-based. Este folosit
pentru urm ătoarele scopuri:
o execuție cât mai rapid ă fără un management complex al datelor;
modelarea target-based a tehnicilor anti-evaziune.
Frag3 folose ște structurile date de tip sfxhashși liste înlănțuite pentru managementul intern
al datelor, lucru ce permite atingerea unor performan țe predictibile și deterministice în orice
mediu, lucru ce ajut ă la gestionarea mediilor fragmentate.
Analiza target-based este un concept relativ nou în detectare la nivel re țea a intruziunilor.
Ideea de baz ă este aceea de a modela obiectivele actuale ale re țelei în locul model ării doar a
protocoalelor și căutării de atacuri în cadrul acestora. Când stivele IP sunt scrise pentru
diferite sisteme de operare, acestea sunt de obicei implementate de c ătre persoane care citesc
RFC-uri care apoi scriu propria interpretare a ceea ce RFC-ul prezint ă în cod. Din p ăcate,
există ambiguit ăți în defini țiile date de RFC-uri pentru unele din condi țiile de margine ce pot
să apară, iar când acest lucru se întâmpl ă diferite persoane pun în aplicare anumite aspecte ale
stivei IP proprii într-un mod diferit. Pentru un IDS aceasta este o problem ă mare.
Într-un mediu în care atacatorul poate determina ce stil de defragmentare IP este
utilizat de o anumit ă țintă, atacatorul poate încerca s ă fragmenteze pachetele în a șa fel încât
ținta le va pune împreun ă într-o anumit ă manieră pe care sistemele pasive ce încearc ă să
modeleze traficulgazd ă trebuie să ghicească în ce fel respectiva gazd ă se va ocup ă de
suprapuneri și cum le va retransmite. În cazul în care atacatorul are mai multe informa ții
despre host-urile țintă decât IDS, este posibil s ă treacă de controalele acestuia.De aici a pornit
idea acestui tip de analiz ă.
647.3.2 sfPortscan
Acest modul dezvoltat de Sourcefire, este conceput pentru a detecta prima faz ă a unui
atac asupra unei re țele: recunoa șterea.În acest ă fază, un atacator determin ă ce tipuri de
protocoale sau servicii sunt folosite de un anumit host. Acesta este momentul tradi țional în
care are loc o scanare a porturilor. Aceast ă fază presupune c ă atacatorul nu are nici o
informație legată de protocoalele sau serviciile suportate de c ătre țintă, în caz contrar, aceast ă
etapă nu ar mai fi necesar ă. Din cauza acestui fapt, cele mai multe cereri trimise de c ătre
atacator vor fi negative(ceea ce înseamn ă că porturile sunt închise). În natura unor re țele de
comunica ții legitime, r ăspunsurile negative din partea host-urilor sunt rare, dar și mai rare
sunt apari țiile multiple ale acestora într-un interval scurt de timp. Obiectivul principal al
acestei detec ții este de a detecta și urmări aceste r ăspunsuri negative.
7.3.3 HTTP Inspect
HTTP Inspect este un decodor generic http pentru aplica țiile utilizatorului. Având un
buffer de date, acesta va decoda acest buffer, va g ăsi câmpurile http pe care apoi le va
normaliza. Inspecteaz ă atât cererile client, cât și răspunsurile server.
Versiunea actual ă are în vedere doar prelucrarea f ără stări. Acest lucru înseamn ă că
inspectarea se face pachet cu pachet, existând posibilitatea unei în șelări în cazul în care
pachetele nu sunt reasamblate. Aceasta func ționează bine atunci când exist ă un alt modul ce
se ocupă cu reasamblarea, dar exist ă limitări în analiza protocolului. Versiunile viitoare vor
aveaun modul de procesare de tip stateful.
Acest modul permite utilizatorului o configura ție variată. Utilizatorii pot configura
serverele http individuale cu o varietate deop țiuni, lucru care ar trebui s ă permită utilizatorului
emularea oric ărui tip de server de web. Exist ă două zone deconfigurare: global și server.
7.3.4 Preprocesorul de date sensibile
Reprezint ă un modul Snort ce realizeaz ă detecția și filtrarea datelor de tip PII(
Personally Identifiable Information). Acest date includ numere de carduri de credit, coduri
numerice personale și adrese de email.Este disponibil ă o sintaxă de expresii regulate care
permit definirea unor pattern-uri proprii.
Dependin țe
Preprocesorul Stream5 trebuie s ă fie activat pentru ca acest modul s ă funcționeze.
Configura ție
Configura ția acestui modul este împ ărțită în două: configurarea preprocesorului și
regulile.
Configurarea modului începe cu:
preprocessor sensitive_data:
65Opțiune Argument Necesar Implicit Explicații
alert_threshold < număr> Nu Alert_threshold 25 Preprocesorul va alerta orice combina ție
PII detectat ă într-o sesiune.Op țiunea
specifică câte trebuie detectate înainte
de alertare.Ar trebui setat ă o valoare
mai mare decât cea mai mare valorea
individual ă din regulile “sd_pattern”
mask_output – Nu Inactiv Acestă opțiune înlocuie ște toți digiții în
afară de ultimii 4 cu “X”.Acestu lucru
este realizat doar asupra numerelor de
card de credit, pentru a preveni
vizualizarea numerelor necriptate
ssn_file <nume de fi șier> nu Inactiv Modulul poate fi updatat cu noi valori
de SSN-uri prin furnizarea unui fi șier de
tip CSV.În mod implicit Snort-ul
recunoaște toate SSN-urile emise pân ă
în noiembrie 2009.
Tabelul 7.4 – Op țiunile pentru configurarea preprocesorului de date sensibile
Exemplu:
preprocessor sensitive_data: alert_threshold 25 \
mask_output \
ssn_file ssn_groups_Jan10.csv
Configurarea regulilor
Regulile sunt utilizate pentru a specifica ce tip de date( PII) trebuie c ăutat de către
preprocesor. O nou ă opțiune este disponibil ă o data cu introducerea acestui modul:
sd_pattern.
Această opțiune specific ă ce tip de date trebuie detectat.
Este utilizat ă următoarea sintax ă:
sd_pattern:<count>, <pattern>;
count = 1 – 255
pattern = any string
Opțiune Explicație
count Specifică de câte ori un pattern trebuie s ă regăsit pentru a se genera o alert ă.Numărul este
urmărit în toate pachetele dintr-o sesiune
patterncredit_card Face match pe numere de card de credit de 15-16 digi ți.Aceste numere
pot avea spa ții, puncte sau nimic între grupuri de digi ți.Astfel sunt
acoperite tipurile de carduri Visa, MasterCard, Discover și American
Express.Numerele reg ăsite sunt verificate folosind algoritmul Luhn.
66us_social Este specific numerelor sociale de securitate americane de 9 digi ți
us_social_nodashes Pattern folosit pentru SSN-uri ce nu au delimitatori( ex: punct).
email Folosit pentru email-uri.
Tabelul 7.5 – Op țiunile pentru configurarea sd_pattern
Dacă se dorește folosirea unui alt pattern decât cele preconstruite, se poate defini unul
propriu folosind o sintax ă regex disponibil ă, dar destul de limitat ă.Sunt suportate urm ătoarele
caractere și secvențe:
Caracter/Secven ță Utilizare
\d potrivire pe orice digit
\D potrivire pe orice non-digit
\l potrivire pe orice liter ă
\L potrivire pe orice character non-liter ă
\w potrivire pe orice caracter alfanumeric
\W potrivire pe orice caracter non-alfanumeric
{ num } repetarea unui character sau secven țe de un num ăr de ori.
? marcarea ca op țional a caracterului sau secven ței anterioare
\\ potrivire pe semnul “\”
\{, \} potrivire pe semnele “{“ , “}”
\? potivire pe semnul “?”
Tabelul 7.6 – Sintaxa regex suportat ă
Orice alt carater folosit în patern va fi tratat ad literarum.
Exemplu de de regul ă:
alert tcp $HOME_NET $HIGH_PORTS -> $EXTERNAL_NET $SMTP_PORTS
(msg:"Credit Card numbers sent over email"; gid:138; sid:1000;
rev:1; sd_pattern:4,credit_card; metadata:service smtp;)
Opțiunea sd_pattern nu este compatibil ă cu alte op țiuni specifice compozi ției unei
reguli. Utilizarea acesteia împreun ă cu alte op țiuni va duce la apari ția unui mesaj de eroare.
Regulile ce folosesc aceast ă opțiune trebuie s ă seteze valoarea GID-ului la 138.
7.4 Semn ături / Reguli
Semnăturile reprezint ă o parte esen țială a Snort-ului. F ără acestea detec ția nu ar mai fi
posibilă. Acestea reprezint ă, în mare parte, sample-uri de trafic mali țios care de îndat ă ce este
identificat, va duce la producereaunei alerte sau întreprinderea unei anume ac țiuni. Aceste
reguli se gãsesc pe site-ul oficial al Snort-ului. Cele mai actuale definitii nu sunt gratis, dar
sunt distribuite gratis la o lun ă de la lansare. Exist ă șisemnãturi neoficiale, dezvoltate de
comunitate, având la baza semnãturile oficiale ale Snort-ului la care s-au adãugat mici
îmbunătățiri.
67Exista o mare diferen ță de abordare între semn ăturile realizate pentru Snort și
semnăturilealtor IDPS-uri concurente. SourceFire încearcã s ă înțeleagã vulnerabilit ățile pentru
care apoi s ă scrie semn ătura pentru aceasta, nu pentru exploatarea în sine. Astfel dacã sunt
create mai multe variante de exploat ări pentru aceia și vulnerabilitate, Snort-ul va fi capabil s ă
le blocheze pe toate. Cel mai bunexemplu este viermele Conficker. Acesta a apãrut în21
Noiembrie 2008, la 2 luni dupã ce Microsoft a anun țat vulnerabilitatea MS08-067( remote
codeexecution). Prima variant ă a virusului putea fi detectat ă de Snort cu defini țiile din 2006
datorită asemănării cu o vulnerabilitate de atunci cu cea exploatat ă de Conficker:
August 7, 2006: Microsoft a lansat un buletin de securitate MS06-040 în legãtura cu o
vulnerabilitate remote code execution g ăsită în Microsoft Windows Server Service;
August 9, 2006: Sourcefire a lansat reguli care s ă protejeze împotriva a toate
exploatărilor vulnerabilit ății MS06-040;
Octombrie 23, 2008: Microsoft a lansat un buletin de securitate MS08-067 în leg ătura
cu o vulnerabilitate remote code execution (similar ă to MS06-040) în Microsoft
Windows Server Service;
Octombrie 23, 2008: Sourcefire a lansat un set de reguli care s ă protejeze împotriva a
tuturo exploat ărilorvulnerabilit ății MS08-067;
Noiembrie 21, 2008: Viermele Conficker.A este identificat. Regulile Sourcefire
publicate atât în August 9, 2006 cât și în Octombrie 23, 2008 sunt activate de
Conficker.A din cauza similarit ății celor 2 vulnerabilit ăți;
Noiembrie 29, 2008: Viermele Conficker.B este identificat. Aceasta variant ă este
corect identificat ă de semnăturile Snort ini țiale.
Martie 4, 2009: Viermele Conficker.C este identificat. Aceasta variant ă este corect
identificat ă de semnăturile Snort ini țiale.
În concluzie abordarea scrierii de defini ții pentru vulnerabilitatea în sine și nu a exploat ării
este mult mai eficient ă și asigură protecție pentru alte eventuale exploat ări ale acelea și
vulnerabilit ăți.
Un alt exemplu în care este eviden țiată abordarea orientat ă pe vulnerabilitate a
semnãturiloroficiale este modul cum a fost abordat ă vulnerabilitatea ap ăruta în comunicarea
RPC cãtre serverul debaze de date ToolTalk. Aceast ă vulnerabilitate a ap ărut în sistemele de
operare de la HP, IBM, SCO Group, SGI și Sun și permitea unui atacator remote s ă execute
cod cu drepturi de super user.
SourceFire a identificat câmpurile vulnerabile din protocolul RPC, care era
vulnerabilitatea și în ce condi ții se manifesta, apoi a scris o semn ătura pentru acest lucru. În
continuare este descris acestproces:
68Analiza pachetului RPC al unei exploat ări ce încearcã s ă speculeze vulnerabilitatea în
cauză
Identificarea Protocolului
Octeții 8 – 11 indic ă un RPC call, astfe avem o cãutare dup ă conținutul “00 00
00 00” pentru acei octe ți:
content:”|00 00 00 00|”; offset:8; depth:4;
Octeții 12 -15 indic ă folosirea versiunii 2 a RPC:
content:”|00 00 00 02|”; offset:12; depth:4;
Octeții 16 – 19 indic ă numărul programului RPC. Cel în cauza este “00 01 86
F3”, astfel ne putem duce la acea pozi ție și căuta apariția acestui program:
content:”|00 01 86 F3|”; offset:16; depth:4;
Peste 2 câmpuri, adicã la 4 octe ți de la pozi ția anterioar ă, indică numãrul
procedurii RPC. Este de interes “00 00 00 07”:
content:”|00 00 00 07|”; distance:4; within:4;
Stare comunica ției
Vrem să identificăm doar sesiunile stabilite:
flow:to_server,established;
Figura 7.7 -Exemplu pachet RPC
69Câmpurile relevante
Trebuie c ăutată cantitatea de date de autorizare trimis ă pentru a putea s ări peste
acestea. Este stocat ă într-un câmp de 4 octe ți. Acesta este citit și se sare peste
câte date sunt în câmpul respectiv:
byte_jump:4,4,relative,align;
Următorul câmp ce trebuie ignorat este câmpul de verificare. M ărimea acestuia
este specificat ă ca și în cazul de mai sus într-un c ămp special.Este citit ă
mărimea și se sare peste num ărul de octe ți specificat:
byte_jump:4,4,relative,align;
După acești pași se ajunge în momentul în care se poate vedea câte date sunt
trimise către program.Aceast ă informație se află în primii 4 octe ți, imediat
după sfârșitul câmpului de verificare. Se cite ște dimensiunea datelor
transmise c ătre program, iar dac ă această dimensiune este prea mare, mai
maredecât ar trebui s ă primeasc ă în mod normal programul, poate reprezenta
o posibilă încercare de overflow. În acest caz se verific ă dacă sunt transmi și
mai mult de 128 de octe ți; în cazul c ă da este generat ă o alertă.
byte_test:4,>,128,0,relative;
În concluzie, o regul ă ce previne orice exploatare a vulnerabilit ății CVE-1999-0003 în
cazul ToolTalk, arat ă în felul urm ător:
alert tcp $EXTERNAL_NET any -> $HOME_NET any \
(msg:”RPC tooltalk TCP overflow attempt”; \
flow:to_server,established; \
content:”|00 00 00 02|”; depth:4; offset:12;\
content:”|00 01 86 F3|”; depth:4; offset:16; \
content:”|00 00 00 07|”; within:4; distance:4; \
byte_jump:4,4,relative,align; \
byte_jump:4,4,relative,align; \
byte_test:4,>,128,0,relative; \
content:”|00 00 00 00|”; depth:4; offset:8; \
reference:bugtraq,122; \
reference:cve,1999-0003; \
classtype:misc-attack; sid:1965; rev:8;)
707.4.1 Scriererea Regulilor
Regulile sunt împ ărțite în dou ă secțiuni logice:
1. Antetul : specific ă acțiunea, protocolul, adresele IP și măștile aferente surs ă și
destinație, precum și porturile surs ă și destinație;
2.Opțiunile: specifică mesajul de alert ă precum și alte informa ții legate de p ărțile
pachetului ce ar trebui inspectate pentru a determina dac ă trebuie întreprins ăacțiunea
precizată.
7.4.2 Antetul unei reguli
Acțiunea regulii
Este indicat astfel Snort-ului ce trebuie s ă facă în eventualitatea unui pachet ce
îndeplinește condițiile impuse. Exist ă 5 acțiuni implicate definite:alertare, logare, permitere,
activare și intrarea în modul dinamic.În plus, dac ă este rulat în mod inline, sunt disponibile
alte 3 tipuri:dropare, respingere și blocare f ără log.
Nume Acțiunea realizat ă
alert generarea unei alerte folosind metoda de alertare selectat ă, urmată de o
logare a pachetului
log logarea pachetului
pass ignorarea pachetului
activate alertare și activarea unei alte regule dinamice
dynamic inactivă până la activarea de c ătre regula mai sus men ționtă, comportându-se
apoi ca o regul ă de logare
reject blocarea și logarea pachetului, urmate de trimiterea unui pachet de reset în
cazul protocolului TCP, sau a unui de top port ICMP inaccesibil în cazul UDP
drop blocarea și logarea pachetului
sdrop blocare fără logare a pachetului
Tabelul 7.8 – Tipurile de ac țiuni posibile
Pot fi definie tipuri de reguli proprii c ărora li se poate asocia unul sau mai multe tipuri
de ieșire.Pot fi utilizare ac țiunile prezentate mai sus.
Următorul exemplu creaz ă un tip ce va realiza doar o logare de tip tcpdump:
ruletype suspicious
{
type log
output log_tcpdump: suspicious.log
}
71Protocoale
Există patru protocoale pe care Snort-ul le analizeaz ă pentru comportament suspicios:
TCP
UDP
ICMP
IP
Pe viitor se urm ărește și implementarea altora: ARP, IGRP, GRE, OSPF, RIP, IPX, etc.
Adresele IP
Snort-ul nu are nici un mecanism de c ăutare a host-urilor dup ă adrese IP în fi șierul de
configurare. Le reg ăsim în antetul regulilor. Sunt formate dintr-o adres ă numeric de tip IP și
un bloc CIDR ce indic ă masca de re țea ce trebuie folosit ă în cazul inspect ării pachetelor.Pot fi
specificate și sub forma unei liste sau folosind operatorul “any” pentru a defini orice adres ă .
Porturile
Numerele de port pot fi specificate în mai multe moduri, prin “any”, defini ții statice
sau intervale, folosind orice valoare dorit ă din intervalul 0 – 65535.
Operatorul direc ție
Se folosește pentru a identifica direc ția pachetului pe care regula trebuie aplicat ă( IP-ul și
portul surs ă sunt considerate a fi cele din stânga, iar cele destina ție, în dreapta operatorului).
Este folosit sub dou ă forme: ->, unidirec țional( de la surs ă la destina ție) și <>, bidirec țional
când se iau în considerare spre analiz ă perechi de adrese IP și port. Nu poate fi folosit sub
forma <-.
7.4.3. Op țiunile unei reguli
Reprezint ă inima motorului de detec ție a intruziunilor al Snort-ului, coroborat cu
ușurința utilizării, puterea și flexibilitatea acestora.
Toate opțiunile sunt separate una de alta prin “ ; ”.Cuvintele cheie sunt separate de
argument folosind “ : ”.
activate tcp !$HOME_NET any -> $HOME_NET 143 (flags:PA; \
content:"|E8C0FFFFFF|/bin"; activates:1; \
msg:"IMAP buffer overflow!";)
dynamic tcp !$HOME_NET any -> $HOME_NET 143 (activated_by:1;
count:50;)
72În continuare sunt prezentate câteva din op țiunile disponibile:
msg: mesajul salvat în loguri și alerte;
reference: regula include o referin ță externă care detaliaz ă atacul (Exemplu: bugtrack,
cve, nessus etc);
alert tcp any any -> any 21 (msg:"IDS287/ftp-wuftp260-
venglin-linux"; flags:AP; content:"|31c031db 31c9b046 cd80
31c031db|";
reference:arachnids,IDS287;reference:bugtraq,1387;
reference:cve,CAN-2000-1574;)
gid: folosit pentru a identifica ce parte a Snort-ului genereaz ă evenimentul;
sid (signature id): identificator unic pentru regul ă; este obligatoriu. Pentru sid exist ă
următoarele recomand ări:
sid < 100 este rezervat;
100 < sid < 1.000.000 pentru regulile oficiale SourceFire;
sid > 1.000.000 pentru regulile create de user.
rev (revision): identificator pentru num ărul de revizie al regulii;
alert tcp any any -> any 25 (content:”CMA”; sid:1000001;
rev:2;)
classtype : clasifică tipul de atac într-o clas ă generică. Acestea sunt definite în
classification.config ;
alert tcp any any -> any 80 (sid:1000002; msg:”EXPLOIT
ntpdx overflow”; dsize: >128; classtype:attempted-admin;
priority:10 );
flags testează flagurile TCP. Se folose ște: S, F, R, A, P, U, 0(zero – niciun bit setat)
sau combina ții între acestea. Exist ă 3 tipuri de modificatori:
+ testeaz ă biții specifica ți, pot fi și alții în plus;
! testează ca biții specifica ți să nu fie seta ți;
* testează dacă oricare dintre bi ții specifica ți sunt testa ți;
alert tcp any any -> any any (sid: 1000003; msg:”pachet
tcp”; flags:SA+;)
minfrag setează un prag pentru dimensiunea minim ă a unui fragment;
TTL : testează valoarea TTL din headerul IP;
73alert icmp any any -> any any (msg:”PING with TTP
100″;ttl:100; sid: 1000004;)
tos:testează valoarea ToS din headerul IP;
alert icmp any any -> any any (msg:”tos diferit de 1 ″;tos:!1;
sid: 1000005;)
fragbits : testeaza bi ții MoreFragments și Don’t Fragment din headerul IP;
alert icmp any any -> any any (msg:”Pachet cu bi ții more
fragment și don’t fragment seta ți”;fragbits:MD+;sid:
1000006;)
id: testează valoarea ID din headerul IP;
dsize: testează dimensiunea înc ărcăturii pachetului;
Content : caută un pattern în payload-ul pachetului. Caracterele : ; \ “ trebuie precedate
de “\”(backslash);
alert tcp any any -> any 111 (sid:1000007; content: “|00 01 86
a5|”; msg: “external mountd access”;)
nocase: valoarea c ăutată în pachet de ajutorul content este case-insensitive;
offset : setează un offset de la care se începe c ăutarea valorii op țiunii content;
depth: setează o adâncime în pachet pân ă la care se caut ă valoarea op țiunii content;
http_client_body : reprezint ă un modificator pentru op țiunea content care limiteaz ă
căutarea în HTTP Body Client Request; preprocesorul Http Inspect trebuie s ă fie activ;
http_cookie : reprezint ă un modificator pentru op țiunea content care limiteaz ă căutarea
în câmpul HTTP Cookie Header din HTTP Client Request; preprocesorul HttpInspect
trebuie să fie activ;
http_header : reprezint ă un modificator pentru op țiunea content care limiteaz ă
căutarea în Headerul HTTP din Client Request;
seq: testează valoarea Sequence No. din headerul TCP;
ack:testează valoarea Acknowledgment din headerul TCP;
74itype: testează tipul ICMP;
icode: testează codul ICMP.
session: datele utilizatorului sunt extrase din sesiunile TCP și printate în alerte.
log tcp any any <> any 23 (session:printable;sid:1000008;)
resp: activeaz ă un răspuns activ ce închide conexiunile considerate periculoase;
pcre: se folosește pcre (perl compatible regular expression) pentru testarea
conținutului unui pachet.
7.4.4 Pragul unei reguli
Se folosește pentru a reduce mesajele logate de regulile care se activeaz ă extrem de
des. Exist ă 3 categorii de praguri:
limit : alertează pentru primele n evenimente într-un interval de timp. Restul
evenimentelor sunt ignorate pentru o perioad ă de timp;
threshold : alertează la fiecare n evenimente într-o perioad ă de timp;
ambele: alertează o dată în intervalul de timp, dar doar dup ă n evenimente.
Un threshold se poate include într-o regul ă sau se poate defini de sine st ătător referindu-se
la sid-ul regulii.
8. Sistem pentru prevenirea scurgerilor de date
8.1 Snort – sistem de detectare și prevenție a scurgerilor de
date
O bună aplicație a Snort-ului este prevenirea scurgerilor de datedintr-o institu ție.
Snort-ul opre ște traficul în func ție de anumite reguli. Acestea pot fi scrise în func ție
denecesitățile și dorințele fiecăruia. O problem ă majorăo reprezint ă poziționarea IDPS-ului în
cadrul rețelei pentru aoferi o eficien ță maximă. Pentru a preveni și nu doar a detecta scurgerea
de date este de preferabil opozi ționarea inline. Aceasta prezint ă o serie de dezavantaje cum ar
fi imposibilitatea decod ăriiprotocoalelor care transmit datele criptat:ssh, https, imaps, pop3s,
smtps. Oricine poate s ă acceseze orice aplica ție care folose ște protocolul https și să uploadeze
documente f ără ca Snort-ul s ă îl poate detecta.Astfel, pentru o implementare eficient ăși
transparent ă pentru utilizatori a unei solu ții de prevenirea scurgerilor de date nu este de ajuns
un singur echipament dotatcu Snort. În cazul tuturor echipamentelor trebuie blocate toate
porturile inutile, iar accesul la portul 80 și 443 să nuse facă direct, ci printr-un proxy cum ar fi
Squid, etc.
75Avantajele folosirii Snort-ului inline pentru prevenirea scurgerilor de date:
transparen țăfață de utilizatori: ace știa nu știu de existenta Snort-ului în re țea, nefiind
necesare configur ări speciale pe sta ția de lucru;
implementare rapid ă: un singur dispozitiv amplasat în punctul de interes este de ajuns
pentru a acoperi to ți utilizatorii.
Dezavantajele folosirii Snort-ului inline pentru prevenirea scurgerilor de date:
imposibilitate inspect ării protocoalelor ce folosesc criptarea datelor :https, pop3s,
smtps, imaps, ssh vor trece f ără a puteafi inspectate;
întârzieri în re țea: pentru a inspecta traficul, o serie de proces ări au loc, cum ar
fidecodarea și normalizarea protocolului, inspectarea acestuia dup ă semnături, toate
acesteproceduri provocând întârzieri în re țea;
punct sensibil: dac ă echipamentul Snort are probleme și se defecteaz ă, întreg traficul
va fioprit, un lucru nedorit de atlfel de nimeni.
8.2 Iptables
Pentru a implementa Snort-ul inline eficient la nivel de host este nevoie de
configurarea serviciului iptables.
Acesta reprezint ă un serviciu furnizat de firewall-ul din cadrul kernel-ului de Linux.
Permite administratorului de sistem definirea unor tabele ce conțin lanțuri de reguli pentru
tratarea pachetelor de re țea.Fiecare tabel ă este asociat ă unui alt tip de procesare. Pachetele
sunt procesate secven țial, pe măsură ce parcurg lan țurile.O regul ă dintr-un lan ț poate provoca
un salt către alt lan ț, lucru ce se poate repeta în limita nivelului de îmbricare dorit
Ipptables folose ște în mod implicit trei tabele :
1. Filter – este responsabil ăcu filtrarea pachetelor.
Are trei lan țuri predefinite în care se pot declara reguli de politic ăfirewall:
Forward : Filtreaz ă pachete c ătre servere protejate de firewall;
Input : Filtreaz ăpachetele destinate firewall-ului;
Output : Filtreaz ăpachetele expediate de firewall.
2. NAT – este responsabil ăcu translatarea adreselor de re țea.
Figura 8.1 – Snort inline
763. MANGLE – este responsabil ă cu modificarea bi ților QOS din headerul TCP
Are 2 lanțuri predefinite:
Pre-routing: face NAT atunci când adresa destina ție a pachetului trebuie schimbat ă;
Post-routing: face NAT atunci cand adres ă sursă a pachetului trebuie schimbat ă.
Pentru fiecare regul ăfirewall creat ă trebuie specificat ă tabela și lanțul de care va apar ține.
La această regulă este o singur ă exceptie: cele mai multe reguli sunt legate de filtrare, astfel
iptables presupune c ă orice lanț definit fără o tabelă asociatăva face parte din tabela filter .
Tabela filter este, prin urmare, implicit ă.
Fiecare regul ă firewall inspecteaz ă pachetele IP și apoi încearc ă să le identifice ca și ținte
pentru o anumit ă operație.
Cele mai folosite ținte sunt:
ACCEPT: iptables opre ște procesarea ulterioar ă; pachetul este trimis c ătre aplicație
sau sistem de operare pentru prelucrare;
DROP : iptables opre ște procesarea ulterioar ă; pachetul este blocat;
LOG: informa țiile sunt trimise la daemonul syslog pentru logare; iptables continu ă
procesarea pachetului;
REJECT: func ționeazăca DROP, dar va trimite un mesaj de eroare la gazda care a a
trimis pachetul cum c ă pachetul a fost blocat;
QUEUE: pachetele sunt în puse în a șteptare pentru o procesare ulterioar ă de către
modul sau alt ă aplicație externă;
DNAT: Rescrie adresa IP destina ție a pachetului;
SNAT: Rescrie adresa IP sursa a pachetului
MASQUERADE : Folosit pentru SNAT; în mod implicit adresa IP surs ă este aceea și
cu cea utilizat ă de interfa ța firewall-ului
77Figura 8.2 – Func ționare Iptables
78Tabelul 8.3 – Op țiuni configurare Iptables
Configurările necesare pentru ca modulul iptables s ă trasmită toate pachetele spre
procesare c ătre Snort se realizeaz ă în felul urm ător:
iptables -I OUTPUT 1 -p all -j QUEUE
iptables -I INPUT 1 -p all -j QUEUE
Figura 8.4 – Func ționare Iptables & SnortParametru Utilizare
-t <tabel> Dacă nu se specific ă o tabelă, tabela filter este aleas ă în mod implicit
-j <target> Salt la lan țul țintă specificat în momentul pachet se potriveste cu regula actual ă.
-A \ -append adăugarea unei reguli la sfâr șitul regulii
-F Stergea tuturor regulilor din tabela selectat ă
-p <tipul protocolului> Potrivire cu protocoalele: icmp, tcp, udp sau toate(all)
-s <adresă ip> Potrivire cu adresa ip surs ă
-d <adres ă ip> Potrivire cu adresa ip destina ție
-i <nume interfe ță> Potrivire cu interfa ța de rețea prin care intr ă pachetul
-o <nume interfa ță> Potrivire cu interfa ța de rețea prin care iese pachetul
-m –state <stare> Stările pot fi: ESTABLISHED, NEW, RELATED, INVALID
79Prin aceste comenzi sunt introduse câte o regul ă nouă în lanțurile INPUT și OUTPUT
din cadrul tabelei Filter în prima pozi ție, reguli ce instruiesc modulul iptables s ă identifice
toate pachetele, indiferent de protocol, ca ținte QUEUE. Astfel, pachetele sunt dispuse într-o
coadă, de unde sunt preluate de Snort pentru procesare. Dup ă inspectarea lor de c ătre Snort,
acestea le dispune tot într-o coad ă, de unde sunt preluate de c ătre modulul iptables, care, în
funcție de etichetarea realizat ă de Snort( allow / drop /reject) va realiza ac țiunea pertinent ă
pentru fiecare pachet.
Pentru revenirea la func ționarea normal ă a acestui model se dau urm ătoarele comenzi
ce șterg toate regulile din lan țurile selectate( tabela filter):
iptables -F INPUT
iptables -F OUTPUT
Pentru apelarea oric ăror comenzi legate de acest modul sunt necesare drepturi de
administrator.
Lansarea în execu ție
Atât Snort-ul, cât și plugin-ul sunt lansa ți în execu ție de către un script: snorting.sh.
Acesta are trei func ționalități, configurabile prin cele trei op țiuni disponibile:
1. –start. Prin aceast ă opțiune este lansate în execu ție Snort-ul. Pe lâng ă acestea, este
configurat și serviciul Iptables, folosind comenzile prezentate în sec țiunea de mai sus
pentru lucrul cu Snort.
2. –stop. Cu ajutorul acestei op țiuni modulul Iptables este readus la starea normal ă de
funcționare.
3. –print <nr>. Cu ajutorul acestei op țiuni pot fi vizualizate ultimele alerte trimise de
Snort către server-ul Syslog.
808.3 Arhitectura de re țea utilizat ă
Pentru implementarea și testarea Snort-ului și a plugin-ului prezentat în sec țiunile
următoare s-a folosit arhitectura de mai sus.Snort-ul a fost implementat în modul inline, la
nivel de host (PC). Astfel, monitorizeaz ă tot traficul de la și spre host-ul din imagine.Traficul
va trece în mod transparent prin filtru f ără a fi nevoie de configur ări adiționale pe
echipamentele existente în re țea.
Drumul pe care un pachet îl parcuge prin Snort este redat mai jos:
Figura 8.5 – Arhitectura implementat ă
811. Pachetul intr ă în Decoder cu scopul de a identifica tipul de pachet și ce protocoale
sunt folosite f ără însă a decoda și datele la nivel de aplica ție. Pachetele cu
checksum gre șit pot fi oprite;
2. Pachetele fragmentate trebuie asamblate înainte pentru ca regulile viitoare s ă fie
aplicate eficient.Normalizarea pachetelor ajut ă motorul de c ăutare al Snort-ului s ă
verifice pachetul mai rapid;
3. D
u
pă ce au fost decodate, asamblate și normalizate, pachetele ajung la motorul
principal, undesunt verificate dup ă niște reguli;
4. Alertele generate de pachete se duc în pluginul de output pentru a fi furnizate
administratoruluisau aplica țiilor.
8.4. Metode de detec ție și prevenție
În cadrul Snort-ului exist ă două etape în care se poate face preven ția și detecția
scurgerilor date:
1.În faza de preprocesare cu ajutorul preprocesorului specific datelor sensibile
prezentat în sec țiunile anterioare.Avantajul configur ării acestui preprocesor este
reprezentat de faptul c ă se evită trecerea pachetelor ce se potrivesc cu regulile
preprocesorului prin motorul principal de detec ție al Snortului, scâz ăndu-se astfel
timpul de procesare precum și utilizarea resurselor;
2. În cadrul motorului de detec ție;
Detecție în ambele faze se bazeaz ă pe conținut. Diferen ța majoră între acestea este
dată de faptul c ă în cadrul celei de-a dou ă există mult mai multe op țiuni disponibile pentru
configurare și scrierea regulilor. Dup ă cum s-a men ționat și în prezentarea preprocesorului,
opțiunea sd_pattern , punctul central al regulilor specifice acestuia, nu este compatibil ă cu nici
o altă opțiune.
În ambele cazuri, detec ția se realizeaz ă cu ajutorul expresiilor regulate. Pentru regulile
generale, acest lucru se configureaz ă cu ajutorul op țiunii pcre ( perl compatible regular
expressions), o libr ărie de func ții ce implementeaz ă modele de potrivire folosind aceia și
sintaxă și semantic ă utilizată de Perl 5. Sintaxa utilizat ă oferă mai multe capabilit ăți decât cele
oferite de op țiunea sd_pattern.
Date Metodă folosită pentru detec ție Verificare validitate
Sd_pattern12PCRE12Sd_pattern PCRE
CNP Regexp Regexp Da Nu
12SnortFigura 8.6 -Drumul unui pachet prin Snort
82Numere
carduribancareRegexp Regexp Da Nu
Email Regexp Regexp Da Da
Tabelul 8.7 – Detec ția și verificarea datelor sensibile
Date Exemple Regexp
Sd_pattern PCRE
CNP \d{13} /[1-9]{1}[1-9]{2}(0[1-
9]|1[0-2])(0[1-
9]|[12]\d|3[01])(0[1-9]|[1-
4]\d| 5[0-2]|99)\d{4}/
Card bancar( VISA) credit_card13/4\d{3}(\s|-)?\d{4}(\s|-
)?\d{4}(\s|-)?\d{4}/
Email Email2/[a-zA-Z0-9_\.]+@[a-zA-
Z]+\.[a-zA-Z]+/
Tabelul 8.8 – Expresii regulate folosite
8.5.Filtrarea protocolului http și https
Majoritatea scurgerilor de date sunt accidentale și au loc prin intermediul re țelelor de
de socializare sau serviciilor de email gratis. Pentru o securitate sporit ă, accesul la acestea
ar trebuie restric ționat. Blocarea acestora nu este extrem de greu de realizat. Atunci când se
realizează o cerere http, host-ul și URL-ul accesat este trimis de c ătre browser server-ului
printr-o cerere GET.
13Predefinit
Figura 8.9 -Protocolul HTTP
83GET /index.php HTTP/1.1
Host: www.facebook.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-
US; rv:1.9.2.17) Gecko/20110422 Ubuntu/10.04
(lucid) Firefox/3.6.17
Accept:
text/html,application/xhtml+xml,application/xml;q=
0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-aliveHTTP/1.1 200 OK
Cache-Control: private, no-cache, no-store, must-
revalidate
Expires: Sat, 01 Jan 2000 00:00:00 GMT
P3P: CP="Facebook does not have a P3P policy.
Learn why here: http://fb.me/p3p"
Pragma: no-cache
path=/; domain=.facebook.com; httponly
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
X-FB-Server: 10.146.68.118
X-Cnection: close
Transfer-Encoding: chunked
Date: Mon, May 2013 19:30:45 GM
Pentru a bloca accesul în cauz ă site-ul respectiv este de ajuns s ă se blocheze Client
Request-ul ce con ține cererea GET c ătre site-ul în cauz ă. Pentru a nu filtra toate pachetele și a
evita întârzierile inutile, se va verifica doar antetul pachetelor http ce pleac ă de la Client c ătre
portul 80 al server-ului web.
drop tcp any any -> any 80 (msg:"Facebook not
allowed";content:"Host: www.facebook.com";
http_header;classtype:policy-violation; sid:1000007;
rev:1;)
Este posibil ă o filtrare dup ă conținut conform modelelor prezentate mai jos:
drop tcp my_ip any -> any $HTTP_PORTS (pcre:"/4\d{3}(\s|-
)?\d{4}(\s|-)?\d{4}(\s|-)?\d{4}/"; msg:"VISA card number
detected over http "; classtype:policy-violation;
sid:9000000;rev:1;)
drop tcp my_ip any -> any $HTTP_PORTS (pcre:"/5\d{3}(\s|-
)?\d{4}(\s|-)?\d{4}(\s|-)?\d{4}/";msg:"MasterCard number
detected over http"; classtype:policy-violation;
sid:9000001;rev:1;)
alert tcp my_ip any -> any $HTTP_PORTS (pcre:"/[a-zA-Z0-
9_\.]+@[a-zA-Z]+\.[a-zA-Z]+/";msg:"Email address detected over
http"; classtype:policy-violation; sid:9000004; rev:1;)
drop tcp my_ip any -> any $HTTP_PORTS (pcre:"/[1-9]{1}[1-
9]{2}(0[1-9]|1[0-2])(0[1-9]|[12]\d|3[01])(0[1-9]|[1-4]\d| 5[0-
2]|99)\d{4}/";msg:"CNP detected over http"; classtype:policy-
violation; sid:9000006;rev:1;)
În cazul portului Https, care func ționează cu encrip ție, blocarea și filtrarea este mai complicat
de realizat.
84Comunica ția folosind Https-ul începe cu o negociere de protocol în care se stabile ște
cheia de sesiune, dup ă care totulfunc ționează criptat.Astfel o filtare dup ă conținut nu este
posibilă.
Protocolul Https avea la început o mic ă problemă în sensul c ă nu comunica corect
validitatea certificatului serverelor care aveau implementate serviciul de Virtual Hosting(mai
multe domenii ce folosesc acela și IP). Astfel un site care folosea Https-ul era necesar s ă aibă
un IP unic; nu era posibil ă găzduirea mai multor site-uri Https pe acela și IP, iar validarea
certificatului s ă funcționeze în mod corect. Motivul principal este dat de faptul c ă atunci când
primul pachet de Client Hello ajungea la server, acesta nu avea cum s ăștie ce site
se vrea servit pentru a furniza corect certificatul corect. Astfel a ap ărut nevoia ca un
Client Request s ă conțină și acest am ănunt pentru ca un server s ă poată găzdui mai multe site-
uri HTTPS pe acela și IP și să poată identifica din timp ce domeniu este accesat pentru a
furniza certificatul corect.
sdfsdf
sdfsdAstfel în RFC4366 a ap ărut o extensie la TLS denumit ăServer Name Indication unde
este specificatîn clar domeniul accesat.
Astfel se poate bloca accesul la site anume dup ă aceasta extensie:
drop tcp any any -> any 443 (msg:"HTTPS Facebook not allowed";
content:"facebook.com"; ssl_state:client_hello;
ssl_version:tls1.0,tls1.1,tls1.2; classtype:policy-violation;
sid:1000008; rev:1;)
Din păcate nu este de ajuns pentru a bloca accesul la un site ce folose ște SSL, în
principiu dincauza browser-elor. Acestea, dup ă ce se realizeaz ă 3-way-handshake-ul TCP, vor
trimite un Client Hellofolosind protocolul TLS 1.0 sau TLS 1.1 sau chiar TLS 1.2, iar pentru
că are extensia Server NameIndication va fi identificat de Snort și dropat. Pentru c ă browser-
ul nu prime ște înapoi „Server Hello” mai încearc ă de câteva ori. Dac ă nici după aceste
încercări nu reușește atunci va folosi o versiune inferioar ă de SSL cum ar fi SSL 2.0 și 3.0,
versiuni ce nu au extensia Server NameIndication.
Din aceast ă cauza Snort-ul va permite trecerea acestor pachete iar site-ul va putea fi în
continuare accesat. Din aceasta cauz ă trebuie blocate aceste versiuni ale protocolului SSL
deoarece nu mai sunt foarte folosite, iar majoritatea server-elor și clienților folosescversiunile
mai noi. Alt motiv pentru blocareaacestora ar fi și încurajarea folosirii protocoalelor sigure
cum ar fi TLS 1.0, 1.1, 1.2. Pentru a realiza acest lucru trebuie activat decoder-ul Snort-ului
care va ajuta la normalizarea și decodareaprotocolului, precum și la posibilitatea folosirii unor
opțiuni specifice SSL-ului cum ar fi „ssl_version”, care ajut ă la identificarea versiunii
Figura 8.10 – Protocolul HTTPS
85protocolului și „ssl_state” folosit ă la identificarea tipului depachet din handshake-ul
SSL(Server Hello, Client Hello, etc).
preprocessor ssl: ports { 443 },
trustservers,noinspect_encrypted
Astfel Snort este instruit s ă porneasc ă preprocesarea pachetelor ssl de pe portul 443, s ă
nu mai aștepte și Server Reply-ul din sesiunea SSL pentru a considera comunica ția
criptată(trustservers) și să nu inspecteze pachetele la nivel de aplica ție pentru ca ele oricum
sunt criptate și pot genera falsuri pozitive(noinspect_encrypted ).
Astfel, pachetele vor fi decodate și normalizate și vom putea folosi func ții ale snort-
ului specifice SSL-ului.
Regula ce blocheaza pachetul Client Hello ce foloseste o versiune inferioara de ssl
este:
drop tcp any any -> any 443 (msg:"SSL old versions not
alowed"; ssl_state:client_hello; ssl_version:sslv3,sslv2;
classtype:policy-violation; sid:1000009; rev:1;)
În cazul traficului browser-elor ce folosesc protocoalele TLS1.0,TLS1.1, TLS1.2 și
nuimplementeaz ă extensia Server Name Indication , acesta va fi blocat.
Primul pas este de a analiza handshake-ul ssl și a vedea unde anume se afl ă extensia
respectivă și cum putem face pentru a ajunge la ea. Se va analiza primul pachet din
handshake, „Client Hello-ul”, și se vaîncerca a ajunge la Server Name Indication, care
conform RFC-ului are num ărul 0.Dacă extensie cu num ărul 0 exist ă, atunci pachetul va fi
lăsat să treacă, dacă nu, atunci pachetul va firespins.
Figura 8.11 Pachet Client Hello TLS 1.0
byte_jump:2,44,align;
Se va sări peste cei 44 de octe ți din payload, se vor citi 2 octe ți ce reprezint ă lungimea
86
câmpului cu cifruri, se va transforma în num ăr întreg și se va sări peste acel num ăr de octeți
care în cazulacesta este 72. Astfel ne vom pozi ționa exact în fata câmpului Compression
Methods Length. Va trebui citit ă lungimea acestui câmpului și omiși acei octe ți
byte_jump:0,1,relative,align;
Se sare peste câmpul unde se descrie Extension Length-ul și se caută în următorii doi
octeții dacă apare0000, num ărul extensiei Server Name Indication:
content:!"|0000|"; distance:2; within:2;
Regula final ă care blocheaz ă orice pachet client hello ce nu are extensia Server Name
Indication este:
drop tcp any any -> any 443 (msg:"SSL without extension not
allowed"; byte_jump:2,44,align;
byte_jump:0,1,relative,align; content:!"|0000|"; distance:2;
within:2; ssl_state:client_hello;
ssl_version:tls1.0,tls1.1,tls1.2;
classtype:policy-violation; sid:1000010; rev:1;
8.6 Filtrarea protocolului FTP
FTP-ul este un protocol extrem de r ăspândit și popular folosit în transferul de date.
Este folositmai ales în rândul creatorilor de site-uri, pentru a face upload-ul unor diverse
documente ce vor fi apoi accesate deutilizatorii site-ului respectiv. Din neaten ție este foarte
ușor să uploadezi și documente ce nu ar trebuir ăspândite publicului larg. Bineîn țeles un
atacator poate folosi acest protocol pentru a uploada script-urimali țioase.
FTP-ul este un protocol foarte vechi, descris în RFC 959 din 1985, și de aceea este
puțin diferit fa ță de alte protocoale TCP/IP folosite în prezent. Acesta nu lucreaz ă pe un
singurport, comenzile se trimit pe portul 21, iar transferul de date se executa fie pe portul 20
fie pe oricare alt port mai mare decât 1024. Alt ă problema ar fi în modul cum transfera FTP
datele, ori folose ște modulAsci ori folose ște modul Binar pentru transfer.
FTP-ul poate func ționa sub dou ă moduri:
Pasiv
1. Clientul ini țiază transferul de pe
un port mai mare de 1024 pe portul
21 al serverului, iar serverul îi va
spune că va începe s ă asculte peun
port peste 1024.
Figura 8.12 – FTP în mod Pasiv
87
2.Clientul se va conecta la acel nou port pecare va asculta serverul și va transmite
sauprimi date. Astfel datele ce trebuiesc filtratevor circula între client și server pe
porturi TCP mai mari decât 1024.nO regul ă ce poate fi folosit ă pentru a fi filtra dup ă
conținut este urm ătoarea:
reject tcp any 1024: ->
any 1024: (msg:"Secret
String pasiv FTP"; content:"secret";
classtype:policy-violation; sid:1000003; rev:1;)
Activ
1. Clientul ini țiază transferul de pe un
port P mai mare decât 1024, în care
îi spune server-ului c ă va ascult ă pe
un port P+1.
2. Serverul va ini ția apoi transferul
folosind portul 20 conectându-se la
client pe noul port pe care acesta
ascultă.
Acest mod are probleme cu echipamentele
de firewall-ul și cu protocolul NAT,mul ți
clienți aflându-se în spatele altor
echipamente de re țea( router, firewall,
proxy), serverul neavând posibilitatea s ă
ajungă niciodată el. Datele pot fi
transferateatât binar cât și în mod asci de
aceea cea mai bun ă regulă este să
fieverificat tot traficul raw pe portul 20
după cuvinte cheie:
reject tcp any 20,1024: -> any 20,1024: (msg:"Secret String
FTP Activ"; content:"secret"; classtype:policy-violation;
sid:1000004; rev:1;)
8.7 Filtrarea protocolului SMTP
Simple Mail Transfer Protocol (SMTP) este protocolul standard folosit pentru
transmisia mesajelorelectronice. Serverele de mail comunic ă prin acest protocol pentru a
transmite mesajele. Protocolul folose ște caractere ASCI pentru transmiterea mesajelor f ăcând
intercepția și decodarea acestora extrem de u șor. Portul folosit este 25.Figura 8.13 – FTP în mod Activ
88O regulă ce scaneaz ă tot traficul de SMTP în c ăutarea stringului „topsecret” este
următoarea:
reject tcp any any ->any 25 (msg:"SMTP topsecret string";
content:"topsecret"; classtype:policy-violation; sid:1000005;
rev:1;)
Problema vine atunci când vrem s ă transmitem și date care nu sunt text, cum ar fi un
executabil. Pentru a trece peste acest ă problemă a apărut MIME(Multipurpose Internet Mail
Extensions) în care sunt definiteni ște standarde pentru codarea binar-text, cea mai popular ă
astfel de codare fiind base64 . Astfel oricemail cu attachment binar, va fi transformat în
base64 și apoi trimis.
Un mail cu attachment binar va fi encodat în base64 și pus în corpul mail-lui, delimitat
de niste tag-uri:
––=_NextPart_000_0061_01CC1B24.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 folose ște doar 64 de caractere, astfel 6 bi ți per caracter sunt de ajuns în loc de
8biti cât sefolosesc în mod normal. Astfel un string trebuie scris în mod binar, împ ărțit în
bucăți de câte 6 bi ți, șiapoi folosind tabelul de conversie Base64,se transform ă fiecare calup
de câte 6 bi ți în caractere.
Pentru a encoda base64 stringul ”topsecret” se procedeaz ă astfel:
t o p s e c r e t
ASCI(Dec) 116 111 112 115 101 99 114 101 116
ASCI(Hexa) 74 6F 70 73 65 63 72 65 74
ASCII(Binar) 0111.0100 0110.1111 0111.000 0111.0011 0110.0011 0110.0011 0111.0010 0110.0101 0111.0100
Tabelul 8.14 – Codare“topsecret”
Conformalfabetului Base64 vom avea:
Bin 011101 000110 111101 110000 011100 110110 010101 100011 011100 100110 010101 110100
Base64(val) 29 6 61 48 28 54 21 35 28 38 21 52
Base64(enc) d G 9 w c 2 V j c m V 0
Tabelul 8.15 – Codare “topsecret” base64
89
Astfel topsecret va fi codatîn Base64 sub forma dG9wc2VjcmV0.
Un caracter ad ăugat în fa ța sau în spatele șirului de caractere c ăutat va schimba total
codare acestuia, deci c ăutarea dup ă șiruri codate nu este o solu ție. Singura solu ție este găsirea
și decodareatraficului base64 și de-abia dup ă aceea efectuat ă căutarea.
Snort-ul are incluse func ții de decodare, singura problema r ămânând doar calibrarea
exactă a locului de unde s ă înceapă decodarea, o gre șeala de 1 bit rezultând în ni ște caractere
decodate totaldiferit fa ță de cele reale.
Regula urm ătoare decodeaz ătraficul base64 calibrând pointer-ul exact de unde începe
traficul codat și apoi caut ă după caracterele „topsecret”:
reject tcp any any -> any 25 (msg:"SMTP base64";
content:"base64"; content:"|0d0a0d0a|";base64_decode:relative;
base64_data; content:"topsecret"; within:14; classtype:policy-
violation; sid:1000006; rev:1;)
8.8 Logarea
Snort a fost configurat s ă realizeze urmatorul tip de logare:
Syslog : alertele sunt trimise sub acest standard c ătre un server specializat;
Syslog-ul este un standard folosit pentru logarea datelor.Acesta separ ă software-ul ce a
generat mesajul de sistemul ce îl stocheaz ă și îl analizeaz ă.Figura 8.16 – Alfabetul Base64
90
Câmpurile principale sunt: nivelul facilit ății, nivelul de severitate și mesajul în sine.
Nivelul facilit ății este utilizat pentru a specifica ce tip de program a logat mesajul. Acest
lucru permite ca în fi șierul de configurare al unui sistem s ă se specifice cum s ă fie manipulate
logurile dup ă acest nivel.
Figura 8.17 – Nivele de securitate specifice Syslog
Figura 8.18 – Nivelele de facilitate Syslog
9.Concluzii
Problemele de securitate care afecteaz ă sistemele și rețelele informatice impun
utilizarea unor solu ții care să aibă în vedere diferitele tipuri de incidente și amenințări care pot
duce la pierderea unor informa ții sensibile.
Sistemele de detec ție și prevenție a intruziunilor au devenit obligatorii pentru
protejarea împotriva diferitelor tipuri de malware, împotriva intercept ării datelor confiden țiale
transmise prin re țelele informatice, precum și pentru protejarea re țelelor interne
organizaționale împotriva unor ac țiuni externe ostile, mai ales în cazul institu țiilor militare,
care sunt predispuse zilnic la astfel de acte datorit ă importan ței lor strategice în securitatea
națională și mondial ă. Această lucrare a analizat aceste echipamentele din toate punctele de
vedere, de la clasificare, metode de detec ție, tehnici de analiz ă a traficului pân ă la criterii
relevante ce pot influenta alegerea unui astfel de echipament și cerințele recomandate pentru
blocarea eficient ă a intruziunilor.
Fiecare IDPS și gen de detec ie are avantajele și dezavantajele sale, iar pentru a
detectași preveni cu succes atacurile informatice nu este de ajuns un singur tip de
echipament, ci o combina ție de mai multe echipamente și tehnici de detec ție.
Snort este extrem de performant putând fi folosit cu succes în detec ția și prevenirea
scurgerilor de date, cu re țineri asupra traficului criptat, trafic ce va trece f ără a putea fi
decriptat. Avantajul lui este pre țul și posibilitatea de a crea reguli proprii care analizeaz ă
traficul informatic la nivel de bi ți. O alta problem ă la Snort este îns ăși faptul ca este open
source, iar defini țiile și configura țiile implicite sunt le vedere, oricine le poate analiza,
modifica și testa, pentru a depista eventualele probleme și arii neacoperite, folosindu-se de
acestea în lansarea unui atac.
Sistemele de detec iei prevenire a intruziunilor, reprezint ă o variabil ă foarte
important ă în ecuaia unui sistem bine protejat, pentru c ă una din cele mai importante
resurse, poate chiar mai important ă decât cele materiale, este dat ă de infoma ție și obținerea
ei. Într-o lume în care echilibrul mondial este dictat de puterea informa ției, menținerea
confidențialități acesteia este foarte important ă, deoarece aceasta d ă valoarea unei informa ții.
210.Bibliografie
1. K. Scarfone, P. Hoffman, „Guide to Intrusion Detection and Prevention Systems(
IDPS)”, NIST Special Publication 800-94, 2007;
2. S. Northcutt, J.Novak, „Network Intrusion Detection, 3rd Edition”, New Riders
Publishing, 2002;
3. Snort Users Manual 2.9.4, Noiembrie 2012;
4. Sandip A. Kale, Prof.S.V. Kulkarni, „Data Leakage Detection: A Survey”;
5. Andrew S. Tanenbaum, „Re țele de calculatoare, edi ția a treia”, Computer Press
Agora, 1998;
6. SourceFire VRT WhitePaper: SourceFire, SourceFire VRT WhitePaper, 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-de-
baza.html
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Sistem de detec ție și prevenire a intruziunilor într-o [609208] (ID: 609208)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.