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.
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:
# 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 ú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 oldalon található.
A védelmi rétegek a helyes sorrendben
- 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.
- 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.
- Szabályok a peremen: Egy gondozott szabályrendszerű Web Application Firewall, például a ModSecurityvel használt OWASP Core Rule Set, a kísérletek egy részét elfogja.
- Az ismételt kísérletek lassítása: Az olyan eszközök, mint a Fail2ban, 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.
- 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 í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.