DDoS-rünnakute täies mahus kaitsega hostimine – müüt või reaalsus

2020. aasta kahel esimesel kvartalil kasvas DDoS-rünnakute arv peaaegu kolm korda, samas kui 65% neist koosneb primitiivsetest „koormustestimise“ katsetest, mis kergesti „väljalülitavad“ kaitseta väikeste veebipoodide, foorumite, blogide ja meedia saite.

Kuidas valida DDoS-rünnakute eest kaitstud hostimist? Millele tähelepanu pöörata ja milleks valmistuda, et mitte ebameeldivasse olukorda sattuda?

(Vaktsiin „hallilt“ turunduselt)

DDoS-rünnakute teostamise tööriistade saadavus ja mitmekesisus sunnivad veebiteenuste omanikke võtma vastavaid meetmeid ohu vastu. DDoS-kaitse üle tuleks mõelda mitte ainult pärast esimest riket, vaid juba veebihostingu (teenusepakkuja või andmekeskuse) valimise etapis.

DDoS-rünnakud klassifitseeritakse vastavalt protokollide kuuluvusele, mille haavatavusi on kõrvale juhitud, OSI avatud süsteemide suhtlemismudeli tasemetele:

• kanalitase (L2),
• võrgutasand (L3),
• transporditasand (L4),
• rakendustase (L7).

Kaitse süsteemide seisukohalt võib neid jagada kaheks rühmaks: infrastruktuuri taseme (L2-L4) ja rakenduse taseme (L7) rünnakud. See on seotud liiklusanalüüsi algoritmide täitmise järjestusega ja arvutuslikku keerukusega: mida sügavamale IP-paketti vaatame, seda rohkem arvutusvõimet on vajalik.

Üldiselt on liikluse reaalajas töötlemise arvutuste optimeerimise teema eraldi artiklite tsükli jaoks. Praegu kujutame lihtsalt ette, et on olemas teatud pilveteenuse pakkuja, kelle arvutusressursid on tinglikult piiramatud ja kes võib tagada veebisaitide kaitse rakenduste tasemel rünnakute eest (sealhulgas tasuta).

3 peamist küsimust, et määrata kindlaks hostimise kaitstuse tase DDoS rünnakute vastu

Vaadakem DDoS-rünnakute kaitse teenuse tingimusi ja hostimisteenuse pakkuja teenuse taseme lepingut (Service Level Agreement, SLA). Kas nendes leidub vastuseid järgmistele küsimustele:

• milliseid tehnilisi piiranguid teenuse pakkuja väidab?
• mis juhtub, kui tellija ületab piirangud?
• kuidas hostinguteenuse pakkuja DDoS-rünnete eest kaitset ehitab (tehnoloogiad, lahendused, teenusepakkujad)?

Kui te ei leidnud käesolevat teavet, siis on see põhjus, et mõelda teenusepakkuja tõsidusele või korraldada DDoS-kaitse (L3-4) ise. Näiteks tellida füüsiline ühendus spetsialiseeritud kaitse teenusepakkujaga.

Oluline! Pole mõtet tagada rakendustasandi rünnete kaitset Reverse Proxy abil, kui teie hostinguteenuse pakkuja ei suuda tagada infrastruktuuri tasandi rünnete kaitset: võrgu seadmed saavad ülekoormatud ja muutuvad kättesaamatuks, sealhulgas ka pilveteenuse pakkuja proksiserveritele (joonis 1).

Joonis 1. Otsene rünne hostinguteenuse pakkuja võrku

Ja ärge laskke end petta juttudest, et serveri reaalne IP-aadress on kaitse pilve taga peidetud, mistõttu tema ründamine otseselt on võimatu. Üheksa juhul kümnest ei ole ründajal raske leida serveri reaalne IP-aadress või vähemalt hostinguteenuse pakkuja võrgu, et "maha võtta" terve andmekeskus.

Kuidas häkkerid otsivad reaalset IP-aadressi

Spoileri all on mitu meetodit reaalse IP-aadressi leidmiseks (toodud informatiivsetel eesmärkidel).

