Az új digitális alvilág: robotokkal vadásznak a jelszavaidra

Amikor a „hackerről” beszélünk, sokak fejében még mindig az a kép él, hogy egy kapucnis fiatal ül egy félhomályos szobában, és naphosszat gépel. A valóság ezzel szemben jóval prózaibb és riasztóbb: ma már automatizált robotok („botok”) végzik a munka nagy részét. Ezek a szoftverek napi huszonnégy órában pásztázzák a webet, és statisztikai valószínűségekre építve keresik a legegyszerűbb hibákat – újrahasznosított jelszavakat, régi adminfelületeket, rosszul beállított szervereket, akár egyetlen árva fájlt, amelyik túl sokat árul el. Az „új digitális alvilág” nem hősies betörésekről szól, hanem ipari méretű, monoton söprésről, ahol egy-egy találat „összeadódik” és komoly pénzzé válik. A támadó oldal költsége minimális: kész listákból dolgoznak, előre ismert útvonalakat próbálnak, és nyílt forrású eszközökkel automatizálnak. A védekező oldal kockázata ezzel szemben teljes: egyetlen elhibázott beállítás, és az e‑mail‑fióktól a webáruházig minden eszközük nyílhat. Azért fontos erről közérthetően beszélni, mert ez a történet nem csak „informatikusokra” tartozik. Ha vállalkozásod van, ha hírlevelet küldesz, ha kampányt futtatsz, akkor nálad vannak ügyféladatok és kulcsok. A botoknak mindegy, hogy kkv vagy multi: a szkenner ugyanazon a listán halad végig. Ez az írás arról szól, hogyan vadásznak a robotok a jelszavakra és a belépési pontokra, mik a kedvenc célpontjaik, és mit tehetsz holnaptól, hogy nálad lepattanjanak. A hangnemem szándékosan határozott: ha csak egy „kicsit” teszünk a védelemért, az tipikusan nem elég. Itt bináris a játék: vagy nincs rés, vagy van.

Mi változott a hackelésben? A kézi betörést ipari automatizmus váltotta

Az elmúlt évtizedben a kiberbűnözés három szinten skálázódott. Először is, megjelent az „automatizált felderítés” mint külön iparág: botok százmillió kérést lőnek ki naponta, és „észrevétlen” információmorzsákból (server header, nyílt sitemap, hibakódok időzítése) szépen felrajzolják, milyen technológián fut a cél. Másodszor, kész „támadási playbookok” terjednek: felhasználónév‑jelszó újrapróbálások (credential stuffing), egyszerű jelszó‑szórás (password spraying), régi pluginok listái, tipikus adminútvonalak. Harmadszor, mindezt összefűzik pénzzé tehető folyamatokká: hozzáférést eladnak a feketepiacon, kriptobányászót tolnak a szerverre, vagy zsaroló kártevőt telepítenek. Nem kell hozzá zseniális hekker – elég a jó lista, a türelem, a sávszélesség, és némi infrastruktúra. Ez a változás üzleti szemmel is kulcsfontosságú. A kár már nem „egyedi műalkotás”, hanem reprodukálható, sorozatban elérhető „termék”, ezért a kockázat eloszlik. A támadó abban érdekelt, hogy minél több félkész, félig nyitott rendszert találjon, ahol akár hetekig bent maradhat. A védekező pedig abban, hogy az első tíz percben „eltöri a botok lábát”: érvénytelenítse a legolcsóbb próbálkozásokat, és a költség‑haszon arányt azonnal eltolja a támadó számára. A lényeg: nem az a kérdés, hogy „téged kinéztek‑e”, hanem az, hogy a te oldalad a tömeges söprésben a „könnyű”, vagy a „túl drága” kategóriába esik‑e. Én azt szeretném elérni, hogy a te rendszered a második legyen.

Hogyan vadásznak a robotok jelszavakra és hozzáférésekre?

