Hackerek: a leggyakoribb fájlok és útvonalak, amiket automatikusan fésülnek

A webes robotok nem zsenik, hanem kitartó futárok: előre gyártott listákat lőnek rá az internetre, és szisztematikusan végigpróbálnak mindent, ami valaha egyszer is hibának bizonyult. Ezzel a módszerrel nem kell „gondolkodniuk”, mert a hibák túlnyomó része ismétlődik: egy elfelejtett phpinfo, egy gyökérben felejtett backup, egy nyitva hagyott xmlrpc, vagy egy fejlesztői környezetből maradt .env. Amíg sok webhely ugyanazokat a mintákat hagyja magán, addig a listázás extrém jól skálázódik. Egy átlagos bot több tízezer útvonalat és fájlnevet tesztel óránként, és ha csak minden ezredik találat, már rentábilis. E cikk célja, hogy rendszerezve, üzleti szemmel is érthetően bemutassa: mely fájlok és útvonalak a robotok kedvenc zsákmányai, hogyan ismerhetők fel a minták, és milyen minimális – de hatásos – védekezést érdemes beállítani. Külön figyelmet kap a WordPress, a PHP-alapú keretrendszerek (Laravel, Symfony, CodeIgniter), illetve a Java/Node/.NET ökoszisztéma. Miközben a fókusz a „mit fésülnek” kérdésen van, a végén találsz rövid Apache/Nginx példákat is. Fontos látni: ez nem „paranoia-lista”, hanem a gyakorlat – pontosan az a menü, amelyen a robotok végigeszik magukat, mert a világ számtalan szerverén ugyanazok a félbehagyott fejlesztői nyomok és admin-maradékok sorakoznak. Aki ezt a menüt leszedi az asztalról, az látványosan csökkenti a kitettségét és a szervere terhelését, miközben az üzleti kockázat is mérséklődik. Dajka Gábor tapasztalata szerint már az alapzaj 80–90%-ának kiszűrése is érzékelhető konverziós és rendelkezésre állási előnyt hoz, mert a robotok döntő többsége egyszerűen lepattan.

Mit fésülnek a robotok – a logika röviden

A robotok három alapelv szerint dolgoznak. Először: ismert fájlnév-variánsok. Ezért futnak nap mint nap a „phpinfo.php”, „info.php”, „pinfo.php”, „php-info.php” és kiterjesztés nélküli „/phpinfo” lekérések – mind ugyanarra a célra: környezeti információ kinyerése. Másodszor: könyvtár-sablonok. A „config”, „app”, „storage”, „logs”, „tmp”, „uploads” mappákat és ezek kombinációit variálják, mert itt szoktak maradni a konfigok és a mentések. Harmadszor: technológiai ujjlenyomat. A „/robots.txt”, „/sitemap.xml”, „/.well-known/…” fájlokból, az HTTP-fejlécekből és a REST/GraphQL útvonalakból (pl. „/wp-json/”, „/api/”, „/graphql”) következtetnek a keretrendszerre és verzióra, majd ennek megfelelő exploitlistát töltenek be. Nem véletlen, hogy a Security Misconfiguration az OWASP Top 10 egyik visszatérő tétele, vagy hogy az „/.well-known/” útvonalak használatát külön RFC rendezi: ezek mind standardizált viselkedések, amelyeket könnyű géppel ellenőrizni. A jó hír, hogy ugyanilyen szabványos módon lehet szűrni is: tiltani a tipikus debug- és backup-fájlokat, IP-re szűkíteni az admin és server-status elérést, és kiszervezni a mentéseket a webgyökérből. A botok nem állnak meg, de ha nincs zsákmány, továbbmennek; ez a skálázás másik oldala. (Lásd: OWASP Top 10 – Security Misconfiguration; „well-known” URI-k: RFC 8615.)

Hitelesítő és konfigurációs fájlok

