Apache met PHP-FPM/FastCGI veilig (en flexibel) maken.

[wizkid_niels]

Hey,

Ik heb een VPS met daarop een paar websites. Op dit moment beheer ik zelf de sites en uploaden wordt niet toegestaan, dus ik kan het qua veiligheid redelijk bijhouden. Binnenkort komt er echter wat bij dat niet meer door mij gedaan wordt, dus ik wil ook dat het wat veiliger ingericht wordt. Ik ben wat aan het proberen geweest op VMs, maar ik kom er niet helemaal uit. (Het is niks commercieëls of zo, maar het zou toch fijn zijn als het goed ingericht is)

Wat ik heb:

Debian 6 32-bits
Apache2.2
PHP-FPM/FastCGI
(MySQL)

Het apache gedeelte gaat prima. Het gaat echter niet helemaal goed met PHP. Ik kan bijvoorbeeld een php-shell uploaden en vervolgens de gehele server uitlezen.

Wat ik wil hebben:
- Op een eenvoudige wijze later nog virtual hosts kunnen aanpassen/verwijderen/toevoegen
- PHP veilig ingericht hebben. Dus niet dat iemand zo'n PHP-shell kan uploaden en vervolgens de hele server kan benaderen (of andere exploits/beveiligingsproblemen?)

Ik dacht dus dat ik in ieder geval verschillende pools moest aanmaken (/etc/php5/fpm/pool.d/) en elke vhost met zijn php pool instellen. Dan moet ik het nog verder beschermen, zodat PHP alleen dingen kan doen die betrekking hebben op de DocumentRoot van apache en niet daarbuiten.

Ik dacht dat dit met chroot omgevingen mogelijk moest zijn, maar ik weet niet of dit -de- manier is om het te doen. Ik vond er niet heel veel guides over, maar de beste die ik vond was deze: http://www.makina-corpus....apache-and-chroot-php-fpm
Echter wordt hier geen rekening gehouden met meerdere virtual hosts.
Ik weet dus niet wat ik precies moet doen om te krijgen wat ik wil en welke methode de "beste" is.

Volgens mij wordt dit (als het goed is) altijd al gedaan bij bijvoorbeeld shared hosting omgevingen, dus zo "bijzonder" zou het toch niet moeten zijn. Toch kan ik er vrij weinig over vinden.

Heeft iemand ideeën?

EDIT: Wat dingen die ik dus zelf zag, maar waarvan ik niet zeker weet of het klopt en of het voldoende is qua bescherming/veiligheid:

1. php safe-mode schijnt niet heel geliefd te zijn. Ik begrijp dat het wat veiligheid toevoegt maar dat het ook vanaf PHP6 verwijderd gaat worden. Dus dat niet gebruiken?

2. Het volgende kwam ik al wel tegen. Aangezien ik per virtual host een aparte "pool" heb in PHP-FPM zou ik het volgende dus kunnen instellen:
/etc/php5/fpm/pool.d/<poolname>.conf
---

code:

user = user1 
group = user1

Bovenstaand dus de eigenaar van het PHP proces, zo zouden er ook geen problemen moeten komen met de eigenaar / permissies van files in de webroot, correct?

code:

chdir = /
php_admin_value[open_basedir] = /var/www/domeinuser1/:/usr/share/php5:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadmin
php_admin_value[disable_functions] = apache_child_terminate, apache_setenv, define_syslog_variables, escapeshellarg, escapeshellcmd, eval, exec, fp, fput, ftp_connect, ftp_exec, ftp_get, ftp_login, ftp_nb_fput, ftp_put, ftp_raw, ftp_rawl
ist, highlight_file, ini_alter, ini_get_all, ini_restore, inject_code, mysql_pconnect, openlog, passthru, php_uname, phpAds_remoteInfo, phpAds_XmlRpc, phpAds_xmlrpcDecode, phpAds_xmlrpcEncode, popen, posix_getpwuid, posix_kill, posix_mkf
ifo, posix_setpgid, posix_setsid, posix_setuid, posix_setuid, posix_uname, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, shell_exec, syslog, system, xmlrpc_entity_decode

Hierdoor zouden de gevaarlijke PHP functies uitstaan waardoor bv. php shells niet meer mogelijk zijn en blijft PHP "contained" in de webroot (/var/www/domeinuser1/) en kan dus niet bij andere bestanden op de server of commando's e.d. uitvoeren. Dat klopt ook?

Zijn er nog andere dingen waar ik aan moet denken? Of is het op deze manier veilig en dus "contained"?

Alvast bedankt,

[ Voor 32% gewijzigd door wizkid_niels op 04-07-2012 20:40 ]

[IEF]

Move naar Non-Windows Operating Systems.

[JMW761]

http://www.suphp.org/Home.html

en goeie rechtenstructuur op je webserver

Denk ook aan quota's! want "vreemden" op je server hebben "vaak" de neiging om meer space te gebruiken dan jij had gedacht van te voren.

[jb044]

Interessante post. Wij hebben een dedicated server voor een x aantal websites van klanten. Hierbij is ook 1 website die direct door een concollega up2date wordt gehouden, de rest doen we zelf. Dus het probleem dat je beschijft komt me bekend voor

Vraag me alleen wel af wat je probleem is: is dat dat je externe partijen niet vertrouwd in het goed up2date houden van hun webapps, of vertrouw je ze echt helemaal niet? In dat laatste geval kun je er denk ik beter helemaal niet aan beginnen, men vindt altijd wel een weg.

[Marlinc]

Ik zou zelf ook suphp aanraden. Het is misschien wel even lastig om de rechten op bestanden en mappen zo te krijgen dat suphp niet gaat klagen over group file/directory write access maar dit zorgt wel voor een laag van beveiliging als het goed is uitgevoerd.