Sustavi za detekciju napada

Za potpunu zaštitu računalne mreže od neovlaštenog pristupa i brojnih malicioznih programa potrebne su pojedinačne sigurnosne kontrole kao što su antivirusni programi i vatrozidi (eng. firewall), sustavi za prevenciju neovlaštenog pristupa (eng. Intrusion Prevention System) IPS i sustavi za detekciju neovlaštenog upada (eng. Intrusion Detection System) čija će tematika biti temelj za pisanje ovog projektnog zadatka. Detekcija neovlaštenih upada predstavlja izrazito važnu komponentu svakog čitavog sigurnosnog sustava. IDS je zasnovan na skupljanju informacija sa čitavog niza mrežnih i računalnih izvora i analiziranju tih informacija s ciljem otkrivanja eventualnih nedozvoljenih aktivnosti. Napadom se smatra štetna aktivnost koja na sustav djeluje s lokacije izvan sustava, a iste takve aktivnosti koje djeluju unutar samog sustava su kvalificirana kao pogrešno korištenje. Svaki IDS mora biti strogo definiran od strane sigurnosne politike organizacije jer pomoću nje se definiraju pravile i procedure koje specificiraju kako se sigurnosna politika provodi na računalnim sustavima i mreži.

--Zoran Kos 19:32, 17. siječnja 2013. (CET)

Kratak pregled povijesti razvoja IDS-a

Sam koncept IDS-a seže u 1980 g., a osmislio ga je James P. Anderson definiravši pokušaj upada ili ugrožavanja sustava kao pokušaj pristupa privatnim informacijama, manipulacijom tih informacija ili pokušajem onesposobljavanja ili sprečavanja rada udaljenog računalnog sustava. Na početku devedesetih godina prošlog stoljeća Davis T. Heberlein predstavio je ideju o mrežnom otkrivanju upada. Godine 1990. Heberlein je bio glavni autor i programer alata NSM (eng. Network Security Monitora). NSM je prvi mrežni detektor upada u sustav i raspoređen je na glavna državna postrojenja gdje analiza mrežnog prometa daje goleme količine informacija. Ova nova svijest proizvodi više interesa u području otkrivanja upada i dovodi do porasta ulaganja u to tržište. Heberleinov doprinos se proširio na projekt DIDS gdje je zajedno s timom Haystack predstavio prvu ideju hibridnih otkrivanja upada. Rad projekta Haystack i predstavljanje alata NSM je donijelo revoluciju sustava IDS i donijelo ga u komercijalni svijet. Komercijalni razvoj tehnologija otkrivanja upada počeo je 1990. godine. Haystack Labs je prvi komercijalni prodavač alata IDS. Istovremeno je Kriptološki centar za podršku ratnog zrakoplovstva razvio Automatizirani mjerni sustav sigurnosti – ASIM (eng. Automated Security Measurement System) za praćenje mrežnog prometa. ASIM je bio prvo rješenje koje je uključivalo i programska i sklopovska rješenja za mrežno otkrivanje upada i još je uvijek u uporabi po cijelom svijetu. Kao što se često događa, razvojna skupina projekta ASIM formirala je komercijalnu tvrtku 1994. godine koja se zove Wheel Group, a njihov proizvod je alat NetRanger koji je prvi komercijalno održiv. Ipak, komercijalni sustavi za otkrivanje upada polako su se razvijali tijekom tih godina, a jedini pravi procvat dogodio se u drugoj polovici desetljeća.

U razdoblju dužem od 20 godina unatrag, pa do danas broj prijavljenih sigurnosnih incidenata porastao je gotovo 100.000 puta, a trend se udvostručuje svake slijedeće godine. Razlog takvog drastičnog rasta je sve veći porast korisnika interneta koji postaje sve dostupniji i jeftiniji za korištenje. Ono što također pridonosi povećanju napada jest što postoji malen broj raspoloživih operacijskih sustava pa pronalaženjem potencijalnih propusta u bilo kojem od njih napada automatski dobiva veliki broj potencijalnih žrtava na kojima može iskoristiti pronađeni propust. Danas osoba koja ima namjeru napasti sustav ne mora raspolagati s velikim znanjem kako sustav funkcionira, dovoljno je znanje korištenja programskih alata za napade koji automatski čine pretragu, skeniranje i upad u sustav. Tako da danas znanje i vještine napadača postaju sve manje važni faktori, jer to sve rade alati umjesto njega. U vrijeme kada je gotovo svako računalo priključeno na Internet i zbog svih ostalih prethodno navedenih razloga, mrežna sigurnost i razvoj sigurnosnih rješenja za obranu od napada s mreže čine jedno od najbrže razvijajućih područja računalne industrije. Posebnu ulogu u tome ima razvoj alata za obranu od ranjivih mrežnih usluga, među kojima važnu ulogu imaju i sustavi za otkrivanje napada sa mreže (za primjer je uzet programski alat Snorb koji će detaljno biti obrađen tokom razrade ove teme). Tržište za otkrivanje upada počelo je dobivati popularnost i uistinu ostvarivati prihode od 1997. godine. Te godine je lider na tržištu mrežnog osiguranja, ISS (eng. Internet Security Systems), razvio sustav za mrežno otkrivanje upada i nazvao ga RealSecure. Trenutno, statistika tržišta pokazuje da su sustavi IDS među najprodavanijima tehnologijama za sigurnost, a taj bi se trend trebao nastaviti.

--Zoran Kos 19:32, 17. siječnja 2013. (CET)

Važne karakteristike IDS-a

Paralelno s razvojem raznih metoda napada na informacijske sustave razvijali su se i obrambeni mehanizmi i tehnike. Jedna od prvih, a danas vjerojatno i najčešće korištenih metoda je korištenje mrežne sigurnosne stijene (eng. firewall). Sigurnosna stijena je u svojoj osnovi programsko ili sklopovsko rješenje koje djeluje kao filtar paketa i služi za osnovno nadziranje prometa između raznih područja povjerenja (eng. zones of trust), čime je moguće u potpunosti zabraniti ili selektivno propuštati promet prema određenim grupama računala. Tipična takva područja koja se koriste su: lokalna mreža (eng. local network) s najvećim stupnjem povjerenja, demilitarizirano područje (eng. demilitarized zone) s manjim stupnjem povjerenja i Internet s najmanjim stupnjem povjerenja. Glavni nedostatak sigurnosne stijene je što većina takvih rješenja radi na mrežnom i prijenosnom sloju, čime je moguće propuštanje ili zabranjivanje prometa samo u ovisnosti o podacima dostupnim na tim slojevima. Mnoge metode zaštite zahtijevaju analizu paketa na slojevima višim od prijenosnog, a posebno na aplikacijskom sloju. Jedna od popularnijim metoda za analizu sigurnosti na određenoj mreži je ona koja koristi sustave za privlačenje napadača (eng. honeypots) koji se koriste kako bi zavaravali napadača tako da povjeruje da radi nad stvarnim poslužiteljem. Uvjet je da takvi sustavi moraju biti dobro izolirani od stvarnog poslužitelja kako napadač ne bi mogao pristupiti ostalim računalima u mreži. Ovakvi sustavi su vrlo često usko objedinjeni sa sustavima za otkrivanje napada sa mreže.

--Zoran Kos 19:22, 18. siječnja 2013. (CET)

Načini sprečavanja neovlaštenih aktivnosti

Danas razlikujemo dva načina sprečavanja neovlaštenih aktivnosti korisnika:

• Izrada potpuno sigurnog računalnog sustava – nije moguće izvesti u praksi, jer ne postoji ni jedan operacijski sustav ili program bez sigurnosnih rupa i proizvođači se niti ne trude napraviti takav operacijski sustav ili program. Od potpuno sigurnog računalni sustav nema nikakve koristi ako je napad izveden unutar organizacije, npr. zloupotreba korisničkih privilegija zaposlenika organizacije.
• Detekcija zlonamjernih aktivnosti – potrebno je detektirati napad što je prije moguće, poželjno u realnom vremenu, da bi se poduzela neka akcija. Tu nastupaju IDS alati koji obavještavaju da se dogodila neovlaštena aktivnost, ali se ne poduzimaju nikakve preventivne mjere kada su detektirane neovlaštene aktivnosti.

Najčešći način detektiranja neovlaštenih aktivnosti u IDS alatima je pregledavanje logova generiranih od strane operacijskih sustava. Log predstavlja zapis o aktivnosti korisnika na računalnom sustavu, gdje je više njih zapisano u pojedine datoteke kronološkim redoslijedom. S obzirom da se radi o datotekama s puno sadržaja IDS alati automatiziraju njihovo pregledavanje i na taj način liše od posla administratore da sami pregledavaju te datoteke. Logovi su jako bitni jer nakon napada na temelju njih može se utvrditi počinjena šteta, tko stoji iza napada i koje korake treba poduzeti da bi se onemogućio napad u budućnosti. U svakoj velikoj organizaciji potreba za korištenjem IDS sustava je neophodna, tome govori u prilog i slijedeća rečenica. Prema izvještaju Eugene H. Spafforda, vrsnog poznavatelja ranjivosti računalnih sustava, stoji da je u posljednjih pet godina krađa informacija porasla za 250%, da je 99% velikih organizacija prijavilo barem jedan sigurnosni incident i da šteta pričinjena neovlaštenim upadima u računalnim sustavima raste na 10 milijardi američkih dolara godišnje.

--Zoran Kos 19:15, 18. siječnja 2013. (CET)

Pristupi u implementaciji IDS-a

Prilikom postavljanja IDS alata administratori mrežnih sustava moraju odgovoriti na dva ključna pitanja: "Gdje je potrebno postaviti IDS alat" i "kako će funkcionirati taj IDS alat?". Odgovor na pitanje gdje postaviti IDS ovisi o trima varijantama, a one su: na računalu gdje rade korisnici, na mreži gdje se skuplja podatke ili u kombinaciji računala ili mreže. Odgovor na drugo pitanje je malo kompliciranije, ali također ovisi o dva pristupa koji su u suprotnosti jedan od drugoga:

• Detekcija potpisima
• Detekcija statističkim anomalijama

Detekcija statističkim anomalijama je metoda koja neovlaštene aktivnosti detektira analizirajući statistiku skupljenih podataka da bi ustanovila neovlaštene aktivnosti u tijeku. Početna točka u implementaciji ovakvog IDS-a je izrada profila normalnog korištenja sustava temeljenog na statističkim uzorcima računalnih podataka za neko specifično vrijeme normalnih, ovlaštenih operacija i korištenja sustava. Nakon toga IDS alat cijelo vrijeme nadgledava praćene atribute i gleda statistički važne devijacije prema ovom profilu. Ako je devijacija uočena, podaci se šalju na IDS-ovu funkciju za odgovor. Suvremeniji alati imaju mogućnost izmjene i nadopunjavanja profila kako bi sustav za detekciju bio što pouzdaniji tijekom dugog vremena korištenja.

• Prednosti: sustav ne traži ne-karakteristične događaje pa može detektirati nove napade,
• Nedostaci: sustav kreira velik broj lažno-pozitivnih i lažno-negativnih napada, ako se profil sustava dovoljno brzo ne mijenja, postoji mogućnost da napad neće biti detektiran.

Detekcija potpisima je prilično jednostavna metoda za implementaciju IDS alata. Skupljaju se podaci mrežnog prometa ili zapisa iz sigurnosnih logova, koji se šalju u pretraživački program gdje se uspoređuju sa definiranim potpisima za napade neovlaštenih korisnika. Ako jedna grupa ovih podataka odgovara opisu za pojedini napad podaci se šalju na funkciju za odgovor IDS alata. Pozitivna karakteristike ove metode jest ta što nije potrebno početno razdoblje tzkv. učenja sustava da bi prepoznavao napade, jer se koriste već gotovi potpisi napada. Primjer takvog programa je i sustav za otkrivanje napada sa mreže je Snort.

• Nedostaci: napadi su definirani eksplicitnim potpisima, koji su smješteni u bazi, što znači da što je potpis općenitije opisan to će IDS alat vraćati više obavijesti o lažnim napadima, preveliko trošenje resursa, potreba za dugom vremenskom obradom podataka.
• Prednost: prihvatljiv način detektiranja napada koji traju vrlo dugo budući da će biti detektirani prije nego što su do kraja završeni.

--Zoran Kos 19:15, 18. siječnja 2013. (CET)

