Zaštita web poslužitelja - Moduli za apache i ostali mehanizmi zaštite

Izvor: SIS Wiki
Skoči na: orijentacija, traži 
Ivan Kos Grabar | Jurica Hlevnjak

Sadržaj

Uvod

Web server, odnosno web poslužitelj, općenito označava bilo koje računalo ili uređaj na kojem se mogu nalaziti različiti podaci. Web poslužitelj najčešće služi za pohranu web stranica koje nude raznolik sadržaj, drugim riječima, kako bi neka stranica bila dostupna na internetu, potrebno ju je smjestiti na neki web poslužitelj. Kako bi se osigurala funkcionalnost samog web poslužitelja, on mora biti opremljen odgovarajućim softverom koji se brine za pravilnu razmjenu podataka između klijenata i samog poslužitelja. Osim što se pod pojmom web server, odnosno web poslužitelj, smatra računalo ili uređaj na kojem su smješteni podaci, češće se u praksi pod ovim pojmom smatra upravo softver zadužen za pravilan prikaz sadržaja i pravilnu komunikaciju između klijenta i servera. Danas se u praksi koristi dosta veliki broj web poslužitelja, no neki od najpoznatijih i najkorištenijih su:

Na sljedećoj slici, dan je grafički prikaz najviše korištenih web poslužitelja po pojedinoj regiji u svijetu, prema podacima iz kolovoza 2012. godine.

Najpopularniji web poslužitelji(Izvor:Most popular web servers by country)

Iz slike možemo uočiti kako je daleko najpopularniji web poslužitelj Apache, a slijede ga Microsoft-IIS, te Nginx. Apache web poslužitelj nalazi se na preko 60% poslužitelja, dok Microsoft-IIS i Nginx zauzimaju 16.7% te 14.3%. Detaljniji pregled statistike korištenja pojedinog web poslužitelja nalazi se na sljedećoj slici.

Postotak korištenja pojedinog web servera(Izvor:Usage of web servers for websites)

Zbog činjenice kako se na poslužiteljima nalaze različiti podaci, koji su često povjerljivi i od velike važnosti za organizaciju, pitanje sigurnosti web poslužitelja od velike je važnosti, te se njemu treba pristupiti sa velikom pažnjom. Prilikom odabira odgovarajućeg web poslužitelja, jedna od najvažnijih stavki je upravo razina sigurnosti koju web poslužitelj pruža. Danas postoji veliki broj različitih oblika napada koji predstavljaju sigurnosne prijetnje na koje je potrebno reagirati odgovarajućim mehanizmima zaštite, te će se u ovom radu obraditi načini zaštite web poslužitelja.


--Ivankos 15:30, 13. siječnja 2013. (CET)


Napadi na web poslužitelje

Zaštita web poslužitelja je lakša ukoliko znamo od čega sve se treba braniti.

Napadi na web poslužitelje su brojni i svakodnevni. Opasnosti koje prijete ovise o aplikacijama koje se nalaze na poslužitelju, o operacijskom sustavu ili npr. o konfiguraciji kompletnog sustava.

Ovdje će ukratko biti opisani najčešći, odnosno tipični napadi na web poslužitelje.

DoS napadi

DoS ili "denial of service" napad je zapravo jednostavan napad u kojem jedan sustav napada drugi s namjerom da spriječi legitimnog korisnika u korištenju usluga tog sustava na način da zauzme sve resurse koji osiguravaju te usluge.

Resursi koji se napadaju su procesor (CPU), radna memorija (RAM), disk, propusnost (bandwidth) ili povezanost na mrežu.

Posljednja dva resursa su najčešća meta. Dakle, napadom se najčešće želi postići to da računalo nema pristup mreži ili da se umanji propusnost tako da se mreža zatrpa prometom.

DoS uključuje sljedeće napade:

DDoS napadi

Razlika u odnosu na DoS napad je u tome što se kod DDoS-a za napad koriste brojna računala koja koordinirano pokreću DoS napade protiv jedne ili više meta. Koristeći klijent-server tehnologiju značajno se multiplicira učinkovitost napada. Ovakvi napadi su obično prejaki čak i za one najveće web stranice.

DDoS napadi provode se najčešće tako da automatizirane skripte traže ranjivosti i upadaju u takve ranjive sustave te ih stavljaju pod kontrolu jednog master sustava. Ti ranjivi sustavi su kompromitirani te se nazivaju zombi računala (zombies). Takva računala mogu se koristiti "po volji" za napade ili vrlo često za slanja neželjene (spam) pošte.

Na slici se nalazi prikaz scenarija ovakvog napada.

Scenarij DoS napada (Izvor:[1])


Neki od najpoznatijih DDoS napada navedeni su ispod: 

Ovaj napad, vezan uz FTP protokol, se koristi za zaobilaženje aplikacijskog vatrozida.
Napadač postavi datoteku na FTP server koja se zahtjevom šalje unutrašnjeg (internal) serveru. 
Ako datoteka sadrži maliciozni kod (npr. skripta) može okupirati resurse na internal serveru kao što su memorija ili procesor.
Napad se može spriječiti regularnim ažuriranjem FTP alata te praćenjem svih nepoznatih prijenosa datoteka na serveru. 
Rješenje  je i podešavanje vatrozida tako da filtrira sadržaj i blokira određene ekstenzije datotetka.

Skeniranje portova radi se tako da napadač koristi softver za sistematsko skeniranje ulaznih točaka računala. 
Napadač može ostvljati uznemirujuće poruke, saznati lozinke ili mijenjati konfiguracije.
Obrana od napada je stalno praćenje mreže za što postoje određeni alati.

Ping uključuje slanje signala drugom računalu očekujući odgovor na signal.
Tako se može saznati koji servisi su na tom računalu dostupni.
Ping flooding je napad koji šalje tisuće ili milijune "pingova" u sekundi što može čak dovesti i do rušenja npr. cijelog web mjesta.
Preplavljivanje se, dakle, radi tako da se na računalo žrtve šalju ping paketi.
Na ovaj napad su ranjivi brojni sustavi.

Ovaj napad je modifikacija prethodno opisanog napada. 
Razlika je u tome što se ping upit ne šalje direktno sustavu koji se napada već na broadcast adresu koja sadrži povratnu adresu žrtve.
Tako čitav niz IP adresa šalje ping zahtjeve na jedno računalo.
Zaštititi se od ovog napada može tako da se server ne koristi za broadcast prijenos. 
Ruter mora odbiti takav način prijenosa iz drugih mreža na internetu.

Napadom se iskorištava ranjivost na TCP/IP komunikacijskom protokolu.
Napadnuto računalo odgovara na zahtjeve sustava koji ne postoji.
Žrtva šalje pakete i čeka odgovor od sustava koji ima pogrešnu IP adresu.
Tako se prilikom odgovora sustav preplavi sa zahtjevima. Zahtjev čeka na odgovor dok ne istekne vrijeme (timeout).
Tijekm čekanja, sustav žrtve je zauzet trošenjem zahtjev i ne može odgovoriti na one legitimne zahtjeve.
Prilikom uspostavljanja veze, odredište prima SYN paket i šalje odgovor (SYN ACK). 
Kada se primi odgovor veza je uspostavljena. Tu se radi o TCP trostrukom rukovanju.
Ako se npr. smanji vrijeme čekanja (timeout) smanjit će se i rizik od ovog napada. 
Današnji sustavi su uglavnom otporni na ove napade. 

IP paketi mogu se smanjiti na način da se paket podijeli na više manjih paketa.
Ako su paketi dovoljno mali, ruteri kao ni intrusion detection sustavi ne mogu identificirati sadržaj paketa
te ih propuštaju dalje bez provjere. Kada paketi stignu te se na drugoj strani slože u jedan, izazvan je
buffer overflow ili preljev spremnika.
Sustav će se najvjerojatnije ponovno pokrenuti (reboot), ali postoji i vjerojatnost da neće biti nikakvog efekta.

Napadač može uspostaviti vezu s računalom žrtve i saznati slijedni broj IP paketa.
S tim brojem, napadač može kontrolirati sustav žrtve na način da uvjerava sustav da komunicira s nekim drugim sustavom.
Napad je sprječen na način da danas operacijski sustavi organiziraju te brojeve nasumično pa ih je teško predvidjeti.

Većina mrežnih uređaja poodržava SNMP protokol i obično je aktivan po default postavkama. 
Ovim napadom moguće je mapirati mrežu ili pratiti i usmjeravati promet.
Najbolji način obrane je korištenje SNMP3 protokola jer on kriptira lozinke i podatke. 
Ipak prelazak na SNMP3 nije lagan pošto gotovo svi mrežni uređaji (ruteri, hubovi, switchevi, printeri, serveri) koriste SNMP.

Pregled mogućih napada na web poslužitelje ovdje je dan ukratko jer je dobro vidjeti kakvi sve napadi postoje, odnosno što sve administratori web poslužitelja moraju uzeti u obzir prilikom instalacije i konfiguracije web poslužitelja. Ovdje nije dan pregled svih napada, već onih vrlo čestih.

Više o temi napada na web poslužitelje može se naći sljedećim linkovima:

Isto tako prilikom zaštite web poslužitelja u obzir treba uzeti i napade na web aplikacije pošto se one nalaze na web poslužiteljima, te ih se također može tretirati kao napade na sam web poslužitelj. Takvi napadi su nama dobro poznati. Riječ je naravno o SQL injection napadima, XSS (cross-site scripting) napadima i sličnim napadima. Nešto više se o tim napadima može naći na sljedećim linkovima:

Indirektni napadi

Ove napade karakterizira uzimanje informacija korisncima kao što su npr. brojevi kreditnih kartica. Korisnika se obično preusmjeri automatski na neku malicioznu web stranicu koja se čini kao dobra, tj. legitimna stranica. Na taj način mogu se ukrasti informacije o identitetu korisnika koje mogu dovesti do krađe identiteta. Uspješni napad kompromitira pouzdanost web mjesta.

Indirektni napadi javljaju se u dva oblika: 

Napadači koriste socijalni inženjering za prijevare.
Korisnika se navodi da se prijavi na lažnu stranicu te mu se uzimaju korisnički podaci.

Kompromitiraju se DNS serveri ili korisnički hostovi za preusmjeravanje korisnika na maliciozne stranice slične legitimnim.


--Jurica 18:26, 16. siječnja 2013. (CET)


Ostali problemi od kojih se se potrebno zaštititi

Danas postoje razvijeni programi koji automatski traže ranjivosti web aplikacija i web poslužitelja te su aktivni stalno. Poznato je da se od velike većine napada moguće obraniti. Ako gradimo web aplikacije, mora nam biti jasno da postoje napadi koji mogu našu aplikaciju srušiti, izmijeniti ili preuzeti. Moramo imati na umu napade koji mogu manipulirati našim podacima, tj. podacima korisnika naše web aplikacije. Napadi kao što su SQL injection, XSS i slični napadi na web aplikacije vrlo jednostavno se mogu izbjeći pravilnim programiranjem aplikacije.

Isto tako, većina napada na same web poslužitelje može se izbjeći njihovim pravilnim podešavanjem. Administratori su sami vrlo često krivi za sigurnosne propuste. Prilikom instalacije, ažuriranja ili konfiguracije, vrlo često se ostavljaju predefinirane (default) postavke. Kada su u pitanju web poslužitelji, najčešće je problem konfiguracija. Sustavi složeni po tim predefiniranim postavkama vrlo su česta meta napada.

Loše konfiguriran web server

Kako bi poslužitelj mogao odgovoriti na brojne zahtjeve istovremeno, potrebno je pokrenuti veliki broj procesa koji na te zahtjeve odgovaraju. Ako se ostave predefinrane postavke, broj zahtjeva na koje će poslužitelj odgovoriti može biti prevelik ili premali. Npr. u Apache serveru taj broj je 256, što znači da server ne može pokrenuti više od 256 procesa. Problem na koji treba paziti je i memorija s kojom treba postupati racionalno jer nije neograničena. Obično poslužitelji ne postižu ekstremne kapacitete jer je dobra praksa ograničiti broj procesa koji mogu biti pokrenuti. Ako se taj broj postavi previsoko vrlo je moguće da će se događati prekidi. Isto tako treba pažljivo konfigurirati i promet prema serveru, te pristup pojedinim direktorijima servera. Vrlo je važna i konfiguracija vatrozida. Vrlo česti su propusti upravo u navedenim slučajevima. Takvi propusti, a to su samo neki, napadačima uvelike olakšavaju posao.

Loše programirane web aplikacije

Kako danas gotovo svaka web aplikacija u pozadini ima bazu podataka ili više njih, problem nastaje upravo u komunikaciji s bazom. Ako je aplikacija loše programirana, napadač može lako doći do podataka iz baze podataka ili čak preuzeti kontrolu nad bazom, a samim time i nad aplikacijom. Ako npr. web stranica komunicira s bazom na svaki zahtjev za stranicom pa čak i onda kada to uopće nije potrebno, već postoji problem koji će napadač znati iskoristiti. Pogotovo ako se radi o web mjestu koje posjećuje veliki broj korisnika. Ovdje treba ograničiti broj upita na bazu. Ovdje vidimo da je problem najčešće u povezivanju na bazu podataka, a znamo da je to najvažniji dio aplikacije od same autentifikacije korisnika pa sve do njegove odjave sa sustava.

Iako veća web mjesta imaju baze podataka na odvojenim database serverima, loše programirane web aplikacije mogu uzrokovati probleme i web serveru i serveru baze podataka. Zaštita web aplikacija vrlo je važna u kontekstu zaštite web poslužitelja.


