Vor der Veröffentlichung eines neuen Dienstes wäre es hilfreich, sicherzustellen, dass er unseren Erwartungen entspricht und verfügbar ist, unabhängig davon, wie viele Kunden ihn gleichzeitig nutzen.
Und wie wird dieser Dienst reagieren, wenn ein verteilter DoS-Angriff dagegen organisiert wird? Ist die Ressource vor potenziellen Angreifern geschützt?
Um mögliche Risiken einzuschätzen und die Sicherheit zu erhöhen, ist es sinnvoll, eigenständig Aktionen durchzuführen, die einen DDoS-Angriff simulieren, während die Ressource noch nicht für den Masseneinsatz gestartet wurde.
In diesem Artikel werden wir über die Erfahrungen beim Organisieren von Auslastungstests für DNS- und HTTP-Dienste sprechen.
Vorbereitung
Um die Erzeugung einer großen Menge an Netzwerkverkehr auf der überwachten Ressource zu provozieren, müssen Sie viele virtuelle Maschinen verwenden, von denen jede die maximale Anzahl von Anforderungen an den Service sendet. Wenn Sie kein leistungsstarkes Rechenzentrum haben, ist es sinnvoll, virtuelle Maschinen vorübergehend in einer Cloud zu mieten. Diese Idee hat eine Besonderheit: Sie müssen sicherstellen, dass die Cloud nicht gecrawlt wird, und Ihre Aktivität für die Aktionen eines Angreifers übernehmen.
Beim Vergleich der Richtlinien verschiedener Cloud-Services (jemand verbietet gnadenlos das Konto, mit dem vermutlich die Aktionen ausgeführt wurden, die zum Ausfall der Ressource führten) hinsichtlich der Durchführung von Auslastungstests unter Verwendung ihrer Funktionalität haben wir uns für Amazon Web Services (AWS) entschieden. Aus den Dokumenten geht hervor , dass AWS Lasttests zulässt, die Genehmigung jedoch durch Senden einer E-Mail an eine bestimmte Adresse beantragt.
Harmonisierung von Stresstests
Wir senden eine Nachricht, in der wir kurz über unsere Absichten sprechen, und wir erhalten ein Formular, das ausgefüllt werden muss:
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:
Es gibt verschiedene Nuancen:
Sie fragen uns, wen wir "bräunen" wollen. Haben wir ein Recht darauf? Wir sagen, dass dies unsere Ressource ist (anscheinend überprüft niemand, ob dies der Fall ist) und dass die Tests vollständig konsistent sind.
Wir müssen festlegen, wie viel Verkehr wir in den einzelnen Regionen erzeugen werden. Während der Korrespondenz stellen wir fest, dass jede Region ihre eigene Grenze für den Netzwerkverkehr hat. Insgesamt dürfen sie 645 Gb / s anfordern. Wir überlegen, wie viel für den Angriff benötigt wird, und wählen die Regionen so aus, dass der erforderliche Wert erzielt wird.
Es muss beschrieben werden, wann der Angriff ausgeführt wird, wie lange er andauert und wie seine Kraft zunimmt. In freier Form, aber ausführlich genug, besprechen wir unsere Pläne. Der Angriff wird mit einer allmählichen Erhöhung der Leistung ausgeführt. Wir zeichnen also auf, welche Stufen die Prüfung haben wird und welche maximale Leistung bei jeder von ihnen erwartet wird. Das Datum des Angriffs kann bis zu einem Tag weggelassen werden, es ist durchaus möglich, einen Bereich von zwei bis drei Wochen anzugeben.
Und wir geben unser Bestes, um sicherzustellen, dass wir uns gut verhalten, den Testfortschritt sorgfältig überwachen und ihn bei Bedarf bei der ersten Anforderung stoppen.
Als Antwort auf das ausgefüllte Formular werden sie höchstwahrscheinlich um eine Klarstellung bitten, sodass wir korrespondieren und Fragen beantworten, bis wir die Erlaubnis zum Testen erhalten.
Es dauert ungefähr drei Werktage, bis der Genehmigungsprozess abgeschlossen ist, wenn die Antwort umgehend erfolgt.
Vorbereitung der Infrastruktur
Nach den Genehmigungen stehen wir vor der Notwendigkeit, die Infrastruktur für Tests vorzubereiten. Tatsache ist, dass wir während der Überprüfung umgehend Folgendes tun müssen:
• eine Instanz aufnehmen;
• einen Testangriff starten;
• Statistiken über den Fortschritt sammeln;
• den Testangriff stoppen;
• Ändern Sie die IP-Adresse.
• Schalten Sie die Instanz aus.
Instanz-Image erstellen
Wählen Sie den Instanztyp
Erstellen wir zunächst ein AWS-Image, das die für die Verwaltung erforderlichen Tools und Skripts enthält. Der erste Schritt ist die Auswahl der zu mietenden Instanz. Wir untersuchen die Eigenschaften verschiedener Arten von Instanzen: Wir untersuchen den Preis, die Menge des maximalen Datenverkehrs und die CPU-Leistung (letztere ist wichtig, da der Datenverkehr immerhin durch die Prozessorkapazitäten verursacht wird), dann testen wir die tatsächliche Leistung und die maximale Anzahl von Anforderungen. Nach unseren Schätzungen t3.small Instanzen am besten zum Testen, aber hier wählt jeder nach seinem Geschmack.
Eigenschaften von Instanzen finden Sie hier . Sie können hier auch Instanzen auswählen und vergleichen.
Anfrage begrenzen
Sie müssen im Voraus überlegen, wie viele Instanzen an den Tests teilnehmen werden. Tatsache ist, dass Amazon für jede Region die Anzahl der Instanzen begrenzt. Wenn Sie das Gefühl haben, dass Sie mehr Instanzen benötigen, als standardmäßig verfügbar sind, sollten Sie so früh wie möglich eine Erhöhung des Limits beantragen. Wechseln Sie dazu zum Abschnitt Support , und erstellen Sie einen Aufruf vom Typ Service-Limit-Erhöhung. Die Bearbeitungszeit für den Einspruch kann unterschiedlich sein: Jemand antwortet am nächsten Tag und stellt so viele Entitäten wie gewünscht zur Verfügung. Jemand sagt, dass er nicht mehr als N Instanzen ausführen lässt. Es gab Regionen, die etwa einen Monat lang auf die Anfrage geantwortet haben.
Leistungsoptimierung
Als Nächstes müssen Sie ein Instanzimage erstellen, das während des Tests gestartet wird. Dazu schalten wir die Instanz des ausgewählten Typs ein, nehmen alle Einstellungen daran vor und speichern das Geschehene als Bild (im Menü Aktionen, in dem Sie die Instanz aktivieren können, sowie die Funktionen zum Erstellen eines Bildes Bild erstellen).
Wir müssen den maximalen ausgehenden Datenverkehr von jeder Instanz erhalten, also optimieren wir zuerst die Netzwerk- und Speichereinstellungen für unsere Aufgabe auf der Instanz.
/etc/sysctl.conf dazu die Einstellungen in der Datei /etc/sysctl.conf :
• Erhöhen Sie die Reichweite lokaler Ports und reduzieren Sie die Zeit, die Sockets im Status FIN_WAIT benötigen:
net.ipv4.ip_local_port_range = 1024-65535 ( : 32768-61000) net.ipv4.tcp_fin_timeout = 10 ( : 60)
Der lokale Portbereich bestimmt die maximale Anzahl der ausgehenden Sockets, die ein Host von einer bestimmten IP-Adresse aus erstellen kann.
Mit der Standardeinstellung (61.000–32.768) werden 28.233 Buchsen erhalten. Mit neuen Einstellungen - 64 500.
Fin_timeout definiert die minimale Zeit, die ausgehende Sockets im Zustand FIN_WAIT sein können.
Wenn Standardwerte angegeben werden, kann das System nicht mehr als (61.000 - 32.768) / 60 = 470 Sockets pro Sekunde bereitstellen.
Durch Erhöhen von port_range und Verringern von fin_timeout können wir die Fähigkeit des Systems beeinflussen, mehr ausgehende Verbindungen zu generieren.
• Lassen Sie uns Sockets im TIME_WAIT-Status wiederverwenden, wenn die freien Sockets enden:
net.ipv4.tcp_tw_reuse = 1
Das Einstellen der obigen Option (die standardmäßig deaktiviert ist) hilft, den Verlust von "inaktiven" bereits erfüllten Verbindungen zu minimieren.
Sehr detailliert über TIME_WAIT wird in diesem Artikel beschrieben .
• Aktivieren Sie die Option tcp_timestamps, damit die obige Option tcp_tw_reuse funktioniert:
net.ipv4.tcp_timestamps = 1 – `tcp_timestamps` tcp_tw_reuse
• Andere Optionen:
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 –
Angriffsskripte testen
1. DNS-Angriff
Eine der Hauptaufgaben beim Testen ist die Bewertung der Leistung von DNS-Servern. DNS-Server können nämlich zum Engpass bei der Fehlertoleranz eines Standorts werden, da selbst bei Problemen mit DNS der stabilste Dienst nicht verfügbar ist. Um eine Last auf den DNS-Servern zu erstellen, werden viele verschiedene DNS-Abfragen generiert. Anforderungen müssen gültig sein und die größtmögliche und längste Antwort vom DNS-Server erfordern.
Das Dienstprogramm DNSPerf eignet sich zum Generieren dieses Datenverkehrs.
DNSPerf ist ein einfaches, flexibles und kostenloses Tool zum Testen der DNS-Leistung. Es wurde in erster Linie für autorisierende DNS-Server entwickelt, kann jedoch auch zum Messen der Leistung von Caching-Servern verwendet werden.
In unserem Fall werden autorisierende DNS-Server geladen, die eine Zone bedienen - example.com.
Für DNSPerf bereiten wir zuerst eine Datei mit den Anforderungen von dns_queries.txt (hauptsächlich ANY, um die Zeit und die Größe der Antwort vom DNS-Server zu erhöhen):
#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
Beispiel für das Ausführen des Dienstprogramms:
dnsperf -s TARGET_IP -d dns_queries.txt -c 100 -n 100 -s = IP- -d = . – stdin -c = . -n = «» .
2. Angriff auf ICMP
Die nächste Testphase besteht darin, die Beständigkeit gegenüber einer großen Anzahl von ICMP-Verkehr zu bewerten. Da Server aus technischen Gründen häufig in der Lage sein müssen, auf Ping-Anfragen zu antworten, besteht die Möglichkeit eines DDoS-Angriffs mit Ping-Anfragen. Sie müssen nicht nur Einstellungen festlegen, die die Möglichkeit von ping-to-death , sondern auch sicherstellen, dass die Server gegen ICMP-Lastspitzen beständig sind. Um solche Lasten zu erstellen, ist es besser, das bekannte Dienstprogramm hping3 zu verwenden , mit dem Sie die Anzahl der Anforderungen, das Intervall zwischen den Sendungen sowie die Paketgröße anpassen können.
Beispiel für das Ausführen des Dienstprogramms:
hping3 -i u1000 -d 1500 -c 100000 -1 TARGET_IP -i u100 = (uX for X microseconds) -d 1500 = -c 1000000 = -1 = ICMP
3. HTTP-Angriff
Jetzt überprüfen wir die Hauptfunktionalität des Dienstes auf Stressresistenz - die Verarbeitung von HTTP (S) -Verkehr. Eines der flexibelsten und einfachsten Tools zum Generieren von HTTP-Verkehr ist die Belagerung . Siege ist ein Open-Source-Multithread-Dienstprogramm, mit dem die Leistung einer Webressource getestet werden kann.
Wie bei DNSPerf können Sie mit Belagerung den Server mit Anforderungen von einer bestimmten Anzahl virtueller Benutzer laden (Benutzeremulation wird über einen separaten Port ausgeführt) und vordefinierte Anforderungssätze verwenden. Dies ist sehr praktisch, da Sie die ressourcenintensivsten Abfragen in den Test einbeziehen können.
Beispiel für das Ausführen des Dienstprogramms:
siege -b -c 100 -f test_urls.txt -b = ( benchmark) -c = . -f =
Inhaltsformat 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
Wie Sie sehen, wurden die Tests hauptsächlich mit POST-Anforderungen durchgeführt, die auf der Serverseite verarbeitet werden müssen und im Vergleich zu anderen Arten von Anforderungen die meisten Ressourcen belegen.
Keine der Optionen verwendet IP-Spoofing, da Amazon dies nicht zulässt. Unabhängig davon, welches src_IP im Paket angegeben ist, wird es beim Verlassen der Instanz in das richtige geändert.
Alle generierten Anfragen müssen legitim sein - es bleibt keine Welle von ausgehendem Datenverkehr unbeantwortet - da die DDoS-Richtlinien von Amazon ziemlich streng sind. Selbst ein koordinierter Stresstest benötigt mindestens einige Tage, um mit dem technischen Support zu kommunizieren. Bei den ersten "böswilligen" Aktionen wird der Hafen gesperrt, aus dem der Datenverkehr stammt, und die Anforderung muss sofort erläutert werden.
Skripte zum Starten von Angriffen
Für die Remotetestverwaltung erstellen wir Bash-Skripte (dns.sh, ping.sh, http.sh), die den gewünschten Angriffstyp starten, sowie Nutzlastdateien (test_urls.txt, valid_dns_queries.txt).
Wenn wir all dies in das AWS-Image hochladen (aus dem alle Instanzen erstellt werden), kann jeder Test mit dem Befehl des folgenden Formats remote ausgeführt werden:
ssh instance-amazon 'sudo <stress-script>.sh start <params> &>>stress.log &'
Das Skript des erforderlichen Typs wird als stress-script.sh angegeben, und params sind die entsprechenden Parameter. In der stress.log-Datei verfolgen wir die Ausgabe des ausgeführten Dienstprogramms. Der Einfachheit halber verwenden wir verschiedene Protokolle für verschiedene Dienstprogramme: dns.log, ping.log, http.log.
Beispiel dns.sh Skript:
Wie aus dem Code hervorgeht, kann das Skript gestartet und gestoppt sowie der Status (ausgeführt / nicht ausgeführt) überprüft werden.
Skripte für ICMP- und HTTP-Tests werden auf die gleiche Weise erstellt, wobei hping3 bzw. siege mit der durch das Argument übergebenen Parameterzeichenfolge gestartet werden.
Beispiele für Befehle:
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 &'
Überwachen von Skripten
Um den ausgehenden Datenverkehr und den Status der Testinfrastruktur zu bewerten, benötigen wir ein Überwachungstool. Aus Gründen der Einfachheit und Ressourcenschonung verwenden wir iptables. Dazu schreiben wir ein Skript, das die Anzahl der gesendeten MB zählt, und fügen es in das AWS-Image ein:
#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
Das Skript erstellt eine neue Kette TRAFFIC_OUT und fügt ihr Filter für die erforderlichen Protokolle hinzu: tcp, udp, icmp.
Die Paketweiterleitung an TRAFFIC_OUT wird der OUTPUT-Kette hinzugefügt.
Die übertragene Datenmenge kann mit dem Befehl ermittelt werden:
# 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
Installieren Sie das Skript als Dienst. Erstellen Sie dazu eine Datei monitoring.service und verschieben Sie sie in das Verzeichnis /etc/systemd/system unseres Images:
# /etc/systemd/system/monitoring.service [Unit] After=network.target [Service] ExecStart=/usr/local/bin/monitoring.sh [Install] WantedBy=default.target
Jetzt können Sie den Dienst zum Start hinzufügen:
systemctl enable monitoring.service systemctl start monitoring.service
Instanzverwaltung
Kommen wir nun zum (möglichst automatisierten) Remote-Instance-Management.
Zu diesem Zweck können Sie den AWS CLI- Mechanismus - Konsolenverwaltung verwenden.
Erstellen Sie einen geheimen Schlüssel (Zugangsschlüssel (Zugangsschlüssel-ID und geheimer Zugangsschlüssel)) und konfigurieren Sie die Konsole.
Jetzt haben wir Zugriff auf alle Funktionen des Kontos.
Die Besonderheit bei der Arbeit mit AWS besteht darin, dass alle Aktionen für eine bestimmte Region ausgeführt werden und wiederholt werden müssen, wenn mehrere Regionen betroffen sind.
Um eine neue Instanz aus dem oben erstellten Image zu erstellen (wir gehen davon aus, dass es eine öffentliche Ami-ID gibt, die wir im Skript verwenden), gehen wir wie folgt vor:
- Erstellen Sie einen SSH-Schlüssel und fügen Sie ihn zu AWS hinzu:
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
- Erstellen Sie eine Sicherheitsgruppe, die den Zugriff auf den Computer über SSH ermöglicht. Andernfalls werden eingehende SSH-Verbindungen verweigert:
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
- Erstellen Sie eine Instanz mit dem zuvor erstellten Schlüssel und der zuvor erstellten Sicherheitsgruppe und geben Sie die Image-ID an. Die Anzahl der gleichzeitig erstellten Instanzen kann beliebig sein:
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
- Warten Sie, bis die Maschine initialisiert ist. Dies dauert einige Zeit: Zuerst erhalten wir eine Erfolgsantwort (instance.json), aber zu diesem Zeitpunkt wurde der Computer gerade erstellt, aber noch nicht gestartet (z. B. wurde ihm noch keine IP-Adresse zugewiesen). Es muss gewartet werden, bis der Start abgeschlossen ist (normalerweise reicht hierfür eine Minute aus).
Dann können Sie über SSH eine Verbindung herstellen, wenn wir die IP-Adresse kennen. Fordern Sie einfach eine Liste der derzeit aktiven Maschinen an. Unter ihren Parametern finden wir PublicDnsName oder PublicIpAddress.
aws ec2 describe-instances --region
Als nächstes führen wir die SSH-Befehle aus und geben den oben erstellten SSH-Schlüssel an:
ssh -I $KEYNAME -oStrictHostKeyChecking=no ubuntu''+ins_dns echo''O''
Mit SSH-Befehlen können Sie den Angriff steuern und erhalten alle Informationen über den Status des Angriffs, da wir die Instanzen mit allen erforderlichen Skripten und Tools versehen haben.
Sie müssen verstehen, dass die meisten Schutzmaßnahmen gegen Denial-of-Service-Angriffe die IP-Adresse blockieren, von der ungewöhnlich viele Anforderungen empfangen werden. Daher müssen sich die IP-Adressen virtueller Maschinen ständig ändern, um die Angriffsstärke aufrechtzuerhalten.
AWS weist bei jedem Start der Maschine eine neue IP-Adresse zu. Um die IP-Adresse zu ändern, müssen Sie das Gerät aus- und wieder einschalten (es muss nicht entfernt werden!).
Der Unterschied zwischen Herunterfahren und Löschen besteht darin, dass wir unterschiedliche Signale senden. Stop - ausschalten, beenden - ausschalten und sofort löschen.
Um den eingehenden Verkehr einer Instanz zu überwachen, verwenden wir den folgenden Befehl mit der Instanz-ID: Wenn die Verkehrsmessung beginnt, wenn sie endet, für welchen Zeitraum werden die Werte summiert:
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
Überwachung der Serviceverfügbarkeit
Um einen Angriff durchzuführen, müssen Sie außerdem beobachten, ob der von uns getestete Dienst aktiv ist.
Wir erstellen und führen das einfachste "Ping" -Skript aus, das die Verfügbarkeit der Zielports überwacht (in unserem Fall 53 und 80).
Beispiel-Python-Code, der die Verfügbarkeitsprüfung automatisiert:
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
Die empfangenen Informationen werden in einer Protokolldatei gespeichert, auf deren Grundlage anhand der Ergebnisse des Angriffs ein Diagramm der Ressourcenverfügbarkeit erstellt werden kann.
Während des Testens ist es notwendig, das Ping-Protokoll ständig zu überprüfen, um die Ressource nicht vollständig und unwiderruflich zu zerstören. Sobald eine signifikante Beeinträchtigung auftritt und die Antwort auf die Anforderung zu lange dauert, muss der Angriff abgebrochen werden.
Wenn die Verlangsamung unbedeutend ist und die Angriffskraft das festgelegte Maximum erreicht hat, ist es sinnvoll, ein oder zwei Minuten zu warten, und wenn der Dienst ohne Unterbrechungen weiterarbeitet, wird die Überprüfung als erfolgreich angesehen.
Finanzielles Problem
Es lohnt sich, ein weiteres Thema im Zusammenhang mit der Organisation von Tests zu erörtern - die Kosten dieser gesamten Veranstaltung.
Amazon bietet detaillierte Preisinformationen, aber Sie müssen verstehen, dass Sie für fast alles bezahlen müssen. Dennoch können viele Berechnungen vernachlässigt werden. Zunächst lohnt es sich, die Verkehrskosten (abhängig von der Region und davon, wie viele Informationen insgesamt übertragen werden) und die Kosten für Mietinstanzen (Zahlung pro Minute) zu berechnen. Diese Gegenstände machen ungefähr 99% der Kosten des gesamten Angriffs aus.
Daher werden die Angriffskosten in Abhängigkeit von der maximalen Angriffskraft und der Anzahl der geplanten Starts jeweils separat berechnet.
Im Hinblick auf eine Vereinfachung der Berechnungen ist es besser, ein Amazon-Konto zu verwenden, das vor nicht mehr als einem Jahr registriert wurde. Dann wird ein Teil der Operationen frei sein. Weitere Informationen zu den Beschränkungen für die kostenlose Nutzung finden Sie hier .
Um die Berechnung der Kosten für die Durchführung von Auslastungstests zu veranschaulichen, möchten wir beispielsweise die Stabilität des DNS-Servers bei einer Auslastung von 10 Gbit / s überprüfen.
Wir wissen, dass Sie mit den verwendeten Tools und den Funktionen der in Mumbai gestarteten t3.small-Instanz 500 MBit / s von einer ausgeführten Instanz ausgeben können. Der Preis für die Anmietung eines Unternehmens beträgt 0,0224 USD pro Stunde für den Datenverkehr - 0,01093 USD für 1 GB. Das heißt, der Höhepunkt des Angriffs bedeutet den gleichzeitigen Betrieb von 20 Einheiten.
Wir werden die Angriffskraft schrittweise erhöhen. Dazu starten wir zuerst eine Entität und fügen dann alle 60 Sekunden eine weitere hinzu.
Die Formel zur Berechnung der Kosten hat folgende Form:
60 * ( ) + 60 * 0,5 /c * ( ) = 60 . 1 * ( ) + 2 * ( ) + ... + 20 * ( ) =
Es stellt sich heraus, dass ein Angriff mit einer Kapazität von 10 Gbit / s auf einen DNS-Server ungefähr 70 US-Dollar kostet. Beachten Sie, dass dies eine grobe Schätzung ist, da das Verkehrsaufkommen nicht genau vorhergesagt werden kann. . , – , .
. .