ModSecurity

Izvor: SIS Wiki
Skoči na: orijentacija, traži

Zvonimir Kapeš, Igor Rauš, Nikola Pintarić

Sadržaj

Uvod

ModSecurity je firewall za web aplikacije (Web application firewall - WAF). [1] To je open source alat za otkrivanje i prevenciju upada namjenjen za we aplikacije. Funkcionira ugrađen u web server, i ponaša se kao kišobran - štiteći aplikacije od napada.

Autor ModSecuritya je Ivan Ristić. Prva verzija ModSecurityja je izdana 2002. godine. ModSecurity je stvoren zbog rastuće potrebe za sigurnošću web aplikacija koje su podložne velikom broju napada. ModSecurity omogućuje pregled web prometa - vidljivost HTTP prometa je ključ sigurnosti web aplikacije: promet se može analizirati u realnom vremenu, zabilježiti i reagirati na nepoželjne događaje. Vrlo je praktično što ModSecurity omogućuje sve to potpuno odvojeno od aplikacije, bez da se upliće u njezin rad.

ModSecurity je alat za monitoriranje, bilježenje i kontrolu pristupa web aplikacija u stvarnom vremenu. Ne postoje određena čvrsta pravila koja govore što morate učiniti da bi ModSecurity radio, već se može birati vlastiti put kroz mogućnosti koje su na raspolaganju. Sloboda izbora je bitan dio ModSecurity identiteta. Uz puni pristup izvornom kodu (open source), sloboda biranja proteže se na prilagodbu i proširivanje alata tako da odgovara potrebama svakog korisnika.

--Nipintaric 19:06, 20. siječnja 2013. (CET)


Principi rada i mogućnosti

Rad ModSecurity alata bazira se na principima kao što su fleksibilnost, pasivnost i predvidljivost, kako bi osigurao najbolji način zaštite. ModSecurity fleksibilnost postiže tako da pruža moćni jezik pravila, koji vam omogućuje da radite točno što trebate, u kombinaciji sa mogučnošću primjene pravila samo tamo gdje trebate. Na taj način se zapravo osigurava i princip pasivnosti. Koliko god informacija ModSecurity pružio, on nikad ne ostvaruje interakciju sa transakcijom osim ako mu nije tako naređeno, tj. primjenjuje pravila tamo gdje trebate. Predvidljivost zapravo nije princip na koji radi, međutim kako nije moguće napraviti savršeni alat ModSecurity pokušava sve svoje nedostatke nadomjestiti pružanjem velike količine informacija. Upravo ta mogućnost pružanja informacija omogućava vama da "predvidite" njegove propuste te ih zaobiđete.

Načini implementacije

ModSecurity podržava dva načina implementacije: ugrađene i implementaciju obrnutog proxy-a. I jedan i drugi način imaju svoje prednosti i nedostatke, te je najbolje odlučiti za implementaciju koja više paše određenim potrebama.

Ugrađena implementacija

S obzirom da je ModSecurity Apache modul, moguće ga je dodati u bilo koju kompatibilnu verziju Apache-a. Ugrađena implementacija je odličan izbor za one koji imaju svoju arhitekturu postavljenu i ne žele je mijenjati. Ova opcija je također i jedina opcija ako treba zaštiti stotine web poslužitelja. U takvim situacijama, nije praktično graditi odvijen proxy baziran sloj zaštite. Ugrađeni ModSecurity ne samo da ne uvodi nove točke kvarova, nego se i skalira neprimjetno sa skaliranjem postojeće web infrastrukture. Glavni izazov sa ugrađenom implementacijom je to što su resursi psolužitelja podjeljeni između web poslužitelja i ModSecurity-a.

Implementacija obrnutog proxy-a

Obrnuti proxy-i su HTTP usmjerivači, dizajnirani da se nalaze među web poslužiteljima i njihovim klijentima. Kada instalirate posvećen Apache obrnuti proxy i dodate mu ModSecurity, dobivate "propisni" mrežni web aplikacijski vatrozid, koji možete koristiti za zaštitu bilo kojeg broja web poslužitelja na istoj mreži. Mnogi sigurnosni praktičari preferiraju imati odvojeni sigurnosni sloj. Sa njim dobijete kompletnu izolaciju od sustava kojeg štitite. Što se tiče performansi, samostalan ModSecurity će imati resurce posvećene njemu, što znači da će moći činiti više (npr. imati više kompleksnih pravila). Glavni nedostatak ovog pristupa je nova točka kvara, s kojom se treba pozabaviti sa višedostupnim postavama dva ili više obrnutih proxy-a.

Apache-reverse-proxy-modsecurity.png

Područja funkcionalnosti

Parsiranje - ModSecurity pokušava stvoriti smisao u podacima koliko je god to moguće. Podržani formati podatka su potpomognuti sigurnosno-svjesnim parserima koji izvlače dijelove podataka i pohranjuju ih za korištenje u pravilima.

