{"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\/da\/blog\/administrirovanie\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","title":{"rendered":"DDoS til hj\u00e6lp: hvordan vi udf\u00f8rer stress- og belastningstest","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DDoS
\n
\nVariti udvikler beskyttelse mod bots og DDoS-angreb samt udf\u00f8rer stresstest og belastningstest. P\u00e5 konferencen HighLoad++ 2018 fortalte vi, hvordan man sikrer ressourcer mod forskellige typer angreb. Kort sagt: isoler dele af systemet, brug cloud-tjenester og CDN, og opdater regelm\u00e6ssigt. Men uden specialiserede selskaber med beskyttelse vil du stadig ikke klare det \ud83d\ude42<\/i>
\n<\/a><\/noindex>
\nF\u00f8r du l\u00e6ser teksten, kan du se de korte punkter p\u00e5 konferencens hjemmeside<\/a><\/noindex>.
\nOg hvis du ikke kan lide at l\u00e6se eller blot vil se videoen, er optagelsen af vores foredrag nedenfor i spoilerlugen.<\/p>\n

Videooptagelse af foredraget<\/b>

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

Mange virksomheder kan allerede udf\u00f8re belastningstest, men ikke alle udf\u00f8rer stresstest. Nogle af vores kunder tror, at deres website er uigennemtr\u00e6ngeligt, fordi de har en highload-l\u00f8sning, og den beskytter godt mod angreb. Vi viser dog, at det ikke helt er sandt.
\nSelvf\u00f8lgelig f\u00e5r vi tilladelse fra kunden, med underskrift og stempel, f\u00f8r vi udf\u00f8rer testene, og med vores hj\u00e6lp kan der ikke udf\u00f8res DDoS-angreb p\u00e5 nogen. Testen udf\u00f8res p\u00e5 det tidspunkt, kunden har valgt, n\u00e5r bes\u00f8gstrafikken til deres ressource er minimal, og problemer med adgang ikke vil p\u00e5virke kunderne. Desuden, da der altid kan ske noget uventet under testningen, har vi konstant kontakt med kunden. Dette g\u00f8r det muligt ikke kun at rapportere om opn\u00e5ede resultater, men ogs\u00e5 at foretage \u00e6ndringer undervejs i testen. Ved afslutning af testen udarbejder vi altid en rapport, hvor vi angiver de opdagede mangler og giver anbefalinger til at afhj\u00e6lpe svage punkter p\u00e5 hjemmesiden. <\/p>\n

Hvordan vi arbejder<\/h3>\n

\nUnder testningen emulerer vi et botnet. Da vi arbejder med kunder, som ikke befinder sig i vores netv\u00e6rk, skal vi for at undg\u00e5, at testen slutter p\u00e5 det f\u00f8rste minut p\u00e5 grund af udl\u00f8bsgr\u00e6nser eller beskyttelse, anmelde belastningen ikke fra \u00e9n IP, men fra vores eget subnet. Desuden har vi en ret kraftig testserver til at skabe betydelig belastning.<\/p>\n

Postulater<\/h3>\n

<\/p>\n

Mere betyder ikke n\u00f8dvendigvis bedre<\/b>
\nJo mindre belastning vi kan bringe resurserne til at fejle, jo bedre. Hvis vi kan f\u00e5 en hjemmeside til at stoppe med at fungere ved blot \u00e9n foresp\u00f8rgsel pr. sekund eller endda ved \u00e9n foresp\u00f8rgsel pr. minut, ville det v\u00e6re fantastisk. Fordi loven om uheldighed siger, at brugere eller ondsindede akt\u00f8rer tilf\u00e6ldigt vil ramme denne s\u00e5rbarhed. <\/p><\/blockquote>\n

Delvis fejl er bedre end total fejl<\/b>
\nVi r\u00e5der altid til at g\u00f8re systemerne heterogene. Og de skal opdeles p\u00e5 det fysiske niveau, ikke kun ved containerisering. Med fysisk adskillelse, selv hvis noget svigter p\u00e5 siden, er der en stor sandsynlighed for, at den ikke stopper helt, og brugerne stadig har adgang til i det mindste en del af funktionaliteten.<\/p><\/blockquote>\n

Den rigtige arkitektur er grundlaget for modstandsdygtighed<\/b>
\nFejltolerance af ressourcen og dens evne til at modst\u00e5 angreb og belastninger b\u00f8r l\u00e6gges under designfasen, faktisk fra de f\u00f8rste blokdiagrammer i notebogen. For hvis fatale fejl sniger sig ind, er det muligt at rette dem senere, men det er meget besv\u00e6rligt.<\/p><\/blockquote>\n

B\u00e5de koden og konfigurationen skal v\u00e6re gode<\/b>
\nMange tror, at et godt udviklingsteam er en garanti for fejltolerancen af tjenesten. Et godt udviklingsteam er bestemt n\u00f8dvendigt, men der skal ogs\u00e5 v\u00e6re god drift, god DevOps. Det kr\u00e6ver specialister, der korrekt konfigurerer Linux og netv\u00e6rket, skriver de rigtige konfigurationer i nginx, s\u00e6tter gr\u00e6nser og s\u00e5 videre. Ellers vil ressourcen kun fungere godt i testen, men i produktionen vil alt bryde sammen p\u00e5 et tidspunkt.<\/p><\/blockquote>\n

Forskelle mellem belastningstest og stresstest<\/b>
\nBelastningstest afsl\u00f8rer systemets funktionsgr\u00e6nser. Stresstest sigter mod at finde svagheder i systemet og bruges til at bryde systemet og se, hvordan det reagerer p\u00e5 fejl i visse dele. Ofte forbliver belastningens karakter ukendt for kunden indtil starten af stresstesten.<\/p><\/blockquote>\n

<\/p>\n

Kendetegn ved L7 angreb<\/h3>\n

\nVi opdeler typer af belastning i L7 og L3&4 niveauer. L7 refererer til belastning p\u00e5 applikationsniveau, som oftest kun forst\u00e5s som HTTP, men vi henviser til enhver belastning p\u00e5 TCP-protokolniveau.
\nL7 angreb har nogle s\u00e6rlige kendetegn. For det f\u00f8rste kommer de direkte til applikationen, hvilket g\u00f8r det vanskeligt at afvise dem med netv\u00e6rksmiddel. Disse angreb udnytter logik og bruger derfor meget effektivt CPU, hukommelse, disk, database og andre ressourcer, selv ved lav trafik.<\/p>\n

HTTP Flood<\/h3>\n

\nI tilf\u00e6lde af ethvert angreb er det lettere at skabe belastning end at h\u00e5ndtere det, og dette g\u00e6lder ogs\u00e5 for L7. Angrebstrafik er ikke altid let at skelne fra legitim trafik, og det er oftest muligt at g\u00f8re det baseret p\u00e5 hyppighed, men hvis alt er planlagt korrekt, er det umuligt at forst\u00e5 fra loggene, hvor angrebet er, og hvor de legitime anmodninger er.
\nSom et f\u00f8rste eksempel vil vi se p\u00e5 HTTP Flood angrebet. Grafen viser, at s\u00e5danne angreb normalt er meget kraftfulde; i eksemplet nedenfor oversteg det maksimale antal anmodninger 600.000 pr. minut.<\/p>\n

\"DDoS
\n
\nHTTP Flood er den enkleste m\u00e5de at skabe belastning p\u00e5. Normalt anvendes et v\u00e6rkt\u00f8j til belastningstest, s\u00e5som ApacheBench, hvor anmodningen og m\u00e5let defineres. Med en s\u00e5 simpel tilgang er der stor sandsynlighed for at st\u00f8de p\u00e5 serverens cache, men det er let at omg\u00e5. For eksempel ved at tilf\u00f8je tilf\u00e6ldige strenge til anmodningen, hvilket tvinger serveren til konstant at returnere en frisk side.
\nMan skal heller ikke glemme user-agent i processen med at skabe belastning. Mange user-agents fra popul\u00e6re testv\u00e6rkt\u00f8jer filtreres af systemadministratorer, og i s\u00e5danne tilf\u00e6lde kan belastningen simpelthen ikke n\u00e5 backend. Resultatet kan forbedres betydeligt ved at inds\u00e6tte en mere eller mindre gyldig header fra en browser i anmodningen.
\nP\u00e5 trods af simpliciteten har HTTP Flood angrebene ogs\u00e5 deres ulemper. For det f\u00f8rste kr\u00e6ver det store ressourcer for at skabe belastning. For det andet er s\u00e5danne angreb meget lette at opdage, is\u00e6r hvis de stammer fra \u00e9n adresse. Som et resultat begynder anmodninger straks at blive filtreret, enten af systemadministratorer eller endda p\u00e5 udbyderens niveau. <\/p>\n

Hvad skal man se efter<\/h3>\n

\nFor reducing the number of requests per second while maintaining efficiency, a bit of creativity and exploration of the website is necessary. You can load not only the channel or server, but also individual parts of an application, such as databases or file systems. You can also search for areas on the site that perform heavy computations: calculators, product selection pages, and so on. Finally, it often happens that there is a PHP script on the site that generates a page from several hundred thousand lines. Such a script can significantly load the server and become a target for attacks.<\/p>\n

Where to look<\/h3>\n

\nWhen we scan a resource before testing, we first look at the site itself. We search for all kinds of input fields, heavy files \u2014 basically anything that could cause issues for the resource and slow down its performance. This is where basic developer tools in Google Chrome and Firefox help, showing page response times.
\nWe also scan subdomains. For example, there is an online store, abc.com, and it has a subdomain admin.abc.com. This is likely an admin panel with authorization, but if you apply load to it, it may create problems for the main resource.
\nThe site may have a subdomain api.abc.com. This is likely a resource for mobile applications. The app can be found in the App Store or Google Play, a special access point can be set up, the API can be dissected, and test accounts can be registered. The problem is that often people think that anything protected by authorization is invulnerable to denial of service attacks. It\u2019s believed that authorization is the best CAPTCHA, but that\u2019s not true. Creating 10-20 test accounts is easy, and by doing so, we gain access to complex and unprotected functionality.
\nNaturally, we look at the history, robots.txt, and WebArchive, ViewDNS, searching for old versions of the resource. Sometimes developers roll out, for example, mail2.yandex.net, while the old version, mail.yandex.net, remains. This mail.yandex.net ceases to be supported, and no development resources are allocated for it, but it continues to consume the database. Accordingly, using the old version, we can effectively leverage the backend resources and everything that lies behind the layout. Of course, this doesn\u2019t happen all the time, but we encounter something similar fairly often.
\nSelvf\u00f8lgelig analyserer vi alle foresp\u00f8rgselsparametre og cookie-strukturen. Man kan for eksempel inds\u00e6tte en v\u00e6rdi i et JSON-array inden for en cookie, skabe en stor indlejring og f\u00e5 ressourcen til at fungere urimeligt l\u00e6nge.<\/p>\n

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

\nDet f\u00f8rste, der kommer i tankerne ved unders\u00f8gelse af en hjemmeside, er at belaste databasen, da n\u00e6sten alle har en s\u00f8gefunktion, og desv\u00e6rre er den d\u00e5rligt beskyttet i n\u00e6sten alle tilf\u00e6lde. Af en eller anden grund giver udviklerne ikke s\u00f8gningen tilstr\u00e6kkelig opm\u00e6rksomhed. Men der er et r\u00e5d \u2014 undg\u00e5 at lave ensartede foresp\u00f8rgsler, da man kan st\u00f8de p\u00e5 caching, ligesom ved HTTP-flood.
\nAt lave tilf\u00e6ldige foresp\u00f8rgsler i databasen er heller ikke altid effektivt. Det er meget bedre at lave en liste over n\u00f8gleord, som relaterer til s\u00f8gningen. Hvis vi vender tilbage til eksemplet med en webshop: lad os sige, at hjemmesiden s\u00e6lger bild\u00e6k og tillader at angive d\u00e6kkets radius, biltype og andre parametre. Kombinationsmuligheder af relevante ord vil f\u00e5 databasen til at arbejde under meget mere komplekse forhold.
\nDerudover b\u00f8r man bruge paginering: det er meget sv\u00e6rere for s\u00f8gningen at give den n\u00e6stsidste side af resultaterne end den f\u00f8rste. Med paginering kan man derfor variere belastningen en smule.
\nI eksemplet nedenfor viser vi belastningen i s\u00f8gningen. Det ses, at fra det f\u00f8rste sekund af testen med ti foresp\u00f8rgsler pr. sekund gik hjemmesiden ned og svarede ikke.<\/p>\n

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

Hvis der ikke er nogen s\u00f8gning?<\/h3>\n

\nHvis der ikke er nogen s\u00f8gning, betyder det ikke, at hjemmesiden ikke indeholder andre s\u00e5rbare indtastningsfelter. Et s\u00e5dant felt kunne v\u00e6re autorisation. I dag elsker udviklere at lave komplekse hashes for at beskytte login-databasen mod angreb ved hj\u00e6lp af regnbue-tabeller. Det er godt, men s\u00e5danne hashes kr\u00e6ver store CPU-ressourcer. Et stort antal falske login-fors\u00f8g f\u00f8rer til overbelastning af processoren, og som f\u00f8lge heraf stopper hjemmesiden med at fungere.
\nTilstedev\u00e6relsen af alle former for kommentar- og feedbackformularer p\u00e5 hjemmesiden er en grund til at sende meget store tekstm\u00e6ngder eller blot skabe massiv spam. Nogle gange accepterer hjemmesider indlejringer, ogs\u00e5 i gzip-format. I dette tilf\u00e6lde tager vi en fil p\u00e5 1 TB, komprimerer den med gzip til nogle f\u00e5 bytes eller kilobyte og sender den til hjemmesiden. Derefter bliver den udpakket, og der opn\u00e5s en meget interessant effekt. <\/p>\n

Rest API<\/h3>\n

\nDet er vigtigt at fokusere p\u00e5 popul\u00e6re tjenester som Rest API. At beskytte Rest API er meget sv\u00e6rere end at beskytte en almindelig hjemmeside. Selv grundl\u00e6ggende metoder til at beskytte mod brute-force angreb og anden uautoriseret aktivitet fungerer ikke for Rest API.
\nRest API er meget nemt at bryde ind i, fordi det har direkte adgang til databasen. Nedbrud af en s\u00e5dan tjeneste kan have alvorlige konsekvenser for virksomheden. Problemet er, at Rest API ofte er knyttet til ikke bare hovedwebsitet, men ogs\u00e5 mobilapplikationen og interne forretningsressourcer. Hvis alt dette g\u00e5r ned, vil effekten v\u00e6re meget st\u00e6rkere end ved nedbrud af en almindelig hjemmeside. <\/p>\n

Belastning af tungt indhold<\/h3>\n

\nN\u00e5r vi bliver bedt om at teste en almindelig landside, et enkelt side-applikation eller en visitkort hjemmeside uden komplekse funktioner, s\u00f8ger vi efter tungt indhold. For eksempel store billeder, som serveren leverer, bin\u00e6re filer eller pdf-dokumentation - vi pr\u00f8ver at downloade alt dette. S\u00e5danne tests belaster filsystemet effektivt og fylder kanalerne, hvilket g\u00f8r dem effektive. Det betyder, at selvom du ikke bringer serveren ned ved at downloade en stor fil med lave hastigheder, s\u00e5 fylder du blot det m\u00e5lrettede servers kanal, hvilket resulterer i serviceafvisning.
\nI dette eksempel ses det, at ved 30 RPS stoppede siden med at svare, eller gav 500 serverfejl.<\/p>\n

\"DDoS
\n
\nMan m\u00e5 heller ikke glemme serverindstillingerne. Ofte ser man, at en person har k\u00f8bt en virtuel maskine, installeret Apache, konfigureret alt til standard, placeret en php-applikation, og nedenfor kan man se resultatet. <\/p>\n

\"DDoS
\n
\nHer gik belastningen til roden og var kun 10 RPS. Vi ventede 5 minutter, og serveren gik ned. Det er dog uklart, hvorfor den gik ned, men der er en formodning om, at den simpelthen har brugt for meget hukommelse, hvilket resulterede i, at den ikke l\u00e6ngere kunne svare.<\/p>\n

B\u00f8lgebaseret<\/h3>\n

\nI de sidste \u00e5r eller to er b\u00f8lgeangreb blevet ret popul\u00e6re. Dette skyldes, at mange organisationer k\u00f8ber de forskellige enheder til beskyttelse mod DDoS, som kr\u00e6ver en vis tid til at opsamle statistik for at begynde at filtrere angrebet. Det vil sige, at de ikke filtrerer angrebet i de f\u00f8rste 30-40 sekunder, fordi de opsamler data og l\u00e6rer. I disse 30-40 sekunder kan der derfor sendes s\u00e5 mange anmodninger til siden, at ressourcen vil v\u00e6re utilg\u00e6ngelig i lang tid, indtil alle anmodninger er behandlet.
\nI tilf\u00e6lde af angrebet nedenfor var der et interval p\u00e5 10 minutter, hvorefter en ny, \u00e6ndret portion af angrebet kom.<\/p>\n

\"DDoS
\n
\nS\u00e5 beskyttelsen blev tr\u00e6net, indledte filtreringen, men en ny, helt anderledes portion af angrebet kom, og beskyttelsen begyndte igen at l\u00e6re. Faktisk stopper filtreringen med at virke, beskyttelsen bliver ineffektiv, og siden er utilg\u00e6ngelig.
\nB\u00f8lgeangreb er kendetegnet ved meget h\u00f8je v\u00e6rdier p\u00e5 toppen; det kan n\u00e5 op p\u00e5 hundrede tusinde eller en million anmodninger pr. sekund, i tilf\u00e6lde af L7. Hvis vi taler om L3&4, kan der v\u00e6re hundredvis af gigabit trafik, eller hundredvis af mpps, hvis vi ser p\u00e5 pakker.
\nProblemet med s\u00e5danne angreb er synkroniseringen. Angrebene kommer fra botnet, og for at skabe et meget stort spidsbelastning er der behov for en h\u00f8j grad af synkronisering. Og denne koordination lykkes ikke altid: nogle gange resulterer det i en eller anden parabolisk spids, som ser temmelig ynkelig ud.<\/p>\n

Ikke kun HTTP<\/h3>\n

\nUdover HTTP p\u00e5 L7-niveauet elsker vi ogs\u00e5 at udnytte andre protokoller. Som regel er der for en almindelig hjemmeside, is\u00e6r en almindelig hosting, ogs\u00e5 mailprotokoller og MySQL, der stikker ud. Mailprotokoller er mindre udsatte for belastninger end databaser, men de kan ogs\u00e5 belastet effektivt, hvilket kan medf\u00f8re overbelastning af CPU'en p\u00e5 serveren.
\nVi har med succes udnyttet en s\u00e5rbarhed i SSH fra 2016. Nu er denne s\u00e5rbarhed n\u00e6sten udbedret hos alle, men det betyder ikke, at man ikke kan p\u00e5f\u00f8re belastning via SSH. Det kan man. Der kan simpelthen sendes en enorm belastning af godkendelser, SSH bruger n\u00e6sten al CPU'en p\u00e5 serveren, og derefter falder websiden allerede ved en til to anmodninger pr. sekund. Disse en til to anmodninger kan ikke adskilles fra legitim belastning i loggene.
\nDer er stadig mange forbindelser, som vi \u00e5bner p\u00e5 serverne. Tidligere havde Apache ofte dette problem, og nu har nginx faktisk ogs\u00e5 det, da det ofte konfigureres som standard. Antallet af forbindelser, som nginx kan holde \u00e5bne, er begr\u00e6nset, s\u00e5 n\u00e5r vi n\u00e5r dette antal forbindelser, accepterer nginx ikke nye forbindelser, og derfor fungerer hjemmesiden ikke.
\nVores testklynge har tilstr\u00e6kkelig CPU til at angribe SSL-handshake. Som praksis viser, kan botnets ogs\u00e5 nogle gange lide at g\u00f8re dette. P\u00e5 den ene side er det klart, at uden SSL kan man ikke klare sig, da det p\u00e5virker Google's resultater, rangering og sikkerhed. P\u00e5 den anden side har SSL desv\u00e6rre et problem med CPU. <\/p>\n

L3&4<\/h3>\n

\nN\u00e5r vi taler om angreb p\u00e5 niveauerne L3&4, taler vi typisk om angreb p\u00e5 kanalniveau. S\u00e5dan belastning kan n\u00e6sten altid skelnes fra legitim, medmindre det er et SYN-flood angreb. Problemet med SYN-flood angreb for beskyttelsesmidler skyldes den store m\u00e6ngde. Den maksimale st\u00f8rrelse for L3&4 var 1,5-2 Tbit\/s. S\u00e5dan trafik er meget sv\u00e6r at h\u00e5ndtere selv for store virksomheder, herunder Oracle og Google.
\nSYN og SYN-ACK er pakker, der bruges ved etablering af forbindelsen. Derfor er det sv\u00e6rt at skelne SYN-flood fra legitim belastning: det er uklart, om det er SYN, der kom for at etablere forbindelsen, eller en del af floden.<\/p>\n

UDP-flood<\/h3>\n

\nNormalt har angriberne ikke den samme kapacitet som os, derfor kan de bruge amplification for at udf\u00f8re angreb. Det vil sige, at angriberen scanner internettet og finder enten s\u00e5rbare eller forkert konfigurerede servere, som for eksempel svarer med tre SYN-ACK p\u00e5 en enkelt SYN-pakke. Ved at forfalske kildeadressen med adressen p\u00e5 den m\u00e5lserver kan man med \u00e9n pakke \u00f8ge styrken, s\u00e5 at sige, tre gange og omdirigere trafikken til offeret.<\/p>\n

\"DDoS
\n
\nProblemet med amplification er deres vanskelige opdagelse. Et af de mest kendte tilf\u00e6lde er det s\u00e5rbare memcached. Desuden er der nu mange IoT-enheder, IP-kameraer, der ogs\u00e5 prim\u00e6rt er konfigureret som standard, og som ogs\u00e5 er forkert konfigureret som standard, hvilket er grunden til, at angriberne oftest gennem s\u00e5danne enheder udf\u00f8rer angreb. <\/p>\n

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

SYN-flood er ikke enkelt<\/h3>\n

\nSYN-flood er sandsynligvis den mest interessante type angreb set fra en udviklers synspunkt. Problemet er, at systemadministratorer ofte bruger IP-blokering til beskyttelse. Desv\u00e6rre er det ikke kun administratorer, der f\u00f8lger skripter, der lider under IP-blokering, men ogs\u00e5 nogle sikkerhedssystemer, som koster mange penge.
\nDenne metode kan ende i katastrofe, for hvis angriberne \u00e6ndrer IP-adresser<\/a>, vil virksomheden blokere sit eget subnet. N\u00e5r firewall'en blokerer sit eget cluster, vil eksterne interaktioner bryde sammen, og ressourcen vil g\u00e5 i stykker.
\nDet er desuden ikke sv\u00e6rt at blokere sit eget netv\u00e6rk. Hvis kunden har et Wi-Fi-netv\u00e6rk p\u00e5 kontoret, eller hvis ressourcernes funktionalitet m\u00e5les med diverse overv\u00e5gningsv\u00e6rkt\u00f8jer, tager vi IP-adressen fra disse overv\u00e5gningssystemer eller det kontor-Wi-Fi, og bruger den som kilde. Resultatet er, at ressourcen ser ud til at v\u00e6re tilg\u00e6ngelig, men de m\u00e5lrettede IP-adresser er blokeret. P\u00e5 denne m\u00e5de kan Wi-Fi-netv\u00e6rket ved HighLoad-konferencen, hvor virksomhedens nye produkt pr\u00e6senteres, blive blokeret\u2014og dette medf\u00f8rer visse forretnings- og \u00f8konomiske omkostninger.
\nUnder testningen kan vi ikke bruge amplification via memcached fra eksterne ressourcer, fordi der er aftaler om, at trafik kun m\u00e5 ledes til tilladte IP-adresser. Derfor bruger vi amplification via SYN og SYN-ACK, n\u00e5r sendingen af \u00e9n SYN resulterer i to-tre SYN-ACK svar, hvilket dermed multiplicerer angrebet med to-tre gange. <\/p>\n

V\u00e6rkt\u00f8jer<\/h3>\n

\nEt af de vigtigste v\u00e6rkt\u00f8jer, vi bruger til belastning p\u00e5 L7-niveau, er Yandex-tank. Is\u00e6r bruges en phantom som kanon, plus der er nogle scripts til at generere patroner og til at analysere resultaterne.
\nTil analyse af netv\u00e6rkstrafik bruges Tcpdump, til serveranalyse \u2014 Nmap. Til at skabe belastning p\u00e5 L3&4-niveau bruges OpenSSL og lidt egen magi med DPDK-biblioteket. DPDK er et bibliotek fra Intel, der muligg\u00f8r direktetilgang til netv\u00e6rksinterfacet uden om Linux-stakken, hvilket \u00f8ger effektiviteten. Selvf\u00f8lgelig bruger vi DPDK ikke kun p\u00e5 L3&4-niveau, men ogs\u00e5 p\u00e5 L7-niveau, da det tillader os at skabe en meget h\u00f8j belastning, op til flere millioner foresp\u00f8rgsler per sekund fra \u00e9n maskine.
\nVi bruger ogs\u00e5 specifikke trafikgeneratorer og s\u00e6rlige v\u00e6rkt\u00f8jer, som vi skriver til specifikke tests. Hvis vi husker s\u00e5rbarheden under SSH, s\u00e5 kan den n\u00e6vnte sammens\u00e6tning ikke udnyttes. Hvis vi angriber mailprotokollen, bruger vi mailv\u00e6rkt\u00f8jer eller skriver blot scripts til dem.<\/p>\n

\n

Konklusioner<\/h3>\n

\nSom konklusion vil jeg gerne sige:<\/p>\n