„Kérem, hogy ilyen felelőtlenséget NE csináljon többet!" — egy incidens tanulságai

Benkó János · 2026. augusztus 30.

Nem törték fel. Nem volt sebezhető bővítmény, elavult PHP vagy gyenge jelszó. Egyszerűen bementek az ajtón, a kulccsal — amit a tulajdonos, anélkül hogy tudott volna róla, kitett a bejárat mellé egy táblára. Két nappal később adathalász oldal futott a domainen, három héttel később napi 21 millió bot kereste, egy évvel később pedig a VirusTotal még mindig „phishing"-nek jelöli. A domain a végén elveszett. Ez a cikk arról szól, hogyan lehet ide eljutni — és pontról pontra arról, hogyan nem.

A történet megtörtént. A szereplők és a szolgáltató nevét megváltoztattuk, a domaint a cikkben fiktivdomain.hu-nak hívjuk, a képeken kitakartuk. Az események, a levelek és a számok viszont pontosan ilyenek voltak.

Vasárnap reggel, 10:40

Márton tapasztalt webfejlesztő. Nem kezdő és nem hanyag: húsz éve épít oldalakat, tucatnyi domaint kezel, és ha valakiről elmondható, hogy „odafigyel az adataira", akkor róla igen.

Egy júniusi vasárnap reggel érkezett a levél. A feladó Bálint, a Fiktív Hoszting Kft. üzemeltetője — egy budapesti kisvállalkozás, ahol Márton néhány kisebb domainje évek óta lakott. Az a fajta szolgáltató, ahol még ember válaszol, hétvégén is.

Tisztelt Vass Márton!

Egy problémával kapcsolatban keresem a fiktivdomain.hu oldallal kapcsolatban: ma bejelentést kaptunk, hogy adathalász oldal kerül fel a domain mögé. Megnézve látszik, hogy június 6-án felkerült néhány hacker fájl, és módosították az index.php-t is. A szerver logjaiból látszik, hogy a [email protected] FTP-felhasználóval léptek be a tárhelyre.

Mentésből most helyreállítottuk a fájlokat, töröltük a kártékonyakat, DE feltűnt, hogy a fiktivdomain.hu/html mappában, a .vscode mappában, az sftp.json fájlban ott volt az internetre „kiplakátolva" az FTP-re bejelentkezéshez a felhasználónév, jelszó, MINDEN!

Kérem, hogy ilyen felelőtlenséget NE csináljon többet!

Ezt a mondatot Márton azóta is fejből tudja.

Hogyan kerül egy FTP-jelszó a nyílt internetre?

Márton évekig a Sublime Text-et használta. Jó szerkesztő, megszokta, a teljes munkafolyamata ráépült. Aztán jött egy új főverzió, és a frissítés ára már nem érte meg — átállt VS Code-ra.

Ez a mondat a történet fordulópontja, pedig teljesen ártalmatlanul hangzik.

A Sublime SFTP-bővítménye a projektmappába teszi a beállításait: sftp-config.json. Ebben ott a host, a port, a felhasználónév és — mert így kényelmes — a jelszó, tisztán olvashatóan. A VS Code SFTP-bővítménye ugyanezt csinálja, csak .vscode/sftp.json néven. Az átálláskor a beállítás átkerült: ugyanaz a szerver, ugyanaz a user, ugyanaz a jelszó, új fájlnévvel, egy rejtett mappában.

És itt jött a csapda, amire a legtöbb fejlesztő soha nem gondol:

Ez a klasszikus, „FTP-korszakos" munkamódszer: van egy helyi mappa, ami egy az egyben tükrözi a szerveren lévő webgyökeret, és a szerkesztő mentéskor felmásolja a változást. Kényelmes. Húsz évig mindenki így dolgozott. Csakhogy ha egyetlenegyszer lefut egy „teljes mappa szinkronizálása" — vagy egy „upload folder", vagy bármi, ami nem egyetlen fájlt tol fel —, akkor a szerkesztő nem tesz különbséget a te tartalmad és a saját konfigmappája között. Feltölti a .vscode-ot is. Benne a jelszavaddal.

Onnantól kezdve a jelszó egy publikusan letölthető URL volt:

https://fiktivdomain.hu/.vscode/sftp.json

Nem kellett hozzá hackelés. Egy curl elég volt.

Június 6., hajnal — mi történt valójában a szerveren

A logokból és a helyreállított fájlokból elég pontosan összeáll a kép. Ez a rész technikai, de érdemes végigolvasni, mert ez a normál forgatókönyv — nem valami egzotikus, célzott támadás.

