الصمود أمام هجوم DDoS على VPS الخاص بك

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

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

هجومان مختلفان يتشاركان اسمًا واحدًا

«DDoS» كلمة واحدة تغطي مشكلتين لا يشتركان في شيء تقريبًا سوى النتيجة. تُوقَفان في مكانين مختلفين، على يد جهتين مختلفتين، بأدوات مختلفة، والخلط بينهما هو سبب هدر الكثير من جهود المكافحة في الطبقة الخطأ.

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

ما الذي تشتريه عبارة «الحماية من DDoS متضمنة» فعليًا

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

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

• تغطي الهجمات التي لا يمكنك النجاة منها بمفردك. فيضان تضخيم بسرعة 200 Gbps ضد خادم بمنفذ سعته 1 Gbps ليس مشكلة إعدادات. إنه حساب رياضي بحت. والتنقية عند الجهة الصاعدة هي الحل الوحيد الموجود.
• لا تملك أي حالة (state) بخصوص تطبيقك. فالفلتر لا يعرف أي عناوين URL لديك مكلفة، ولا أي الزوار مسجَّلون دخولهم، ولا أن طلبًا لنقطة نهاية البحث لديك يكلّف أربعمئة ضعف طلب لشعارك.
• تستجيب لعتبة، لا لمعاناتك. يُفعَّل الكشف بناءً على حجم حركة المرور. والهجوم الذي لا يتجاوز تلك العتبة لا يُفعِّلها أبدًا، مهما كان مدى إسقاطه لموقعك شاملًا.
• قد تُوجِّه عنوانك إلى اللاشيء (null-route) لفترة وجيزة في الحالات القصوى. فلكل شبكة سقف. وإذا هدد هجوم بنية تحتية مشتركة، فقد يُسقَط العنوان لفترة — وهذا أمر معياري وعالمي، ويستحق معرفته قبل وقوعه لا أثناءه.

أولًا، حدِّد ما إذا كان هذا هجومًا أصلًا

نسبة كبيرة من الحوادث المشتبه بأنها هجمات DDoS هي في الحقيقة شيء آخر يرتدي معطفها، والإصلاحات ليست قابلة للتبادل. قبل أن تضع حدًا لمعدل أي شيء، اقضِ دقيقتين في استبعاد المنتحلين — فالتشخيص الخاطئ هنا يكلّفك ساعة، وأحيانًا يكلّفك مستخدميك الحقيقيين.

• أصبحت مشهورًا. رابط على مجمّع محتوى كبير يُنتج شكل حركة مرور يبدو تمامًا كفيضان على الطبقة 7، إلا أن المُحيلات (referrers) حقيقية والطلبات لصفحات يريدها إنسان فعلًا. هذه مشكلة سعة بسببٍ سعيد؛ ووضع حد لمعدلها إيذاء للنفس.
• زاحف فقد أدبه. أدوات الكشط العدوانية وبرامج تدريب الذكاء الاصطناعي يمكنها بسهولة أن تتفوق على خادم صغير. عادة ما يفضح user-agent نفسه، والإصلاح هو robots.txt إلى جانب حد موجّه، لا حد عام.
• أنت من كسر شيئًا. نشر عطّل التخزين المؤقت، أو مهمة cron هاربة، أو قاعدة بيانات فقدت فهرسًا (index) — كلها تظهر بمظهر «حِمل مفاجئ بلا سبب واضح». إذا تطابق التوقيت مع تغيير أجريته، فصدِّق التغيير.
• مراقبتك الخاصة هي الفيضان. نادر ومحرج، وأكثر شيوعًا مما يعترف به أحد. حلقة فحص سلامة (health check) تعيد المحاولة دون تراجع تدريجي (backoff) يمكنها توليد معدل طلبات مثير للإعجاب فعلًا.

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

قراءة الهجوم من الخادم نفسه

لست بحاجة إلى لوحة تحكم لتصنيف ما يجري. أربعة أوامر، تُنفَّذ بالترتيب، تخبرك في أقل من دقيقة في أي طبقة تخوض المعركة — ومعرفة ذلك تحدد كل ما تفعله بعد ذلك.

