Sistem de detectare a intruziunilor în rețea

NIDS , Network Intrusion Detection System , sunt instrumente IT , software sau hardware , dedicate analizei traficului unuia sau mai multor segmente ale unei rețele LAN pentru a identifica anomalii în fluxuri sau intruziuni IT probabile.

Cele mai frecvente NIDS sunt compuse din una sau mai multe sonde situate în rețea, care comunică cu un server centralizat, care se bazează în general pe o bază de date . Printre activitățile anormale care pot avea loc și pot fi detectate de către un NIDS se numără: acces neautorizat, propagare de software rău intenționat, achiziție abuzivă de privilegii aparținând subiecților autorizați, interceptarea traficului ( sniffing ), refuzul de serviciu ( DoS ).

Operațiune

Logica pe care se bazează NIDS pentru a recunoaște fluxurile neautorizate este împărțită în:

Potrivirea modelelor : capacitatea NIDS de a compara fluxurile cu semnăturile, stilul antivirus și de a le notifica cu promptitudine. Semnăturile indică de obicei un set de condiții, de exemplu: Dacă un pachet este IPv4 , TCP , portul de destinație este 31337, iar sarcina utilă conține foo , declanșează „alarma”.
Detectarea anomaliilor : recunoașterea fluxurilor suspecte datorită unui mecanism sofisticat de funcții matematice și algoritmi care se referă la RFC-uri și standardele acestora. Dacă unul sau mai multe fluxuri nu respectă standardele, sistemul semnalează eroarea cu alarma obișnuită.

Când NIDS detectează evenimente semnificative, acestea le clasifică în funcție de criticitatea lor, de exemplu Scăzut, Mediu, Înalt; apar adesea falsuri pozitive, adică evenimente care nu reprezintă de fapt un pericol pentru sistemele informatice, în general din cauza configurațiilor greșite din partea administratorilor de sistem. În general, senzorii de rețea care comunică cu serverul centralizat al NIDS efectuează o monitorizare pasivă full-duplex a rețelei, poziționată în spatele unui robinet de rețea , care poate fi definit brutal ca un „robinet” care reglează traficul și are grijă de păstrați sonda rămânând invizibilă în rețea. Pentru ca senzorii să funcționeze corect, trebuie să fie supuși unei actualizări continue a semnăturilor pentru a contracara cele mai recente vulnerabilități.

NIDS-urile moderne funcționează întotdeauna cu firewall-uri , în acest scop IPS, sistemul de prevenire a intruziunilor , care, pe lângă asigurarea controlului asupra fluxurilor, continuă prin blocarea celor neautorizate.

argumente pro şi contra

Într-un sistem informatic care implementează politici de securitate valabile, un sistem bun de răspuns la incidente și care adoptă firewall-uri, antivirus și toate cele mai moderne măsuri de securitate, NIDS joacă un rol fundamental, ca:

analizează încărcătura utilă a pachetelor prin identificarea traficului anormal;
oferă informații despre scanările primite de rețea;
permite să primiți alarme în timp real;
evidențiați orice erori în configurația sistemului;
evidențiați vulnerabilitățile rețelei;
permite monitorizarea comportamentului utilizatorilor din interiorul rețelei;
raportați dacă alte măsuri de securitate, cum ar fi firewall-ul sau antivirusul, nu au funcționat corect;
detectează orice atacuri din rețeaua internă către rețeaua externă;
detectează prezența oricăror viermi care încearcă să trimită informații în afara rețelei;
monitorizează resursele partajate utilizate;
vă permit să înțelegeți ce măsuri preventive să luați pentru a evita orice atacuri viitoare;
sunt dificil de detectat deoarece acționează pasiv.

Caracteristicile extinse descrise au determinat unii administratori de rețea să creadă că NIDS poate raporta și rezolva orice probleme de securitate. Paradoxal, gândirea că NIDS garantează securitate totală, având în vedere potențialul lor enorm, poate fi contraproductivă, deoarece acest lucru ar genera un fals sentiment de securitate. De fapt, nu există nici o siguranță totală, nici un singur produs care vă permite să fiți în siguranță totală.