Bufferiranje - U tipičnoj instalaciji, tijela zahtjeva i odgovara će biti bufferirana. To znači da ModSecurity obično vidi kompletne zahtjeve prije nego što su prosljeđeni aplikaciji na procesiranje, i kompletne odgovore prije nego što su poslani klijentima. Bufferiranje je važna mogućnost zato što je to jedini način da se pruži pouzdana zaštita. Negativna strana ove sposobnosti je to što zahtjeva dodatni RAM za pohranjivanje tijela zahtjeva i odgovora.

Vođenje logova - Potpuno transakcijsko logiranje je velik dio onoga što ModSecurity radi. Ova mogućnost omogućava da se bilježi kompletni HTTP promet umjesto samo osnovnih pristupnih log informacija. Zaglavlja zahtjeva, tijelo zahtjeva, zaglavlje odgovora, tijelo odgovora i mnoge druge informacije su dostupne pomoću ove funkcije.

Rule engine - radi na temelju posla izvedenog od svih drugih komponenti. Do trenutka kada rule engine počne raditi, razni bitovi podataka koje zahtjeva će več biti pripremljeni i spremni za inspekciju. U tom trenutku če pravila preuzeti ulogu kako bi procjenile transakcije i poduzele potrebne akcije.

--Igraus 13:09, 24. siječnja 2013. (CET)

Faze obrade

ModSecurity verzija 2.0 i nadalje omogućuje smještanje pravila u jednu od pet faza Apache request ciklusa:

Na slici ispod je prikazan Apache ciklus zahtjeva i prikazane su ModSecurity faze obrade.

ProcessingPhases.jpg

Za odabir faze koju izvodi pravilo koristi se akcija izravno u pravilu ili korištenjem SecDefaultAction direktive: 

SecDefaultAction "log,pass,phase:2,id:4"	 
 SecRule REQUEST_HEADERS:Host "!^$" "deny,phase:1,id:5"

Faza Request Headers (zaglavlje zahtjeva)

Pravila u ovoj fazi se obrađuju nepostredno nakon što Apache završi čitanje zaglavlja zahtjeva. U tom trenutku tijelo zahtjeva još nije pročitano, te svi argumenti zahtjeva još nisu dostupni. Pravila bi se trebala smjestiti u ovu fazu ako ih je potrebno izvršiti što prije (prije nego Apache učini nešto za zahjevom), za izvršavanje nečega prije nego li je tijelo zahtjeva pročitano ili odlučiti način obrade tijela zahtjeva (hoće li biti parsiran kao XML ili ne).

Faza Request Body (tijelo zahtjeva)

Ovo je faza za generalnu analizu ulaznih podataka. Većina aplikacijski orijentiranih pravila smješta se u ovu fazu. U ovoj fazi primljeni su argumenti zahtjeva (ako je pročitano tijelo zahtjeva). ModSecurity omogućava tri tipa kodiranja za ovu fazu:

Za pristup podacima iz ove faze potrebno je postaviti SecRequestBodyAccess na On.

Faza Response Headers (zaglavlja odgovora)

Ova faza počinje neposredno prije slanja zaglavlja odgovora natrag do klijenta. Pravila se pokreću ovdje ako se želi promatrati odgovor prije negoli se dogodi. Neki kodovi odgovora (npr. 404) se obrađuju ranije od strane Apachea i neće se pokrenuti kako bi bilo za očekivati.

Faza Response Body (tijelo odgovora)

Ovo je faza za generalnu analizu izlaznih podataka. U ovoj fazi mogu se pokrenuti pravila za tijelo odgovora. U ovoj fazi se provjerava odlazni HTML za otkrivanje podataka, provjeru poruka o greškama ili autentičnost teksta. Za pristup podacima iz ove faze potrebno je postaviti SecResponseBodyAccess na On.

Faza Logging (bilježenje)

Ova faza se pokreće neposredno prije bilježenja različitih događaja. Pravila stavljena u ovu fazu određuju samo kako se bilježenje odvija. Ova faza se može koristiti za pregled poruka o greškama koje bilježi Apache. U ovoj fazi ne može se blokirati veza jer je za to prekasno. Ova faza omogućuje i pregled ostalih zaglavlja odgovora koje nisu bile dostupne tijekom faze 3 i faze 4. Ova faza je posebna jer se izvršavan na kraju svake transakcije bez obzira na to što se dogodilo u prethodnim fazama. Izvršit će se čak i ako je zahtjev presreten ili ako je akcija dozvole korištena za propuštanje transakcije.

--Nipintaric 17:07, 20. siječnja 2013. (CET)

Pravila

