Y-G '04 :: Przegląd tematu

Anubis

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ł Wink

)
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:

	Cytat:
	<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.