Chiar dacă NIDS sunt cu siguranță necesare pentru a garanta un nivel bun de securitate a sistemului, singure nu ar fi suficiente pentru că:

nu înlocuiesc personalul de securitate existent deoarece necesită o monitorizare constantă;
nu identifică atacurile care exploatează vulnerabilitățile care încă nu au fost făcute publice, numite 0-day;
acționează pasiv, adică nu blochează traficul rău intenționat chiar dacă pot fi configurate pentru a interacționa cu un firewall;
atunci când există o cantitate mare de trafic de procesat, este posibil ca pachetele să se piardă, rezultând eșecul detectării unui atac;
nu pot analiza informații criptate;
identifică o încercare de atac, dar nu detectează dacă a avut succes;
au probleme cu atacurile care folosesc pachete fragmentate;
prin creșterea numărului de semnături, eficiența NIDS poate fi redusă;
necesită resurse semnificative din punct de vedere al spațiului pentru stocarea jurnalelor;
nu înlocuiesc alte mecanisme de protecție.

Din cele spuse, reiese că NIDS sunt necesare pentru a crește controlul asupra activității sistemelor, dar nu sunt suficiente pentru a garanta continuitatea serviciului, deoarece acționează pasiv.

NIDS vs Firewall

Ambele firewall-uri și NIDS lucrează împreună pentru a preveni accesul neautorizat la o rețea. Ambele sunt esențiale, dar nici unul nu este suficient pentru a garanta un nivel ridicat de siguranță pe cont propriu. În afară de aceste similitudini, există diferențe tehnice substanțiale care le caracterizează. Firewall-urile au o funcție de filtrare a pachetelor pentru a bloca traficul care nu respectă politicile lor.

Pachetele sunt filtrate pe baza adresei IP sursă sau destinație și a porturilor corespunzătoare. Jurnalele stocate se referă cu greu la traficul permis, deoarece este considerat de încredere. Dacă unele dintre pachetele rău intenționate au reușit să treacă prin firewall din cauza unei configurații incorecte a firewall-ului sau a oricărei vulnerabilități exploatate, nu numai că ar fi posibil să se efectueze un atac reușit, dar, mai presus de toate, nu ar exista informații despre acesta stocat.

Pentru a depăși această problemă, intră în joc NIDS, care analizează conținutul acestor pachete și semnalează orice activitate anormală detectată cu o alarmă, indiferent de succesul sau eșecul acesteia. Mai mult, în cazul în care un atac ar fi provenit din rețea, paravanul de protecție nu ar fi de nici un folos. De fapt, deși este capabil să filtreze traficul către și de la rețeaua externă, nu are putere asupra traficului intern către rețea.

O altă slăbiciune a firewall-urilor se datorează faptului că uneori utilizatorii din naivitate sau nerăbdare se conectează la Internet prin crearea de conexiuni neautorizate prin modem. Acest comportament pune întreaga rețea în pericol, deoarece traficul generat, chiar și în acest caz, nu va fi filtrat de firewall. Prin urmare, NIDS, în timp ce monitorizează traficul din interiorul rețelei, nu elimină paravanele de protecție.

Tehnici de analiză a pachetelor

Prin setarea plăcii de rețea NIDS în modul promiscuos, este posibil să ascultați pasiv tot traficul care trece prin segmentul de rețea, fără a interfera cu aceasta. Analiza pachetelor poate fi efectuată utilizând trei tehnologii: analiza potrivirii tiparelor, analiza stării potrivirii tiparelor și analiza protocolului.

