# Įtartinų procesų radimas Linux serveriuose

> Įtartinų procesų radimas Linux: ištrinti programų failai, maskuojantys pavadinimai ir paleidimo vietos, priskyrimas paketui ir pėdsakų išsaugojimas.

Šaltinis: https://phpsos.de/lt/blog/verdaechtige-prozesse-linux/  
Būsena: 2026-10-25  
Teikėjas: PHP SOS, PHP avarinė pagalba ir serverio sauga. Skubi pagalba per „WhatsApp“: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20reikia%20pagalbos%20su%20m%C5%ABs%C5%B3%20PHP%20serveriu.%20%C4%AEmon%C4%97%3A%20%E2%80%A6%20Svetain%C4%97%3A%20%E2%80%A6

**Trumpai:** įtartinus procesus Linux serveriuose atpažinsite pagal keletą požymių: programos failas ištrintas arba yra `/tmp`, `/dev/shm` ar žiniatinklio kataloge, pavadinimas imituoja sistemos procesą, neįprastas naudotojas, nuolatiniai tinklo ryšiai ar didelė apkrova be priežasties. Tik skaitančiomis komandomis patikrinkite, ar programos failas priklauso įdiegtam paketui, ir radinius išsaugokite, prieš ką nors nutraukdami.

## Ką procesui reiškia „įtartinas“

Žiniatinklio serveryje veikia šimtai procesų. Dauguma priklauso operacinei sistemai, žiniatinklio serveriui, duomenų bazei ar PHP. Užpuolikas, kuris per pažeidžiamumą, tokį kaip PHP2Shell, galėjo vykdyti kodą, stengiasi tarp jų nekristi į akis. Jis renkasi nepastebimus pavadinimus ir programas deda ten, kur žiniatinklio serverio naudotojas gali rašyti.

Patikrai padeda žinoti normalią būseną. Kas žino, kokios tarnybos serveryje turi veikti, su kokiais naudotojais ir kokia apkrova, nukrypimus pastebi daug greičiau. Jei tokių žinių trūksta, verta palyginimui panaudoti panašaus, neįtarto serverio procesų sąrašą.

