DDoS till hjälp: hur vi genomför stress- och belastningstester

Företaget Variti utvecklar skydd mot botar och DDoS-attacker samt genomför stresstest och belastningstestning. På konferensen HighLoad++ 2018 berättade vi om hur man skyddar resurser mot olika typer av attacker. Kort sagt: isolera delar av systemet, använd molntjänster och CDN och håll er regelbundet uppdaterade. Men utan specialiserade företag för skydd klarar ni er inte själva 🙂

Innan ni läser texten kan ni ta del av korta punkter på konferensens webbplats.
Och om ni inte gillar att läsa eller bara vill titta på videon, finns inspelningen av vårt föredrag nedan under spoiler.

Videoinspelning av föredraget

Många företag kan redan genomföra belastningstest, men inte alla gör stresstest. Några av våra kunder tror att deras webbplats är oförsvarande eftersom de har ett highload-system, och det skyddar dem väl mot attacker. Vi visar dock att detta inte riktigt stämmer.
Självklart får vi tillstånd från kunden innan tester genomförs, med signatur och stämpel, och med vår hjälp kan man inte utföra DDoS-attacker mot någon. Testning sker vid en tidpunkt som kunden väljer, när besöksnivån för deras resurs är minimal, så att problem med åtkomst inte påverkar kunderna. Dessutom, eftersom det alltid kan gå fel under testprocessen, har vi ständig kontakt med kunden. Detta möjliggör inte bara att rapportera uppnådda resultat utan också att göra ändringar under testningen. Vid avslutningen av testningen upprättar vi alltid en rapport där vi påpekar upptäckta brister och ger rekommendationer för att åtgärda svaga punkter på webbplatsen.

Så här arbetar vi

Vid genomförande av testningen emulerar vi ett botnät. Eftersom vi arbetar med kunder som inte är lokaliserade i våra nätverk, för att testet inte ska avslutas på första minuten på grund av begränsningar eller skydd, ger vi belastningen inte från en IP, utan från vårt eget subnet. Dessutom, för att skapa en betydande belastning har vi en kraftfull testserver.

Postulat

Mycket betyder inte bra
Ju lägre belastning vi kan få resursen att gå ner på, desto bättre. Om vi kan få sidan att sluta fungera vid en begäran per sekund, eller till och med en begäran per minut, är det fantastiskt. För enligt Murphy's lag kommer användare eller angripare av en slump att utnyttja just denna sårbarhet.

Delvis fel är bättre än totalt fel
Vi rekommenderar alltid att göra systemen heterogena. Det är viktigt att separera dem på fysisk nivå, inte bara genom containerisering. Vid fysisk separation, även om något går fel på sidan, är det troligt att det inte helt slutar fungera, och användare fortfarande har tillgång till åtminstone en del av funktionaliteten.

Rätt arkitektur är grundläggande för motståndskraft
Resursens redundans och dess förmåga att hantera attacker och belastningar bör beaktas redan under designsteget, praktiskt taget i skedet av att rita de första blockdiagrammen i anteckningsboken. För om fatala fel slinker in kan de vara svåra att rätta till senare.

Inte bara koden, utan även konfigurationen bör vara bra
Många tror att ett bra utvecklingsteam garanterar tjänstens redundans. Ett bra utvecklingsteam är verkligen nödvändigt, men det måste också finnas god drift, bra DevOps. Det innebär att det behövs specialister som korrekt konfigurerar Linux och nätverket, korrekt skriver konfigurationer i nginx, ställer in gränser och så vidare. Annars kommer resursen att fungera bra under tester, men i produktion kommer det att gå fel vid något tillfälle.

Skillnader mellan belastningstest och stresstest
Belastningstestning låter oss identifiera systemets funktionsgränser. Stresstestning syftar till att hitta svaga punkter i systemet och används för att bryta ner systemet och se hur det beter sig när vissa delar misslyckas. Den typ av belastning är vanligtvis okänd för kunden fram till början av stresstestningen.

Utmärkande drag för L7-attacker

Vi delar vanligtvis in belastningarna i belastningar på nivå L7 och L3&4. L7 är belastning på applikationsnivå, oftast tolkas den endast som HTTP, men vi menar all belastning på protokollnivå TCP.
L7-attacker har vissa utmärkande drag. För det första riktar de sig direkt mot applikationen, vilket gör att det är svårt att avvärja dem med nätverksmetoder. Dessa attacker utnyttjar logik och, tack vare detta, förbrukar de CPU, minne, disk, databas och andra resurser mycket effektivt även vid liten trafik.