A jelszóvadászat ma több, egymást erősítő technikából áll. A legkézenfekvőbb a „password spraying”: a botok néhány tipikus jelszót (például cégnevet kiegészítve évszámmal) kipróbálnak a legnyilvánvalóbb felhasználónevekre („info”, „admin”, „sales”). Ha nagy a felhasználói bázis, ez a módszer meglepően hatásos, mert a legtöbb rendszer nem tiltja le az IP‑t kevés próbálkozás után. A következő lépcső a „credential stuffing”: korábbi szivárgásokból (ahol e‑mail/jelszó párosok milliói keringenek) a botok megpróbálják ugyanazt a jelszót a te szolgáltatásodban is. Ha valaki újrahasznosít, nyitva az ajtó. A harmadik csatorna az „útvonal‑lista”: tipikus végpontok, ahol belépni vagy információt kinyerni lehet (wp-login.php, xmlrpc.php, admin‑panelek, phpinfo‑oldalak). A negyedik a „kihagyott zárolás”: ha nincs IP‑alapú sebességkorlát, ha az űrlap nem védi magát a botok ellen (például nincs WAF vagy rate limiting), akkor a robotok órákon át, észrevétlenül dolgoznak. Végül ott a „be nem zárt fejlesztői ajtó”: tesztfájlok, mentések, fejlesztői konfigurációk (.env, .aws/credentials), amelyekben gyakran ott a kulcs a teljes infrastruktúrához. Dajka Gábor tapasztalata szerint a legtöbb incidens nem összetett trükktől dől el, hanem egyetlen óvatlan döntéstől: admin jog megmaradt egy alvállalkozónál, a jelszópolitika csak papíron létezik, a WordPress ugyan friss, de a pluginok nem. Ezek a logikák ráadásul kombinálhatók: a bot előbb megszerzi a verziószámot és a CMS‑t, majd célzottan küldi az ismert trükköket, és közben lassan, alacsony zajszinten tapogatja a belépőpontokat.

Kedvenc célpontok: rövid, sajtóbarát térkép a „vadászterületekről”

Hogy könnyebb legyen eligazodni, összeszedtem azokat a végpontokat és fájlokat, amelyeket a botok a leggyakrabban próbálnak. A táblázat nem teljes, de üzleti döntéshozónak és tartalomtulajdonosnak is ad fogódzót: ha ezeket az ajtókat becsukod (vagy nem is engeded előlállni), a tömeges támadások nagy részét elvágod.

Az emberi tényező: miért működik még mindig a jelszóvadászat?

Azért, mert az emberek nem gépek. Időnyomás alatt dolgoznak, projektről projektre váltanak, és ésszerűnek tűnik „egy időre” bekapcsolva hagyni valamit, ami aztán ottfelejtődik. A jelszavaknál három pszichológiai minta ismétlődik. Az első az „emlékezni akarás”: kitalálunk egy szabályt (szó + évszám), és ezt rugalmasan variáljuk. A botok pont ezt használják ki: a jelszavak kiszámíthatóak. A második az „újrahasználás kényszere”: ha öt, tíz, húsz rendszerben dolgozunk, szinte lehetetlen mindegyikhez külön, erős jelszót fejben tartani. A harmadik a „fokozatos lazulás”: az elején szigorúak vagyunk, aztán egy kampányhét közepén kikapcsoljuk a kétlépcsős azonosítást, mert „csak most gyorsan”. Dajka Gábor tapasztalata szerint a jó biztonság nem az emberek „megjavításáról” szól, hanem arról, hogy a rendszer jót „kényszerít ki” tőlük: a jelszókezelő be van vezetve és használható; a 2FA alapértelmezetten bekapcsol; az adminfelület nem érhető el a teljes internetről; a kritikus fájlok elérését a webszerver blokkolja. A reputációs dimenziót sem szabad elfelejteni: ha a közönség azt látja, hogy a márka „kamu” jelszó‑reseteket küld vagy gyanús bejelentkezéseket enged, az nemcsak IT‑kérdés. Marketingprobléma is, mert megbillen a bizalom. Itt kapcsolódik össze az online marketing és a pszichológia: a biztonságérzet az ügyfélélmény része. Ha nincs rendben, a konverzió is sérül.

