✍🏽 🈸 🐄 Génération de trafic dans l'espace utilisateur 💆🏿 🐦 👤

Génération de trafic à l'aide de MoonGen + DPDK + Lua dans la vue de l'artiste

La neutralisation des attaques DDoS en conditions réelles nécessite des tests préliminaires et des tests de diverses techniques. L'équipement et les logiciels réseau doivent être testés dans des conditions artificielles proches des conditions réelles - avec des flux de trafic intensifs simulant des attaques. Sans de telles expériences, il est extrêmement difficile d'obtenir des informations fiables sur les caractéristiques spécifiques et les limites de tout outil complexe.

Dans cet article, nous allons révéler certaines des méthodes de génération de trafic utilisées dans Qrator Labs.

AVERTISSEMENT

Nous recommandons fortement au lecteur de ne pas essayer d'utiliser les outils mentionnés pour attaquer des objets d'une infrastructure réelle. L'organisation d'attaques DoS est punie par la loi et peut entraîner des sanctions sévères. Qrator Labs effectue tous les tests dans un environnement de laboratoire isolé.

Niveau technique moderne

Une tâche importante dans notre domaine consiste à saturer l'interface Ethernet 10G avec de petits paquets, ce qui implique un traitement de 14,88 Mpps (millions de paquets par seconde). Ci-après, nous considérons les plus petits paquets de réseau Ethernet - 64 octets - car notre principal intérêt est de maximiser le nombre de paquets transmis par unité de temps. Un calcul simple montre que nous avons seulement environ 67 nanosecondes pour traiter un tel paquet.

À titre de comparaison, cette fois-ci est proche de ce dont un processeur moderne a besoin pour obtenir un morceau de données de la mémoire s'il manque le cache. Tout devient encore plus compliqué lorsque nous commençons à travailler avec des interfaces Ethernet 40G et 100G et essayons de les saturer complètement jusqu'au débit de ligne (les performances déclarées maximales possibles du périphérique réseau).

Étant donné que dans le cas habituel, le flux de données passe par l'application dans l'espace utilisateur (espace utilisateur), puis par le noyau, pour finalement entrer dans le contrôleur réseau (NIC), la première et la plus simple idée est d'essayer de configurer la génération de paquets directement dans le noyau. Un exemple d' une telle solution est le module nucléaire pktgen [2]. Cette méthode vous permet d'améliorer considérablement les performances, mais pas assez flexible, car le moindre changement dans le code source dans le noyau entraîne un long cycle de construction, un redémarrage des modules du noyau ou même du système entier et, en fait, des tests, ce qui réduit la productivité globale (c'est-à-dire que cela nécessite plus de temps de la part du programmeur et effort).

Une autre approche possible consiste à obtenir un accès direct de l'espace utilisateur aux tampons de mémoire du contrôleur de réseau. Ce chemin est plus compliqué, mais vaut l'effort pour atteindre une productivité plus élevée. Les inconvénients incluent une grande complexité et une faible flexibilité. Des exemples de cette approche sont netmap , PF_RING et DPDK [4].

Un autre moyen efficace, quoique très coûteux, d'atteindre des performances élevées consiste à utiliser un équipement non universel, mais spécialisé. Exemple: Ixia .

Il existe également des solutions basées sur DPDK utilisant des scripts, ce qui augmente la flexibilité dans le contrôle des paramètres du générateur et vous permet également de varier le type de packages générés au démarrage. Ci-dessous, nous décrivons notre propre expérience avec l'un de ces outils - MoonGen.

Architecture MoonGen

Les caractéristiques distinctives de MoonGen sont:

Le traitement des données DPDK dans l'espace utilisateur est la principale raison du gain de performances;
Lua [ 5 ] pile avec des scripts simples au niveau supérieur et des liaisons à la bibliothèque DPDK écrite en C, en bas;
Grâce à la technologie JIT (juste à temps), les scripts Lua fonctionnent assez rapidement, ce qui contredit quelque peu les idées généralement acceptées sur l'efficacité des langages de script.

