Röviden: Hogy DDoS vagy hackertámadás történt, azt a nyomok mutatják. A DDoS nagyon sok kérést generál, és lassúvá vagy elérhetetlenné teszi a weboldalt, de semmit sem módosít. Egy exploitnak gyakran csak néhány kérés kell, és új fájlokat, fiókokat, folyamatokat vagy kapcsolatokat hagy maga után. A helyes besorolás dönti el, hogy terhelést kell-e elhárítania, vagy egy incidenst kell megfékeznie.
A különbség egyszerű szavakkal
A DDoS-támadás (Distributed Denial of Service) olyan, mint egy tömeg, amely elzárja egy üzlet bejáratát. Senki sem jut be, de az üzletben nem lopnak semmit. A cél az, hogy túlterhelje a weboldalát vagy a szerverét, hogy a valódi ügyfelek ne jussanak át.
Az exploit ezzel szemben egy nyitott ajtón át történő behatolás. A támadó egy sebezhetőséget használ ki, például a PHP-ban, a CMS-ben vagy egy bővítményben, hogy kódot futtasson a szerverén. Ez csendben is megtörténhet, anélkül hogy a weboldal lassabb lenne. A következmények a spam-oldalaktól az adatlopáson át a szerver átvételéig terjednek.
A vezetőség számára a különbség döntő: a DDoS elérhetőségi probléma, amely a támadással véget ér. Egy sikeres exploit biztonsági incidens, amely addig marad, amíg meg nem találják, nem tisztítják meg és nem dokumentálják.
DDoS vagy hackertámadás: a jelek összehasonlítása
A következő táblázat segít az első besorolásban. Elemzést nem pótol, de megmutatja, hová nézzen először.
| Jegy | Inkább DDoS | Inkább exploit vagy behatolás |
|---|---|---|
| Elérhetőség | lassú vagy kiesett | gyakran normális |
| Kérések a naplóban | nagyon sok, gyakran egyenletes | kevés, célzott kérés |
| Fájlok | változatlanok | új vagy módosított PHP-fájlok |
| Fiókok | változatlanok | új adminok, megváltoztatott jelszavak |
| Folyamatok | webszerver és PHP teljes terhelés alatt | ismeretlen folyamatok, bányászat, spamküldés |
| Hálózat | sok bejövő forgalom | szokatlan kimenő kapcsolatok |
| A vége után | minden olyan, mint előtte | a nyomok megmaradnak |
Figyelem az átfedéseknél: egy rés tömeges keresése úgy nézhet ki, mint egy kis DDoS. A PHP2Shell környékén éppen ez volt várható, amikor a támadók sebezhető szervereket kerestek. A magas terhelés tehát azt is jelentheti, hogy valaki éppen betörni próbál.
Első ellenőrzések a szerveren
A következő parancsok nem változtatnak semmin a rendszeren, és gyors áttekintést adnak. Behatolás gyanúja esetén mentse a naplókat, mielőtt nagyobb beavatkozásokat végezne.
# Terhelés és futásidő
uptime
# Összefoglalt kapcsolatok és a leggyakoribb ellenoldalak
ss -s
ss -tn state established | awk 'NR>1 {print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head
# A leggyakoribb kliens-címek az access-naplóban (az útvonalat igazítsa)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# Az elmúlt 7 napban módosított PHP-fájlok
find /var/www -type f -name '*.php' -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# A legnagyobb CPU-terhelésű folyamatok
ps aux --sort=-%cpu | head -15
A kapcsolatáttekintésnél a negyedik oszlop mutatja az ellenoldalt. Sok kapcsolat kevés címről, vagy a normál érték többszörösére való emelkedés túlterhelésre utal. Új PHP-fájlok a feltöltési vagy gyorsítótár-könyvtárakban, a webszerver-felhasználó alatt futó, idegen nevű folyamatok vagy ismeretlen célok felé irányuló kimenő kapcsolatok inkább behatolásra utalnak. Egy részletes listát a A feltörés jelei a PHP2Shell után oldalon talál.
Miért lehet a magas terhelés elterelő hadmozdulat is
Előfordul, hogy a támadók túlterhelést idéznek elő, miközben egyidejűleg célzottan betörnek. A csapat ekkor az elérhetőséggel van elfoglalva, és a tényleges nyomok elvesznek a naplózajban. Ezért érvényes: még ha egy DDoS nyilvánvaló is, a vége után ellenőrizze a fájlokat, a fiókokat és a kimenő kapcsolatokat.
A PHP2Shell esetében ehhez jön még, hogy a php.net és a biztonsági cégek szerint nincsenek közzétett, megerősített Indicators of Compromise. A felismerés viselkedéselemzésen alapul. Egy olyan szervert, amely az október közepétől tartó szkennelési időszakban javítatlan volt, ezért a megfigyelt terheléstől függetlenül ellenőrizni kell.
Egy további változat az zsarolólevelek, amelyekben DDoS-támadással fenyegetnek, ha nem fizet. Őrizze meg az ilyen üzeneteket, ne fizessen szakemberekkel való egyeztetés nélkül, és vizsgálja meg a feljelentést a Zentrale Ansprechstelle Cybercrime-nál (a kiberbűnözés központi kapcsolattartó pontja, Németország). Tájékoztassa párhuzamosan a tárhelyszolgáltatóját, hogy védelmi intézkedéseket lehessen előkészíteni. Hogyan értékelheti ehhez a naplókat, azt a Webszerver-naplók kiértékelése egy támadás után útmutató írja le.
Mit tegyen az első órákban
DDoS gyanúja esetén:
- Tájékoztassa a tárhelyszolgáltatót vagy az adatközpontot; ott gyakran vannak szűrők a szerver előtt.
- Aktiváljon vagy szigorítson egy előtte álló védelmi szolgáltatást vagy egy WAF-ot virtuális javítással.
- Állítson be rate limiteket a webszerverben, és különösen védje a költséges oldalakat, mint a keresés vagy a kosár.
- Őrizze meg a naplókat, hogy a támadás később visszakövethető legyen.
Behatolás gyanúja esetén:
- Ne töröljön semmit, és ne telepítse újra a szervert, mielőtt a naplók és az érintett fájlok le nem lettek mentve.
- Frissítse a PHP-t javított verzióra, és indítsa újra az összes workert, ha ez még nem történt meg.
- Ha a frissítés nem lehetséges azonnal, vegye le a weboldalt átmenetileg a hálózatról, ahogy a BSI javasolja.
- A hozzáférési adatokat egy tiszta eszközről újítsa meg, nem a lehetségesen érintett szerverről.
- Ellenőriztesse, hogy személyes adatok érintettek lehetnek-e; ekkor bejelentési határidők futhatnak.
Mindkét esetben segít egy rövid, tárgyszerű feljegyzés a tárhelyszolgáltatónak és a szolgáltatóknak: mióta áll fenn a probléma, mely weboldalak érintettek, mit figyelt meg, és mit változtatott már meg. Rögzítse emellett, hogy ki melyik döntést hozta. Ez az idővonal időt takarít meg az elemzésnél, és később értékes a biztosítás, az adatvédelem és a belső utómunka számára. Ha nem világos, hogy egyáltalán támadás áll-e fenn, kezelje a helyzetet elővigyázatosságból incidensként, amíg az ellenkezője be nem bizonyosodik.
Hogyan segít konkrétan a PHP SOS?
- Távolról besoroljuk a helyzetet a terhelés, a naplók, a fájlok és a kapcsolatok alapján, és megmondjuk, valószínűleg mivel van dolga.
- Túlterhelés esetén szűrőket, rate limiteket és előtte álló védelmi szabályokat állítunk be, amíg a támadás el nem hal.
- Behatolás gyanúja esetén átvesszük a strukturált incidenskezelést (incident response): mentés, megfékezés, az ok megtalálása, megtisztítás.
- A végén dokumentáljuk, mi történt, és mely intézkedéseket hajtottuk végre, az incidens lezárásáig.
Gyakori kérdések
Ellophat adatokat egy DDoS-támadás?
A tisztán DDoS-támadás az elérhetőséget célozza, nem az adatokat. Nem módosít fájlokat, és nem olvas adatbázisokat. Egy behatolási kísérlettel azonban egyidejűleg is jelentkezhet, ezért ennek ellenére érdemes megnézni a fájlokat és a fiókokat.
Miről ismerem fel, hogy feltörték a weboldalamat?
Tipikus jelek az új vagy módosított PHP-fájlok, az ismeretlen rendszergazdai fiókok, az idegen oldalakra irányuló átirányítások, a váratlan kimenő kapcsolatok és az olyan folyamatok, amelyek nem illenek az alkalmazásához. Egyetlen jel nem bizonyíték, több együtt komoly jelzés.
Segít a CDN vagy a WAF mindkét támadástípus ellen?
A volumetrikus támadások ellen egy előtte álló szolgáltatás többnyire jól segít. Az exploitok ellen a szabályok csak akkor hatnak, ha felismerik a mintát. A PHP2Shellnél a Cloudflare maga is rámutat, hogy a pusztán a kérésadatokon alapuló szabályok nem elegendők.
Be kell jelentenem egy DDoS-támadást?
Ez az egyedi esettől és az Ön ágazatától függ. Személyes adatokhoz való hozzáférés nélkül a GDPR szerinti bejelentési kötelezettség általában nem áll fenn, ágazatspecifikus kötelezettségek azonban létezhetnek. Tisztázza az adatvédelmi felelősével vagy egy ügyvéddel.