Meetod 1: Otsing avatud allikatest

Otsingut saab alustada veebiteenustest Intelligence X: see otsib teavet sügaval veebis, dokumentide jagamise platvormidel, töötleb Whois-andmeid, avalikult lekkinud andmeid ja paljusid teisi allikaid.

Kui mingite näitajate (HTTP-pealkirjad, Whois-andmed jne) alusel on võimalik määrata, et veebisaidi kaitse on üles seatud Cloudflare’i kaudu, võib reaalse IP otsingut alustada nimekirja, mis sisaldab umbes 3 miljonit IP-aadressi veebisaitidest, mis asuvad Cloudflare’i taga.

SSL-sertifikaadi ja teenuse kaudu Censys on võimalik leida palju kasulikku, sealhulgas saidi reaalne IP-aadress. Et luua päring teie ressursi kohta, minge vahekaardile Certificates ja sisestage:

_parsed.names: nimiveebisaidi AND tags.raw: trusted

SSL-sertifikaatidega serverite IP-aadresside otsimiseks tuleb rippmenüüd käsitsi läbi vaadata mitme tööriistaga (vahekaart «Explore», seejärel valime «IPv4 Hosts»).

Meetod 2: DNS

DNS-kirje muutuste ajaloos otsimine on ajatu ja tõestatud meetod. Veebisaidi eelmine IP-aadress võib anda aimu, millises hostimisettevõttes (või andmekeskuses) see asus. Kasutuses on mitmeid veebiteenuseid, mis on oma kasutusmugavuse poolest silma paistvad ViewDNS ja SecurityTrails.

Seoses seadistuste muutmisega ei hakka veebisait kohe kasutama pilvteenuse kaitse või CDN'i IP-aadressi, vaid mõnda aega töötab see otse. Sel juhul on tõenäoline, et veebiteenustele, mis hoiavad IP-aadresside muutumise ajalugu, on salvestatud teave saidi algse IP-aadressi kohta.

Kui pole midagi muud peale vana DNS-serveri nime, saab spetsiaalsete utiliitide (dig, host või nslookup) abil küsida IP-aadressi saidi domeeninime kaudu, näiteks:

_dig @vana_dns_serveri_nimi nimilehelt

Meetod 3: email

Meetodi idee seisneb selles, et tagasisidevormi / registreerimise (või muu meetodiga, mis võimaldab algatada kirjasaadetise) kaudu saadetakse kiri teie elektronposti ja kontrollitakse päiseid, eriti valdkonda „Received”.

Kiri meilis on sageli MX-kirje (e-posti serveri) reaalne IP-aadress, mis võib olla aluseks teiste sihiserverite leidmiseks.

Otsingu automatiseerimise tööriistad

Cloudflare'i taga IP-aadresside leidmiseks mõeldud tarkvara töötab enamasti kolmel viisil:

• DNS-i vale seadistuse skaneerimine, kasutades DNSDumpster.com;
• Crimeflare.com andmebaasi skaneerimine;
• alamdomeenide leidmine sõnastiku raames ründamise teel.

Alamdomeenide otsimine osutub sageli kolmest kõige tõhusamaks variandiks — saidi omanik võis peamise saidi kaitsta, kuid jättis alamdomeenid otse toimima. Kontrollimiseks on kõige lihtsam kasutada CloudFail.

Lisaks on olemas utiliidid, mis on mõeldud ainult alamdomeenide leidmiseks sõnastiku raames ja avalike allikate otsimiseks, näiteks: Sublist3r või dnsrecon.

Kuidas otsing praktikas käib

Võtame näiteks saidi seo.com, mis kasutab Cloudflare'i, ja leiame selle tuntud teenuse abil builtwith (mis võimaldab nii määrata tehnoloogiad / mootorid / CMS-id, mille põhjal sait töötab, kui ka vastupidi — otsida saite kasutatavate tehnoloogiate järgi).

