En la unuaj du trimestroj de 2020, la nombro da DDoS-atakoj preskaŭ triobliĝis, kun 65% el ili estante primitivaj provoj pri "ŝarĝo-testado", kiuj facile "malŝaltas" sendefendajn retejojn de malgrandaj interretaj butikoj, forumoj, blogoj kaj amaskomunikiloj.
Kiel elekti DDoS-protektan gastigadon? Kion vi atentu kaj por kio vi preparu por ne fini en malagrabla situacio?
(Vakcinado kontraŭ "griza" merkatado interne)
La havebleco kaj vario de iloj por efektivigi DDoS-atakojn devigas posedantojn de interretaj servoj preni taŭgajn rimedojn por kontraŭstari la minacon. Vi devus pensi pri DDoS-protekto ne post la unua fiasko, kaj eĉ ne kiel parto de aro de mezuroj por pliigi la misfunkciadon de la infrastrukturo, sed en la stadio de elekto de retejo por lokigo (gastiga provizanto aŭ datumcentro).
DDoS-atakoj estas klasifikitaj laŭ la protokoloj, kies vundeblecoj estas ekspluatitaj al la niveloj de la Open Systems Interconnection (OSI) modelo:
- kanalo (L2),
- reto (L3),
- transporto (L4),
- aplikita (L7).
De la vidpunkto de sekurecaj sistemoj, ili povas esti ĝeneraligitaj en du grupojn: infrastrukturaj nivelaj atakoj (L2-L4) kaj aplikaĵnivelaj atakoj (L7). Ĉi tio estas pro la sekvenco de ekzekuto de trafikanalizalgoritmoj kaj komputila komplekseco: ju pli profunde ni rigardas en la IP-pakaĵeto, des pli da komputika potenco estas postulata.
Ĝenerale, la problemo de optimumigo de kalkuloj dum prilaborado de trafiko en reala tempo estas temo por aparta serio de artikoloj. Nun ni nur imagu, ke ekzistas iu nuba provizanto kun kondiĉe senlimaj komputikresursoj, kiuj povas protekti retejojn kontraŭ aplikaĵnivelaj atakoj (inkluzive de ).
3 ĉefaj demandoj por determini la gradon de gastiga sekureco kontraŭ DDoS-atakoj
Ni rigardu la servokondiĉojn por protekto kontraŭ DDoS-atakoj kaj la Servonivela Interkonsento (SLA) de la gastiga provizanto. Ĉu ili enhavas respondojn al la sekvaj demandoj:
- kiaj teknikaj limigoj estas deklaritaj de la servoprovizanto??
- kio okazas kiam la kliento preterpasas la limojn?
- Kiel gastiganta provizanto konstruas protekton kontraŭ DDoS-atakoj (teknologioj, solvoj, provizantoj)?
Se vi ne trovis ĉi tiun informon, tiam ĉi tio estas kialo aŭ pensi pri la seriozeco de la servoprovizanto aŭ organizi bazan DDoS-protekton (L3-4) memstare. Ekzemple, ordigu fizikan konekton al la reto de specialigita sekureca provizanto.
Grava! Ne utilas provizi protekton kontraŭ aplikaĵ-nivelaj atakoj uzante Reverse Proxy se via gastiga provizanto ne kapablas provizi protekton kontraŭ infrastruktur-nivelaj atakoj: la retaj ekipaĵoj estos troŝarĝitaj kaj fariĝos neatingebla, inkluzive por la prokurserviloj de la nuba provizanto (Figuro). 1).
Figuro 1. Rekta atako al la reto de la gastiga provizanto
Kaj ne lasu ilin provi rakonti al vi fabelojn, ke la vera IP-adreso de la servilo estas kaŝita malantaŭ la nubo de la sekureca provizanto, kio signifas, ke estas neeble ataki ĝin rekte. En naŭ kazoj el dek, ne estos malfacile por atakanto trovi la realan IP-adreson de la servilo aŭ almenaŭ la reton de la gastiga provizanto por "detrui" tutan datumcentron.
Kiel agas piratoj serĉante realan IP-adreson
Sub la spoilers estas pluraj metodoj por trovi realan IP-adreson (donita por informaj celoj).
Metodo 1: Serĉu en malfermaj fontoj
Vi povas komenci vian serĉon per la interreta servo: Ĝi serĉas la malluman reton, platformojn de interŝanĝo de dokumentoj, prilaboras Whois-datumojn, publikajn datumfluojn kaj multajn aliajn fontojn.
Se, surbaze de iuj signoj (HTTP-kapoj, Whois-datumoj, ktp.), eblis determini, ke la protekto de la retejo estas organizita per Cloudflare, tiam vi povas komenci serĉi la realan IP de, kiu enhavas ĉirkaŭ 3 milionojn da IP-adresoj de retejoj situantaj malantaŭ Cloudflare.
Uzante SSL-atestilon kaj servon vi povas trovi multajn utilajn informojn, inkluzive de la reala IP-adreso de la retejo. Por generi peton por via rimedo, iru al la langeto Atestiloj kaj enigu:
_parsed.names: nomoretejo KAJ etikedoj.raw: fidinda
Por serĉi IP-adresojn de serviloj per SSL-atestilo, vi devos permane trairi la falliston per pluraj iloj (la langeto "Esplori", tiam elektu "IPv4 Gastigantoj").
Metodo 2: DNS
Serĉi la historion de DNS-rekordaj ŝanĝoj estas malnova, provita metodo. La antaŭa IP-adreso de la retejo povas klarigi sur kiu gastigado (aŭ datumcentro) ĝi troviĝis. Inter la interretaj servoj laŭ facileco de uzado elstaras jenaj: и .
Kiam vi ŝanĝas la agordojn, la retejo ne tuj uzos la IP-adreson de la nuba sekureca provizanto aŭ CDN, sed funkcios rekte dum iom da tempo. En ĉi tiu kazo, ekzistas ebleco, ke interretaj servoj por konservi la historion de ŝanĝoj de IP-adresoj enhavas informojn pri la fontadreso de la retejo.
Se estas nenio krom la nomo de la malnova DNS-servilo, tiam uzante specialajn ilojn (dig, host aŭ nslookup) vi povas peti IP-adreson laŭ la domajna nomo de la retejo, ekzemple:
_dig @old_dns_server_name nomoejo
Metodo 3: retpoŝto
La ideo de la metodo estas uzi la sugeston/registriĝilon (aŭ ajnan alian metodon, kiu ebligas al vi komenci la sendon de letero) por ricevi leteron al via retpoŝto kaj kontroli la kapliniojn, precipe la kampon "Ricevita". .
La retpoŝta kaplinio ofte enhavas la realan IP-adreson de la MX-rekordo (retpoŝta interŝanĝa servilo), kiu povas esti deirpunkto por trovi aliajn servilojn ĉe la celo.
Serĉu Aŭtomatigajn Ilojn
IP-serĉa programaro malantaŭ la ŝildo Cloudflare plej ofte funkcias por tri taskoj:
- Skanu por DNS misagordo uzante DNSDumpster.com;
- Skanado de datumbazo Crimeflare.com;
- serĉu subdomajnojn per vortara serĉmetodo.
Trovi subdomajnojn ofte estas la plej efika opcio el la tri - la posedanto de la retejo povus protekti la ĉefan retejon kaj lasi la subdomajnojn funkcii rekte. La plej facila maniero por kontroli estas uzi .
Krome, ekzistas utilecoj destinitaj nur por serĉi subdomajnojn uzante vortarserĉon kaj serĉadon en malfermaj fontoj, ekzemple: aŭ .
Kiel serĉo okazas praktike
Ekzemple, ni prenu la retejon seo.com uzante Cloudflare, kiun ni trovos uzante konatan servon (ebligas al vi ambaŭ determini la teknologiojn / motorojn / CMS sur kiuj la retejo funkcias, kaj inverse - serĉi retejojn laŭ la teknologioj uzataj).
Kiam vi alklakas la langeton "IPv4 Gastigantoj", la servo montros liston de gastigantoj uzante la atestilon. Por trovi tiun, kiun vi bezonas, serĉu IP-adreson kun malfermita haveno 443. Se ĝi alidirektas al la dezirata retejo, tiam la tasko estas finita, alie vi devas aldoni la domajnan nomon de la retejo al la kaplinio "Gastiganto" de la retejo. HTTP-peto (ekzemple, *curl -H "Gastiganto: retejo_nomo" *).
En nia kazo, serĉo en la datumbazo Censys donis nenion, do ni antaŭeniras.
Ni faros DNS-serĉon per la servo.
Serĉante la adresojn menciitajn en la listoj de DNS-serviloj uzante la ilon CloudFail, ni trovas laborajn rimedojn. La rezulto estos preta post kelkaj sekundoj.
Uzante nur malfermajn datumojn kaj simplajn ilojn, ni determinis la realan IP-adreson de la retservilo. La resto por la atakanto estas afero de tekniko.
Ni revenu al elekto de gastiga provizanto. Por taksi la avantaĝon de la servo por la kliento, ni konsideros eblajn metodojn de protekto kontraŭ DDoS-atakoj.
Kiel gastiga provizanto konstruas sian protekton
- Propra protekta sistemo kun filtra ekipaĵo (Figuro 2).
Postulas:
1.1. Trafika filtra ekipaĵo kaj programaraj licencoj;
1.2. Plentempaj specialistoj por ĝia subteno kaj funkciado;
1.3. Interreta alirkanaloj, kiuj sufiĉos por ricevi atakojn;
1.4. Signifa antaŭpagita kanala bendolarĝo por ricevi "forĵetaĵan" trafikon.
Figuro 2. La propra sekureca sistemo de gastiga provizanto
Se ni konsideras la priskribitan sistemon kiel rimedon de protekto kontraŭ modernaj DDoS-atakoj de centoj da Gbps, tiam tia sistemo kostos multe da mono. Ĉu la gastiganta provizanto havas tian protekton? Ĉu li pretas pagi por "forĵetaĵo" trafiko? Evidente, tia ekonomia modelo estas neprofita por la provizanto se la tarifoj ne provizas pliajn pagojn. - Inversa Prokurilo (nur por retejoj kaj iuj aplikoj). Malgraŭ nombro , la provizanto ne garantias protekton kontraŭ rektaj DDoS-atakoj (vidu Figuro 1). Gastigantaj provizantoj ofte ofertas tian solvon kiel panaceon, ŝanĝante la respondecon al la sekureca provizanto.
- Servoj de specialigita nuba provizanto (uzo de ĝia filtra reto) por protekti kontraŭ DDoS-atakoj ĉe ĉiuj OSI-niveloj (Figuro 3).
Figuro 3. Ampleksa protekto kontraŭ DDoS-atakoj uzante specialigitan provizanton
supozas profundan integriĝon kaj altnivelan de teknika kompetenteco de ambaŭ partioj. Subkontraktado de trafikaj filtraj servoj permesas al la gastiga provizanto redukti la prezon de pliaj servoj por la kliento.
Grava! Ju pli detale estas priskribitaj la teknikaj karakterizaĵoj de la servo provizita, des pli granda estas la ŝanco postuli ilian efektivigon aŭ kompenson en kazo de malfunkcio.
Krom la tri ĉefaj metodoj, ekzistas multaj kombinaĵoj kaj kombinaĵoj. Elektante gastigadon, gravas por la kliento memori, ke la decido dependos ne nur de la grandeco de garantiitaj blokitaj atakoj kaj filtrado de precizeco, sed ankaŭ de la rapideco de respondo, kaj ankaŭ de informa enhavo (listo de blokitaj atakoj, ĝenerala statistiko ktp.).
Memoru, ke nur kelkaj gastigaj provizantoj en la mondo kapablas provizi akcepteblan nivelon de protekto memstare; en aliaj kazoj, kunlaborado kaj teknika legopovo helpas. Tiel, kompreni la bazajn principojn por organizi protekton kontraŭ DDoS-atakoj permesos al la posedanto de la retejo ne fali por merkataj lertaĵoj kaj ne aĉeti "porkon en poke".
fonto: www.habr.com