Co zrobić po włamaniu na VPS? Procedura odzyskiwania

Nie czyść przejętego VPS

Jeśli Twój VPS został przejęty, najważniejsza decyzja zapada przed wykonaniem jakiegokolwiek polecenia. Nie próbuj czyścić maszyny. Odizoluj ją u dostawcy, wykonaj snapshot dysku w celach dowodowych, zrotuj wszystkie przechowywane na niej dane uwierzytelniające, a następnie przeprowadź reinstalację na nowym serwerze, korzystając z zaufanych źródeł.

Nie da się udowodnić, że rootkit został usunięty, ponieważ narzędzia służące do tego dowodzenia są kontrolowane przez atakującego.

To cały argument. Oto mechanizm, który za tym stoi. Atakujący, który uzyskał dostęp do konta root, może zmodyfikować ps tak, aby wybrany identyfikator procesu nigdy nie pojawiał się w wynikach. Jedna linia w /etc/ld.so.preload ładuje kod atakującego do każdego dynamicznie linkowanego programu w systemie, przez co ls, ss oraz find raportują w ten sam spójny, fałszywy sposób. Ładowalny moduł jądra (LKM) może ukryć pliki na poziomie wywołań systemowych, więc nawet świeżo pobrany plik binarny widzi czysty dysk. Usuwasz koparkę kryptowalut, wykres użycia CPU spada, a serwer cichnie. Cisza jest również tym, jak wygląda działający backdoor.

Reinstalacja kosztuje mniej, niż się wydaje. Typowy VPS to garść pakietów, jeden katalog konfiguracyjny i jeden zestaw danych, więc odbudowa jest skończonym zadaniem z określonym końcem. Polowanie na każdą zmianę wprowadzoną przez atakującego jest procesem otwartym i nigdy nie prowadzi do pewności.

Potwierdzenie naruszenia bezpieczeństwa

Wiele serwerów zgłaszanych jako zhakowane w rzeczywistości nie zostało przejętych. Tysiące nieudanych prób logowania SSH dziennie to internetowy szum tła, ponieważ każdy publiczny adres IPv4 jest nieustannie skanowany. Dane wyjściowe lastb pełne prób root oraz admin oznaczają jedynie, że skanery wykryły otwarty port. Nie oznacza to, że ktokolwiek uzyskał dostęp.

Poniższe sygnały wymagają uwagi:

• Udane logowanie, którego nie można wyjaśnić, na przykład Accepted password for root from 203.0.113.7.
• Klucz w authorized_keys, który nie został dodany przez administratora.
• Powiadomienie o nadużyciu od dostawcy hostingu dotyczące ruchu wychodzącego z serwera.
• Proces zużywający 100% CPU, którego nazwa została skopiowana z wątku jądra. Koparki kryptowalut, umieszczone przez niezabezpieczone gniazda Redis lub Docker, są często zgłaszane pod nazwami takimi jak kdevtmpfsi oraz kinsing.
• Połączenia wychodzące do adresów, z których nie korzysta żadna z uruchomionych usług.

Dla maskowania się pod wątek jądra istnieje szybki test. Prawdziwe wątki jądra są wyświetlane w nawiasach kwadratowych i nie posiadają przypisanego pliku wykonywalnego, dlatego sudo ls -l /proc/<pid>/exe kończy się dla nich błędem No such file or directory. Jeśli proces wyświetlany jako [kworker/0:2] posiada dowiązanie exe wskazujące na lokalizację w /tmp, jest to zwykły program użytkownika podszywający się pod nazwę jądra.

Należy pamiętać, że podczas wykonywania tych sprawdzeń system może podawać fałszywe informacje. Powyższe kroki pozwalają stwierdzić, że wystąpił problem. Nie są one jednak wystarczające, aby wykluczyć naruszenie bezpieczeństwa.

Odcięcie sieci na poziomie dostawcy, a nie z wnętrza serwera

Izolacja jest priorytetem, ponieważ każdy kolejny krok jest bezcelowy, dopóki osoba niepowołana posiada dostęp do powłoki. Analiza logów, rotacja kluczy i przywracanie danych tracą sens, gdy aktywny intruz obserwuje działania.

