Krótko: Inwentarz IT serwerów WWW to lista wszystkich stron, portali, sklepów i serwerów z danymi, które są potrzebne od razu przy komunikacie bezpieczeństwa: gdzie działa system, z jaką wersją i trybem pracy PHP, jaka aplikacja, kto odpowiada i jakie dane byłyby dotknięte. Bez tej listy każda reakcja zaczyna się od szukania. Z nią porównanie przy komunikacie takim jak PHP2Shell zajmuje minuty zamiast dni.
Pierwsze pytanie brzmiało: gdzie u nas w ogóle działa PHP?
Gdy 21.10.2026 projekt PHP opublikował poprawki, a BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej) zaleciło natychmiastowe działanie, polecenie było jednoznaczne: zaktualizować PHP, zrestartować wszystkie procesy. Mimo to dla wielu firm pierwszym krokiem nie była aktualizacja, lecz inwentaryzacja. Strona główna była znana. Ale portal dla handlowców? Strona kariery u innego dostawcy? Landing page z kampanii sprzed trzech lat? Wewnętrzna wiki?
Prasa branżowa i usługi pomiarowe uwidoczniły skalę problemu. Palo Alto Networks (Unit 42) naliczyło ponad 22,6 mln narażonych, potencjalnie podatnych instancji. Wśród nich jest zapewne wiele systemów, o których ich operatorzy po prostu już nie pamiętają.
Co należy do inwentarza IT serwerów WWW
Przydatny inwentarz to tabela z jednym wierszem na każdą stronę lub aplikację. Sprawdziły się te kolumny:
| Kolumna | Przykład | Po co |
|---|---|---|
| Adres | shop.beispiel.de | jednoznaczne przyporządkowanie |
| Cel i znaczenie | sklep internetowy, krytyczny dla przychodów | ustalanie priorytetów |
| Firma hostingowa lub lokalizacja | serwer zarządzany u dostawcy X | do kogo dzwonić |
| Serwer i system operacyjny | vServer, Debian | droga aktualizacji, źródła informacji o bezpieczeństwie |
| Serwer WWW i tryb pracy PHP | Nginx z PHP-FPM | ryzyko, np. mod_php |
| Wersja PHP i stan pakietu | 8.3, pakiet z datą | porównanie z komunikatami |
| Aplikacja i wersja | Shopware, wtyczki | komunikaty producenta |
| Odpowiedzialny wewnętrznie / zewnętrznie | kierownik IT / agencja Y | kto działa |
| Przetwarzane dane | konta klientów, zamówienia | obowiązki zgłoszeniowe, pilność |
| Kopie zapasowe | codziennie, zewnętrznie, ostatnio przetestowane dnia … | odtworzenie |
| Ostatni dowód poprawki | data i dokument | dowód wobec osób trzecich |
Tryb pracy zasługuje na szczególną uwagę. Przy PHP2Shell zespół PHP ocenił ryzyko jako najwyższe w przypadku Apache z mod_php. Kto wie, które systemy tak działają, może zająć się nimi najpierw. Kolumna ze stanem pakietu jest ważna, ponieważ wyświetlany numer wersji po backportach często pozostaje taki sam; wskazówki na ten temat znajdują się w artykule Jak prawidłowo sprawdzić wersję PHP i stan poprawek.
Jak znaleźć zapomniane systemy
Znane systemy wpisuje się szybko. Prawdziwa praca to te nieznane. Pomagają w ich wyszukaniu następujące źródła:
- Domeny i DNS: Przejrzeć wszystkie domeny firmy i ich subdomeny. Każdy wpis wskazujący na serwer WWW jest kandydatem.
- Faktury: Księgowość zna każdą firmę hostingową, rejestratora i dostawcę chmury, który dostaje pieniądze. To często najpełniejsza lista.
- Agencje i działy merytoryczne: Marketing, sprzedaż i dział personalny chętnie zlecają strony bezpośrednio. Proszę zapytać.
- Znane serwery: Na każdym serwerze konfiguracja pokazuje, jakie strony faktycznie obsługuje.
- Urządzenia z interfejsem WWW: NAS-y, routery i urządzenia typu appliance mają czasem własne PHP, zob. PHP na NAS-ach, routerach i urządzeniach appliance.
Do kroku 4 na serwerach z Linuksem pomaga kilka poleceń tylko do odczytu. Pokazują skonfigurowane strony, usługi PHP i pule FPM:
# Skonfigurowane strony (Apache lub Nginx)
apachectl -S 2>/dev/null
nginx -T 2>/dev/null | grep -E "^\s*server_name" | sort -u
# Działające usługi i procesy PHP
systemctl list-units --type=service | grep -iE "php|fpm|lsws|litespeed"
ps -eo user,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep | sort | uniq -c
# Pule FPM w Debianie i Ubuntu
ls /etc/php/*/fpm/pool.d/ 2>/dev/null
Jeśli na jednym serwerze działa obok siebie kilka wersji PHP, każda należy do listy. Każdą trzeba zaktualizować i zrestartować osobno.
Proszę wpisywać także systemy, które właściwie powinny zostać wyłączone. Właśnie one często nadal działają, od lat nie są aktualizowane i zostają zapomniane. Wpis „wyłączyć do …” sprawia, że zadanie pozostaje widoczne.
Utrzymanie inwentarza w aktualnym stanie
Inwentarz jest tak dobry, jak jego ostatnia aktualizacja. Trzy zasady utrzymują go przy życiu. Po pierwsze: jedna osoba jest odpowiedzialna i jest informowana o każdej nowej stronie, każdej przeprowadzce i każdym wyłączeniu, także gdy pracę wykonuje agencja. Po drugie: raz na kwartał lista jest porównywana z DNS, fakturami i konfiguracją serwerów. Po trzecie: inwentarz jest częścią planu awaryjnego i jest dostępny także poza własnym działem IT, na przykład w wydruku.
Dla firm z wieloma rozproszonymi systemami, na przykład portalami dla handlowców, konfiguratorami i dostępami dla dostawców, typowe miejsca znalezisk opisuje artykuł Bezpieczeństwo IT dla średnich firm i przemysłu. Jak włączyć inwentarz do planu awaryjnego, wyjaśnia artykuł Jak sporządzić plan awaryjny IT dla serwerów WWW.
Częste błędy w inwentarzu serwerów WWW
Wiele inwentarzy istnieje, ale w razie awarii nie pomaga. Przyczyny są podobne:
- Tylko serwery, bez stron: Lista wymienia maszyny, ale nie to, jakie strony na nich działają i kto odpowiada za nie merytorycznie. Przy luce nikt nie wie, który dział jest dotknięty.
- Wersja zamiast stanu pakietu: „PHP 8.3” po PHP2Shell mówi niewiele. Dopiero stan pakietu i data pokazują, czy poprawka jest zawarta.
- Brak systemów zewnętrznych: To, co działa u agencji lub dostawcy platformy, bywa pomijane, ponieważ „nie odpowiadamy tam za to”. Odpowiedzialność za dane mimo to pozostaje w firmie.
- Brak osób kontaktowych: Wpis bez nazwiska i numeru telefonu odpowiedzialnej osoby traci w razie awarii czas.
- Jednorazowa akcja: Inwentarz powstaje w tygodniu kryzysowym i potem nigdy nie jest otwierany. Po roku spora część już się nie zgadza.
Kto unika tych pięciu błędów, przy następnym komunikacie ma listę, z którą naprawdę można pracować.
Jak konkretnie pomaga PHP SOS?
- Razem z Państwem rejestrujemy wszystkie strony i serwery, także zapomniane, na podstawie DNS, faktur, usługodawców i konfiguracji serwerów.
- Ustalamy dla każdego systemu tryb pracy, wersję PHP i rzeczywisty stan pakietu.
- Priorytetyzujemy systemy według dostępności, danych i trybu pracy i mówimy, gdzie trzeba działać najpierw.
- Tam, gdzie PHP2Shell jest nadal otwarte, zamykamy lukę w ramach natychmiastowej pomocy przy PHP2Shell i wpisujemy dowód do inwentarza.
Podsumowanie: Inwentarz to najmniej efektowny i zarazem najskuteczniejszy środek bezpieczeństwa. Kto wie, co działa, przy następnym komunikacie może od razu działać, zamiast najpierw szukać.
Częste pytania
Jakie dane są minimum w inwentarzu serwerów WWW?
Adres strony, serwer lub firma hostingowa, tryb pracy PHP, wersja PHP ze stanem pakietu, aplikacja z wersją, osoba odpowiedzialna wewnętrznie i zewnętrznie, rodzaj przetwarzanych danych oraz miejsce kopii zapasowych. Dzięki tym danym każdy nowy komunikat bezpieczeństwa można szybko porównać z systemami.
Jak znaleźć strony, o których nikt już nie wie?
Kilkoma drogami jednocześnie: zarządzanie domenami i strefy DNS, faktury od firm hostingowych i rejestratorów, pytania do agencji i działów merytorycznych oraz konfiguracja znanych serwerów. Stare strony kampanii, systemy testowe i subdomeny zwykle w ten sposób się pojawiają.
Kto powinien prowadzić inwentarz?
Wskazana osoba, zwykle w dziale IT lub u kierownika IT. Ważne, aby każda zmiana dotycząca stron i serwerów była tam zgłaszana, także wtedy, gdy zleca ją dział merytoryczny lub agencja.
Czy wystarczy tabela, czy potrzebne jest oprogramowanie?
W większości średnich firm wystarczy dobrze prowadzona tabela. Oprogramowanie opłaca się, gdy wiele systemów ma być rejestrowanych automatycznie. Decydująca jest aktualność, a nie narzędzie.