Pe scurt: Pentru a verifica fișierele de bază ale CMS-ului, comparați fișierele instalate cu un original curat al aceleiași versiuni: la WordPress prin sumele de control oficiale, la alte sisteme printr-o descărcare proaspătă sau printr-o reconstrucție din composer.lock. Fiecare abatere este o sarcină de verificare. Comparația găsește și cod malițios necunoscut, dar acoperă doar fișierele pentru care există un original.
De ce comparația găsește mai mult decât orice semnătură
Scannerele de malware caută tipare cunoscute. Ce nu cunosc, ratează. O comparație cu originalul lucrează invers: nu întreabă dacă un fișier pare suspect, ci dacă este exact ceea ce a livrat producătorul. Fiecare abatere iese în evidență, indiferent dacă urmează sau nu un tipar cunoscut.
După PHP2Shell, acest lucru este deosebit de valoros. Pentru vulnerabilitățile CVE-2026-109618 și CVE-2026-109619 nu există Indicators of Compromise publicați și confirmați. Scannerele nu pot deci căuta țintit urme PHP2Shell. O comparație cu originalul găsește, în schimb, orice modificare a nucleului, indiferent cum a apărut. De ce scannerele singure nu sunt suficiente explică articolul Scannere de malware pentru site-uri: ce găsesc și ce nu.
Principiul: aceeași versiune, sursă curată
O comparație valorează cât referința ei. Trebuie îndeplinite trei condiții:
- Exact aceeași versiune: O comparație cu o versiune mai nouă arată sute de diferențe inofensive. Aflați versiunea instalată din aplicație sau din
composer.lock. - Sursă oficială: Originalul provine de la producător, din directorul oficial de pachete sau din propriul sistem de control al versiunilor. Nu dintr-o copie de siguranță veche a serverului afectat.
- Comparație pe o copie: Lucrați pe o copie securizată a directorului web, pentru ca marcajele de timp și urmele să rămână păstrate.
| Sistem | Referință | Unealtă |
|---|---|---|
| Nucleul WordPress și pluginurile din director | sume de control de la WordPress.org | wp core verify-checksums, wp plugin verify-checksums |
| Proiecte Composer (de ex. Shopware 6, Laravel, Symfony, Drupal, TYPO3 în modul Composer) | reconstrucție din composer.lock |
composer install într-un director gol, apoi diff |
| CMS cu pachet de descărcare | pachet de aceeași versiune de la producător | diff -rq |
| Proiecte proprii cu Git | ultimul commit cunoscut | git status, git diff |
| Pachetele de sistem ale serverului | baza de date de pachete a distribuției | dpkg --verify, rpm -Va |
WordPress: mai mult decât verify-checksums
Cum verificați nucleul și pluginurile cu WP-CLI este descris în ghidul Găsirea backdoor-urilor în WordPress. Merită o completare: potrivit documentației WP-CLI, opțiunea --include-root verifică toate fișierele și dosarele din directorul principal și avertizează asupra intrărilor care nu aparțin WordPress. Acolo depun atacatorii bucuros fișiere ale căror nume amintesc de fișierele de bază.
# Nucleul față de sumele de control oficiale, inclusiv fișierele străine din directorul principal
wp core verify-checksums --include-root
Pluginurile și temele comerciale nu sunt acoperite de această cale. Pentru ele descărcați de la furnizor pachetul original al aceleiași versiuni și comparați cu diff.
Verificarea fișierelor de bază CMS la proiectele Composer
Multe aplicații PHP moderne constau în cea mai mare parte din pachete pe care le instalează Composer, managerul de pachete pentru PHP. Cum funcționează explică pagina Composer: managerul de pachete pentru PHP. Fișierul composer.lock consemnează exact ce versiuni sunt instalate. Potrivit documentației Composer, composer install folosește aceste versiuni exacte. Astfel se poate reconstrui starea de livrare:
# Pe un sistem curat, nu pe serverul afectat
mkdir /tmp/referenz && cd /tmp/referenz
cp /pfad/zur/kopie/composer.json /pfad/zur/kopie/composer.lock .
composer install --no-scripts --no-plugins --no-autoloader
# Enumerarea diferențelor din dosarul vendor
diff -rq /tmp/referenz/vendor /pfad/zur/kopie/vendor
Opțiunile --no-scripts și --no-plugins împiedică executarea scripturilor din pachete la reconstrucție. Dacă producția a fost instalată cu --no-dev, folosiți această opțiune și la reconstrucție, altfel pachetele de dezvoltare apar ca diferență. Atenție la două tipuri de rezultate: fișiere care diferă și fișiere care există doar pe server. Al doilea grup este adesea mai interesant. Cum verificați suplimentar pachetele instalate pentru vulnerabilități cunoscute descrie ghidul Verificarea dependențelor Composer pentru vulnerabilități.
Comparați și sistemul de operare
Dacă un atacator a avut drepturi de root, el poate fi înlocuit și programe de sistem. Managerele de pachete aduc propria comparație:
# Debian, Ubuntu: fișiere al căror conținut diferă de pachet
sudo dpkg --verify
# RHEL, AlmaLinux, Rocky: verificarea tuturor pachetelor
sudo rpm -Va
Un 5 pe a treia poziție a ieșirii înseamnă că s-a modificat conținutul unui fișier. Potrivit manualului dpkg, comparația conținutului este acolo în prezent singura verificare eficientă. Fișierele de configurare modificate sunt normale și marcate cu c. Un program modificat în /usr/bin este, în schimb, un semnal grav de alarmă. Rețineți: un atacator cu drepturi de root poate manipula și baza de date de pachete. Dacă bănuiți acces root, o reconstruire este mai fiabilă decât orice comparație.
Un sistem de control al versiunilor pentru codul aplicației face comparațiile viitoare o chestiune de secunde. git status arată atunci fiecare abatere de la starea aprobată.
Evaluarea abaterilor și cunoașterea limitelor
Nu orice abatere este un atac. Unele agenții au adaptat în trecut direct fișierele de bază, în loc să folosească extensii. Pachetele de limbă, sfârșiturile de rând după un transfer prin FTP sau corecturile aplicate ulterior produc și ele diferențe. Decisiv este dacă cineva poate explica modificarea.
Parcurgeți fiecare abatere în parte și notați rezultatul: cunoscută și documentată, explicabilă inofensiv sau neclară. Fișierele neclare le deschideți doar ca text, pe o copie, și le înlocuiți dintr-o sursă curată. La fișierele care există doar pe server, întrebarea este mai simplă: cine nu le cunoaște ar trebui să le salveze și să le elimine, după ce conținutul lor a fost verificat.
Încărcările, fișierele de configurare precum wp-config.php sau .env, adaptările proprii și cache-urile nu au original. Ele trebuie verificate țintit, la fel ca baza de date, cronjoburile, conturile de utilizator și cheile SSH. O comparație curată este de aceea un element important, dar nu o achitare pentru întregul server.
Cum ajută PHP SOS concret?
- Stabilim versiunile instalate și construim o referință curată din surse oficiale.
- Comparăm nucleul, extensiile, pachetele Composer și programele de sistem și evaluăm fiecare abatere.
- Verificăm țintit zonele fără original și înlocuim fișierele modificate dintr-o sursă curată, în cadrul eliminării malware-ului.
- La dorință, configurăm o stare de versiune față de care se desfășoară verificările viitoare.
Întrebări frecvente
Cum verific dacă fișierele de bază ale WordPress au fost modificate?
Cu WP-CLI și comanda wp core verify-checksums. Ea compară fișierele cu sumele de control pe care WordPress.org le publică pentru versiunea instalată. Cu opțiunea --include-root, WP-CLI avertizează suplimentar asupra fișierelor din directorul principal care nu aparțin WordPress.
Ce fac la un CMS fără funcție de verificare integrată?
Descărcați exact aceeași versiune din sursa oficială a producătorului și comparați ambele directoare cu diff. La proiectele Composer reconstruiți starea din composer.lock într-un director gol și comparați dosarul vendor.
Găsește comparația și cod malițios din pluginuri și teme?
Doar dacă există pentru acestea un original curat, de exemplu din directorul oficial sau de la furnizor. Adaptările proprii, încărcările și fișierele de configurare nu au original și trebuie verificate separat.
Înlocuiește comparația un scanner de malware?
O completează. Comparația găsește orice modificare a fișierelor cunoscute, inclusiv cod malițios necunoscut. Dar nu spune nimic despre fișierele fără original, despre baza de date, cronjoburi sau accesuri.