حماية DDoS (الطبقة 7) في التطبيق

ينطبق على: ✔️ Application Gateway V2 ✔️ Front Door Premium

يتضمن Azure Web Application Firewall (WAF) عدة آليات دفاع تساعد في منع هجمات حجب الخدمة الموزعة (DDoS). يمكن لهجمات DDoS استهداف كل من طبقة الشبكة (L3/L4) وطبقة التطبيق (L7). Azure DDoS Protection تحميك من هجمات الكتلة الكبيرة في طبقة الشبكة. يعمل Azure WAF في الطبقة 7، ويحمي تطبيقات الويب من هجمات DDoS في L7 مثل فيضانات HTTP. معا، تمنع هذه الدفاعات المهاجمين من الوصول إلى تطبيقك والتأثير على توفره وأدائه.

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

اختر طبقات الدفاع الخاصة بك

استخدم النموذج التالي عند التخطيط لحماية L7 DDoS. كل طبقة تلتقط حركة المرور التي لا تفعل الطبقة فوقها.

الطبقة ماذا تفعل مكان تكوينه
حماية DDoS على المنصة يمتص هجمات L3/L4 الحجمية على Azure edge وعلى عناوين IP العامة الأصلية الخاصة بك مدمجة افتراضيا على الواجهة الأمامية لـ Azure؛ تتطلب حماية شبكة Azure DDoS لعناوين IP العامة في Application Gateway وعناوين IP العامة الأصلية
التخفيف الآلي من L7 يتعلم حركة المرور العادية ويقلل من دواسة الوقود التي تسبب مشاكل في العملاء أثناء الارتفاع، دون ضبط طارئ HTTP DDoS ruleset (preview) on الواجهة الأمامية لـ Azure Premium and Application Gateway WAF v2
التحقق من العميل يفصل البشر والعملاء الشرعيين عن حركة الهجوم الآلية قبل الحظر مجموعة قواعد مدير البوت، تحدي جافاسكريبت، CAPTCHA
تحديد السعر تحديد عدد الطلبات التي يمكن لأي عميل أو جغرافيا أو نقطة نهاية إرسالها قواعد تحديد السعر المخصصة على الباب الأمامي وبوابة التطبيق
قواعد مخصصة مستهدفة يحجب توقيع هجوم معروف أثناء الحادث مطابقة القواعد المخصصة (الجغرافيا، عنوان IP، ASN، بصمة العميل، الرأس، URI)
حماية الأصل يمنع حركة الهجوم من الوصول إلى حساباتك على الإطلاق التخزين المؤقت، تثبيت المنشأ، القياس التلقائي

قائمة التحقق لتكوين القاعدة

أكمل هذه الخطوات قبل أن تتعرض لهجوم. قم بتعديلها لتناسب متطلبات طلبك.

  1. Deploy Azure WAF with الواجهة الأمامية لـ Azure Premium أو Application Gateway WAF v2 لحماية من هجمات طبقة التطبيقات L7.
  2. حول سياسة WAF إلى وضع الوقاية. سياسة في وضع الكشف تسجل فقط ولا تحظر حركة المرور. تحقق من السياسة ضد حركة المرور الإنتاجية وضبطها أولا لتقليل الإيجابيات الكاذبة، ثم فعل الوقاية منها.
  3. قم بتعيين مجموعة قواعد HTTP DDoS (المتوفرة على كل من الواجهة الأمامية لـ Azure Premium و Application Gateway WAF v2) بحيث يكون التخفيف التلقائي هو تعلم خط حركة المرور الأساسي قبل أن تحتاجه.
  4. تمكين مجموعة قواعد مدير البوتات لتحديد والتعامل مع الروبوتات السيئة المعروفة.
  5. قم بتكوين قاعدة حد معدل شاملة واحدة على الأقل (انظر تحديد المعدل).
  6. قم بتوسيع عدد العينات الأصلية لديك بحيث يكون هناك سعة فائضة كافية، واضبط Application Gateway على التدرج التلقائي دون فرض حد أقصى منخفض لعدد المثلات.
  7. فعل التخزين المؤقت على الواجهة الأمامية لـ Azure بحيث يتم امتصاص حركة المرور الذروة المفاجئة عند الحافة بدلا من نقطة البداية لديك.
  8. غط تعرضك للمستوى L3/L4، والذي يختلف حسب المنصة. انظر حماية DDoS على المنصة تختلف حسب المنصة. قم بتثبيت منشأك بحيث يقبل حركة المرور فقط من الواجهة الأمامية لـ Azure أو Application Gateway.
  9. قم بتفعيل تسجيل التشخيص إلى Log Analytics، وابن الاستعلامات في Analyze WAF والوصول إلى السجلاتقبل وقوع حادث.

