# Găsirea proceselor suspecte pe serverele Linux

> Găsiți procese suspecte pe Linux: recunoașteți fișiere de program șterse, nume de camuflaj și locuri de pornire, atribuiți pachetul și păstrați urmele.

Sursa: https://phpsos.de/ro/blog/verdaechtige-prozesse-linux/  
Stadiu: 25.10.2026  
Furnizor: PHP SOS, Asistență de urgență PHP și securitatea serverelor. Ajutor imediat pe WhatsApp: https://wa.me/491736494914?text=Bun%C4%83%20ziua%2C%20PHP%20SOS%2C%20avem%20nevoie%20de%20ajutor%20cu%20serverul%20nostru%20PHP.%20Firma%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**Pe scurt:** Procesele suspecte pe serverele Linux le recunoașteți după câteva trăsături: fișierul de program șters sau aflat în `/tmp`, `/dev/shm` ori într-un director web, numele imită un proces de sistem, utilizator neobișnuit, conexiuni de rețea permanente sau încărcare mare fără motiv. Verificați cu comenzi de citire dacă fișierul de program aparține unui pachet instalat și păstrați constatările înainte de a încheia ceva.

## Ce înseamnă „suspect” la un proces

Pe un server web rulează sute de procese. Majoritatea aparțin sistemului de operare, serverului web, bazei de date sau PHP. Un atacator care a putut executa cod printr-o vulnerabilitate precum PHP2Shell încearcă să nu iasă în evidență între ele. Alege nume discrete și depune programele acolo unde utilizatorul serverului web are voie să scrie.

Pentru verificare ajută să cunoașteți starea normală. Cine știe ce servicii trebuie să ruleze pe un server, sub ce utilizatori și cu ce încărcare recunoaște abaterile mult mai repede. Dacă lipsește această cunoaștere, merită să folosiți pentru comparație lista de procese a unui server similar, nesuspect.