Należy wykonać to w panelu sterowania dostawcy, w zaporze sieciowej działającej poza systemem operacyjnym. Należy zablokować ruch przychodzący i wychodzący, pozostawiając konsolę internetową jako jedyną drogę dostępu. Reguły wymuszane na tym poziomie są niezależne od stanu dysku.

Istnieją dwa powody, dla których nie należy wykonywać tego z wnętrza serwera. Zapora skonfigurowana wewnątrz przejętego jądra jest przez nie egzekwowana, a użytkownik root może wyczyścić reguły nftables tak samo łatwo, jak zostały one utworzone. Ponadto sudo ip link set enp1s0 down przez SSH przerywa własną sesję, co odcina dostęp do maszyny w trakcie jej badania.

Należy zablokować zarówno ruch wychodzący, jak i przychodzący. Reverse shell łączy się z serwera do atakującego, więc blokada tylko ruchu przychodzącego pozostawia ustanowione połączenie w pełni funkcjonalnym. Jeśli dostawca oferuje tylko reguły przychodzące, pozostaje odłączenie interfejsu sieciowego lub wyłączenie instancji.

Nie należy jeszcze restartować serwera. Najpierw trzeba sprawdzić, czy istnieje /var/log/journal. Jeśli ten katalog nie istnieje, journald zapisuje dane w /run/log/journal, który znajduje się w pamięci RAM, więc restart usuwa ślady włamania. Uruchomione procesy również znikają po restarcie, a ich linie poleceń często stanowią najistotniejszy dowód, jaki można uzyskać.

Wykonaj migawkę dysku przed podjęciem jakichkolwiek działań

Migawka i kopia zapasowa pełnią w tym przypadku odmienne funkcje. Migawka wykonywana w tej chwili jest kopią naruszonego dysku: stanowi materiał dowodowy i jest jedynym sposobem na cofnięcie zmian w razie przypadkowego nadpisania danych. Starsze kopie zapasowe stanowią ścieżkę odzyskiwania systemu. Jeśli panel dostawcy używa tych pojęć zamiennie, należy najpierw zapoznać się z różnicami między migawkami VPS a właściwymi kopiami zapasowymi, ponieważ zasady retencji oraz sposób przywracania danych nie są tożsame.

Migawkę należy wykonać z poziomu panelu dostawcy przed ponownym zalogowaniem się do systemu. Migawka na żywo jest spójna na poziomie awarii (crash consistent): rejestruje stan dysku w danej chwili, co odpowiada nagłemu odcięciu zasilania. Jest to wystarczające dla celów dowodowych. Migawkę należy nazwać w sposób uniemożliwiający jej przypadkowe przywrócenie. Nazwa tak bezpośrednia jak COMPROMISED-do-not-restore-2026-08-12 jest odpowiednim poziomem precyzji. Należy ją zachować do czasu zakończenia dochodzenia oraz zamknięcia zgłoszenia o nadużyciu (abuse ticket) u dostawcy hostingu.

Jak uzyskać dostęp, gdy SSH nie działa

Dostępne są dwie ścieżki, obie w panelu dostawcy. Konsola internetowa (VNC lub szeregowa) łączy się z maszyną tak, jakby podłączono do niej klawiaturę. Działa, gdy sshd nie odpowiada, gdy firewall jest błędnie skonfigurowany lub gdy atakujący zmienił port SSH. Uwierzytelnianie odbywa się za pomocą lokalnego hasła, więc w przypadku serwera z dostępem wyłącznie przez klucze, może być konieczny reset hasła root, aby konsola była użyteczna.

Tryb ratunkowy (Rescue mode) jest lepszą opcją. Uruchamia on niewielki system typu live z podłączonym, lecz nieuruchomionym dyskiem, dzięki czemu wydawane polecenia są wiarygodne: zainfekowane jądro systemu oraz zainfekowane pliki binarne nie są wykonywane. Zamontuj dysk w trybie tylko do odczytu.

lsblk -f
sudo mkdir -p /mnt/victim
sudo mount -o ro /dev/vda1 /mnt/victim

