[Műszaki elemzés] Mélyreható és könnyen érthető: Bevezetés a hálózati támadás és védelem támadásába

A DDoS (Distributed Denial of Service) támadások az egyik legerősebb és legnehezebb védekezés, mert a DDoS támadások fő célja, hogy megakadályozzák egy kijelölt célpont normál szolgáltatást nyújtását, vagy akár az internetről való eltűnését.

A DDoS-t egyszerűen három kategóriába lehet sorolni a kezdeményezés módja szerint.

Az első kategória erővel nyerHatalmas adatcsomagok zúdítanak az internet minden szegletéből, elzárva az IDC bejáratát, így a különböző erős hardveres védelmi rendszereket és a gyors, hatékony vészfolyamatokat használhatatlanná teszik. Tipikus példák erre a támadásra az ICMP Flood és az UDP Flood, amelyek ma már ritkák.

A második kategória az ügyesség győzelokos és észrevehetetlen, néhány percenként küld csomagot, vagy akár csak csomagra van szükség, így a luxus konfigurációs szerver már nem reagál. Ezt a támadást főként protokollok vagy szoftverek sebezhetőségeinek kihasználásával indítják, mint például Slowloris támadások, hash ütközési támadások stb., és speciális környezeti véletleneket igényelnek.

A harmadik kategória a fenti kettő keverékeNemcsak a protokoll és a rendszer hibáit használja ki, hanem nagy mennyiségű forgalmat is tartalmaz, például a SYN Flood támadást és DNS Query Flood támadást, amelyek a jelenlegi fő támadási módszer.

Ez a cikk sorra ismerteti ezeket a leggyakoribb és legreprezentatívabb támadási módszereket, és bemutatja védekezési lehetőségeiket.

A SYN Flood az egyik legklasszikusabb DDoS támadás az interneten, amely először körülbelül 1999-ben jelent meg, és a Yahoo volt a leghíresebb áldozat akkoriban. A SYN Flood támadások kihasználják a TCP hármas kézfogási hibáit, amelyek alacsony költséggel a célszervert nem reagálóvá és nehezen követhetővé teszik.

A TCP szabványos háromféle kézfogási eljárása a következő:

• Az ügyfél TCP csomagot küld, amely tartalmazza a SYN zászlót, a SYN szinkronizálja, és a szinkronizációs csomag jelzi az ügyfél által használt portot és a TCP kapcsolat kezdeti sorozatszámát.
• Miután megkapta a SYN csomagot az ügyféltől, a szerver egy SYN+ACK (azaz Visszaigazolás) csomagot küld vissza, jelezve, hogy az ügyfél kérését elfogadták, és a TCP kezdeti sorozatszáma automatikusan hozzáadódik 1-vel.
• Az ügyfél visszaadja az ACK visszaigazolási üzenetet a szervernek, és a TCP sorozatszámot is hozzáadja az 1-essel.
  

E három lépés után létrejön a TCP kapcsolat. A megbízható átvitel érdekében a TCP protokoll néhány kivételkezelési mechanizmust hozott létre a három kézfogás alatt. A harmadik lépésben, ha a szerver nem kapja meg a végső ACK visszaigazolási csomagot az ügyféltől, a szerver SYN_RECV állapotban marad, hozzáadja a kliens IP-címet a várólistához, és a második lépésben újra elküldi a SYN+ACK csomagot. Az újraküldéseket általában 3-5 alkalommal végzik, és a várólistát körülbelül 30 másodperces időközönként kérdezik, hogy minden klienst újra megpróbáljanak. Másrészt, miután a szerver elküldi a SYN+ACK csomagot, előre kijelöli az erőforrásokat a közelgő TCP kapcsolat adataihoz, amelyeket megőriznek a próbálkozás megvárása alatt. Ami még fontosabb, ha a szerver erőforrásai korlátozottak, a fenntartható SYN_RECV állapot már nem fogad el új SYN csomagokat a korlát túllépése után, vagyis az új TCP kapcsolatokat elutasítják.