U ModSecurityu sve se vrti oko dvije stvari: konfiguracije i pravila. Konfiguracija govori ModSecurityju kako obrađivati podatke koje vidi, dok pravila odlučuju što raditi s obrađenim podacima. Primjer pravila: 

 SecRule ARGS "<script>" log,deny,status:404

U ovom pravilu pretražuju se ulazni podaci (<script>) i ako se nađe određeni uzorak dogodit će se log,deny,status:404 (biti će detaljnije objašnjeno u nastavku).

Sintaksa pravila izgleda ovako [Ristić, 2012, str. 11]: SecRule VARIJABLE OPERATOR AKCIJE Ta tri dijela imaju sljedeća značenja:

1. VARIJABLE - govore ModSecurityju gdje da gleda. ARGS varijabla u gore navedenom primjeru znači da se gledaju svi parametri zahtjeva.

2. OPERATOR dio govori ModSecurityju kako da gleda. U primjeru naveden je regularan izraz koji će se usporediti s ARGS.

3. AKCIJE - ovaj dio govori ModSecurityju što da radi ako pronađe ono što traži. U primjeru su dane tri instrukcije: zabilježi problem, odbij transakciju i koristi status 404 za odbijanje.

Ovo je vrlo jednostavno pravilo, a pravila mogu biti mnogo kompliciranija i pružaju velike mogućnosti i slobodu u uporabi. Popis svih varijabli, operatora i akcija može se pronaći ovdje.

--Nipintaric 19:43, 20. siječnja 2013. (CET)

Akcije

Sve akcije omogućene u ModSecurity alatu spadaju u jednu od sljedećih skupina:

1. Prekidne akcije - Prouzročuju da ModSecurity nešto učini. U mnogo slučajeva to znači blokirati transakciju, međutim ne uvijek. Npr. Allow akcija je klasificirana kao prekdina akcija, a ona čini suportno od blokiranja. U svakom pravilu ili lancu pravila može postojati samo jedna prekidna akcija. U slučaju da postoji više prekidnih akcija u pravilu, samo zadnja će vrijediti. U lancu, prekidna akcija se može pojaviti samo u prvom pravilu. Potrebno je napomenuti da ovavka vrsta akcija neće biti izvršena ako je SecRuleEngine postavljen na DetectionOnly, tj. potrebno je postaviti SecRuleEngine=On.

2. Ne prekidne akcije – čini nešto, ali to nešto ne utjeće na tok procesiranja pravila, kao što je npr. Postavljanje varijavle ili promjena njene vrijednosti. Ne prekidna akcija se može pojaviti u bilo kojem pravilu , uključujući svako pravilo uključeno u lanac.

3. Akcije toka – Ove akcije utječu na tok pravila

4. Akcije meta podataka – Ove akcije se koriste za pružanje više informacija o pravilima

5. Podatkovne akcije – Ova skupina nisu zapravo akcije, već samo kontejneri koji sadržavaju podatke korištene od strane drugih akcija. Tako npr. status akcija sadrži status koji će biti korišten za blokiranje.

--Igraus 13:10, 24. siječnja 2013. (CET)

Instalacija

Instalacijski koraci:

Build se razlikuje kod UNIX OS-a i Windowsa.

LINUX

ModSecurity se može instalirati na klasičan način putem izvršne datoteke, a budući da je open source, moguće ga je i kompilirati iz koda. Prednost instalacije preko izvršne datoteke je jednostavnost, a nedostatak je mogućnost da nije dostupna posljednja verzija. Postoji i razvojna verzija dostupna preko svn-a, no kako nije službena, moguće su neke nestabilnosti i bugovi. U nastavku će biti opisan postupak instalacije putem izvršne datoteke za Apache server na Linux Ubuntu operacijskom sustavu.

Kako bi se ModSecurity mogao instalirati, potrebno je prvotno zadovoljiti neke preduvjete, te instalirati potrebne biblioteke ukoliko ih već nema.

  1. ModSecurity radi s Apache serverom verzije 2.0 ili više. Apache se može instalirati sljedećim naredbama: 
    sudo apt-get install apache2
    Uz Apache odmah instaliramo i php5: 
    sudo apt-get install php5
    Na poslijetku restartamo: 
    sudo /etc/init.d/apache2 restart
  2. Ukoliko već nije, potrebno je uključiti mod_unique_id sljedećom naredbom 
    sudo ln -s /etc/apache2/mods-available/unique_id.load /etc/apache2/mods-enabled
  3. Potrebno je instalirati libxml2 i libpcre 
    sudo apt-get install libxml2 libxml2-dev libxml2-utils
    sudo apt-get install libaprutil1 libaprutil1-dev
    Za 64 bitni Ubuntu, potrebno je izvršiti i sljedeću liniju: 
    sudo ln -s /usr/lib/x86_64-linux-gnu/libxml2.so.2 /usr/lib/libxml2.so.2
  4. Ukoliko ćemo koristiti skriptni jezik Lua, kojim je moguće dodatno obogatiti osnovne funkcionalnostii ModSecuritya, potrebno je instalirati i lua biblioteku. Upute za preuzimanje i instalaciju mogu se pronaći na stranici lua.org/download.
    Sada su ispunjeni svi preduvjeti potrebni za instalaciju ModSecuritya, pa se u sljedećem koraku može instalirati i sam ModSecurity.
  5. ModSecurity instaliramo sljedećom naredbom: 
    sudo apt-get ins--~~~~tall libapache-mod-security

