DDoS للمساعدة: كيف نجري اختبارات الإجهاد والتوتر

تقوم شركة Variti بتطوير الحماية ضد هجمات البوتات و DDoS ، وتجري أيضًا اختبارات التحمل والتحميل. في مؤتمر HighLoad ++ 2018 ، تحدثنا عن كيفية تأمين الموارد من أنواع مختلفة من الهجمات. باختصار: عزل أجزاء من النظام ، واستخدام الخدمات السحابية و CDN وتحديثها بانتظام. ولكن من دون شركات متخصصة ، لا يزال بإمكانك الحماية :)

قبل قراءة النص ، يمكنك التعرف على ملخصات مختصرة على موقع المؤتمر .
وإذا كنت لا ترغب في قراءة مقطع فيديو أو ترغب في مشاهدته ، فسيتم تسجيل تقريرنا أدناه أسفل المفسد.


تعرف العديد من الشركات بالفعل كيفية إجراء اختبار الإجهاد ، ولكن ليس جميعها تقوم باختبار الإجهاد. يعتقد بعض عملائنا أن موقعهم معرض للخطر نظرًا لأن لديهم نظام تحميل عالي وأنه يحمي من الهجمات. نظهر أن هذا ليس صحيحا تماما.

بالطبع ، قبل إجراء الاختبارات ، نحصل على إذن من العميل ، موقّع ومختوم ، وبفضل مساعدتنا ، لا يمكننا القيام بهجوم على DDoS على أي شخص. يتم إجراء الاختبار في الوقت الذي يختاره العميل ، عندما يكون حضور مورده ضئيلًا ، ولن تؤثر مشاكل الوصول على العملاء. بالإضافة إلى ذلك ، نظرًا لوجود خطأ ما دائمًا أثناء عملية الاختبار ، لدينا اتصال مستمر مع العميل. هذا لا يسمح فقط بالإبلاغ عن النتائج المحققة ، ولكن أيضًا لتغيير شيء ما أثناء الاختبار. في نهاية الاختبار ، نضع دائمًا تقريرًا نوضح فيه العيوب المكتشفة ونقدم توصيات للتخلص من نقاط الضعف في الموقع.

كيف نعمل

أثناء الاختبار ، نحاكي الروبوتات. نظرًا لأننا نعمل مع عملاء غير موجودين في شبكاتنا ، من أجل منع انتهاء الاختبار في الدقيقة الأولى بسبب إطلاق الحدود أو الحماية ، فإننا نقوم بتحميل الحمل ليس من عنوان IP واحد ، ولكن من شبكتنا الفرعية الخاصة. بالإضافة إلى ذلك ، لإنشاء حمولة كبيرة ، لدينا خادم اختبار قوي إلى حد ما.

المسلمات

الكثير ليس جيد

كلما قل الحمل الذي يمكن أن نحققه المورد ، كان ذلك أفضل. إذا تمكنت من جعل الموقع يتوقف عن العمل من طلب واحد في الثانية ، أو حتى من طلب واحد في الدقيقة ، فهذا جيد. لأنه وفقًا لقانون المعنى ، يقع المستخدمون أو المهاجمون عن طريق الخطأ في هذه الثغرة الأمنية.

الفشل الجزئي أفضل من الفشل الكامل

نحن ننصح دائمًا بعمل أنظمة غير متجانسة. علاوة على ذلك ، فإن الأمر يستحق الفصل بينهما على المستوى المادي ، وليس فقط الحاوية. في حالة الفصل الفعلي ، حتى إذا فشل شيء ما على الموقع ، فمن المحتمل ألا يتوقف عن العمل بشكل كامل ، وسيظل بإمكان المستخدمين الوصول إلى جزء على الأقل من الوظيفة.

العمارة الصحيحة هي أساس الاستدامة

يجب وضع التسامح مع الخطأ للمورد وقدرته على الصمود أمام الهجمات والأحمال في مرحلة التصميم ، في الواقع ، في مرحلة رسم الرسوم البيانية للكتلة الأولى في دفتر ملاحظات. لأنه إذا كانت هناك أخطاء قاتلة تتسلل إليها ، فيمكنك تصحيحها في المستقبل ، لكن ذلك صعب للغاية.