تختلف حماية DDoS على المنصة لأخرى

دفاعات L7 لا تهم إلا إذا نجت عناوين IP العامة الأساسية من هجوم حجمي، ولم تبدأ منصتا Azure WAF من نفس المكان.

الواجهة الأمامية لـ Azure لديه حماية DDoS على المنصة بشكل افتراضي. الواجهة الأمامية لـ Azure هي خدمة حافة موزعة عالميا، وحافتها محمية بحماية DDoS من بنية Azure التحتية دون أي تكلفة إضافية وبدون تكوين. تنتهي حركة المرور عند حافة الباب الأمامي بدلا من عنوان IP الذي تملكه، لذلك لا يوجد عنوان IP عام لك يمكن للمهاجم استهدافه عند L3/L4. هذه الحماية متأصلة في المنصة، لذلك لا تشتري أو تفعل أي شيء للحصول عليها.

Application Gateway يحتاج إلى حماية شبكة Azure DDoS. بوابة التطبيق هي مورد إقليمي له عنوان IP عام في شبكتك الافتراضية الخاصة. حماية Azure الافتراضية على مستوى البنية التحتية تحمي منصة Azure نفسها، لكنها لا تمنحك تعديلا أو تخفيفا لكل مورد أو تقارير عن بعد أو تقارير هجوم لذلك العنوان. لحماية عنوان IP العام للبوابة من هجمات الوسائط L3/L4، قم بتمكين حماية شبكة Azure DDoS على الشبكة الافتراضية التي تحتويها. هذه خدمة مدفوعة وتم شراؤها بشكل منفصل.

العواقب العملية عند اختيار أو تصميم النشر:

  • إذا كنت خلف الواجهة الأمامية لـ Azure، خصص ميزانية لعناصر التحكم في L7؛ حماية الحواف في L3/L4 موجودة بالفعل.
  • إذا كنت تستخدم Application Gateway ولم تقم بتفعيل حماية شبكة DDoS، يمكن ضبط قواعد WAF الخاصة بك بشكل مثالي ولا تزال تتجاوزها هجوم حجمي على عنوان IP العام للبوابة. فعلها.
  • في كلتا الحالتين، عناوين IP العامة الأصلية التي تكشفها لا تزال تحتاج إلى حماية شبكة Azure DDoS، بالإضافة إلى القفل بحيث لا يمكن الوصول إليها إلا من خدمة WAF. واجهة أمامية محمية أمام مصدر غير محمي ومتاح للجمهور غير محمية.

لمزيد من المعلومات، راجع نظرة عامة على حماية Azure DDoSوحماية بوابة تطبيقك باستخدام حماية شبكة Azure DDoS.

الحماية التلقائية باستخدام مجموعة قواعد DDoS الخاصة ب HTTP (المعاينة)

التحكم الثابت مثل فلاتر IP، والمرشحات الجغرافية، وحدود المعدل الثابت غالبا لا تستطيع مواكبة شبكات البوت نت الموزعة: العتبات هي تخمينات، وهي دائما مفعلة، ويجب عليك إعادة ضبطها مع تطور أنماط المرور. مجموعة قواعد HTTP DDoS هي أول نموذج حماية تلقائي للطبقة السابعة من Azure WAF يتعلم ويكتشف ويدافع عنه مع تكوين مستخدم بسيط. يتوفر في نسخة Preview على كل من الواجهة الأمامية لـ Azure Premium و Application Gateway WAF v2. بمجرد تعيينها، تقوم بتحديد حركة المرور العادية باستمرار، وعندما تشير الموجات إلى هجوم، تحظر العملاء المخالفين بشكل انتقائي دون الحاجة إلى ضبط طارئ.

