# Javítatlan PHP tömeges keresése: így zajlanak az automatizált támadások

> Automatizált támadások webszerverek ellen: hogyan zajlik a javítatlan PHP tömeges keresése, miért célpontok a kis cégek, és mit tehet ellene.

Forrás: https://phpsos.de/hu/blog/automatisierte-massenscans/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** A webszerverek elleni automatizált támadások hullámokban zajlanak: programok átfésülik az internetet elérhető szerverek után, külső jellemzők alapján besorolják őket, és tömegesen kipróbálják az ismert réseket, például a PHP2Shellt. A vállalat mérete közben nem számít. Védelmet a javított PHP, a kis támadási felület és egy olyan felügyelet nyújt, amely gyorsan észreveszi a sikeres találatokat.

## A kiindulópont: „Kit érdekelne a mi weboldalunk?”

Ezt a kérdést a PHP2Shell után gyakran halljuk, különösen kisebb vállalatoktól. Az őszinte válasz: valószínűleg személyesen senkit. De az ilyen jellegű réseknél ez nem is szükséges. A támadásokat olyan programok hajtják végre, amelyek nem nevekre, hanem alkalmakra keresnek.

A BSI (a német szövetségi információbiztonsági hivatal) a PHP2Shell esetében gyors, nagy léptékű kihasználással számolt. A Cloudflare támadási kísérletekről számolt be, és arról, hogy a támadók módosították a mintáikat a védelmi szabályok megkerülésére. Mindkettő illik ahhoz, ami széles körben elterjedt szoftver kritikus résein rendszeresen történik.

## Hogyan zajlanak az automatizált támadások webszerverek ellen

Az automatizált kampányok többnyire hasonló mintát követnek. Az alábbi áttekintés általánosan írja le a fázisokat, támadási részletek nélkül:

| Fázis | Mi történik | Mi segít ellene |
|---|---|---|
| Keresés | Programok nagy címtartományokat vagy nyilvános jegyzékeket, például tanúsítványnaplókat vizsgálnak elérhető webszerverek után | kevés nyilvánosan elérhető rendszer, az összes cím leltára |
| Besorolás | A válaszokat kiértékelik: webszerver, PHP-verzió, CMS, tipikus útvonalak | verziójelzések elrejtése, felesleges fájlok eltávolítása |
| Kipróbálás | Ismert réseket tömegesen tesztelnek, gyakran előzetes besorolás nélkül | aktuális PHP, újraindítás, WAF kiegészítő rétegként |
| Berögzülés | Siker esetén egy hátsó ajtót helyeznek el, például webshellt vagy cron-feladatot | korlátozott írási jogok, nincs PHP-futtatás a feltöltési mappákban |
| Hasznosítás | A szervert használják, például spamre, kriptobányászatra, átirányításokra vagy adatlopásra | a folyamatok, fájlok és kimenő kapcsolatok felügyelete |

A harmadik sor fontos. Sok kampány nem is veszi a fáradságot, hogy előtte pontosan besorolja a szervereket. Egyszerűen kipróbál mindent, ami elérhető. Ezért a feltűnésmentesség önmagában nem véd.

### Miért jönnek a támadások hullámokban

Az automatizált kampányok ritkán futnak le egyszer, majd soha többé. Jellemző a hullámokban érkező minta. Az első hullám röviddel egy rés ismertté válása után jön, gyakran még kiforratlan eszközökkel. További hullámok jönnek, amikor a támadók javítják az eszközeiket, vagy hozzáigazítják a védelmi szabályokhoz. A Cloudflare a PHP2Shellnél pontosan ezt figyelte meg: módosított támadási mintákat a szabályok megkerülésére.

Az Ön számára ez azt jelenti: az a szerver, amely az első hullámot sértetlenül átvészelte, nem tartósan biztonságos, amíg javítatlan. Egy újonnan felállított szerver pedig attól a pillanattól célpont, hogy elérhető. Aki például új TLS-tanúsítványt állíttat ki, láthatóvá teszi a nevet a nyilvános tanúsítványnaplókban, amelyeket a szkennerek is kiértékelnek. Egy új rendszert ezért csak akkor szabad a hálózatra tenni, ha már frissített.

## Miért érintettek a kis cégek is ugyanúgy

Az automatizált támadásoknál nem egyetlen célpont értéke számít, hanem a mennyiség. Egy kisvállalkozás szervere számítási teljesítményt, jó hírű domaint, levélküldést és néha ügyféladatokat kínál. A támadóknak ez elég.

Ehhez jön: a kisebb vállalatoknak gyakran nincs saját IT-juk, amely azonnal telepítené a frissítéseket. A szervereik tovább maradnak sebezhetők, és ezért gyakrabban kerülnek a szkennerek találati listáiba. Aki elsőként javít, kiesik ezekből a listákból.

Egy további pont az ellátási lánc. Sok kis weboldal ügynökségek vagy kis tárhelyszolgáltatók szerverein van, ahol tucatnyi ügyfélprojekt fut egymás mellett. A támadók számára egy ilyen szerver különösen kifizetődő, mert egyetlen találat egyszerre sok weboldalt érint. Az Ön kockázata ilyenkor nemcsak a saját gondosságától függ, hanem a szolgáltatójáétól is.

> **Fontos:**
> A naplóiban lévő szkennelések normálisak, és nem bizonyítják a betörést. Egy sikeres támadás más nyomokban mutatkozik meg: új fájlok, idegen folyamatok, ismeretlen fiókok, szokatlan kimenő kapcsolatok.

## Mit ellenőrizhet maga

