# CMS-magfájlok összevetése az eredetivel

> CMS-magfájlok összevetése az eredetivel: ellenőrző összegek, tiszta referenciaállapot és diff WordPresshez, Composer-projektekhez és rendszercsomagokhoz.

Forrás: https://phpsos.de/hu/blog/cms-kerndateien-vergleichen/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

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

1. **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.lock` fájlból állapítsa meg.
2. **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.
3. **Ö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](https://phpsos.de/hu/ratgeber/backdoor-wordpress-finden/) ú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.

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

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

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

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

## Források

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