التصميم متشابه على كلا المنصتين من حيث الجوانب الأكثر أهمية:

  • عتبات معا. تتعلم مجموعة القواعد كلا من العتبة العالمية (لكل ملف تعريف من Front Door، أو لكل بوابة تطبيق) وعتبات فردية قائمة على عناوين IP. يتم تطبيق العتبات القائمة على الملكية الفكرية فقط بعد تجاوز العتبة العالمية. هذا التصميم يمنع مجموعة القواعد من العمل على الارتفاعات المفاجئة من بعض عناوين IP ما لم تدفع حركة المرور الكلية إلى ما هو أبعد من المعدل الطبيعي.
  • حسب الموارد. يتم تعلم العتبات على مستوى الموارد العالمية. إذا قمت بتعيين سياسة WAF واحدة مع مجموعة القواعد لعدة ملفات تعريف أمامية أو عدة بوابات، تقوم الخدمة بحساب العتبات بشكل منفصل لكل واحدة.
  • الحساسية. كل قاعدة تقدم ثلاثة مستويات حساسية. الحساسية الأعلى تطبق عتبة أقل؛ الحساسية الأقل تطبق عتبة أعلى. الإعداد المتوسط هو الإعداد الافتراضي والموصى به.
  • أمر التقييم. يقوم WAF بتقييم مجموعة قواعد DDoS الخاصة ب HTTP أولا، حتى قبل القواعد المخصصة. القاعدة المخصصة التي تحتوي على إجراء السماح تتجاوز جميع فحوصات WAF الأخرى، لكنها لا تتجاوز مجموعة قواعد DDoS الخاصة ب HTTP.
  • تجاوز مجموعة القواعد لحركة المرور الموثوقة. القاعدة المخصصة التي تحتوي على إجراء السماح لا تساعد هنا - فهي تتجاوز كل مجموعة قواعد أخرى لكن ليس مجموعة قواعد DDoS الخاصة ب HTTP. استخدم استثناءات WAF بدلا من ذلك، والتي يمكنك نطاقها لقاعدة محددة، أو مجموعة قواعد، أو مجموعة قواعد مدارة كاملة، بما في ذلك مجموعة قواعد DDoS الخاصة ب HTTP. انظر حركة المرور المعفاة الموثوقة مع الاستثناءات.
  • يتطلب حركة مرور مستمرة. يمكن لمجموعة القواعد أن تعمل فقط عندما تتعلم القواعد الموثوقة. إذا لم يتلق مورد ما حركة مرور كافية خلال مرحلة التعلم، فلن تكتشف القواعد أو تحمي حتى تفعل ذلك. راجع جدول المنصة لمعرفة المتطلب المحدد.

اختلافات المنصات

مميزه الواجهة الأمامية لـ Azure Premium بوابة التطبيق WAF v2
مرحلة التعلم يتم حساب الخطوط الأساسية عبر نافذة متحركة؛ يبدأ الكشف خلال 24–36 ساعة للملفات التي استقبلت حركة مرور على الأقل خلال 50% من الأيام السبعة الماضية يتم تعلم الأساسيات لمدة لا تقل عن 24 ساعة؛ مجموعة القواعد لا تكتشف أو تحجب حتى تكتمل مرحلة التعلم التي تستغرق 24 ساعة
حركة مرور غير كافية إذا استقبل ملف تعريف حركة المرور لأقل من 50% من الأيام السبعة الماضية، فلن تكتشف القواعد أو تحجب حتى تتوفر حركة مرور كافية لخطوط أساس موثوقة إذا لم تستقبل البوابة حركة مرور كافية خلال مرحلة التعلم على مدار 24 ساعة لتحديد خطوط أساس موثوقة، فلن تكتشف القواعد أو تحجب الهجمات حتى تفعل ذلك
تخفيف الأثر توضع عناوين IP المخالفة في صندوق العقوبات وتحظر طوال مدة صندوق العقوبة توضع عناوين IP المخالفة في صندوق عقوبات وتحظر لمدة 15 دقيقة
معرفات القواعد 500100 (معدل طلب العميل)، 500110 (الروبوتات المشتبه بها) 500100 (معدل طلب العميل)، 500110 (الروبوتات المشتبه بها)
مقاييس إضافية Web Application Firewall HTTPDDoSRuleset نشط حجم صندوق العقوبات، صد صندوق العقوبات

قواعد مجموعة القواعد

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

‏‏قاعدة Description
500100: تم اكتشاف الشذوذ عند معدل طلبات العملاء العالي يقوم بتحديد جميع حركة المرور على ملف تعريف الباب الأمامي أو بوابة التطبيق المرتبطة بها السياسة. عندما يتجاوز العميل الحد المكتسب، يتم تفعيل الإجراء المحدد ويوضع عنوان IP المخالف في صندوق العقوبة.
500110: الروبوتات المشتبه بها ترسل معدلات طلبات مرتفعة يحافظ على قواعد منفصلة، وعموما أكثر صرامة، لحركة المرور المصنفة كبوتات من قبل Microsoft Threat Intelligence. يتم حظر الروبوتات المصنفة كعالية المخاطر فور اختراق العتبة العالمية.

