Stručně: Chcete-li zkontrolovat jádrové soubory CMS, porovnejte nainstalované soubory s čistým originálem téže verze: u WordPressu přes oficiální kontrolní součty, u jiných systémů pomocí čerstvého stažení nebo sestavení z composer.lock. Každá odchylka je úkol ke kontrole. Porovnání najde i neznámý škodlivý kód, pokrývá ale jen soubory, pro které originál existuje.
Proč porovnání najde víc než jakákoli signatura
Malwarové skenery hledají známé vzorce. Co neznají, přehlédnou. Porovnání s originálem pracuje obráceně: neptá se, zda soubor vypadá podezřele, ale zda přesně odpovídá tomu, co výrobce dodal. Každá odchylka vyjde najevo, ať už se řídí známým vzorcem, nebo ne.
Po PHP2Shell je to zvlášť cenné. Pro zranitelnosti CVE-2026-109618 a CVE-2026-109619 neexistují zveřejněné, potvrzené indikátory kompromitace (Indicators of Compromise). Skenery tedy nemohou cíleně hledat stopy PHP2Shell. Porovnání s originálem naopak najde každou změnu jádra bez ohledu na to, jak vznikla. Proč samotné skenery nestačí, vysvětluje článek Malwarové skenery pro weby: co najdou a co ne.
Princip: stejná verze, čistý zdroj
Porovnání je jen tak dobré jako jeho reference. Musí být splněny tři podmínky:
- Přesně stejná verze: Porovnání s novější verzí ukáže stovky nevinných rozdílů. Nainstalovanou verzi zjistěte z aplikace nebo z
composer.lock. - Oficiální zdroj: Originál pochází od výrobce, z oficiálního adresáře balíčků nebo z vašeho vlastního systému správy verzí. Ne ze staré zálohy dotčeného serveru.
- Porovnání na kopii: Pracujte na zajištěné kopii webového adresáře, aby zůstala zachována časová razítka a stopy.
| Systém | Reference | Nástroj |
|---|---|---|
| Jádro WordPressu a pluginy z adresáře | kontrolní součty z WordPress.org | wp core verify-checksums, wp plugin verify-checksums |
| Projekty s Composerem (např. Shopware 6, Laravel, Symfony, Drupal, TYPO3 v režimu Composer) | sestavení z composer.lock |
composer install v prázdném adresáři, poté diff |
| CMS se stahovaným balíčkem | balíček téže verze od výrobce | diff -rq |
| Vlastní projekty s Gitem | poslední známý commit | git status, git diff |
| Systémové balíčky serveru | databáze balíčků distribuce | dpkg --verify, rpm -Va |
WordPress: víc než verify-checksums
Jak zkontrolovat jádro a pluginy pomocí WP-CLI, je v průvodci Hledání zadních vrátek ve WordPressu. Vyplatí se jedno doplnění: podle dokumentace WP-CLI volba --include-root zkontroluje všechny soubory a složky v hlavním adresáři a upozorní na položky, které k WordPressu nepatří. Právě tam útočníci rádi ukládají soubory s názvy, které připomínají jádrové soubory.
# Jádro proti oficiálním kontrolním součtům, včetně cizích souborů v hlavním adresáři
wp core verify-checksums --include-root
Komerční pluginy a motivy tato cesta nezahrnuje. U nich stáhnete originální balíček téže verze od poskytovatele a porovnáte pomocí diff.
Kontrola jádrových souborů CMS u projektů s Composerem
Mnoho moderních aplikací PHP se z největší části skládá z balíčků, které instaluje Composer, správce balíčků pro PHP. Jak funguje, vysvětluje stránka Composer: správce balíčků pro PHP. Soubor composer.lock přesně určuje, které verze jsou nainstalovány. Podle dokumentace Composeru používá composer install právě tyto verze. Tak lze sestavit stav při dodání:
# Na čistém systému, ne na dotčeném serveru
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
# Vypsat rozdíly ve složce vendor
diff -rq /tmp/referenz/vendor /pfad/zur/kopie/vendor
Volby --no-scripts a --no-plugins brání tomu, aby se při sestavení spouštěly skripty z balíčků. Pokud byla produkce nainstalována s --no-dev, použijte tuto volbu i při sestavení, jinak se vývojové balíčky objeví jako rozdíl. Všímejte si dvou druhů výsledků: souborů, které se liší, a souborů, které existují jen na serveru. Druhá skupina bývá zajímavější. Jak nainstalované balíčky navíc zkontrolovat na známé zranitelnosti, popisuje průvodce Kontrola závislostí Composeru na zranitelnosti.
Porovnat i operační systém
Pokud měl útočník práva root, mohl nahradit i systémové programy. Správci balíčků mají vlastní porovnání:
# Debian, Ubuntu: soubory, jejichž obsah se liší od balíčku
sudo dpkg --verify
# RHEL, AlmaLinux, Rocky: zkontrolovat všechny balíčky
sudo rpm -Va
Číslice 5 na třetím místě výstupu znamená, že se změnil obsah souboru. Podle příručky dpkg je porovnání obsahu tam v současnosti jedinou účinnou kontrolou. Změněné konfigurační soubory jsou normální a jsou označeny c. Změněný program v /usr/bin je naopak vážným poplachovým signálem. Pozor: útočník s právy root může zmanipulovat i databázi balíčků. Při podezření na přístup root je nové sestavení spolehlivější než jakékoli porovnání.
Systém správy verzí pro kód aplikace promění budoucí porovnání v záležitost vteřin. git status pak ukáže každou odchylku od schváleného stavu.
Posoudit odchylky a znát hranice
Ne každá odchylka je útok. Některé agentury dříve upravovaly jádrové soubory přímo, místo aby používaly rozšíření. Rozdíly vznikají také u jazykových balíčků, konců řádků po přenosu přes FTP nebo dodatečně nasazených oprav. Rozhodující je, zda změnu někdo umí vysvětlit.
Projděte každou odchylku zvlášť a zapište výsledek: známá a zdokumentovaná, nevinně vysvětlitelná, nebo nejasná. Nejasné soubory otevírejte jen jako text na kopii a nahraďte je z čistého zdroje. U souborů, které existují jen na serveru, je otázka jednodušší: kdo je nezná, měl by je nechat zajistit a odstranit poté, co byl zkontrolován jejich obsah.
Nahrané soubory, konfigurační soubory jako wp-config.php nebo .env, vlastní úpravy a cache originál nemají. Je třeba je zkontrolovat cíleně, stejně jako databázi, cron úlohy, uživatelské účty a klíče SSH. Čisté porovnání je proto důležitým stavebním kamenem, ale není zproštěním viny pro celý server.
Jak konkrétně pomáhá PHP SOS?
- Zjistíme nainstalované verze a z oficiálních zdrojů sestavíme čistou referenci.
- Porovnáme jádro, rozšíření, balíčky Composeru i systémové programy a posoudíme každou odchylku.
- Oblasti bez originálu zkontrolujeme cíleně a změněné soubory nahradíme v rámci odstranění malwaru z čistého zdroje.
- Na přání nastavíme verzovaný stav, vůči kterému poběží budoucí kontroly.
Časté dotazy
Jak zkontroluji, zda byly změněny jádrové soubory WordPressu?
Pomocí WP-CLI a příkazu wp core verify-checksums. Ten porovná soubory s kontrolními součty, které WordPress.org zveřejňuje pro nainstalovanou verzi. S volbou --include-root navíc WP-CLI upozorní na soubory v hlavním adresáři, které k WordPressu nepatří.
Co dělat u CMS bez vestavěné kontroly?
Stáhnete přesně stejnou verzi z oficiálního zdroje výrobce a oba adresáře porovnáte pomocí diff. U projektů s Composerem sestavíte stav z composer.lock v prázdném adresáři a porovnáte složku vendor.
Najde porovnání i škodlivý kód v pluginech a motivech?
Jen pokud pro ně existuje čistý originál, například z oficiálního adresáře nebo od poskytovatele. Vlastní úpravy, nahrané soubory a konfigurační soubory originál nemají a je nutné je zkontrolovat zvlášť.
Nahrazuje porovnání malwarový skener?
Doplňuje ho. Porovnání najde každou změnu známých souborů, i neznámý škodlivý kód. Neříká ale nic o souborech bez originálu, o databázi, cron úlohách ani přístupech.