قبل إصدار خدمة جديدة ، سيكون من الجيد التأكد من أنها تعمل وفقًا لتوقعاتنا ومتاحة بغض النظر عن عدد العملاء الذين يستخدمونها في نفس الوقت.
وكيف سيكون رد فعل هذه الخدمة إذا تم تنظيم هجوم DoS موزع ضدها؟ هل المورد محمي من المهاجمين المحتملين؟
من أجل تقييم المخاطر المحتملة وزيادة الأمان ، فمن المنطقي القيام بشكل مستقل بإجراءات تحاكي هجوم DDoS ، في حين لم يتم إطلاق المورد للاستخدام الشامل.
في هذه المقالة ، سنتحدث عن تجربة تنظيم اختبار الحمل لخدمات DNS و HTTP.
تدريب
من أجل إثارة توليد قدر كبير من حركة مرور الشبكة على المورد الذي تتم مراقبته ، تحتاج إلى استخدام العديد من الأجهزة الافتراضية ، كل منها سيرسل الحد الأقصى لعدد الطلبات إلى الخدمة. إذا لم يكن لديك مركز بيانات قوي ، فمن المنطقي استئجار أجهزة افتراضية مؤقتًا في السحابة. تتميز هذه الفكرة بخصوصية واحدة: يجب عليك التأكد من أن السحابة لا تزحف ، فتأخذ نشاطك في تصرفات المهاجم.
بمقارنة سياسات مختلف الخدمات السحابية (يحظر شخص بلا رحمة الحساب الذي من المفترض أنه تم تنفيذ الإجراءات التي أدت إلى فشل المورد) فيما يتعلق بإجراء اختبار الحمل باستخدام وظائفه ، قررنا التوقف في Amazon Web Services (AWS). تشير مستنداتهم إلى أن AWS تسمح باختبار الحمل ، ولكنها تطلب الموافقة عن طريق إرسال بريد إلكتروني إلى عنوان محدد.
توحيد اختبار الإجهاد
نرسل رسالة نتحدث فيها باختصار عن نوايانا ، ونحصل على نموذج يجب ملؤه:
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:
هناك العديد من الفروق الدقيقة:
يسألوننا من سوف "نمر". هل لدينا الحق في ذلك؟ نقول أن هذا هو موردنا (على ما يبدو ، لا أحد يتحقق مما إذا كان الأمر كذلك) وأن الاختبار متسق تمامًا.
نحتاج إلى تعيين مقدار حركة المرور التي سننشئها في كل منطقة. خلال المراسلات ، اكتشفنا أن لكل منطقة حدودها الخاصة على مقدار حركة مرور الشبكة. في المجموع ، يسمح لهم بطلب 645 جيجابت / ثانية. نحن نفكر في مقدار المطلوب للهجوم ، ونختار المناطق بطريقة للحصول على القيمة اللازمة.
يلزم وصف الوقت الذي سيتم فيه تنفيذ الهجوم ، ومدة استمراره وكيف ستنمو قوته. في شكل حر ، ولكن بتفصيل كاف نتحدث عن خططنا. يتم تنفيذ الهجوم مع زيادة تدريجية في القوة ، لذلك نحن نرسم المراحل التي سيخضع لها الاختبار وما أقصى قوة متوقعة في كل منها. يمكن حذف تاريخ الهجوم حتى يوم واحد ، ومن الممكن الإشارة إلى مدى يتراوح بين أسبوعين وثلاثة أسابيع.
وبدون فشل ، نحن نبذل قصارى جهدنا للتأكد من أننا سنتصرف بشكل جيد ، ونراقب بعناية تقدم الاختبار ونوقفه عند الطلب الأول إذا لزم الأمر.
على الأرجح ، استجابةً للنموذج المكتمل ، سيطلبون بعض التوضيح ، لذلك نحن نتوافق مع الأسئلة ونجيب عليها حتى نحصل على تصريح للاختبار.
يستغرق حوالي ثلاثة أيام عمل لإكمال عملية الموافقة إذا تمت الإجابة عليها على الفور.
إعداد البنية التحتية
بعد الموافقات ، نواجه الحاجة إلى إعداد البنية التحتية للاختبار. الحقيقة هي أنه خلال الفحص ، سنحتاج إلى:
• تشمل مثيل ؛
• شن هجوم اختبار ؛
• جمع إحصاءات عن التقدم المحرز ؛
• وقف هجوم الاختبار ؛
• تغيير عنوان IP ؛
• أغلق المثيل.
إنشاء صورة مثيل
اختر نوع المثيل
أولاً ، دعونا نبني صورة AWS تحتوي على الأدوات والبرامج النصية اللازمة للإدارة. الخطوة الأولى هي اختيار المثيل المطلوب تأجيره. ندرس خصائص أنواع مختلفة من الحالات: ننظر إلى السعر ، وكمية الحد الأقصى لحركة المرور ، وطاقة وحدة المعالجة المركزية (وهذا الأخير مهم ، لأنه يتم إنشاء حركة المرور بواسطة قدرات المعالج بعد كل شيء) ، ثم نقوم باختبار الأداء الحقيقي والحد الأقصى لعدد الطلبات. وفقًا لتقديراتنا ، t3.small الحالات t3.small هي الأكثر ملاءمة للاختبار ، ولكن هنا يختار الجميع ذوقه.
يمكن العثور على خصائص الحالات هنا . يمكنك أيضًا تحديد ومقارنة المثيلات هنا .
طلب الحد
يلزمك التفكير مسبقًا في عدد الحالات التي ستشارك في الاختبار. والحقيقة هي أن الأمازون يوفر لكل منطقة حدودها على عدد الحالات. إذا كان لديك شعور بأنك ستحتاج إلى عدد أكبر من الحالات مما هو متاح بشكل افتراضي ، فعليك طلب زيادة الحد الأقصى في أقرب وقت ممكن. للقيام بذلك ، انتقل إلى قسم الدعم ، وقم بإنشاء مكالمة من نوع زيادة حد الخدمة. يمكن أن يكون وقت معالجة الاستئناف مختلفًا: يجيب شخص ما في اليوم التالي ، مع تقديم أكبر عدد ممكن من الكيانات حسب الطلب ، ويقول شخص ما إنه لن يدع أكثر من مثيلات N تعمل. كانت هناك مناطق استجابت للطلب لمدة شهر تقريبًا.
ضبط الأداء
بعد ذلك ، تحتاج إلى إنشاء صورة مثيل سيتم إطلاقها أثناء الاختبار. للقيام بذلك ، نقوم بتشغيل مثيل النوع المحدد ، ونقوم بإعداد جميع الإعدادات عليه ، ثم احفظ ما حدث كصورة (في قائمة "إجراءات" ، حيث يمكنك تمكين المثيل ، بالإضافة إلى وظيفة إنشاء صورة إنشاء صورة).
نحتاج إلى الحصول على الحد الأقصى لحركة المرور الصادرة من كل مثيل ، لذلك أولاً نحسّن إعدادات الشبكة والذاكرة لمهمتنا في المثال.
للقيام بذلك ، قم بإجراء الإعدادات في ملف /etc/sysctl.conf :
• زيادة نطاق المنافذ المحلية وتقليل الوقت الذي تقضيه المآخذ في ولاية FIN_WAIT:
net.ipv4.ip_local_port_range = 1024-65535 ( : 32768-61000) net.ipv4.tcp_fin_timeout = 10 ( : 60)
يحدد نطاق المنفذ المحلي الحد الأقصى لعدد مآخذ التوصيل الصادرة التي يمكن للمضيف إنشاءها من عنوان IP محدد.
باستخدام الإعداد الافتراضي (61،000–32،768) ، يتم الحصول على 28،233 مآخذ. مع الإعدادات الجديدة - 64 500.
يحدد Fin_timeout الحد الأدنى من الوقت الذي يمكن أن تكون فيه مآخذ التوصيل الصادرة في حالة FIN_WAIT.
إذا تم تحديد القيم الافتراضية ، فلا يمكن للنظام توفير أكثر من (61000-32،768) / 60 = 470 مآخذ في الثانية الواحدة.
عن طريق زيادة port_range وتناقص fin_timeout ، يمكننا التأثير على قدرة النظام على إنشاء المزيد من الاتصالات الصادرة.
• دعونا نعيد استخدام المآخذ في ولاية TIME_WAIT عندما تنتهي المآخذ المجانية:
net.ipv4.tcp_tw_reuse = 1
يساعد تعيين الخيار أعلاه (والذي يتم تعطيله افتراضيًا) على تقليل فقد الاتصالات "المعطلة" التي تم الوفاء بها بالفعل.
ويرد وصف مفصل للغاية حول TIME_WAIT في هذه المقالة .
• قم بتشغيل خيار tcp_timestamps لخيار tcp_tw_reuse أعلاه للعمل:
net.ipv4.tcp_timestamps = 1 – `tcp_timestamps` tcp_tw_reuse
• خيارات أخرى:
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 –
اختبار البرامج النصية الهجوم
1. هجوم DNS
إحدى المهام الرئيسية للاختبار هي تقييم أداء خوادم DNS. وبصفة خاصة ، يمكن أن تصبح خوادم DNS عنق الزجاجة للتسامح مع الخطأ في الموقع ، لأنه حتى إذا كانت الخدمة الأكثر استقرارًا غير متوفرة إذا كانت هناك مشاكل في DNS. لإنشاء حمل على خوادم DNS ، سنقوم بإنشاء العديد من استعلامات DNS المختلفة. يجب أن تكون الطلبات صالحة وتتطلب أكبر استجابة ممكنة وأطول من خادم DNS.
الأداة المساعدة DNSPerf مناسبة لإنشاء مثل هذه الحركة.
DNSPerf هي أداة اختبار أداء DNS بسيطة ومرنة ومجانية. تم تصميمه في المقام الأول لخوادم DNS الموثوقة ، ولكن يمكن استخدامه أيضًا لقياس أداء خوادم التخزين المؤقت.
في حالتنا ، يتم تحميل خوادم DNS الموثوقة التي تخدم منطقة واحدة - example.com.
بالنسبة لـ DNSPerf ، نقوم أولاً بإعداد ملف به طلبات dns_queries.txt (أي بشكل أساسي أي زيادة وقت وحجم الاستجابة من خادم 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
مثال على تشغيل الأداة المساعدة:
dnsperf -s TARGET_IP -d dns_queries.txt -c 100 -n 100 -s = IP- -d = . – stdin -c = . -n = «» .
2. الهجوم على ICMP
تتمثل المرحلة التالية من الاختبار في تقييم مقاومة عدد كبير من حركة مرور ICMP. نظرًا لأسباب فنية ، غالبًا ما تحتاج الخوادم إلى أن تكون قادرة على الاستجابة لطلبات ping ، هناك احتمال لهجوم DDoS باستخدام طلبات ping. بالإضافة إلى تحديد الإعدادات التي تستبعد إمكانية تنفيذ الأمر ping-to-death ، يجب عليك التأكد من أن الخوادم مقاومة لأحمال ICMP القصوى. لإنشاء مثل هذه الأحمال ، من الأفضل استخدام الأداة المساعدة hping3 المعروفة ، والتي تتيح لك ضبط عدد الطلبات والفاصل الزمني بين عمليات الإرسال وكذلك حجم الحزمة.
مثال على تشغيل الأداة المساعدة:
hping3 -i u1000 -d 1500 -c 100000 -1 TARGET_IP -i u100 = (uX for X microseconds) -d 1500 = -c 1000000 = -1 = ICMP
3. هجوم HTTP
الآن نحن نتحقق من مقاومة الإجهاد للوظائف الرئيسية لخدمة - معالجة حركة مرور HTTP (S). واحدة من أكثر الأدوات مرونة وأسهل لتوليد حركة مرور HTTP هي الحصار . Siege هي أداة مساعدة مفتوحة المصدر ومتعددة الخيوط مصممة لاختبار أداء مورد ويب.
مثل DNSPerf ، يسمح لك الحصار بتحميل الخادم مع طلبات من عدد معين من المستخدمين الظاهري (يتم مضاهاة المستخدم باستخدام منفذ منفصل) ، وكذلك استخدام مجموعة محددة مسبقًا من الطلبات. هذا مناسب للغاية ، حيث يمكنك تضمين أكثر استعلامات الموارد كثافة في الاختبار.
مثال على تشغيل الأداة المساعدة:
siege -b -c 100 -f test_urls.txt -b = ( benchmark) -c = . -f =
تنسيق المحتوى 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
كما ترون ، تم إجراء الاختبارات باستخدام طلبات POST بشكل أساسي والتي تتطلب معالجة من جانب الخادم وتحتل أكبر عدد من الموارد مقارنة بأنواع الطلبات الأخرى.
لا يستخدم أي من الخيارات خداع IP ، حيث أن Amazon لا تسمح بذلك. مهما كان تحديد src_IP في الحزمة ، فسيتم تغييره إلى الحزمة الصحيحة عند الخروج من المثيل.
يجب أن تكون جميع الطلبات التي تم إنشاؤها شرعية - لا توجد موجة من حركة المرور الصادرة دون إجابة - حيث أن سياسة الأمازون DDoS صارمة إلى حد ما. حتى اختبار الإجهاد المنسق يستغرق بضعة أيام على الأقل للتواصل مع الدعم الفني ، وخلال الإجراءات "الخبيثة" الأولى نحصل على حظر المنفذ الذي خرجت منه حركة المرور ، والمطلوب أن يتم شرحه على الفور.
مخطوطات لشن هجمات
لإدارة الاختبار عن بُعد ، سنقوم بإعداد البرامج النصية للباش (dns.sh ، ping.sh ، http.sh) التي تطلق نوع الهجوم المطلوب ، والملفات ذات الحمولات النافعة (test_urls.txt ، valid_dns_queries.txt).
عندما نقوم بتحميل كل هذا على صورة AWS (التي سيتم إنشاء كل الحالات منها) ، يمكن تشغيل كل اختبار عن بُعد باستخدام أمر التنسيق التالي:
ssh instance-amazon 'sudo <stress-script>.sh start <params> &>>stress.log &'
يتم تحديد البرنامج النصي من النوع المطلوب كـ stress-script.sh ، والمعلمات هي المعلمات المقابلة. في ملف الإجهاد ، سنقوم بتتبع إخراج الأداة المساعدة قيد التشغيل. للراحة ، سوف نستخدم سجلات مختلفة للأدوات المساعدة المختلفة: dns.log ، ping.log ، http.log.
مثال dns.sh script:
كما يمكن رؤيته من الكود ، يمكن تشغيل البرنامج النصي وإيقافه ، بالإضافة إلى التحقق من الحالة (التشغيل / عدم التشغيل).
يتم إنشاء البرامج النصية لاختبارات ICMP و HTTP بنفس الطريقة ، بدءًا من hping3 والحصار ، على التوالي ، مع تمرير سلسلة المعلمات عبر الوسيطة.
أمثلة على الأوامر:
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 &'
رصد النصوص
لتقييم حركة المرور الصادرة وحالة البنية التحتية للاختبار ، نحتاج إلى أداة مراقبة. لأسباب تتعلق بالبساطة وتوفير الموارد ، نستخدم iptables. للقيام بذلك ، سنقوم بكتابة نص يحسب عدد ميغابايت المرسلة ، ووضعه على صورة 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
يقوم البرنامج النصي بإنشاء سلسلة TRAFFIC_OUT جديدة ويضيف إليها عوامل تصفية للبروتوكولات الضرورية: tcp و udp و icmp.
تتم إعادة توجيه الحزمة إلى TRAFFIC_OUT إلى سلسلة OUTPUT.
يمكن العثور على كمية البيانات المنقولة بواسطة الأمر:
# 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
تثبيت البرنامج النصي كخدمة. للقيام بذلك ، قم بإنشاء ملف monitoring.service /etc/systemd/system إلى الدليل /etc/systemd/system :
# /etc/systemd/system/monitoring.service [Unit] After=network.target [Service] ExecStart=/usr/local/bin/monitoring.sh [Install] WantedBy=default.target
الآن يمكنك إضافة الخدمة لبدء التشغيل:
systemctl enable monitoring.service systemctl start monitoring.service
إدارة المثيلات
الآن دعونا نتعامل مع إدارة المثيلات عن بعد (قدر الإمكان تلقائيًا).
لهذه الأغراض ، يمكنك استخدام آلية AWS CLI - إدارة وحدة التحكم.
إنشاء مفتاح سري (مفاتيح الوصول (معرف مفتاح الوصول ومفتاح الوصول السري)) وتكوين وحدة التحكم.
الآن لدينا إمكانية الوصول إلى جميع ميزات الحساب.
خصوصية العمل مع AWS هي أن جميع الإجراءات يتم تنفيذها لمنطقة معينة ويجب تكرارها في حالة وجود عدة مناطق.
لإنشاء مثيل جديد من الصورة التي بنيناها أعلاه (نفترض أن هناك معرفًا عموميًا نستخدمه في البرنامج النصي) ، سنفعل ما يلي:
- إنشاء مفتاح SSH وإضافته إلى 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
- إنشاء مجموعة أمان تسمح بالوصول إلى الجهاز عبر SSH. خلاف ذلك ، سيتم رفض اتصالات SSH الواردة:
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
- إنشاء مثيل باستخدام المفتاح ومجموعة الأمان التي تم إنشاؤها مسبقًا وتحديد معرف الصورة. يمكن أن يكون عدد الحالات التي تم إنشاؤها في وقت واحد عشوائيًا:
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
- انتظر حتى تتم تهيئة الجهاز. يستغرق هذا بعض الوقت: أولاً ، نحصل على استجابة نجاح (instances.json) ، ولكن في ذلك الوقت تم إنشاء الجهاز للتو ، ولكن لم يتم تشغيله بعد (على سبيل المثال ، لم يتم تعيين عنوان IP خاص به بعد). من الضروري انتظار اكتمال الإطلاق (عادة ما تكون دقيقة كافية لذلك).
ثم يمكنك الاتصال عبر SSH إذا كنا نعرف عنوان IP. فقط اطلب قائمة بالأجهزة التي تعمل حاليًا. من بين المعلمات الخاصة بنا نجد PublicDnsName أو PublicIpAddress.
aws ec2 describe-instances --region
بعد ذلك ، نقوم بتنفيذ أوامر SSH ، مع الإشارة إلى مفتاح SSH الذي تم إنشاؤه أعلاه:
ssh -I $KEYNAME -oStrictHostKeyChecking=no ubuntu''+ins_dns echo''O''
تسمح لك أوامر SSH بالتحكم في الهجوم والحصول على جميع المعلومات حول حالة الهجوم ، حيث قمنا بتزويد المثيلات بجميع النصوص والأدوات اللازمة.
يجب أن تفهم أن معظم الدفاعات ضد هجمات رفض الخدمة تحظر عنوان IP الذي تم استلام الكثير من الطلبات عليه بشكل غير طبيعي. لذلك ، يجب أن تتغير عناوين IP الخاصة بالأجهزة الافتراضية باستمرار من أجل الحفاظ على قوة الهجوم.
تقوم AWS بتعيين عنوان IP جديد في كل مرة يتم فيها تشغيل الجهاز. لذلك ، لتغيير IP ، تحتاج إلى إيقاف تشغيل الجهاز وتشغيله مرة أخرى (لا حاجة لإزالته!).
الفرق بين الإغلاق والحذف هو أننا نرسل إشارات مختلفة. إيقاف - لإيقاف ، إنهاء - لإيقاف وحذف على الفور.
من أجل مراقبة حركة المرور الواردة لمثيل ما ، نستخدم الأمر التالي بمعرف المثيل: عندما يبدأ قياس حركة المرور ، وعندما ينتهي ، لأي فترة يتم جمع القيم:
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
مراقبة توفر الخدمة
بالإضافة إلى ذلك ، للقيام بهجوم ، ستحتاج إلى ملاحظة ما إذا كانت الخدمة التي نختبرها حية.
نقوم بإنشاء وتشغيل البرنامج النصي "ping" الأبسط الذي يراقب توفر المنافذ المستهدفة (53 و 80 في حالتنا).
نموذج لشفرة Python التي تعمل على أتمتة التحقق من التوفر:
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
يتم تخزين المعلومات المستلمة في ملف سجل ، وبناءً عليه ، بناءً على نتائج الهجوم ، سيكون من الممكن إنشاء رسم بياني لتوفر الموارد.
أثناء الاختبار ، من الضروري التحقق باستمرار من سجل "ping" حتى لا تقتل المورد بالكامل ولا رجعة فيه. بمجرد ظهور تدهور كبير واستجابة الطلب تستغرق الكثير من الوقت ، يجب إيقاف الهجوم.
إذا كان التباطؤ ضئيلًا ، ووصلت قوة الهجوم إلى الحد الأقصى المحدد ، فمن المنطقي الانتظار لمدة دقيقة أو دقيقتين ، وإذا استمرت الخدمة في العمل دون انقطاع ، فسيعتبر الفحص ناجحًا.
القضية المالية
يجدر مناقشة مسألة أخرى متعلقة بتنظيم الاختبار - تكلفة هذا الحدث بأكمله.
توفر أمازون معلومات مفصلة عن الأسعار ، ولكن عليك أن تفهم أنه يتعين عليك الدفع مقابل كل شيء تقريبًا. ومع ذلك ، يمكن إهمال العديد من العمليات الحسابية. بادئ ذي بدء ، يجدر حساب تكلفة حركة المرور (يعتمد ذلك على المنطقة وعلى مقدار المبلغ الإجمالي الذي سيتم إرسال المعلومات) وتكلفة استئجار الحالات (الدفع في الدقيقة). هذه العناصر تشكل حوالي 99 ٪ من تكلفة الهجوم بأكمله.
لذلك ، يتم حساب تكلفة الهجوم في كل حالة على حدة ، اعتمادًا على [قوة الأعمال العدائية] القصوى للهجوم وعدد عمليات الإطلاق المخطط لها.
من وجهة نظر تبسيط العمليات الحسابية ، من الأفضل استخدام حساب Amazon ، الذي تم تسجيله منذ أكثر من عام. ثم جزء من العمليات ستكون حرة. اقرأ المزيد عن حدود الاستخدام المجاني هنا .
لتوضيح حساب تكلفة إجراء اختبار الحمل ، دعنا نقول إننا نريد التحقق من استقرار خادم DNS عند تحميل يبلغ 10 جيجابت / ثانية.
نحن نعلم أن الأدوات المستخدمة وقدرات مثيل t3.small التي تم إطلاقها في مومباي تسمح لك بإصدار 500 ميجابايت / ثانية من مثيل واحد قيد التشغيل. سعر استئجار كيان هو 0.0224 دولار في الساعة ، لحركة المرور - 0.01093 دولار لل 1 غيغابايت. وهذا يعني أن ذروة الهجوم تعني التشغيل المتزامن لـ 20 كيانًا.
سنزيد قوة الهجوم تدريجيًا ، لذلك سنطلق كيان واحد أولاً ، ثم نضيف كيانًا آخر كل 60 ثانية.
تأخذ صيغة حساب التكلفة النموذج:
60 * ( ) + 60 * 0,5 /c * ( ) = 60 . 1 * ( ) + 2 * ( ) + ... + 20 * ( ) =
اتضح أن تكلفة الهجوم الواحد بسعة 10 جيجابت / ثانية لخادم DNS تبلغ حوالي 70 دولارًا. لاحظ أن هذا تقدير تقريبي ، حيث لا يمكن التنبؤ بدقة بحجم حركة المرور. . , – , .
. .