Avant la sortie d'un nouveau service, il serait bon de s'assurer qu'il fonctionne conformément à nos attentes et est disponible quel que soit le nombre de clients l'utilisant en même temps.

Et comment ce service réagira-t-il si une attaque DoS distribuée est organisée contre lui? La ressource est-elle protégée des attaquants potentiels?

Afin d'évaluer les risques possibles et d'augmenter la sécurité, il est logique de mener indépendamment des actions qui simulent une attaque DDoS, alors que la ressource n'a pas encore été lancée pour une utilisation de masse.

Dans cet article, nous parlerons de l'expérience de l'organisation des tests de charge pour les services DNS et HTTP.

La préparation

Afin de provoquer la génération d'une énorme quantité de trafic réseau sur la ressource surveillée, vous devez utiliser de nombreuses machines virtuelles, chacune envoyant le nombre maximal de demandes au service. Si vous ne disposez pas d'un centre de données puissant, il est judicieux de louer temporairement des machines virtuelles dans un cloud. Cette idée a une particularité: vous devez vous assurer que le cloud ne rampe pas, en prenant votre activité pour les actions d'un attaquant.

En comparant les politiques de divers services cloud (quelqu'un bannit impitoyablement un compte avec lequel, vraisemblablement, des mesures ont été prises qui ont conduit à une défaillance des ressources) concernant les tests de charge en utilisant leurs fonctionnalités, nous avons décidé de nous arrêter à Amazon Web Services (AWS). Leurs documents indiquent qu'AWS autorise les tests de charge, mais demande l'approbation en envoyant un e-mail à une adresse spécifique.

Harmonisation des tests de résistance

Nous envoyons un message où nous parlons brièvement de nos intentions, et nous obtenons un formulaire qui doit être rempli:

Customer ID: Customer Name: Email Address: AWS Account ID load test will be performed from: Does the customer have an NDA? Target Data EC2 Resources: Cloudfront Distribution: API Gateway / Lambda ID: ELB Names: Non-AWS Target: Region (please list all regions in scope for testing): Source Data: IP Addresses: Source Account ID: Regions involved: Testing Parameters: How much traffic do you plan to generate by region during testing? What is your expected peak load from source by region? (ie xx Gbps) What is your expected peak load at destination? (ie xx Gbps) Are you testing traffic outbound from EC2, inbound into EC2, or both? Are you testing traffic outbound (egress) from EC2, inbound (ingress) into EC2, or both: Egress. What is your expected peak load from source by region? (ie xx Gbps) Ingress. What is your expected peak load from source by region? (ie xx Gbps) Start Date: End Date: Finite testing details including timeline of testing: Summary of Test: Testing Timelines by phase including rps, pps, and Gbps: Peak bandwidth for each source IP: Tools Used for each phase of test: Types of testing to be performed for each phase of the request: What criteria/metrics will you monitor to ensure the success of this test? Who is performing the Load Test? (Please provide contact details): Does the tester have an NDA? Testing Security Do you have a way to monitor the data traffic for the duration of the test to verify bandwidth limits do not exceed approved rates? Do you have a way to immediately stop the traffic if we/you discover any issue? 2 Emergency contact names and phone numbers: 

Il existe plusieurs nuances:

1. Ils nous demandent qui nous "bronzerons". Avons-nous droit à cela? Nous disons que c'est notre ressource (apparemment, personne ne vérifie si c'est le cas) et que les tests sont entièrement cohérents.

   
   

2. Nous devons désigner la quantité de trafic que nous créerons dans chacune des régions. Au cours de la correspondance, nous découvrons que chaque région a sa propre limite sur la quantité de trafic réseau. Au total, ils sont autorisés à demander 645 Gb / s. Nous considérons combien est nécessaire pour l'attaque, et nous sélectionnons les régions de manière à obtenir la valeur nécessaire.

   
   

3. Il est nécessaire de décrire la durée de l'attaque, sa durée et la croissance de sa puissance. Sous forme libre, mais avec suffisamment de détails, nous parlons de nos plans. L'attaque est effectuée avec une augmentation progressive de la puissance, nous peignons donc les étapes du test et la puissance maximale attendue pour chacune d'elles. La date de l'attaque peut être omise jusqu'à un jour; il est tout à fait possible d'indiquer une plage de deux à trois semaines.

   
   