Kui liigelda „IPv4 Hosts” vahekaardile, näitab teenus nimekirja hostidest, kus on kasutusel sertifikaat. Otsimiseks leidke IP-aadress avatud pordiga 443. Kui see suunab õigele veebilehele, siis on ülesanne täidetud, vastasel korral tuleb HTTP-päringu päisesse lisada veebilehe domeeninimi (näiteks *curl -H "Host: domeeninimi"*https://IP_aadress).

Meie puhul ei andnud Censys andmebaasi otsimine tulemusi, liigume edasi.

DNS-i otsimist teeme teenuse kaudu https://securitytrails.com/dns-trails.

Käies läbi DNS-serverite nimekirjades märkida CloudFail utiliidiga, leiame funktsioneerivaid ressursse. Tulemused on valmimas juba mõne sekundi pärast.

Kasutades vaid avatud andmeid ja lihtsaid tööriistu, määrasime veebiserveri reaalse IP-aadressi. Ülejäänud on ründajale tehnika küsimus.

Naaseme tagasi hosting-teenuse pakkuja valiku juurde. Et hinnata teenuse kasulikkust kliendile, vaatleme võimalikke DDoS-rünnakute kaitse meetodeid.

Kuidas hosting-teenuse pakkuja oma kaitset loob

1. Omapärane kaitsesüsteem filtritehnoloogiaga (joonis 2).
   Nõuab järgmist:
   1.1. Varustust liikluse filtreerimiseks ja tarkvara litsentse;
   1.2. Kvalifitseeritud spetsialistid selle toetamiseks ja haldamiseks;
   1.3. Interneti-ühenduse kanaleid, mida on piisavalt rünnakute vastuvõtmiseks;
   1.4. Olulist ettetellitud kanali laiust "prügiliiklus" vastuvõtmise jaoks.
   
   Joonis 2. Hostimisettevõtte iseseisev kaitsesüsteem
   Kui vaadata kirjeldatud süsteemi kui kaitsevahendit tänapäevaste DDoS rünnakute eest ulatuses sadade Gbps, siis selline süsteem maksab väga palju raha. Kas hostimisettevõttel on selline kaitse olemas? Kas nad on valmis tasuma "prügiliikluse" eest? Ilmselgelt on selline majandusmudel pakkuja jaoks kahjumlik, kui hindades mitte ette nähtud lisatasusid.
2. Reverse Proxy (ainult veebilehtede ja teatud rakenduste jaoks). Vaatamata mitmetele eeliseid, pakkuja ei garanteeri kaitset otseste DDoS rünnakute eest (vt joonis 1). Hostimisettevõtted pakuvad tihti sellist lahendust imerohuna, delegeerides vastutuse kaitseteenuse pakkujale.
3. Spetsialiseeritud pilvepakkuja teenused (tema filtreerimisvõrgu kasutamine) DDoS rünnakute kaitseks OSI kõigil tasanditel (joonis 3).
   
   Joonis 3. Komplexne DDoS rünnakute kaitse spetsialiseeritud teenusepakkuja abil
   Lahendus eeldab sügavat integreerimist ja kõrget tehnilise põhjendatuse taset mõlemal poolel. Teenuste üleviimine filtrimise kaudu allhanke võimaldab hostimisettevõttel alandada lisateenuste hinda kliendile.

Oluline! Mida täpsemalt on kirjas pakutava teenuse tehnilised omadused, seda suuremad on võimalused nende täitmise või compensatsiooni nõudmiseks seoses seiskumisega.

Lisaks kolmele peamisele meetodile on olemas palju kombinatsioone ja segusid. Kliendile on hostingu valimisel oluline meeles pidada, et otsus mõjutab mitte ainult garanteeritud blokeeritud rünnakute suurust ja filtreerimise täpsust, vaid ka reaktsiooniaega ning informatiivsust (blokitud rünnakute nimekiri, üldstatistika jne).

Pidage meeles, et vaid vähesed hostinguteenuse pakkujad suudavad tagada rahuldava kaitse, enamikul juhtudel aitavad koostöö ja tehnilised oskused. Seega võimaldab DDoS-rünnakute kaitse põhimõtete mõistmine veebisaidi omanikul vältida turundustrikke ja mitte osta "kassi kotis".

Allikas: habr.com