يتخيل معظم الناس الدفاع ضد DDoS كجدار واحد ضخم يمنع حركة البيانات الضارة. في الواقع، الأمر أشبه بسلسلة من نقاط التفتيش، كل واحدة تقوم بمهمة مختلفة. من أهم نقاط التفتيش هذه تحديد المعدل (rate limiting) وتنقية حركة البيانات (traffic scrubbing). عندما تفهم كيف يعملان معًا، ستفهم لماذا تنجح حماية DDoS في الاستضافة الجيدة فعليًا في إيقاف الهجمات بدلًا من مجرد إبطائها.
لا تعمل أي من هاتين التقنيتين بشكل جيد بمفردها. تحديد المعدل بدون تنقية يسمح للهجمات المعقدة بالتسلل. والتنقية بدون تحديد المعدل تهدر الموارد على هجمات كان يمكن إيقافها مبكرًا وبتكلفة أقل. معًا، تشكلان دفاعًا متعدد الطبقات يرصد أنواعًا مختلفة من الهجمات في مراحل مختلفة.
ما الذي يفعله تحديد المعدل فعليًا
يضع تحديد المعدل حدًا أقصى لعدد الطلبات التي يمكن لمصدر واحد إرسالها خلال فترة زمنية معينة. تخيله كحارس أمن يعد كم مرة يحاول نفس الشخص الدخول من الباب في الدقيقة الواحدة. إذا تجاوز الحد، يُمنع من الدخول، ولو مؤقتًا.
يبدو هذا بسيطًا، لكنه فعّال بشكل مفاجئ ضد جزء كبير من حركة الهجمات. الكثير من البوتات والسكربتات تهاجم الخادم بطلبات متكررة من نفس عنوان IP أو نطاق IP صغير. يمكن لحد بسيط على صفحات تسجيل الدخول أو نماذج البحث أو نقاط API إيقاف هذه الهجمات قبل أن تستهلك أي موارد حقيقية من الخادم.
أين يفشل تحديد المعدل
المشكلة هي أن الهجمات الحديثة نادرًا ما تأتي من عنوان IP واحد. تنشر شبكات البوتات الطلبات عبر آلاف، وأحيانًا ملايين، الأجهزة المخترقة. قد يرسل كل مصدر فردي بضع طلبات فقط، ضمن حدود معقولة، بينما يطغى الحجم الإجمالي على خادمك.
يواجه تحديد المعدل أيضًا صعوبة مع ارتفاعات حركة البيانات المشروعة. عرض بيع سريع أو منشور فيروسي على وسائل التواصل الاجتماعي قد ينتج أنماط طلبات تشبه هجومًا حقيقيًا. إذا كانت قواعدك صارمة جدًا، ستنتهي بحظر عملاء حقيقيين.
ما الذي تضيفه تنقية حركة البيانات للصورة
تعمل تنقية حركة البيانات على مستوى مختلف. بدلًا من عد الطلبات لكل مصدر، تحلل مراكز التنقية الشكل العام لحركة البيانات التي تصل إلى الشبكة وتصفي ما لا ينتمي إليها، قبل أن تصل إلى خادمك أصلًا.
تنظر مراكز التنقية في أمور مثل:
- حجم وبنية الحزم غير الطبيعية مقارنة بحركة البيانات المعتادة
- انتهاكات البروتوكول التي لن ينتجها عميل شرعي
- الأنماط الجغرافية وأنماط ASN التي تشير إلى مصدر شبكة بوت
- توقيعات الهجمات المعروفة المطابقة لمصادر معلومات التهديدات
لأن التنقية تحدث في مرحلة مبكرة، غالبًا عبر شبكة موزعة من مراكز البيانات، فهي قادرة على امتصاص الفيضانات الحجمية التي كانت ستشبع نطاق خادم واحد تمامًا. هذه هي الطبقة التي تتعامل مع الهجمات الضخمة والقوية التي لا يمكن لتحديد المعدل وحده التعامل معها. لقد تناولنا آلية هذا التصفية على مستوى الشبكة في كيف تُوقف حماية DDoS على مستوى الاستضافة الهجمات قبل وصولها إلى خادمك.
لماذا تحتاج التنقية إلى مساعدة أيضًا
التنقية ممتازة في رصد الأنماط عبر كميات كبيرة من حركة البيانات، لكنها ليست دائمًا دقيقة على مستوى الطلب الفردي. هجمات طبقة التطبيقات، تلك التي تحاكي سلوك المتصفح الحقيقي وتستهدف نقاطًا محددة مثل نماذج تسجيل الدخول أو صفحات الدفع، قد تبدو مطابقة تقريبًا لحركة البيانات المشروعة عند النظر إليها بشكل إجمالي. هذه بالضبط هي الفجوة التي يسدها تحديد المعدل. إذا أردت نظرة أعمق على سبب صعوبة هذه الهجمات، فقد شرحناها في هجمات DDoS على طبقة التطبيقات: لماذا يصعب إيقافها أكثر من الفيضانات البسيطة.
كيف تتكامل الطبقتان في الواقع العملي
في إعداد حماية DDoS في الاستضافة المبني جيدًا، تمر حركة البيانات عبر كلتا الطبقتين بالتتابع. تتعامل التنقية أولًا مع الضوضاء على مستوى الشبكة، فتزيل الفيضانات الحجمية الواضحة والحزم المشوهة قبل أن تصل إلى بنيتك التحتية أصلًا. وما يمر بعد ذلك يمر بقواعد تحديد المعدل التي تفحص السلوك بدقة أكبر، لكل IP، لكل جلسة، ولكل نقطة نهاية.
هذا التقسيم للعمل مهم لأن كل طبقة مضبوطة لما تجيده:
- تلتقط التنقية الفيضانات الضخمة المقاسة بالجيجابت أو التيرابت في الثانية
- يلتقط تحديد المعدل إساءة الاستخدام المقاسة بعدد الطلبات في الثانية من مصادر محددة
- تعمل التنقية على بيانات الشبكة والبروتوكول الخام
- يعمل تحديد المعدل على سياق مستوى التطبيق، مثل عنوان URL الذي يتم استهدافه بشكل متكرر
عندما تُضبط الطبقتان بشكل جيد، يجب على المهاجم تجاوز نوعين مختلفين جدًا من المرشحات المصممة بواسطة تخصصين مختلفين. وهذه مشكلة أصعب بكثير من التغلب على طبقة واحدة فقط.
مثال من الواقع
لنفترض أن مهاجمًا يشن حملة مختلطة: فيضان UDP حجمي مقترن بفيضان HTTP أبطأ يستهدف صفحة تسجيل الدخول لديك. تتعرف طبقة التنقية فورًا على أنماط الحزم غير الطبيعية لفيضان UDP وتسقطها قبل أن تستهلك أي نطاق ترددي لديك. في الوقت نفسه، يُلتقط فيضان HTTP، الذي يشبه حركة متصفح عادية أكثر، بواسطة قواعد تحديد المعدل التي تراقب عدد محاولات تسجيل الدخول القادمة من كل جلسة خلال فترة زمنية قصيرة. لم تكن أي من الطبقتين وحدها لتوقف الهجومين معًا. معًا، تعاملتا مع الأمر دون أن يلاحظ تطبيقك شيئًا.
ماذا يعني هذا لاختيار الاستضافة
عند تقييمك لادعاءات مزود استضافة بشأن حماية DDoS في الاستضافة، من المفيد أن تسأل تحديدًا كيف تُنفَّذ هاتان الطبقتان، وليس فقط ما إذا كانت عبارة "حماية DDoS" مذكورة في صفحة الأسعار. مزود يوفر التنقية فقط قد يفوت إساءة استخدام طبقة التطبيقات. ومزود يوفر تحديد المعدل فقط سيُغمر بمجرد ظهور هجوم حجمي حقيقي.
نحن نشغّل كلتا الطبقتين كجزء من بيئة VPS المُدارة لدينا: تنقية على مستوى الشبكة لامتصاص الفيضانات الكبيرة، مقترنة بقواعد تحديد معدل مضبوطة لكل موقع لرصد إساءة الاستخدام المستهدفة. يمكنك قراءة المزيد عن كيفية تكامل هذه الأجزاء في صفحة حماية DDoS لدينا، وإذا أردت جانب الجدار الناري من القصة، فإن نظرة عامة على WAF لدينا تشرح كيف يكمّل تصفية الطلبات كلتا الطبقتين.
أسئلة يجب طرحها على مزودك
قبل الالتزام بخطة استضافة بناءً على تسويقها الأمني، اطرح هذه الأسئلة:
- هل تتم التنقية على مستوى الشبكة، أم فقط بشكل تفاعلي بعد اكتشاف الهجوم؟
- هل قواعد تحديد المعدل قابلة للتخصيص لكل موقع، أم ثابتة على مستوى المنصة بالكامل؟
- ما هو الوقت النموذجي للتخفيف من الهجوم بمجرد بدئه؟
- هل ينشر المزود أي بيانات حوادث حقيقية أو دراسات حالة؟
إذا لم تكن متأكدًا من صحة ادعاءات مزود استضافتك الحالي، فقد شرحنا كيفية التحقق من ذلك بشكل صحيح في كيف تعرف ما إذا كانت حماية DDoS لدى مزود استضافتك حقيقية أم مجرد تسويق.
الخلاصة
تحديد المعدل وتنقية حركة البيانات ليسا تقنيتين متنافستين. إنهما طبقتان متكاملتان تغطي كل منهما نقاط الضعف في الأخرى. تتعامل التنقية مع الفيضان، ويتعامل تحديد المعدل مع الهجمات الدقيقة التي تتسلل في حزم أصغر وأكثر دهاءً. إذا كانت استضافتك تمتلك واحدة فقط من هاتين التقنيتين، فأنت محمي بنصف الحماية فقط. اطرح أسئلة محددة، ليس فقط عما إذا كانت حماية DDoS موجودة، بل كيف تعمل فعليًا، قبل أن تثق بها لضمان استمرارية عملك.