HTTP Flood

Vid varje attack är det lättare att skapa belastning än att hantera den, och det gäller också för L7. Attacktrafik är inte alltid lätt att särskilja från legitim trafik, och oftast kan detta göras utifrån frekvens, men om allt är välplanerat är det omöjligt att förstå genom loggarna var attacken är och var de legitima förfrågningarna är.
Som ett första exempel kan vi titta på HTTP Flood-attacken. Diagrammet visar att sådana attacker vanligtvis är väldigt kraftfulla, i exemplet nedan översteg det toppantalet förfrågningar 600 000 per minut.

HTTP Flood är det enklaste sättet att skapa belastning. Vanligtvis används något verktyg för belastningstestning, till exempel ApacheBench, och en förfrågan och ett mål ställs in. Med denna enkla metod är det stor risk att stöta på servernas caching, men detta kan enkelt kringgås. Till exempel, genom att lägga till slumpmässiga strängar i förfrågan, vilket tvingar servern att ständigt leverera en färsk sida.
Kom ihåg användaragenten under belastningen. Många användaragent för populära testverktyg filtreras av systemadministratörer, och i sådana fall kan belastningen helt enkelt missa att nå backend. Resultatet kan avsevärt förbättras genom att infoga en mer eller mindre giltig rubrik från en webbläsare i förfrågan.
Trots enkelheten har HTTP Flood-attacker sina nackdelar. För det första kräver belastningen stora resurser. För det andra är sådana attacker väldigt lätta att upptäcka, särskilt om de kommer från en enda adress. Resultatet blir att förfrågningarna omedelbart börjar filtreras av antingen systemadministratörerna eller till och med på leverantörsnivå.

Vad man ska leta efter

För att minska antalet förfrågningar per sekund utan att förlora i effektivitet, behöver man använda lite fantasi och undersöka webbplatsen. Man kan belasta inte bara kanalen eller servern, utan även specifika delar av applikationen, som till exempel databaser eller filsystem. Dessutom kan man leta efter ställen på webbplatsen som gör stora beräkningar: kalkylatorer, sidor med produktval och liknande. Slutligen händer det ofta att webbplatsen har ett php-skript som genererar sidor från flera hundratusen rader. Ett sådant skript belastar också servern avsevärt och kan bli ett mål för attacker.

Var man ska söka

När vi skannar resursen innan testning, tittar vi naturligtvis först och främst på själva webbplatsen. Vi letar efter alla möjliga inmatningsfält, tunga filer – helt enkelt allt som kan skapa problem för resursen och sakta ner dess arbete. Här hjälper de banala utvecklingsverktygen i Google Chrome och Firefox som visar sidans responstider.
Vi skannar också underdomäner. Till exempel, det finns en viss onlinebutik, abc.com, och den har en underdomän admin.abc.com. Det är troligen en administrationssida med autentisering, men om vi belastar den, kan den skapa problem för huvudresursen.
Webbplatsen kan ha en underdomän api.abc.com. Det är troligen en resurs för mobilapplikationer. Applikationen kan hittas i App Store eller Google Play, sätta upp en speciell åtkomstpunkt, analysera API:et och registrera testkonton. Problemet är att människor ofta tror att allt som skyddas av autentisering är oförlåtligt för attacker av tjänsteavbrott. Man anser att autentisering är den bästa CAPTCHA:n, men så är det inte. Att skapa 10-20 testkonton är enkelt, och när vi gjort det får vi tillgång till komplex och exponerad funktionalitet.
Självklart ser vi på historiken, på robots.txt och WebArchive, ViewDNS, söker efter gamla versioner av resursen. Ibland händer det att utvecklarna har lanserat, säg, mail2.yandex.net, medan den gamla versionen, mail.yandex.net, fortfarande finns kvar. Den här mail.yandex.net slutar att stödjas, avsätts inte resurser till utvecklingen av den, men den fortsätter att konsumera databasen. Därför kan man effektivt använda resurserna i backend och allt som står bakom markup med hjälp av den gamla versionen. Självklart händer det inte alltid, men vi stöter ändå på liknande situationer ganska ofta.
Självklart analyserar vi alla förfrågningsparametrar och cookie-strukturen. Man kan till exempel skicka ett värde i en JSON-array inuti en cookie, skapa stor inbäddning och få resursen att fungera onödigt länge.