4. Et sans faute, nous faisons de notre mieux pour nous assurer que nous nous comportons bien, surveiller attentivement la progression des tests et l'arrêter à la première demande si nécessaire.

   
   

Très probablement, en réponse au formulaire rempli, ils demanderont des éclaircissements, alors nous correspondons et répondons aux questions jusqu'à ce que nous obtenions la permission de tester.

Il faut environ trois jours ouvrables pour terminer le processus d'approbation en cas de réponse rapide.

Préparation des infrastructures

Après les approbations, nous sommes confrontés à la nécessité de préparer l'infrastructure pour les tests. Le fait est que lors de la vérification, nous devrons rapidement:

• inclure une instance;

• lancer une attaque test;

• collecter des statistiques sur les progrès;

• arrêter l'attaque d'essai;

• changer l'adresse IP;

• désactiver l'instance.

Créer une image d'instance

Sélectionnez le type d'instance

Commençons par créer une image AWS qui contiendra les outils et scripts nécessaires à la gestion. La première étape consiste à choisir l'instance à louer. Nous étudions les caractéristiques des différents types d'instances: nous regardons le prix, la quantité de trafic maximum, la puissance CPU (ce dernier est important, car le trafic est créé par la puissance du processeur après tout), puis nous testons les performances réelles et le nombre maximum de requêtes. Selon nos estimations, les instances t3.small sont les plus pratiques pour les tests, mais ici tout le monde choisit à son goût.

Les caractéristiques des instances peuvent être trouvées ici . Vous pouvez également sélectionner et comparer des instances ici .

Demande de limite

Vous devez penser à l'avance au nombre d'instances qui participeront au test. Le fait est qu'Amazon prévoit pour chaque région ses limites sur le nombre d'instances. Si vous avez le sentiment que vous aurez besoin de plus d'instances que ce qui est disponible par défaut, vous devez demander une augmentation de la limite le plus tôt possible. Pour ce faire, accédez à la section Support , créez un appel de type Augmentation de la limite de service. Le temps de traitement d'une demande peut être différent: quelqu'un répond le lendemain, fournissant autant d'entités que demandé, quelqu'un dit qu'il ne laissera pas plus de N instances s'exécuter. Certaines régions ont répondu à la demande pendant environ un mois.

Réglage des performances

