Sisteme de Detectie a Intruziunilor

Sisteme de Detecție a Intruziunilor

Cuprins:

Cuprins:

Introducere

2.Principiile INTRUZIUNILOR (IPS)

2.1 Tehnologii IPS

2.2 Metode de detecție pentru IPS

2.2.1 Detecția pe bază de semnătura

2.2.2 Detecția bazată pe anomalii

2.2.3 Stateful Protocol Analysis

2.3 Componentele și Arhitectura IPS

2.3.1 Arhitecturi de rețea

2.3.2 Crearea de jurnale

2.3.3 Network-Based IPS

2.3.4 Abilități de prevenire a incidentelor

2.4 Network Behavior Analysis (NBA)

2.4.1 Locațiile Senzorilor

2.4.2 Posibilități de creare a jurnalelor

2.4.3 Tipuri de evenimente detectate

3.Sisteme de detecție a intruziunilor bazate pe gazde (HIDS)

3.1 Componente și Arhitectura

3.1.1 Componente tipice

3.1.2. Arhitecturi de rețea

3.1.3 Locațiile agenților

3.1.4 Arhitecturi ale stațiilor gazdă

3.1.5 Funcții de Securitate

3.1.6 Funcția de creare de jurnale

3.1.7 Funcția de detecție

4. Honeypot

4.1 Amplasamentul sistemelor "Honeypot"

4.2 Clasificarea honeypot-urilor:

5. Instalarea și configurarea unui sistem HIDS

5.1 Platforma folosita

5.2 Instalare

5.3 Instalarea Internet Information Services (IIS)

5.4 Rularea utilitarului IISLockdown

5.5 Instalarea și configurarea PHP pentru IIS

5.6 Configurare IIS pentru PHP

5.7 Configurarea Snort să ruleze ca un serviciu

5.8 Instalare și configurare MySQL

5.9 Crearea de reguli noi pentru Snort

6. Concluzii

Anexa 1 – Acronime

Bibliografie

Introducere

Principiile de bază ale securității sistemelor informatice s-au schimbat relativ puțin in ultimii ani. Utilizarea echipamentelor de tip router și aplicarea listelor de control al accesului, impreună cu controlul traficului ce intră și iese din rețele utilizând soluții firewall reprezintă, și in prezent, tehnicile principale pentru protecție perimetrală.

Facând parte din categoria tehnicilor de tip pasiv, cele două nivele de protecție au fost continuu optimizate din punct de vedere al performanțelor, funcționalităților și al administrării. Creșterea susținută a numărului de atacuri și a complexității acestora, precum și necesitatea de tehnologii de protecție activă, sunt motivele ce au condus la introducerea in domeniu de noi tehnologii.

Î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 si nu numai au început sa investească în programe antivirus de

rețea, firewall-uri, securitatea mesajelor provenite din posta electronică si 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.

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 admin-ului printr-o anumita notificare, pentru a putea lua decizia optimă cât mai

repede cu putință cu privire la starea rețelei.

Acum câțiva ani a apărut conceptul de IDS – Intrusion Detection System (Sisteme de detecția intruziunilor).

Definit ca un sistem de identificare, inventariere și raportare a traficului de rețea neautorizat, un sistem IDS reprezintă o soluție alternativa ce permite administratorilor de rețea și de securitate să identifice în timp optim încercările de atac asupra unui sistem informatic. Comparativ cu un sistem firewall, care, pe bază politicilor de tip „allow” și a

celor de tip „deny” controlează traficul la perimetrul unei rețele, sistemele IDS analizează traficul de date permis de către un firewall sau router pentru identificarea tentativelor de atac. Tehnicile de detecție al intruziunilor sunt bazate pe identificarea semnăturilor de atac și anomaliilor de trafic la nivel de aplicație. Alertarea în cazul unui potențial atac este un serviciu extrem de util pentru administratori, care pot astfel interveni în timp optim pentru protejarea rețelei. Sistemele IDS au crescut astfel în utilizare și în prezență pe piață.

Producătorii de pe piață au fost practic nevoiți să susțină și să imbunătațească tehnologiile IDS. Astfel a fost dezvoltat conceptul de IPS –Intrusion Prevention Systems (Sisteme de prevenire a intruziunilor).

Un sistem IPS este în principiu un sistem IDS cu funcționalitate de blocare a atacurilor detectate. Pe lângă diferența principala, respectiv modul pasiv sau proactiv de protecție exista și alte elemente distincte precum modul de amplasare în cadrul unei rețele informatice (sistemele IPS sunt de obicei amplasate „inline” – similar cu echipamentele router și firewall), cerințele hardware din punct de vedere al procesării.

Sistemele IPS pot fi folosite acționând ca un firewall de nivel aplicație (Proxy firewall), soluțiile IPS asigura o granularitate mare din punct de vedere al modalităților de blocare parțiala a atacurilor la nivel aplicație. Implementarea de controale automatizate pentru răspuns în cazuri de atac are totuși și dezavantaje. Un sistem IPS nu va lasă pachetele de date să treacă decât după inspecția conținutului acestora la nivel aplicativ. Acesta introduce, întârzieri în timpul de răspuns al serviciilor în rețea motiv pentru care sistemele IPS de tip „inline” trebuie să aibă la bază hardware performant care să asigure cerințele de trafic specifice.

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.

IDS (Intrusion Detection System) este un dispozitiv sau aplicație folosită la inspectarea traficului pe rețele și la alertarea utilizatorilor sau administratorilor atunci când au loc tentative de acces neautorizate. Un sistem de detectare a intruziunilor (IDS) este software-ul care automatizează procesul de detectare a intruziunilor. Un sistem de prevenire a intruziunilor (IPS) este software-ul care are toate capacitățile sistemului de detectare a intruziunilor și care poate să le contracareze.

Arhitectura de principiu a unui sistem pentru detectia intruziunilor (IDS) este prezentată în figura urmatoare.

Arhitectura generica a unui sistem IDS

Senzorii sunt responsabili cu colectarea datelor. Exemple de tipuri de intrări pentru un senzor sunt pachetele din rețea, fișierele log. Senzorii colectează și trimit mai departe informația la analizatori.

Analizatorii primesc intrarea de la unu sau mai mulți senzori sau de la alți analizatori. Analizatorul este responsabil cu determinarea apariției unei intruziuni. Răspunsul acestei componente este un indicator ce indica dacă a apărut sau nu o intruziune. Răspunsurile pot fi stocate pentru o evidență ulterioară.

Interfața cu utilizatorul a unui IDS oferă posibilitatea utilizatorului de a vedea rezultatele sistemului sau de a controla comportamentul acestuia. în unele sisteme, aceasta interfața poate fi asociata unei componente „manager”, „director” sau „consolă”.

Tehnologii IPS

În literatura de specialitate sunt disponibile mai multe clasificari ale sistemelor IDS, celemai importante fiind dupa provenienta datelor si dupa tehnica de detectie folosită.

În functie de proveniența datelor utilizate în procesul de detectie (ceea ce dicteaza în mod implicit si amplasarea acestora), solutiile IDS se clasifica în HIDS (IDS bazate pe

informații provenind de la stații) si NIDS (IDS bazate de datele de trafic din rețea).

IPS-urile sunt dispozitive  instalate in rețea destinate detectării și blocării unei mari varietăți de atacuri. Unele studii din domeniul cercetării arata că aceste IPS-uri sunt folosite pentru detectarea intruziunii și pentru monitorizarea pasiva a traficului.

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:

2.1.1 IPS la nivel de rețea (NIPS – Network IPS):: 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; NISP combină funcționalități ale sistemelor IDS , IPS și firewall, și uneori le găsim sub denumirea de IDS in-line sau Gateway IDS (GIDS). NISP poate doar preveni pachetele de date infectate care traversează dispozitivul. Pentru o funcționare eficienta a IPS, fluxurile de date trebuie forțate să treacă prin acest dispozitiv. Mai exact, datele ar trebui protejate atunci cand sunt transmise spre sau receptate de la calculatoare din retea care:

solicita un grad inalt de securitate si protectie

au probabilitate mare de patrundere in retea

datorita locatiei, reteaua este segmentata in zone de protectie mai mici, oferind o larga raspandire.

2.1.2 Wireless : 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;

2.1.3 IPS la nivel de server/stație de lucru (HIPS – Host IPS): HIPS poate monitoriza fluxurile de date și mediile specifice aplicațiilor (locațiile fișierelor și setările regiștrilor pentru server-ul web de exemplu) pentru a proteja aplicațiile de atacuri neidentificate încă. Implementările uzuale sunt de tipul NISP, deoarece acestea protejează nu doar un singur host, ci mai multe servere aplicative din cadrul unei rețele de date.

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ție de lucru (HIPS – Host IPS): HIPS poate monitoriza fluxurile de date și mediile specifice aplicațiilor (locațiile fișierelor și setările regiștrilor pentru server-ul web de exemplu) pentru a proteja aplicațiile de atacuri neidentificate încă. Implementările uzuale sunt de tipul NISP, deoarece acestea protejează nu doar un singur host, ci mai multe servere aplicative din cadrul unei rețele de date.

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.1.4 Network Behavior Analysis (NBA), care examinează traficul de pe rețea pentru a identifica fluxurile de trafic neobișnuite, cum ar fi distribuit Denial of Service (DDoS) atacuri, pentru anumite forme de malware-ului (viermi, backdoors), precum și încălcări în politica de securitate.

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;

Un sistem IPS la nivel de rețea poate reacționa la diversele tipuri de atacuri prin blocarea unui port de switch care generează trafic neautorizat, generarea și aplicare automata de reguli de filtrare trafic la nivel de router sau firewall (blocarea unei adrese individuale IP sau a unei întregi clase), închiderea automata a conexiunilor client-server în cadrul cărora este detectat trafic neautorizat sau alterarea conținutului datelor la nivel aplicativ pentru anularea/minimizarea efectelor acestora asupra țintei atacului.

Tehnologia IPS este relativ nouă și in continuuă evoluție. Incercând să rezolve limitările și problemele IDS, sistemele IPS trebuie să răspundă insă unei provocări mult mai mari.

Daca in cazul IDS, o alarmă falsă nu afecta in mod direct traficul de date și disponibilitatea serviciilor, in cazul IPS, o alarmă falsă tradusă in activarea de măsuri de blocare a potențialului atac se poate traduce in blocarea unor servicii de rețea legitime sau accesul unor surse legitime. In ciuda acestor probleme, sistemele IPS alături de sistemele IDS, sunt in prezent in atenția specialiștilor de securitate. Prevenirea intruziunilor fiind mult mai valoroasă decât detecția intruziunilor, deoarece procesul de detecție a intruziunilor doar „observă” evenimentele în desfășurare, fără a încerca să le oprească.

În cazul sistemelor suport pentru aplicații practice cu cerințe ridicate privind protecția datelor și a altor tipuri de resurse implicate, o soluție IDS eficientă trebuie să prezinte următoarele caracteristici:

să fie ușor de operat;

să fie adaptabile prin setarea adecvată a diverșilor parametri specifici proceselor de detecție/ prevenire a intruziunilor, pentru a nu stânjeni funcționarea normală a aplicației;

să ruleze continuu;

să fie tolerantă la defecte;

să determine o încărcare minimală a sistemului;

să determine precis devieri de la comportamentul normal;

să fie bine adaptată pentru cerințele specifice ale sistemului protejat;

