Spamküldés? A honlap látszólag rendesen működik, a tárhelyszolgáltató mégis leállítja a levélküldést. Ismeretlen címzettekről érkeznek visszapattanó üzenetek, vagy a valódi ügyféllevelek kézbesítése romlik. Más esetben a szolgáltató szokatlan kimenő forgalom miatt jelez.
A megszerzett rendszer erőforrásai a támadó számára is értéket jelenthetnek. A MITRE az erőforrások jogosulatlan felhasználásának példái között számítási kapacitás kihasználását, hálózati közvetítést és üzenetküldő szolgáltatásokkal végzett spamküldést is tárgyal. [1]
Cikksorozatunk hatodik részében azt nézzük meg, hogyan válhat egy weboldal levélszemét küldésének vagy további támadásoknak az eszközévé. Bemutatjuk a fontos különbségeket, a felderítéshez használható nyomokat, valamint a WordPress- és Joomla-oldalak ellenőrzési szempontjait.
Mit jelent az, hogy a weboldal spamet küld?
A levélküldési probléma leírásához először a küldés útját kell azonosítani. A PHP mail() függvénye a futtatási környezet levelezési beállításaira támaszkodik. Egy külön levelezőkönyvtár, például a PHPMailer közvetlen SMTP-kapcsolatot is használhat. [2][3]
A levelek ezért nem feltétlenül ugyanazon a rendszeren mennek keresztül, mint amelyiken a weboldal fut. A vizsgálatban külön kérdés a levelet előállító alkalmazás, az átadáshoz használt hozzáférés és a továbbító kiszolgáló.
| Lehetséges helyzet | Mit kell azonosítani? |
|---|---|
| Jogosulatlan levélküldő program került a tárhelyre | A programot, indításának módját és a küldési útvonalat |
| A rendes űrlappal élnek vissza | A kiváltó kéréseket, címzetteket és beilleszthető tartalmat |
| SMTP-hozzáférést szereztek meg | A használt fiókot, hitelesítési eseményeket és küldési adatokat |
| Csak a feladót hamisítják | Az üzenetek tényleges eredetét és hitelesítési eredményeit |
Ez vizsgálati felosztás, nem egy konkrét weboldal diagnózisa. A négy helyzet akár egyszerre is előfordulhat.
Hogyan válhat egy szabályos űrlap a visszaélés eszközévé?
Az OWASP automatizált fenyegetésekről szóló anyaga a webalkalmazások funkcióival végzett visszaéléseket is rendszerezi, köztük a spam elhelyezését és továbbítását. Az automatizált visszaéléshez nem minden esetben kell külön kártékony programot telepíteni az oldalra. [4]
Kitalált példa: egy ajánlatkérő a beküldő által megadott e-mail-címre visszaigazolást küld, amelyben a szabadon kitölthető üzenetet is megismétli. Egy bot idegen címzetteket és reklámszöveget ad meg. A weboldal így a saját visszaigazolási funkciójával továbbít kéretlen üzeneteket.
Ebben a példában az űrlap rendeltetésszerű működését kell újragondolni: milyen adat kerül a válaszlevélbe, ki választhatja meg a címzettet, és milyen feltételekkel indulhat küldés? A csak a tulajdonosnak kézbesített bejövő spam és az idegen címzettekre kiküldött visszaigazolás külön hatás.
A botvédelem és a küldési korlátozás hasznos ellenőrzési terület, de az alkalmazás megengedett működését is értékelni kell.
Az ellopott SMTP-hozzáférés külön probléma
Az SMTP egy lehetséges levélküldési út. A PHPMailer például hitelesített SMTP-küldést is támogat, ezért a weboldal levelezése külön szolgáltatói fiókhoz kapcsolódhat. [3]
Kitalált példa: egy kompromittált alkalmazásból megszerzik a levélküldéshez használt hitelesítési adatot. A támadó ezután másik gépről használja ugyanazt a fiókot. Ebben a példában a weboldal fájljainak helyreállítása önmagában nem vonja vissza a megszerzett SMTP-hozzáférést.
A kivizsgálásnál ezért össze kell kapcsolni az alkalmazás és a levelezőszolgáltató adatait. Melyik fiók küldött, mikor történt hitelesítés, és milyen forrásból? Ha a naplók nem érhetők el az ügyfélfelületen, a szolgáltatótól kell kérni a megfelelő időszak vizsgálatát.
A feladóhamisítás nem bizonyít weboldalfeltörést
Az e-mailben látható feladói cím önmagában nem hitelesíti az üzenet eredetét. Az e-mail-hitelesítési mechanizmusok más-más szempontból adnak információt a küldőről. [5–7]
- Az SPF azt szabályozza, milyen kiszolgálók küldhetnek az ellenőrzött domain nevében, elsősorban az SMTP-boríték feladója alapján. [5]
- A DKIM digitális aláírással köti az üzenetet egy aláíró domainhez, és ellenőrizhetővé teszi az aláírt részek sértetlenségét. [6]
- A DMARC a látható feladói domainhez igazodó SPF- vagy DKIM-eredményt, valamint a domain közzétett szabályzatát használja. [7]
Kitalált példa: valaki egy teljesen másik levelezőrendszerről a céged címét tünteti fel feladóként. A panasz vagy visszapattanás ilyenkor is érkezhet hozzád, de ebből nem következik, hogy a saját weboldalad küldte az üzenetet.
Technikai magyarázat: A sikeres SPF-, DKIM- vagy DMARC-ellenőrzés sem minősíti jóindulatúnak a tartalmat. Kitalált példa: a támadó valóban használhat egy engedélyezett küldőfiókot, és a kéretlen levél szabályos hitelesítéssel jut tovább. A küldési jogosultság és az üzenet rendeltetése külön kérdés.
Milyen következménye lehet a jogosulatlan küldésnek?
A Gmail küldői útmutatója szerint a domain- és IP-reputáció, a felhasználói spamjelzések és a küldési mintázat is befolyásolhatják a kézbesítést. Megosztott küldő-IP-n más feladók tevékenysége is hatással lehet a közös IP megítélésére. [8]
Ezért egy kézbesítési probléma vizsgálatakor külön kell kezelni a domain, a küldőfiók és a tényleges küldő-IP szerepét. A weboldal IP-címe és a levéltovábbító IP-címe nem feltétlenül ugyanaz.
Kitalált példa: a weboldal külső SMTP-szolgáltatón keresztül küld, és ott korlátozzák az érintett fiókot. A saját tárhelyen vizsgált levélsor nem mutatja meg a külső szolgáltató összes küldési eseményét. Előbb a küldési útvonalat kell tisztázni.
A rendes üzleti levelek kézbesítését ezért a kártékony működés megszüntetése után is ellenőrizni kell.
Miből ismerhető fel a visszaélés?
A szokatlan forgalom jó kiindulópont lehet, de önmagában nem elég a diagnózishoz. Egy jogos hírlevél vagy egy hibásan ismétlődő feladat is okozhat eltérést. Az eseményeket az oldal dokumentált működéséhez kell viszonyítani.
Vizsgálati nyom lehet például a szolgáltatói riasztás, sok ismeretlen címzett, azonos időszakban ismétlődő űrlapkérés vagy egy nem dokumentált küldőprogram. Az OWASP naplózási útmutatója az alkalmazásesemények és biztonsági események rögzítését is tárgyalja; az adatokból az időrendet kell összeállítani. [9]
Az üres „Elküldött” mappa nem írja le az összes alkalmazásból vagy külső küldési útvonalon indított műveletet. A vizsgálatot a levelezőkliens nézete helyett a tényleges küldési lánchoz kell kötni.
Mit lehet megnézni cPanelben?
A cPanel Email → Track Delivery, magyar felületen kézbesítéskövetésként megjelenő funkciója a fiókhoz tartozó kézbesítési eseményeket mutatja. Címzett szerint szűrhető, és a továbbítási problémák felderítésében segíthet. A szolgáltató engedélyezheti vagy letilthatja a funkciót. [10]
Érdemes rögzíteni az esemény idejét, az üzenetazonosítót, a címzettet és a kézbesítési eredményt. A megjelenített mezők és a rendelkezésre álló időszak alapján ezután célzottan kérhető további szolgáltatói vizsgálat.
A szerver teljes levélsorának kezelése külön jogosultságot igényelhet. A WHM Mail Queue Manager szerveradminisztrációs felület; megléte nem jelenti azt, hogy egy megosztott tárhely ügyfelének is rendelkezésére áll. [11]
Technikai magyarázat: A küldési próbálkozás, a továbbításra átvétel és a tényleges címzetti kézbesítés külön állapot. A PHP
mail()sikeres visszatérése a továbbításra történő elfogadást jelzi, nem a címzetthez érkezést. [2] A levélsor és a naplók értékelésénél ezért az esemény pontos jelentését is rögzíteni kell.
A program eredetére utaló PHP-adatok
A PHP levelezési beállításai között szerepel a mail.log és a mail.add_x_header. Az előbbi a mail() hívásainak naplózására szolgál, az utóbbi beállítástól függően eredetre utaló adatot adhat a levélhez. [12]
Ezek a környezethez kötött nyomok nem terjednek ki automatikusan minden külön SMTP-könyvtárra vagy külső API-küldésre. A naplózási lehetőségeket a tárhelyszolgáltatóval kell egyeztetni, és a meglévő bizonyítékokat érdemes megőrizni a változtatások előtt.
WordPress: melyik működés indítja a levelet?
A WordPress wp_mail() függvénye dokumentált levélküldési pont. A sikeres visszatérés itt sem jelenti automatikusan, hogy a címzett megkapta az üzenetet. [13]
A vizsgálat kérdése, melyik bővítmény, sablon vagy feladat indítja a küldést, és az melyik levelezési útvonalon jut tovább. Kitalált példa: egy regisztrációs funkcióval visszaélő bot minden kérésre új értesítést vált ki. Az értesítő szabályosan működik, a kiváltás módja mégis visszaélés.
A WordPress saját ütemezése ismétlődő eseményeket is indíthat. A wp_schedule_event() dokumentációja szerint az esedékes események futását az alapműködésben weboldalkérések váltják ki. Ez különbözik a kiszolgáló cronrendszerétől. [14]
Technikai magyarázat: Egy SMTP-bővítmény vagy a
wp_mail()köré épített napló csak a rajta áthaladó küldést írja le. Kitalált példa: egy külön elhelyezett program közvetlen SMTP-kapcsolatot nyit, így annak forgalmát más forrásból kell feltárni. Egyetlen üres alkalmazásnapló nem teljes körű bizonyíték.
Joomla: központi levelezés és a bővítmény működése
A Joomla saját levelezési szolgáltatást biztosít az alkalmazások és bővítmények számára. A dokumentáció a központi beállításokra építő használatot és a levélküldési hibák kezelését is bemutatja. [15]
Joomla-oldalnál ezért érdemes összevetni a központi levélküldési beállításokat az érintett komponens saját működésével. Egy hírlevélrendszer, űrlap vagy egyedi integráció feladatát és tényleges küldési útját külön kell azonosítani.
Kitalált példa: egy űrlapkomponens visszaigazolásával élnek vissza, miközben egy másik bővítmény saját levélküldő beállítást használ. Az egyik útvonal letiltása nem mutatja meg, mi történik a másikon.
A Joomla biztonsági útmutatója a veszélyes fájlfeltöltést is tárgyalja: egy ilyen hiba program elhelyezését és bizonyos körülmények között kódfuttatást tehet lehetővé. A bejutási hibát és az elhelyezett levélküldő kódot külön kell kezelni. [16]
Mire használhatják még a megszerzett környezetet?
Forgalom közvetítésére
A MITRE a proxyhasználatot a támadói kommunikáció egyik technikájaként írja le. Köztes rendszerek segítségével a forgalom eredete és útvonala összetettebbé válhat. [17]
Kitalált példa: egy kompromittált környezetben elindított közvetítőprogram idegen kéréseket továbbít. A külső célpont a köztes rendszer forgalmát észleli. A konkrét lehetőségeket azonban a jogosultságok és a hálózati korlátozások határozzák meg; egy CMS-hozzáférés nem azonos a teljes szerver feletti irányítással.
Más szolgáltatások terhelésére
A MITRE a hálózati szolgáltatásmegtagadást külön támadási technikaként tárgyalja. [18] Kitalált példa: a megszerzett rendszer más célpontok felé küld nagy mennyiségű forgalmat. A vizsgálatban ilyenkor azt kell megkülönböztetni, hogy a saját oldal a támadás célpontja, közvetítője vagy a kimenő forgalom forrása.
Szerveroldali kérések kikényszerítésére
Az SSRF, vagyis server-side request forgery olyan helyzet, amikor a támadó a szerverrel kezdeményeztet kérést nem megfelelően ellenőrzött bemenet alapján. Az OWASP a célpontok, protokollok és hálózati elérési lehetőségek korlátozását is tárgyalja. [19]
Ez nem feltétlenül igényel külön telepített malware-t. Kitalált példa: egy külső tartalom lekérésére szolgáló funkció ellenőrzés nélkül fogad címet, és a támadó eltérő cél elérésére használja. Az alkalmazás és a kimenő kapcsolatok vizsgálata együtt adhat választ a működésre.
A bejövő webes védelem nem azonos a kimenő forgalom ellenőrzésével
A Cloudflare proxizott DNS-bejegyzése a támogatott webes kéréseket a Cloudflare hálózatán keresztül vezeti a webhelyhez. Ez a webes kiszolgálás útvonaláról szól, nem a tárhely összes kimenő kapcsolatának általános felügyeletéről. [20]
Hasonló különbség van az alkalmazáson belül is. A WordPress pre_http_request hookja a WordPress HTTP API kéréseit képes megszakítani vagy saját válasszal kezelni. Nem a kiszolgáló összes programjának hálózati tűzfala. [21]
Technikai magyarázat: A webes kérés blokkolása, a WordPress HTTP API korlátozása, a levélküldés leállítása és a szerver kimenő kapcsolatainak szabályozása eltérő beavatkozás. Az intézkedést ahhoz a csatornához kell választani, amelyen a jogosulatlan működés ténylegesen zajlik.
Hogyan állítható helyre a megbízható működés?
A NIST incidenskezelési ajánlása összekapcsolja az észlelést, a reagálást és a helyreállítást. [22] Az alábbi sorrend szerkesztett weboldalas javaslat; az aktuális károkozás alapján kell alkalmazni.
- Azonosítsd a csatornát. Melyik program, fiók vagy funkció küld levelet vagy indít kimenő kapcsolatot?
- Őrizd meg a nyomokat, és korlátozd a károkozást. Rögzítsd az időszakot, üzenetazonosítókat, fájlokat és hozzáférési eseményeket; a szükséges leállítást egyeztesd az üzemeltetővel.
- Kezeld az okot. A jogosulatlan program, a visszaélésre alkalmas funkció és a megszerzett hozzáférés eltérő feladat.
- Ellenőrizd a megmaradt feladatokat és hozzáféréseket. A küldés szüneteltetése nem azonos a bejutási lehetőség megszüntetésével.
- Vizsgáld a függőben lévő küldéseket. A levélsorban jogos üzenetek is lehetnek; a döntést azonosítás alapján kell meghozni.
- Teszteld a szükséges szolgáltatásokat. A valódi űrlapok, értesítések és integrációk ellenőrzött visszaállítása is része a munkának.
- Kövesd a küldést és a kézbesítést. A javított alkalmazásállapot és a levelezési szolgáltatás válaszai külön ellenőrzendők.
A WordPress hivatalos hardening útmutatója a megbízható szoftverforrásokat, az indokolt jogosultságokat, a mentéseket és a megfigyelést is kiemeli. Ezek a felkészülés és a későbbi összehasonlítás alapjai lehetnek. [23]
A következő rész: rosszindulatú botok és automatizált visszaélések
A következő részben a rosszindulatú botokat vesszük sorra: a felderítést, tömeges műveleteket és az alkalmazásfunkciókkal végzett visszaéléseket. Bemutatjuk, milyen jelekből lehet kiindulni, és hogyan különíthető el a szükséges automatizálás a káros működéstől.
Források
Forrásellenőrzés: 2026. november 1. A példák kitalált szemléltető esetek. A vizsgálati táblázat és a helyreállítási sorrend szerkesztett javaslat; konkrét rendszerre vonatkozó diagnózist nem állít. A levelezési funkciók elérhetősége a szolgáltatói környezettől is függ.
- MITRE ATT&CK: Resource Hijacking – T1496.
- PHP: mail().
- PHPMailer: Official project documentation.
- OWASP: Automated Threats to Web Applications.
- RFC 7208: Sender Policy Framework.
- RFC 6376: DomainKeys Identified Mail.
- RFC 7489: Domain-based Message Authentication, Reporting, and Conformance.
- Google: Email sender guidelines.
- OWASP: Logging Cheat Sheet.
- cPanel: Track Delivery.
- cPanel & WHM: Mail Queue Manager.
- PHP: Mail runtime configuration.
- WordPress: wp_mail().
- WordPress: wp_schedule_event().
- Joomla: Mail.
- Joomla: Common Vulnerabilities.
- MITRE ATT&CK: Proxy – T1090.
- MITRE ATT&CK: Network Denial of Service – T1498.
- OWASP: Server Side Request Forgery Prevention.
- Cloudflare: DNS proxy status.
- WordPress: pre_http_request.
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management.
- WordPress: Hardening WordPress.
Ha gyanús, hogy weboldalad vírusos vagy feltört, segítünk a helyreállításban !