Krótko: Monitoring bezpieczeństwa serwera oznacza stałą obserwację serwerów WWW pod kątem oznak ataku, zamiast reagować dopiero wtedy, gdy skarżą się klienci. Nadzorujemy pliki, procesy, logowania, połączenia i logi Państwa serwerów PHP oraz w zrozumiały sposób oceniamy każdą nieprawidłowość. Dzięki temu wcześniej rozpoznają Państwo problemy, a w razie potrzeby dysponują potrzebnymi śladami.
Dlaczego monitoring bezpieczeństwa serwera ma znaczenie właśnie teraz
PHP2Shell pokazało, jak szybko nowa luka może stać się zagrożeniem dla milionów serwerów. Unit 42 naliczyło ponad 22,6 miliona wystawionych na dostęp, potencjalnie podatnych instancji. Jednocześnie nie ma opublikowanych, potwierdzonych wskaźników naruszenia (Indicators of Compromise). Kto chce wiedzieć, czy na jego serwerze coś się dzieje, musi zwracać uwagę na zachowanie.
Wiele włamań wykrywa się późno, często przez osoby trzecie: ostrzeżenie Google, blokadę dostawcy hostingu z powodu wysyłania spamu, sygnał od klienta. Do tego czasu logi są często zrotowane, a ślady utracone. Monitoring bezpieczeństwa skraca ten czas i sprawia, że dzienniki nadal istnieją, gdy są potrzebne. Dla zarządu oznacza to przede wszystkim jedno: decyzje w razie incydentu opierają się na faktach, a nie na przypuszczeniach.
Co nadzorujemy
| Obszar | Na co zwracamy uwagę |
|---|---|
| Pliki | nowe lub zmienione pliki PHP, wykonywalny kod w folderach uploadów, zmiany w .htaccess i konfiguracji |
| Procesy | polecenia uruchamiane z workerów PHP, nieznane procesy stałe, awarie workerów |
| Logowania | logowania SSH i do panelu, nowe konta administratorów w CMS, nagromadzone nieudane próby |
| Sieć | nietypowe połączenia wychodzące, nagła wysyłka poczty, nowe otwarte porty |
| Logi | podejrzane wzorce żądań, nagromadzenie błędów, luki w rejestrowaniu |
| Stan | wersje PHP, CMS i pakietów w porównaniu ze znanymi aktualizacjami bezpieczeństwa |
Jak ręcznie sprawdzić takie sygnały, opisuje strona Analiza logów serwera WWW po ataku. Dla dostępów administracyjnych zalecamy dodatkowo środki z Ochrona logowań administratora przed Brute Force.
Jak konkretnie pomaga PHP SOS?
- Rozpoznanie stanu wyjściowego: Rejestrujemy serwery, aplikacje, istniejące dzienniki i dotychczasowy nadzór oraz ustalamy, co jest normalne. Bez tego stanu wyjściowego nieprawidłowości nie da się pewnie rozpoznać.
- Konfiguracja nadzoru: Konfigurujemy kontrolę integralności plików, przekazywanie logów do oddzielnego miejsca przechowywania i reguły dla typowych skutków ataku. Logi leżą tak, aby atakujący na serwerze WWW nie mógł ich po prostu usunąć.
- Dostrojenie: W pierwszych tygodniach dopasowujemy reguły, aby nie zalewały Państwa fałszywe alarmy, na przykład z powodu regularnych aktualizacji lub wdrożeń.
- Zgłaszanie i ocena: Nieprawidłowości zgłaszamy wraz z oceną: co zaobserwowano, jak prawdopodobny jest atak i co zrobić dalej.
- Raportowanie: W regularnych odstępach otrzymują Państwo podsumowanie ze zdarzeniami, otwartymi aktualizacjami i zaleceniami.
Proszę przechowywać logi w oddzielnym systemie. Przy PHP2Shell prasa branżowa radzi zabezpieczyć logi serwera od 20.10.2026. Kto przechowuje je centralnie, ma je również wtedy, gdy serwer WWW trzeba postawić od nowa.
Jak wygląda nasze zgłoszenie
Ostrzeżenie jest użyteczne tylko wtedy, gdy się je rozumie. Dlatego każde zgłoszenie zawiera te same elementy:
- Co zaobserwowano? Na przykład: w folderze uploadów strony powstał nowy plik PHP, a krótko potem worker PHP nawiązał połączenie wychodzące z nieznanym adresem.
- Jak to oceniamy? Udowodniony jest nowy plik i połączenie. Prawdopodobny jest związek. Nieznane jest, czy dane zostały przesłane.
- Co już zrobiliśmy? Na przykład zabezpieczyliśmy plik i, jeśli uzgodniono, przełączyliśmy stronę w tryb konserwacji.
- Co muszą Państwo rozstrzygnąć? Na przykład czy strona ma pozostać offline do wyjaśnienia przyczyny.
Zdarzenia nieszkodliwe, na przykład regularną aktualizację wtyczki, rozpoznajemy po stanie wyjściowym i ujmujemy w raporcie, zamiast obciążać Państwa każdym z osobna. Z czasem nadzór coraz lepiej poznaje Państwa systemy.
Co Państwo otrzymują i czego potrzebujemy
Otrzymują Państwo skonfigurowany nadzór z udokumentowanymi regułami, zrozumiałe zgłoszenia z zaleceniem działania, regularne raporty i centralne miejsce przechowywania dzienników. W razie potwierdzonego incydentu dane trafiają bezpośrednio do Incident Response.
Od Państwa potrzebujemy:
- dostępu administratora do serwerów, aby skonfigurować agentów i przekazywanie logów
- przeglądu aplikacji, planowanych wdrożeń i okien serwisowych
- osoby kontaktowej, która przyjmuje zgłoszenia i może podejmować decyzje
- uzgodnienia z inspektorem ochrony danych, ponieważ logi mogą zawierać dane osobowe, takie jak adresy IP
Czego nie obiecujemy
Monitoring nie wykrywa każdego ataku. Zręczni atakujący starają się pozostać niezauważeni, a niektóre luki zostawiają niewiele śladów. Monitoring zwiększa prawdopodobieństwo wczesnego zauważenia włamania i dostarcza wiarygodnych danych. Nie zastępuje ani aktualizacji, ani utwardzania.
Czasów reakcji także nie ustalamy ryczałtowo; zależą od uzgodnionej opieki. Monitoring najlepiej wykazuje swoją użyteczność jako część umowy serwisowej bezpieczeństwa, w której aktualizacje, kopie zapasowe i nadzór są uregulowane łącznie.
Częste pytania
Jaka jest różnica między zwykłym monitoringiem a monitoringiem bezpieczeństwa?
Zwykły monitoring sprawdza, czy serwer jest osiągalny i ma dość zasobów. Monitoring bezpieczeństwa zwraca uwagę na oznaki ataku, takie jak nowe pliki wykonywalne, nietypowe procesy czy obce logowania. Oba uzupełniają się.
Czy monitoring wykryje atak przez PHP2Shell?
Nie ma opublikowanych, potwierdzonych wskaźników naruszenia (Indicators of Compromise) dla PHP2Shell. Monitoring może jednak uwidocznić typowe skutki włamania, takie jak nowe pliki PHP lub polecenia uruchamiane z procesu PHP. Nie ma gwarancji skuteczności.
Czy muszę w tym celu instalować oprogramowanie na serwerze?
Zazwyczaj tak, na przykład agenta do integralności plików i przekazywania logów. Jakich narzędzi używamy, uzgadniamy z Państwem i w razie potrzeby z Państwa dostawcą hostingu, aby pasowały do eksploatacji i ochrony danych.
Czy monitoring bezpieczeństwa działa także przy hostingu współdzielonym?
Tylko w ograniczonym zakresie. Bez dostępu do procesów i dzienników systemowych pozostaje przede wszystkim nadzór nad plikami i treściami z zewnątrz. Pełny nadzór wymaga własnego lub zarządzanego serwera.