Ensuite, vous devez créer une image d'instance qui sera lancée pendant les tests. Pour ce faire, nous activons l'instance du type sélectionné, définissons tous les paramètres dessus, puis enregistrons ce qui s'est passé en tant qu'image (dans le menu Actions, où vous pouvez activer l'instance, ainsi que la fonctionnalité pour créer une image Créer une image).

Nous devons obtenir le trafic sortant maximal de chaque instance, nous optimisons donc d'abord les paramètres réseau et mémoire pour notre tâche sur l'instance.

Pour ce faire, /etc/sysctl.conf les paramètres dans le fichier /etc/sysctl.conf :

• Augmentez la portée des ports locaux et réduisez le temps passé par les sockets dans l'état FIN_WAIT:

 net.ipv4.ip_local_port_range = 1024-65535 ( : 32768-61000) net.ipv4.tcp_fin_timeout = 10 ( : 60) 

La plage de ports locaux détermine le nombre maximal de sockets sortants qu'un hôte peut créer à partir d'une adresse IP spécifique.

Avec le paramètre par défaut (61 000–32 768), 28 233 sockets sont obtenus. Avec de nouveaux paramètres - 64 500.

Fin_timeout définit la durée minimale pendant laquelle les sockets sortants peuvent être dans l'état FIN_WAIT.

Si des valeurs par défaut sont spécifiées, le système ne peut pas fournir plus de (61 000–32 768) / 60 = 470 sockets par seconde.

En augmentant port_range et en diminuant fin_timeout, nous pouvons affecter la capacité du système à générer davantage de connexions sortantes.

• Réutilisons les sockets dans l'état TIME_WAIT à la fin des sockets libres:

 net.ipv4.tcp_tw_reuse = 1 

La définition de l'option ci-dessus (qui est désactivée par défaut) permet de minimiser la perte de connexions "inactives" déjà remplies.

Des informations très détaillées sur TIME_WAIT sont décrites dans cet article .

• Activez l'option tcp_timestamps pour que l'option tcp_tw_reuse ci-dessus fonctionne:

 net.ipv4.tcp_timestamps = 1 –   `tcp_timestamps`     tcp_tw_reuse 

• Autres options:

 net.ipv4.tcp_max_tw_buckets = 720000 –       TIME_WAIT net.ipv4.tcp_keepalive_time = 600 –  - keepalive- net.ipv4.tcp_keepalive_probes = 3 –   keepalive- net.ipv4.tcp_keepalive_intvl = 10 –     keepalive- net.ipv4.tcp_window_scaling = 1 –   TCP- net.ipv4.tcp_mem = 8192 131072 196304 –     TCP- net.ipv4.udp_mem = 8192 131072 196304 –     udp- net.ipv4.tcp_slow_start_after_idle=0 –  Slow-Start Restart net.core.wmem_default = 31457280 –         net.core.wmem_max = 33554432 –        net.core.somaxconn = 65535 –        net.core.netdev_max_backlog = 65535 –          vm.swappiness = 30 –    vm.dirty_ratio = 50 –     50 %  vm.pagecache = 90 –     

Tester les scripts d'attaque

1. Attaque DNS

L'une des principales tâches des tests consiste à évaluer les performances des serveurs DNS. À savoir, les serveurs DNS peuvent devenir le goulot d'étranglement de la tolérance aux pannes d'un site, car même si le service le plus stable n'est pas disponible en cas de problème avec DNS. Pour créer une charge sur les serveurs DNS, nous allons générer de nombreuses requêtes DNS différentes. Les demandes doivent être valides et nécessitent la réponse la plus large et la plus longue possible du serveur DNS.

L'utilitaire DNSPerf convient pour générer un tel trafic.

DNSPerf est un outil de test de performances DNS simple, flexible et gratuit. Il est principalement conçu pour les serveurs DNS faisant autorité, mais peut également être utilisé pour mesurer les performances des serveurs de mise en cache.

Dans notre cas, des serveurs DNS faisant autorité sont chargés et desservent une zone - example.com.

Pour DNSPerf, nous préparons d'abord un fichier avec les requêtes dns_queries.txt (principalement TOUT pour augmenter le temps et la taille de la réponse du serveur DNS):

 #dns_queries.txt example.com ANY www.example.com ANY test.example.com ANY static.example.com ANY example.com  www.example.com  test.example.com MX 

Exemple d'exécution de l'utilitaire:

 dnsperf -s TARGET_IP -d dns_queries.txt -c 100 -n 100 -s =  IP- -d =      .   – stdin -c =   .         -n =  «»   . 

2. Attaque contre ICMP

La prochaine étape des tests consiste à évaluer la résistance à un grand nombre de trafic ICMP. Étant donné que, pour des raisons techniques, les serveurs doivent souvent être en mesure de répondre aux requêtes ping, il existe une possibilité d'attaque DDoS utilisant des requêtes ping. En plus de spécifier des paramètres qui excluent la possibilité de ping-to-death , vous devez vous assurer que les serveurs sont résistants aux pics de charge ICMP. Pour créer de telles charges, il est préférable d'utiliser l'utilitaire hping3 bien connu, qui vous permet d'ajuster le nombre de demandes, l'intervalle entre les envois, ainsi que la taille des paquets.

Exemple d'exécution de l'utilitaire:

 hping3 -i u1000 -d 1500 -c 100000 -1 TARGET_IP -i u100 =     (uX for X microseconds) -d 1500 =    -c 1000000 =     -1 =  ICMP 

3. Attaque HTTP

Maintenant, nous vérifions la résistance au stress, la principale fonctionnalité du trafic HTTP (S) de traitement des services. L'un des outils les plus flexibles et les plus simples pour générer du trafic HTTP est le siège . Siege est un utilitaire multithread open source conçu pour tester les performances d'une ressource Web.

Comme DNSPerf, siege vous permet de charger le serveur avec les demandes d'un nombre donné d'utilisateurs virtuels (l'émulation des utilisateurs est effectuée à l'aide d'un port séparé), ainsi que d'utiliser un ensemble prédéfini de demandes. Ceci est très pratique, car vous pouvez inclure les requêtes les plus gourmandes en ressources dans le test.

Exemple d'exécution de l'utilitaire:

 siege -b -c 100 -f test_urls.txt -b =   ( benchmark) -c =   .         -f =    

Format de contenu test_urls.txt :

 http://example.com/site/login POST login=username&password=test http://example.com/site/client POST useragent=Mozilla&version=123&date=24May http://example.com/site/order POST user=username&company=ooo&phone=812345678 

Comme vous pouvez le voir, les tests ont été effectués en utilisant principalement des requêtes POST qui nécessitent un traitement côté serveur et occupent le plus grand nombre de ressources par rapport aux autres types de requêtes.

Aucune des options n'utilise l'usurpation d'adresse IP, car Amazon ne le permet pas. Quel que soit src_IP spécifié dans le package, il sera remplacé par le bon à la sortie de l'instance.

Toutes les demandes générées doivent être légitimes - aucune vague de trafic sortant sans réponse - car la politique DDoS d'Amazon est assez stricte. Même un test de stress coordonné prend un minimum de plusieurs jours pour communiquer avec le support technique, et lors des premières actions "malveillantes" nous obtenons l'interdiction du port d'où le trafic est sorti, et l'exigence doit être expliquée immédiatement.

Scripts pour lancer des attaques

Pour la gestion des tests à distance, nous préparerons des scripts bash (dns.sh, ping.sh, http.sh) qui lancent le type d'attaque souhaité et des fichiers de charge utile (test_urls.txt, valid_dns_queries.txt).

Lorsque nous téléchargeons tout cela sur l'image AWS (à partir de laquelle toutes les instances seront créées), chaque test peut être exécuté à distance à l'aide de la commande du format suivant:

 ssh instance-amazon 'sudo <stress-script>.sh start <params> &>>stress.log &' 

Le script du type requis est spécifié sous la forme stress-script.sh et params sont les paramètres correspondants. Dans le fichier stress.log, nous suivrons la sortie de l'utilitaire en cours d'exécution. Pour plus de commodité, nous utiliserons différents journaux pour différents utilitaires: dns.log, ping.log, http.log.

Exemple de script dns.sh :

 #!/bin/bash if [[ ! "$1" =~ ^(start|stop|status)$ ]]; then echo "nothing to do: need argument for stop,start or status" exit 1 fi if [[ "$1" = "start" ]]; then shift dnsperf $@ fi if [[ "$1" = "stop" ]]; then kill $(pidof dnsperf) fi if [[ "$1" = "status" ]]; then if [[ ! "$(pidof dnsperf)" = "" ]]; then echo "dnperf is running with PID $(pidof dnsperf)" ps aux | grep dnsperf else echo "dnsperf is not running" fi fi 

Comme le montre le code, le script peut être démarré et arrêté, ainsi que vérifier l'état (en cours / non en cours d'exécution).

Les scripts pour les tests ICMP et HTTP sont construits de la même manière, en démarrant hping3 et siege, respectivement, avec la chaîne de paramètres passée à travers l'argument.

Exemples de commandes:

 ssh instance-amazon 'sudo dns.sh start -s TARGET_IP -d valid_dns_queries.txt -c 1 -n 100 &>>dns.log &' ssh instance-amazon 'sudo ping.sh start -i u1000 -d 1500 -c 100000 -1 TARGET_IP &>>ping.log &' ssh instance-amazon 'sudo http.sh start -b -c 100 -f test_urls.txt &>> http.log &' 

Surveiller les scripts

Pour évaluer le trafic sortant et l'état de l'infrastructure de test, nous avons besoin d'un outil de surveillance. Pour des raisons de simplicité et d'économie de ressources, nous utilisons iptables. Pour ce faire, nous allons écrire un script qui compte le nombre de Mo envoyés et le placer sur l'image AWS:

 #iptables.sh sudo iptables -N TRAFFIC_OUT sudo iptables -A TRAFFIC_OUT -p tcp sudo iptables -A TRAFFIC_OUT -p udp sudo iptables -A TRAFFIC_OUT -p icmp sudo iptables -A OUTPUT -j TRAFFIC_OUT sudo iptables-save 

Le script crée une nouvelle chaîne TRAFFIC_OUT et y ajoute des filtres pour les protocoles nécessaires: tcp, udp, icmp.

Le transfert de paquets vers TRAFFIC_OUT est ajouté à la chaîne OUTPUT.

La quantité de données transférées peut être trouvée par la commande:

 # iptables -L TRAFFIC_OUT -v -n -x | tail -n 3 | awk '{print $2/1024/1024,"Mb\t\t\t",$3}' : 2.2 Mb tcp 4.4 Mb udp 3.2 Mb icmp 

Installez le script en tant que service. Pour ce faire, créez un fichier monitoring.service et déplacez-le dans le répertoire /etc/systemd/system de notre image:

 # /etc/systemd/system/monitoring.service [Unit] After=network.target [Service] ExecStart=/usr/local/bin/monitoring.sh [Install] WantedBy=default.target 

Vous pouvez maintenant ajouter le service au démarrage:

 systemctl enable monitoring.service systemctl start monitoring.service 

Gestion des instances

Passons maintenant à la gestion des instances à distance (aussi automatisée que possible).

À ces fins, vous pouvez utiliser le mécanisme AWS CLI - gestion de la console.

Créez une clé secrète (clés d'accès (ID de clé d'accès et clé d'accès secrète)) et configurez la console.

Nous avons maintenant accès à toutes les fonctionnalités du compte.

La particularité de travailler avec AWS est que toutes les actions sont effectuées pour une région spécifique et doivent être répétées si plusieurs régions sont impliquées.

Pour créer une nouvelle instance à partir de l'image que nous avons construite ci-dessus (nous supposons qu'il existe un ami-ID public que nous utilisons dans le script), nous ferons ce qui suit:

• créez une clé SSH et ajoutez-la à AWS:

 yes n |ssh-keygen -q -t rsa -f $KEYNAME -m pem -N "" > /dev/null chmod 400 $KEYNAME aws ec2 import-key-pair --region $REGION --key-name $KEYNAME --public-key-material file:///$(pwd)/$KEYNAME.pub 

• créer un groupe de sécurité qui permet l'accès à la machine via SSH. Sinon, les connexions SSH entrantes seront refusées:

 SECURITY="ssh-group" aws ec2 create-security-group --region $REGION --group-name $SECURITY --description "Just ssh. Nothing more" IP_RANGE="0.0.0.0/24" aws ec2 authorize-security-group-ingress --region $REGION --group-name $SECURITY --protocol tcp --port 22 --cidr $IP_RANGE 

• créez une instance avec la clé et le groupe de sécurité créés précédemment et spécifiez l'ID d'image. Le nombre d'instances créées simultanément peut être arbitraire:

 IMG='ami-0d0eaed20348a3389' NUM=1 aws ec2 run-instances --region $REGION --image-id $IMG --count $NUM --instance-type t2.micro --key-name $KEYNAME --security-groups default $SECURITY > instances.json 

• attendez que la machine soit initialisée. Cela prend un certain temps: nous obtenons d'abord une réponse de réussite (instances.json), mais à ce moment-là, la machine vient d'être créée, mais pas encore démarrée (par exemple, aucune adresse IP n'a encore été attribuée). Il faut attendre la fin du lancement (généralement une minute suffit).

Ensuite, vous pouvez vous connecter via SSH si nous connaissons l'adresse IP. Demandez simplement une liste des machines en cours d'exécution. Parmi leurs paramètres, nous trouvons PublicDnsName ou PublicIpAddress.

 aws ec2 describe-instances --region 

Ensuite, nous exécutons les commandes SSH, indiquant la clé SSH créée ci-dessus:

 ssh -I $KEYNAME -oStrictHostKeyChecking=no ubuntu''+ins_dns echo''O'' 

Les commandes SSH vous permettent de contrôler l'attaque et d'obtenir toutes les informations sur l'état de l'attaque, car nous avons fourni aux instances tous les scripts et outils nécessaires.

Vous devez comprendre que la plupart des défenses contre les attaques par déni de service bloquent l'adresse IP à partir de laquelle de nombreuses demandes sont reçues de manière anormale. Par conséquent, les adresses IP des machines virtuelles doivent constamment changer afin de maintenir la puissance d'attaque.

AWS attribue une nouvelle adresse IP à chaque démarrage de la machine. Par conséquent, pour changer l'adresse IP, vous devez éteindre et rallumer la machine (pas besoin de la retirer!).

La différence entre l'arrêt et la suppression est que nous envoyons des signaux différents. Arrêter - pour désactiver, terminer - pour désactiver et supprimer immédiatement.

Afin de surveiller le trafic entrant d'une instance, nous utilisons la commande suivante avec l'ID d'instance: quand la mesure du trafic commence, quand elle se termine, pour quelle période les valeurs sont additionnées:

 aws cloudwatch get-metric-statistics --region REGION --namespace AWS/EC2 \ --statistics Sum --metric-name NetworkIn --start-time $STARTTIME --end-time $FINISHTIME --period $PERIOD --dimensions Name=InstanceId,Value=$INCTANCEID 

Surveillance de la disponibilité des services

De plus, pour mener une attaque, vous devrez observer si le service que nous testons est vivant.

Nous créons et exécutons le script de «ping» le plus simple qui surveille la disponibilité des ports cibles (53 et 80 dans notre cas).

Exemple de code Python qui automatise la vérification de la disponibilité:

 def http(url): cmd = ['curl', '-w', '"%{time_total}"', '-o', '/dev/null', '-s', url] result = check_output(cmd).decode('utf-8') result = float(json.loads(result)) return result * 1000000 def dns(ip, domain): cmd = ['dig', 'any', '@'+ip, domain ] result = check_output(cmd).decode('utf-8') result = int(result.split('Query time:')[1].split('msec')[0]) return result 

Les informations reçues sont stockées dans un fichier journal, sur la base duquel, sur la base des résultats de l'attaque, il sera possible de construire un graphique de disponibilité des ressources.

Lors des tests, il est nécessaire de vérifier en permanence le journal «ping» afin de ne pas tuer complètement et irrévocablement la ressource. Dès qu'une dégradation importante apparaît et que la réponse à la demande prend trop de temps, l'attaque doit être arrêtée.

Si le ralentissement est insignifiant et que la puissance d'attaque a atteint le maximum défini, il est logique d'attendre une minute ou deux et si le service continue de fonctionner sans interruption, la vérification est considérée comme réussie.

Problème financier

Il vaut la peine de discuter d'une autre question liée à l'organisation des tests - le coût de l'ensemble de cet événement.

Amazon fournit des informations détaillées sur les prix, mais vous devez comprendre que vous devez payer pour presque tout. Néanmoins, de nombreux calculs peuvent être négligés. Tout d'abord, il vaut la peine de calculer le coût du trafic (cela dépend de la région et de la quantité totale d'informations qui seront transmises) et le coût de la location des instances (paiement par minute). Ces objets représentent environ 99% du coût de toute l'attaque.

Par conséquent, le coût d'une attaque est calculé dans chaque cas séparément, en fonction de la [puissance des hostilités] puissance d'attaque maximale et du nombre de lancements prévus.

Du point de vue de la simplification des calculs, il est préférable d'utiliser un compte Amazon, qui a été enregistré il y a moins d'un an. Une partie des opérations sera alors gratuite. En savoir plus sur les limites d'utilisation gratuite ici .

Afin d'illustrer le calcul du coût de réalisation des tests de charge, disons que nous voulons vérifier la stabilité du serveur DNS à une charge de 10 Gb / s.

Nous savons que les outils utilisés et les capacités de l'instance t3.small lancée à Mumbai vous permettent d'émettre 500 Mb / s à partir d'une instance en cours d'exécution. Le prix de location d'une entité est de 0,0224 $ l'heure, pour le trafic - 0,01093 $ pour 1 Go. Autrement dit, le pic de l'attaque signifie le fonctionnement simultané de 20 entités.

Nous augmenterons progressivement la puissance d'attaque, pour cela nous lançons d'abord une entité, puis nous en ajoutons une autre toutes les 60 s.

La formule de calcul du coût prend la forme:

 60  * (   ) + 60  * 0,5 /c * (  ) =       60 . 1 * (    ) + 2 * (    ) + ... + 20 * (    ) =    

Il s'avère que le coût d'une attaque d'une capacité de 10 Gb / s sur un serveur DNS est d'environ 70 $. Notez qu'il s'agit d'une estimation approximative, car le volume de trafic ne peut pas être prévu avec précision. . , – , .

. .