A SYN Flood a fenti TCP protokoll beállításokat használja a támadás céljának eléréséhez. A támadók sok IP-címet rejtenek, hogy SYN csomagokat küldjenek a szerverre, és mivel a hamisított IP-címek szinte lehetetlenek létezni, szinte egyetlen eszköz sem válaszol a szerverre. Ennek eredményeként a szerver hatalmas várólistát tart fenn, és újra próbál SYN+ACK csomagokat küldeni, ami rengeteg erőforrást fogyaszt és nem szabadítható ki. Még fontosabb, hogy a támadt szerver SYN_RECV sora rosszindulatú csomagokkal van megtöltve, új SYN kéréseket már nem fogadnak el, és a legitim felhasználók nem tudnak három kézfogást teljesíteni a TCP kapcsolatok létrehozásához. Más szóval, a szervert a SYN Flood megtagadta a szolgáltatástól.

Ha érdekel a SYN Flood, megnézheted a http://www.icylife.net/yunshu/show.php?id=367-t, amit 2006-ban írtam, később több változtatást is végrehajtottam, hibákat javítottam, csökkentettem az agresszivitást, és kizárólag tesztelésre használtam.

Mint az internet legalapvetőbb és legalap szolgáltatása, a DNS természetesen a DDoS támadások egyik legfontosabb célpontja. Egy DNS szolgáltatás leállítása közvetetten ledöntheti egy vállalat egész üzletágát vagy egy hálózati szolgáltatást egy régióban. Néhány ideje a népszerű hackercsoport, az Anonymous is bejelentette, hogy 13 DNS szervert támad meg a globális interneten, de végül nem sikerült.

Az UDP támadások a legegyszerűbb támadási módszerek a hatalmas forgalom elindítására, és a véletlenszerű forrású IP-hamisításokat nehéz nyomon követni. Azonban a szűrés könnyebb, mert a legtöbb IP nem kínál UDP szolgáltatásokat, így egyszerűen eldobhatod az UDP forgalmat. Ezért a tiszta UDP forgalom támadásai ma viszonylag ritkák, és ezeket az UDP protokoll által továbbított DNS Query Flood támadások váltják fel. Egyszerűen fogalmazva, ha a DDoS támadások minél magasabb protokollra indulnak, annál nehezebb megvédeni ellene, mert minél magasabb a protokoll, annál inkább üzleti jellegű, és annál összetettebb a védelmi rendszer.

A DNS lekérdezési áradat akkor történik, amikor egy támadó nagy számú zsebbáb gépet manipulál, hogy rengeteg domainnév-lekérdezési kérést indítson el a célponthoz. Az ACL-alapú szűrés megelőzése érdekében javítani kell a csomagok véletlenszerűségét. Gyakori gyakorlat, hogy véletlenszerűen hamisítják a forrás IP-címet, véletlenszerűen a forrásportot és más paramétereket az UDP rétegen. A DNS protokoll rétegben a lekérdezési azonosítót véletlenszerűen hamisítják meg a megoldandó domain név mellett. A szűrés megakadályozása mellett a véletlenszerű hamisított domainnevek megoldása csökkentheti annak esélyét is, hogy elérje a DNS gyorsítótárt, és minél több CPU-erőforrást fogyaszt el a DNS szerverről.

A DNS Query Flood kódjával kapcsolatban 2011 júliusában írtam egy kódot a szerver teljesítményének tesztelésére, és a link http://www.icylife.net/yunshu/show.php?id=832. Hasonlóképpen, ez a kód mesterségesen kevésbé agresszív, és csak tesztelési célokra szolgál.

A fent leírt SYN Flood és DNS Query Flood ezen a szakaszon hatékonyan védhető ellen, és a nagy gyártók és internetes cégek valódi fejfájása a HTTP Flood támadások. Az HTTP Flood egy webszolgáltatás elleni támadás, amely egy hetedik rétegű protokollon alapul. Nagy kára főként három szempontból nyilvánul meg: kényelmes kezdeményezés, nehéz szűrés és a messzemenő hatás.