MoonGen peut être considéré comme un wrapper Lua autour de la bibliothèque DPDK. Au moins les opérations DPDK suivantes sont visibles au niveau de l'interface utilisateur Lua:

Configuration des contrôleurs de réseau;
Allocation et accès direct aux pools et tampons de mémoire, qui, à des fins d'optimisation, doivent être alloués dans des zones alignées en continu;
Accès direct aux files d'attente RSS des contrôleurs de réseau;
API de gestion des flux de calcul, prenant en compte l'hétérogénéité des accès mémoire (NUMA et affinité CPU) [ 12 ].

Architecture MoonGen, schéma à partir du matériau [ 1 ].

Moongen

MoonGen est un générateur de paquets haute vitesse scripté basé sur la bibliothèque DPDK. Les scripts Lua contrôlent l'ensemble du processus: le script créé par l'utilisateur est responsable de la création, de la modification et de l'envoi des packages. Grâce à la bibliothèque de traitement de paquets LuaJIT et DPDK très rapide, cette architecture vous permet de saturer une interface Ethernet de 10 gigabits avec des paquets de 64 octets en utilisant un seul cœur du CPU. MoonGen vous permet d'atteindre cette vitesse même lorsque le script Lua modifie chaque package. Il n'utilise pas d'astuces comme la réutilisation du même tampon du contrôleur réseau.

MoonGen peut également recevoir des paquets, c'est-à-dire vérifier quels paquets ont été abandonnés par le système testé. Étant donné que la réception des paquets est contrôlée exclusivement par un script Lua personnalisé, il peut également être utilisé pour créer des scripts de test plus complexes. Par exemple, vous pouvez utiliser deux instances de MoonGen pour établir une connexion entre elles. Une telle configuration peut notamment être utilisée pour tester les boîtiers dits intermédiaires (équipements entre le point d'envoi et de réception du trafic), par exemple les pare-feu. MoonGen se concentre sur quatre domaines principaux:

Haute performance et évolutivité multicœur: plus de 20 millions de paquets par seconde sur un seul cœur de processeur;
Flexibilité: chaque package est généré en temps réel sur la base d'un script Lua créé par l'utilisateur;
Horodatage exact: sur le matériel ordinaire (marchandise), le marquage horaire est effectué avec une précision de la milliseconde;
Contrôle précis des intervalles entre les paquets envoyés: génération fiable des modèles et types de trafic requis sur du matériel ordinaire.

DPDK

DPDK signifie Data Plane Development Kit et se compose de bibliothèques dont les fonctions principales sont d'augmenter les performances de génération de paquets réseau sur une grande variété d'architectures de processeur central.

Dans un monde où les réseaux informatiques deviennent le fondement de la communication humaine, les performances, la bande passante et la latence deviennent des paramètres de plus en plus critiques pour des systèmes tels que les réseaux sans fil et l'infrastructure de câbles, y compris tous leurs composants individuels: routeurs, équilibreurs de charge, pare-feu; ainsi que des domaines d'application: transfert média (streaming), VoIP, etc.

DPDK est un moyen léger et pratique de créer des tests et des scripts. Le transfert de données dans l'espace utilisateur est quelque chose que nous n'observons pas si souvent, principalement parce que la plupart des applications communiquent avec les équipements réseau via le système d'exploitation et la pile du noyau, ce qui est l'opposé du modèle DPDK.

Lua

Le principal objectif de l'existence de Lua est de fournir des outils expressifs simples et flexibles qui sont extensibles pour des tâches actuelles spécifiques, au lieu d'un ensemble de primitives applicables dans un seul paradigme de programmation. En conséquence, la langue de base est très légère - l'intégralité de l'interpréteur ne prend que 180 Ko sous forme compilée et s'adapte facilement à un large éventail d'implémentations possibles.

Lua est un langage dynamique. Il est si compact qu'il peut être placé sur presque n'importe quel appareil. Lua prend en charge un petit ensemble de types: valeurs booléennes, nombres (virgule flottante double précision) et chaînes. Les structures de données classiques, telles que les tableaux, les ensembles et les listes, peuvent être représentées par la seule structure de données intégrée dans Lua - une table, qui est un tableau associatif hétérogène.

