2020. aasta kahel esimesel kvartalil kasvas DDoS-rünnakute arv peaaegu kolm korda, samas kui 65% neist on primitiivsed "koormustestimise" katsed, mis suudavad hõlpsasti "välja lülitada" kaitsetud veebilehed, sealhulgas väikesed e-poed, foorumid, blogid ja meedia.
Kuidas valida DDoS-rünnakute eest kaitstud veebihosting? Millele pöörata tähelepanu ja millega ette valmistada, et mitte ebamugavasse olukorda sattuda?
(Immuniseerimismeede "hallist" turundusest)
DDoS-rünnakute läbipaistvus ja mitmekesisus sunnivad veebiteenuste omanikke võtma vastavaid meetmeid, et seista vastu ohule. DDoS-kaitse peale mõtlema peaks mitte pärast esimest tõrget ja isegi mitte vaid osana infrastruktuuri tõrketaluvuse parandamise meetmetest, vaid juba veebihostingu valimisel.
DDoS-rünnakud klassifitseeritakse vastavalt protokollide kuuluvusele, mille haavatavusi ära kasutatakse, OSI mudeli tasemete järgi:
- kanalitasemel (L2),
- võrgutasemel (L3),
- transporditasemel (L4),
- rakendustasandil (L7).
Kaitsesüsteemide seisukohalt saab need üldistada kaheks rühmaks: infrastruktuuri taseme rünnakud (L2-L4) ja rakendustaseme rünnakud (L7). See on seotud liikluse analüüsi algoritmide täitmise järjekorra ja arvutuskeerukusega: mida sügavamale vaatame IP-paketti, seda rohkem arvutusressursse on vaja.
Üldiselt on liikluse reaalajas töötlemise arvutusoptimeerimise ülesanne teema eraldi artiklite tsüklile. Ja nüüd kujutame lihtsalt ette, et on olemas teatud pilveteenus, millel on tingimuslikult piiramatud arvutusressursid, mis suudab tagada veebilehtede kaitse rakendustaseme rünnakute eest (sealhulgas ).
3 peamist küsimust, et määrata ära veebihostingu kaitseaste DDoS-rünnakute eest
Vaatame DDoS-rünnakute kaitseteenuse tingimusi ja veebihostingu teenuse taseme lepet (Service Level Agreement, SLA). Kas nendes lepingutes on vastused järgmistele küsimustele:
- milliseid tehnilisi piiranguid teenuse pakkuja väidab?
- mis juhtub, kui klient ületab piirangud?
- kuidas veebihostinguteenuse pakkuja DDoS-rünnakute kaitset korraldab (tehnoloogiad, lahendused, teenusepakkujad)?
Kui te ei leidnud seda teavet, on see märk, et peate kas kahtlema teenusepakkuja tõsiduses või korraldama ise põhilise DDoS-kaitse (L3-4). Näiteks tellige füüsilineühendus spetsialiseeritud kaitsepakkuja võrguga.
Oluline! Ei ole mõtet tagada rakendustasandi rünnakute kaitset Reverse Proxy abiga, kui teie hostimisteenuse pakkuja ei suuda tagada infrastruktuuri tasandi rünnakute kaitset: võrgu seadmed saavad ülekoormatud ja muutuvad kättesaamatuks, sealhulgas ka pilveteenuse pakkuja proksiserveritele (joonis 1).
Joonis 1. Otsene rünnak hostimisteenuse pakkuja võrgule
Ärge laske end petta jutust, et serveri reaalne IP-aadress on kaitsepakkuja pilve taga varjatud, mistõttu on selle otse ründamine võimatu. Üheksast kümnest juhul on ründajal lihtne leida serveri reaalne IP-aadress või vähemalt hostimisteenuse pakkuja võrgu aadress, et "maha võtta" terve andmekeskus.
Kuidas tegutsevad häkkerid reaalsete IP-aadresside otsimisel
Spoilerite all on mõned meetodid reaalsete IP-aadresside leidmiseks (toodud tutvumiseks).
Meetod 1: Otsimine avatud allikatest
Otsingut on võimalik alustada veebiteenusest: see otsib teavet tumedalt veebist, dokumentide jagamise platvormidelt, töötleb Whois andmeid, avalike andmete lekked ja paljusid teisi allikaid.
Kui mingite tunnuste (HTTP-pealkirjad, Whois andmed jne) põhjal suudeti kindlaks teha, et veebisaidi kaitse on korraldatud Cloudflare’i abil, siis alustada reaalsete IP-de otsimist saab, mis sisaldab umbes 3 miljonit IP-aadressi saitidest, mis asuvad Cloudflare’i taga.
SSL-sertifikaadi ja teenuse abil on võimalik leida palju kasulikku, sealhulgas reaalne veebisaidi IP-aadress. Oma ressurssi otsingu koostamiseks minge vahekaardile Sertifikaadid ja sisestage:
_parsed.names: nimiveebisaidi AND tags.raw: trusted
SSL-sertifikaadi kasutavate serverite IP-aadresside otsimiseks tuleb avanev loend käsitsi läbi käia mitme tööriistaga (vahekaardil "Uuring", valige "IPv4 Hosts").
Meetod 2: DNS
DNS-kandete ajaloo uurimine on vana, tõestatud meetod. Aja jooksul muutunud veebisaidi eelmine IP-aadress võib anda aimu, millises hostimis- (või andmekeskuse) asukohas see asus. Online-teenustest eristuvad kasutusmugavuse poolest ja .
Kui saidi seadeid muudetakse, ei kasuta see kohe pilveteenuse pakkuja või CDN-i IP-aadressi, vaid töötab mõnda aega otse. Sel juhul on olemas võimalus, et online-teenuste ajalugu sisaldab teavet saidi algse aadressi kohta.
Kui ei ole midagi muud, kui vana DNS-serveri nimi, saab spetsiaalsete tööriistade (dig, host või nslookup) kaudu küsida saidi domeeninime kaudu IP-aadressi, näiteks:
_dig @vana_dns_serveri_nimi nimilehelt
Meetod 3: e-post
Meetodi idee on saada tagasisidevormi / registreerimise (või muu viisi) kaudu e-kiri oma e-posti aadressile ja kontrollida päiseid, sealhulgas "Received" välja.
E-kirja päises on sageli tegelik IP-aadress MX-kirje (e-posti vahetusse server), mis võib olla aluseks teiste sihiserverite otsimiseks.
Automaatsed otsimise tööriistad
Cloudflare-i taga IP-otsimiseks mõeldud tarkvara töötab peamiselt kolme ülesande raames:
- vale DNS-i seadistuse skannimine, kasutades DNSDumpster.com;
- skannimine Crimeflare.com andmebaasi;
- alamdomeenide otsimine sõnastiku kaudu.
Alamdomeenide otsimine osutub sageli kolmest valikust kõige tõhusamaks, kuna saidi omanik võib peasaidi kaitsta, kuid alamdomeenid võivad töötada otse. Kontrollimiseks on kõige lihtsam kasutada .
Lisaks on olemas tööriistu, mis on mõeldud ainult alamdomeenide otsimiseks sõnastiku kaudu ja avalikes allikates, näiteks: või .
Kuidas otsing praktikas toimub
Näiteks võtame saidi seo.com, mis kasutab Cloudflare'i ja mille leiame tuntud teenuse (mis võimaldab määrata tehnoloogiaid / mootorit / CMS, mille põhjal sait töötab, samuti vastupidi - otsida saite kasutatud tehnoloogiate alusel).
IPv4 Hostide vahekaartidele liikumisel näitab teenus loetelu hostidest, mis kasutavad sertifikaati. Otsige vajalikku, otsides avatud port 443-ga IP-aadressi. Kui see suunab soovitud saidile, on ülesanne täidetud, vastasel juhul tuleb lisada HTTP-pöörde "Host" päisesse saidi domeeninimi (näiteks *curl -H "Host: saidi_nimi" *).
Meie puhul ei andnud Censys andmebaaside otsing tulemusi, liikume edasi.
Teeme DNS-i otsingu teenuse kaudu.
Töötades DNS-serverite nimekirjades mainitud aadresse CloudFail utiliidiga, leiame töötavad ressursid. Tulemus on valmis juba mõne sekundi pärast.
Kasutades ainult avalikke andmeid ja lihtsaid tööriistu, suutsime määrata veebiserveri reaalse IP-aadressi. Ülejäänu on ründaja jaoks tehnika küsimus.
Naaseme hostimisteenuse pakkuja valimise juurde. Et hinnata teenuse kasu kliendi jaoks, vaatame võimalikke viise DDoS-rünnakute vastu kaitsmiseks.
Kuidas hostimisteenuse pakkuja oma kaitset ehitab
- Omandatud kaitsesüsteem filtreerimise seadmetega (joonis 2).
Nõuab järgmist:
1.1. Seadmeid, et filtreerida liiklust ja litsentse tarkvara jaoks;
1.2. Karmide spetsialistide meeskonda nende hooldamiseks ja kasutamiseks;
1.3. Interneti-ühenduse kanaleid, mida piisab rünnakute vastuvõtmiseks;
1.4. Olulist ette makstud kanaliparvustust, et vastu võtta 'prügi' liiklust.
Joonis 2. Omandatud kaitsesüsteem hostimisteenuse pakkuja poolt
Kui vaadata kirjeldatud süsteemi kui kaitsevahendit kaasaegsete DDoS rünnakute vastu, mis ulatuvad sadadeni Gbps, siis selline süsteem maksab väga palju. Kas hostimisteenuse pakkujal on selline kaitse? Kas ta on valmis maksma 'prügi' liikluse eest? On selge, et selline majandusmudel on pakkuja jaoks kahjumlik, kui hindades ei ole ette nähtud täiendavaid tasusid. - Tagasi Proxy (ainult veebisaitide ja mõnede rakenduste jaoks). Hoolimata mitmetest , pakkuja ei taga kaitset otseste DDoS rünnakute eest (vt joonis 1). Hostimisteenuse pakkujad pakuvad sageli sellist lahendust imerohuna, lükates vastutuse kaitset pakkuvale teenusele.
- Spetsialiseeritud pilveteenuse pakkuja teenused (tema filtreerimisvõrgu kasutamine) DDoS rünnakute kaitseks kõikidel OSI tasanditel (joonis 3).
Joonis 3. Komplekne DDoS rünnakute kaitse spetsialiseeritud teenuse pakkuja abil
eeldab sügavat integreerimist ja kõrget tehnilist kompetentsust mõlemalt poolt. Liiklust filtreerimise teenuste väljastamine võimaldab hostimisteenuse pakkujal vähendada lisateenuste hinda kliendi jaoks.
Oluline! Mida detailselt on kirjas antud teenuse tehnilised omadused, seda suuremad on šansid nende täitmist või hüvitamist nõuda seoses seiskumisega.
Lisaks kolmele põhimeetodile on olemas palju kombinatsioone ja kombinatsioone. Klient peab hostingut valides meeles pidama, et lahendus mõjutab mitte ainult garanteeritud rünnakute suurust ja filtreerimise täpsust, vaid ka reaktsiooniaega ja informatiivsust (blokeeritud rünnakute nimekiri, üldstatistika jne).
Pidage meeles, et maailmas on vaid üksikud hostimisettevõtted, kes suudavad iseseisvalt tagada vastuvõetava kaitsetaseme, enamikul juhtudel aitab koostöö ja tehniline pädevus. Niisiis, põhialuste mõistmine DDoS-rünnakute kaitse korraldamisel takistab saidi omaniku langemist turundustrikkidesse ning mitte ostmast "kassi kotis".
Allikas: habr.com