Jeśli lsblk wykazuje wolumeny LVM (logical volume manager) zamiast zwykłej partycji, najpierw aktywuj je za pomocą sudo vgchange -ay, a następnie zamontuj urządzenie, które pojawi się w /dev/mapper/.

Nie używaj chroot na zamontowanym dysku w celu przeglądania plików. Polecenie chroot uruchamia pliki binarne atakującego z Twoimi uprawnieniami, co niweczy cały cel uruchomienia trybu ratunkowego.

Gromadzenie wiarygodnych dowodów

Uruchom poniższe polecenia w trybie ratunkowym (rescue mode), z dyskiem zamontowanym w trybie tylko do odczytu w /mnt/victim. Zacznij od logów logowania, ponieważ pozwalają one określić czas włamania, a posiadanie ram czasowych ułatwia dalszą analizę.

sudo grep -aE 'Accepted (password|publickey)' /mnt/victim/var/log/auth.log
sudo last -f /mnt/victim/var/log/wtmp
sudo lastb -f /mnt/victim/var/log/btmp
sudo journalctl -D /mnt/victim/var/log/journal -u ssh --since "2026-07-01"

Brak pliku /var/log/auth.log sam w sobie nie jest podejrzany. Niektóre współczesne obrazy Ubuntu są dostarczane bez rsyslog, więc logi sshd trafiają wyłącznie do journala, co odczytuje polecenie journalctl -D. Warto natomiast zwrócić uwagę na luki w ciągłości logów lub pliki dziennika wyzerowane do 0 bajtów. Usuwanie śladów w logach jest powszechne i zazwyczaj przeprowadzane niechlujnie.

Następnie sprawdź konta i klucze.

sudo find /mnt/victim/root /mnt/victim/home -name 'authorized_keys*' -exec ls -l {} +
sudo awk -F: '$3 == 0 {print $1}' /mnt/victim/etc/passwd
sudo lsattr /mnt/victim/root/.ssh/authorized_keys

Polecenie awk wyświetla każde konto z identyfikatorem użytkownika 0. Każdy wynik inny niż root oznacza istnienie drugiego konta root. Wzorzec find celowo uwzględnia również authorized_keys2, ponieważ OpenSSH domyślnie odczytuje obie te lokalizacje, a druga z nich jest łatwa do przeoczenia. Jeśli lsattr wyświetli i na liście atrybutów, plik jest niezmienny (immutable): atakujący ustawia tę flagę, aby próba usunięcia klucza zakończyła się błędem Operation not permitted, co może zostać błędnie zinterpretowane przez zmęczonego administratora jako udana edycja.

Trwałość (persistence) ukrywa się w niewielkiej liczbie miejsc, więc sprawdź je wszystkie.

sudo ls -lt /mnt/victim/etc/systemd/system
sudo ls -l /mnt/victim/etc/cron.d /mnt/victim/var/spool/cron/crontabs
sudo cat /mnt/victim/etc/ld.so.preload
sudo grep -rnE 'curl|wget|base64|/dev/tcp' /mnt/victim/etc/update-motd.d /mnt/victim/etc/rc.local /mnt/victim/root/.bashrc /mnt/victim/root/.profile

Plik /etc/ld.so.preload nie istnieje w standardowej instalacji Ubuntu lub Debian, więc No such file or directory jest prawidłowym wynikiem, a jakakolwiek zawartość wymaga uwagi. Podobnie jest z plikiem logowania, który przesyła wynik base64 -d do powłoki: poprawna konfiguracja nie wymaga ukrywania swojej treści.

Buduj oś czasu w oparciu o czas zmiany (ctime), a nie czas modyfikacji (mtime).

sudo find /mnt/victim -xdev -newerct '2026-08-01' -type f -printf '%TF %TT %p\n' | sort

Polecenie touch pozwala atakującemu ustawić dowolną wartość czasu modyfikacji, więc mtime jest niewiarygodny. Czas zmiany (ctime) aktualizuje się przy każdej zmianie inoda, a touch nie może cofnąć tego licznika, dlatego -newerct dostarcza bardziej rzetelną listę plików zapisanych w ostatnim czasie. Nie jest to jednak dowód ostateczny, ponieważ root może zmienić zegar systemowy lub zapisać dane bezpośrednio na urządzeniu blokowym.

