Przejdź do treści 
Bezpieczeństwo obsługi PHP W bezpośrednim porównaniu FPM i CGI, izolacja procesów, uprawnienia użytkowników i twarde limity są najważniejszymi czynnikami. Pokazuję, dlaczego FPM z dedykowanymi pulami zmniejsza ryzyko, podczas gdy klasyczne CGI zapewnia ścisłą izolację, ale generuje opóźnienia i obciążenie procesora z powodu wysokich kosztów ogólnych.
Punkty centralne
- Izolacja określa powierzchnię ataku i ryzyko związane z różnymi kontami.
- Baseny FPM oddzielać użytkowników, ustawiać limity i chronić zasoby.
- CGI silnie izoluje, ale kosztuje procesor i czas na żądanie.
- OPcache wymaga oddzielnych segmentów pamięci masowej dla każdego konta.
- hosting wspólny korzyści z dedykowanych instancji FPM.
Jak programy obsługi PHP kształtują bezpieczeństwo
Każdy handler łączy serwer WWW i interpreter PHP, ale Wykonanie mod_php ładuje PHP bezpośrednio do procesu serwera WWW; zapewnia to szybkość, ale współdzieli ten sam kontekst użytkownika i zwiększa ryzyko związane z hostingiem. CGI uruchamia nowy proces dla każdego żądania w ramach użytkownika docelowego, co pozwala zachować czysto oddzielone prawa, ale z zauważalnym narzutem. FastCGI utrzymuje procesy przy życiu i zmniejsza koszty uruchamiania, ale tylko FPM zapewnia dokładną kontrolę, której wymagają nowoczesne konfiguracje dla wielu użytkowników. Preferuję FPM, ponieważ pozwala na oddzielne pule, oddzielne UID i ścisłe limity na konto bez utraty wydajności.
FPM vs CGI: rozgraniczenie bezpieczeństwa w życiu codziennym
W bezpośrednim porównaniu, CGI ściśle oddziela, ale FPM kontynuuje separację. stały i utrzymuje niskie opóźnienia. Pule FPM działają pod odpowiednim kontem użytkownika, izolują ścieżki i hermetyzują zasoby; w ten sposób exploit w witrynie A uniemożliwia dostęp do witryny B. Ograniczam również wpływ wadliwych skryptów za pomocą memory_limit, max_execution_time i request_terminate_timeout. Chociaż CGI kończy każdy proces po żądaniu, marnuje czas procesora poprzez ciągłe uruchamianie i ładowanie rozszerzeń. W środowiskach współdzielonych dominuje zatem FPM, najlepiej jako dedykowana pula na domenę lub projekt.
Izolacja w hostingu współdzielonym: ryzyko i środki zaradcze
W środowiskach współdzielonych największe Ryzyko związane z hostingiem, gdy konta współdzielą zasoby lub prawa w sposób niezamierzony. Atakujący atakują słabe uprawnienia do plików, błędne katalogi tymczasowe lub nierozdzielone pamięci podręczne. Dzięki dedykowanym pulom FPM na konto hermetyzuję procesy, ścieżki plików, dzienniki i segmenty OPcache. Oddzielam również ścieżki przesyłania i zapobiegam atakom symlink za pomocą restrykcyjnych opcji montowania i czystych modeli właścicieli. Wielopoziomowość Izolacja procesów z chroot, CageFS lub jails znacznie zmniejsza wpływ włamania, ponieważ atakujący nie może dotrzeć do systemu hosta.
Zarządzanie zasobami: pule, limity i limity czasu
FPM zdobywa punkty, ponieważ mogę kierować zasoby przydzielać i w ten sposób ograniczyć nadużycia. Używam pm.max_children, aby ograniczyć jednoczesne procesy PHP, podczas gdy pm.max_requests restartuje długo żyjące workery po X żądaniach, aby zapobiec wyciekom pamięci. request_terminate_timeout kończy zawieszanie się, które w przeciwnym razie wiązałoby pamięć RAM i chroni przed atakami hamującymi. W przypadku przesyłania ustawiłem post_max_size i upload_max_filesize, aby normalne przepływy pracy działały, ale gigantyczne pliki nie były akceptowane. W połączeniu z systemowymi cgroups dla CPU i RAM, host pozostaje responsywny nawet podczas szczytowych obciążeń.
Wydajność i bezpieczeństwo w porównaniu liczb
Bezpośrednie porównanie sterowników ujawnia praktyczne różnice namacalny. Używam poniższego przeglądu do podejmowania decyzji i kalibracji oczekiwań. Wartości opisują typowe tendencje w rzeczywistych konfiguracjach i pokazują, dlaczego FPM jest pierwszym wyborem w scenariuszach hostingu współdzielonego. CGI nadaje priorytet twardości poprzez restart, FPM równoważy izolację i szybkość, LSAPI błyszczy ze stosami LiteSpeed. To pozostaje ważne: Izolacja bez limitów jest mało pomocna, podobnie jak limity bez izolacji.
| Handler | Wydajność | Bezpieczeństwo | Zużycie pamięci RAM | Izolacja | Idealny dla |
|---|---|---|---|---|---|
| mod_php | Wysoki | Niski | Niski | Niski | Małe, proste witryny |
| CGI | Niski | Wysoki | Wysoki | Wysoki | Testy, ścisła separacja |
| FastCGI | Średni | Średni | Średni | Średni | Faza przejściowa |
| PHP-FPM | Bardzo wysoki | Wysoki | Niski | Wysoki | Hosting współdzielony, CMS |
| suPHP | Niski | Bardzo wysoki | Wysoki | Bardzo wysoki | Maksymalne bezpieczeństwo plików |
| LSAPI | Bardzo wysoki | Średni | Bardzo niski | Średni | Wysoki ruch dzięki LiteSpeed |
Z tego zestawienia wyciągam jasny wniosek KonsekwencjeW przypadku hostingu dla wielu użytkowników FPM zapewnia najlepsze ogólne bezpieczeństwo w przeliczeniu na jednostkę wydajności. CGI pozostaje opcją dla specjalnych przypadków z maksymalną separacją i niewielką liczbą żądań. Unikam mod_php w środowiskach z kilkoma klientami. LSAPI zasługuje na uwagę, gdy używany jest LiteSpeed, a pamięci RAM jest bardzo mało. Jednak w większości scenariuszy zalety oddzielnych pul FPM z wyraźnymi limitami przeważają nad wadami.
Pułapki konfiguracyjne: bezpieczne ustawienia domyślne dla stosów FPM
Wiele włamań jest spowodowanych przez Błędna konfiguracja, nie poprzez egzotyczne exploity. Dwa przełączniki są dla mnie obowiązkowe: ustawiam cgi.fix_pathinfo=0, aby uniknąć PATH_INFO traversals i ograniczyć za pomocą security.limit_extensions zakończenia wykonywalne (np. .php,.php8,.phtml). W konfiguracjach Nginx sprawdzam, czy SCRIPT_FILENAME jest ustawiona poprawnie i żadne żądania nie prześlizgują się do dowolnych ścieżek. Dezaktywuję również rzadko używane funkcje, takie jak wykonanie, shell_exec, proc_open oraz popen poprzez disable_functions. Nie jest to panaceum, ale znacznie zmniejsza efekt prostych webshelli. open_basedir Używam go bardzo selektywnie: może pomóc, ale łatwo prowadzi do efektów ubocznych z zadaniami CLI, bibliotekami do manipulacji obrazami lub Composerem. Spójna separacja ścieżek na konto i czyste prawa właściciela są lepsze.
Prawidłowe izolowanie sesji, przesyłania i katalogów tymczasowych
Wspólny Ścieżki temperatury są klasycznym sposobem na eskalację uprawnień. Dla każdej puli FPM definiuję session.save_path oraz upload_tmp_dir w specyficznym dla konta katalogu poniżej katalogu domowego, z restrykcyjnymi prawami i przyklejonym bitem tylko tam, gdzie jest to konieczne. noexec, nodev oraz nosuid na wierzchowcach zmniejszają powierzchnię ataku kolejnych poziomów. Dla sesji GC ustawiłem session.gc_probability/gc_divisor aby pliki w ramach konta można starzeć i usuwać; Odrzucam globalne wiadra sesji dla wszystkich użytkowników. Każdy, kto używa Redis do sesji, ściśle oddziela przestrzenie nazw i przypisuje oddzielne poświadczenia i limity dla każdego konta. Zapobiega to wpływowi wadliwego kodu na sesje w innych projektach.
Projektowanie gniazd, autoryzacje i hartowanie systemd
Pule FPM komunikują się za pośrednictwem gniazd. Wolę Gniazda UNIX do komunikacji lokalnej i umieść je w katalogu specyficznym dla konta za pomocą 0660 i odpowiednią grupę. Globalny 0666-gniazda są tabu. Alternatywnie, używam tylko TCP z Bind on 127.0.0.1 lub na interfejsie wewnętrznym i zaporach sieciowych. Na poziomie usługi systemd niezawodnie: NoNewPrivileges=true, ProtectSystem=ostry, ProtectHome=true, PrivateTmp=true, CapabilityBoundingSet= (puste), limity dla MemoryMax, CPUQuota, TasksMax oraz LimitNOFILE. Eliminuje to wiele ścieżek eskalacji, nawet w przypadku ataku na lukę w zabezpieczeniach aplikacji webowej. Umieszczam również pule w ich własnych wycinkach, aby stłumić hałaśliwych sąsiadów i egzekwować budżety.
CLI, cron i queue worker: taka sama izolacja jak na stronie internetowej
Często Blindspot: php-cli nie działa przez FPM. Dlatego uruchamiam cronjobs, indeksatory i kolejki robotów wyraźnie jako użytkownik powiązanego konta i używam oddzielnego php.ini na projekt (lub php_value-overrides), ograniczenia, rozszerzenia i open_basedir-ekwiwalenty. Pracownicy kolejek (np. z popularnych CMS i frameworków) otrzymują takie same budżety RAM/CPU jak procesy sieciowe, w tym strategię restartu w przypadku wycieków. W przypadku powtarzających się zadań ustawiam backoff i limity szybkości, aby wadliwy importer feedów nie blokował hosta. Parytet jest ważny: to, co jest zabronione w puli webowej, nie powinno być nagle dozwolone w CLI.
Rejestrowanie, slowlogi i backpressure
Widoczność określa, jak szybko rozpoznam atak lub błędną konfigurację. Dla każdej puli piszę własne Dzienniki błędów i aktywuj request_slowlog_timeout aksamit slowlog, aby uzyskać ślady stosu dla zawieszeń. log_limit zapobiega zalewaniu dzienników przez pojedyncze żądania. Z pm.status_path i punkt końcowy ping, monitoruję procesy, czasy oczekiwania i wykorzystanie. Na poziomie serwera WWW ustawiam Limity stawek, limity żądań i limitów czasu (odczyt nagłówka i treści), aby zapobiec przeciążeniu backendów. Baza reguł WAF może również przechwytywać trywialne wektory ataków; jednak kluczowe pozostaje, aby FPM utrzymywał powierzchnię ataku na konto na niskim poziomie, a limity niezawodnie działały.
Czyste oddzielenie wielu wersji i rozszerzeń PHP
W szczególności w przypadku hostingu współdzielonego Wersje PHP równolegle. Przechowuję własne binaria FPM, rozszerzenia i konfiguracje gotowe dla każdej wersji i wiążę je na konto do. Gniazda znajdują się w oddzielnych katalogach, aby żadne żądania nie zostały przypadkowo przekierowane do niewłaściwej puli. OPcache pozostaje oddzielny dla każdej wersji i każdego konta; revalidate_freq oraz validate_timestamps w zależności od strategii wydania. Zachowuję ostrożność w przypadku JIT: Rzadko przyspiesza typowe obciążenia CMS i zwiększa złożoność - wyłączenie go jest często bezpieczniejszym i bardziej stabilnym wyborem. Rozszerzenia ładuję minimalnie; wszystko, co nie jest absolutnie konieczne (np. pdo_mysql vs. nieużywane sterowniki), pozostaje na zewnątrz.
Model zagrożeń: typowe wektory ataku i wpływ administratora
W praktyce zawsze widzę te same wzorce: przesyłanie plików z wykonywalnymi końcówkami, niezabezpieczona deserializacja, nieczyste dane, nieczytelne pliki. PATH_INFO-przekierowanie, lokalne dołączanie plików i sztuczki z dowiązaniami symbolicznymi. FPM nie rozwiązuje tego automatycznie, ale ogranicza zakresZaatakowana pula widzi tylko swoją własną przestrzeń nazw. Z security.limit_extensions i poprawną konfigurację serwera WWW, zapobiegam interpretowaniu przesyłanych obrazów jako PHP. Oddzielne ścieżki tymczasowe i sesyjne zapobiegają sesjom między kontami i wyścigom plików tymczasowych. Wraz z restrykcyjnymi uprawnieniami do plików, umask oraz noexec-współczynnik powodzenia prostych exploitów wyraźnie spada.
Prawa do plików, Umask i koncepcje własności
Systemy plików pozostają częstym Podatność, jeśli uprawnienia są ustawione nieprawidłowo. Używam umask do regulowania domyślnych uprawnień, aby przesyłane pliki nie były zapisywalne globalnie. suPHP lub FPM z prawidłowym przypisaniem UID/GID zapewniają, że właściciel skryptu odpowiada właścicielowi pliku. Zapobiega to zmianie plików lub odczytywaniu dzienników przez procesy stron trzecich. Blokuję również wrażliwe ścieżki, ustawiam noexec na uchwytach /tmp i zmniejszam powierzchnię ataku poprzez konsekwentne oddzielanie ścieżek odczytu i zapisu.
Bezpieczne korzystanie z OPcache
Buforowanie zapewnia szybkość, ale bez czystej separacji tworzy pamięć współdzieloną Efekty uboczne. W przypadku pul FPM utrzymuję OPcache oddzielnie dla każdego konta, aby klucze i kod nie nakładały się na siebie. Aktywuję validate_timestamps w trybie deweloperskim i obniżam go tylko w produkcji dla stabilnych wdrożeń, aby zmiany w kodzie zaczęły działać poprawnie. Ponadto sprawdzam file_cache tylko w katalogu domowym konta, a nie globalnie. Jeśli korzystasz z pamięci współdzielonej, powinieneś użyć opcji Ryzyko związane z pamięcią współdzieloną i ściśle ograniczyć widoczność.
Kombinacje serwerów internetowych: Apache, Nginx, LiteSpeed
Wybór front-endu wpływa na opóźnienia, uściski dłoni TLS i obsługę żądań zauważalny. Apache z mpm_event dobrze współgra z FPM, jeśli bufor keep-alive i proxy są prawidłowe. Nginx przed FPM przekonuje statycznymi zasobami i może przenieść obciążenie, podczas gdy PHP odbiera tylko dynamiczne ścieżki. LiteSpeed z LSAPI zapewnia bardzo niskie koszty ogólne, ale pozostaje związany z innym ekosystemem. W każdym stosie obowiązują następujące zasady: czysto oddzielaj pule FPM, definiuj limity, monitoruj dzienniki i świadomie konfiguruj warstwy pamięci podręcznej.
Hartowanie: chroot, CageFS i Jails
Oprócz programów obsługi, izolacja systemu operacyjnego określa Efekt włamania. Z chroot, CageFS lub Jails, blokuję konto w jego własnym systemie plików. Oznacza to, że atakujący traci dostęp do binariów hosta i wrażliwych ścieżek urządzeń. W połączeniu z FPM na konto, tworzy to wielowarstwową obronę, która jest również skuteczna przeciwko słabościom wtyczek w systemach CMS. Jeśli chcesz porównać opcje, możesz znaleźć Porównanie obsługi PHP cenna orientacja dla kategoryzacji stosów.
Kontenery, SELinux/AppArmor i realistyczne oczekiwania
kontenery i frameworki MAC, takie jak SELinux lub AppArmor skutecznie uzupełniają FPM. Konteneryzacja pomaga powiązać zależności dla każdego projektu i ograniczyć dostęp do głównego systemu plików. Ograniczam obrazy do minimum, usuwam niepotrzebne możliwości i montuję tylko te katalogi, które są naprawdę potrzebne. Profile SELinux/AppArmor ograniczają wywołania systemowe i uniemożliwiają procesowi działanie poza jego kontekstem. Pozostaje to ważne: Kontenery nie zastępują izolacji FPM i czystych uprawnień do plików - tworzą dodatkową warstwę, która przechwytuje błędy, a nie zastępuje podstawy.
Praktyczna lista kontrolna dla gospodarzy i zespołów
W projektach zaczynam od jasnego SekwencjaNajpierw oddzielam konta technicznie, a następnie wdrażam pule FPM dla każdej domeny. Następnie ustawiam realistyczne limity, mierzę szczyty obciążenia i dostosowuję pm.max_children i pm.max_requests. Następnie sprawdzam uprawnienia do plików, zabezpieczam katalogi przesyłania i usuwam niepotrzebne uprawnienia do zapisu. Konfiguruję OPcache na pulę, aby kod, sesje i pamięci podręczne pozostały odizolowane. Na koniec testuję przełączanie awaryjne: symuluję zawieszenia, wzorce DoS i sytuacje braku pamięci, aż mechanizmy ochrony będą działać niezawodnie.
Krótkie podsumowanie
Jedno jest dla mnie pewne: FPM oferuje najlepsze Równowaga bezpieczeństwa i wydajności, zwłaszcza przy porównywaniu fpm i cgi. CGI pozostaje użyteczne, gdy absolutna separacja ma priorytet nad szybkością, ale FPM osiąga podobne cele bezpieczeństwa przy znacznie mniejszym narzucie. Dedykowane pule, twarde limity i segregowane pamięci podręczne znacznie zmniejszają ryzyko hostingu w środowiskach współdzielonych. Uzupełnione o izolację procesów, czyste uprawnienia do plików i kontrolowane wykorzystanie OPcache, host ustawia decydujące bariery ochronne. Konsekwentne łączenie tych elementów skutecznie chroni projekty, jednocześnie utrzymując niskie czasy reakcji.