Akcióterv: 10 lépés, amivel holnaptól drágává teszed a támadást

Az alábbi lista nem „célszintű” szabvány, hanem józan, vállalható minimum. A logika egyszerű: vágd le a botok olcsó próbálkozásait, és lakatold le a kulcsfájlokat.

• Vezess be jelszókezelőt a csapatnak (vállalati fiókkal), és tiltsd az újrahasznosítást. Így a „spraying” hatástalan.
• Kapcsold be a 2FA‑t minden külső felülethez (admin, e‑mail, tárhely, felhő). A támadónak plusz faktor kelljen.
• Zárd a /xmlrpc.php‑t és korlátozd a /wp-login.php-t IP‑re vagy sebességre. Ha kell, csak országon belül engedd.
• Rejtsd el az adminfelületet (védett útvonal, VPN, reverse proxy) és adj rá IP‑whitelistet.
• Tedd „láthatatlanná” a kulcsfájlokat: .env, .aws/credentials, backupok ne legyenek a webgyökérben.
• Állíts be WAF‑ot és rate limitinget (kérés/perc), hogy a robotok ne tudjanak „kísérletezni”.
• Kapcsold ki a phpinfo‑s oldalak publikusságát, és töröld a teszt/mentés fájlokat (test.php, *.bak, *.old).
• Frissítsd a CMS‑t és a pluginokat úgy, mint egy üzleti kritikus rendszert: ritmus, felelős, rollback.
• Naplózz és riaszd: sikertelen bejelentkezések, hirtelen forgalomugrás, ismeretlen országok blokkolása.
• Gyakorold az incidenskezelést: ha gond van, tudd, kit hívsz, mit zársz, mit kommunikálsz.

Mi történik, ha már baj van? Krízismenet a valósághoz igazítva

Az incidens kezelése egyszerre technikai és reputációs feladat. Technikailag első a kontain­ment: minden, ami kívülről elérhető, és gyanús aktivitást mutat, megy karanténba (ideiglenes IP‑blokkok, adminfelület lekapcsolása, jelszócsere kényszerítése). Ezzel párhuzamosan „forenszikus mentést” készítesz (fájlok, adatbázis, logok), mert az okok feltárása később könnyebb lesz. Következő a helyreállítás: ismert jó állapot visszaállítása, frissítések, kulcsok cseréje (API, SMTP, felhőszolgáltató), és minden felesleges hozzáférés (volt alvállalkozók, ideiglenes fiókok) törlése. Végül jön a kommunikáció. A krízis itt dől el: ha az ügyfél tőled tudja meg, hogy gyanús belépéseket észleltél, és miket tettél azonnal, nő a bizalom. Ha tőle kérdezed meg késve, miért lát furcsaságokat, akkor repedezik. Magyar piacon különösen fontos a „jó szándék feltételezése”: nem kell pánikot kelteni, de a tényeket és a lépéseket világosan, időrendben kell közölni. Dajka Gábor tapasztalata szerint érdemes előre megírni két‑három sablont: (1) gyanús belépés és jelszócsere kérése, (2) incidens lezárása és tanulságok, (3) adatvédelmi tájékoztató frissítése. A legfontosabb gondolat: a krízist nem lehet „megúszni”, de át lehet vinni úgy, hogy a márka karaktert kapjon tőle. A transzparencia itt nem PR‑fogás, hanem kockázatcsökkentés. Ha pontosan kommunikálsz, kevesebb lesz a feltételezés és az indulat. Ha félrebeszélsz, a közösségi tér tölti ki a vákuumot.

Dajka Gábor marketingszakértő, business coach és befektető szerint