ليس فقط يجب أن يكون رمز جيدة ، ولكن أيضا التكوين

يعتقد الكثير من الناس أن فريق التطوير الجيد هو ضمان لمرونة الخدمة. إن فريق التطوير الجيد ضروري حقًا ، ولكن يجب أن يكون هناك أيضًا تشغيل جيد ، DevOps جيد. أي أننا بحاجة إلى متخصصين يقومون بتكوين Linux والشبكة بشكل صحيح ، وكتابة التكوينات بشكل صحيح في nginx ، وتهيئة الحدود والمزيد. خلاف ذلك ، فإن المورد سوف يعمل بشكل جيد فقط في الاختبار ، وفي الإنتاج في مرحلة ما سوف ينكسر كل شيء.

الاختلافات بين الإجهاد واختبار الإجهاد

اختبار الحمل يسمح لك لتحديد حدود النظام. يهدف اختبار الإجهاد إلى العثور على نقاط الضعف في النظام ويستخدم لكسر هذا النظام ومعرفة كيف سيتصرف في عملية فشل أجزاء معينة. في الوقت نفسه ، تظل طبيعة الحمل غير معروفة للعميل حتى بدء اختبار الإجهاد.

السمات المميزة لهجمات L7

عادة ما نقسم أنواع الحمل إلى حمولات على مستوى L7 و L3 و 4. L7 عبارة عن تحميل على مستوى التطبيق ، وغالبًا ما يتم فهمه فقط على أنه HTTP ، لكننا نعني أي تحميل على مستوى بروتوكول TCP.

هجمات L7 لها بعض السمات المميزة. أولاً ، يتم تقديمهم مباشرة إلى التطبيق ، أي أنه من غير المحتمل أن تنعكس هذه الكلمات من خلال وسائل الشبكة. هذه الهجمات تستخدم المنطق ، وبسبب هذا تستهلك وحدة المعالجة المركزية والذاكرة والقرص وقاعدة البيانات وغيرها من الموارد بكفاءة عالية مع القليل من حركة المرور.

الفيضان HTTP

في حالة حدوث أي هجوم ، يكون التحميل أسهل من المعالجة ، وفي حالة L7 يكون هذا صحيحًا أيضًا. ليس من السهل دائمًا التمييز بين حركة المرور والهجمات الشرعية ، وغالبًا ما يتم ذلك حسب التكرار ، ولكن إذا تم التخطيط لكل شيء بشكل صحيح ، فمن المستحيل فهم موقع الهجوم وأين تأتي الطلبات المشروعة من السجلات.

كمثال أول ، فكر في هجوم HTTP Flood. يوضح الرسم البياني أن مثل هذه الهجمات عادة ما تكون قوية للغاية ، في المثال أدناه ، تجاوز عدد طلبات الذروة 600 ألف في الدقيقة.



HTTP Flood هي أسهل طريقة لإنشاء تحميل. عادة ، يتم استخدام نوع من أداة اختبار التحميل لذلك ، على سبيل المثال ، ApacheBench ، ويتم تعيين الطلب والغرض. مع هذه الطريقة البسيطة ، من المحتمل أن يتم تشغيلها في ذاكرة التخزين المؤقت للخادم ، ولكن من السهل الالتفاف عليها. على سبيل المثال ، إضافة خطوط عشوائية إلى الاستعلام ، مما يفرض على الخادم إعطاء صفحة جديدة باستمرار.
أيضا ، لا تنسى وكيل المستخدم في عملية إنشاء تحميل. يتم تصفية العديد من عملاء أدوات الاختبار الشائعة بواسطة مسؤولي النظام ، وفي هذه الحالة ، قد لا يصل الحمل ببساطة إلى الواجهة الخلفية. يمكنك تحسين النتيجة بشكل كبير عن طريق إدخال رأس صالح أكثر أو أقل من المتصفح في الطلب.
على الرغم من بساطته ، فإن هجمات HTTP Flood لها عيوبها. أولاً ، هناك حاجة إلى قدرات كبيرة لإنشاء تحميل. ثانياً ، من السهل جدًا اكتشاف مثل هذه الهجمات ، خاصة إذا كانت من نفس العنوان. ونتيجة لذلك ، تبدأ الطلبات فورًا في التصفية إما عن طريق مسؤولي النظام ، أو حتى على مستوى الموفر.