să fie ușor de întreținut;

să se bazeze pe implementări pentru care se asigură actualizări periodice ale semnăturilor;

să fie capabilă să țină evidența evenimentelor,și să stocheze datele respective într-o locație securizată, de asemenea să asigure trimiterea de mesaje de alertă către administratorii de securitate.

In concluzie, orice echipament IPS poate fi folosit ca și echipament IDS. Echipamentele IPS în general lucrează impreună cu sistemele NBA și IDS. Când este detectat un atac de către IDS sau NBA, sistemul IPS poate șterge pachetele respective, permițând totuși ca restul traficului să treacă.
In opinia mea, un sistem NBA poate fi considerat un pic mai puțin proactiv decat cel IDS și, în general, se axează pe traficul intern. Poate fi de asemenea implementat si peste o anumită conexiune și să inspecteze pachete exact ca un IDS. Spuneam mai puțin proactiv deoarece NBA incearcă să recunoască problemele care sunt deja in curs de desfășurare (de exemplu, scanarea rețelei sau atacurilor DDOS, care sunt in curs de desfășurare), încearcând sa identifice amenințările ce nu au fost identificate de IDS sau de software-ul antivirus. Deoarece sistemul NBA este orientat spre identificarea simptomelor sau a comportamentelor, actualizarea motorului de analiză se face mai rar comparativ cu sistemele IDS.
Un sistem HIDS monitorizează starea stației precum si aspecte ale comportamentului său dinamic cu scopul de a determina încercări de violare a politicii de securitate a sistemului respectiv. HIDS utilizeaza în general o baza de date securizată cu obiecte sistem si atributele de referinta asociate acestora ( permisiune, dimensiune, date modificare, etc.). În procesul de monitorizare se compara atributele curente ale obiectelor cu cele de referinta, din baza de date.

Un sistem NDIS monitorizeaza pachetele de date din retea (Snort, Bro), sau statisticile de trafic furnizate de echipamentele din retea sau alte aplicatii (Novell Analyzer, Microsoft Network Monitor) pentru a determina indicatori asupra activitatilor suspecte cum ar fi: scanari, propagari de viermi, atacuri DoS, etc..

În multe implementări de sisteme IDS comerciale, se combina aspecte specifice HIDS si cele NIDS, aceste implementari fiind numite si NNIDS (IDS de nod de retea). NNIDS opereaza ca un NIDS hibrid la nivel de statie ce proceseaza traficul destinat catre

masina respectiva. Aceste solutii hibride adreseaza limitarile de vizibilitate ale NIDS

clasic în ceea ce priveste traficul de retea criptat, oferind totodată o monitorizare

eficienta la nivelul serviciilor (Web, SMTP, SSH, etc.) pentru identificarea încercarilor

de violare a specificatiilor protocoalelor de nivel aplicatie.

2.2 Utilizarea tehnologiilor IDPS

Scopul principal al IDPS-urilor (“Intrusion detection and prevention system”) 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 incindentul administratorilor de securitate, care pot iniția acțiuni de răspuns pentru a minimiza daunele cauzate de incident.

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țand identificarea traficului ce încalcă normele de securitatea ale unei companii: monitorizarea transferurilor de fișiere și recunoașterea celor ce ar putea fi

suspicioase, asemenea transferului unei baze de date într-un laptop);

activitățile de recunoaștere, ce indică de cele mai multe ori iminența unui posibil

atac(ex: unele tool-uri de atac și forme de malware – în special cel de tip worm)

efectuează activități de recunoaștere ca scanarea de host-uri și port-uri pentru

identificarea unor ținte pentru atacurile viitoare.Un IDPS poate bloca aceste acțiuni,

notificând în același timp administratorii de securitatea, care pot interveni, dacă este

nevoie, pentru a preveni incindente viitoare.Datorită frecvenței foarte mari a

activităților de recunoaștere în internet, detecția acestora se concentrează în mod

deosebit pe rețele interne.

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

identificarea problemelor politicilor de securitate: poate oferi indicații asupra calității