ModSecurity je sada instaliran, no potrebno ga je konfigurirati kako bi radio ono što mi želimo.

--Zvkapes 19:56, 20. siječnja 2013. (CET)

Windows

Podesite Makefile.win da konfigurira Apache bazu i biblioteke. Potrebno je kompajlirati s naredbom: nmake -f Makefile.win. Zatim je potrebno instalirati ModSecurity modul s: nmake -f Makefile.win install. Nakon toga potrebno je kopirati libxml2.dll i lua5.1.dll u Apache bin direktorij.

Drugi način je korištenje LoadFile za učitavanje tih biblioteka:

Podešavanje glavne Apache httpd config datoteke vrši se naredbama: 

 LoadFile /usr/lib/libxml2.so 
 LoadFile /usr/lib/liblua5.1.so

Učitavanje ModSecurity modula: 

 LoadModule security2_module modules/mod_security2.so

--Nipintaric 21:09, 20. siječnja 2013. (CET)

Konfiguracija

ModSecurity je prvotno podešen tako da ne radi ništa. Ne bilježi nikakve događaje niti sprečava napade na aplikacije. Tako je podešen iz više razloga [Ristić, 2012, str. 57]:

  1. Na taj se način osigurava da ModSecurity radi samo ono što mi želimo da radi. Dakle, mi kontroliramo što i kako će raditi, pritom razmišljajući o svakoj kontroli koju dodamo u konfiguraciju
  2. Nije moguće podesiti početnu konfiguraciju da radi jednako dobro u svim uvjetima. Postoje određene smjernice i dobra praksa, no detalji konfiguracije ovise o specifičnim uvjetima rada i samoj aplikaciji.
  3. Sigurnost se plaća povećanim korištenjem računalnih resursa, procesora i radne memorije, a također postoji i mogućnost blokiranja inače prihvatljivih zahtjeva. Zbog toga je važno dobro poznavati konfiguraciju i znati što se radi kako bi se izbjegle takve situacije.

Konfiguracijska datoteka koja povezuje Apache s ModSecurityem je mod-security.conf, a nalazi se u /etc/apache2/mods-available kod Debian/Ubuntu operacijskih sustava. Sadržaj te datoteke izgleda ovako: 

<IfModule security2_module>
	SecDataDir /var/cache/modsecurity
	Include "/etc/modsecurity/*.conf"
</IfModule>

Unutar IfModule tagova dodaju se konfiguracijske datoteke za ModSecurity. Te datoteke sadrže razne direktive, među kojima su i pravila vatrozida. Na početku je postavljen put do modsecurity direktorija i uključene su sve .conf datoteke iz njega, no u samom tom folderu nakon čiste instalacije takvih datoteka nema. Dostupna je samo "preporučena" konfiguracija u datoteci modsecurity.conf-recomended koju treba preimenovati kako bi se aktivirala. To možemo učiniti sljedećom naredbom: 

sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Konfiguracijskih direktiva ModSecuritya ima poveći broj, preko 50. Detaljnije o svakoj direktivi zasebno može se pronaći u službenoj dokumentaciji. Ovdje ćemo navesti samo neke važnije koje se koriste i kod preporučene konfiguracije. Podijeljene su na više cjelina:

Inicijalizacija pogona

Globalna sklopka za uključivanje/isključivanje ModSecuritya. Direktiva koja ovo omogućuje jest SecRuleEngine, a može poprimiti tri različite vrijednosti:

Upravljanje tijelom zahtjeva

Zahtjevi se sastoje od dva dijela - zaglavlja i tijela. Kako su tijela opcionalni dio, njih možemo, a i ne moramo uključiti u kontrolu ModSecurity-a. ModSecurity može obaviti inspekciju podataka iz tijela, te nakon toga odlučiti hoće li dopustiti ili odbaciti zahtjev. No, kako bi se podaci provjerili potrebno ih je lokalno pohraniti. Direktive iz ovog dijela definiraju opcije kao što su pristup tijelu (SecRequestBodyAccess), dopuštena veličina tijela prihvatljiva za buffering(SecRequestBodyLimit, SecRequestBodyNoFilesLimit), te što s onima koji prelaze definiranu veličinu(SecRequestBodyLimitAction). Podaci tijela zahtjeva koji odgovaraju definiranom ograničenju buffera, bit će pohranjeni u radnu memoriju, dok će se oni veći pohranjivati na tvrdi disk. Zbog toga treba biti oprezan kod korištenja ovih direktiva jer povećavaju korištenje radne momorije i produljuju vrijeme odgovora.

