Na kratko: Za preverjanje jedrnih datotek CMS nameščene datoteke primerjajte s čistim originalom iste različice: pri WordPress prek uradnih kontrolnih vsot, pri drugih sistemih prek svežega prenosa ali ponovne gradnje iz composer.lock. Vsako odstopanje je nalog za pregled. Primerjava najde tudi neznano škodljivo kodo, vendar zajame samo datoteke, za katere obstaja original.
Zakaj primerjava najde več kot vsak podpis
Skenerji zlonamerne programske opreme iščejo znane vzorce. Česar ne poznajo, spregledajo. Primerjava z originalom deluje obratno: ne sprašuje, ali je datoteka videti sumljiva, ampak ali natanko ustreza temu, kar je proizvajalec dostavil. Vsako odstopanje izstopa, ne glede na to, ali sledi znanemu vzorcu.
To je po PHP2Shell še posebej dragoceno. Za ranljivosti CVE-2026-109618 in CVE-2026-109619 ni objavljenih, potrjenih indikatorjev ogroženosti (Indicators of Compromise). Skenerji zato ne morejo ciljno iskati sledi PHP2Shell. Primerjava z originalom pa najde vsako spremembo jedra, ne glede na to, kako je nastala. Zakaj samo skenerji ne zadoščajo, pojasnjuje prispevek Skenerji zlonamerne kode za spletne strani: kaj najdejo in česa ne.
Načelo: ista različica, čist vir
Primerjava je samo toliko dobra kot njena referenca. Izpolnjeni morajo biti trije pogoji:
- Natanko ista različica: primerjava z novejšo različico pokaže na stotine nenevarnih razlik. Nameščeno različico ugotovite iz aplikacije ali iz
composer.lock. - Uradni vir: original izvira od proizvajalca, iz uradnega imenika paketov ali iz vašega lastnega sistema za nadzor različic. Ne iz stare varnostne kopije prizadetega strežnika.
- Primerjava na kopiji: delajte na zavarovani kopiji spletnega imenika, da se ohranijo časovni žigi in sledi.
| Sistem | Referenca | Orodje |
|---|---|---|
| Jedro WordPress in vtičniki iz imenika | kontrolne vsote iz WordPress.org | wp core verify-checksums, wp plugin verify-checksums |
| Projekti Composer (npr. Shopware 6, Laravel, Symfony, Drupal, TYPO3 v načinu Composer) | ponovna gradnja iz composer.lock |
composer install v praznem imeniku, nato diff |
| CMS z namestitvenim paketom | paket iste različice od proizvajalca | diff -rq |
| Lastni projekti z Gitom | zadnji znani commit | git status, git diff |
| Sistemski paketi strežnika | zbirka paketov distribucije | dpkg --verify, rpm -Va |
WordPress: več kot verify-checksums
Kako jedro in vtičnike preverite z WP-CLI, piše v vodniku Iskanje stranskih vrat v WordPressu. Splača se ena dopolnitev: po dokumentaciji WP-CLI možnost --include-root preveri vse datoteke in mape v korenskem imeniku in opozori na vnose, ki ne spadajo k WordPress. Tam napadalci radi odložijo datoteke, katerih imena spominjajo na jedrne datoteke.
# Jedro proti uradnim kontrolnim vsotam, vključno s tujimi datotekami v korenskem imeniku
wp core verify-checksums --include-root
Komercialnih vtičnikov in tem ta pot ne zajame. Zanje pri ponudniku prenesite originalni paket iste različice in primerjajte z diff.
Preverjanje jedrnih datotek CMS pri projektih Composer
Številne sodobne aplikacije PHP v največji meri sestavljajo paketi, ki jih namesti Composer, upravljalnik paketov za PHP. Kako deluje, pojasnjuje stran Composer: upravljalnik paketov za PHP. Datoteka composer.lock določa, katere različice so natančno nameščene. Po dokumentaciji Composer composer install uporabi prav te različice. Tako je mogoče znova zgraditi stanje ob dostavi:
# Na čistem sistemu, ne na prizadetem strežniku
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
# Izpis razlik v mapi vendor
diff -rq /tmp/referenz/vendor /pfad/zur/kopie/vendor
Možnosti --no-scripts in --no-plugins preprečita, da bi se pri ponovni gradnji izvajali skripti iz paketov. Če je bila produkcija nameščena z --no-dev, to možnost uporabite tudi pri ponovni gradnji, sicer se razvojni paketi pojavijo kot razlika. Bodite pozorni na dve vrsti rezultatov: datoteke, ki se razlikujejo, in datoteke, ki obstajajo samo na strežniku. Druga skupina je pogosto zanimivejša. Kako nameščene pakete dodatno preverite glede znanih ranljivosti, opisuje vodnik Preverjanje odvisnosti Composer za ranljivosti.
Primerjajte tudi operacijski sistem
Če je imel napadalec pravice root, je lahko zamenjal tudi sistemske programe. Upravljalniki paketov imajo lastno primerjavo:
# Debian, Ubuntu: datoteke, katerih vsebina odstopa od paketa
sudo dpkg --verify
# RHEL, AlmaLinux, Rocky: preverite vse pakete
sudo rpm -Va
5 na tretjem mestu izpisa pomeni, da se je vsebina datoteke spremenila. Po priročniku dpkg je primerjava vsebine tam trenutno edino učinkovito preverjanje. Spremenjene konfiguracijske datoteke so običajne in označene s c. Spremenjen program v /usr/bin pa je resen alarmni znak. Upoštevajte: napadalec s pravicami root lahko manipulira tudi zbirko paketov. Pri sumu na dostop root je ponovna postavitev zanesljivejša od vsake primerjave.
Sistem za nadzor različic za kodo aplikacije prihodnje primerjave spremeni v zadevo sekund. git status potem pokaže vsako odstopanje od odobrenega stanja.
Ocena odstopanj in poznavanje meja
Vsako odstopanje ni napad. Nekatere agencije so v preteklosti jedrne datoteke prilagajale neposredno, namesto da bi uporabile razširitve. Jezikovni paketi, konci vrstic po prenosu prek FTP ali naknadno nameščeni popravki prav tako povzročijo razlike. Odločilno je, ali lahko kdo spremembo pojasni.
Vsako odstopanje preglejte posebej in rezultat zabeležite: znano in dokumentirano, nenevarno pojasnljivo ali nejasno. Nejasne datoteke odprite samo kot besedilo na kopiji in jih zamenjajte iz čistega vira. Pri datotekah, ki obstajajo samo na strežniku, je vprašanje preprostejše: kdor jih ne pozna, naj jih zavaruje in odstrani, potem ko je bila njihova vsebina pregledana.
Nalaganja, konfiguracijske datoteke, kot sta wp-config.php ali .env, lastne prilagoditve in predpomnilniki nimajo originala. Preveriti jih je treba ciljno, prav tako zbirko podatkov, cronjobe, uporabniške račune in ključe SSH. Čista primerjava je zato pomemben gradnik, vendar ne oprostitev za celoten strežnik.
Kako PHP SOS pomaga konkretno?
- Ugotovimo nameščene različice in iz uradnih virov zgradimo čisto referenco.
- Primerjamo jedro, razširitve, pakete Composer in sistemske programe ter ocenimo vsako odstopanje.
- Področja brez originala preverimo ciljno in spremenjene datoteke v okviru odstranjevanja zlonamerne kode zamenjamo iz čistega vira.
- Na željo vzpostavimo različico, proti kateri tečejo prihodnja preverjanja.
Pogosta vprašanja
Kako preverim, ali so bile jedrne datoteke WordPress spremenjene?
Z WP-CLI in ukazom wp core verify-checksums. Datoteke primerja s kontrolnimi vsotami, ki jih WordPress.org objavlja za nameščeno različico. Z možnostjo --include-root WP-CLI dodatno opozori na datoteke v korenskem imeniku, ki ne spadajo k WordPress.
Kaj storim pri CMS brez vgrajene funkcije preverjanja?
Iz uradnega vira proizvajalca prenesete povsem enako različico in oba imenika primerjate z diff. Pri projektih Composer stanje iz composer.lock zgradite znova v praznem imeniku in primerjate mapo vendor.
Ali primerjava najde tudi škodljivo kodo v vtičnikih in temah?
Samo, če za te obstaja čisti original, na primer iz uradnega imenika ali od ponudnika. Lastne prilagoditve, nalaganja in konfiguracijske datoteke nimajo originala in jih je treba preveriti posebej.
Ali primerjava nadomešča skener zlonamerne programske opreme?
Dopolnjuje ga. Primerjava najde vsako spremembo znanih datotek, tudi neznano škodljivo kodo. Ne pove pa ničesar o datotekah brez originala, zbirki podatkov, cronjobih ali dostopih.