Lažne detekcije napada IDS-a

Lažno pozitivno detektirani napadi mogu dovesti do sprečavanja normalnog funkcioniranja sustava dok lažno negativni napadi mogu ostaviti sustav otvoren neovlaštenim korisnicima. Trendovi najnovijih istraživanja idu prema modelima koji su hibridi detekcije potpisima i statističkih anomalija. Odgovori na napade ovise o pojedinom alatu IDS-a koji se koristi. Oni tradicionalni alati koriste funkcije obavještavanja administratora putem e-maila, paginga i SMNP protokola, što je zapravo i najsigurniji načini odgovora na napade IDS alata. Najistaknutiji modeli sustava za detektiranje neovlaštenih aktivnosti su: Dorothy Denning, IDES (Intrusion Detection Expert System) i NMS (Network Securty Monitor). Rad IDS-a zasniva se na nadziranju pojedinih dijelova operacijskog sustava, te analiziranju zaglavlja i sadržaja paketa na raznim slojevima mrežnog stoga. Obje vrste podataka sadrže informacije o aktivnostima korisnika, pa je na osnovu analize njihova sadržaja moguće prepoznati neuobičajene aktivnosti i napade. Pri analiziranju mrežnog prometa IDS ni na koji način ne smije usporavati mrežni promet – njegov rad mora biti u potpunosti nevidljiv korisnicima mreže i svih sustava na mreži. Dobra preporuka da se poslovi koji su vezani za analizu mrežnog prometa obavljaju na računalu isključivo namijenjenom za prepoznavanje i praćenje napada na određeni poslužitelj, aplikaciju ili grupu računala u mreži. Ako je takvo računalo ili više njih integrirano u sustav tada ih nazivamo senzorima.

--Zoran Kos 08:29, 20. siječnja 2013. (CET)

Načini zaobilaženja IDS-a

Zaobilaženje sustava IDS podrazumijeva skrivanje napada na neko računalo u mreži od IDS sustava. Najjednostavniji način zaobilaženja sustava IDS je izvođenje DoS (eng. Denial of Service) napada na njemu, čime se onemogućuje njegov rad. Nekada je dovoljno samo uzrokovati jako veliki broj lažnih alarma zbog čega će administratorima biti teško razlučiti pravi napad od lažnog. Nešto složeniji načini zaobilaženja otežavaju usporedbu uzoraka u IDS-ovim pravilima. Primjerice, ako IDS provjerava postoji li u paketima niz znakova „etc/passwd“, napadač može tako oblikovati svoj napad da se koristi drugačiji niz znakova koji ima istu posljedicu, npr. „etc/./passwd“. Često korištene tehnike su zamjene znakova s drugačijim kodiranjem, a kao primjer se može uzeti Unicode format koji omogućuje različite prikaze istog znaka. Možda najsloženije tehnike zaobilaženja sustava IDS uključuju fragmentiranje paketa. Napadač namjerno fragmentira paket u kojem se nalazi zloćudni kod tako da zavara IDS. Često se koriste mogućnosti protokola TCP (eng. Transmission Control Protocol) poput RST (eng. reset) zastavica, zaštitnih suma zastavica hitnosti. IDS sustavi sastoje se od nekoliko komponenti, koje su u jednostavnim implementacijama IDS sustava ugrađene u jedan uređaj:

• senzori koji otkrivaju sigurnosne prijetnje,
• upravljačke ploče koja služi za praćenje događaja i uzbuna te kontrolu senzora i
• središnjeg uređaja koji događaje zabilježene senzorima sprema u bazu podataka te, uz pomoć sustava pravila, generira uzbune (eng. alert) na temelju uočenih događaja.

--Zoran Kos 22:00, 17. siječnja 2013. (CET)

Arhitektura IDS-a

IDS je logički podijeljen na nekoliko zasebnih komponenti. Pojedine komponente sustava međusobno surađuju s zajedničkim ciljem efikasnog otkrivanja pojedinih vrsta napada te generiranja sigurnosnih upozorenja i njihovog spremanja u datoteke dnevnika (eng. log files). Komunikacija između pojedinih komponenti ostvarena je razmjenom poruka. Primarna namjena razdvajanja cjelokupnog sustava na više međusobno ovisnih komponenti je jednostavnost razvoja, bolja podjela zadataka unutar sustava te mogućnost da se koriste moduli iz različitih IDS sustava u jednoj heterogenoj cjelini. Pojedine komponente se mogu smještati i na zasebnim računalima čime se ostvaruje mogućnost izrade sustava koji će maksimalno iskoristiti paralelni rad (npr. clustering rješenja) i dati najbolje performanse. Nažalost, arhitektura IDS rješenja u stvarnosti dosta varira od sustava do sustava, bilo zbog nedovoljne standardiziranosti i nedostatka standarda ili proizvođačeve namjene da onemogući korištenje pojedinih komponenti i od konkurentskih proizvoda. Tipične komponente od kojih se sastoji IDS su sljedeće, a grafički su prikazane pomoću slike 1.1.:

• dekoder paketa
• pretprocesor
• sustav detekcije
• sustav za vođenje dnevnika i upozoravanje
• izlazni moduli

Ponegdje se kao zasebni dio IDS-a izdvaja i konzola za nadziranje rada sustava. Konzola za nadziranje sustava služi za praćenje rada i upravljanje pojedinim dijelovima sustava te IDS senzorima. U većini stvarnih implementacija IDS-a konzola za nadziranje sustava nije ništa drugo nego posebno izdvojeni senzor ili svaki senzor ima mogućnost upravljanja ostalim senzorima. Moguća su i grupiranja pojedinih funkcija u jedinstveni modul, primjerice dekoder paketa i pretprocesor mogu biti dio modula za pripremanje mrežnih paketa. Međusobnu ovisnost pojedinih modula prikazana je na slici u ovom poglavlju. Tok paketa koji ulazi u IDS prikazan je punom strelicom. Akcije koje IDS može poduzeti na paketu prikazane su isprekidanom crticom. Na putu od dekodera paketa do izlaznih modula paket može biti ili ispušten ili će se za njega generirati odgovarajuće sigurnosno upozorenje i zapis u datoteci dnevnika.

Slika br. 1.1. Arhitektura IDS sustava

--Zoran Kos 23:47, 17. siječnja 2013. (CET)

Vrste IDS-a

U mnogim literaturama kojima je tematika računalna sigurnost, IDS-ovi se najčešće klasificiraju prema svojoj namijeni. U osnovi razlikujemo dvije vrste IDS-a (NIDS i HIDs), ali u mnogim literaturama možemo raspozanit četiri osnovne skupine i od kojih je jedna kombinacija prethodnih (DIDS), pa tako imamo:

1. NIDS (eng. Network intrusion detection system) – neovisna platforma koja identificira upade provjerom mrežnog prometa i praćenjem većeg broja računala. Takvi sustavi dobivaju pristup mrežnom prometu povezujući se na parični obnavljač (eng. hub) ili komutator (eng. switch), koji su konfigurirani za preslikavanje priključaka (eng. port mirroring – kopiranje mrežnih paketa s jednog priključka na drugi) ili sl. Primjer ovakvog sustava je alat Snort. Cilj NIDS-a je nadzirati rad ranjivih mrežnih usluga i aplikacija, pratiti rad korisnika na mreži te paziti na dobro poznate propuste u mrežnim protokolima i porukama koje se razmjenjuju. NIDS u svojoj osnovi djeluje vrlo slično kao i aplikacijska sigurnosna stijena ili aplikacijski prilaz (eng. application level gateway).
2. PIDS (eng. Protocol-based intrusion detection system) – radi se o sustavu ili agentu koji se obično instalira na poslužitelju te prati i analizira komunikacijski protokol (primjerice HTTP, eng. Hypertext Transfer Protocol) između povezanih uređaja (računala ili sustava).
3. APIDS (eng. Application protocol-based intrusion detection system) – radi se o sustavu ili agentu koji obično između grupe poslužitelja prati i analizira komunikaciju specifičnim aplikacijskim protokolima. Npr. za web poslužitelj s bazom podataka pratio bi se SQL protokol.
4. HIDS (eng. Host-based intrusion detection system) – radi se o agentu vezanom uz jedno računalo. On identificira upade pomoću analize sistemskih poziva, aplikacijskih zapisnika, izmjena datotečnih sustava i drugih važnijih dijelova operacijskog sustava. Primjer takvog sustava je OSSEC HIDS, NESSUS, SAMHAIN. Rad HIDS-a zasniva se na prikupljanju potpisa ili sažetka (eng. hash, digest) te praćenju dozvola na kritičnim sistemskim datotekama, nadziranju rada s datotečnim sustavom, nadziranju procesa, memorije i td. Važan dio HIDS-a je baza podataka koja sadrži informacije o ranjivim programima i uslugama na osnovu kojih sustav može procijeniti rizičnost pojedinih pokrenutih aplikacija, te dati ukupnu procjenu o sigurnosti.
5. DIDS (eng. Distribuited Intrusion Detection System) - distribuirani sustav za otkrivanje upada, sastoji se od sustava NIDS, HIDS ili oba, a njegov način rada prikazuje slika br. 1.2. DIDS se sastoji od senzora smještenih po cijeloj mreži koji šalju izvještaje u središnju upravljačku jedinicu te središnje upravljačke jedinice koja sadrži bazu potpisa. Ako za to dođe potreba, ti se potpisi šalju do određenog senzora kako bi on mogao provesti određenu akciju. Između središnje upravljačke jedinice i senzora koristi se kriptirana VPN3 (eng. Virtual Private Network) veza.

Slika br. 1.2. Distribuirani sustav za otkrivanje napada

Također, postoji i podjela na pasivne i reaktivne sustave – pasivni sustavi uoče potencijalnu opasnost, zabilježe odgovarajuće informacije i generiraju uzbunu, dok reaktivni sustavi, koji se često nazivaju i IPS-ovima (eng. Intrusion prevention system), reagiraju na uočeni problem resetiranjem veze, reprogramiranjem vatrozida i sl.

--Zoran Kos 23:57, 17. siječnja 2013. (CET)

Problemi i nedostaci IDS-a

Glavni nedostaci IDS-a

Uz brojne prednosti, postoje i određeni nedostaci IDS-ova. Pregledavanjem sadržaja mrežnih paketa te datoteka sa dnevničkim zapisima često se dozvoljeni promet krivo okarakterizira kao nedozvoljeni, odnosno nedozvoljeni kao dozvoljeni. Do ove pojave dolazi uslijed previše općenitih definicija potpisa pojedinih vrsta napada. IDS-ovi uglavnom ne mogu zaustaviti ili usporiti aktivne mrežne napade. Zbog mogućih dojava o lažnim napadima na sustav, nije niti je poželjno da IDS-ovi prekidaju uspostavljene veze jer bi to rezultiralo velikim brojem neopravdanih prekida u radu. Posljedica činjenice da IDS-ovi ne mogu prekinuti napade je generiranje onoliko sigurnosnih upozorenja koliko ima dnevničkih zapisa o samim napadima. Pošto se ponekad i ispravni promet neopravdano prepoznaje kao napad, količina upozorenja za sistemske administratore se time dodatno povećava.

Sljedeći problem je vremenski raskorak između napada i otkrivanja napada. Iz razloga što IDS mora analizirati veliki broj zapisa te moguće potrebe za naknadnom provjerom dojave o napadu od strane sistemskog administratora, IDS-ovi pružaju spor odgovor na napade na računalne i mrežne resurse. Još jedan od nedostataka IDS-ova je činjenica da oni ne mogu otkriti nove vrste napada, nego mogu ustanoviti samo već postojeće. Kako ovakvi sustavi uglavnom uspoređuju sadržaje dnevničkih zapisa i mrežnih paketa s definiranim potpisima za napade, novi napadi nisu sadržani u bazi potpisa pa ih IDS niti ne prepoznaje. Otkrivanje nepoznatih vrsta napada moguća je samo ukoliko je IDS zasnovan ili kombiniran sa metodom prepoznavanja statističkih anomalija.