Belastning i sökningen

Det första som kommer att tänka på vid en webbplatsundersökning är att belasta databasen, eftersom nästan alla har sökfunktioner, och tyvärr är de flesta av dessa dåligt skyddade. Av någon anledning ägnar utvecklarna inte tillräcklig uppmärksamhet åt sökningen. Men här finns ett tips — undvik att göra likartade frågor, eftersom du kan stöta på caching, precis som vid HTTP-flod.
Att göra slumpmässiga förfrågningar till databasen är inte alltid effektivt. Det är mycket bättre att skapa en lista över nyckelord som relaterar till sökningen. Återigen, om vi tar exemplet med en webbshop: anta att webbplatsen säljer däck och gör det möjligt att ange däcks radie, typ av bil och andra parametrar. Kombinationerna av relevanta ord får databasen att arbeta under betydligt mer komplexa förhållanden.
Dessutom bör man använda pagination: det är mycket svårare för sökningen att ge den näst sista sidan av resultatet än den första. Det innebär att man kan diversifiera belastningen något med hjälp av pagination.
Exemplet nedan visar belastningen vid sökningen. Det syns att från första sekunden av testet på hastighet med tio förfrågningar per sekund låg sajten ner och svarade inte.

Finns det ingen sökning?

Om det inte finns någon sökning, betyder det inte att webbplatsen inte innehåller andra sårbara inmatningsfält. Ett sådant fält kan vara autentisering. Utvecklarna älskar nu att göra komplexa hashar för att skydda databasen med användarnamn från attacker med regnbågsdiagram. Det är bra, men sådana hashar kräver stora CPU-resurser. En stor ström av falska autentiseringar orsakar processoravbrott, vilket gör att webbplatsen slutar fungera.
Närvaron av olika formulär för kommentarer och feedback på webbplatsen ger anledning att skicka mycket stora texter där, eller helt enkelt skapa massivt spam. Ibland accepterar webbplatser inbäddade filer, inklusive i gzip-format. I så fall tar vi en fil som är 1TB stor, komprimerar den med gzip till några byte eller kilobyte och skickar till webbplatsen. Därefter avzippar den sig och får en mycket intressant effekt.

Rest API

Det är viktigt att uppmärksamma de populära tjänsterna som Rest API. Att skydda ett Rest API är mycket svårare än att skydda en vanlig webbplats. Vanliga metoder för att skydda mot lösenordsåterställningar och annan olaglig aktivitet fungerar inte ens för Rest API.
Rest API är mycket lätt att bryta sig in i eftersom det kommunicerar direkt med databasen. Att sabotera en sådan tjänst får allvarliga konsekvenser för företaget. Problemet är att Rest API ofta är kopplat till inte bara huvudwebbplatsen utan även mobilapplikationen och interna affärsresurser. Om allt detta går ner blir effekten mycket starkare än vid en enkel webbplats krascher.

Belastning på tungt innehåll

Om vi ombeds att testa en vanlig landningssida eller en webbplats utan komplex funktionalitet letar vi efter tungt innehåll. Till exempel stora bilder som servern levererar, binära filer, pdf-dokumentation – vi försöker ladda ner allt detta. Sådana tester belastar filsystemet bra och blockerar kanalerna, vilket gör dem effektiva. Det vill säga, även om du inte lyckas krascha servern genom att ladda ner en stor fil i låg hastighet, kommer du helt enkelt att blockera kanalen till den avsedda servern, vilket leder till driftstopp.
Exemplet visar att vid en hastighet av 30 RPS slutade webbplatsen att svara eller gav 500-fel.

Glöm inte att konfigurera servrarna. Man stöter ofta på att någon köpt en virtuell server, installerat Apache, ställt in allt som standard, placerat php-applikationen, och nedan kan man se resultatet.

Här var belastningen riktad mot roten och var endast 10 RPS. Vi väntade 5 minuter, och servern kraschade. Det är dock oklart varför den kraschade, men man tror att den helt enkelt blev överbelastad av minne, vilket fick den att sluta svara.

Wave based