Mind a SYN Flood, mind a DNS Query Flood megköveteli a támadóknak, hogy nagy számú botot irányítsanak, amelyek root jogosultsággal rendelkeznek. Időbe és erőfeszítésbe telik sok gyökérjogosultság összegyűjtése, és a támadás során a bábgép lassan töltődik fel, mivel a támadó gyorsan elveszíti az erőforrásokat az adminisztrátor által felfedezett rendellenes forgalom miatt, ami jelentős támadási intenzitáscsökkenést eredményez, és hosszú ideig nem tartható fenn. Az HTTP Flood támadások mások, a támadóknak nem kell sok botot irányítaniuk, hanem portszkennereket használnak, hogy anonim HTTP proxykat vagy SOCKS proxyt találjanak az interneten, amelyeken keresztül a támadó HTTP-kéréseket indít a támadás célpontjának. Az anonim proxyk viszonylag gazdag forrást, és nem nehéz néhány nap alatt megszerezni a proxykat, így a támadások könnyen elindíthatók és hosszú ideig is eltarthatnak.

Másrészt a HTTP áradat támadások a HTTP rétegen indulnak, amelyek erőteljesen utánozzák a normál felhasználók weboldalkérési viselkedését, amely szorosan kapcsolódik a weboldal üzletéhez, így megnehezíti a biztonsági szolgáltatók számára, hogy olyan közös megoldást nyújtsanak ki, amely nem befolyásolná a felhasználói élményt. A szabályok, amelyek egy helyen jól működnek, a helyzetek megváltoztatása sok gondatlan emberöléshez vezethet.

Végül a HTTP flood támadások komoly láncreakciókat okozhatnak, amelyek nemcsak közvetlenül lassú válaszokat okoznak a támadt webfront-endtől, hanem közvetve is támadják a háttérben lévő Java és más üzleti rétegi logikai és háttér-adatbázis szolgáltatásokat, növelve a nyomást, sőt, még a naplótároló szervereket is érintve.

Érdekes módon a HTTP Floodnak is van egy történelmi beceneve, amit CC támadásnak hívnak. A CC a Challenge Collapsar rövidítése, amely egy ismert kínai biztonsági cég DDoS védőeszköze. A jelenlegi helyzet alapján nemcsak a Collapsar, hanem minden hardveres védelmi berendezés továbbra is kihívás alatt áll, és a kockázatot nem szüntették meg.

Támadások esetén az első reakció hatalmas forgalom és hatalmas csomagok lesz. De van egy támadás, ami az ellenkezőjét teszi, ismert, hogy lassú, így egyes támadó célpontok meghalnak anélkül, hogy tudnák, hogyan halnak meg, ami a lassú kapcsolati támadás, a legreprezentáltabb a Slowloris, amelyet a rsnake talált fel.

A HTTP protokoll előírja, hogy a HTTP kérések \r\n\r\n véget érnek, ami azt jelzi, hogy a kliens befejezte a küldést, és a szerver megkezdte a feldolgozást. Mi történik, ha soha nem küldöd el \r\n\r\n? A Slowloris ezt előnyére használja DDoS támadásokban. A támadó a HTTP kérés fejlécében beállítja a Connect-et Keep-Alive (Maradjon életbe), megkéri a webszervert, hogy ne legyen megszakítva a TCP kapcsolat, majd lassan néhány percenként küld kulcs-érték formátumot a szervernek, például a:b\r\n, amitől a szerver azt hiszi, hogy az HTTP fejlécet nem kapta meg, és vár. Ha egy támadó multithreadinget vagy bábot használ ugyanezhez, a szerver webkonténerét gyorsan túlterhelni fogja a támadó szembe, és többé nem fogad új kéréseket.

Hamarosan különböző Slowloris változatok kezdtek megjelenni. Például a POST módszer adatokat küld be a Webszervernek, nagy tartalomhosszúságú, de lassú bájtról bájtra POST valódi adattartalmat tölt ki, stb. A Slowloris támadással kapcsolatban a rsnake tesztkódot is ad, lásd http://ha.ckers.org/slowloris/slowloris.pl.

