# Lista kontrolna po włamaniu: 20 punktów na etap po incydencie

> Lista kontrolna po zhakowaniu strony: 20 punktów od ograniczenia szkód i zabezpieczenia dowodów przez oczyszczenie i nowe dostępy po obowiązki.

Źródło: https://phpsos.de/pl/ratgeber/checkliste-nach-dem-hack/  
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 Państwa strona została zhakowana, ta lista kontrolna pomaga o niczym nie zapomnieć: najpierw ograniczyć szkody i zabezpieczyć dowody, potem znaleźć przyczynę i oczyścić, następnie odnowić wszystkie dostępy, sprawdzić obowiązki i zamknąć incydent z dokumentacją. Kolejność jest ważna, ponieważ kto najpierw usuwa, traci ślady, a kto tylko oczyszcza, nie zamykając luki, zostanie zaatakowany ponownie.

## Do czego służy ta lista kontrolna, gdy strona została zhakowana

Lista kontrolna jest przeznaczona dla zarządu, właścicieli i osób odpowiedzialnych za IT po potwierdzonym lub prawdopodobnym ataku na stronę, sklep lub serwer WWW z PHP. Nadaje się też po PHP2Shell, gdy serwer był dostępny przed aktualizacją i istnieją wskazówki na kompromitację.

Nie każdy punkt pasuje do każdego środowiska. Mimo to proszę przejść listę w całości i przy każdym punkcie zanotować, czy jest wykonany, nie dotyczy, czy otwarty. Ten protokół jest później cenny dla ubezpieczenia, ochrony danych i wewnętrznego podsumowania.

Do każdego kroku proszę wpisać datę, godzinę, osobę odpowiedzialną i wynik. Jeśli zaangażowanych jest kilka osób, proszę wyznaczyć jedną, która prowadzi listę i odnotowuje decyzje.

## Faza 1: natychmiast ograniczyć i zabezpieczyć

1. **Ograniczyć szkodę:** przełączyć stronę w tryb konserwacji lub odłączyć od sieci, jeśli zagrożeni są odwiedzający albo mogą wyciekać dane. BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa Informacji) zaleca przy PHP2Shell tymczasowe odłączenie niezałatanych serwerów WWW od sieci, jeśli aktualizacja nie jest możliwa od razu.
2. **Niczego nie usuwać:** nie kasować plików, nie stawiać serwera od nowa i nie czyścić logów, zanim ślady nie zostaną zabezpieczone.
3. **Zabezpieczyć logi:** skopiować logi dostępu, błędów, PHP-FPM i systemowe do innego systemu i zapisać sumy kontrolne. W sprawie PHP2Shell prasa branżowa radzi przechowywać logi od 20.10.2026.
4. **Zabezpieczyć obraz:** utworzyć jako stan dowodowy kopię plików i bazy danych, a w przypadku serwerów wirtualnych migawkę (snapshot), i nie zmieniać jej.
5. **Poinformować odpowiedzialnych:** wcześnie zaangażować zarząd, inspektora ochrony danych, hosting i, jeśli istnieje, ubezpieczenie cybernetyczne. Wiele ubezpieczeń ma obowiązki zgłoszeniowe.

## Faza 2: znaleźć przyczynę i oczyścić

6. **Ustalić punkt wejścia:** przeanalizować logi, zmiany plików i wersje. Sprawdzić samo PHP, CMS, motywy, rozszerzenia, dane dostępowe i usługi serwera. Bez znanej przyczyny ryzyko ponownego ataku pozostaje.
7. **Zamknąć lukę:** doprowadzić PHP do naprawionej wersji (8.5.12, 8.4.27, 8.3.36 lub 8.2.35 albo potwierdzony backport dostawcy), zaktualizować CMS i rozszerzenia, zrestartować wszystkie procesy robocze PHP.
8. **Zawęzić okres:** ustalić najwcześniejszy moment podejrzanej aktywności. Decyduje on o tym, które backupy mogą być czyste i jakie dane mogły zostać dotknięte.
9. **Usunąć tylne furtki:** sprawdzić i usunąć webshelle, obce pliki PHP w folderach uploadu i pamięci podręcznej, zmienione pliki rdzenia, zadania cron, klucze SSH i usługi systemowe. Pliki rdzenia zastąpić plikami z czystego źródła.
10. **Oczyścić bazę danych:** usunąć nieznane konta administratorów, wprowadzone skrypty w treściach i ustawieniach oraz treści ze spamem.
11. **Rozważyć odbudowę:** przy głębokiej kompromitacji serwera odbudowa na świeżym, załatanym systemie ze sprawdzonymi danymi jest często pewniejszą drogą niż oczyszczanie w działającym systemie.

## Faza 3: odnowić dostępy i utwardzić

12. **Zmienić hasła:** do CMS, konta hostingowego, panelu, bazy danych, FTP, SFTP, SSH i poczty, i to z czystego urządzenia.
13. **Wymienić klucze i tokeny:** wygenerować od nowa klucze API, interfejsy usług płatności i wysyłki, klucze aplikacji CMS, klucze SSH i certyfikaty, które leżały na serwerze.
14. **Zakończyć sesje:** wylogować wszystkie aktywne logowania w CMS i usługach oraz sprawdzić zarejestrowane urządzenia dwuskładnikowe.
15. **Włączyć logowanie dwuskładnikowe:** dla wszystkich dostępów administratora, łącznie z hostingiem, domeną i DNS.
16. **Utwardzić serwer:** sprawdzić i udokumentować ustawienia PHP, uprawnienia do plików, blokady wykonywania w folderach uploadu, zaporę i nagłówki bezpieczeństwa.

## Faza 4: obowiązki, komunikacja i zamknięcie

