• FastCGI w Apache dla CentOS i nie tylko

  dodany przez Przemysław Sikora

  Usługi hostingowe są coraz tańsze. Niestety z niską ceną idzie też często brak bezpieczeństwa i niestabilność. W dobrze zaprojektowanym systemie firmy hostingowej, konta użytkowników powinny być możliwie jak najbardziej odseparowane od siebie. PHP powinien chodzić z uprawnieniami użytkownika, który jest właścicielem danego serwisu. Daje to dodatkowy plus w postaci braku konieczności ustawiania uprawnień dla plików i folderów systemów zarządzania treścią (CMS). W klasycznym wydaniu, aby „strona” mogła zapisywać dane na dysku np. konfigurację, niebędna była zmiana właściciela na „apache” lub nadanie uprawnień 777. Obydwa te rozwiązania nie są dobre z powodu bezpieczeństwa. Weźmy pod uwagę też inną sytuację, gdy jeden z klientów firmy hostingowej ma stronę tzw. wizytówkę, a drugi sklep z wieloma produktami lub rozbudowanego CMS-a, który notuje rekordowe ilości wejść. Tylko pogratulować właścicielom, ale dla nas i innych użytkowników, może skutkować to brakiem wolnych zasobów na pamięć lub procesor. Jak na to poradzić? Najlepiej zastąpując PHP w postaci modułu Apache przez FCGI (FastCGI). Wielu uważa, że jest to bardzo niewydajne w porównaniu z wersją modułową, ale nie jest wcale tak źle :). Zapraszam do instalacji i konfiguracji. Przydałoby się nam repozytorium RPMFORGE. Zakładamy, że je mamy:

  yum install mod_fastcgi

  mkdir /var/www/fcgi

  mkdir /var/www/fcgi/nasza-strona.eu

  cp -a /etc/php.d /var/www/fcgi/nasza-strona.eu

  cp /etc/php.ini /var/www/fcgi/nasza-strona.eu

  Czas na utworzenie tzw. wrappera.

  vim /var/www/fcgi/nasza-strona.eu/wrapper

  PHPRC="/var/www/fcgi/nasza-strona.eu/php.ini"
PHP_INI_SCAN_DIR="/var/www/fcgi/nasza-strona.eu/php.d"
PHP_CGI=/usr/bin/php-cgi
PHP_FCGI_CHILDREN=4 # ilość procesów potomnych (więcej dla częściej odwiedzanych stron)
PHP_FCGI_MAX_REQUESTS=1000
export PHPRC
export PHP_CGI
export PHP_FCGI_CHILDREN
export PHP_FCGI_MAX_REQUESTS
exec $PHP_CGI

  Czas na edycję vhosta. Niezbędne jest dopisanie:

  FastCgiServer /var/www/fcgi/nasza-strona.eu/wrapper
AddHandler php-fastcgi .php
Action php-fastcgi /fcgi/nasza-strona.eu/wrapper
ScriptAlias /fcgi/ /var/www/fcgi/
AddType application/x-httpd-php .php
SuexecUserGroup nasz_user nasza_grupa
  Pamiętajmy, aby cała zawartość katalogu (DocumentRoot) strony była własnością skonfigurowanego użytkownia i grupy. Folder „/var/www/fcgi/nasza-strona.eu/” oraz plik „wrapper” też muszą mieć takie uprawnienia. Warto jest wydać na wspomnianym pliku komendę „chattr +i wrapper”, aby uniemożliwić edycję pliku nawet administratorowi, a przede wszystkim mając na względzie właściciela. Konieczna jest również edycja pliku „/etc/httpd/conf.d/fastcgi.conf” i dopisanie do niego:
  <Location /var/www/fcgi>
Order Deny,Allow
Deny from All
Allow from env=REDIRECT_STATUS
Options ExecCGI
SetHandler fastcgi-script
</Location>
  Na koniec restart Apache

  service httpd restart

  Dzięki opisanemu rozwiązaniu zwiększamy bezpieczeństwo użytkowników i jesteśmy w stanie nad nimi choć trochę zapanować.

2 komentarze do “FastCGI w Apache dla CentOS i nie tylko”

1. rot pisze:

   3 kwietnia 2013 o 4:55

   „PHP powinien chodzić z uprawnieniami użytkownika, który jest właścicielem danego serwisu”

   Większej bzdury dawno nie przeczytałem, W takim układzie wystarczy że w twoim „bezpiecznym” cms-ie znajdzie się jakaś dziura umożliwiająca załadowanie własnego kodu i atakujący przejedzie po całej stronie a nie tylko po katalogu do upload-u. Szerzenie takich bzdur w sytuacji gdy istnieje w sieci mnóstwo słabo zabezpieczonych stron z dawno przeterminowanym oprogramowaniem na które tylko czekają exploit-y jest niebezpieczne dla czytelników.

   Btw. można pozostać przy mod_php i korzystać z mpm_ikt co jest chyba troszkę wydajniejsze niż fcgi + suphp ale mogę się mylić.

2. centos pisze:

   4 kwietnia 2013 o 14:20

   „PHP powinien chodzić z uprawnieniami użytkownika, który jest właścicielem danego serwisu”. To jest w kontekście suexec i fastcgi. Nie powiedziałem, że jest to idealne rozwiązanie, ale minimalizuje szkody wyrządzone przez dziury w cms-ach. W najgorszym wypadku ucierpi jeden klient, a nie wszyscy.