Zabezpieczanie serwerów PHP

31

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:

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

David Pashley
źródło

Odpowiedzi:

15
  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.

Antoine Benkemoun
źródło
Niektóre złe witryny faktycznie wymagają register_globals i fopen, dlatego używasz php.ini dla witryny z suPHP. Jedna strona może po prostu przejść kamikaze, a inne mogą być (prawie) całkowicie bezpieczne.
Antoine Benkemoun
4
Jeśli używają register_globals i fopen, sugeruje to, że jakość jest tak zła, że ​​możesz chcieć ponownie rozważyć ich użycie :)
David Pashley
Jeśli płacą 150 € / mc, nie zastanawiasz się.
Antoine Benkemoun
3

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.

msanford
źródło
Moje pytanie dotyczyło bardziej ochrony twojego serwera przed źle napisanym PHP. :) Nie miałem na myśli, że sam PHP jest niepewny, bardziej, że przyciąga mniej doświadczonych programistów, a standardowa biblioteka wymaga od nich pamiętania o ochronie każdego połączenia, a nie biblioteki chroniącej wszystkich użytkowników. +1, ponieważ jest to bardzo przydatna odpowiedź.
David Pashley,
Odniosłem wrażenie i odpowiedziałem odpowiednio :) Dzięki za komentarz! Oczywiście nie mogę się tutaj w to wciągnąć, ale to są duże doły. Jeśli masz bardziej szczegółowe pytania, z pewnością możesz postawić je na stosie przepełnienia stosu, a ja i wszyscy inni będziemy się do tego przyczyniać. (I za ile to warte, jestem ZCE).
msanford
3

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
Deem3n
źródło
1

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.

Brent
źródło
1

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.

Jim OHalloran
źródło
0

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


źródło
2
Na czym polega szybka, zhakowana strona internetowa? :) hardened-php.net/suhosin/benchmark.html sugeruje wolniejszy o 8,85% na jednym teście. Może to być akceptowalne ze względu na zapewniane przez nie korzyści bezpieczeństwa. To prawdopodobnie powinien być komentarz, a nie odpowiedź.
David Pashley,
Suhosin chroni przede wszystkim przed atakami lokalnymi. Jeśli więc udostępniasz swój serwer osobom, którym nie ufasz, być może warto zwolnić. Jeśli masz własny serwer lub własny kawałek vm, nie widzę sensu.
0

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.

DF
źródło
Nie, szukam sposobów na poprawę bezpieczeństwa środowiska wykonawczego PHP.
David Pashley,
0

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.


źródło
1
Czy funkcja escapeshellcmd () nie jest po prostu używana do zmiany ciągu? Nie zapewnia żadnego sposobu wykonania procesu. Jak ktoś może go użyć do spowodowania problemu?
David Pashley,