Włamanie na serwer Linux, podobnie jak każde inne włamanie, nie zawsze jest oczywiste, a diagnoza „włamanie” jest najczęściej stawiana przez specjalistę na podstawie określonego sygnału lub zestawu sygnałów. Przykładem może być podejrzane logowanie przez SSH, nieznany proces, zmieniony plik konfiguracyjny lub nietypowe połączenie sieciowe. Zadaniem specjalisty jest powiązanie tych oznak ze sobą i ustalenie, co się wydarzyło, w jakiej kolejności oraz do jakich konsekwencji doprowadziło.
Nie zawsze są do tego potrzebne zaawansowane platformy monitorowania. W wielu przypadkach można rozpocząć od standardowych narzędzi systemu Linux: dzienników systemowych, historii uwierzytelniania, informacji o procesach, metadanych plików oraz ustawień automatycznego uruchamiania programów. Należy jednak rozumieć ograniczenia każdego źródła: dziennik może nie zawierać potrzebnego zdarzenia, a odnaleziony ślad nie zawsze oznacza, że dane działanie stanowi część kampanii włamań.
Od czego rozpoczyna się dochodzenie
Incident Response to ukierunkowana strategia działań realizowana po wystąpieniu incydentu bezpieczeństwa informacji. Obejmuje wykrywanie podejrzanych zdarzeń, ich analizę, ograniczanie zagrożenia, usuwanie skutków incydentu oraz przywracanie działania systemu.
Odtworzenie chronologii ataku jest jednym z kluczowych zadań tej strategii lub, jeśli ktoś woli, całego procesu. Specjalista musi odpowiedzieć na kilka pytań: w jaki sposób osoby atakujące mogły uzyskać początkowy dostęp, jakie działania zostały wykonane po uzyskaniu dostępu do systemu, czy udało się podnieść uprawnienia, czy osoba atakująca próbowała utrzymać dostęp oraz jakie dane lub usługi mogły ucierpieć.
Na początku procesu warto określić przedział czasowy incydentu, zebrać dostępne źródła danych i ustalić, które zdarzenia można niezależnie potwierdzić.
Na przykład wpis o udanym logowaniu przez SSH sam w sobie nie dowodzi naruszenia bezpieczeństwa systemu. Mogło to być logowanie administratora, zadanie zautomatyzowane lub działanie osoby atakującej, która posługiwała się skradzionymi danymi uwierzytelniającymi. Znaczenie zdarzenia staje się bardziej zrozumiałe, gdy zestawi się je z innymi zdarzeniami, czasem logowania, działaniami wykonanymi na koncie oraz zmianami na serwerze.
Gdzie w systemie Linux szukać śladów
W systemie Linux nie ma jednego dziennika, w którym rejestrowane jest absolutnie wszystko, co dzieje się w systemie. Poszczególne komponenty zapisują zdarzenia w różnych miejscach, a zakres dostępnych danych zależy od dystrybucji, konfiguracji i wcześniej włączonych mechanizmów audytu.
Jednym z głównych źródeł jest dziennik systemowy systemd-journald. Zdarzenia z bieżącego dnia można wyświetlić za pomocą polecenia:
sudo journalctl --since today
Aby ograniczyć wyniki do zdarzeń związanych z SSH, w systemach, w których usługa nosi nazwę ssh, można użyć polecenia:
sudo journalctl -u ssh --since today
W innych dystrybucjach usługa może nazywać się sshd. Jeśli polecenie nie zwróci żadnych wyników, nie oznacza to jeszcze, że SSH nie było używane. Należy sprawdzić nazwę usługi, dostępny okres przechowywania danych oraz ustawienia rejestrowania zdarzeń.
W systemach Debian i Ubuntu zdarzenia związane z uwierzytelnianiem są często dostępne w pliku /var/log/auth.log. W systemach z rodziny RHEL do tego celu często wykorzystywany jest plik /var/log/secure. Konkretna konfiguracja może się jednak różnić, dlatego tych ścieżek nie należy traktować jako uniwersalnych.
Aby wyszukać nieudane i udane próby logowania w dzienniku systemów Ubuntu lub Debian, można wykonać polecenie:
sudo grep -E 'Failed password|Accepted password|Invalid user' /var/log/auth.log
Polecenie wyszukuje określone komunikaty tekstowe związane z uwierzytelnianiem SSH. Nie obejmuje wszystkich możliwych sposobów logowania i nie zastępuje analizy pełnego dziennika. Jeśli plik nie istnieje, należy sprawdzić dziennik systemowy, rotację logów oraz konfigurację SSH.
Przydatne są również inne źródła. Polecenie last wyświetla informacje o logowaniach pobrane z bazy danych sesji, zwykle z pliku /var/log/wtmp. Polecenie lastb, jeśli odpowiednia baza istnieje i jest prowadzona, pomaga analizować nieudane próby logowania. Dane uzyskane za pomocą tych poleceń nie stanowią jednak pełnego dziennika wszystkich działań użytkownika.
Osobno warto sprawdzić dzienniki aplikacji, serwera WWW, bazy danych, systemu uwierzytelniania oraz narzędzi audytowych. Jeśli domniemanym punktem wejścia jest podatna aplikacja internetowa, same dzienniki systemowe mogą okazać się niewystarczające.
Jak odtworzyć sekwencję zdarzeń
Główna trudność w dochodzeniu nie polega na liczbie logów, lecz na konieczności prawidłowego powiązania ich ze sobą.
Załóżmy, że w dzienniku SSH znaleziono następujące wpisy:
- 14:01:02 Failed password for admin from 203.0.113.55
- 14:01:05 Failed password for admin from 203.0.113.55
- 14:01:11 Accepted password for admin from 203.0.113.55
Uwaga: adres pochodzi z przykładów wykorzystywanych w dokumentacji szkoleniowej.
Na podstawie tych wpisów można wyciągnąć ograniczony, ale przydatny wniosek: najpierw wystąpiły dwie nieudane próby uwierzytelnienia, po czym serwer zarejestrował udane logowanie użytkownika admin.
Czy można stwierdzić, że serwer został zhakowany? Na tym etapie jeszcze nie. Należy ustalić, do kogo należy konto, czy takie logowanie było oczekiwane, czy adres należy do znanej infrastruktury oraz jakie działania nastąpiły po udanym uwierzytelnieniu.
Następnym krokiem jest sprawdzenie zdarzeń związanych z uprawnieniami i procesami. Na przykład dziennik sudo może zawierać wpis o uruchomieniu polecenia przez użytkownika z podwyższonymi uprawnieniami. Ważne jest jednak rozróżnienie faktu wydania polecenia, jego uruchomienia i pomyślnego zakończenia: konkretny wpis w dzienniku nie zawsze potwierdza wszystkie trzy okoliczności.
Następnie należy przeanalizować procesy, połączenia sieciowe i zmiany w plikach. Jeśli po podejrzanym logowaniu pojawił się nieznany proces, nawiązał połączenie z zewnętrznym adresem i zmienił konfigurację automatycznego uruchamiania, łączny obraz tych oznak znacząco wzmacnia podejrzenia.
Na potrzeby dochodzenia należy utworzyć oś czasu obejmującą czas zdarzenia, źródło danych, zaobserwowany fakt oraz poziom pewności interpretacji.
Jakie polecenia pomagają sprawdzić ślady systemowe
Po przeanalizowaniu dzienników uwierzytelniania warto przejść do sprawdzenia stanu systemu, w szczególności uruchomionych procesów.
Polecenie: ps aux
wyświetla procesy działające w chwili wykonania polecenia. Pomaga znaleźć nieznane programy, nietypowe argumenty uruchomienia oraz procesy działające z uprawnieniami uprzywilejowanych użytkowników.
Lista procesów jest jednak jedynie migawką bieżącego stanu, a nie historią uruchomień. Jeśli podejrzany program już się zakończył, standardowy wynik polecenia ps go nie pokaże. Do odtworzenia wcześniejszych uruchomień mogą być potrzebne wcześniej skonfigurowany audyt, telemetria bezpieczeństwa lub inne dzienniki.
Bieżące połączenia sieciowe można sprawdzić za pomocą polecenia: sudo ss -plant
Wyświetla ono gniazda TCP, procesy i powiązane z nimi informacje, o ile jest to obsługiwane i dostępne dla danego użytkownika. Polecenie pomaga analizować aktualne połączenia, ale nie odtwarza wszystkich połączeń, które istniały w przeszłości.
Szczególną uwagę należy zwrócić na mechanizmy automatycznego uruchamiania. Osoba atakująca, która uzyskała dostęp, może próbować go utrzymać po ponownym uruchomieniu systemu lub zakończeniu pierwotnego procesu.
Do wstępnego sprawdzenia zadań cron można użyć poleceń:
crontab -l sudo crontab -l
Pierwsze polecenie wyświetla zadania bieżącego użytkownika, a drugie — użytkownika root. Należy również sprawdzić zadania systemowe, katalogi konfiguracyjne cron oraz pozostałe konta użytkowników.
W systemach korzystających z systemd należy także sprawdzić usługi i jednostki typu timer:
systemctl list-units --type=service --all systemctl list-unit-files --type=service systemctl list-timers --all
Pierwsze polecenie pokazuje usługi załadowane przez systemd, także nieaktywne, drugie — zainstalowane pliki jednostek, a trzecie — timery.
Nieznana usługa lub jednostka typu timer nie musi być złośliwa. Należy porównać ją z zainstalowanymi pakietami, przeznaczeniem serwera, czasem pojawienia się oraz zawartością odpowiednich plików konfiguracyjnych. Podobnie warto sprawdzić klucze SSH w pliku authorized_keys, zwłaszcza jeśli ich pojawienie się pokrywa się w czasie z podejrzanym logowaniem.
Dlaczego jedno źródło nie wystarcza
Każde źródło ma swoje ograniczenia.
Dziennik systemowy może nie zawierać danego zdarzenia, jeśli odpowiedni komponent nie rejestrował zdarzeń lub starsze wpisy zostały już usunięte podczas rotacji logów. Historia poleceń powłoki może być niekompletna: polecenia niekoniecznie są zapisywane natychmiast, a niektóre działania wykonywane są bez użycia interaktywnej powłoki. Bieżąca lista procesów pokazuje wyłącznie to, co jest uruchomione w danej chwili. Czas modyfikacji pliku również nie wskazuje automatycznie, kto i dlaczego go zmienił.
Dlatego wnioski należy opierać na całokształcie dostępnych dowodów. Na przykład wpis o udanym logowaniu przez SSH potwierdza fakt uwierzytelnienia zgodnie z dziennikiem. Wpis audytowy może wskazywać na uruchomienie procesu. Zmieniony plik usługi może sugerować próbę utrwalenia obecności osoby atakującej w systemie. Dzienniki sieciowe mogą pomóc ustalić, z jakimi adresami komunikował się system.
Jeśli kilka niezależnych źródeł jest ze sobą zgodnych, hipoteza staje się bardziej wiarygodna. Nawet wtedy ważne jest jednak oddzielenie potwierdzonych faktów od przypuszczeń.
Do bardziej szczegółowego audytu w systemie Linux można wykorzystać narzędzie auditd. Może ono rejestrować określone zdarzenia systemowe, jeśli odpowiednie reguły zostały skonfigurowane wcześniej. Należy pamiętać, że zainstalowanie narzędzia po wykryciu incydentu nie pozwala uzyskać wstecznie informacji o zdarzeniach, które wcześniej nie były rejestrowane.
Kontenery i Kubernetes
Opisane podejście dobrze sprawdza się w przypadku klasycznego serwera Linux — maszyny fizycznej lub wirtualnej o stosunkowo trwałym systemie plików. Jeśli dziennik został zapisany na dysku i nie został usunięty ani nadpisany, można go przeanalizować po pewnym czasie. W infrastrukturze kontenerowej sytuacja wygląda inaczej, co zmienia samą logikę dochodzenia.
Kontenery są często tworzone na podstawie obrazów, uruchamiane na ograniczony czas i zastępowane podczas aktualizacji aplikacji lub skalowania. Jeśli kontener zakończy działanie, Kubernetes może uruchomić jego nową instancję. Poprzednia instancja przestaje działać, a jej dzienniki bywają dostępne tylko przez ograniczony czas. Jeśli obiekt Pod zostanie usunięty, odtworzenie jego stanu za pomocą standardowych poleceń może być już niemożliwe. Dlatego dzienniki, system plików i stan procesów wewnątrz kontenera nie powinny być jedynymi źródłami dowodów.
Pierwszą rzeczą, którą warto sprawdzić, jest to, czy zachowały się dzienniki zakończonego kontenera. Na przykład polecenie:
kubectl logs
umożliwia pobranie dzienników poprzedniej instancji kontenera, jeśli są jeszcze dostępne. Parametr -c określa nazwę kontenera wewnątrz obiektu Pod, co jest szczególnie istotne, gdy kontenerów jest kilka.
Polecenie to nie jest jednak uniwersalnym sposobem odzyskiwania utraconych danych: jeśli obiekt Pod został usunięty lub dzienniki zostały już wyczyszczone, mogą być niedostępne. Dlatego w Kubernetes należy z wyprzedzeniem zorganizować przesyłanie logów aplikacji do zewnętrznego repozytorium, niezależnego od cyklu życia kontenerów.
Dalsza część dochodzenia wykracza poza sam kontener. W Kubernetes ważne jest ustalenie nie tylko tego, co robiła aplikacja, ale także tego, kto zarządzał klastrem. Do tego służy Kubernetes Audit Logging — mechanizm rejestrowania żądań kierowanych do serwera API. W zależności od skonfigurowanej polityki audyt może pomóc ustalić, kto tworzył i usuwał obiekty Pod, zmieniał ustawienia kontroli dostępu RBAC lub wykonywał operacje exec wewnątrz kontenera.
Podczas analizy należy uwzględnić identyfikator użytkownika lub konta usługi, czas żądania, jego typ oraz wynik. Sam fakt włączenia audytu nie oznacza jeszcze, że każde działanie zostanie zapisane: kompletność danych zależy od konfiguracji, a zawartość dzienników — od poziomu audytu.
Dodatkowym źródłem są zdarzenia klastra, które można wyświetlić za pomocą polecenia:
kubectl get events -A --sort-by=.metadata.creationTimestamp
Polecenie wyświetla dostępne zdarzenia we wszystkich przestrzeniach nazw i sortuje je według czasu utworzenia. Na ich podstawie można wykryć na przykład powtarzające się ponowne uruchomienia kontenerów, błędy uruchamiania lub problemy z rozmieszczeniem obiektów Pod.
Zdarzenia Kubernetes mają jednak ograniczony okres przechowywania i służą przede wszystkim do prezentowania stanu klastra, a nie do długoterminowego badania incydentów. Po upływie okresu przechowywania potrzebne zdarzenia mogą już nie być dostępne. Dlatego należy traktować je jako uzupełnienie dzienników i audytu, a nie jako gwarantowanie zachowaną historię incydentu.
Istnieje również kolejny poziom obserwacji — węzeł, na którym działał kontener. Komponenty takie jak containerd i CRI-O uczestniczą w uruchamianiu kontenerów i komunikacji z Kubernetes. Na węźle mogą zachować się dzienniki kontenerów, informacje o środowisku uruchomieniowym (runtime) oraz zdarzenia systemowe.
Jest to przydatne, gdy instancja kontenera już zakończyła działanie, ale sam węzeł nadal pracuje. Lokalizacja plików, format dzienników i okres przechowywania zależą jednak od konfiguracji. Ponowne uruchomienie lub odtworzenie obiektu Pod, rotacja logów i czyszczenie danych środowiska uruchomieniowego mogą ograniczyć dostępność śladów. Ponadto nie każdy dziennik środowiska uruchomieniowego zawiera pełną historię uruchomienia i wszystkie parametry kontenera.
Należy również uwzględnić ograniczenia widoczności standardowych poleceń systemu Linux. Polecenia ps aux i ss -plant wykonane wewnątrz kontenera pokazują procesy i połączenia sieciowe w granicach dostępnych przestrzeni nazw i uprawnień. Do wstępnej kontroli może to wystarczyć, ale taki wynik nie przedstawia pełnego obrazu węzła. Jeśli istnieje podejrzenie ucieczki z kontenera lub naruszenia bezpieczeństwa samego węzła, należy osobno zbadać host i jego telemetrię.
Do zapewnienia bardziej zaawansowanej obserwowalności stosuje się narzędzia oparte na eBPF, na przykład Falco i Tetragon. Mogą one śledzić określone zdarzenia jądra, uruchamianie procesów oraz aktywność plikową i sieciową. W połączeniu z metadanymi Kubernetes taka telemetria pomaga powiązać zdarzenie z konkretnym obiektem Pod lub kontenerem.
Narzędzia te nie zapewniają jednak pełnej widoczności i nie gwarantują, że ich działanie nie zostanie pominięte. Wynik zależy od konfiguracji, dostępnych zdarzeń, uprawnień, stanu agenta oraz miejsca przechowywania zebranych danych.
Ogólna zasada pozostaje taka sama jak w przypadku badania klasycznego serwera Linux: dowody należy gromadzić z wyprzedzeniem. Jeśli audyt Kubernetes nie był włączony, dzienniki kontenerów nie były przesyłane do zewnętrznego repozytorium, a narzędzia monitorujące zdarzenia jądra nie działały przed incydentem, odtworzenie brakującej historii po fakcie jest często niemożliwe.
Różnica między klasycznym serwerem a infrastrukturą kontenerową nie polega na tym, że jedno środowisko łatwiej zbadać, a drugie trudniej. Chodzi o to, gdzie powstają ślady, jak długo są dostępne i kto odpowiada za ich zachowanie. Dlatego strategia Incident Response dla Kubernetes powinna obejmować kilka poziomów jednocześnie: aplikację i kontener, węzeł, środowisko uruchomieniowe oraz zarządzające API klastra. To właśnie spójność tych źródeł pozwala odtworzyć sekwencję ataku, gdy poszczególne komponenty zdążyły już zniknąć.
Kiedy problemem nie jest hasło, lecz token
Przykład ataku polegającego na odgadywaniu hasła SSH, przedstawiony na początku artykułu, jest wygodnym przypadkiem szkoleniowym. W praktyce jednak w przypadku współczesnego serwera Linux lub kontenera dostęp do środowiska coraz częściej uzyskuje się nie za pomocą hasła, lecz przy użyciu skradzionych danych uwierzytelniających innego rodzaju: tokenu dostawcy usług chmurowych, certyfikatu SSH o krótkim okresie ważności, klucza API przypadkowo umieszczonego w repozytorium albo zmiennej środowiskowej odczytanej z przejętego potoku CI/CD.
Różnica ma istotne znaczenie metodologiczne. Wyciek hasła zazwyczaj pozostawia klasyczny ślad — nieudane i udane próby logowania w dzienniku uwierzytelniania. Skradziony token do usług chmurowych lub API może natomiast w ogóle nie wiązać się z logowaniem na serwerze, a skradziony klucz lub certyfikat SSH zostawi wpis o udanym logowaniu, który wygląda jak zwykła sesja i nie jest poprzedzony nieudanymi próbami. W obu przypadkach osoba atakująca korzysta z aktywnych uprawnień, więc dla systemów uwierzytelniania jej działania wyglądają jak zwyczajna, niczym nie wyróżniająca się aktywność.
W takiej sytuacji journalctl i auth.log mogą nie zawierać żadnych podejrzanych wpisów, mimo że bezpieczeństwo dostępu do systemu zostało już naruszone.
Oznacza to, że zakres źródeł danych podlegających kontroli musi zostać rozszerzony. Oprócz logów samego serwera warto sprawdzić:
- dzienniki wydawania i wykorzystywania tokenów po stronie dostawcy tożsamości, w tym logi IAM w AWS, GCP lub Azure, jeśli serwer działa w chmurze;
- historię commitów i sekrety przechowywane w repozytoriach;
- dzienniki systemów CI/CD, pozwalające ustalić, kto, kiedy i z jakimi uprawnieniami uruchamiał potok;
- lokalizację geograficzną oraz wzorce wykorzystania tokenu, porównując je z oczekiwanym zachowaniem legalnego procesu lub użytkownika.
Do tej listy warto dodać jeszcze jedną kategorię: narzędzia AI wykorzystywane w firmie — konektory i agenci podłączani do poczty czy plików mogą działać z uprawnieniami użytkownika, więc ich aktywność bywa trudna do odróżnienia od działań samego konta. Zasady bezpiecznego korzystania z takich narzędzi, w tym Shadow AI, klasyfikację danych i zasadę najmniejszych uprawnień, omawia szkolenie Bezpieczne korzystanie z AI w firmie: ChatGPT, Copilot i ochrona danych.
Nie unieważnia to żadnego z wcześniejszych wniosków dotyczących klasycznych logów — nadal pozostają one podstawowym źródłem informacji tam, gdzie dostęp uzyskiwany jest za pomocą hasła lub klucza przechowywanego bezpośrednio na serwerze.
Jeśli jednak infrastruktura opiera się na chmurowych danych uwierzytelniających, już od początku dochodzenia należy pamiętać, że brak podejrzanych wpisów w /var/log nie oznacza, że do naruszenia bezpieczeństwa nie doszło. Być może atak po prostu nie pozostawił śladów w źródłach, które sprawdzono jako pierwsze.
Co zrobić, jeśli ślady wskazują na włamanie
Wykrycie podejrzanej aktywności nie jest powodem, aby natychmiast usuwać nieznane pliki lub ponownie uruchamiać serwer. Takie działania mogą zniszczyć istotne dowody, zmienić stan systemu lub utrudnić odtworzenie sekwencji zdarzeń.
Pierwszą decyzją powinno być ustalenie, jak aktywne jest zagrożenie i czy konieczne jest pilne odizolowanie systemu od sieci. Jeśli osoba atakująca nadal prowadzi działania, ograniczenie zagrożenia może być ważniejsze niż zebranie pełnego zestawu dowodów. Należy przy tym uwzględnić konsekwencje dla działalności biznesowej i krytyczność systemu. Odizolowanie od sieci, zatrzymanie wybranych procesów i wyłączenie serwera to różne środki, które należy wybierać ze świadomością, jakie dane mogą zostać utracone.
Szczególnie trudna bywa ta decyzja przy ataku ransomware, gdzie widoczne szyfrowanie danych i presja czasu wymuszają reakcję biznesową niemal natychmiast — często zanim dochodzenie techniczne zdąży się w pełni rozwinąć. Konflikt między zabezpieczeniem dowodów a szybkim przywróceniem działania warto przećwiczyć zawczasu, zamiast rozstrzygać go w trakcie ataku. Taki scenariusz — od pierwszego alarmu, przez izolację, aż po odbudowę środowiska — rozpisuje szkolenie Ransomware bez paniki — jak przygotować firmę, przetrwać atak i odzyskać dane.
Jeśli jest to możliwe i bezpieczne, przed wprowadzeniem istotnych zmian należy zachować dostępne dzienniki, odnotować czas i bieżący stan systemu, zebrać informacje o procesach i połączeniach sieciowych, a także udokumentować wykonane działania. W przypadku poważnych incydentów ważne jest zapewnienie integralności kopii, ograniczenie dostępu do nich i prowadzenie ewidencji przekazywania materiałów.
Ten artykuł koncentruje się na technicznej stronie dochodzenia — na tym, co faktycznie można ustalić z logów i śladów systemowych. Równolegle z pracą techniczną zespół musi jednak podejmować decyzje organizacyjne: kogo informować, czy i kiedy zgłosić incydent, kto ma prawo podjąć decyzję o izolacji systemu krytycznego dla biznesu. Tej stronie procesu — pierwszej godzinie po wykryciu ataku, rozpisanej na pierwsze 10 minut, 30 minut i całą godzinę, wraz z zasadami prowadzenia dziennika decyzji i wcześniejszymi upoważnieniami do izolacji systemów — poświęcone jest osobne szkolenie Pierwsze 60 minut po cyberataku — praktyczne reagowanie na incydenty.
W infrastrukturze kontenerowej dochodzi do tego osobne zadanie: zachowanie danych, które mogą zniknąć wraz z kontenerem lub obiektem Pod. Mogą to być logi aplikacji, zdarzenia Kubernetes, wpisy audytowe serwera API oraz telemetria węzła. Jeśli logi są przesyłane do zewnętrznego repozytorium, należy sprawdzić, jakie dane zdążyły już tam trafić. Nie należy zakładać, że po usunięciu obiektu Pod będzie można je odzyskać za pomocą standardowych poleceń.
Jeśli istnieją oznaki usuwania logów, przejęcia konta administratora lub ingerencji w system rejestrowania zdarzeń, nie można ufać lokalnym danym bez dodatkowej weryfikacji. W takiej sytuacji mogą być potrzebne scentralizowane dzienniki, dane z monitorowania sieci, kopie zapasowe oraz informacje z zewnętrznych systemów monitorujących.
Po ograniczeniu zagrożenia należy ustalić przyczynę incydentu, usunąć podatność, sprawdzić dane uwierzytelniające i klucze dostępu oraz określić bezpieczny sposób przywrócenia działania systemu. W systemach kontenerowych należy dodatkowo sprawdzić obrazy, konfiguracje wdrożeniowe, uprawnienia kont usługowych i ustawienia klastra.
Samo usunięcie podejrzanego procesu lub ponowne utworzenie kontenera nie gwarantuje, że osoba atakująca utraciła dostęp.
Jak zorganizować dochodzenie w praktyce
Zamiast próbować analizować cały system jednocześnie, lepiej postępować metodycznie, krok po kroku.
Najpierw określa się przybliżony przedział czasowy incydentu i ustala, jakie źródła danych są dostępne. Następnie analizuje się zdarzenia uwierzytelniania i powiązane z nimi działania. Później bada się procesy, aktywność sieciową, zmiany w plikach oraz mechanizmy automatycznego uruchamiania.
Jeśli serwer działa w Kubernetes, do tych kroków należy dodać sprawdzenie logów kontenerów, zdarzeń klastra, audytu serwera API oraz danych z węzła.
Na podstawie odnalezionych dowodów tworzy się oś czasu, zaznaczając, co zostało potwierdzone, co pozostaje przypuszczeniem i jakie dane trzeba jeszcze pozyskać. Podczas porównywania źródeł należy uwzględnić strefy czasowe, synchronizację zegarów oraz możliwe luki w rejestrowaniu zdarzeń.
Do uporządkowania wyników można wykorzystać MITRE ATT&CK — bazę wiedzy o taktykach i technikach stosowanych przez przeciwników. Na przykład zmiana kluczy SSH, tworzenie usług systemd i nadużywanie mechanizmu cron należą do znanych metod utrzymywania dostępu w systemie Linux.
W Kubernetes należy dodatkowo analizować działania związane z uprawnieniami dostępu, wykonywaniem poleceń wewnątrz kontenerów oraz modyfikowaniem zasobów klastra. Klasyfikacja pomaga w jednolity sposób opisywać zaobserwowane zachowania, ale sama w sobie nie dowodzi, że dana technika została zastosowana w badanym incydencie.
Na koniec należy rozdzielić dwa pytania: co się wydarzyło i w jakim stopniu udało się to ustalić. Brak podejrzanych wpisów nie dowodzi braku ataku. Może oznaczać, że potrzebne zdarzenia nie były rejestrowane, dzienniki zostały już usunięte lub wykorzystywane narzędzia nie zapewniały odpowiedniej widoczności.
Podsumowanie
Badanie ataku na system Linux nie polega na znalezieniu jednego podejrzanego polecenia, lecz na systematycznej analizie wielu źródeł danych. Dzienniki uwierzytelniania pomagają badać logowania do systemu, informacje o procesach i połączeniach ujawniają część aktywności, a zmiany w plikach i mechanizmy automatycznego uruchamiania pomagają zweryfikować hipotezę o utrwaleniu dostępu przez osobę atakującą.
W infrastrukturze kontenerowej obowiązuje ta sama zasada, ale źródła dowodów są rozproszone między aplikacją, kontenerem, węzłem i warstwą zarządzającą Kubernetes. Tymczasowy charakter kontenerów sprawia, że wcześniejsze skonfigurowanie gromadzenia i przechowywania telemetrii ma szczególne znaczenie.
Główne ograniczenie polega na tym, że ani Linux, ani Kubernetes nie rejestrują automatycznie każdego działania. Kompletność dochodzenia zależy od konfiguracji, zachowania dzienników, dostępności telemetrii oraz narzędzi audytowych działających przed incydentem. Jeśli niezbędne zdarzenia nie były rejestrowane, ich odtworzenie po fakcie jest często niemożliwe.
Przed rozpoczęciem dochodzenia warto odpowiedzieć na pięć pytań:
- Jakie źródła danych są dostępne i z jakiego okresu zachowały się wpisy?
- Które zdarzenia potwierdzają uzyskanie początkowego dostępu i co wiadomo o późniejszych działaniach?
- Czy istnieją niezależne dowody uruchomienia podejrzanych procesów, modyfikacji plików lub nietypowej aktywności sieciowej?
- Jakie dane mogły zostać utracone, zmienione lub usunięte, w tym podczas ponownego uruchamiania kontenerów lub usuwania obiektów Pod?
- Jakie działania pozwolą ograniczyć zagrożenie, a jednocześnie zachować wystarczającą ilość informacji do zweryfikowania wniosków?
Jeśli na część pytań nie ma jeszcze odpowiedzi, nie oznacza to, że dochodzenie jest niemożliwe. Oznacza to, że należy wskazać luki w dostępnych informacjach, zebrać dodatkowe dowody i nie wyciągać wniosków, których nie potwierdzają dostępne dane.
