AI-alapú támadások: mi változik, és mi véd továbbra is

2025 óta bizonyított, hogy a támadók a nyelvi modelleket már nem csupán rendkívül hiteles adathalász e-mailek megírására használják, hanem komolyan veendő támadásokat is végrehajtatnak velük. A weboldalak és szerverek üzemeltetésében ez azonban kevesebbet változtat, mint amit sok szalagcím sugall — egy ponton viszont nagyon is sokat: a tempóban.

Ami bizonyított

2025 novemberében az Anthropic, a Claude nyelvi modell fejlesztője leírta az első dokumentált támadási kampányt, amelyet nagyrészt egy AI hajtott végre. Egy államilag támogatott csoport mintegy 30 szervezetet támadott meg, köztük technológiai cégeket, pénzintézeteket és hatóságokat. Az Anthropic elemzése szerint a munka 80–90 százalékát az AI végezte, az emberek csak alkalmanként hoztak döntéseket. Néhány esetben a behatolás valóban sikerült.¹

Alig egy évvel később ez már nem egyedi eset. Az Anthropic 2026 szeptemberi jelentése órák alatt lezajlott behatolásokat ír le, valamint egyedül dolgozó elkövetőket, akik párhuzamosan több tucat célpontot támadtak. Az egyik eset közvetlenül a weboldalakat érinti: egy elkövető AI segítségével támadást fejlesztett ki egy addig ismeretlen sebezhetőség ellen, amely a WordPress újratelepítését érinti. Ennek révén érvényes hozzáférési adatok nélkül tudott rendszergazdai fiókot létrehozni — legalább négy weboldalon sikerrel. Emellett az egyik áldozat biztonsági mentéseit úgy manipulálta, hogy egy visszaállítás azonnal újra hozzáférést adott volna neki a rendszerhez.²

A Google Threat Intelligence Group 2026 májusában talált először olyan zero-day támadókódot, amelyet értékelése szerint AI segítségével fejlesztettek ki: a kétfaktoros bejelentkezés megkerülését egy elterjedt, nyílt forráskódú, böngészőből használható rendszerfelügyeleti eszközben, tömeges támadásra szánva. A támadókódot még a tervezési szakaszban elfogták, mielőtt bevetették volna. Amit a Google ebben a két jelentésében leír, az részlépésekre kiterjedő autonómia — AI-ügynökök, amelyek önállóan találnak sebezhetőségeket, és kártevők, amelyek egy már átvett eszközön önállóan dolgoznak tovább —, nem pedig egy teljes támadás, amelyet már senki sem irányít.^{3, 4}

Ugyanez a képesség azonban a védekezők rendelkezésére is áll. A Google Big Sleep nevű AI-ügynöke 2025-ben kritikus hibát talált az SQLite adatbázisban, amelyről a Google szerint addig csak a támadók tudtak. Ez azonban csak annak segít, aki a javítást utána telepíti is.⁵

Ami változik: tempó és mennyiség

Egy támadás sok apró lépésből áll: szolgáltatások felderítése, verziók azonosítása, megfelelő sebezhetőség keresése, a támadókód hozzáigazítása, a válaszok kiértékelése, továbblépés. Ezek többségéhez eddig tapasztalt emberekre és sok időre volt szükség. Egy nyelvi modell sokat közülük másodpercek alatt elvégez, éjjel-nappal és egyszerre sok célpont ellen.

Ez a legvilágosabban a sebezhetőség nyilvánosságra kerülése és kihasználása között eltelt időn látszik. A Mandiant, a Google incidenskezelési részlege erre 2018-ban és 2019-ben átlagosan 63 napot mért, 2023-ban már csak ötöt. Az M-Trends 2026 jelentésben a becsült átlag mínusz hét nap: a kihasználás rendszeresen még azelőtt megtörténik, hogy egyáltalán létezne javítás. A folyamat az AI előtt kezdődött, de az AI felgyorsítja.^{6, 7}

A német Szövetségi Információbiztonsági Hivatal (Bundesamt für Sicherheit in der Informationstechnik, BSI) 2026 júniusában rögzítette, hogy AI segítségével percek vagy órák alatt levezethető egy közzétett javításból (patch), hogyan kell kinéznie egy támadásnak. Következtetése: a szervezeteknek perceken, legfeljebb néhány órán belül át kell tudniuk tekinteni és értékelni a sebezhetőségeket, és szükség esetén telepíteni a javításokat. A hivatal szerint néhány nap nem megfelelő reakcióidő.⁸

