2020. aasta esimese kahe kvartali jooksul kasvas DDoS-i rünnakute arv peaaegu kolmekordseks, kusjuures 65% neist olid primitiivsed katsed "koormustestimiseks", mis "keelab" kergesti väikeste veebipoodide, foorumite, ajaveebi ja meediaväljaannete kaitsetud saidid.
Kuidas valida DDoS-kaitsega hostimist? Millele tasuks tähelepanu pöörata ja milleks valmistuda, et mitte sattuda ebameeldivasse olukorda?
(Vaktsineerimine "halli" turustamise vastu)
DDoS-i rünnakute läbiviimiseks kasutatavate tööriistade kättesaadavus ja mitmekesisus sunnib võrguteenuste omanikke võtma asjakohaseid meetmeid ohu vastu võitlemiseks. DDoS-i kaitsele peaksite mõtlema mitte pärast esimest riket ja isegi mitte osana infrastruktuuri tõrketaluvust suurendavate meetmete komplektist, vaid paigutuse saidi (hostimise pakkuja või andmekeskuse) valimise etapis.
DDoS-i rünnakud klassifitseeritakse sõltuvalt protokollidest, mille turvaauke kasutatakse kuni avatud süsteemide vastastikuse ühenduse (OSI) mudeli tasemeni:
- kanal (L2),
- võrk (L3),
- transport (L4),
- rakendatud (L7).
Turvasüsteemide seisukohalt võib need üldistada kahte rühma: infrastruktuuri tasemel ründed (L2-L4) ja rakendustasandi ründed (L7). Selle põhjuseks on liiklusanalüüsi algoritmide täitmise järjestus ja arvutuslik keerukus: mida sügavamalt me IP-paketti uurime, seda rohkem on vaja arvutusvõimsust.
Üldiselt on arvutuste optimeerimise probleem liikluse reaalajas töötlemisel eraldi artiklite seeria teema. Kujutagem nüüd ette, et on olemas tinglikult piiramatute arvutusressurssidega pilveteenuse pakkuja, mis suudab kaitsta saite rakendustaseme rünnakute eest (sh ).
Kolm peamist küsimust DDoS-i rünnakute vastu võitlemise turvalisuse taseme määramiseks
Vaatame DDoS-i rünnakute eest kaitsmise teenusetingimusi ja hostiteenuse pakkuja teenusetaseme lepingut (SLA). Kas need sisaldavad vastuseid järgmistele küsimustele:
- milliseid tehnilisi piiranguid teenusepakkuja kehtestab??
- mis juhtub, kui klient ületab piirid?
- Kuidas loob hostingu pakkuja kaitset DDoS-i rünnakute vastu (tehnoloogiad, lahendused, tarnijad)?
Kui te seda teavet ei leidnud, on see põhjus kas mõelda teenusepakkuja tõsidusele või korraldada omal käel DDoS-i põhikaitse (L3-4). Näiteks tellige füüsiline ühendus spetsialiseeritud turvateenuse pakkuja võrguga.
Tähtis! Rakenduse tasemel rünnakute eest pole mõtet pöördpuhverserverit kasutada, kui teie hostiteenuse pakkuja ei suuda pakkuda kaitset infrastruktuuri tasemel rünnakute eest: võrguseadmed on ülekoormatud ja muutuvad kättesaamatuks, sealhulgas pilveteenuse pakkuja puhverserveritele (joonis). 1).
Joonis 1. Otsene rünnak hostingu pakkuja võrgule
Ja ärge laske neil rääkida teile muinasjutte, et serveri tegelik IP-aadress on turvateenuse pakkuja pilve taga peidus, mis tähendab, et seda pole võimalik otse rünnata. Üheksal juhul kümnest ei ole ründajal keeruline leida serveri või vähemalt hostiteenuse pakkuja võrgu tegelikku IP-aadressi, et terve andmekeskus "hävitada".
Kuidas häkkerid tõelise IP-aadressi otsimisel tegutsevad
Spoilerite all on mitu meetodit tegeliku IP-aadressi leidmiseks (antud informatiivsel eesmärgil).
1. meetod: otsige avatud allikatest
Otsingut saate alustada võrguteenusega: see otsib pimedas veebis, dokumentide jagamise platvormidel, töötleb Whoisi andmeid, avalikke andmelekkeid ja paljusid muid allikaid.
Kui mingite märkide (HTTP päised, Whoisi andmed jne) põhjal oli võimalik kindlaks teha, et saidi kaitse on korraldatud Cloudflare'i abil, siis saab päris IP-d otsima hakata alates, mis sisaldab umbes 3 miljonit Cloudflare'i taga asuvate saitide IP-aadressi.
SSL-sertifikaadi ja teenuse kasutamine leiate palju kasulikku teavet, sealhulgas saidi tegeliku IP-aadressi. Oma ressursi päringu loomiseks minge vahekaardile Sertifikaadid ja sisestage:
_parsed.names: nimisait JA tags.raw: usaldusväärne
SSL-sertifikaadi abil serverite IP-aadresside otsimiseks peate ripploendi mitme tööriistaga käsitsi läbi käima (vahekaart „Uuri”, seejärel valige „IPv4 hostid”).
2. meetod: DNS
DNS-kirje muudatuste ajaloost otsimine on vana, end tõestanud meetod. Saidi eelmine IP-aadress võib teha selgeks, millises hostimises (või andmekeskuses) see asus. Kasutuslihtsuse poolest paistavad võrguteenuste hulgas silma järgmised: и .
Seadete muutmisel ei kasuta sait kohe pilveturbe pakkuja IP-aadressi või CDN-i, vaid töötab mõnda aega otse. Sel juhul on võimalik, et IP-aadressi muudatuste ajaloo salvestamise võrguteenused sisaldavad teavet saidi lähteaadressi kohta.
Kui pole midagi peale vana DNS-serveri nime, saate spetsiaalsete utiliitide (dig, host või nslookup) abil küsida IP-aadressi saidi domeeninime järgi, näiteks:
_dig @vana_dns_serveri_nimiсайта
3. meetod: email
Meetodi idee on kasutada tagasiside/registreerimisvormi (või mõnda muud meetodit, mis võimaldab teil kirja saatmist algatada), et saada oma meilile kiri ja kontrollida päiseid, eelkõige välja “Saadud”. .
Meili päis sisaldab sageli MX-kirje (meilivahetusserveri) tegelikku IP-aadressi, mis võib olla lähtepunktiks sihtmärgilt teiste serverite leidmisel.
Otsingu automatiseerimise tööriistad
Cloudflare'i kilbi taga olev IP-otsingutarkvara töötab enamasti kolme ülesande jaoks:
- Otsige DNS-i valesti konfiguratsiooni, kasutades veebisaiti DNSDumpster.com;
- Crimeflare.com andmebaasi skannimine;
- otsige alamdomeene sõnastikuotsingu meetodil.
Alamdomeenide leidmine on sageli neist kolmest kõige tõhusam variant – saidi omanik võib põhisaiti kaitsta ja jätta alamdomeenid otse tööle. Lihtsaim viis kontrollimiseks on kasutada .
Lisaks on olemas utiliidid, mis on mõeldud ainult alamdomeenide otsimiseks sõnastikuotsingu abil ja avatud allikatest otsimiseks, näiteks: või .
Kuidas otsing praktikas toimub
Võtame näiteks saidi seo.com kasutades Cloudflare'i, mille leiame tuntud teenust kasutades (võimaldab teil määrata nii tehnoloogiad / mootorid / CMS-i, millel sait töötab, kui ka vastupidi - otsida saite kasutatud tehnoloogiate järgi).
Kui klõpsate vahekaardil IPv4 hostid, kuvab teenus sertifikaati kasutavate hostide loendi. Vajaliku leidmiseks otsige avatud pordiga 443 IP-aadress. Kui see suunab soovitud saidile, on ülesanne lõpetatud, vastasel juhul peate lisama saidi domeeninime saidi päisesse "Host". HTTP päring (näiteks *curl -H "Host: saidi_nimi" *).
Meie puhul ei andnud otsing Censysi andmebaasis midagi, nii et liigume edasi.
Teenuse kaudu teostame DNS-otsingu.
Otsides CloudFaili utiliidi abil DNS-serverite loendites mainitud aadresse, leiame tööressursse. Tulemus on valmis mõne sekundi pärast.
Kasutades ainult avatud andmeid ja lihtsaid tööriistu, määrasime veebiserveri tegeliku IP-aadressi. Ülejäänu on ründaja jaoks tehnika küsimus.
Pöördume tagasi hostingu pakkuja valiku juurde. Et hinnata teenusest kliendile kasu, kaalume võimalikke kaitsemeetodeid DDoS-i rünnakute eest.
Kuidas hostingu pakkuja kaitset loob
- Oma kaitsesüsteem koos filtreerimisseadmetega (joonis 2).
Vajab:
1.1. Liikluse filtreerimise seadmed ja tarkvara litsentsid;
1.2. Täiskohaga spetsialistid selle toetamise ja toimimise eest;
1.3. Interneti-juurdepääsukanalid, millest piisab rünnakute vastuvõtmiseks;
1.4. Märkimisväärne ettemakstud kanali ribalaius rämpsliikluse vastuvõtmiseks.
Joonis 2. Majutusteenuse pakkuja enda turvasüsteem
Kui käsitleme kirjeldatud süsteemi kui kaitsevahendit tänapäevaste sadade Gbps kiiruste DDoS-rünnakute eest, maksab selline süsteem palju raha. Kas hostingu pakkujal on selline kaitse olemas? Kas ta on valmis "rämpsu" liikluse eest maksma? Ilmselgelt on selline majandusmudel pakkuja jaoks kahjumlik, kui tariifid ei näe ette lisatasusid. - Reverse Proxy (ainult veebisaitide ja mõne rakenduse jaoks). Vaatamata arvule , ei garanteeri tarnija kaitset otseste DDoS-rünnakute eest (vt joonis 1). Hostingi pakkujad pakuvad sageli sellist lahendust imerohina, nihutades vastutuse turvateenuse pakkujale.
- Spetsialiseerunud pilveteenuse pakkuja teenused (tema filtreerimisvõrgu kasutamine), et kaitsta DDoS-i rünnakute eest kõigil OSI tasemetel (joonis 3).
Joonis 3. Terviklik kaitse DDoS-i rünnakute vastu spetsiaalse teenusepakkuja abil
eeldab mõlema poole sügavat integratsiooni ja kõrgetasemelist tehnilist pädevust. Liikluse filtreerimisteenuste sisseostmine võimaldab hostingu pakkujal alandada kliendile lisateenuste hinda.
Tähtis! Mida üksikasjalikumalt kirjeldatakse pakutava teenuse tehnilisi omadusi, seda suurem on võimalus nõuda nende rakendamist või kompenseerimist seisaku korral.
Lisaks kolmele põhimeetodile on palju kombinatsioone ja kombinatsioone. Majutust valides on kliendil oluline meeles pidada, et otsus ei sõltu mitte ainult garanteeritud blokeeritud rünnakute suurusest ja filtreerimise täpsusest, vaid ka reageerimise kiirusest ja teabe sisust (blokeeritud rünnakute loend, üldine statistika jne).
Pidage meeles, et maailmas suudavad vastuvõetaval tasemel kaitset pakkuda vaid vähesed hostingu pakkujad, muudel juhtudel aitab koostöö ja tehniline kirjaoskus. Seega võimaldab DDoS-i rünnakute vastase kaitse korraldamise põhiprintsiipide mõistmine saidi omanikul mitte langeda turundusnippidesse ega osta "siga kotis".
Allikas: www.habr.com