Amit a támadó lát, mielőtt bármit tenne

Egy weboldal biztonságáról sok minden kiderül kívülről, bejelentkezés nélkül: milyen rendszer fut alatta, mennyire maradt el a frissítésekkel, és van-e ismert hiba a futó verzióiban. Az automatizált támadások is a nyilvános adatok gyűjtésével kezdődnek. A Hugging Face elleni 2026 júliusi támadásban július 10. csendes nap volt: az ágensek főleg kódkeresőkben és a Hugging Face nyilvános programozói felületén kerestek rá azokra az azonosítókra, amelyeket a saját környezetükben láttak. A fő támadás másnap indult.

Mi látszik kívülről, és mivel nézheted meg

A táblázat azt sorolja, ami egy átlagos WordPress-oldalon bejelentkezés nélkül kiolvasható, és hogy melyik nyilvános eszköz mutatja meg.

Amit a forráskód elárul

A böngésző minden látogatáskor letölti a lap forrását, és abban sok minden benne marad. A WordPress alapból beírja a saját verziószámát a lap fejlécébe, a bővítmények fájljai pedig gyakran a verziójukkal együtt töltődnek be: a címük végén ?ver= és egy szám áll. A bővítmények mappájában sokszor egy readme.txt is lekérhető, benne a verzióval.

A verziót a nyilvános sebezhetőség-adatbázisokban érdemes megkeresni. Ilyet több cég is fenntart, például a WPScan, a Patchstack és a Wordfence. Ha a futó verzióra van bejegyzés, és a javított változat már megjelent, a hiba nyilvános, a javítás pedig nincs fent.

A verziószám elrejtése keveset segít. A tömeges támadások jellemzően minden oldalon rápróbálnak a hibára, a verzió ellenőrzése nélkül, a tulajdonosnak viszont épp a verzió mutatja meg, mi maradt el.

Amit a szerver válasza elárul

A kapcsolódáskor kiderül, meddig érvényes a tanúsítvány, és milyen titkosítást enged a szerver. A válasz fejléceiből az, milyen biztonsági szabályokat kér az oldal a böngészőtől, például hogy ne töltsön be idegen szkriptet, vagy csak titkosított kapcsolaton jöjjön vissza; és néha az is, milyen szoftver milyen verzióval fut a szerveren.

A tanúsítványt és a titkosítás beállítását a Qualys SSL Labs vizsgálója, a fejléceket a Mozilla HTTP Observatory nevű eszköze nézi meg; mindkettő ingyenes.

Amit a szerveren felejtenek

A legkockázatosabb réteg a fájloké, amelyek nem a látogatóknak készültek, mégis lekérhetők: egy költözés után ottfelejtett adatbázismentés, egy wp-config.php-ról készült másolat, egy naplófájl, amibe a hibák a szerver útvonalaival együtt kerülnek. Egy letölthető mentés a teljes adatbázist kiadhatja, benne a felhasználók adataival.

Kívülről ezeket csak találgatással lehet megtalálni: a támadóeszközök a szokásos fájlnevekre kérdeznek rá sorban, oldalról oldalra. A saját oldaladon egyszerűbb belülről megnézni. A tárhely fájlkezelőjében a gyökérkönyvtárban minden olyan fájl gyanús, ami nem a látogatóknak szól, például a .sql, .zip, .bak és .log végűek és a régi másolatok. Ami kell, az a gyökérkönyvtár fölé kerüljön, a többi törölhető.

A saját oldalamon 2026 augusztusában hat ilyen fájlt találtam a gyökérkönyvtárban: a webszerver beállításainak mentéseit, amelyekből a teljes szabálykészlet kiolvasható volt. Azóta ezek a mentések a gyökérkönyvtár fölé kerülnek.

Ha a saját oldaladat nézed

A külső ellenőrzést lassan érdemes végezni. A tárhelyek előtt gyakran védelmi rendszer ül, ami a sűrű, gyanús kéréseket, például sok nem létező fájl lekérését egymás után, támadásnak nézi, és kizárja a kérdezőt.

2026 augusztusában velem is ez történt: a saját ellenőrző szkriptem néhány nem létező fájlra kérdezett rá a saját oldalamon, és a tárhely tűzfala órákra kizárta a gépemet. Se a weboldal, se a szerver parancssora, se a tárhely kezelőfelülete nem volt elérhető, miközben a látogatók zavartalanul böngésztek. Azóta az ellenőrzéseim azonosítható néven, szünetekkel kérdeznek, és csak olyan fájlt kérnek le, amiről tudom, hogy létezik.

Amit kívülről nem lehet látni

Több lényeges dolog csak belülről látszik: kinek van admin-fiókja, készül-e mentés, és visszatölthető-e, mi áll a hibanaplóban, és melyik bővítmény van telepítve, de kikapcsolva. A kikapcsolt bővítmény fájljai a szerveren maradnak, és a közvetlenül megnyitható fájljai kikapcsolt állapotban is lefuthatnak. Ezekhez hozzáférés kell; hogy belülről mi jelzi, ha egy oldalt már feltörtek, arról külön írás szól.

Mit kezdj azzal, amit találsz

Sürgős, ha a futó verzióra ismert, már javított hiba van, vagy ha egy mentés letölthető. A Patchstack 2026-os jelentése szerint a tömegesen kihasznált WordPress-hibáknál medián öt óra telt el a nyilvánosságra kerüléstől az első tömeges támadásig. A frissítést ilyenkor aznap érdemes feltenni, előtte teljes mentéssel.

Érdemes rendbe tenni a hamarosan lejáró tanúsítványt, a hiányzó biztonsági fejléceket és a szerver kiírt verzióját. Mindhárom beállítás kérdése.

Ráér az elmaradt frissítés, amelyikre nincs ismert hiba. Hónapokig halogatni viszont nem érdemes, mert a több verziót átugró frissítés nagyobb eséllyel tör el valamit.

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

A gondozott oldalaimat naponta én is kívülről nézem: egy felhőben futó ellenőrzés megnézi, lejár-e a tanúsítvány vagy a domain, betölt-e minden kép és szkript, jön-e titkosítatlan elem a lapon, és került-e titkos kulcs a lapok forrásába. Az ellenőrzés szándékosan nem a munkagépemről fut: ha a tárhely tűzfala a gépemet még egyszer kizárná, a felügyelet attól még dolgozik.

Az első felmérésnél egy új oldalon ugyanezt a kívülről látható részt nézem végig: mi fut alatta, és mennyire maradt el, van-e a verzióin ismert hiba, rendben van-e a tanúsítvány, a biztonsági fejlécek és az e-mail-hitelesítés. Rejtett fájlok után nem keresgélek, és jelszót sem próbálgatok. Amit találok, három csoportban írom le: mi sürgős, mit érdemes rendbe tenni, és mi ráér. Hozzáférés nem kell hozzá, és a felmérés ingyenes.

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

← Vissza az Írásokhoz