A második változás a célpontok kiválasztását érinti. Ha egy támadás kevesebb munkával jár, olyan célpontok is megérik, amelyek eddig túl kicsik voltak — az Anthropic pontosan ezt az eltolódást írja le. Az a feltevés, hogy egy kis weboldal nem érdekli a támadókat, mindig is merész volt. Ma egyszerűen téves: az automatizált támadások nem feltétlenül a jelentőség, hanem az elérhetőség alapján választanak célpontot.²

Ami nem változik: min múlik egy támadás sikere

Figyelemre méltó, mi hiányzik ezekből a jelentésekből: az új támadási technikák. Az Anthropic kifejezetten azt írja, hogy a leírt műveletek egyike sem olyan technikán alapult, amelyet a védekezők még soha nem láttak. Ezek a jól ismert behatolási pontok — ellopott hozzáférési adatok, frissítetlen eszközök a hálózat peremén, nyíltan elérhető szolgáltatások, becsempészett adatbáziskód (SQL injection), adathalászat. A Mandiant 2025-re vonatkozóan ugyanerre a következtetésre jut: a sikeres betörések túlnyomó többsége továbbra is alapvető emberi és rendszerszintű hibákra vezethető vissza, nem magára az AI-ra.^{2, 7}

Weboldalak esetében különösen sokatmondó egy szám: a VulnCheck szerint 2026 első félévében a tartalomkezelő rendszerek tették ki mindazon sebezhetőségek egyharmadát, amelyeket a VulnCheck újonnan felvett az aktívan kihasznált sebezhetőségek listájára. Minden telepített, de nem használt bővítmény növeli a támadási felületet anélkül, hogy bármit hozzátenne.⁹

Ebből következik e cikk fő üzenete: az AI-alapú támadások ellen nem feltétlenül van szükség újfajta védelemre. Az segít, ami mindig is segített. A biztonságot azonban ma újra kell gondolnunk: teljes körűen, automatizáltan és következetes felügyelet mellett.

Rétegek csodafegyver helyett

Sajnos ezen a ponton nem tudunk egyetlen olyan intézkedést megnevezni, amelynek bevezetése után minden probléma megoldódik és minden rendszer biztonságos. Ezért rétegmodellre építünk: minden réteg felfogja a támadások egy részét, és mindegyik abból indul ki, hogy az előtte lévő réteg kudarcot vallott. Így üzemeltetjük az ügyfeleink számára hosztolt weboldalakat és alkalmazásokat, és a sajátjainkat is. A következő szakaszokban részletesen bemutatjuk ezeket a rétegeket.

A hálózat pereme („Edge”): webalkalmazás-tűzfal és CrowdSec

Bármely nyilvánosan elérhető webszolgáltatásunkhoz érkező kérés először egy webalkalmazás-tűzfalon (WAF) halad át: ez a ModSecurity az OWASP Core Rule Settel, egy (globális közösség által) közösen karbantartott szabálygyűjteménnyel, amely a szokásos támadási minták ellen véd — becsempészett adatbáziskód, idegen szkriptek, az engedélyezett területen kívüli fájlok elérése. A szabályok mintákat ismernek fel, nem konkrétan az egyes sebezhetőségeket. Ezért azoknak a támadásoknak egy részét is feltartóztatják, amelyek olyan sebezhetőségek ellen irányulnak, amelyekre még nincs javítás. Így olyan időt nyerünk, amelyről nem is tudtuk, hogy szükségünk lesz rá.

Emellett a CrowdSec kiértékeli a naplókat, és egyes kérések helyett viselkedést ismer fel: ki keres módszeresen adminisztrációs felületeket, ki próbálgat jelszavakat, vagy ki pásztáz szervereket ismert sebezhetőségek után kutatva. Az ilyen címeket letiltja, mielőtt elérnék a weboldalt. Ehhez jön még a hálózat: aki CrowdSecet üzemeltet, megosztja az észlelt támadásokat, és cserébe egy közösen karbantartott tiltólistát kap. Így egy cím, amely máshol támad, már azelőtt le lehet tiltva nálunk, hogy az első kérését elküldené.