ما الذي تبحث عنه

لتقليل عدد الطلبات في الثانية الواحدة مع عدم فقد الكفاءة ، تحتاج إلى إظهار القليل من الخيال واستكشاف الموقع. لذلك ، لا يمكنك فقط تحميل القناة أو الخادم ، ولكن أيضًا الأجزاء الفردية من التطبيق ، على سبيل المثال ، قواعد البيانات أو أنظمة الملفات. يمكنك أيضًا البحث عن أماكن على الموقع تقوم بإجراء حسابات رائعة: الآلات الحاسبة وصفحات اختيار المنتج والمزيد. أخيرًا ، يحدث غالبًا أن هناك برنامج نصي php على الموقع يقوم بإنشاء صفحة تحتوي على مئات الآلاف من الأسطر. يقوم هذا البرنامج النصي أيضًا بتحميل الخادم بشكل كبير ويمكن أن يصبح هدفًا للهجوم.

أن ننظر فيها

عندما نقوم بمسح مورد قبل الاختبار ، فإننا أولاً ننظر أولاً إلى الموقع نفسه. نحن نبحث عن جميع أنواع حقول الإدخال والملفات الثقيلة - بشكل عام ، كل ما يمكن أن يخلق مشاكل لمورد ويبطئ تشغيله. هنا ، تساعد أدوات التطوير الشائعة في Google Chrome و Firefox في إظهار وقت استجابة الصفحة.

نحن أيضا تفحص المجالات الفرعية. على سبيل المثال ، هناك متجر إلكتروني معين ، abc.com ، ويحتوي على نطاق فرعي admin.abc.com. على الأرجح ، هذه هي لوحة المشرف بترخيص ، ولكن إذا وضعت عبءًا عليها ، فبإمكانها إنشاء مشاكل للمورد الرئيسي.

قد يحتوي الموقع على نطاق فرعي api.abc.com. على الأرجح ، هذا مورد للتطبيقات المحمولة. يمكن العثور على التطبيق في App Store أو Google Play ، ووضع نقطة وصول خاصة ، وتشريح API وتسجيل حسابات الاختبار. المشكلة هي أن الناس يعتقدون غالبًا أن كل شيء محمي بموجب ترخيص محصن ضد هجمات الحرمان من الخدمة. يزعم ، إذن هو أفضل اختبار CAPTCHA ، لكنه ليس كذلك. إجراء 10-20 حسابات اختبار بسيط ، ومن خلال إنشائها ، يمكننا الوصول إلى وظائف معقدة وغير مخفية.

بطبيعة الحال ، نحن ننظر إلى التاريخ ، في ملف robots.txt و WebArchive و ViewDNS ، نحن نبحث عن إصدارات قديمة من المورد. يحدث أحيانًا أن المطورين قد نشروا ، على سبيل المثال ، mail2.yandex.net ، ولكن الإصدار القديم ، mail.yandex.net ، ظل موجودًا. لم يعد البريد mail.yandex.net مدعومًا ، ولم يتم تخصيص موارد التطوير له ، لكنه لا يزال يستهلك قاعدة البيانات. وفقًا لذلك ، باستخدام الإصدار القديم ، يمكنك استخدام موارد الخلفية بشكل فعال وكل ما هو خلف التخطيط. بالطبع ، هذا لا يحدث دائمًا ، لكننا لا نزال نواجه شيئًا كهذا في كثير من الأحيان.

وبطبيعة الحال ، نقوم بتشريح جميع معلمات الطلب ، وهيكل ملفات تعريف الارتباط. يمكنك ، على سبيل المثال ، دفع بعض القيمة في صفيف JSON داخل ملف تعريف الارتباط ، وإنشاء تداخل أكثر وجعل المورد يعمل لفترة طويلة بشكل غير معقول.

تحميل البحث

