Zabezpieczanie serwerów PHP

Aplikacje PHP mają reputację ponadprzeciętnych problemów bezpieczeństwa. Jakich technik konfiguracji używasz, aby upewnić się, że aplikacja jest bezpieczna?

Szukam pomysłów takich jak:

• Korzystanie z Hardened PHP / Suhosin
• Korzystanie z mod_security
• Wyłączanie register_globals i allow_url_fopen w php.ini

Zwykle używam Linuksa, ale sugeruję również rozwiązania Windows.

1. Użyj dyrektywy open_basedir, aby ograniczyć skrypty PHP do ich katalogu domowego i ewentualnych dodatkowych katalogów aplikacji. To samo w sobie jest bardzo wydajne.

2. Użyj utwardzonego php, ponieważ to nic nie kosztuje i może pomóc.

3. Użyj suPHP, aby skrypty PHP były wykonywane jako właściciel pliku (jeden użytkownik na stronę) i unikaj używania plików o złych uprawnieniach, takich jak 777 ... suPHP może również pozwolić ci mieć na php.ini na stronę, aby jedna strona była głupia wymagania nie niszczą wszystkiego.

4. Mod_security jest dużym plusem, ale musi być dobrze używany i skonfigurowany.

Z mojego doświadczenia wynika, że ​​większość luk w witrynach opartych na języku PHP jest wynikiem złego projektu (witryny), a nie wad samego PHP.

Kilka szybkich wskazówek:

• Uniwersalnie filtruj wejście, wyjście specjalne. Clarificaiton: filtr nie oznacza ucieczki, oznacza „jeśli znajdę coś podejrzanego w tym danych wejściowych użytkownika, spowoduj niepowodzenie przesyłania i powiedz użytkownikowi o ponownym sformatowaniu”.
• Zamiast używać escapeshellcmd (), po prostu nie zezwalaj, aby jakiekolwiek dane wejściowe użytkownika były wykonywane w powłoce . To niebezpieczne i prawdopodobnie nigdy nie jest konieczne.
• Nie wywoływaj funkcji takich jak phpinfo () na stronie produkcyjnej (lub jeśli tak, patrz poniżej *).
• Projektując aplikację internetową, zawsze bierz pod uwagę „czy to możliwy wektor ataku?” Powiedzmy, wstrzyknięcie SQL. Jeśli odpowiedź brzmi „tak”, podłącz ją natychmiast - nie mów „ok, dodam ją później jako program”. Bezpieczeństwo nigdy nie jest cechą.
• Nigdy nie wysyłaj surowych błędów do użytkownika; oznacza to ustawienie display_errors = php.ini na Off, log_errors = On. Wyłapuj błędy w czasie wykonywania i wyświetlaj coś ładnego. Weźmy na przykład wieloryba Twittera: nie dostarczy on informacji na poziomie debugowania, po prostu mówi „ups, coś się zepsuło, odśwież”.

* Możesz także rzucić okiem na krótki post, który napisałem zatytułowany „Zabezpieczanie phpinfo (), w pewnym sensie” i koniecznie przeczytaj komentarze http://egovsergo.com/2009/04/03/protecting-your-phpinfo/ To był szybki pomysł, że musiałem (nieco) chronić phpinfo (), jeśli w jakiś sposób zapomniałem usunąć go z witryny produkcyjnej.

Mówiąc bardziej ogólnie, niektórzy programiści piszą opakowania dla wrażliwych funkcji, które sprawdzają, czy nie jest ustawiona flaga „strona produkcyjna”, i wyłącza wrażliwą funkcję w produkcji.

Inne parametry, które należy zmienić, aby wzmocnić PHP:

safe_mode = Off
register_globals = Off
expose_php = Off
allow_url_fopen = Off
allow_url_include = Off
log_errors = On
error_log = /var/log/phperror.log
display_errors = Off
enable_dl = Off
disable_functions="popen,exec,system,passthru,proc_open,shell_exec,show_source,phpinfo"

Przechowuj wszystkie błędy PHP w pliku /var/log/phperror.log :

touch /var/log/phperror.log
chmod 666 /var/log/phperror.log

Dodałem dotdeb repozytoria do mojego /etc/apt/sources.lst

deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable all

Ponieważ łatają php / apache / mysql znacznie częściej niż Debian.

Zastanów się open_basedirnad konfiguracją „na stronę”. open_basedirjest ustawieniem php.ini, które uniemożliwi twoim skryptom dostęp do plików poza zdefiniowaną białą listą. Jeśli serwer obsługuje kilka witryn, uniemożliwi to jednej witrynie odczyt ustawień bazy danych z innej witryny. Zapobiegnie również dostępowi do skryptu php / modyfikowaniu podstawowych plików systemowych. Open basedir jest łatwy do skonfigurowania, wystarczy dodać wiersz „ php_admin_value open_basedir /my/list/of/folders:/as/a/colon/seperated/list” do każdego hosta Apache.

Zastanów się również nad wyłączeniem silnika skryptów PHP dla wszystkich witryn / folderów, które nie powinny zawierać skryptów PHP (np. Folder przesłanych obrazów). Ponownie, jest to proste, dodaj „silnik php_admin_value wyłączony” do dowolnych wirtualnych hostów Apache, które nie potrzebują php. Aby wyłączyć PHP w katalogu, umieść to samo w znaczniku Directory.

Uruchamiaj uprawnienia do plików tak ściśle, jak to możliwe, unikaj dostępu do zapisu w skryptach PHP dla użytkownika Apache, co zapobiega modyfikowaniu się uruchomionego skryptu lub innych skryptów na tej samej stronie / serwerze. Jeśli to możliwe, unikaj uprawnień 777, określ minimalne uprawnienia wymagane do uruchomienia aplikacji i korzystania z nich.

Jeśli hostujesz wiele witryn, każda z własną bazą danych, użyj osobnego użytkownika MySQL / Postgres dla każdego z nich i ustaw uprawnienia dla każdego użytkownika, tak aby miał on dostęp tylko do odpowiednich baz danych. To znowu zapobiegnie manipulowaniu nieuczciwym skryptem przy bazie danych innej aplikacji.

Suosin, HardenedPHP, mod_security i tym podobne są również cenne, ale używaj ich oprócz ściśle zamkniętej konfiguracji, nie zamiast.

Suhosin ma dość znaczny koszt wydajności, więc komentarz „nic nie kosztuje” jest nieco odległy.

Szukasz podstawowych wskazówek dotyczących zapory / topologii? Podoba mi się pomysł używania np. Funta, aby uniemożliwić dostęp bezpośrednio do serwera PHP z niemytych stron internetowych. W ten sposób możesz także oddzielić serwer WWW od innych części sieci.

Korzystanie z Suhosin / mod_security / SuPHP z pewnością sprawi, że twój serwer PHP będzie bezpieczny. Wyłączenie niektórych funkcji, takich jak exec, passthru, system i escapeshellcmd, również bardzo pomoże.