Na kraju, u zadnje vrijeme je prisutna sve veća tendencija kriptiranja prometa koji prolazi kroz mrežu. Sve više mrežnih usluga razmjenjuje poruke preko sigurnih kanala i virtualnih privatnih mreža (VPN). IDS-ovi imaju velikih problema u nadziranju veza zaštićenih IPSec rješenjima ili ostvarenih putem npr. SSH tuneliranja. Problem postaje sve veći, a pogotovo dolazi do izražaja kada se uzme u obzir da će prelaskom s IPv4 na IPv6 gotovo sav promet postati kriptiran. Zbog spomenutih nedostataka očito je da je nužno razinu sigurnosti pomaknuti s otkrivanja zlonamjernih aktivnosti na njihovo sprečavanje, pa je tako došlo do razvoja sustava za sprečavanje mrežnih napada (eng. Intrusion Prevention System – IPS). IPS-ovi omogućavaju preventivno djelovanje glede računalnih napada i izbjegavanje nastajanja štete koja bi bila prouzročena tim napadima.

--Zoran Kos 19:21, 18. siječnja 2013. (CET)

Tehnike smanjenja učinkovitosti IDS-a

Postoje tri glavne skupine tehnika koje smanjuju učinkovitost IDS sustava, na način da zaobilaze sigurnosne mjera koje postavljaju IDS sustavi, a to su:

1. Odbijanje usluge (eng. Denial of Service)
   • Učiniti mrežni IDS sustav neučinkovitim tako da mu ta tehnika zada previše posla. Ako se NIDS „bombardira“ s lažnim aktivnostima pravi napadi mogu proći nezapaženo. Promet može biti usmjeren izravno na mreži IDS sustava ili na uređaj u mreži koji se nalazi u izvorišnoj adresi.
   • Sprječavanje mrežnog IDS sustava od obavljanja bilo kakvih analiza. NIDS je ili instaliran na standardni operacijski sustav ili na neke druge uređaje koji rade s prilagođenim operacijskim sustavima namještenim da samo pokrenu aplikaciju.
2. Umetanje paketa (eng. Insertion)
   • Kodiranje URL niza (eng. URL Encoding) - tehnika kada se unutar URL niza zamijene znakovi s njihovim heksadecimalnim ekvivalentom. Pseudo inteligentni mrežni IDS neće moći prevariti ovaj način zbog toga što će analizirati zahtjev prije pokretanja. Ova tehnika je dobro dokumentirana i ugrađena u mnoge alate i najvjerojatnije neće prevariti IDS sustav.
   • Obrnuti obilazak (eng. Reversed Traversal) - način kako bi se pokušao omesti NIDS sustav je tako da se „zakomplicira“ zahtjev. Zahtjev će se i dalje točno rješavati na ciljanom uređaju u mreži, ali će mrežni IDS odbaciti paket. Ovaj napad je dosta star i uvelike prepoznatljiv kod svih IDS alata.
3. Samoreferentni direktoriji (eng. Self-Referencing Directories) - tehnika je slična tehnici obrnutog obilaska. Dodavanjem znaka „/.“ u bilo koji zahtjev neće imati utjecanja na značenje zbog toga što to znači da je sadašnja pozicija u trenutnom direktoriju. Npr. /cgi-bin/test-cgi postaje /./cgi-bin/./test.cgi. Ovo je novija tehnika za upad u sustav od tehnike obrnutog obilaska i prošlo je neko vrijeme dok je nisu autori IDS sustava uspjeli otkrili.
   • Skrivanje parametara (eng. Parameter Hiding) - zahtjev može sadržavati dodatne informacije (parametre) koji se koriste za izgradnju dinamičnih stranica. Parametri se obično koriste kod zahtjeva za pretraživanjem i preuzimaju sljedeći oblik: /anypage.php?attack=paramhiding&evasion=blackhat&success... Parametri su navedeni nakon znaka „?“ i pseudo inteligentni IDS će vjerojatno ignorirati sve podatke poslije njega kako bi poboljšao učinkovitost obrade. Znak „?“ može se koristiti kako bi se sakrili važni podaci.
   • Dugi URL nizovi (eng. Long URLs) - čak i grubi mrežni IDS ima tehnike uzorkovanja koje su napravljene kako bi se poboljšala učinkovitost. Jedna takva tehnika je ograničiti količinu uzoraka podataka za svaki okvir. Očito će okvir koji premašuje određenu dužinu biti samo dijelom pročitan i analiziran. Ako je paket povećan na ovu duljinu onda će bilo koji opasni sadržaj (izvan okvira) proći bez provjere.
   • Više kosih crta (eng. Multiple slashes) - moguće je poslati zahtjev na web poslužitelj koji zamjenjuje jednostruke kose crte s više kosih crta i web poslužitelju će i dalje ti zahtjevi izgledati valjani. Napad je uspješan ako mrežni IDS sustav ne može uspješno usporediti zahtjev s pravilima. Pseudo inteligentni sustavi ne mogu tako lako biti prevareni, dok su rani grubi IDS sustavi uspjeli biti zavarani. No danas su se i oni razvili i ni njih se više ne može prevariti ovom metodom.
4. Izbjegavanje (eng. Evasion)
   • Sporo skeniranje (eng. Slow Scans) – NIDS nadziranjem učestalosti prometa dane IP adrese otkrije aktivnost skeniranja mreže. Ako alat za skeniranje može umjetno raširiti aktivnost skeniranja na duže vrijeme, NIDS možda neće otkriti ovu aktivnost.
   • Metoda podudaranja (eng. Method Matching) – sasvim je legitimno unutar HTTP RFC-a (eng. Request for Comment) poslati alternativnu metodu da bi se dobio odgovor koja je metoda izvorno bila jedina dostupna. Alternativne metode su vrlo korisne napadačima zbog toga što omogućavaju otkrivanje prisutnosti CGI (eng. Common Gateway Interface) skripta na web-poslužitelju.
   • Zahtjev za prijevremeni kraj (eng. Premature Request Ending) - tehnika je napravljena kako bi se zavarao pseudo inteligentni mrežni IDS. Metoda pokušava postaviti kraj zahtjeva prije njegovog stvarnog završetka i prije zlonamjernih podataka.
   • Netočno formatiranje HTTP zahtjeva (eng. HTTP Mis-Formating) – iako postoji jasno definirana struktura za bilo koji HTTP zahtjev, mnogi web-poslužitelji će prihvatiti zahtjev koji ne odgovara točno određenom obliku. Pa bilo koja analiza koja ovisi o RCF formatu tada neće uspjeti
   • Sintaksa DOS direktorija (eng. DOS directory syntax) – u DOS-u za specificiranje putanje direktorija koristi se znak „\“, dok je u Unix sustavu taj znak „/“. Kao rezultat ovoga, web-poslužitelji koji se zasnivaju na DOS-u moraju prevesti kosu crtu unaprijed u kosu crtu unatrag.
   • Prepoznavanje velikog i malog slova (eng. Case Sensitivity) – kod operacijskog sustava Unix slijedeći izrazi imaju drugačije značenje: Password, PASSWORD, PassWord.. Sustav DOS bi gore navedene nizove znakova interpretirao kao iste dokumente. Prema tome, ako se pošalje zahtjev koji ima sva velika slova, on će se i dalje interpretirati točno. Pseudo inteligentni IDS je još uvijek ranjiv na ovu taktiku.
   • Spajanje sjednica (eng. Session Splicing) - spajanje sjednica je različito od fragmentacije i radi samo slanje HTTP podataka u dijelovima, sa svrhom sprečavanja oba mrežna IDS sustava da uspješno otkriju podudaranje niza znakova. Ponovo sastavljanje je moguće, potencijalno s pseudo inteligentnim IDS-om, ali nije vjerojatno obzirom na velike obrade podataka koje su nastale.
   • Metode za obradu NULL znaka (eng. NULL Method Processing) - Ova se tehnika oslanja na činjenici da se u programskom jeziku C koristi NULL znak za označavanje kraja niza znakova. Pseudo inteligentni IDS sustav analizirati će zahtjev im interpretirati ga netočno te ignorirati zlonamjerne podatke.

--Zoran Kos 10:11, 18. siječnja 2013. (CET)

Karakteristike NIDS-a

Kao što je već prije spomenuto NIDS je sustav namijenjen prikupljanju i analiziranju mrežnog prometa koji nužno nije stvoren ili usmjeren prema računalu na kojem je postavljen IDS. Za razliku od Firewala, NIDS ne može utjecati na stanje veze pa se sve njegove aktivnosti svode na prepoznavanje i upozoravanje na napade. Mrežni IDS mogu otkriti veliki broj vrsta napada preko mreže zahvaljujući već unaprijed poznatim potpisima napada. Glavne vrste takvih potpisa vezane su uz nadziranje karakterističnih ciljeva u mrežnim paketima. Najčešće se nadziru sadržaj paketa, zaglavlje paketa te pristupna vrata. Primjer niza znakova u sadržaju paketa koji se može tražiti je niz:

cat “+ +” > /.rhosts 

“cgi-bin”, “ifs”, “aglimpse” itd. 

Druga vrsta potpisa traži sumnjive pakete koji stižu na računalo i cilj im je pristupiti karakterističnim pristupnim vratima (IMAP, SunRPC, Telnet, FTP...), a na lokalnom računalu nisu pokrenute mrežne usluge na tim pristupnim vratima. Posljednja vrsta potpisa zadužena je za otkrivanje opasnih i nelogičnih kombinacija u zaglavljima mrežnih paketa. Najpoznatiji takav primjer je program Winnuke, koji je slao pakete na NetBIOS pristupna vrata s uključenim opcijama URG (eng. urgent pointer) i OOB (eng. out of band). Zbog propusta u operacijskom sustavu Microsoft Windows, takvi paketi su uzrokovali trenutno rušenje sustava. Sličan primjer malicioznih paketa su i paketi koji u zaglavlju imaju uključenu i SYN i FIN opciju čime napadač pokušava uspostaviti i zatvoriti vezu u isto vrijeme. Najpoznatiji programi koji mogu otkriti sve prethodno navedene vrste napada su Snort, Axent, Cisco Secure IDS, ISS, Shadow itd.

Prilikom spomena NIDS-a, većina ljudi pomisli na prepoznavanje uzoraka, no postoji još jedan način njegove implementacije, a to je analiza protokola. Arhitektura NIDSA-a temeljenih na analizi protokola u potpunosti se razlikujue od one arhitekture koja je na prepoznavanju uzoraka. Alati koji se temelje na analizi protokola imaju mogućnost analize podataka u stvarnom vremenu, tako da mogu brzo odrediti koji se problemi dešavaju na mreži. NIDS temeljen na analizi protokola će dekodirati svaki paket prema specifikaciji protokola, te će zatim provjeriti polja da provjeri da li onda odgovaraju standardu, ako ne odgovara standardu, paket će biti označen. Za pakete koji odgovaraju standardu, ali i dalje jesu napadi, npr. showcode.asp, bin/sh, NIDS može napraviti prepoznavanje uzoraka u određenim poljima koje valja provjeriti, umjesto provjeravanja cijelog paketa. Poboljšanje performansi ove metodologije ovisit će o mnogim faktorima: veličini paketa, veličini odgovarajućih polja, komponenti koje valja provjeriti i td. Nedostaci ove ahtekture su:

• Svaki proizvođač implementira protokol prama svojoj implementaciji RFC-a (eng. Request for Comments). Na taj način moguće je dobivanje lažnih pozitivnih rezultata, ukoliko se paketi ne vrednuju na isti način od uređaja koji stvaraju promet i NIDS sustava.
• Mogućnost pronalaska načina rada NIDS sustava temeljenog na analizi protokola.
• Način na koji NIDS tretira pakete koje ne može dekodirati. U tom slučaju šalje poruku korisniku da ne može dekodirati paket ili koristi heuristiku na paketu i provjerava je li to poznati protokol koji se nalazi na nekom drugom portu.

