Zaštita PHP aplikacija s mod security
Studenti: Danijel Tot, Sanjin Vučković
Sadržaj |
Povijest ModSecurityja
Razvijanje ModSecurityja započelo je 2002. godine, nakon što je Ivan Ristić shvatio da je nemoguće napraviti „sigurnu“ web aplikaciju. Došao je na ideju da napravi alat koji će biti smješten između interneta i web aplikacije, te kontrolirati ulazno/izlazne podatke. Prva verzija je puštena u studenom 2002. godine. U početku najviše je problema imao s implementiranjem u Apache zbog toga što Apache 1.3.x nije imao APIje za presretanje ili filtriranje podataka. Verzije Apache 2.x su sadržavale te APIje, ali je Ivan Ristić prije toga našao način kako čitati tijelo HTTP zahtjeva. Nadalje 2006. godine na razvijanju ModSecurityja su mu se pridružili: Brian Rectanus, Ofer Shezaf i Ryan C. Barnett. U siječnju 2009. godine Ristić je prestao sa radom na ModSecurityju, zbog napuštanja tvrtke Breach Security, te su na projektu ostali raditi samo preostalo tadašnji članovi. Ryan Barnett je napravio značajan pomak u razvoju ModSecuritya 2010 godine izdavanjem CRS v2. CRS označava Core Rule Set, odnosno skup osnovnih pravila koji rješavaju uobičajene i poznate napade na web aplikacije. Još jedna važnija promjena se dogodila u ožujku 2011. kada je došlo do promjene licence iz GPLv2 u Apache Software License (ASLv2), što je veliki korak široj uporabi ModSecuritya. Također je ista promjena najavljena i za CRS projekt.
ModSecurity
ModSecurity je alat za praćenje aplikacija, vođenje logova i kontrolu pristupa u realnom vremenu. U nekim izvorima može se pronaći da je ModSecurity WAF, odnosno Web Application Firewall. To znači da ModSecurity može poslužiti kao zaštita između interneta i web aplikacija. WAF je inače serverski dodatak ili filter koji provodi skup pravila u HTTP komunikaciji. Pravilima se utječe na HTTP komunikaciju i ona se po potrebi može i prekinuti. WAF se uvijek koristi u sigurnosne svrhe, kako bi se aplikacije dostupne na internetu zaštitile od sigurnosnih propusta. Kao što je već rečeno uz pomoć ModSecurityja se mogu pratiti aplikacije i njihova komunikacija s korisnicima. Ako se uoče nepravilnosti u komunikaciji, odnosno da netko pokušava koristiti aplikaciju na nepredviđen način, ti se pokušaji mogu voditi u logovima, a po potrebi se može i zabraniti kontrola pristupa toj aplikaciji određenom korisniku. To se provodi uz pomoć skupa pravila koje definira i provodi ModSecurity.
Što ModSecurity radi?
ModSecurity ima mnogo funkcionalnosti, ali bismo njegove funkcionalnosti mogli svrstati u par kategorija. Prvenstveno njegova namjena ovisi o samom korisniku i o njegovim potrebama. Valja spomenuti da svaki korisnik može konfigurirati ModSecurity vrlo jednostavno, ako poznaje sintaksu pravila koja želi provoditi. Kategorije u koje smještamo najčešće slučajeve korištenja ModSecurityja su:
ModSecurity daje pristup toku HTTP prometa, u realnom vremenu, uz mogućnost pregledavanja tog prometa. To je dovoljno da bi se moglo provoditi praćenje sigurnosti aplikacije. Također je uz pomoć ovog alata moguće pouzdano kontrolirati pristup aplikaciji i blokirati određene izvore od pristupa.
Virtualno nadograđivanje
Virtualno nadograđivanje je koncept smanjenja sigurnosnih propusta u zasebnom sloju, gdje se sigurnosni propusti u aplikaciji mogu smanjivati bez promjene na samoj aplikaciji. Virtualno nadograđivanje je moguće na aplikacijama koje koriste bilo kakav način vanjskog komuniciranja, a iznimno je korisno za aplikacije koje koriste HTTP, zbog toga što promet može biti analiziran od uređaja koji predstavlja posrednika u komunikaciji. ModSecurity je dobar za virtualno nadograđivanje zbog njegovih mogućnosti za kontrolu pristupa i jednostavne sintakse za pisanje pravila koja mogu biti prilagođena svakoj namjeni. Ovo je kategorija koja je najjednostavnija za implementiranje, a nudi najviše za bilo koju web aplikaciju.
Vođenje logova za HTTP promet
Web serveri su vrlo slabi po ovom pitanju i inače ne vode logove koji se koriste u sigurnosne svrhe. Prema početnim postavkama web serveri vrlo malo događaja zapisuju u log, a i uz promjene konfiguracije se malo toga može napraviti da bi se vodili kvalitetniji i detaljniji logovi. Za razliku od njih ModSecurity ima mogućnost da u log upisuje i sve podatke koji su se prenijeli u komunikaciji. On daje mogućnost da se u log zapisuje što god je potrebno, te se kasnije može koristiti za „forenziku“ odnosno kreiranje scenarija po kojem je napadač iskoristio neki sigurnosni propust u aplikaciji. Uz pomoć toga se kasnije mogu napraviti dodatne zakrpe i popravci na aplikaciji.
Kontinuirana pasivna procjena sigurnosti
Procjena sigurnosti se inače obavlja kao aktivnost prema unaprijed određenom rasporedu, kada određeni napadač pokušava simulirati neki napad. Za razliku od toga kontinuirana pasivna procjena sigurnosti je varijacija praćenja u realnom vremenu, gdje se umjesto na vanjske napade prati ponašanje samog sustava i njegovi sigurnosni propusti. Također to možemo promatrati kao sustav koji upozorava na sigurnosne propuste i prije nego što ih je netko iskoristio. Zbog toga što se bilježe svi događaji koji su nepravilni u radu aplikacije i koji se mogu iskoristiti kao sigurnosni propust.
Ojačavanje web aplikacija
Jedan od najvažnijih načina na koji se koristi ModSecurity je smanjivanje područja s kojeg dolazi napad. Sa ModSecurityjem je moguće selektirati koja HTTP svojstva aplikacija može prihvatiti (npr. request methods, request headers, content types i slično). Tako ModSecurity u suradnji s nekim drugim npr. Apache modulima može surađivati kako bi se smanjili sigurnosni propusti pri upravljanju sesijama ili napad poznatiji pod imenom cross-site request forgery.
Ostale namjene
ModSecurity je prilično fleksibilan što se tiče namjene i open source aplikacija je što omogućava njegove preinake i za korištenje drugačijih namjena. Na primjer, može se koristiti i kao XML web servis ruter, kombinirajući njegovu mogućnost da parsira XML i primjenjuje XPath izraze s mogućnošću da preusmjeravanje zahtjeva.
Karakteristike ModSecurityja
Fleksibilnost - za ModSecurity može se reći da je fleksibilan iz više razloga. To je open source aplikacija za koju korisnici mogu dobiti izvorni kod pa ju tamo mogu konfigurirati prema želji. Drugi razlog je taj što korisnici sami kreiraju pravila prema kojima žele da njihova zaštita radi, pa i tamo imaju veliku mogućnost da odaberu kako će se aplikacija ponašati.
Pasivnost - ModSecurity je sam po sebi veoma pasivna aplikacija. On će pratiti sav promet ali neće donositi odluke koje nisu definirane prema pravilima koje je korisnik kreirao. Dakle odluke koji će se paketi odbiti, kojim će se korisnicima zabraniti pristup, donosi sam korisnik koji implementira sustav zaštite web aplikacije.
Predvidljivost - vrlo je jednostavno predvidjeti kako će se ModSecurity ponašati. Prema pravilima koja mu korisnik zada. To je još jedna od odlika kojom se ModSecurity može pohvaliti. Ova je karakteristika vrlo povezana s pasivnošću jer ModSecurity ništa ne radi ako mu tako korisnik ne definira.
Kvaliteta prije kvantitete - sam tvorac ModSecurityja kaže da je tom projektu posvećeno puno vremena na kvalitetne funkcionalnosti, a ne na mnogobrojne funkcionalnosti. Zato postoji ograničen skup pravila koja se mogu definirati u ModSecuirtyju, ali su ona izrazito kvalitetna i dobro funkcioniraju.
Sigurnosne prijetnje PHP aplikaciji
Danas se sve internetske stranice temelje na osnovnih tehnologijama poput HTML-a i PHP-a. Budući da svi koriste iste osnove, postoje i osobe sa zlim namjerama koji tu činjenicu žele iskoristiti. Ovdje će biti prikazani najčešći načini napada na PHP aplikacije, dok u praksi postoje još brojni načini na koji napadači izvode napade na PHP aplikacije.
SQL Injection
Ova vrsta napada je jedna od najčešćih napada na php aplikacije. Moguće ju je primijeniti kada u aplikaciji postoji dio u kojem korisnik upisuje informacije i šalje iz prema serveru, koji zatim komunicira s bazom podataka i vraća nekakav rezultat. Pomoću SQL injectiona pokušava se manipulirati komunikacijom s bazom podataka, tako da se izvodi upit koji otkriva povjerljive podatke ili čak briše tablice iz baze podataka. Takvih aplikacija danas ima veliki broj jer gotovo sve internetske stranice imaju dio povezan s logiranjem korisnika, a upravo je upisivanje korisničkog imena i lozinke najčešće korišteno za izvršavanje SQL injection napada.
XSS
XSS, odnosno cross site scripting, vrsta je napada u kojoj napadač pokušava ubaciti malicioznu skriptu na server, koja se zatim izvodi kod svih korisnika koji posjete zaraženu stranicu. Aplikacije koje su ranjive na ovakvu vrstu napada su one aplikacije koje primaju i pohranjuju nekakve podatke od korisnika, i te podatke prikazuju drugim korisnicima. Budući da preglednici očekuju da su skripte koje se pokreću sa servera pouzdane, te skripte se izvršavaju u preglednicima krajnjih korisnika. Ako napadač uspije ubaciti malicioznu skriptu na server, koja će se zatim pokrenuti kod drugih korisnika, očito je da ovakva vrsta prijetnje predstavlja veliki problem. Maliciozne skripte najčešće sadrže dijelove napisane u JavaScriptu.
CSRF
Kratica CSRF znači Cross-Site Request Forgery, a kod ove vrste napada napadač izvršava naredbe na serveru za koje nema autorizaciju. Napadač pokušava "prevariti" drugu osobu, koja ima potrebnu autorizaciju, da izvrši akciju koja će imati štetne posljedice za tog drugog korisnika. Najčešći oblik napada je da napadač pošalje nekakav link, koji u sebi sadrži maliciozni zahtjev, drugoj osobi, ta osoba pozove dobiveni link u svome pregledniku i izvrši se neka akcija koju je napadač isprogramirao, a druga osoba nije znala da će se izvršiti. Žrtva pri tome ima ovlasti na određenoj web aplikaciji koje napadač nema, i pomoću ovakvog napada napadač želi obaviti akciju za koju nema autorizaciju izvršiti ju. Ovakvi napadi najviše utječu na sigurnost krajnjih korisnika, koji kao žrtve napada mogu bez svoga znanja napadačkima otkriti svoje povjerljive podatke.
Brute force
Brute force označava vrstu napada gdje napadač pokušava pristupiti dijelu aplikacije za koju nema pristup. To radi tako da pogađa korisničko ime i lozinku neke osobe koja ima potrebnu autorizaciju. Pri ovakvim napadima isprobavaju se liste najčešće korištenih lozinki i pokušava se dobiti pristup zaštićenom dijelu aplikacije. Ako sustav dopušta neograničen broj pokušaja, tada je samo pitanje vremena kada će napadač "probiti" lozinku i dobiti pristup sustavu. Osim probijanja korisničkih računa, postoje programi koji rade na brute force principu, a ispituju koji je url stranice za pristup bazi podataka. Ispituju se sve poznate kombinacije i nakon nekog vremena je za očekivati da će se otkriti url na kojem se nalazi ulaz u sustav za upravljanje bazom podataka neke aplikacije.
Pisanje pravila
Kao što je do sada nekoliko puta spomenuto, ModSecurity radi na principu pravila. Korisnik piše različita pravila koja pomažu pri povećanju sigurnosti php aplikacija, a sav promet koji ide između korisnika i aplikacije prolazi kroz sva ta pravila i ako zadovolji sve kriterije, tek tada će doći do odredišta. Kako bi pravila mogli pisati korisnici koji ne pripadaju krugu stručnjaka za internetsku sigurnost, sintaksa pravila je jednostavna te omogućuje brzo pisanje jednostavnih pravila, ali i pisanje nešto kompliciranijih pravila.
Sintaksa pravila
Jedno pravilo može biti oblika:
SecRule ARGS "izraz" nolog,deny, status:404
Odmah na prvi pogled neke se stvari mogu zaključiti. Na prvome mjestu dolazi naziv pravila, koja su unaprijed definirana i ima ih velik broj. Zatim postoji ARGS "izraz", što označava se da će pretraživati nekakav izraz koji će biti napisan u zagradi, a najčešće se pri pisanju izraza koriste regularni izrazi. Sljedeći dio glasi "nolog,deny, status:404", što su očito nekakve opcije koje govore što će se raditi s podacima koji zadovolje navedeno pravilo.
Općenito, pravila su oblika:
NazivPravila Varijable Operatori Akcije
Iz ovoga se može vidjeti da se pravila sastoje od četiri dijela:
Naziv pravila označava ime pravila koje se koristi. Taj broj pravila je ograničen, a sva su detaljno opisana u javno dostupnoj službenoj dokumentaciji ModSecurityja. Ovdje će kasnije biti detaljno opisano nekoliko najčešće korištenih pravila.
Varijable, odnosno dio pravila s varijablama govori što pravilo treba tražiti. Također su u dokumentaciji opisana sva podržana pravila kojih ima veliki broj, a pravilo korišteno u primjeru gore, ARGS, označava da će se tražiti argumenti koji se pošalju kao dio zahtjeva prema php aplikaciji.
Operatori govore pravilu kako tražiti i nadopunjuju dio s varijablama. Gornji primjer ima kao operator "izraz", koji u kombinaciji s varijablom ARGS označava se da će pretraživati postoji li određeni izraz, koji se piše kao regularni izraz, u zahtjevu koji je poslan aplikaciji.
Akcije su posljednji dio pravila, i u njima se navodi što će se raditi nakon što dio s varijablama i operatorima pronađe traženi izraz. U navedenom izrazu kao akcije su navedeni "nolog,deny, status:404". Tu postoje tri akcije, prva (nolog) govori da se ništa neće zapisivati u logove, druga (deny) označava da će se odbiti zahtjev koji je poslan aplikaciji, a treća (status:404) označava da će se vratiti korisniku greška tipa 404.
Akcije
Akcije su bitan dio koji određuju što će se napraviti kada se pronađe nekakva nepravilnost te se mogu podijeliti u 5 skupina: prekidajuće, neprekidajuće, akcije tijeka, akcije za meta podatke i podatkovne akcije.
Prekidajuće akcije označavaju da će doći do nekakvog prekida akcije koju je korisnik pokrenuo, čime se poslao zahtjev aplikaciji. Nakon analize tog zahtjeva pomoću pravila, ako se neki dio zahtjeva označi opasnim, može doći do prekidajuće akcija koja će korisniku vratiti grešku, i neće uopće dozvoliti da podaci dođu do same aplikacije jer bi joj mogli naštetiti.
Neprekidajuće akcije su one kada se pravilo aktivira i obavi neku akciju, ali zahtjev korisnika se ipak propušta do same aplikacije. Primjerice može se primijetiti nekakva sumnjiva radnja i to se zapisati u log, ali korisniku se neće javiti nikakva greška nego će mu se omogućiti nastavak rada.
Akcije tijeka su akcije kojima se može upravljati tijekom prolaska zahtjeva kroz pravila, odnosno može se odrediti da se prilikom analize neka pravila preskoče.
Akcije za meta podatke označavaju da se dodaje više informacija o samim pravilima. Primjer je akcija severity, koja pravilu dodaje oznaku važnosti. Postoji 8 stupnjeva važnosti koji se mogu dodijeliti pravilu: 0 – Emergency, 1 – Alert, 2 – Critical, 3 – Error, 4 – Warning, 5 – Notice, 6 – Info, 7 – Debug.
Podatkovne akcije zapravo ni nisu akcije, nego služe za spremanje podataka koje će koristiti druge akcije. Primjerice, ako će se ispisati greška korisniku sa statusom 403, može se pomoću podatkovnih akcija navesti koji će se podaci prikazati prilikom greške s tim statusom.
Osnovna pravila
ModSecurity kroz projekt CRS (Core Rule Set) već nudi osnovni skup pravila koja su već napisana za korisnike koji ne žele pisati pravila sami, a žele spriječiti najpoznatije napade. Ta pravila se mogu preuzeti ovdje. Kada se skine ovaj skup pravila sadrži par vrsta pravila, a to su: aktivna pravila, osnovna pravila, eksperimentalna pravila, opcionalna pravila, itd. To znači da je ModSecurity još uvijek u fazi razvoja i da se u skladu sa sigurnošću razvijaju i pravila koja tu sigurnost podržavaju kroz ModSecurity.
Request Handle
SecRuleEngine – koristi se da bi omogućio rad ModSecurityja, odnosno konfigurira način rada pravila.
•On - procesiraj pravila •Off - ne procesiraj pravila •DetectionOnly - procesiraj pravila, ali se nikada ne uplići u transakciju, čak ni kada to pravila zahtijevaju
Primjer korištenja: SecRuleEngine On
SecRequestBodyAccess - ako ovo pravilo nije uključeno tada ModSecurity neće pristupati tijelu poruke, te mu neće biti dostupne vrijednosti POST varijabli. To daje mogućnost napadaču da iskoristi takav sigurnosni propust.
•On - pregledavaj tijelo poruke •Off - ne pregledavaj tijelo poruke
Primjer korištenja: SecRequestBodyAccess On
SecRequestBodyLimit - definira najveću moguću količinu podataka koja će biti prenijeta u tijelu poruke. Za ovo pravilo postoji „hard limit“ od 1GB podataka. Postoji pravilo slično ovome ('SecRequestBodyNoFilesLimit') koje definira maksimalnu moguću količinu podataka prenijetih izuzimajući datoteke. Sintaksa pravila je ista.
•BROJ_BAJTOVA – kao parametar ovom pravilu prosljeđuje se broj bajtova koji će označavati najveću moguću količinu podataka prenijetih u tijelu poruke
Primjer korištenja: SecRequestBodyLimit 134217728 Pojašnjenje primjera: 134217728B iznosi 128MB što znači da će u tijelu poruke biti moguće prenijeti max 128MB podataka.
SecRequestBodyLimitAction - ovo pravilo je izravno povezano s pravilom SecRequestBodyLimit i odgovara načinu na koji će aplikacija postupiti ako korisnik pokuša prenijeti više od dozvoljene količine podataka.
•Accept – prihvati poruku •Reject - odbij poruku
Primjer korištenja: SecRequestBodyLimitAction Reject
Response Handle
SecResponseBodyAccess - odobrava pristup tijelu poruke odgovora. Uz pomoć pravila ovog tipa može se pronaći curenje različitih podataka koje nije dozvoljeno. Naravno uključivanjem ovog pravila usporava se komunikacija i troše se dodatni resursi.
•On- dozvoli pristup tijelu poruke •Off- zabrani pristup tijelu poruke
Primjer korištenja: SecResponseBodyAccess On
SecResponseBodyMimeType - definira kojem tipu podataka želimo pristupati.
•text/plain - pristup čistom tekstu •text/html - pristup html datotekama •text/xml - pristup xml datotekama •itd.
Primjer korištenja: SecResponseBodyMimeType text/plain text/html
SecResponseBodyLimit - definira maksimalnu veličinu tijela poruke koja može biti poslana.
•BROJ_BAJTOVA – kao parametar ovom pravilu prosljeđuje se broj bajtova koji će označavati najveću moguću količinu podataka prenijetih u tijelu poruke
Primjer korištenja: SecResponseBodyLimit 524288
Filesystem Configuration
SecTmpDir - definira mapu u koji će ModSecurity spremati privremene datoteke (kada je potrebno upravljati datotekama koje su veće od ograničenja).
•Putanja do mape u koju će se spremati privremene datoteke
Primjer korištenja: SecTmpDir /tmp/
SecDataDir - definira mapu u kojoj će ModSecurity čuvati stalne datoteke.
•Putanja do mape u koju će se spremati stalne datoteke
Primjer korištenja: SecDataDir /data/
Debug Log
SecDebugLog - definira putanju do mape u kojoj se nalazi datoteka s ekstenzijom .log u koju će se spremati debug log.
•Putanja do mape u koju će se spremati debug log
Primjer korištenja: SecDebugLog /apache/security/logs/debug.log
SecDebugLogLevel - definira razinu osjetljivosti koja određuje što će se spremati u debug log, a što ne.
•0 – u log se ne sprema ništa •1 – samo pogreške •2 – upozorenja •3 – zapažanja •4 – detalji o provođenju transakcija •... •9 – u log se sprema sve uključujući detaljne informacije
Primjer korištenja: SecDebugLogLevel 3
Audit Log
SecAuditEngine – konfigurira vođenje revizijskog loga.
•On – vođenje revizijskog loga je omogućeno •Off – vođenje revizijskog loga je isključeno •RelevantOnly – u log se upisuju samo važniji podaci
Primjer korištenja: SecAuditEngine RelevantOnly
SecAuditLog - definira putanju do mape u kojoj će se voditi revizijski log.
•Putanja do mape u koju će se spremati revizijski log
Primjer korištenja: SecAuditLog /apache/security/logs/error.log
SecAuditLogType - definira način na koji će se voditi revizijski log.
•Serial - svi revizijski logovi će se spremati u istu datoteku. •Concurrent - revizijski logovi se spremaju u različite datoteke, za svaku transakciju posebna datoteka.
Primjer korištenja: SecAuditLogType Concurrent
Instalacija ModSecurityja
Jedna od velikih prednosti ModSecurityja je i njegova prenosivost te dostupnost. Moguće ga je vrlo jednostavno instalirati na server i početi koristiti. Trenutna stabilna verzija (2.7.1) kompatibilna je s Apache, IIS7 i Nginx serverima. Ovdje će biti prikazana instalacija i rad na serveru Apache, a za instalaciju na ostalim serverima potrebno je pogledati službenu dokumentaciju dostupnu svima na internetu.
Prvo je potrebno postaviti Apache server, a za potrebe ovoga testiranja koristit će se XAMPP paket za operacijski sustav Windows 7, koji sadrži Apache server, a uključuje i MySQL te PHP, koji će također biti korišteni. Korišteni XAMPP paket je verzije 1.8.1, što znači da će biti uključen Apache verzije 2.4.3. Treba obratiti pozornost da verzije ModSecurity 2.0 i kasnije rade isključivo s Apache serverima verzije 2.0 i kasnije. Nakon instaliranja Apache servera potrebno je preuzeti sve potrebne datoteke za ModSecurity, koje su svima dostupne i otvorenog koda, a može ih se preuzeti ovdje.
Od preuzetih datoteka, obavezno je staviti onu naziva mod_security2.so u Apache direktorij, poddirektorij modules. Ova datoteka označava da je na server dodan novi modul, te se ona ne smije mijenjati. Ovdje se također može primijetiti da je za instalaciju ModSecurityja potrebno imati pristup datotekama servera i imati prava modificiranja tih datoteka.
Nakon postavljanja datoteke u poddirektorij modules, potrebno je negdje pozvati taj modul. To se radi u konfiguracijskim postavkama Apache servera, koje se obično nalaze u poddirektoriju conf, a naziv same datoteke je httpd.conf. To je tekstualna datoteka koju se može otvoriti s bilo kojim programom za uređivanje teksta i potrebno je napraviti tri koraka. Prvi korak je dodati novi redak u dio u kojem se učitavaju posebnu moduli, a taj redak je sljedeći:
LoadModule security2_module modules/mod_security2.so
Drugi korak je sličan, potrebno je provjeriti da je uključen modul Unique Id, odnosno da postoji redak:
LoadModule unique_id_module modules/mod_unique_id.so
među učitanim modulima. Taj redak trebao bi već postojati, ali je zakomentiran da se ne učitava, te je samo potrebno maknuti oznaku za komentar. Treći korak je postavljanje putanje s datotekom s pravilima. Pravila mogu biti napisana u više datoteka, a mogu biti i u samo jednoj. Preporuka je pisati pravila u više datoteka, posebno ako će se pisati veliki broj pravila, tako da se odvoje različita pravila koja imaju različitu namjenu. Ako će se koristiti samo jedna datoteka, tada je potrebno u httpd.conf datoteci dodati putanju pravila, kao na primjer:
Include "conf/extra/modsecurity.conf"
Dio pod navodnicima odnosi se na putanju pravila, koja mogu biti postavljena u bilo koji poddirektorij, a preporuka je stavljati ih u poddirektorij conf.
Primjeri korištenja
U ovom će dijelu biti prikazano nekoliko primjera korištenja ModSecurityja. Već je opisano kako je to jak alat i što sve omogućuje, a ovdje će biti prikazano nekoliko osnovnih primjera korištenja i kako zaštititi PHP aplikacije od nekoliko vrsta različitih napada.
Blokiranje IP adrese
ModSecurity omogućuje da se blokira pristup aplikaciji s određene IP adrese. Isto tako, moguće je blokirati pristup svim IP adresema, a zatim posebnim pravilima omogućiti određenim adresa da ipak mogu pripstupiti aplikaciji. Za blokiranje određene IP adrese koristi se pravilo oblika:
SecRule REMOTE_ADDR "^10\.24\.18\.250$" "phase:1,nolog,deny,id:119,status:403
Korišteno pravilo je SecRule, varijabla je REMOTE_ADDR, operator "^10\.24\.18\.250$", a akcije "phase:1,nolog,deny,id:119,status:404". Ova varijabla označava se će se nešto raditi s IP adresama, u operatoru je točno napisana IP adresa s kojom će se nešto raditi, a pod akcijama se može vidjeti i što će biti napravljeno. Jedna od akcija je "deny", što znači da će se omogućiti pristup aplikaciji s te IP adrese. Akcija "status:403" označava da će se korisniku koji pokuša pristupiti s navedene IP adrese ispisati pogreška tipa 403, kao što se može vidjeti na sljedećoj slici:
Blokiranje pristupa po parametrima URL-a
Moguće je blokirati pristup određenim stranicama kada se u URL unese određeni parametar preko kojega se radi blokiranje. Jedan takav primjer je pravilo:
SecRule ARGS "sis-blok" "phase:1,log,deny,id:1"
Kao varijabla se ovdje koristi ARGS, što znači da će se pretraživati argumenti koji se navedu u operatoru pravila. U ovom primjeru kao operator naveden je izraz "sis-blok", tako da kada korisnik kao parametar URL-a unese izraz "sis-blok", tada će mu biti onemogućem pristup toj stranici, kao što je vidljivo na sljedećoj slici:
Izraz u operatoru pravila se može oblikovati pomoću regularnih izraza (regular expressions), tako da je moguće postaviti i mnogo složenije izraze koji će biti blokirani. Ako se pak ne pronađe traženi izraz, stranica će se normalno otvoriti:
Prethodna dva primjera, blokiranje po IP adresi i blokiranje po parametrima URL-a mogu se kombinirati, te će u sljedećem primjeru biti prikazano blokiranje pristupa pojedinom korisniku, ali samo na određeni vremenski rok. Za takvu funkcionalnost koriste se sljedeća pravila:
SecAction phase:1,id:116,nolog,pass,initcol:ip=%{REMOTE_ADDR}
SecRule ARGS "blokiraj" "phase:2,block,id:117,setvar:ip.blocked=1,expirevar:ip.blocked=20"
SecRule IP:BLOCKED "@eq 1" "phase:1,deny,id:118,log"
Prvo pravilo je naziva SecAction i ono nema varijable i operatore nego samo akcije, tako da se ono poziva uvijek, ne treba biti ispunjen nikakav uvjet da se ono pozove. Namjena ovog pravila je da se u varijablu "ip" zapiše IP adresa korisnika. Drugo pravilo određuje izraz u parametru preko kojega će se blokirati pristup stranici. Ako korisnik upiše navedeni parametar, tada će se postaviti varijabla "ip.blocked" na 1 i njeno trajanje iznosi 20 sekundi, što je određeno akcijom "expirevar". Varijabla "ip.blocked" zapravo služi kao zastavica te kada ima vrijednost 1 pridodjeljena IP adresa je blokirana i ne može se pristupiti niti jednoj stranici aplikacije. Treće pravilo provjerava je li postavljena vrijednost varijable "ip.blocked" na 1, a ako jest onda se blokira pristup korisnika.
Sprječavanje SQL injection napada
Kao što je već navedeno uz pomoć ModSecurityja mogu se sprječavati i SQL injection napadi. Na sljedećoj slici može se vidjeti forma za prijavljivanje koja se spaja na bazu podataka i provjerava postojanje korisnika. U testne svrhe u bazi se nalazi korisnik sa korisničkim imenom "admin" i lozinkom "admin". Na slici vidimo da je uneseno korisničko ime admin, a za lozinku je upisan SQL injection:
Naravno, ako u konfiguraciji ModSecurityja nije upisan skup pravila koji blokira SQL napade, tada će prijava uspješno proći:
Da bi se to sprječilo potrebno je u ModSecurityju postaviti sljedeće pravilo:
SecRule ARGS "(/\*!?|\*/|[';]--|--[\s\r\n\v\f]|(?:--[^-]*?-)|([^\-&])#.*?[\s\r\n\v\f]|;?\\x00)" "phase:2, id:'981231',deny,msg:'SQL Comment Sequence Detected.',log"
Da bi prethodno pravilo moglo pravilno raditi, kao što je već spomenuto u poglavlju osnovna pravila, potrebno je postaviti pravilo SecRequestBodyAccess On. Nadalje ovo pravilo provjerava regularni izraz i ukoliko znakovi koji su upisani na mjestu lozinke ili korisničkog imena odgovaraju tom regularnom izrazu provodi akcije koje su upisane iza regularnog izraza. Tim akcijama dodjeljuje se jedan id. Korisniku se zabranjuje pristup stranici uz pomoć naredbe deny. Te će se u log upisati pokušaj provođenja SQL injection napada. Nakon uključenog pravila u ModSecurity i pokušaja ponovnog provođenja SQL injection napada, rezultat je sljedeći:
Sprječavanje DOS napada
Sljedeći isječak koda, odnosno skup pravila blokira Denial Of Service napade.
SecAction "phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},setvar:ip.requests=+1,expirevar:ip.requests=5,id:120"
SecRule ip:requests "@eq 5" "phase:1,deny,log,setvar:ip.block=1,expirevar:ip.block=60,id:121"
SecRule ip:block "@eq 1" "phase:1,deny,log,logdata:'req/sec: %{ip.requests}, blocks: %{ip.blocks}',status:403,id:123"
Prvi redak je akcija koja za određenu ip adresu koja pristupa stranici sprema broj pokušaja, odnosno broj pristupanja bilo kojoj stranici aplikacije. Ta akcija se ne zapisuje u log zbog naredbe nolog, korisnik se pušta na stranicu uz pomoć naredbe pass i dodijeljuje se vrijednost varijable "ip.request" dodavanjem za 1. Nadalje može se vidjeti kako se opet koristi naredba expirevar, ta naredba nakon 5 sekundi briše varijablu "ip.requests". U drugom retku vidimo pravilo koje ispituje da li je vrijednost varijable "ip.request" jednaka 5. Znači u slučaju da korisnik osvježava stranicu više od 5 puta unutar 5 sekundi, tada će se provesti to pravilo. to pravilo zabranjuje pristup korisniku uz pomoć naredbe deny. Slučaj DOS napada se zabilježava u log, te se postavlja varijabla "ip.block" koja služi kao zastavica koja označava blokiranje određene ip adrese. Ta varijabla u ovom slučaju ističe za 60 sekundi. Naravno u realnim situacijama će se pristup korisniku zabraniti na puno duže. Treći redak provjerava da li je vrijednost varijable "ip.block" jednaka 1. U slučaju da je jednaka 1, tada će se korisniku biti zabranjen pristup stranici i biti će mu vraćen status: 403. Te će se u log spremiti podaci o ip adresi, broju pokušaja i vrijednost zastavice "ip.block".
Primjer loga može se vidjeti ovdje:
--b41c0000-A-- [20/Jan/2013:17:17:23 +0100] UPwYk6n@BbkAAA98WkQAAAB4 10.24.18.250 14028 10.24.13.30 80 --b41c0000-B-- GET /main_login.php HTTP/1.1 Host: 10.24.13.30 Connection: keep-alive Cache-Control: max-age=0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17 Accept-Encoding: gzip,deflate,sdch Accept-Language: hr-HR,hr;q=0.8,en-US;q=0.6,en;q=0.4 Accept-Charset: UTF-8,*;q=0.5 Cookie: __utma=129477260.357856877.1357675843.1357739668.1358676202.3; __utmz=129477260.1357675843.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none) --b41c0000-F-- HTTP/1.1 403 Forbidden Vary: accept-language,accept-charset Accept-Ranges: bytes Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=utf-8 Content-Language: en --b41c0000-H-- Message: Access denied with code 403 (phase 1). Operator EQ matched 1 at IP:block. [file "D:/xampp/apache/conf/extra/modsecurity.conf"] [line "249"] [id "123"] [data "req/sec: 9, blocks: "] Action: Intercepted (phase 1) Apache-Handler: type-map Stopwatch: 1358698643345718 82005 (- - -) Stopwatch2: 1358698643345718 82005; combined=6000, p1=0, p2=0, p3=0, p4=0, p5=3000, sr=0, sw=3000, l=0, gc=0 Producer: ModSecurity for Apache/2.7.1 (http://www.modsecurity.org/). Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7 Engine-Mode: "ENABLED" --b41c0000-Z--
Sprječavanja XSS napada
Ako aplikacija ima dio u kojem korisnik može unositi nekakav tekst i zatim ga poslati na server, taj dio se može iskoristiti za XSS napad. Primjer takvog napada može se vidjeti na sljedećoj slici:
U polje za unos unesen se sljedeći dio koda:
<script>alert("Virus!!")</script>
Ovaj dio koda nema nikakav maliciozni dio, već samo ispisuje poruku, no moguće je umjesto ispisa obične poruke krasti cookie ili session podatke, kao još brojne druge mogućnosti koje mogu imati štetne posljedice. Da bi se aplikacija zaštitila od XSS napada koristi se pravilo oblika:
SecRule ARGS "(?i)(<script[^>]*>[\s\S]*?<\/script[^>]*>|<script[^>]*>[\s\S]*?<\/script\s\S*[\s\S]|<script[^>]*>[\s\S]*?<\/script[\s]*[\s] |<script[^>]*>[\s\S]*?<\/script| <script[^>]*>[\s\S]*?)" "id:124,phase:1,log,deny"
U ovom pravilu se kao operator koristi nešto složeniji regularni izraz u kojem se jasno može vidjeti da se sprješava unos poruke koja počinje i završava tagovima script. Ako korisnik unese dio koda dan kao u primjeru, tada će se aktivirati ovo pravilo i ispisat će se već poznata poruka "Access forbidden!" i "Error 403".
Ograničavanje veličine datoteke za upload
ModSecurity omogućuje i vrlo jednostavno ograničavanje veličine datoteka koje se uploadaju na server. Potrebna pravila već su opisana u poglavlju Request Handle. Pravila koja su korištena za ograničavanje veličine datoteke za upload su:
SecRequestBodyLimit 10000 SecRequestBodyLimitAction Reject
U prvom pravilu navedena je veličina datoteke u bajtovima koja je dopuštena za upload, a preko drugog pravila se određuje da se upload datoteka koje nadmašuju postavljenu veličinu odbacuju. Ako je datoteka koju se želi poslati na server veća od dozvoljene veličine ispisat će se pogreška kao na sljedećoj slici:
Izvorni kod
Svi izvorni kodove korišteni za izradu praktičnog dijela ovog projekta mogu se preuzeti ovdje.
Literatura
1.Službena stranica ModSecurityja, dostupno 15.1.2013.
2.Tutorijal instalacije ModSecurityja za windowse, dostupno 15.1.2013.
3.Datoteke potrebne za instalaciju, dostupno 15.1.2013.
4.ModSecurity Handbook u pdf obliku, dostupno 16.1.2013.
5.ModSecurity reference manual, dostupno 18.1.2013.
6.ModSecurity pravila, dostupno 18.1.2013.
7.ModSecurity introduction, dostupno 17.1.2013.
8.CRS Project, dostupno 16.1.2013.
9.XAMPP paket, dostupno 16.1.2013.
Podjela obaveza
Sanjin Vučković - poglavlja:5,6,7,8,9
Danijel Tot - poglavlja:1,2,3,4,8,10
