39360.zip
Sistemul de detectare a intruziunilor în rețea (NIDS) open-source Snort, scalabil și eficient, utilizează o serie de reguli bine definite pentru a detecta pachetele anormale din rețeaua dumneavoastră. Menținerea acestor seturi de reguli îmbunătățește dramatic eficiența sistemului. Câteva tehnici de gestionare a regulilor vă pot ajuta să vă mențineți IDS-ul Snort. În primul rând, puteți preveni o supraîncărcare a alertelor prin înăsprirea definițiilor variabilelor și îngrijirea regulilor Snort. De asemenea, puteți persista regulile dvs. personalizate de-a lungul actualizărilor setului de reguli. În cele din urmă, puteți deconstrui o regulă pentru a înțelege cum să personalizați regulile pentru mediul dumneavoastră.
În mod implicit, Snort conține mai mult de 1900 de reguli de stoc într-o serie de aproape 50 de fișiere text organizate pe tipuri, așa cum arată Figura 1. Aceste reguli definesc declanșatoarele de răspuns la multe exploatări de vulnerabilități cunoscute referitoare la Windows, UNIX și la aplicații utilizate pe scară largă, cum ar fi Microsoft IIS, Apache, Microsoft SQL Server și Oracle SQL. Regulile ajută, de asemenea, Snort să furnizeze date de recunoaștere și posibile avertismente de configurare pentru a vă alerta cu privire la scanările de rețea sau la o mașină care difuzează un șir de comunitate implicit SNMP, de exemplu. După cum vă puteți imagina, Snort poate genera un număr imens de alerte. Pentru a reduce zgomotul regulilor de stoc, configurația implicită a Snort activează în mod implicit doar aproximativ 1300 dintre reguli și dezactivează în mod implicit tipuri întregi de reguli, cum ar fi politica, chat-ul și virusul. (Un tip de regulă este de obicei conținut în propriul său fișier text, astfel încât regulile de tip virus sunt conținute în fișierul virus.rules). Treceți în revistă toate grupurile de reguli dezactivate și activați-le pe cele care s-ar putea aplica mediului dumneavoastră.
Pruneți-vă regulile
Chiar și cu numeroasele reguli pe care Snort le dezactivează în mod implicit, sistemul IDS Snort va genera probabil multe alerte. Trudind printre toate aceste alerte s-ar putea să vă plictisească simțurile la traficul cu adevărat suspect. După ce instalați Snort în mediul dumneavoastră, curățați regulile pentru a le elimina pe cele care nu se referă la mediul dumneavoastră sau care nu vă interesează. De exemplu, dacă nu aveți limbajul de scripting PHP încorporat în HTML: Hypertext Preprocessor (PHP) instalat în mediul dumneavoastră, puteți dezactiva fișierul de reguli web-php.rules rules. Totuși, atunci când decideți ce reguli să dezactivați, luați în considerare utilizatorii care ar putea avea diverse programe pe mașinile lor. De exemplu, unul dintre senzorii dvs. Snort ar putea capta pachete suspecte de la o mașină de acasă compromisă prin intermediul unei conexiuni VPN. Așadar, continuând exemplul anterior, chiar dacă nu aveți PHP instalat pe niciunul dintre computerele corporative, unul dintre utilizatorii dvs. finali ar putea să-l fi instalat acasă. Dacă acel computer de acasă ar fi compromis printr-o vulnerabilitate PHP, atacatorul ar putea fi capabil să vă acceseze rețeaua corporativă în timp ce computerul compromis este conectat de la distanță la rețeaua corporativă (cum ar fi printr-un VPN).
Majoritatea sistemelor de alertă și raportare afișează numele și SID-ul pentru fiecare regulă pentru o referință ușoară. Pentru a reduce și mai mult lista de reguli activate, monitorizați-vă sistemele, notați numele sau SID-urile regulilor străine, apoi dezactivați aceste reguli. Pentru a dezactiva manual o regulă Snort, deschideți fișierul de reguli și inserați un semn (#) în fața regulii. Pentru a dezactiva o întreagă clasă de reguli, adăugați un semn de picătură în fața numelui de fișier al regulii în fișierul de configurare Snort. Trebuie să reporniți Snort pentru a încărca regulile modificate.
Revizuirea regulilor dvs. în mod regulat și continuarea eliminării celor care nu se aplică rețelei dvs. va scădea dramatic numărul de alerte pe care Snort le generează, facilitând astfel depistarea și identificarea pachetelor cu adevărat suspecte. Și nu uitați să reactivați regulile după cum este necesar atunci când introduceți o nouă tehnologie pe care regulile dezactivate în prezent ar proteja-o.
Mențineți regulile la zi
Snort.org găzduiește două versiuni de reguli Snort: snortrules-stable și snortrules-current, care funcționează cu Snort 2.0x și, respectiv, Snort 1.9x. Cele mai noi reguli conțin semnături suplimentare și actualizări ale regulilor existente pentru a utiliza variabilele extinse. De exemplu, regulile din versiunea 2.0.0.0 definesc variabile care descriu în mod specific anumite funcții ale mașinilor (de exemplu, variabilele HTTP_SERVERS și HTTP_PORTS caracterizează calculatoarele care rulează servicii Web și care ar putea fi predispuse la atacuri asupra serviciilor Web). Aceste noi variabile funcționează în noile reguli pentru a depista în continuare atacurile primite. O regulă veche ar putea să vă avertizeze cu privire la o solicitare HTTP suspectă destinată oricărui calculator din rețeaua dumneavoastră, dar noua regulă caută același atac numai atunci când este destinat unui server Web pe care îl definește variabila HTTP_SERVERS. Acest proces de clasificare ajută la reducerea alarmelor false.
Snort.org actualizează frecvent seturile de reguli pentru a rămâne la curent cu noile descoperiri de exploit. Pentru a rămâne la zi, verificați, descărcați și aplicați în mod regulat reguli noi care ar fi utile în mediul dumneavoastră. Cu toate acestea, rețineți că, ori de câte ori descărcați un set de reguli noi, fișierele text care conțin noile reguli le suprascriu pe cele care conțin regulile vechi. Veți descoperi rapid că comentarea tuturor regulilor nefolosite de fiecare dată când vă actualizați fișierele de reguli este împovărătoare.
Oinkmaster to the Rescue
Din fericire, mai multe instrumente open-source vă pot ajuta să depășiți această problemă. Un program de script Perl numit Oinkmaster, pe care îl puteți descărca de la http://www.algonet.se/~nitzer/oinkmaster, automatizează descărcarea de reguli noi și gestionează regulile dezactivate sau modificate. Adaptat pentru sistemele UNIX, scriptul Perl utilizează instrumentele wget, tar și gzip pentru a prelua și extinde noile reguli ori de câte ori scriptul este rulat. Cele mai multe dintre aceste instrumente sunt instalate pe sistemele UNIX, dar puteți descărca instrumentele pentru Windows. Nu uitați că soluțiile open-source au un suport dedicat limitat (dacă există), așa că trebuie să căutați online soluții la orice problemă sau întrebare pe care o puteți avea. Comunitatea de software cu sursă deschisă (OSS) abundă în informații utile. Un loc bun pentru a începe este abonarea la una dintre listele de discuții Snort, la care vă puteți înscrie la http://www.snort.org/lists.html.
Asigurați-vă că consultați fișierul README pentru instrucțiuni detaliate de instalare pentru platforma dumneavoastră. Procedura de instalare de bază a Oinkmaster constă în extinderea fișierelor oinkmaster.pl și oinkmaster.conf în directorul Snort (sau într-un director pe care îl specificați), apoi folosind oinkmaster.conf pentru a configura Oinkmaster.
Deschideți oinkmaster.conf și urmați comentariile în linie pentru a configura instrumentul. În primul rând, confirmați locația regulilor actualizate ca o adresă Web (de exemplu, http://www.snort.org/dl/signatures/snortrules.tar.gz). Asigurați-vă că direcționați Oinkmaster către un site de încredere și de bună reputație, mai ales dacă alegeți să descărcați și să instalați regulile în mod automat. În caz contrar, riscați să descărcați reguli corupte (sau, mai rău, alterate) care ar putea compromite IDS-ul dumneavoastră.
În continuare, specificați fișierele care trebuie să fie omise, modificate și dezactivate. În mod implicit, Oinkmaster nu procesează (adică sare peste) local.rules și snort.conf.
Funcția modifysid a scriptului vă permite să modificați regulile nou descărcate; gândiți-vă la modifysid ca la o funcție de căutare și înlocuire pentru o regulă specifică pe care o identificați prin SID. Cu această comandă, puteți modifica textul unei reguli specifice. De exemplu, puteți utiliza modifysid pentru a activa o regulă care este dezactivată în mod implicit. Pentru a face acest lucru, adăugați o nouă comandă modifysid care să identifice regula pe care doriți să o activați și instruiți-o să elimine caracterul de comentariu (#). De fiecare dată când un nou set de reguli este descărcat, acest caracter de comentariu va fi eliminat atunci când Oinkmaster analizează acea regulă. De asemenea, puteți utiliza modifysid pentru a ridica tipul de acțiune al unei reguli. De exemplu, comanda
modifysid 2003 "alert" | "sev1"
modifysid 2003 "alert" | "sev1"
elevează alerta cu SID-ul 2003 la un tip de acțiune personalizat sev1. Oinkmaster face acest lucru căutând „alert” și înlocuindu-l cu „sev1”. Și da, va face mai multe substituiri, așa că folosiți-o cu grijă.
Funcția finală și cea mai populară a Oinkmaster, disablesid, vă permite să dezactivați regulile selectate. Specificați SID-urile tuturor regulilor pe care doriți să le păstrați dezactivate. De exemplu, pentru a dezactiva alertarea privind scanările de rețea, ați putea începe cu o intrare similară cu
disablesid 469, 615, 618, 620
După descărcarea și analizarea unui nou set de reguli, Oinkmaster caută SID-urile specificate și comentează regulile. Atâta timp cât Oinkmaster vă gestionează regulile, regulile vor rămâne dezactivate, chiar și în timpul actualizărilor setului de reguli.
Executați manual scriptul ori de câte ori doriți să vă actualizați regulile. Dacă vă simțiți îndrăzneț, programați scriptul să se execute și să actualizeze regulile în mod recurent. Oinkmaster va prelua regulile, le va extinde și le va copia în directorul de reguli al senzorului dumneavoastră. Ca în cazul majorității OSS, utilizați Oinkmaster cu discreție și învățați mai întâi ce face și cum va afecta mediul dumneavoastră. De exemplu, testați un nou set de reguli rulând Snort în modul de autotestare (folosind snort -T plus ceilalți parametri) înainte de a implementa regulile în mediul de producție.
Oinkmaster vă permite să evitați riscurile descărcării de actualizări dubioase, oferindu-vă opțiunea de a face o copie de siguranță a regulilor vechi și livrând un jurnal al acțiunilor sale la consolă. Examinați această ieșire, care arată regulile eliminate, regulile active modificate, revizuirile care nu sunt reguli și fișierele noi, pentru a confirma că Oinkmaster și-a îndeplinit cu succes sarcinile și pentru a confirma regulile pe care Oinkmaster le-a modificat. Dacă alegeți să programați ca Oinkmaster să ruleze automat, luați în considerare trimiterea prin e-mail a rezultatelor pentru a facilita revizuirea, așa cum arată figura 2. Următorul exemplu arată cum să programați Oinkmaster să ruleze zilnic la ora 6:15 a.m. utilizând comanda Linux crontab (crontab vă permite să programați lucrări în Linux):
15 6 * * * /home/snort/oinkmaster.pl -o /home/snort/rules -b /home/snort/backup 2>&1 | mail -s "Oinkmaster"
Parametrii Oinkmaster specifică directorul de reguli (-o), directorul de reguli de rezervă (-b) și o comandă pentru a trimite prin e-mail rezultatele către proprietar. Comanda 2>&1 trimite ieșirea StdErr la StdOut (consola) înainte de a o trimite la aplicația de e-mail.
Vezi o regulă Snort
Pe lângă dezactivarea sau modificarea de bază a regulilor din stoc, puteți să vă creați propriile reguli și să adaptați în continuare regulile Snort direct la mediul dumneavoastră. De exemplu, luați în considerare o implementare de senzori care monitorizează traficul în interiorul și în afara firewall-ului dvs. Deși ar putea să vă intereseze să știți câte atacuri cu viermi respinge firewall-ul dumneavoastră, probabil că vă va interesa și mai mult să știți dacă vreunul dintre aceste atacuri provine din interiorul rețelei dumneavoastră. Recent, regulile Snort au inclus reguli „reglate” precum exemplul de mai sus, dar au rămas multe altele pe care ați putea dori să le personalizați în mod similar. Lista 1 prezintă o regulă standard care vă alertează atunci când detectează viermele SQL Slammer (cunoscut și sub numele de Sapphire). Haideți să deconstruim rapid această regulă. (Pentru informații detaliate despre toți parametrii disponibili care definesc regulile, consultați documentația amănunțită a regulilor Snort la http://www.snort.org/docs/writing_rules/chap2.html#tth_sec2.3.26.)
Toate regulile trebuie să locuiască pe o singură linie și să înceapă cu o acțiune a regulii, care în acest caz este
alert
Acțiunea regulii definește modul în care Snort răspunde la regulă dacă este declanșată. Puteți modifica tipul de regulă (de exemplu, într-un șir de caractere, cum ar fi „sev1”) pentru a oferi o gestionare personalizată – de exemplu, pentru a intensifica acțiunea în cazul unei corespondențe. Acest pas este diferit de exemplul anterior, în care am folosit Oinkmaster pentru a modifica tipul de alertă al unei reguli existente; în acest exemplu, creăm o nouă regulă folosind o regulă existentă ca șablon.
Setul de parametri
udp $EXTERNAL_NET any -> $HOME_NET 1434
furnizează protocolul, adresa IP, informațiile despre port și direcția de trafic pentru regulă. Această regulă îi spune lui Snort să găsească orice pachet UDP de la o sursă de rețea (pe care o definește variabila $EXTERNAL_NET) care încearcă să ajungă la variabila $HOME_NET pe portul 1434. Majoritatea regulilor implicite utilizează în primul rând variabilele $EXTERNAL_NET și $HOME_NET. Cu toate acestea, unele reguli utilizează variabile mai specifice. De exemplu, regulile care se referă la serverele DNS (în fișierul dns.rules) utilizează variabila $DNS_SERVERS. Definiți aceste variabile în fișierul de configurare Snort (de obicei snort.conf). Opțional, creați propriile variabile pentru a reflecta topologia dumneavoastră (de exemplu, $MAIL_SERVERS) și pentru a le utiliza în regulile personalizate. Definiți o variabilă folosind numele acesteia (de exemplu, var MAIL_SERVERS= 192.168.0.20/30), apoi faceți referire la variabilă prin prefixarea acesteia cu un semn de dolar ($ – de exemplu, $MAIL_SERVERS). Acțiunea regulii și acești parametri alcătuiesc antetul regulii.
Opțiunile regulii rafinează și mai mult regula astfel încât un pachet suspect (și numai un pachet suspect) va declanșa un răspuns. După cum ați putea ghici, aceste semnături pot deveni destul de detaliate și se extind mult dincolo de simpla potrivire a porturilor. De exemplu, imaginați-vă falsurile pozitive care ar rezulta dacă această regulă Slammer v-ar alerta pur și simplu cu privire la orice trafic pe portul UDP 1434.
Opțiunea msg
msg:"MS-SQL Worm propagation attempt"
oferă o descriere simplă a alertei pentru a fi utilizată în activitățile de alertă și raportare. Opțiunea content
content:"|04|"; depth:1; content:"|81 F1 03 01 04 9B 81 F1 01|";content:"sock"; content:"send";
conține șirul de potrivire a modelului de sarcină utilă sensibil la majuscule și minuscule, fie în valori ASCII, fie în valori hexazecimale (includeți valorile hexagonale cu caracterul pipe-|). Puteți specifica mai multe opțiuni de conținut. Opțiunea de adâncime urmează fiecărei opțiuni de conținut și specifică numărul de octeți din încărcătura utilă în care doriți să căutați conținutul specificat. În acest exemplu, un pachet va declanșa un răspuns dacă conține valoarea hexagonală 04 în primul octet sau restul conținutului oriunde în payload.
Regulele descărcate conțin adesea referințe la informații detaliate despre exploit-ul suspect sau motivul care a stat la baza creării regulii. Unele sisteme de raportare susțin opțiunea de referință prin furnizarea de linkuri directe către aceste informații:
reference:bugtraq,5310; reference:bugtraq,5311;reference:url,vil.nai.com/vil/content/v_99992.htm;
Snort atribuie regulile la clase și atribuie acestor clase o prioritate ridicată, medie sau scăzută. În prezent, există mai mult de 30 de clasificări, inclusiv attempt-admin, trojan-activity, attempt denial of service și network-scan. În exemplul nostru, clasificarea este
classtype:misc-attack
Snort înregistrează prioritatea de răspuns pentru intruziunile detectate. Puteți utiliza un instrument sau un script extern pentru a analiza mai departe această prioritate și a lua măsuri cu aplicația dumneavoastră de raportare.
În segmentul final
sid:2003; rev:2;
sid reprezintă o regulă Snort unică, iar rev denotă numărul de revizuire. Aceste proprietăți identifică în mod unic regula.
Adaptarea regulii
Să examinăm cum să modificăm această regulă pentru a oferi o alertă intensificată atunci când detectează gazde interne infectate. Deoarece avem de-a face cu același exploit ca și regula originală, definiția de conținut a regulii rămâne aceeași. Trebuie să modificăm doar adresele IP și direcția de trafic. Să schimbăm adresa IP sursă în $HOME_NET, după cum urmează:
udp $HOME_NET any -> $EXTERNAL_NET 1434
Snort.conf definește $EXTERNAL_NET ca fiind „any”, astfel încât această regulă va prinde în continuare pachetele corupte care vizează gazde interne (la fel ca și regula originală). Cu toate acestea, acum că avem o regulă dedicată care urmărește numai adresele IP sursă interne, putem schimba tipul de acțiune într-un tip de acțiune personalizat care declanșează o alertă escaladată.
Regula Snort actuală include această regulă de detectare a viermilor Slammer de ieșire în setul de reguli implicite. Cu toate acestea, atunci când un nou vierme, virus sau alt exploit începe să se răspândească, luați în considerare crearea de noi reguli care să evidențieze intruziuni specifice.
Crearea regulilor dumneavoastră
În plus față de regulile existente sau personalizate pe care le puteți modifica sau crea, este posibil să doriți să includeți reguli pe care le obțineți dintr-o altă sursă. De exemplu, atunci când vestea despre un nou vierme se răspândește pe Internet, site-urile de securitate și grupurile de știri se grăbesc să publice reguli Snort unice care pot detecta noul vierme. Lipiți aceste reguli noi în fișierul local.rules, apoi reporniți Snort pentru ca noile reguli să intre în vigoare.
Snort oferă cadrul pentru un IDS ieftin și personalizabil. Susținut de un set de reguli sprijinit de comunitate, Snort rămâne un sistem flexibil și eficient. Menținerea regulilor la zi vă va crește vigilența și va reduce zgomotul care rezultă din alertele ineficiente. La fel ca în cazul oricărui proiect open-source, dacă vă acordați timpul necesar pentru a înțelege cum funcționează și vă familiarizați cu suplimentele dezvoltate de comunitate, vă veți simți mult mai confortabil cu sistemul și îi veți crește eficiența în mediul dvs.
.