Lua utilise la compilation JIT (juste à temps), donc, étant un langage de script, il affiche des performances comparables aux langages compilés tels que C [ 10 ].

Pourquoi moongen

En tant qu'entreprise spécialisée dans la neutralisation des attaques DDoS, Qrator Labs a besoin d'un moyen fiable pour créer, mettre à niveau et tester ses propres solutions de sécurité. C'est pour ces derniers, les tests, que diverses méthodes de génération de trafic simulant des attaques réelles sont nécessaires. Cependant, il n'est pas si facile de simuler une attaque par inondation dangereuse, mais simple, aux 2-3 niveaux du modèle OSI, principalement en raison des difficultés à atteindre des performances élevées dans la génération de paquets.

En d'autres termes, pour une entreprise engagée dans la disponibilité et la neutralisation continues des DDoS, simuler diverses attaques DoS dans un environnement de laboratoire isolé est un moyen de comprendre comment les différents équipements qui font partie des systèmes matériels de l'entreprise se comporteront dans la réalité.

MoonGen est un bon moyen de générer des valeurs de trafic proches de la limite pour le contrôleur de réseau avec un minimum de cœurs de processeur. Le transfert de données dans l'espace utilisateur améliore considérablement les performances de la pile en question (MoonGen + DPDK), par rapport à de nombreuses autres options pour générer des valeurs de trafic élevées. L'utilisation de DPDK pur nécessite beaucoup plus d'efforts, vous ne devez donc pas être surpris de notre désir d'optimiser les performances. Nous prenons également en charge un clone [ 7 ] du référentiel MoonGen d'origine afin d'étendre la fonctionnalité et la mise en œuvre de nos propres tests.

Afin d'obtenir une flexibilité maximale, la logique de génération des packages est définie par l'utilisateur à l'aide du script Lua, qui est l'une des principales fonctionnalités de MoonGen. Dans le cas d'un traitement de paquets relativement simple, cette solution fonctionne assez rapidement pour saturer l'interface 10G sur un seul cœur de processeur. Une façon typique de modifier des packages entrants et d'en créer de nouveaux consiste à travailler avec des packages du même type, dans lesquels seuls certains des champs changent.

Un exemple est le test l3-tcp-syn-ack-flood, décrit ci-dessous. Notez que toute modification du package peut être effectuée dans le même tampon, où le package généré ou reçu à l'étape précédente s'est avéré être. En effet, de telles conversions de paquets sont effectuées très rapidement, car elles n'impliquent pas d'opérations coûteuses, telles que des appels système, l'accès à des sections de mémoire potentiellement non mises en cache, etc.

Tests sur le matériel Qrator Labs

Qrator Labs effectue tous les tests en laboratoire sur divers équipements. Dans ce cas, nous avons utilisé les contrôleurs d'interface réseau suivants:

Intel 82599ES 10G
Mellanox ConnectX-4 40G
Mellanox ConnectX-5 100G

Nous notons séparément que lorsque vous travaillez avec des contrôleurs de réseau fonctionnant sur des normes supérieures à 10G, le problème de performances devient plus aigu. Aujourd'hui, il n'est pas possible de saturer l'interface 40G avec un seul cœur, bien qu'avec un petit nombre de cœurs, cela soit déjà réaliste.

Dans le cas des contrôleurs de réseau fabriqués par Mellanox, il est possible de modifier certains paramètres et réglages de l'appareil à l'aide du guide de réglage [ 3 ] fourni par le fabricant. Cela vous permet d'augmenter les performances et, dans certains cas particuliers, d'approfondir le comportement de la carte réseau. D'autres fabricants peuvent avoir des documents similaires pour leurs propres appareils hautes performances destinés à un usage professionnel. Même si vous ne trouvez pas un tel document dans le domaine public, il est toujours judicieux de contacter directement le fabricant. Dans notre cas, les représentants de la société Mellanox ont été très gentils et, en plus de fournir de la documentation, ont rapidement répondu à nos questions, grâce auxquelles nous avons réussi à utiliser à 100% la bande, ce qui était très important pour nous.

Test d'inondation TCP SYN

