Īsi sakot: Lai pārbaudītu CMS kodola failus, salīdziniet uzstādītos failus ar tīru tās pašas versijas oriģinālu: WordPress gadījumā pēc oficiālajām kontrolsummām, citām sistēmām pēc svaigas lejupielādes vai atveidojuma no composer.lock. Katra novirze ir pārbaudes uzdevums. Salīdzināšana atrod arī nezināmu ļaunprātīgu kodu, bet aptver tikai failus, kuriem ir oriģināls.
Kāpēc salīdzinājums atrod vairāk nekā jebkurš paraksts
Ļaunprogrammatūras skeneri meklē zināmus paraugus. Ko tie nepazīst, to tie palaiž garām. Salīdzināšana ar oriģinālu darbojas pretēji: tā nejautā, vai fails izskatās aizdomīgs, bet vai tas precīzi atbilst tam, ko ražotājs piegādājis. Katra novirze izceļas neatkarīgi no tā, vai tā seko zināmam paraugam.
Pēc PHP2Shell tas ir īpaši vērtīgi. Ievainojamībām CVE-2026-109618 un CVE-2026-109619 nav publicētu, apstiprinātu Indicators of Compromise. Skeneri tāpēc nevar mērķtiecīgi meklēt PHP2Shell pēdas. Salīdzināšana ar oriģinālu savukārt atrod katru izmaiņu kodolā neatkarīgi no tā, kā tā radusies. Kāpēc ar skeneriem vien nepietiek, izskaidro raksts Ļaunprogrammatūras skeneri vietnēm: ko tie atrod un ko ne.
Princips: tā pati versija, tīrs avots
Salīdzinājums ir tik labs, cik laba ir tā atsauce. Jāizpilda trīs nosacījumi:
- Precīzi tā pati versija: salīdzinājums ar jaunāku versiju parāda simtiem nekaitīgu atšķirību. Uzstādīto versiju noskaidrojiet no lietojumprogrammas vai no
composer.lock. - Oficiāls avots: oriģināls nāk no ražotāja, no oficiālā pakotņu kataloga vai no jūsu pašu versiju kontroles sistēmas. Nevis no vecas skartā servera rezerves kopijas.
- Salīdzināšana uz kopijas: strādājiet uz nodrošinātas tīmekļa direktorijas kopijas, lai laika zīmogi un pēdas saglabātos.
| Sistēma | Atsauce | Rīks |
|---|---|---|
| WordPress kodols un spraudņi no kataloga | kontrolsummas no WordPress.org | wp core verify-checksums, wp plugin verify-checksums |
| Composer projekti (piem., Shopware 6, Laravel, Symfony, Drupal, TYPO3 Composer režīmā) | atveidojums no composer.lock |
composer install tukšā direktorijā, tad diff |
| CMS ar lejupielādes pakotni | tās pašas versijas pakotne no ražotāja | diff -rq |
| Paši projekti ar Git | pēdējais zināmais commit | git status, git diff |
| Servera sistēmas pakotnes | distributīva pakotņu datubāze | dpkg --verify, rpm -Va |
WordPress: vairāk nekā verify-checksums
Kā ar WP-CLI pārbaudīt kodolu un spraudņus, rakstīts ceļvedī Slēpto piekļuvju atrašana WordPress. Vērts papildināt: saskaņā ar WP-CLI dokumentāciju opcija --include-root pārbauda visus failus un mapes galvenajā direktorijā un brīdina par ierakstiem, kas nepieder WordPress. Tur uzbrucēji labprāt novieto failus, kuru nosaukumi atgādina kodola failus.
# Kodols pret oficiālajām kontrolsummām, ieskaitot svešus failus galvenajā direktorijā
wp core verify-checksums --include-root
Komerciālos spraudņus un tēmas šis ceļš neaptver. Tiem pakalpojuma sniedzēja lapā lejupielādējiet tās pašas versijas oriģinālo pakotni un salīdziniet ar diff.
CMS kodola failu pārbaude Composer projektiem
Daudzas mūsdienu PHP lietojumprogrammas lielākoties sastāv no pakotnēm, ko instalē Composer, PHP pakotņu pārvaldnieks. Kā tas darbojas, izskaidro lapa Composer: PHP pakotņu pārvaldnieks. Fails composer.lock fiksē, kuras versijas tieši ir uzstādītas. Saskaņā ar Composer dokumentāciju composer install izmanto šīs precīzās versijas. Ar to var atveidot piegādes stāvokli:
# Tīrā sistēmā, nevis skartajā serverī
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
# Uzskaitīt atšķirības vendor mapē
diff -rq /tmp/referenz/vendor /pfad/zur/kopie/vendor
Opcijas --no-scripts un --no-plugins novērš, ka atveidošanas laikā tiek izpildīti skripti no pakotnēm. Ja produkcija tika instalēta ar --no-dev, izmantojiet šo opciju arī atveidošanā, citādi izstrādes pakotnes parādīsies kā atšķirība. Pievērsiet uzmanību diviem rezultātu veidiem: failiem, kas atšķiras, un failiem, kas pastāv tikai serverī. Otrā grupa bieži ir interesantāka. Kā uzstādītās pakotnes papildus pārbaudīt uz zināmām ievainojamībām, apraksta ceļvedis Composer atkarību pārbaude uz ievainojamībām.
Salīdziniet arī operētājsistēmu
Ja uzbrucējam bija root tiesības, viņš varēja nomainīt arī sistēmas programmas. Pakotņu pārvaldnieki nāk ar savu salīdzināšanu:
# Debian, Ubuntu: faili, kuru saturs atšķiras no pakotnes
sudo dpkg --verify
# RHEL, AlmaLinux, Rocky: pārbaudīt visas pakotnes
sudo rpm -Va
5 izvades trešajā pozīcijā nozīmē, ka faila saturs ir mainījies. Saskaņā ar dpkg rokasgrāmatu satura salīdzinājums tur pašlaik ir vienīgā efektīvā pārbaude. Mainīti konfigurācijas faili ir normāli un atzīmēti ar c. Mainīta programma /usr/bin turpretī ir nopietna trauksmes pazīme. Ņemiet vērā: uzbrucējs ar root tiesībām var manipulēt arī ar pakotņu datubāzi. Ja pastāv aizdomas par root piekļuvi, pārbūve ir uzticamāka nekā jebkurš salīdzinājums.
Versiju kontroles sistēma lietojumprogrammas kodam nākamās salīdzināšanas padara par sekunžu lietu. git status tad parāda katru novirzi no apstiprinātā stāvokļa.
Noviržu vērtēšana un robežu apzināšanās
Ne katra novirze ir uzbrukums. Dažas aģentūras agrāk kodola failus ir pielāgojušas tieši, nevis izmantojušas paplašinājumus. Valodu pakotnes, rindu beigas pēc pārsūtīšanas ar FTP vai vēlāk ieviesti labojumi arī rada atšķirības. Izšķirošais ir, vai kāds var izmaiņu izskaidrot.
Izejiet cauri katrai novirzei atsevišķi un pierakstiet rezultātu: zināma un dokumentēta, nekaitīgi izskaidrojama vai neskaidra. Neskaidrus failus atveriet tikai kā tekstu uz kopijas un aizstājiet no tīra avota. Failiem, kas pastāv tikai serverī, jautājums ir vienkāršāks: kas tos nepazīst, tos vajadzētu nodrošināt un likt noņemt pēc satura pārbaudes.
Augšupielādēm, konfigurācijas failiem, piemēram, wp-config.php vai .env, pašu pielāgojumiem un kešatmiņām oriģināla nav. Tie jāpārbauda mērķtiecīgi, tāpat kā datubāze, cronjobs, lietotāju konti un SSH atslēgas. Tīra salīdzināšana tāpēc ir svarīgs elements, bet ne attaisnojums visam serverim.
Kā PHP SOS palīdz konkrēti?
- Mēs noskaidrojam uzstādītās versijas un izveidojam tīru references stāvokli no oficiāliem avotiem.
- Mēs salīdzinām kodolu, paplašinājumus, Composer pakotnes un sistēmas programmas un novērtējam katru novirzi.
- Mēs mērķtiecīgi pārbaudām jomas bez oriģināla un ļaunprogrammatūras noņemšanas ietvaros mainītos failus aizstājam no tīra avota.
- Pēc vēlēšanās mēs ieviešam versiju stāvokli, pret kuru notiks turpmākās pārbaudes.
Biežāk uzdotie jautājumi
Kā pārbaudīt, vai WordPress kodola faili ir mainīti?
Ar WP-CLI un komandu wp core verify-checksums. Tā salīdzina failus ar kontrolsummām, ko WordPress.org publicē uzstādītajai versijai. Ar opciju --include-root WP-CLI papildus brīdina par failiem galvenajā direktorijā, kas nepieder WordPress.
Ko darīt ar CMS bez iebūvētas pārbaudes funkcijas?
Jūs lejupielādējat tieši to pašu versiju no ražotāja oficiālā avota un salīdzināt abas direktorijas ar diff. Composer projektiem stāvokli atveidojat no composer.lock tukšā direktorijā un salīdzināt vendor mapi.
Vai salīdzināšana atrod arī ļaunprātīgu kodu spraudņos un tēmās?
Tikai tad, ja tiem ir tīrs oriģināls, piemēram, no oficiālā kataloga vai no pakalpojuma sniedzēja. Pašu pielāgojumiem, augšupielādēm un konfigurācijas failiem oriģināla nav, un tie jāpārbauda atsevišķi.
Vai salīdzināšana aizstāj ļaunprogrammatūras skeneri?
Tā to papildina. Salīdzināšana atrod katru izmaiņu zināmos failos, arī nezināmu ļaunprātīgu kodu. Taču tā neko nesaka par failiem bez oriģināla, datubāzi, cronjobs vai piekļuvēm.