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.
Periaate: sama versio, puhdas lähde
Vertailu on vain niin hyvä kuin sen vertailukohta. Kolmen ehdon on täytyttävä:
- Täsmälleen sama versio: Vertailu uudempaan versioon näyttää satoja harmittomia eroja. Selvittäkää asennettu versio sovelluksesta tai tiedostosta
composer.lock. - Virallinen lähde: Alkuperäinen tulee valmistajalta, viralliselta pakettihakemistolta tai omasta versionhallinnastanne. Ei vaikutuksen alaisen palvelimen vanhasta varmuuskopiosta.
- 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ä. 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.
# 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. 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:
# 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.
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:
# 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.
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 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.