Ujjlenyomatot veszek minden fájlról

A 2026 júliusi betörés után a Hugging Face-nek gyorsan kellett felelnie egy kérdésre: módosítottak-e a támadók bármit abban, amit a cég a nyilvánosságnak kiad. A választ a kiadott konténerképek és csomagok ujjlenyomata adta meg: a technikai idővonal szerint mindegyik egyezett a várttal. A betörés láncát egy másik Műhely-írás veszi végig.

Egy weboldalon ugyanez a kérdés így hangzik: a szerveren az van-e, amit feltöltöttem? Ugyanazzal a módszerrel lehet rá felelni, csak a vakfoltjait érdemes előre ismerni.

Mi az ujjlenyomat

Az ujjlenyomat, más néven hash, egy fájl tartalmából kiszámolt rövid azonosító, ennél az oldalnál SHA-256 eljárással. Ha a fájlban egyetlen bájt is megváltozik, az ujjlenyomat teljesen más lesz, és két különböző fájlhoz gyakorlatilag nem lehet ugyanazt az ujjlenyomatot előállítani. Ezért elég a két oldal ujjlenyomat-listáját összevetni: ahol egyeznek, ott a fájl bájtra ugyanaz.

Így vetem össze ezen az oldalon

Ez az oldal kézzel írt HTML, és minden élesítés után lefut egy összevetés. A gépemen lévő összes fájlnak kiszámolom az ujjlenyomatát, a szerveren ugyanezt egy parancs teszi meg, és a két listát útvonal szerint rendezve összevetem. Egyszerűsítve így néz ki:

# a gépemen: minden fájl ujjlenyomata, útvonal szerint rendezve
(cd src && find . -type f -exec shasum -a 256 {} +) | sort -k 2 > helyi.txt

# a szerveren ugyanez
ssh szerver 'cd ~/public_html && find . -type f -exec sha256sum {} +' | sort -k 2 > eles.txt

# ami csak az egyikben van, vagy eltér
diff helyi.txt eles.txt

# a nem világolvasható fájlok száma a szerveren: a jó válasz 0
ssh szerver 'find ~/public_html -type f ! -perm -o=r | wc -l'

Az eltérésből három dolog derül ki: mi van csak nálam, mi van csak a szerveren, és minek tér el a tartalma. A szerveren szándékosan lévő fájlok, például a webszerver beállítása és a tárhely saját fájljai, kimaradnak; minden más eltérés hiba, amíg ki nem derül, honnan jött.

Ez az összevetés a saját hibámat is megfogta. 2026. szeptember 25-én az élesítés után eltérést mutatott, mert a csomagolás után öt perccel a forrásban még változtak fájlok: a lap hibátlanul működött, csak a szerveren más állt, mint a gépemen. Augusztus 15-én ugyanez a hiba egyszer már félkész munkát vitt ki. Azóta az élesítés el sem indul, ha a forrásban van nem rögzített változás.

Amit az egyező ujjlenyomat nem bizonyít

Az egyező ujjlenyomat a tartalom azonosságát bizonyítja, azt viszont nem, hogy a webszerver ki is tudja szolgálni a fájlt. Egy macOS-ről feltöltött, csak a tulajdonosa által olvasható kép a szerveren bájtra egyezik, a lap mégis törött képpel jelenik meg, és közben 200-as választ ad. Ezért az összevetés után egy második lépés is fut: megszámolja a szerveren a nem világolvasható fájlokat és a be nem járható mappákat, és mindkét számnak nullának kell lennie. Hogy a jogosultság hogyan utazik át a tömörítésen, egy korábbi Műhely-írás részletezi.

WordPressen: a hivatalos ujjlenyomatok

WordPressen a mag és a wordpress.org-ról telepített bővítmények fájljainak ujjlenyomatát a WordPress.org közzéteszi, és a WP-CLI két paranccsal össze tudja vetni velük a szerveren lévő fájlokat:

wp core verify-checksums --include-root
wp plugin verify-checksums --all

Az első a WordPress magját veti össze a telepített verzióval, és a --include-root kapcsolóval a gyökérkönyvtár nem a WordPresshez tartozó fájljaira is figyelmeztet, így egy ottfelejtett mentés vagy egy bejuttatott fájl is előkerül. A második a wordpress.org-os bővítmények minden fájlját a hivatalos ujjlenyomatokhoz méri (WP-CLI-dokumentáció).

A módszer ott vak, ahol nincs mihez mérni. A fizetős bővítményeknek nincs nyilvános ujjlenyomat-listájuk, a témákra a WP-CLI-nak nincs ilyen parancsa, a feltöltött képekhez és dokumentumokhoz pedig eleve nem is lehet hivatalos lista. Ezeket a saját, ismert állapothoz lehet mérni: a feltöltéskor elmentett ujjlenyomatokhoz, vagy a saját gépen lévő példányhoz.

Ahová az ujjlenyomat nem lát: az adatbázis

A WordPress-feltörések egy része a fájlokhoz hozzá sem nyúl, csak az adatbázisba ír: új admin-fiókot vesz fel, vagy spamet tesz a bejegyzések közé. Az adatbázis minden szerkesztéssel magától is változik, ezért az ujjlenyomata semmit nem mond. Itt a kockázatos részeket érdemes külön figyelni: az admin-fiókok és a bekapcsolt bővítmények listáját. Hogy egy feltörés milyen más jelekből derül ki, arról egy Írás szól.

Amit ebből a saját munkámban csinálok

Ezen az oldalon minden élesítés után lefut a fenti összevetés, a jogosultságok számlálásával együtt. A gondozott WordPress-oldalakon pedig naponta lefut egy ellenőrzés, ami a saját kódom fájljait nézi: megvannak-e a szerveren, nem ürültek-e ki, és benne van-e az a részlet, amitől működnek. Egy frissítés vagy a tárhely karbantartása a saját kódot is eltüntetheti, vagy egy javítást visszavonhat, a lap pedig közben hibátlanul betölt. Ugyanez az ellenőrzés az admin-fiókok listáját is összeveti a várttal.

Az egyik oldal tárhelyén nincs parancssor. Ott a saját kódom egy jelölőt ír a lapra, és a napi ellenőrzés kívülről keresi: ha a jelölő eltűnik, a kód nem fut.

Kérdések a témáról

← Vissza a Műhelyhez