Weblabor

Sokszor felmerül webkiszolgálókat adminisztrálók körében a kérdés, hogy hogyan lehetne a PHP futtatását biztonságosabbá tenni. Bizonyára sokunk futtat, telepített már rendszert mod_php-val (Apache), és sokan meg is tapasztaltuk ennek a hátrányait. Véleményem szerint ezeket a hátrányokat nagyon szépen meg lehet szüntetni, és lehet PHP-t futtatni biztonságosan, kompromisszumok nélkül.

A mod_php

A mod_php legnagyobb előnye, hogy nagyon egyszerű telepíteni, pillanatok alatt készen van. Debian Linux alatt a telepítése egy lépésben történik: apt-get install libapache2-mod-php5 (feltételezzük, hogy Apache 2-es kiszolgálót és PHP 5-ös verziót szeretnénk telepíteni). Ez a parancs letölti a megfelelő Apache modult, és telepíti azt. A PHP konfigurációs állományát (php.ini) alapértelmezés szerint a /etc/php5/apache könyvtárba teszi. A parancs kiadását követően újra kell indítanunk a kiszolgálót, és már használhatjuk is a PHP-t.

A mod_php előnyei

• Egyszerű, gyors telepítés
  
• Ismert a webfejlesztők körében
  
• Gyors a PHP futása (mihez képest, ugye?)
  
• Virtual hostonként lehetőségünk van egyedi PHP beállítások használatára
  
• A PHP futási paramétereit magunk is könnyedén módosíthatjuk könyvtáranként .htaccess állományok segítségével
  

A mod_php hátrányai

Mindannyian dolgoztunk már mod_php-val, így ismerjük azt a tényt, hogy a PHP kiszolgálása a kiszolgálótt futtató felhasználó nevében történik (ez némely rendszeren a www-data, másokon a nobody). Ez a megoldás azért problémás, mert ha írni akarunk a fájlrendszerbe, akkor azt csak a jogosultsági rendszer meglazításával lehet: vagy az összes felhasználónak írási joggal kell rendelkeznie az adott állományra vagy könyvtárra, vagy az a www-data tulajdonában kell legyen.

Ez egy felhasználónál nem gond (fejlesztő gépe), de mi a helyzet akkor, ha többen vannak? Ha én a /home/donci/nagyontitkosallomanyok könyvtárban szeretném tárolni a nagyon titkosnak ítélt dolgaimat, akkor hogy oda tudjak írni, a www-data felhasználónak is kell tudnia oda írni. Ebből a tényből következik az, hogy ha a badboy nevű felhasználó kideríti az elérési utat (ami nem feltétlenül esik egybe a web gyökérkönyvtárral), akkor simán el tudja olvasni az én titkosnak vélt állományaimat.

Természetesen, ekkor nagyon fontos az open_basedir PHP direktíva beállítása, hogy badboy ne tudjon PHP programmal garázdálkodni a saját könyvtárán kívül (/home/badboy). Ugyanez vonatkozik a többi felhasználóra is!

De ez sem teljesen jó megoldás: én, mint átlagos felhasználó nem tudom a nagyon titkos könyvtáramat a www-data tulajdonába átadni, mivel nem tudom a jelszavát. Annyit tehetek csak, hogy az összes felhasználónak adok olvasási, írási jogot a könyvtárra (chmod o+rw), de ezután már PHP futtatási jog sem kell ahhoz, hogy valaki turkálhasson a könyvtárban. Valljuk be, ez nem túl szerencsés dolog.

Másik nagy hátránya a mod_php használatának az, hogy egy modul futtatja az összes felhasználó PHP programjait, ezért, ha a kedves badboy ír egy olyan programot, ami valamely oknál fogva működésképtelenné teszi a mod_php-t, akkor az én PHP programom futása is megakad.

Egy lehetséges megoldás: PHP futtatása mod_fastcgi segítségével

Elég sok kutatásba, próbálkozásba került, mire sikerült megoldani a PHP futtatását úgy, hogy a fentebb említett, mod_php használatából fakadó hátrányokat kiküszöböljem.

Mi ez a FastCGI?

Röviden: olyan mint a CGI, csak jobb. Nézzük kicsit leegyszerűsítve: egy CGI (Common Gateway Interface) alkalmazás esetén a program futása a következőképpen néz ki: jön a kérés a kiszolgáló felé, mire az továbbítja a kérést a CGI programnak. Jelen esetben ez a PHP értelmező lesz, ami futtatja a programot, és az eredményt visszaadja a kiszolgálónak, majd ezután eltűnik a memóriából. Egy következő kéréskor ugyanez a folyamat ismétlődik, amiből egyből láthatjuk, hogy ez a módszer nem túl hatékony, a PHP értelmezőt állandóan be kell tölteni, majd ki kell pakolni a memóriából.

A FastCGI ezt a be/ki töltögetést küszöböli ki: a PHP értelmező bent marad a memóriában addig, amíg szükség van rá. Sőt, egyszerre több értelmezőt is a memóriában tart, így egyszerre több kérést is ki tud szolgálni a szerver.

A CGI program külön szálként fut a kiszolgálón, elkülönítve tőle, és a többi hasonló száltól. Ha az egyik kedves felhasználó programja megöli a CGI értelmezőjét, akkor sincs semmi gond, az meghal, de a többi attól még vígan dolgozik, és szolgálja ki a lapokat.

PHP futtatás felhasználói jogokkal? Lehetséges?