أول ما يتبادر إلى الذهن عند البحث في موقع ما هو تحميل قاعدة البيانات ، نظرًا لأن كل شخص لديه عملية بحث تقريبًا ، وكل شخص لديه تقريبا ، لسوء الحظ ، يتمتع بحماية سيئة. لسبب ما ، لا يهتم المطورون بالبحث الكافي. ولكن هناك توصية واحدة - لا تقدم نفس النوع من الطلبات ، لأنك قد تواجه التخزين المؤقت ، كما هو الحال مع فيضان HTTP.

كما أن إجراء استعلامات عشوائية في قاعدة البيانات غير فعال دائمًا. من الأفضل بكثير إنشاء قائمة بالكلمات الرئيسية ذات الصلة بالبحث. إذا عدت إلى مثال متجر على الإنترنت: دعنا نقول أن الموقع يبيع إطارات السيارات ويسمح لك بتعيين نصف قطر الإطارات ونوع السيارة وغيرها من المعالم. وفقًا لذلك ، فإن مجموعات الكلمات ذات الصلة ستجعل قاعدة البيانات تعمل في ظروف أكثر تعقيدًا.

بالإضافة إلى ذلك ، يجدر استخدام ترقيم الصفحات: من الصعب جدًا أن يُرجع البحث لإرجاع الصفحة قبل الأخيرة للمشكلة أكثر من الأولى. وهذا هو ، بمساعدة ترقيم الصفحات ، يمكنك تنويع الحمل قليلا.

في المثال أدناه ، نعرض الحمل في البحث. يمكن أن نرى أنه من الثانية الأولى من الاختبار بسرعة عشر طلبات في الثانية ، انخفض الموقع ولم يستجب.

إذا لم يكن هناك بحث؟

إذا لم يكن هناك بحث ، فإن هذا لا يعني أن الموقع لا يحتوي على حقول الإدخال الضعيفة الأخرى. قد يكون هذا الحقل إذنًا. الآن يرغب المطورون في إنشاء تجزئات معقدة لحماية قاعدة بيانات تسجيل الدخول من الهجمات على جداول قوس قزح. هذا جيد ، لكن هذه التجزئة تستهلك موارد وحدة المعالجة المركزية الكبيرة. يؤدي التدفق الكبير من التراخيص الخاطئة إلى فشل المعالج ، ونتيجة لذلك ، يتوقف الموقع عن العمل على الإخراج.

يعد وجود جميع أنواع النماذج للتعليقات والتعليقات على الموقع مناسبة لإرسال نصوص كبيرة جدًا أو لإنشاء فيضان هائل. في بعض الأحيان تقبل المواقع مرفقات الملفات ، بما في ذلك بتنسيق gzip. في هذه الحالة ، نأخذ ملفًا بسعة 1 تيرابايت ، باستخدام gzip نقوم بضغطه على بضع بايت أو كيلوبايت وإرساله إلى الموقع. ثم يتم فك ضغطها ويتم الحصول على تأثير مثير للاهتمام للغاية.

بقية API

أود أن أبدي القليل من الاهتمام للخدمات الشائعة مثل Rest API. تعد حماية واجهة برمجة تطبيقات Rest Rest أكثر صعوبة من الموقع العادي. بالنسبة لـ Rest API ، حتى الطرق التافهة للحماية من تكسير كلمة المرور والنشاطات غير المشروعة الأخرى لا تعمل.

من السهل جدا كسر واجهة برمجة تطبيقات API لأنها تصل إلى قاعدة البيانات مباشرة. في الوقت نفسه ، ينطوي فشل مثل هذه الخدمة على عواقب وخيمة للغاية على الأعمال. الحقيقة هي أن واجهة برمجة تطبيقات Rest عادةً لا تتضمن فقط الموقع الرئيسي ، ولكن أيضًا تطبيق الهاتف المحمول ، وبعض موارد الأعمال الداخلية. وإذا وقع كل هذا ، فسيكون التأثير أقوى بكثير في حالة فشل موقع بسيط.

تحميل المحتوى الثقيل