صندوق العقوبات

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

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

المراقبة أثناء المعاينة

عندما يخترق عنوان IP عتبة، يتم تسجيل إدخال سجل مع إجراء حظر لمجموعة قواعد HTTP DDoS وزيادات مقياس مطابقة القواعد المدارة في WAF.

  • الباب الأمامي: استخدم مقياس Web Application Firewall Request Measure المصفاة حسب اسم القاعدة لعدد الكتل، ومقياس Web Application Firewall HTTPDDoSRuleset Is Active الذي يبلغ 1 بمجرد اكتمال التعلم وجاهزية مجموعة القواعد للتعامل مع حركة المرور التي تتجاوز العتبات المتعلمة.
  • بوابة التطبيق: كل طلب محظور لاحق من عنوان IP معاقب يزيد من مقياس مطابقة القواعد المدارة، وحجم صندوق العقوباتومقاييس كتل صندوق العقوبة يتتبع صندوق العقوبات مباشرة.

إعفاء حركة المرور الموثوقة مع استثناءات

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

استثناءات WAF تغلق هذه الفجوة. الاستثناء يتجاوز فحص WAF للطلبات التي تطابق سمات محددة، أو تحدد نطاقا لقاعدة واحدة، أو مجموعة قواعد، أو مجموعة قواعد مدارة كاملة. يمكنك تطبيق استثناءات على قواعد DDoS الخاصة ب HTTP وكذلك على DRS وCRS وحماية البوتات.

الاستثناءات تطابق في:

  • عنوان IP البعيد (Equals أو IP Match)، وهو الخيار المعتاد لإعفاء نطاق المراقبة المعروفة أو اختبار التحميل أو مصادر الشريك من قواعد DDoS
  • طلب URI
  • اسم وقيمة رأس الطلب، مطابقة مع Equals، تبدأ ب، تنتهي مع، أو تحتوي

إرشادات لاستخدام الاستثناءات مع مجموعة قواعد DDoS:

  • ابحث عن نطاق ضيق قدر الإمكان. أفضل استثناء حسب القاعدة على إعفاء مجموعة القواعد بالكامل. الاستثناء الواسع يمنح المهاجم مسارا موثقا حول التخفيف الآلي الخاص بك. إذا كان مولد الأحمال يحتاج فقط إلى تخفيف من القاعدة 500100، فلا تعفيه من القاعدة 500110 أيضا.
  • مصادر معفاة، ليست مسارات. الاستثناء القائم على IP لحزمة اختبار معروفة يكون محدودا. الاستثناء القائم على URI على نقطة نهاية عامة هو باب مفتوح لأي شخص يجده.
  • راجعها وفق جدول زمني محدد. قد تظل الاستثناءات المضافة لاختبار التحميل لمرة واحدة سارية بعد عام.
  • انتبه للحدود. تدعم كل سياسة WAF ما يصل إلى 60 استثناء، وكل بوليصة Front Door تدعم 60 استثناء إجمالا عبر جميع السياسات المرتبطة. يمكن أن يحتوي استثناء واحد على ما يصل إلى 600 عنوان IP، أو 10 URIs، أو 10 رؤوس طلبات.
  • الاستثناءات تتطلب محرك WAF من الجيل القادم وإصدار قواعد الإدارة DRS 2.1 أو أحدث.

استخدم الأداة المناسبة للعمل: الاستثناءات تتخطى فحص عنصر واحد من الطلب (كوكيز أو رأس صاخب) مع الاستمرار في فحص الباقي؛ الاستثناءات تتجاوز قواعد أو مجموعات قواعد محددة لمطابقة الطلبات؛ قاعدة السماح المخصصة تتجاوز كل شيء ما عدا مجموعة قواعد DDoS الخاصة ب HTTP.

مهم

استثناءات WAF ومجموعة قواعد HTTP DDoS قيد المعاينة على كل من الواجهة الأمامية لـ Azure و Application Gateway WAF v2. راجع شروط الاستخدام الإضافية لمعاينات Microsoft Azure.

