„Drengen, der lavede vores website, har allerede sat beskyttelse mod DDoS op.“
„Vi har jo DDoS-beskyttelse, hvorfor gik hjemmesiden ned?“
„Hvor mange tusinde vil Qrator have?“
For at kunne svare ordentligt på sådanne spørgsmål fra klienten/chefen, ville det være godt at vide, hvad der ligger bag betegnelsen „DDoS-beskyttelse“. Valget af beskyttelsestjenester minder mere om lægelig behandling end om at vælge et bord i IKEA.
Jeg har arbejdet med websupport i 11 år, har overlevet hundredevis af angreb på de tjenester, jeg understøtter, og nu vil jeg kort fortælle om det indre arbejde med beskyttelse.
Regelmæssige angreb. 350k req i alt, 52k req legitim
De første angreb dukkede op praktisk talt samtidig med internettet. DDoS som fænomen blev massivt fra slutningen af 2000'erne (se ).
Fra omkring 2015-2016 har næsten alle hostingudbydere taget DDoS-beskyttelse i brug, ligesom de fleste fremtrædende hjemmesider i konkurrerende områder (lav whois på IP-adresserne for hjemmesiderne eldorado.ru, leroymerlin.ru, tilda.ws, og se beskyttelsesoperatørernes netværk).
Hvis man for 10-20 år siden kunne afvise de fleste angreb på selve serveren (vurder anbefalingerne fra systemadministratoren Maxim Moshkov fra 90'erne: ), så er beskyttelsesopgaverne nu blevet mere komplekse.
Typer af DDoS-angreb set fra valget af beskyttelsesoperatør
Angreb på niveau L3 / L4 (i henhold til OSI-modellen)
— UDP flood fra botnet (direkte fra inficerede enheder sendes der mange anmodninger til den angrebne service, hvilket oversvømmer serverens kanal);
— DNS/NTP/etc. amplification (der sendes mange anmodninger fra inficerede enheder til sårbare DNS/NTP/etc., afsenderens adresse forfalskes, en stor mængde pakker med svar på anmodninger oversvømmer kanalen til den, der angribes; sådanne angreb er de mest massive i det moderne internet);
— SYN / ACK flood (der sendes mange anmodninger til de angrebne servere for at etablere forbindelse, hvilket resulterer i overbelastning af køen til forbindelser);
— angreb med fragmentering af pakker, ping of death, ping flood (google venligst);
— osv.
Disse angreb har til formål at "oversvømme" kanalserveren eller "dræbe" dens evne til at modtage ny trafik.
Selvom SYN/ACK flood og amplification er meget forskellige, kæmper mange virksomheder mod dem på samme effektive måde. Problemer opstår med angreb fra den næste gruppe.
Angreb på L7 (applikationsniveau)
— http flood (hvis en webside eller en http-api angribes);
— angreb på sårbare områder af hjemmesiden (uden cache, som meget belastende for hjemmesiden osv.).
Målet er at få serveren til at "arbejde hårdt", behandle mange "tilsyneladende reelle forespørgsler" og blive uden ressourcer til ægte forespørgsler.
Selvom der er andre angreb, er disse de mest almindelige.
Alvorlige angreb på L7-niveau skabes unikt for hvert angrebne projekt.
Hvorfor 2 grupper?
Fordi der er mange, der er gode til at afvise angreb på L3 / L4 niveau, men som enten slet ikke tager sig af at beskytte på applikationsniveau (L7), eller som stadig håndterer dem svagere end alternativerne.
Hvem er hvem på DDoS-beskyttelsesmarkedet
(min personlige mening)
Beskyttelse på L3/L4 niveau
For at afvise angreb med amplification ("overbelastning" af serverens kanal) er det nok med brede kanaler (mange af beskyttelsestjenesterne er tilsluttet de fleste store netværksudbydere i Rusland og har kanaler med en teoretisk kapacitet større end 1 Tbps). Glem ikke, at meget sjældne angreb med amplification varer i mere end en time. Hvis du er Spamhaus og ikke er populær hos nogen — ja, de kan forsøge at nedlægge dine kanaler i flere dage, selv med risiko for din verdens botnets overlevelse. Hvis du bare har en webshop, selv hvis det er mvideo.ru — en Tbps i flere dage vil du ikke se meget snart (forhåbentlig).
For at afvise angreb med SYN/ACK floode, fragmentering af pakker osv., er det nødvendigt med hardware eller softwareløsninger til detektion og afskæring af sådanne angreb.
Sådan hardware produceres af mange (Arbor, der er løsninger fra Cisco, Huawei, softwareløsninger fra Wanguard osv.), mange store operatører har allerede installeret det og sælger DDoS-beskyttelsestjenester (jeg ved om installationer hos Rostelecom, MegaFon, TTK, MTS, stort set alle store udbydere gør det, det gør hosting selskaber også med deres egen beskyttelse a-la OVH.com, Hetzner.de, jeg har selv stødt på beskyttelse hos ihor.ru). Nogle firmaer udvikler deres egne softwareløsninger (teknologier som DPDK muliggør behandling af trafik i titusinder af gigabit på én fysisk x86-maskine).
Alle kendte spillere kan mere eller mindre effektivt forhindre L3/L4 DDoS-angreb. Jeg kan ikke lige nu sige, hvem der har den største maksimale båndbredde (det er insiderinformation), men normalt er det ikke så vigtigt, og forskellen ligger kun i, hvor hurtigt beskyttelsen aktiveres (øjeblikkeligt eller efter et par minutters nedetid på projektet, som hos Hetzner).
Spørgsmålet er, hvor kvalitativt dette gøres: et angreb med forstærkning kan afværges ved at blokere trafik fra lande med den højeste mængde skadelig trafik, eller man kan blot forkaste virkelig overflødig trafik.
Men ud fra min erfaring klarer alle seriøse aktører på markedet dette uden problemer: Qrator, DDoS-Guard, Kaspersky, G-Core Labs (tidligere SkyParkCDN), ServicePipe, Stormwall, Voxility osv.
Jeg har ikke haft erfaring med beskyttelse fra operatører som Rostelecom, MegaFon, TTK, Beeline. Ifølge kollegernes anmeldelser tilbyder de disse tjenester ret kvalitativt, men der er stadig periodiske mangler i erfaringen: nogle gange er det nødvendigt at justere noget gennem supporten fra beskyttelsesoperatøren.
Nogle operatører har en særskilt tjeneste kaldet "beskyttelse mod angreb på L3/L4-niveau" eller "kanalbeskyttelse", som er meget billigere end beskyttelse på alle niveauer.
Hvordan kan en ikke-hovedleverandør afværge angreb på hundreder af Gbit, når de ikke har egne kanaler?Beskyttelsesoperatøren kan forbinde sig til en hvilken som helst af de store udbydere og afværge angreb "for deres regning". Man skal betale for kanalen, men alle disse hundrede Gbit vil ikke altid blive udnyttet, der er muligheder for betydelig reduktion af omkostningerne ved kanaler i dette tilfælde, så ordningen forbliver bæredygtig.
Sådan nogle rapporter fra den overordnede L3/L4-beskyttelse har jeg regelmæssigt modtaget, mens jeg har støttet hostingudbyderens systemer.
Beskyttelse på L7-niveau (applikationsniveau)
Angreb på L7-niveau (applikationsniveau) kan stabilt og kvalitativt afværges af enkelte.
Jeg har en reel, ganske stor erfaring med
— Qrator.net;
— DDoS-Guard;
— G-Core Labs;
— Kaspersky.
De opkræver betaling for hver megabit ren trafik, og prisen pr. megabit ligger omkring flere tusinde rubler. Hvis du har mindst 100 Mbit ren trafik — åh. Beskyttelsen bliver meget dyr. Jeg kan i kommende artikler fortælle, hvordan man designer applikationer for at spare meget på kapaciteten af beskyttelseskanaler.
Den virkelige "konge af bjerget" er Qrator.net, de øvrige ligger langt bagefter. Qrator er indtil videre de eneste i min erfaring, der har en næsten nul procent af falske alarmer, men de er til gengæld flere gange dyrere end de andre spillere på markedet.
Andre udbydere tilbyder også kvalitetsbeskyttelse og stabilitet. Mange af de tjenester, vi understøtter (herunder nogle meget kendte i landet!), er beskyttet af DDoS-Guard, G-Core Labs, og er ganske tilfredse med de resultater, de får.
Angreb, afvist af Qrator
Jeg har også erfaring med mindre beskyttelsesudbydere som cloud-shield.ru, ddosa.net, der er tusinder af dem. Jeg vil ikke anbefale dem entydigt, da erfaringen ikke er ret stor, men jeg vil fortælle om principperne for deres arbejde. Prisen for deres beskyttelse ligger ofte 1-2 niveauer under de store spillere. Som regel køber de en delvis beskyttelsestjeneste (L3/L4) fra en af de større spillere og laver deres egen beskyttelse mod angreb på højere niveauer. Dette kan være ret effektivt, og du kan få en god service til færre penge, men husk, at det stadig er små virksomheder med få ansatte.
Hvad er udfordringen ved at afvise angreb på L7-niveau?
Alle applikationer er unikke, og det er nødvendigt at tillade nyttig trafik for dem og blokere skadelig trafik. Det er ikke altid muligt at sortere bots fra, så det er nødvendigt at anvende mange, virkelig MANGE niveauer af trafikrensning.
Engang var det nok med modulet nginx-testcookie (), og det er stadig tilstrækkeligt til at afvise et stort antal angreb. Da jeg arbejdede i hostingbranchen, byggede jeg L7-beskyttelse netop på nginx-testcookie.
Desværre er angrebene blevet mere komplekse. testcookie anvender bot-checks baseret på JS, og mange moderne bots kan nu nemt klare dem.
Angrebende botnets er også unikke, og det er nødvendigt at tage hensyn til karakteristikaene for hvert stort botnet.
Amplifikation, direkte flooding fra botnet, trafikfiltrering fra forskellige lande (forskellig filtrering for forskellige lande), SYN/ACK flooding, pakke fragmentering, ICMP, http flooding, og på applikations-/http-niveau kan der opfindes et ubegribelig antal forskellige angreb.
I alt kan der på niveauet for kanalbeskyttelse, specialiseret udstyr til trafikrensning, specialsoftware og ekstra filtreringsindstillinger for hver kunde være titusinder og hundredevis af filtreringslag.
For effective management and proper tuning of filtering settings for different users, extensive experience and qualified personnel are essential. Even a large operator, deciding to offer protection services, cannot simply throw money at the problem: experience must be gained from existing sites and false triggers on legitimate traffic.
For a protection operator, there is no ‘DDoS mitigation button’; there are many tools that need to be used skillfully.
And another bonus example.
The server without protection was blocked by the hosting provider during an attack with a capacity of 600 Mbps.
(The 'disappearance' of traffic is not noticeable since only one site was attacked, it was temporarily removed from the server and the block was lifted within an hour).
This same server is under protection. The attackers 'gave up' after a day of repelled attacks. The attack itself turned out not to be the strongest.
Attacks and protection at L3/L4 are more trivial; they primarily depend on the bandwidth of the channels, detection algorithms, and attack filtering.
L7 attacks are more complex and original, depending on the attacked application, capabilities, and the attackers' creativity. Protection against them requires extensive knowledge and experience, and the results may not be immediate or guaranteed. Until Google develops another neural network for protection.
Kilde: habr.com
