كثير من مزودي الاستضافة يقولون إنهم يوفرون حماية DDoS. تجدها مطبوعة في صفحة المميزات، ومذكورة في رسائل المبيعات، ومدرجة بجانب "وقت تشغيل 99.9%" كأنها كلها مضمونة بنفس القدر. لكن عندما يقع هجوم فعلي، يتضح الفرق بين الحماية الحقيقية وخانة الاختيار التسويقية بسرعة كبيرة.
إذن كيف تعرف الفرق قبل أن تجد نفسك في منتصف انقطاع الخدمة؟ إليك ما يجب أن تنظر إليه فعلاً.
كيف تبدو حماية DDoS في الاستضافة الحقيقية
التخفيف الفعلي من هجمات DDoS يحدث في مرحلة سابقة، قبل أن تصل حركة المرور الضارة إلى خادمك. يعمل ذلك عن طريق فحص حركة المرور عند حافة الشبكة، وتحديد أنماط الهجوم، وتصفية الحزم السيئة مع السماح لحركة المرور النظيفة بالمرور.
السؤال الأساسي هو: أين تقع الحماية فعلياً؟ إذا كانت حماية المزود موجودة فقط على الخادم نفسه، فقد فات الأوان. بحلول الوقت الذي تصل فيه حركة مرور الهجوم إلى واجهة شبكة خادمك، يكون النطاق الترددي قد استُنفد بالفعل. والخادم يحاول معالجة بيانات غير مفيدة لم يكن يجب أن يراها أصلاً.
توفر حماية DDoS في الاستضافة الجيدة توجيهاً لحركة المرور عبر طبقة تصفية قبل وصولها إلى الخادم. قد يعني ذلك مراكز تصفية محلية، أو فلترة في مستوى مركز البيانات، أو التكامل مع شبكة تخفيف متخصصة. يختلف التطبيق الفعلي، لكن المبدأ واحد: وقف الهجوم في مرحلة مبكرة.
أسئلة يجب طرحها على أي مزود استضافة
صفحات التسويق لن تخبرك بما تحتاج معرفته. هذه الأسئلة ستفعل ذلك.
ما هي إجمالي سعة التخفيف؟
هجمات الحجم الكبير الحديثة يمكن أن تتجاوز 1 Tbps. إذا لم يستطع المزود إخبارك بسعة التخفيف بأرقام واضحة، فهذه علامة تحذيرية. عبارات مثل "حماية على مستوى المؤسسات" دون تفاصيل لا تعني شيئاً. ابحث عن مزودين يذكرون أرقام الإنتاجية الفعلية، حتى لو كانت في نطاق المئات من Gbps.
هل التخفيف مستمر دائماً، أم يُفعَّل بعد الكشف؟
بعض المزودين يستخدمون التخفيف "التفاعلي"، حيث لا تبدأ الحماية إلا بعد اكتشاف الهجوم. تلك الفترة الزمنية للاكتشاف، حتى لو كانت بضع دقائق، قد تكفي لإسقاط موقع. التصفية المستمرة أكثر موثوقية بكثير. اسأل مباشرة: هل يتم فحص حركة المرور دائماً، أم فقط أثناء الهجوم النشط؟
ماذا يحدث لحركة المرور الشرعية أثناء التخفيف؟
بعض دفاعات DDoS تعمل بأسلوب غير دقيق. تحجب نطاقات IP بأكملها أو مناطق جغرافية كاملة لوقف الهجوم، مما يضر بالمستخدمين الحقيقيين أيضاً. اسأل عما إذا كان التخفيف لديهم يفرق بين حركة مرور الهجوم والزوار الحقيقيين، وكيف يتم ذلك.
هل تغطي الحماية Layer 7 إضافة إلى Layer 3/4؟
الهجمات الحجمية على مستوى الشبكة هي الأكثر شيوعاً، لكن الهجمات على مستوى التطبيقات أصعب في الإيقاف وأكثر شيوعاً في الوقت الحالي. تناولنا السبب بالتفصيل في هجمات DDoS على مستوى التطبيق: لماذا يصعب إيقافها أكثر من الفيضانات البسيطة. إذا ذكر المزود فقط حدود النطاق الترددي أو عدد الحزم في الثانية، فقد لا يكون مجهزاً للتعامل مع فيضانات HTTP التي تستهدف منطق تطبيقك.
عبارات تسويقية يجب الانتباه إليها
إليك بعض العبارات التي تبدو مطمئنة لكنها لا تقول لك الكثير في الواقع:
- "حماية DDoS مضمنة" - مضمنة كيف؟ بأي سعة؟ على أي طبقة؟
- "نراقب هجمات DDoS على مدار الساعة" - المراقبة ليست تخفيفاً. معرفتك أنك تتعرض لهجوم لا توقفه.
- "محمي ببنية تحتية على مستوى المؤسسات" - هذا لا يعني شيئاً بدون تفاصيل.
- "خادمك محمي ضد DDoS" - إذا كانت الحماية موجودة فقط على مستوى الخادم، فهي غير مجدية إلى حد بعيد ضد الهجمات الكبيرة.
- "لم نتعرض قط لانقطاع كبير بسبب DDoS" - قد يعني ذلك أن لديهم حماية ممتازة. لكنه قد يعني أيضاً أنهم لم يكونوا هدفاً بعد.
كيف تتحقق من الحماية دون انتظار هجوم
تحقق من مزودي الشبكة الأعلى لمركز البيانات
مزود الاستضافة لا يكون محمياً أكثر من شبكته العليا. ابحث عمن يتشارك معهم وما إذا كان شركاء مركز البيانات لديهم قدرات تخفيف DDoS معلنة. المزودون الذين يستخدمون شبكات Tier 1 أو شبكات تصفية معروفة مثل تلك التي تديرها Cloudflare أو Akamai أو Radware عموماً في وضع أفضل من أولئك الذين يعملون عبر شبكات إقليمية أصغر.
اقرأ بنود اتفاقية مستوى الخدمة
المزود الذي يأخذ حماية DDoS في الاستضافة بجدية سيدرجها في اتفاقية مستوى الخدمة، لا فقط في صفحة التسويق. إذا لم تذكر الاتفاقية شيئاً عن تخفيف الهجمات، أو استثنت صراحةً DDoS كسبب للانقطاع، فخذ ذلك بجدية. هذا يخبرك أين تقع المسؤولية الفعلية.
اسأل عن سياسة Null-Routing
كثير من المزودين يستجيبون لهجمات DDoS الكبيرة عن طريق null-routing لعنوان IP المستهدف، مما يعني أنهم يجعلون موقعك غير متاح لحماية بقية بنيتهم التحتية. هذه ممارسة مقبولة إلى حد ما، لكن متى وكيف يحدث ذلك مهم جداً. اسأل: عند أي حجم هجوم تلجأون إلى null-routing؟ لكم من الوقت؟ هل هناك مسار بديل لحركة المرور الشرعية خلال تلك الفترة؟
ابحث عن الحوادث التاريخية
انظر إلى سجل صفحة حالة المزود، ومنتديات مجتمعه، ومواقع مراجعات الاستضافة المستقلة. ابحث عن منشورات حول انقطاعات DDoS. المزود الذي يملك تخفيفاً حقيقياً سيكون لديه حوادث، لكنها ستحل بسرعة. أما المزود الذي يعتمد على null-routing فسيظهر انقطاعات طويلة في كل مرة يتعرض فيها أحد عملائه لهجوم.
كيف تتناسب حماية DDoS مع منظومة الأمان الشاملة
حتى حماية DDoS في الاستضافة الممتازة لا تحل محل طبقات الأمان الأخرى. جدار حماية التطبيقات (WAF) يتعامل مع تهديدات مختلفة، مثل حقن SQL وعمليات حشو بيانات الاعتماد، وهي أمور لم يُصمَّم فلتر DDoS لاكتشافها. للاطلاع على تفاصيل كيفية عمل هاتين الطبقتين معاً، راجع لماذا يتفوق أمان المواقع متعدد الطبقات على أي أداة منفردة في كل مرة.
الهدف من حماية DDoS في الاستضافة هو إبقاء موقعك متاحاً أثناء الهجوم. WAF يتعامل مع الطلبات الضارة التي تمر عبره. النسخ الاحتياطية والمراقبة تغطي عملية الاسترداد إذا حدث خطأ ما. هذه ليست أدوات متنافسة - بل هي أدوات متكاملة.
عندما نقوم بإعداد تخفيف DDoS للخوادم هنا، يعمل على مستوى الشبكة في مرحلة سابقة بحيث يتم تصفية حركة مرور الهجوم قبل وصولها إلى النطاق الترددي للخادم. ونجمع ذلك مع التصفية على مستوى التطبيق حتى لا تتسرب فيضانات HTTP المنخفضة الحجم لكن المستهدفة. يمكنك قراءة المزيد عن كيفية عمل تلك البنية في نظرة عامة على حماية DDoS لدينا.
خلاصة القول
لا تأخذ عبارة "حماية DDoS مضمنة" بظاهرها. الفرق بين مزود يحجب الهجمات وآخر يكتفي بمشاهدتها قد يعني ساعات من الانقطاع، وخسائر في الإيرادات، وضرراً في السمعة.
اطرح أسئلة محددة. اقرأ اتفاقية مستوى الخدمة. تحقق من شبكة مركز البيانات العليا. وانظر إلى ما يحدث فعلاً عندما يتعرض أحد العملاء لهجوم، لا إلى ما تعد به صفحة التسويق.
الحماية الحقيقية قابلة للتحقق. إذا لم يستطع المزود إعطاءك إجابات واضحة عن سعة التخفيف والبنية التحتية وسياسة null-routing، فهذا يخبرك بشيء مهم.