هل الأنبوب ممتلئ؟ راقب عدّادات الواجهة. إذا كانت الإنتاجية ملتصقة بسقف المنفذ، فأنت في هجوم حجمي، وعملك هو فتح تذكرة دعم، لا تغيير إعداد:

• vnstat -tr 10 — متوسط الإنتاجية خلال عشر ثوانٍ، أسرع قراءة صادقة على الإشباع.
• cat /proc/net/dev مرتين، بفارق ثانية واحدة — فروق الحزم والبايتات لكل واجهة، دون الحاجة إلى أي أداة.

هل هو فيضان SYN؟ تتراكم الاتصالات نصف المفتوحة في حالة SYN-RECV. عدد قليل منها طبيعي؛ أما الآلاف فليست كذلك:

• ss -s — سطر الملخص، أعداد الاتصالات حسب الحالة بنظرة واحدة.
• ss -tn state syn-recv | wc -l — الرقم المحدد الذي يهم.

هل هي الطبقة 7؟ إذا كان النطاق الترددي عاديًا لكن كل شيء بطيء، فاحسب الطلبات لكل عميل في سجل الوصول لديك. عنوان واحد بعشرات آلاف الزيارات هو هاوٍ؛ أما مئة ألف عنوان بثلاث زيارات لكل منها فهو الهجوم الحقيقي:

• tail -n 100000 access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -30
• استبدل $1 بـ$7 لترتيب المسارات المطلوبة بدلًا من ذلك. إذا هيمنت نقطة نهاية واحدة مكلفة، فقد وجدت الهدف ونصف الحل.

ما الذي استُنفد فعليًا؟ متوسط الحِمل (load average) وحده لا يخبرك بالكثير. ابحث عن السقف المحدد الذي بلغته: عمليات PHP-FPM الفرعية كلها مشغولة، أو اتصالات قاعدة البيانات عند حدها الأقصى، أو واصفات الملفات مستنفدة، أو عمّال عالقون في حالة D بانتظار القرص. ذلك السقف — لا حركة المرور — هو ما أسقط الموقع، ورفعه غالبًا أسرع من فلترة أي شيء.

أول عشر دقائق

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

1. صنِّف قبل أن تتصرف. واجهة مشبَعة تعني هجومًا حجميًا؛ وواجهة هادئة مع عمّال مشغولين تعني الطبقة 7. ثلاثون ثانية تُنفق هنا تُجنّبك إصلاح الطبقة الخطأ لمدة ساعة.
2. إذا كان حجميًا، افتح تذكرة دعم فورًا وأدرج فيها عنوان الوجهة، ووقت البدء، وعدّادات واجهتك. ثم توقف عن الكتابة على الخادم — فلا يمكنك إصلاح هذا من داخله.
3. إذا كانت الطبقة 7، خزّن مؤقتًا أولًا. تفعيل التخزين المؤقت الكامل والصارم للصفحات للزوار المجهولين هو أسرع طريقة وحيدة لتحويل انقطاع إلى مجرد هزّة كتف، وهو أيضًا الإجراء الوحيد الذي يفيد أمام حركة المرور الحقيقية كذلك.
4. ثم ضع حدًا لمعدل الطلبات — نقطة النهاية المستهدفة أولًا، وكل شيء آخر بعدها. ابدأ بتحفظ. فالحد الذي يُقصي مستخدميك أنت هو استمرار للهجوم تتسبب به بنفسك.
5. احظر فقط ما هو لا لبس فيه. دزينة عناوين بمئة ألف طلب لكل منها، أو user-agent مزيّف بوضوح، أو دولة واحدة ليس لديك فيها مستخدمون. قاوم الرغبة في كتابة قواعد معقدة وأنت تحت النار؛ فلن تتذكرها الشهر القادم.
6. تخلَّص من الحِمل عمدًا إن اضطررت. تقديم صفحة ثابتة «قيد الصيانة» للزوار غير المسجَّلين يُبقي الجهاز حيًا، ويُبقي واجهة API الخاصة بك تعمل، ويشتري لك وقتًا للتفكير. تقرير ما ستضحي به بنفسك أفضل من أن يُقرَّر عنك.
7. دوِّن ما فعلته. كل قاعدة مؤقتة أضفتها هي لغم لنسختك المستقبلية منك. القواعد التي أفادت تصبح دائمة؛ والبقية تُزال غدًا.

