utok na apache

[Martin Tiršel]

Zdravim,

virtualne weby s php je mozne cez suexec a fcgid (nepliest s fastcgi)  
spustat s pravami ineho uzivatela/skupiny. Nastavenie je sice zlozitejsie  
a je potreba sa s tym vyhrat a potestovat, ale vo vysledku to stoji za to.  
V tejto konfiguracii je mozne pouzit apache v rezime worker, pre ktory  
mod_php nieje vhodny, pretoze PHP4/5 nieje thread safe.

Tu je par rad, ktore mozno zachrania hodiny alebo dni googlenia :)

*) a2enmod suexec fcgid
*) /etc/apache2/suexec/www-data nastavit prvy riadok na root adresar webov  
(toto je obmedzenie suexec, ide nastavit len jeden adresar), druhy riadok  
zakomentovat
*) /etc/apache2/mods-available/fcgid.conf: treba nastavit parametry,  
dokumentacia mizerna, ale je par tutorialov s nejakymi info. Za zmienku  
stoji navysit IPCConnectTimeout (pripadne dalsie timeouty) na nejaku  
rozumnu hodnotu (pozor, toto treba nastavovat aj uplne vo vsetkych  
virtualoch, inak sa bude brat vsade 20(alebo 40?) sekundovy hardcoded  
timeout - jedna z veci, nad ktorou som dlho laboroval), nastavit  
DefaultMin[Max]ClassProcessCount na 0 a X (X je podla potrieb),  
MaxRequestsPerProcess (viz http://fastcgi.coremail.cn/doc.htm), ...

Konfiguracia virtualu vyzera nejako takto:


<VirtualHost *:80>
    ServerName www.domena.xy
    DocumentRoot /var/www/user/webs/www.domena.xy

    SuexecUserGroup user group

    <Directory /var/www/user/webs/www.domena.xy>
       AddHandler fcgid-script .php
       FCGIWrapper /var/www/user/.user_config/www.domena.xy.php-cgi .php
       Options ExecCGI FollowSymLinks
       Order Allow,Deny
       Allow From all
    </Directory>

    IPCConnectTimeout 80
    IPCCommTimeout 300
    BusyTimeout 300
	
</VirtualHost>

fcgid wrapper na php potom treba nejako takto:

#!/bin/bash

umask 027
TMPDIR="/var/www/user/tmp"
export TMPDIR
TEMPDIR="/var/www/user/tmp"
export TEMPDIR
PHP_FCGI_CHILDREN=2
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=2000
export PHP_FCGI_MAX_REQUESTS

exec /usr/bin/php-cgi --php-ini  
/var/www/user/.user_config/www.domena.xy.php.ini $@


Nastavenie PHP_FCGI_CHILDREN na hodnotu vyssiu ako nula sice spawnuje  
procesy pod rodicovskym PHP procesom, co umozni zdielanie pamate medzi  
tymito PHP procesami, ale vznika tu problem, kedy (zrejme pri necinnosti -  
ak nieje dosiahnuta hodnota PHP_FCGI_MAX_REQUESTS a nastane skorej  
fcgid.conf: ProcessLifeTime alebo MaxRequestsPerProcess [skorej by som  
tipoval ten lifetime] ) je hlavny PHP proces killnuty, ale tieto dcerske  
procesy smrt rodica "preziju" a osamostatnia sa, cim sa postupne tieto  
procesy mnozia a mina sa tak pamat. Zatial som ine riesenie ako periodicke  
spustanie skriptu, ktore treba raz za hodinu tieto procesy vycisti,  
neobjavil. Nieje to ale nic tragicke a da sa s takymto riesenim fungovat.  
Ak sa nastavi na 0, tak netreba takto hackovat, ale potom nemaju rozne  
akceleratory/cache velky vyznam, kedze kazdy PHP proces daneho virtualu ma  
len svoju pamat (snad som to dobre popisal, pochopil som to takto z  
diskusii).

Vykonovo by som povedal, ze to nieje poznat (max. ak este nieje spusteny  
proces daneho virtualu, tak prva poziadavka je o par stoviek milisekund  
pomalsia, u tych dalsich nepozorujem rozdiel). Co sa tyka konzumacie  
pamati, tak ta by teoreticky mala byt lepsia (hlavne pri velkom prenose  
statickych suborov sa apache odlahci, pretoze nemusi mat dalsich (tusim)  
30MB per www-data proces, plus pri dobrom zladeni niektorych virtualnych  
webov sa da dosiahnut daleko mensia konzumacia pamate, nez u mod_php), u  
mna to vyzera, ze asi trocha narastla, ale je to len pocit, kedze  
konfiguracia servera je trochu odlisna nez za doby mod_php (a niektore  
veci este nemam uplne doladene).

Niektore veci v takejto konfiguracii ale niesu 100% kompatibilne (vdaka za  
info p. Kouril), ako napr.:
* HTTP autorizacia do PHP (riesitelne)
* v htaccess nefunguju php.ini nastavenia (riesitelne)
* apache preda fcgid procesu data az po kompletnom obdrzani, takze napr.  
upload suboru sa neda priebezne kontrolovat (ajax progress bar u uploadov)  
(u apache zatial asi neriesitelne, u inych webserverov mozno)

Na viacej si teraz nevzpominam (alebo o nich neviem :), ale vacsina by  
mala byt nejako riesitelna. Rozhodne je takato konfiguracia lepsia,  
bezpecnejsia a pod vacsou kontrolou, vyuzije sa lepsie vykon viacjadrovych  
procesorov, atd...

-- 
S pozdravom,
Martin Tiršel



On Sun, 20 Sep 2009 22:28:24 +0200, Petr Stehlik <pstehlik na sophics.cz>  
wrote:

> Pavel Kankovsky píše v Ne 20. 09. 2009 v 21:36 +0200:
>> On Sun, 20 Sep 2009, Petr Stehlik wrote:
>>
>> > ano, to útočník může vždycky, to je běžná chyba uživatele, že mu  
>> utečou
>> > hesla, ale ten útočník by pak neměl mít možnost měnit běžící procesy,
>> > IMHO.
>>
>> Když necháte uživatele spouštět kód pod stejným uživatelem, jako běží
>> Apache
>
> jaký je doporučený způsob pouštění PHP pod jiným uživatelem (v Debianu)?
> Četl jsem, že všechny dobré způsoby jsou příliš pomalé (ve smyslu
> snížení výkonu webového serveru).
>
> Petr
>
>
> _______________________________________________
> Linux mailing list
> Linux na linux.cz
> http://www.linux.cz/mailman/listinfo/linux