{"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\/nl\/blog\/administrirovanie\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","title":{"rendered":"DDoS als hulp: hoe we stress- en belastingtests uitvoeren","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DDoS
\n
\nHet bedrijf Variti ontwikkelt bots- en DDoS-bescherming, en voert stress- en belastingstests uit. Tijdens de conferentie HighLoad++ 2018 hebben we besproken hoe bronnen te beveiligen tegen verschillende soorten aanvallen. Kort samengevat: isoleer delen van het systeem, gebruik cloudservices en CDN en houd je updates regelmatig bij. Maar zonder gespecialiseerde bedrijven met bescherming kom je er niet helemaal. \ud83d\ude42<\/i>
\n<\/a><\/noindex>
\nVoordat je de tekst leest, kun je de korte samenvattingen bekijken. op de website van de conferentie.<\/a><\/noindex>.
\nEn als je niet graag leest of gewoon liever een video kijkt, vind je hieronder onder de spoiler de opname van onze presentatie.<\/p>\n

Video-opname van de presentatie.<\/b>

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

Veel bedrijven kunnen inmiddels belastingstests uitvoeren, maar niet iedereen voert stress-tests uit. Sommige van onze klanten denken dat hun website onkwetsbaar is omdat ze een highload-systeem hebben, dat goed beschermt tegen aanvallen. Wij laten zien dat dit niet helemaal waar is.
\nNatuurlijk vragen we voor het uitvoeren van tests toestemming van de klant, met handtekening en stempel, en met onze hulp kan er geen DDoS-aanval op iemand worden uitgevoerd. De testing vindt plaats op een door de klant gekozen tijd, wanneer het verkeer naar hun bron minimaal is, zodat problemen met de toegankelijkheid geen invloed hebben op de klanten. Bovendien, omdat er tijdens de test altijd iets mis kan gaan, hebben we constant contact met de klant. Dit stelt ons in staat om niet alleen rapport uit te brengen over de behaalde resultaten, maar ook om tijdens de test aanpassingen te maken. Na afloop van de tests stellen we altijd een rapport op, waarin we de geconstateerde tekortkomingen aangeven en aanbevelingen doen voor het verhelpen van zwakke plekken van de website. <\/p>\n

Hoe we werken<\/h3>\n

\nBij het uitvoeren van tests emuleren we een botnet. Aangezien we werken met klanten die zich niet in onze netwerken bevinden, zorgen we ervoor dat de test niet al in het eerste minuut stopt vanwege limieten of bescherming door belasting te genereren vanaf niet \u00e9\u00e9n IP, maar vanuit ons eigen subnet. Bovendien hebben we een vrij krachtige testserver om aanzienlijke belasting te cre\u00ebren.<\/p>\n

Postulaten<\/h3>\n

<\/p>\n

Veel betekent niet goed.<\/b>
\nHoe minder belasting we kunnen veroorzaken om de bron te laten falen, hoe beter. Als we het voor elkaar krijgen om de site te laten stoppen met functioneren bij \u00e9\u00e9n verzoek per seconde, of zelfs bij \u00e9\u00e9n verzoek per minuut, is dat geweldig. Want volgens de wet van Murphy zullen gebruikers of kwaadwillenden per ongeluk precies deze kwetsbaarheid tegenkomen. <\/p><\/blockquote>\n

Gedeeltelijke uitval is beter dan volledige uitval<\/b>
\nWe adviseren altijd om systemen heterogeen te maken. En het is belangrijk om ze fysiek van elkaar te scheiden, niet alleen door middel van containerisatie. In het geval van fysieke scheiding, zelfs als er iets op de site faalt, is de kans groot dat deze niet volledig ophoudt te functioneren en dat gebruikers tenminste toegang behouden tot een deel van de functionaliteit.<\/p><\/blockquote>\n

De juiste architectuur is de basis voor veerkracht<\/b>
\nDe fouttolerantie van een bron en zijn vermogen om aanvallen en belasting te weerstaan, moeten al in de ontwerpfase worden ingebed, eigenlijk in de fase van het schetsen van de eerste stroomdiagrammen in een notitieboek. Want als fatale fouten binnensluipen, kunnen ze later worden gecorrigeerd, maar het is zeer moeilijk.<\/p><\/blockquote>\n

Niet alleen de code moet goed zijn, maar ook de configuratie<\/b>
\nVelen denken dat een goed ontwikkelteam een garantie is voor de fouttolerantie van de service. Een goed ontwikkelteam is inderdaad noodzakelijk, maar er moet ook een goede exploitatie zijn, goede DevOps. Dat wil zeggen, er zijn specialisten nodig die Linux en netwerken correct configureren, configuraties in nginx goed schrijven, limieten instellen, enzovoort. Anders zal de bron alleen goed functioneren tijdens testen, maar op productie zal op een gegeven moment alles kapot gaan.<\/p><\/blockquote>\n

Verschillen tussen load testing en stress testing<\/b>
\nLoad testing stelt ons in staat de grenzen van de werking van een systeem te ontdekken. Stress testing is gericht op het vinden van zwakke plekken in het systeem en wordt gebruikt om het systeem te breken en te zien hoe het zich gedraagt tijdens de uitval van bepaalde onderdelen. Hierbij blijft de aard van de belasting meestal onbekend voor de klant tot het begin van de stress testing.<\/p><\/blockquote>\n

<\/p>\n

Kenmerken van L7-aanvallen<\/h3>\n

\nWe delen soorten belasting meestal in op L7- en L3&4-niveau. L7 is de belasting op toepassingsniveau, meestal begrijpen we daar alleen HTTP mee, maar wij bedoelen elke belasting op TCP-protocolniveau.
\nL7-aanvallen hebben bepaalde kenmerkende eigenschappen. Ten eerste komen ze rechtstreeks in de applicatie aan, wat betekent dat ze moeilijk met netwerkmiddelen te verijdelen zijn. Deze aanvallen maken gebruik van logica en verbruiken daardoor, zelfs met weinig verkeer, op een zeer effici\u00ebnte manier CPU, geheugen, schijf, database en andere middelen.<\/p>\n

HTTP Flood<\/h3>\n

\nBij elke aanval is het gemakkelijker om de belasting te cre\u00ebren dan om deze af te handelen, en dat geldt ook voor L7-aanvallen. Het is niet altijd eenvoudig om het aanvalsverkeer van legitiem verkeer te onderscheiden, en meestal wordt dit gedaan op basis van frequentie. Maar als alles goed is gepland, is het onmogelijk om uit de logs te begrijpen waar de aanval en waar de legitieme verzoeken zijn.
\nAls eerste voorbeeld bekijken we de aanval HTTP Flood. Uit de grafiek blijkt dat dergelijke aanvallen meestal zeer krachtig zijn; in het onderstaande voorbeeld overschreed het piekniveau van verzoeken 600.000 per minuut.<\/p>\n

\"DDoS
\n
\nHTTP Flood is de eenvoudigste manier om belasting te cre\u00ebren. Gewoonlijk wordt hiervoor een of ander belastingtesthulpmiddel gebruikt, zoals ApacheBench, en worden een verzoek en een doelstelling ingesteld. Met een dergelijke eenvoudige benadering is de kans groot dat je tegen servercache aanloopt, maar die is gemakkelijk te omzeilen. Bijvoorbeeld door willekeurige tekenreeksen aan het verzoek toe te voegen, waardoor de server telkens een frisse pagina moet leveren.
\nVergeet ook de user-agent niet tijdens het cre\u00ebren van de belasting. Veel user-agents van populaire testtools worden door systeembeheerders gefilterd, en in dat geval kan de belasting gewoon niet op de backend aankomen. Het resultaat kan aanzienlijk verbeterd worden door een min of meer geldige header van een browser in het verzoek in te voegen.
\nOndanks de eenvoud hebben HTTP Flood-aanvallen ook hun nadelen. Ten eerste zijn er grote middelen nodig om belasting te cre\u00ebren. Ten tweede worden dergelijke aanvallen heel gemakkelijk gedetecteerd, vooral als ze vanuit \u00e9\u00e9n adres komen. In dat geval worden de verzoeken onmiddellijk gefilterd, hetzij door systeembeheerders, hetzij zelfs op het niveau van de provider. <\/p>\n

Wat te zoeken<\/h3>\n

\nOm het aantal verzoeken per seconde te verlagen zonder in te boeten op effici\u00ebntie, is het noodzakelijk om creatief te zijn en de website te verkennen. Zo kan niet alleen de bandbreedte of server worden belast, maar ook specifieke delen van de applicatie, zoals databases of bestandssystemen. Ook kan men zoeken naar plekken op de site die zware berekeningen uitvoeren: calculators, productselectie-pagina's en meer. Tot slot komt het vaak voor dat er op een site een php-script draait dat een pagina genereert uit honderden duizenden regels. Een dergelijk script belast ook in hoge mate de server en kan een doelwit voor een aanval worden.<\/p>\n

Waar te zoeken<\/h3>\n

\nWanneer we een bron scannen voordat we tests uitvoeren, kijken we in de eerste plaats naar de site zelf. We zoeken naar verschillende invoervelden, zware bestanden - kortom alles wat problemen kan veroorzaken voor de bron en de prestaties kan vertragen. Gewone ontwikkeltools in Google Chrome en Firefox helpen hier, door de laadtijden van pagina's te tonen.
\nWe scannen ook subdomeinen. Bijvoorbeeld, er is een online winkel, abc.com, en deze heeft een subdomein admin.abc.com. Dit is waarschijnlijk het administratiepaneel met autorisatie, maar als er belasting op wordt gelegd, kan dit problemen veroorzaken voor de hoofdbron.
\nDe website kan een subdomein api.abc.com hebben. Waarschijnlijk is dit de bron voor mobiele applicaties. De applicatie kan worden gevonden in de App Store of Google Play, een speciale toegangspunt kan worden ingesteld, het API kan worden ontleed en testaccounts kunnen worden geregistreerd. Het probleem is dat vaak mensen denken dat alles wat beschermd is met autorisatie onaantastbaar is voor aanvallen op de beschikbaarheid. Men zegt dat autorisatie de beste CAPTCHA is, maar dat is niet waar. Het is eenvoudig om 10-20 testaccounts aan te maken en zodra we deze hebben, krijgen we toegang tot complexe en ongedekte functionaliteiten.
\nNatuurlijk kijken we naar de geschiedenis, naar robots.txt en WebArchive, ViewDNS, en zoeken we naar oude versies van de bron. Soms komt het voor dat de ontwikkelaars bijvoorbeeld mail2.yandex.net hebben uitgerold, terwijl de oude versie, mail.yandex.net, is blijven staan. Deze mail.yandex.net wordt niet meer ondersteund, er worden geen ontwikkelingsmiddelen meer aan besteed, maar het blijft wel databases verbruiken. Hierdoor kunnen we met behulp van de oude versie effectief de back-end middelen en alles wat achter de lay-out staat inzetten. Natuurlijk gebeurt dit niet altijd, maar we komen dit soort situaties toch behoorlijk vaak tegen.
\nNatuurlijk analyseren we alle parameters van de aanvraag en de structuur van de cookie. We kunnen bijvoorbeeld een waarde in een JSON-array binnen een cookie plaatsen, een grote hi\u00ebrarchie cre\u00ebren en de resource laten werken met een onredelijk lange verwerkingstijd.<\/p>\n

Zoeklast<\/h3>\n

\nHet eerste wat in je opkomt bij het verkennen van een website, is het belasten van de database, aangezien bijna iedereen een zoekfunctie heeft en deze helaas vaak slecht is beveiligd. Om de een of andere reden besteden ontwikkelaars niet genoeg aandacht aan de zoekfunctie. Maar er is \u00e9\u00e9n aanbeveling: vermijd het doen van repetitieve aanvragen, omdat je dan te maken kunt krijgen met caching, zoals bij een HTTP-overstroming.
\nHet doen van willekeurige aanvragen naar de database is ook niet altijd effectief. Het is veel beter om een lijst van zoekwoorden te maken die betrekking hebben op de zoekfunctie. Als we teruggaan naar het voorbeeld van een webwinkel: stel dat de site banden verkoopt en mogelijkheden biedt om de bandmaat, het type auto en andere parameters in te stellen. Combinaties van relevante woorden zorgen ervoor dat de database onder veel moeilijkere omstandigheden moet werken.
\nBovendien is het verstandig om paginering te gebruiken: het is veel moeilijker voor de zoekfunctie om de op \u00e9\u00e9n na laatste pagina van resultaten terug te geven dan de eerste. Dus met paginering kun je de belasting iets diversifi\u00ebren.
\nIn het onderstaande voorbeeld tonen we de belasting op de zoekfunctie. Het is duidelijk dat de website al na de eerste seconde van de test, met tien aanvragen per seconde, uitviel en niet meer reageerde.<\/p>\n

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

Wat als er geen zoekfunctie is?<\/h3>\n

\nAls er geen zoekfunctie is, betekent dat niet dat de site geen andere kwetsbare invoervelden bevat. Zo kan aanmelding een kwetsbaar veld zijn. Tegenwoordig zijn ontwikkelaars dol op het maken van complexe hashes om hun aanmeldingen te beschermen tegen aanvallen met regenboogtabellen. Dat is goed, maar dergelijke hashes consumeren veel CPU-resources. Een grote stroom valse aanmeldingen leidt tot een procesverval en als gevolg daarvan stopt de site met werken.
\nDe aanwezigheid van allerlei formulieren voor opmerkingen en feedback op de site is een aanleiding om daar zeer grote teksten naar toe te sturen of gewoon massale spam te genereren. Soms accepteren sites ge\u00fcploade bestanden, waaronder in gzip-formaat. In dat geval nemen we een bestand van 1 TB, comprimeren het met gzip tot enkele bytes of kilobytes en sturen het naar de site. Daarna wordt het uitgepakt en ontstaat er een zeer interessant effect. <\/p>\n

Rest API<\/h3>\n

\nLaten we even stilstaan bij populaire diensten zoals Rest API. Het beschermen van een Rest API is veel ingewikkelder dan dat van een gewone website. Zelfs de meest basale methoden voor bescherming tegen wachtwoordherhaals en andere onwettige activiteiten functioneren niet voor Rest API.
\nRest API is heel gemakkelijk te breken, omdat het direct toegang heeft tot de database. Het uit de lucht halen van zo'n dienst heeft behoorlijk ernstige gevolgen voor een bedrijf. Dit komt omdat de Rest API meestal niet alleen de hoofdwebsite aanstuurt, maar ook de mobiele applicatie en enkele interne bedrijfsbronnen. Als dit allemaal uitvalt, is het effect veel groter dan bij een eenvoudige website die offline gaat. <\/p>\n

Lading op zware content<\/h3>\n

\nAls we gevraagd worden om een gewoon one-page applicatie, landing page of visitekaartje te testen zonder complexe functionaliteit, zoeken we naar zware content. Bijvoorbeeld grote afbeeldingen die door de server worden geleverd, binaire bestanden, pdf-documentatie \u2014 we proberen al deze dingen te downloaden. Dergelijke tests belasten het bestandssysteem goed en vullen de netwerken, waardoor ze effectief zijn. Zelfs als je de server niet laat crashen door een groot bestand te downloaden met lage snelheid, vul je gewoon de bandbreedte van de doelserver en dat leidt tot een Denial of Service.
\nAan de hand van zo'n test is te zien dat de website bij een snelheid van 30 RPS niet meer reageerde of 500-fouten van de server gaf.<\/p>\n

\"DDoS
\n
\nVergeet ook de serverconfiguratie niet. Je ziet vaak dat iemand een virtuele machine heeft gekocht, Apache heeft ge\u00efnstalleerd, alles standaard heeft ingesteld en een php-applicatie heeft geplaatst, en hieronder kun je het resultaat zien. <\/p>\n

\"DDoS
\n
\nHier was de belasting slechts 10 RPS. We hebben 5 minuten gewacht en de server viel uit. Het is echter onduidelijk waarom hij uitviel, maar er is een vermoeden dat hij gewoon overstroomd was met geheugen, waardoor hij niet meer reageerde.<\/p>\n

Golflengte gebaseerd<\/h3>\n

\nIn de afgelopen \u00e9\u00e9n \u00e0 twee jaar zijn golfaanvallen behoorlijk populair geworden. Dit komt doordat veel organisaties bepaalde hardware aanschaffen ter bescherming tegen DDoS-aanvallen, waarvoor een bepaalde tijd nodig is om statistieken te verzamelen voordat de aanval gefilterd kan worden. Dit betekent dat ze de aanval in de eerste 30-40 seconden niet filteren omdat ze gegevens verzamelen en leren. Tijdens deze 30-40 seconden kan er echter zoveel verkeer naar de site worden gestuurd dat de bron gedurende lange tijd niet toegankelijk is, totdat alle verzoeken zijn verwerkt.
\nIn het geval van de onderstaande aanval was er een interval van 10 minuten, waarna er een nieuwe, gewijzigde aanval binnenkwam.<\/p>\n

\"DDoS
\n
\nDat betekent dat de bescherming is getraind, de filtering heeft ingeschakeld, maar er kwam een nieuwe, totaal andere aanval binnen, waardoor de bescherming opnieuw moet leren. In feite stopt de filtering met werken, wordt de bescherming ineffectief en is de site niet bereikbaar.
\nBij golfaanvallen zijn de waarden op het hoogtepunt zeer hoog, deze kunnen oplopen tot honderdduizend of een miljoen verzoeken per seconde, in het geval van L7. Als we spreken over L3&4, kunnen daar honderden gigabits verkeer zijn, of, respectievelijk, honderden mpps, als we in pakketten tellen.
\nHet probleem van dergelijke aanvallen ligt in de synchronisatie. De aanvallen komen vanuit een botnet, en om een zeer grote piek bij \u00e9\u00e9n keer te cre\u00ebren, is een hoge mate van synchronisatie vereist. Deze co\u00f6rdinatie lukt niet altijd: soms resulteert dit in een bepaalde paraboolvormige piek, die behoorlijk teleurstellend uitziet.<\/p>\n

Niet enkel HTTP<\/h3>\n

\nNaast HTTP op L7-niveau, zijn we ook ge\u00efnteresseerd in andere protocollen. Gewoonlijk heeft een gemiddelde website, vooral bij reguliere hosting, ook e-mailprotocollen en MySQL blootgelegd. E-mailprotocollen zijn in mindere mate onderhevig aan belasting dan databases, maar ook deze kunnen behoorlijk effectief worden belast, wat resulteert in een overbelaste CPU op de server.
\nWe hebben succesvol gebruik gemaakt van een kwetsbaarheid in SSH uit 2016. Deze kwetsbaarheid is inmiddels bijna overal verholpen, maar dat betekent niet dat je geen belasting op SSH kunt plaatsen. Dat kan wel. Er wordt gewoon enorme belasting van autorisaties gegenereerd, SSH verbruikt bijna alle CPU op de server en vervolgens valt de website al uit door \u00e9\u00e9n of twee verzoeken per seconde. Deze \u00e9\u00e9n of twee verzoeken zijn aan de logs niet te onderscheiden van legitieme belasting.
\nEr blijven veel verbindingen relevant die we op servers openen. Vroeger had Apache hier last van, en nu heeft nginx dit probleem, omdat het vaak standaard wordt ingesteld. Het aantal verbindingen dat nginx open kan houden is beperkt, en we openen dit aantal verbindingen, waarna nginx geen nieuwe verbindingen meer accepteert, waardoor de site niet functioneert.
\nOnze testcluster heeft voldoende CPU-kracht om de SSL-handshake aan te vallen. Zoals de praktijk aantoont, houden botnets hier ook soms van. Enerzijds is het duidelijk dat SSL onmisbaar is, vanwege Google-uitslagen, ranking en veiligheid. Anderzijds heeft SSL helaas een probleem met CPU-verbruik. <\/p>\n

L3&4<\/h3>\n

\nWanneer we spreken over aanvallen op niveau L3&4, verwijzen we meestal naar aanvallen op kanaalniveau. Dergelijke belasting is bijna altijd te onderscheiden van legitieme belasting, tenzij het een SYN-flood aanval betreft. Het probleem van SYN-flood aanvallen voor beschermingsmiddelen is het enorme volume. De maximale waarde voor L3&4 was 1,5-2 Tb\/s. Dergelijk verkeer is zelfs voor grote bedrijven, waaronder Oracle en Google, zeer moeilijk te verwerken.
\nSYN en SYN-ACK zijn pakketten die worden gebruikt bij het opzetten van een verbinding. Daarom is SYN-flood moeilijk te onderscheiden van legitieme belasting: het is niet duidelijk of het een SYN is die is binnengekomen voor het opzetten van een verbinding of een deel van de flood.<\/p>\n

UDP-flood<\/h3>\n

\nGewoonlijk hebben aanvallers niet dezelfde mogelijkheden als wij, dus bij het organiseren van aanvallen kan amplificatie worden gebruikt. Dit betekent dat de aanvaller het internet scant en kwetsbare of verkeerd ingestelde servers vindt die bijvoorbeeld als reactie op \u00e9\u00e9n SYN-pakket drie SYN-ACK-pakketten versturen. Door het IP-adres van de doelserver te vervalsen, kan met \u00e9\u00e9n pakket de capaciteit, laten we zeggen, verdrievoudigd worden en het verkeer naar het doelwit worden omgeleid.<\/p>\n

\"DDoS
\n
\nHet probleem met amplificaties is dat ze moeilijk te detecteren zijn. Een van de meest opvallende voorbeelden is de beruchte kwetsbaarheid met memcached. Daarnaast zijn er nu veel IoT-apparaten, IP-camera's, die ook vaak standaard zijn ingesteld, en in veel gevallen verkeerd zijn geconfigureerd, waardoor aanvallers via dergelijke apparaten vaak aanvallen uitvoeren. <\/p>\n

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

Moeilijke SYN-flood<\/h3>\n

\nSYN-flood is waarschijnlijk de interessantste soort aanval vanuit het perspectief van een ontwikkelaar. Het probleem is dat systeembeheerders vaak IP-blokkering gebruiken voor bescherming. Daarbij lijden niet alleen systeembeheerders die volgens scripts handelen, maar helaas ook sommige beveiligingssystemen die voor veel geld zijn aangeschaft.
\nDeze methode kan desastreuze gevolgen hebben, want als aanvallers vervangingen maken, IP-adressen<\/a>, zal het bedrijf zijn eigen subnet blokkeren. Wanneer de firewall zijn eigen cluster blokkeert, zullen externe interacties instorten en zal de bron falen.
\nBovendien is het niet moeilijk om de blokkering van je eigen netwerk te bereiken. Als er in het kantoor van de klant een Wi-Fi-netwerk is, of als de functionaliteit van bronnen wordt gemeten met verschillende monitoringtools, nemen we het IP-adres van dit monitoringsysteem of de Wi-Fi-cli\u00ebnt van het kantoor en gebruiken dit als bron. De bron lijkt toegankelijk, maar de doel-IP-adressen zijn geblokkeerd. Zo kan het Wi-Fi-netwerk van de HighLoad-conferentie, waar een nieuw product van het bedrijf wordt gepresenteerd, geblokkeerd worden \u2014 en dat brengt bepaalde zakelijke en economische kosten met zich mee.
\nTijdens de tests kunnen we geen ampificatie via memcached met externe bronnen gebruiken, omdat er afspraken zijn gemaakt over het leveren van verkeer alleen aan toegestane IP-adressen. Daarom gebruiken we ampificatie via SYN en SYN-ACK, waarbij het systeem bij het versturen van \u00e9\u00e9n SYN met twee of drie SYN-ACK's reageert, en de aanval op die manier wordt vermenigvuldigd met twee of drie. <\/p>\n

Hulpmiddelen<\/h3>\n

\nEen van de belangrijkste tools die we gebruiken voor de belasting op niveau L7 is Yandex-tank. In het bijzonder wordt een phantom als kanon gebruikt, plus zijn er verschillende scripts voor het genereren van munitie en het analyseren van resultaten.
\nVoor de analyse van netwerkverkeer gebruiken we Tcpdump, voor de serveranalyse \u2014 Nmap. Voor het cre\u00ebren van belasting op niveau L3&4 gebruiken we OpenSSL en een beetje eigen magie met de DPDK-bibliotheek. DPDK is een bibliotheek van Intel die het mogelijk maakt om met de netwerkaansluiting te werken zonder de Linux-stack, waardoor de effici\u00ebntie wordt verhoogd. Uiteraard gebruiken we DPDK niet alleen op niveau L3&4, maar ook op niveau L7, omdat het in staat is om een zeer hoge belasting te genereren, tot enkele miljoenen verzoeken per seconde vanaf \u00e9\u00e9n machine.
\nDaarnaast gebruiken we specifieke traffic generators en speciale tools die we voor specifieke tests schrijven. Als we denken aan een kwetsbaarheid via SSH, kan deze met de hierboven genoemde set niet worden ge\u00ebxploiteerd. Wanneer we het e-mailprotocol aanvallen, maken we gebruik van e-mailtools of schrijven we gewoon scripts daarover.<\/p>\n

\n

Conclusies<\/h3>\n

\nAls conclusie willen we zeggen:<\/p>\n