Integralność pakietów wymaga jednego polecenia i jednego zastrzeżenia. W działającym systemie sudo dpkg --verify wyświetla wiersz dla każdego pliku z pakietu, którego suma kontrolna nie zgadza się, oznaczając to symbolem 5 w kolumnie sumy kontrolnej. Polecenie sudo debsums -ac wykonuje to samo zadanie, uwzględniając pliki konfiguracyjne, pod warunkiem zainstalowania pakietu debsums. Wyniki interpretuj jednostronnie. Zmieniony plik /usr/sbin/sshd stanowi twardy dowód. Czysty raport nie dowodzi niczego, ponieważ to samo konto root, które podmieniło plik binarny, może nadpisać listy sum kontrolnych w /var/lib/dpkg/info/. Skanery rootkitów, takie jak rkhunter i chkrootkit, podlegają tej samej zasadzie: wykrycie zagrożenia jest informacją, czysty wynik nie jest gwarancją bezpieczeństwa.

Skopiuj zgromadzone dane z maszyny przed wykonaniem jakichkolwiek destrukcyjnych działań.

sudo tar --ignore-failed-read -C /mnt/victim -czf /root/evidence-2026-08-12.tgz \
  var/log etc root/.ssh root/.bash_history home
sha256sum /root/evidence-2026-08-12.tgz

Zapisz ten skrót (hash) w miejscu zewnętrznym względem serwera. Jeśli sprawa trafi do ubezpieczyciela lub na policję, możliwość wykazania, że archiwum nie zmieniło się od momentu zabezpieczenia, stanowi różnicę między dowodem a zwykłym folderem z plikami. Przypadkowe usunięcie danych podczas śledztwa jest częstym zjawiskiem, a posiadanie migawki oraz tego archiwum pozwala na odzyskanie sprawności systemu. Cofnięcie skutków błędnego polecenia rm jest znacznie trudniejsze, niż się powszechnie uważa, co wyjaśnia artykuł odzyskiwanie plików usuniętych za pomocą rm -rf.

Znajdź drogę, przez którą weszli

Odbudowa systemu, która nie zamyka drogi wejścia, prowadzi do ponownego przejęcia kontroli nad serwerem, często w ciągu kilku dni, ponieważ skanowanie, które wykryło podatność za pierwszym razem, nigdy nie ustaje. Cztery drogi odpowiadają za większość włamań na pojedyncze serwery.

Logowanie hasłem przez SSH. Linia Accepted password for root z adresu, którego nie rozpoznajesz, jest odpowiedzią samą w sobie. Sprawdź PasswordAuthentication w /etc/ssh/sshd_config oraz w każdym pliku wewnątrz /etc/ssh/sshd_config.d/. sshd używa pierwszej wartości, jaką uzyska dla danego słowa kluczowego, a linia Include znajduje się na samej górze głównego pliku w systemie Ubuntu, więc dodany plik konfiguracyjny po cichu nadpisuje ustawienie, które edytowałeś niżej.

Usługa udostępniona bez uwierzytelniania. Redis na porcie 6379, Docker API na 2375, baza danych powiązana z 0.0.0.0 zamiast z 127.0.0.1. Docker jest częstym zaskoczeniem. Publikowanie portu kontenera wstawia reguły DNAT (destination network address translation), które są oceniane przed łańcuchami ufw, więc ufw status może raportować port jako zablokowany, podczas gdy kontener za nim odpowiada całemu internetowi. Zrozum to przed odbudową: dlaczego opublikowane porty Dockera omijają ufw omawia kolejność reguł i sposób naprawy.

Niezałatana aplikacja internetowa. Przeszukaj log dostępu serwera WWW w okolicach najwcześniejszego podejrzanego znacznika czasu pod kątem żądania POST do ścieżki przesyłania plików lub ścieżki administracyjnej, a następnie poszukaj plików w głównym katalogu WWW z pasującym czasem modyfikacji. Zabłąkany plik PHP w katalogu przesyłania plików to klasyczny rezultat.