controlului oferit de implementarea politicilor de securitate existente( ex: duplicarea

regulilor firewall și alertarea traficului ce ar fi trebuit blocat de către firewall, dar din

cauza unor erori de configurare nu a fost blocat;

documentarea amenițărilor existente asupra organizației: logarea informațiilor legate

de amenințările ce sunt detectate ajută la identificarea caracteristicilor și frecvenței

diverselor atacuri asupra resurselor computaționale ale organizației.Astfel, pot fi

adoptate măsurile adecvate pentru protejarea resurselor existente;

descurajarea diverselor persoane în a încălca politicile de securitate: acțiunea de

monitorizare a tehnologiilor descurajează violarea normelor de securitate din cauza

riscului de detecție.

Din cauza dependenței tot mai sporite față de sistemele informaționale precum și

potențialul impact al intruziunilor asupra acestor sisteme, IDPS-urile au devenit un plus

necesar pentru infrastructura de securitate a oricărei organizații.

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:

2.3.1 Î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;

2.3.2 Notificarea administratorilor de securitate despre evenimente importante

observate. Această notificare, cunoscut sub numele de alertă, survine prin mai multe

metode: email-uri, pagini de răspuns, mesajele de pe interfața cu utilizatorul a

sistemului, prin trap-urile de tip SNMP( Simple Network Management Protocol) ,

mesaje syslog, ori programe și script-uri definite de utilizator. Un mesaj de notificare

include de obicei doar informații de bază cu privire la un eveniment, administratorii

trebuie să acceseze IDPS-ul pentru informații suplimentare;

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

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

Oprirea atacului fără vreo altă intervenție ar putea fi realizat după cum urmează:

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

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

Blocarea 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 detecț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,

reducerea unuia duce la apariția celuilalt. Multe organizații aleg să scadă aparițiile de falsuri

negative, cu costul creșteri falsurilor pozitive, fapt ce duce la detecția mai multor evenimente

periculoase, făcându-se uz de mai multe resurse de analiză pentru a se face diferența între

evenimentele fals pozitive și cele malware. Modificarea configurației unui IDPS pentru a

îmbunătăți precizia de detectare este cunoscută sub numele de tuning.

Cele mai multe tehnologii IDPS oferă funcționalități ce combat utilizarea tehnicile

comune de evaziune.Evaziunea reprezintă modificarea formatului activităților malware, astfel

încât „înfățișarea” acestora se schimbă, dar efectul rămâne același. Atacatorii folosesc tehnici

de evaziune pentru a încerca să prevină detecția atacurilor realizată de IDPS-uri.De exemplu,

un atacator ar putea codifica caractere text într-un anume mod, știind că ținta știe să

interpreteze caracterele codificate, în speranța că orice IDPS de monitorizare nu o face. Cele

mai multe tehnologii IDPS pot depăși tehnicile comune de evaziune prin duplicarea unor

procesări speciale efectuate de către ținte.În cazul în care IDPS-ul poate "vedea" activitatea în

același mod în care o face ținta, atunci tehnicile de evaziune vor fi ineficiente în încercarea de

a ascunde atacurile.

3.Clasificarea IDS

În functie tehnica de detectie folosita, sistemele IDS au fost în mod traditional grupate în doua clase mari: sisteme bazate pe anomalii si cele bazate pe semnaturi.

În timp, o serie de noi tehnici au fost recunoscute în literatura de specialitate si anume: monitorizarea integritatii, monitorizarea fisierelor de jurnalizare, tehnici capcana (honeypot), analiza protocoalelor de tip stateful si tehnicile hibride.

3.1 Analiza fisierelor de jurnalizare

Analiza fisierelor de jurnalizare, denumita adesea în literatura comerciala de

specialitate LIDS (detectie de intruziuni bazata pe fisiere de jurnalizare) poate fi utilizata

pentru a detecta utilizari necorespunzatoare ale sistemelor, sau violari ale politicii de

securitate.

3.2 Solutii de analiza offline

Anumite solutii realizeaza analiza fisierelor de jurnalizare (log) pe o durata de timp si genereaza rapoarte care pot fi evaluate ulterior de personalul de administrare sau desecuritate. Acest gen de solutii ruleaza în mod uzual zilnic si sunt benefice în

identificarea evenimentelor pentru o analiza mai aprofundata de timp real. Rapoartele

ofera de asemenea informatii statistice care ajuta în evaluarea tendintelor (detectarea

de anomali). Totusi aceste solutii au limitari în ceea ce priveste adresarea situatiilor ce

necesita un raspuns imediat. De exemplu, daca un server web este inaccesibil, este

necesar un raspuns imediat, iar identificarea acestei probleme pe baza acestui tip de

solutie este inadecvata.

3.2.1 Logwatch este o solutie ajustabila care analizeaza fisierele specificate de utilizator pe baza unor criterii alese de acesta si genereaza rapoarte. Aplicatia consta într-un set de scripturi Perl si filtre care sunt simplu de configurat. Aceste criterii sunt furnizate ca optiuni în linia de comanda. Solutia poate fi utilizata pentru analiza fisierelor de jurnalizare a programelor uzuale (cum ar fi Apache, sendmail, etc.), dar poate fi usor

configurata pentru a interpreta si jurnalele altor categorii de aplicatii.

3.2.2 SLAPS-2 (System Log Analysis & Profiling System 2) este o colectie de programe Perl utilizate pentru filtrarea fisierelor de jurnalizare sistem ce se colecteaza pe un server central. Aplicatia produce o serie de rapoarte de analiza a operarii sistemului care pot fi trimise prin email catre o lista de utilizatori specificati. Aceasta solutie adreseaza si aspecte legate de rotatia fisierelor de jurnalizare utilizate în decursul analizei.

3.3 Solutii de analiza online

Analiza de timp real consta în acele solutii care ruleaza permanent si monitorizeaza unul sau mai multe fisiere de jurnalizare. Aceste solutii au avantajul generarii în timp real de alerte când sunt detectate anumite evenimente, însa cele mai multe dintre solutii sunt limitate în ceea ce priveste adresarea situatiilor atipice.

3.3.1 SWatch (Simple Watchdog) a fost una din primele solutii create pentru monitorizarea fisierelor de jurnalizare. Aceasta filtreaza datele care nu satisfac solutia de filtru, si efectueaza asupra datelor ramase un set de actiuni specificate de utilizator. Când se identifica o linie în fisierul de jurnal care satisface conditia specificata de utilizator o

poate salva, sau notifica administratorii. Solutia ofera suport pentru executarea unui set

de actiuni, cât si pentru ignorarea evenimentelor duplicate. Deoarece examineaza secvential evenimentele, functia de corelatie temporara lipseste în acest caz .

3.3.2 Logsurfer este o solutie mai eficienta care permite schimbarea dinamica a regulilor în timp sau în functie de contextul evenimentelor identificate. Solutia permite o multitudine de optiuni ce asigura un grad ridicat de flexibilitate, cum ar fi: specificarea de exceptii,setare de timeout pentru reguli, specificarea de secvente de identificare care pot fi ignorate, trimiterea rezultatelor prin email catre anumite masini, etc. Logsurfer+ este o

extensie care permite generarea de alerte când se detecteaza lipsa de mesaje si

permite de asemenea specificarea unui numar minim de evenimente care trebuie

identificate pentru a genera o alerta. Aceasta ultima facilitate poate fi folosita pentru

identificarea starilor anormale, însa este necesara o evaluare prealabila din partea

utilizatorului pentru determinarea acestui prag de anomalie.

3.4 Monitorizarea integritatii sistemelor (detectia rootkit)

Monitorizarea integritatii sistemelor are ca obiectiv detectia aplicatiilor malitioase de tip rootkit. Aceasta categorie de malware permite acces privilegiat si permanent asupra

unui sistem, ascunzând în acelasi timp prezenta sa prin modificarea unor functii de

baza ale sistemului de operare sau a altor aplicatii. În mod uzual, atacatorul va instala

un rootkit în faza de preluare a controlului asupra sistemului, care îi va permite

mascarea intruziunii, precum si mentinerea accesului privilegiat la sistem prin ocolirea

mecanismelor normale de autentificare sau autorizare. Detectia rootkit-urilor este dificil

de realizat, deoarece acestea sunt capabile sa schimbe functiile sistemului care sunt

utilizate în procesul de identificare a aplicatiilor malitioase.

Detectoarele de tip Rootkit existente în momentul de fata ruleaza local pe sistemul

monitorizat, în mod similar tehnologiilor de tip antivirus.

3.5 Detecția bazată pe semnături

Aceasta este cea mai simpla tehnica utilizata în principal de aplicatiile de tip antivirus.

O semnătură este un model care corespunde unei amenințări cunoscute. Detecția pe bază de semnături consta în compararea unui eveniment cu un anumit tip de comportament cunoscut. Sistemul compară semnătura evenimentului cu semnăturile cunoscute din bază de date. Dacă acestea se potrivesc, atunci se declanșează automat o politica de securitate sau o regula bine stabilită pentru acel tip de semnătură. De exemplu o încercare de telnet cu un nume de utilizator de "root", poate reprezenta încălcarea politicii de securitate a unei organizații sau un e-mail cu subiectul "Poze!" și cu un fișier atașat de tip executabil sun caracteristicile unei forme de malware.

Detecția pe bază de semnătura este foarte eficientă în detectarea amenințărilor cunoscute, dar în mare parte ineficiente la detectarea amenințărilor necunoscute anterior, sau în amenințările deghizate prin utilizarea de tehnici de evaziune.

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.

3.6 Detecția bazată pe integritate

Aceasta tehnica este utilizata pentru a crea o suma de verificare a obiectelor (fisierelor, zone de memorie) care se stocheaza apoi într-o baza de date. Periodic integritatea acestor obiecte sistem se verifica prin recalcularea sumei de verificare si compararea cu cea înregistrata initial în baza de date. Avantajul acestei tehnici fata de cea bazata pe semnatura consta în posibilitatea de a detecta tipuri necunoscute de rootkit.

Implementarile în care obiectele monitorizare sunt doar fisiere, corespund cazului descris în sectiune monitorizarii integritatii fisierelor.

SVV (System Virginity Verifier) este un verificator de integritate a memoriei care

compara componentele Windows utilizate în mod frecvent (de exemplu tabelele de

functii IRP, IDT, SSDT) cu o stare anterioara de referinta valida. Acesta utilizeaza de

asemenea componente euristice pentru a contoriza numarul de evenimente fals

pozitive generate de aplicatii autorizate precum software-ul antivirus ce ruleaza pe

system.

3.7 Detectoare de tip crossview

Tehnica a fost propusa initial de Microsoft în proiectul Ghostbuster [Wan05] si permite detectia rootkit-urilor ascunse în diferite nivele între spatiul utilizator si cel kernel prin combinarea unor seturi variate de interogari ce confera perspective multiple asupra sistemului. Implementarile existente au la baza doua tipuri de scanari :

Scanare inside the box – permite obtinerea unei perspective de nivel utilizator prin interogarea API-urilor de enumerare OS, care se compara cu o alta perspectiva generata prin inspectarea directa a structurilor de date kernel. O diferenta între rezultatele nivelului utilizator si cel kernel indica prezenta rootkitului între aceste 2 spatii. Implementarile Revealer (Microsoft) si Blacklight (FSecure) utilizeaza acest tip de scanare pentru detectia proceselor si fisierelor ascunse.

Scanare outside the box – compara rezultatul unei perspective de nivel kernel obtinuta pe sistemul verificat, cu rezultatul unei perspective similare, obtinute pe un sistem neinfectat. O modalitate de a obtine un sistem neinfectat este de a reboota sistemului monitorizat si încarca un kernel neinfectat (utilizând un mediu extern). O diferenta între aceste doua perspective indica prezenta rootkit-ului la nivel kernel. Eficacitatea acestei tehnici de detectie depinde în mare masura de modul de implementare a solutiei. O implementare pentru sisteme de tip Windows ce utilizeaza acest tip de scanare este Klister

3.8 Detectoare bazate pe comportament

Interceptarea apelurilor de functii, mesajelor sau evenimentelor transferate între

componentele software, poate constitui mijlocul prin care se poate modifica

comportamentului sistemului de operare sau aplicatiilor. În literatura de specialitate,

codul care se ocupa cu interceptarea apelurilor de functii, mesajelor sau evenimentelor

se numeste hook.

3.8.1 VICE este un detector de rootkit pentru Windows care verifica punctele de interceptare ale proceselor din spatiul utilizator cât si din cel kernel. VICE instaleaza un driver care scaneaza kernel-ul pentru identificarea elementelor de interceptare. Politica utilizata în cautarea punctelor de interceptare la nivel proces este bazata pe principiul conform caruia fiecare pointer de functie trebuie sa rezolve catre o adresa de cod în spatial procesului sau al kernelui. În cautarea punctelor de interceptare în spatiul kernel, VICE verifica urmatoarele structuri de date kernel :

Tabelele IDT (Interrupt Descriptor Table) si SSDT (System Service Descriptor Table) pentru a confirma ca pointerii de functie rezolva catre spatiul de cod kernel.

Tabelele de functii IRP (I/O Request Packet) în drivere si verifica daca acestea pointeaza catre zone de cod din spatiul driverului.

Tabele IAT(Import Address Table) si EAT (Export Address Table) din spatiul

procesului pentru a identifica prezenta unui element de interceptare.

Totusi VICE are o rata mare de alarme false, deoarece multe aplicatii Windows

încorporeaza în constructia lor principii de interceptare.

3.8.2 Patchtfinder utilizeaza o metoda de creare a profilului caii de executie la momentul rularii. Idea acestei solutii are la baza observatia ca rootkitul trebuie sa adauge cod la o anumita cale de executie pentru efectuarea unor activitati aditionale. Acesta

utilizeaza trasatura procesoarelor X86 de contorizare a numarului de instructiuni

executate.

Tehnica are câteva limitari în ceea ce priveste:

Performantele sistemului – modul de executie al procesorului va necesita oprirea

rularii dupa fiecare instructiune si apelarea unei rutine de întrerupere de serviciu

pentru actualizarea contorul de instructiune.

Acuratetea alertelor – metoda conduce catre un comportament nedeterminist

când este utilizata în sisteme de operare complexe (precum Windows) datorita

întrepatrunderilor cailor de control, ceea ce conduce catre alarme false

3.9 Detecția bazată pe anomalii

Analizatorul determină ce înseamnă un trafic normal pentru rețea și orice alt trafic care nu se înscrie în categorie este marcat ca fiind suspicios. Profilurile sunt dezvoltate în urma monitorizării caracteristicilor tipice de activitate pe o perioadă de timp. Un profil pentru o rețea ar putea arăta că activitatea Web cuprinde o medie de 13% din lărgimea de banda de Internet . Dacă acesta lărgime de banda creste, sistemul alertează un administrator. Se pot crea profiluri cum ar fi numărul de e-mail-urile trimise de către un utilizator, numărul de încercări de autentificare eșuate, nivelul de utilizare al procesorului pe un sistem de calcul intr-un anumit interval de timp.

Principalul beneficiu al acestui tip de detecție este că poate fi foarte eficientă în detectarea amenințărilor necunoscute anterior. Un profil este generat inițial pe o perioadă mare de timp (zile, uneori săptămâni). Aceasta perioada este numita perioada de formare..

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.

4. Stateful Protocol Analysis

Stateful Protocol Analysis este procesul de comparare a profilurilor de trafic pentru fiecare protocol. Spre deosebire de detecția bazată pe anomalii , care utilizează calculatorul gazdă sau rețeaua pentru a genera profiluri de activitate și trafic, Stateful Protocol Analysis se bazează pe analiza de trafic conform specificațiilor producătorului a celui protocol de comunicare. Orice ieșire din tiparul standard de comunicare al protocolului , sistemul se alertează.

Această analiză a protocolului poate identifica secvențe de comenzi neașteptate sau comenzi ce nu corespund din punct de vedere cronologic cu specificațiile de comunicare ale protocolului.

Principalul dezavantaj al analizei protocolului de comunicare este faptul ca necesita foarte multe resurse de sistem, în special procesor și memorie RAM. Un al dezavantaj îl reprezintă faptul ca aceasta analiza nu poate detecta atacurile care nu încalcă caracteristicile general acceptabile ale protocoalelor de comunicare.

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

Această metodă de analiză este o consumatoarea foarte mare de resurse, din cauza complexității analizei realizate și supraîncărcarea ce rezultă din urmărirea simultană a mai multor sesiuni.De altfel, acest fapt reprezintă și dezavantajul principal al acestei metode. O altă problemă serioasă este aceea că atacurile care nu încalcă caracteristicile de comportament general acceptat al protocolului nu sunt detectate(ex: efectuarea mai multor acțiuni benign î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.

5. Monitorizarea integritatii fisierelor

Aceasta categorie de monitorizare este capabila sa identifice si raporteze modificari neautorizate asupra fisierelor. Se utilizeaza pentru protectia fisierelor critice (fisiere binare aplicatie, sau fisiere de configurare a aplicatiilor si serviciilor) si care se considera a fi statice între activitatile de actualizare a sistemului sau a configuratiilor acestuia. Aceasta tehnica stabileste în prealabil o suma de verificare a fisierelor care se stocheaza într-o baza de date, dupa care verifica integritatea fisierelor monitorizate prin recalcularea sumei de verificare si compararea cu cea înregistrata initial în baza de date.

O implementare reprezentativa pentru aceasta clasa o reprezinta aplicatia Tripwire, al carei principiu de functionare se regaseste si în alte implementari cum ar fi AFICK.

În prima faza se creeaza politica de monitorizare a integritatii prin identificarea fisierelor si directoarelor ce trebuie monitorizate, si stabilirea regulilor de identificare a

intruziunilor si a nivelului de verificare a integritatii sistemului – atributele de fisier ce vor

fi monitorizate cum ar fi: dimensiune, id utilizator, id group, timp ultim acces, timp ultima modificare, numar de legaturi, numar iNode, permisiuni, etc.. Apoi, se initializeaza baza de date care pastreaza informatii despre starea de referinta a fisierelor ce vor fi monitorizate

Pe durata monitorizarii se va compara informatia de referinta (din baza de date) cu atributele de stare actuala ale fisierului, iar în caz de discrepanta se genereaza un

raport sau o alerta.

Pentru o securitate sporita a mecanismului de monitorizare a integritatii, Tripwire

cripteaza si semneaza propriile fisiere utilizând doua chei criptografice pentru a detecta

daca a fost compromis :

Cheia de site – protejeaza fisierul de politica si cel de configurare

Cheia locala – protejeaza baza de date si rapoartele de discrepanta generate.

Pe lânga utilitatea în descoperirea intruziunilor si a breselor de securitate,

monitorizarea integritatii fisierelor poate servi si la eficientizarea altor procese din

organizatie cum ar fi managementul modificarilor si asigurarea conformitatii cu politica

de securitate .

6. Detectia intruziunilor cu sisteme capcana (honeypot)

Honey-pots reprezinta o tehnica flexibila utilizata în principal de companiile de produse antivirus si agentii guvernamentale pentru culegerea de informatii despre noile tipuri de amenintari.

În principiu, se monitorizeaza un spatiu de adrese neutilizat în activitatea

normala (numit în literatura de specialitate si “Black Hole”), iar identificarea de trafic

destinat catre acest spatiu reprezentând un atac în curs de desfasurare.

Spre deosebire de sistemele de detectie clasice, al caror rol este de a identifica

intruziuni în curs de desfasurare pentru a le stopa, sistemele capcana au fost create

pentru a capta atacurile directionate asupra organizatiei, protejând sistemele reale si

oferind totodata informatii despre atacatori si metodele folosite.

Performanta unui honeypot depinde de modul de adresare în cadrul implementarii a unor probleme pe care le poate prezenta un astfel de sistem, cum ar fi:

Identificarea. Sistemele de tip capcana ofera mai multa sau mai putina interactiune si pot raspunde mai multor obiective cum ar fi încetinirea propagarii atacurilor pe baza de viermi, detectarea acceselor neautorizate, colectarea de informatii despre atacatori.

Valoarea sistemelor capcana este diminuata daca identitatea lor reala este divulgata.

Odata detectat, un atacator poate sa evite sistemul capcana, sau sa-l alimenteze cu

informatii false, derutante. Exceptând cazul când o organizatie face cunoscut faptul ca

utilizeaza sisteme capcana pentru a descuraja atacurile asupra sistemelor sale, este

important ca sistemul capcana sa nu fie detectabil. Chiar daca este identificat, el poate

avea un rol în infrastructura de securitate, semnalând atacul asupra retelei interne prin

actionarea unei alarme. În cazul în care se doreste mai mult decât atât, colectarea de

informatii despre atacator si metodele folosite, programul pentru emularea capcanei

trebuie modificat. Cu cât comportamentul sistemului „capcana” este modificat mai mult

fata de parametrii impliciti definiti de producator, determinând raspunsuri neasteptate

de atacatori, cu atât scad sansele ca identitatea acestuia sa fie relevata.

Exploatarea. Chiar si în cazul unor sisteme capcana cu interactiune scazuta, ce nu

ofera un sistem real ce poate fi compromis, ci emuleaza doar niste servicii, exista riscul

ca aceste sisteme sa fie compromise. Din acest motiv se impune o securizare maxima

sistemului de operare, pe care este instalata aplicatia capcana, prin aplicarea

patchurilor si modificarea parametrilor impliciti de acces: servicii, conturi, parole,

resurse partajate în retea. Ca masura suplimentara este recomandata instalarea unui

firewall local pe masina care ruleaza aplicatia capcana. Sistemele capcana cu nivel

ridicat de interactiune, care ofera un mediu real la dispozitia atacatorilor trebuie

protejate prin sisteme externe de protectie: limitarea benzii de comunicatie, instalarea

unui sistem de detectare a intruziunilor, monitorizarea atenta a tuturor actiunilor

întreprinse asupra sistemului capcana.

Relevanta. Majoritatea atacurilor, mai ales cele venite din exterior prin Internet

sunt efectuate prin instrumente automate care încearca sa exploateze vulnerabilitati publice.

Aceste atacuri pot fi relativ usor contracarate prin aplicarea unor masuri elementare de securitate cum ar fie modificarea parametrilor impliciti de acces, instalarea unui firewall si a unui sistem de detectare a intruziunilor. Amenintarea serioasa o prezinta atacurile lansate de persoane cu cunostinte avansate, care au informatii despre vulnerabilitati înca nedescoperite de producatorii de software, si pentru care nu exista patchuri disponibile.

Pentru a surprinde astfel de atacuri este necesara ajustarea particulara a sistemului „capcana” pentru fiecare tip de atac ce se doreste a fi capturat. De exemplu, pentru a depista si demonstra o eventuala frauda de date (cum ar fi efectuarea unei copieri neautorizate de numere de carti de credit), activitatile detectate de scanare a retelei si penetrarea sistemului de acces la serverul capcana nu identifica implicit si tentativa de furt a datelor. Aceasta tentativa de frauda nu va fi captata daca sistemul capcana nu simuleaza valoarea cautata de infractor: baza de date centrala a sistemului de carti de credit. Rezolvarea acestui impediment, a lipsei de relevanta a informatiilor oferite de capcana, va necesita particularizarea sistemului capcana astfel încât sa poata obtine probe solide (si din punct de vedere juridic) în ceea ce priveste scopul atacatorului.

O tehnică recentă de luptă cu atacatorii rețelelor constă în întinderea de curse de trei tipuri:

– momeli: crearea unui cont special de utilizator cu o parolă simplă(user: guest, password: guest); orice atacator care se conectează la acest cont este atent monitorizat;

– capcane: instalarea și configurarea unui sistem de operare cu cele mai cunoscute deficiențe și vulnerabilități de securitate, ușor de găsit, pentru a-i prinde pe intruși;

– honeypot(borcanul cu miere).

Un sistem Honeypot(borcanul cu miere) are rolul de a atrage și prinde în capcană pe acei atacatori(hackeri, crackeri, script kiddies, etc.) care încearcă să penetreze rețele și sisteme de calcul prin scanări, sondări și intruziuni. Este un dispozitiv soft și/sau hard pasiv, care are rolul de a se lăsa sondat, scanat, atacat, compromis.

Scopurile implemetării unui Sistem Honeypot într-o rețea sunt următoarele:

– distragerea atacatorilor de la atacarea unor resurse mult mai valoroase ale rețelei;

-avertizarea anticipată asupra scanărilor, tentativelor de intruziune și noilor atacuri;

– examinarea profundă a activităților efectuate de un atacator în timpul și după exploatarea Sistemului Honeypot;

– definirea profilului atacatorului și stabilirea tehnicilor utilizate de acesta;

– folosirea învățămintelor pentru astuparea breșelor de securitate din rețeaua reală;

– verificarea eficienței proiectului și politicii de securitate a rețelei.

Instalarea sistemelor Honeypot trebuie facuta astfel încât:

– să fie suficient de protejate, astfel încât să fie atractive pentru atacatori;

– să nu fie tare fortificate pentru a permite efectuarea diferitelor tipuri de atacuri asupra lor și nu asupra altor resurse ale rețelei;

– să fie instalate în zonele DMZ(Demilitarisation Zone) ale rețelelor și să nu apară în înregistrările DNS și/sau WINS;

– folosind firewall-uri, să se creeze un set de reguli în jurul SH care să permită întregul trafic de intrare dinspre Internet spre SH, dar să permită doar traficul de ieșire de tip FTP, ICMP și DNS;

– să nu facă parte din partea productivă a rețelei și să fie instalate pe sisteme singulare, pentru a proteja restul rețelei.

Sistemele de tip "Honeypot" reprezintă capcane pregătite să detecteze, să respingă sau să contracareze intr-o anumita măsura încercările de utilizare neautorizata a sistemelor de calcul. Aceste sisteme pot aduce riscuri în cadrul unei rețele, și trebuie administrate cu atenție. Dacă nu sunt protejate în mod adecvat, un atacator le poate folosi pentru a accesa resursele rețelei. Are natura unei “ capcane” și de cele mai multe ori consta intr-o resursa informatica (document, bază de date, serviciu de rețea, server etc.) Aceasta resursa este doar în aparenta parte a sistemului, ea fiind izolata și protejata.

Un sistem "Honeypot" este alcătuit dintr-un sistem de calcul individual, o colecție de date sau un segment de rețea izolat care pare să facă parte dintr-o rețea legitima, neprotejat și fără monitorizare, și care pare să conțină date sau resurse valoroase pentru potențialii atacatori. Un sistem "Honeypot" care este mascat sub forma unui sistem "Proxy" fără protecție, poarta denumirea de "sugarcane" (acadea).

Sistemul "Honeypot" nu trebuie poziționat pe un segment de producție din cadrul rețelei interne al organizației, și nu trebuie să "vadă" trafic sau activități legitime. Tot ceea ce sistemul "Honeypot" interceptează poate fi clasificat ca malițios sau neautorizat. O aplicație practica în care poate fi folosit sistemul "Honeypot" este de mascare intr-un sistem de tipul celor abuzate de SPAM-eri putând identifica cu o corectitudine de 100% datele infectate cu SPAM. Sistemul "Honeypot" nu necesita capabilități de recunoaștere a SPAM-ului, și nici un filtru de separare a mesajelor obișnuite de cele de tip SPAM. Mesajele normale de posta electronică nu vor ajunge niciodată intr-un sistem "Honeypot".

6.1 Amplasamentul sistemelor "Honeypot"

In funcție de locul în care sunt plasate, sistemele "Honeypot" se clasifică in:

sisteme de producție (production honeypots);

sisteme de cercetare (research honeypots).

Sistemele "Honeypot" de producție sunt ușor de administrat, capturează numai o cantitate limitata de informații, și sunt folosite în principal de companii și corporații. Aceste sisteme sunt plasate în interiorul rețelei de producție pentru a putea îmbunătăți starea generală de securitate. În mod normal sistemele "Honeypot" de producție sunt ușor de întreținut deoarece nu necesită prea mult timp de interacțiune umană. Acest tip de sisteme furnizează mai puține informații despre atacuri sau atacatori decât sistemele "Honeypot" de cercetare. Scopul acestor sisteme este de a ajuta la reducerea riscurilor de securitate în interiorul unei companii, adăugând valoare masurilor de securitate deja implementate.

Sistemele "Honeypot" de cercetare sunt rulate de organizații de cercetare bazate pe voluntariat și non-profit sau instituții educaționale pentru colectarea de informații legate de motivele și tacticile pe care comunitatea de "Blackhat" le aplică în cadrul rețelelor. Aceste sisteme nu adăugă valoare în mod direct unei anumite organizații, în schimb sunt folosite pentru a cerceta amenințările la care sunt supuse organizațiile, și pentru a învăța cum anume trebuie să se protejeze de atacuri. Ar trebui privite ca o sursa de "contra-informații", principalul scop fiind să strângă informații despre atacatori. Aceste informații sunt apoi folosite pentru a proteja rețeaua împotriva respectivelor amenințări. Sistemele "Honeypot" de cercetare sunt complexe din punct de vedere al implementării și al mentenanței, capturând cantități mari de date.

6.2 Avantajele utilizării sistemelor Honeypot:

– flexibilitatea: pot lua diferite forme (serviciu de rețea emulat, bază de date, server de diferite tipuri, doar componentă a unui sistem de operare, un simplu daemonhoneyd, etc.);

– volum scăzut de informații: colectează date numai atunci când interacționează cu activități neautorizate;

– nu interacționează cu utilizatorii obișnuiți;

– generează relativ puține alarme false, deoarece honeypot-ul interacționează doar cu activitățile neautorizate (încercările de atac).

Limitele sistemelor Honeypot:

– un sistem Honeypot fraudat devine o treaptă în compromiterea rețelei din care face parte; deci SH trebuie să fie bine protejate;

– sunt specializate pe un anumit tip de interacțiune cu atacatorii(exemplu:conexiunile HTTP, SMTP);

– complexitatea sistemelor Honeypot aduce posibilități de exploatare(penetrare) suplimentare;

– întreținerea SH de către administratorul de securitate este o activitate laborioasă și sensibilă,

– sunt ușor detectabile, deoarece au un comportament constant, predictibil.

În prezent sunt concepute sisteme Honeynet, cu următoarele caracteristici:

– sunt întregi rețele capcană formate din sisteme reale;

– sunt structurate pe nivelele modelului de referință ISO/OSI și pe toate nivelele modelului TCP/IP;

– se utilizează în activitatea de cercetare, activități militare și guvernamentale;

– se folosesc pentru a studia metodele și instrumentele de atac;

– urmăresc și înțelegerea diferitelor motivații ale atacatorilor și comportamentele lor;

– sunt izolate, protejate și atent supravegheate.

In concluzie, prin aplicarea tehnicii Honeypot se asigură un nou strat al securității rețelei de calculatoare.

Se recomandă implementarea sistemelor Honeypot în conjuncție cu alte tehnici de securitate cunoscute, cum sunt sistemele firewall și sistemele proxy.

Sistemele Honeypot, Honeyd și Honeynet sunt tehnici de securitate viabile, dar nu sunt un panaceu universal la problemele de securitate în rețea. Ele se constituie numai într-un strat suplimentar pentru asigurarea securității rețelelelor de calculatoare.

6.3 Clasificarea honeypot-urilor:

După gradul de activitate care este permisa cu atacatorul:

honeypot-uri cu interacțiune scăzuta, care emulează servicii de rețea sau componente ale unui sistem de operare (ușor de instalat, mai sigure, dar colectează mai puține informații)

honeypot-uri cu interacțiune sporita, care simulează toate aspectele unui sistem de operare (pot fi integral compromise, permițând efectuarea altor atacuri; colectează cantități mari de informații);

După modul de conectare la Internet

honeypot-uri fizice, care constau intr-o mașina conectata la rețea, având propria adresa IP

honeypot-uri virtuale, care sunt simulate de o singura mașina, care răspunde la traficul efectuat către ele

7. Tehnologii de scanare a vulnerabilitatilor

Scanarea vulnerabilitatilor are la baza conceptul scanarii de porturi. Scanerul de

vulnerabilitati identifica statiile active si porturile deschise pe acestea, furnizând însa si

informatii cu privire la vulnerabilitatile asociate. Scanerele de vulnerabilitati furnizeaza

urmatoarele capabilitati :

Identificarea statiilor active din retea

Identificarea serviciilor active si vulnerabile ale unei statii

Identificarea sistemelor de operare si a vulnerabilitatilor asociate acestora

Identificarea setarilor eronate

Stabilirea unei baze pentru testul de penetrare

Dintre beneficiile utilizarii acestora de catre organizatie se amintesc :

Reprezinta instrumente proactive pentru identificarea propriilor vulnerabilitatilor înaintea atacatorilor

Ofera informatii cu privire la modalitatea de eliminare a vulnerabilitatilor

descoperite

Reprezinta un mijloc relativ rapid si usor de utilizat cu ajutorul caruia se poate cuantifica gradul de expunere la vulnerabilitati al organizatiei

Identifica versiunile software ce trebuie actualizate, si în conjunctie cu

instrumentele de management al patch-urilor se determina actualizarile

necesare

Valideaza conformitatea cu politica de securitate a organizatiei în ceea ce

priveste aplicatiile instalate, serviciile active, configuratiile sistemelor, etc.

Dintre limitarile scanerelor de vulnerabilitati se amintesc :

Genereaza un volum de trafic de retea mult mai mare scanerele de porturi, ceea ce necesita o planificare si utilizare adecvata pentru a nu avea impact negative asupra activitatilor operationale ale organizatiei.

Necesita actualizari constante ale bazei de date cu vulnerabilitati pentru a putea recunoaste vulnerabilitatile recente. Astfel, în alegerea scanerului de vulnerabilitati trebuie avut în vedere frecventa cu care actualizarile sunt disponibile

Ineficiente în ceea ce priveste detectia noilor tipuri de vulnerabilitati

Pentru o organizatie tipica, practicile de securitate operationala curente recomanda:

Scanarea de vulnerabilitati a statiilor la cel mult trei luni pentru sistemele fara importanta critica pentru organizatie si infrastructura, si scanarea în regim continuu (monitorizarea permanenta) a sistemelor critice (firewall-urilor, baze de date, etc).

Folosirea mai multor tipuri de scanere de vulnerabilitati. O solutie poate fi o combinatie de scaner comercial si unul bazat pe surse deschise.

Rezultatele obtinute în urma scanarii vulnerabilitatilor trebuie documentate, iar

deficientele descoperite trebuie remediate dupa cum urmeaza:

Actualizarea sau aplicarea de patch-uri de urgenta sistemelor vulnerabile pentru eliminarea vulnerabilitatilor

Deconectarea statiile neautorizate si dezactivarea serviciilor neutilizate

Impunerea de controale de limitare a accesului la serviciile vulnerabile (la nivel de firewall, si statie), în cazul în care remedierea necesita timp, iar serviciul nu poate fi oprit.

Revizuirea controalelor de securitate pentru a asigura o rata de vulnerabilitati scazuta.

Unul din cele mai eficiente instrumente ce poate fi utilizat pentru scanarea de porturi si care poseda si elemente de baza în scanarea vulnerabilitatilor este Nmap .

7.1 Nmap

suporta o gama variata de tehnici de scanare (ICMP, TCP, UDP), oferind totodata posibilitati avansate de identificare a protocolului serviciilor, a adreselor IP, scanare ascunsa, si analize de filtrare a traficului. Scanarile Nmap se desfasoara în

mai multe faze secventiale dupa cum urmeaza :

Prescanari de scripturi – motorul de scripting Nmap (MSN) utilizeaza o colectie de scripturi special destinate obtinerii de informatii aditionale despre sistemele tinta. Este activata de optiunea –s C si are loc doar când scripturile necesare sunt selectate (exemple de astfel de scripturi sunt: dhcp-discover si broadcastdns- service-discovery, care utilizeaza interogari de tip broadcast pentru a obtine informatii de la serviciile standard de retea).

Enumerarea tintei – pe baza specificatorilor de statie oferiti (poate fi combinative de DNS, adrese IP, notatie CIDR), Nmap genereaza lista adreselor IP care vor fi scanate.

Descoperirea statiilor – scanarea începe prin descoperirea statiilor active care astfel vor necesita o investigatie mai amanuntita. Acest proces este numit descoperire statie (sau scanare ping). Nmap utilizeaza tehnici multiple de descoperire cum ar fi cereri ARP, sau combinatii de interogari mai elaboratebazate pe TCP si ICMP.

Rezolutia DNS inversa – dupa determinarea statiilor ce se vor scana, vor obtine numele DNS inverse ale tuturor statiilor active identificate de scanarea ping.

Scanarea porturilor – este componenta principala a Nmap. Raspunsurile (sau lipsa de raspuns) asociate sondarilor trimise sunt utilizate pentru clasificarea starii porturilor (deschis, închis sau filtrat) de pe statia tinta.

Detectia versiunii – pentru porturile care au fost deschise, Nmap poate trimite o varietate de probe pentru a determina versiunea de software care ruleaza pe statia tinta, verificând raspunsurile receptionate pe baza unei baze de date de semnaturi de servicii cunoscute.

Detectia sistemului de operare – are la baza caracteristici specifice de

implementare ale standardelor de retea în diverse sisteme de operare. Pe baza masurarii acestei diferente este adesea posibila determinarea sistemului de operare care ruleaza pe statia tinta.

Traceroute – Nmap contine o implementare optimizata de traceroute, identificând în paralel rutele de retea pentru mai multe statii pe baza celor mai bune pachete de sondare generate în fazele de descoperire anterioare.

Scripturi de scanare – majoritatea scripturilor motorului de scripting vor fi rulate în aceasta faza, si au ca rol detectarea vulnerabilitatilor serviciilor, identificarea de Malware, colectarea de informatii aditionale din bazele de date si alte servicii de retea, precum si detectia avansata a versiunii.

Rezultatele de iesire – Nmap colecteaza toate informatiile obtinute si le salveaza într-un fisier sau le afiseaza pe ecran.

7.2 Nessus

Este un pachet de testare a vulnerabilitatilor ce poate realiza teste automate

asupra unor retele tinta, incluzând scanari ICMP, TCP si UDP, testarea unor servicii de

retea (Apache, MySQL, Oracle, Microsoft IIS, si altele), precum si capacitati de

raportare a vulnerabilitatilor identificate . Nessus este unul dintre cele mai

utilizate instrumente de scanare si testare a retelelor. Nessus are doua componente

(demon si client) ce lucreaza intr-o maniera distribuita permitând astfel un management

si control eficient. Rapoartele generate de Nessus sunt usor de înteles, concise

continând uneori alerte de tip “false pozitive”, astfel fiind necesar ca personalul de

securitate sa parcurga manual raportul necesitând totodata un înalt nivel de cunostinte

si experienta.

7.3 Metasploit Framework (MSF) este o platforma avansata de tip sursa deschisa pentru dezvoltarea, testarea si utilizarea de programe de tip “exploatare”. Initial proiectul a pornit ca un joc de retea, dar s-a dezvoltat pe parcurs devenind un instrument puternic folosit în testele de penetrare, dezvoltarea de programe de “exploatare” si cautarea de vulnerabilitati. Mediul si scripturile de exploatare sunt scrise în Ruby si pot rula pe aproape orice sistem de tip Unix si Windows. Sistemul însusi poate fi accesat si

controlat prin intermediul unui interpretor de comenzi sau a unei interfete web .

Dintre pachetele comerciale, cel mai reprezentativ este eEye Retina . Acesta

scaneaza vulnerabilitatile unei retele dispunând de un sistem de management al remediilor prin care descopera si asista la repararea tuturor vulnerabilitatilor de securitate cunoscute într-un sistem. Retina este usor de configurat si include instrumente avansate de raportare pentru a ajuta la izolarea si sistematizarea remediilor necesare. În afara de faptul ca dispune de cea mai completa baza de date de vulnerabilitati cunoscute, Retina dispune si de o tehnologie proprietara numita CHAM (Common Hacking Attack Methods) care emuleaza un comportament de tip hacker pentru penetrarea în adâncime a retelei. În acest fel, Retina poate practice detecta vulnerabilitati ascunse sau necunoscute anterior, oferind cunostintele pentru o securizare mai buna a retelei.

8.Sisteme 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 date dintr-o instituție.

Snort-ul oprește traficul în funcție de anumite reguli. Acestea pot fi scrise în funcție

de necesităț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 dotat cu Snort. În cazul tuturor echipamentelor trebuie blocate toate porturile inutile, iar accesul la portul 80 și 443 să nu se facă direct, ci printr-un proxy cum ar fi Squid, etc.

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

transparență față de utilizatori: 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

fi decodarea ș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

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

8.2.2. NAT – este responsabilă cu translatarea adreselor de rețea.

8.2.3. MANGLE –este responsabilă cu modificarea biților QOS din headerul TCP

Are 2 lanțuri predefinite:

Pre-routing: face NAT atunci când adresa destinație a pachetului trebuie schimbată;

Post-routing: face NAT atunci cand adresă sursă a pachetului trebuie schimbată.

Pentru fiecare regulă firewall creată trebuie specificată tabela și lanțul de care va aparține. La această regulă este o singură exceptie: cele mai multe reguli sunt legate de filtrare, astfel iptables presupune că orice lanț definit fără o tabelă asociată va face parte din tabela filter. Tabela filter este, prin urmare, implicită. Fiecare regulă firewall inspectează pachetele IP și apoi încearcă să le identifice ca și ținte pentru o anumită operație.

Cele mai folosite ținte sunt:

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

DROP : iptables oprește procesarea ulterioară; pachetul este blocat;

LOG: informațiile sunt trimise la daemonul syslog pentru logare; iptables continuă procesarea pachetului;

REJECT: funcționează ca DROP, dar va trimite un mesaj de eroare la gazda care a 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

8.3 Parametri 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

8.4 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:

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

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

verifice pachetul mai rapid;

3. După ce au fost decodate, asamblate și normalizate, pachetele ajung la motorul

principal, undesunt verificate după niște reguli;

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

administratoruluisau aplicațiilor.

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

GET /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-alive

HTTP/1.1 200 OK

Cache-Control: private, no-cache, no-store, mustrevalidate

Expires: Sat, 01 Jan 2000 00:00:00 GMT

P3P: CP="Facebook does not have a P3P policy.

Learn why here: http://fb.me/p3p"

Pragma: no-cache

path=/; domain=.facebook.com; httponly

Content-Encoding: gzip

Content-Type: text/html; charset=utf-8

X-FB-Server: 10.146.68.118

X-Cnection: close

Transfer-Encoding: chunked

Date: Mon, May 2015 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;)

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

Comunicația folosind Https-ul începe cu o negociere de protocol în care se stabilește

cheia de sesiune, după care totul funcț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 siteuri HTTPS pe același IP și să poată identifica din timp ce domeniu este accesat pentru a

furniza certificatul corect.

Astfel î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ă browserul 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 folosesc versiunile 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 protocolului și „ssl_state” folosită la identificarea tipului depachet din handshake-ul SSL(Server Hello, Client Hello, etc).

preprocessor ssl: ports { 443 },

trustservers,noinspect_encrypted

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

Astfel, pachetele vor fi decodate și normalizate și vom putea folosi funcții ale snortului specifice SSL-ului.

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

este:

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

În cazul traficului browser-elor ce folosesc protocoalele TLS1.0,TLS1.1, TLS1.2 și nu implementează 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.

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

singur port, 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

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 pe un port peste 1024.

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

sau primi date. Astfel datele ce trebuiesc filtratevor circula între client și server pe

porturi TCP mai mari decât 1024.

O 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 transferate atât binar cât și în mod asci de aceea cea mai bună regulă este să fie verificat 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.

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

următoarea:

reject tcp any any ->any 25 (msg:"SMTP topsecret string";

content:"topsecret"; classtype:policy-violation; sid:1000005;

rev:1;)

Problema vine atunci când vrem să transmitem și date care nu sunt text, cum ar fi un

executabil. Pentru a trece peste acestă problemă a apărut MIME(Multipurpose Internet Mail

Extensions) în care sunt definiteniște standarde pentru codarea binar-text, cea mai populară

astfel de codare fiind base64. Astfel oricemail cu attachment binar, va fi transformat în

base64 și apoi trimis.

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

––=_NextPart_000_0061_01CC1B24.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

8 biti 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, și apoi 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:

Conform alfabetului Base64 vom avea:

Alfabetul Base64

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:policyviolation;sid:1000006; rev:1;)