Igen, lehetséges, az Apache suEXEC szolgáltatását használva. A suEXEC biztonsága azon alapul, hogy egy wrapperként (befoglaló programként) más felhasználói jogokkal tud indítani alfolyamatokat. Ezzel a módszerrel megoldhatjuk, hogy a CGI módban futó PHP programunk felhasználói jogokkal fusson. Meg kell említenünk a teljesség kedvéért, hogy léteznek még más PHP futtatási megoldások is: például a SuPHP, de a fellelhető információk alapján ennek a sebessége messze elmarad a FastCGI sebességétől (mérések szerint akár 70× lassabb is lehet!).

A kiszolgáló beállítása

A környezet kialakításához szükségünk lesz a mod_fastcgi (emellett a mod_cgi és mod_actions) és mod_suexec modulokra a kiszolgálóhoz, és CGI módú (--enable-fastcgi opcióval fordított) PHP-ra.

A fentebb említett modulok betöltését a következő sorok az Apache konfigurációs állományába történő beírásával érhetjük el:Debian rendszer alatt elég a mods-available könyvtárból a megfelelő .load állományokat linkelni a mods-enabled könyvtárba.

A FastCGI konfigurációs állomány

Nálam ez egy fastcgi nevű állományban van az Apache 2 conf.d könyvtárában:A wrapper a suexec2 program, amely indítani fogja a CGI programokat, és alapértelmezésben a www-data felhasználó/csoport jogokkal fog futni a PHP értelmező. Ezt követően a kiszolgáló /cgi könyvtárára biztosítunk CGI futtatási lehetőséget.

Ezután már csak a virtuális kiszolgáló beállítása következik, mely két részből áll: a konfigurációs állományból, és egy PHP-t indító shell scriptből, melyre a suEXEC miatt van szükség. Nézzük meg ez utóbbit először.

A PHP-t indító shell script

A suEXEC biztonsági beállításai olyanok, hogy csak a /var/www könyvtárból enged suid-elt program futtatást. Ezért egy apró programot kell ebben a könyvtárban elhelyezni, amely majd a CGI módú PHP értelmezőt indítja. Erre a programra a suEXEC biztosítja a kiszolgálótól eltérő felhasználói jogokat.

Virtuális kiszolgáló beállítása

A host neve legyen a példa kedvéért foo.bar, a felhasználó pedig foo. Ennek érdekében a /var/www alatt hozzunk létre egy foo.bar könyvtárat, melynek tulajdonosa foo:foo legyen. Ebbe a könyvtárba kell tenni a PHP-t indító scriptet php-fcgi néven, szintén foo:foo jogokkal. A könyvtárat azért csináljuk, hogy a virtuális kiszolgálók konfigurációs állományait elkülönítsük egymástól.



A fenti kis programocska a /usr/lib/cgi-bin/php5 programnak fogja átadni a vezérlést, amely feldolgozza majd a mi PHP szkriptünket. A PHPRC beállítás pedig lehetővé teszi, hogy ebben a könyvtárban elhelyezzünk egy php.ini-t, így lehetőségünk van virtuális kiszolgálónként egyedileg konfigurált PHP-t használni. Ezt a php.ini-t már lehet root jogokkal odatenni, ha nem akarjuk, hogy a felhasználó módosíthassa.

A szokásos dolgokon kívül a következőket kell beállítani:A SuexecUserGroup után adjuk meg azt a felhasználót, akinek a nevében fog futni a PHP. Ezután már csak néhány FastCGI beállítás jön, ahol megadjuk, hogy egy php kiterjesztésű állomány kiszolgálásakor a fent elkészített szkriptünk fusson (de már felhasználói jogokkal).

A FastCGI módszer hátrányai

• Lassabb mint a mod_php. Részben igaz csak, igazából csak a CGI hívás miatt van egy pici konstans overhead (pár ms). Némely esetben a FastCGI PHP a gyorsabb
  
• Nem lehet .htaccess-ben php.ini beállításokat használni, cserébe viszont van egy saját php.ini-nk, ahol tényleg mindent be tudunk állítani virtuális kiszolgálónként (azt is, hogy milyen modulokat használhat az adott host)
  
• Ha nem a felhasználó tulajonában van a PHP program, nem fut...
  
• Az Apache által biztosított könyvtár autentikáció csak külön beállításokkal működik
  

A FastCGI módszer előnyei

Azt hiszem a fentiekből már teljesen világos lehet, de azért kiemelném a legfontosabbakat:

• Biztonságosabb, mint a mod_php, mivel felhasználói jogokkal fut a PHP programunk
  
• Hostonként teljes a kontroll a PHP felett a saját php.ini miatt
  
• Mivel a /var/www-ben elhelyezett kis szkriptek bármilyen programot indíthatnak, ezért hostonként más verziójú PHP futtatható!
  
• Nem kell foglalkozni a könyvtárak jogainak átadásával: ahova a felhasználó írhat, oda írhat a PHP is, ezáltal sokkal átláthatóbb a jogrend
  

Az eredmény

A kiszolgálónkon a ps -axfu parancsot kiadva valami hasonló kimenetet kell kapnunk:Szépen látszik, hogy a FastCGI fő folyamatot még a www-data indította el, de a többi alfolyamat már felhasználóként fut.

Források

• FastCGI weblap
  
• Suexec'ed PHP-FastCGI on Apache 2
  
• Using FastCGI with PHP
  
• Apache 2 mit PHP 4/5 als FastCGI
  
• mod_fcgi, egy másik FastCGI implementáció