A legnagyobb kár jellemzően nem egy brute-force-ból, hanem egy kiszivárgott konfigurációból következik. Egyetlen publikussá vált .env több annál, mint „kellemetlen hiba”: azonnali hozzáférés lehet az adatbázishoz, külső API-khoz, felhőszolgáltatókhoz. Ugyanez igaz a „wp-config.php” mentett, szerkesztő által generált vagy átnevezett változataira, illetve a framework-ök „config” mappáira. Tipikus, hogy fejlesztés közben ideiglenesen „kiteszik” a fájlt, majd elfelejtik visszazárni; vagy a mentések kényelmi okból a webgyökérben maradnak. A botok pontosan ezt a fegyelmezetlenséget árazzák be. Ha egy robot bármelyik alábbi fájlt eléri, pár másodpercen belül jön a második hullám: célzott próbálkozások a belső rendszerek ellen. A gond nem csak technikai: folyamatbeli. Ha nincs takarítási rutin és „no webroot backups” szabály, előbb-utóbb lesz találat. Dajka Gábor tapasztalata szerint a hazai KKV-k döntő többségénél itt dől el a meccs: a hozzáférési adatok védelme kultúra és önfegyelem kérdése, nem költségvetésé. Az alábbi táblázat a leggyakrabban vadászott konfigcélpontokat foglalja össze.

Admin és belépési végpontok; debug és tesztoldalak

A második nagy halmaz a bejáratok és az információszivárogtató oldalak. A bejáratoknál a cél jellemzően kettős: egyrészt belépni gyenge jelszóval, másrészt terhelni vagy visszaélni (pl. az XML-RPC egyszerre sok próbálkozást enged). A debug-oldalak pedig – például a „phpinfo.php” különféle variánsai – pontos térképet adnak a támadónak a környezeti modulokról, verziókról, elérési útvonalakról. A kettő kombinációja adja a legveszélyesebb elegyet: egy kiszivárgott konfig plusz egy elérhető admin vagy server-status oldal már elegendő egy gyors, célzott támadáshoz. A jó hír: ezek nagy része feketelistával és IP-szűréssel kényelmesen elvágható – nálam ez az első beállítás minden új projektnél. Az alábbi listák a terepen leggyakrabban látott célpontok; ha ezek közül bármelyik publikus, kezeld magas kockázatként.

• /wp-login.php, /wp-admin/, /wp-admin/admin-ajax.php
• /xmlrpc.php (brute-force és pingback visszaélések)
• /wp-cron.php?doing_wp_cron=… (terhelés, időzítések megakasztása)
• /phpMyAdmin/, /pma/, /mysqladmin/ (ál- és valós elérési utak)
• /server-status, /server-info (modulok, verziók, munkásállapot)
• /grafana/, /kibana/, /jenkins/, /manager/html (Tomcat), /actuator/health (Spring)

• /phpinfo.php, /php-info.php, /info.php, /pinfo.php, /phpinfos.php, /phpinfo
• /test.php, /test1.php, /test2.php, /i.php, /time.php, /temp.php, /asdf.php
• /linusadmin-phpinfo.php, /dashboard/phpinfo.php, /index.php/phpinfo
• /dev/phpinfo.php, /_profiler/phpinfo, /symfony/_profiler/phpinfo, /frontend_dev.php/$

Verziókezelő-maradványok és CMS-specifikus célpontok

Harmadik nagy kategória az, amit fejlesztésből vagy költözésből „ott felejtünk”. A verziókezelő mappák (például „/.git/” és társai) azért veszélyesek, mert gyakran visszafejthető belőlük a komplett projekt, sőt, néha még a távoli origin URL-je is. A szerkesztők által létrehozott cserefájlok (pl. „.swp”, „.swo”) és a „.old”, „.bak” végződésű mentések a másik visszatérő fájdalompont. A CMS-ek világában a robotok rendszerspecifikus listákat használnak: WordPressnél a „/wp-login.php”, „/xmlrpc.php”, „/wp-admin/”, „/wp-json/”, és a feltöltések alatti futtatható fájlok; Drupálnál a telepítő; Joomla esetén az „/administrator/”. A következő felsorolások a terepen leggyakoribb maradványokat és CMS-útvonalakat mutatják. Ha ezek közül bármelyik listázható vagy letölthető, sürgős beavatkozás szükséges.

• /.git/, /.git/HEAD, /.git/config, /.gitignore, /.git-credentials
• /.svn/, /.hg/
• /.DS_Store (macOS meta), Thumbs.db
• *.swp, *.swo (Vim), ~, .bak, .old, .save
• /.vscode/settings.json, /.vscode/sftp.json, /sftp.json, /sftp-config.json

