Trumpai: norėdami patikrinti CMS branduolio failus, palyginkite įdiegtus failus su švariu tos pačios versijos originalu: WordPress atveju per oficialias kontrolines sumas, kitose sistemose per šviežią atsisiuntimą ar atkūrimą iš composer.lock. Kiekvienas nukrypimas yra patikros užduotis. Palyginimas randa ir nežinomą kenkėjišką kodą, bet apima tik failus, kuriems yra originalas.
Kodėl palyginimas randa daugiau nei bet koks parašas
Kenkėjiškų programų skenerai ieško žinomų šablonų. Ko jie nepažįsta, praleidžia. Palyginimas su originalu veikia atvirkščiai: jis neklausia, ar failas atrodo įtartinai, o ar jis tiksliai atitinka tai, ką pristatė gamintojas. Kiekvienas nukrypimas išryškėja, nesvarbu, ar jis atitinka žinomą šabloną, ar ne.
Po PHP2Shell tai ypač vertinga. Pažeidžiamumams CVE-2026-109618 ir CVE-2026-109619 nėra paskelbtų, patvirtintų kompromitavimo indikatorių (Indicators of Compromise). Todėl skeneriai negali tikslingai ieškoti PHP2Shell pėdsakų. O palyginimas su originalu randa kiekvieną branduolio pakeitimą, nesvarbu, kaip jis atsirado. Kodėl vien skenerių nepakanka, paaiškina straipsnis Kenkėjiškų programų skeneriai svetainėms: ką jie randa ir ko ne.
Principas: ta pati versija, švarus šaltinis
Palyginimas yra tiek geras, kiek geras jo etalonas. Reikia įvykdyti tris sąlygas:
- Tiksliai ta pati versija: palyginimas su naujesne versija parodo šimtus nekenksmingų skirtumų. Įdiegtą versiją nustatykite iš programos arba iš
composer.lock. - Oficialus šaltinis: originalas ateina iš gamintojo, iš oficialaus paketų katalogo arba iš jūsų pačių versijų kontrolės sistemos. Ne iš senos paveikto serverio atsarginės kopijos.
- Palyginimas su kopija: dirbkite su išsaugota žiniatinklio katalogo kopija, kad išliktų laiko žymos ir pėdsakai.
| Sistema | Etalonas | Įrankis |
|---|---|---|
| WordPress branduolys ir papildiniai iš katalogo | WordPress.org kontrolinės sumos | wp core verify-checksums, wp plugin verify-checksums |
| Composer projektai (pvz., Shopware 6, Laravel, Symfony, Drupal, TYPO3 Composer režimu) | atkūrimas iš composer.lock |
composer install tuščiame kataloge, tada diff |
| CMS su atsisiunčiamu paketu | tos pačios versijos paketas iš gamintojo | diff -rq |
| Savi projektai su Git | paskutinis žinomas commit | git status, git diff |
| Serverio sistemos paketai | distribucijos paketų duomenų bazė | dpkg --verify, rpm -Va |
WordPress: daugiau nei verify-checksums
Kaip patikrinti branduolį ir papildinius su WP-CLI, aprašyta gide Užpakalinių durų paieška WordPress. Verta pridėti vieną papildymą: pasak WP-CLI dokumentacijos, parinktis --include-root patikrina visus failus ir aplankus pagrindiniame kataloge ir perspėja apie įrašus, kurie nepriklauso WordPress. Ten užpuolikai mėgsta padėti failus, kurių pavadinimai primena branduolio failus.
# Branduolys pagal oficialias kontrolines sumas, įskaitant svetimus failus pagrindiniame kataloge
wp core verify-checksums --include-root
Komercinių papildinių ir temų šis kelias neapima. Jiems atsisiųskite tos pačios versijos originalų paketą iš teikėjo ir palyginkite su diff.
CMS branduolio failų patikra Composer projektuose
Daug šiuolaikinių PHP programų daugiausia sudarytos iš paketų, kuriuos diegia Composer, PHP paketų valdymo įrankis. Kaip jis veikia, paaiškina puslapis Composer: PHP paketų valdymas. Failas composer.lock fiksuoja, kurios versijos tiksliai įdiegtos. Pasak Composer dokumentacijos, composer install naudoja būtent šias versijas. Taip galima atkurti pristatymo būseną:
# Švarioje sistemoje, ne paveiktame serveryje
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
# Išvardyti skirtumus vendor aplanke
diff -rq /tmp/referenz/vendor /pfad/zur/kopie/vendor
Parinktys --no-scripts ir --no-plugins neleidžia atkuriant vykdyti paketų skriptų. Jei produkcija buvo įdiegta su --no-dev, šią parinktį naudokite ir atkurdami, kitaip kūrimo paketai atsiras kaip skirtumas. Atkreipkite dėmesį į dvi rezultatų rūšis: failus, kurie skiriasi, ir failus, kurie yra tik serveryje. Antroji grupė dažnai įdomesnė. Kaip papildomai patikrinti įdiegtus paketus dėl žinomų spragų, aprašo gidas Composer priklausomybių patikra dėl spragų.
Palyginkite ir operacinę sistemą
Jei užpuolikas turėjo root teises, jis galėjo pakeisti ir sistemos programas. Paketų valdymo įrankiai turi savo palyginimą:
# Debian, Ubuntu: failai, kurių turinys skiriasi nuo paketo
sudo dpkg --verify
# RHEL, AlmaLinux, Rocky: patikrinti visus paketus
sudo rpm -Va
5 trečioje išvesties pozicijoje reiškia, kad failo turinys pasikeitė. Pasak dpkg vadovo, turinio palyginimas ten šiuo metu yra vienintelė veiksminga patikra. Pakeisti konfigūracijos failai yra normalūs ir pažymėti c. O pakeista programa /usr/bin yra rimtas pavojaus ženklas. Atkreipkite dėmesį: užpuolikas su root teisėmis gali manipuliuoti ir paketų duomenų baze. Įtarus root prieigą, naujas įdiegimas patikimesnis nei bet koks palyginimas.
Programos kodo versijų kontrolės sistema ateityje palyginimus paverčia sekundžių reikalu. git status tada parodo kiekvieną nukrypimą nuo patvirtintos būsenos.
Nukrypimų vertinimas ir ribų pažinimas
Ne kiekvienas nukrypimas yra ataka. Kai kurios agentūros anksčiau branduolio failus keitė tiesiogiai, užuot naudojusios plėtinius. Kalbos paketai, eilučių pabaigos po perdavimo per FTP ar vėliau įdiegtos pataisos taip pat sukelia skirtumus. Lemia tai, ar kas nors gali paaiškinti pakeitimą.
Peržiūrėkite kiekvieną nukrypimą atskirai ir užrašykite rezultatą: žinomas ir dokumentuotas, nekenksmingai paaiškinamas arba neaiškus. Neaiškius failus atidarykite tik kaip tekstą kopijoje ir pakeiskite iš švaraus šaltinio. Su failais, esančiais tik serveryje, klausimas paprastesnis: kas jų nepažįsta, turėtų juos išsaugoti ir leisti pašalinti, kai jų turinys patikrintas.
Įkėlimai, konfigūracijos failai, pavyzdžiui, wp-config.php ar .env, savi pritaikymai ir talpyklos originalo neturi. Juos reikia tikrinti tikslingai, kaip ir duomenų bazę, cron užduotis, naudotojų paskyras ir SSH raktus. Todėl švarus palyginimas yra svarbi dalis, bet ne išteisinimas visam serveriui.
Kaip PHP SOS padeda konkrečiai?
- Nustatome įdiegtas versijas ir iš oficialių šaltinių sukuriame švarų etaloną.
- Lyginame branduolį, plėtinius, Composer paketus ir sistemos programas ir įvertiname kiekvieną nukrypimą.
- Sritis be originalo tikriname tikslingai, o pakeistus failus pakeičiame iš švaraus šaltinio vykdydami kenkėjiškų programų šalinimą.
- Pageidaujant įrengiame versijos būseną, su kuria vyks būsimos patikros.
Dažni klausimai
Kaip patikrinti, ar WordPress branduolio failai buvo pakeisti?
Su WP-CLI ir komanda wp core verify-checksums. Ji palygina failus su kontrolinėmis sumomis, kurias WordPress.org skelbia įdiegtai versijai. Su parinktimi --include-root WP-CLI papildomai perspėja apie pagrindiniame kataloge esančius failus, kurie nepriklauso WordPress.
Ką daryti su CMS, neturinčiu integruotos patikros funkcijos?
Atsisiunčiate lygiai tą pačią versiją iš oficialaus gamintojo šaltinio ir abu katalogus palyginate su diff. Composer projektuose atkuriate būseną iš composer.lock tuščiame kataloge ir palyginate vendor aplanką.
Ar palyginimas randa kenkėjišką kodą ir papildiniuose bei temose?
Tik jei jiems yra švarus originalas, pavyzdžiui, iš oficialaus katalogo ar iš teikėjo. Savo pritaikymai, įkėlimai ir konfigūracijos failai originalo neturi ir turi būti tikrinami atskirai.
Ar palyginimas pakeičia kenkėjiškų programų skenerį?
Jis jį papildo. Palyginimas randa kiekvieną žinomų failų pakeitimą, taip pat nežinomą kenkėjišką kodą. Tačiau jis nieko nesako apie failus be originalo, duomenų bazę, cron užduotis ar prieigas.