كلمتان، سلوكان متضادان
هناك أمران يمكن للمضيف فعلهما عند وصول فيضان، والقطاع يبيع كليهما تحت اسم "DDoS protection". الأول هو الامتصاص: تُسحب الحركة إلى طبقة scrubbing أعلى خادمك، تُسقَط حزم الهجوم هناك، وتستمر الحزم الشرعية في طريقها، وتبقى خدمتك قابلة للوصول طوال الوقت. الثاني هو blackholing — يُسمى أيضاً null-routing، أو RTBH نسبة إلى RFC 5635 — حيث يُسحب عنوان IP الخاص بك من جدول التوجيه بحيث لا يصله شيء على الإطلاق. يتوقف الفيضان عن ضرب مركز البيانات. وكذلك يتوقف وصول مستخدميك ومراقبتك وجلسة SSH الخاصة بك. يحصل المهاجم بالضبط على النتيجة التي دفع مقابلها.
كلاهما هندسة حقيقية، ولا واحد منهما غير صادق بحسب شروطه الخاصة. يوجد blackholing لأن امتصاص فيضان كبير يكلّف مالاً فعلياً — العبور يُقاس بالاستهلاك، وسعة scrubbing تُشترى وتُهيَّأ مسبقاً — ومضيف اقتصادي يُطبّق null-route على عميل واحد للحفاظ على بقاء أربعمئة عميل آخرين متصلين يتخذ قراراً يمكن الدفاع عنه. الحيلة في الضمير. "DDoS protection" صحيحة في الحالتين؛ ما يختلف هو خدمة مَن يجري حمايتها. اقرأ كل بطاقة خطة وهذا السؤال أمامك.
| الاستجابة | حركة الهجوم | خدمتك | عادةً ما تُوصف بـ |
|---|---|---|---|
| Scrubbing / امتصاص | تُصفَّى في المسار العلوي، وتُسقَط عند الحافة | تبقى تعمل، عادةً دون تغيّر ملحوظ | "تخفيف دائم التشغيل"، "anycast scrubbing" |
| Blackhole / null-route | تُهمَل مع حركتك الشرعية معاً | غير متصلة طوال المدة — عادةً 1–24 h | "حماية حتى X Gbps"، "تعليق مؤقت لعنوان IP" |
| تحديد معدّل عند الحافة فقط | تُسقَط جزئياً، وبشكل عشوائي جزئياً | متدهورة — يرى المستخدمون الحقيقيون فقدان حزم | "حماية أساسية مشمولة" |
| لا شيء (الناقل يقرر) | تصل إلى الرف حتى يقوم مسار علوي بعمل blackhole للبادئة | غير متصلة، وكذلك جيران رفّك | "حماية DDoS متاحة" |
قراءة الحروف الصغيرة قبل أن تدفع
المفردات تفضح الأمر. "Protection up to 10 Gbps" سقف أعلى، والجملة التي تليه مباشرة — تلك المتعلقة بتجاوز الحركة للحد — هي بند null-route. "Protected IP available as an add-on" تعني أن العنوان الذي تحصل عليه افتراضياً غير محمي. "Per-incident" تعني وصول فاتورة بعد الهجوم. "Fair use" مرفقة بالتخفيف تعني حصة من الهجمات شهرياً، وبعدها تصبح وحدك. لا شيء من هذه العبارات كذب؛ إنها ببساطة مكتوبة لتُقرأ مروراً دون تمحيص.
مثال محدد ومنشور، لأنه سياسة موثقة لا نميمة: تبيع BuyVM عناوين مُصفّاة من DDoS كإضافة منفصلة بـ$3/شهر لكل IP، وتُطبَّق null-route على العناوين غير المصفّاة أثناء استمرار الهجوم. نصف الأمر دون تعليق كثير في صفحة مقارنة BuyVM لدينا، لأن عنوان IP رخيص غير مصفّى منتج معقول تماماً حين تعرف أن هذا ما اشتريته. نمط الفشل هو اكتشاف ذلك الساعة 03:00 وbooter يعمل.
أربعة أسئلة تستحق إرسالها لقسم ما قبل البيع قبل أول فاتورة. ما سعة التخفيف، وهل هذا الرقم إجمالي أم الرقم المتاح في نقطة تواجد واحدة؟ "شبكة بـ2 Tbps" تنتهي في مركز scrubbing واحد لديها أنبوب واحد يُملأ. هل التخفيف مشمول في هذه الخطة أم أنه إضافة؟ هل توجد رسوم لكل حادثة أم حصة شهرية من الأحداث المخفَّفة؟ عند أي عتبة تُطبِّقون null-route، ولأي مدة؟ المضيف الذي يجيب على السؤال الأخير برقم يستحق أكثر من ذلك الذي يجيب عليه بصفات.
الطبقات الثلاث، ولماذا الطبقة هي التي تحدد مَن يستطيع الإصلاح
Layer 3/4 الحجمي. فيضانات SYN، وفيضانات UDP، والانعكاس أو التضخيم عبر خدمات NTP وDNS وmemcached وCLDAP وSSDP المفتوحة. يُنفق المهاجم قليلاً من عرض النطاق الترددي في مساره العلوي ويستعيد أضعافه موجَّهة نحوك. هذه مشكلة عرض نطاق ترددي وحزم في الثانية، وهي غير قابلة للحل جذرياً على خادمك: بحلول الوقت الذي يستطيع فيه kernel إسقاط الحزمة، يكون الأنبوب الذي يحملها ممتلئاً بالفعل. لا شيء في nftables ينقذك هنا. السعة التي فوقك وحدها تفعل.
استنفاد حالة Layer 4. فيضانات SYN وACK والاتصالات مصمَّمة حجمها ليس لملء الأنبوب بل لملء جدول — قائمة انتظار SYN في kernel، وجدول conntrack، وقائمة انتظار القبول في تطبيقك. يمكن أن يكون عرض النطاق الترددي تافهاً: بضع مئات من Mbps تُسقط خادماً غير مضبوط بينما يبدو الرسم البياني في جانب المضيف كأنه بعد ظهر هادئ. هذه الطبقة نصفها ملكك فعلياً: يمكن النجاة منها بـtcp_syncookies، وقيمة مضبوطة لـnf_conntrack_max، وحدود لكل مصدر، ولا يمكن النجاة منها بدونها.
تطبيق Layer 7. فيضانات HTTP مكوَّنة من طلبات صالحة فردياً — مصافحات TLS حقيقية، وسلاسل User-Agent موثوقة، وأحياناً متصفحات حقيقية — موجَّهة نحو أي شيء مكلف في موقعك: البحث، تسجيل الدخول، سلة الشراء، صفحة قوائم مدعومة بقاعدة بيانات. أظهرت فئة هجمات HTTP/2 Rapid Reset مقدار الميغابتات القليلة الكافية حين يكلّف كل طلب الخادمَ أكثر مما يكلّف العميل. لا يستطيع جهاز scrubbing رؤية داخل جلسة TLS لا يُنهيها بنفسه، لذا تُعالَج هذه الطبقة إما بقواعد عند الحافة أو بواسطة reverse proxy خاص بك — أبداً بسعة حجمية خام.
| الطبقة | الهجوم النموذجي | الحجم النموذجي | أين يجب إيقافه | قابل للإصلاح على خادمك؟ |
|---|---|---|---|---|
| L3/L4 حجمي | فيضان UDP، تضخيم DNS/NTP/memcached | 5 Gbps – 1+ Tbps | في المسار العلوي، عند الحافة | لا — الأنبوب يمتلئ أولاً |
| استنفاد حالة L4 | فيضان SYN / ACK، استنفاد conntrack | 0.1 – 10 Gbps | الحافة، إضافة إلى ضبط kernel | جزئياً — syncookies، ضبط حجم conntrack |
| تطبيق L7 | فيضان طلبات HTTP(S)، POST بطيء، Rapid Reset | غالباً أقل من 1 Gbps | قواعد الحافة أو reverse proxy الخاص بك | نعم — تحديد المعدل، التحدي، التخزين المؤقت |
كم حجم الهجوم الحقيقي، بصراحة؟
ما يقارب تسعة من كل عشرة هجمات تصل إلى خادم صغير خارجي مصدرها booter أو stresser — خدمة اشتراك تكلف $10 إلى $30 شهرياً تُعيد بيع سعة تضخيم بالدقيقة. توصل هذه الخدمات شيئاً بين 5 و50 Gbps في اندفاعات مدتها بضع دقائق، وهي ما يواجهه فعلياً خادم Minecraft، أو شبكة IRC، أو مُرحِّل Tor، أو منتدى لديه مشرف سابق غاضب، أو غرفة لعب تنافسية. هذا النطاق قابل للنجاة منه تماماً، وهو أيضاً كافٍ تماماً لإسقاط VPS غير محمي بسعر $5.
النطاق التالي الأعلى — 100 إلى 400 Gbps من botnet مؤجَّرة — هو ما يصل حين يكون لدى أحدهم ضغينة محددة وميزانية. نادر ضد الأهداف الصغيرة واعتيادي ضد مواقع القمار والبث والمحتوى الإباحي. وفوق ذلك تقع الأحداث القياسية التي تُبلِّغ عنها كبرى شركات التخفيف، والمقاسة الآن بعدة تيرابت في الثانية ومئات ملايين الطلبات في الثانية؛ الأرقام الفصلية على Cloudflare Radar هي المرجع العام المعتاد. من شبه المؤكد أنك لست الهدف المقصود لأحد هذه الأحداث.
يمكن أن تكون ضحية لأحدها رغم ذلك، وهذا الجزء الذي لا يضعه أحد على بطاقة الخطة: الضرر الجانبي ينتقل حسب البادئة. إذا كان المضيف يقوم بـblackhole بدقة /24 — وكثيرون يفعلون ذلك، لأنها أصغر بادئة يقبلها معظم الناقلين لـRTBH — فإن هجوماً موجَّهاً نحو عنوان واحد في شبكتك الفرعية يُسقط كل عنوان فيها. جاهزية تشغيلك تعتمد على أعداء شخص غريب. هامش السعة هو ما يمنع الحاجة لاتخاذ ذلك القرار أصلاً.
أرقامنا الخاصة، للمعايرة لا للتباهي: 1 Tbps من L3/L4 anycast scrubbing، موزَّعة على أربع نقاط تواجد، قادرة كل واحدة منها على امتصاص نحو 300 Gbps بمفردها، مع اكتشاف تلقائي خلال ثانيتين. أكبر حدث امتصصناه لصالح عميل كان يفوق 600 Gbps ضد خادم ألعاب، ولم تنقطع اتصالات اللاعبين. البنية موثَّقة بتفصيل أكبر على صفحة الشبكة.
مشمول، أو لكل حادثة، أو بحصة — الشكل التجاري مهم
هناك ثلاث طرق لبيع التخفيف، وتنتج فواتير مختلفة جداً. مشمول: التكلفة مُدرجة في سعر الخطة، ولا يغيّر الهجوم شيئاً مما تدفعه. لكل حادثة: تُحاسَب على كل حدث مُخفَّف، وأحياناً لكل ساعة تخفيف. حصة: عدد من الأحداث شهرياً، أو بند "استخدام عادل" يترك للمضيف قرار متى اكتفيت.
نموذج الدفع لكل حادثة ليس احتيالاً. حركة المرور التي خضعت لـscrubbing لا تزال تعبر عبور المضيف قبل أن تُسقَط، ويُحاسَب العبور بالمئين الخامس والتسعين أو مقابل معدل مُلتزَم به — حملة مستمرة ضد عميل واحد بندٌ حقيقي في فاتورة أحدهم. المشكلة ليست العدالة، بل القابلية للتنبؤ: في ظل حملة مدتها أسبوعان، مضيف يحاسب لكل حادثة يحوّل هجوماً عليك إلى فاتورة عليك، وهو هجوم ثانٍ بخطوات إضافية. اسأل عن النموذج المطبَّق قبل أن تحتاج إلى معرفته.
موقفنا، مذكور بوضوح ليكون قابلاً للتحقق: الدرع مُفعَّل افتراضياً في كل خطة من Starter بـ$8.50 إلى Citadel بـ$299.50، بدون تسجيل اختياري، بدون رسوم لكل حادثة، بدون حصة شهرية، وبدون بند "استخدام عادل" مرفق بالتخفيف. إنه نفس النسيج على أرخص VPS كما على أكبر خادم مخصص — انظر خطط VPS والفئات المخصصة. ما يتغيّر مع الفئة هو الرابط الصاعد ومجموعة قواعد Layer 7 الاختيارية، وليس ما إذا كنت محمياً أصلاً.
انتشار anycast، ولماذا يتفوق زمن الكشف على السعة المُعلَنة
مركز scrubbing واحد له سقف صارم: العبور إلى ذلك المبنى الواحد. له أيضاً تكلفة في الكمون، لأنه أثناء التخفيف تُنقَل حركة الجميع إلى ذلك المبنى أولاً — وهذا هو سبب تباطؤ بعض المضيفين بشكل ملحوظ لمستخدمي أوروبا لحظة بدء الهجوم، وبقائهم على هذا الحال حتى يتوقف.
anycast يغيّر الحساب قبل أن يتدخل أي جهاز. تُعلَن نفس البادئة من كل نقطة تواجد، فتُقسَّم botnet موزَّعة عالمياً على تلك النقاط بمجرد طوبولوجيا الإنترنت: هجوم بقدرة 600 Gbps مصدره من كل مكان يصل كنحو 150 Gbps في أربعة أماكن بدلاً من 600 Gbps في مكان واحد. الانتشار يؤدي معظم العمل؛ وعتاد scrubbing لا يتعامل إلا مع ما تبقى بعد أن قسَّمته الجغرافيا بالفعل.
زمن الكشف هو الرقم الأقل تقديراً. التخفيف الذي يبدأ خلال ثانيتين غير محسوس لجلسة TCP؛ والتخفيف الذي يبدأ خلال ستين ثانية يصل بعد أن يكون مستخدموك قد أعادوا التحميل مرتين وغادروا، وبعد أن تكون غرفة اللعب قد أفرغت. حين يذكر مضيف السعة دون كمون الكشف، اطلب الرقم الثاني — فهو الذي يحدد ما إذا كان مستخدموك قد لاحظوا شيئاً أصلاً.
إذا أحضرت بادئتك الخاصة، يصبح blackholing مبضعاً تُمسكه أنت بدلاً من أن يُمارَس عليك. مجتمعات BGP لدينا تغطي خفض الأفضلية لكل ناقل (cs:100:carrier)، والإلحاق الإقليمي (cs:200:region)، وblackhole انتقائي (cs:666:prefix)، بحيث يمكنك تطبيق null-route على عنوان واحد تحت الهجوم بينما تستمر بقية مخصصاتك في الخدمة. هذا هو blackholing المُستخدَم بشكل صحيح: جراحي، قصير، وقرارك أنت.
التعقيد الخارجي: بروكسي أمريكي في المقدمة يُبطل الفائدة
النصيحة المعتادة في كل منتدى هي "ضعه فقط خلف Cloudflare، الفئة المجانية كافية". لموقع عادي هذه نصيحة جيدة. إذا اخترت مضيفاً خارجياً لأسباب قضائية، فإنه يستورد بهدوء كل ما تركته وراءك: شركة مؤسَّسة في الولايات المتحدة تُنهي الآن جلسة TLS الخاصة بك وترى نصك الصريح، وتستلم شكاوى إساءة الاستخدام وحقوق النشر وتتصرف بموجبها وفق سياستها الخاصة، وتحتفظ بحساب مرتبط بعنوان بريد إلكتروني وغالباً وسيلة دفع، ويمكن تبليغها بإجراءات قانونية أمريكية. تجاهل مضيفك لإشعار DMCA لا يساوي الكثير حين تلتزم به CDN الخاصة بك — الآلية موضَّحة في شرح تجاهُل DMCA والتعرض القضائي في دليل 14-Eyes.
البروكسي أيضاً لا يخفي origin الخاص بك ما لم تُقيّد origin بجدار ناري ليقبل فقط بادئات البروكسي وتبقيه كذلك. حتى في هذه الحالة، يتسرب العنوان عبر سجل DNS السلبي، وعبر سجلات شفافية الشهادات إذا أجاب origin يوماً على TLS باسمه الخاص، وعبر بريد يُرسَل مباشرة من الخادم، وعبر سجل A قديم لم يُحذف قط، وعبر أي صفحة خطأ تعكس اسم مضيف الخادم نفسه. الضربات المباشرة إلى origin هي كيف تُسقَط المواقع "المحمية" على أي حال. دليل الاستضافة المجهولة يستعرض كامل سطح التسرب.
إذا أردت طبقة بروكسي دون التكلفة القضائية، شغِّلها بنفسك: نسخة ثانية صغيرة في نفس الولاية القضائية أو ولاية متوافقة، تُنهي TLS بمفتاحك الخاص، مع جدار ناري لـorigin لا يقبل إلا ذلك العنوان. تحتفظ بالتخزين المؤقت وتصفية الطلبات، ولا ينضم أي طرف ثالث إلى سلسلة الثقة. كلا الجهازين خلف نفس نسيج scrubbing، لذا لا يصبح البروكسي هدفاً سهلاً جديداً.
ما الذي يبقى مسؤوليتك، على الخادم
الـscrubbing في المسار العلوي يحمي الأنبوب. إنه لا يضبط kernel الخاص بك، ونطاق استنفاد الحالة هو حيث يموت خادم غير مضبوط أمام هجوم بالكاد سجّلته الشبكة. القائمة القصيرة، بترتيب مردودها: فعِّل net.ipv4.tcp_syncookies وارفع net.ipv4.tcp_max_syn_backlog (المعاملات موثَّقة في مرجع ip-sysctl الخاص بـkernel)؛ اضبط حجم nf_conntrack_max على عدد الاتصالات الذي تتوقعه فعلياً، أو استخدم notrack لحركة ألعاب UDP عالية المعدل بحيث لا يُستشار الجدول أبداً؛ أضف حدود معدّل لكل مصدر في nftables بدلاً من الاعتماد على أن تكون الحافة جراحية الدقة.
من جانب التطبيق، limit_req وlimit_conn في nginx لا تكلفان شيئاً وتوقفان معظم فيضانات L7 التي لم تُصمَّم عمداً لتبدو بشرية. خزِّن مؤقتاً ما يمكن تخزينه، لأن أفضل هدف للمهاجم هو دائماً الصفحة الواحدة التي تولّدها من قاعدة البيانات في كل طلب. أبقِ SSH وأي لوحة تحكم بعيداً عن العنوان الذي يخدم حِمل العمل العام، أو خلف قائمة سماح.
اتجاه واحد ينساه الناس: لا تصبح reflector. مُحلِّل DNS مفتوح، أو daemon NTP غير مضبوط، أو memcached مكشوف على خادمك يجعلك جزءاً من هجوم تضخيم شخص آخر، وتُعامَل إساءة الاستخدام الصادرة بحزم أكبر بكثير من الواردة — زمن الاستجابة المنشور في AUP لدينا هو null-route وتعليق خلال ساعتين. الفيضانات الواردة شيء يحدث لك؛ الفيضانات الصادرة شيء أنت مسؤول عنه.
قائمة التحقق التي تستحق المراجعة قبل الشراء
تسعة أسئلة، بالترتيب الذي يفرز المضيفين بأسرع شكل. ما سعة التخفيف، وهل هي لكل نقطة تواجد أم إجمالية؟ هل هي مشمولة في سعر الخطة أم تُباع لكل IP؟ هل توجد رسوم لكل حادثة، أو حصة من الأحداث المخفَّفة شهرياً؟ ما كمون الكشف؟ هل تصفية Layer 7 متاحة أصلاً، وعلى أي الفئات؟ عند أي عتبة ولأي مدة تُطبَّق null-route، وهل تُخبَر حين يحدث ذلك؟ هل يغيّر التخفيف مسار حركتي أو كموني أثناء تفعيله؟ هل الحماية على العنوان الذي أحصل عليه افتراضياً؟ وأخيراً — السؤال الذي لا يطرحه أحد تقريباً — ماذا يُحتفَظ به عن حركتي أثناء تشغيل التخفيف؟
هذا السؤال الأخير مهم في هذا السوق أكثر من أي سوق آخر. scrubbing يعني أن شيئاً في المسار العلوي ينظر إلى حزمك. اسأل عمّا يبقى بعد الحدث. جوابنا، ولا يتغيّر أثناء الهجوم: الكشف يعمل على عدادات إجمالية عند الحافة — حزم وبتات في الثانية، لكل بادئة — لا على سجلات محتفَظ بها لكل تدفق، والموقف الثابت القائم على انعدام netflow، وانعدام PCAP، وانعدام نسخ مرآوي لـNIC، المنشور في سياسة الخصوصية، ينطبق أثناء التخفيف تماماً كما في بقية الوقت. مضيف لا يستطيع الإجابة على هذا يخبرك بشيء.
إذا جاءت الإجابات هزيلة، البديل رخيص: اشترِ شهراً واحداً من أصغر خطة، ووجِّه إليها مسبار مراقبة، واسأل الدعم مباشرة ماذا يحدث حين يتعرض الخادم لضربة. لا يوجد عقد هنا ولا رسوم إعداد، لذا مضيف يتهرب من السؤال كتابياً يكلفك $8.50 لتكتشف ذلك. انشر Starter، أو اقرأ VPS مقابل المخصص إذا كان حِمل العمل كبيراً بما يكفي ليغيّر الجواب الفئة.