Wyciek poświadczeń. Klucz zatwierdzony w repozytorium, token wklejony na czat, plik .env udostępniony jako plik statyczny przez błędnie skonfigurowany serwer WWW. Automatyzacja ułatwia przypadkowe popełnienie tego błędu, co stanowi argument za utrzymywaniem sekretów z dala od agentów AI i ich plików konfiguracyjnych.

Jeśli po tym wszystkim nie potrafisz wskazać drogi wejścia, załóż, że doszło do wycieku poświadczeń i traktuj każdy sekret przechowywany na maszynie jako publiczny.

Rotacja wszystkich poświadczeń, do których maszyna mogła mieć dostęp

Rotację należy przeprowadzić po odcięciu sieci, nigdy wcześniej. Rotacja w czasie, gdy atakujący nadal posiada aktywne połączenie, jedynie przekazuje mu nowe sekrety.

• Każdy klucz prywatny SSH przechowywany na serwerze oraz każde konto w innej lokalizacji, które ufało odpowiadającemu mu kluczowi publicznemu.
• Każdy klucz przekazany do maszyny za pomocą ssh -A. Mechanizm agent forwarding pozostawia gniazdo w /tmp, a użytkownik root na tej maszynie może go użyć do uwierzytelnienia się jako użytkownik w dowolnym miejscu, gdzie klucz jest akceptowany, tak długo jak sesja pozostaje otwarta.
• Tokeny API w plikach .env, w liniach Environment= jednostek systemd, w konfiguracji CI oraz w poświadczeniach dostawców.
• Hasła do baz danych oraz konta aplikacji, które z nich korzystają.
• Klucze prywatne TLS (transport layer security), które znajdowały się na serwerze. Należy wygenerować certyfikat ponownie i unieważnić stary.
• Hasło do konta hostingowego z włączonym uwierzytelnianiem dwuskładnikowym. Panel ten pozwala na przebudowę, tworzenie migawek oraz dostęp przez konsolę do każdego posiadanego serwera, stanowi więc rzeczywistą granicę bezpieczeństwa.
• Każde hasło wpisane w sesji powłoki na tym hoście w czasie, gdy był on przejęty, ponieważ użytkownik root może rejestrować sesję terminala w czasie rzeczywistym.

Jeśli hasło używane na tej maszynie jest wykorzystywane gdziekolwiek indziej, należy je zmienić również w tamtych lokalizacjach. Ponowne używanie haseł sprawia, że jeden przejęty VPS staje się przejętym kontem e-mail.

Lista kontrolna odbudowy serwera

1. Utwórz nowy serwer z czystego obrazu dystrybucji. Nie używaj migawki (snapshot) przejętej maszyny ani pełnego przywracania systemu plików root.
2. Zainstaluj pakiety z repozytoriów dystrybucji. Nigdy nie kopiuj plików binarnych ze starego dysku.
3. Przywróć wyłącznie dane z kopii zapasowej wykonanej przed najwcześniejszymi śladami włamania w Twojej osi czasu. Dotyczy to zrzutów baz danych, przesłanych plików i stanu aplikacji. Pozostaw /etc, /usr oraz stare pliki jednostek (unit files).
4. Wprowadź zrotowane sekrety ręcznie. Nie kopiuj starego pliku .env.
5. Sprawdź przywróconą zawartość stron WWW pod kątem plików dodanych w czasie włamania, zanim ponownie udostępnisz je w sieci.
6. Zabezpiecz serwer przed wystawieniem go na świat: używaj tylko kluczy SSH, konta użytkownika innego niż root, zapory sieciowej z domyślną polityką odrzucania ruchu przychodzącego (default-deny) i nie publikuj usług szerzej, niż jest to konieczne. Wykonaj kroki opisane w pierwsze dziesięć minut na nowym VPS, następnie poprawnie zabezpiecz SSH, a potem dodaj fail2ban na Ubuntu 24.04, aby ograniczyć liczbę prób logowania. Przypisz każdej usłudze własne konto z minimalnymi uprawnieniami, aby kolejny punkt zaczepienia nie oznaczał dostępu do konta root.
7. Wyłącz stary serwer i zachowaj jego migawkę do czasu zakończenia dochodzenia oraz zamknięcia zgłoszeń o nadużyciach.
8. Napraw kopie zapasowe. Jeśli punkt 3 był zgadywaniem, prawdziwą lekcją jest to, że historia kopii zapasowych była zbyt krótka, by sięgnąć okresu sprzed włamania. Wersjonowane kopie zapasowe poza serwerem z długim okresem retencji zapewniają czysty punkt przywracania w przyszłości: kopie zapasowe restic na VPS oferują obie te funkcje.