A fentiek több alapvető támadási módszert vezetnek be, amelyek bármelyike használható a hálózat megtámadására, sőt olyan hatalmas weboldalak, mint az Alibaba, Baidu és Tencent legyőzésére is. De ez még nem minden, különböző szintű támadók teljesen eltérő DDoS támadásokat indíthatnak, és ezek használata ugyanaz.

A fejlett támadók soha nem használnak egyetlen vektort a támadáshoz, hanem rugalmasan kombinálják őket a célkörnyezet alapján. A hagyományos SYN Floodot könnyű kiszűrni a forgalomtisztító eszközök által fordított detektálással, SYN sütikkel és más technikai eszközökkel, de ha a SYN+ACK csomagokat keverik a SYN Flood-ba, így minden hamisított SYN csomagnak van egy hamisított kliens megerősítő csomagja, akkor a megfelelő itt a forrás IP-cím, forrásport, cél IP, célport, TCP ablakméret, TTL stb., mind összhangban van ugyanazon a hoszter és a TCP Flow jellemzőivel. A folyamattisztító berendezések visszafordítási detektálásának és SYN sütik teljesítményére gyakorolt nyomás jelentősen nőni fog. Valójában a SYN adatcsomagok és különféle más zászlóbitek speciális támadási hatásokkal rendelkeznek, amelyeket itt nem vezetnek be. Vannak egyedi technikák a DNS lekérdezési árasztáshoz is.

Először is, a DNS felosztható hétköznapi DNS-re és engedélyezett domain-DNS-re, amely megtámadja a szokásos DNS-t, az IP-címet véletlenszerűen kell hamisítani, és a szerver rekurzív felbontást igényel; Azonban az engedélyezett DNS-t támadásakor a hamisított forrás IP-cím nem teljesen véletlenszerű legyen, hanem az internetszolgáltatók DNS-címeinek előre összegyűjtött DNS-címeinek kell lennie, hogy elérjék a maximális támadási hatást, és a forgalomtisztító eszköz kínos helyzetbe kerüljön, hogy IP-feketelistát adjon vagy nem kell hozzáadni. Ha hozzáadod ezt, sok gondatlan emberöléshez vezet, és ha nem teszünk feketelistát, minden csomagot visszafelé kell vizsgálni, ami növeli a teljesítmény terhelését.

Másrészt, ahogy korábban említettük, a tisztítás nyomásának növelése érdekében a kért domain nevet véletlenszerűen kell kiválasztani anélkül, hogy a gyorsítótárt érintenénk, de meg kell jegyezni, hogy a megoldandó domain névnek bizonyos szabályosságnak kell lennie a hamisításban, például csak egy adott domain részét hamisítani, és egy részt megszilárdítani, hogy áttörje a tisztító eszköz által állított fehérlistát. Az ok egyszerű: a Tencent szerverei csak a Tencent domain neveket tudják megoldani, és a teljesen véletlenszerű domainneveket közvetlenül eldobhatják, és szilárdítani kell. De ha teljesen megjavítják, könnyen eldobható közvetlenül is, ezért meg kell hamisítani.

Másodszor, a DNS elleni támadásoknak nem szabad kizárólag az UDP portokra összpontosítaniuk, amelyek szintén szabványos szolgáltatásoknak számítanak a DNS protokoll szerint. Támadás esetén egyszerre végrehajthatók az UDP és a TCP támadások.

A HTTP Flood célja, hogy áttörje a frontend gyorsítótárát, és közvetlenül elérje magát a Webszervert a HTTP fejlécben található mezőbeállításokon keresztül. Emellett a HTTP Flood nagyon kritikus a célpontok kiválasztásában, és a hétköznapi támadók olyan oldalakat választanak, amelyekhez sok adatlekérdezést igényelnek, például a keresést támadás célpontjának, ami nagyon helyes, és minél több erőforrást fogyaszthat el a szerverből. De ezt a támadást könnyű felismerni tisztító eszközökkel ember-gép azonosítással, szóval hogyan lehet ezt a problémát megoldani? Nagyon egyszerű: próbálj meg olyan oldalakat választani, amelyekhez a normál felhasználók is hozzáférnek az APP-on, általában különböző webes API-kon. A normál felhasználók és a rosszindulatú forgalom az APP-ből érkezik, az ember és gép közötti különbség nagyon kicsi, és nehéz megkülönböztetni az alapvető integrációt.