Végül külön említést érdemelnek az úgynevezett „well-known” és felderítő fájlok: „/robots.txt”, „/sitemap.xml”, „/.well-known/security.txt”, „/.well-known/traffic-advice”. Ezek önmagukban nem „hibák”, de fingerprint-ként használhatók – pontos képet adnak a szerkezetedről, vagy a keresőknek súgnak az elérési utakról. Ha rossz helyen vagy rosszul konfigurálva szerepelnek, a botoknak megkönnyítik a dolgát. (A „well-known” szabványt az RFC 8615 írja le.)

Minimalista védekezés – gyors nyereség kevés súrlódással

Ez a cikk nem teljes hardening-kézikönyv; a cél a „mit fésülnek” és a legkevesebb munkával elérhető legnagyobb zajcsökkentés. A tapasztalat szerint három lépés már látványos eredményt hoz. 1) Feketelistázd a tipikus debug-, backup- és verziókezelő-maradványokat; 2) Zárd az XML-RPC-t (vagy csak megbízható IP-re engedd), a server-status-t pedig kizárólag helyi IP-ről tedd elérhetővé; 3) Vidd ki a mentéseket a webgyökérből, és tiltsd a végrehajtást a feltöltések alatt. WordPress esetén a hivatalos Hardening WordPress útmutató jó gerinc: tartsd a magot és a bővítményeket frissen, változtasd a bejelentkezési szabályokat, és limitáld az admin-URL-ek láthatóságát. Ha van WAF (akár felhőben), írj egyetlen szabályt a „phpinfo” és a feltűnő backup-kiterjesztések (env, bak, old, swp) tiltására; már ettől leapad a forgalom. A lenti példák a WordPress-gyökeret vagy tipikus PHP-site-ot védenek. (Részletes, hivatalos szempontrendszer: WordPress Hardening Guide.)

Apache (.htaccess, a WP gyökerében)
<Files "xmlrpc.php">Require all denied</Files>
<Files "wp-cron.php">Require ip 127.0.0.1<br>Require all denied</Files>
RedirectMatch 403 ^/(?:\.git|\.svn|\.hg|\.aws|\.vscode|\.ssh)(/|$)
RedirectMatch 403 \.(?:env|bak|old|swp|save)$
<Location "/server-status">Require ip 127.0.0.1</Location>

Nginx (site conf, példa)
location = /xmlrpc.php { return 444; }
location = /wp-cron.php { allow 127.0.0.1; deny all; }
location ~ ^/(\.git|\.svn|\.hg|\.aws|\.vscode|\.ssh) { deny all; }
location ~ \.(env|bak|old|swp|save)$ { deny all; }
location ^~ /wp-content/uploads/ { types { } default_type application/octet-stream; }

Ha üzleti oldalról nézed: mindez alacsony költségű, visszafordítható változtatás, amely csökkenti a botforgalmat, gyorsítja az oldalt, és mérsékli az incidenskezelés rejtett költségét. A megelőzés itt valóban olcsóbb, mint bármely helyreállítás – és nem igényel „nagyprojektet”.

Összegzés: miért pont ezeket fésülik?

Mert ez a legrövidebb út a haszonhoz. A robotok számára a világ egységesített hibakatalógus: ha egyszer valaki valahol /.env-et hagyott kint, akkor mások is meg fogják tenni; ha az XML-RPC egyszer jó volt brute-force-ra, akkor marad a listán; ha a „phpinfo” valaha is kint felejtődött, akkor érdemes rá lőni. A minta egyszerű, mégis sok szervezet újra és újra belesétál. Nem azért, mert ne tudnák a szabályokat, hanem mert a mindennapi prioritás-listában a biztonság gyakran „holnapra” csúszik. Innen nézve a kérdés nem technikai, hanem vezetői: van-e olyan minimum, amelyet minden projektben kötelezően bekapcsolunk? Van-e szokásrend a mentések kezelésére? Elfogadjuk-e, hogy az „alapzaj” csökkentése nem opcionális, hanem üzleti döntés? Én nem azért javaslom a fenti tiltólistát és IP-szűrést, mert „szépen néz ki” egy biztonsági auditban, hanem mert azonnali megtérülést hoz: kevesebb fals riasztás, kevesebb fércmeló, és tisztább forgalmi adatok a marketingben. Amit mérsz, azt tudod fejleszteni – márpedig a robotzaj, ha hagyod, torzítja a képet. Ha levágod az útvonalakat, amelyekre a robotok vadásznak, nemcsak a kitettséged csökken, hanem a döntéseid is pontosabbak lesznek.

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