Az automatizálás ellen ez különösen jól működik, mert az automatizálás nyomokat hagy. Aki rövid idő alatt több ezer kérést küld, mintázatot hoz létre — függetlenül attól, hogy mögötte egy szkriptet futtató ember vagy egy nyelvi modell áll.

A szerveren: csak ami szükséges

Szervereinkre SSH-n nem lehet bejelentkezni jelszóval, „root” felhasználóként vagy bármilyen tetszőleges felhasználóval. Belépni csak kriptográfiai kulccsal lehet, és csak az a néhány, előre rögzített felhasználó teheti meg, akinek egyáltalán engedélyezett a bejelentkezés; azokat a címeket, amelyek máshol támadások miatt tűntek fel, a tűzfal már ezt megelőzően eldobja. A tűzfal alapértelmezésként egyáltalán semmit nem enged be: csak az van nyitva, amire valóban szükség van. A hozzáféréseket központilag kezeljük, és aki már nem tartozik a csapathoz, minden szerveren elveszíti azokat. Mindezt infrastruktúra kódként (Infrastructure as Code, IaC) hozzuk létre, és minden szerveren egyformán állítjuk be, soha nem kézzel.

A jelszavak végigpróbálgatása ellen — ez az egyik első feladat, amelyet gépre lehet bízni — tehát nem egy jobb jelszó segít, hanem az, ha egyáltalán nincs jelszó.

A konténerben: a lehető legkevesebb jogosultság

Maguk az alkalmazások egymástól elszigetelten, konténerekben futnak, és mindegyik csak azokkal a jogosultságokkal rendelkezik, amelyekre a működéséhez szüksége van: a fájlrendszer írásvédett, kivéve azokat a könyvtárakat, amelyekben adatoknak kell lenniük. A konténer elvből soha nem fut root-jogosultsággal, a memóriahasználatának rögzített felső határa van, és saját hálózatban működik, elkülönítve más ügyfelek konténereitől. Aki kihasznál egy sebezhetőséget az alkalmazásban, nem tudja felülírni a programkódot, és arra sincs közvetlen lehetősége, hogy más ügyfelek konténereivel kommunikáljon, és azokat kompromittálja.

Ugyanilyen fontos, mi nincs eleve a konténerben. Azoknak az eszközöknek, amelyekre az építéshez szükség van, az üzemeltetéshez viszont nem, ott nincs helyük. Pusztán a csomagkezelő és segédprogramjainak eltávolítása saját weboldalunk konténerképéből 2026 szeptemberében 38 kritikus és magas súlyosságú találatot szüntetett meg a sebezhetőségi szkennerben. Arról nem is beszélve, hogy a hiányzó eszközök megnehezítik, sőt akár meg is akadályozzák a kompromittálási kísérleteket. Ami nem érhető el, azt ugyanis nem lehet kihasználni.

Üzem közben: tudni, nem feltételezni

Egy szerver nem attól biztonságos, hogy a beállításakor biztonságos volt. Minden éjjel egy szkenner (Trivy) ellenőrzi az összes szerver telepített csomagjait és az összes futó konténerképet ismert sebezhetőségek szempontjából. A szerverek biztonsági frissítései naponta automatikusan települnek; ha valamelyik egy futásnál tovább függőben marad, a felügyeleti rendszer jelez.

Így 2026 szeptemberében saját weboldalunk konténerképét 5 kritikus és 51 magas súlyosságú sebezhetőségről nullára csökkentettük — mérve, nem becsülve.

Egy időablak azonban így is marad: egy sebezhetőség nyilvánosságra kerülése és a következő frissítés között, sőt még inkább azelőtt. Ezt semmilyen frissítési folyamat nem tudja teljesen bezárni. Pontosan erre az időablakra való a többi réteg — a WAF, amely a sebezhetőség ismerete nélkül is felismeri a támadási mintákat, és a szűkre szabott jogosultságok, amelyek korlátozzák, mekkora kárt okozhat egy sikeres támadás.

Vészhelyzetre: biztonsági mentések, amelyeket a támadó nem törölhet