حدود معدل الطلبات التي تصمد، والخطأ الذي يقع فيه الجميع

تحديد معدل الطلبات هو الأداة الرئيسية للطبقة 7، وnginx يقوم بذلك جيدًا عبر توجيهين (directives) يحلان مشكلتين مختلفتين فعليًا. limit_req يحدّ معدل الطلبات — أي عدد المرات التي يمكن للعميل أن يطلب فيها. limit_conn يحدّ التزامن — أي عدد الاتصالات التي يمكن لعميل واحد إبقاؤها مفتوحة في آنٍ واحد. الفيضانات تحتاج الأول؛ وهجمات Slowloris، التي تُبقي آلاف الاتصالات شبه الخاملة مفتوحة لاستنفاد مجمع عمّالك، تحتاج الثاني. انشر واحدًا منهما فقط وستكون محميًا من نصف المشكلة فقط.

ثلاثة تفاصيل تفصل بين حد فعّال وآخر شكلي:

• استخدم burst، واستخدم nodelay. المتصفحات الحقيقية دفعية الطبيعة (bursty) — فمشاهدة صفحة واحدة تُطلق دزينة من طلبات الأصول شبه المتزامنة. الحد بلا هامش يُبطئ الزوار الحقيقيين بينما يمر المهاجم الذي يضبط وتيرته دون العتبة بقليل مرور الكرام.
• حدِّد نقاط النهاية المكلفة بشكل منفصل. صفحة البحث، ونموذج تسجيل الدخول، وإعادة تعيين كلمة المرور، وأي نقطة نهاية تكتب في قاعدة البيانات، تستحق ميزانية أضيق بكثير من أصولك الثابتة. يجد المهاجمون هذه النقاط دون عناء، لأنها هي التي تؤلم.
• أعد 429، لا 503. رمز الحالة إشارة للعملاء المهذَّبين ولمحركات البحث بأن هذا تقييد لا عطل — ويمنع بعد ظهر سيئ من أن يتحول إلى مشكلة في الترتيب على محركات البحث.

التخزين المؤقت هو أرخص وسيلة مكافحة ستنشرها على الإطلاق

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

الأمور التي تهم حين تفعّله في خضم الأزمة:

• خزّن مؤقتًا للزوار المجهولين فقط. تجاوَز التخزين المؤقت عند وجود كوكيز (cookie) لجلسة. فتقديم صفحة مستخدم مسجَّل دخوله إلى مستخدم آخر حادثة أسوأ بكثير من الانقطاع الذي كنت تُصلحه.
• قدِّم محتوى قديمًا (stale) عن قصد.استخدام proxy_cache_use_stale في nginx مع updating error timeout يعني أنه حين تكون خلفيتك (backend) متعثرة، يحصل الزوار على صفحة قديمة قليلًا بدلًا من خطأ. أثناء الهجوم، هذا هو الفارق بين موقع يبدو بخير وآخر يبدو ميتًا.
• ادمج حالات الإخفاق المكررة. proxy_cache_lock يضمن أن ألف طلب متزامن لصفحة غير مخزَّنة مؤقتًا يُنتج طلب خلفية واحدًا، لا ألفًا. فبدونه، يمر هجوم كاسر للتخزين المؤقت مباشرة عبر التخزين المؤقت ويصل إلى قاعدة بياناتك بكامل قوته.
• حيّد سلاسل الاستعلام الكاسرة للتخزين المؤقت. الحيلة المعتادة هي إلحاق ? وقيمة عشوائية بحيث يصبح كل طلب مفتاحًا فريدًا ويُخفق (miss) إلى الأبد. طبّع مفتاح التخزين المؤقت لديك ليتجاهل معاملات الاستعلام التي لا يستخدمها تطبيقك فعليًا.

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