تحدي قبل أن تحجب

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

  • تحدي جافاسكريبت هو تحد غير مرئي لا يتطلب أي تفاعل بشري. إذا نجح المتصفح في حساب التحدي، يقوم WAF بالتحقق من صحة العميل كغير بوت ويواصل تقييم القواعد المتبقية؛ الطلبات التي تفشل يتم حظرها. استخدمه كتحدي افتراضي لحركة المرور العامة على الويب. الطلبات إلى نقطة التحدي لا ترسل إلى الخلفية ولا تحتسب ضمن تحديد المعدل.
  • CAPTCHA هو تحد تفاعلي يتطلب مشاركة المستخدمين، ويفضل حفظه للتدفقات ذات القيمة العالية مثل تسجيل الدخول، والتسجيل، والخروج، حيث يكون الإساءة الآلية مكلفة ويعتبر بضع ثوان من الاحتكاك مقبولا. صلاحية ملف تعريف الارتباط التحدي قابلة للتكوين في إعدادات السياسات بين 5 و1,440 دقيقة، مع مدة افتراضية 30 دقيقة. تتحمل CAPTCHA رسوما إضافية قائمة على الاستخدام.

خطط حول حدود الميزتين قبل نشرهما:

  • استدعاءات AJAX وAPI غير مدعومة. لا تضع تحديات أمام مسارات واجهات برمجة التطبيقات. استخدم قواعد تحديد المعدل والمطابقة هناك بدلا من ذلك.
  • التحديات مصممة لموارد HTML، وليس للصور المدمجة أو CSS أو ملفات جافا سكريبت.
  • في أول طلب يثير تحديا، يقتصر حجم POST على 64 كيلوبايت على الواجهة الأمامية لـ Azure و128 كيلوبايت على Application Gateway.
  • لا تدعم أي من الميزات Internet Explorer؛ كلاهما يدعم الإصدارات الحالية من Microsoft Edge وChrome وFirefox وSafari.
  • يعاد إصدار تحدي جافاسكريبت عند تغيير عنوان IP الخاص بالعميل وعند طلبات الأصل المشترك (CORS).
  • في Application Gateway، تحدي JavaScript قيد المعاينة ولا يدعم قواعد تحديد المعدلات المخصصة. بوابة التطبيقات للحاويات لا يدعمها WAF.

تحديد السعر

على الأقل، أنشئ قاعدة حد للمعدل تمنع معدل الطلبات المرتفع من أي عميل واحد. اضبط هذه القاعدة كقاعدة الحد الأدنى لمعدل الأولوية (أعلى قيمة رقمية)، حتى يتم تقييم حدود المعدل أو قواعد المطابقة المحددة أولا.

الواجهة الأمامية لـ Azure

  • تطبق حدود المعدل لكل عنوان IP في السوكت، وهو عنوان العميل الذي يفتح اتصال TCP إلى الواجهة الأمامية لـ Azure وقد يكون بروكسي وليس المستخدم النهائي.
  • يتم تقييم العتبات خلال نافذة زمنية ثابتة مدتها دقيقة أو خمس دقائق. بمجرد اختراق العتبة، يقوم الواجهة الأمامية لـ Azure بحجب جميع حركة المرور التي تطابق القاعدة لبقية النافذة. استخدم نافذة الخمس دقائق للتخفيف من فيضانات HTTP: المهاجم الذي تم حجبه في الدقيقة الأولى يبقى محجوبا للدقائق الأربع المتبقية.
  • النوافذ الأكبر ذات الحد الأدنى المقبول هي أكثر التكوين فعالية ضد DDoS. النوافذ الأكبر وقيم العتبة الأكبر تفرض أيضا الاقتراب من العتبة المكونة. عند عتبات منخفضة جدا (أقل من حوالي 200 طلب في الدقيقة)، يمكن لبعض الطلبات فوق العتبة المرور، لأن طلبات من عميل واحد يمكن أن تصل إلى خوادم Front Door التي لم يتم تحديث عداداتها بعد.
  • قواعد تحديد المعدل تدعم فقط إجراءات التسجيلوالحجب فقط؛ الإذن غير مدعوم.
  • طبق قاعدة على جميع حركة المرور عن طريق المطابقة على Host رأس بطول أكبر من 0 لأن كل طلب صالح ل الواجهة الأمامية لـ Azure يحتوي على واحد.

