CleanOps

Pierwsza godzina po wykryciu włamania na stronę — co robić, a czego nie robić

13 października 2026 • 3 min czytania • włamanie, lista kontrolna, WordPress, Joomla, incydent

Osoba notująca w zeszycie obok laptopa

Dostajesz maila z hostingu, telefon od klienta albo widzisz ostrzeżenie w Google. Strona jest zainfekowana. Pierwsza reakcja większości ludzi, czyli szybkie kasowanie wszystkiego, co wygląda podejrzanie, to jednocześnie najgorsza możliwa. Oto co zrobić w pierwszej godzinie, żeby nie pogorszyć sprawy i zachować wszystko, czego będzie potrzebować osoba naprawiająca.

Czego NIE robić

  1. Nie kasuj plików na oko. Zainfekowany plik szablonu usunięty w panice to biała strona i dni odtwarzania. Plik w kwarantannie to kilka sekund przywrócenia.
  2. Nie aktualizuj od razu. Aktualizacja nadpisze daty modyfikacji plików rdzenia, które pokazują, kiedy atak się zaczął, a infekcji poza rdzeniem nie ruszy.
  3. Nie przywracaj kopii zapasowej sprzed tygodnia bez sprawdzenia. Infekcja w większości przypadków jest starsza niż objawy. Kopia z zeszłego tygodnia często zawiera już backdoora, a przywrócenie jej zniszczy aktualne dane (zamówienia, wpisy, komentarze).
  4. Nie loguj się do panelu z tego samego hasła co zawsze, zanim nie sprawdzisz komputera. Jeśli hasło wyciekło z Twojego komputera, wpisanie go ponownie nic nie da.
  5. Nie pisz jeszcze do klientów, że „wszystko w porządku”. Najpierw ustal, co się stało.

Co zrobić: 7 kroków

1. Zapisz, co widzisz (5 minut)

Zrzuty ekranu komunikatu z hostingu, ostrzeżenia Google, strony z telefonu. Zapisz datę i godzinę, kiedy się dowiedziałeś, i od kogo. Przy zgłoszeniu do hostingu, ubezpieczyciela czy urzędu będziesz tego potrzebował.

2. Zrób kopię całego katalogu strony i bazy (10–20 minut)

Zanim ktokolwiek czegokolwiek dotknie. Przez panel hostingu (kopia „na żądanie”), przez SFTP (pobranie całego katalogu) albo przez SSH:

tar czf ~/kopia-$(date +%F).tgz public_html/
mysqldump -u uzytkownik -p nazwa_bazy | gzip > ~/baza-$(date +%F).sql.gz

Kopia z infekcją to nie błąd. To dowód i siatka bezpieczeństwa.

3. Pobierz logi dostępu (5 minut)

Logi serwera WWW (access_log, error_log) z ostatnich 2–4 tygodni. Hosting często rotuje je co kilka dni i stare znikają. To w nich jest odpowiedź na pytanie, jak atakujący wszedł: żądania POST do dziwnych plików, logowania z nietypowych adresów, pierwsze wywołanie web‑shella.

4. Zmień hasła, do których masz pewność (10 minut)

Panel hostingu, konto FTP/SFTP, panel CMS‑a. Z komputera, co do którego masz pewność, że jest czysty, albo z telefonu. Nie zmieniaj jeszcze hasła bazy, jeśli nie wiesz, jak zaktualizować plik konfiguracyjny, bo położysz stronę.

5. Ogranicz szkody (10 minut)

Jeśli hosting nie zablokował strony sam, rozważ to:

  • w WordPressie włącz tryb konserwacji wtyczką albo prostym .htaccess, który przepuszcza tylko Twój adres IP;
  • jeśli strona rozsyła spam, poproś hosting o tymczasowe wyłączenie wysyłki poczty z konta;
  • jeśli strona przekierowuje odwiedzających na złośliwe treści, krótkie wyłączenie strony jest mniejszą szkodą niż każdy kolejny zarażony klient.

6. Sprawdź, czy problem jest szerszy (5 minut)

Inne strony na tym samym koncie hostingowym. Jedno konto, kilka domen: infekcja jednej to zwykle infekcja wszystkich. Sprawdź daty modyfikacji plików w pozostałych katalogach.

7. Zdecyduj, kto naprawia (5 minut)

Samodzielnie, jeśli umiesz porównać pliki z wydaniem i przejrzeć bazę. Wykonawca lub narzędzie, jeśli nie. Od wykonawcy wymagaj kwarantanny zamiast kasowania, dziennika zmian i porównania z oficjalnym wydaniem. O tym, na co uważać przy dawaniu dostępu, jest osobny wpis.

Co dalej, po pierwszej godzinie

Naprawa, zamknięcie drogi wejścia (hasła, sole, aktualizacje, usunięcie zbędnych wtyczek), prośba do hostingu o ponowny skan i zdjęcie blokady, prośba do Google o ponowne sprawdzenie, jeśli było ostrzeżenie. A potem obserwacja przez kilka tygodni: site:twojadomena.pl, Search Console, daty modyfikacji plików.

Jeśli strona przetwarzała dane osobowe (sklep, formularze z danymi klientów, konta użytkowników), sprawdź, czy incydent nie wymaga zgłoszenia do Prezesa UODO. Termin to 72 godziny od stwierdzenia naruszenia, więc nie odkładaj tej decyzji. To nie porada prawna; w razie wątpliwości skonsultuj się z prawnikiem.

Lista w skrócie

  • zrzuty ekranu i notatka z datą,
  • kopia plików i bazy,
  • logi dostępu z ostatnich tygodni,
  • hasła do hostingu, SFTP i CMS‑a zmienione z czystego urządzenia,
  • strona ograniczona lub wyłączona, jeśli szkodzi odwiedzającym,
  • pozostałe strony na koncie sprawdzone,
  • decyzja, kto naprawia i na jakich zasadach.

Bezpłatne sprawdzenie w CleanOps nie zmienia niczego na serwerze, więc można je zrobić jako pierwszy krok diagnozy, równolegle z powyższą listą.

Czytaj też