{"id":31924,"date":"2019-10-31T21:44:01","date_gmt":"2019-10-31T18:44:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy\/"},"modified":"2019-10-31T21:44:01","modified_gmt":"2019-10-31T18:44:01","slug":"ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","title":{"rendered":"DDoS till hj\u00e4lp: hur vi genomf\u00f6r stress- och belastningstester","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DDoS
\n
\nF\u00f6retaget Variti utvecklar skydd mot botar och DDoS-attacker samt genomf\u00f6r stresstest och belastningstestning. P\u00e5 konferensen HighLoad++ 2018 ber\u00e4ttade vi om hur man skyddar resurser mot olika typer av attacker. Kort sagt: isolera delar av systemet, anv\u00e4nd molntj\u00e4nster och CDN och h\u00e5ll er regelbundet uppdaterade. Men utan specialiserade f\u00f6retag f\u00f6r skydd klarar ni er inte sj\u00e4lva \ud83d\ude42<\/i>
\n<\/a><\/noindex>
\nInnan ni l\u00e4ser texten kan ni ta del av korta punkter p\u00e5 konferensens webbplats<\/a><\/noindex>.
\nOch om ni inte gillar att l\u00e4sa eller bara vill titta p\u00e5 videon, finns inspelningen av v\u00e5rt f\u00f6redrag nedan under spoiler.<\/p>\n

Videoinspelning av f\u00f6redraget<\/b>

\r\n \"Spela\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

M\u00e5nga f\u00f6retag kan redan genomf\u00f6ra belastningstest, men inte alla g\u00f6r stresstest. N\u00e5gra av v\u00e5ra kunder tror att deras webbplats \u00e4r of\u00f6rsvarande eftersom de har ett highload-system, och det skyddar dem v\u00e4l mot attacker. Vi visar dock att detta inte riktigt st\u00e4mmer.
\nSj\u00e4lvklart f\u00e5r vi tillst\u00e5nd fr\u00e5n kunden innan tester genomf\u00f6rs, med signatur och st\u00e4mpel, och med v\u00e5r hj\u00e4lp kan man inte utf\u00f6ra DDoS-attacker mot n\u00e5gon. Testning sker vid en tidpunkt som kunden v\u00e4ljer, n\u00e4r bes\u00f6ksniv\u00e5n f\u00f6r deras resurs \u00e4r minimal, s\u00e5 att problem med \u00e5tkomst inte p\u00e5verkar kunderna. Dessutom, eftersom det alltid kan g\u00e5 fel under testprocessen, har vi st\u00e4ndig kontakt med kunden. Detta m\u00f6jligg\u00f6r inte bara att rapportera uppn\u00e5dda resultat utan ocks\u00e5 att g\u00f6ra \u00e4ndringar under testningen. Vid avslutningen av testningen uppr\u00e4ttar vi alltid en rapport d\u00e4r vi p\u00e5pekar uppt\u00e4ckta brister och ger rekommendationer f\u00f6r att \u00e5tg\u00e4rda svaga punkter p\u00e5 webbplatsen. <\/p>\n

S\u00e5 h\u00e4r arbetar vi<\/h3>\n

\nVid genomf\u00f6rande av testningen emulerar vi ett botn\u00e4t. Eftersom vi arbetar med kunder som inte \u00e4r lokaliserade i v\u00e5ra n\u00e4tverk, f\u00f6r att testet inte ska avslutas p\u00e5 f\u00f6rsta minuten p\u00e5 grund av begr\u00e4nsningar eller skydd, ger vi belastningen inte fr\u00e5n en IP, utan fr\u00e5n v\u00e5rt eget subnet. Dessutom, f\u00f6r att skapa en betydande belastning har vi en kraftfull testserver.<\/p>\n

Postulat<\/h3>\n

<\/p>\n

Mycket betyder inte bra<\/b>
\nJu l\u00e4gre belastning vi kan f\u00e5 resursen att g\u00e5 ner p\u00e5, desto b\u00e4ttre. Om vi kan f\u00e5 sidan att sluta fungera vid en beg\u00e4ran per sekund, eller till och med en beg\u00e4ran per minut, \u00e4r det fantastiskt. F\u00f6r enligt Murphy's lag kommer anv\u00e4ndare eller angripare av en slump att utnyttja just denna s\u00e5rbarhet. <\/p><\/blockquote>\n

Delvis fel \u00e4r b\u00e4ttre \u00e4n totalt fel<\/b>
\nVi rekommenderar alltid att g\u00f6ra systemen heterogena. Det \u00e4r viktigt att separera dem p\u00e5 fysisk niv\u00e5, inte bara genom containerisering. Vid fysisk separation, \u00e4ven om n\u00e5got g\u00e5r fel p\u00e5 sidan, \u00e4r det troligt att det inte helt slutar fungera, och anv\u00e4ndare fortfarande har tillg\u00e5ng till \u00e5tminstone en del av funktionaliteten.<\/p><\/blockquote>\n

R\u00e4tt arkitektur \u00e4r grundl\u00e4ggande f\u00f6r motst\u00e5ndskraft<\/b>
\nResursens redundans och dess f\u00f6rm\u00e5ga att hantera attacker och belastningar b\u00f6r beaktas redan under designsteget, praktiskt taget i skedet av att rita de f\u00f6rsta blockdiagrammen i anteckningsboken. F\u00f6r om fatala fel slinker in kan de vara sv\u00e5ra att r\u00e4tta till senare.<\/p><\/blockquote>\n

Inte bara koden, utan \u00e4ven konfigurationen b\u00f6r vara bra<\/b>
\nM\u00e5nga tror att ett bra utvecklingsteam garanterar tj\u00e4nstens redundans. Ett bra utvecklingsteam \u00e4r verkligen n\u00f6dv\u00e4ndigt, men det m\u00e5ste ocks\u00e5 finnas god drift, bra DevOps. Det inneb\u00e4r att det beh\u00f6vs specialister som korrekt konfigurerar Linux och n\u00e4tverket, korrekt skriver konfigurationer i nginx, st\u00e4ller in gr\u00e4nser och s\u00e5 vidare. Annars kommer resursen att fungera bra under tester, men i produktion kommer det att g\u00e5 fel vid n\u00e5got tillf\u00e4lle.<\/p><\/blockquote>\n

Skillnader mellan belastningstest och stresstest<\/b>
\nBelastningstestning l\u00e5ter oss identifiera systemets funktionsgr\u00e4nser. Stresstestning syftar till att hitta svaga punkter i systemet och anv\u00e4nds f\u00f6r att bryta ner systemet och se hur det beter sig n\u00e4r vissa delar misslyckas. Den typ av belastning \u00e4r vanligtvis ok\u00e4nd f\u00f6r kunden fram till b\u00f6rjan av stresstestningen.<\/p><\/blockquote>\n

<\/p>\n

Utm\u00e4rkande drag f\u00f6r L7-attacker<\/h3>\n

\nVi delar vanligtvis in belastningarna i belastningar p\u00e5 niv\u00e5 L7 och L3&4. L7 \u00e4r belastning p\u00e5 applikationsniv\u00e5, oftast tolkas den endast som HTTP, men vi menar all belastning p\u00e5 protokollniv\u00e5 TCP.
\nL7-attacker har vissa utm\u00e4rkande drag. F\u00f6r det f\u00f6rsta riktar de sig direkt mot applikationen, vilket g\u00f6r att det \u00e4r sv\u00e5rt att avv\u00e4rja dem med n\u00e4tverksmetoder. Dessa attacker utnyttjar logik och, tack vare detta, f\u00f6rbrukar de CPU, minne, disk, databas och andra resurser mycket effektivt \u00e4ven vid liten trafik.<\/p>\n

HTTP Flood<\/h3>\n

\nVid varje attack \u00e4r det l\u00e4ttare att skapa belastning \u00e4n att hantera den, och det g\u00e4ller ocks\u00e5 f\u00f6r L7. Attacktrafik \u00e4r inte alltid l\u00e4tt att s\u00e4rskilja fr\u00e5n legitim trafik, och oftast kan detta g\u00f6ras utifr\u00e5n frekvens, men om allt \u00e4r v\u00e4lplanerat \u00e4r det om\u00f6jligt att f\u00f6rst\u00e5 genom loggarna var attacken \u00e4r och var de legitima f\u00f6rfr\u00e5gningarna \u00e4r.
\nSom ett f\u00f6rsta exempel kan vi titta p\u00e5 HTTP Flood-attacken. Diagrammet visar att s\u00e5dana attacker vanligtvis \u00e4r v\u00e4ldigt kraftfulla, i exemplet nedan \u00f6versteg det toppantalet f\u00f6rfr\u00e5gningar 600 000 per minut.<\/p>\n

\"DDoS
\n
\nHTTP Flood \u00e4r det enklaste s\u00e4ttet att skapa belastning. Vanligtvis anv\u00e4nds n\u00e5got verktyg f\u00f6r belastningstestning, till exempel ApacheBench, och en f\u00f6rfr\u00e5gan och ett m\u00e5l st\u00e4lls in. Med denna enkla metod \u00e4r det stor risk att st\u00f6ta p\u00e5 servernas caching, men detta kan enkelt kringg\u00e5s. Till exempel, genom att l\u00e4gga till slumpm\u00e4ssiga str\u00e4ngar i f\u00f6rfr\u00e5gan, vilket tvingar servern att st\u00e4ndigt leverera en f\u00e4rsk sida.
\nKom ih\u00e5g anv\u00e4ndaragenten under belastningen. M\u00e5nga anv\u00e4ndaragent f\u00f6r popul\u00e4ra testverktyg filtreras av systemadministrat\u00f6rer, och i s\u00e5dana fall kan belastningen helt enkelt missa att n\u00e5 backend. Resultatet kan avsev\u00e4rt f\u00f6rb\u00e4ttras genom att infoga en mer eller mindre giltig rubrik fr\u00e5n en webbl\u00e4sare i f\u00f6rfr\u00e5gan.
\nTrots enkelheten har HTTP Flood-attacker sina nackdelar. F\u00f6r det f\u00f6rsta kr\u00e4ver belastningen stora resurser. F\u00f6r det andra \u00e4r s\u00e5dana attacker v\u00e4ldigt l\u00e4tta att uppt\u00e4cka, s\u00e4rskilt om de kommer fr\u00e5n en enda adress. Resultatet blir att f\u00f6rfr\u00e5gningarna omedelbart b\u00f6rjar filtreras av antingen systemadministrat\u00f6rerna eller till och med p\u00e5 leverant\u00f6rsniv\u00e5. <\/p>\n

Vad man ska leta efter<\/h3>\n

\nF\u00f6r att minska antalet f\u00f6rfr\u00e5gningar per sekund utan att f\u00f6rlora i effektivitet, beh\u00f6ver man anv\u00e4nda lite fantasi och unders\u00f6ka webbplatsen. Man kan belasta inte bara kanalen eller servern, utan \u00e4ven specifika delar av applikationen, som till exempel databaser eller filsystem. Dessutom kan man leta efter st\u00e4llen p\u00e5 webbplatsen som g\u00f6r stora ber\u00e4kningar: kalkylatorer, sidor med produktval och liknande. Slutligen h\u00e4nder det ofta att webbplatsen har ett php-skript som genererar sidor fr\u00e5n flera hundratusen rader. Ett s\u00e5dant skript belastar ocks\u00e5 servern avsev\u00e4rt och kan bli ett m\u00e5l f\u00f6r attacker.<\/p>\n

Var man ska s\u00f6ka<\/h3>\n

\nN\u00e4r vi skannar resursen innan testning, tittar vi naturligtvis f\u00f6rst och fr\u00e4mst p\u00e5 sj\u00e4lva webbplatsen. Vi letar efter alla m\u00f6jliga inmatningsf\u00e4lt, tunga filer \u2013 helt enkelt allt som kan skapa problem f\u00f6r resursen och sakta ner dess arbete. H\u00e4r hj\u00e4lper de banala utvecklingsverktygen i Google Chrome och Firefox som visar sidans responstider.
\nVi skannar ocks\u00e5 underdom\u00e4ner. Till exempel, det finns en viss onlinebutik, abc.com, och den har en underdom\u00e4n admin.abc.com. Det \u00e4r troligen en administrationssida med autentisering, men om vi belastar den, kan den skapa problem f\u00f6r huvudresursen.
\nWebbplatsen kan ha en underdom\u00e4n api.abc.com. Det \u00e4r troligen en resurs f\u00f6r mobilapplikationer. Applikationen kan hittas i App Store eller Google Play, s\u00e4tta upp en speciell \u00e5tkomstpunkt, analysera API:et och registrera testkonton. Problemet \u00e4r att m\u00e4nniskor ofta tror att allt som skyddas av autentisering \u00e4r of\u00f6rl\u00e5tligt f\u00f6r attacker av tj\u00e4nsteavbrott. Man anser att autentisering \u00e4r den b\u00e4sta CAPTCHA:n, men s\u00e5 \u00e4r det inte. Att skapa 10-20 testkonton \u00e4r enkelt, och n\u00e4r vi gjort det f\u00e5r vi tillg\u00e5ng till komplex och exponerad funktionalitet.
\nSj\u00e4lvklart ser vi p\u00e5 historiken, p\u00e5 robots.txt och WebArchive, ViewDNS, s\u00f6ker efter gamla versioner av resursen. Ibland h\u00e4nder det att utvecklarna har lanserat, s\u00e4g, mail2.yandex.net, medan den gamla versionen, mail.yandex.net, fortfarande finns kvar. Den h\u00e4r mail.yandex.net slutar att st\u00f6djas, avs\u00e4tts inte resurser till utvecklingen av den, men den forts\u00e4tter att konsumera databasen. D\u00e4rf\u00f6r kan man effektivt anv\u00e4nda resurserna i backend och allt som st\u00e5r bakom markup med hj\u00e4lp av den gamla versionen. Sj\u00e4lvklart h\u00e4nder det inte alltid, men vi st\u00f6ter \u00e4nd\u00e5 p\u00e5 liknande situationer ganska ofta.
\nSj\u00e4lvklart analyserar vi alla f\u00f6rfr\u00e5gningsparametrar och cookie-strukturen. Man kan till exempel skicka ett v\u00e4rde i en JSON-array inuti en cookie, skapa stor inb\u00e4ddning och f\u00e5 resursen att fungera on\u00f6digt l\u00e4nge.<\/p>\n

Belastning i s\u00f6kningen<\/h3>\n

\nDet f\u00f6rsta som kommer att t\u00e4nka p\u00e5 vid en webbplatsunders\u00f6kning \u00e4r att belasta databasen, eftersom n\u00e4stan alla har s\u00f6kfunktioner, och tyv\u00e4rr \u00e4r de flesta av dessa d\u00e5ligt skyddade. Av n\u00e5gon anledning \u00e4gnar utvecklarna inte tillr\u00e4cklig uppm\u00e4rksamhet \u00e5t s\u00f6kningen. Men h\u00e4r finns ett tips \u2014 undvik att g\u00f6ra likartade fr\u00e5gor, eftersom du kan st\u00f6ta p\u00e5 caching, precis som vid HTTP-flod.
\nAtt g\u00f6ra slumpm\u00e4ssiga f\u00f6rfr\u00e5gningar till databasen \u00e4r inte alltid effektivt. Det \u00e4r mycket b\u00e4ttre att skapa en lista \u00f6ver nyckelord som relaterar till s\u00f6kningen. \u00c5terigen, om vi tar exemplet med en webbshop: anta att webbplatsen s\u00e4ljer d\u00e4ck och g\u00f6r det m\u00f6jligt att ange d\u00e4cks radie, typ av bil och andra parametrar. Kombinationerna av relevanta ord f\u00e5r databasen att arbeta under betydligt mer komplexa f\u00f6rh\u00e5llanden.
\nDessutom b\u00f6r man anv\u00e4nda pagination: det \u00e4r mycket sv\u00e5rare f\u00f6r s\u00f6kningen att ge den n\u00e4st sista sidan av resultatet \u00e4n den f\u00f6rsta. Det inneb\u00e4r att man kan diversifiera belastningen n\u00e5got med hj\u00e4lp av pagination.
\nExemplet nedan visar belastningen vid s\u00f6kningen. Det syns att fr\u00e5n f\u00f6rsta sekunden av testet p\u00e5 hastighet med tio f\u00f6rfr\u00e5gningar per sekund l\u00e5g sajten ner och svarade inte.<\/p>\n

\"DDoS
\n<\/p>\n

Finns det ingen s\u00f6kning?<\/h3>\n

\nOm det inte finns n\u00e5gon s\u00f6kning, betyder det inte att webbplatsen inte inneh\u00e5ller andra s\u00e5rbara inmatningsf\u00e4lt. Ett s\u00e5dant f\u00e4lt kan vara autentisering. Utvecklarna \u00e4lskar nu att g\u00f6ra komplexa hashar f\u00f6r att skydda databasen med anv\u00e4ndarnamn fr\u00e5n attacker med regnb\u00e5gsdiagram. Det \u00e4r bra, men s\u00e5dana hashar kr\u00e4ver stora CPU-resurser. En stor str\u00f6m av falska autentiseringar orsakar processoravbrott, vilket g\u00f6r att webbplatsen slutar fungera.
\nN\u00e4rvaron av olika formul\u00e4r f\u00f6r kommentarer och feedback p\u00e5 webbplatsen ger anledning att skicka mycket stora texter d\u00e4r, eller helt enkelt skapa massivt spam. Ibland accepterar webbplatser inb\u00e4ddade filer, inklusive i gzip-format. I s\u00e5 fall tar vi en fil som \u00e4r 1TB stor, komprimerar den med gzip till n\u00e5gra byte eller kilobyte och skickar till webbplatsen. D\u00e4refter avzippar den sig och f\u00e5r en mycket intressant effekt. <\/p>\n

Rest API<\/h3>\n

\nDet \u00e4r viktigt att uppm\u00e4rksamma de popul\u00e4ra tj\u00e4nsterna som Rest API. Att skydda ett Rest API \u00e4r mycket sv\u00e5rare \u00e4n att skydda en vanlig webbplats. Vanliga metoder f\u00f6r att skydda mot l\u00f6senords\u00e5terst\u00e4llningar och annan olaglig aktivitet fungerar inte ens f\u00f6r Rest API.
\nRest API \u00e4r mycket l\u00e4tt att bryta sig in i eftersom det kommunicerar direkt med databasen. Att sabotera en s\u00e5dan tj\u00e4nst f\u00e5r allvarliga konsekvenser f\u00f6r f\u00f6retaget. Problemet \u00e4r att Rest API ofta \u00e4r kopplat till inte bara huvudwebbplatsen utan \u00e4ven mobilapplikationen och interna aff\u00e4rsresurser. Om allt detta g\u00e5r ner blir effekten mycket starkare \u00e4n vid en enkel webbplats krascher. <\/p>\n

Belastning p\u00e5 tungt inneh\u00e5ll<\/h3>\n

\nOm vi ombeds att testa en vanlig landningssida eller en webbplats utan komplex funktionalitet letar vi efter tungt inneh\u00e5ll. Till exempel stora bilder som servern levererar, bin\u00e4ra filer, pdf-dokumentation \u2013 vi f\u00f6rs\u00f6ker ladda ner allt detta. S\u00e5dana tester belastar filsystemet bra och blockerar kanalerna, vilket g\u00f6r dem effektiva. Det vill s\u00e4ga, \u00e4ven om du inte lyckas krascha servern genom att ladda ner en stor fil i l\u00e5g hastighet, kommer du helt enkelt att blockera kanalen till den avsedda servern, vilket leder till driftstopp.
\nExemplet visar att vid en hastighet av 30 RPS slutade webbplatsen att svara eller gav 500-fel.<\/p>\n

\"DDoS
\n
\nGl\u00f6m inte att konfigurera servrarna. Man st\u00f6ter ofta p\u00e5 att n\u00e5gon k\u00f6pt en virtuell server, installerat Apache, st\u00e4llt in allt som standard, placerat php-applikationen, och nedan kan man se resultatet. <\/p>\n

\"DDoS
\n
\nH\u00e4r var belastningen riktad mot roten och var endast 10 RPS. Vi v\u00e4ntade 5 minuter, och servern kraschade. Det \u00e4r dock oklart varf\u00f6r den kraschade, men man tror att den helt enkelt blev \u00f6verbelastad av minne, vilket fick den att sluta svara.<\/p>\n

Wave based<\/h3>\n

\nUnder de senaste \u00e5ret eller tv\u00e5 har v\u00e5gattacker blivit ganska popul\u00e4ra. Detta beror p\u00e5 att m\u00e5nga organisationer k\u00f6per olika produkter f\u00f6r att skydda sig mot DDoS-attacker, vilka kr\u00e4ver viss tid f\u00f6r att samla statistik innan de kan b\u00f6rja filtrera attacken. Det vill s\u00e4ga, de filtrerar inte attacken under de f\u00f6rsta 30-40 sekunderna, eftersom de samlar in data och l\u00e4r sig. D\u00e4rf\u00f6r kan man under dessa 30-40 sekunder skicka s\u00e5 mycket trafik till sajten att resurserna blir \u00f6verbelastade under en l\u00e5ng tid innan alla f\u00f6rfr\u00e5gningar har hanterats.
\nI fallet med attacken nedan fanns det en period p\u00e5 10 minuter, varefter en ny, modifierad attack kom.<\/p>\n

\"DDoS
\n
\nDet vill s\u00e4ga, skyddet l\u00e4rde sig, underkastade filtrering, men en ny, helt annan attack kom, och skyddet b\u00f6rjade l\u00e4ra sig igen. Faktiskt slutar filtreringen att fungera, skyddet blir ineffektivt och sajten blir otillg\u00e4nglig.
\nF\u00f6r v\u00e5gattacker k\u00e4nnetecknas av mycket h\u00f6ga v\u00e4rden p\u00e5 toppen, den kan n\u00e5 upp till hundratusen eller en miljon f\u00f6rfr\u00e5gningar per sekund, i fallet med L7. Om vi pratar om L3 & 4, kan det vara hundratals gigabit trafik, eller flera hundra mpps om vi r\u00e4knar i paket.
\nProblemet med s\u00e5dana attacker ligger i synkroniseringen. Attacken kommer fr\u00e5n ett botn\u00e4t, och f\u00f6r att skapa en v\u00e4ldigt stor eng\u00e5ngstopp kr\u00e4vs en h\u00f6g grad av synkronisering. Och denna koordination uppn\u00e5s inte alltid: ibland resulterar det i en parabolisk topp som ser ganska bedr\u00f6vlig ut.<\/p>\n

Inte bara HTTP<\/h3>\n

\nF\u00f6rutom HTTP p\u00e5 L7, \u00e4lskar vi att utnyttja andra protokoll. Normalt har vanliga webbplatser, s\u00e4rskilt p\u00e5 vanlig hosting, \u00f6ppna e-postprotokoll och MySQL. E-postprotokoll \u00e4r mindre utsatta f\u00f6r belastning \u00e4n databaser, men de kan ocks\u00e5 belastas ganska effektivt och f\u00e5 en \u00f6verbelastad CPU p\u00e5 servern.
\nVi har faktiskt lyckats utnyttja en SSH-s\u00e5rbarhet fr\u00e5n 2016. Denna s\u00e5rbarhet har nu n\u00e4stan \u00e5tg\u00e4rdats av alla, men det betyder inte att man inte kan belasta SSH. Det g\u00e5r. Man skickar helt enkelt en enorm belastning av autentiseringar, SSH tar upp n\u00e4stan hela CPU:n p\u00e5 servern och sajten kraschar redan vid en till tv\u00e5 f\u00f6rfr\u00e5gningar per sekund. D\u00e4rf\u00f6r g\u00e5r dessa en eller tv\u00e5 f\u00f6rfr\u00e5gningar i loggarna inte att s\u00e4rskilja fr\u00e5n legitim belastning.
\nDet finns fortfarande m\u00e5nga anslutningar som vi \u00f6ppnar p\u00e5 servrar. Tidigare var det ett problem med Apache, och nu drabbar det faktiskt \u00e4ven nginx, eftersom det ofta \u00e4r felkonfigurerat som standard. Antalet anslutningar som nginx kan h\u00e5lla \u00f6ppna \u00e4r begr\u00e4nsat, vilket inneb\u00e4r att n\u00e4r vi n\u00e5r detta antal tar nginx inte emot nya anslutningar, och resultatet \u00e4r att webbplatsen slutar fungera.
\nV\u00e5rt testkluster har tillr\u00e4ckligt med CPU f\u00f6r att attackera SSL-handshake. I praktiken \u00e4r det tydligt att botn\u00e4t ibland ocks\u00e5 gillar att g\u00f6ra detta. \u00c5 ena sidan \u00e4r det sj\u00e4lvklart att SSL \u00e4r n\u00f6dv\u00e4ndigt, eftersom det \u00e4r viktigt f\u00f6r Googles resultat, rankning och s\u00e4kerhet. \u00c5 andra sidan har SSL tyv\u00e4rr problem med CPU. <\/p>\n

L3&4<\/h3>\n

\nN\u00e4r vi pratar om attacker p\u00e5 niv\u00e5er L3&4 talar vi oftast om attacker p\u00e5 kanalsniv\u00e5. S\u00e5dan belastning \u00e4r n\u00e4stan alltid tydligt \u00e5tskiljbar fr\u00e5n legitim trafik, om det inte \u00e4r en SYN-flood attack. SYN-flood problem f\u00f6r s\u00e4kerhetsmedel best\u00e5r i det stora trafikvolymen. Den maximala storleken f\u00f6r L3&4 har varit 1,5-2 Tbit\/s. En s\u00e5dan trafik \u00e4r mycket sv\u00e5r att hantera \u00e4ven f\u00f6r stora f\u00f6retag, inklusive Oracle och Google.
\nSYN och SYN-ACK \u00e4r paket som anv\u00e4nds vid anslutningsuppr\u00e4ttande. D\u00e4rf\u00f6r \u00e4r det sv\u00e5rt att skilja SYN-flood fr\u00e5n legitim belastning: det \u00e4r oklart om det \u00e4r SYN-paketet som kom f\u00f6r att etablera en anslutning, eller en del av floden.<\/p>\n

UDP-flood<\/h3>\n

\nVanligtvis har angripare inte den kraft som vi har, s\u00e5 de kan anv\u00e4nda amplification f\u00f6r att genomf\u00f6ra attacker. Det vill s\u00e4ga, angriparen skannar internet och hittar antingen s\u00e5rbara eller felkonfigurerade servrar, som till exempel svarar med tre SYN-ACK-paket p\u00e5 ett enda SYN-paket. Genom att f\u00f6rfalska k\u00e4lladressen fr\u00e5n m\u00e5ltj\u00e4nstens adress kan man \u00f6ka kraften, s\u00e4g tre g\u00e5nger, med ett enda paket och omdirigera trafiken till m\u00e5let.<\/p>\n

\"DDoS
\n
\nProblemet med amplification ligger i deras sv\u00e5ra uppt\u00e4ckbarhet. Ett av de senaste exemplen \u00e4r den uppm\u00e4rksammade s\u00e5rbarheten med memcached. Dessutom har det nu dykt upp m\u00e5nga IoT-enheter, IP-kameror, som ocks\u00e5 oftast \u00e4r felkonfigurerade som standard, vilket g\u00f6r att angripare ofta utnyttjar dessa enheter f\u00f6r sina attacker. <\/p>\n

\"DDoS
\n<\/p>\n

Nyckfull SYN-flood<\/h3>\n

\nSYN-flood \u00e4r kanske den mest intressanta typen av attacker sett ur utvecklarens perspektiv. Problemet \u00e4r att systemadministrat\u00f6rer ofta anv\u00e4nder IP-blockering som skydd. D\u00e5 drabbas inte bara administrat\u00f6rer som arbetar med skript utan tyv\u00e4rr \u00e4ven vissa skyddssystem som k\u00f6ps f\u00f6r stora pengar.
\nEn s\u00e5dan metod kan bli katastrofal, f\u00f6r om angriparna byter ut IP-adresser<\/a>, s\u00e5 kommer f\u00f6retaget att blockera sitt eget n\u00e4tverk. N\u00e4r brandv\u00e4ggen blockerar sin egen kluster kommer externa interaktioner att kollapsa och resursen att g\u00e5 s\u00f6nder.
\nDessutom \u00e4r det inte sv\u00e5rt att uppn\u00e5 blockering av sitt eget n\u00e4tverk. Om klientens kontor har ett Wi-Fi-n\u00e4tverk, eller om resursernas funktionalitet m\u00e4ts med hj\u00e4lp av olika \u00f6vervakningssystem, s\u00e5 tar vi IP-adressen f\u00f6r detta \u00f6vervakningssystem eller kontorets Wi-Fi-klient och anv\u00e4nder den som k\u00e4lla. Utg\u00e5ngen ser ut att vara tillg\u00e4nglig, men de m\u00e5linriktade IP-adresserna \u00e4r blockerade. P\u00e5 s\u00e5 s\u00e4tt kan Wi-Fi-n\u00e4tverket f\u00f6r konferensen HighLoad blockeras, d\u00e4r f\u00f6retagets nya produkt presenteras \u2014 och detta medf\u00f6r vissa aff\u00e4rs- och ekonomiska kostnader.
\nUnder testningen kan vi inte anv\u00e4nda f\u00f6rst\u00e4rkning via memcached med externa resurser, eftersom det finns avtal om att trafik endast f\u00e5r skickas till till\u00e5tna IP-adresser. D\u00e4rf\u00f6r anv\u00e4nder vi f\u00f6rst\u00e4rkning via SYN och SYN-ACK, d\u00e4r f\u00f6r varje skickad SYN svarar systemet med tv\u00e5 till tre SYN-ACK, vilket g\u00f6r att attacken multipliceras med tv\u00e5 till tre g\u00e5nger. <\/p>\n

Verktyg<\/h3>\n

\nEtt av de huvudsakliga verktygen vi anv\u00e4nder f\u00f6r belastning p\u00e5 L7-niv\u00e5 \u00e4r Yandex-tank. I synnerhet anv\u00e4nds Phantom som kanon, plus n\u00e5gra skript f\u00f6r att generera kulor och f\u00f6r att analysera resultaten.
\nF\u00f6r att analysera n\u00e4tverkstrafik anv\u00e4nds Tcpdump, f\u00f6r att analysera servern anv\u00e4nds Nmap. F\u00f6r att skapa belastning p\u00e5 L3&4-niv\u00e5 anv\u00e4nds OpenSSL och lite egen magi med DPDK-biblioteket. DPDK \u00e4r ett bibliotek fr\u00e5n Intel som m\u00f6jligg\u00f6r arbete med n\u00e4tverksgr\u00e4nssnittet, f\u00f6rbi Linux-stacken, vilket \u00f6kar effektiviteten. Sj\u00e4lvklart anv\u00e4nder vi DPDK inte bara p\u00e5 L3&4-niv\u00e5 utan ocks\u00e5 p\u00e5 L7-niv\u00e5, eftersom det m\u00f6jligg\u00f6r att skapa en mycket h\u00f6g belastning av flera miljoner beg\u00e4rningar per sekund fr\u00e5n en maskin.
\nVi anv\u00e4nder ocks\u00e5 specifika trafikgenererare och verktyg som vi skriver f\u00f6r specifika tester. Om vi minns s\u00e5rbarheten under SSH, kan den ovan n\u00e4mnda upps\u00e4ttningen inte utnyttjas. Om vi attackerar postprotokollet tar vi postverktyg eller skriver bara skript f\u00f6r dem.<\/p>\n

\n

Slutsatser<\/h3>\n

\nSom avslutning vill jag s\u00e4ga:<\/p>\n