# CMS-ydintiedostojen vertailu alkuperäiseen

> CMS-ydintiedostojen vertailu alkuperäiseen: tarkistussummat, puhdas vertailuversio ja diff WordPressille, Composer-projekteille ja järjestelmäpaketeille.

Lähde: https://phpsos.de/fi/blog/cms-kerndateien-vergleichen/  
Tilanne: 25.10.2026  
Palveluntarjoaja: PHP SOS, PHP-hätäapu ja palvelimen tietoturva. Pikaapu WhatsAppilla: https://wa.me/491736494914?text=Hei%20PHP%20SOS%2C%20tarvitsemme%20apua%20PHP-palvelimemme%20kanssa.%20Yritys%3A%20%E2%80%A6%20Verkkosivusto%3A%20%E2%80%A6

**Lyhyesti:** Tarkistaaksenne CMS:n ydintiedostot vertaatte asennettuja tiedostoja saman version puhtaaseen alkuperäiseen: WordPressissä virallisten tarkistussummien avulla, muissa järjestelmissä tuoreella latauksella tai composer.lock-tiedostosta tehdyllä jälleenrakennuksella. Jokainen poikkeama on tarkistustehtävä. Vertailu löytää myös tuntemattoman haittakoodin, mutta kattaa vain tiedostot, joille alkuperäinen on olemassa.

## Miksi vertailu löytää enemmän kuin mikään allekirjoitus

Haittaohjelmaskannerit etsivät tunnettuja kuvioita. Mitä ne eivät tunne, sen ne ohittavat. Vertailu alkuperäiseen toimii päinvastoin: se ei kysy, näyttääkö tiedosto epäilyttävältä, vaan vastaako se täsmälleen sitä, minkä valmistaja on toimittanut. Jokainen poikkeama huomataan, noudattipa se tunnettua kuviota tai ei.