Analiza de potrivire a modelelor se ocupă cu analiza conținutului pachetelor în căutarea secvențelor de biți prefixate. Aceasta este o abordare simplă de implementat, dar, în același timp, destul de rigidă și din punct de vedere computerizat, deoarece fiecare pachet trebuie comparat cu sute de semnături de detectare a intruziunilor. Fiecare semnătură este asociată cu un atac specific și instruiește IDS pe tipul de pachet să fie considerat anormal. Fiecare semnătură presupune o structură compusă din șase componente <protocol>, <ip_src>, <port_src>, <ip_dst>, <port_dst> și <payload_con_exploit> care sunt comparate cu pachetele de intrare și de ieșire în modul următor: DACĂ protocolul utilizat este <protocol>, adresa IP sursă este <ip_src>, portul asociat cu adresa IP sursă este <src_port>, adresa IP de destinație este <ip_dst>, portul asociat cu adresa IP de destinație este <dst_port> și sarcina utilă conținută în pachet este <payload_con_exploit>, THEN generează o alarmă. Conform celor descrise până acum, o alarmă este generată atunci când apare modelul de potrivire între un pachet și o regulă. Aceasta înseamnă că ar fi suficient să împărțim șirul de exploatare conținut în sarcina utilă în două cadre TCP, pentru a nu detecta atacul. Pentru a rezolva această problemă, a fost introdusă analiza Stateful Pattern Matching, care este un criteriu de analiză mai sofisticat care efectuează aceleași verificări ca și Analiza Matching Pattern, dar luând în considerare fluxul de date TCP. Acest lucru implică o sarcină de calcul mai mare, deoarece se întâmplă adesea că există sesiuni TCP deschise pentru a fi monitorizate pentru o perioadă lungă de timp.

Analiza protocolului, pe de altă parte, generează o alarmă pentru orice încălcare a specificațiilor tehnice ale unui protocol. De exemplu, să presupunem că un client dorește să deschidă o conexiune TCP cu un server, în acest scop trimite un pachet SYN și se așteaptă să primească fie un pachet SYN / ACK, fie un RST / ACK. Orice alte pachete primite sunt considerate o încălcare și generează o alarmă. Această tehnică minimizează, dacă protocolul este bine definit, numărul de falsuri pozitive generate dacă traficul legitim este recunoscut ca anormal, cu toate acestea, nu este neobișnuit să se găsească RFC-uri ambigue care lasă loc dezvoltatorilor să implementeze protocolul la discreția lor.

Alarme fals pozitive și false negative

NIDS funcționează cu cantități mari de date și au nevoie de cel puțin un algoritm de generare a alarmelor pentru a funcționa. Unii administratori aleg să considere tot traficul considerat nedemn de încredere ca anormal (politică închisă), în timp ce alții aleg să considere tot traficul care nu este considerat anormal (politică deschisă) ca fiind de încredere. În prima ipoteză, sarcina de calcul a NIDS va fi semnificativă și se va genera un număr mare de alarme false numite fals pozitive, care se poate datora:

pachete generate de unele dispozitive de rețea nerecunoscute de NIDS;
încălcări ale protocoalelor nu datorate atacurilor, ci implementărilor ambigue;
circumstanțe normale considerate periculoase de NIDS, cum ar fi vizualizarea unei pagini web care conține codul sursă al unui exploit.

În a doua ipoteză, numărul alarmelor va fi considerabil mai mic, dar există riscul de a nu identifica traficul anormal care nu găsește nicio corespondență cu regulile stabilite, generând negative negative care sunt mai greu de detectat și care se pot datora :

configurații de rețea necorespunzătoare;
cantitatea mare de trafic într-o asemenea măsură încât nu este acceptată de NIDS;
trafic criptat;
semnături incorecte sau prea generice;
Atacuri de 0 zile pentru care semnătura corespunzătoare nu a fost încă dezvăluită.

Numărul de negative negative poate fi limitat doar cu menținerea constantă a NIDS și actualizarea frecventă a semnăturilor. Pentru a găsi echilibrul corect între fals pozitiv și fals negativ, este recomandabil să analizați temeinic topologia rețelei și să eliminați cauza care generează alarme false. Procedarea prin eliminarea radicală a regulii corespunzătoare unui atac ar putea fi o alegere prea naivă și superficială care uneori poate implica riscul de a nu detecta atacuri reale.

