Krótko: Podejrzane procesy na serwerach Linux rozpoznają Państwo po kilku cechach: plik programu usunięty lub w /tmp, /dev/shm albo w katalogu WWW, nazwa naśladuje proces systemowy, nietypowy użytkownik, trwałe połączenia sieciowe lub duże obciążenie bez powodu. Poleceniami tylko do odczytu proszę sprawdzić, czy plik programu należy do zainstalowanego pakietu, i zabezpieczyć znaleziska, zanim cokolwiek zostanie zakończone.
Co oznacza „podejrzany” w odniesieniu do procesu
Na serwerze WWW działają setki procesów. Większość należy do systemu operacyjnego, serwera WWW, bazy danych lub PHP. Atakujący, który przez lukę taką jak PHP2Shell mógł wykonać kod, próbuje się między nimi nie wyróżniać. Wybiera niepozorne nazwy i umieszcza programy tam, gdzie użytkownik serwera WWW może zapisywać.
Przy kontroli pomaga znajomość stanu normalnego. Kto wie, jakie usługi mają działać na serwerze, pod jakimi użytkownikami i z jakim obciążeniem, rozpoznaje odchylenia znacznie szybciej. Jeśli tej wiedzy brakuje, warto do porównania wziąć listę procesów podobnego, niepodejrzanego serwera.
Pojedyncza cecha nie jest jeszcze dowodem. Rozstrzyga ich współwystępowanie. Proces o nazwie wątku jądra, który działa pod www-data, został uruchomiony z /dev/shm i utrzymuje połączenie z zagranicą, to jasny przypadek. Jak sprawdzić szczególny przypadek powłoki pod serwerem WWW, opisuje Sygnał ostrzegawczy: serwer WWW uruchamia powłokę.
Pierwszy przegląd w pięciu poleceniach
Wszystkie polecenia tylko odczytują dane. Proszę je wykonać jako root, aby widzieć wszystkie procesy, i zapisać wyniki do pliku poza katalogiem WWW.
# 1. Wszystkie procesy z użytkownikiem, PID rodzica, czasem startu, CPU i wierszem poleceń
ps -eo user,pid,ppid,lstart,%cpu,%mem,cmd --sort=-%cpu | head -40
# 2. Procesy, których plik programu został usunięty
ls -l /proc/[0-9]*/exe 2>/dev/null | grep "(deleted)"
# 3. Procesy działające z katalogów tymczasowych lub WWW
ls -l /proc/[0-9]*/exe 2>/dev/null | grep -E " -> (/tmp|/var/tmp|/dev/shm|/var/www)"
# 4. Procesy z połączeniami sieciowymi
ss -tunap
# 5. Przegląd procesów użytkowników serwera WWW
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) "
Nazwy użytkowników różnią się w zależności od dystrybucji i panelu; Plesk i inne panele często uruchamiają PHP pod użytkownikiem danego klienta. Listę proszę dostosować do swojego środowiska.
Wyniki proszę czytać z uwzględnieniem czasu startu. Procesy działające od ostatniego restartu serwera zwykle należą do systemu. Uwagi wymagają procesy uruchomione w środku nocy lub w dniach po 17 października, które nie pasują do żadnej usługi. Proszę też porównać liczbę procesów PHP z tym, na co pozwala konfiguracja puli; wyraźnie więcej procesów pod użytkownikiem serwera WWW to wskazówka.
Podejrzane procesy w Linuxie: typowe cechy
| Cecha | Dlaczego zwraca uwagę | Czy możliwe niegroźne wyjaśnienie? |
|---|---|---|
| Plik programu „(deleted)” | atakujący usuwają pliki po uruchomieniu | tak, po aktualizacjach pakietów do restartu |
Miejsce startu /tmp, /dev/shm, katalog uploadu |
tam może zapisywać każdy lub serwer WWW | rzadko |
Nazwa w nawiasach kwadratowych, jak [kworker] |
naśladuje wątki jądra | nie, jeśli za nią stoi plik programu |
| Trwale duże obciążenie CPU bez powodu | typowe dla koparek kryptowalut | tak, przy zadaniach wsadowych lub indeksowaniu |
| Proces nadrzędny 1 i użytkownik serwera WWW | oderwany od serwera WWW, działa samodzielnie dalej | rzadko |
| Połączenie z nieznanym celem | sterowanie lub wyciek danych | tak, przy aktualizacjach i API |
Prawdziwe wątki jądra nie mają pliku programu; ls -l /proc/PID/exe nie zwraca dla nich ścieżki. Jeśli proces z nazwą jądra wskazuje na plik, jest zamaskowany. Przy dużym obciążeniu bez widocznego powodu pomaga artykuł Koparka kryptowalut na serwerze WWW.
Kontrola krzyżowa: czy plik programu należy do pakietu?
Niemal wszystkie uzasadnione programy na serwerze pochodzą z zarządzania pakietami. Plik programu, który nie należy do żadnego pakietu, nie jest automatycznie szkodliwy, ale zasługuje na dokładne spojrzenie.
PID=12345
EXE=$(readlink /proc/$PID/exe); echo "$EXE"
dpkg -S "$EXE" # Debian/Ubuntu: do jakiego pakietu należy plik?
rpm -qf "$EXE" # rodzina RHEL
sha256sum /proc/$PID/exe # suma kontrolna, działa także przy usuniętym pliku
tr '\0' ' ' < /proc/$PID/environ | head -c 600; echo # zmienne środowiskowe
Jeśli plik programu jest usunięty, sha256sum /proc/$PID/exe i tak odczytuje go z działającego procesu. Ta suma kontrolna należy do dokumentacji. Kopię pliku powinna wykonać tylko osoba, która wie, jak bezpiecznie ją przechowywać.
Granice kontroli na działającym systemie
Wszystkie powyższe polecenia ufają systemowi, który właśnie Państwo sprawdzają. Przy zwykłym włamaniu przez stronę z uprawnieniami użytkownika serwera WWW jest to uzasadnione. Jeśli atakujący zdobył uprawnienia roota, może ukrywać procesy i fałszować wyniki. Wtedy serwer pokazuje tylko to, na co pozwala atakujący.
Wskazówkami są sprzeczności: obciążenie bez widocznego procesu, połączenia, które widzi firewall, a ss nie, albo zmienione programy systemowe. W takich przypadkach kontrola należy do zabezpieczonego obrazu. W działających systemach dochodzi często zabezpieczenie pamięci operacyjnej, ponieważ niektóre szkodliwe programy istnieją tylko tam i na dysku zostawiają niewiele śladów. To zabezpieczenie musi nastąpić przed restartem i wymaga odpowiednich narzędzi oraz doświadczenia. Dlaczego warto je wykonać przed ponowną instalacją, wyjaśnia Zabezpieczanie dowodów przed ponowną instalacją.
Proszę nie kończyć podejrzanych procesów jako pierwszego kroku. Często uruchamia je ponownie zadanie cron lub usługa, a wraz z procesem znikają z pamięci wiersz poleceń, połączenia i usunięty plik programu.
Kontrola autostartów i kolejne kroki
Szkodliwy proces, który po restarcie by zniknął, byłby dla atakujących bezwartościowy. Dlatego do każdego znaleziska procesu należy pytanie, co go uruchamia. Obok zadań cron wchodzą w grę przede wszystkim usługi systemd, które atakujący z uprawnieniami roota może założyć. Zwracają uwagę usługi z ogólnymi nazwami, których plik programu leży w nietypowym katalogu, oraz pliki unit utworzone po 17 października.
# Działające usługi i niedawno zmienione pliki unit
systemctl list-units --type=service --state=running --no-pager
find /etc/systemd /usr/lib/systemd /lib/systemd -type f -newerct "2026-10-17" -ls 2>/dev/null
# Czy biblioteka jest wstrzykiwana do każdego procesu? Plik zwykle nie istnieje.
ls -l /etc/ld.so.preload 2>/dev/null && cat /etc/ld.so.preload
Wpis w /etc/ld.so.preload jest na normalnych serwerach WWW rzadki i stanowi silną wskazówkę manipulacji z uprawnieniami roota. Jak w pełni sprawdzić zaplanowane zadania, opisuje Rozpoznawanie ukrytych zadań cron jako tylnej furtki.
Potem następują kolejne kroki w tej kolejności:
- Zabezpieczyć wyniki i sumy kontrolne z godziną.
- Szukać mechanizmów trwałości: zadania cron, usługi i timery systemd, klucze SSH.
- Wyjaśnić pochodzenie: logi od 20 października, nowe pliki w katalogu WWW.
- Izolować serwer i zaplanować oczyszczenie lub budowę od nowa.
Przegląd wszystkich typowych oznak po PHP2Shell daje Czy już zostałem skompromitowany?.
Jak konkretnie pomaga PHP SOS?
- Ocenić procesy: Sprawdzamy listę procesów, pliki programów i połączenia oraz oceniamy każde znalezisko.
- Zabezpieczyć w sposób dopuszczalny w sądzie: W ramach informatyki śledczej zabezpieczamy pamięć operacyjną i nośniki, zanim cokolwiek zostanie zmienione.
- Znaleźć mechanizmy trwałości: Szukamy mechanizmów, które ponownie uruchamiają szkodliwe procesy.
- Zamknąć sprawę: Oczyszczamy lub budujemy od nowa i dokumentujemy incydent aż do zamknięcia.
Częste pytania
Po czym poznać podejrzany proces w Linuxie?
Typowe cechy to usunięty plik programu, miejsce startu w /tmp lub /dev/shm, nazwa naśladująca proces systemowy, nietypowy użytkownik i trwałe połączenia sieciowe. Pojedyncze cechy są wskazówkami, kilka razem to poważne podejrzenie.
Co oznacza „(deleted)” przy /proc/PID/exe?
Plik programu procesu został usunięty po uruchomieniu. Zdarza się to zasadnie po aktualizacjach pakietów, dopóki usługa się nie zrestartuje. W przypadku procesów z katalogów tymczasowych lub pod użytkownikiem serwera WWW jest to typowe zachowanie maskujące.
Czy mogę polegać na wyniku ps?
Przy zwykłym włamaniu zazwyczaj tak. Jeśli jednak atakujący zdobył uprawnienia roota, może manipulować narzędziami i wynikami. Wtedy wiarygodniejsza jest kontrola z zewnątrz, na przykład na zabezpieczonym obrazie.
Czy powinienem zakończyć podejrzany proces poleceniem kill?
Nie w pierwszej kolejności. Najpierw proszę zabezpieczyć wiersz poleceń, plik programu, połączenia i czas startu. Zakończony proces niczego już nie zdradza, a często i tak uruchamia go ponownie zadanie cron lub usługa.