1. Bejelentkezés. Egy külföldi IP-ről FTP-n beléptek a admin felhasználóval. Nem próbálkozás, nem brute force: első nekifutásra, helyes jelszóval. A logban ez semmiben nem különbözik attól, mintha a tulajdonos lépett volna be. Ezért nem is riaszt semmi — nincs mire riasztani.
2. Az index.php módosítása. Nem törölték az oldalt: az feltűnő lenne. Beszúrtak az elejére egy rövid kódrészletet, ami látogatótól függően viselkedik — normál böngészőnek az eredeti oldalt adja, a kampány célközönségének viszont továbbdob. Így a tulajdonos hetekig nem vesz észre semmit, mert ő a saját oldalát látja.
3. A tartalom feltöltése. Néhány mappa, véletlenszerű nevekkel, mélyre ásva a könyvtárszerkezetben — jellemzően valami uploads/2019/07/.cache/ mélységben. Bennük egy adathalász készlet (phishing kit): pixelre pontos másolata egy ismert bank vagy futárszolgálat belépőoldalának; egy POST-ot fogadó szkript, ami a beírt adatokat továbbküldi (általában egy Telegram-botnak vagy gyűjtő e-mail-címre); és egy „antibot" szűrő, ami a biztonsági cégek IP-tartományait és böngésző-azonosítóit igyekszik kitiltani, hogy a kit minél tovább életben maradjon.
4. A tartalék bejáratok. Ezt a lépést hagyják ki a legtöbben a takarításnál. Egy webshell — gyakran egyetlen, ártalmatlannak látszó sor egy létező fájl közepén —, esetleg egy plusz FTP-fiók, néha egy időzített feladat. A jelszócsere ezeket nem zárja ki. Ezért nem elég a jelszót cserélni: az egész tárhelyet fertőzöttnek kell tekinteni, amíg az ellenkezője be nem bizonyosodik.
5. A domain „élesítése". Amikor a kit készen áll, a domain bekerül a kampányba. És innentől nem a saját történetét éli.

Amikor megérkezett a 21 millió

Néhány héttel később jött a második levél Budapestről. Ez már nem kérés volt, hanem közlés:

Kedves Márton!

A mai napon hajnaltól kezdve brutális látogatottság van az oldal ellen. Ez még a múltkori FTP-belépéshez köthető, mert folyamatosan százezer számra vannak hívások! Mivel ez most már kritikus méreteket ölt, mert a szerver túlterhelődik, így a domain DNS-ében a domain IP-címét „lekapcsoltuk" ideiglenesen (1-2 napra legalább). Nem tudunk más megoldást, muszáj volt ezt meglépni!

Ha ez nagy gond Önnek, akkor kérem, a domain weboldalát vigye át másik szolgáltatóhoz, jelezve feléjük, hogy időnként brutális látogatottság érkezik a domainre. Sokan nem fognak örülni neki, sőt, nem fognak ilyen oldalnak nyilván tárhelyet adni!

Az utolsó mondattól fagyott meg benne a vér. Nem azért, mert durva — hanem mert igaz volt.

A domain bekerült a Cloudflare mögé, bekapcsolt az „I'm Under Attack" mód, és letiltásra került minden forgalom Magyarországon kívülről. Ezt látta a Cloudflare huszonnégy óra alatt:

Számoljunk utána: 21 170 000 kérés / 86 400 másodperc = átlagosan 245 kérés minden egyes másodpercben, éjjel-nappal. Csúcsban ennek a többszöröse. Egy megosztott tárhelyen, ahol rajta kívül még száz ügyfél oldala fut, ez nem „nagy látogatottság". Ez az áramszünet.

De honnan jön 21 millió kérés egy jelentéktelen kis domainre?

Ez a kérdés hetekig nem hagyta nyugodni, mert nem stimmelt a nagyságrend. Az oldal, amiről beszélünk, jó napokon száz látogatót kapott. Hogyan lesz ebből huszonegymillió?

A válasz nem egyetlen okra vezethető vissza. Több réteg rakódott egymásra, és mindegyik önmagában is sokszorozó hatású. Ez a legvalószínűbb rekonstrukció:

1. A kampány mérete (a magvetés)

Egy adathalász kampány nem száz e-mailt jelent. Milliókat. SMS-ben, e-mailben, néha hirdetésben. Minden egyes üzenetben ott a link — erre a domainre. Ha egy közepes kampány két-hárommillió üzenetet küld ki, és ebből csak minden huszadik címzett kattint, az százezres nagyságrendű valódi kattintás. Ez már önmagában megfeküdné a tárhelyet. De ez még csak a bemelegítés.