17. **Sprawdzić obowiązki zgłoszeniowe:** jeśli mogą być dotknięte dane osobowe, może być konieczne [zgłoszenie w ciągu 72 godzin na podstawie art. 33 RODO](https://phpsos.de/pl/compliance/dsgvo-meldepflicht-72-stunden/). Ocena należy do inspektora ochrony danych lub prawnika. Obowiązki branżowe, na przykład wynikające z NIS2, sprawdzić osobno.
18. **Rozważyć zawiadomienie:** [centralne punkty kontaktowe ds. cyberprzestępczości (ZAC)](https://phpsos.de/pl/compliance/anzeige-polizei-zac/) niemieckiej policji przyjmują zawiadomienia od firm. Zabezpieczone logi są do tego ważną podstawą.
19. **Poinformować klientów i Google:** poinformować dotkniętych rzeczowo i w uzgodnieniu. Jeśli Google wyświetla ostrzeżenie, po oczyszczeniu poprosić o weryfikację, jak opisano w artykule [Usuwanie ostrzeżenia Google](https://phpsos.de/pl/ratgeber/google-warnung-entfernen/).
20. **Udokumentować zamknięcie i monitorować:** zapisać w raporcie przyczynę, okres, środki i otwarte punkty, wyciągnąć wnioski dla planu awaryjnego i w kolejnych tygodniach wzmożenie monitorować systemy.

## Częste błędy na etapie po incydencie

Wiele incydentów się przeciąga, ponieważ w pierwszym zdenerwowaniu oszczędzono w niewłaściwym miejscu lub działano zbyt szybko. Tych błędów należy unikać:

- **Usuwanie tylko tego, co widoczne:** usunięta strona ze spamem lub usunięte przekierowanie nie jest dowodem czystej strony. Tylne furtki często pozostają niezauważone.
- **Zmiana haseł z dotkniętego systemu:** jeśli na komputerze lub serwerze nadal działa złośliwe oprogramowanie, nowe dane dostępowe mogą od razu wyciec.
- **Ślepe wgrywanie backupu:** bez zamkniętej luki i bez sprawdzenia backupu atakujący szybko znów stoi w drzwiach.
- **Traktowanie poprawki jako odwołania alarmu:** aktualizacja do naprawionej wersji PHP nie dowodzi, że wcześniej nic się nie stało, i nie usuwa wprowadzonego złośliwego oprogramowania.
- **Zbyt późne sprawdzenie obowiązków:** terminy zaczynają biec od uzyskania wiedzy o incydencie, a nie od końca oczyszczania.
- **Brak dokumentacji:** bez protokołu na pytania ubezpieczenia, organów lub klientów trudno później odpowiedzieć.

> **Ważne:**
> Ta lista kontrolna nie zastępuje porady prawnej. W razie pytań o obowiązki zgłoszeniowe, odpowiedzialność lub ubezpieczenie proszę zwrócić się do inspektora ochrony danych, prawnika lub ubezpieczyciela.

## Jak konkretnie pomaga PHP SOS?

- Przejmujemy uporządkowane [reagowanie na incydenty](https://phpsos.de/pl/leistungen/incident-response/) i prowadzimy listę kontrolną wspólnie z Państwem, punkt po punkcie z protokołem.
- Zabezpieczamy logi i stany systemu tak, aby pozostały użyteczne dla ubezpieczenia, organów i ewentualnej [informatyki śledczej](https://phpsos.de/pl/leistungen/it-forensik/).
- Zamykamy lukę, oczyszczamy lub odbudowujemy i odnawiamy dostępy we właściwej kolejności.
- Dostarczamy raport końcowy z przyczyną, środkami i rekomendacjami oraz na życzenie dalej monitorujemy systemy.


## Częste pytania

**Co jest pierwszą rzeczą, którą powinienem zrobić, gdy moja strona została zhakowana?**  
Zachować spokój, niczego nie usuwać i ograniczyć szkodę. W razie potrzeby proszę odłączyć stronę od sieci lub przełączyć w tryb konserwacji i zabezpieczyć logi oraz pliki, zanim zaczną Państwo oczyszczać. Potem następuje szukanie przyczyny i oczyszczanie.

**Czy wystarczy przywrócić stronę z backupu?**  
Zwykle nie. Backup może już zawierać złośliwy kod, a luka, przez którą wszedł atakujący, po wgraniu kopii nadal jest otwarta. Najpierw zamknąć przyczynę, potem wgrać sprawdzony, czysty stan na zaktualizowany system.

**Czy muszę zgłosić włamanie organowi ochrony danych?**  
Jeśli mogą być dotknięte dane osobowe, art. 33 RODO przewiduje co do zasady zgłoszenie w ciągu 72 godzin od uzyskania wiedzy, o ile naruszenie nie jest mało prawdopodobne, by skutkowało ryzykiem dla osób, których dane dotyczą. Ocena należy do Państwa inspektora ochrony danych lub prawnika.

**Kiedy incydent jest naprawdę zamknięty?**  
Gdy przyczyna jest zamknięta, wszystkie znane tylne furtki usunięte, dostępy odnowione, obowiązki spełnione, a środki udokumentowane. Do tego należy okres wzmożonego monitorowania, aby wykryć przeoczone ślady.

## Źródła

- [RODO art. 33: zgłoszenie do organu nadzorczego](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Policja niemiecka: centralne punkty kontaktowe ds. cyberprzestępczości (ZAC)](https://www.polizei.de/)
- [BSI: wskazówki dotyczące incydentów bezpieczeństwa IT (Niemcy)](https://www.bsi.bund.de/)
- [php.net: komunikaty o bezpieczeństwie dotyczące PHP2Shell](https://www.php.net/)