9.Instalarea și configurarea unui sistem HIDS

Pentru instalare s-a folosit o mașină virtuala VMWARE compusa din două hard-disk-uri și o placa de rețea „Bridget” cu cea instalata fizic. Pe primul disk s-a efectuat o instalare noua de Windows XP SP2. Discurile sunt formatate cu sistemul de fișiere NTFS. Prima partiție este alocata în întregime sistemului de operare iar cea de-a două partiție este alocata software-ului pentru IDS. După instalarea sistemului de operare s-au dezinstalat componente Windows ce nu sunt necesare. Au fost închise câteva servicii ne utile dar care pornesc automat. Windows Firewall dezactivat. Placa de rețea configurata în mod DHCP.

` Pentru adresa în interfața web s-a modificat fișierul hosts din directorul „C:\Windows\system32\drivers\etc„ , cu 127.0.0.1 windis

9.1 Platforma folosită

Există mai multe pachete de software, care produc această topologie. Am mers pe platforma Microsoft pentru o mai mare ușurința în instalare și configurarea software-ului.

IIS Web Server: serverul de web Microsoft care găzduiește consola BASE

Snort: este un program gratuit(open source), scris de Martin Roesch, dezvoltat in prezent de Sourcefire. Snort este un sistem de detectare a intruziunii, capabil de captura în timp real a traficului de pe rețea și stocarea capturilor în fișiere .log.

Snort efectuează analize de protocol, căutarea de conținut / de potrivire, și este frecvent utilizat pentru a bloca în mod activ sau pasiv,pentru a detecta o varietate de atacuri, cum ar fi depășirile de buffer, scanarea de porturi stealth, atacuri de aplicatii web, atacuri CGI.

Combinând beneficiile semnării, protocol și de inspecție anomalie,Snort este un instrument foarte puternic și este cunoscut a fi unul dintre cele mai bune IDS de pe piață, cu milioane de download-uri și aproximativ 300.000 de utilizatori înregistrați, Snort a devenit standardul de facto pentru IPS.

Arhitectura Snort este axată pe performanță, simplitate și flexibilitate. Există trei subsisteme principale care alcătuiesc Snort: decodor de pachete, motorul de detecție, precum și subsistemul de logare si alertare.

Regulile Snort sunt reguli simple pentru a putea scrie, dar suficient de puternice pentru a detecta o mare varietate de pachete ostile sau doar suspecte in traficul de rețea. Există trei directive de acțiune de bază pe care Snort le poate folosi cand un pachet se potrivește cu un model din norma prevăzută: treci, jurnal, sau de alertă.

Snort va rula pe orice platformă în cazul în care va rula libpcap. Versiunea actuală a Snort este 1.2.1, libpcap este necesar pentru a compila și rula software-ul. Snort poate rula pe RedHat Linux 5.1/5.2/6.0, Debian Linux, MkLinux, S / Linux, HP-UX, Solaris 2.5.1-2.7 (x86 și SPARC), x86 gratuit / net / OpenBSD, NetBSD m68k, și MacOS X.

Să vedem care este diferența dintre Snort si tcpdump. Snort este similar tcpdump, insa este axat mai ales pe aplicațiile de securitate ale pachetelor de sniffing.

Snort decodează stratul de aplicare a unui pachet și poate da reguli pentru a colecta de trafic care are date specifice conținute în stratul de aplicare a acesteia. Acest lucru permite Snort să detecteze multe tipuri de activități ostile, inclusiv a depășirilor de buffer, scanează CGI, sau orice alt pachet de date utile, pachet care poate fi caracterizat într-o amprentă de detectare unica.
Figura 1 prezintă pachete tipice de ieșire Snort pentru o afișare banner telnet, iar Figura 2 prezintă acelasi pachet afișat de/cu tcpdump.

20:59:49.153313 0:10:4B:D:A9:66 -> 0:60:97:7:C2:8E type:0x800 len:0x7D

192.168.1.3:23 -> 192.168.1.4:1031 TCP TTL:64 TOS:0x10 DF

***PA* Seq: 0xDF4A6536 Ack: 0xB3A6FD01 Win: 0x446A

FF FA 22 03 03 E2 03 04 82 0F 07 E2 1C 08 82 04 .."………….

09 C2 1A 0A 82 7F 0B 82 15 0F 82 11 10 82 13 FF …………….

F0 0D 0A 46 72 65 65 42 53 44 20 28 65 6C 72 69 …FreeBSD (elri

63 2E 68 6F 6D 65 2E 6E 65 74 29 20 28 74 74 79 c.home.net) (tty

70 30 29 0D 0A 0D 0A p0)….

Figure 1: Typical Snort telnet packet display.

20:59:49.153313 0:10:4b:d:a9:66 0:60:97:7:c2:8e 0800 125: 192.168.1.3.23 >

192.168.1.4.1031: P 76:147(71) ack 194 win 17514 (DF) [tos 0x10] (ttl 64,

id 660)

4510 006f 0294 4000 4006 b48d c0a8 0103

c0a8 0104 0017 0407 df4a 6536 b3a6 fd01

5018 446a d2ad 0000 fffa 2203 03e2 0304

820f 07e2 1c08 8204 09c2 1a0a 827f 0b82

150f 8211 1082 13ff f00d 0a46 7265 6542

5344 2028 656c 7269 632e 686f 6d65 2e6e

6574 2920 2874 7479 7030 290d 0a0d 0a

Figure 2: The same telnet packet as displayed by tcpdump.

Din momentul in care este inceput atacul, nu dureaza decat cateva secunde pana cand acesta este detectat.

Exemplul A, următor, prezintă o regulă simplă de detectare web, scrisă in cod Snort analog :

Exemplul A

badweb_schema = library_schema:new( 1, ["time", "int", "ip", "ip", "str"], scope());

# list of web servers to watch. List IP address of servers or a netmask

# that matches all. use 0.0.0.0:0.0.0.0 to match any server

da_web_servers = [ 0.0.0.0:0.0.0.0 ] ;

query_list = [ "/cgi-bin/nph-test-cgi?",

"/cgi-bin/test-cgi?",

"/cgi-bin/perl.exe?",

"/cgi-bin/phf?"

] ;

filter bweb tcp ( client, dport: 80 )

{

if (! ( tcp.connDst inside da_web_servers) )

return;

declare $blob inside tcp.connSym;

if ($blob == null)

$blob = tcp.blob;

else

$blob = cat ( $blob, tcp.blob );

while (1 == 1) {

$x = index( $blob, "\n" );

if ($x < 0) # break loop if no complete line yet

break;

$t=substr($blob,$x-1,1); # look for cr at end of line

if ($t == '\r')

$t=substr($blob,0,$x-1); # tear off line

else

$t=substr($blob,0,$x);

$counter=0;

foreach $y inside (query_list) {

$z = index( $blob, $y );

if ( $z >= 0) {

$counter=1;

# save the time, the connection hash, the client,

# the server, and the command to a histogram

record system.time, tcp.connHash, tcp.connSrc, tcp.connDst,

$t to badweb_hist;

}

}

if ($counter)

break;

}

# keep us from getting flooded if there is no newline in the data

if (strlen($blob) > 4096)

$blob = "";

# save the blob for next pass

$blob = substr($blob, $x + 1);

}

badweb_hist = recorder ("bin/histogram packages/test/badweb.cfg",

"badweb_schema" );

Regulile Snort pentru detectarea sondelor web CGI

Exemplul B: Snort rules to detect the same web CGI probes.

alert tcp any any -> any 80 (msg:"CGI-nph-tst-cgi";

content:"cgi-bin/nph-test-cgi?"; flags: PA;)

alert tcp any any -> any 80 (msg:"CGI-test-cgi";

content:"cgi-bin/test-cgi?"; flags: PA;)

alert tcp any any -> any 80 (msg:"CGI-perl.exe";

content:"cgi-bin/perl.exe?"; flags: PA;)

alert tcp any any -> any 80 (msg:"CGI-phf";

content:"cgi-bin/phf?"; flags: PA;)

WinPcap: WinPcap este un tool pt. accesul intr-o rețea în forma link-layer sub Windows. Permite aplicațiilor să capteze și să transmită pachete pe rețea trecând de protocolul stack. în plus include pachete de filtrare kernel precum și un motor cu suport pt. captarea pachetelor la distanta. Acesta este constituit dintr-un driver care extinde sistemul de operare pentru a permite accesul de nivel scăzut intr-o rețea și o librărie care este folosita pentru accesul în straturile de nivel scăzut al unei rețele. Aceasta librărie conține versiunea de Windows al nivelului cunoscut sub numele de libpcap UNIX API.

MySQL server: MySQL este un server de baze de date bazate pe SQL pentru o varietate de platforme și este cea mai susținută platformă pentru stocarea alertelor din Snort. Toate alertele declanșate de la senzori sunt stocate în bază de date MySQL.

ADODB: Biblioteca pentru obiecte PHP.Este probabil, cea mai rapida baza de date open source pentu PHP.Suporta multe facilități de vizitare, cum ar fi sesiuni de baze de date susținute (cu notificarea de expirare sesiune), generare de cod SQL, tabele pivot, SELECT emularea limită pentru toate bazele de date, monitorizarea performanței.

PHP: limbaj de scripting pentru dezvoltare web și poate fi încapsulat în HTML.

BASE (Basic Analysis and Security Engine): BASE este o aplicație cu interfața web pentru vizualizarea alertelor IDS din Snort. Aici toate informațiile senzorilor sunt vizualizate și prelucrate.BASE se bazează pe codul din Consola de Analiză a intruziunilor pentru Baze de date (ACID). Această aplicație oferă un web front-end pentru interogare si analiza alerte provenind dintr-un sistem de Snort IDS.

9.2 Instalare

Toate programele se instalează pe a două partiție. Primul instalat este WinPcap, program disponibil gratuit. Următorul program este Snort care se instalează în d:\win-ids\snort. în directorul Bin se găsește un fișier numit snort.conf. Acest fișier trebuie editat pentru a reflecta cel mai bine configurația viitorului IDS. în prima fază se stabilesc variabilele de lucru ale programului Snort. Se stabilește rețeaua interna cât și cea externa de unde provin atacurile. Pentru testare am folosit clasa C de IP-uri 192.168.1.0./24:

var HOME_NET 192.168.1.0/24

var EXTERNAL_NET! $ HOME_NET

Trebuie de asemenea schimbată calea unde Snort caută fișierele ce conțin Reguli de scanare și de identificare a traficului. Fiind o aplicație scrisă pentru sistemele Linux, Snort are definite în fișierul de configurare căile către directoarele unde s-ar fi instalat standard. După modificarea tuturor căilor de acces către fișierele de configurare, fișierele .log și fișierele ce conțin reguli, se testează Snort prin identificarea plăcilor de rețea instalate. Acest lucru se face folosind comanda Snort –W. Răspunsul este de forma:

Pentru testarea funcționalității, în command prompt tastam Snort –v -2 unde parametrul –v va rula Snort în modul „Verbose” iar –i2 va comuta Snort pentru traficul de pe Interfața de rețea Numărul 2. Aceasta interfața a fost detectata mai cu cu Snort –W. Dacă Snort funcționează, acesta va fi afișa pe ecran capturi ale pachetelor de date prin simpla deschidere a unei pagini web.

9.3 Instalarea Internet Information Services (IIS)

Pentru instalarea IIS în alta parte decât locația standard, vom folosi un fișier de răspunsuri. în acest fișier de răspunsuri specificam faptul ca viitorul director web se va afla pe partiția D:, și ca nu dorim instalarea serviciilor SNMP și NNTP.

[Components]

iis_common = on

iis_inetmgr = on

iis_www = on

iis_smtp = off

iis_nntp = off

[InternetServer]

PathWWWRoot="D:\win-ids\InetPub\wwwroot"

9.4 Rularea utilitarului IISLockdown

IISLockdown este un utilitar dezvoltat de către Microsoft care închide serviciile ce nu sunt necesare în IIS. Acest lucru reduce suprafața de atac disponibilă pentru un atacator sau numărul de posibile atacuri. To provide in-depth defense or multiple layers of protection against an attacker, URLscan, with customized templates for each supported server role, has been integrated into the IIS Lockdown Tool. Pentru a oferi apărare în profunzime sau mai multe straturi de protecție împotriva unui atacator, URLscan, cu template-uri personalizate pentru fiecare rol de server de susținut, a fost integrat în Lockdown IIS Tool. However, to help keep your server secure and to stay protected against known security vulnerabilities, you must install all critical updates. Cu toate acestea, pentru a păstra serverul securizat și protejat împotriva vulnerabilităților de securitate cunoscute, trebuie instalate toate actualizările critice.

All the default security-related configuration settings in IIS versions 6.0 and 7.0 meet or exceed the security configuration settings made by the IIS Lockdown tool. Toate setarile de securitate legate de configurația implicită în versiunile IIS 6.0 și 7.0b trebuie sa îndeplinească sau să depășească setările de configurare de securitate efectuate de instrumentul IIS Lockdown. Therefore, you do not have to run this tool on Web servers that are running IIS version 6.0 or 7.0.However, if you are upgrading from an earlier version of IIS, you should run the IIS Lockdown Tool before the upgrade to enhance the security of your Web server. Cu toate acestea, în cazul în care faceți upgrade la o versiune anterioară a IIS, ar trebui să rulați IIS Lockdown înainte de upgrade pentru a spori securitatea server-ul dvs. Web.

Here is a list of the new features in IIS Lockdown Tool 2.1: Aici este o listă de caracteristici noi în IIS Lockdown 2.1:

Server roles . Server roluri. Version 2.1 is driven by supplied templates for the major IIS-dependent Microsoft products. Versiunea 2.1 este condusă de template-uri furnizate pentru produsele majore IIS dependente de Microsoft. These include Microsoft Exchange Server 5.5 and Exchange 2000 Server, Microsoft Commerce Server, Microsoft BizTalk Server, Microsoft Small Business Server 4.5 and 2000, Microsoft SharePoint Portal Server, Microsoft FrontPage Server Extensions, and SharePoint Team Services. Acestea includ Microsoft Exchange Server 5.5 și Exchange 2000 Server, Microsoft Commerce Server, Microsoft BizTalk Server, Microsoft Small Business Server 4.5 și 2000, Microsoft SharePoint Portal Server, Microsoft FrontPage Server Extensions, iar echipa SharePoint Services.

URLscan integration , with customized templates for each supported server role . URLscan integrare, cu template-uri personalizate pentru fiecare rol de server acceptate. This integration enables the IIS Lockdown Tool to provide additional security enforced by URLscan without requiring the administrator to design a custom URLscan filter for the particular server configuration and application. Această integrare permite IIS Lockdown să furnizeze securitate suplimentară impusă de URLscan fără a solicita administratorului sa proiecteze un filtru personalizat URLscan pentru configurarea serverului special și de aplicație.

Ability to remove or disable IIS services . Capacitatea IIS de a elimina sau dezactiva servicii. Services such as HTTP, FTP, SMTP, and NNTP can be removed or disabled. Servicii, cum ar fi HTTP, FTP, SMTP și NNTP pot fi eliminate sau cu dezactivate.

Support for scripted or unattended installation . Suport pentru instalare scenarii nesupravegheate. The tool can read from an answer file. Instrumentul poate citi dintr-un fișier de răspunsuri.

Reproiectarea Redesigned user interface and fixes . interfeței cu utilizatorul . In response to user feedback, the IIS Lockdown Tool offers an improved user experience. Ca răspuns la feedback-ul utilizatorilor,

IIS Lockdown oferă o experiență de utilizare îmbunătățită.

IIS Lockdown Instrumentul este de fapt un asistent care poate fi utilizat pentru a opri unele dintre părți neutilizate de IIS, care sunt cele mai sensibile la atacul hackerilor.

Atunci When you download the tool, you are prompted for a location to install the files, as shown in Figure A . când se descărca programul, se solicită o locație pentru a instala fișierele, așa cum se arată în Figura A.

Când descărcarea este completă, trei fișiere sunt plasate în directorul specificat .

Executați instrumentul prin dublu-clic IISLockd pentru a apare pe ecran asa cum arată

Click Next and choose either Express Lockdown or Advanced Lockdown ( Figure D ). Faceți clic pe Next si alegeti „Express Lockdown” sau „Advanced Lockdown” (Figura D). If you choose Express Lockdown, you are providing maximum security for a basic Web server. Dacă alegeți Express Lockdown, vi se oferă securitate maximă pentru un server web de bază. With this choice, your Web server displays only static pages and does not use any advanced features, such as Internet printing or Active Server Pages. Cu această alegere, server-ul dvs. Web se afișează numai pagini statice și nu va utiliza alte caracteristici avansate, cum ar fi imprimarea internet sau Active Server Pages.

If you choose Express Lockdown, you'll see the prompt shown in Figure E . Select Yes. Dacă alegeți Express Lockdown, veți vedea afișate prompt în figura E Da. Selectare. Your Web server will be secured, and you can simply view the report. Web server va fi securizat, și puteți vedea, pur și simplu raport.

If you choose Advanced Lockdown, you'll see the prompt shown in Figure F . Dacă alegem Advanced Lockdown, vom vedea afișate prompt în figura F.

This choice allows you to decide whether you want to disable the options shown below. Această alegere vă permite să decideți dacă doriți să dezactivați opțiunile afișate mai jos. (See the IIS Lockdown Tool help file for a detailed description of what these options do and why you might want to disable them.) (A se vedea IIS Lockdown dosar instrument de ajutor pentru o descriere detaliată a ceea ce aceste opțiuni și de ce ați putea dori să le dezactivați.)

Active Server Pages (.asp) Pagini Active Server (. ASP)

Index Server Web Interface (.idq) Index interfata Web Server (. Idq)

Server-Side Includes (.shtml, .shtm, .stm) Server-side includes (. Shtml. Shtm,. STM)

Internet Data Connector (.idc) Internet conector de date (. IDC)

Internet Printing (.printer) Internet Printing (. Imprimantă)

HTR Scripting (.htr) HTR Scripting (. HTR)

When you finish, click Next to bring up the screen shown in Figure G . Here, you can take some additional security steps. Când ați terminat, faceți clic pe Next pentru a aduce pe ecran se arată în figura G. Aici, se pot lua unele măsuri de securitate suplimentare.

This choice allows you to select from the following options: Această alegere permite să selectați din următoarele opțiuni:

Remove Sample Web Files Web Scoateți Exemplu Fișiere

Remove The Scripts Virtual Directory Scoateți Scripturi Virtual Directory

Remove The MSADC Virtual Directory Scoateți directorul virtual MSADC

Disable Distributed Authoring And Versioning (WebDAV) Dezactivează distribuite Authoring Și versiuni (WebDAV)

Set File Permissions To Prevent The IIS Anonymous User Account From Executing System Utilities Setați permisiunile de fișiere Pentru a preveni Contul IIS utilizator anonim de la executing Utilități Sistem

Set File Permissions To Prevent The IIS Anonymous User Account From Writing To Web Content Directories Setați permisiunile de fișiere Pentru a preveni Contul IIS utilizator anonim de la scriere la directoare web de conținut

When you finish selecting options, click Next and then choose Yes to lock down your server. Când ați terminat selectarea opțiunilor, faceți clic pe Next și apoi alegeți Da pentru a bloca serverul. The screen in Figure H will appear. Ecranul din figura H va apărea.

When the process is finished, you can select the View Report Button, as we've done in Figure I . Când procesul este terminat, puteți selecta Vezi Raportul buton, cum este prezntat în figura.

To wind up the process, click Next. Pentru a continua procesul, faceți clic pe Next. When the Completed screen appears ( Figure J ), just click Finish. Când apare ecranul „Completed” (Figura J), faceți clic pe Terminare.

At any time, you can undo your changes by running IISLockd again to access the screen shown in Figure K and then clicking Undo. În orice moment, aveți posibilitatea să anulați modificările prin rularea IISLockd din nou pentru a accesa ecranul din figura K și apoi făcând clic pe Anulare. You can also click Lockdown Again to change your settings. Puteți, de asemenea, faceți clic pe Lockdown din nou pentru a schimba setările.

Going one step further Mergând un pas mai departe ,Now that your IIS Web service is secure, you should look at your other IIS services. acum, că serviciul IIS Web este sigur, ar trebui să ne uitam si la alte servicii IIS. By default, FTP and other related services are not locked down. În mod implicit, FTP si alte servicii conexe nu sunt blocate în jos. You should take the appropriate measures to secure them.Ar ar trebui să se ia măsurile corespunzătoare pentru a le asigura. Finally, test all functionality prior to putting your Web server into production. În cele din urmă, toate funcțiile de testare trebuie finalizate înainte de a pune server-ul de Web în producție. It's also a good idea to browse Microsoft's additional security checklists at Microsoft TechNet and download Microsoft's Network Security Hotfix Checker. Este, de asemenea, o idee bună pentru a căuta la Microsoft liste de control de securitate suplimentare la Microsoft TechNet și a le descărca de laMicrosoft Network Security Hotfix Checker.

9.5 Instalarea și configurarea PHP pentru IIS

Pentru configurarea PHP se folosește fișierul php.ini-dist. La fel ca și în cazul Snort, este necesara schimbarea unor linii din fișierul de configurare:

max_execution_time = 60

Schimbare: display_errors = Dezactivat

include_path = "d:\win-ids\php\pear"

extension_dir = "d:\win-ids\php\ext"

cgi.force_redirect = 0

extension=php_gd2.dll

extension=php_mysql.dll

session.save_path = "c:\windows\temp"

9.6 Configurare IIS pentru PHP

Navigate to the Control Panel, double left-click on 'Administrative Tools', and double left-click on 'Internet Information Services' starting the 'Internet Information Services' applet. În Control Panel, "Administrative Tools", Internet Information Services " la Default Web Site", se adaugă extensia .PHP cu fișierul executabil din" D: \win-ids\php\php-cgi . exe ". După această setare, IIS va deschide paginile web ce au extensia PHP. Pentru testare se copiază pagina test.php în rădăcina directorului wwwroot. în internet Explorer se accesează aceasta pagina, care va afișa setările modului PHP.

9.7 Configurarea Snort să ruleze ca un serviciu

In Command Prompt ne mutam în directorul d:\win-ids\snort\binAt the command prompt type 'cd d:\win-ids\snort\bin' (less the outside quotes) and tap the 'Enter' key.. Se tastează comanda At the command prompt type 'snort /SERVICE /INSTALL -cd:\win-ids\snort\etc\snort.conf -ld:\win-ids\snort\log -K ascii -ix' (less the outside quotes), and tap the 'Enter' key. "Snort / SERVICE / INSTALL –c D: \ win-ids\Snort\etc\snort.conf –l d: \ win-ids\ Snort\log -K ASCII -i2".

Prin aceasta comanda Snort se va instala ca un serviciu și se va regăsi în lista de servicii din Administrative Tools. Parametrul „–c” spune programului unde își găsește fișierul de configurare. Parametrul „-l” specifica directorul unde va salva log-urile. Parametrul „-K” reprezintă formatul în care acesta le va salva (ASCII). „-i” reprezintă parametrul pentru Snort care precizează care dintre plăcile de rețea să fie folosite pentru captura de trafic.

Se verifică instalarea Snort ca și serviciu în utilitarul „Services” și se comută Snort pe pornire Automată, odată cu sistemul de operare.

Verificarea Serviciului Snort

9.8 Instalare și configurare MySQL

Crearea de baze de date Snort Open a command window and at the command window type 'mysql -u root' (less the outside quotes) and tap the 'Enter' key.in command prompt se tastează "mysql-u root”. At the mysql prompt type 'drop database test;' (less the outside quotes), and tap the 'Enter' key.La promptul mysql se tastează "drop database test;" apoi 'create database Snort;’. După crearea bazei de date pentru Snort, se creează bază de date unde va fi ținuta arhiva: „ create database archive;”

Pentru popularea bazei de date cu tabel se folosește scriptul ce este furnizat cu Snort. At the mysql prompt type 'create database archive;' (less the outside quotes), and tap the 'Enter' key.”create database cccccccccccccccccccccccccccccccccccccccsss At the mysql prompt type 'source d:\win-ids\snort\schemas\create_mysql' (less the outside quotes), and tap the 'Enter' key. La promptul mysql se tastează "source d: \win-ids\Snort\scheme\create_mysql" . Se va afișa 22 'Query OK, 0 rânduri afectate (0.00 sec). Pentru verificare se tastează „ show tables;”Note: It will display for 'Tables_in_snort' as '16 rows in set (0.02 sec)' and drop back to the mysql prompt. Notă: Se va afișa pentru „Tables_in_Snort", ca" 16 rânduri în set (0.02 sec) "și a reveni la mysql prompt. In At the mysql prompt type 'connect archive;' (less the outside quotes), and tap the 'Enter' kepromptul mysql se tastează "connect archive;"

Pentru crearea bazei de date de arhivare se tastează At the mysql prompt type 'source d:\win-ids\snort\schemas\create_mysql' (less the outside quotes), and tap the 'Enter' key."source d:\win-ids\Snort\scheme\create_mysql". Note: It will display 22 'Query OK, 0 rows affected (0.00 sec)' entries and drop back to the mysql prompt. Se va afișa din nou 22 'Query OK, 0 rânduri afectate (0.00 sec). Create Database Access and Authenticated Users

Crearea bazei de date de acces și Autentificarea Utilizatorilor se face prin At the mysql prompt type 'set password for root@localhost = password('d1ngd0ng');' (less the outside quotes), and tap the 'Enter' key."set password root @ localhost = password (" d1ngd0ng ');

At the mysql prompt type 'grant INSERT,SELECT,UPDATE on snort.* to snort identified by 'l0gg3r';' (less the outside quotes), and tap the 'Enter' key. La promptul mysql se introduc pe rând următoarele comenzi”

'grant INSERT,SELECT,UPDATE on Snort.* to Snort identified by 'l0gg3r';

'grant INSERT,SELECT,UPDATE on Snort.* to Snort@localhost identified by 'l0gg3r'

'grant INSERT,SELECT,UPDATE,DELETE,CREATE on Snort.* to base identified by 'an@l1st';

'grant INSERT,SELECT,UPDATE,DELETE,CREATE on Snort.* to base@localhost identified by 'an@l1st';'

grant INSERT,SELECT,UPDATE,DELETE,CREATE on archive.* to base identified by 'an@l1st';'

grant INSERT,SELECT,UPDATE,DELETE,CREATE on archive.* to base@localhost identified by 'an@l1st';'

Se merge apoi la Navigate to the 'd:\win-ids\mysql' folder, right-click on the 'my.ini' file and open with 'WordPad'."D:\win-ids\mysql'si se editează fișierul my.iniOriginal: sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION" cu sql-mode ="NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION"Now save the file, eXit WordPad, and reboot the system.

După repornirea sistemului se verifica dacă Snort a fost pornit ca serviciu și dacă nu sunt erori. Prin deschiderea unei pagini la adresa http://winids/base se va afișa consola de administrare base.

Captura Ecran BASE

9.9 Crearea de reguli noi pentru Snort

Formatul standard al unei reguli pentru Snort este de forma:

action protocol src_ip src_port direction dst_ip dst_port (opțiuni regula)

Pentru a genera alerte, s-a creat o regula (test.rule) pentru ca Snort să capteze tot traficul de pe rețea chiar dacă acesta nu reprezintă o amenințare.

alert ip any any -> any any (msg:"Got an IP Packet"; classtype:not-suspicious; sid:2000000; rev:1;)

alert icmp any any -> any any (msg:"Got an ICMP Packet"; classtype:not-suspicious; sid:2000001; rev:1;)

alert icmp any any -> any any (msg:"ICMP Large ICMP Packet"; dsize:>800; reference:arachnids,246; classtype:bad-unknown; sid:2000499; rev:4;)

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 criteria 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 detectie si prevenire a intruziunilor, reprezintă o variabilă foarte

importantă în ecua ia unui sistem bine protejat, pentru că una din cele mai importante

resurse, poate chiar mai importantă decât cele materiale, este dată de infomație și obținerea ei. Într-o lume în care echilibrul mondial este dictat de puterea informației, menținerea confidențialități acesteia este foarte importantă, deoarece aceasta dă valoarea unei informații.

Anexa 1 – Acronime

Bibliografie

K. Scarfone, P. Hoffman, „Guide to Intrusion Detection and Prevention Systems( IDPS)”, NIST Special Publication 800-94, 2007;

S. Northcutt, J.Novak, „Network Intrusion Detection, 3rd Edition”, New Riders Publishing, 2002;

Snort Users Manual 2.9.4, Noiembrie 2012;

Andrew S. Tanenbaum, „Rețele de calculatoare, ediția a treia”, Computer Press Agora, 1998;

Rebecca Bace.” An Introduction to Intrusion Detection and Assessment”.

Patrick,Harper.” Snort Install Manual”. SecurityWriter

http://snort.org/

Home

http://www.wikipedia.org/

http://tutoriale.eajutor.ro/unix-linux/tutorial-iptables-firewall-linux-comenzi-debaza.html

http://www.securityfocus.com/infocus/1670

http://www.honeypots.net/

Bibliografie

K. Scarfone, P. Hoffman, „Guide to Intrusion Detection and Prevention Systems( IDPS)”, NIST Special Publication 800-94, 2007;

S. Northcutt, J.Novak, „Network Intrusion Detection, 3rd Edition”, New Riders Publishing, 2002;

Snort Users Manual 2.9.4, Noiembrie 2012;

Andrew S. Tanenbaum, „Rețele de calculatoare, ediția a treia”, Computer Press Agora, 1998;

Rebecca Bace.” An Introduction to Intrusion Detection and Assessment”.

Patrick,Harper.” Snort Install Manual”. SecurityWriter

http://snort.org/

Home

http://www.wikipedia.org/

http://tutoriale.eajutor.ro/unix-linux/tutorial-iptables-firewall-linux-comenzi-debaza.html

http://www.securityfocus.com/infocus/1670

http://www.honeypots.net/

Anexa 1 – Acronime