2. A biztonsági szkennerek (a láthatatlan sokszorozó)

Ez az a réteg, amire szinte senki nem gondol, pedig a forgalom nagy részét valószínűleg ez adta.

Amikor egy adathalász link kimegy hárommillió címre, akkor minden egyes címzett védelmi rendszere lekéri azt az URL-t. Nem a felhasználó: a rendszer. A vállalati levelezőkapu megnyitja és lefuttatja egy homokozóban. A víruskereső ellenőrzi a reputációját. A böngésző biztonsági szolgáltatása kikéri. A tiltólista-szolgáltatók crawlerei újramintavételeznek. Az e-mail-biztonsági termékek „kattintáskori védelme" minden egyes kattintáskor újra meglátogatja. És mindezt nem egyszer teszik meg, hanem ismételten, hogy lássák, megszűnt-e a fenyegetés.

Egy címzett = akár tíz-húsz gépi lekérés, több napra elosztva. Szorozd fel hárommillióval.

3. A ragadozók (aki a másik zsákmányát keresi)

Amikor egy domain felkerül a nyilvános fenyegetéslistákra, az nemcsak a jófiúknak szól. Léteznek csoportok, akiknek ez a bevásárlólista: végigmennek a friss adathalász domaineken, és keresik a más által feltelepített webshelleket. Egy már feltört, már működő tárhely készen kapott infrastruktúra — nem kell hozzá jelszó, ha valaki más már hagyott ott egy hátsó ajtót. Ezek a botok nem egy URL-t kérnek le, hanem több ezer útvonalat próbálnak végig minden domainen, újra és újra.

4. A visszhang (amit már nem lehet leállítani)

És itt a legfájóbb rész: a takarítás után a forgalom nem áll le.

A link ott maradt hárommillió postafiókban. Ott maradt a spamszűrők adatbázisában, a fenyegetés-hírcsatornákban, a botnetek konfigurációs fájljaiban. A bot pedig nem tudja, hogy „vége". Ha nem kap választ, újrapróbálja — sokszor agresszívabban, mint először, mert az újrapróbálkozási logika pont erre való. A domain elindult egy önjáró körforgásban, aminek már semmi köze nem volt ahhoz, hogy a tulajdonosa mit csinál a szerveren.

A tűzoltás — mi történt, és mi hozott eredményt

A lépések sorrendben:

• Az összes FTP-felhasználó letiltása a fióknál, nem csak az érintetté — azonnali vérzéscsillapítás.
• Minden domain egyenkénti átvizsgálása, mielőtt bármi visszakapcsol — itt derül ki, meddig terjedt.
• Domain a Cloudflare mögé, „Under Attack" mód — a forgalom 100%-át megfogta.
• Geo-korlátozás: minden Magyarországon kívüli forgalom tiltva — a maradék zaj kizárása.
• Jelszócsere mindenhol, ahol az a jelszó valaha szerepelt — a tényleges gyökérok kezelése.
• Jelszótárolás megszüntetése a szerkesztőben — hogy ne fordulhasson elő újra.

A Cloudflare technikailag tökéletesen működött: 21,17 millióból 21,17 milliót fogott meg, az origin nulla kérést kapott. De ez már csak a tünetet kezelte. A szolgáltató addigra jogosan lekapcsolta a DNS-t, a domain addigra már rajta volt minden listán, amin senki sem akar rajta lenni.

Itt válik élesen láthatóvá a különbség védelem és kármentés között. A Cloudflare, ha előre ott van, védelem. Ha baj után kerül be, akkor csak egy nagyon jó lapát, amivel a törmeléket takarítod.

A tényleges veszteség: a hírnév, ami nem a tiéd

Kézenfekvő azt hinni, hogy amint a szerver tiszta, vége a történetnek. Nem így van.

Egy évvel az incidens után a VirusTotal még mindig ezt mutatja a domainre:

Négy szolgáltató a kilencvenkettőből. Nem sok, ugye? Ez a négy viszont bőven elég ahhoz, hogy:

• vállalati tűzfalak blokkolják az oldalt — a Fortinet nem hobbiprojekt, hanem ott van több tízezer cég hálózatának a szélén;
• a domainről küldött e-mailek eleve hátránnyal induljanak a spamszűrőknél;
• a böngészők egy része figyelmeztető képernyőt tegyen elé;
• és ami a legrosszabb: ha valaki üzleti partnerként világít át téged, és beírja a domaint a VirusTotalba, piros feliratot lát.