بوابة التطبيق WAF v2

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

  • تتطلب القواعد جلسة GroupByUserSession، التي تتحكم في كيفية احتساب الطلبات. تتيح لك هذه الميزة تحديد التصنيف بشيء غير عنوان IP للعميل:

    GroupByVariable استخدمه عندما
    ClientAddr (افتراضي) الحالة العادية مع عدادات مستقلة لكل IP المصدر
    ClientAddrXFFHeader بوابتك تقع خلف شبكة CDN أو بروكسي، وعنوان IP العميل الحقيقي موجود X-Forwarded-For
    GeoLocation تريد تحديد حد أقصى لحركة المرور لكل دولة/منطقة أثناء فيضان مركزة جغرافيا
    GeoLocationXFFHeader نفس الشيء السابق، باستخدام عنوان IP في X-Forwarded-For
    None عداد مشترك واحد لنمط متطابق بشكل ضيق، مثل صفحة تسجيل الدخول أو قائمة بوكلاء المستخدمين المشبوهين

  • تتطلب قواعد تحديد السرعة أحدث محرك WAF (اختر CRS 3.2 أو أحدث لمجموعة القواعد الافتراضية) ولا تدعم في السحب التي تترك في الهواء.

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

  • العتبات غير مطبقة تماما، لذا لا تستخدم تحديد المعدل للتحكم الدقيق في حركة المرور. استخدمه للتخفيف من معدلات الفائدة الشاذة والحفاظ على التوفر. كن حذرا بشكل خاص مع قواعد المطابقة الواسعة التي تستخدم GeoLocation أو None؛ الحد المناسب المختار بشكل سيء قد يسبب انقطاعات متكررة قصيرة لحركة المرور الشرعية.

حدد عتبات واعية للجغرافيا

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

ابدأ بقياس توزيعك في وقت السلم على مدى أسبوع كامل على الأقل، بحيث يتم تمثيل تأثيرات أيام الأسبوع، وعطلة نهاية الأسبوع، والمناطق الزمنية:

  • في الواجهة الأمامية لـ Azure، اقسم مقياس عدد الطلبات على بعد ClientCountry.

  • في Log Analytics، اشتق الدولة من عنوان IP الخاص بالعميل في سجل الوصول:

    AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(7d)
| extend Country = tostring(geo_info_from_ip_address(clientIp_s).country)
| summarize Requests = count(), Clients = dcount(clientIp_s) by Country
| extend ShareOfTraffic = round(100.0 * Requests / toscalar(
      AzureDiagnostics
      | where Category == "FrontdoorAccessLog" and TimeGenerated > ago(7d)
      | count), 2)
| order by Requests desc

ثم قم بتجميع النتائج إلى مستويات وحدد عتبة لكل منها:

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

كيفية تنفيذ المستويات يعتمد على المنصة:

  • Application Gateway WAF v2 - استخدم GroupByVariable: GeoLocation (أو GeoLocationXFFHeader خلف CDN أو بروكسي) بحيث تشترك كل حركة المرور من منطقة جغرافية واحدة في عداد، وإنشاء قاعدة حد سرعة واحدة لكل مستوى مع عتبة خاصة بها. نظرا لأن الاختراق يتصرف ضد كل عميل في تلك المنطقة، قم بقياس هذه العتبات بشكل محافظ وتحقق منها أولا في إجراء السجلات: قاعدة جغرافية واسعة المطابقة غير صحيحة يمكن أن تسبب انقطاعات قصيرة متكررة لحركة المرور الشرعية.
  • الواجهة الأمامية لـ Azure - العدادات لكل عنوان IP في المقبس، لذا ابن المستويات بشروط مطابقة جغرافية بدلا من ذلك: قاعدة حد سرعة واحدة لكل مستوى، مطابقة على الدول المعنية، لكل منها عتبة خاصة بها. كل عميل في جغرافيا طويلة الذيل يحصل على سقف أقل بكثير من العملاء في أسواقك الأساسية، دون أن يؤثر سلوك أحد العملاء على الآخرين.

بعض الممارسات التي تحافظ على إمكانية الحفاظ على ذلك:

  • اطلب القواعد من الأكثر تحديدا إلى الأقل: قواعد السوق الأساسية ذات أولوية أعلى (قيمة رقمية أقل)، ثم ثانوية، ثم ذات ذيل طويل، مع قاعدة الشاملة العالمية كقاعدة الحد الأدنى لمعدل الأولوية.
  • أفضل إجراء تحدي على كتلة للمناطق الجغرافية ذات الذيل الطويل. حركة المرور من دولة ذات حجم قانوني قليل تبدو مشبوهة في المجموع لكنها لا تزال تحتوي على مستخدمين حقيقيين - مسافرين، مستخدمي VPN، وموظفين عن بعد.
  • أعد القياس بعد إطلاق التسويق، والتوسعات الإقليمية، والفعاليات الكبرى للمنتجات. التكوين الواعي للجغرافيا لا يكون جيدا إلا بقدر الأساس الذي تم حجمه منه.
  • راقب الإشارة العكسية أثناء الحادث: الدولة التي تساهم عادة بنسبة 1% من حركة المرور فجأة تساهم ب 40% هي من أسرع الطرق للتأكد من أنك تشاهد هجوما وليس نموا عضويا.