Vienas požymis dar nėra įrodymas. Lemia derinys. Procesas su branduolio gijos pavadinimu, veikiantis po `www-data`, paleistas iš `/dev/shm` ir laikantis ryšį į užsienį, yra aiškus atvejis. Kaip patikrinti ypatingą apvalkalo po žiniatinklio serveriu atvejį, aprašo [Įspėjamasis ženklas: žiniatinklio serveris paleidžia apvalkalą (shell)](https://phpsos.de/lt/blog/webserver-startet-shell/).

## Pirma apžvalga penkiomis komandomis

Visos komandos tik skaito. Vykdykite jas kaip root, kad matytumėte visus procesus, o išvestis išsaugokite faile už žiniatinklio katalogo ribų.

```bash
# 1. Visi procesai su naudotoju, tėvinio proceso PID, paleidimo laiku, CPU ir komandine eilute
ps -eo user,pid,ppid,lstart,%cpu,%mem,cmd --sort=-%cpu | head -40

# 2. Procesai, kurių programos failas ištrintas
ls -l /proc/[0-9]*/exe 2>/dev/null | grep "(deleted)"

# 3. Procesai, veikiantys iš laikinųjų ar žiniatinklio katalogų
ls -l /proc/[0-9]*/exe 2>/dev/null | grep -E " -> (/tmp|/var/tmp|/dev/shm|/var/www)"

# 4. Procesai su tinklo ryšiais
ss -tunap

# 5. Žiniatinklio serverio naudotojų procesų apžvalga
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) "
```

Naudotojų vardai skiriasi pagal distribuciją ir skydelį; Plesk ir kiti skydeliai PHP dažnai vykdo pagal atitinkamo kliento naudotoją. Sąrašą pritaikykite savo aplinkai.

Išvestis skaitykite žiūrėdami į paleidimo laiką. Procesai, veikiantys nuo paskutinio serverio paleidimo iš naujo, dažniausiai priklauso sistemai. Dėmesio verti procesai, paleisti vidury nakties ar dienomis po spalio 17 d. ir netinkantys jokiai tarnybai. Palyginkite ir PHP procesų skaičių su tuo, ką leidžia jūsų baseino konfigūracija; gerokai daugiau procesų po žiniatinklio serverio naudotoju yra užuomina.

## Įtartini procesai Linux sistemoje: tipiniai požymiai

| Požymis | Kodėl krinta į akis | Ar įmanomas nekenksmingas paaiškinimas? |
|---|---|---|
| Programos failas „(deleted)“ | užpuolikai failus ištrina po paleidimo | taip, po paketų atnaujinimų iki paleidimo iš naujo |
| Paleidimo vieta `/tmp`, `/dev/shm`, įkėlimų aplankas | ten gali rašyti visi arba žiniatinklio serveris | retai |
| Pavadinimas laužtiniuose skliaustuose, pvz., `[kworker]` | imituoja branduolio gijas | ne, jei už jo yra programos failas |
| Nuolat didelė CPU apkrova be priežasties | tipiška kriptokasėjams | taip, esant paketiniams darbams ar indeksavimui |
| Tėvinis procesas 1 ir žiniatinklio serverio naudotojas | atsiskyręs nuo žiniatinklio serverio, veikia savarankiškai | retai |
| Ryšys su nežinomu tikslu | valdymas ar duomenų nutekėjimas | taip, atnaujinimų ir API atveju |

Tikros branduolio gijos neturi programos failo; `ls -l /proc/PID/exe` joms kelio nerodo. Jei procesas su branduolio pavadinimu rodo į failą, jis užsimaskavęs. Esant didelei apkrovai be aiškios priežasties padeda straipsnis [Kriptokasėjas žiniatinklio serveryje](https://phpsos.de/lt/blog/kryptominer-auf-dem-server/).

## Kontrolinė patikra: ar programos failas priklauso paketui?

Beveik visos teisėtos serverio programos kyla iš paketų valdymo. Programos failas, nepriklausantis jokiam paketui, nėra automatiškai kenkėjiškas, bet vertas atidaus žvilgsnio.

```bash
PID=12345
EXE=$(readlink /proc/$PID/exe); echo "$EXE"
dpkg -S "$EXE"        # Debian/Ubuntu: kuriam paketui priklauso failas?
rpm -qf "$EXE"        # RHEL šeima
sha256sum /proc/$PID/exe   # kontrolinė suma, veikia ir su ištrintu failu
tr '\0' ' ' < /proc/$PID/environ | head -c 600; echo   # aplinkos kintamieji
```

Jei programos failas ištrintas, `sha256sum /proc/$PID/exe` jį vis tiek nuskaito iš veikiančio proceso. Ši kontrolinė suma turi patekti į dokumentaciją. Failo kopiją turėtų kurti tik tas, kas žino, kaip ją saugiai saugoti.

## Patikros veikiančioje sistemoje ribos

Visos pirmiau pateiktos komandos pasitiki sistema, kurią dabar tikrinate. Esant įprastam įsilaužimui per svetainę su žiniatinklio serverio naudotojo teisėmis tai pateisinama. Jei užpuolikas įgijo root teises, jis gali slėpti procesus ir klastoti išvestis. Tuomet serveris rodo tik tai, ką leidžia užpuolikas.

Į tai nurodo prieštaravimai: apkrova be matomo proceso, ryšiai, kuriuos mato ugniasienė, bet `ss` ne, ar pakeistos sistemos programos. Tokiais atvejais patikrą reikia atlikti saugiame atvaizde. Veikiančių sistemų atveju dažnai prisideda ir operatyviosios atminties išsaugojimas, nes kai kurios kenkėjiškos programos egzistuoja tik joje ir kietajame diske palieka mažai pėdsakų. Šis išsaugojimas turi būti atliktas prieš paleidimą iš naujo ir reikalauja tinkamų įrankių bei patirties. Kodėl tai reikėtų padaryti prieš diegiant iš naujo, paaiškina [Įrodymų išsaugojimas prieš diegiant iš naujo](https://phpsos.de/lt/blog/beweise-sichern-vor-neuinstallation/).

> **Svarbu:**
> Įtartinų procesų nenutraukite kaip pirmo žingsnio. Dažnai juos iš naujo paleidžia cron užduotis ar tarnyba, o kartu su procesu iš atminties dingsta komandinė eilutė, ryšiai ir ištrintas programos failas.

## Automatinio paleidimo patikra ir kiti žingsniai

Kenkėjiškas procesas, kuris po paleidimo iš naujo išnyktų, užpuolikams būtų beverčiai. Todėl prie kiekvieno proceso radinio priklauso klausimas, kas jį paleidžia. Be cron užduočių, daugiausia galimi systemd tarnybos, kurias užpuolikas su root teisėmis gali sukurti. Krinta į akis tarnybos su bendriniais pavadinimais, kurių programos failas yra neįprastame kataloge, ir unit failai, atsiradę po spalio 17 d.

```bash
# Veikiančios tarnybos ir neseniai pakeisti unit failai
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

# Ar biblioteka įterpiama į kiekvieną procesą? Šio failo paprastai nėra.
ls -l /etc/ld.so.preload 2>/dev/null && cat /etc/ld.so.preload
```

Įrašas `/etc/ld.so.preload` įprastuose žiniatinklio serveriuose pasitaiko retai ir yra stiprus manipuliavimo su root teisėmis požymis. Kaip visiškai patikrinti suplanuotas užduotis, aprašo [Paslėptų cron užduočių kaip užpakalinių durų atpažinimas](https://phpsos.de/lt/blog/cronjobs-als-hintertuer/).

Toliau seka kiti žingsniai tokia tvarka:

1. Išvestis ir kontrolines sumas išsaugoti su laiku.
2. Ieškoti išliekamumo: cron užduočių, systemd tarnybų ir laikmačių, SSH raktų.
3. Išsiaiškinti kilmę: žurnalai nuo spalio 20 d., nauji failai žiniatinklio kataloge.
4. Izoliuoti serverį ir planuoti išvalymą ar perkūrimą.

Visų tipinių požymių po PHP2Shell apžvalgą pateikia [Ar jau esu pažeistas?](https://phpsos.de/lt/php2shell/bin-ich-gehackt-anzeichen/).

## Kaip PHP SOS padeda konkrečiai?

- **Įvertinti procesus:** tikriname procesų sąrašą, programų failus ir ryšius bei kiekvieną radinį klasifikuojame.
- **Išsaugoti teisme priimtinai:** su [IT forensika](https://phpsos.de/lt/leistungen/it-forensik/) išsaugome operatyviąją atmintį ir duomenų laikmenas, prieš ką nors keičiant.
- **Rasti išliekamumą:** ieškome mechanizmų, kurie kenkėjiškus procesus paleidžia iš naujo.
- **Užbaigti:** išvalome arba perkuriame ir dokumentuojame incidentą iki pabaigos.


## Dažni klausimai

**Kaip atpažinti įtartiną procesą Linux sistemoje?**  
Tipiniai požymiai: ištrintas programos failas, paleidimo vieta /tmp ar /dev/shm, pavadinimas, imituojantis sistemos procesą, neįprastas naudotojas ir nuolatiniai tinklo ryšiai. Pavieniai požymiai yra užuominos, keli kartu rimtas įtarimas.

**Ką reiškia „(deleted)“ prie /proc/PID/exe?**  
Proceso programos failas buvo ištrintas po paleidimo. Tai teisėtai nutinka po paketų atnaujinimų, kol tarnyba paleidžiama iš naujo. Procesams iš laikinųjų aplankų ar po žiniatinklio serverio naudotoju tai tipiškas maskavimosi elgesys.

**Ar galiu pasitikėti ps išvestimi?**  
Esant įprastam įsilaužimui dažniausiai taip. Tačiau jei užpuolikas įgijo root teises, jis gali manipuliuoti įrankiais ir išvestimis. Tuomet patikimesnė yra patikra iš išorės, pavyzdžiui, saugiame atvaizde.

**Ar įtartiną procesą turėčiau nutraukti su kill?**  
Ne pirmiausia. Pirmiausia išsaugokite komandinę eilutę, programos failą, ryšius ir paleidimo laiką. Nutrauktas procesas nieko nebeišduoda, o dažnai jį vis tiek paleidžia iš naujo cron užduotis ar tarnyba.

## Šaltiniai

- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI: Vokietijos Federalinė informacijos saugumo tarnyba](https://www.bsi.bund.de/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)