Röviden: A CMS-magfájlok ellenőrzéséhez vesse össze a telepített fájlokat ugyanazon verzió tiszta eredetijével: a WordPressnél a hivatalos ellenőrző összegekkel, más rendszereknél friss letöltéssel vagy a composer.lock alapján végzett újraépítéssel. Minden eltérés ellenőrzési feladat. Az összevetés az ismeretlen kártékony kódot is megtalálja, de csak azokat a fájlokat fedi le, amelyeknek van eredetijük.
Miért talál többet az összevetés bármilyen szignatúránál
A kártevőkeresők ismert mintákat keresnek. Amit nem ismernek, azt átnézik. Az eredetivel való összevetés fordítva működik: nem azt kérdezi, hogy egy fájl gyanúsnak tűnik-e, hanem azt, hogy pontosan megfelel-e annak, amit a gyártó kiszállított. Minden eltérés feltűnik, akár ismert mintát követ, akár nem.
A PHP2Shell után ez különösen értékes. A CVE-2026-109618 és CVE-2026-109619 résekhez nincsenek közzétett, megerősített Indicators of Compromise. A keresők tehát nem tudnak célzottan PHP2Shell-nyomokat keresni. Az eredetivel való összevetés ezzel szemben a mag minden módosítását megtalálja, függetlenül attól, hogyan keletkezett. Hogy a keresők miért nem elegendők önmagukban, azt a Kártevőkeresők weboldalakhoz: mit találnak meg és mit nem cikk magyarázza.
Az elv: ugyanaz a verzió, tiszta forrás
Egy összevetés csak annyit ér, amennyit a referenciája. Három feltételnek kell teljesülnie:
- Pontosan ugyanaz a verzió: Egy újabb verzióval való összevetés több száz ártalmatlan különbséget mutat. A telepített verziót az alkalmazásból vagy a
composer.lockfájlból állapítsa meg. - Hivatalos forrás: Az eredeti a gyártótól, a hivatalos csomagjegyzékből vagy az Ön saját verziókezelő rendszeréből származik. Nem az érintett szerver egy régi mentéséből.
- Összevetés egy másolaton: A webkönyvtár egy mentett másolatán dolgozzon, hogy az időbélyegek és a nyomok megmaradjanak.
| Rendszer | Referencia | Eszköz |
|---|---|---|
| A WordPress-mag és a jegyzékből származó pluginok | a WordPress.org ellenőrző összegei | wp core verify-checksums, wp plugin verify-checksums |
| Composer-projektek (pl. Shopware 6, Laravel, Symfony, Drupal, TYPO3 Composer-módban) | újraépítés a composer.lock alapján |
composer install üres könyvtárban, majd diff |
| Letöltőcsomaggal rendelkező CMS | ugyanazon verzió csomagja a gyártótól | diff -rq |
| Saját projektek Gittel | az utolsó ismert commit | git status, git diff |
| A szerver rendszercsomagjai | a disztribúció csomagadatbázisa | dpkg --verify, rpm -Va |
WordPress: több, mint a verify-checksums
Hogyan ellenőrizheti a magot és a pluginokat a WP-CLI-vel, azt a Hátsó ajtók keresése a WordPressben útmutató írja le. Egy kiegészítés megéri: a WP-CLI dokumentációja szerint a --include-root opció a főkönyvtár összes fájlját és mappáját ellenőrzi, és figyelmeztet a nem a WordPresshez tartozó bejegyzésekre. Oda szívesen helyeznek el a támadók olyan fájlokat, amelyek nevei magfájlokra emlékeztetnek.
# Mag a hivatalos ellenőrző összegek ellen, a főkönyvtárban lévő idegen fájlokkal együtt
wp core verify-checksums --include-root
A kereskedelmi pluginokat és témákat ez az út nem fedi le. Ezekhez töltse le a szolgáltatótól ugyanazon verzió eredeti csomagját, és vesse össze a diff paranccsal.
CMS-magfájlok ellenőrzése Composer-projekteknél
Sok modern PHP-alkalmazás nagyrészt olyan csomagokból áll, amelyeket a Composer, a PHP csomagkezelője telepít. Hogyan működik, azt a Composer: a PHP csomagkezelője oldal magyarázza. A composer.lock fájl rögzíti, pontosan mely verziók vannak telepítve. A Composer dokumentációja szerint a composer install ezeket a pontos verziókat használja. Ezzel újraépíthető a kiszállítási állapot:
# Egy tiszta rendszeren, nem az érintett szerveren
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
# A vendor mappa különbségeinek felsorolása
diff -rq /tmp/referenz/vendor /pfad/zur/kopie/vendor
A --no-scripts és --no-plugins opciók megakadályozzák, hogy az újraépítéskor a csomagok szkriptjei lefussanak. Ha az éles rendszert --no-dev opcióval telepítették, ezt használja az újraépítésnél is, különben a fejlesztési csomagok különbségként jelennek meg. Két eredménytípusra figyeljen: azokra a fájlokra, amelyek különböznek, és azokra, amelyek csak a szerveren léteznek. A második csoport gyakran az érdekesebb. Hogyan ellenőrizheti a telepített csomagokat ezenfelül ismert rések szempontjából, azt a Composer-függőségek ellenőrzése résekre útmutató írja le.
Az operációs rendszert is vesse össze
Ha a támadó root-jogokkal rendelkezett, rendszerprogramokat is lecserélhetett. A csomagkezelők saját összevetést hoznak magukkal:
# Debian, Ubuntu: olyan fájlok, amelyek tartalma eltér a csomagtól
sudo dpkg --verify
# RHEL, AlmaLinux, Rocky: az összes csomag ellenőrzése
sudo rpm -Va
A kimenet harmadik helyén álló 5 azt jelenti, hogy egy fájl tartalma megváltozott. A dpkg kézikönyve szerint a tartalom összevetése ott jelenleg az egyetlen hatékony ellenőrzés. A módosított konfigurációs fájlok normálisak, és c jelöli őket. Egy módosított program a /usr/bin alatt ezzel szemben komoly riasztójel. Vegye figyelembe: egy root-jogokkal rendelkező támadó a csomagadatbázist is manipulálhatja. Root-hozzáférés gyanúja esetén az újjáépítés megbízhatóbb minden összevetésnél.
Az alkalmazáskódhoz használt verziókezelő rendszer a jövőbeli összevetéseket másodpercek ügyévé teszi. A git status ilyenkor minden eltérést megmutat a jóváhagyott állapottól.
Az eltérések értékelése és a korlátok ismerete
Nem minden eltérés támadás. Egyes ügynökségek korábban közvetlenül módosították a magfájlokat, ahelyett hogy bővítményeket használtak volna. Nyelvi csomagok, az FTP-n keresztüli átvitel utáni sorvégek vagy utólag telepített javítások szintén különbségeket okoznak. Az a döntő, hogy valaki meg tudja-e magyarázni a módosítást.
Minden eltérést egyenként nézzen át, és jegyezze fel az eredményt: ismert és dokumentált, ártalmatlanul megmagyarázható vagy tisztázatlan. A tisztázatlan fájlokat csak szövegként nyissa meg egy másolaton, és cserélje le tiszta forrásból. A csak a szerveren létező fájloknál egyszerűbb a kérdés: aki nem ismeri őket, mentesse és távolíttassa el őket, miután a tartalmukat ellenőrizték.
A feltöltéseknek, a konfigurációs fájloknak, mint a wp-config.php vagy a .env, a saját módosításoknak és a gyorsítótáraknak nincs eredetijük. Ezeket célzottan kell ellenőrizni, ahogyan az adatbázist, a cron-feladatokat, a felhasználói fiókokat és az SSH-kulcsokat is. A tiszta összevetés ezért fontos építőelem, de nem felmentés az egész szerver számára.
Hogyan segít konkrétan a PHP SOS?
- Megállapítjuk a telepített verziókat, és hivatalos forrásokból tiszta referenciát építünk.
- Összevetjük a magot, a bővítményeket, a Composer-csomagokat és a rendszerprogramokat, és minden eltérést értékelünk.
- Az eredeti nélküli területeket célzottan ellenőrizzük, és a módosított fájlokat a kártevő-eltávolítás keretében tiszta forrásból cseréljük le.
- Kívánságra beállítunk egy verzióállapotot, amely ellen a jövőbeli ellenőrzések futnak.
Gyakori kérdések
Hogyan ellenőrzöm, hogy a WordPress magfájljait módosították-e?
A WP-CLI-vel és a wp core verify-checksums paranccsal. Ez összeveti a fájlokat azokkal az ellenőrző összegekkel, amelyeket a WordPress.org a telepített verzióhoz közzétesz. A --include-root opcióval a WP-CLI emellett figyelmeztet a főkönyvtárban lévő, nem a WordPresshez tartozó fájlokra.
Mit tegyek olyan CMS-nél, amelyben nincs beépített ellenőrző funkció?
Pontosan ugyanazt a verziót töltse le a gyártó hivatalos forrásából, és vesse össze a két könyvtárat a diff paranccsal. Composer-projekteknél a composer.lock alapján építse újra az állapotot egy üres könyvtárban, és hasonlítsa össze a vendor mappát.
Az összevetés a pluginokban és témákban lévő kártékony kódot is megtalálja?
Csak akkor, ha ezekhez van tiszta eredeti, például a hivatalos jegyzékből vagy a szolgáltatótól. A saját módosításoknak, a feltöltéseknek és a konfigurációs fájloknak nincs eredetijük, ezeket külön kell ellenőrizni.
Az összevetés helyettesíti a kártevőkeresőt?
Kiegészíti. Az összevetés az ismert fájlok minden módosítását megtalálja, az ismeretlen kártékony kódot is. Arról viszont nem mond semmit, hogy mi van az eredeti nélküli fájlokkal, az adatbázissal, a cron-feladatokkal vagy a hozzáférésekkel.