اختر عتبة من حركة المرور الخاصة بك

استخدم استعلام Log Analytics التالي لتحديد قاعدة الشمول. بالنسبة لبوابة التطبيق، استبدل FrontdoorAccessLog ب ApplicationGatewayAccessLog.

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| summarize count() by bin(TimeGenerated, 5m), clientIp_s
| summarize max(count_), percentile(count_, 99), percentile(count_, 95)

لتحديد عتبات كل جغرافيا كما ذكرت سابقا، أضف الدولة إلى نفس الاستعلام:

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| extend Country = tostring(geo_info_from_ip_address(clientIp_s).country)
| summarize count() by bin(TimeGenerated, 5m), clientIp_s, Country
| summarize max(count_), percentile(count_, 99), percentile(count_, 95) by Country
| order by percentile_count__99 desc

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

قواعد مخصصة للتخفيف المستهدف

أنشئ قواعد WAF مخصصة لحجب أو تحديد معدلات هجمات HTTP وHTTPS التي لها توقيعات يمكن التعرف عليها، مثل وكيل مستخدم معين، أو رأس معين، أو ملف تعريف الارتباط، أو نمط سلاسل الاستعلام، أو URI، أو مزيج منها. بعيدا عن مطابقة السلاسل، يمكن لقواعد الواجهة الأمامية لـ Azure WAF المخصصة مطابقة على:

  • الموقع الجغرافي: حجب حركة المرور من خارج منطقة خدمتك، أو إعادة توجيهها إلى صفحة ثابتة.
  • عناوين IP للعميل (CIDR) وقوائم تقييد IP للعناوين والنطاقات التي حددتها على أنها خبيثة.
  • رقم AS (ASN): قم بتقليل الفيضانات التي تأتي من مزود استضافة أو شبكة نقل لا ينتمي إليها مستخدموك الشرعيون، دون عد نطاقات IP.
  • بصمة العميل (JA4): تطابق مع بصمة JA4، وهي هاش مشتق من مصافحة TLS وخصائص HTTP الخاصة بالعميل. نظرا لأن أدوات الهجوم وعملاء البوت نت ينتجون بصمة متسقة بغض النظر عن عنوان IP الذي يرسلون منه، فإن JA4 هو أحد أكثر التوقيعات ديمومة المتاحة أثناء الهجوم الموزع: التناوب بين آلاف عناوين IP المصدر لا يغير البصمة، والحجب أو تحديد المعدلات يقضي على شبكة البوت نت بأكملها بقاعدة واحدة. تحقق من بصمة الإصبع مع سجلات زمن السلم قبل أن تفرض عليها. المتصفحات الشائعة ومجموعات تطوير البرمجيات الشائعة تشترك في بصمات أصابعها عبر أعداد هائلة من المستخدمين الشرعيين، لذا فإن حظر JA4 غير المتحقق يمكن أن يكون واسعا للغاية. قم بنشر إجراء تسجيل أولا، وتأكد من ظهور البصمة فقط في حركة الهجوم، ثم انتقل إلى الحظر أو قاعدة حد المعدل.
  • ادمج JA4 مع حالات أخرى لتخفيف الجراحات أثناء الحادث. على سبيل المثال، تحديد المعدل بدلا من حظر بصمة JA4 المحددة ورقم ASN لا تخدم من المستخدمين منه، أو بصمة JA4 وطلب URI.
  • قيود وسم الخدمةوالحجم على مكونات الطلب.

هناك ممارستان مهمتان أثناء الحادث:

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

القواعد المدارة ليست موجهة للدفاع ضد DDoS، لكنها تحمي من الهجمات الشائعة الأخرى ويجب أن تبقى مفعلة. انظر القواعد المدارة (الواجهة الأمامية لـ Azure) أو القواعد المدارة (Application Gateway).

