# Primerjava jedrnih datotek CMS z originalom

> Jedrne datoteke CMS primerjajte z originalom: kontrolne vsote, čisto referenčno stanje in diff za WordPress, projekte Composer in sistemske pakete.

Vir: https://phpsos.de/sl/blog/cms-kerndateien-vergleichen/  
Stanje: 25.10.2026  
Ponudnik: PHP SOS, Nujna pomoč za PHP in varnost strežnikov. Takojšnja pomoč po WhatsAppu: https://wa.me/491736494914?text=Pozdravljeni%2C%20PHP%20SOS%2C%20potrebujemo%20pomo%C4%8D%20z%20na%C5%A1im%20stre%C5%BEnikom%20PHP.%20Podjetje%3A%20%E2%80%A6%20Spletna%20stran%3A%20%E2%80%A6

**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](https://phpsos.de/sl/blog/grenzen-von-malware-scannern/).

## Načelo: ista različica, čist vir

Primerjava je samo toliko dobra kot njena referenca. Izpolnjeni morajo biti trije pogoji:

1. **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`.
2. **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.
3. **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](https://phpsos.de/sl/ratgeber/backdoor-wordpress-finden/). 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.

```bash
# 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](https://phpsos.de/sl/php/composer/). 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:

```bash
# 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](https://phpsos.de/sl/ratgeber/composer-abhaengigkeiten-pruefen/).

## Primerjajte tudi operacijski sistem

Če je imel napadalec pravice root, je lahko zamenjal tudi sistemske programe. Upravljalniki paketov imajo lastno primerjavo:

```bash
# 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.

> **Nasvet:**
> 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](https://phpsos.de/sl/leistungen/malware-entfernung/) 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.

## Viri

- [WordPress](https://wordpress.org/)
- [Composer](https://getcomposer.org/)
- [Debian Security Tracker](https://security-tracker.debian.org/)