# Incident Response przy atakach na serwery

> Incident Response przy atakach na serwery: przejmujemy triage, powstrzymanie, oczyszczanie i przywracanie z jasnymi rolami oraz udokumentowanym przebiegiem.

Źródło: https://phpsos.de/pl/leistungen/incident-response/  
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:** Jeśli atak dotyczy więcej niż jednej strony, potrzebują Państwo usługodawcy Incident Response, który uporządkowanie obsłuży incydent. Przejmujemy obraz sytuacji, powstrzymanie, oczyszczanie i bezpieczne przywrócenie działania, z jasnymi rolami i pełną dokumentacją. Decyzje pozostają po Państwa stronie, my zapewniamy podstawę techniczną.

## Co oznacza Incident Response przy atakach na serwery

Incident Response to uporządkowana obsługa incydentu bezpieczeństwa. Zamiast gorączkowych pojedynczych działań praca przebiega według stałych faz: rozpoznać i sklasyfikować, powstrzymać, usunąć, przywrócić, podsumować. Każdy środek jest odnotowywany wraz z czasem i uzasadnieniem.

Szczególnie przy serwerach WWW ma to znaczenie. Serwer z aplikacjami PHP zawiera często dane dostępowe do baz danych, operatorów płatności, serwerów pocztowych i interfejsów. Kto się tam włamał, może przemieszczać się dalej. Sytuacja po PHP2Shell pokazuje, jak szybko może powstać taka sytuacja: nieuwierzytelnione wykonanie kodu, ponad 22,6 miliona wystawionych instancji według Unit 42 i brak opublikowanych, potwierdzonych wskaźników naruszenia (Indicators of Compromise).

## Kiedy potrzebują Państwo usługodawcy Incident Response

- dotknięte są lub mogą być dotknięte kilka serwerów lub aplikacji
- istnieje podejrzenie wycieku danych osobowych lub danych płatniczych
- atakujący może być jeszcze aktywny, na przykład przez trwające połączenia lub nowe konta
- pojawił się szantaż lub publiczna zapowiedź ataku
- ubezpieczyciel, organy lub partnerzy biznesowi oczekują udokumentowanego przebiegu

