# Utwardzanie serwerów WWW z PHP > Utwardzanie serwera dla PHP: izolujemy strony, bezpiecznie ustawiamy php.ini, uprawnienia i dostępy oraz dokumentujemy każdą zmianę na Państwa serwerach WWW. Źródło: https://phpsos.de/pl/leistungen/server-haertung/ Stan: 25.10.2026 Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6 **Krótko:** Kto chce utwardzić serwer dla PHP, dba o to, aby pojedyncza luka nie otwierała całego serwera. Izolujemy strony od siebie, bezpiecznie konfigurujemy PHP i serwer WWW, ograniczamy uprawnienia i dostępy oraz dokumentujemy każdą zmianę. Dzięki temu szkoda jest mniejsza, jeśli mimo wszystko coś się wydarzy. ## Dlaczego utwardzanie stało się ważniejsze po PHP2Shell PHP2Shell pokazało, jak szybko luka w samym PHP staje się problemem dla wszystkich stron na serwerze. Przez CVE-2026-109618 i CVE-2026-109619 atakujący mogą wykonać kod bez logowania. Poprawka zamyka te drzwi. Utwardzanie odpowiada na inne pytanie: co może zrobić ktoś, kto mimo to się dostanie, przez tę lub następną lukę? Na nieutwardzonym serwerze wszystkie strony często działają pod tym samym użytkownikiem, PHP może wykonywać polecenia systemowe, a dane dostępowe leżą czytelnie dla wszystkich procesów. Włamanie na małą stronę poboczną sięga wtedy aż do sklepu internetowego. Dobre utwardzenie rozdziela te obszary. Nie jest to jednorazowe działanie, lecz stan podstawowy, który musi być zachowany przy każdej nowej stronie i każdej zmianie wersji. ## Utwardzanie serwera dla PHP: co konkretnie dostosowujemy ### Izolacja każdej strony Każda strona otrzymuje własnego użytkownika systemowego i własną pulę PHP-FPM. Dzięki `open_basedir` i odpowiednim uprawnieniom plików aplikacja widzi tylko własny katalog. Więcej na ten temat: [open_basedir i izolacja każdej strony](https://phpsos.de/pl/ratgeber/open-basedir/). ### Bezpieczna konfiguracja PHP Ustawiamy php.ini i konfigurację puli tak, aby aplikacje nie mogły same nadpisywać wartości istotnych dla bezpieczeństwa. Fragment, jak może wyglądać w puli FPM: ```ini ; Wartości w puli FPM ustawione na stałe, nie do zmiany przez ini_set() php_admin_flag[expose_php] = off php_admin_flag[display_errors] = off php_admin_flag[log_errors] = on php_admin_value[open_basedir] = /var/www/kunde1/:/tmp/ php_admin_flag[session.upload_progress.enabled] = off php_admin_flag[allow_url_include] = off ``` To, które funkcje można dodatkowo zablokować, zależy od aplikacji. Wskazówki znajdą Państwo na stronach [Bezpieczna konfiguracja php.ini](https://phpsos.de/pl/ratgeber/php-ini-sicher-konfigurieren/) i [Prawidłowe użycie disable_functions](https://phpsos.de/pl/ratgeber/disable-functions/). ### Uprawnienia plików i dostęp do zapisu Serwer WWW może zapisywać tylko tam, gdzie jest to konieczne, na przykład w folderze uploadów. W katalogach uploadów wykonywanie PHP jest blokowane. Kod programu należy do innego użytkownika niż ten, pod którym działa PHP. Zasady wyjaśnia strona [Uprawnienia plików na serwerze WWW](https://phpsos.de/pl/ratgeber/dateirechte-webserver/). ### Dostępy, usługi i logi SSH tylko z kluczem, interfejsy administracyjne z uwierzytelnianiem dwuskładnikowym, niepotrzebne usługi i porty zamknięte. Logi są przechowywane i zabezpieczane tak, aby po incydencie nadal były dostępne. Kopie zapasowe sprawdzamy pod kątem możliwości odtworzenia. ### Serwer WWW i nagłówki bezpieczeństwa Do utwardzania należy także sam serwer WWW: ukrycie informacji o wersji, wyłączenie listowania katalogów, zablokowanie dostępu do plików konfiguracyjnych, kopii zapasowych i systemu kontroli wersji oraz dodatkowe zabezpieczenie obszarów administracyjnych, na przykład przez zezwolenie tylko dla wybranych adresów IP. Nagłówki bezpieczeństwa, takie jak Content-Security-Policy czy HSTS, chronią odwiedzających Państwa stronę w przeglądarce. ## Co często znajdujemy podczas inwentaryzacji Wiele słabych punktów powtarza się od serwera do serwera. Typowe są: kilka stron pod wspólnym użytkownikiem, publicznie dostępne interfejsy baz danych, stare instalacje testowe w podkatalogach, zapomniane wersje PHP obok aktualnej oraz kopie zapasowe leżące w katalogu WWW i możliwe do pobrania. Często brakuje też jakiegokolwiek rejestrowania logowań albo logi są usuwane po kilku dniach. Żaden z tych punktów sam w sobie nie jest spektakularny. Razem decydują jednak o tym, czy włamanie pozostanie ograniczone do jednej strony, czy obejmie cały serwer. ## Jak konkretnie pomaga PHP SOS? 1. **Inwentaryzacja:** Rejestrujemy system operacyjny, serwer WWW, wersje PHP, strony, użytkowników, otwarte usługi i istniejące kopie zapasowe. 2. **Plan działań:** Otrzymują Państwo listę z priorytetami, nakładem pracy i możliwymi skutkami dla każdego punktu. To Państwo decydują, co zostanie wdrożone. 3. **Wdrożenie krokami:** Zmieniamy konfiguracje po uzgodnieniu, po każdym kroku testujemy strony i odnotowujemy, jak można cofnąć każdą zmianę. 4. **Kontrola:** Po wdrożeniu sprawdzamy skutek, na przykład czy strona rzeczywiście nie może już czytać obcych katalogów. 5. **Przekazanie:** Otrzymują Państwo dokumentację nowego stanu, zrozumiałą także dla Państwa dostawcy hostingu lub agencji. ## Co Państwo otrzymują i czego potrzebujemy Otrzymują Państwo raport z utwardzania ze stanem wyjściowym, wdrożonymi środkami, świadomie pozostawionymi otwartymi punktami wraz z uzasadnieniem oraz zaleceniem dotyczącym regularnej kontroli. Zmiany w plikach konfiguracyjnych są udokumentowane w sposób umożliwiający ich prześledzenie. Od Państwa potrzebujemy: - **dostępu root lub administratora** do serwera, a przy panelach dodatkowo dostępu do panelu - **listy aplikacji** i ich osobliwości, na przykład uploadów, interfejsów, zadań cron - **technicznej osoby kontaktowej**, która może potwierdzać funkcje po zmianach - **okien serwisowych** na restarty - **aktualnej kopii zapasowej** lub zlecenia jej wcześniejszego wykonania ## Czego nie obiecujemy Utwardzanie nie czyni serwera nie do zaatakowania. Zmniejsza powierzchnię ataku i ogranicza szkody, ale nie zastępuje ani aktualizacji, ani monitorowania. Niezałatana wersja PHP pozostaje podatna, niezależnie od tego, jak dobrze ustawiono resztę. Dlatego łączymy utwardzanie z [usługą łatania PHP](https://phpsos.de/pl/leistungen/php-patch-service/), a następnie zalecamy stałą opiekę w ramach [umowy serwisowej bezpieczeństwa](https://phpsos.de/pl/leistungen/security-wartungsvertrag/). Przy hostingu współdzielonym wiele rzeczy nie daje się ustawić, ponieważ konfigurację narzuca dostawca hostingu. Wtedy pokazujemy, co jest możliwe w ramach Państwa pakietu i gdzie sensowne byłoby przejście na własny lub zarządzany serwer. ## Częste pytania **Co oznacza utwardzanie serwera?** Utwardzanie oznacza wyłączenie lub ograniczenie wszystkiego, co nie jest potrzebne do działania. Należą do tego zbędne usługi, zbyt szerokie uprawnienia, otwarte porty i niebezpieczne ustawienia domyślne. Celem jest, aby pojedynczy błąd nie otwierał od razu całego serwera. **Czy utwardzanie zapobiegłoby PHP2Shell?** Nie, przed luką w samym PHP chroni tylko poprawka. Utwardzanie ogranicza jednak to, co atakujący może osiągnąć po udanym włamaniu, na przykład czy może uzyskać dostęp do innych stron lub danych dostępowych. **Czy przez utwardzanie moja strona przestanie działać?** Takie ryzyko istnieje, jeśli ustawienia są zmieniane bez testów. Wdrażamy zmiany krok po kroku, po każdym kroku sprawdzamy funkcje i odnotowujemy, jak można cofnąć każdą zmianę. **Jak często należy weryfikować utwardzenie?** Najpóźniej po większych aktualizacjach, zmianie wersji PHP lub nowych aplikacjach na serwerze. Sensowna jest regularna kontrola w ramach bieżącej konserwacji. ## Źródła - [BSI: IT-Grundschutz (Niemcy)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html) - [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/) - [php.net: komunikaty o bezpieczeństwie](https://www.php.net/)