Jeśli nie potrafisz określić daty włamania, nie możesz wybrać bezpiecznej kopii zapasowej. W takim przypadku przywróć tylko dane, które możesz sprawdzić wzrokowo: zrzut SQL, który można przeczytać, lub katalog z obrazami, który można przejrzeć. Traktuj wszystko, co jest wykonywalne, jako podejrzane i zainstaluj to ponownie z repozytoriów.

Co oznacza powiadomienie o nadużyciu od dostawcy hostingu

Większość użytkowników dowiaduje się o naruszeniu bezpieczeństwa serwera od swojego dostawcy, a nie z własnego monitoringu. Dostawcy widzą ruch wychodzący: ataki brute force SSH na inne sieci, spam na porcie 25 lub udział w atakach typu reflection. Zgłoszenie zazwyczaj zawiera znaczniki czasu, numery portów oraz próbkę przepływów, wraz z wyznaczonym terminem liczonym w godzinach.

Należy odpowiedzieć na zgłoszenie, nawet jeśli jedyną informacją jest to, że serwer został odizolowany i trwa jego ponowna instalacja. Dostawcy stosują null-route lub zawieszają serwer, gdy zgłoszenie pozostaje bez odpowiedzi, co zmienia incydent w awarię. Następnie należy poprosić o surowe logi będące podstawą raportu. Znaczniki czasu zostały zarejestrowane poza maszyną, więc są jedynym elementem osi czasu, którego atakujący nie mógł zmodyfikować; często pozwalają one określić datę włamania dokładniej niż jakiekolwiek dane na dysku.

Zainfekowany serwer klienta to dla dostawcy rutynowe zadanie, a poprawne obsłużenie incydentu nie wpływa negatywnie na ocenę użytkownika. Szersze pytanie o to, czy hosting VPS jest bezpieczny, sprowadza się głównie do konfiguracji wykonanej przez klienta, czyli dokładnie tego elementu, który teraz trzeba wykonać od podstaw.

Kiedy wezwać specjalistę

• Serwer zawierał dane osobowe należące do innych osób. Zgodnie z RODO (Ogólne rozporządzenie o ochronie danych), naruszenie ochrony danych osobowych należy zgłosić organowi nadzorczemu bez zbędnej zwłoki, a jeśli to możliwe, w terminie 72 godzin od stwierdzenia naruszenia. Ocena, czy ten termin już biegnie, jest zadaniem prawnym, a nie administracyjnym.
• W zakresie znajdowały się dane kart płatniczych. Organizacje płatnicze wymagają udziału certyfikowanego śledczego, a samodzielne działania mogą zniszczyć materiał dowodowy.
• Pojawiło się żądanie okupu lub dane zostały zaszyfrowane.
• Maszyna miała dostęp do innych systemów: sieci wewnętrznej, hypervisora, czy runnera CI przechowującego poświadczenia produkcyjne. Jeden przejęty host w grupie oznacza incydent obejmujący całą grupę, dopóki nie udowodniono inaczej.
• Dowody muszą być przygotowane na potrzeby ubezpieczyciela lub organów ścigania. Należy zatrzymać się na etapie snapshotu, wykonać pełny obraz dysku oraz odnotować, kto i kiedy miał do niego dostęp.

W przypadku pojedynczego VPS z własnymi usługami, na którym nie znajdują się dane innych osób, powyższa procedura stanowi pełny zakres działań. Odizoluj serwer u dostawcy. Wykonaj snapshot w celach dowodowych. Zbierz dane, które wciąż można uznać za wiarygodne. Zrotuj wszystkie poświadczenia. Zbuduj środowisko od nowa.

FAQ

Czy mogę wyczyścić zhakowany serwer VPS zamiast go stawiać od nowa?