Az „új digitális alvilág” nem romantikus ellenfél, hanem egy automatizált gépsor. A jó hír, hogy a védelem is gépiesíthető. Én nem „hibátlan” rendszereket kérek az ügyfeleimtől, hanem rendet: néhány nem alkuképes szabályt, amit nem lépünk át kampány alatt sem. A biztonság olyan, mint a pénzügyi fegyelem: ha válság idején felfüggeszted, pont akkor üt vissza. Merjünk állást foglalni a saját szervezetünkkel szemben is: nincs újrahasznosított jelszó; nincs publikus phpinfo; nincs admin bárhonnan; és van felelős, aki a frissítésekért és a hozzáférések tisztításáért felel. Lehet ezt túlzásnak érezni, amíg nincs baj. De az első incidensnél mindig kiderül, hogy a legdrágább veszteség nem a kiesett forgalom, hanem a megdőlt bizalom. Én azt vallom: a digitális reputáció nem marketingköltség, hanem tőke. Aki ezzel így bánik, ritkán kerül címlapra rossz hírrel. És ha mégis megtörténik valami, lesz nyelve, ereje és hitele, hogy végigvigye a helyreállítást. Ebben az értelemben a kiberbiztonság nem „IT‑projektsor”, hanem vezetői kultúra. Ahol ez megszületik, ott a robotok nem találnak fogást – legfeljebb zajt csapnak a küszöb alatt.

Szakértő válaszol – GYIK

Meddig elég a jó jelszó, és mikor kell 2FA?

Egyedi, hosszú jelszó ma már a minimum, de önmagában nem elég. A 2FA azt a kockázatot kezeli, hogy a jelszavad máshol már kiszivárgott. Ha a 2FA alapértelmezett minden külső felületen (admin, e‑mail, felhő), a botok 90%-a elhasal az első kanyarban. A 2FA‑t nem kényelmetlenségként kell kezelni, hanem mint a „biztonsági övet”: ha menet közben kényelmetlen, állíts a beállításokon, de ne kapcsold ki.

Mi az az xmlrpc.php és miért szeretik a támadók?

Régi WordPress‑integrációs végpont, amivel automatizáltan lehet műveleteket végezni. A botok azért szeretik, mert tömeges jelszópróbálásra (password spraying) alkalmas. A legtöbb oldalon nincs rá szükség – ezért a legegyszerűbb védelem, ha tiltod vagy IP‑re zárod. Ha valamilyen szolgáltatás még használja, tedd kivétellé, ne maradjon mindenki számára nyitva.

Magyar piacon tényleg ennyire gyakoriak a robotok?

Igen. A botforgalom nem „gazdag” és „szegény” országok szerint válogat; a listák globálisak. A hazai kkv‑k ráadásul sokszor WordPress‑t használnak, amelyhez rengeteg kész támadási lista kering. A gyakorlat azt mutatja, hogy aki a fenti alapokat betartja (2FA, xmlrpc tiltás, kulcsfájlok elrejtése, frissítések), már a zaj nagy részét kiszűri.

Mikor kell szakértőt bevonni, és mikor elég a „házi” karbantartás?

Ha csak alap WordPress‑t futtatsz pár pluginnal, egy fegyelmezett házi karbantartás (frissítések, biztonsági bővítmény, WAF, mentések) sokat ér. Amint fizetés, integrációk, felhő‑kulcsok, vagy ügyféladatok kerülnek képbe, kötelező legalább évente egy külső audit és jogosultság‑átvilágítás. A biztonság nem egyszeri projekt, hanem rutin.

Miért kommunikáljak nyilvánosan egy incidensről?

Mert az ügyfél úgyis észreveszi a következményeket (kényszerített jelszócsere, belépési értesítők), és a bizonytalanság rombolja a bizalmat. A tények rövid, világos közlése és a megtett lépések felsorolása csökkenti a pánikot, gyorsítja a helyreállítást, és hosszú távon erősíti a márkát.

Ajánlott magyar videók/podcastok

Ha még jobban megértenéd, hogyan gondolkodnak a támadók és a védekezés logikáját, ajánlom az alábbi magyar anyagot:

Források

OWASP Top 10 – A05:2021 Security Misconfiguration.

MITRE ATT&CK – T1110 Brute Force. [oai_citation:0‡attack.mitre.org](https://attack.mitre.org/techniques/T1110/)

WordPress – Hardening WordPress (hivatalos ajánlások).

Ha tetszett a cikk, támogasd a blogomat és vedd meg a könyvem.