Aki átvette az irányítást egy szerver felett, következő lépésként gyakran a biztonsági mentéseket próbálja törölni vagy módosítani; a fenti WordPress-eset megmutatja, hogyan néz ez ki. Biztonsági mentéseink titkosítottak, egy másik szerveren vannak, és „append-only” módban íródnak: a mentett szerver új mentéseket adhat hozzá, de a meglévőket nem törölheti és nem írhatja felül. A korábbi állapotok így akkor is megmaradnak, ha egy támadó teljesen az irányítása alá vonta ezt a szervert.

Ez önmagában nem elég: azt is tudni kell, melyik állapot tiszta. Ezért az Edge, a szerverek és az alkalmazások naplói egy külön szerveren futnak össze; ezekből kiderül, mióta volt jelen valaki a rendszerben. A visszaállítást pedig be is gyakoroltuk. Azok a mentések, amelyeket soha nem validálnak igazán teljes körűen, inkább csak reménykedést jelentenek, mint valódi biztosítékot.

Védelem, amely ártatlanokat sújt

Ezen rétegek mindegyike valódi látogatókat is érinthet. 2026 augusztusában saját weboldalunkon az Edge-en működő védelmi réteg egyes látogatókat egy-egy teljes napra kizárt. Az ok egyetlen hiányzó fájl volt: hiányzott a böngészőfülön megjelenő kis ikon (favicon), ezért minden oldalbetöltés hibaüzenetet, azaz 404-es választ eredményezett, egy előre beállított szabály pedig egy adott időtartamon belül elegendő számú 404-es hibát támadásnak minősített. Ezt a szabályt azóta úgy módosítottuk, hogy egy-egy alkalmi 404-es hiba már nem vezet azonnal egy feddhetetlen látogató letiltásához.

Ugyanazon a héten az első kiértékelés megmutatta, kik is hívják le valójában az általunk üzemeltetett weboldalakat. Egy alapértelmezésként mellékelt tiltólista gyakorlatilag az AI-szolgáltatások összes lekérését elutasította — egyetlen nap alatt nagyjából 370-et olyan kliensektől, amelyek magukat egy ember kérésére eljáró ChatGPT-nek adták ki: nem tartalmakat gyűjtő crawlerről volt szó, hanem egy szolgáltatásról, amely egy válaszhoz el akarta olvasni valamelyik oldalt. Egy olyan cég számára, amely ügyfeleit láthatóvá akarja tenni az AI-válaszokban, ez egyértelműen rossz védelem volt. Azóta weboldalanként magunk döntjük el, hogy az AI-szolgáltatások olvashatják-e az adott oldalt: egyáltalán nem, csak ember kérésére, vagy teljes körűen (crawlerekkel együtt).

Egyik eset sem mellékes. Az a védelem, amely valódi látogatókat zár ki, kontraproduktív, és előbb-utóbb teljesen kikapcsolják, hogy ne veszítsenek el több ügyfelet. Nem ez a cél. Ha pedig valaki mindent letilt, ami gépnek tűnik, az nem biztonsági stratégia, hanem döntés a saját láthatóság és megtalálhatóság ellen.

Amit Ön maga is ellenőrizhet

Hogy saját rendszerei mennyire felkészültek, azt a következő kérdésekkel mérheti fel. Minden olyan kérdés, amelyre nem tud azonnal vagy igazán pontosan válaszolni, arra utal, hogy teendője van.

• Mi érhető el kívülről? A főként belső használatú adminisztrációs felületek, az adatbázisok és az egyéb jelszavas bejelentkezések nem valók nyíltan az internetre.
• Miből ismeri fel, hogy valamelyik rendszerében biztonsági rés van?
• Milyen gyorsan kerül fel ténylegesen egy biztonsági frissítés a rendszereire — és honnan tudja, hogy valóban felkerült?
• Áll-e az alkalmazás előtt valami, ami felismeri a támadási mintákat, és közbelép, mielőtt a támadás magát az alkalmazást elérné?
• Milyen jogosultságokkal fut az alkalmazás, és valóban szüksége van-e ezekre?
• Van-e olyan biztonsági mentés, amelyet még az sem tud törölni, aki teljes jogosultsággal rendelkezik a szerveren? Mikor állítottak vissza belőle utoljára?
• Ki kap riasztást, ha valami gyanús — és ki dönti el, mi történjen ezután?

Az AI gyorsabbá és olcsóbbá tette a támadásokat, de nem feltartóztathatatlanná. Ami véd ellenük, ugyanaz, mint korábban. Csak teljes körűen kell megvalósítani és felügyelni.