L3-tcp-syn-ack-flood est un exemple de simulation d'une attaque comme SYN flood [ 6 ]. Il s'agit d'une version étendue de Qrator Labs du test l3-tcp-syn-flood du référentiel principal MoonGen, qui est stocké dans notre clone de référentiel.

Notre test peut exécuter trois types de processus:

Générez un flux de paquets TCP SYN à partir de zéro, en faisant varier les champs requis, tels que l'adresse IP source, le numéro de port source, etc.
Créez une réponse ACK valide pour chaque paquet SYN reçu selon TCP;
Créez une réponse SYN-ACK valide pour chaque paquet ACK reçu conformément au protocole TCP.

Par exemple, la boucle de code interne (respectivement, la «plus chaude») pour créer des réponses ACK est la suivante:

local tx = 0 local rx = rxQ:recv(rxBufs) for i = 1, rx do local buf = rxBufs[i] local pkt = buf:getTcpPacket(ipv4) if pkt.ip4:getProtocol() == ip4.PROTO_TCP and pkt.tcp:getSyn() and (pkt.tcp:getAck() or synack) then local seq = pkt.tcp:getSeqNumber() local ack = pkt.tcp:getAckNumber() pkt.tcp:unsetSyn() pkt.tcp:setAckNumber(seq+1) pkt.tcp:setSeqNumber(ack) local tmp = pkt.ip4.src:get() pkt.ip4.src:set(pkt.ip4.dst:get()) pkt.ip4.dst:set(tmp) … -- some more manipulations with packet fields tx = tx + 1 txBufs[tx] = buf end end if tx > 0 then txBufs:resize(tx) txBufs:offloadTcpChecksums(ipv4) -- offload checksums to NIC txQ:send(txBufs) end

L'idée générale de créer un ensemble de réponses est la suivante. Tout d'abord, vous devez supprimer le paquet de la file d'attente RX, puis vérifier si le type de paquet correspond à celui attendu. En cas de coïncidence, préparez une réponse en modifiant certains champs du package d'origine. Enfin, placez le paquet créé dans la file d'attente TX en utilisant le même tampon. Pour améliorer les performances, au lieu de prendre les paquets un par un et de les modifier un par un, nous les agrégons, en extrayant tous les paquets disponibles de la file d'attente RX, en créant les réponses correspondantes et en les mettant tous dans la file d'attente TX. Malgré un nombre assez important de manipulations sur un même package, les performances restent élevées, principalement en raison du fait que Lua JIT compile toutes ces opérations dans un petit nombre d'instructions de processeur. De nombreux autres tests, non seulement TCP SYN / ACK, fonctionnent sur le même principe.

Le tableau ci-dessous montre les résultats du test SYN flood (génération SYN sans tentatives de réponse) à l'aide de Mellanox ConnectX-4. Cette carte réseau possède deux ports 40G avec un plafond de performances théorique de 59,52 Mpps sur un port et 2 * 50 Mpps pour deux ports. L'implémentation spécifique de la connexion de la carte réseau au PCIe limite quelque peu la bande passante (donnant 2 * 50 au lieu des 2 * 59,52 attendus).

cœurs par port	1 port, Mpps	2 ports, Mpps pour chaque port
1	20	19
2	38	36
3	56,5	47
4	59,5	50

Test d'inondation SYN; Carte réseau: famille Mellanox Technologies MT27700 (ConnectX-4), double port 40G; Processeur: Processeur Intel® Xeon® Silver 4114 à 2,20 GHz

Le tableau suivant montre les résultats du même test d'inondation SYN effectué sur un Mellanox ConnectX-5 avec un port 100G.

noyaux	Mpps
1	35
2	69
3	104
4	127
5	120
6	131
7	132
8	144

Test d'inondation SYN; Carte réseau: famille Mellanox Technologies MT27800 (ConnectX-5), port 100G unique; Processeur: Processeur Intel® Xeon® Silver 4114 à 2,20 GHz

Notez que dans tous les cas, nous atteignons plus de 96% du plafond de performance théorique sur un petit nombre de cœurs de processeur.

Capturez le trafic entrant et enregistrez-le dans des fichiers PCAP

