Lühidalt: CMS-i tuumafailide kontrollimiseks võrdlete paigaldatud faile sama versiooni puhta originaaliga: WordPressi puhul ametlike kontrollsummade abil, teiste süsteemide puhul värske allalaadimise või failist composer.lock ülesehituse kaudu. Iga kõrvalekalle on kontrolliülesanne. Võrdlus leiab ka tundmatu kahjuliku koodi, kuid katab ainult need failid, millele originaal olemas on.
Miks võrdlus leiab rohkem kui ükski signatuur
Pahavaraskannerid otsivad tuntud mustreid. Mida nad ei tunne, selle jätavad nad märkamata. Originaaliga võrdlus töötab vastupidi: see ei küsi, kas fail näeb kahtlane välja, vaid kas see vastab täpselt sellele, mille tootja on tarninud. Iga kõrvalekalle jääb silma, olenemata sellest, kas see järgib tuntud mustrit või mitte.
See on pärast PHP2Shelli eriti väärtuslik. Aukude CVE-2026-109618 ja CVE-2026-109619 kohta ei ole avaldatud ega kinnitatud kompromiteerimistunnuseid (Indicators of Compromise). Skannerid ei saa seega sihipäraselt PHP2Shelli jälgi otsida. Originaaliga võrdlus leiab seevastu iga tuuma muudatuse, sõltumata sellest, kuidas see tekkis. Miks skannerid üksi ei piisa, selgitab artikkel Veebisaitide pahavaraskannerid: mida nad leiavad ja mida mitte.
Põhimõte: sama versioon, puhas allikas
Võrdlus on nii hea kui selle võrdlusalus. Täidetud peavad olema kolm tingimust:
- Täpselt sama versioon: võrdlus uuema versiooniga näitab sadu kahjutuid erinevusi. Selgitage paigaldatud versioon välja rakendusest või failist
composer.lock. - Ametlik allikas: originaal pärineb tootjalt, ametlikust paketikataloogist või teie enda versioonihaldussüsteemist. Mitte mõjutatud serveri vanast varukoopiast.
- Võrdlus koopial: töötage veebikataloogi kindlustatud koopial, et ajatemplid ja jäljed säiliksid.
| Süsteem | Võrdlusalus | Tööriist |
|---|---|---|
| WordPressi tuum ja kataloogi pluginad | WordPress.org kontrollsummad | wp core verify-checksums, wp plugin verify-checksums |
| Composeri projektid (nt Shopware 6, Laravel, Symfony, Drupal, TYPO3 Composeri režiimis) | uuesti ülesehitus failist composer.lock |
composer install tühjas kataloogis, seejärel diff |
| CMS allalaadimispaketiga | sama versiooni pakett tootjalt | diff -rq |
| Enda projektid Gitiga | viimane teadaolev commit | git status, git diff |
| Serveri süsteemipaketid | distributsiooni paketiandmebaas | dpkg --verify, rpm -Va |
WordPress: rohkem kui verify-checksums
Kuidas tuuma ja plugin'aid WP-CLI-ga kontrollida, on kirjas juhendis Tagauste leidmine WordPressis. Üks täiendus tasub ära: WP-CLI dokumentatsiooni järgi kontrollib valik --include-root kõiki peakataloogis olevaid faile ja kaustu ning hoiatab kirjete eest, mis WordPressi ei kuulu. Sinna panevad ründajad meelsasti faile, mille nimed tuletavad meelde tuumafaile.
# Tuum ametlike kontrollsummade vastu, kaasa arvatud võõrad failid peakataloogis
wp core verify-checksums --include-root
Kommertspluginaid ja -teemasid see tee ei hõlma. Nende jaoks laadige pakkujalt alla sama versiooni originaalpakett ja võrrelge käsuga diff.
CMS-i tuumafailide kontroll Composeri projektides
Paljud kaasaegsed PHP rakendused koosnevad suuremalt osalt pakettidest, mille Composer paigaldab; see on PHP paketihaldur. Kuidas see töötab, selgitab leht Composer: PHP paketihaldur. Fail composer.lock fikseerib, millised versioonid täpselt on paigaldatud. Composeri dokumentatsiooni järgi kasutab composer install just neid täpseid versioone. Nii saab tarneseisu uuesti üles ehitada:
# Puhtas süsteemis, mitte mõjutatud serveris
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
# Loetlege vendor-kausta erinevused
diff -rq /tmp/referenz/vendor /pfad/zur/kopie/vendor
Valikud --no-scripts ja --no-plugins takistavad, et ülesehitamisel käivitataks pakettides olevaid skripte. Kui tootmine paigaldati valikuga --no-dev, kasutage seda ka ülesehitamisel, muidu ilmuvad arenduspaketid erinevusena. Pöörake tähelepanu kahele tulemusliigile: failid, mis erinevad, ja failid, mis eksisteerivad ainult serveris. Teine rühm on sageli huvitavam. Kuidas paigaldatud pakette lisaks tuntud aukude suhtes kontrollida, kirjeldab juhend Composeri sõltuvuste kontroll aukude suhtes.
Võrrelge ka operatsioonisüsteemi
Kui ründajal olid root-õigused, võis ta asendada ka süsteemiprogramme. Paketihaldurid toovad kaasa oma võrdluse:
# Debian, Ubuntu: failid, mille sisu erineb paketist
sudo dpkg --verify
# RHEL, AlmaLinux, Rocky: kõikide pakettide kontroll
sudo rpm -Va
5 väljundi kolmandal kohal tähendab, et faili sisu on muutunud. dpkg käsiraamatu järgi on sisu võrdlus seal praegu ainus tegelikult toimiv kontroll. Muudetud konfiguratsioonifailid on normaalsed ja märgitud tähega c. Muudetud programm kataloogis /usr/bin on seevastu tõsine häiremärk. Arvestage: root-õigustega ründaja võib manipuleerida ka paketiandmebaasiga. Root-ligipääsu kahtluse korral on uuestiehitus usaldusväärsem kui ükskõik milline võrdlus.
Rakenduskoodi versioonihaldussüsteem muudab tulevased võrdlused sekundiasjaks. git status näitab siis iga kõrvalekallet kinnitatud seisust.
Kõrvalekallete hindamine ja piiride tundmine
Mitte iga kõrvalekalle ei ole rünnak. Mõned agentuurid on tuumafaile varem otse kohandanud, selle asemel et laiendusi kasutada. Keelepaketid, reavahetused pärast FTP-ga edastamist või tagantjärele paigaldatud parandused tekitavad samuti erinevusi. Otsustav on, kas keegi oskab muudatust seletada.
Käige iga kõrvalekalle eraldi läbi ja märkige tulemus: tuntud ja dokumenteeritud, kahjutult seletatav või ebaselge. Ebaselgeid faile avage ainult tekstina koopial ja asendage need puhtast allikast. Failide puhul, mis eksisteerivad ainult serveris, on küsimus lihtsam: kes neid ei tunne, peaks need kindlustama ja eemaldada laskma, kui nende sisu on üle vaadatud.
Üleslaadimistel, konfiguratsioonifailidel nagu wp-config.php või .env, enda kohandustel ja vahemäludel originaali ei ole. Neid tuleb kontrollida sihipäraselt, samuti andmebaasi, cron-töid, kasutajakontosid ja SSH-võtmeid. Puhas võrdlus on seetõttu oluline ehituskivi, kuid mitte kogu serveri õigeksmõistmine.
Kuidas PHP SOS konkreetselt aitab?
- Selgitame välja paigaldatud versioonid ja ehitame ametlikest allikatest üles puhta võrdlusaluse.
- Võrdleme tuuma, laiendusi, Composeri pakette ja süsteemiprogramme ning hindame iga kõrvalekallet.
- Kontrollime originaalita alasid sihipäraselt ja asendame muudetud failid pahavara eemaldamise raames puhtast allikast.
- Soovi korral seadistame versiooniseisu, mille vastu tulevased kontrollid jooksevad.
Korduma kippuvad küsimused
Kuidas kontrollin, kas WordPressi tuumafaile on muudetud?
WP-CLI ja käsuga wp core verify-checksums. See võrdleb faile kontrollsummadega, mille WordPress.org paigaldatud versiooni kohta avaldab. Valikuga --include-root hoiatab WP-CLI lisaks peakataloogis olevate failide eest, mis WordPressi ei kuulu.
Mida teha CMS-iga, millel pole sisseehitatud kontrollfunktsiooni?
Laadite täpselt sama versiooni alla tootja ametlikust allikast ja võrdlete mõlemat kataloogi käsuga diff. Composeri projektide puhul ehitate seisu failist composer.lock tühjas kataloogis uuesti üles ja võrdlete vendor-kausta.
Kas võrdlus leiab ka pluginates ja teemades olevat kahjulikku koodi?
Ainult siis, kui neil on puhas originaal, näiteks ametlikust kataloogist või pakkujalt. Enda kohandustel, üleslaadimistel ja konfiguratsioonifailidel originaali ei ole ja neid tuleb eraldi kontrollida.
Kas võrdlus asendab pahavaraskanneri?
See täiendab seda. Võrdlus leiab iga muudatuse tuntud failides, ka tundmatu kahjuliku koodi. Kuid see ei ütle midagi originaalita failide, andmebaasi, cron-tööde ega ligipääsude kohta.