O singură trăsătură nu este încă o dovadă. Decisiv este ansamblul. Un proces cu numele unui thread de kernel, care rulează sub `www-data`, a fost pornit din `/dev/shm` și ține o conexiune în străinătate, este un caz clar. Cum verificați cazul special al unui shell sub serverul web descrie [Semnal de alarmă: serverul web pornește un shell](https://phpsos.de/ro/blog/webserver-startet-shell/).

## Prima privire de ansamblu în cinci comenzi

Toate comenzile doar citesc. Rulați-le ca root, pentru a vedea toate procesele, și salvați rezultatele într-un fișier din afara directorului web.

```bash
# 1. Toate procesele cu utilizator, PID părinte, ora de pornire, CPU și linia de comandă
ps -eo user,pid,ppid,lstart,%cpu,%mem,cmd --sort=-%cpu | head -40

# 2. Procesele al căror fișier de program a fost șters
ls -l /proc/[0-9]*/exe 2>/dev/null | grep "(deleted)"

# 3. Procesele care rulează din directoare temporare sau web
ls -l /proc/[0-9]*/exe 2>/dev/null | grep -E " -> (/tmp|/var/tmp|/dev/shm|/var/www)"

# 4. Procesele cu conexiuni de rețea
ss -tunap

# 5. Procesele utilizatorilor serverului web, pe scurt
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) "
```

Numele utilizatorilor diferă în funcție de distribuție și panou; Plesk și alte panouri rulează adesea PHP sub utilizatorul clientului respectiv. Adaptați lista la mediul dumneavoastră.

Citiți rezultatele cu privirea la ora de pornire. Procesele care rulează de la ultima repornire a serverului aparțin de regulă sistemului. Procesele pornite în plină noapte sau în zilele de după 17 octombrie și care nu se potrivesc cu niciun serviciu merită atenție. Comparați și numărul proceselor PHP cu ceea ce permite configurația pool-ului dumneavoastră; un număr clar mai mare de procese sub un utilizator al serverului web este un indiciu.

## Procese suspecte pe Linux: trăsături tipice

| Trăsătură | De ce iese în evidență | Posibilă explicație inofensivă? |
|---|---|---|
| Fișierul de program „(deleted)” | Atacatorii șterg fișierele după pornire | da, după actualizări de pachete până la repornire |
| Loc de pornire `/tmp`, `/dev/shm`, director de upload | acolo poate scrie oricine sau serverul web | rar |
| Nume între paranteze pătrate precum `[kworker]` | imită thread-urile de kernel | nu, dacă în spate se află un fișier de program |
| Încărcare CPU mare permanent, fără motiv | tipic pentru criptominere | da, la job-uri batch sau indexare |
| Proces părinte 1 și utilizatorul serverului web | desprins de serverul web, rulează independent | rar |
| Conexiune către o țintă necunoscută | comandă sau scurgere de date | da, la actualizări și API-uri |

Thread-urile de kernel autentice nu au fișier de program; `ls -l /proc/PID/exe` nu returnează la ele nicio cale. Dacă un proces cu nume de kernel trimite spre un fișier, este camuflat. La încărcare mare fără motiv vizibil ajută articolul [Criptominere pe serverul web](https://phpsos.de/ro/blog/kryptominer-auf-dem-server/).

## Contraproba: aparține fișierul de program unui pachet?

Aproape toate programele legitime de pe un server provin din gestionarul de pachete. Un fișier de program care nu aparține niciunui pachet nu este automat malițios, dar merită o privire atentă.

```bash
PID=12345
EXE=$(readlink /proc/$PID/exe); echo "$EXE"
dpkg -S "$EXE"        # Debian/Ubuntu: cărui pachet aparține fișierul?
rpm -qf "$EXE"        # familia RHEL
sha256sum /proc/$PID/exe   # suma de control, funcționează și la fișier șters
tr '\0' ' ' < /proc/$PID/environ | head -c 600; echo   # variabile de mediu
```

Dacă fișierul de program este șters, `sha256sum /proc/$PID/exe` îl citește totuși din procesul în execuție. Această sumă de control aparține documentației. O copie a fișierului ar trebui să facă doar cineva care știe cum se păstrează în siguranță.

## Limitele verificării pe sistemul în execuție

Toate comenzile de mai sus se încred în sistemul pe care îl verificați chiar acum. La o intruziune obișnuită prin site, cu drepturile utilizatorului serverului web, aceasta este acceptabil. Dacă atacatorul a obținut drepturi de root, poate ascunde procese și falsifica rezultatele. Atunci serverul arată doar ce permite atacatorul.

Indicii în acest sens sunt contradicțiile: încărcare fără proces vizibil, conexiuni pe care firewall-ul le vede, dar `ss` nu, sau programe de sistem modificate. În astfel de cazuri verificarea se mută pe o imagine securizată. La sistemele în execuție se adaugă adesea o copie a memoriei de lucru, deoarece unele programe malițioase există doar acolo și lasă pe disc puține urme. Această copie trebuie făcută înainte de o repornire și cere unelte potrivite și experiență. De ce ar trebui să o creați înainte de o reinstalare explică [Păstrați probele înainte de reinstalare](https://phpsos.de/ro/blog/beweise-sichern-vor-neuinstallation/).

> **Important:**
> Nu încheiați procesele suspecte ca prim pas. Adesea un cronjob sau un serviciu le repornește, iar odată cu procesul dispar din memorie linia de comandă, conexiunile și fișierul de program șters.

## Verificarea autostarturilor și pașii următori

Un proces malițios care ar dispărea după o repornire ar fi lipsit de valoare pentru atacatori. De aceea, la orice proces găsit aparține întrebarea ce îl pornește. Pe lângă cronjob-uri vin în discuție mai ales serviciile systemd, pe care un atacator cu drepturi de root le poate crea. Iese în evidență serviciile cu nume generice al căror fișier de program se află într-un director neobișnuit și fișierele unit create după 17 octombrie.

```bash
# Servicii care rulează și fișiere unit modificate recent
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

# Se injectează o bibliotecă în fiecare proces? Fișierul nu există în mod normal.
ls -l /etc/ld.so.preload 2>/dev/null && cat /etc/ld.so.preload
```

O intrare în `/etc/ld.so.preload` este rară pe serverele web normale și un indiciu puternic de manipulare cu drepturi de root. Cum verificați complet sarcinile programate descrie [Recunoașterea cronjob-urilor ascunse ca ușă din spate](https://phpsos.de/ro/blog/cronjobs-als-hintertuer/).

După aceea urmează pașii următori, în această ordine:

1. Păstrați rezultatele și sumele de control cu ora.
2. Căutați persistența: cronjob-uri, servicii și timere systemd, chei SSH.
3. Clarificați proveniența: loguri din 20 octombrie, fișiere noi în directorul web.
4. Izolați serverul și planificați curățarea sau reconstruirea.

O privire de ansamblu asupra tuturor semnelor tipice după PHP2Shell oferă [Sunt deja compromis?](https://phpsos.de/ro/php2shell/bin-ich-gehackt-anzeichen/).

## Cum ajută PHP SOS concret?

- **Evaluarea proceselor:** Verificăm lista de procese, fișierele de program și conexiunile și încadrăm fiecare constatare.
- **Păstrarea cu valoare probatorie:** Prin [criminalistica IT](https://phpsos.de/ro/leistungen/it-forensik/) păstrăm memoria de lucru și suporturile de date înainte de a modifica ceva.
- **Găsirea persistenței:** Căutăm mecanismele care repornesc procesele malițioase.
- **Încheierea:** Curățăm sau reconstruim și documentăm incidentul până la încheiere.


## Întrebări frecvente

**Cum recunosc un proces suspect pe Linux?**  
Trăsături tipice sunt un fișier de program șters, un loc de pornire în /tmp sau /dev/shm, un nume care imită un proces de sistem, un utilizator neobișnuit și conexiuni de rețea permanente. Trăsăturile individuale sunt indicii, mai multe la un loc o suspiciune serioasă.

**Ce înseamnă „(deleted)” la /proc/PID/exe?**  
Fișierul de program al procesului a fost șters după pornire. Aceasta se întâmplă legitim după actualizări de pachete, până când serviciul repornește. La procesele din directoare temporare sau sub utilizatorul serverului web este un comportament tipic de camuflaj.

**Mă pot baza pe rezultatul ps?**  
La o intruziune obișnuită, de regulă da. Dacă atacatorul a obținut însă drepturi de root, poate manipula instrumentele și rezultatele. Atunci o verificare din exterior, de exemplu pe o imagine securizată, este mai de încredere.

**Ar trebui să închei un proces suspect cu kill?**  
Nu ca prim pas. Păstrați mai întâi linia de comandă, fișierul de program, conexiunile și ora de pornire. Un proces încheiat nu mai trădează nimic, iar adesea un cronjob sau un serviciu îl repornește oricum.

## Surse

- [BSI IT-Grundschutz (protecția de bază IT, Germania)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI: Oficiul Federal German pentru Securitatea Informației](https://www.bsi.bund.de/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)