Én ezt az egész témát nem „kockaügynek” látom, hanem megbízhatósági és bizalom kérdésnek. Egy márka a digitális térben annyira erős, amennyire következetes. Ha a szervered tele van félbehagyott fájlokkal és nyitott ajtókkal, az nem csak támadási felület: puha üzenet arról, hogy belül sincs rend. A minőség nem hangzatos vállalás, hanem napi fegyelem – és ebbe beletartozik az is, hogy a webgyökérben nem parkol backup, a debug a fejlesztői környezet privilégiuma, az admin pedig nem kirakat. Aki ezt komolyan veszi, az ritkábban „ég”, és ha mégis történik valami, kisebb az ár. Üzleti értelemben a biztonság itt marketing is: tisztább adat, stabilabb elérhetőség, kevesebb kiesés. Aki a robotok kedvenc zsákmányait elzárja, nem szuperhős lesz, csak következetes. És ez az, amit az ügyfelek észrevesznek. Ha egyetlen mondatot vihetsz el: a minimális higiénia nem extra munka – az az alap, amire mindent építesz. Ha ez megvan, jöhetnek a kifinomult megoldások, de nélküle minden más csak pózolás.

Szakértő válaszol – GYIK

Mennyire célpont a magyar KKV-k WordPress ökoszisztémája?

Dajka Gábor: Nagyon. A robotok nem „nemzetiségi alapon” lőnek, hanem listák alapján, így a magyar tartományok és tárhelyszolgáltatók ugyanúgy a célkeresztben vannak. Tapasztalatom szerint a leggyakoribb hibák: az XML-RPC nyitva hagyása, a gyökérben felejtett mentések és a feltöltések mappájában futtatható fájlok. Ezek mind automatával is észlelhetők, ezért kell őket azonnal lezárni.

Érdemes-e teljesen kikapcsolni az XML-RPC-t?

Ha nincs rá legitim integrációd (pl. mobil-app szerkesztés, távoli publikálás), akkor igen. Ha van, IP-re szűkítsd, vagy tegyél elé WAF-szabályt. Az XML-RPC a brute-force-nak és a visszaéléseknek régóta kedvelt csatornája; könnyű nyereség lezárni vagy szűkíteni.

Mit kezdjek a „phpinfo” típusú lekérésekkel?

Tedd egyértelműen tilosnak: szerveroldali szinten (Apache/Nginx) dobd vissza 403/444-gyel. Ha szükség van rá fejlesztés közben, legyen csak fejlesztői környezetben, ideiglenesen, és IP-re korlátozva. Prod környezetben nincs rá jó ok.

Hogyan csökkentsem a botok által generált zajt az analitikában?

Két fronton lépj: infrastruktúrában és mérésben. Infrastruktúrában szűrd a tipikus útvonalakat (ld. fenti példák), a mérésben pedig különítsd el a 403/444 válaszokat és a gyanús user-agenteket. Így a forgalmi képed tisztul, a marketingdöntéseid pontosabbak lesznek.

Mi a minimum WordPress-hardening, amit ma már nem illik kihagyni?

Friss mag és bővítmények, XML-RPC tiltás vagy szűkítés, server-status csak belső IP-ről, feltöltések alatt nincs végrehajtás, admin-URL-ek IP-re korlátozása, mentések nem a webgyökérben. Ha ez megvan, már a robotzaj többségét blokkoltad.

Ajánlott magyar videók/podcastok

Az alábbi ajánló a témához kapcsolódó, magyar nyelvű ismeretterjesztő anyag:

Források

OWASP Top 10 – A05:2021 Security Misconfiguration: https://owasp.org/Top10/A05_2021-Security_Misconfiguration/

WordPress – Hardening WordPress (hivatalos útmutató): https://wordpress.org/support/article/hardening-wordpress/

IETF RFC 8615 – Well-Known Uniform Resource Identifiers (URI): https://www.rfc-editor.org/rfc/rfc8615

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