Postavljanjem NIDS-a u LAN uočavaju se mnoge situacije gdje je NIDS temeljen na analizi protokola odgovarajući alat. Većina velikih kompanija koriste Snort ili neki interni routing protokol. Većina tih protokola osvježava se putem multicasta (OSPF, EIGRP) ili broadcasta (RIP, IGRP). U zadnjih nekoliko godina napisani su alati poput irpas-a, nemesis-a i nmap-a koji mogu izvlačiti informacija iz tih protokola, ili ih čak lažirati. Korištenjem tih alata napadač može ozbiljno narušiti rad mreže ubacivanjem krivih ruta ili loših paketa (pogotovo ako napadač uspije lažirati gateway i hvatati pakete, te ih prosljeđivati pravom gatewayu. NIDS može biti u mogućnosti detektirati routing protokole, ali ne zna koje vrste protokola bi trebale biti pokrenute i koko bi trebale biti konfigurirane. Slika 2.1. prikazuje na jednostavan način kako funkcionira NIDS.

Slika 1.3. Mrežni IDS

--Zoran Kos 10:11, 18. siječnja 2013. (CET)

Programski alat Snort

Općenito o Snortu

Programski alat Snort je besplatan, ali vrlo napredan alat namijenjen detekciji, odnosno prevenciji nedozvoljenog pristupa sustavima, koji izvodi analizu mrežnog prometa u stvarnom vremenu, uz pripadno upozoravanje, blokiranje ili zapisivanje prometa. Ime je dobio po engleskoj riječi koja u prijevodu znači šmrkati, njušiti. Snort je razvijen od strane Martina Roecha 1998. godine uz pomoć libpcap biblioteke (C/C++ programski jezik) specijalizirane za hvatanje prometa na mreži. U početku je bio poznat pod nazivom „lagana“ tehnologija otkrivanja upada (zbog početnih 120 linija koda), a kasnije se razvio u zrelu IPS tehnologiju punu bogatih osobina i postao skoro pa standardom za otkrivanje i sprečavanje upada u sustav. Osnovna svrha mu je bila da korisniku posluži kao alat za osluškivanje (eng. Sniffer) mrežnog prometa, koji na izlazu automatski dešifrira i preprocesira pakate te javlja eventualne pogreške. Nakon što je prepoznat od strane zajednice otvorenog koda (eng. Open Source community) alat Snort je početkom 1999. godine doživio svoju prvu inačicu (1.0) koja nije imala predprocesore. Tokom iduće godine alat Snort je postao dio vlasništva tvrtke Sourcefire koju je osnovao sam tvorac alata, Martin Roesch.

Vrlo brzi razvoj Interneta donosi sve veće brzine prijenosa pa tako u jednom vremenskom intervalu prođe jako puno paketa kroz mrežu i teško je te sve pakete podataka nadzirati u stvarnom vremenu. Moglo bi se dogoditi da neki paketi podataka prođu kroz mrežu, a da nisu ni provjereni. Napredak alata Snort krenuo je od toga da se tijekom nadzora mreže provjeravaju samo ona pravila koja mogu doći u obzir s obzirom na vrstu upada u sustav. Ovakvim načinom se ne mora prolaziti kroz sva pravila i nepotrebno gubiti vrijeme na ona koja ne mogu doći u obzir je je novih upada svakim danom sve više, a time i novih pravila. Danas Snort može analizirati mrežni promet na IP mrežama i stvarati zapise u stvarnom vremenu. Radi na temelju definiranih pravila (eng. rules), ali postoje i dodaci (eng. plug-ins) koji mogu pronaći nepravilnosti u jednom paketu. Pravila pomoću kojih Snort otkriva neovlaštene upade u sustav, zapisane su u tekstualnim datotekama tako da ih korisnici mogu sami prilagođavati (nadopunjavati, brisati) prema svojim potrebama. Pravila se grupiraju u kategorije kako se za vrijeme nadziranja mreže ne bi trebalo prolaziti kroz sva pravila, nego kroz određenu kategoriju. Svaka kategorija spremljena je u svoj zasebni tekstualni dokument. Snort je izvorno napisan za sustav Linux, a s vremenom je počeo razvoj i za druge operacijske sustave. Danas je dostupan za slijedeće platforme: Linux, OpenBSD, NetBSD, Solaris, HP-UX, AIX, IRIX, MacOS i Windows. Svi detalji vezani za alat Snort, kako program funkcionira, sve izdane verzije, pravila i ostale upute mogu se naći na stranici: http://www.snort.org

Prilikom implementacije ovakvog NIDS sustava i općenito, potrebno je baratatiti dobrim znanjem TCP/IP stoga. Razlog zbog kojeg to navodimo leži u čestom korištenju paketa za logiranje mrežnog prometa tcpdupm, tako da bi korisnici trebali biti upoznati sa načinom rada i izgledom logova ovog paketa. Znanje značenja zastavica TCP/IP (npr. SYN i RST) potrebno je kako bi se razumio ID potpis koji predstavlja specijalno TCP stanje. Zbog loše konfiguracije potpisa, pravila i postavki alata Snort može doći do javljanja lažnih alarma, koji su lažno pozitivnog karaktera. Gora stvar je ako se radi o lažno negativnim detekcijama, jer u tom slučaju alat nije detektirao napad i neće doći do javljanja pogreške. Jednostavnost i velika prilagodljivost jezika za opis pravila omogućuju da svatko napiše vlastita prilagođena pravila za otkrivanje novih vrsta napada. Postoje i posebne kolekcije tj. biblioteke tako napisanih pravila održavanih od strane zajednice otvorenog koda, primjerice Bleeding Edge Threats, koje obuhvaćaju pravila za prepoznavanje gotovo svakog danas poznatog načina napada. Mogućnosti jezika za opis pravila te kratki pregled programa koji mogu surađivati sa Snortom opisani su u poglavlju o podešavanju Snorta. O važnosti samog programa govori i činjenica da je Snort de facto standard na svakoj većoj implementaciji nekog projekta temeljenog na LAMP (Linux, Apache, MySQL, PHP) platformu, te da je nezaobilazni dio skupine najčešće korištenih programa otvorenog koda (eng. Open source programs suite).

--Zoran Kos 12:47, 18. siječnja 2013. (CET)

Primjena Snort-a u organizacijama i usporedba s drugim IDS/IPS alatima

Zbog čega koristiti alat Snort

Svakoj organizaciji potrebna je zaštita od upada zbog onoga čime se organizacija bavi, u svrhu zaštite privatnih podataka, intelektualnog vlasništva, osobnih podataka zaposlenika i drugih bitnih stvari koje su u interesu tvrtke. Danas traje velika borba na državnoj razini protiv krađe autorskih prava i ostalih oblika piratstva, pogotovo najveći rast bilježi ilegalno skidanje glazbe i filmova. Najveća prijetnja organizaciji su njeni zaposlenici jer oni neupućeni ili nemarni u svojem poslu, a koriste i alate za dijeljenje poruka, kao što su Kazaa i Gnutella, koji su zabranjeni jer se povezuju s drugim računalima u svijetu i tako čine savezne zločine, ali i pozivanju potencijalne napadače na djelovanje. Preuzimanje takvog sadržaja predstavlja velik problem i alat Snort može tu uvelike pomoći, npr. može poslužiti za čuvanje propusnosti mreže tako da identificira i spriječi P2P (eng. Peer-to-Peer) aktivnosti. U posljednje vrijeme bilježi se rast napada putem medijskih formata pa i te akcije može spriječiti Snort. Snort također može poslužiti kao obrazovni alat i kao alat za otkrivanje upada u sustav na fakultetima, također može biti implementiran kao dio IT (eng. Information technology) nastavnog plana i programa. Jedan dodatak koji bi se mogao uklopiti u nastavni plan i program je alat Barnyard. Radi se o alatu otvorenog koda koji preuzima odgovornost za punjenje baze podataka s izlazom iz alata Snort. Usmjeravanje izlaza alata Snort pruža stvarne prilike za pisanje dodataka i programa za obavještavanje. Veliki broj lažno pozitivnih obavijesti koje stvara alat Snort dovode do toga da se puno podataka mora zapisati u bazu podataka. Također, jedna od obrazovnih mogućnosti za integriranje alata Snort u nastavni plan i program je pisanje izlaznih datoteka. Razvijanje izlaznih dodataka je zadatak primjerene veličine za skupinu poslijediplomskih studenata.

--Zoran Kos 18:30, 18. siječnja 2013. (CET)

Konkurencija programskom alatu Snort

Programski alat Snort ima jako dobre ocjene od strane poduzeća koje ga koriste, ali i onih kojima je zadatak da procjenjuju programske alate na području IDS-a. Navedeni alat je alat otvorenog koda koji se temelji na jeziku pravila, provjere vrši na temelju funkcija za potpise i ima dobru programsku podršku. Velika upotreba ovog alata leži u tome što je besplatan i dostupan u svim verzijama OS-a pa velika poduzeća nemaju nikakvih izdataka oko njegove nabave, ali Snorta prate popratni moduli koje tvrtka naplaćuje. Postavke alata mogu biti takve da bude „nevidljiv“ na mreži pa ostaje nezamijećen i zaštićen od napadača. Kada je ovako skriven može nastaviti s radom i zapisivati upade ako mreža postane ugrožena čime je povećana njegova praktična vrijednost. Konkurencija Snortu je mrežni alat Bro, stvoren od strane Vern Paxona u institutu Lawrence Berkley National Labaratory and International Computer Science Institute. Bro je alat otvorenog koda, koji je napisan za platformu UNIX i služi za mrežno otkrivanje upada. Mogućnosti navedenog alata slične su onima koje ima alat Snort. Bro nadzire mrežni promet koristeći skup pravila otvorenog koda kako bi mogao tražiti sumnjivi promet. Od kad je alat Bro dobio mogućnost da ga se može samostalno prilagođavati, administratori mogu određivati i provjeravati mogućnosti koje će se postaviti na mrežu. Otkrivanjem novih oblika mrežnih napada, pravila se mogu mijenjati i dodavati tako da imaju sadržane potpise tih novih napada (zbog čega se mreža može bolje nadzirati). Kao i alat Snort, Bro može otkriti nepravilnosti u mrežnom prometu i te nepravilnosti zapisati u za to određene datoteke. Bro može pružiti izvrstan mrežni IDS sustav za poduzeća za jako nisku cijenu. Dodatna prednost mu je i što je prilagođen tako da može koristiti datoteke s potpisima alata Snort. Bro bi mogao biti snažniji alat od Snort-a za mrežni IDS zbog toga što je napravljen tako da je više mrežno orijentiran te može otkriti i prijaviti sve strane aktivnosti na mreži. Alati Snort i Bro napravljeni su kako bi se u potpunosti integrirali u mrežu. Potpuno iskorištavanje mogućnosti koje nude ova dva alata zavisi o stručnosti operatera (administratora) u organizacijama koji rade na njima i koji ih uključuju (i naravno kasnije održavaju) u sustav. U kombinaciji, ova dva alata pružaju drugi sloj zaštite koji je potreban za ispravno štićenje od slabosti sustava.

Osim programskog alata Bro, konkurenciju alatu Snort čine i slijedeći alati:

1. AIDE (eng. Advanced Intrusion Detection Envirnonment) je NIDS alat koji radi na operacijskom sustavu UNIX. Glavni nedostatak ovog alata je manjak dokumentacije za podršku korisnicima. Još uvijek je u razvoju, ali ima potencijala da postane značajan alat. Ovaj alat bi trebao biti prvi izbor ako se traži NIDS za operacijski sustav UNIX.
2. Shadow IDS je alat otvorenog koda, a nastao kao dio projekta koji je pokrenuo CIDER (eng. Cooperative Intrusion Detection Environment). Ima dobru dokumentaciju kao podršku korisnicima, koristi biblioteke „tcpdump“ i „lipcap“. Predsnost u odnosu na alat Snort je ta što omogućava administratoru da postavi senzore kroz cijelu mrežu, tj. može se koristiti kao DIDS.
3. Tripwire se zasniva na uređaju u računalnoj mreži s IDS-om, a razvijen je kao projekt sveučilišta Purde University. Dostupan kao inačica alata otvorenog koda i kao komercijalna inačica. Jedan od najstarijih IDS alata, razvijen 1992. godine; djeluje na operacijskim sustavima Linux i Windows.

--Zoran Kos 13:02, 18. siječnja 2013. (CET)

Važnost i uloga Snort pravila

Kako doći do Snort pravila

Na služebnim stranicama alata Snort može se naći dokumentacija vezana za Snort pravila. Trenutna važeća verzija Snorta je 2.9., pravila su definirana od strane Sourcefire Vulnerability Research Team (VRT) Rules, a certificirana su od strane VRT Certified Rules License Agreement. Za preuzimanje i korištenje pravila potrebno se registrirati (trial verzija) ili učlaniti (plaća se godišnja članarina. Jednogodišnja članarina iznosi 30 dolara, za osobnu upotrebnu, za poslovnu ta pretplata raste i do 400 dolara ovisno koliko se inačica želi preuzeti. No tvrtka Sorcefire dopušta korištenje trial verzije koja je duga 30 dana, od dana preuzimanja registracije. Uz definirana pravila koja se mogu uređivati preko najjednostavnijeg alata za editiranje teksta (npr. Notepada), njih korisnik može i sam definirati i brisati ukoliko mu nisu potrebna. Najbolje mjesto gdje bi se trebalo početi s brisanjem pravila je kad se pogleda mapa s rasporedom uređaja u mreži. U velikim mrežama postoji puno mrežnih dijagrama pomoću kojih se može vidjeti gdje se u mreži nalaze određene mrežne tehnologije, skolopovlje, operacijski sustavi i aplikacije. Ako se koristi operacijski sustav Windows 7 u mreži onda se mogu isključiti sva pravila za druge operacijske sustave tako da se ispred njih stavi znak #. Alat Snort može potrošiti puno vremena ako vrši pretragu po svim pravilima a u stvari nema potrebe za tim.

Snort pravila podijeljena su u dva dijela, prikazana u primjeru ispod:

1. Pravilo zaglavlja – može biti mapirano prema RTN-u (eng. Rule Tree Node), odnosno sve što znači prije prve zagrade;
2. Opcije pravila – mogu biti mapirane prema OTN-u (eng. Optional Tree Node), a nalaze se unutar pravila.

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"CONTENT-REPLACE MSN deny out-bound file transfer attempts"; 
flow:established,to_server; content:"INVITE MSNMSGR"; nocase; replace:"AAAAAAAAAAAAAA"; content:"context"; 
nocase; replace:"aaaaaaa"; metadata:policy security-ips alert; classtype:policy-violation; sid:12032; rev:2;)

--Zoran Kos 18:27, 18. siječnja 2013. (CET)

Karakteristike Snort pravila

Snort može jednostavno proslijediti ove informacije kroz povezanu listu bez važnih zadrški. Najveće zadrške u računanju pojavljuju se prilikom korištenja slijedeće tri ključne riječi:

• content
• content-list
• uricontent

Svaka od tih ključnih riječi podrazumijeva pregledavanje dijela podataka u cilju pronalaženja pojedinog uzorka. Zbog zadrške koju unosi prepoznavanje uzoraka, ono je posljednji dio opcija pravila koja se provjerava. Otprilike više od 80% pravila sadrži ili content ili uricontent ključnu riječ. Kada alat Snort inicijalizira i provjeri pravila, on stvara zasebna pravila za TCP, UDP, ICMP I IP protokol. Unutar svakog stabla kasnije će se kreirati zasebne trodimenzionalna povezana lista sa RTN-ovima (prva dimenzija), OTM-ovima (druga dimenzija) i pokazivačima funkcija (treća dimenzija). RTN-ovi također uključuju i informacije o IP adresama i portovima. Kada Snort pošalje paket kroz dio za detekciju prvo provjerava koji je protokol paketa, tako da ga može proslijediti na prvo stablo pravila. Kada je paket poslan na odgovarajuće stablo na evaluaciju, biti će provjeren u odnosu na svaki RTN, s lijeva na desno, dok se ne pronađe poklapanje. Prilikom provjere RTN-ova, Snort prvo provjerava IP adresu, a zatim port, ukoliko je potrebno. Ukoliko je pronađen RTN koji odgovara promatranom paketu, paket se provjerava u odnosu na OTN-ove, te se ponovo traži poklapanje. Svi OTN-ovi se ne provjeravaju za sve opcije, jer bi to predstavljalo preveliko trošenje resursa. Umjesto toga svaki OTN ima povezanu listu pokazivača funkcija (treća dimenzija) za testove koje treba provesti u odnosu na svaki pojedini OTN. Primjer lanca zaglavlja (RTN) i lanca opcija (OTN) prikazan je na sljedećoj slici br. 3.1.

Slika br. 3.1. Izmjena rada između RTN-a i OTN-a

--Zoran Kos 18:27, 18. siječnja 2013. (CET)

Algoritam za provjeru uzoraka paketa

Snort koristi Boyer-Mooreov algoritam za provjeravanje uzoraka prilikom pregledavanja sadržaja paketa. Taj algoritam je jedan od najefikasnijih algoritama provjeravanja stringova i često se koristi za pretraživanje ili zamjenu dijelova teksta u editorima teksta. Tijekom rada NIDS-a proanalizirani paket može odgovarati više različitim pravilima, a za svako od njih algoritam se mora preokrenuti iz početka. Za primjer možemo uzeti paket koji se uspoređuje s uzorkom /cfdocs/cfmlsystaxcheck.cfm, a također i 15 idućih OTN-pva sadrži /cfdocs/ direktorij na početku uzorka, slika br. 3.2. prikazuje sve /cfsdocs/ direktorijem koji sadrže uzorke na temelju kojih Snort provjerava ulazni paket. Nakon pretraživanja paketa oučeno je da /cfsdocs/ ne postoji nigdje u paketu, ali svjedno će se provesti svih ostalih 15 provjera. Da bi se to izbjeglo u testnoj fazi se moraju koristiti algoritmi koji koriste dobre aspekte Boyer-Moorevog algoritma i Aho-Corassick algoritama za poboljšanje potrebnih performansi, k tome i tvrka Sourcefire i teži.

Slika br. 3.2. Provjera svih pravila Boyer-Mooreovim algoritmom

Aho-Corasick_Boyer-mooreov kombinirani algoritam primjenjuje se u novijim inačicama alata Snort (od inačice 5 pa nadalje). To je ustvari algoritam sličan Booyer-Mooreovom algoritmu primjenjen na skup ključnih riječi sadržanih u stablu ključnih riječi koje podsjeća na Aho-Corassickovo stablo. Na taj način su izolirane najbolje značajke oba algoritma. Najvažnija sličnost kod Boyer-Moorovog algoritma jest pomicanje pogrešnog znaka, a kod Aho-Corasick primjena stabla ključnih riječi. Kako bi se riješio netom prije navedeni problem koji je grafički prikazan slikom br. 3.2., 16 navedenih pravila u direktoriju /cfdocs/ bi se organiziralo u stablo kljčnih riječi koje je prilazano slikom br. 3.3. Efikasnost je odmah uočljiva jer neslaganje može odmah eliminirati mnoga pravila, te na taj način isključiti suvišna i nepotrebna pretraživanja.

Slika br. 3.3. Provjera svih pravila Aho-Corasick_Boyer-Mooreovim kombiniranim algoritmom

--Zoran Kos 18:25, 18. siječnja 2013. (CET)

Stvaranje novih/vlastitih pravila

Pravila se mogu prilagoditi vlastitom sustavu, ovisno o situaciji koje mogu biti tipa primjećivanje nekog nestandardnog ponašanja u mreži kao što može biti prijenos velike količine podataka bez nekog vidljivog razloga. U tom slučaju treba podatke analizirati, pokupiti uzorke prometa i napraviti odgovarajuće pravilo. Ukoliko dođe do novog oblika pravila potrebno je vlastoručno izmjeniti popis pravila, stvoriti novo pravilo koje može privremeno poslužiti svrsi dok ne izađe službena inačica koja sadrži ekvivalentno pravilo. Alat Snort razlikuje više tipova pravila, a to su:

1. Pravila protoka – bitni podaci o paketu i mrežni protokoli koji se koriste.
2. Pravila vezana za uređaje u računalnoj mreži – nisu bitni podaci o paketu, nego samo protokol, odnosno broj porta.
3. aplikacijska pravila – koriste se kod otkrivanja neobičnih ponašanja u aplikaciji ili protokolu.

Prilikom pisanja vlastitih pravila, potrebno je znati kako izgleda osnovni format pravila, koji je zorno prikazan slijedećim kodom i slikom br. 3.4.

<snort action> <protocol> <src IP> <src PORT> <direction> <dst IP> <dst port> 
(msg:"Tell the user what I'm tracking"; <optional classtype>;<optional snort ID 
(sid)>; <optional revision (rev) number>;)

Slika br. 3.4. Format pravila alata Snort

Ključne riječi iz osnovnog formata pravila:

• Snort action - radnje koje poduzima alat Snort. Ovdje može stajati jedna od tri ključne riječi:

Alert (obavijest) - šalje obavijest na osnovu potpisa,

Log (zapis) ne stvara se obavijest nego se samo zapisuje ovaj događaj u određenu datoteku te

Pass (prolaz) - govori sustavu za otkrivanje da se propuste oni paketi koji zadovoljavaju uvjete o potpisu.

• Protocol - u ovom dijelu se označava alatu Snort koji protokol se treba nadzirati. Neki od najčešćih protokola su TCP (eng. Transmission Control Protocol), UDP (eng. User Datagram Protocol) i ICMP (eng. Internet Control Message Protocol) ili može biti općenito IP protokol.
• Source IP - skupina IP adresa iz kojih alat Snort može vidjeti od kuda je uspostavljena veza.
• Direction - pokazuje da li je veza uspostavljena iz izvorne ili odredišne IP adrese.
• Destination port - odredišni priključak prometa: 80 za HTTP, 21 za FTP (eng. File Transfer Protocol) i 23 za telnet veze.
• Message - polje gdje se uz obavijesti mogu ostaviti komentari, a informacija se prikaže na mjestu za obavijesti
• Class type - oznaka prioriteta. Ako postoji više pravila koji se slažu s dijelom mrežnog prometa, ovaj parametar pomaže da se definira koje će se pravilo koristiti.
• Snort Identification (SID) number - jedinstveni broj koji je dodijeljen određenom pravilu. Pri stvaranju vlastitog pravila dodjeljuje se broj SID koji je iznad 1 000 000. Ovime se stvara vidljiva razlika između pravila alata Snort i pravila koja je korisnik sam stvorio.
• Revision number - opcionalni dio, a koristan je ako se stvara više inačica istog pravila te ako se prate promjene pravila za cijeli sustav IDS.

Nakon što smo naveli sve važne vezane za formiranje pravila, možemo napisati primjer jednog takvog jednostavnog pravila:

 alert tcp !192.168.1.0/24 any -> 192.168.1.0/24 25 

Zaglavlje pravila zadanog na ovaj način će aktivirati svaki paket koji dolazi s bilo kojih pristupnih vrata i bilo koje adrese izvan lokalne mreže na lokalnu mrežu i pristupna vrata 25/tcp (SMTP protokol). Umjesto operatora "->" koji označava jednosmjernu komunikaciju, može se koristiti i operator "<>" koji označava dvosmjernu komunikaciju. Operator "<-" ne postoji zbog čitljivosti i konzistentnosti pravila, nego je u tome slučaju potrebno okrenuti izvorišnu i odredišnu adresu te koristiti operator "->".

--Zoran Kos 18:55, 18. siječnja 2013. (CET)

Dinamička i aktivirajuća pravila

Ovakva pravila uvijek dolaze u paru, odnosno uz svako dinamičko pravilo dolazi i jedno aktivirajuće pravilo. Nijedno od ove dvije vrte pravila ne mogu postojati sama za sebe. Ukoliko se zadovolje uvjeti iz aktivirajućeg pravila, počet će se obrađivati i pripadajuće dinamičko pravilo. Aktivirajuće pravilo ponaša se kao i obično pravilo s akcijom alert, osim što ima dodatnu obaveznu opciju koja označava dinamičko pravilo koje treba obraditi ukoliko su zadovoljeni uvjeti iz zaglavlja pravila. Dinamičko pravilo se ponaša kao i pravilo s akcijom log osim što se obrađuje samo u slučaju kada ga aktivira aktivirajuće pravilo. Za definiranje ovih vrsta pravila koriste se ključne riječi activate odnosno dynamic. Primjer korištenja para dinamičkog i aktivirajućeg pravila pokazuje sljedeći ispis:

activate tcp !$HOME_NET any -> $HOME_NET 143 (flags: PA; \
content: "|E8C0FFFFFF|/bin"; activate: 1; \
msg: "IMAP buffer overflow!")
dynamic tcp !$HOME_NET any -> $HOME_NET 143 \
(activated_by: 1; count: 50;)

Navedeno pravilo otkriva napade prekoračenjem međuspremnika na IMAP protokol i zatim sprema podatke za idućih 50 paketa koji dolaze na IMAP pristupna vrata (143/tcp). Ukoliko je napad uspio vrlo je vjerojatno da će idućih 50 paketa sadržavati korisne informacije o daljnjim postupcima napadača, pa je korisno sakupiti i takve podatke za kasniju analizu.

--Zoran Kos 19:58, 18. siječnja 2013. (CET)

Primjeri pisanja Snort pravila

Kao što je već navedeno, kako bi Snort funkcionirao kako korisnik želi, potrebno je uključiti željena pravila za njega. Možda i najbolja karakteristika Snorta je da ga korisnik može prilagoditi svojim željama i potrebama, tj. pomoću pravila odabrati što i kako će Snort raditi. Budući da se neprestano izmišljaju novi napadi, često se pišu nova pravila za njihovu detekciju. Pravila se po potrebi ažuriraju i mogu se naći na Snortovoj web stranici. No, zanimljivo je da korisnik, uz malo osnovnog znanja, može napisati i svoja pravila te ih ubaciti u alat koji će ih tada koristiti. U praktičnom dijelu našeg projekta odlučili smo se malo „poigrati“ pisanjem tih pravila i provjeriti rezultate.(Napomena: prilikom pokretanja Snorta koristili smo -A console opciju kako bismo upozorenja odmah ispisali na ekran, no ako ne uključimo ovu opciju sva upozorenja, umjesto da se ispišu na ekran, pohranit će se u datoteku koju smo definirali u konfiguracijskoj datoteci - u našem slučaju to je alerts.ids koja se nalazi u log mapi).

Nakon kratkog proučavanja tutoriala odlučili smo početi s nekim jednostavnim pravilima, npr.

alert ip any any -> any any (msg: "Nadjen IP paket!"; sid:3000009)

Ovo pravilo jednostavno bilježi sve ulovljene IP pakete i šalje (ili zabilježi) upozorenje za svakog od njih. Ovo pravilo nije pretjerano korisno, ali dobro je za početak, da vidimo kako funkcioniraju Snort pravila i kako ih pisati, ali i za samu provjeru funkcionira li Snort kako treba. Na sljedećoj slici vidimo kako izgledaju rezultati:

Slika br. 3.5. Primjer pravila 1

Zatim smo testirali pravilo za ICMP koje glasi:

alert icmp 192.168.1.36 any -> any any (msg: "Nadjen ICMP paket!";sid:1000002)

Ovo pravilo bilježi sve ICMP pakete koje šalje naše računalo. Time možemo otkriti npr. da li nas tko ping-a. To smo i testirali tako da smo pokrenuli Snort na jednom računalu i pokušali ga ping-ati s drugog računala u mreži. Snort je to detektirao i dobili smo sljedeće rezultate:

Slika br. 3.6. Primjer pravila 2

Isto kao za ICMP, testirali smo pravilo koje bilježi pakete, ali ovaj put HTTP pakete. Tako se mogu zabilježiti koji se sve paketi šalju i prema kojim adresama, što bi analitičarima moglo dobro doći. Pravilo glasi:

alert tcp 192.168.1.36 any -> any 80 (msg: "Nadjen HTTP paket!"; sid:3000005)

Ako pokrenemo neku stranicu dok Snort s ovim pravilom radi, dobit ćemo gomilu paketa kao što se vidi na sljedećoj slici:

Slika br. 3.7. Primjer pravila 3

Međutim, kad dobijemo previše podataka, uglavnom većina njih nije pretjerano korisna, stoga želimo sami odrediti na kakve pakete ćemo obraćati pažnju, odnosno kakve karakteristike paket mora imati. Iduće pravilo bilježi pakete koji sadrže određen sadržaj, konkretno u ovom slučaju adresu određene stranice. Tim načinom možemo kontrolirati korisnikovo posjećivanje određenim stranicama, tj. bilježiti njegove posjete u log i tako vidjeti kada su se stranice posjećivale s njegovog računala. Tako npr. šefovi mogu vidjeti ako su se njihovi zaposlenici pristupali nedozvoljenim Internet stranicama(npr. Facebook, Youtube i sl.) za vrijeme radnog vremena. Mi smo za probu uzeli FOI-evu stranicu. Pravilo glasi:

alert tcp 192.168.1.36 any <> any any (content: "http://www.foi.unizg.hr"; msg: "Zabiljezen pristup FOI stranici!"; sid:3000010)

U ovom pravilu koristimo novu opciju - content: "x", koja filtrira pakete na način da uzima u obzir samo pakete koji u sebi sadrže vrijednost x. Ispis rezultata izgleda ovako:

Slika br. 3.8. Primjer pravila 4

Ovdje vidimo sve pakete koji sadrže FOI-evu adresu, a više detalja možemo vidjeti u log datoteci.

Lea Jakoplić 21:58, 19. siječnja 2013. (CET)

Komponente Snort-a

Snort se sastoji od više komponenata koje međusobno surađuju s ciljem da otkriju napad u mreži. To su sljedeće komponente:

• Dekoder paketa
• Predprocesori
• Mehanizam otkrivanja
• Sustav stvaranja zapisa i obavijesti (logova i alertova)
• Izlazni moduli

Snort radi tako da, kad se preuzme paket iz mreže, proslijedi se dekoderu paketa gdje se obavlja obrada, tj. dešifriranje. Nakon obrade u dekoderu paketi ulaze u predprocesore, koji tada nad paketima podataka vrše zadaće potrebne prije dolaska do mehanizama za otkrivanje (sortiraju ih ili mijenjaju). Nakon toga paketi dolaze do najbitnijeg dijela Snort alata - mehanizma za otkrivanje. Pomoću njega se otkrivaju mogući maliciozni paketi. Tu u igru ulaze pravila, koja se nalaze u internoj strukturi podataka - uspoređuju se svojstva paketa (njihov tip, vrijednost itd.) sa postojećim pravilima i, ako dođe do poklapanja, nad tim paketima obavlja se radnja definirana u tom pravilu. Te radnje mogu biti zapisivanje paketa, stvaranje obavijesti ili obje radnje u isto vrijeme, ali i jednostavno odbacivanje paketa. Znači, ovisno o tome što mehanizam otkrivanja otkrije, iduća komponenta - sustav stvaranja zapisa i obavijesti - bilježi odgovarajuće zapise i stvara obavijesti. Izlazni moduli obavljaju odgovarajuće radnje ovisno o tome što želimo s izlaznim podacima sustava stvaranja zapisa i obavijesti - pohraniti ih u datoteku, bazu podataka, ispisati ih na ekran, poslati poruku i sl. Skica povezanosti komponenata Snorta nalaze se na sljedećoj slici:

Slika br. 3.9. Komponente Snorta

Lea Jakoplić 17:56, 20. siječnja 2013. (CET)

Instalacija Snort alata

Da biste koristili programski alat snort najprije ga je potrebno instalirati i podesiti. Dok za linux platformu postoji veliki broj tutoriala koji vas korak po korak vode kroz instalaciju, ako poželite isti alat postaviti na windows platformu puno će teže biti pronaći neki koji će pokazati sve što treba napraviti pa će to ovdje biti prikazano. Za početak potrebno je preuzeti winpcap biblioteku sa njihove stranice: http://www.winpcap.org/ i instalirati ju. Snort koristi dotičnu biblioteku za hvatanje paketa pa je ona nužan preduvjet za njegov rad. Nakon toga potrebno je preuzeti sam snort sa stranice: http://www.snort.org. Za instalaciju na windows sustav potrebna je izvršna datoteka: Snort_2_9_4_Installer.exe uz to potrebno je preuzeti i snort pravila(za preuzimanje pravila potrebna je registracija na snort stranici. Nakon preuzimanja datoteka snort je potrebno instalirati. Postupak je iznimno jednostavan i jedino je potrebno odabrati mapu u koju želimo instalirati alat. Nakon instalacije potrebno je ugraditi pravila u alat. Dobivena pravila kopiramo u mapu /rules dok dobivenu snort.conf datoteku kopiramo u /etc mapu u kojoj prepišemo postojeću. Ako je sve dobro obavljeno, snort bi trenutno morao biti funkcionalan. Ako navigiramo do mape u kojoj se nalazi i pokrenemo ga naredbom snort, alat bi trebao ispisati sve moguće opcije kao što je vidljivo na slici dolje:

Slika br. 3.10. Snort izbornik

Naravno, ovime snort još nije u potpunosti funkcionalan. Još uvijek nije moguće pokrenuti NIDS mod koji je nama najzanimljiviji. Da bismo to mogli, potrebno je izmijeniti snort.conf datoteku. Za početak otvorimo dotičnu datoteku u nekom text editor alatu i pronađemo HOME_NET varijablu. Ova varijabla označava adresu mreže u kojoj koristimo snort pa je prema tome i unesemo, na primjer:

var HOME_NET 192.168.1.0/24

Sljedeće što se mora izmjeniti je putanja do snort pravila. Potrebno je pronaći ove varijeble:

var RULE_PATH ../rules
var SO_RULE_PATH ../so_rules
var PREPROC_RULE_PATH ../preproc_rules

kao što se može vidjeti, putanje su definirane u linux formatu i na windows sustavu neće raditi. Umjesto njih potrebno je upisati putanje do stvarnih snort pravila na dotičnom računalu kao u ovom primjeru:

var RULE_PATH C:\Snort\rules\rules
var SO_RULE_PATH C:\Snort\rules\so_rules
var PREPROC_RULE_PATH C:\Snort\preproc_rules

Kada je to obavljeno, potrebno je izmijeniti putanje do white i black list pravila odnosno sljedeće varijable:

var WHITE_LIST_PATH ../rules
var BLACK_LIST_PATH ../rules

White list pravila ne dolaze u paketu sa snortom pa se ta linija može zakomentirati ako korisnik ne misli koristiti svoja, dok se za black list pravila mora izmijeniti putanja što izgleda ovako:

#var WHITE_LIST_PATH ../rules
var BLACK_LIST_PATH var RULE_PATH C:\Snort\rules\black_list_rules

Potrebno je još izmijeniti putanje do modula za predprocesiranje i do dinamičkih pravila:

# path to dynamic preprocessor libraries
dynamicpreprocessor directory /usr/local/lib/snort_dynamicpreprocessor/

# path to base preprocessor engine
dynamicengine /usr/local/lib/snort_dynamicengine/libsf_engine.so

# path to dynamic rules libraries
dynamicdetection directory /usr/local/lib/snort_dynamicrules

Na način da odgovaraju vašem računalu slijedeći dolje prikazan primjer:

# path to dynamic preprocessor libraries
dynamicpreprocessor directory C:\Snort\lib\snort_dynamicpreprocessor

# path to base preprocessor engine
dynamicengine C:\Snort\lib\snort_dynamicengine\libsf_engine.dll

# path to dynamic rules libraries
dynamicdetection directory C:\Snort\lib\snort_dynamicrules

Posebnu pažnju treba obratiti na libsf_engine koji za potrebe linux operacijskog sustava ima nastavak so,ali ga je za rad na windows platformi potrebno promijeniti u dll. Preporuka je i dodavanje apsolutne putanje do datoteka classification.config i reference.config odnosno izmjena ovog koda:

include classification.config
include reference.config

U nešto slično primjeru:

include C:\Snort\etc\classification.config
include C:\Snort\etc\reference.config

Za kraj potrebno je još dodati slijedeću liniju u kod:

output alert_fast:alerts.ids

Pri čemu je ime datoteke po želji korisnika. Nakon završetka postavljanja snort.conf datoteke potrebno ju je pohraniti i pokrenuti snort u NIDS načinu rada naredbom:

snort -c C:\Snort\etc\snort.conf  

U slučaju da je sve postavljeno ispravno dobit će se nakon podužeg učitavanja sljedeći ekran:

Inače će snort javiti grešku uključujući i liniju koda u kojoj je došlo do nje.

Noa Franjul 23:32, 20. siječnja 2013. (CET)

Načini rada Snorta

Za početak napomena, bez obzira na korišteni način rada, Snort će pri normalnim postavkama hvatati pakete da mrežnom sučelju broj 1. U slučaju da računalo ima veći broj sučelja i ne koristimo zadano, potrebno je odabrati sučelje koje želimo koristiti. Naredbom snort -W ispisat će se sva dostupna sučelja zajedno s njihovim brojevima.

Slika br. 3.11. Prikaz mrežnih sučelja

Željeno sučelje odabiremo naredmom -ix pri čemu je x broj sučelja koje želimo koristiti. Znači naredba za odabir sučelja 2 i pokretanja Snorta u Sniffer načinu radi bi izgledala ovako:

snort -i2 -v 

Redosljed naredba nije važan tako da će i sljedeća naredba biti ekvivalentna prethodnoj:

snort -v -i2 

Sniffer način rada

Sniffer je osnovni način rada Snorta. Pri pokretanju ovog načina rada Snort će čitati sve primljene pakete i Prikazivati podatke o njima na standardnom izlazu. Da bi se Snort pokrenuo u sniffer načinu rada potrebno je navigirati do mape u kojoj je snort instaliran i nakon toga ući u bin mapu gdje se nalazi izvršna datoteka programa. Sniffer mod se pokreće naredbom snort -v nakon čega će Snort nakon kratkog učitavanja početi hvatati pakete i ispisivati ih. Pokretanjem na ovaj način Snort će ispisivati samo osnovne informacije o primljenim paketima.

Slika br. 3.12. Sniffer mod

Da bi snort ispisao i detalje o primljenim paketima može se koristiti naredba -d, dok se opcijom -e mogu dobiti i zaglavlja aplikacijskog sloja

Slika br. 3.13. Prikaz detalja o paketima i aplikacijskog sloja

Snort će ovako pokrenut hvatati pakete dok ga korisnik ne prekine. Snort se prekida pritiskom Ctrl+c tipka nakon čega će snort ispisati statistiku o posljednjoj sesiji. To uključuje trajanje sesije, broj uhvaćenih paketa, broj analiziranih paketa, prosjek primljenih paketa po sekundi i raspored paketa po protokolima. Primjer jednog takvog ispisa se vidi na slici dolje.

Slika br. 3.14. Sniffer statistika

Iz svega navedenog može se vidjeti da sniffer način rada može biti koristan za brzi pregled korištenja mrežnog prometa na nekom računalu, ali da bi se primijetilo nedopuštene radnje korisnik mora stalno provjeravati ispis što baš i nije praktično. Da to ne bi bio slučaj koristi se sljedeći mod.

Packet logger način rada

Ovaj način rada je u biti isti kao i sniffer način rada, ali umjesto da podatke zapisuje na standardni izlaz on ih zapisuje u datoteku. To znači da sve naredbe koje su prethodno objašnjene u sniffer načinu rada funkcioniraju i ovdje. Nova naredba za ovaj mod je -l pomoću koje se definira mapa u koju ćemo pohraniti pakete. Primjer jedne takve naredbe bi bio ovakav:

snort -i2 -dve -l C:\Snort\log 

Pri definiranju putanje treba paziti da mapa koju želimo koristiti stvarno postoji, inače će nam Snort javiti grešku pri pokretanju. Mapa definirana u primjeru je defaultna mapa koja se koristi za Snort logove, naravno putanja će biti različita ovisno o tome gdje ste alat instalirali. Naravno moguće je koristiti bilo koju mapu u svrhu pohrane logova. Pri pokretanju packet logger moda, Snort će defaultno pohranjivati podatke u ascii obliku. To znači da će biti jasno čitljivi korisniku,ali je njihovo zapisivanje sporije. Pri velikoj količini mrežnog prometa preporuča se korištenje binarnog zapisa koristeći opciju -b. Pri tome nije potrebno definirati opcije hvatanja paketa kao u prošlom primjeru jer binarni način rada zapisuje sve detalje o paketima. znači dovoljna nam je sljedeća naredba:

snort -i2 -b -l C:\Snort\log 

Rezultat ovakve naredbe neće biti čitljiv korisniku,ali se dobivena datoteka može pročitati nekim alatom za analizu mrežnog prometa kao što je Wireshark, pomoću kojeg onda možemo dobiti pregled svih detalja o paketima. Još jedna zanimljiva opcija je i ponovna analiza pohranjenih paketa uz pomoć samog Snorta. Za to se koristi opcija -r i zadavanjem datoteke u koj smo pohranili pakete.

snort -i2 -dv -r C:\Snort\log\log.log 

Moguće je i filtriranje primljenih paketa u samom Snortu jednostavnim zadavanjem protokola ili porta koji paket mora sadržavati.

snort -i2 -dv -r C:\Snort\log\log.log tcp port 25 

Tako će gore navedeni primjer ispisati samo smtp poruke koje su uhvaćene. Packet logger način rada je idealan za analizu mrežnog prometa, može dati uvid u razne maliciozne kodove koji koriste mrežu, nedopuštene zahtjeve s određenog računala ili jednostavno pregled mrežnog prometa. Ali prava snaga Snorta i najčešći način korištenja je detekcija uljeza odnosno NIDS način rada.

NIDS način rada

NIDS odnosno Network intrusion detection system je način rada u kojem snort primljene pakete provjerava i uz pomoć definiranih pravila odlučuje da li da javi upozorenje ili jednostavno propusti paket. Da bi Snort uopće mogao raditi u ovom načinu rada potrebno je imati podešenu konfiguracijsku datoteku i definirana pravila. Konfiguracijska datoteka se u pravilu nalazi na putanji ../etc/snort.conf(odnosno ..\etc\snort.conf za win platformu) u odnosu na glavnu Snortovu mapu i potrebno ju je najprije podesiti kao što je opisano u poglavlju za podešavanje snorta. Nakon što je datoteka podešena NIDS način rada se pokreće naredbom -c "putanja do snort.conf datoteke" kao što je prikazano primjerom.

snort -i2 -A fast -c C:\Snort\etc\snort.conf -l C:\Snort\log\log.log  

Snort će nakon toga započeti poduže učitavanje pravila koje zna trajati i do 30 sekunda da bi nakon toga počeo hvatati pakete na zadanom sučelju i provjeravati ih. Ovisno o definiranim pravilima snort može s paketima postupati na različite načine pri čemu su najčešći: pass koji pakete koji zadovolje jednostavno propusti i ne zabilježi u log datoteci, log koji pohrani podatke o paketu u zadanoj log datoteci i alert koji osim što zapiše podatke u log datoteku stvara i poseban alert zapis u dodatnoj datoteci.

Slika br. 3.15. NIDS način rada

Snort pakete klasificira prema njihovim zaglavljima i u pravilu neće provjeravati njihov sadržaj. Najčešći uvjeti u pravilima koja snort koristi su adrese računala koja komuniciraju, port ili sadržaj paketa. Može se i stvoriti kompleksnija pravila koja provjeravaju više uvjeta. Osim načina rada fast koji je prikazan gore, snort podržava i druge opcije, fast način rada zapisuje samo podatke o izvoru i odredištu paketa, vremenu kad je poslan i vrsti poruke upozorenja, ako nam je potrebno više detalja možemo koristiti full opciju pri kojoj snort zapisuje i sadržaj paketa i njegovog zaglavlja. Unsock je još jedna zanimljiva opcija pomoću koje se može proslijediti dobivene podatke nekom drugom alatu za analizu što može biti poželjno s obzirom da snort za sada nema grafičko sučelje, a često nije praktično analizirati tekstualne datoteke nastale nakon nekoliko sati snimanja mrežnog prometa. NIDS način rada snorta je u biti iznimno fleksibilan alat za detekciju uljeza i kao takav je danas i jedan od najpopularnijih, za više detalja o raznim mogućnostima koje se mogu definirati uz pomoć snort pravila pročitajte poglavlje posvećeno njima.

Iptables način rada

Koristeći Snort na Linux operacijskim sustavima dobiva se mogućnost korištenja funkcionalnsti alata iptables u samom snortu. Time snort postaje IPS odnosno sustav za spriječavanje napada jer dobiva opciju odbacivanja paketa za koje je pretprocesiranjem odlučio da su nepoželjni. Da bi se uopće moglo koristiti iptables, snort je potrebno pokrenuti u inline načinu rada. To se postiže korištenjem snort_inline poziva umjesto snort koji se je koristio u prethodnim modovima. uz to potrebno je dodati opciju -Q koja služi za preusmjeravanje primanja paketa na iptables red čekanja. Sve se to radi da bi snort dobio dodatna pravila koja omogućuju ispuštanje paketa. to su drop koji ispušta paket, zapisuje podatke o njemu u datoteku i ne obavještava pošiljatelja o odbijanje, s drop koji radi isto ali ne zapisuje podatke u datoteku i reject koji obavještava pošiljateljja o odbijanju. primjer jednog takvog poziva snorta bi bio slijedeći:

snort_inline -QD -c /etc/drop.conf -l /log/snort_inline 

Može se primjetiti da se ne koristi uobičajena snort.conf već umjesto nje drop.conf datoteka koja je u biti modificirana snort.conf datoteka u koju su dodana pravila za odvacivanje paketa. Uz to u pravilu se koristi nova mapa za pohranu logova koja se u ovom primjeru nalazi unutar log mape. Ovaj mod je vrlo popularan na Linux platformi i postoji verzija snorta Honeynet Snort Inline Toolikt koj već u sebi sadrži dodatna pravila za rad sa iptables.

Noa Franjul 23:32, 20. siječnja 2013. (CET)

Programski alat Snorby

Čemu služi programski alat Snorby

Alat Snorb kao sam za sebe ne čini potpun IDS i ne može zabilježiti sve napade koji se dogode na neki sustav zbog mnogih rupa i propusta prilikom njegovog programiranja i pisanja pravila. Stoga je potrebno, za što potpuniji IDS, instalirati za početak sustav za upravljanje bazama podataka RDMBSkoji će poslužiti kao skladište za spremanje zapisa događaja na sustavu te grafičko sučelje za pregled i administraciju događaja. U tom slučaju Snort je moguće koristiti sa dva besplatna sustava baza podataka: MySQL i PostgreSQL. Snort može biti dobar kamen temeljac za nadogradnju i usavršavanje IDS-a, veliki razlog je taj što je rad s Snortom jedino moguć preko komandne linije, a u današnje vrijeme to izgleda pomalo zastarjelo i ne privlači toliku pažnju kao oni programski alati koji razrađeno grafičko sučelje. Kraće rečeno, u programskom alatu Snort ne postoji način da se događaji pregledavaju na sistematičan način. Također, postoji više besplatnih grafičkih sučelja za Snort - Aanval, Snorby, BASEi RazorBack. U nastavku teksta bit će opisana uporaba alata uz pomoć Snorby grafičkog sučelja. Nakon instalacije i pokretanja Snorby sučelja (objašnjenja navedena u idućem poglavlju), korisniku je omogućen:

• Sumarni prikaz događaja;
• Prikaz svih događaja uz mogućnost jednostavne klasifikacije (ručnog označavanja) svakog događaja te;
• Detaljan uvid u svaki pojedinačni događaj;
• Metrika i izvještaji gdje se mogu izrađivati planovi otklanjanja i prevencije budućih napada.

Snorby omogućuje praćenje više odvojenih instanci Snort alata istovremeno. Moguć je sumarni prikaz u raznim vremenskim intervalima po:

• Senzorima, tj. instancama alata,
• Ozbiljnosti prijetnje (visoka/srednja/niska),
• Protokolima (TCP/UPD/ICMP),
• Ishodišnim točkama mrežnog prometa,
• Odredištu (računalu s pokrenutom instancom alata).

Uz sumarni, omogućen je i pregled nekoliko posljednjih te ukupan broj događaja svake klase. Klasa događaja je vrsta napada koja se tim događajem (tj. mrežnom aktivnošću) pokušava ostvariti. Jedna od glavnih odlika Snorby alata jest što ima ugrađen mehanizam za potpuno hvatanje i analizu paketa (eng. Full Packet Capture) koristeći moćne i poznate alate OpenFPC i Solera DS Appliances. Na ovaj način dobiva se pregled cjelokupne analiza punog prijepisa mrežnog prometa te pregled kompletnog razgovora vezanog za napad za razliku od tipičnih IDS rješenja gdje se uglavnom vidi oko 300 bajta prometa. Snorby također pruža 20 različitih pravila korištenja tipki (eng. hotkeys) čime omogućuje bržu pretragu, pregled, clasifikaciju događaja bez upotrebe miša.

Slika br. 4.1. Snorby alat

--Zoran Kos 09:46, 20. siječnja 2013. (CET)

Arhitektura alata Snorby

Snorby predstavlja središnju/centralnu konzolu, odnosno stanicu. Sav mrežni promet koji je stigao preko mrežnog sučelja (mrežne kartice eth0, eth1) najprije ulazi u alate za detekciju napada (Snort, Suricata, Sagan) koji su mješteni u LAN-u. Oni generiraju logove i preko eth2 prosljeđuju ih Snorby-u koji se nalazi u demilitaliziranoj zoni (takva arihitektura prikazana je na slici br. 4.2). S obzirom da u našem projektu koristimo samo Snort, naša arhitektura bit će prilagođena prema idućoj slici br. 4.3.

Slika br. 4.2 Arhitektura IDS-a sa Snorbyem

Slika br. 4.3 Arhitektura Snorbya i Snorta za potrebe našeg projekta

--Zoran Kos 10:34, 20. siječnja 2013. (CET)

Postupak instalacije Snorbya i svih potrebnih komponenti

S obzirom da na internetu postoje mnogi totoriali, upute za instalaciju Snorbya, tome poslu treba pristupiti koncentrirano i pedantno. To je bitno za naglasiti jer s obzirom, kada govorimo samo o Linux operacijskom sustavu, postoje mnoge njegove inačice koje će se drugačije ponašati i zahtjevati točno definirane verzije prilikom instalacije svih potrebnih preduvjeta koji su potrebni kako bi Snorby mogao nesmetano raditi. Zbog tog razloga što se intaliraju verzije definirane po defaultu (koje mogu biti zastarjelog tipa) potrebno je provesti ručna ažuriranja kako bi Snorby mogao raditi.

1. Preduvjet - alat Snort

S obzirom da na internetu postoji bogat asortiman uputa za instalaciju ovog alata, kratko ćemo se osvrnuti na najbitnije dijelove. Procedura instalacije i stavljanja u rad za Windows korisnike je puno jednostavnija u odnosu za one koji koriste Linux. Za linux korisnike najbitnije je na početku instalirati:

• Biblioteke za hvatanje paketa:

sudo apt-get install libpcre3-dev 
sudo apt-get install libpcap0.8-dev

• Preuzeti i raspakirati Snort

 curl -L http://www.snort.org/dl/snort-current/snort-2.9.4.tar.gz -o snort-2.9.4.tar.gz 

• Instalirati Snort u sustav

 cd snort-2.9.4
# ./configure
# make
# make install

• Provjeriti verziju za svaki slučaj

 snort --version 

• Definirati potrebne direktorije

# mkdir /etc/snort
# mkdir /etc/snort/rules
# mkdir /var/log/snort

• Pravilno definirati puteve do pravila te file snort.conf
• Izvršiti pokretanje programa s

 snort -D -c /etc/snort/snort.conf -l /var/log/snort/ 

• VAŽNA NAPOMENA: za rad s Snortom potrebno je biti ulogiran kao root kako bi korisniku bila dodljenjena prava korištenja datoteka. $ su -. U suprotnom slučaju Snort će vračati slijedeću poruku:

 ERROR: Failed to lookup interface: no suitable device found. Please specify one with -i switch 

Za više informacija posjetite ovaj link za korisnike Linux OS-a, a ovaj link za korsnike Windows OS-a.

--Zoran Kos 14:01, 20. siječnja 2013. (CET)

2. Preduvjet - GIT

GIT je open source programsko rješenje za praćenje promjena u tekstualnim i drugim datotekama koje se mogu tretirati kao tekstualne. Komunikacija s GIT poslužiteljem moguća je putem HTTP, HTTPS, rsync ili SSH protokola. Također, da bi se povećala baza klijenata, omogućen je pristup i klijentima koji za komunikaciju koriste SVN (git-svn). Za više informacija pogledajte službene stranice.

• Postupak instalacije GIT-a naveden je u nastavku.

$ yum install curl-devel expat-devel gettext-devel \
 openssl-devel zlib-devel
$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
 libz-dev libssl-dev
$ sudo http://git-scm.com/download
$ tar -zxf git-1.7.2.2.tar.gz
$ cd git-1.7.2.2
$ make prefix=/usr/local all
$ sudo make prefix=/usr/local install

--Zoran Kos 14:48, 20. siječnja 2013. (CET)

3. Preduvjet - Ruby 1.9.2

Ruby je višeplatformski jezik opće namjene i otvorenog koda. Ruby je daleko najviše populariziran 2005.-e dolaskom Ruby on Rails frameworka za web aplikacije. Zbog toga što se u nekim zajednicama Ruby koristi gotovo isključivo za Rails programiranje, ponekad je lako protumačiti da su ta dva pojma sinonimi. To nije točno; treba razumijeti da je "Ruby on Rails" samo programska podrška napisana u Ruby programskom jeziku. Sadrži veliki broj gotovih plugina - ruby gems, za sve namjene koje je moguće zamisliti. RubyGems je standardni Ruby package manager. Za više informacija pogledajte materijale koji se nalaze na službenoj stranici ruby-lang.org , ali i cijeli pregled Ruby Gems-a na stranicama rubygems.

• Postupak skidanja i instalacije Ruby (1.9.2):

# cd /usr/local/src/
# wget http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p180.tar.gz
# tar xvzf ruby-1.9.2-p180.tar.gz
# cd ruby-1.9.2-p180/
# ./configure
# make
# make install

--Zoran Kos 14:48, 20. siječnja 2013. (CET)

4. Preduvjet - Ruby on Rails

Predstavlja novi način razvoja web aplikacija. Primarni mu je cilj automatsko generiranje potpune web aplikacije na temelju sheme relacijske baze podataka pa je dobra preporuka da se uz Rails koriste Apache i MySQL. Ukratko Rails je framework za Ruby. Za više informacija posjetite službenu stranicu rubyonrails.

• Postupak skidanja i instalacije Ruby on Rails

# gem install thor i18n bundler tzinfo builder memcache-client \
  rack rack-test erubis mail text-format sqlite3
# gem install rack-mount --version=0.4.0
# gem install rails
# gem install rake

--Zoran Kos 14:48, 20. siječnja 2013. (CET)

5. Preduvjet - Instalacija MySQL servera

Za potrebe ovog projetka potrebno je instalirati mysql server na lokalnom računalu kako bi bila mogaća komunikacija između baze podataka i ruby on rails-a. Kada je instalacija završena, MySQL server će početi automatski raditi. Prva linija označuje instaliju i pokretanje MySQL servera, a druga linija provjerava da li taj server radi.

sudo apt-get install mysql-server
sudo netstat -tap | grep mysql

--Zoran Kos 15:49, 20. siječnja 2013. (CET)

6. Preduvjet - Instalacija Open JDK Java 7 Runtime

--Zoran Kos 15:49, 20. siječnja 2013. (CET)

7. Preduvjet - Instalacija Barnyard2

Barnyard2 je open source interpreter koji prosljeđuje Snortu parsirane binarne podatke različitih formata odvojenih procesa. Time se sprečava da Snort napravi promašaje prilikom analize podatkovnog prometa.

• Postupak instalacije

$ cd /data/src/
$ wget http://www.securixlive.com/download/barnyard2/barnyard2-1.9.tar.gz
$ tar xzvf barnyard2-1.9.tar.gz
$ cd barnyard2-1.9/
$ ./configure --with-mysql
$ make
# make install
# mv /usr/local/etc/barnyard2.conf /usr/local/etc/snort/

--Zoran Kos 17:25, 20. siječnja 2013. (CET)

Konfiguracija senzora

Snorby generira događaje iz senzora. Na lokalnom serveru, mora se configurirati Baryard tako da zapisuje događaje iz Snorta u Snorbijevu bazu podataka. U datoteku barnyard2.conf mora se dodati put do Snorby-eve baze podataka.

output database: alert, mysql, user=<snorbyuser> password=<snorbypasswd> dbname=snorby host=localhost 

--Zoran Kos 17:25, 20. siječnja 2013. (CET)

Početak rada Snorby-a

Kako je na službenoj stranici opisan postupak instalacije ovdje on neće biti posebno opisan. Nakon što je Snorby instaliran potrebno je istalirati takozvani Passenger koji omogućuje pristup aplikaciji preko Apache2 kojem glavna svrha, da tako nazovemo, da glumi server i zadužen je za rad s dinamičnim stranicama. Glavna uloga servera je da mu pošaljemo određeni podatak (npr. otvori nam stranicu sa tom i tom adresom), a on potraži mjesto na našem računalu gdje se ta stranica nalazi i vrati nam podatke koje je isprogramirana stranica procesuirala. Snorby pokrečemo u komadnoj liniji naredbom:

 rails server -e production 

Nakon čega otvaramo preglednik i u pretražnik upisujemo http://<server>:3000/users/login koji nas proslijeđuje na stranicu za login. Primjer stranice prikazan je na slijedećoj slici br. 4.4.

• Podaci za login su:

login: snorby@snorby.org

password: snorby

Slika br. 4.1. Prijava u web aplikaciju Snorby

Nakon toga potrebno je instalirati Phusion Passenger koji pojednostavljuje instalaciju Ruby on Rails s Apache2 i Nginx. Prikaz instalacije je prikazan u idućem ojeljku s nekoliko izvršnih linija koda:

# apt-get install apache2-prefork-dev libcurl4-openssl-dev
# gem install passenger
# passenger-install-apache2-module

# vim /etc/apache2/apache2.conf
  U datoteku je potrebno nadopasati slijedeći kod:
  LoadModule passenger_module /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.7/ext/apache2/mod_passenger.so
  PassengerRoot /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.7
  PassengerRuby /usr/local/bin/ruby

# vim /etc/apache2/sites-available/default
  U datoteci je potrebno napraviti određene izmjene
  <VirtualHost *:80>
  ServerName aldeid.local
  DocumentRoot /var/www/snorby/public
  <Directory /var/www/snorby/public>
    Options -MultiViews


    AllowOverride all
  </Directory>
  ...
  </VirtualHost>

Na kraju svega potrebno je ponovno pokrenuti Apache naredbom
# /etc/init.d/apache2 restart

U glavnom izborniku potrebno je provjeriti jesu li senzori dobro instalirani. Ako jesu instalirani moguće je pokrenuti workera i job queue koji će bilježiti promet i zapisivati eventualne napade ili pogreške pri radu. Na kraju je potrebno kofigurirati OpenFPC koji je odgovoran za hvatanje paketa.

Slika br. 4.5 Postavke za Snorby-admin.png

Slika br. 4.6 Snorby-worker i job queue

--Zoran Kos 18:53, 20. siječnja 2013. (CET)

Literatura

CIS, Snort IDS, http://www.cis.hr/files/dokumenti/CIS-DOC-2011-10-028.

CIS, Poboljšanje performanski NIDS-a za velike brzine, http://www.cis.hr/www.edicija/LinkedDocuments/CCERT-PUBDOC-2002-04-02.pdf

CERT, OSSec HIDS, http://www.cis.hr/www.edicija/LinkedDocuments/CCERT-PUBDOC-2008-03-222.pdf

CERT, Detekcija neovlaštenih upada, http://www.cis.hr/www.edicija/LinkedDocuments/CCERT-PUBDOC-2000-09-04.pdf

Požgaj, I., Raspodjeljeni sustav za spriječavanje mrežnih napada, http://www.zemris.fer.hr/~sgros/publications/diploma_thesis/pozgaj_igor_diplomski.pdf

Rehman, R., Intrusion Detection Systems with Snort http://ptgmedia.pearsoncmg.com/imprint_downloads/informit/perens/0131407333.pdf

http://www.aldeid.com/wiki/Barnyard2

http://www.aldeid.com/wiki/EN:Snort/Installation#Installation_of_Snort

http://www.aldeid.com/wiki/Snorby

https://github.com/Snorby/snorby

https://www.phusionpassenger.com/

https://rvm.io/rvm/install/

https://github.com/Snorby/snorby/wiki/Ubuntu-1.9.2-without-RVM-by-Eric-Peters

http://stackoverflow.com/questions/3464098/rails-3-no-such-file-to-load-openssl

http://ubuntuforums.org/showthread.php?t=804021

http://sistemac.srce.unizg.hr/index.php?id=35&tx_ttnews[tt_news]=741&tx_ttnews[backPid]=23&cHash=59f4861232

http://s3.amazonaws.com/snort-org/www/assets/166/snort_manual.pdf

http://www.snort.org/snort/faq/

http://www.pearsonhighered.com/samplechapter/0131407333.pdf