Jak jste se již měli možnost dozvědět v úvodním díle na téma nebezpečné webhostingy, rozdíl mezi freehostingem a placenou variantou spočívá pouze v nabízeném prostoru, dostupnosti, podpoře a podobných kritériích, nikoliv však v samotné konfiguraci, která jako jediná přímo ovlivňuje integritu sdílených dat. Považovat komerční webhosting za vhodnější volbu a předpokládat, že jsme si za bezpečnost zaplatili, by bylo značně naivní. Pojďme se nyní společně podívat na to, jak by takový bezpečně nakonfigurovaný server určený pro mass virtual hosting mohl vypadat.
Role bezpečnostního analytika v případě provádění penetračních testů a potencionálního útočníka v případě skutečného napadení se v podstatě nikterak neliší. Útok vždy probíhá z pozice jednoho řádového zákazníka a jeho úspěšnost se přímo odvíjí od schopnosti dané osoby interpretovat množství konfiguračních direktiv, a dojde-li k nalezení nedostatku, této chyby využít, případně zkombinovat s jinou mezerou nebo mezerami v systému. V případě freehostingu je pro útočníka situace nepatrně jednodušší, neboť se za zřízení účtu nic neplatí a konto je okamžitě připraveno k použití. U komerčních hostingů je nutné si buď za prostor zaplatit, nebo se domluvit se správcem serveru na odzkoušení webové prezentace zdarma. Většinou se stačí zmínit o specifickém a tudíž poněkud náročnějším systému a postěžovat si na současný server. Takřka každá webhostingová společnost vám vyjde vstříc (některé dokonce nabízejí odzkoušení i oficiálně), útočník však na sebe v tomto případě zbytečně přitahuje pozornost, a tudíž není běžnou praxí uvedené možnosti zneužívat k protiprávnímu jednání. Komerční hostingy mají, co se bezpečnosti týče, ještě jednu nepatrnou výhodu, a tou jsou tarify, které povětšinou běží na různých serverech. Pokud chce totiž útočník napadnout konkrétní prezentaci, pak si musí zjistit (případně odhadnout), který z tarifů daný web pravděpodobně využívá, a objednat si totožný. V opačném případě riskuje, že se ocitne na úplně jiném serveru než je kýžená prezentace a útok nebude moci provést.
V současnosti nejcennější komoditou není zdaleka zlato, platina nebo ropa, nýbrž informace a ani ve světě hackingu tomu není jinak. Získávání informací je první fází jakéhokoliv útoku a v případě webhostingů mají navíc útočníci situaci poněkud usnadněnou, neboť PHP, tedy dynamický skriptovací jazyk, jimž je vybavena drtivá většina jak tuzemských, tak zahraničních webhostingů, disponuje nenápadnou funkcí phpinfo(), která se při svém zavolání beze všeho podělí o kompletní konfiguraci PHP procesoru. A právě výstup této funkce je cenným zdrojem informací jak pro samotné zákazníky webhostingu, tak pro případné útočníky, kteří chtějí data cizích uživatelů kompromitovat.
Nenechte se ale mýlit, výstup funkce phpinfo() není ničím tajným a často se s ním setkáte už při výběru samotného webhostingu, kdy je na něj odkazováno v přehledu jednotlivých tarifů. Jen výjimečně správce serveru tuto funkci zakáže v naději, že tak zabrání útokům, což však v žádném případě není řešení. Omezí tak pouze regulérní uživatele a zkušenější útočník si potřebné informace obstará jiným, i když zdlouhavějším způsobem. Mnohé konfigurační direktivy totiž disponují vlastní funkcí pro detekci aktuálního stavu a v neposlední řadě lze ke zjištění konfigurace zavolat funkci ini_get() s potřebnými parametry.
Bezpečnost sdílených serverů samozřejmě netkví pouze v konfiguračních direktivách dynamického jazyka, dává nám však k dispozici nejvíce indicií k rozeznání bezpečné konfigurace od té nebezpečné ještě před tím, než si za prostor na daném serveru zaplatíme. Podívejme se proto nyní společně na výstup funkce phpinfo() a seznamme se s důležitými direktivami, které by pro nás měly být jakýmsi vodítkem při výběru bezpečného webhostingu.
Funkce phpinfo() sice vypadá nenápadně, její výstup však vzbuzuje obdiv, přinejmenším co se obsáhlosti a přehledného zpracování týče. První, čeho si asi každý všimne, je titulek informující o používané verzi PHP. Setkáte se buď se 4. nebo 5. verzí, přičemž ta čtvrtá již není nadále vyvíjena. Jak známo, z chyb se člověk učí, máte-li tedy tu možnost, doporučuji vždy volit verzi co možná nejaktuálnější (v případě čtvrté verze nese definitivně poslední vydání označení 4.4.9 a v případě páté verze lze aktuální označení najít na oficiálních stránkách vývojového týmu).
Níže, v poli System, pak nalezneme informace o používaném operačním systému (dominuje GNU/Linux), verzi kernelu, architekturu apod. Zde nás zajímá především verze jádra, která by měla být pokud možno vyšší než 2.6.24.1. Pokud tomu tak není a útočníkovi se podaří získat přístup k shellu (příkazové řádce), byť i s omezenými pravomocemi, pomocí volně dostupného lokálního exploitu velice snadno dosáhne eskalace práv a získá postavení správce systému (root), což s sebou přináší naprostou kontrolu nad celým serverem a pro ostatní uživatele fatální následky.
Vyznáte-li se alespoň trochu v Linuxu, pak zajisté víte, že aplikace lze instalovat buď přímo ze zdrojových kódů, nebo pomocí binárních balíčků, v lepším případě pak jsou standardní součástí používané distribuce. Instaloval-li správce systému PHP ze zdrojových kódů, můžeme v řádku s názvem Configure Command vidět konfigurační direktivy, se kterými byla aplikace zkompilována. Zde bychom měli nalézt hodnotu ‚–disable-posix‘. Pokud se tak nestalo, nebo bylo PHP instalováno jinak než ze zdrojových kódů, pak je sada funkcí POSIX standardní součástí tohoto jazyka. Běžní uživatelé tyto příkazy, kterými POSIX disponuje, nikdy nevyužijí, to samé bohužel nemůžeme říci o útočnících. Pomocí funkce posix_getpwuid() v kombinaci s jednoduchým cyklem lze totiž zobrazit kompletní obsah souboru /etc/passwd a získat tak cenné informace pro další fáze útoku (např. přihlašovací jména k nesystémovým účtům).
Další řádek, kterému bychom měli věnovat naši pozornost, nese označení Server API (SAPI) a obsahuje buď hodnotu se slovem Handler nebo CGI v názvu. PHP totiž může běžet dvojím způsobem, a sice buď jako Apache modul (DSO – Dynamic Shared Object) nebo CGI procesor. Každý ze způsobů má své výhody i nevýhody, přičemž na sdílených serverech je častěji využíván právě první ze způsobů. Důvodem je především větší rychlost, která je na mass virtual hostingu velice důležitá. Bohužel z pohledu bezpečnosti je na tom lépe druhá varianta, která je sice pomalejší a už ze své podstaty nemůže standardně disponovat některými funkcemi (konfiguračními soubory .htaccess, HTTP autentifikací atd.), zato však nabízí bezpečnější práci se soubory z důvodu odlišení jednotlivých uživatelů pomocí unikátních identifikátorů. Je-li totiž PHP spuštěno jako modul, pak při zavolání jakéhokoliv skriptu ze strany libovolného uživatele dojde k vykonání uvedených příkazů s právy webového serveru (většinou nobody, www-data nebo apache) a tyto práva dědí všichni uživatelé. Co to znamená pro samotnou bezpečnost sdílených dat? Konfigurační direktiva safe_mode (viz příští díl) tak postrádá jeden ze svých hlavních smyslů, a sice zabránit útočníkům v přístupu k datům jiných uživatelů.
Jak tedy tento problém vyřešit a neztratit zároveň výhody, které nám PHP v podobě modulu nabízí? Odpověď je poměrně jednoduchá, pomocí jiných modulů, které zajistí, že každý z uživatelů bude majitelem unikátního identifikátoru a v případě práce s daty cizích uživatelů mu bude pomocí direktivy safe_mode (případně i bez ní) přístup odepřen. Tuto funkci nabízí hned několik modulů, nejběžnějšími jsou mod_cgi, mod_fastcgi a mod_fcgid. Dále pak rozšíření mod_ruid, mod_suid, mod_suid2, mod_suphp, suexec, mpm-itk, mpm-peruser a další. Zdaleka ne všechny se hodí k nasazení na mass virtual hosting a jsou určeny pro PHP v podobě modulu Apache, jsou zde uvedeny pouze pro názornost a lepší pochopení toho, k čemu tato rozšíření slouží. Běží-li tedy PHP jako modul, alespoň jedno z výše uvedených rozšíření byste měli v přehledu funkce phpinfo() nalézt (řádek Loaded Modules). Pokud se tak nestane, riskujete nejen kompromitaci svých osobních dat, ale i financí, jste-li provozovateli například e-shopu.
V příštím díle, který tento seriál o bezpečnosti webhostingů uzavře, se mimo jiné seznámíme se třemi nejdůležitějšími konfiguračními direktivami jazyka PHP, které přímo ovlivňují bezpečnost a integritu sdílených dat a dalšími tipy pro výběr bezpečného webhostingu. Pokud se tedy domníváte, že zde některé důležité informace nezazněly, vyčkejte se svým komentářem na závěrečný díl.
ČLÁNKY DO MAILU