Felülvizsgálati kérelem több helyre is ment. És itt jön a keserű tanulság: a domain hírneve nem a te tulajdonod. Egy tucat egymástól független cég adatbázisában él, mindegyik a saját ütemében frissít, mindegyiknek más a folyamata, van, ahol nincs is valódi visszavonási út — csak egy űrlap, amire soha nem jön válasz. Az adatok pedig továbbterjednek: az egyik szolgáltató a másiktól veszi át a listát, így a törlés után visszaszivárog.

Miért lett a vége az, hogy elengedte?

Ez a domain szerencsére nem volt túl értékes. Nem futott rajta bevétel, nem kapcsolódott hozzá céges e-mail-cím, nem szerepelt nyomtatott anyagon, nem volt komoly linkprofilja. Márton megnézte a mérleget — mennyi munka lenne visszaszerezni a tiszta lapot, szemben azzal, amit ér —, és elengedte.

Racionális döntés volt. És mégis: a történet legfontosabb része nem ez, hanem az a mondat, amit utána mondott ki.

Ugyanaz a szerkesztő, ugyanaz a munkamódszer, ugyanaz a mappaszerkezet. Csak a véletlenen múlt, melyik projekten futott le először a „teljes mappa feltöltése". Ha a fő céges domain lett volna:

• a céges e-mail ment volna vele — spam-mappa, blokkolt kézbesítés, hetekig;
• a Google találati listában megjelent volna a „Ez az oldal károsíthatja a számítógépét" figyelmeztetés;
• a fizetési szolgáltató akár fel is mondhatott volna — a szerződéseikben ott van az adathalászat mint azonnali felmondási ok;
• a partnerek átvilágításánál piros zászló lett volna;
• és a márkanevet, amit tíz év alatt épített, nem lehetett volna „elengedni".

Ez nem drámázás. Ez az, ami majdnem megtörtént.

A tizenkét dolog, amit ezután másképp csinál

Ez a cikk hasznos része. Menj végig rajta a saját oldaladra — a legtöbbje egy délután alatt megcsinálható.

A hozzáférés

1. Jelszó soha nem lakik a projektmappában. Se sftp.json-ban, se sftp-config.json-ban, se wp-config.php.bak-ban, se „ideiglenesen" egy jelszavak.txt-ben. A szerkesztő nem trezor. Használj SSH-kulcsot — a bővítmények mind támogatják —, a kulcs pedig maradjon a ~/.ssh-ban, jelmondattal védve.
2. Az FTP halott — engedd el. A sima FTP titkosítatlanul viszi át a jelszavadat a hálózaton. 2026-ban ennek nincs mentsége: SFTP vagy SSH, semmi más. Ha a szolgáltatód csak FTP-t tud, az önmagában elég ok a költözésre.
3. Kétfaktoros hitelesítés mindenhol, ahol egyáltalán van: tárhely-vezérlőpult, domain-regisztrátor, DNS-szolgáltató, GitHub, e-mail. A regisztrátori fiókod többet ér, mint maga a weboldal.

A telepítés menete

4. A webgyökér nem munkamappa. Ez a legfontosabb szerkezeti változás. A webszerveren futó tartalom legyen egy telepítés eredménye, ne egy szerkesztőből felmásolt élő mappa. Verziókezelő (git) + telepítő szkript, tiltólistával arra, ami sosem kerülhet ki:

   .git  .github  .vscode  .idea  .env  .env.*  *.log  _source  node_modules

5. Amit kizársz a gitből, azt zárd ki a telepítésből is — külön. Ez két különböző lista, és a legtöbb baleset abból van, hogy valaki azt hiszi, egy. A .gitignore a verziókezelőt védi, a telepítő tiltólistája a webszervert.
6. A titkok a webgyökér FÖLÖTT laknak. Egy .env fájl egy szinttel feljebb, 600-as jogosultsággal. Ami a webgyökérben van, azt előbb-utóbb valaki le tudja kérni — akkor is, ha te úgy tudod, hogy nem.

A szerver

7. Tiltsd le a rejtett mappák kiszolgálását webszerver szinten. Ez egyetlen blokk, és pont ezt az incidenst előzte volna meg:

   # nginx
   location ~ /\.(?!well-known) { deny all; return 404; }
   
   # Apache
   RedirectMatch 404 /\.(?!well-known)

   Ezzel a .vscode/sftp.json egyszerűen nem létezik a külvilág számára, akkor sem, ha véletlenül feltöltöd.
