Pe scurt: Fișierele modificate le găsiți pe Linux cu find și un interval de timp, de exemplu de la 17 octombrie 2026, prima tentativă de atac observată asupra PHP2Shell conform rapoartelor din presă. Verificați nu doar ora modificării conținutului (mtime), ci și pe cea a metadatelor (ctime), deoarece prima poate fi falsificată ușor. Rezultatul devine de încredere abia prin compararea cu sumele de control ale pachetelor, Git sau un backup.
De ce marcajele de timp sunt un bun punct de plecare, dar nu o dovadă
Cine aduce cod pe un server modifică fișiere. Webshell-uri noi, fișiere de configurare adaptate, rânduri adăugate în scripturi existente: toate lasă marcaje de timp. Căutarea modificărilor în intervalul corect este de aceea una dintre cele mai rapide căi către primele constatări.
Pentru PHP2Shell, ca început al intervalului se potrivește 17 octombrie 2026, ziua primei tentative de atac observate conform rapoartelor din presă. Patchurile au apărut pe 21 octombrie. Cine și-a actualizat serverul abia după aceea caută până în ziua propriei actualizări și dincolo de ea. Cum recunoașteți webshell-urile printre constatări descrie Recunoașterea și eliminarea webshell-urilor. Aici este vorba despre metoda căutării însăși.
Cele trei marcaje de timp ale unui fișier
Linux stochează pentru fiecare fișier mai multe momente. Pentru căutarea modificărilor, două sunt decisive.
| Marcaj de timp | Semnificație | Falsificabil? |
|---|---|---|
| mtime | ultima modificare a conținutului | da, de ex. cu touch, de oricine are voie să scrie fișierul |
| ctime | ultima modificare a conținutului sau a metadatelor, precum drepturile | nu cu mijloace simple |
| atime | ultimul acces de citire | adesea dezactivat sau imprecis, puțin potrivit pentru căutare |
Atacatorii antedatează de bună voie mtime la data fișierelor vecine, pentru ca un fișier nou să nu iasă în evidență. ctime se schimbă însă odată cu aceasta. Un fișier cu mtime vechi și ctime proaspăt este de aceea un indiciu puternic de manipulare.
La comparație, acordați atenție fusurilor orare. find și ls arată ora locală a serverului, în timp ce multe fișiere de jurnal și servicii lucrează în UTC. Cine pune unul lângă altul constatări din sistemul de fișiere și din loguri ar trebui să convertească toate datele în același fus orar, altfel evenimentele nu par să se potrivească. Patchurile au apărut aproximativ pe 21 octombrie la 14:00 UTC, adică la ora 16:00, ora Germaniei.
Găsirea fișierelor modificate pe Linux cu find
Toate comenzile doar citesc. Adaptați calea și data.
# Conținut modificat din 17.10.2026, sortat, cu mtime, ctime și proprietar
find /var/www -type f -newermt "2026-10-17" -printf '%TY-%Tm-%Td %TH:%TM %CY-%Cm-%Cd %CH:%CM %u %p\n' | sort
# Metadate modificate din 17.10.2026 (găsește și fișierele antedatate)
find /var/www -type f -newerct "2026-10-17" -printf '%C+ %T+ %p\n' | sort
# Ascunderea zgomotului cunoscut: cache, loguri, sesiuni
find /var/www -type f -newerct "2026-10-17" \
-not -path "*/cache/*" -not -path "*/logs/*" -not -path "*/sessions/*" -printf '%C+ %p\n' | sort
# Uitați-vă și în afara directorului web
find /etc /usr/local/bin /tmp /var/tmp /dev/shm -xdev -type f -newerct "2026-10-17" -printf '%C+ %p\n' 2>/dev/null | sort
Comparați la fiecare potrivire ambele marcaje de timp. Dacă ctime este clar mai nou decât mtime și nimeni nu a schimbat în acest timp drepturi sau copiat fișiere, fișierul aparține listei. Fiți atenți și la proprietar: un fișier al utilizatorului serverului web între fișiere ale utilizatorului de deploy iese în evidență.
Nu uitați fișierele și directoarele ascunse. Numele care încep cu un punct nu sunt afișate de multe gestionare de fișiere și de un simplu ls. Atacatorii folosesc aceasta de bună voie, la fel ca numele care seamănă până la confuzie cu fișiere reale.
# Fișiere și foldere ascunse în directorul web, fără cele cunoscute precum .htaccess și .git
find /var/www -name ".*" -not -name ".htaccess" -not -name ".well-known" -not -path "*/.git/*" -printf '%C+ %u %p\n' | sort
Comparația cu o sursă de încredere
Marcajele de timp arată unde s-a mișcat ceva. Dacă a fost o modificare legitimă arată abia compararea cu o sursă în care aveți încredere.
- Gestionarul de pachete: Pentru fișierele de sistem,
dpkg --verify(Debian/Ubuntu) saurpm -Va(familia RHEL) verifică fișierele față de sumele de control ale pachetelor instalate. Fișierele de configurare diferă legitim, fișierele de program nu. - Git: Dacă aplicația se află într-un depozit,
git -C /var/www/projekt status --porcelainarată orice abatere de la ultimul commit. - Sumele de control ale CMS-ului: Multe sisteme își pot compara fișierele de bază cu sumele de control oficiale, vezi Compararea fișierelor de bază ale CMS-ului cu originalul.
- Backup dinaintea incidentului: O comparație în rulare de probă listează diferențele fără a copia nimic.
# Doar listarea diferențelor dintre nivelul backupului și sistemul live (rulare de probă, nu copiază nimic)
rsync -rcn --out-format="%n" /backup/www-2026-10-15/ /var/www/
Comparația cu backupul presupune că backupul a fost creat înainte de incident și nu a fost el însuși modificat. De ce sunt decisive aici copiile de siguranță păstrate separat explică Backupuri după regula 3-2-1.
Salvați rezultatele fiecărei căutări, cu data, într-un fișier din afara serverului. Din aceste liste rezultă ulterior cronologia incidentului și ele dovedesc ce ați verificat și când.
Dacă nu există nici backup, nici depozit
La multe site-uri mai mici nu există o bază curată de comparație: nici Git, nici backup dinaintea incidentului, pluginuri actualizate de ani de zile manual. Nu sunteți totuși complet fără puncte de sprijin.
Descărcați CMS-ul și extensiile de la producător exact în versiunile instalate și comparați aceste fișiere cu serverul. Ce diferă sau lipsește acolo merită o privire. Rămân adaptările dumneavoastră, upload-urile și configurația; acolo ajută căutarea după marcaje de timp, completată cu o privire asupra proprietarului și drepturilor. Fișierele care sunt singurele dintr-un director cu alt grup, alte drepturi sau un ctime clar mai nou decât vecinii lor aparțin listei.
Sincer vorbind: fără bază de comparație rămâne o nesiguranță reziduală. La sistemele cu date sensibile, o reconstruire din surse curate este atunci adesea mai de încredere decât căutarea fiecărui fișier modificat în parte. Pentru viitor, lecția este simplă: un depozit pentru cod și copii de siguranță regulate, păstrate separat.
Surse tipice de erori la căutare
- Excluderi prea largi: Directoarele de cache și de upload sunt ascunzători îndrăgite.
- Verificat doar mtime: Fișierele antedatate scapă.
- Deployment în interval: Un rollout obișnuit modifică sute de fișiere și acoperă constatările individuale. Comparați cu depozitul.
- Fișiere deja deschise sau copiate: Copiile fără păstrarea marcajelor de timp distrug urmele. Păstrați cu unelte care păstrează marcajele de timp.
- Căutat doar în directorul web: Atacatorii depun unelte și în
/tmp,/dev/shmsau în directorul home al utilizatorului serverului web. - Schimbări de drepturi trecute cu vederea: Un fișier ale cărui drepturi permit brusc scrierea tuturor este o constatare, chiar dacă conținutul lui este neschimbat.
Cum se asamblează constatările într-o desfășurare arată Întocmirea cronologiei unui incident.
Cum ajută PHP SOS concret?
- Căutare sistematică: Căutăm în directoarele web și în căile de sistem modificări în intervalul relevant și evaluăm împreună mtime și ctime.
- Verificare față de originale: Comparăm cu pachetele, depozitul, sumele de control ale CMS-ului și backupurile dumneavoastră.
- Evaluarea constatărilor: Separăm modificările obișnuite de manipulări și păstrăm probele.
- Curățare: Prin eliminarea malware-ului restabilim un nivel curat și îl documentăm.
Întrebări frecvente
Cum găsesc toate fișierele modificate de la o anumită dată?
Cu find și opțiunea -newermt, de exemplu find /var/www -type f -newermt "2026-10-17". Pentru modificările metadatelor folosiți -newerct. Ambele comenzi doar citesc și nu schimbă nimic.
Care este diferența dintre mtime și ctime?
mtime este momentul ultimei modificări a conținutului și poate fi antedatat cu mijloace simple. ctime este momentul ultimei modificări a conținutului sau a metadatelor și nu poate fi falsificat atât de ușor. Dacă cele două diferă puternic, merită o privire atentă.
Cum exclud fișierele de cache din căutare?
Cu -not -path pentru directoarele cunoscute de cache, loguri și sesiuni. Nu excludeți însă prea larg, deoarece atacatorii depun fișiere tocmai acolo unde multe modificări sunt normale.
Care verificare este cea mai de încredere?
Compararea cu o sursă de încredere: sumele de control ale gestionarului de pachete, un depozit Git sau un backup dinaintea incidentului. Marcajele de timp sunt un bun punct de plecare, dar nu o dovadă.