„Poiss, kes meile veebilehe tegi, on juba DDoS kaitse seadistanud.“
„Kuid meil on ju DDoS kaitse, miks veebileht kukkus?“
„K cuanto tuhandeid tahab Qrator?“
Et normaalselt vastata sellistele küsimustele kliendilt/ülemuselt, oleks hea teada, mis peitub nime taga „DDoS kaitse“. Kaitsesüsteemide valik meenutab pigem arsti poolt ravimite valimist kui IKEA-st laua valimist.
Olen tegelenud veebilehtede hooldamisega 11 aastat, ellu jäänud sadadest rünnakutest toetatud teenustele, ja nüüd räägin natuke kaitse siseküljest.
Regulaarsed rünnakud. 350k req kokku, 52k req legaalsed
Esimesed rünnakud ilmusid praktiliselt koos internetiga. DDoS fenomen hakkas massiliseks muutuma 2000. aastate lõpust (vaadake ).
Umbes aastast 2015-2016 hakkasid peaaegu kõik hostimispakkujad DDoS rünnakute kaitsele, nagu ka enamus märgatavaid veebilehti konkurentsivõimelistes valdkondades (tehke whois IP-de järgi saitidelt eldorado.ru, leroymerlin.ru, tilda.ws, näete kaitse operaatorite võrke).
Kui 10-20 aastat tagasi oli enamik rünnakuid võimalik tõrjuda serveris ise (hindake Lenta.ru süsteemiadministraatori Maxim Moshkovi soovitusi 90-ndatest: ), siis on praegu kaitseprobleemid muutunud keerukamaks.
DDoS-rünnakute tüübid kaitseoperaatori valiku vaatenurgast
Rünnakud L3 / L4 tasemel (OSI mudeli järgi)
— UDP spämmi botivõrgust (haavatud seadmetelt saadetakse palju päringuid rünnatavale teenusele, serverid ummistavad ühenduse);
— DNS/NTP/jne amplifikatsioon (haavatud seadmetelt saadetakse palju päringuid nõrkadele DNS/NTP/jne, saatja aadressi valeesitus, hulk pakette vastustega ummistab rünnatava ühenduse; nii tehakse tänapäeval kõige massilisemaid rünnakuid internetis);
— SYN / ACK spämmin (rünnatavatele serveritele saadetakse palju ühenduse loomise päringuid, ühenduste järjekord ummistub);
— rünnakud pakettide fragmentatsiooniga, ping of death, ping flood (palun googeldage);
— jne.
Need rünnakud sihivad «ummistada» serveri kanalit või «tappa» selle võimet uut liiklust vastu võtta.
Kuigi SYN/ACK rünnakud ja amplifikatsioon erinevad oluliselt, suudavad paljud ettevõtted nendega võrdselt hästi toime tulla. Probleemid tekivad järgmise grupi rünnakutega.
Rünnakud L7 (rakendustasandil)
— http flood (kui rünnatakse veebisaiti või mõnda http API-d);
— rünnakute haavatavatele kohtadele saidil (millel pole vahemälu, mis koormavad saiti väga palju jne).
Eesmärk on sundida serverit 'raske töö' tegema, töötlema palju 'nagu tõelisi päringuid' ja jääma ressursita tegelike päringute jaoks.
Kuigi on ka teisi rünnakuid, on need kõige levinumad.
Tõsised rünnakud L7 tasemel on loodud ainulaadselt iga rünnatava projekti jaoks.
Miks kaks rühma?
Sest on palju neid, kes oskavad hästi kaitsta rünnakute eest L3/L4 tasemel, kuid ei võta üldse rakendustasandi (L7) kaitset või suudavad sellega tegeleda nõrgemalt kui alternatiivid.
Kes on kes DDoS kaitse turul
(minu isiklik arvamus)
Kaitse L3/L4 tasemel
Amplifitseeritud rünnakute tõrjumiseks (serveri kanali "koormus") on piisavad laiad kanalid (paljud kaitsesüsteemid on ühendatud Venemaa enamike suurte selgroo pakkujatega ja neil on kanalid, mille teoreetiline maht on üle 1 Tbit). Pea meeles, et väga haruldased amplifitseeritud rünnakud kestavad kauem kui tund. Kui oled Spamhaus ja kõik sind ei armasta — jah, nad võivad proovida kanaleid mitu päeva välja lülitada, isegi kasutatava maailmakuulsa botneti edasise ellujäämise riskiga. Kui sul on lihtsalt veebipood, isegi kui see on mvideo.ru — 1 Tbit mitme päeva jooksul ei näe sa väga varsti (loodan).
SYN/ACK ülekoormuse, pakettide fragmentatsiooni jms rünnakute tõrjumiseks on vajalik varustus või tarkvarasüsteemid selliste rünnakute tuvastamiseks ja tõkestamiseks.
Selliseid seadmeid tootavad paljud (Arbor, lahendused on olemas Cisco, Huawei, Wanguardi tarkvaralised lahendused jne), paljud suuremad operaatorid on need juba installeerinud ja pakuvad DDoS-i kaitse teenuseid (tean installatsioonidest Rostelecomis, MegaFonis, TTK-s, MTS-is, põhimõtteliselt kõigis suurtel teenusepakkujatel, sama teeb ka hostimine oma kaitsega nagu OVH.com, Hetzner.de, olen ise kohanud kaitset ihor.ru-s). Mõned ettevõtted arendavad oma tarkvaralahendusi (tehnoloogiad nagu DPDK võimaldavad töödelda kümneid gigabite liiklust ühe füüsilise x86 masina peal).
Tuntud mängijatest suudavad L3/L4 DDoS rünnakuid tõhusalt peatada kõik. Ma ei ütle, kellel on suurem maksimaalne kanali maht (see on insider-teave), kuid tavaliselt pole see nii oluline, vahe on ainult selles, kui kiiresti kaitse tööle hakkab (kas kohe või mõne minuti jooksul, nagu Hetzneris).
Küsimus on selles, kui kvaliteetselt seda tehakse: amplifikatsiooni rünnaku saab peatada, blokeerides liikluse riikidest, kus on kõige rohkem kahjulikku liiklust, või saab ära visata ainult tõeliselt liigse liikluse.
Kuid minu kogemuste põhjal saavad kõik tõsised turu mängijad selle probleemideta hakkama: Qrator, DDoS-Guard, Kaspersky, G-Core Labs (endine SkyParkCDN), ServicePipe, Stormwall, Voxility jne.
Olen kokku puutunud vaid mõne operaatori, näiteks Rostelecomi, MegaFoni, TTK ja Beeline'i teenustega. Kaaslaste arvamuste kohaselt pakuvad nad neid teenuseid piisavalt kvaliteetselt, kuid vahepeal tuleb siiski tunda kogemuse puudust: mõnikord tuleb toe kaudu midagi veel timmida.
Mõnedel operaatoritel on eraldi teenus "L3/L4 tasandi rünnakute kaitse" või "kanalite kaitse", mis on palju odavam kui kaitse kõigil tasanditel.
Kuidas suudab mitte-magistraalne operaator rünnakuid sadade Gbit-suudelt tagasi peegeldada, kui tal pole oma kanaleid?Kaitseoperaator võib ühenduda mistahes suure operaatoriga ja peegeldada rünnakuid "tema kulul". Kanali eest tuleb maksta, kuid kõiki neid sadu Gbit-suusid ei pruugi vajaduse korral ära kasutada, seega on sellel juhul kanalite kulude märkimisväärne vähendamine võimalik, mistõttu jääb skeem toimima.
Selliseid aruandeid said L3/L4 kaitseseltsist olen regulaarselt saanud, toetades hosting-teenuse pakkuja süsteeme.
L7-taseme (rakendus) kaitse
L7-taseme (rakendus) rünnakud suudavad pidevalt ja kvaliteetselt tõrjuda rünnakut.
Mul on tegelikult piisavalt suur kogemus
— Qrator.net;
— DDoS-Guard;
— G-Core Labs;
— Kaspersky.
Nad küsivad tasu iga puhta megabiti eest, megabit maksab umbes paar tuhat rubla. Kui teil on vähemalt 100 Mbit puhast liiklust — oh. Kaitse on väga kallis. Võin järgnevates artiklites rääkida, kuidas rakendusi projekteerida, et kulusid kaitsekanalite mahtude osas oluliselt kokku hoida.
Reaalne "mäetipp" — Qrator.net, teised jäävad neile alla. Qrator on minu praktikas ainus, kes pakub peaaegu nulli valesid häireid, kuid samas on nende teenus mitmeid kordi kallim kui teiste turu mängijate omi.
Teised operaatorid pakuvad samuti kvaliteetset ja stabiilset kaitset. Paljud teenused, mida me toetame (sealhulgas väga tuntud meie riigis!), on DDoS-Guard, G-Core Labs kaitse all ja on tulemusega täiesti rahul.
Qratori tõrjuda rünnakud
On ka kogemusi väikeettevõtete kaitsesüsteemidega nagu cloud-shield.ru, ddosa.net ja nende sarnastega. Kindlasti ma ei soovita, kuna kogemus pole just suur, aga räägin nende tööpõhimõtetest. Nende kaitse hind on sageli 1–2 korda madalam kui suurte mängijate juures. Reegliks on, et nad ostavad osalist kaitset (L3/L4) kelleltki suuremast ettevõttest ning loovad juurde oma kaitse kõrgematel tasemetel. See võib olla üsna tõhus ja saate head teenust odavamalt, kuid need on siiski väiksed ettevõtted, palun arvestage sellega.
Mis on keeruline rünnakute peegeldamisel L7 tasemel?
Kuna kõik rakendused on ainulaadsed, tuleb lubada neile kasulikku liiklust ja blokeerida kahjulik. Kahjuks ei õnnestu alati robotite eraldamine, mistõttu tuleb kasutada palju, tõeliselt PALJU liikluse puhastamise astmeid.
Kunagi piisab nginx-testcookie moodulist (), ja seda on siiani piisavalt, et peegeldada suurt hulka rünnakuid. Kui töötasin hostimise valdkonnas, kehtestasime L7 kaitse just nginx-testcookiele.
Kahjuks on rünnakud muutunud keerukamateks. testcookie kasutab JavaScripti baasil botide kontrollimisi, ent paljud kaasaegsed botid suudavad need edukalt läbida.
Ründavad botivõrgustikud on samuti unikaalsed ning iga suure botivõrgustiku eripära tuleb arvesse võtta.
Tugevdus, otse rünnak botivõrgustikest, liikluse filtreerimine erinevatest riikidest (erinev filtreerimine erinevates riikides), SYN/ACK rünnakud, pakettide fraktsioneerimine, ICMP, http rünnakud — rakenduse/http tasandil saab välja mõelda piiramatult erinevaid rünnakuid.
Kokkuvõttes võib kanalite kaitse, spetsialiseeritud seadmed liikluse puhastamiseks, spetsiaalne tarkvara ja iga kliendi jaoks kohandatud filtreerimise sätted võtta sadu ja tuhandeid filtreerimistasemete tasemeid.
Selle õigeks haldamiseks ja erinevate kasutajate jaoks filtreerimise seadete korrektseks kohandamiseks on vajalik suur kogemus ja kvalifitseeritud personali olemasolu. Isegi suur operaator, kes otsustab pakkuda kaitseteenuseid, ei saa „lihtsalt raha visata probleemile”: kogemusi tuleb saada langenud saitidel ja vale positiivsete tuvastuste kaudu seaduslikul liikluses.
Ründekaitse operaatoritel puudub nupp «DDoS-vastane»; on olemas mitmesuguseid tööriistu, millega tuleb osata toime tulla.
Ja veel üks näite.
Kaitseta server blokeeriti hostimise pakkuja poolt rünnaku ajal, mille mahuks oli 600 Mbit.
(„Traffic'i kadumist“ ei olnud tunda, kuna rünnatud oli ainult üks veebileht, mis eemaldati serverist ajutiselt ja blokeering eemaldati tunni jooksul).
See sama server on kaitstud. Ründajad „tüdisid ära“ ühe päeva kestnud rünnakute järel. Rünnak ise osutus mitte kõige tugevamaks.
L3/L4 rünnakud ja kaitse on lihtsamad, need sõltuvad peamiselt kanalite tugevusest, rünnakute tuvastamise ja filtreerimise algoritmidest.
L7 rünnakud on keerulisemad ja originaalsemad, need sõltuvad rünnatud rakendusest, ründajate võimalustest ja fantaasiast. Kaitse nende vastu nõuab sügavaid teadmisi ja kogemusi, ning tulemus ei pruugi olla kohene ja mitte 100% kindel. Seni ei ole Google välja mõelnud uut tehisintellekti kaitseks.
Allikas: habr.com