Un autre exemple du test est rx-to-pcap, qui tente de capturer tout le trafic entrant et de l'enregistrer dans un certain nombre de fichiers PCAP [ 8 ]. Bien que ce test ne concerne pas spécifiquement la génération de packages en tant que tels, il sert de démonstration du fait que le maillon le plus faible dans l'organisation du transfert de données via l'espace utilisateur est le système de fichiers. Même le système de fichiers virtuel tmpfs ralentit considérablement le flux. Dans ce cas, 8 cœurs du processeur central sont nécessaires pour utiliser 14,88 Mpps, tandis qu'un seul cœur suffit pour recevoir (et réinitialiser ou rediriger) la même quantité de trafic.

Le tableau suivant montre la quantité de trafic (en Mpps) qui a été reçue et enregistrée dans des fichiers PCAP situés dans le système de fichiers ext2 sur le SSD (deuxième colonne) ou sur le système de fichiers tmpfs (troisième colonne).

noyaux	sur SSD, Mpps	sur tmpfs, Mpps
1	1,48	1,62
2	4	4.6
3	6,94	8.1
4	9,75	11,65
5	12,1	13,8
6	13,38	14,47
7	14,4	14,86
8	14,88	14,88

Test Rx-to-pcap; Carte réseau: Intel 82599ES 10 Gigabit; CPU: Intel® Xeon® CPU E5-2683 v4 @ 2.10GHz

Modification de MoonGen: tman Task Manager

Nous aimerions également présenter au lecteur notre propre extension de la fonctionnalité MoonGen, qui fournit une autre façon de lancer un groupe de tâches pour les tests. L'idée principale ici est de séparer la configuration générale et les paramètres spécifiques à chaque tâche, vous permettant d'exécuter un nombre arbitraire de tâches différentes (c'est-à-dire des scripts Lua) en même temps. Dans notre clone du référentiel MoonGen, l'implémentation de MoonGen avec le gestionnaire de tâches [ 9 ] est présentée, nous ne listerons ici que brièvement ses principales fonctions.

La nouvelle interface de ligne de commande vous permet d'exécuter simultanément plusieurs tâches de différents types. Le scénario de base est le suivant:

 ./build/tman [tman options...] [-- <task1-file> [task1 options...]] [-- <task2-file> [task2 options...]] [-- ...]

De plus, ./build/tman -h fournit une aide détaillée.

Cependant, il existe une limitation: les fichiers de travail Lua standard ne sont pas compatibles avec l'interface tman . Le fichier de travail tman doit définir clairement les objets suivants:

La fonction configure (analyseur) qui décrit les paramètres du travail;
La fonction de tâche (taskNum, txInfo, rxInfo, args), qui décrit le processus de tâche réel. Ici, txInfo et rxInfo sont des tableaux de files d'attente RX et TX, respectivement; args contient les paramètres du gestionnaire de tâches et la tâche elle-même.
Des exemples peuvent être trouvés dans examples / tman.

L'utilisation du gestionnaire de tâches vous donne plus de flexibilité pour exécuter des tests hétérogènes.

Conclusions

La méthode proposée par MoonGen s'est avérée bien adaptée à nos objectifs et a satisfait les employés avec les résultats obtenus. Nous avons obtenu un outil très performant, tout en maintenant à la fois l'environnement de test et le langage assez simples. Les performances élevées de cette configuration sont obtenues grâce à deux caractéristiques principales: l'accès direct aux tampons du contrôleur d'interface réseau et la technique de compilation Just-In-Time dans Lua.

En règle générale, la réalisation d'un plafond théorique pour les performances d'un contrôleur d'interface réseau est une tâche réalisable. Comme nous l'avons montré, un seul cœur peut suffire à saturer un port 10G, tandis qu'une charge complète d'un port 100G ne présente pas de problème particulier avec un plus grand nombre de cœurs.

Nous sommes particulièrement reconnaissants à l'équipe Mellanox pour leur aide avec leur équipement et à l'équipe MoonGen pour leur réaction à la correction des erreurs.

Génération de trafic dans l'espace utilisateur