Upravljanjem tijelom odgovora

Kao i kod zahtjeva, na jednak način možemo provjeravati i tijela odgovora koji odlaze s našeg servera. Na taj način možemo spriječiti curenje podataka. Direktiva kojom uključujemo ovu mogućnost jest SecResponseBodyAccess. Kako ova opcija također povećava korištenje radne memorije, često se isključuje, osobito zbog toga jer je većina podataka koji se šalju sa servera uglavnom u statičkom obliku, npr. html ili css datoteke, a takve stvari nam nisu od značaja za sigurnost. Kako bi se donekle kontrolirali podaci koje će ModSecurity filtrirati, postoji direktiva SecResponseBodyMimeType. Tom direktivom određujemo MIME tipove datoteka koje su nam od interesa, a izbjegavamo nepotrebno korištenje resursa za manje važne podatke. Kao i kod tijela zahtjeva, postoje direktive za upravljanje veličinom buffera i slučajem kada datoteka prijeđe zadanu veličinu.

Postavke datotečnog sustava

U ovoj cjelini direktiva upravlja se sa raznim direktorijima koje ModSecurity koristi prilikom rada. Naime, direktorije postavljamo sami kako želimo, a u ovom djelu ih povezujemo s aplikacijom. To su direktive za:

Logiranje

Skup direktiva za definiranje direktorija pohranjivanja debug loga (SecDebugLog), te određivanje razine logiranja (SecDebugLogLevel). SecDebugLogLevel direktiva ima raspon od 0 (bez logiranja) do 9 (logiraj sve). Preporučena produkcijska razina je 3. Osim debug loga, postoje i razne direktive za upravljanje audit logom. To su SecAuditEngine(On|Off|RelevantOnly) kojim se uključuje|isključuje log, SecAuditLogRelevantStatus kojim se uz pomoć regularnih izraza definira koje će se transakcije logirati s obzirom na njihov HTTP Response Status Code, SecAuditLogParts za definiranje dijelova transakcija koji će se logirati, SecAuditLogType kojim se definira da će se sve bilježiti u jednu datoteku (Serial) ili svaka transakcija u posebnu datoteku (Concurrent), SecAuditLog za definiranje direktorija pohranjivanja serijskih zapisa, te SecAuditLogStorageDir za pohranjivanje concurrent log datoteka.

Ostalo

U ovoj cjelini postoje dvije direktive - SecArgumentSeparator kojom se definira kojim znakom su razdvojeni argumenti i SetCookieFormat za definiranje verzije cookiea.


Tabela osnovnih direktiva:

Cjelina Direktiva Opis Vrijednost
Inicijalizacija pogona SecRuleEngine Globalna sklopka za uključivanje/isključivanje ModSecuritya. On: Procesuiraj pravila
Off: Ne procesuiraj pravila
Detection only: Samo bilježenje u log, bez prekidanja.
Upravljanje tijelom zahtjeva SecRequestBodyAccess Pristup tijelu zahtjeva. On|Off
SecRequestBodyLimit Dopuštena veličina tijela prihvatljiva za buffering. broj u bajtovima
SecRequestBodyNoFilesLimit Dopuštena veličina tijela prihvatljiva za buffering, isključujući datoteke koje se prenose u zahtjevu. broj u bajtovima
SecRequestBodyInMemoryLimit Dopuštena veličina na disku. broj u bajtovima
SecRequestBodyLimitAction Akcije koje se poduzimaju ukoliko je ograničenje veličine prekoračeno. Reject, ProcessPartial
Upravljanje tijelom odgovora SecResponseBodyAccess Pristup tijelu odgovora. On|Off
SecResponseBodyMimeType Tipovi datoteka koji će se uzeti u obzir za inspekciju. MIME format (npr. text/html, text/xml)
SecResponseBodyLimit Dopuštena veličina tijela prihvatljiva za buffering. broj u bajtovima
SecResponseBodyLimitAction Akcije koje se poduzimaju ukoliko je ograničenje veličine prekoračeno. Reject|ProcessPartial
Postavke datotečnog sustava SecTmpDir Direktorij za privremene podatke. /put/do/direktorija
SecDataDir Direktorij za trajne podatke. /put/do/direktorija
SecUploadKeepFiles Kontrola zadržavanja datoteka. On|Off|RelevantOnly
SecUploadDir Direktorij za pohranjivanje presretenih datoteka. /put/do/direktorija
SecUploadFileMode Dopuštenja pristupa datotekama. octal_mode(npr. 0640)|"default"
Logiranje SecDebugLog Put do ModSecurity debug loga. /put/do/modsec-debug.log
SecDebugLogLevel Razina logiranja. 0|1|2|3|4|5|6|7|8|9
0: bez logiranja
1: samo greške
2: upozorenja
3: napomene
4: detalji o transakcijama
5: kao i gornje, ali uključujući i informacije o svakom dijelu informacije kojim se barata
9: logiranje svega
SecAuditEngine Uključivanje/isključivanje audit loga. On: logiranje svih transakcija
Off: bez logiranja
RelevantOnly: logiranje samo transakcija koje uzrokuju upozorenje ili grešku, prema tome kako je definirano sa SecAuditLogRelevantStatus
SecAuditLogRelevantStatus Utvrđivanje standardnih kodova odgovora (npr. 404, 405, 504 i sl.) relevantnih za logiranje. 4(?!04))")
SecAuditLogParts Dijelovi transakcije koji će se bilježiti u audit logu. A|B|C|D|E|F|G|H|I|J|K|Z
SecAuditLogType Način bilježenja laudit loga. Serial: sve se logira u jednu datoteku.
Concurrent: posebna log datoteka za svaku transakciju.
SecAuditLog Putanja do datoteke audit loga. /put/do/audit.log
Ostalo SecArgumentSeparator Definira kojim znakom su razdvojeni argumenti. znak
SecCookieFormat Odabir verzije cookiea. 0: Netscape cookie, njčešće korištena verzija
1: cookie verzija 1

