Bezpieczeństwo dla adminów
Najbardziej popularną metodą włamania na serwer www jest Remote File Include (PHP injection). Najbardziej podatne są kombajny typu Mambo, Joomla, których kopii w Internecie istnieją tysiące. Znalezienie jednej luki pozwala automatycznie zainfekować je wszystkie - bo użycie googli pozwala je wszystkie wyszukać - co do jednego.
Jeżeli mamy statystyczny serwer www to jest on najczęściej wykorzystywany przez kilku użytkowników, którzy stawiają swoje strony. Administrator takiego serwera (jeżeli w ogóle jest ktoś taki, a nawet jeżeli jest to albo jest ignorantem z dziedziny bezpieczeństwa albo ma to tam, gdzie słońce nie dochodzi) zazwyczaj nie konfiguruje w ogóle PHP, co staje się przyczyną kłopotów.
Jeżeli było włamanie na serwer i teraz szukają kozła ofiarnego to według moich szacunków 70% winy ponosi użytkownik, który postawił dziurawy skrypt/stronę a 30% admini^H lamer, który się tym serwerem opiekuje.
Zatem oprócz bezpiecznych skryptów należy także zadbać o bezpieczeństwo serwera.
1) Rozdzielamy przestrzeń życiową...
Skrypty jednego usera nie powinny mieć możliwości przeglądania skryptów drugiego usera (np. w poszukiwaniu haseł ;) )Oprócz tego powinniśmy rozdzielić katalogi tymczasowe aby nie można było np. podglądać sesji.
w /etc/httpd/conf/httpd.conf tworzymy zatem wpisy dla każdego usera:
<Directory /home/user1/public_html/>
php_admin_value open_basedir "/home/user1/public_html:/usr/lib/php:/home/user1/tmp:/usr/share/pear"
php_admin_value upload_tmp_dir "/home/user1/tmp"
php_admin_value session.save_path "/home/user1/tmp"
</Directory>
2) Weźmy na tapetę /etc/php.ini.
Dyrektywa disable_functions pozwala nam zabronić userom uruchamiania niektórych funkcji. Na przykład:
disable_functions = dl, exec, passthru, system, shell_exec, popen, mail, fsockopen
Oprócz tego warto jeszcze ustawić:
allow_url_fopen = Off
allow_url_include = Off (dla PHP5)
3) Security by obscurity
w konfiguracji apacza warto zrobić sobie virtualhosta obsługującego domenę a wszelkie inne requesty niech trafiają do głównego virtualhosta:
NameVirtualHost *
<VirtualHost *>
DocumentRoot /var/www/html/
ServerName athlon.lemat.priv.pl
ErrorLog "/var/log/httpd/error_log"
CustomLog "/var/log/httpd/access_log" combined
</VirtualHost>
<VirtualHost *>
DocumentRoot /home/lemat/public_html/
ServerName lemat.priv.pl
ServerAlias www.lemat.priv.pl
ErrorLog "/var/log/httpd/lemat-error_log"
CustomLog "/var/log/httpd/lemat-access_log" combined
</VirtualHost>
dzięki temu wszyscy potencjalni włamywacze skanujący zakresami IP trafią w pustkę. Dodam tylko, że w katalogu /var/www/html/ warto umieścić index.html opisujący w jaki sposób można się skontaktować z adminem danego serwera albo przekierowanie na domenę.
Oczywiście w /var/www/html/ nie umieszczamy podkatalogów ze skryptami, które zazwyczaj mają problemy z bezpieczeństwem - phpBB, Mambo, Joomla, Wordpress, phpMyAdmin z wpisanym na sztywno hasłem, skrypty statystyk etc. W pliku logu z głównego virtualhosta można zaobserwować jakich URLi szukają włamywacze.
4) Ruch WYchodzący z serwera
Serwer www właściwie powinien tylko i wyłącznie akceptować połaczenia PRZYchodzące. Zatem można by założyć, że serwer nie będzie generował ruchu WYchodzącego, czyli krótko mowiąc można by wyciąć (DROP) wszystkie pakiety z rozpoczynające połączenia (SYN) w łańcuchu OUTPUT iptables zostawiając tylko połączenia typu RELATED, ESTABLISHED (-m state).
Wyjątki (trzeba zezwolić PRZED regułką DROPującą):
53 udp,tcp - zapytania do serwerów DNS
serwer FTP w trybie aktywnym - ale to załatwia RELATED
czasami jakaś strona pobiera z Internetu zawartość, np. kursy walut - to już trzeba ustalać indywidualnie z programistą - może to być protokołem http, ftp lub jakieś inne połączenia.
5) Safe mode
Safe mode w zasadzie przynosi więcej problemów niz korzyści, aby to uruchomić to skrypty PHP musiałyby być uruchamiane z uprawnieniami użytkowników. Jednak ma jedną niezaprzeczalną zaletę - nie pozwala skryptom na długie działanie. Czasami mam okazję oglądać skrypty różnych włamywaczy - pierwszą rzeczą, którą robią to zapewnienie sobie nielimitowanego czasu wykonywania skryptu. Mogą wtedy nawiązać połaczenie zwrotne "ET dzwoni do domu" a taki proces w systemie jest w zasadzie "niewidoczny".
Pod adresem http://linio.terramail.pl/konfigphp.html znajduje się znaczniej dokładniejszy opis zagadnień bezpieczeństwa autorstwa Henryka Liniowskiego.
Pod adresem http://maciaszek.pl/phpcon/download/bezpieczenstwo.pdf znajduje się inny dokument dotyczący zagadnienia bezpieczeństwa w PHP autorstwa Marka Jakubowicza, tutaj fajnie poruszono zagadnienie modułów.