Tämä on PHP2Shellin jälkeen erityisen arvokasta. Aukoille CVE-2026-109618 ja CVE-2026-109619 ei ole julkaistuja, vahvistettuja Indicators of Compromise -tunnisteita. Skannerit eivät siis voi etsiä kohdennetusti PHP2Shellin jälkiä. Vertailu alkuperäiseen löytää sen sijaan jokaisen ytimen muutoksen riippumatta siitä, miten se on syntynyt. Miksi skannerit eivät yksin riitä, selittää kirjoitus [Verkkosivustojen haittaohjelmaskannerit: mitä ne löytävät ja mitä eivät](https://phpsos.de/fi/blog/grenzen-von-malware-scannern/).

## Periaate: sama versio, puhdas lähde

Vertailu on vain niin hyvä kuin sen vertailukohta. Kolmen ehdon on täytyttävä:

1. **Täsmälleen sama versio:** Vertailu uudempaan versioon näyttää satoja harmittomia eroja. Selvittäkää asennettu versio sovelluksesta tai tiedostosta `composer.lock`.
2. **Virallinen lähde:** Alkuperäinen tulee valmistajalta, viralliselta pakettihakemistolta tai omasta versionhallinnastanne. Ei vaikutuksen alaisen palvelimen vanhasta varmuuskopiosta.
3. **Vertailu kopiolla:** Työskennelkää varmistetulla kopiolla verkkohakemistosta, jotta aikaleimat ja jäljet säilyvät.

| Järjestelmä | Vertailukohta | Työkalu |
|---|---|---|
| WordPressin ydin ja hakemiston liitännäiset | WordPress.orgin tarkistussummat | `wp core verify-checksums`, `wp plugin verify-checksums` |
| Composer-projektit (esim. Shopware 6, Laravel, Symfony, Drupal, TYPO3 Composer-tilassa) | jälleenrakennus tiedostosta `composer.lock` | `composer install` tyhjässä hakemistossa, sitten `diff` |
| CMS latauspaketilla | valmistajan saman version paketti | `diff -rq` |
| Omat projektit Gitissä | viimeinen tunnettu commit | `git status`, `git diff` |
| Palvelimen järjestelmäpaketit | jakelun pakettitietokanta | `dpkg --verify`, `rpm -Va` |

## WordPress: enemmän kuin verify-checksums

Miten ytimen ja liitännäiset tarkistetaan WP-CLI:llä, kerrotaan oppaassa [Takaovien etsintä WordPressistä](https://phpsos.de/fi/ratgeber/backdoor-wordpress-finden/). Yksi täydennys kannattaa: WP-CLI:n dokumentaation mukaan valinta `--include-root` tarkistaa kaikki päähakemiston tiedostot ja kansiot ja varoittaa merkinnöistä, jotka eivät kuulu WordPressiin. Sinne hyökkääjät jättävät mielellään tiedostoja, joiden nimet muistuttavat ydintiedostoja.

```bash
# Ydin virallisia tarkistussummia vasten, mukaan lukien vieraat tiedostot päähakemistossa
wp core verify-checksums --include-root
```

Kaupallisia liitännäisiä ja teemoja tämä tie ei kata. Niille lataatte saman version alkuperäispaketin toimittajalta ja vertaatte komennolla `diff`.

## CMS-ydintiedostojen tarkistus Composer-projekteissa

Monet nykyaikaiset PHP-sovellukset koostuvat suurimmaksi osaksi paketeista, jotka Composer, PHP:n pakettienhallinta, asentaa. Miten se toimii, selittää sivu [Composer: PHP:n pakettienhallinta](https://phpsos.de/fi/php/composer/). Tiedosto `composer.lock` kirjaa, mitkä versiot on asennettu täsmälleen. Composerin dokumentaation mukaan `composer install` käyttää näitä tarkkoja versioita. Näin toimitustila voidaan rakentaa uudelleen:

```bash
# Puhtaalla järjestelmällä, ei vaikutuksen alaisella palvelimella
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

# Luettele vendor-kansion erot
diff -rq /tmp/referenz/vendor /pfad/zur/kopie/vendor
```

Valinnat `--no-scripts` ja `--no-plugins` estävät pakettien skriptejä suorittumasta jälleenrakennuksessa. Jos tuotanto asennettiin valinnalla `--no-dev`, käyttäkää sitä myös jälleenrakennuksessa, muuten kehityspaketit näkyvät erona. Kiinnittäkää huomiota kahteen tulostyyppiin: tiedostoihin, jotka eroavat, ja tiedostoihin, jotka ovat vain palvelimella. Jälkimmäinen ryhmä on usein mielenkiintoisempi. Miten asennetut paketit tarkistetaan lisäksi tunnettujen aukkojen varalta, kuvaa opas [Composer-riippuvuuksien tarkistus aukkojen varalta](https://phpsos.de/fi/ratgeber/composer-abhaengigkeiten-pruefen/).

## Vertailkaa myös käyttöjärjestelmää

Jos hyökkääjällä oli root-oikeudet, hän on voinut korvata myös järjestelmäohjelmia. Pakettienhallinnoissa on oma vertailu:

```bash
# Debian, Ubuntu: tiedostot, joiden sisältö poikkeaa paketista
sudo dpkg --verify

# RHEL, AlmaLinux, Rocky: tarkista kaikki paketit
sudo rpm -Va
```

Viitonen tulosteen kolmannella paikalla tarkoittaa, että tiedoston sisältö on muuttunut. dpkg-käsikirjan mukaan sisältövertailu on siellä tällä hetkellä ainoa tehokas tarkistus. Muuttuneet asetustiedostot ovat normaaleja ja merkitty kirjaimella `c`. Muuttunut ohjelma hakemistossa `/usr/bin` on sen sijaan vakava hälytysmerkki. Huomatkaa: root-oikeuksilla varustettu hyökkääjä voi manipuloida myös pakettitietokantaa. Jos root-pääsyä epäillään, uudelleenrakennus on luotettavampi kuin mikään vertailu.

> **Vinkki:**
> Sovelluskoodin versionhallinta tekee tulevista vertailuista sekunttien asian. `git status` näyttää silloin jokaisen poikkeaman hyväksytystä tilasta.

## Poikkeamien arviointi ja rajojen tunteminen

Kaikki poikkeamat eivät ole hyökkäyksiä. Jotkin toimistot ovat aiemmin muokanneet ydintiedostoja suoraan laajennusten käyttämisen sijaan. Kielipaketit, rivinvaihdot FTP-siirron jälkeen tai jälkikäteen asennetut korjaukset aiheuttavat myös eroja. Ratkaisevaa on, osaako joku selittää muutoksen.

Käykää jokainen poikkeama läpi erikseen ja kirjatkaa tulos: tunnettu ja dokumentoitu, harmittomana selitettävissä tai epäselvä. Epäselvät tiedostot avaatte vain tekstinä kopiolla ja korvaatte puhtaasta lähteestä. Tiedostojen kohdalla, jotka ovat vain palvelimella, kysymys on yksinkertaisempi: jos kukaan ei tunne tiedostoa, se kannattaa varmistaa ja antaa poistaa sen sisällön tarkistuksen jälkeen.

Upload-tiedostoilla, asetustiedostoilla kuten `wp-config.php` tai `.env`, omilla mukautuksilla ja välimuisteilla ei ole alkuperäistä. Ne on tarkistettava kohdennetusti, samoin tietokanta, cron-tehtävät, käyttäjätilit ja SSH-avaimet. Puhdas vertailu on siksi tärkeä rakennuspalikka mutta ei vapauttava todiste koko palvelimelle.

## Miten PHP SOS auttaa konkreettisesti?

- Selvitämme asennetut versiot ja rakennamme puhtaan vertailukohdan virallisista lähteistä.
- Vertaamme ytimen, laajennukset, Composer-paketit ja järjestelmäohjelmat ja arvioimme jokaisen poikkeaman.
- Tarkistamme alueet, joille alkuperäistä ei ole, kohdennetusti ja korvaamme muuttuneet tiedostot [haittaohjelmien poiston](https://phpsos.de/fi/leistungen/malware-entfernung/) yhteydessä puhtaasta lähteestä.
- Pystytämme halutessanne versiotilan, jota vasten tulevat tarkistukset ajetaan.


## Usein kysytyt kysymykset

**Miten tarkistan, onko WordPressin ydintiedostoja muutettu?**  
WP-CLI:llä ja komennolla wp core verify-checksums. Se vertaa tiedostoja tarkistussummiin, jotka WordPress.org julkaisee asennetulle versiolle. Valinnalla --include-root WP-CLI varoittaa lisäksi päähakemiston tiedostoista, jotka eivät kuulu WordPressiin.

**Mitä teen CMS:lle, jossa ei ole sisäänrakennettua tarkistustoimintoa?**  
Lataatte täsmälleen saman version valmistajan virallisesta lähteestä ja vertaatte hakemistoja komennolla diff. Composer-projekteissa rakennatte tilan composer.lock-tiedostosta tyhjään hakemistoon ja vertaatte vendor-kansiota.

**Löytääkö vertailu myös haittakoodin liitännäisistä ja teemoista?**  
Vain jos niistä on puhdas alkuperäinen, esimerkiksi virallisesta hakemistosta tai toimittajalta. Omilla mukautuksilla, upload-tiedostoilla ja asetustiedostoilla ei ole alkuperäistä, ja ne on tarkistettava erikseen.

**Korvaako vertailu haittaohjelmaskannerin?**  
Se täydentää sitä. Vertailu löytää jokaisen muutoksen tunnetuissa tiedostoissa, myös tuntemattoman haittakoodin. Se ei kuitenkaan kerro mitään tiedostoista, joilla ei ole alkuperäistä, tietokannasta, cron-tehtävistä eikä tunnuksista.

## Lähteet

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