--Zvkapes 19:56, 20. siječnja 2013. (CET)

Core Rules Set

ModSecurity je firewall za web aplikacije koji sam po sebi pruža slabu zaštitu. Da bi postao koristan, potrebno je namjestiti pravila. Kako bi se olakšalo korištenje samog alata, certifiran je set pravila. Taj set pravila nazivaju se Suštinska pravila ili Core Rules. Za razliku od sustava za detekciju i spriječavanje penetracija, koji se baziraju na potpisima specifičnim za poznate ranjivosti, Suštinska pravila pružaju generičku zaštitu od nepoznatih ranjivosti često nađenih u web aplikacijama. Kako bi se osigurala generička zaštita web aplikacija, Suštinska pravila koriste sljedeće tehnike:

HTTP zaštita – detekcija kršenja HTTP protokola i lokalno definirana pravila upotrebe.

Real-Time Blacklist Lookups – koristi IP reputaciju treće strane.

Detekcija malware-a baziranog na webu – Identifirica maliciozni web sadržaj provjeravajući preko Google Safe Browsing API-a.

HTTP zaštita od DoS-a – obrana od HTTP poplavljivanja i sporih HTTP DoS napada.

Zaštita od uobičajenih web napada – detekcija uobičajenih napada na sigurnost web aplikacije.

Detekcija automatizacije – detekcija botova, crawler-a, skenera i ostalih površinskih malicioznih aktivnosti.

Integracija sa AV skeniranjem uploadanih datoteka – detekcija malicioznih datoteka uploadanih kroz web aplikaciju.

Praćenje osljetljivih podataka – Praćenje korištenja kreditne kartice i blokiranje propusta.

Zaštita od Trojanaca – Detekcija pristupa Trojanskim konjima.

Identifikacija nedostataka aplikacije – upozoravanje o pogršnoj konfiguraciji aplikacije.

Detekcija i sakrivanje greški – Prikrivanje poruka o pogrešci poslanih od servera.

--Igraus 21:56, 15. siječnja 2013. (CET)

Instalacija CRS-a

