ابتزاز DDoS: ما يوقف فعليًا هجومًا على موقع تصنيفات للبالغين، وما لا يوقفه

الصباح الذي يتوقف فيه الدليل عن التحميل دون سبب واضح

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

ما يحدث فعليًا، في الغالبية العظمى من هذه الحالات، هو هجوم حجب الخدمة الموزع: موجة من حركة المرور، غالبًا من آلاف الأجهزة المخترقة، هدفها جعل الموقع عاجزًا عن الرد على الزوار الحقيقيين. هذا ليس نادرًا ولا غريبًا. أفاد فريق استخبارات التهديدات في Cloudflare بأنه خفّف حوالي 5,343 هجوم DDoS على مستوى الشبكة في الساعة عبر شبكته خلال النصف الأول من عام 2026، بمعدل حوالي 128,000 يوميًا. معظم هذه الهجمات قصيرة وصغيرة قياسًا بأكبر الحوادث المسجلة: بقيت نسبة 96.62% منها دون 500 ميجابت في الثانية، وانتهت نسبة 90.60% منها في أقل من عشر دقائق. لكن "الصغير" نسبي: هجوم بقوة 100 ميجابت في الثانية يكفي لإخراج خادم عادي غير محمي من الخدمة، وهذا جزء بسيط فقط من ما يحدث في مساء عادي من أيام الأسبوع ضد مواقع لم يسمع بها أحد من قبل.

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

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

مذكرة الفدية، ولماذا لا ينهي دفعها شيئًا

تأتي بعض الهجمات مرفقة بمطلب. النمط المعروف في قطاع الأمن باسم ransom DDoS أو RDoS يبدأ عادة بهجوم إيضاحي قصير أو تهديد مباشر عبر البريد الإلكتروني، يتبعه تعليمات بدفع مبلغ، غالبًا بعملة رقمية، لإيقاف هجوم أكبر أو تجنّب بدايته أساسًا. جماعات بُنيت تمامًا على هذا السيناريو، مثل DD4BC وArmada Collective من أوائلها، تستخدمه منذ نحو عام 2014، وما زالت جهات أحدث تعتمد الهيكل نفسه لأنه يستمر في النجاح بما يكفي لتبرير الجهد.

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

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

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

ما يوقف حركة المرور فعليًا قبل أن تصل إلى الخادم

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

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

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

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

اختيار مزود يريد فعلًا الاحتفاظ بالحساب

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

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

الفحص العملي بسيط ويستغرق دقائق قليلة: البحث في سياسة الاستخدام المقبول أو شروط الخدمة الخاصة بالمزود عن كلمات adult وpornographic وobscene وescort قبل التوقيع، بدلًا من افتراض أن مزود الأمن محايد تلقائيًا فقط لأنه ليس معالج دفعات أو بنكًا. إذا كانت السياسة صامتة عن ذلك، فهذا الصمت ليس ضمانًا أيضًا، فقط بند لم يختبره أحد بعد. الاحتفاظ بمزود ثانٍ في الذهن، مع إعداد DNS يمكنه التوجيه إليه في ساعة لا في يوم كامل، يهم هنا بالضبط كما يهم في الاستضافة عمومًا.

ما تكلفه الانقطاعات فعليًا بعد انتهائها

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

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

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

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