Krótko: To, czy po włamaniu zainstalować serwer od nowa czy oczyścić, zależy od tego, jak pewnie znają Państwo zakres włamania. Jeśli atakujący mógł mieć uprawnienia roota, moment włamania jest niejasny lub brakuje logów, odbudowa z zaufanych źródeł jest pewniejszym wyborem. Oczyszczenie wchodzi w grę tylko przy wąsko ograniczonym, dobrze udokumentowanym zainfekowaniu. W obu przypadkach obowiązuje: najpierw zabezpieczyć dowody i zamknąć lukę, potem sprzątać.
Dlaczego to pytanie pada po PHP2Shell szczególnie często
PHP2Shell umożliwia według php.net zdalne wykonanie złośliwego kodu bez logowania. Kto prowadził niezałatany serwer, musi więc zapytać, czy w czasie od 17.10.2026, czyli od pierwszej zaobserwowanej według doniesień medialnych próby ataku, coś się wydarzyło. Poprawka nie odpowiada na to pytanie, a nie ma opublikowanych, potwierdzonych wskaźników kompromitacji (indicators of compromise).
Gdy znajdzie się podejrzany plik, nieznany proces lub obce zadanie cron, trzeba zdecydować. Impuls bywa taki, by szybko usunąć albo od razu zainstalować od nowa. Jedno i drugie może być właściwe, ale nie jako pierwszy krok.
Kolejność przed decyzją
Zanim wybiorą Państwo między oczyszczeniem a instalacją od nowa, trzeba załatwić trzy rzeczy. Obowiązują one dla obu dróg.
- Powstrzymać: Odłączyć serwer od sieci lub ograniczyć dostęp do tego, co niezbędne, bez wyłączania go, jeśli ma jeszcze zostać zabezpieczona pamięć operacyjna.
- Zabezpieczyć dowody: Zabezpieczyć logi, pliki, bazę danych i możliwie obraz systemu, z datą i sumą kontrolną. Dlaczego jest to konieczne przed każdą ponowną instalacją, wyjaśnia artykuł Zabezpieczyć dowody, zanim zainstalują Państwo od nowa.
- Włączyć ubezpieczyciela i ochronę danych: Wiele polis cyber oczekuje uzgodnienia istotnych kroków. Wskazówki znajdują się w artykule Ubezpieczenie cyber: co liczy się w razie szkody. To, czy istnieje obowiązek zgłoszenia według RODO, oceniają inspektor ochrony danych lub adwokat.
Dopiero potem opłaca się właściwe rozważenie.
Serwer po włamaniu zainstalować od nowa czy oczyścić: kryteria
| Kryterium | Oczyścić | Zainstalować od nowa |
|---|---|---|
| Zakres włamania | Wąsko ograniczony, udokumentowany, np. jeden plik w folderze uploadu bez dalszych śladów | Niejasny lub ze wskazówkami na dostęp do systemu |
| Możliwe uprawnienia roota atakującego | Wykluczone z dobrymi dowodami | Nie do wykluczenia |
| Dostępność logów | Pełne dla istotnego okresu | Niepełne, nadpisane lub podatne na manipulację |
| Nakład | Mniejszy, gdy ustalenie jest jasne | Większy, ale lepiej planowalny |
| Pozostała niepewność | Większa, ukryte tylne furtki trudno wykluczyć | Mniejsza, jeśli zbudowano rzetelnie z zaufanych źródeł |
| Czas przestoju | Zwykle krótszy | Zwykle dłuższy, przy przygotowaniu dobrze sterowalny |
| Przydatność dla starych systemów | Problematyczne, jeśli system i tak jest przestarzały | Dobra okazja do przejścia na obsługiwaną wersję PHP |
Jako zasada kciuka: im mniej Państwo wiedzą, tym więcej przemawia za odbudową. Przy luce w interpreterze PHP, która wykonuje kod w kontekście użytkownika serwera WWW, atakujący może wykorzystać kolejne podatności, aby uzyskać więcej uprawnień. Bez gruntownego badania trudno to wykluczyć.
Obie drogi w praktyce
Co naprawdę znaczy „zainstalować od nowa”
Zainstalować od nowa nie oznacza skopiować starą kopię zapasową na świeży serwer. Odbudowa zaczyna się od czystego systemu operacyjnego z oficjalnego źródła, aktualnych pakietów i załatanej wersji PHP. Aplikację instaluje się z oryginału producenta, wtyczki i motywy również.
Dopiero potem dochodzą własne treści, i to sprawdzone. Przesłane pliki nie mogą zawierać wykonywalnych skryptów, baza danych może zawierać wprowadzone treści, na przykład ukryte konta administratora lub skrypty we wpisach. Pliki konfiguracyjne są pisane na nowo, a nie kopiowane. Wszystkie dane dostępowe są odnawiane: baza danych, administratorzy CMS, klucze SSH, klucze API, panel hostingowy.
Kopie zapasowe odgrywają przy tym ważną rolę, ale tylko jeśli ich stan sprzed włamania i same nie zostały zmienione. Wiele generacji w oddzielnych miejscach pozwala to sprawdzić; więcej w artykule Kopie zapasowe według reguły 3-2-1.
Gdy oczyszczenie jest uzasadnione
Oczyszczenie może mieć sens, gdy zainfekowanie wykryto wcześnie, dostępne są pełne logi, a badanie nie daje wskazówki na kolejne dostępy. Wtedy znalezione pliki są po zabezpieczeniu usuwane, sprawdzane są zadania cron, konta użytkowników i klucze SSH, a pliki rdzenia porównywane z oryginałem producenta.
Ważna jest realistyczna ocena: webshelle są często niepozorne i ukryte w kilku miejscach. Jak je znaleźć, opisuje artykuł Rozpoznawanie i usuwanie webshelli. Po oczyszczeniu serwer powinien być obserwowany z bliska, aby przeoczona tylna furtka została zauważona.
Proszę niczego nie usuwać, zanim logi i pliki nie zostaną zabezpieczone, i zamknąć lukę, zanim serwer wróci do sieci. W przeciwnym razie tracą Państwo ślady i zapraszają następne włamanie.
Kiedy nie potrzebują Państwo usługodawcy
W przypadku prostej strony na hostingu współdzielonym, gdzie system zarządza firma hostingowa i potwierdza poprawkę PHP, decyzja często w ogóle nie należy do Państwa. Mogą Państwo zainstalować aplikację od nowa z oryginału, sprawdzić treści i odnowić dane dostępowe, przy wsparciu firmy hostingowej. Także doświadczony zespół wewnętrzny może sam udźwignąć odbudowę, jeśli zabezpieczenie dowodów i dokumentacja są opanowane.
Zewnętrzna pomoc się opłaca, gdy nie można wykluczyć uprawnień roota, mogą być dotknięte dane osobowe, zaangażowane jest ubezpieczenie lub powiązanych jest wiele systemów.
Jak konkretnie pomaga PHP SOS?
- Zabezpieczamy logi, pliki i bazę danych w sposób nadający się na dowód, zanim cokolwiek zostanie zmienione.
- Oceniamy zakres włamania i zalecamy oczyszczenie lub odbudowę z uzasadnieniem, z rozdziałem na udokumentowane, prawdopodobne i nieznane.
- W razie potrzeby budujemy serwer od nowa z zaufanych źródeł, z załataną wersją PHP i odnowionymi dostępami.
- Przejmujemy usuwanie złośliwego oprogramowania tam, gdzie oczyszczenie jest uzasadnione, i dokumentujemy każdy krok.
Podsumowanie
Na pytanie „zainstalować od nowa czy oczyścić?” odpowiada wiedza o włamaniu. Kto nie zna pewnie zakresu, buduje od nowa. Kto potrafi go ograniczyć i dobrze udokumentować, może oczyścić. W obu przypadkach obowiązuje ta sama kolejność: powstrzymać, zabezpieczyć, zamknąć lukę, potem sprzątać.
Częste pytania
Czy instalacja od nowa po włamaniu jest zawsze lepsza?
Nie zawsze, ale często. Jeśli nie wiadomo, jak daleko zaszedł atakujący, odbudowa z zaufanych źródeł jest zwykle pewniejszym wyborem. Przy wąsko ograniczonym, dobrze udokumentowanym zainfekowaniu może wystarczyć oczyszczenie.
Czy mogę po prostu wgrać starą kopię zapasową?
Tylko jeśli jest pewne, że kopia powstała przed włamaniem i nie zawiera tylnej furtki. Dodatkowo luka musi być wcześniej zamknięta, w przeciwnym razie serwer jest od razu znów podatny na atak. Dane nowsze trzeba sprawdzić osobno.
Co muszę zabezpieczyć przed ponowną instalacją?
Logi, kopię plików i bazy danych oraz, jeśli to możliwe, obraz systemu. Te dowody są potrzebne do analizy przyczyn, ubezpieczenia i ewentualnego zgłoszenia. Po usunięciu ich nie ma.
Czy wystarczy usunąć znalezionego webshella?
Rzadko. Atakujący często zakładają kilka tylnych furtek, na przykład zadania cron, konta użytkowników lub klucze SSH. Kto usunie tylko widoczny plik, pozostawia otwarte pozostałe dostępy.