Minden TCP kapcsolat a szerver oldalon és önmagában is létezik, és erőforrásokat is fogyasztania kell a TCP állapot fenntartásához, így a kapcsolatot nem lehet túl sokat fenntartani. Ha ezt meg lehet oldani, az agresszivitás jelentősen nő, vagyis a Slowloris állam nélküli módon indíthat támadásokat, elfoglalhatja a TCP sorozatszámát, és ellenőrizheti a TCP kapcsolatok karbantartását a kliensen szimatolással, így a rendszermagnak nem kell figyelnie a TCP különböző állapotváltozásaira, így egy notebook akár 65 535 TCP kapcsolatot is generálhat.

Az előző leírások mind technikai támadási fejlesztések. Az emberi oldalon más lehetőségek is vannak. Ha a SYN Flood sok csomagot küld, és Slowloris lassú kapcsolatai kísérik, hányan fedezik fel a titkot? Még ha a szerver leáll, csak SYN támadások is előfordulhatnak, amelyek megpróbálják erősíteni a TCP réteg tisztítását, és figyelmen kívül hagyják az alkalmazásréteg viselkedését. Mindenféle támadás együtt működhet a maximális hatás eléréséhez. A támadási idő kiválasztása is kulcsfontosságú tényező, például ha a karbantartók ebédelés közben választanak ki, amikor a karbantartók munkából való kilépés után az úton ragadnak, vagy amikor nincs jel a metró vezeték nélküli hálózati kártyáján, illetve amikor a célvállalat nagyszabású eseményt tart, és a forgalom megugrik.

Ez tiszta támadás, így nincs kód vagy részletes magyarázat.

A korábbi támadási módszerek többé-kevésbé botokat igényelnek, még a HTTP Flood is nagy számú névtelen proxy keresését igényli. Ha támadás történik, csak néhány utasítást kell adnod, és a gép automatikusan feljön és végrehajtja, ami a tökéletes megoldás. Ez a támadás már megjelent, és ez P2P hálózatokból történik.

Ahogy mindannyian tudjuk, a P2P felhasználók és az interneten elért forgalom rendkívül nagy szám. Ha mindannyian egy kijelölt helyre mennek adatletöltésre és több ezer valódi IP-címhez kötni, egyetlen eszköz sem tudja támogatni. Vegyük például a BT letöltést: néhány népszerű videó torrentjeit hamisítani és keresőmotorokra feltölteni elegendő ahhoz, hogy sok felhasználót és forgalmat megtévesszen, de ez csak egy alapvető támadás.

A fejlett P2P támadások közvetlen hamisítása az erőforrás-kezelő szerverekről. Például a Thunder kliens feltölti az általa talált erőforrásokat az erőforrás-kezelő szerverre, majd továbbítja azokat más felhasználóknak, akiknek le kell tölteniük ugyanazokat az erőforrásokat, így egy linket közzétesznek. A protokoll visszafordításával a támadók nagy mennyiségű népszerű erőforrás-információt hamisítanak meg, amelyeket az erőforrás-kezelő központon keresztül terjesztenek, amely azonnal elterjedhet az egész P2P hálózatban. Ami még rémisztőbb, hogy ezt a támadást még maga a támadó sem tudja megállítani, és a támadás folytatódik, amíg a P2P tisztviselő fel nem találja a problémát, frissíti a szervert, és a letöltő felhasználó újraindítja a letöltött szoftvert.

Ennyi a DDoS támadások bevezetése, és nem akarok tovább menni – elég ahhoz, hogy megértsük: ennyi védelem elég.

Általánosságban a DDoS támadások ügyesek és kecsesek lehetnek. Az alkalmazás szépsége az elme egységében rejlik.