إذا عرض علينا اختبار بعض التطبيقات العادية المكونة من صفحة واحدة والصفحة المقصودة وموقع بطاقة العمل على الويب ، والتي لا تحتوي على وظائف معقدة ، فإننا نبحث عن محتوى ثقيل. على سبيل المثال ، الصور الكبيرة التي يقدمها الخادم والملفات الثنائية وتوثيق ملفات pdf - نحاول ضخها بالكامل. مثل هذه الاختبارات تحميل نظام الملفات بشكل جيد وقنوات تسد ، وبالتالي فهي فعالة. أي أنه حتى إذا لم تقم بإيقاف تشغيل الخادم وتنزيل ملف كبير بسرعات منخفضة ، فسوف تقوم ببساطة بسد قناة الخادم الهدف ومن ثم سيحدث رفض الخدمة.
يوضح مثال على هذا الاختبار أنه عند سرعة 30 RPS توقف الموقع عن الاستجابة أو أنشأ 500 خطأ في الخادم.



لا تنس إعداد الخوادم. يمكنك أن تجد في كثير من الأحيان أن شخصًا اشترى جهازًا افتراضيًا ، وقام بتثبيت Apache هناك ، وتكوين كل شيء افتراضيًا ، وتحديد موقع تطبيق php ، ويمكنك أدناه رؤية النتيجة.



هنا ذهب الحمل إلى الجذر وبلغ 10 RPS فقط. انتظرنا 5 دقائق وتعطل الخادم. لكن حتى النهاية ، لا يُعرف سبب سقوطه ، ولكن هناك افتراضًا أنه ببساطة كان ممتلئًا بالذاكرة ، وبالتالي توقف عن الاستجابة.

موجة مقرها

في العام الماضي أو العامين الماضيين ، أصبحت هجمات الأمواج شائعة للغاية. ويرجع ذلك إلى حقيقة أن العديد من المؤسسات تشتري قطعًا معينة من الأجهزة للحماية من DDoS ، والتي تتطلب قدرًا معينًا من الإحصاءات لبدء تصفية الهجمات. أي أنهم لا يقومون بتصفية الهجوم في أول 30 إلى 40 ثانية ، لأنهم يجمعون البيانات ويتعلمون. وفقًا لذلك ، في هذه الفترة من 30 إلى 40 ثانية ، يمكنك تشغيل الكثير بحيث يظل المورد لفترة طويلة حتى يتم هز جميع الطلبات.

في حالة الهجوم ، كان هناك فاصل زمني مدته 10 دقائق ، وبعد ذلك وصل جزء جديد معدّل من الهجوم.



بمعنى أن الدفاع المدربين بدأ في التصفية ، لكن وصل جزء جديد مختلف تمامًا من الهجوم ، وبدأ الدفاع في التدريب مرة أخرى. في الواقع ، يتوقف التصفية عن العمل ، وتصبح الحماية غير فعالة ، ولا يمكن الوصول إلى الموقع.

تتميز الهجمات الموجية بقيم عالية جدًا في الذروة ، ويمكن أن تصل إلى مائة ألف أو مليون طلب في الثانية ، في حالة L7. إذا تحدثنا عن L3 و 4 ، فيمكن أن يكون هناك مئات غيغا بايت من حركة المرور ، أو بناءً على ذلك ، مئات من mpps ، إذا عدت في حزم.

المشكلة في مثل هذه الهجمات هي المزامنة. الهجمات تأتي من الروبوتات ، ومن أجل خلق ذروة كبيرة لمرة واحدة ، هناك حاجة إلى درجة عالية من التزامن. وهذا التنسيق لا يعمل دائمًا: في بعض الأحيان يكون الإخراج نوعًا من ذروة مكافئ ، والذي يبدو مثيرًا للشفقة.

ليس HTTP الموحدة

بالإضافة إلى HTTP على مستوى L7 ، نحن نحب استغلال البروتوكولات الأخرى. كقاعدة عامة ، يحتوي موقع الويب المعتاد ، وخاصة الاستضافة العادية ، على بروتوكولات البريد و MySQL. بروتوكولات البريد أقل تأثراً من قواعد البيانات ، ولكن يمكن أيضًا تحميلها بكفاءة عالية والحصول على وحدة المعالجة المركزية الزائدة على الخادم عند الإخراج.

بمساعدة مشكلة ضعف SSH لعام 2016 ، حققنا نجاحًا كبيرًا. الآن تم إصلاح مشكلة عدم الحصانة هذه تقريبًا للجميع ، ولكن هذا لا يعني أنه لا يمكن تحميل SSH. يمكنك ذلك. يتم تقديم حمولة ضخمة من التراخيص ، SSH يستوعب وحدة المعالجة المركزية بأكملها تقريبًا على الخادم ، ومن ثم يتألف موقع الويب بالفعل من طلب واحد أو اثنين في الثانية.