Przy pojedynczej zainfekowanej stronie często wystarcza [pomoc awaryjna przy zhakowanej stronie](https://phpsos.de/pl/leistungen/website-gehackt-notfallhilfe/). Przejście do pełnej obsługi incydentu omawiamy z Państwem, gdy tylko zarysuje się większy zakres.

## Jak konkretnie pomaga PHP SOS?

1. **Triage i obraz sytuacji:** Ustalamy, co zaobserwowano, które systemy i dane mogą być dotknięte oraz kogo trzeba zaangażować wewnętrznie. Wynikiem jest pierwszy, pisemny obraz sytuacji z otwartymi pytaniami.
2. **Zabezpieczenie śladów i powstrzymanie:** Logi, systemy plików i bazy danych są zabezpieczane, zanim zaingerujemy. Następnie izolujemy dotknięte systemy, blokujemy przejęte dostępy i przerywamy rozpoznawalne połączenia atakującego.
3. **Usunięcie:** Zamykamy drogę włamania, na przykład przez łatanie do naprawionych wersji PHP i restart wszystkich workerów, usuwamy tylne furtki i wymieniamy sekrety. Do szczegółowej analizy w razie potrzeby angażujemy wyspecjalizowanych partnerów od [informatyki śledczej](https://phpsos.de/pl/leistungen/it-forensik/).
4. **Przywrócenie:** Systemy wracają do pracy w sposób kontrolowany, w miarę możliwości z czystych źródeł lub na nowo postawionych serwerach. Następnie nadzorujemy je ze zwiększoną uwagą pod kątem ponownych nieprawidłowości.
5. **Podsumowanie:** Otrzymują Państwo raport końcowy z osią czasu, przyczynami, środkami i zaleceniami. Wspólnie ustalamy, co następnym razem ma pójść szybciej.

> **Działać natychmiast:**
> Proszę zachować logi serwera i nie zmieniać systemów, zanim nie zostaną zabezpieczone. Przy PHP2Shell BSI zaleca czasowe odłączenie od sieci serwerów WWW, których nie da się od razu załatać.

## Role i komunikacja w trakcie incydentu

Incydent wymaga jasnych odpowiedzialności. Sprawdza się niewielki zespół złożony z osoby uprawnionej do decyzji, technicznej osoby kontaktowej po Państwa stronie i nas jako kierownictwa technicznego. Odprawy dotyczące sytuacji odbywają się w stałych odstępach, a wyniki są odnotowywane na piśmie.

Równolegle toczą się zadania, których nie przejmujemy, ale dla których dostarczamy fakty: ocena [obowiązku zgłoszenia na podstawie RODO w ciągu 72 godzin](https://phpsos.de/pl/compliance/dsgvo-meldepflicht-72-stunden/), poinformowanie ubezpieczyciela, ewentualne zawiadomienie oraz [komunikacja kryzysowa](https://phpsos.de/pl/compliance/krisenkommunikation/) wobec klientów i partnerów.

## Czego potrzebujemy od Państwa i co otrzymują Państwo

Potrzebujemy dostępów administracyjnych do dotkniętych systemów, przeglądu infrastruktury i usługodawców, osoby uprawnionej do decyzji oraz gotowości do czasowego wyłączenia systemów w razie potrzeby. Pomocne są istniejące plany awaryjne, szkice sieci i kopie zapasowe z datą.

Otrzymują Państwo bieżący protokół incydentu, regularne obrazy sytuacji w zrozumiałym języku, raport końcowy dla zarządu, inspektora ochrony danych i ubezpieczyciela oraz listę ulepszeń z priorytetami. Jak lepiej przygotować się na kolejny incydent, opisuje strona [Opracowanie planu awaryjnego IT dla serwerów WWW](https://phpsos.de/pl/compliance/notfallplan-erstellen/).

## Typowe błędy w pierwszych godzinach

Wiele incydentów staje się cięższych, ponieważ w pośpiechu dobrze zamierzone kroki wykonywane są w niewłaściwej kolejności. Te wzorce widzimy często:

- **Natychmiastowa ponowna instalacja:** Serwer jest kasowany i instalowany od nowa, zanim wykonano kopię zabezpieczającą. Potem nie da się już wyjaśnić, czy dane wyciekły.
- **Zmiana haseł z zainfekowanego systemu:** Jeśli atakujący nadal ma dostęp, widzi też nowe hasła.
- **Usunięcie tylko widocznego pliku:** Webshell znika, druga tylna furtka w zadaniu cron pozostaje.
- **Łatanie bez restartu:** Nowe pliki PHP leżą na dysku, a stare workery nadal działają w pamięci.
- **Nikt nie prowadzi protokołu:** Później nikt nie wie, kto i kiedy co zmienił. Utrudnia to rozmowy z ubezpieczycielem i organami.

Uzgodniony przebieg zapobiega tym błędom, nie opóźniając powstrzymania ataku.

## Czego nie obiecujemy

Nie obiecujemy, że każdy incydent zostanie w pełni wyjaśniony; bez śladów pewne pytania pozostają otwarte i tak zapisujemy to w raporcie. Nie udzielamy porad prawnych ani nie wypowiadamy się w kwestii odpowiedzialności czy ochrony ubezpieczeniowej. Naszym celem jest jasne zakończenie: pracujemy nad incydentem, aż zostanie zamknięty i udokumentowany.


## Częste pytania

**Jaka jest różnica między Incident Response a informatyką śledczą?**  
Celem Incident Response jest powstrzymanie incydentu i bezpieczne przywrócenie działania. Informatyka śledcza wyjaśnia szczegółowo i w sposób zabezpieczający dowody, co się stało. W praktyce oba obszary zazębiają się, a informatyka śledcza często zabezpiecza ślady równolegle.

**Kiedy powinienem zaangażować usługodawcę Incident Response?**  
Gdy tylko pojawi się podejrzenie, że atakujący miał dostęp do systemów, a nie mogą Państwo pewnie ocenić zakresu. Im wcześniej rozpocznie się zabezpieczanie śladów, tym więcej da się później udowodnić.

**Kto podejmuje decyzje w trakcie incydentu?**  
Decyzje podejmują Państwo, na przykład o wyłączeniach, komunikacji lub zgłoszeniach. My przygotowujemy podstawy techniczne, pokazujemy opcje wraz z ich skutkami i wdrażamy decyzje.

**Czy muszę angażować policję?**  
Zawiadomienie jest w wielu przypadkach sensowne i dla niektórych ubezpieczycieli istotne. Za to odpowiadają centralne punkty kontaktowe ds. cyberprzestępczości policji. Czy i kiedy złożyć zawiadomienie, decydują Państwo wraz z prawnikiem.

## Źródła

- [BSI: Federalny Urząd ds. Bezpieczeństwa Informacji (Niemcy)](https://www.bsi.bund.de/)
- [RODO art. 33: zgłoszenie do organu nadzorczego](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Policja: centralne punkty kontaktowe ds. cyberprzestępczości (Niemcy)](https://www.polizei.de/)
- [BSI: IT-Grundschutz (Niemcy)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)