Variti udvikler beskyttelse mod bots og DDoS-angreb og udfører også stress- og belastningstest. På HighLoad++ 2018-konferencen talte vi om, hvordan man sikrer ressourcer fra forskellige typer angreb. Kort sagt: Isoler dele af systemet, brug cloud-tjenester og CDN'er, og opdater regelmæssigt. Men du vil stadig ikke kunne håndtere beskyttelse uden specialiserede virksomheder :)
Inden du læser teksten, kan du læse de korte abstracts .
Og hvis du ikke kan lide at læse eller bare vil se videoen, er optagelsen af vores rapport nedenfor under spoileren.
Videooptagelse af rapporten
Mange virksomheder ved allerede, hvordan man laver belastningstest, men ikke alle laver stresstest. Nogle af vores kunder mener, at deres side er usårbar, fordi de har et højbelastningssystem, og det beskytter godt mod angreb. Vi viser, at det ikke er helt rigtigt.
Inden vi udfører test, indhenter vi naturligvis tilladelse fra kunden, underskrevet og stemplet, og med vores hjælp kan et DDoS-angreb ikke udføres på nogen. Testning udføres på et tidspunkt, som kunden vælger, hvor trafikken til hans ressource er minimal, og adgangsproblemer ikke vil påvirke kunderne. Derudover, da noget altid kan gå galt under testprocessen, har vi konstant kontakt med kunden. Dette giver dig mulighed for ikke kun at rapportere de opnåede resultater, men også at ændre noget under testen. Efter afslutning af test udarbejder vi altid en rapport, hvori vi påpeger eventuelle konstaterede mangler og giver anbefalinger til at fjerne sidens svagheder.
Hvordan vi arbejder
Når vi tester, emulerer vi et botnet. Da vi arbejder med klienter, som ikke er placeret på vores netværk, for at sikre, at testen ikke slutter i det første minut på grund af begrænsninger eller beskyttelse, der udløses, leverer vi belastningen ikke fra én IP, men fra vores eget subnet. Plus, for at skabe en betydelig belastning, har vi vores egen ret kraftfulde testserver.
Postulater
For meget betyder ikke godt
Jo mindre belastning vi kan bringe en ressource til at fejle, jo bedre. Hvis du kan få siden til at stoppe med at fungere på én anmodning i sekundet, eller endda én anmodning i minuttet, er det fantastisk. For ifølge ondskabens lov vil brugere eller angribere ved et uheld falde i denne særlige sårbarhed.
Delvis fejl er bedre end fuldstændig fiasko
Vi anbefaler altid at gøre systemer heterogene. Desuden er det værd at adskille dem på det fysiske niveau, og ikke kun ved containerisering. I tilfælde af fysisk adskillelse, selvom noget fejler på siden, er der stor sandsynlighed for, at det ikke stopper helt med at fungere, og brugerne vil fortsat have adgang til i det mindste en del af funktionaliteten.
God arkitektur er grundlaget for bæredygtighed
En ressources fejltolerance og dens evne til at modstå angreb og belastninger bør fastlægges på designstadiet, faktisk på tidspunktet for tegning af de første rutediagrammer i en notesblok. For hvis fatale fejl kommer snigende, er det muligt at rette dem i fremtiden, men det er meget svært.
Ikke kun koden skal være god, men også konfigurationen
Mange tror, at et godt udviklingsteam er en garanti for fejltolerant service. Et godt udviklingsteam er virkelig nødvendigt, men der skal også være god drift, gode DevOps. Det vil sige, at vi har brug for specialister, der konfigurerer Linux og netværket korrekt, skriver konfigurationer korrekt i nginx, sætter grænser osv. Ellers vil ressourcen kun fungere godt i test, og på et tidspunkt vil alt gå i stykker i produktionen.
Forskelle mellem belastnings- og stresstest
Belastningstest giver dig mulighed for at identificere grænserne for systemets funktion. Stresstest er rettet mod at finde systemets svage punkter og bruges til at bryde dette system og se, hvordan det vil opføre sig i processen med fejl i visse dele. I dette tilfælde forbliver belastningens art normalt ukendt for kunden, før stresstestning begynder.
Karakteristiske træk ved L7-angreb
Vi opdeler normalt typer belastninger i belastninger på L7 og L3&4 niveauerne. L7 er en belastning på applikationsniveau, oftest betyder det kun HTTP, men vi mener enhver belastning på TCP-protokolniveau.
L7-angreb har visse særpræg. For det første kommer de direkte til applikationen, det vil sige, at det er usandsynligt, at de vil blive afspejlet via netværksmidler. Sådanne angreb bruger logik, og på grund af dette forbruger de CPU, hukommelse, disk, database og andre ressourcer meget effektivt og med lidt trafik.
HTTP Flood
I tilfælde af ethvert angreb er belastningen lettere at skabe end at håndtere, og i tilfælde af L7 er dette også sandt. Det er ikke altid nemt at skelne angrebstrafik fra legitim trafik, og oftest kan dette gøres efter frekvens, men hvis alt er planlagt korrekt, så er det umuligt ud fra loggene at forstå, hvor angrebet er, og hvor de legitime anmodninger er.
Som et første eksempel kan du overveje et HTTP Flood-angreb. Grafen viser, at sådanne angreb normalt er meget kraftige; i eksemplet nedenfor oversteg det maksimale antal anmodninger 600 tusinde pr. minut.
HTTP Flood er den nemmeste måde at skabe belastning på. Typisk kræver det en form for belastningstestværktøj, såsom ApacheBench, og sætter en anmodning og et mål. Med sådan en simpel tilgang er der stor sandsynlighed for at løbe ind i servercache, men det er nemt at omgå det. For eksempel tilføjelse af tilfældige strenge til anmodningen, hvilket vil tvinge serveren til konstant at vise en frisk side.
Glem heller ikke brugeragenten i færd med at oprette en belastning. Mange bruger-agenter af populære testværktøjer filtreres af systemadministratorer, og i dette tilfælde kan belastningen simpelthen ikke nå backend. Du kan forbedre resultatet markant ved at indsætte en mere eller mindre gyldig header fra browseren i anmodningen.
Så simple som HTTP Flood-angreb er, har de også deres ulemper. For det første kræves der store mængder strøm for at skabe belastningen. For det andet er sådanne angreb meget nemme at opdage, især hvis de kommer fra én adresse. Som et resultat begynder anmodninger straks at blive filtreret enten af systemadministratorer eller endda på udbyderniveau.
Hvad skal man søge
For at reducere antallet af anmodninger pr. sekund uden at miste effektivitet, skal du vise lidt fantasi og udforske webstedet. Således kan du indlæse ikke kun kanalen eller serveren, men også individuelle dele af applikationen, for eksempel databaser eller filsystemer. Du kan også kigge efter steder på siden, der laver store beregninger: lommeregnere, produktudvalgssider mv. Endelig sker det ofte, at siden har en form for PHP-script, der genererer en side på flere hundrede tusinde linjer. Et sådant script belaster også serveren betydeligt og kan blive et mål for et angreb.
Hvor skal man kigge
Når vi scanner en ressource før test, kigger vi selvfølgelig først på selve webstedet. Vi leder efter alle slags inputfelter, tunge filer – i det hele taget alt, der kan skabe problemer for ressourcen og bremse dens drift. Banale udviklingsværktøjer i Google Chrome og Firefox hjælper her, som viser sidens svartider.
Vi scanner også underdomæner. For eksempel er der en bestemt netbutik, abc.com, og den har et underdomæne admin.abc.com. Mest sandsynligt er dette et adminpanel med autorisation, men hvis du lægger en belastning på det, kan det skabe problemer for hovedressourcen.
Siden kan have et underdomæne api.abc.com. Mest sandsynligt er dette en ressource til mobile applikationer. Applikationen kan findes i App Store eller Google Play, installer et særligt adgangspunkt, dissekere API'en og registrer testkonti. Problemet er, at folk ofte tror, at alt, der er beskyttet af autorisation, er immunt over for lammelsesangreb. Angiveligt er autorisation den bedste CAPTCHA, men det er den ikke. Det er nemt at lave 10-20 testkonti, men ved at oprette dem får vi adgang til kompleks og utilsløret funktionalitet.
Naturligvis ser vi på historien, på robots.txt og WebArchive, ViewDNS og kigger efter gamle versioner af ressourcen. Nogle gange sker det, at udviklere har rullet ud, f.eks. mail2.yandex.net, men den gamle version, mail.yandex.net, forbliver. Denne mail.yandex.net understøttes ikke længere, udviklingsressourcer er ikke allokeret til den, men den fortsætter med at forbruge databasen. Ved at bruge den gamle version kan du derfor effektivt bruge ressourcerne i backend og alt, hvad der ligger bag layoutet. Det sker selvfølgelig ikke altid, men vi støder stadig på dette ret ofte.
Vi analyserer naturligvis alle anmodningsparametrene og cookiestrukturen. Du kan f.eks. dumpe noget værdi ind i et JSON-array inde i en cookie, skabe en masse nesting og få ressourcen til at virke i urimelig lang tid.
Søg belastning
Det første, der kommer til at tænke på, når man undersøger et websted, er at indlæse databasen, da næsten alle har en søgning, og for næsten alle er den desværre dårligt beskyttet. Af en eller anden grund er udviklere ikke opmærksomme nok på søgning. Men der er en anbefaling her - du bør ikke lave anmodninger af samme type, fordi du kan støde på caching, som det er tilfældet med HTTP flood.
At lave tilfældige forespørgsler til databasen er heller ikke altid effektivt. Det er meget bedre at oprette en liste over søgeord, der er relevante for søgningen. Hvis vi vender tilbage til eksemplet med en online butik: lad os sige, at webstedet sælger bildæk og giver dig mulighed for at indstille dækkenes radius, typen af bil og andre parametre. Derfor vil kombinationer af relevante ord tvinge databasen til at arbejde under meget mere komplekse forhold.
Derudover er det værd at bruge paginering: det er meget sværere for en søgning at returnere den næstsidste side af søgeresultaterne end den første. Det vil sige, ved hjælp af paginering kan du lidt diversificere belastningen.
Eksemplet nedenfor viser søgebelastningen. Det kan ses, at siden det allerførste sekund af testen med en hastighed på ti anmodninger i sekundet gik siden ned og svarede ikke.
Hvis der ikke er nogen søgning?
Hvis der ikke er nogen søgning, betyder det ikke, at siden ikke indeholder andre sårbare inputfelter. Dette felt kan være autorisation. I dag kan udviklere lide at lave komplekse hashes for at beskytte login-databasen mod et regnbuebordsangreb. Det er godt, men sådanne hashes bruger mange CPU-ressourcer. En stor strøm af falske godkendelser fører til en processorfejl, og som et resultat holder webstedet op med at fungere.
Tilstedeværelsen på webstedet af alle slags formularer til kommentarer og feedback er en grund til at sende meget store tekster der eller blot skabe en massiv oversvømmelse. Nogle gange accepterer websteder vedhæftede filer, herunder i gzip-format. I dette tilfælde tager vi en 1TB fil, komprimerer den til flere bytes eller kilobytes ved hjælp af gzip og sender den til webstedet. Derefter pakkes den ud, og der opnås en meget interessant effekt.
Rest API
Jeg vil gerne være lidt opmærksom på så populære tjenester som Rest API. At sikre en Rest API er meget sværere end en almindelig hjemmeside. Selv trivielle metoder til beskyttelse mod brute force med password og anden illegitim aktivitet virker ikke for Rest API.
Rest API er meget let at bryde, fordi den får direkte adgang til databasen. Samtidig medfører fejlen af en sådan tjeneste ganske alvorlige konsekvenser for erhvervslivet. Faktum er, at Rest API normalt ikke kun bruges til hovedwebstedet, men også til mobilapplikationen og nogle interne forretningsressourcer. Og hvis alt dette falder, så er effekten meget stærkere end i tilfælde af en simpel hjemmesidefejl.
Indlæser tungt indhold
Hvis vi bliver tilbudt at teste en almindelig enkeltsides applikation, landingsside eller visitkortwebsted, som ikke har kompleks funktionalitet, leder vi efter tungt indhold. For eksempel store billeder, som serveren sender, binære filer, pdf-dokumentation – alt dette forsøger vi at downloade. Sådanne test indlæser filsystemet godt og tilstopper kanaler og er derfor effektive. Det vil sige, at selvom du ikke lægger serveren ned og downloader en stor fil ved lave hastigheder, vil du blot tilstoppe kanalen på målserveren, og så vil der opstå et lammelsesangreb.
Et eksempel på en sådan test viser, at siden med en hastighed på 30 RPS holdt op med at reagere eller producerede 500. serverfejl.
Glem ikke at konfigurere servere. Du kan ofte opleve, at en person har købt en virtuel maskine, installeret Apache der, konfigureret alt som standard, installeret en PHP-applikation, og nedenfor kan du se resultatet.
Her gik belastningen til roden og udgjorde kun 10 RPS. Vi ventede 5 minutter, og serveren styrtede ned. Det er rigtigt, at man ikke helt ved, hvorfor han faldt, men der er en antagelse om, at han simpelthen havde for meget hukommelse og derfor holdt op med at reagere.
Bølge baseret
I de sidste år eller to er bølgeangreb blevet ret populære. Dette skyldes det faktum, at mange organisationer køber visse stykker hardware til DDoS-beskyttelse, som kræver en vis mængde tid at akkumulere statistik for at begynde at filtrere angrebet. Det vil sige, at de ikke filtrerer angrebet i de første 30-40 sekunder, fordi de samler data og lærer. Derfor kan du på disse 30-40 sekunder starte så meget på webstedet, at ressourcen vil ligge i lang tid, indtil alle anmodninger er ryddet op.
Ved angrebet nedenfor var der et interval på 10 minutter, hvorefter en ny, modificeret del af angrebet ankom.
Det vil sige, at forsvaret lærte, begyndte at filtrere, men en ny, helt anden del af angrebet kom, og forsvaret begyndte at lære igen. Faktisk holder filtrering op med at virke, beskyttelsen bliver ineffektiv, og siden er utilgængelig.
Bølgeangreb er karakteriseret ved meget høje værdier på toppen, det kan nå hundrede tusinde eller en million anmodninger i sekundet, i tilfælde af L7. Hvis vi taler om L3&4, så kan der være hundredvis af gigabits trafik, eller følgelig hundredvis af mpps, hvis du tæller i pakker.
Problemet med sådanne angreb er synkronisering. Angrebene kommer fra et botnet og kræver en høj grad af synkronisering for at skabe en meget stor engangsspids. Og denne koordinering fungerer ikke altid: nogle gange er outputtet en slags parabolsk top, som ser ret patetisk ud.
Ikke HTTP alene
Ud over HTTP på L7 kan vi godt lide at udnytte andre protokoller. Som regel har en almindelig hjemmeside, især en almindelig hosting, mailprotokoller og MySQL, der stikker ud. Mail-protokoller er underlagt mindre belastning end databaser, men de kan også indlæses ganske effektivt og ende med en overbelastet CPU på serveren.
Vi havde ret succes med at bruge 2016 SSH-sårbarheden. Nu er denne sårbarhed rettet for næsten alle, men det betyder ikke, at belastning ikke kan sendes til SSH. Kan. Der er simpelthen en enorm belastning af autorisationer, SSH æder næsten hele CPU'en på serveren, og så kollapser hjemmesiden fra en eller to anmodninger i sekundet. Derfor kan disse en eller to anmodninger baseret på logfilerne ikke skelnes fra en legitim belastning.
Mange forbindelser, som vi åbner på servere, forbliver også relevante. Tidligere var Apache skyldig i dette, nu er nginx faktisk skyldig i dette, da det ofte er konfigureret som standard. Antallet af forbindelser, som nginx kan holde åbne, er begrænset, så vi åbner dette antal forbindelser, nginx accepterer ikke længere en ny forbindelse, og som følge heraf fungerer siden ikke.
Vores testklynge har CPU nok til at angribe SSL-håndtryk. I princippet, som praksis viser, kan botnets nogle gange også lide at gøre dette. På den ene side er det klart, at du ikke kan undvære SSL, fordi Googles resultater, rangering, sikkerhed. På den anden side har SSL desværre et CPU-problem.
L3&4
Når vi taler om et angreb på L3&4-niveauer, taler vi normalt om et angreb på link-niveau. En sådan belastning kan næsten altid skelnes fra en legitim, medmindre det er et SYN-oversvømmelsesangreb. Problemet med SYN-flood-angreb til sikkerhedsværktøjer er deres store volumen. Den maksimale L3&4-værdi var 1,5-2 Tbit/s. Denne form for trafik er meget vanskelig at behandle selv for store virksomheder, herunder Oracle og Google.
SYN og SYN-ACK er pakker, der bruges ved etablering af en forbindelse. Derfor er SYN-flood svær at skelne fra en legitim belastning: det er ikke klart, om dette er en SYN, der kom til at etablere en forbindelse, eller en del af en oversvømmelse.
UDP-oversvømmelse
Typisk har angribere ikke de muligheder, som vi har, så forstærkning kan bruges til at organisere angreb. Det vil sige, at angriberen scanner internettet og finder enten sårbare eller forkert konfigurerede servere, der for eksempel som svar på én SYN-pakke reagerer med tre SYN-ACK'er. Ved at spoofe kildeadressen fra adressen på målserveren er det muligt at øge strømmen med for eksempel tre gange med en enkelt pakke og omdirigere trafik til offeret.
Problemet med forstærkninger er, at de er svære at opdage. Nylige eksempler inkluderer det opsigtsvækkende tilfælde af den sårbare memcached. Plus, nu er der en masse IoT-enheder, IP-kameraer, som også for det meste er konfigureret som standard, og som standard er de konfigureret forkert, hvorfor angribere oftest laver angreb gennem sådanne enheder.
Svær SYN-flod
SYN-flood er nok den mest interessante type angreb fra en udviklers synspunkt. Problemet er, at systemadministratorer ofte bruger IP-blokering til beskyttelse. Desuden påvirker IP-blokering ikke kun systemadministratorer, der handler ved hjælp af scripts, men desværre også nogle sikkerhedssystemer, der er købt for mange penge.
Denne metode kan blive til en katastrofe, for hvis angribere erstatter IP-adresser, vil virksomheden blokere sit eget undernet. Når firewall'en blokerer sin egen klynge, vil output fejle eksterne interaktioner, og ressourcen vil fejle.
Desuden er det ikke svært at blokere dit eget netværk. Hvis kundens kontor har et Wi-Fi-netværk, eller hvis ressourcernes ydeevne måles ved hjælp af forskellige overvågningssystemer, tager vi IP-adressen på dette overvågningssystem eller klientens kontors Wi-Fi og bruger den som kilde. Til sidst ser ressourcen ud til at være tilgængelig, men mål-IP-adresserne er blokeret. Således kan Wi-Fi-netværket på HighLoad-konferencen, hvor virksomhedens nye produkt præsenteres, blive blokeret, og det medfører visse forretningsmæssige og økonomiske omkostninger.
Under test kan vi ikke bruge forstærkning gennem memcached med nogen eksterne ressourcer, fordi der er aftaler om kun at sende trafik til tilladte IP-adresser. Derfor bruger vi forstærkning gennem SYN og SYN-ACK, når systemet reagerer på at sende en SYN med to eller tre SYN-ACK'er, og ved udgangen ganges angrebet med to eller tre gange.
Værktøj
Et af de vigtigste værktøjer, vi bruger til L7-arbejdsbelastning, er Yandex-tank. Især bruges et fantom som en pistol, plus der er flere scripts til at generere patroner og til at analysere resultaterne.
Tcpdump bruges til at analysere netværkstrafik, og Nmap bruges til at analysere serveren. For at skabe belastningen på L3&4-niveau, bruges OpenSSL og lidt af vores egen magi med DPDK-biblioteket. DPDK er et bibliotek fra Intel, der giver dig mulighed for at arbejde med netværksgrænsefladen uden om Linux-stakken og derved øge effektiviteten. Naturligvis bruger vi DPDK ikke kun på L3&4-niveauet, men også på L7-niveauet, fordi det giver os mulighed for at skabe et meget højt belastningsflow inden for rækkevidden af flere millioner anmodninger pr. sekund fra én maskine.
Vi bruger også visse trafikgeneratorer og specialværktøjer, som vi skriver til specifikke tests. Hvis vi husker sårbarheden under SSH, kan ovenstående sæt ikke udnyttes. Hvis vi angriber mail-protokollen, tager vi mail-værktøjer eller skriver blot scripts på dem.
Fund
Som konklusion vil jeg gerne sige:
- Udover klassisk belastningstest er det nødvendigt at udføre stresstest. Vi har et rigtigt eksempel, hvor en samarbejdspartners underleverandør kun udførte belastningstest. Det viste, at ressourcen kan modstå den normale belastning. Men så dukkede en unormal belastning op, besøgende på siden begyndte at bruge ressourcen lidt anderledes, og som følge heraf lagde underleverandøren sig ned. Det er således værd at lede efter sårbarheder, selvom du allerede er beskyttet mod DDoS-angreb.
- Det er nødvendigt at isolere nogle dele af systemet fra andre. Hvis du har en søgning, skal du flytte den til separate maskiner, det vil sige ikke engang til Docker. For hvis søgning eller godkendelse mislykkes, vil noget i det mindste fortsætte med at fungere. I tilfælde af en onlinebutik, vil brugerne fortsætte med at finde produkter i kataloget, gå fra aggregatoren, købe, hvis de allerede er godkendte, eller godkende via OAuth2.
- Forsøm ikke alle former for cloud-tjenester.
- Brug CDN ikke kun til at optimere netværksforsinkelser, men også som et middel til beskyttelse mod angreb på kanaludmattelse og blot oversvømmelser til statisk trafik.
- Det er nødvendigt at bruge specialiserede beskyttelsestjenester. Du kan ikke beskytte dig selv mod L3&4-angreb på kanalniveau, fordi du højst sandsynligt simpelthen ikke har en tilstrækkelig kanal. Det er heller ikke sandsynligt, at du vil kæmpe mod L7-angreb, da de kan være meget store. Derudover er søgen efter små angreb stadig forbeholdt særlige tjenester, specielle algoritmer.
- Opdater regelmæssigt. Dette gælder ikke kun for kernen, men også for SSH-dæmonen, især hvis du har dem åbne udadtil. I princippet skal alt opdateres, fordi du næppe vil kunne spore visse sårbarheder på egen hånd.
Kilde: www.habr.com