السقوف التي تقرر ما إذا كنت ستنهار

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

• عمّال التطبيق. في PHP-FPM: pm.max_children، وعدد عمّال Python لديك، وحجم عنقود Node. هذا هو الحد الحقيقي للتزامن في موقعك. وحين يكونون جميعًا مشغولين، يصطف كل زائر إضافي في طابور، ويكون الموقع معطلًا بصرف النظر عن مدى خمول المعالج. ارفعه فقط بقدر ما تسمح الذاكرة — فالمبادلة (swapping) أسوأ من الاصطفاف في طابور.
• طابور القبول (accept queue). net.core.somaxconn وقائمة انتظار الاستماع (listen backlog) لديك يحددان عدد الاتصالات التي يمكنها انتظار القبول. قائمة انتظار صغيرة تحوّل اندفاعة يمكن النجاة منها إلى اتصالات مرفوضة.
• SYN cookies. net.ipv4.tcp_syncookies يتيح للنواة (kernel) الرد على فيضان SYN دون تخصيص حالة لاتصالات لن تكتمل أبدًا. النوى الحديثة تفعّله افتراضيًا؛ تحقق من ذلك بدلًا من افتراضه، فهو لا يكلّف شيئًا وينقذك من أكثر أنواع الفيضانات شيوعًا على الإطلاق.
• واصفات الملفات (file descriptors). كل اتصال هو واصف. الحد الافتراضي لـnofile غالبًا ما يكون أقل من عدد الاتصالات التي تحاول خدمتها، ونمط الفشل — فشل عمليات القبول (accepts) بينما يبدو كل شيء سليمًا — محيّر فعلًا في الثالثة فجرًا.
• اتصالات قاعدة البيانات. رفع عدد عمّالك دون رفع مجمع الاتصالات (connection pool) لا يفعل سوى نقل الطابور إلى مكان أصعب رؤية. يجب ضبط هذين الرقمين معًا.

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

وضع شيء أمام الخادم الأصلي

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

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

الخادم الأصلي المخفي يساوي أكثر من أي فلتر

يستحق الأمر أن يُقال بصراحة، لأنه يقلب الأولوية المعتادة: أرخص وسيلة لمكافحة DDoS متاحة لك هي عنوان لا يملكه المهاجم. أما الفلترة فهي ما تفعله حين يكون ذلك قد فشل بالفعل.

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

اختيار العتاد والموقع بحيث تبقى الهجمات مملة

يُحسَم بعض هذا قبل وقوع أي هجوم على الإطلاق، في لحظة اختيار الباقة. ثلاث خصائص تهم أكثر بكثير مما توحي به ورقة المواصفات:

• نطاق ترددي غير مقيَّد. على باقة مقيَّدة بعدّاد، الهجوم ليس مجرد انقطاع — بل فاتورة أيضًا. فحركة المرور التي لم تطلبها ولم تستطع رفضها تُحتسب مع ذلك من حصتك. النقل غير المقيَّد يحوّل مخاطرة مالية إلى مخاطرة تقنية بحتة، وهي فئة مشكلات أفضل بكثير.
• ما إذا كان المنفذ ملكك وحدك. على مضيف افتراضي مشترك، يمكن لجار يتعرض لهجوم أن يُضعف أداءك، وسقف حمايتك الخاص مشترك أيضًا. العتاد المخصص بمنفذه الخاص يزيل هذين الأثرين. بالنسبة لمشروع يتوقع اهتمامًا عدائيًا، هذا هو السبب الأوضح للانتقال من VPS — أكثر من عدد الأنوية أو الذاكرة (RAM).
• أين تقع الشبكة. شبكة أوروبية جيدة الاتصال بسعة عبور (transit) حقيقية تمتص فيضانًا لن تمتصه شبكة سيئة النظير (peering)، والولاية القضائية التي اخترتها لأسباب قانونية لها خصائص شبكية أيضًا. يستحق الأمر التحقق من الاثنين معًا عند الاختيار من بين المواقع المتاحة.

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