Under de senaste året eller två har vågattacker blivit ganska populära. Detta beror på att många organisationer köper olika produkter för att skydda sig mot DDoS-attacker, vilka kräver viss tid för att samla statistik innan de kan börja filtrera attacken. Det vill säga, de filtrerar inte attacken under de första 30-40 sekunderna, eftersom de samlar in data och lär sig. Därför kan man under dessa 30-40 sekunder skicka så mycket trafik till sajten att resurserna blir överbelastade under en lång tid innan alla förfrågningar har hanterats.
I fallet med attacken nedan fanns det en period på 10 minuter, varefter en ny, modifierad attack kom.

Det vill säga, skyddet lärde sig, underkastade filtrering, men en ny, helt annan attack kom, och skyddet började lära sig igen. Faktiskt slutar filtreringen att fungera, skyddet blir ineffektivt och sajten blir otillgänglig.
För vågattacker kännetecknas av mycket höga värden på toppen, den kan nå upp till hundratusen eller en miljon förfrågningar 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äknar i paket.
Problemet med sådana attacker ligger i synkroniseringen. Attacken kommer från ett botnät, och för att skapa en väldigt stor engångstopp krävs en hög grad av synkronisering. Och denna koordination uppnås inte alltid: ibland resulterar det i en parabolisk topp som ser ganska bedrövlig ut.

Inte bara HTTP

Förutom HTTP på L7, älskar vi att utnyttja andra protokoll. Normalt har vanliga webbplatser, särskilt på vanlig hosting, öppna e-postprotokoll och MySQL. E-postprotokoll är mindre utsatta för belastning än databaser, men de kan också belastas ganska effektivt och få en överbelastad CPU på servern.
Vi har faktiskt lyckats utnyttja en SSH-sårbarhet från 2016. Denna sårbarhet har nu nästan åtgärdats av alla, men det betyder inte att man inte kan belasta SSH. Det går. Man skickar helt enkelt en enorm belastning av autentiseringar, SSH tar upp nästan hela CPU:n på servern och sajten kraschar redan vid en till två förfrågningar per sekund. Därför går dessa en eller två förfrågningar i loggarna inte att särskilja från legitim belastning.
Det finns fortfarande många anslutningar som vi öppnar på servrar. Tidigare var det ett problem med Apache, och nu drabbar det faktiskt även nginx, eftersom det ofta är felkonfigurerat som standard. Antalet anslutningar som nginx kan hålla öppna är begränsat, vilket innebär att när vi når detta antal tar nginx inte emot nya anslutningar, och resultatet är att webbplatsen slutar fungera.
Vårt testkluster har tillräckligt med CPU för att attackera SSL-handshake. I praktiken är det tydligt att botnät ibland också gillar att göra detta. Å ena sidan är det självklart att SSL är nödvändigt, eftersom det är viktigt för Googles resultat, rankning och säkerhet. Å andra sidan har SSL tyvärr problem med CPU.

L3&4

När vi pratar om attacker på nivåer L3&4 talar vi oftast om attacker på kanalsnivå. Sådan belastning är nästan alltid tydligt åtskiljbar från legitim trafik, om det inte är en SYN-flood attack. SYN-flood problem för säkerhetsmedel består i det stora trafikvolymen. Den maximala storleken för L3&4 har varit 1,5-2 Tbit/s. En sådan trafik är mycket svår att hantera även för stora företag, inklusive Oracle och Google.
SYN och SYN-ACK är paket som används vid anslutningsupprättande. Därför är det svårt att skilja SYN-flood från legitim belastning: det är oklart om det är SYN-paketet som kom för att etablera en anslutning, eller en del av floden.

UDP-flood

Vanligtvis har angripare inte den kraft som vi har, så de kan använda amplification för att genomföra attacker. Det vill säga, angriparen skannar internet och hittar antingen sårbara eller felkonfigurerade servrar, som till exempel svarar med tre SYN-ACK-paket på ett enda SYN-paket. Genom att förfalska källadressen från måltjänstens adress kan man öka kraften, säg tre gånger, med ett enda paket och omdirigera trafiken till målet.

Problemet med amplification ligger i deras svåra upptäckbarhet. Ett av de senaste exemplen är den uppmärksammade sårbarheten med memcached. Dessutom har det nu dykt upp många IoT-enheter, IP-kameror, som också oftast är felkonfigurerade som standard, vilket gör att angripare ofta utnyttjar dessa enheter för sina attacker.

Nyckfull SYN-flood

