Gdy coś pójdzie nie tak

Moduł 10: Bezpieczeństwo na co dzień · Czas czytania: 11 min

Cel lekcji: Po tej lekcji rozpoznają Państwo sygnały świadczące o włamaniu na serwer, wykonają pierwsze kroki bez niszczenia dowodów i kopii zapasowych, zdecydują między czyszczeniem a ponowną instalacją oraz będą wiedzieć, kiedy trzeba zgłosić naruszenie ochrony danych.

Kluczowe pojęcia: incydent, sygnały, izolowanie, snapshot jako dowód, dziennik incydentu, ponowna instalacja, wymiana kluczy i haseł, czysta kopia zapasowa, obowiązek zgłaszania naruszeń ochrony danych (72 godziny), Prezes Urzędu Ochrony Danych Osobowych (UODO), plan awaryjny

Rozpoznawanie incydentu

Włamanie rzadko się zapowiada. Zazwyczaj widać po prostu coś "dziwnego". Sygnały, które należy traktować poważnie:

• Wysokie obciążenie bez powodu: procesor stale pracuje na 100%, na przykład z powodu koparki kryptowalut. Za pomocą top lub htop mogą Państwo sprawdzić, który to proces i na jakim użytkowniku działa.
• Nieznane procesy lub usługi: program o dziwnej nazwie, często w /tmp, /dev/shm lub /var/tmp, albo usługa lub timer systemd, których Państwo sami nie utworzyli.
• Podejrzany ruch wychodzący: dostawca informuje, że Państwa serwer wysyła spam lub atakuje inne serwery, albo wykresy sieci w panelu pokazują nagłe skoki.
• Nowi użytkownicy lub klucze: nieznany wpis w ~/.ssh/authorized_keys, użytkownik w /etc/passwd z UID 0, nowy wiersz w /etc/sudoers.d/.
• Zmienione pliki: nieznane pliki PHP na stronie internetowej, zmieniony crontab.
• Logi, które zniknęły lub są puste: atakujący chętnie zacierają ślady.

Kilka poleceń do szybkiego rozejrzenia się:

anna@web1:~$ top -o %CPU
anna@web1:~$ sudo ss -tunap | grep ESTAB
anna@web1:~$ sudo last -n 20
anna@web1:~$ awk -F: '$3 == 0 {print $1}' /etc/passwd
anna@web1:~$ sudo find /etc/systemd/system /etc/cron* -newer /etc/hostname -type f
anna@web1:~$ for u in /root /home/*; do sudo cat $u/.ssh/authorized_keys 2>/dev/null; done

last pokazuje, kto i kiedy się logował, wiersz z awk wyświetla wszystkie konta z UID 0 (powinno to być wyłącznie root), a wiersz z find wyszukuje unity i pliki cron nowsze niż plik utworzony podczas instalacji.

Uwaga: na serwerze, na który rzeczywiście się włamano, także te polecenia mogą być podmienione. Pomagają one coś podejrzewać, ale nie dowodzą, że wszystko jest czyste.

Pierwsze kroki: spokój, izolacja, dokumentacja

W pierwszych minutach najważniejsze jest, aby w panice niczego nie usuwać. Prosimy działać w tej kolejności.

1. Proszę założyć dziennik. Na papierze lub na laptopie (nie na serwerze) należy zapisywać, co Państwo widzą, kiedy i co robią. Będzie to potrzebne później, aby ustalić przyczynę, a także do zgłoszenia, zawiadomienia Policji lub dla ubezpieczyciela. Zaleca to również holenderskie NCSC.

2. Proszę odizolować serwer. Należy zapobiec dalszym szkodom (spam, ataki, wysyłanie danych) bez wyłączania serwera:

• w zaporze dostawcy (jeśli jest dostępna) proszę zablokować wszystko oprócz SSH z Państwa własnego adresu; lub
• zrobić to samo na samym serwerze, przez konsolę;
• jeśli nie ma innej możliwości: wyłączyć serwer w panelu. Wtedy jednak traci się zawartość pamięci.

3. Proszę wykonać snapshot. Snapshot w panelu utrwala obecny stan serwera. To Państwa dowód i źródło informacji, aby później ustalić, jak atakujący dostał się do środka, nawet jeśli serwer zostanie potem zainstalowany od nowa.

4. Proszę zabezpieczyć kopie zapasowe. Należy sprawdzić, czy kopie zapasowe poza serwerem są nadal nienaruszone, i zadbać o to, aby zaatakowany serwer nie miał już do nich dostępu (na przykład przez cofnięcie klucza dostępu serwera do magazynu kopii). Atakujący próbują również usuwać lub szyfrować kopie zapasowe.

Czyścić czy instalować od nowa?

Kusząca odpowiedź brzmi: usunąć podejrzany plik, zatrzymać koparkę kryptowalut i gotowe. Nie wiadomo jednak, co jeszcze zrobił atakujący: druga furtka, zmieniony program, dodatkowy klucz, timer, który wszystko przywraca. Serwerowi, na którym ktoś miał uprawnienia root, nie można już ufać.

Dlatego administratorzy, a także holenderskie NCSC, zalecają: proszę zainstalować zaatakowane systemy od nowa i przywrócić dane z kopii zapasowej, która sama nie jest zainfekowana. W praktyce:

1. Nowa instalacja (ponowna instalacja w panelu lub nowy serwer).
2. Od razu podstawy z tego kursu: aktualizacje, zwykły użytkownik z sudo, SSH z nowymi kluczami, zapora (moduły 2 do 5).
3. Ponowna instalacja aplikacji z oficjalnych źródeł, najlepiej przy użyciu plików compose lub notatek (lekcja 10.4).
4. Przywrócenie danych (baza danych, przesłane pliki) z kopii zapasowej sprzed incydentu. Proszę nie przywracać na ślepo kodu ani konfiguracji: mogą zawierać furtkę. Również przywrócone dane należy przejrzeć krytycznie; atakujący mógł być w systemie dłużej, niż się wydaje.
5. Załatanie luki, przez którą atakujący się dostał. W przeciwnym razie sytuacja się powtórzy. Przy ustalaniu przyczyny pomoże snapshot z kroku 3.

Wymiana wszystkiego, co mogło wyciec

Należy założyć, że wszystko, co znajdowało się na serwerze, jest w rękach atakującego:

• Klucze SSH: proszę usunąć wszędzie klucze publiczne, które były na serwerze, i utworzyć nowe pary kluczy, jeśli na serwerze znajdowały się klucze prywatne.
• Hasła do baz danych, paneli administracyjnych i użytkowników aplikacji.
• Klucze API i tokeny (poczta, płatności, magazyn w chmurze, magazyn kopii zapasowych) z plików .env i konfiguracji: proszę je unieważnić w danej usłudze i wymienić.
• Certyfikaty: klucz prywatny certyfikatu znajdował się na serwerze. Proszę unieważnić certyfikat i zamówić nowy (z Let's Encrypt idzie to szybko, lekcja 7.3).

Zgłaszanie: RODO i inne

Jeśli na serwerze były dane osobowe (dane klientów, konta, adresy e-mail), mogło dojść do naruszenia ochrony danych. RODO (artykuł 33) stanowi, że administrator danych zgłasza naruszenie organowi nadzorczemu bez zbędnej zwłoki i w miarę możliwości w ciągu 72 godzin od jego stwierdzenia. W Polsce jest to Prezes Urzędu Ochrony Danych Osobowych (UODO), a zgłoszenia dokonuje się przez formularz elektroniczny. Kilka najważniejszych zasad:

• zgłoszenie nie jest wymagane, jeśli naruszenie prawdopodobnie nie powoduje ryzyka dla osób, których dane dotyczą; w razie wątpliwości należy zgłosić;
• jeśli nie mają Państwo jeszcze wszystkich informacji, proszę mimo to zgłosić naruszenie w ciągu 72 godzin i uzupełnić je później;
• osoby, których dane wyciekły, należy poinformować, jeśli istnieje dla nich wysokie ryzyko;
• każde naruszenie należy odnotować we własnym rejestrze, także wtedy, gdy nie trzeba go zgłaszać.

Jeśli administrują Państwo serwerem dla klienta, są Państwo zazwyczaj podmiotem przetwarzającym: wtedy należy bez zbędnej zwłoki poinformować klienta (administratora danych), aby mógł dokonać zgłoszenia. Ta lekcja nie stanowi porady prawnej; w razie wątpliwości proszę zajrzeć na stronę UODO.

Ponadto: nadużycia popełnione z Państwa serwera proszę zgłosić dostawcy (często już je zauważył), a w przypadku poważnego ataku złożyć zawiadomienie na Policji. Jeśli Państwa organizacja podlega ustawie o krajowym systemie cyberbezpieczeństwa (KSC) po nowelizacji wdrażającej NIS2, obowiązują osobne, krótsze terminy zgłoszeń.

Przygotowanie: plan awaryjny

Incydent zawsze zdarza się w złym momencie. To, co załatwią Państwo wcześniej, oszczędza godziny:

• Proszę wiedzieć, jak dostać się do konsoli i przycisku snapshotu u dostawcy, i przechowywać dane logowania do panelu (z weryfikacją dwuetapową) w miejscu poza serwerem.
• Proszę wiedzieć, gdzie są kopie zapasowe, jak je przywrócić i że działają (lekcja 8.2).
• Proszę prowadzić listę wszystkich sekretów przechowywanych na serwerze, aby wiedzieć, co trzeba wymienić.
• Proszę mieć listę kontaktów: dostawca, kto jeszcze powinien wiedzieć o serwerze (klient, współpracownik) oraz dane kontaktowe do zgłoszenia naruszenia ochrony danych.

W praktyce

Na ekranie VPS w WebOké znajdą Państwo konsolę, snapshoty, kopie zapasowe i przycisk ponownej instalacji; u innych dostawców nazywają się one podobnie (console lub VNC, snapshot, rescue, reinstall). Ten kurs to samopomoc: nikt nie zagląda na Państwa serwer i nikt nie posprząta za Państwa po incydencie. Właśnie dlatego tak ważny jest plan awaryjny, który mogą Państwo wykonać samodzielnie.

Podsumowanie

• Sygnały: niewyjaśnione obciążenie, nieznane procesy, usługi lub klucze, dziwny ruch wychodzący, zmienione lub zniknięte pliki i logi.
• Pierwsze kroki: prowadzenie dziennika, izolacja serwera, snapshot jako dowód, zabezpieczenie kopii zapasowych.
• Serwera, na którym ktoś miał root, nie czyści się, lecz instaluje od nowa; dane przywraca się z czystej kopii zapasowej, a lukę się łata.
• Należy wymienić wszystkie klucze, hasła, tokeny i certyfikaty, które były na serwerze.
• Naruszone dane osobowe? Naruszenie zgłasza się w miarę możliwości w ciągu 72 godzin do Prezesa UODO, a każde naruszenie się odnotowuje.

Quiz

Zadanie

Zadanie O10.3: Plan awaryjny na jednej stronie. Proszę napisać dla własnego serwera plan awaryjny o objętości najwyżej jednej strony A4: jak dostać się do panelu, konsoli i snapshotów; gdzie są kopie zapasowe i jak je przywrócić; jakie sekrety znajdują się na serwerze; kogo trzeba poinformować (i czy w razie naruszenia ochrony danych trzeba je zgłosić); oraz jakie pięć pierwszych kroków podejmą Państwo przy podejrzeniu włamania. Plan proszę przechowywać poza serwerem.

Przeczytaj więcej

• Brak dostępu do VPS: co teraz?
• Snapshoty i kopie zapasowe VPS
• Podłączanie własnego ISO lub ponowna instalacja VPS
• Holenderskie NCSC, Gehackt, wat nu? (źródło w języku niderlandzkim): https://www.ncsc.nl/incidenten-en-herstellen/gehackt-wat-nu
• Prezes Urzędu Ochrony Danych Osobowych (UODO), zgłaszanie naruszeń ochrony danych: https://uodo.gov.pl/