Osim dodatka samih pravila u konfiguraciju, CRS postavi i vlastitu, jasnu organizaciju direktorija koju kasnije možemo koristiti i za dodavanje vlastitih pravila. CRS možemo preuzeti sa službenih stranica projekta pod tabom Download ili Sourceforge, no potrebno je paziti na verziju koju preuzimamo. Koraci instalacije (za Debian/Ubuntu operacijske sustave) su sljedeći:

  1. Prvo preuzmemo komprimiranu datoteku sa sljedećom naredbom: 
    sudo wget http://downloads.sourceforge.net/project/mod-security/modsecurity-crs/0-CURRENT/modsecurity-crs_2.2.5.tar.gz -P /tmp/
  2. Prebacimo se u direktorij u koji smo preuzeli datoteku, te ju dekomprimiramo. 
    cd /tmp
    Datoteka koju tražimo jest modsecurity-crs_2.2.5.tar.gz. 
     sudo tar -zxvf modsecurity-crs_2.2.5.tar.gz
  3. Premjestimo sadržaj dobivenog direktorija u modsecurity direktorij: 
     sudo mv modsecurity-crs_2.2.5/* /etc/modsecurity/
    Možemo odmah i izbrisati datoteke koje nam više ne trebaju: 
     sudo rm -R modsecurity-crs_2.2.5.tar.gz modsecurity-crs_2.2.5
  4. S CRS pravilima dolazi i konfiguracijska datoteka (modsecurity_crs_10_setup.conf.example) s dodatnim postavkama, no kao i kod preporučene konfiguracije za čisti ModSecurity, i ova je datoteka prvotno "isključena" na način da je dodana ekstenzija .example. Kako bismo koristili tu konfiguracijsku datoteku potrebno je ukloniti taj dodatak, a to ćemo učiniti na način da ju preimenujemo: 
     sudo mv /etc/modsecurity/modsecurity_crs_10_setup.conf.example /etc/modsecurity/modsecurity_crs_10_setup.conf
  5. Pravila koja možemo uključiti nalaze se u direktorijima base_rules, optional_rules, slr_rules i experimental_rules. Pravila unutar tih direktorija nalaze se u .conf datotekama, nazvanim prema vrsti napada ili greški od kojih brane.Prema nazivu možemo odrediti pravila koja su nam potrebna, a svako pravilo ima i kratak opis. Predviđeno je da se ona pravila koja želimo uključiti nalaze u direktoriju activated_rules koji je na početku prazan. Kako bismo to učinili, možemo kreirati simbolične linkove za pravila koja želimo. Ovdje ćemo uključiti sva pravila iz direktorija base_rules i optional_rules:
    Pozicioniramo se u direktorij iz kojeg želimo pravila: 
    cd /etc/modsecurity/base_rules/
    Kreiramo simbolične linove za svaku datoteku: 
    for f in * ; do sudo ln -s /etc/modsecurity/base_rules/$f /etc/modsecurity/activated_rules/$f ; done
    Isto učinimo i za direktorij optional_rules: 
    cd /etc/modsecurity/optional_rules
    for f in * ; do sudo ln -s /etc/modsecurity/optional_rules/$f /etc/modsecurity/activated_rules/$f ; done
  6. Kako bismo dodali nova pravila u apache, moramo dodati novu liniju unutar <IfModule security2_module> tagova apache konfiguracije (httpd.conf datoteka, odnosno, kod Debian/Ubuntu OS-a mod-security.conf unutar mods-available direktorija). Pa slijedi: 
    sudo gedit /etc/apache2/mods-available/mod-security.conf
    U datoteku, prije </IfModule> taga dodamo liniju Include "/etc/modsecurity/activated_rules/*.conf" te pohranimo.
  7. Restartamo web server: 
    sudo /etc/init.d/apache2 restart

--Zvkapes 19:56, 20. siječnja 2013. (CET) --Igraus 13:10, 24. siječnja 2013. (CET)

Testiranje

Za potrebe testiranja koristit će se Damn Vulnerable Web Application iz OWASP Broken Web Application projekta, budući da pruža mnoštvo web aplikacija sa poznatim nedostacima. Prikazat će se osnovna upotreba nekih pravila, te pravila iz Core Rule Seta.

SQL Injection napad

Jednostavni SQL Injection napad može izgledati nešto kao na sljedećoj slici:

Sis modsec 01.jpg

U ovom slučaju napad omogućuju znakovi navodnika koji poremete originalni SQL upit na bazu. Dakle, u ovakvom bi slučaju bilo dovoljno da ModSecurity traži takve znakove u argumentima, te ukoliko ih pronađe, zabrani pristup. Jednostavno pravilo bi tada izgledalo ovako: 

 SecRule ARGS "'" "phase:2, log, deny, status:503"

Direktivom SecRule definiramo pravilo, tražimo anomalije u ARGS, tj. argumentima, a traži se jednostruki znak navodnika, dakle " ' ". Akcije koje se poduzimaju definirane su sa "phase:2, log, deny, status:503". To znači da će ModSecurity provjeravati transakciju u drugoj fazi, a to je faza provjere tijela zahtjeva. U ovom konkretnom slučaju to bi jednako dobro funkcioniralo da se definiralo i u fazi 1 budući da se argumenti prenose GET metodom, no ukoliko bi se prenosili sa POST, tada bismo ga previdjeli. Log akcijom dajemo uputu da zabilježi pokušaj u log, deny osporava pravo pristupa, te vraća 'status:503'. Nakon dodatka ovog pravila, dobivamo sljedeći zaslon:

Sis modsec 02.jpg

Ovo je sasvim jednostavan primjer pravila koje omogućuje zaustavljanje takvih osnovnih napada. Core Rule Set sadrži mnoštvo vrlo složenih pravila koje se odnose na SQL injection napade svake vrste. Ta pravila sadrže kompleksne regularne izraze, koji su i vrlo teški za čitanje, pa je potrebno pročitati popratnu dokumentaciju. Primjer jednog takvog pravila: 

SecRule REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "(?i:(?:\b(?:(?:s(?:ys\.(?:user_(?:(?:t(?:ab(?:_column|le)|rigger)|object|view)s|c(?:onstraints|atalog))|all_tables|tab)|elect\b.{0,40}\b(?:substring|users?|ascii))|m(?:sys(?:(?:queri|ac)e|relationship|column|object)s|ysql\.(db|user))|c(?:onstraint_type|harindex)|waitfor\b\W*?\bdelay|attnotnull)\b|(?:locate|instr)\W+\()|\@\@spid\b)|\b(?:(?:s(?:ys(?:(?:(?:process|tabl)e|filegroup|object)s|c(?:o(?:nstraint|lumn)s|at)|dba|ibm)|ubstr(?:ing)?)|user_(?:(?:(?:constrain|objec)t|tab(?:_column|le)|ind_column|user)s|password|group)|a(?:tt(?:rel|typ)id|ll_objects)|object_(?:(?:nam|typ)e|id)|pg_(?:attribute|class)|column_(?:name|id)|xtype\W+\bchar|mb_users|rownum)\b|t(?:able_name\b|extpos\W+\()))"  "phase:2,rev:'2.2.5',capture,t:none,t:urlDecodeUni,ctl:auditLogParts=+E,block,msg:'Blind SQL Injection Attack',id:'950007',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE1',tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.sql_injection_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}"

Ovo konkretno pravilo odnosi se na slijepi SQL injection. Vidljivo je da CRS pravila traže greške na mnogim mjestima, od cookiea do naziva datoteka, sadrže iznimno kompleksne regularne izraze, te iscrpan opis greške koji se pojavljuje u logu. Primjer zapisa iz audt-loga kod uključenih CRS pravila prilikom pokušaja SQL injection napada:

Sis modsec 03.jpg

Kontrola pristupa

ModSecurity dopušta definiranje pravila na način da možemo postaviti i pozitivni i negativni sigurnosni model. Negativni sigurnosni model podrazumijeva definiranje pravila za ono što želimo odbiti, odnosno, dopušta se sve osim onoga što je definirano pravilima. Na negativnom modelu funkcioniraju CRS pravila. Pozitivni sigurnosni model, s druge strane, podrazumijeva definiranje onoga što je dopušteno, a blokiranje svega ostaloga. Dobar primjer za korištenje pozitivnog sigurnosnog modela jest kontrola pristupa preko ip adrese, što ćemo pokazati u ovom testu.

Kako bismo ostvarili pozitivni sigurnosni model, prvo je potrebno definirati koje transakcije su dozvoljene. U ovom primjeru, dozvolit ćemo pristup aplikaciji samo s određene IP adrese, konkretno, s lokalne adrese 192.168.1.3. 

SecRule REMOTE_ADDR "@streq 192.168.1.3" "phase:1, allow, nolog"

Sve ostale zahtjeve trebamo blokirati. U ModSecurityu to najlakše definiramo direktivom SecAction. 

SecAction "phase:1,deny,log"

Sada ukoliko pokušamo pristupiti aplikaciji sa bilo koje adrese koja nije 192.168.1.3, dobit ćemo zabranu pristupa kao na sljedećoj slici:

Forbidden.jpg

--Zvkapes 19:56, 20. siječnja 2013. (CET)

Literatura

  1. ModSecurity Reference Manual. Dostupno 20.1.2013. na http://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual.
  2. Ristić, I. (2012). ModSecurity Handbook. Feisty Duck. London. Dostupno 20.1.2013. na https://www.feistyduck.com/books/modsecurity-handbook/gettingStarted.html
  3. CARNet. Mod security modul. Dostupno 20.1.2013. na http://www.cis.hr/www.edicija/LinkedDocuments/CCERT-PUBDOC-2004-02-63.pdf
  4. Sa, A. (2012). How To Install Mod_Security On Apache(Ubuntu 12.10) Step By Step Tutorial For Beginners. Root25.com. Dostupno 20.1.2013. http://www.root25.com/2012/11/how-to-install-modsecurity-on-apache-ubuntu12-stepbystep-tutorial.html
  5. Pk, S. Mod_Security .. Intro. Dostupno 20.1.2013. na http://blog.supportpro.com/2009/08/mod_security-intro/
  6. Trustwave. ModSecurity. http://www.modsecurity.org/
  7. Biancuzzi, F. (2006). ModSecurity 2.0 with Ivan Ristic. Dostupno 20.1.2013. na http://www.securityfocus.com/columnists/418/1

Zaduženja članova tima

Zvonimir Kapeš


Nikola Pintarić


Igor Rauš

Dobavljeno iz "https://security.foi.hr/wiki/index.php/ModSecurity"
Osobni alati
Imenski prostori
Inačice
Radnje
Orijentacija
Traka s alatima