خمسة أشياء يجب ألا تفعلها

أنماط الفشل هنا ثابتة بما يكفي لسردها، وكل واحد منها كلّف شخصًا ما عطلة نهاية أسبوع:

• لا توجّه عنوانك إلى اللاشيء بنفسك (null-route). حجب عنوانك الخاص بالكامل (blackholing) ينهي الهجوم بأكثر الطرق حرفية ممكنة — إذ لا يستطيع أحد الوصول إليك، بما في ذلك مستخدموك. إنها أداة الملاذ الأخير لمزوّدك، لا إجراء تتخذه طوعًا.
• لا تعامل fail2ban كحماية من DDoS. إنها أداة جيدة ضد محاولات القوة الغاشمة (brute-force) من عدد قليل من العناوين. أما أمام فيضان موزَّع فتستجيب خلال دقائق لشيء يصل خلال ثوانٍ، وقاعدة تحظر آلاف العناوين قد تكلّف في معالجة جدار الحماية أكثر مما كلّفك الهجوم نفسه.
• لا تدفع فدية. الغالبية الساحقة من رسائل الابتزاز التي تهدد بهجوم مدمّر تأتي من أشخاص بلا أي قدرة فعلية، يرسلون آلاف الرسائل المتطابقة. أما الأقلية القليلة القادرة فعلًا على التنفيذ فستعود، لأنك أثبتّ أنك تدفع.
• لا تنتقم. فبصرف النظر عن كون ذلك غير قانوني في كل مكان تقريبًا، فإن المصادر هي أطراف ثالثة مخترَقة. ستكون بذلك تهاجم ضحايا، وتفعل ذلك من عنوان يخصك أنت بلا أي لبس.
• لا ترحّل في حالة ذعر. تغيير المضيف في منتصف الهجوم يعني أن العنوان الجديد سيصبح عامًا خلال دقائق وأنك بلا إعدادات تعمل. ثبِّت الوضع أولًا، ورحِّل بتروٍّ لاحقًا — وإذا رحّلت فعلًا، فإن دليلنا عن الترحيل دون توقف موجود تحديدًا كي لا يكون الترحيل حادثة ثانية.

النسخة المختصرة

مجرَّدًا من التفسير، يتسع النموذج العملي في ثمانية أسطر:

1. صنِّف أولًا. واجهة مشبَعة تعني هجومًا حجميًا يخص مضيفك. وواجهة هادئة مع عمّال مستنفَدين تعني الطبقة 7 وتخصك أنت.
2. في الحالة الحجمية، افتح تذكرة دعم تتضمن العنوان، والطابع الزمني، وعدّاداتك — ثم توقف عن لمس الخادم.
3. خزّن مؤقتًا وبصرامة للزوار المجهولين، وقدِّم محتوى قديمًا تحت الضغط، وادمج حالات الإخفاق المكررة. هذا هو التغيير الأعلى تأثيرًا الذي يمكنك إجراؤه.
4. حدِّد المعدل حسب معدل الطلبات وحسب التزامن، بأشد صرامة على نقاط النهاية الأكثر تكلفة، وأعد 429.
5. أصلح إعداد عنوان IP الحقيقي لديك قبل كل شيء آخر، وإلا فإن كل حد لكل عميل خلف بروكسي يكون إما عديم الفائدة أو كارثيًا.
6. اعرف سقوفك — العمّال، وقائمة الانتظار (backlog)، والواصفات، واتصالات قاعدة البيانات — وارفعها عمدًا في يوم هادئ.
7. أبقِ عنوان الخادم الأصلي سريًا ومحجوبًا بجدار حماية إلا عن عُقدك الأمامية. هذا يساوي أكثر من كل الفلاتر مجتمعة.
8. احصل على نطاق ترددي غير مقيَّد كي لا تتحول حركة المرور التي لم تطلبها أبدًا إلى فاتورة أيضًا.

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