Biztonság és felügyelet: kisebb támadási felület, gyorsabb észlelés
Miért nehezebb célpont az egyedi kódú oldal?
Mert a támadás üzlet, és az üzlethez méret kell. Egy támadó nem a te cégedet keresi: keres egy hibát egy bővítményben, amit néhány százezer oldal használ, ír rá egy szkriptet, és végigfuttatja az interneten. A megtérülést a telepítések száma adja, nem a te forgalmad.
Ezért a kockázat nem attól függ, mennyire vagy „érdekes", hanem attól, mekkora idegen kódfelületet futtatsz. A számok ezt mutatják:
| Mit mér | Érték | Forrás |
|---|---|---|
| Új sebezhetőség a WordPress-ökoszisztémában, 2025 | 11 334 db (+42% egy év alatt) | Patchstack, State of WordPress Security in 2026 |
| Ebből bővítményben | 91% | ugyanott |
| Ebből sablonban (téma) | 9% | ugyanott |
| A rendszermagban | elenyésző, néhány darab | ugyanott |
| Súlyos hibák, amelyeket 24 órán belül támadni kezdtek | 45% (az első kihasználásig eltelt medián idő: ~5 óra) | ugyanott |
| Amit a szokásos hoszting- és WAF-védelem ténylegesen blokkolt | az ismert WordPress-támadások 12%-a | ugyanott |
A tanulság nem az, hogy a WordPress rossz. A tanulság az, hogy a sebezhetőségek túlnyomó része a ráaggatott kiegészítőkből jön, és a védelem, amit mellé szokás venni, a támadások töredékét fogja meg. Ha a bővítmény-réteg nincs ott, ez a teljes támadási osztály kiesik.
Egy egyedi oldalon a futó kód az, amit én írtam és amit el tudok magyarázni soronként. Nincs harminc idegen csomag, amelyik magától frissül, és nincs olyan funkció, amiről nem tudom, mit csinál a háttérben.
A webshop miért kiemelt célpont?
Mert ott pénz mozog, és ott van a legtöbb egyforma telepítés. A WooCommerce a WordPress-alapú webshopok mintegy 93,7%-át adja — vagyis egyetlen működő támadás azonnal több millió boltra érvényes. A bankkártya-lopó (skimmer) kampányok ezért célozzák évek óta ugyanazt a két rendszert: a WooCommerce-t és a Magentót, mert ott van a legtöbb aktív bolt.
Ezek a támadások nem törik le az oldalt. Épp ellenkezőleg: a bolt tovább működik, csak a fizetési oldalon fut egy plusz szkript, amely a kártyaadatot elküldi. Az ilyen fertőzés hónapokig észrevétlen marad — nem a látogató veszi észre, hanem a bank.
Egyedi webshopnál a fizetés a bankszolgáltató saját felületén vagy szerveroldali hívással történik, a kártyaadat nem az én kódomon megy át, és nincs olyan bővítmény-felület, amelybe idegen szkriptet lehetne beültetni. Ezen felül a tartalombiztonsági szabály (Content-Security-Policy) böngésző szinten tiltja, hogy idegen forrásból bármilyen szkript lefusson.
Mi épül be minden projektbe, felár nélkül?
Minimalizált támadási felület. Nincs harmadik féltől származó bővítmény-réteg a kiszolgálón. A publikus webgyökérben csak az áll, aminek látszania kell; a forrás, a szolgáltatás-kód és a titkok azon kívül vannak.
Védett űrlapok. Eredet-ellenőrzés, rejtett csapda-mező, méretkorlát, ember-ellenőrzés és IP-alapú korlátozás — szerveroldali kód, meghatározott sorrendben. Élő példa és a réteg-sorrend indoklása: pekarunagyker.hu esettanulmány.
Fájlfeltöltés valódi ellenőrzéssel. A feltöltött állomány típusát a tartalma alapján állapítja meg a rendszer, nem a fájlnév kiterjesztéséből; makrót és futtatható tartalmat keres, majd vírusellenőrzés fut. Élő példa: bucipek.hu esettanulmány.
Böngésző-szintű védelmi fejlécek. Tartalombiztonsági szabály (CSP), X-Frame-Options: DENY a kattintás-eltérítés ellen, nosniff, szigorított hivatkozó-szabály, kikapcsolt kamera/mikrofon/helyadat-hozzáférés, és HSTS preload listával — vagyis a böngésző soha nem próbál titkosítatlanul csatlakozni. Ezeket nem kell elhinned: nyisd meg a fejlesztői eszközök hálózat fülét ezen az oldalon.
Jogosultsági elkülönítés a kiszolgálón. Az ajánlatkérő szolgáltatás saját, ideiglenes felhasználóval fut, írásvédett rendszerfájlokkal, elzárt /home könyvtárral, minden képességtől (capability) megfosztva, saját memóriakorláttal. Ha bármi történne vele, nem tud kilépni a saját dobozából.
Titkok a kódon kívül. Az SMTP-jelszó, az API-kulcsok és a többi érzékeny adat környezeti fájlban van, jogosultság-védetten. A forráskódban nincs jelszó — soha, semmilyen körülmények között.
Napi mentés, bizonyított visszaállítással. A mentés naponta fut, titkosítva, verziózva. A mentés attól mentés, hogy vissza is lehet állítani belőle: ezt nem feltételezem, hanem időnként ténylegesen visszaállítok egy fájlt, és megnézem, hogy azonos-e.
Zárt tűzfal. Alapértelmezésben minden bejövő kapcsolat tiltott; csak a kifejezetten engedélyezett szolgáltatások érhetők el kívülről. A CDN, a webes tűzfal és a levelezés hitelesítésének beállítása külön is kérhető: Cloudflare, tűzfal és e-mail védelem.
A folyamatos felügyelet: saját fejlesztésű figyelőrendszer
A folyamatos felügyelet külön is kérhető, akkor is, ha nem én építettem az oldalt. A szerverfigyelést nem dobozos szolgáltatásból veszem. Saját rendszert írtam rá, amely nyelvi modellel értelmezi a gép állapotát, és azonnal üzen, ha valami eltér a megszokottól. Ez fut jelenleg is, folyamatosan:
| Mit figyel | Milyen gyakran | Mit tesz, ha baj van |
|---|---|---|
| Kívülről elérhető portok, deklarált engedélylistához mérve | 5 percenként | Riasztás, és addig ismétli, amíg a port nyitva van — nem felejti el |
| Teljes rendszerállapot: terhelés, memória, lemez, szolgáltatások, bejelentkezések, tűzfal | 2 óránként | Riasztás a konkrét eltéréssel és a javasolt paranccsal |
| Csali-fájlok (canary): jelszófájlnak látszó, valójában csapda állományok | folyamatosan, fájlrendszer-eseményre | Bárki hozzáér vagy megnyitja: azonnali riasztás, mert legitim ok nincs rá |
| Figyelt weboldalak elérése és a háttérszolgáltatás állapota | percenként | Riasztás a hibakóddal, ha az oldal nem válaszol vagy a háttér elszállt |
| Tanúsítvány lejárata | ütemezetten | Riasztás jóval a lejárat előtt |
| Új, ismeretlen folyamat és portnyitás az alapállapothoz képest | folyamatosan | Riasztás, és a rendszer megnevezi, melyik folyamat nyitotta |
A riasztás nem egy irányítópultba érkezik, amit senki nem néz: azonnal a telefonomra megy, és a rendszer emberi nyelven kérdezhető is a gép állapotáról. A naplózás rotációval fut, a rendszernek van vészleállítója, és a saját működését is jelenti.
Ezen felül minden általam épített oldalon fut a projekt saját ellenőrzése is: a rootcr.hu esetében például tízpercenként ellenőrzöm, hogy az ajánlatkérő értesítője ténylegesen kiment-e — ha nem, arról riasztás jön, nem az érdeklődő elmaradó válasza deríti ki.
Amit nem ígérek
Nincs feltörhetetlen rendszer, és aki ilyet ígér, az vagy nem érti, vagy nem mondja el, mit ad el. Három dolgot lehet komolyan vállalni, és én ezeket vállalom:
- Kicsi támadási felület. Ami nincs telepítve, azon nem lehet betörni.
- Gyors észlelés. A kár nagysága általában nem attól függ, bejutottak-e, hanem attól, mennyi ideig voltak bent észrevétlenül.
- Visszaállíthatóság. Napi, titkosított mentés, amelyből tényleg visszaáll a rendszer — mert ki lett próbálva.
Gyakori kérdések
Ez azt jelenti, hogy az egyedi oldalt nem lehet feltörni?
Nem. Azt jelenti, hogy az automata tömegtámadások — amelyek a támadások túlnyomó részét adják — nem találnak rajta fogást, mert nincs rajta az a bővítmény-réteg, amit keresnek. A célzott, kézi támadás ellen a kicsi felület, a szigorú jogosultságok, a gyors észlelés és a működő mentés véd.
Meglévő WordPress oldalamat is figyeled?
A felügyelet önmagában elvégezhető rá, de legyünk őszinték: a figyelés nem javítja meg a rendszert, csak korábban szól. Ha az oldal bővítményekkel van életben tartva, előbb azt kell megnézni, mennyi belőle a foltozás és mennyi az újraépítés — erről külön írás: félbehagyott weboldal átvétele.
Mennyibe kerül a felügyelet?
A díj a figyelt rendszer méretétől függ (hány oldal, hány szolgáltatás, kell-e havi jelentés), ezért ajánlat alapján megy. Amit fixen mondhatok: a projektbe épített védelem — űrlapvédelem, fájlellenőrzés, védelmi fejlécek, jogosultsági elkülönítés, mentés — nem külön tétel, benne van az árakban. Webshopnál a felügyelet a webshop üzemeltetés része, méret szerinti havidíjjal.
Mi történik, ha mégis baj van?
Először elzárom a bejutási utat, utána állítom vissza a szolgáltatást — nem fordítva, mert a visszaállított rendszert azonnal újra megfertőznék ugyanazon a lyukon. Utána jön a napló átnézése: mikor, honnan, mit értek el. A végén írásos összefoglaló, benne azzal is, mi tette lehetővé.
Hol tárolod a mentéseket?
Titkosítva, a futó rendszertől elkülönítve, verziózva — így a régebbi állapotok is elérhetők, nem csak a tegnapi. A visszaállítás bizonyítottan működik: nem elméletben, hanem kipróbálva.
A biztonság mennyivel drágítja a projektet?
Semmivel. Ami itt fel van sorolva, az az építés része, nem opció. Egy sablonrendszernél ugyanezért bővítményeket kellene venni és karbantartani — ott ez az összeg havi díjként jelentkezik, és a fentiek szerint a támadások töredékét fogja meg.