A naplók áttekintése megmutatja, mennyire szkennelik a szerverét. A következő parancsok csak olvasnak, és nem változtatnak semmit:

```bash
# A tíz cím a legtöbb kéréssel az aktuális hozzáférési naplóban
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

# A „nem található” válasszal megválaszolt kérések gyakoriság szerint
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Kiadja a szerver a PHP-verzióját a fejlécben?
curl -sI https://www.example.de/ | grep -i "x-powered-by"
```

A nem létező útvonalakra érkező sok kérés tipikus szkennelési zaj. Akkor legyen figyelmesebb, ha az ilyen kérésekre hirtelen sikeres válaszok következnek, ha a feltöltési mappákban olyan fájlokat hívnak meg, amelyeket nem ismer, vagy ha a webszerver-felhasználó olyan folyamatokat indít, amelyeket egyébként soha. A PHP2Shellhez kifejezetten megerősített felismerési jegyek eddig nincsenek, a besorolás ezért ilyen viselkedési furcsaságokon alapul. Hogyan értékelheti alaposabban a naplókat, azt a [Webszerver-naplók kiértékelése](https://phpsos.de/hu/ratgeber/logfiles-auswerten/) útmutató írja le. Ha a harmadik lekérdezés PHP-verziót mutat, megéri az `expose_php = Off` beállítás; a háttér a [Verziójelzések elrejtése](https://phpsos.de/hu/blog/expose-php-versionsangaben/) oldalon található.

## A védelmi rétegek a helyes sorrendben

1. **A PHP frissítése és újraindítása:** Ez a lépés nélkül minden más intézkedés foltozás marad.
2. **A támadási felület csökkentése:** a nem használt weboldalakat, tesztrendszereket és régi mikrooldalakat le kell állítani vagy bejelentkezés mögé tenni.
3. **Szabályok a peremen:** Egy gondozott szabályrendszerű Web Application Firewall, például a [ModSecurityvel használt OWASP Core Rule Set](https://phpsos.de/hu/blog/modsecurity-owasp-crs/), a kísérletek egy részét elfogja.
4. **Az ismételt kísérletek lassítása:** Az olyan eszközök, mint a [Fail2ban](https://phpsos.de/hu/blog/fail2ban-fuer-webserver/), kizárják azokat a címeket, amelyek feltűnően sok hibát okoznak. Az elosztott szkennelések ellen ez csak korlátozottan segít.
5. **Felügyelet:** Tartsa szemmel a webszerver-felhasználó folyamatait, az új PHP-fájlokat és a kimenő kapcsolatokat, hogy egy sikeres találat ne maradjon hetekig észrevétlen.

## Hogyan segít konkrétan a PHP SOS?

- **A támadási felület felmérése:** Meghatározzuk, hogy mely rendszerei érhetők el kívülről, és mit árulnak el magukról.
- **Javítás és keményítés:** Frissítjük a PHP-t, újraindítunk, és csökkentjük a verziójelzéseket, az írási jogokat és a szükségtelen szolgáltatásokat.
- **Szabályok és tiltások:** Az alkalmazásához illő WAF-szabályokat és tiltási mechanizmusokat állítunk be.
- **Folyamatos felügyelet:** Jelezzük a feltűnő folyamatokat, fájlokat és kapcsolatokat, mielőtt egy találatból incidens lenne.

Hogyan néz ki ez folyamatos üzemben, azt a [Biztonsági monitoring webszerverekhez](https://phpsos.de/hu/leistungen/security-monitoring/) írja le.

## Összegzés

Az automatizált támadások nem kérdezik, kié a szerver. Csak azt kérdezik, sebezhető-e. A legjobb válasz erre nem látványos: gyorsan javítani, keveset kínálni, pontosan figyelni. Aki ezt teszi, tovább szkennelik, de már nem találják meg.


## Gyakori kérdések

**Célpontjai a kis vállalatok az automatizált támadásoknak?**  
Igen. Az automatizált szkennelések az elérhető szervereket az üzemeltető személyétől függetlenül vizsgálják. Hogy egy konszern vagy egy kisiparos áll mögötte, a szoftver számára nem számít. Az a döntő, hogy a szerver sebezhetőnek látszik.

**Miből ismerem fel a szkenneléseket a naplóimban?**  
Jellemzők a sok kérés olyan útvonalakra, amelyek az Ön weboldalán egyáltalán nem léteznek, gyakran változó címekről és feltűnő azonosítókkal. Az ilyen bejegyzések normálisak, és még nem bizonyítják sikeres támadást, de jelzik, hogy a szerverét vizsgálják.

**Segít, ha elrejtem a PHP-verziót?**  
Kissé megnehezíti a szkennerek számára, hogy célzottan besorolják a szerverét, és értelmes alapbeállítás. De nem véd az olyan támadások ellen, amelyek egyszerűen minden szervert kipróbálnak. A frissítés továbbra is kötelező.

**Teljesen megakadályozhatom a szkenneléseket?**  
Nem. Minden nyilvánosan elérhető szervert rendszeresen szkennelnek. A cél nem a szkennelések megakadályozása, hanem annak biztosítása, hogy semmit se találjanak: naprakész szoftver, kis támadási felület és egy felügyelet, amely jelzi a feltűnő jelenségeket.

## Források

- [Cloudflare-blog: Cloudflare deploys protections against php2shell vulnerability](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/)
- [PHP-kézikönyv](https://www.php.net/manual/de/)
- [OWASP ModSecurity Core Rule Set](https://coreruleset.org/)
- [BSI: a német Szövetségi Információbiztonsági Hivatal](https://www.bsi.bund.de/)