Acest post vă va ajuta să scrieți reguli Snort eficiente pentru a vă îmbunătăți semnificativ poziția de securitate. Vom începe cu o defalcare a modului în care este construită o Regulă și apoi vom explora cele mai bune practici cu exemple pentru a capta cât mai multe activități malițioase în timp ce folosiți cât mai puține reguli.
Snort este un sistem open-source de detectare a intruziunilor în rețea (NIDS) care oferă o analiză în timp real a pachetelor și face parte din soluția Coralogix STA. Dacă sunteți un client Coralogix STA, nu uitați să verificați, de asemenea, postarea mea anterioară despre cum să editați regulile Snort în STA.
Anatomia regulilor Snort
Înainte de a ne scufunda în diferitele strategii pentru a scrie cele mai bune reguli Snort, să începem prin a diseca un exemplu de regulă Snort:
alert: îi spune lui Snort să raporteze acest comportament ca o alertă (este obligatoriu în regulile create pentru STA).
tcp: înseamnă că această regulă se va aplica numai la traficul în TCP.
any: în acest context, înseamnă „de la orice port sursă”, apoi există o săgeată ‘->’ care înseamnă „o conexiune la” (nu există un operator ‘<-‘, dar puteți pur și simplu să întoarceți argumentele în jurul operatorului. Puteți utiliza operatorul „<>” pentru a indica faptul că direcția conexiunii este irelevantă pentru această regulă), apoi un interval IP care indică adresa IP de destinație și apoi portul. Puteți indica un interval de port folosind două puncte, cum ar fi 0:1024, ceea ce înseamnă 0-1024. În paranteza rotundă, există câteva directive pentru stabilirea mesajului de alertă, metadate despre regulă, precum și verificări suplimentare.
msg: este o directivă care stabilește pur și simplu mesajul care va fi trimis (către Coralogix în cazul STA) în cazul în care va fi detectat un trafic corespunzător.
flow: este o directivă care indică dacă conținutul pe care urmează să îl definim ca semnătură trebuie să apară în comunicarea către server („to_server”) sau către client („to_client”). Acest lucru poate fi foarte util dacă, de exemplu, am dori să detectăm răspunsul serverului care indică faptul că a fost încălcat.
established: este o directivă care va determina Snort să își limiteze căutarea pachetelor care se potrivesc cu această semnătură doar la pachetele care fac parte din conexiuni stabilite. Acest lucru este util pentru a minimiza sarcina pe Snort.
uricontent: este o directivă care îi ordonă lui Snort să caute un anumit text în conținutul URI HTTP normalizat. În acest exemplu, căutăm un URL care este exact textul „/root.exe”.
nocase: este o directivă care indică faptul că am dori ca Snort să efectueze o căutare insensibilă la majuscule și minuscule.
classtype: este o directivă care este un atribut de metadate care indică ce tip de activitate detectează această regulă.
reference: este o directivă care este un atribut de metadate care face legătura cu un alt sistem pentru mai multe informații. În exemplul nostru, valoarea url,<https://….> face trimitere la un URL de pe internet.
sid: este o directivă care este un atribut de metadate care indică ID-ul semnăturii. Dacă vă creați propria semnătură (chiar dacă doar înlocuiți o regulă încorporată), utilizați o valoare mai mare de 9.000.000 pentru a preveni o coliziune cu o altă regulă preexistentă.
rev: este o directivă care indică versiunea regulii.
Există multe altele de învățat despre regulile Snort, care suportă analiza RegEx, analiza specifică protocolului (la fel ca uricontent pentru HTTP), căutarea de date binare (non-textuale) prin utilizarea valorilor hexagonale ale octeților și multe altele. Dacă doriți să aflați mai multe, puteți începe de aici.
Bune practici pentru scrierea unor reguli Snort eficiente
- Țintiți vulnerabilitatea, nu exploit-ul – Evitați să scrieți reguli pentru detectarea unui kit de exploit specific, deoarece există nenumărate exploit-uri pentru aceeași vulnerabilitate și putem fi siguri că se scriu altele noi în timp ce citiți acest articol. De exemplu, multe dintre primele semnături pentru detectarea atacurilor de tip buffer overrun arătau astfel:
alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (content:"AAAAAAAAAAAAAA", msg:"Buffer overrun detected.")
Motivul este, bineînțeles, că pentru a lansa cu succes un atac de tip buffer overrun, atacatorul trebuie să umple buffer-ul unei anumite variabile și să adauge încărcătura sa utilă malițioasă la sfârșit, astfel încât aceasta să devină executabilă. Caracterele pe care alege să le folosească pentru a umple memoria tampon sunt complet nesemnificative și, într-adevăr, după apariția unor astfel de semnături, multe seturi de instrumente de atac au folosit pur și simplu o literă sau litere diferite pentru a umple memoria tampon și au scăpat complet de detectarea acestui tip de semnătură. O modalitate mult mai bună ar fi aceea de a încerca să detecteze acest tip de atacuri prin detectarea introducerii incorecte în câmpuri pe baza tipului și a lungimii acestora.
- Particularitatea ta este cel mai bun atu al tău, așa că folosește-l – Fiecare organizație are lucruri care o fac unică. Multe dintre acestea pot fi foarte utile atunci când încercați să prindeți activități rău intenționate în organizația dvs. – atât externe, cât și interne. Utilizând aceste cunoștințe interne profunde în avantajul dumneavoastră, veți transforma, în esență, problema dintr-o problemă tehnologică într-o problemă de inteligență pur și simplu de școală veche, forțându-i pe atacatori să aibă o înțelegere mult mai intimă a organizației dumneavoastră pentru a-și putea ascunde eficient urmele. Aceste lucruri pot fi de natură tehnologică sau se pot baza pe obiceiurile de lucru specifice organizației dvs. și pe liniile directoare interne. Iată câteva exemple:
- Orele tipice de lucru: Unele organizații la care am lucrat nu le permiteau deloc angajaților să lucreze de acasă, iar majoritatea angajaților ar fi părăsit deja biroul la ora 19:00. Pentru organizații similare, ar fi logic să setați o alertă care să vă notifice despre conexiunile de la birou după o anumită oră. Un atacator care ar instala un software malițios în organizația dvs. ar trebui să cunoască acest comportament și să își regleze malware-ul pentru a comunica cu serverele sale de comandă & control exact la aceeași oră astfel de comunicări ar trece neobservate.
- Browser tipic: Să presupunem că organizația dvs. a decis să utilizeze browserul Brave ca browser principal și că acesta este instalat automat pe fiecare laptop nou al corporației și că ați eliminat comenzile rapide de pe desktop pentru browserul IE/Edge de pe toate laptopurile corporative. În acest caz, o conexiune din organizație, atât la o adresă internă, cât și la una externă care utilizează un browser diferit, cum ar fi IE/Edge, ar trebui să fie configurată pentru a declanșa o alertă.
- IP Ranges based on Roles: Dacă este posibil să atribuiți diferite intervale IP pentru diferite servere în funcție de rolul lor, de exemplu, să aveți toate serverele DB pe 192.168.0.0/24, serverele web pe 192.168.1.0/24, etc., atunci ar fi posibil și chiar ușor să configurați reguli inteligente bazate pe comportamentul așteptat al serverelor dvs. în funcție de rolul lor. De exemplu, serverele de baze de date, de obicei, nu se conectează singure la alte servere, imprimantele nu încearcă să se conecteze la controlorii de domeniu, etc.
- Încercări neobișnuite de conectare: Multe organizații folosesc o partajare publică pe un server de fișiere pentru a-i ajuta pe utilizatori să partajeze fișiere între ei și folosesc imprimantele activate în rețea pentru a le permite utilizatorilor să tipărească direct de pe computerele lor. Aceasta înseamnă că calculatoarele client nu ar trebui să se conecteze între ele, chiar dacă ați ales (cu înțelepciune) să blocați un astfel de acces într-un firewall sau la comutator, însăși încercarea de conectare de la un client la un alt calculator client ar trebui să ridice o alertă și să fie investigată cu atenție.
- Porturi neobișnuite: Unele organizații utilizează o bibliotecă specială pentru optimizări de comunicare între servicii, astfel încât toate comunicațiile HTTP între servere utilizează un port diferit de cele obișnuite (cum ar fi 80, 443, 8080 etc.). În acest caz, este o idee bună să creați o regulă care să fie declanșată de orice comunicare pe aceste porturi în mod normal comune.
- Honeytokens – Pe un câmp de luptă precum internetul, unde toată lumea poate fi aproape oricine, înșelăciunea, funcționează la fel de bine pentru apărători ca și pentru atacatori, dacă nu chiar mai bine. Trucuri precum redenumirea contului de administrator încorporat cu un nume diferit, mai puțin atractiv și crearea unui nou cont numit Administrator pe care nu îl veți folosi niciodată și crearea unei reguli Snort pentru a detecta dacă acest nume de utilizator, e-mail sau parolă sunt folosite vreodată în rețea. Ar fi aproape imposibil pentru atacatori să observe că Snort a detectat încercările lor de a folosi utilizatorul administrator fals. Un alt exemplu este crearea de produse, clienți, utilizatori și înregistrări de carduri de credit false în baza de date și apoi potrivirea regulilor Snort pentru detectarea lor în traficul din rețea.
Sperăm că ați găsit aceste informații utile. Pentru mai multe informații despre STA Coralogix, consultați cele mai recente caracteristici pe care le-am lansat recent.
.