وفقًا لذلك ، لا يمكن تمييز استعلامات السجل هذه أو اثنين من تحميل شرعي.
تظل العديد من الاتصالات التي نفتحها في الخوادم ذات صلة. في السابق ، أخطأ Apache ، أخطأ nginx الآن فعليًا ، لأنه غالبًا ما يتم تكوينه افتراضيًا. عدد الاتصالات التي يمكن لـ nginx إبقائها مفتوحة محدود ، لذلك نحن نفتح هذا العدد من الاتصالات ، ولم يعد اتصال nginx الجديد يقبل ، ولا يعمل الموقع على الإخراج.

تحتوي مجموعة الاختبار على وحدة المعالجة المركزية الكافية لمهاجمة مصافحة طبقة المقابس الآمنة. من حيث المبدأ ، كما تبين الممارسة ، فإن الشبكات الروبوتية تحب أيضًا القيام بذلك في بعض الأحيان. فمن ناحية ، من الواضح أنه لا يمكنك الاستغناء عن طبقة المقابس الآمنة ، لأن إصدار Google وترتيبها وأمانها. SSL ، من ناحية أخرى ، للأسف لديه مشكلة وحدة المعالجة المركزية.

L3 و 4

عندما نتحدث عن هجوم على مستويي L3 و 4 ، عادة ما نتحدث عن هجوم على مستوى القناة. مثل هذا الحمل يمكن تمييزه دائمًا عن كونه شرعيًا إذا لم يكن هجومًا بالفيضانات SYN. مشكلة هجمات الفيضان SYN لميزات الأمان كبيرة. وكانت القيمة القصوى لل L3 و 4 1.5-2 تيرابايت / ثانية. من الصعب للغاية التعامل مع هذه الحركة حتى بالنسبة للشركات الكبيرة ، بما في ذلك Oracle و Google.

SYN و SYN-ACK هما الحزمتان المستخدمتان لتأسيس الاتصال. لذلك ، من الصعب التمييز بين SYN-flood وعبء مشروع: ليس من الواضح أن هذا SYN ، الذي جاء لتأسيس الاتصال ، أو جزء من الفيضان.

الفيضانات UDP

عادة ، لا يملك المهاجمون القدرات التي لدينا ، لذلك يمكن استخدام التضخيم لتنظيم الهجمات. أي أن المهاجم يفحص الإنترنت ويجد الخوادم الضعيفة أو التي تمت تهيئتها بشكل غير صحيح ، والتي ، على سبيل المثال ، استجابة لحزمة SYN واحدة ، تستجيب بثلاثة SYN-ACK. بتزوير عنوان المصدر من عنوان الخادم الهدف ، يمكنك استخدام حزمة واحدة لزيادة السعة ، على سبيل المثال ، ثلاث مرات ، وإعادة توجيه حركة المرور إلى الضحية.



المشكلة مع التضخيم هو الكشف المعقدة. من أحدث الأمثلة يمكننا أن نذكر الحالة المثيرة مع الضعفاء. بالإضافة إلى ذلك ، يوجد الآن العديد من أجهزة إنترنت الأشياء ، وكاميرات IP ، والتي يتم أيضًا تكوينها بشكل افتراضي في الغالب ، ويتم تكوينها بشكل غير صحيح بشكل افتراضي ، وبالتالي ، من خلال هذه الأجهزة ، يقوم المهاجمون في الغالب بشن هجمات.

من الصعب SYN الفيضانات

SYN- الفيضانات هي على الأرجح وجهة النظر الأكثر إثارة للاهتمام لجميع الهجمات من وجهة نظر المطور. المشكلة هي أنه في كثير من الأحيان يستخدم مسؤولو النظام حظر IP للحماية. علاوة على ذلك ، لا يؤثر حظر IP على مسؤولي النظام فقط التي تعمل وفقًا للنصوص البرمجية ، ولكن للأسف ، بعض أنظمة الأمان التي يتم شراؤها مقابل الكثير من المال.