--Jurica 18:55, 17. siječnja 2013. (CET)


Preporuke za zaštitu web poslužitelja (NIST guidelines)

NIST ili National Institute of Standards and Technology [5] objavio je publikaciju u kojoj su navedene preporuke i savjeti vezani uz sigurnost web poslužitelja (zadnje izdanje 2007. godine).

Publikacija se može naći na sljedećem linku: NIST preporuke za zaštitu web poslužitelja

Publikacija je vrlo cijenjena te se smatra najboljom publikacijom za ovo područje. Svi koji se na neki način bave web poslužiteljima trebali bi pročitati ovu publikaciju.

Primarna namjena ovog dokumenta je pomoć organizacijama u instaliranju, konfiguraciji i održavanju web poslužitelja. Detaljnije su opisane preporuke vezane uz:

Važno je naglasiti da je dokument primarno napisan za organizacije kao što su državni odjeli i agencije na području SAD-a. Međutim, preporuke vrijede za sve sustave.

Također, preporuke vrijede i za Apache i za IIS web poslužitelj, kao i za ostale.


Planiranje i upravljanje web poslužiteljima

Planiranje osigurava da je web poslužitelj sigurniji što je više moguće. Provodi se na samom početku životnog ciklusa sustava kako bi se maksimizirala sigurnost i smanjili troškovi.

Planiranje web poslužitelja uključuje sljedeće:


Zaštita operacijskog sustava web poslužitelja

Prvi korak u zaštiti web poslužitelja je kaljenje ili očvršćivanje OS-a. Mnogi sigurnosni problemi se mogu izbjeći ako je operacijski sustav na kojem leži web poslužitelj dobro konfiguriran. Gotovo svi web poslužitelji funkcioniraju na višenamjenskim operacijskim sustavima. Predefinirane postavke postavljene od strane proizvođača nisu najbolje rješenje i problem su za sigurnost. Razlog je u tome što proizvođači o tome niti ne razmišljaju.

Preporuka je pet potrebnih koraka za održavanje OS-a sigurnim: 

1) planiranje instalacije i postavljanja OS-a i drugih komponenti na poslužitelj (računalo)
2) nadopune i ažuriranja OS-a
3) očvršćivanje i konfiguracija OS-a za adekvatnu sigurnost
4) instalacija i konfiguracija dodatnih sigurnosnih kontrola, ukoliko je to potrebno
5) testiranje OS-a za osiguranje da su prethodni koraci odrađeni dobro

Instalacija i konfiguracija OS-a

Nadopune i ažuriranja

Kad je OS instaliran, potrebno ga je ažurirati i nadograditi kako bi se ispravile sve poznate ranjivosti. Sve ranjivosti koje su poznate je potrebno ukloniti prije nego se na njega postavi web poslužitelj.

Onemogućavanje nepotrebnih servisa i aplikacija

Samo u idealnom slučaju, web poslužitelj je jednonamjenski host. Prilikom konfiguracije potrebno je onemogućiti sve osim onoga što je prijekopotrebno. Dakle, potrebno je isključiti sve servise i aplikacije, i uključiti samo one koje su potrebne web poslužitelju. Preostale je nakon toga potrebno i obrisati. Ako je moguće u nekom slučaju, dobro je instalirati minimalnu konfiguraciju OS-a i zatim isključiti navedeno.

Neke od servisa i aplikacija koje je dobro isključiti su:


Konfiguracija autentifikacije korisnika

Potrebno je limitirati broj autoriziranih korisnika koji mogu konfigurirati OS na mali broj (administratori i webmasteri).

Kako bi se osigurala primjerena autentifikacija korisnika potrebno je pratiti sljedeće korake:


Konfiguracija kontrole resursa

Pažljivim postavljanjem kontrole pristupa i odbijanjem neautoriziranog pristupa, administratori poslužitelja mogu smanjiti sigurnosne „breaches“. Ako se npr. odbije pravo čitanja datoteke može se zaštititi informacija, ako se odbije pisanje može se očuvati integritet informacija. Limitiranje prava na pokretanje programa samo na administratore može spriječiti korisnike u promjeni konfiguracija i slično.

Instalacija i konfiguracija dodatnih sigurnosnih kontrola

OS često ne uključuje sve sigurnosne kontrole, servise ili aplikacije. Stoga je potrebno odabrati, instalirati i konfigurirati dodatni softver kako bi se nadopunile nedostajuće kontrole. To su najčešće anti-malware softver, aplikacijski vatrozid, sustav za otkrivanje i prevenciju upada, softver koji ažurira drugi softver i slično.

Sigurnosno testiranje

Svako periodično testiranje je važno u identificiranju ranjivosti. Primjerene metode za testiranje OS-a uključuju skeniranje ranjivosti i penetracijska testiranja. To se obično provodi automatskim skenerima.

Penetracijsko testiranje je testiranje procesa dizajniranih za kompromitiranje mreže koristeći alate i metodologije napadača. Uključuje iterativno identificiranje i eksploataciju najslabijih područja mreže kako bi pristupilo ostatku mreže, kompromitirajući cjelokupnu sigurnost mreže.


Zaštita web poslužitelja

Zaštita web poslužitelja počela je zaštitom operacijskog sustava koji se vrti u pozadini. Kada je OS instaliran i siguran, može početi instalacija web server softvera. Instalacija se mora vršiti u okruženju u kojem nema povezanosti na mrežu (Internet). Razlog je taj što se server može kompromitirati u svega nekoliko minuta ako je povezan na mrežu, a da nije do kraja konfiguriran.

Sigurna instalacija web poslužitelja

Potrebno je instalirati samo one servise koji su potrebni web serveru. Svaka nepotrebna aplikacija, servis ili skripta mora biti uklonjena odmah.

Tijekom instalacije preporučaju se sljedeći koraci:

Konfiguracija kontrola pristupa

OS i web poslužitelj najčešće omogućuju postavljanje prava pristupa za individualne datoteke, uređaje ili druge komunikacijske resurse. Vrlo je važno postaviti ista prava kako na OS-u tako i na web poslužitelj softveru. Ono na što se posebno pazi su ograničavanje pristupa web server aplikacija podskupu računalnih resursa te ograničavanje pristupa korisnicima kroz dodatne kontrole pristupa gdje su potrebne detaljnije razine kontrole pristupa.

Kontrola pristupa može se također iskoristiti za ograničenje resursa prilikom DOS napada.

Obično se kontrola pristupa postavlja za sljedeće:

Konfiguracija dopuštenja za web aplikacije

Kada se neka aplikacija pokreće na serveru važno je da se ona pokreće samo za nekog individualnog korisnika ili za neku grupu. Novi korisnici i grupe trebaju biti nezavisni od ostalih korisnika i grupa, te jedinstveni.

Preporuke su sljedeće:

Također je važno da aplikacije ne može spremati ili čitati datoteke izvan specificirane strukture datoteka. Treba osigurati da se direktorijima i datotekama ne može pristupati izvan specificiranog stabla direktorija. Datotekama se ne smije pristupiti niti preko URL-a te datoteke.

Konfiguracija direktorija sigurnog sadržaja

Poveznice ili prečaci na direktorije koji se nalaze na serveru ne smiju postojati na javnom dijelu servera, odnosno u javnom dijelu stabla direktorija. Ako je moguće treba onemogućiti mogućnost da se prate ti linkovi. Također, log datoteke ili konfiguracijske datoteke moraju biti izvan specificiranog stabla direktorija.

Kako bi se ograničio pristup određenim direktorijima treba pratiti sljedeće korake:

URI i kolačići

URI je zanimljiv iz razloga što s njim dolazi i nekoliko sigurnosnih pitanja. Npr. URI se pamti u logovima web preglednika, proxy logovima ili HTTP povezanim logovima trećih strana. Stoga se ne preporuča sakrivanje osjetljivih podataka kao što su korisničko ime i lozinka u URI. Brojni napadači i maliciozni botovi traže osjetljive URI podatke kroz izvorni kod.

Kolačići sadrže informacije koje se mogu zapisati na korisnički disk kad korisnik posjeti stranicu. Namjena kolačića je prepoznavanje korisnika od strane servera. Poznate su ranjivosti koje su vezane uz kolačiće (cookies). Stoga kolačići ne smiju sadržavati podatke koje napadač može direktno iskoristiti.

Kontrola web botova na web poslužitelju

Web botovi (crawleri ili pauci) su aplikacije korištene za prikupljanje podataka, analizu i indeksiranje web sadržaja. Koriste se i zbog brojnih drugih namjena.

Botovi mogu biti izazov za administratore jer serveri sadrže direktorije koji ne trebaju biti indeksirani, neke stranice ne žele biti dostupne kroz tražilice, botovi mogu otkriti informacije koje su trebale ostati tajna. Ipak, moguće je utjecati na ponašanje većine botova.

Ako se želi limitirati akcije botova, potrebno je kreirati tekstualnu datoteku robots.txt u root ili admin direktoriju. To je jednostavna datoteka koja treba sadržavati neke ključne riječi i povezane informacije. Ključne riječi pokazuju botovima koje dijelove treba isključiti iz pretraživanja. Npr. ključna riječ User-agent je ime bota, a Disallow kaže botu koji dijelovi su isključeni (npr. User-agent:* Disallow:/images/ Disallow:/banners/ itd. ). Moguće je i isključiti sve botove (User-gent:* Disallow:/).


Zaštita web sadržaja

Zaštita web sadržaja je druga komponenta zaštite web poslužitelja. Prva se odnosi na zaštitu aplikacija i softvera koji se nalazi u pozadini, uključujući sam web poslužitelj softver i operacijski sustav.

Sigurnost sadržaja često se zanemaruje. Ipak važne su dvije komponente zaštite sadržaja. Prva je da se vlasnički i klasificirani podaci, te osjetljive informacije ne stavljaju kao javno dostupne na poslužitelj, ako nisu poduzete mjere zaštite (kriptiranje i autentifikacija). Druga je izbjegavanje kompromisa uzrokovanih načinom kako se sadržaj obrađuje na poslužitelju.

Objava informacija na web stranicama

Često se ne vodi briga o sadržaju koji se objavljuje na webu.

Preporuka je da se sljedeći sadržaj ne postavlja na stranice:

Provjera regulacija o prikupljanju osobnih informacija

Ovdje je nemoguće zaobići zakone kojima je propisano koje informacije se smiju prikupljati o korisnicima. Zakoni, regulacije i preporuke su važne i treba ih se držati. Preporuča se traženje savjeta od stručnjaka iz tog područja. Ako organizacija želi prikupljati podatke, mora biti svjesna promjena legalnih, regulatornih i ugovornih zahtjeva. Agencije koje prikupljaju podatke trebaju to raditi u sukladno konstituciji i zakonu.

Prihvatljiva praksa je upoznati individualca o informacijama koje se o njemu prikupljaju, uključujući opise podataka koji se prikupljaju, s kime se dijele i što će se činiti s njima. Informacije mogu biti sljedeće: ime, e-mail adresa, adresa, broj telefona, SSN, informacije o financijama.

Ublaživanje indirektnih napade na sadržaj

Indirektni napadi nisu direktni napadi na web poslužitelj ili sadržaj, već uključuju načine prikupljanja informacija od korisnika koji posjete maliciozne web stranice.

Tipovi ovih napada su phishing i pharming. O ovim napadima više se može pročitati na ovom linku

Phishing se ne može spriječiti u potpunosti tehničkim mjerama zaštite na web poslužitelju, ali neke mjere koje nisu tehničke prirode mogu smanjiti broj takvih napada:

Pharming se također može ublažiti raznim tehnikama:

Zaštita aktivnog sadržaja

Odnosi se na dinamičke web stranice sa interaktivnim elementima. Povezano je s tehnologijama kao što su ActiveX, Java, VBScript, JavaScript, AJAX.

Potrebno je posebno razmatrati zaštitu aktivnog sadržaja pošto postoje brojne ranjivosti web tehnologija na strani klijenata. Tu treba u obzir uzeti prethodno navedene tehnologije i njihove nedostatke.

Ranjivosti na strani servera se očituju u sljedećem:

Problem su tehnologije kao što su CGI, ASP.NET, PHP, Java EE i slične.

U ovom dijelu vidljivo je da se razmatra zaštita web aplikacija. Ovdje se u sve probleme pojedine tehnologije neće ulaziti.


Korištenje autentifikacijske i tehnologije kriptiranja

Koriste se brojne tehnologije za identifikaciju i autentifikaciju korisnika od kojih se neke baziraju na kriptografskim funkcijama. Kriptiranje se koristi za zaštitu informacija koje se prenose mrežom ili su pohranjene negdje. Bez kriptiranja svatko može lako saznati sadržaj poruke koja se prenosi čime se krši integritet i pouzdanost podataka.

Zahtjevi za autentifikaciju i kriptiranje

Periodički je potrebno ispitati sve informacije dostupne na poslužitelju. Za informacije koje zahtijevaju neku razinu autentifikacije, potrebno je odrediti tehnologije i metode koje će osigurati primjerenu razinu autentifikacije i enkripcije.

Autentifikacija temeljena na adresi

Najjednostavnijji mehanizam autentifikacije podržan na većini poslužitelja. Kontrola pristupa se temelji na IP adresi. Osjetljiva je na napade uključujući IP spoofing i DNS poisoning. Korištenje ove autentifikacije nije preporučljivo osim ako se radi o minimalnim sigurnosnim zahtjevima.

Osnovna autentifikacija