Răspunsul NIDS

IDS-urile nu intervin în general asupra traficului, ci doar răspund pasiv raportând anomalii prin mesaje text, e-mailuri sau apeluri telefonice. Modul în care este semnalizată alarma depinde adesea de gravitatea alarmei. Unele IDS pot fi, de asemenea, programate pentru a răspunde activ la atacuri mai grave, luând una dintre următoarele contramăsuri:

trimiterea unui pachet RST către atacator prin simularea că acesta provine din sistemul atacat pentru a face să creadă că victima este inaccesibilă;
interacțiunea cu un firewall de rețea pentru a bloca temporar sau permanent conexiunile cu victima;
monitorizarea întregului schimb de pachete;
prin nslookup, portscan sau traceroute către sistemul de atac pentru a prelua mai multe informații.

Cu toate acestea, prin configurarea IDS pentru a răspunde activ la atacuri, falsurile pozitive riscă să blocheze conexiunile care în mod normal ar fi permise provocând un DoS.

Poziționare

Una dintre cele mai critice activități în configurarea și implementarea unui IDS este poziționarea acestuia în rețeaua care urmează să fie monitorizată. În funcție de topologia rețelei, pot apărea cazuri diferite. Când gazdele dintr-un segment de rețea sunt conectate printr-un hub, implementarea unui NIDS este relativ simplă, deoarece hub-ul este o componentă de rețea care se ocupă de replicarea fiecărui pachet pe toate porturile. În acest fel este suficient să conectați NIDS la orice port al hub-ului pentru a putea citi tot traficul care trece.

Cu toate acestea, în prezența unui comutator, situația este diferită, iar implementarea NIDS este mai complicată. Comutatoarele, de fapt, funcționează la un nivel mai ridicat al stivei ISO / OSI decât hub-urile și atunci când trebuie să trimită un pachet, îl trimit numai către portul de destinație relativ. O soluție pentru a putea citi tot traficul segmentului de rețea este oglindirea porturilor care constă în monitorizarea unuia sau mai multor porturi ale comutatorului, copierea traficului pe un alt port numit port oglindă. Acest port trebuie neapărat să aibă o capacitate de lățime de bandă posibil egală cu suma capacității de lățime de bandă a tuturor porturilor monitorizate. Numai în acest fel traficul poate fi gestionat corespunzător.

După cum sa menționat, alegerea poziționării IDS este o activitate foarte delicată care trebuie să țină seama de nevoile rețelei și de resursele disponibile.

O altă variabilă de luat în considerare la poziționarea unui IDS este locația sa în raport cu un firewall. Prin plasarea sistemului de detectare a intruziunilor în afara firewall-ului, vor fi identificate toate activitățile anormale, inclusiv cele care nu vor avea acces la rețea, deoarece sunt blocate de firewall. Un IDS aranjat în acest fel va fi mai expus atacurilor din exterior, deoarece este neprotejat. Resursele necesare sunt imense, deoarece cantitatea de trafic analizată și jurnalele stocate vor fi semnificative. O soluție mai ieftină este plasarea IDS-urilor în firewall pentru a monitoriza doar traficul care intră în rețea. Acest lucru va genera mai puține alarme și vor exista mai puține jurnale de analizat.

Dacă, pe de altă parte, scopul IDS este protecția serverelor, o alternativă validă este instalarea sistemului de detectare a intruziunilor în zona demilitarizată (DMZ). Cu toate acestea, celelalte segmente de rețea ar rămâne ne-monitorizate.

Prin urmare, în cazul în care resursele disponibile sunt mari, cea mai robustă soluție este instalarea unui IDS pentru fiecare segment de rețea. Acest lucru vă permite să țineți întreaga rețea sub control, să configurați fiecare sistem de detectare a intruziunilor într-un mod diferit în funcție de nevoile segmentului unic și să evitați posibilele supraîncărcări ale sistemelor. În plus, dacă un IDS ar eșua din orice motiv (cum ar fi erori hardware / software sau atacuri de diferite tipuri), celelalte segmente de rețea ar continua să fie monitorizate.