Nie można tego zrobić z pełnym przekonaniem, ponieważ wymagałoby to polegania na raportach generowanych przez przejęty system. Podmieniony ps ukrywa proces, linia w /etc/ld.so.preload wstrzykuje kod do każdego dynamicznie linkowanego narzędzia, a moduł jądra może ukryć pliki przed wszystkimi programami jednocześnie. Znalezienie śladów włamania jest dowodem, ale brak wyników nie oznacza bezpieczeństwa. Czyszczenie systemu jest dopuszczalne tylko wtedy, gdy na serwerze nie ma żadnych istotnych danych i akceptujesz ryzyko ponownego przejęcia kontroli przez atakującego.

Czy powinienem wyłączyć zhakowany serwer, czy zostawić go włączonego?

Najpierw odetnij dostęp do sieci na poziomie dostawcy, a następnie pozostaw serwer włączony wystarczająco długo, aby wykonać migawkę (snapshot) i przejrzeć uruchomione procesy. Wyłączenie zasilania niszczy listę procesów i usuwa cały dziennik, jeśli /var/log/journal nie istnieje, ponieważ journald zapisuje dane w pamięci operacyjnej w lokalizacji /run. Wyłącz serwer mimo wszystko, jeśli aktywnie atakuje inne sieci, a nie masz możliwości zablokowania jego ruchu wychodzącego. Powstrzymanie szkód jest ważniejsze niż zachowanie dowodów.

Jak ustalić, kiedy atakujący uzyskał dostęp?

Znajdź najwcześniejszą linię w Accepted password lub Accepted publickey, której nie potrafisz wyjaśnić, sprawdzając /var/log/auth.log lub dziennik systemowy. Porównaj ją z listą czasu modyfikacji plików, używając find / -xdev -newerct 'YYYY-MM-DD' -type f, ponieważ ctime jest trudniejszy do sfałszowania niż mtime. Następnie zestaw obie te wartości z sygnaturami czasowymi z powiadomienia o nadużyciu (abuse ticket) od dostawcy, które zostały zarejestrowane poza maszyną i nie mogły zostać zmienione. Wybierz kopię zapasową starszą niż najwcześniejsza z tych trzech dat. Jeśli nic się nie zgadza, załóż, że włamanie nastąpiło wcześniej niż sięga historia kopii zapasowych i przywróć tylko te dane, które możesz zweryfikować.

Czy moje kopie zapasowe są bezpieczne do przywrócenia po włamaniu?

Same dane zazwyczaj są bezpieczne, pod warunkiem ich sprawdzenia. Pliki systemowe nie są. Kopia zapasowa wykonana po włamaniu zawiera backdoor, więc przywrócenie całego systemu plików root przywraca również atakującego. Sprawdź również samo repozytorium kopii zapasowych: jeśli dane uwierzytelniające do niego były przechowywane na zhakowanym serwerze, historia mogła zostać usunięta lub zmieniona, co stanowi argument za używaniem celów kopii zapasowych typu append-only lub opartych na modelu pull. Przywróć dane aplikacji, a następnie zainstaluj oprogramowanie ponownie z repozytoriów dystrybucji.

Czy muszę kogoś informować, że mój VPS został zhakowany?

Zawsze odpowiadaj na powiadomienie o nadużyciu (abuse notice) od swojego dostawcy. Poza tym, obowiązek zależy od tego, czyje dane znajdowały się na maszynie. Dane osobowe należące do innych osób mogą wywołać prawny obowiązek zgłoszenia, na przykład zgodnie z wymogiem RODO dotyczącym powiadomienia organu nadzorczego w ciągu 72 godzin. Jeśli na serwerze przechowywano dane uwierzytelniające użytkowników, poinformuj ich, aby mogli zmienić hasła w innych serwisach. Jeśli klucze na serwerze autoryzowały dostęp do systemów stron trzecich, takich jak serwis hostingowy kodu lub konto w chmurze, powiadom tych dostawców, aby mogli sprawdzić, czy nie doszło do nadużyć. Serwer czysto osobisty, nieprzechowujący danych innych osób, nie nakłada żadnych obowiązków poza odpowiedzią na zgłoszenie o nadużyciu.