DDoS للإنقاذ: كيف نجري اختبارات الضغط والحمل

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

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

تسجيل بالفيديو للتقرير

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

كيف نعمل

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

المسلمات

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

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

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

لا يجب أن يكون الرمز جيدًا فحسب ، بل يجب أن يكون ملف config
يعتقد الكثير من الناس أن فريق التطوير الجيد هو ضمان للتسامح مع أخطاء الخدمة. هناك حاجة فعلاً إلى فريق تطوير جيد ، ولكن يجب أن تكون هناك أيضًا عمليات جيدة و 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 ، وإعداد نقطة وصول خاصة ، وتشريح واجهة برمجة التطبيقات وتسجيل حسابات الاختبار. تكمن المشكلة في أن الأشخاص غالبًا ما يعتقدون أن كل شيء محمي بموجب التفويض ليس عرضة لهجمات رفض الخدمة. يُزعم أن التفويض هو أفضل اختبار 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 API أكثر صعوبة من موقع ويب عادي. بالنسبة إلى Rest API ، حتى الأساليب المبتذلة للحماية من القوة الغاشمة لكلمة المرور وغيرها من الأنشطة غير المشروعة لا تعمل.
من السهل جدًا كسر واجهة برمجة التطبيقات Rest لأنها تتحدث مباشرة إلى قاعدة البيانات. في الوقت نفسه ، يترتب على سحب هذه الخدمة عواقب وخيمة على الشركة. الحقيقة هي أن Rest API عادة ما تكون مرتبطة ليس فقط بالموقع الرئيسي ، ولكن أيضًا بتطبيق الهاتف المحمول ، وبعض موارد الأعمال الداخلية. وإذا سقط كل شيء ، فإن التأثير يكون أقوى بكثير مما هو عليه في حالة فشل موقع بسيط.

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

إذا عُرض علينا اختبار بعض التطبيقات العادية أحادية الصفحة ، أو الصفحة المقصودة ، أو موقع بطاقة العمل الذي لا يحتوي على وظائف معقدة ، فإننا نبحث عن محتوى ثقيل. على سبيل المثال ، الصور الكبيرة التي يقدمها الخادم ، والملفات الثنائية ، ووثائق 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 وحدة المعالجة المركزية بالكامل تقريبًا على الخادم ، ثم يتطور موقع الويب من طلب واحد أو طلبين في الثانية. وفقًا لذلك ، لا يمكن تمييز هذه الطلبات من السجلات عن التحميل الشرعي.
تظل ذات صلة والكثير من الاتصالات التي نفتحها في الخوادم. في السابق ، أخطأ أباتشي بهذا ، والآن يخطئ nginx في الواقع ، لأنه غالبًا ما يتم تكوينه افتراضيًا. عدد الاتصالات التي يمكن أن يبقيها nginx مفتوحًا محدود ، لذلك نفتح هذا العدد من الاتصالات ، ولم يعد nginx يقبل اتصالًا جديدًا ، والموقع لا يعمل عند الخروج.
تحتوي مجموعة الاختبار الخاصة بنا على وحدة معالجة مركزية كافية لمهاجمة مصافحة SSL. من حيث المبدأ ، كما تظهر الممارسة ، تحب الروبوتات أيضًا القيام بذلك في بعض الأحيان. من ناحية أخرى ، من الواضح أن SSL لا غنى عنه ، لأن إصدار Google ، الترتيب ، الأمان. من ناحية أخرى ، لدى SSL مشكلة في وحدة المعالجة المركزية للأسف.

المستوى 3 و 4

عندما نتحدث عن هجوم على مستويين L3 و 4 ، فإننا نتحدث عادة عن هجوم على مستوى القناة. يتم تمييز مثل هذا الحمل دائمًا تقريبًا عن الحمل الشرعي ، ما لم يكن هجومًا فيضان SYN. تكمن مشكلة هجمات الفيضانات SYN للدفاعات في الحجم الهائل. كانت القيمة القصوى لـ L3 & 4 هي 1,5-2 تيرا بايت في الثانية. من الصعب جدًا معالجة مثل هذه الزيارات حتى بالنسبة للشركات الكبيرة ، بما في ذلك Oracle و Google.
SYN و SYN-ACK عبارة عن حزم يتم استخدامها عند إنشاء اتصال. لذلك ، من الصعب التمييز بين فيضان SYN والحمل المشروع: ليس من الواضح ما إذا كان هذا هو SYN الذي جاء لإنشاء اتصال أو جزء من فيضان.

الفيضانات UDP

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

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

صعوبة فيضان SYN

من المحتمل أن يكون SYN-Flood هو أكثر أنواع الهجوم إثارة للاهتمام من وجهة نظر المطور. تكمن المشكلة في أن مسؤولي النظام غالبًا ما يستخدمون حظر IP للحماية. علاوة على ذلك ، لا يؤثر الحظر بواسطة IP على مسؤولي النظام الذين يتصرفون وفقًا للنصوص فحسب ، بل يؤثر ، للأسف ، على بعض أنظمة الحماية التي يتم شراؤها مقابل الكثير من المال.
يمكن أن تتحول هذه الطريقة إلى كارثة ، لأنه إذا قام المهاجمون بتغيير عناوين IP ، فستقوم الشركة بحظر شبكتها الفرعية. عندما يحظر جدار الحماية المجموعة الخاصة به ، ستنهار التفاعلات الخارجية نتيجة لذلك ، وينقطع المورد.
علاوة على ذلك ، فإن حظر الشبكة الخاصة بك أمر سهل. إذا كان لدى مكتب العميل شبكة WI-Fi ، أو إذا تم قياس أداء الموارد باستخدام شاشات مختلفة ، فإننا نأخذ عنوان IP لنظام المراقبة هذا أو عميل Wi-Fi للمكتب ، ونستخدمه كمصدر. عند الإخراج ، يبدو أن المورد متاح ، لكن عناوين IP المستهدفة محظورة. لذلك ، يمكن حظر شبكة Wi-Fi الخاصة بمؤتمر HighLoad ، حيث يتم تقديم منتج جديد للشركة - وهذا يستلزم بعض التكاليف التجارية والاقتصادية.
أثناء الاختبار ، لا يمكننا استخدام التضخيم عبر memcached بواسطة بعض الموارد الخارجية ، نظرًا لوجود اتفاقيات لتغذية حركة المرور فقط إلى عناوين IP المسموح بها. وفقًا لذلك ، نستخدم التضخيم من خلال SYN و SYN-ACK ، عندما يستجيب النظام لإرسال SYN واحد مع اثنين أو ثلاثة SYN-ACKs ، ويتم مضاعفة الهجوم مرتين أو ثلاث مرات عند الإخراج.

أدوات

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

النتائج

في الختام ، أود أن أقول:

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

المصدر: www.habr.com