يمكن أن تتحول هذه الطريقة إلى كارثة ، لأنه إذا قام المهاجمون بتغيير عناوين IP الخاصة بهم ، فستقوم الشركة بحظر شبكتها الفرعية الخاصة. عندما يقوم جدار الحماية بحظر الكتلة الخاصة به ، سوف تتعطل التفاعلات الخارجية عند الإخراج ، وسيتم قطع المورد.

وتحقيق حجب الشبكة الخاصة بك أمر سهل. إذا كان لدى مكتب العميل شبكة Wi-Fi ، أو إذا تم قياس صحة الموارد باستخدام المراقبة المختلفة ، فإننا نأخذ عنوان IP لنظام المراقبة أو عميل Wi-Fi الخاص بالمكتب ، ونستخدمه كمصدر. في الإخراج ، يبدو أن المورد متاح ، لكن عناوين IP المستهدفة محظورة. لذلك ، يمكن حظر شبكة Wi-Fi الخاصة بمؤتمر HighLoad ، حيث يتم تقديم منتج جديد للشركة ، وهذا يستلزم تكاليف تجارية واقتصادية معينة.

أثناء الاختبار ، لا يمكننا استخدام التضخيم من خلال حفظها بواسطة بعض الموارد الخارجية ، لأن هناك اتفاقات لتوفير حركة المرور فقط لعناوين IP المسموح بها. وفقًا لذلك ، نستخدم التضخيم من خلال SYN و SYN-ACK ، عندما يستجيب النظام بإرسال اثنين أو ثلاثة من SYN-ACK لإرسال SYN واحد ، ويتم ضرب الناتج مرتين إلى ثلاث مرات.

الأدوات

واحدة من الأدوات الرئيسية التي نستخدمها للتحميل على مستوى L7 هي Yandex-tank. على وجه الخصوص ، يتم استخدام الوهمية كسلاح ، بالإضافة إلى أن هناك العديد من البرامج النصية لتوليد خراطيش ولتحليل النتائج.

يستخدم Tcpdump لتحليل حركة مرور الشبكة ، ويتم استخدام Nmap لتحليل حركة مرور الخادم. لإنشاء حمل على مستوى L3 و 4 ، يتم استخدام OpenSSL وقليلًا من سحره الخاص مع مكتبة DPDK. DPDK هي مكتبة من Intel تتيح لك العمل مع واجهة الشبكة ، متجاوزة مكدس Linux ، وبالتالي تزيد من الكفاءة. بطبيعة الحال ، نحن نستخدم DPDK ليس فقط على مستوى L3 و 4 ، ولكن أيضًا على مستوى L7 ، لأنه يسمح لك بإنشاء تدفق حمل مرتفع للغاية ، في غضون بضعة ملايين طلب في الثانية من جهاز واحد.
نستخدم أيضًا بعض المولدات المرورية والأدوات الخاصة التي نكتبها لاختبارات محددة. إذا استذكرنا مشكلة عدم الحصانة ضمن SSH ، فمع المجموعة أعلاه ، لا يمكن الهروب منها. إذا هاجمنا بروتوكول البريد ، فسنأخذ أدوات مساعدة للبريد أو نكتب نصوص عليها.

النتائج

نتيجة لذلك ، أود أن أقول:

• بالإضافة إلى اختبار الحمل الكلاسيكي ، يجب أيضًا إجراء اختبار الإجهاد. لدينا مثال في العالم الحقيقي حيث أجرى مقاول من الباطن شريك اختبار الحمل فقط. أظهر أن المورد يتحمل الحمل القياسي. ولكن بعد ذلك ظهرت حمولة غير طبيعية ، بدأ زوار الموقع في استخدام المورد بشكل مختلف قليلاً ، وعند الإخراج وضع المقاول من الباطن. وبالتالي ، يجدر البحث عن الثغرات الأمنية حتى إذا كنت محميًا بالفعل من هجمات DDoS.
• من الضروري عزل بعض أجزاء النظام عن الأجزاء الأخرى. , , . , - . - , , , , OAuth2.
• .
• CDN , .
• . L3&4 , , , . L7 , . , - , .
• . , SSH daemon, . , , .