8. A feltöltési mappákban tiltsd le a PHP futtatását. Az adathalász készletek túlnyomó része egy uploads mappában landol. Ha ott nem fut PHP, a feltöltött fájl csak egy haszontalan szövegfájl marad.
9. WAF és forgalomkorlátozás alapból, ne tűzoltásként. A Cloudflare ingyenes csomagja a 21 milliós hullámot lenyelte. Az „Under Attack" mód utólagos bekapcsolása viszont már késő volt. Állíts be előre szabályokat, amik megvédik az oldaladat.

Az észlelés

10. Fájlintegritás-figyelés. A támadás és a felfedezés között két nap telt el, és nem a tulajdonos vette észre, hanem egy külső bejelentő. Egy egyszerű ellenőrzés, ami riaszt, ha új .php fájl jelenik meg a webgyökérben vagy megváltozik az index.php — ez órákra rövidíti ezt a két napot.
11. Forgalom-anomália figyelése. Ha valami a tízszeresére ugrik, arról tudni akarsz. Nem másnap, hanem akkor.
12. Izoláció. A legdrágább tanulság: egy FTP-felhasználó alatt lakott több domain. Egy jelszó kiszivárgása így nem egy oldalt, hanem az összeset veszélyeztette. Ma minden oldal külön Linux-felhasználó alatt fut, saját jogosultsággal — ha az egyik elesik, a többihez nem vezet út.

Ha most történik veled — az első óra

Mentsd el ezt a sorrendet, mert baj közben senki nem gondolkodik tisztán:

1. Ne törölj semmit azonnal — előbb készíts másolatot a fájlokról és a logokról. Ez a bizonyíték, és ebből derül ki, mi történt.
2. Zárd le a hozzáféréseket: minden FTP/SFTP/SSH-fiók, vezérlőpult, adatbázis-jelszó, API-kulcs.
3. Feltételezd, hogy továbbterjedt. Ha egy jelszó kiszivárgott, mindenhol cseréld, ahol az a jelszó — vagy annak variánsa — valaha szerepelt.
4. Keresd a hátsó ajtókat, ne csak a nyilvánvaló kártevőt: friss módosítású fájlok, ismeretlen időzített feladat, plusz felhasználói fiókok, gyanús sorok meglévő fájlok közepén.
5. Állj helyre olyan mentésből, ami biztosan a fertőzés előtti — nem a legutóbbiból.
6. Tedd a domaint WAF mögé, mielőtt visszakapcsolod.
7. Csak ezután indítsd a felülvizsgálati kérelmeket (Google Search Console, Safe Browsing, VirusTotal, tiltólisták). Ha piszkosan kéred, másodszorra kétszer nehezebb lesz.

A valódi tanulság

Márton az első levelében azt írta a szolgáltatójának, hogy „általában nagyon gondosan kezelem az adataimat, erre nem voltam felkészülve". Ez igaz volt. És pontosan ezért nem elég.

A biztonság nem gondosság kérdése. A gondosság elfárad, siet, elfelejt, és egyszer csak rákattint a „teljes mappa feltöltése" gombra egy péntek este. A biztonság szerkezet kérdése: olyan felállás, amiben a rossz dolog akkor sem tud megtörténni, ha az ember hibázik.

Nem az volt a hiba, hogy kiszivárgott a jelszó. Az volt a hiba, hogy létezett olyan jelszó, amit egy fájl ki tudott plakátolni — és hogy a rendszerben egyetlen olyan pont sem volt, ahol ez a lánc megszakadhatott volna. Bármelyik lépés elég lett volna: SSH-kulcs jelszó helyett, rejtett fájlok tiltása a szerveren, szerkesztős feltöltés helyett telepítés, izolált felhasználók, integritás-figyelés. Egy is. Egy sem volt.

Ma mind megvan. Nem azért, mert bárki megokosodott, hanem mert fizetni kellett érte egy domaint.

Ha olvasás közben kicsit ideges lettél — az jó jel

Nézd meg még ma ezt a hármat, ingyen, öt perc alatt:

1. Nyisd meg böngészőben: https://a-te-domained.hu/.vscode/sftp.json — és ugyanígy a /.git/config, /.env, /sftp-config.json címeket. Ha bármelyik letöltődik, azonnal cserélj jelszót.
2. Nézd meg a domainedet a VirusTotalon. Tudni akarod, mit lát rólad a világ.
3. Nézd meg, hány FTP-felhasználó van a tárhelyeden, és hány oldalhoz fér hozzá mindegyik.