# Biztonság és felügyelet — kisebb támadási felület, gyorsabb észlelés

URL: https://rootcr.hu/biztonsag-felugyelet/
Frissítve: 2026-08-15

# Biztonság és felügyelet: kisebb támadási felület, gyorsabb észlelés

> **Röviden:** A weboldalak túlnyomó részét nem célzott támadás éri, hanem automata robot, amely egyetlen ismert bővítmény-hibát próbálgat több millió oldalon. 2025-ben 11 334 új sebezhetőséget jelentettek a WordPress-ökoszisztémában, és ezek 91%-a bővítményben volt — nem a rendszermagban. Az egyedi kódú oldalon ez a réteg egyszerűen nincs ott: nincs mit próbálgatni rajta. Emellett a szervert, amelyen az oldalak futnak, saját fejlesztésű, nyelvi modellel támogatott figyelőrendszer őrzi: ötpercenkénti port-őrjárat, csali-fájlok, kétóránkénti teljes rendszer-ellenőrzés, azonnali riasztás. Az alapszintű védelem minden projektben benne van, felár nélkül; a folyamatos felügyelet külön is kérhető.

## 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](/referenciak/pekarunagyker/).

**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](/referenciak/bucipek/).

**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 folyamatos felügyelet: saját fejlesztésű figyelőrendszer

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.

<div class="tldr"><strong>Az alap benne van, a felügyelet külön kérhető.</strong> A fenti védelmi réteg minden projektben alapfelszereltség, felár nélkül. A folyamatos, riasztásos felügyelet — beleértve az oldalad felvételét a percenkénti elérés-ellenőrzésbe és a havi állapotjelentést — önálló szolgáltatásként rendelhető, az oldal és a rendszer méretéhez szabott díjjal. <a href="/#kapcsolat">Kérj rá ajánlatot</a>.</div>

## 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:

1. **Kicsi támadási felület.** Ami nincs telepítve, azon nem lehet betörni.
2. **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.
3. **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](/tudastar/felbehagyott-weboldal-atvetele/).

### 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](/arak/).

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