Analiza jurnalului

Analiza jurnalului este de o importanță fundamentală în procesul de detectare a intruziunilor atât în cazul încercărilor de intruziune, cât și în cazul unui incident computerizat. Jurnalele stochează înregistrări care conțin informații despre marca de timp, protocolul utilizat, adresa IP sursă și destinație și porturile utilizate de orice activitate anormală monitorizată. De asemenea, pot fi conținute date suplimentare, cum ar fi o descriere text a evenimentului sau numărul regulii care a generat alarma. Când sunt generate jurnalele cauzate de evenimentele unei anumite entități, este recomandabil să stocați și sarcina utilă a pachetului care a generat alarma pentru a avea mai multe detalii despre eveniment. Să luăm un exemplu luând în considerare o cerere DNS. În corespondență cu acest eveniment, va fi generat un jurnal în care se va raporta că atacatorul potențial cu adresa IP 100.200.100.200 a trimis un pachet UDP către destinatar 90.80.70.60, pe portul 53. Acest lucru nu va fi suficient pentru a înțelege dacă solicitarea DNS a fost sau nu dăunătoare. Situația ar fi diferită dacă s-ar putea analiza și sarcina utilă a pachetelor.

Una dintre cele mai mari probleme în analiza jurnalelor este eterogenitatea lor inerentă, deoarece acestea variază în funcție de firewall, router sau IDS utilizate. Nu există instrumente care sincronizează cronologic jurnalele produse de diferite sisteme. Uneori se poate întâmpla ca fusul orar să difere de la sistem la sistem, făcând analiza și mai complicată; cu toate acestea, protocoale precum NTP pot fi utilizate pentru sincronizarea diferitelor sisteme. Mai mult, capacitatea de a reacționa în fața unei intruziuni este extrem de importantă. Acționarea promptă atunci când este identificată o intruziune este adesea esențială pentru a preveni atacatorul de a modifica sau șterge jurnalele. Cu toate acestea, administratorii de rețea ar trebui să acorde atenție nu numai manipulării posibile a jurnalelor, ci și numeroaselor activități anormale care pot apărea, cum ar fi cele care urmează să fie analizate.

Scăderea performanței rețelei datorită saturației lățimii de bandă, care apare deoarece atacatorul folosește adesea mașini compromise pentru a stoca programe, mp3-uri și filme pentru a fi partajate ilegal cu alți utilizatori ai rețelei.
Trafic suspect către adrese IP necunoscute sau peste protocoale utilizate în mod obișnuit. Dacă sunt detectate conexiuni de ieșire de la un server web, acest lucru poate însemna că serverul a fost compromis.
Dacă sunt identificate pachete malformate, există riscul ca un atacator să caute vulnerabilități pe diferite mașini din sistem sau să încerce să ocolească un firewall.
Pierderea conectivității, care ar putea fi asociată cu un atac DoS.
Un număr mare de încercări de conectare eșuate, care sunt obișnuite atunci când atacatorul încearcă să obțină mai multe privilegii decât sunt de fapt acordate.
Activitate neobișnuită a modemului, care ar putea indica prezența probabilă a unui apelator.
„Scanează” către mașinile din rețea, care sunt utilizate de atacator pentru a colecta informații despre sistemele de operare instalate, serviciile active, porturile deschise și topologia rețelei. Aceste informații vor fi apoi utilizate pentru a efectua un atac.
Cantitatea mare de trafic generat în timpul orelor de lucru neindicată indică utilizatorii neautorizați care utilizează rețeaua. În cazul în care un comutator este prezent în rețeaua atacată, odată introdus, atacatorul ar putea intercepta traficul folosind două atacuri.
Atacul ARP-POISONING, unde tabelele ARP ale gazdelor aparținând aceluiași segment de rețea sunt modificate, astfel încât mașina pe care se află snifferul să vadă și traficul generat de celelalte gazde.
Atacul DHCP-POISONING, unde atacatorul face ca o gazdă din rețeaua internă să pretindă că este serverul DHCP și trimite răspunsuri ad-hoc la DHCP-REQUEST care sosesc, specificând adresa IP a atacatorului ca gateway implicit. În acest fel, tot traficul, înainte de a ajunge afară, va trece prin mașina controlată de atacator.