حماية الأصل

  • قم بتثبيت الوصول إلى عناوين IP العامة في النقطة الأصلية وتقييد حركة المرور الواردة بحيث لا يمكن الوصول إليها إلا الواجهة الأمامية لـ Azure أو Application Gateway. اتبع الإرشادات حول تأمين حركة المرور إلى الواجهة الأمامية لـ Azure Origins.
  • تأكد من عدم وجود عناوين IP مكشوفة للجمهور في الشبكة الافتراضية لبوابة التطبيقات.
  • Enable caching on الواجهة الأمامية لـ Azure. الاستجابات المخزنة مؤقتا تمتص حجم الذروة عند الحافة وتقلل من معدل الطلب الذي يصل إلى الأصل، وهو غالبا ما يكون الفرق بين تدهور الأداء وانقطاع.
  • أصول المقياس مع مساحة الرأس. التخفيف الآلي واليدوي يستغرق وقتا للتفعيل؛ السعة الفائضة تغطي هذه الفجوة.

الاستجابة لهجوم نشط

  1. تأكد أنه هجوم، وليس نموا عضويا. تحقق من سجلات WAF والوصول بحثا عن تغير مفاجئ في معدل الطلبات، وعدد عناوين IP للعميل، ومزيج الجغرافيا، وتوزيع وكيل المستخدم، وURIs المطلوبة.
  2. تحقق مما هو بالفعل يخفف الضرر. تأكد من أن مجموعة قواعد DDoS الخاصة ب HTTP نشطة وراجع كتلاتها حسب اسم القاعدة. في Application Gateway، تحقق أيضا من حجم مربع العقوبة ومقاييس صندوق العقوبة الذي يمنع العناوين ، لأن الكتلة الأولى لكل عنوان IP تظهر فقط في السجلات. راجع قواعد حدود المعدل.
  3. قارن مزيج الجغرافيا مع خطك الأساسي. الدولة التي تساهم عادة بجزء صغير من حركة المرور وتهيمن عليها فجأة هي إشارة هجوم سريعة وعالية الثقة. كما يخبرك أي مستوى من قواعد الحد يجب تشديد السعر أولا.
  4. ارفع من الحساسية قبل كتابة قواعد جديدة. زيادة حساسية قواعد DDoS في HTTP أو خفض حد المعدل الحالي أسرع وأكثر أمانا من كتابة قاعدة جديدة تحت الضغط.
  5. تحدى بدلا من حظر الأماكن التي تكون فيها حركة المرور مختلطة. طبق تحدي JavaScript على مسارات HTML المتأثرة، وCAPTCHA على التدفقات الحساسة.
  6. اكتب قاعدة مستهدفة فقط بعد تحديد توقيع دائم: ASN، بصمة العميل، تركيبة الرأس، الجغرافيا، أو نمط URI. قم بنشره أولا في إجراء السجل إذا كان النمط يتطابق مع المستخدمين الحقيقيين أيضا.
  7. حافظ على حماية الأصل أثناء الضبط: تأكد من تفعيل التخزين المؤقت، وتأكد من قفل المنشأ، وقم بالتكبير.
  8. بعد الحادث، أعد تحديد حدود السعر مقابل بيانات المرور الجديدة واحتفظ بقواعد الطوارئ التي ثبتت صحتها في وضع السجل إذا لم ترغب في تطبيقها باستمرار.

تحليل سجلات WAF والوصول

راقب حركة المرور باستخدام سجلات Azure WAF للبحث عن الشذوذات، واستخدامها لتحديد عناوين IP المشبوهة التي ترسل أعدادا غير معتادة من الطلبات، أو سلاسل وكلاء المستخدمين غير المعتادة، أو أنماط سلاسل استعلام غير معتادة.

الباب الأمامي Azure

AzureDiagnostics
| where Category == "FrontdoorWebApplicationFirewallLog"

بوابة تطبيق Azure

AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"

أفضل المتحدثين وأفضل وكلاء المستخدمين عبر نافذة الهجوم (الواجهة الأمامية لـ Azure موضح؛ بديل ApplicationGatewayAccessLog ل Application Gateway):

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(1h)
| summarize Requests = count() by clientIp_s
| top 20 by Requests desc

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(1h)
| summarize Requests = count() by userAgent_s, requestUri_s
| top 20 by Requests desc

لمزيد من المعلومات، انظر Azure WAF with الواجهة الأمامية لـ Azure and Azure WAF with Azure Application Gateway.

المحتوى ذو الصلة

  • Last updated on