SYN-flood är kanske den mest intressanta typen av attacker sett ur utvecklarens perspektiv. Problemet är att systemadministratörer ofta använder IP-blockering som skydd. Då drabbas inte bara administratörer som arbetar med skript utan tyvärr även vissa skyddssystem som köps för stora pengar.
En sådan metod kan bli katastrofal, för om angriparna byter ut IP-adresser, så kommer företaget att blockera sitt eget nätverk. När brandväggen blockerar sin egen kluster kommer externa interaktioner att kollapsa och resursen att gå sönder.
Dessutom är det inte svårt att uppnå blockering av sitt eget nätverk. Om klientens kontor har ett Wi-Fi-nätverk, eller om resursernas funktionalitet mäts med hjälp av olika övervakningssystem, så tar vi IP-adressen för detta övervakningssystem eller kontorets Wi-Fi-klient och använder den som källa. Utgången ser ut att vara tillgänglig, men de målinriktade IP-adresserna är blockerade. På så sätt kan Wi-Fi-nätverket för konferensen HighLoad blockeras, där företagets nya produkt presenteras — och detta medför vissa affärs- och ekonomiska kostnader.
Under testningen kan vi inte använda förstärkning via memcached med externa resurser, eftersom det finns avtal om att trafik endast får skickas till tillåtna IP-adresser. Därför använder vi förstärkning via SYN och SYN-ACK, där för varje skickad SYN svarar systemet med två till tre SYN-ACK, vilket gör att attacken multipliceras med två till tre gånger.

Verktyg

Ett av de huvudsakliga verktygen vi använder för belastning på L7-nivå är Yandex-tank. I synnerhet används Phantom som kanon, plus några skript för att generera kulor och för att analysera resultaten.
För att analysera nätverkstrafik används Tcpdump, för att analysera servern används Nmap. För att skapa belastning på L3&4-nivå används OpenSSL och lite egen magi med DPDK-biblioteket. DPDK är ett bibliotek från Intel som möjliggör arbete med nätverksgränssnittet, förbi Linux-stacken, vilket ökar effektiviteten. Självklart använder vi DPDK inte bara på L3&4-nivå utan också på L7-nivå, eftersom det möjliggör att skapa en mycket hög belastning av flera miljoner begärningar per sekund från en maskin.
Vi använder också specifika trafikgenererare och verktyg som vi skriver för specifika tester. Om vi minns sårbarheten under SSH, kan den ovan nämnda uppsättningen inte utnyttjas. Om vi attackerar postprotokollet tar vi postverktyg eller skriver bara skript för dem.

Slutsatser

Som avslutning vill jag säga:

• Förutom klassisk belastningstestning måste man också genomföra stresstestning. Vi har ett verkligt exempel där en underleverantör till en partner endast genomförde belastningstestning. Det visade att resurserna klarar den normala belastningen. Men sedan kom en ovanlig belastning, besökarna på webbplatsen började använda resursen på ett något annat sätt, — och i slutändan kraschade underleverantören. Så det är viktigt att leta efter sårbarheter, även om ni redan är skyddade mot DDoS-attacker.
• Det är nödvändigt att isolera vissa delar av systemet från andra. Om ni har en sökfunktion ska den flyttas till separata maskiner, alltså inte ens i Docker. För om sökningen eller autentiseringen misslyckas kommer åtminstone något fortsatt att fungera. I fallet med en webbutik kommer användarna att fortsätta hitta produkter via katalogen, gå in via aggregatorer, köpa om de redan är inloggade, eller logga in via OAuth2.
• Man ska inte försumma alla möjliga molntjänster.
• Använd CDN inte bara för att optimera nätverksfördröjningar, utan också som ett skydd mot attacker som utarmar kanalen och rent av mot floder av statisk trafik.
• Det är nödvändigt att använda specialiserade skyddstjänster. Mot L3&4-attacker på kanalnivå kommer ni inte att klara er själva, eftersom ni troligtvis helt enkelt inte har tillräcklig kapacitet. Mot L7-attacker kommer ni knappast att klara er, eftersom de kan vara mycket stora. Dessutom är det fortfarande specialiserade tjänster och algoritmer som ansvarar för att upptäcka små attacker.
• Uppdatera regelbundet. Detta gäller inte bara kärnan utan även SSH-daemon, särskilt om de är öppna mot omvärlden. I princip bör ni uppdatera allt, eftersom ni knappast kan övervaka vissa sårbarheter på egen hand.

Källa: habr.com