Koristi strukturu direktorija web poslužitelja. Za pristup datotekama istog direktorija obično su iste privilegija pristupa. Osnovna ili basic autentifikacija je podržana od standardnih preglednika te korisna za zaštitu informacija od malicioznih botova, ali za neke češće i sofisticiranije napade nije dovoljna.

Digest autentifikacija

Pojavila se u verziji 1.1 HTTP protokola. Koristi tzv. challenge-response mehanizam za autentifikaciju. Korisniku koji je pitan za korisničke podatke se šalje nonce (broj korišten samo jednom) ili neka druga vrijednost. Informacije koje korisnik unosi se sažimaju kriptografskim hash funkcijama koje koriste i nonce. Ovo štiti od sniff napada, ali i malicioznih botova.

SSL/TLS

SSL i TLS osguravaju i server i klijent autentifikaciju i enkripciju komunikacija. Više se o ovim protokolima može pročitati ovdje.

SSL i TLS dopuštaju korisniku potvrdu identiteta poslužitelja. Omogućuje klijentu standardne tehnike kriptografije. Dopušta web poslužitelju da potvrdi identitet korisnika provjeravajući certifikat. SSL/TLS imaju i nedostatke, ali su prepoznati kao najrašireniji protokoli koji osiguravaju siguran HTTPS prijenos podataka između klijenta i servera.


Implementacija sigurne mrežne infrastrukture

Mrežna infrastruktura kao podrška web poslužitelju je kritični dio sigurnosti web poslužitelja. Mrežna infrastruktura je prva linija obrane između Interneta i web poslužitelja, što naravno uvelike ovisi o konfiguraciji infrastrukture. Međutim, sama konfiguracija mreže nije dovoljna za zaštitu web poslužitelja.

U ovom dijelu razmatraju moraju se razmotriti sve one mrežne komponente koje mogu podržati i štititi web poslužitelj kao dio cjelokupne njegove sigurnosti.

Struktura i kompozicija mreže

Uređaji koji kontroliraju mrežni promet između mreža su ruteri i vatrozidi. Time oni mogu štititi web poslužitelj od ranjivosti u TCP/IP-u i time mogu smanjiti sigurnosna pitanja vezana uz nesigurne aplikacije i OS. U mnogim situacijama, kompozicija i struktura mreže je prva kritična odluka koja djeluje na sigurnost poslužitelja jer određuje kako elementi mrežne infrastrukture štite poslužitelj.

Nepreporučljivi mrežni raspored

Ako se npr. poslužitelj nalazi u unutrašnjoj produkcijskoj mreži, odnosno ako se nalazi u istoj mreži u kojoj su i unutarnji korisnici i poslužitelji, postoji glavna slabost tog rasporeda koja izlaže unutarnju mrežu i njezine komponente dodatnom riziku. Ako u ovom slučaju napadač kompromitira poslužitelj, imat će pristup cijeloj unutrašnjoj mreži. Također, ne preporuča se ni raspored u kojem se poslužitelj stavlja ispred vatrozida ili rutera koji osiguravaju IP filtriranje. U tom slučaju zaštite praktički ni nema.

Demilitarizirana zona

Demilitarizirana zona opisuje mrežni segment kao neutralnu zonu između neke mreže (npr. organizacijske mreže) i Interneta. Sprječava vanjskog korisnika u dobivanju pristupa unutrašnjoj mreži (intranetu). Ova zona umanjuje rizik lociranja web poslužitelja u unutrašnjoj mreži ili njegovog izlaganja Internetu. DMZ pruža najviše beneficija s najmanje rizika za neku organizaciju.

Postoji veći broj DMZ konfiguracija.

Stvaranje DMZ uključuje stavljanje vatrozida između graničnog rutera i unutrašnje mreže, i stvaranje novog mrežnog segmenta kojem se može pristupiti samo kroz DMZ uređaj. Web poslužitelj se nalazi na novom segmentu, zajedno s ostalim komponentama infrastrukture i poslužiteljima koji ne moraju biti dostupni izvana. Spomenuti granični ruter često može biti i osnovni vatrozid.

Sljedeća slika prikazuje primjer jednostavne DMZ koristeći ruter s listom kontrole pristupa.

Jednostavni firewall (Izvor:NIST)

DMZ kakva je prikazana iznad predstavlja pristup s malim troškovima. Nedostatak postoji u pogledu ovog graničnog rutera. Nešto bolji pristup dodaje još jedan vatrozid između Interneta i DMZ kao što je prikazano na slici ispod.

Dvostruki firewall (Izvor:NIST)

Dvostruki vatrozid povećava sigurnost jer može imati složeniji i moćniji skup sigurnosnih pravila. Ako je pristup s dva vatrozida preskup, dobro rješenje je postojanje tzv. „service leg“ DMZ. U toj konfiguraciji vatrozid ima nekoliko (npr. 3) mrežnih sučelja od kojih je jedno zakopčano na granični ruter, drugo na unutrašnju mrežu, treće na DMZ kao što se vidi na slici ispod.

Service leg DMZ (Izvor:NIST)

Prednosti DMZ sa stajališta sigurnosti:

Vanjski (outsourced) hosting

Može se donijeti odluka da se hosting web poslužitelja preda vanjskoj trećoj strane (ISP-u ili npr. vladinoj agenciji). Tako se poslužitelj neće nalaziti u mreži organizacije.

Outsourced web server hosting (Izvor:NIST)

Upravljana mreža (managed network)

Moguće je postaviti vezu između web poslužitelja i ostalih komponenti na način da veza ide kroz odvojenu mrežu poznatu kao managed network, umjesto da veza ide kroz standardnu mrežu organizacije. Ako se ta mreža koristi, svaki host koristi dodatno mrežno sučelje kojim se povezuje na tu mrežu. Isto tako, taj host neće moći slati promet između managed sučelja i bilo kojeg drugog mrežnog sučelja. Arhitektura efektivno izolira mreže. Korist se vidi u tome što se omogućuje zaštita komponenti od napada (npr. DDoS-a).

Konfiguracija mrežnih elemenata

Kada se poslužitelj smjesti na mrežu, potrebno je konfigurirati sve elemente mrežne infrastrukture. Primarni elementi su vatrozidi, ruteri, IDS i IPS (intrusion detection i prevention sustavi), switch, load balanseri i reverse proxy. Svaki element ima svoju ulogu u cjelokupnoj strategiji zaštite web poslužitelja.

Ruter/vatrozid (firewall)

Postoji više vrsta vatrozida. Npr. osnovni vatrozid je zapravo ruter koji osigurava pristup IP paketima. Najjači vatrozidi su vatrozidi aplikacijskih slojeva ili proxy vatrozidi koji mogu razumjeti i filtrirati web sadržaj. Iako se smatra da ruter i vatrozid mogu eliminirati sav rizik i zaštititi protiv miskonfiguracije web poslužitelja, to nažalost nije tako. I vatrozid i ruter su također ranjivi.

Moderni ruteri mogu se ponašati kao mrežni i transportni filteri, tj. osnovni vatrozid. Ruter može osigurati filtriranje sadržaja bazirano na sljedećem:

Snaga rutera očituje se najčešće u njegovoj cijeni.

Aplication layer vatrozidi smatraju se najsigurnijim i imaju veliki broj prednosti kao što su mogućnosti:

Intrusion detection i prevention sustavi (IDS i IPS)

To su aplikacije koje prate događaje koji se javljaju u sustavu ili mreži i analiziraju ih kao znakove potencijalnih incidenata. Oba sustava nude vrlo slične sposobnosti pa se često nazivaju IDPS. Kada takav sustav detektira potencijalni incident obavještava administratora kroz poruke putem konzole, maila, stranice ili nekog drugog mehanizma.

Dva su najvažnija tipa IDPS-a. To su host baziran i mrežno bazirani tip.

IDPS mora biti konfiguriran za:

Switch

Switch je uređaj koji osigurava vezu između dva ili više hostova lociranih na istom mrežnom segmentu. Često uključuje specifične sigurnosne postavke. Npr. vrlo često je da switch ima mogućnost minimiziranja rizika napada ARP spoofinga i ARP trovanja. Naravno, ako switch ima te mogućnosti potrebno ih je uključiti prema dokumentaciji proizvođača.

Load balancers

Distribuiraju HTTP zahtjeve kroz višestruke poslužitelje, dopuštajući povećanje kapaciteta web stranica dodavajući dodatne poslužitelje. Ponašaju se kao virtualni serveri, primajući HTTP zahtjeve na web stranice. Ono što se karakteristika je to da load balancer pokušava osigurati da svaki server prima podjednaki broj zahtjeva. Ima i mogućnost praćenja servera.

Revers proxies

To je uređaj koji se nalazi između poslužitelja i njegovog klijenta. Tok podataka je povratni za razliku od tradicionalnog (forward) proxy-ja. Može služiti kao dodatna zaštita poslužitelja. Može sadržavati sljedeće funkcionalnosti:


Administracija web poslužitelja

Nakon što je web poslužitelj u potpunosti razvijen, administratori ga moraju kontinuirano sigurno održavati. U ovom dijelu dane su preporuke za sigurnu administraciju web poslužitelja vezane uz glavne aktivnosti kao što su rukovanje i analiziranje log datoteka, izvođenje regularnih backupova (izrada sigurnosnih kopija), oporavak od kompromitiranja, regularno testiranje sigurnosti i provođenje remote administracije na siguran način.

Logovi

Bilježenje logova je temelj sigurnosni stav. Bilježenjem ispravnih podataka u log datoteke i praćenje tih zapisa je vitalno za svaki sustav. Osim osnovnih logova kao što su mrežni i sustavski, često se provode i oni dodatni.

Log zapisi osiguravaju sljedeće:

Administratori moraju pratiti sljedeće instrukcije kako bi konfigurirali i omogućili logove: 

1. Identificiranje sposobnosti bilježenje logova web poslužitelja
   - transfer log
   - error log
   - agent log
   - referrer log
2. Identificiranje dodatnih zahtjeva za bilježenje logova
3. Preporučene opće konfiguracije logova
4. Pregled i zadržavanje log datoteka
5. Alate za automatiziranu analizu log datoteka

Backup procedure

Očuvanje integriteta podataka je jedna od najvažnijih funkcija poslužitelja. Dva su osnovna principa kojih se treba držati prilikom izrade sigurnosnih kopija: regularni backup podataka i OS-a i održavanje odvojenih zaštićenih kopija sadržaja.

Strategije i police izrade sigurnosnih kopija

Kopije se izrađuju iz legalnih i financijskih razloga. Sve organizacije trebaju izraditi police sigurnosnih kopija podataka.

Tu treba uključiti utjecaj tri faktora:

Održavanje test poslužitelja

Donosi obično nove troškove, ali nudi brojne prednosti:

Održavanje autoritativne kopije web sadržaja

Svaka organizacija treba održavati kopije sadržaja web poslužitelja.

Za zaštitu i osiguravanje tih kopija treba pratiti sljedeće zahtjeve:

Oporavak od kompromitiranja

Prvi korak oporavka je izrada i dokumentiranje potrebnih polica i procedura za odgovaranje na uspješne upade prije samog upada.

Primjer koraka koje je dobro provoditi nakon otkrivanja uspješnog upada:

Sigurnosno testiranje poslužitelja

Potrebno je testove provoditi periodički. Bez periodičkih testova nema saznanja da su trenutne mjere dobre. Postoje razne tehnike testiranja. Najčešće je skeniranje ranjivosti. Penetracijsko testiranje se također široko koristi.

Preporuka je, dakle:

Remote administracija

Ovo se preporuča samo ako su pažljivo razmotreni svi rizici. Ako organizacija smatra da je potrebno remote administriranje ili promjena sadržaja, potrebno je pratiti sljedeće korake koji osiguravaju da je sadržaj postavljen na najsigurniji mogući način:

(Izvor: http://csrc.nist.gov/publications/nistpubs/800-44-ver2/SP800-44v2.pdf)

--Jurica 17:12, 17. siječnja 2013. (CET)


Zaštita Apache web poslužitelja

Apache web poslužitelj

Kao što je navedeno u uvodu, Apache web poslužitelj danas je najpopularniji web poslužitelj te se koristi za pogon velike većine servera te za rukovanje različitim web sadržajem. Apache web poslužitelj pojavio se 1995. godine, a prvu verziju je izradio Robert McCool zajedno sa svojim suradnicima, te je tako nastala prva verzija Apache HTTP poslužitelja. Nakon samog izlaska Apache web poslužitelja, njegova popularnost naglo je porasla, te je i tu popularnost zadržao i do danas. Prednosti koje su korisnici Apache web poslužitelja prepoznali su jednostavnost, efikasnost te činjenica što je Apache web poslužitelj besplatan, odnosno open source. Također, jedna od najbitnijih značajki Apache web poslužitelja, koja je ujedno i najznačajnija za njegove korisnike je razina sigurnosti koju on pruža, a ta razina sigurnosti dostignuta je konstantnim postupcima ispravaka i optimizacije, te se u pravilu, nova verzija Apache web poslužitelja izdaje samo kako bi se uklonili sigurnosni propusti, no njih je vrlo mali broj.

Apache web poslužitelj logo(Izvor:[2])

Za Apache web poslužitelj važna je i 2002. godina, kada izlazi 2.0 inačica, koja je donijela mnoga poboljšanja, a neka od tih su:


--Ivankos 15:29, 20. siječnja 2013. (CET)


Apache sigurnosni principi

Sigurnost se može definirati na razne načine.

Jedan način je definiranje sigurnosti kroz tri cilja:

Još jedan način uključuje pogled na sigurnost kroz procese koji se sastoje od faza:

Ovdje se prvenstveno ne misli na tehničku zaštitu, već onu taktičku razinu zaštite.


Osnovni sigurnosni principi

Ovo su principi koje svaka osoba koja se bavi sigurnošću mora poznavati: 

Prema principu podmornice, pregrađivanje čuva cijelu podmornicu od curenja vode u nekom dijelu.
Ako podmornica ne bi bila pregrađena, cijela podmornica bi se ispunila vodom.
Dakle, misli se na kontrolu štete. Ideja je da se cijeli dizajn sastoji od brojnih malih povezanih dijelova.

Svaki dio sustava treba imati svoje privilegije za izvođenje svog posla i nikakve druge privilegije.
Ako je jedan dio sustava kompromitiran, šteta će biti ograničena.

Ovdje se misli na postojanje višestrukih nezavisnih slojeva sigurnosti.

Informacije treba čuvati skrivene od napadača čim više je moguće i time napadaču otežati posao što je više moguće.

Ako neka komponenta sustava padne, treba osigurati da podbaci tako da se promijeni u još sigurnije stanje.
Npr. ako sustav za prijavu padne, onda treba odbiti sve moguće pokušaje prijave u sustav.

Sustav je jak koliko je jaka najslabija karika. Potrebno je razumijeti sve dijelove sustava i fokusirati se na one slabije dijelove.

Pošto se ljudi teško nose sa složenošću (7 koncepata), teško je razumijeti stvari koje su složene.
Jednostavne sustave lako je konfigurirati, provjeravati i koristiti.

Koraci sigurnosnog procesa

Ako uzmemo u obzir ona početna definiranja sigurnosti može se doći do sedam praktičnih koraka koji pokrivaju sigurnosni proces:

1. Razumijeti okolinu i sigurnosne zahtjeve

2. Uspostaviti sigurnosne police i dizajn sustava

3. Razviti operacijske procedure

4. Pažljivo konfigurirati

5. Provoditi održavanje i redovito ažurirati

6. Pratiti

7. Nositi se s napadima


Apache pogled na aplikacijsku strukturu

Osim Apache pogleda, na aplikacijsku strukturu možemo gledati s korisničkog stajališta i stajališta mreže.

Apache pogled na sustav je vrlo složen. Uključuje sve komponente koje poznajemo, ali ne razmišljamo o njima na taj način.

To su:

Sljedeća slika najbolje islustrira ove navedene komponente.

Apache pogled (Izvor: Ristić, I. Apache Security)


--Jurica 15:26, 19. siječnja 2013. (CET)


Savjeti za sigurniji Apache

Prilikom postavki Apache web poslužitelja dobro se držati nekih sugestija. Neke su općenite, dok su neke vezane upravo za Apache.

Savjeti se detaljnije mogu pročitati na web stranicama Apache poslužitelja: Apache savjeti

Ovdje je dan kraći pregled najvažnijih sigurnosnih savjeta od Apache tima: 

Apache Community stalno brine o novim sigurnosnim pitanjima, stoga se često objavljuju nove verzije i dopune.
Ipak, potrebno je ažurirati redovito i ostali softver te operacijski sustav.

Apache se pokreće kao root korisnik, i prebacuje na drugog korisnika kako je definirano u User direktivi.
Potrebno je brinuti o zaštiti pristupa od strane ne-root korisnika.
U datoteke smije pisati samo onaj tko ima root privilegiju, ali isto mora vrijediti za datoteke koje se nalaze 
u direktorijima koje su u strukturi iznad.
Ako se root direktorij poslužitelja stavi u /usr/local/apache onda je taj direktorij potrebno kreirati kao root korisnik 
na sljedeći način:

mkdir /usr/local/apache 
cd /usr/local/apache 
mkdir bin conf logs 
chown 0 . bin conf logs 
chgrp 0 . bin conf logs 
chmod 755 . bin conf logs

Ako se dopusti da neki drugi korisnik ima pristup root direktoriju sustav je već kompromitiran.

Predstavlja administratoru nekoliko potencijalnih prijetnji.
Prva je povećano opterećenje servera. Isto tako SSI ima isto rizik povezan s CGI skriptama.
Koristeći exec cmd naredbu SSI omogućava datoteci da se izvrši kao CGI skripta ili program s dopuštenjem 
korisnika ili grupe koja pokreće Apache kako je konfigurirano u httpd.conf
Za izolaciju štete koju SSI može uzrokovati potrebno je omogućiti suexec.

Prvo na pameti treba biti povjerenje u onoga tko je pisao CGI skriptu.
CGI skripte se izvršavaju kao isti korisnik, stoga imaju potencijalni sukob s ostalim skriptama.

Korisniku se smije dopustiti pokretanje CGI skripte samo ako je razmotreno sljedeće:
Ako se vjeruje korisniku da neće pisati skripte koje izlažu sustav napadima
Ako se razmotri sigurnost stranice pa je ta prijetnja nevažna
Ako nema korisnika, tj. ako nitko ne posjećuje server

Ograničenje CGI na posebne direktorije daje administratoru kontrolu nad onim što će ići u te direktorije.
Većina stranica odabire uparvo ovu opciju umjesto Non Scripting CGI pristup.

Ugrađene opcije skripti koje se pokreću kao dio servera kao što su mod_php, mod_perl, mod_tcl i slične,
pokreću se pod identitetom samog servera pa mogu pristupiti svemu onome čemu i server sam može pristupiti.

Potrebno je spriječiti korisnike u postavljanju .httacces datoteke koja može zaobići sigurnosne postavke.
To se može učiniti na sljedeći način postavljanjem naredbe u config datoteku:

<Directory /> 
AllowOverride None 
</Directory>

Default pristup se često ne razumije. Ako se ne promijene te postavke, server može naći način da dođe
do datoteke kroz URL mapping pravila i njima poslužiti klijenta.
Kako bi spriječili da klijent izlista sadržaj kompletnog servera potrebno je dodati u config sljedeće:

<Directory /> 
Order Deny,Allow 
Deny from all 
</Directory>

Ovo brani pristup filesystem lokaciji.
Ako pak se želi dati pristup samo nekim područjima potrebno je dodati ovo:

<Directory /usr/users/*/public_html> 
Order Deny,Allow 
Allow from all 
</Directory> 
<Directory /usr/local/httpd> 
Order Deny,Allow 
Allow from all 
</Directory>


U logovima se moraju naći sve informacije o svemu što se događalo u sustavu.
Primjer:

grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log 
grep "client denied" error_log | tail -n 10

Naredba izlistava broj napada koji su htjeli eksploatirati Apache Tomcat Source.

Log datoteka prikazuje samo ono što se već dogodilo.

(Izvor: http://httpd.apache.org/docs/2.2/misc/security_tips.html)

--Jurica 14:29, 19. siječnja 2013. (CET)


Moduli za Apache

Apache obuhvaća brojne Multi-Processing module koji otpremaju podatke na obradu dretvama ili procesima. Brojni dodatni moduli su dostupni za proširenje funkcionalnosti samog Apache poslužitelja. Broj modula danas je negdje oko 540.

Ovdje će biti opisani moduli Apache poslužitelja vezani uz sigurnost ovog web poslužitelja.

mod_access

mod_access ili access_module osigurava kontrolu pristupa baziranu na klijentovom imenu (hostname), IP adresi ili nekoj drugoj karkteristici zahtjeva kojeg klijent šalje serveru.

Direktive (smjernice) koje osigurava ovaj modul koriste se u <Directory>,<Files> i <Location> sekciji kao i u .htaccess datoteci za kontrolu pristupa pojedinim dijelovima poslužitelja.

Pristup se može kontrolirati na temelju klijentovog imena, IP adrese ili karakteristike njegovog zahtjeva koje se bilježe u environment varijablama (varijable okoline).

Direktive koje se koriste su:

Allow i Deny smjernice se koriste kako bi se specificiralo koji klijent može, a koji ne može pristupiti poslužitelju. Order smjernica postavlja default stanje pristupa i konfigurira kako Allow i Deny smjernice međusobno djeluju jedna s drugom.

Općenito, zabrana pristupa se primjenjuje na sve metode pristupa (GET, PUT, POST). Ipak, moguće je ograničiti neke metode, a druge dopustiti. Te metode stavljaju se onda u <Limit> sekciju.

Allow smjernica

Kontrolira koji host možee pristupiti nekom području poslužitelja.

Sintaksa je sljedeća:

Allow from all|host|env=env-variable [host|env=env-variable]

Prvi argument je uvijek from. Allow from all dopušta pristup svima. Ako se želi specificirati samo neki korisnik ili grupa, tada se može koristiti neki od ovih formata:

Allow from apache.org

Allow from .hr example.edu

Allow from 10.1.2.3

Allow from 192.168.1.104 192.168.1.205

Allow from 10.1

Allow from 10 172.20 192.168.2

Allow from 10.1.0.0/255.255.0.0

Allow from 10.1.0.0/16

Za IPv6 se također može specificirati na sljedeći način:

Allow from 2001:db8::a00:20ff:fea7:ccea

Allow from 2001:db8::a00:20ff:fea7:ccea/10


Deny smjernica

Kontrolira koji hostovi nemaju pristup poslužitelju prema imenu hosta, IP adresi ili varijabli okoline.

Sintaksa je sljedeća:

Deny from all|host|env=env-variable [host|env=env-variable]

Argumenti smjernice jednaki su argumentima Allow smjernice.


Order smjernica

Kontrolira predefinirano stanje pristupa i uređuje kako su Allow i Deny procijenjeni.

Sintaksa:

Order ordering (Allow,Deny; Deny,Allow ili Mutual-failure)

Order Deny,Allow

Primjer:

Order Allow,Deny

Allow from apache.org

Deny from foo.apache.org


(Izvor: http://httpd.apache.org/docs/2.0/mod/mod_access.html)


--Jurica 18:42, 19. siječnja 2013. (CET)


mod_auth

Modul služi za autentifikaciju koristeći tekstualne datoteke. Modul dopušta korištenje HTTP osnovne autentifikacije za ograničavanje pristupa na način da provjerava korisnika u plain text password i group datotekama. Slične funkcionalnosti ima i mod_auth_dbm i mod_auth_digest. 

Smjernicom se postavlja kako je autorizacija  i autentifikacija proslijeđena modulima nižih razina.
Sintaksa: AuthAuthoritative On|Off
Ako se vrijednost postavi na Off tada se dopušta da se autentifikacija i autorizacija proslijede na module niže razine.

Postavlja ime tekst datoteke koja sadrži listu grupa korisnika za autentifikaciju.
Sintaksa: AuthGroupFile file-path
File-path je putanja do datoteke grupe. Ako nije apsolutna, tretira se kao relativna.
Primjer: mygroup: bob joe anne

Postavlja naziv tekst datoteke koja sadrži listu korisnika i lozinki za autentifikaciju.
Sintaksa: AuthUserFile file-path

(Izvor: http://httpd.apache.org/docs/2.0/mod/mod_auth.html ovdje)


--Jurica 18:54, 19. siječnja 2013. (CET)


mod_cband

Ukoliko postoji potreba za ograničavanjem mrežnog prometa, odnosno mrežne propusnosti, modul cband za Apache web poslužitelj dolazi do izražaja. Osnovna namjena cband modula je ograničavanje mrežne propusnosti prema korisnicima i virtualnim hostovima (eng. virtual host). Pojam virtualni host, označava praksu kod koje se na jednom uređaju, odnosno poslužitelju nalazi više web mjesta, pa tako svako web mjesto koje se nalazi na tom poslužitelju, može se razlikovati prema IP adresi, ili prema imenu, odnosno web mjesto može biti IP-Based ili name-base. Više o virtual host-u se nalazi na sljedećem linku, Apache Virtual Host documentation. Upotrebom modula cband, mogu se postavljati ograničenja prema virtualnim hostovima, te korisnicima u obliku dodijeljenih kvota vezanih uz mrežnu propusnost, zatim najveću brzinu downloada, najveći broj istovremenih zahtjeva sa različitih IP adresa.

Značajke Apache modula cband:

Što se tiče same instalacije modula cband, ona je poprilično jednostavna te se sastoji od nekoliko koraka. Prvi korak kod instalacije modula na Linux okruženju je njegovo preuzimanje, modul cband preuzet je sa adrese prikazane ispod. 

wget http://dembol.org/downloads/cband/mod-cband-0.9.7.5.tgz

Modul dolazi u obliku tar arhive te ga je potrebno raspakirati. 

tar -xzf mod-cband-0.9.7.5.tgz

Nakon raspakiravanja, unutar direktorija u kojem je raspakiran modul potrebno je pokrenuti instalaciju. 

cd mod-cband-0.9.7.5
./configure
make
make install

Nakon završene instalacije potrebno je restartati Apache kako bi se pohranile promjene. 

/etc/apache2/restart

Sljedeći primjer prikazuje na koji način se može ograničiti promet nad nekoliko virtualnih hostova. Potrebno je kreirati pravilo kojim se kasnije mogu povezivati virtualni hostovi, u ovom primjeru to je myUser. 

<CBandUser myUser>
    # 100Mb limit, 10 tjedana
    CBandUserLimit 100Mi
    CBandUserPeriod 10W
    # datoteka u koju se zapisuje bandwidth po hostu
    CBandUserScoreboard /somewhere/user.myUser.scoreboard
</CBandUser>
    #nad svakim virtualnim hostom primjenjuje se myUser
<VirtualHost firstvhost>
    ...
    CBandUser myUser
<VirtualHost>
<VirtualHost secondvhost>
    ...
    CBandUser myUser
</VirtualHost>


Primjer kako ograničiti bandwidth određenoj IP adresi je prikazan ispod. Prvi korak kod ograničavanja bandwidtha je da se definira skup, odnosno klasa koja sadrži sve IP adrese kojima se ograničava propusnost 

<CBandClass myClass>
    CBandClassDst IP1
    CBandClassDst IP2/mask
    CBandClassDst IP3
    ....
</CBandClass>

Zatim se nad tom stvorenom klasom IP adresa mogu stavljati različita pravila, odnosno ograničenja. 

<VirtualHost>
    ...
    # limit prometa od 1GB, na period od 4 tjedna
    CBandClassLimit myClass 1G
    CBandPeriod 4W
</VirtualHost>

Nešto više o modulu cband nalazi se na sljedećim linkovima, cband Documentation, cband FAQ. Vrlo sličan modul cbandu, je i modul bandwidth, odnosno mod_bandwidth. Njegova namjena je prilično slična kao i namjena mod_cband, dakle, mod_bandwidth omogućava postavljanje limita, odnosno ograničenja bandwidtha ili propusnosti prema serveru ili prema korisnicnima. Na sljedećim linkovima nalazi se više informacija o samom mod_bandwidthu kao i njegova instalacija i konfiguracija, Setup and configure bandwidth limiting, mod_bandwidth.

(Izvor: http://dembol.org/blog/mod_cband/documentation/)

--Ivankos 19:55, 19. siječnja 2013. (CET)


mod_chroot

Ovaj modul omogućuje pokretanje Apache poslužitelja u sigurnoj chroot okolini. Ovaj modul uključen je u neke linux distribucije kao što su FreeBSD, Gentoo Linux, NetBSD, PLD Linux itd.

chroot mijenja root direktorij procesa u neki direktorij koji nije "/". To znači da se proces zaključa unutar nekog virtualnog file system root-a. Ako se chroot konfigurira dobro, Apache procesi i svi procesi djeca uključujući CGI skripte neće moći pristupiti ničemu osim onog što je u tom kontejneru ili zatvoru (jail). Ne root procesi ne mogu napustiti chroot jail.

Ako se koristi mod_chroot tada se Apache može smjestiti u "zatvor" bez dodatnih datoteka. Međutim, pokretanje Apache poslužitelja u tom zatvorenom kontejneru može biti problematično.

mod_chroot može se uključiti u Apache pomoću sljedećih naredbi u Linux okruženju: 

./configure --add-module /usr/src/mod_chroot-x.y/src/apache13/mod_chroot.c

make && make install

apachectl start

(Izvor: http://core.segfault.pl/~hobbit/mod_chroot/)


--Jurica 19:31, 19. siječnja 2013. (CET)


mod_ssl

Modul ssl za Apache web poslužitelj služi za uspostavljanje sigurne veze upotrebom kriptografije putem SSL(Secure Socket Layer) protokola. Modul ssl pojavio se 1998. godine za Apache verziju 1.3., dok se izlaskom verzije 2.0., modul ssl nalazi kao dio Apache web poslužitelja. Secure Socket Layer protokol koristi se za obavljanje sigurnih transakcija preko interneta. Njegova osnovna namjena je osigurati zaštićeni prijenos podataka između klijenta i servera. SSL je danas jedan od najšire korištenih protokola koji nudi privatnost i pouzdanost kod komunikacije između klijenta i servera. Uz pomoć kriptografskih algoritama i ključeva između dvije komunikacijske strane, uspostavlja enkripcijski kanal kroz koji ostali protokoli poput HTTP mogu obavljati svoj dio posla. Kao dodatna značajka SSL protokola, javlja se autentifikacija svih strana komunikacijskog kanala pomoću certifikata. SSL protokol se sastoji od nekoliko slojeva:

Prema TCP/IP mrežnom modelu, SSL protokol se nalazi u aplikacijskom sloju, što je i prikazano na slici ispod. Osim osiguravanja spomenutog HTTP protokola, za kojega je i inicijalno bio namijenjen, SSL se koristi i za osiguravanje SMTP, POP, IMAP, te FTP protokola.

SSL protokol u TCP/IP modelu(Izvor:[3])

SSL protokol u osnovi uključuje identifikaciju servera, identifikaciju klijenta te kriptiranu razmjenu podataka između klijenta i servera, a tu razmjenu ostvaruje preko prije spomenutih tehnika kriptiranja. U osnovi svaka SSL konekcija odnosno veza ostvaruje se u dva koraka ili faze, handshake faza, i data-exchange faza. SSL protokol u osnovi uključuje identifikaciju servera, identifikaciju klijenta te kriptiranu razmjenu podataka između klijenta i servera, a tu razmjenu ostvaruje preko prije spomenutih tehnika kriptiranja. U osnovi svaka SSL konekcija odnosno veza ostvaruje se u dva koraka ili faze, handshake faza, i data-exchange faza.

Deataljniji prikaz komunikacije putem SSL protokola prikazan je na sljedećoj slici.

Način uspostavljanja veze kod SSL protokola(Izvor:[4])

Iz slike možemo vidjeti kako klijent uspostavlja vezu sa serverom putem handshake postupka, te razmjenu ključeva i certifikata. Nakon uspostavljanja veze, odnosno uspješnog handshakinga ili rukovanja, do izražaja dolazi Record layer SSL protokola u kojem se svi podaci koji se razmjenjuju kriptiraju dogovorenim algoritmom. Važan dio SSL-a je i njegov SSL Alert Protocol koji, ukoliko dođe do nekakve greške javlja upozorenje. Koliko je sigurna veza, odnosno sjednica uspostavljena SSL protokolom ovisi o mogućnostima klijenta i servera, te ukoliko server podržava 128-bitne ključeve, dok klijent podržava samo 40-bitne ključeve, veza ili sjednica će biti ostvarena putem 40-bitnog ključa.

Modul ssl sadrži veliki broj direktiva čiji kompletan popis se nalazi na http://httpd.apache.org/docs/2.2/mod/mod_ssl.html. Također, mod_ssl se može konfigurirati na način da može implementirati mnoge značajke SSL protokola putem različith varijabli. Neke od tih varijabli su:

Najjednostavnija konfiguracija mod_ssl-a sastoji se od sljedećih direktiva: 

# omogućavanje SSL
SSLEngine On
# definiranje lokacije certifikata od servera
SSLCertificateFile /usr/local/apache/conf/ssl/server.crt
# definiranje lokacije privatnog ključa servera
SSLCertificateKeyFile /usr/local/apache/conf/ssl/server.key

(Izvor: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html)

--Ivankos 20:59, 19. siječnja 2013. (CET)


mod_filter

mod_filter za Apache web poslužitelj omogućava pametnu konfiguraciju koja je sposobna prepoznati određeni izlazni sadržaj. Koristeći ovaj modul, Apache može biti konfiguriran na način da obrađuje različite vrste sadržaja preko različitih filtera, te može i obraditi sadržaj nepoznate vrste. mod_filter, web administratorima omogućava fleksibilnost u stvaranju lanca filtriranja Smjernice, odnosno direktive ovog modula su sljedeće:

Postoje tri koraka kod konfiguracije lanca filtriranja: 

Pomoću FilterDeclare smjernice deklarira se filter, dodjeljuje mu se ime te tip filtera


Smjernica FilterProvider registrira tzv. ''providera'' sa filterom. Ukoliko filter nije deklariran sa FilterDeclare, dodjeljuje mu
se defaultni tip. Zadnji argument kojega FilterProvider prima je izraz, koji omogućava provideru izvršavanja zahtjeva, samo ukoliko
je taj izraz ispravan.


Prethodne dvije smjernice potrebne su za izgradnju lanca filtriranja, ali za njegov pravilan rad potrebna je smjernica FilterChain,
koja je zadužena za konstrukciju lanca filtriranja od prethodno deklariranih pametnih filtara, također ova smjernica 
omogućava fleksibilnost ubacivanja filtera na kraj ili početak lanca, te brisanje filtera.

(Izvor: http://httpd.apache.org/docs/2.4/mod/mod_filter.html linku)

mod_ratelimit

Apache modul mod_ratelimit služi kao filter za limitiranje klijentu mreženu propusnost, odnosno bandwidth. Brzina konekcije definira se u KiB/s, pomoću varijable rate_limit. Primjer konfiguracije pomoću mod_ratelimit: 

<Location /downloads>
    SetOutputFilter RATE_LIMIT
    SetEnv rate-limit 400 
</Location>

(Izvor: http://httpd.apache.org/docs/2.4/mod/mod_ratelimit.html)

mod_limits

Apache modul mod_limits ima dvije osnovne namjene, da limitira najveći broj istovremenih ostvarenih konekcija, te da server odbija zahtjev ukoliko je opterećenje iznad neke određene granice. Primjer upotrebe mod_limits, gdje se ograničava broj konekcija sa IP adresa, te dopušteno preopterećenje: 

<IfModule mod_limits.c>
LimitMaxConnsPerUid 20
LimitMaxConnsPerIP 30
LimitMaxLoadAVG 10
CheckLoadInterval 5
</IfModule>

(Izvor: https://github.com/hackman/mod_limits)

mod_suexec

Apache modul mod_suexec omogućava izvršavanje CGI skripta određenom korisniku ili grupi korisnika. mod_suexec zajedno sa suexec programom se koristi za izvršavanje spomenutih CGI skripti. Sintaksa mod_suexec: 

SuexecUserGroup User Group

mod_suexec sadrži smjernicu SuexecUserGroup koja omogućava definiranje korisnika ili grupe korisnika za izvršavanje određenih CGI skripti. Primjer upotrebe mod_suexec: 

SuexecUserGroup nobody nogroup

(Izvor: http://httpd.apache.org/docs/2.2/mod/mod_suexec.html)

mod_log_config

Modul mod_log_config omogućava evidenciju i bilježenje svih zahtjeva prema poslužitelju. Omogućava fleksibilnu evidenciju svih zahtjeva sa strane klijenta, odnosno evidenciju korisničkih zahtjeva. Bilješke se mogu zapisivati u prilagodljivom formatu, te se mogu zapisivati direktno u datoteku ili na neki vanjski program. Smjernice, odnosno direktive ovog modula su:

TransferLog se koristi za stvaranje datoteke dnevnika, odnosno log datoteke, LogFormat se koristi za postavljanje prilagođenog formata, te CustomLog za definiranje log datoteke i formata. BufferedLogs se koristi kada se se zapisi prvo spremaju u radnu memoriju, a zatim se zapisuju na tvrdi disk, čime se ne mora nakon svakog zahtjeva izvršavati zapisivanje u dnevnik i spremanje na disk. Ovakvim načinom bilježenje zahtjeva, učinkovitije se koristi disk, te se povećavaju performanse.

(Izvor: http://httpd.apache.org/docs/2.4/mod/mod_log_config.html)

mod_log_forensic

mod_log_forensic omogućava forenzičko bilježenje klijentskih zahtjeva prema serveru. Bilježenje, odnosno logiranje, se obavlja prije i poslije obrade zahtjeva, pa tako forenzički dnevnik sadrži dva retka za svaki zahtjev prema serveru, također format zapisa u dnevnik je fiksan, što znači da se nakon zapisa on ne može mijenjati. Zapisivanje u dnevnik prvi put se provodi prije daljnje obrade zahtjeva, a drugi put nakon obrade zahtjeva u isto vrijeme u kojem bi se u dnevnik bilježio zapis kod normalnog logiranja. ForensicLog smjernica zadužena je za zapisivanje zahtjeva prema serveru za forenzičku analizu. Sintaksa ForensicLog direktive: 

ForensicLog filename|pipe

Svaki zapis u dnevnik dobiva jedinstveni ID preko kojega se može povezati određeni zahtjev koristeći CustomLog direktivu. Argumenti koje ForensicLog prima su ime datoteke na koju se zapisuje, te vanjski program koji prihvaća zabilješke o zahtjevima.

(Izvor: http://httpd.apache.org/docs/2.4/mod/mod_log_forensic.html)


--Ivankos 21:00, 19. siječnja 2013. (CET)


Ostali mehanizmi zaštite

Apache u "zatvoru"

Koliko god se trudili zaštiti neki sustav, upadi i u najzaštićeniji sustav su mogući. Ukoliko napadač uspije probiti mehanizme zaštite, njegova namjena je pronaći što više ranjivosti te postati superuser korisnik, te na taj način imati nesmetan pristup i kontrolu nad poslužiteljem. Cilj jail mehanizma zaštite je, ukoliko dođe do upada u sustav, ograničiti napadaču pristup određenim dijelovima sustava, te ga zadržati u samo određenom dijelu sustava u kojem ne može prouzrokavati značajniju štetu. Blokiranje napadača ostvaruje se sistemskim pozivom chroot, koji omogućava postavljanje restrikcija na različite procese, te se tako limitira pristup tog procesa određenim datotečnim sustavima. chroot funkcionira na način da odabere direktorij koji postaje novi root datotečnog sustava. Nakon izvršavanja sistemskog poziva chroot nad procesom, proces se ne može vratiti u prethodno stanje, odnosno on se nalazi u 'zatvoru', jail. Implementiranjem jail mehanizma u web server pruža mnogo prednosti, a neke od njih su:

Sljedeći primjer prikazuje kako uz pomoć chroot staviti Apache u 'zatvor'. Prvi korak je da se kreira novi home direktorij za Apache te se Apache premjesti u tu novu lokaciju. 

# mkdir -p /chroot/apache/usr/local
# mv /usr/local/apache /chroot/apache/usr/local
# ln -s /chroot/apache/usr/local/apache /usr/local/apache
# mkdir -p /chroot/apache/var
# mv /var/www /chroot/apache/var/
# ln -s /chroot/apache/var/www /var/www

Razlog zbog kojega se Apache kopira u novi direktorij je da se mogu upotrebljavati obje verzije Apache-a, 'slobodna' i 'zatvorena'. Za ispravan rad, Apache-u su potrebne biblioteke, pa se uz pomoć ldd alata može dobiti popis tih biblioteka. 

# ldd /chroot/apache/usr/local/apache/bin/httpd
        libm.so.6 => /lib/tls/libm.so.6 (0x005e7000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x00623000)
        libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x00902000)
        libexpat.so.0 => /usr/lib/libexpat.so.0 (0x00930000)
        libdl.so.2 => /lib/libdl.so.2 (0x0060b000)
        libc.so.6 => /lib/tls/libc.so.6 (0x004ac000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00494000)

Kopije ovih biblioteka potrebno je staviti u 'zatvor'. 

# mkdir /chroot/apache/lib
# cp /lib/tls/libm.so.6 /chroot/apache/lib
# cp /lib/libcrypt.so.1 /chroot/apache/lib
# cp /usr/lib/libgdbm.so.2 /chroot/apache/lib
# cp /usr/lib/libexpat.so.0 /chroot/apache/lib
# cp /lib/libdl.so.2 /chroot/apache/lib
# cp /lib/tls/libc.so.6 /chroot/apache/lib
# cp /lib/ld-linux.so.2 /chroot/apache/lib

Sljedeći koraci obuhvaćaju način na koji se korisnici, grupe korisnika i datoteke stavljaju u 'zatvor'. Defaultni korisnik httpd ne postoji u jail okruženju, pa i jail mora sadržavati njegove autentifikacijske sadržaje. 

# mkdir /chroot/apache/etc
# cp /etc/nsswitch.conf /chroot/apache/etc/
# cp /lib/libnss_files.so.2 /chroot/apache/lib

Kako bi Apache funkcionirao u jail okruženju, potrebne su neke dodatne datoteke kako bi se omogućilo raspoznavanje imena domena. 

# cp /lib/libnss_dns.so.2 /chroot/apache/lib
# cp /etc/hosts /chroot/apache/etc
# cp /etc/resolv.conf /chroot/apache/etc

Ovim postupkom Apache se nalazi u jail okruženju.

Sljedeći primjer prikazuje kako konfigurirati PHP za pravilan rad unutar jail okruženja. Prvi korak je normalna instalacija PHP-a, te je zatim potrebno napraviti listu dijeljenih biblioteka te ih kopirati u jail okruženje. 

# ldd /chroot/apache/usr/local/apache/libexec/libphp4.so
       libcrypt.so.1 => /lib/libcrypt.so.1 (0x006ef000)
       libresolv.so.2 => /lib/libresolv.so.2 (0x00b28000)
       libm.so.6 => /lib/tls/libm.so.6 (0x00111000)
       libdl.so.2 => /lib/libdl.so.2 (0x00472000)
       libnsl.so.1 => /lib/libnsl.so.1 (0x00f67000)
       libc.so.6 => /lib/tls/libc.so.6 (0x001df000)
       /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00494000)

Ukoliko se neke biblioteke nalaze već u jail okruženju, kopiraju se samo one koje nedostaju, u ovom primjeru one su boldane. 

# cp /lib/libresolv.so.2 /chroot/apache/lib
# cp /lib/libnsl.so.1 /chroot/apache/lib

Ovime je PHP konfiguriran da radi u jail okruženju.

(Izvor: Ristić I. Apache Security)

--Ivankos 17:31, 20. siječnja 2013. (CET)


Sustavi za otkrivanje upada (intrusion detection)

Sustavi za otkrivanje neovlaštenih upada(IDS - Intrusion Detection System) danas predstavljaju jednu od najvažnijih komponenti sigurnosnog sustava. Upravo zbog tog razloga treba voditi računa o izradi sigurnosnih mehanizama koji onemogućavaju neovlašteni pristup računalnim resursima i podacima. No, potpuno sprječavanje neovlaštenog pristupa ponekad nije moguće izvesti. Današnji sigurnosni sustavi pokušavaju pravovremeno detektirati takve napade, te samim time i pravovremeno poduzeti potrebne akcije sprječavanja neovlaštenog pristupa.


Mod Security (mod_sec)

Mod Security, odnosno mod_sec, jedan je od najpoznatijih modula za Apache web poslužitelj. Njegova osnovna namjena je da djeluje kao zaštitni mehanizam za detekciju i prevenciju neovlaštenih aktivnosti koje su usmjerene prema web aplikacijama, kao i na web poslužitelj. Mod Security funkcionira kao integrirani dio web poslužitelja, a neke od njegovih najvažnijih značajki su:

Postupak instalacije Mod Security modula razlikuje se ovisno o odabranoj platformi, te o inačici Apache web poslužitelja. mod_sec radi na 1.3.x te na 2.x inačicama Apache web poslužitelja te je kompatibilan sa obje verzije. ModSecurity moguće je dohvatiti u obliku izvornog koda(tar arhiva), ili kao izvršnu datoteku sa adrese http://www.modsecurity.org/download/. Preporučena instalacija ModSecurity je preko izvornog koda, jer time se osigurava instalacija najnovije verzije, kao i eventualne izmjene kod instalacije od strane korisnika, no jednostavnija i bržža opcija je instalacija preko izvršne datoteke. Za instalaciju ModSecurity potrebno je zadovoljiti neke uvjete. Uz pretpostavku kako je Apache web poslužitelj već instaliran, kao i modul mod_unique_id potrebno je instalirati dodatne biblioteke libpcre(biblioteka koja sadrži skup funkcija za regularne izraze), libxml2(biblioteka za XML obradu), libcurl(služi za udaljeno bilježenje logova,remote logging). Također, opcionalna biblioteka koja se preporuča je liblua, koja služi za kreiranje složenijih pravila pomoću Lua skriptnog jezika.

Na Debian i Ubuntu distribucijama instalacija preko izvršne datoteke moguća je preko jedne naredbe: 

# apt-get install libapache-mod-security

Pomoću ove naredbe, ModSecurity paket se downloada te instalira, i aktivira se modul u Apache konfiguracijskoj datoteci.

Instalacija na Windows okruženju također je prilično jednostavna, nakon downloada odgovarajućeg paketa, potrebno je kopirati dinamičke biblioteke u mapu modules, zatim je potrebno modificirati konfiguraciju Apache web servera kako bi se aktivirao ModSecurity: 

LoadModule security2_module modules/mod_security2.so

Također, kako bi ModSecurity pravilno funkcionirao na Windows okruženju potrebno je aktivirati mod_unique_id, potrebno je u konfiguraciju Apache-a dodati: 

LoadModule unique_id_module modules/mod_unique_id.so

Nakon instalacije ModSecurity potrebno ga je pravilno podesiti kako bi on pravilno funkcionirao.

Konfiguracijske direktive

ModSecurity koristi poveći broj direktiva, te će ovdje biti navedene samo neke od njih. Konfiguracija ModSecurity obavlja se preko konfiguracijske datoteke httpd.conf, te ga je potrebno u toj datoteci uključiti kako bi ga Apache mogao koristiti. ModSecurity se uključuje pomoću IfModule direktive: 

IfModule mod security.c>
   #popis pravila
   ...
/IfModule>

Prema početnim postavkama, mnoge opcije ModSecurity su onemogućene, pa ih je potrebno omogućiti i podesiti.

Uključivanje filtriranja prometa obavlja se preko sljedeće direktive: 

SecFilterEngine On

Vrijednosti koje SecFilterEngine parametri mogu imati su: 

On - analiza svih dolazećih zahtjeva
Off - analiza zahtjeva isključena, ne analizira se niti jedan zahtjev
DynamicOnly - analiziraju se zahtjevi koji su generirani dinamički za vrijeme izvođenja

Provjera POST sadržaja

Provjera sadržaja koji se prosljeđuje serveru preko POST metode također je isključena prilikom inicijalne instalacije, te ju je potrebno uključiti odgovarajućom direktivom. POST metodom se prosljeđuju vrijednosti koje upisuju korisnici putem web formi, a i na ovaj način se provodi većina napada, pa se svakako preporuča uključiti provjeru POST sadržaja putem direktive: 

SecFilterScanPost On

Nasljeđivanje filtera

U Apache web poslužitelju poddirektoriji nasljeđuju pravila filtriranja od nadređenih direktorija, ovakav pristup je vrl čest, no postoje situacije u kojima je potrebno definirati drugačija pravila filtriranja, pa se u tom slučaja nasljeđivanje sigurnosnih postavki iz nadređenog direktorija onemogućava sljedećom direktivom: 

<Location /web/direktorij>
   SecFilterInheritance Off
</Location>

Provjera URL kodiranja

Za korištenje specijalnih znakova unutar URL adrese, HTTP dozvoljava prikazivanje znakova u heksadecimalnom obliku, u tom slučaju znakovi se prikazuju u obliku %XY, gdje su X i Y znakovi od A do F u heksadecimalnom obliku. No, često se javlja slučaj da napadači koriste druge znakove kako bi zaobišli sigurnosne mehanizme. Upravo zbog tog razloga, ModSecurity provjerava sve podržane tipove kodiranja kako bi se osiguralo da su svi upiti pravilno kodirani, te se ta provjera ispravnosti kodiranja URL niza uključuje pomoću direktive: 

SecFilterCheckURLEncoding On

Za modul ModSecurity postoji opširna i detaljna dokumentacija, koja pokriva sve aspekte ovog vrlo korisnog modula. Na sljedećim linkovima može se pronaći više informacija o samom modulu:


(Izvor: http://www.modsecurity.org/)

--Ivankos 14:34, 20. siječnja 2013. (CET)


OSSEC

OSSEC [6] je besplatan, open source sustav za otkrivanje upada (intrusion detection system). Sustav omogućuje analize logova, provjeru integriteta datoteka, praćenje polica, otkrivanje rootkita, real-time obavještavanje i aktivno odgovaranje.

OSSEC radi na gotovo svim operacijskim sustavima (Linux, MacOS, Solaris, Windows, OpenBSD...).

Prednost mu je što ima centraliziranu arhitekturu koja mu omogućuje praćenje i upravljanje višestrukim sustavima.

Autor OSSEC-a je Daniel B. Cid, a objavio ga je 2004. godine.

Kako OSSEC funkcionira

OSSEC se sastoji od brojnih dijelova. Ima centralni Manager koji prati sve i prima informacije od agenata, sysloga, baze i agentnih uređaja.

Manager koji je glavni dio, pohranjuje sljedeće:

Agent je manji program instaliran u sustav koji se želi pratiti. Prikuplja informacije u realnom vremenu te ih prosljeđuje Manageru na analizu.

Moguće je instalirati i sustav bez agenta u slučaju da ga sustav ne podržava, ali i dalje ostaje mogućnost izvođenja nekih operacija.

OSSEC je moguće instalirati unutar virtualne mašine te daje vrlo korisne informacije o svemu što se na njoj događa.

Također, sustav može prihvaćati podatke za analizu s brojnih uređaja kao što su vatrozidi, switchevi, ruteri i slično.

Instalacija i pokretanje

Na Linux sustavima instalacija se provodi u svega par koraka.

Prije instalacije potrebno je skinuti posljednju verziju i po mogućnosti provjeriti sažetak. 

# wget http://www.ossec.net/files/ossec-hids-2.6.tar.gz
# wget http://www.ossec.net/files/ossec-hids-2.6_checksum.txt
# cat ossec-hids-2.6_checksum.txt
MD5 (ossec-hids-2.6.tar.gz) = f4140ecf25724b8e6bdcaceaf735138a
SHA1 (ossec-hids-2.6.tar.gz) = 258b9a24936e6b61e0478b638e8a3bfd3882d91e
# md5sum ossec-hids-2.6.tar.gz
MD5 (ossec-hids-2.6.tar.gz) = f4140ecf25724b8e6bdcaceaf735138a
# sha1sum ossec-hids-2.6.tar.gz
SHA1 (ossec-hids-2.6.tar.gz) = 258b9a24936e6b61e0478b638e8a3bfd3882d91e

Zatim treba napraviti extract paketa i pokrenuti ./install.sh 

# tar -zxvf ossec-hids-*.tar.gz (or gunzip -d; tar -xvf)
# cd ossec-hids-*
# ./install.sh

i naravno pokrenuti OSSEC naredbom 

# /var/ossec/bin/ossec-control start


(Izvor: http://www.ossec.net/)

--Jurica 23:13, 19. siječnja 2013. (CET)


Praktični dio >> Sigurna instalacija i konfiguracija Apache Web Servera

U dosadašnjem dijelu rada mogu se vidjeti načini zaštite web poslužitelja od čestih napada. Jedno od važnijih dijelova su preporuke za zaštitu web poslužitelja koje se mogu primijeniti na sve web poslužitelje. Zaštita poslužitelja počinje planiranjem. Nakon toga kreće se s osiguravanjem operacijskog sustava na kojem će se pokretati web poslužitelj. Zatim slijedi zaštita samog poslužitelja, zaštita mrežne infrastrukture pa zaštita sadržaja i sigurna administracija.

Dakle prije same instalacije i konfiguracije poslužitelja potrebno je ranije učiniti nekoliko koraka.

Zbog praktičnosti izvedbe i dostupnih resursa za ovaj dio rada krenut ćemo s pretpostavkom da su ti koraci napravljeni, te počinjemo s korakom zaštite web poslužitelja (Apache poslužitelj), čemu prethodi njegova sigurna instalacija i konfiguracija.

Dakle, ovdje će biti prikazano kako instalirati i konfigurirati web poslužitelj Apache na što je moguće sigurniji način, od samog preuzimanja paketa, instalacije i konfiguracije te instalacije i konfiguracije dodatnih modula kao što su mod_ssl, mod_cband, mod_security, koji su opisani iznad.


Instalacija

Postupak instalacije

Instalacija je prvi korak koji se provodi kako bi naš poslužitelj bio funkcionalan. Naravno prije same instalacije potreban nam je instalacijski paket koji se lako može skinuti s web stranica Apache poslužitelja.

Prvo pitanje na koje se može pojaviti je instalacija poslužitelja iz izvornog koda ili koristeći binarni paket.

Ako se odlučimo za korak u kojem je prvo potrebno kompajlirati izvorni kod, možemo imati potpunu kontrolu iako postupak traje puno duže vrijeme. Instalacija iz binarnih paketa je vrlo često jednostavna, ali tu su česti problem predefinirane postavke.

Ovdje će biti prikazan ovaj prvi način instalacije. Dakle, potrebno je skinuti izvorni kod. 

$ wget http://archive.apache.org/dist/httpd/httpd-2.4.3.tar.gz

Ako želimo biti dosljedni u provođenju sigurnosnih mjera, provjerit ćemo integritet paketa kojeg smo skinuli uz pomoć MD5 ili SHA1, ili još složeniji pristup korištenjem kriptografije javnog ključa što se može učiniti uz pomoć PGP-a.

Ako se koristi npr. MD5, potrebno je s Apache web stranice (na ovoj stranici su sve distribucije uključujući i sažetke i ključeve) skinuti MD5 sažetak i usporediti s izračunatim sažetkom paketa kojeg smo skinuli.

Sljedećom naredbom izračunavamo sažetak paketa kojeg smo skinuli prethodno: 

$ md5sum httpd-2.4.3.tar.gz 
538dccd22dd18466fff3ec7948495417  httpd-2.4.3.tar.gz

Naredba ispod skida i prikazuje sadržaj MD5 sume sa stranice Apache poslužitelja: 

$ wget -O - -q http://archive.apache.org/dist/httpd/httpd-2.4.3.tar.gz.md5
538dccd22dd18466fff3ec7948495417 *httpd-2.4.3.tar.gz

Sume naravno moraju biti identične, inače je paket koji smo skinuli ranije kompromitiran.


Ako želimo koristiti PGP, odnosno kompleksniju provjeru, treba učiniti sljedeće: 

$ wget http://archive.apache.org/dist/httpd/httpd-2.4.3.tar.gz.asc

Ako ovdje želimo provjeriti potpis, od nas će se tražiti ključ. 

$ gpg httpd-2.4.3.tar.gz.asc

Ovdje će se u ovom slučaju pojaviti poruka da nema ključa.

Ključ možemo dobiti uz pomoć naredbe: 

$ gpg --keyserver pgpkeys.mit.edu --recv-key DE885DD3

Kad se naredba izvrši, pojavi se poruka da je ključ uspješno importan.

Ako sada provjerimo potpis s naredbom 

$ gpg httpd-2.4.3.tar.gz.asc

dobit ćemo željeni rezultat.

Mi smo za našu potrebu iskoristili MD5 funkciju za provjeru integriteta preuzetog paketa.


Nakon ovog koraka možemo biti sigurni da imamo dobar paket Apache poslužitelja.

Dodatno je moguće provjeriti na web stranicama poslužitelja postoje li kakvi dodatni patchevi.

Sljedeće što nas čeka je odabir između stvaranja jedinstvene statične biblioteke ili kompajliranje koristeći dinamičko učitavanje modula. Danas razlika između ovih pristupa gotovo da ne dolazi do izražaja.


Prije nego pokrenemo instalaciju, potrebno je provjeriti da je Apache svjestan okoline.

Naravno potrebno je napraviti extract skinutog paketa 

$ gzip -d httpd-2.4.3.tar.gz
$ tar xvf httpd-2.4.3.tar
$ cd httpd-2.4.3

te obaviti provjeru sljedećom naredbom 

$ ./configure --prefix=/PREFIX

PREFIX = filesystem putanja unutar koje bi server trebao biti instaliran, default vrijednost je najčešće /usr/local/apache

Configure skripta istraži sustav i kreira Makefile, te je moguće pokrenuti proces (mogu se javiti problemi s bibliotekom APR koju je potrebno dodatno instalirati, a upute se mogu pronaći u readme.txt) 

$ make
# make install

$ vi PREFIX/conf/httpd.conf
$ PREFIX/bin/apachectl -k start
# /usr/local/apache/bin/apachectl start

Ove naredbe instaliraju Apache te ga pokreću. Nakon toga dobro je konfigurirati operacijski sustav tako da se Apache pokrene prilikom pokretanja sustava.

Za moguće probleme ili dodatne upute najbolje je pogledati ovdje.


Provjera instalacije

Jednostavno, otvorimo naš web preglednik i u URL ukucamo localhost ili 127.0.0.1. Ako se dobije poruka da je Apache uspješno instaliran onda je sve prošlo u redu.

Kako bi se u to uvjerili, mi smo učinili isto te dobili sljedeće:


Početna stranica

Također možemo pogledati koji Apache procesi su pokrenuti 

$ ps -Ao user,pid,ppid,cmd | grep httpd
// ispis

Instalacija modula

Zajedno s Apache poslužiteljem instalira se tek manji broj modula. Kako bi osigurali naš poslužitelj što je više moguće, instalirat ćemo module koji su spomenuti na početku. Ovdje također treba biti oprezan, jer nije dobro instaliravati module koji nam nisu potrebni.

Vrlo lako možemo provjeriti koji moduli su instalirani naredbom 

$ ./configure --help

Modul koji pored sebe ima oznaku yes aktiviran je po defaultu.

Koristeći naredbe --enable-module i --disable-module određujemo koji moduli će biti aktivirani, a koji ne. 

$ ./configure \
> --prefix=/usr/local/apache \
> --enable-module=rewrite \
> --enable-module=so \
> --disable-module=imap \
> --disable-module=userdir

Za pogled na cijelu listu predefinirano aktiviranih modula možemo ukucati naredbu 

$ ./httpd -l

Ako želimo promijeniti default listu modula treba nam sljedeća naredba: 

$ ./configure \
> --prefix=/usr/local/apache \
> --enable-rewrite \
> --enable-so \
> --disable-imap \
> --disable-userdir


Kao što je rečeno, kako bi osigurali dodatno Apache instalirat ćemo ove module: mod_cband, mod_ssl i mod_security.

Kako instalirati mod_cband već je ranije opisano.

Prvo je potrebno skinuti modul naredbom: 

$ wget http://dembol.org/downloads/cband/mod-cband-0.9.7.5.tgz

i raspakirati naredbom 

$ tar -xzf mod-cband-0.9.7.5.tgz

Nakon raspakiravanja pokreću se sljedeće naredbe: 

$ cd mod-cband-0.9.7.5
$ ./configure
$ make
$ make install

Kako bi modul mogao funkcionirati potrebno je ponovno pokrenuti Apache poslužitelj.

Naravno, da bi ovim modulom mogli štiti poslužitelj od npr. DoS napada potrebno je u datoteci httpd.conf podesiti određene parametre o čemu se više može pročitati u dijelu Konfiguracija.


Što se tiče ssl modula, on je u većini slučaja instaliran po defaultu. Ipak, vrlo lako ga se može instalirati pomoću sljedeće naredbe: 

# sudo a2enmod ssl

Naravno, nakon toga potrebno je ponovno pokrenuti Apache, a kako bi se uvjerili da je modul instaliran i da radi može se iskoristiti sljedeće: 

$ apache2ctl -t -D DUMP_MODULES | grep ssl

Naredba bi trebala vratiti sljedeće: 

# ssl_module (shared)
#(The module is loaded.)


Mod Security koji je opisan ranije vrlo je koristan alat za Apache poslužitelj (i ostale). Modul predstavlja sustav za otkrivanje upada što je vrlo važno u zaštiti poslužitelja.

Ovaj modul se vrlo lako može instalirati na svaki Linux sustav, pa tako i ovaj koji mi koristimo, Ubuntu 12.4.

Prije same instalacije modula potrebno je bilo instalirati neke biblioteke: 

$ sudo apt-get install libxml2 libxml2-dev libxml2-utils
$ sudo apt-get install libaprutil1 libaprutil1-dev

Sam Security mod instaliramo uz pomoć ove naredbe: 

$ sudo apt-get install libapache-mod-security

Ono što je također dobro napraviti je uključiti OWASP Core Rule Set za Mod Security, te u njega uključiti neke postavke koje OWASP preporučuje, a nalaze se u datoteci modsecurity_crs_10_setup.conf.example.

To se može učiniti na sljedeći način: 

$ cd /tmp
$ sudo wget http://downloads.sourceforge.net/project/mod-security/modsecurity-crs/0-CURRENT/modsecurity-crs_2.2.5.tar.gz
$ sudo tar -zxvf modsecurity-crs_2.2.5.tar.gz
$ sudo cp -R modsecurity-crs_2.2.5/* /etc/modsecurity/
$ sudo rm modsecurity-crs_2.2.5.tar.gz
$ sudo rm -R modsecurity-crs_2.2.5
$ sudo mv /etc/modsecurity/modsecurity_crs_10_setup.conf.example  /etc/modsecurity/modsecurity_crs_10_setup.conf

Za kraj je također dobro provjeriti uspješnost instalacije 

$ sudo a2enmod headers
$ sudo a2enmod mod-security

i ponovno pokrenuti Apache.

Uz ovaj modul obično je potrebno instalirati i mod_evasive. Ovo je vrlo koristan modul koji osigurava potrebne akcije u slučaju DoS, DDoS ili Brute Force napada. 

$ sudo apt-get install libapache2-mod-evasive

Osim toga potrebno je kreirati i njegovu konfiguracijsku datoteku, provjeriti instalaciju i ponovno pokrenuti Apache. 

$ sudo vi /etc/apache2/mods-available/mod-evasive.conf
$ sudo a2enmod mod-evasive


Za kraj instalacije ovdje je priložen jedan video u kojem je prikazano kako je na vrlo lagan i brz način moguće konfigurirati neke osnovne postavke Apache poslužitelja: video.


Sama instalacija kao u slučaju bilo kojeg drugog modula nije dovoljna. Potrebno je naravno u konfiguracijskim datotekama podesiti one elemente koji su nam potrebni.

(Izvori: apache.org; Ristić I. Apache Security)

Konfiguracija

Nakon što je naša instalacija u potpunosti gotova, potrebno je učiniti Apache poslužitelj još sigurnijim.

Konfiguracija se provodi u datoteci koja ima nastavak .conf (obično je to httpd.conf datoteka).

U našem slučaju ova datoteka se nalazi na sljedećoj putanji: /usr/local/apache2/conf/httpd.conf

Ako pogledamo malo bolje tu datoteku, vidimo da je prepuna raznih konfiguracija, a ponajviše ima komentara. Datoteka je nepregledna na prvi pogled i predefinirano u sebi sadrži puno stvari koje nam zapravo ni ne trebaju.


Datoteka httpd.conf


Stoga, dobra praksa je da datoteku ispraznimo i krenemo od početka, tj. hrabro od prazne konfiguracijske datoteke. Najbolje je držati tu datoteku urednom, kratkom i jasnom.

Za početak u httpd.conf potrebno je upisati nekoliko direktiva opće namjene: 

# lokacija datoteka web servera
ServerRoot /usr/local/apache
# lokacija direktorija stabla web servera
DocumentRoot /var/www/htdocs
# put do PID(Process ID) datoteke u kojoj je pohranjen PID glavnog Apache procesa
PidFile /var/www/logs/httpd.pid
# port na kojem osluškuje
Listen 80
# onemogućavanje pretvorbe klijentskih IP adresu u imena 
HostNameLookups Off

Postavljanje korisničkog računa na serveru

Nakon instalacije, Apache je pokrenut kao korisnik nobody. Ovakav korisnički račun je uobičajen na Unix operacijskim sustavima, no dobra praksa je kreirati odvojeni korisnički račun za svaki pojedinačni zadatak. Ovaj način rada je koristan, ukoliko dođe do napada na poslužitelj u kojem napadač preuzima privilegije i prava određenog korisničkog računa.

Najčešće korišteno korisničko ime je httpd, ali se koristi i apache. Za kreiranje računa potrebno je izvršiti sljedeće naredbe(kao root): 

#groupadd httpd
# useradd httpd -g httpd -d /dev/null -s /sbin/nologin

Pomoću ovih naredbi kreira se grupa i korisnički račun, te se računu dodjeljuje home direktorij /dev/null i shell /sbin/nologin(čime se onemogućava login za račun). Na kraju je potrebno dodati sljedeće linije u httpd.conf: 

User httpd
Group httpd

Postavljanje dozvola za izvršavanje Apache binary datoteka

Apache se izvršava preko porta 80, te on mora biti pokrenut kao root. Ukoliko se dopusti bilo kojem drugom korisničkom računu da mijenja httpd binary datoteku, taj račun bi mogao dobiti dozvole za izvršavanje bilo koje datoteke kao root. Iz ovoga se može uočiti koliki sigurnosni rizik ovaj propust predstavlja, ukoliko ga napadač iskoristi. Zbog gore navedenog razloga, root se mora konfigurirati na način da samo on ima dozvolu pisanja, odnosno write: 

# chown -R root:root /usr/local/apache
# find /usr/local/apache -type d | xargs chmod 755
# find /usr/local/apache -type f | xargs chmod 644

Podešavanje zadanih postavki

Ukoliko dođe do greške koja može slučajno otkriti važne sistemske datoteke, potrebno je zabraniti pristup cjelokupnom datotečnom sustavu i nakon toga dopustiti pristup root dokumentu na način da se u httpd.conf datoteku ubace sljedeće direktive: 

<Directory />
    Order Deny,Allow
    Deny from all
</Directory>
<Directory /var/www/htdocs>
    Order Allow,Deny
    Allow from all
</Directory>
Options direktiva

Gore spomenuti način zaštite ne štiti posve od netočno ili zlonamjerno postavljenih simboličnih linkova izvan direktorija var/www/htdocs. Korisnici sustav mogli bi kreirati simbolične linkove do resura čiji oni nisu vlasnici. Kontrola simboličnih linkova i druge kontrole pristupa datotekama kontroliraju se preko Options directive unutar <Directive> direktive. Options direktiva može imati jednu ili više sljedećih vrijednosti: 

All - prikaz svih opcija
None - niti jedna opcija nije omogućena
ExecCGI - omogućava izvršavanje CGI skripti
FollowSymLinks - omogućava pristup simboličnim linkovima
Includes - dozvoljava server-side uključenja
IncludesNOEXEC - dozvoljava SSI,ali ne dozvoljava exec naredbu koja se koristi za izvršavanje vanjskih skripti
Indexes - dozvoljava serveru da generira listu datoteka u direktoriju kada zadana indeksna datoteka nedostaje
MultiViews - dozvoljava pregovaranje o sadržaju, content negotiation
SymLinksIfOwnerMatch - dozvoljava pristup simboličnim linkovima ako je vlasnik linka isti kao i vlasnik resursa na koji link
                       pokazuje

Direktiva Options -FollowSymlinks onemogućuje upotrebu simboličnih linkova u Apache-u. Znak - ispred imena opcije pokazuje Apache-u da zadrži postojeću konfiguraciju i onemogući navedenu opciju. Isto tako, znak + znači dodavanje opcije u konfiguraciju.

AllowOveride direktiva

Prema zadanim postavkama dozvoljava pojedinim dijelovima konfiguracijskih podataka da budu smješteni unutar stabla direktorija web servera, u datotekama koje se nazivaju .htaccess. Konfiguracijski podaci koji se nalaze unutar te datoteke mogu nadjačati podatke unutar httpd.conf datoteke. Ovakav način može znatno usporiti rad servera, te može omogućiti bilo kome tko ima kontrolu nad stablom direktorija, limitiranu kontrolu nad serverom. Ova značajka se kontrolira putem AllowOverride direktive, koja se također pojavljuje unutar <Directive> direktive, koja specificira direktorij za koji se opcija odnosi. AllowOverride directiva podržava sljedeće opcije: 

AuthConfig - omogućava korištenje(unutar .htacces datoteke) autorizacijskih direktiva
FileInfo - omogućava korištenje direktiva vezanih uz kontroliranje tipova dokumenata
Indexes - omogućava korištenje direktiva vezanih uz kontroliranje indeksiranja direktorija
Limit - omogućava korištenje direktiva vezanih uz kontroliranje pristupa host-u
Options - omogućava korištenje direktiva vezanih uz kontroliranje specifičnih funkcija direktorija(Options, XbitHack direktive)
All - dozvoljava sve opcije
None - ignorira .htacces konfiguracijsku datoteku

Za zadanu konfiguraciju odabrana je None opcija, pa prema tome <Directory> direktive su: 

<Directory />
    Order Deny,Allow
    Deny from all
    Options None
    AllowOverride None
</Directory>
   
<Directory /var/www/htdocs>
    Order Allow,Deny
    Allow from all
</Directory>

Omogućavanje CGI skripti

Omogućavanje CGI skripta se preporuča samo ukoliko su one nužne. U tom slučaju, kao dobra praksa, ističe se grupiranje svih skripti u jedan direktorij koji najčešće nosi naziv cgi-bin. Na taj način možemo znati koje skripte se izvršavaju na serveru. Kako bi se dozvolilo izvršavanje CGI skripti u nekom direktoriju, u ovom slučaju /var/www/cgi-bin, potrebno je u httpd.conf dodati: 

<Directory /var/www/cgi-bin>
    Options ExecCGI
    SetHandler cgi-script
</Directory>

Bilježenje aktivnosti(logging)

Vrlo važan čimbenik zaštite je zapisivanje svih aktivnosti na serveru u dnevnik. Postoje dvije vrste dnevnika, acces log, koji služi za zapisivanje svih zahtjeva prema serveru. Pomoću direktive LogFormat, definira se format zapisa u dnevnik, a zatim pomoću CustomLog direktive kreira se access dnevnik u tom formatu: 

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\
          "" combined
CustomLog /var/www/logs/access_log combined

Sljedeći dnevnik je error log, te se u njega bilježe sve sistemske aktivnosti, poput kada se web server pokrenuo i zaustavio, kao i sve eventualne pogreške nastale tijekom obrade zahtjeva. Primjer česte greške je greška koja se generira kada klijent zatraži neki nepostojeći resurs, tada HTTP generira pogrešku pod kodom 404, te se u tom slučaju bilježi aktivnost u access log te greška u error log. Za definiranje error log-a potrebne su direktive LogLevel i ErrorLog, gdje ErrorLog kreira stvarni dnevnik: 

LogLevel info
ErrorLog /var/www/logs/error_log

Postavljanje konfiguracijskih limita na serveru

Slabo ili nepravilno podešeni limiti na serveru mogu server učiniti lakom metom za različite napade. Sljedeća konfiguracijska direktiva prikazuje zadanu(defaultnu) konfiguraciju vrijednosti Apache-a te se definira koliko dugo server čeka na sporog klijenta: 

# čekaj do 300 sekundi sporije klijente
TimeOut 300
# dozvoli ponovnu upotrebu veze između zahtjeva 
KeepAlive On
# dozvoli maksimalno 100 zahtjeva po konekciji 
MaxKeepAliveRequests 100
# čekaj do 15 sekundi do sljedećeg 
# zahtjeva na otvorenu vezu 
KeepAliveTimeout 15

Defaultna, zadana vrijednost za timeout konekcije, odnosno prestanak konekcije je 300 sekundi, što je dosta dugo čekanje. Timeout se može postaviti na 60 sekundi i time se znatno povećava tolerancija prema DoS napadima. Sljedeće direktive nameću limite na različite aspekte jednog HTTP zahtjeva: 

# ne nameće se nikakav limit na zahtjev
LimitRequestBody 0
# dozvoli do 100 zaglavlja u zahtjevu
LimitRequestFields 100
# svako zaglavlje može biti dužine do 8190 bitova
LimitRequestFieldsize 8190
# prva linija zahtjeva može biti
# dužine do 8190 bitova 
LimitRequestLine 8190
# limitiraj XML zahtjev do milijun bitova(Apache 2.x)
LimitXMLRequestBody 1000000

Sprječavanje curenja informacija(information leaks)

Svaka informacija o serveru koja je na bilo koji način dostupna, omogućava napadačima izvšavanje različitih napada. Primjer odavanje informacija javlja se kod instalacijskog procesa, gdje se automatski stavlja email adresa korisnika koji kompilira Apache u konfiguracijski datoteku. Na taj način korisnički račun se otkriva javnosti, što predstavlja rizik. Sljedeća direktiva služi za zamjenu generirane adresa od strane Apache-a sa generičkom adresom: 

ServerAdmin webmaster@apachesecurity.net

Prema početnim postavkama, email adresa definirana ovom direktivom pojavljuje se na stranicama generiranim od strane servera, ukoliko to ne želimo, ova opcija se isključuje pomoću direktive: 

ServerSignature Off

HTTP protokol definira povratno polje zaglavlja pod nazivom server, čija namjena je identifikacija softvera koji odgovara na zahtjev. Prema početnim postavkama, Apache ovo polje popunjava sa imenom, verzijom, te imenima i verzijama svih modula. Primjer kako to izgleda na testnom zahtjevu: 

$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD / HTTP/1.0
   
HTTP/1.1 200 OK
Date: Fri, 19 Mar 2004 22:05:35 GMT
Server: Apache/1.3.29 (Unix)
Content-Location: index.html.en
Vary: negotiate,accept-language,accept-charset
TCN: choice
Last-Modified: Fri, 04 May 2001 00:00:38 GMT
ETag: "4002c7-5b0-3af1f126;405a21d7"
Accept-Ranges: bytes
Content-Length: 1456
Connection: close
Content-Type: text/html
Content-Language: en
Expires: Fri, 19 Mar 2004 22:05:35 GMT

Ovo polje zaglavlja otkriva neke potencijalno korisne informacije napadačima, pa se pomoću sljedeće direktive dozvoljava samo prikaz imena servera: 

ServerTokens ProductOnly

Još jedan problem koji se javlja je automatsko indeksiranje direktorija, a on može prouzročiti nenamjerno otkrivanje različitih datoteka, pa se preporuča isključivanje automatskog indeksiranja, te konfiguriranje Apache-a na način da odbija sve zahtjeve koji odgovaraju nizu regularnih izraza. Sljedeća direktiva služi za traženje različitih datotečnih ekstenzija koje nebi smjele biti prisutne na web serveru: 

<FilesMatch "(^\.ht|~$|\.bak$|\.BAK$)">
    Order Allow,Deny    
    Deny from all
</FilesMatch>

FilesMatch direktiva gleda samo posljednji dio cijelog imena datoteke,odnosno ekstenziju, pa prema tome FilesMatch konfiguracijske specifikacije se ne mogu primijeniti na imena direktorija. Kako bi se u cijelosti ograničio pristup određenom direktoriju, na primjer pristup CVS administrativnim datotekama, to se može na ovaj način: 

<DirectoryMatch /CVS/>
    Order Allow,Deny
    Deny from all
</DirectoryMatch>

(Izvori: apache.org; Ristić I. Apache Security)

--Jurica 21:49, 20. siječnja 2013. (CET) | --Ivankos 21:53, 20. siječnja 2013. (CET)

Literatura

1.Ristić I.(2005). Apache Security

2.Gelbmann M.(2012). Most popular web servers by country, dostupno na http://w3techs.com/blog/entry/most_popular_web_servers_by_country

3.W3Techs.com(2012). Usage of web servers for websites, dostupno na http://w3techs.com/technologies/overview/web_server/all

4.Kargl F., Maier J., Weber M.(2001). Protecting Web Servers from Distributed Denial of Service Attacks, dostupno na http://www.princeton.edu/~rblee/ELE572Papers/p514-kargl.pdf

5.TechiWarehouse(2004). Types of Attacks on Web Servers, dostupno na http://www.techiwarehouse.com/engine/21b0d480/Types-of-Attacks-on-Web-Servers

6.Oryano S.P.(2009). Securing a Web server, dostupno na http://www.ibm.com/developerworks/web/library/wa-secureweb/

7.Tracy M., Jansen W., Scarfone K., Winograd T.(2007). Guidelines on Securing Public Web Servers, dostupno na http://csrc.nist.gov/publications/nistpubs/800-44-ver2/SP800-44v2.pdf

8.Trustwave Holdings Inc., ModSecurity® Reference Manual, dostupno na http://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual#ModSecurity.C2.AE_Reference_Manual

9.Carnet,Mod security modul, dostupno na http://www.cis.hr/www.edicija/LinkedDocuments/CCERT-PUBDOC-2004-02-63.pdf

10.Carnet(2008). Usporedba sigurnosnih rizika poslužitelja Apache i IIS, dostupno na http://www.cert.hr/sites/default/files/CCERT-PUBDOC-2008-09-239.pdf

11.ModSecurity Handbook, dostupno na https://www.feistyduck.com/books/modsecurity-handbook/

12.http://en.wikipedia.org/wiki/Web_application_security

13.https://www.owasp.org/index.php/Category:Attack

14.Phishing and pharming Information Site, dostupno na http://www.pharming-phishing.com/

15.What is TLS/SSL?, dostupno na http://technet.microsoft.com/en-us/library/cc784450%28v=ws.10%29.aspx

16.Security tips, dostupno na http://httpd.apache.org/docs/2.2/misc/security_tips.html

17.Kargl, Maier, Weber. Protecting Web Servers from Distributed Denial of Service Attacks. Princeton. Dostupno na http://www.princeton.edu/~rblee/ELE572Papers/p514-kargl.pdf

18.Guidelines on Securing Public Web Servers. NIST. Dostupno na http://csrc.nist.gov/publications/nistpubs/800-44-ver2/SP800-44v2.pdf

19.Apache Module Index. Dostupno na http://httpd.apache.org/docs/2.0/mod/

20.OSSEC. Dostupno na http://www.ossec.net/

Zaduženja članova tima

Ovdje je ukratko navedeno što je koji član tima radio, iako je ispod svakog poglavlja to naznačeno.


Ivan Kos Grabar


Jurica Hlevnjak


siječanj 2013. | Ivan Kos Grabar | Jurica Hlevnjak

Dobavljeno iz "https://security.foi.hr/wiki/index.php/Za%C5%A1tita_web_poslu%C5%BEitelja_-_Moduli_za_apache_i_ostali_mehanizmi_za%C5%A1tite"
Osobni alati
Imenski prostori
Inačice
Radnje
Orijentacija
Traka s alatima