Aspecte legale

Orice activitate de monitorizare a rețelei trebuie să respecte reglementările în vigoare în statul în care este situat sistemul informațional și cu politicile interne ale companiei. În caz contrar, există riscul de a fi urmărit penal pentru încălcarea confidențialității utilizatorilor rețelei și pentru interceptarea abuzivă a comunicării computerizate. În plus, nu va fi posibilă utilizarea datelor colectate pentru a întreprinde acțiuni în justiție împotriva unui intrus. Prin urmare, este adecvat:

informează utilizatorii că activitatea lor din rețea va fi monitorizată;
indicați scopul monitorizării;
specificați tipurile de trafic monitorizat;
specifică managerul căruia îi vor fi trimise rapoartele privind orice compromisuri.

Din punct de vedere birocratic, aceste măsuri pot fi traduse într-o scrisoare informativă care va fi semnată de toți utilizatorii rețelei pentru confirmare. Din punct de vedere tehnic, este posibilă implementarea unui „Mesaj al Zilei” (MOTD) care constă într-un mesaj inițial care informează utilizatorii despre activitatea de înregistrare în rețea. În cazul unui incident pe computer, jurnalele reprezintă dovezi valoroase și, ca atare, trebuie obținute în conformitate cu legislația în vigoare și să fie astfel încât să poată ilustra în detaliu desfășurarea faptelor. Prin urmare, este recomandabil să vă asigurați că dovada obținută este:

autentic și nealterat chiar și în cazul deplasării dispozitivelor care conțin dovada;
complet, deoarece nu trebuie să arate accidentul din singura perspectivă atribuibilă acțiunilor desfășurate de atacator, ci trebuie să evalueze și perspective care ar putea da naștere la contradicții;
inteligibil și credibil, sau reprezentat într-un format care poate fi citit de oricine și nu pentru utilizarea exclusivă a experților din sector.

Alegerea unui NIDS

Pentru a încheia această prezentare generală, sunt discutate elementele care trebuie luate în considerare atunci când alegeți un NIDS.

Cost: evident, trebuie să fie proporțional cu resursele care trebuie protejate.
Capacitate de lățime de bandă acceptată: este cantitatea de trafic pe care senzorul o poate analiza într-o unitate de timp. Se măsoară în Mb / s sau în pachete / s.
Actualizare semnătură: NIDS din acest punct de vedere funcționează exact ca antivirusul. Pentru a identifica noi atacuri, acestea trebuie să aibă semnături recente în baza lor de date. Din acest motiv, este extrem de important ca actualizările să fie furnizate în timp util și să se ofere posibilitatea actualizării automat a bazei de date. De asemenea, este importantă posibilitatea de a utiliza semnături personalizate create ad-hoc pentru nevoile dumneavoastră.
Activitate de înregistrare: este recomandabil să verificați claritatea jurnalelor și să evaluați dacă ieșirea este salvată în format standard sau proprietar.
Scalabilitate: Posibilitatea extinderii funcționalității NIDS în caz de nevoi viitoare este extrem de importantă, în special numărul de senzori suportați și posibilitatea gestionării sistemului central printr-o consolă specială ar trebui evaluată.

Elemente conexe

linkuri externe

(EN) Snort - Populare Open Source NIDS
( RO ) ISS RealSecure Network IDS , pe iss.net . Adus la 21 august 2005 (arhivat din original la 4 august 2005) .
( EN ) Arhiva RFC , la faqs.org .

Portal de securitate IT : accesați intrările Wikipedia care se ocupă cu securitatea IT