طبقات الحماية من هجمات DDoS وأين تقف كل طبقة

في الجزء الأول عرفنا أن لكل نوع من هجمات DDoS مورداً يستنزفه، وفي الجزء الثاني رأينا بأعيننا في مختبر معزول كيف سقط جدول الاتصالات تحت إغراق SYN، وعمال التطبيق تحت إغراق الطبقة السابعة، واتصالات ال Reverse Proxy تحت Slowloris. والسؤال الآن: كيف تحمي خدمتك؟ والإجابة ليست أداة واحدة، وإنما طبقات، كل طبقة توقف نوعاً من الهجوم عند المورد الذي يستهدفه، ولا توجد طبقة واحدة توقف كل شيء. وهذا الجزء يشرح الطبقات من حيث المبدأ، ومتى تحتاج كل طبقة، أما الأدوات بأسعارها وأرقام قبل وبعد من المختبر فهي موضوع الجزء الرابع.

وسوف نناقش في هذا المقال ما يلي:

• فكرة الدفاع بالطبقات، ولماذا لا يكفي سيرفرك وحده أمام الهجوم الحجمي.
• الحماية عند المزود ومراكز التنظيف Scrubbing Centers.
• شبكة Anycast وال CDN، والحماية المدمجة عند مزودي السحابة.
• إخفاء السيرفر الأصلي Origin، حتى لا يتجاوز المهاجم كل الطبقات.
• SYN Cookies وضبط النواة، وحدود الاتصالات والمهل.
• حد المعدل والتخزين المؤقت وWAF وإدارة الروبوتات.
• التوسع التلقائي وفاتورته، وخطة الاستجابة ومن تتصل به.
• ما تطلبه الضوابط الأساسية للأمن السيبراني ECC في هذا الباب.

الدفاع بالطبقات: من يوقف ماذا؟

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

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

الحماية عند المزود ومراكز التنظيف

الطبقة الأولى هي مزود الإنترنت أو مزود الاستضافة نفسه، لأنه يرى الحركة قبل أن تصل إلى خطك. وأبسط ما يقدمه المزود هو الحماية الأساسية من الهجمات الحجمية المعروفة، وكثير من مزودي VPS يقدمونها ضمن السعر، وهذا من الأسئلة التي ذكرناها في كيف تختار خادماً افتراضياً VPS. وفي الحالات الكبيرة يحول المزود حركتك عند الهجوم إلى مراكز تنظيف Scrubbing Centers، وهي مراكز بسعة ضخمة تستقبل كل الحركة الموجهة إليك، وتفصل الحركة السليمة عن حركة الهجوم، ثم ترسل إليك السليمة فقط. والتحويل يجري عادة بإعلان مسارات BGP يجعل الإنترنت يرسل حركتك إلى المركز أولاً، والعودة إليك تكون كثيراً عبر نفق GRE، وهو النوع الذي ذكرناه في مقال الأنفاق Tunnels.

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

شبكة Anycast وال CDN والحماية السحابية

الطبقة الثانية هي شبكة توصيل المحتوى CDN المبنية على Anycast، وفكرة Anycast أن العنوان نفسه يعلن من مواقع كثيرة حول العالم، فيذهب كل زائر، ومعه كل جهاز مهاجم، إلى أقرب موقع إليه. والأثر الدفاعي لهذا كبير: الهجوم الموزع على آلاف الأجهزة يتوزع بدوره على عشرات المواقع، فلا يحمل موقع واحد الهجوم كله، والسعة الإجمالية للشبكة أكبر من أي هجوم تقريباً. وفوق ذلك تخدم ال CDN الصفحات المخزنة من ال Cache دون أن تمر على سيرفرك أصلاً، وقد شرحنا آليتها في شبكة توصيل المحتوى CDN.

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

أخف عنوان السيرفر الأصلي Origin عن المهاجم

كل ما سبق لا يساوي شيئاً إذا عرف المهاجم العنوان الحقيقي لسيرفرك، لأنه عندئذ يتصل به مباشرة ويتجاوز ال CDN والتنظيف وال WAF معاً. وهذا أشيع خطأ في الحماية من DDoS على الإطلاق: يضع صاحب الموقع Cloudflare أمامه، ثم يترك المنفذين 80 و443 مفتوحين للجميع، ويترك العنوان مكشوفاً في سجل بريد قديم أو في سجل DNS قديم. والحل له جانبان شرحناهما في أدلة مستقلة، فلا نكررها:

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

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

ضبط النواة وتقنية SYN Cookies

ننتقل الآن إلى السيرفر نفسه، والطبقة هنا تحمي من هجمات البروتوكول التي لا يتجاوز حجمها خطك. وأهم سلاح ضد إغراق SYN هو SYN Cookies، وفكرتها أن السيرفر عندما يمتلئ جدول الاتصالات نصف المفتوحة لا يحجز مكاناً للاتصال الجديد، وإنما يرمز المعلومات التي يحتاجها داخل رقم التسلسل Sequence Number في رده SYN-ACK نفسه، فإذا عاد العميل الحقيقي بـ ACK استخرج السيرفر المعلومات من الرد وأكمل الاتصال، وإذا لم يعد، كما يفعل المهاجم، فلم يخسر السيرفر شيئاً. والصورة التالية تبين الفرق:

وفي Linux يتحكم في هذا وما حوله عدد من إعدادات النواة sysctl الموثقة في توثيق إعدادات شبكة النواة، والقيم التالية مثال على سيرفر ويب، لا قيم ثابتة لكل حالة:

# /etc/sysctl.d/90-ddos.conf  (مثال، راجع القيم بحسب ذاكرة سيرفرك وحمله)
net.ipv4.tcp_syncookies = 1          # فعل SYN Cookies عند امتلاء الجدول
net.ipv4.tcp_max_syn_backlog = 4096  # حجم جدول الاتصالات نصف المفتوحة
net.core.somaxconn = 4096            # أقصى طول لطابور الاتصالات المكتملة
net.netfilter.nf_conntrack_max = 262144  # جدول تتبع الاتصالات في الجدار الناري

في الإعداد أعلاه لاحظ التالي:

• tcp_syncookies قيمته الافتراضية 1 في توثيق النواة، أي أنه يعمل عند امتلاء الجدول، فتأكد فقط أن أحداً لم يعطله.
• تكبير tcp_max_syn_backlog وsomaxconn يعطيك هامشاً قبل الامتلاء، ولكنه يؤخر المشكلة ولا يحلها، فالحل هو SYN Cookies.
• nf_conntrack_max مهم إذا كان على السيرفر جدار ناري يتتبع الاتصالات، فجدول التتبع نفسه مورد يمتلئ تحت الإغراق، وإذا امتلأ أسقط الجدار الناري الاتصالات الجديدة كلها.
• هذه الإعدادات تطبق على السيرفر نفسه، أما في المختبر فقد طبقناها داخل ال Container فقط بالخيار --sysctl دون أن نمس الجهاز المضيف.

حدود الاتصالات والمهل ضد الهجمات البطيئة

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

ولاحظ أن تحديث ال Reverse Proxy نفسه جزء من هذه الطبقة، فهجوم HTTP/2 Rapid Reset الذي ذكرناه في الجزء الأول أوقفه تحديث برامج السيرفر لا إعداد تكتبه أنت، ولهذا تحديث nginx وHAProxy وغيرهما ليس ترفاً.

حد المعدل والتخزين المؤقت وجدار WAF أمام التطبيق

أما إغراق الطبقة السابعة فطلباته سليمة في شكلها، فلا تكشفها الطبقات السابقة، وتحتاج إلى ثلاث أدوات تكمل بعضها:

• حد معدل الطلبات Rate Limiting: يحدد عدد الطلبات المسموح بها لكل عنوان في مدة معينة، ويرد على الزائد برمز مثل 429 قبل أن يصل إلى التطبيق. وخوارزمياته مشروحة في تحديد معدل الطلبات Rate Limiting، وإعداده في كل Reverse Proxy في حماية تطبيقات الويب على مستوى HTTP. ولاحظ حده: إذا كان المهاجم يملك آلاف العناوين فكل عنوان يبقى تحت الحد، ولهذا حد المعدل يوقف الهجوم الرخيص ويرفع كلفة الموزع ولا يلغيه.
• التخزين المؤقت Caching: الطلب الذي يخدم من ال Cache لا يكلف التطبيق شيئاً، فكل مسار تجعله قابلاً للتخزين تخرجه من قائمة أهداف الهجوم، وأخطر المسارات هي التي لا تخزن مثل البحث والدخول، فهذه تحتاج حد معدل خاصاً بها.
• جدار حماية تطبيقات الويب WAF وإدارة الروبوتات Bot Management: يميز الطلب المشبوه بسلوكه لا بعنوانه فقط، مثل البصمة وتكرار النمط، ويعرض صفحة تحقق على المشكوك فيه، وقد شرحنا WAF على سيرفرك في دليل حماية HTTP، والحماية من الروبوتات عند Cloudflare في خدمات Cloudflare وبدائلها.

التوسع التلقائي وفاتورته

قد يتساءل البعض: إذا كانت خدمتي في السحابة مع توسع تلقائي Autoscaling، ألا يكفي أن تزيد السيرفرات مع الهجوم؟ والإجابة أنه قد يبقي الخدمة تعمل، ولكنه ينقل المشكلة من التوفر إلى الفاتورة، فكل سيرفر جديد يضاف لخدمة طلبات المهاجم تدفع ثمنه أنت، ومعه حركة البيانات الخارجة ورسوم الخدمات المدارة. وهذا ما يسمى أحياناً حجب الخدمة الاقتصادي Economic Denial of Sustainability، فالمهاجم لا يسقط خدمتك وإنما يجعل تشغيلها مكلفاً. والحل أن تضع سقفاً أعلى للتوسع Maximum Capacity، وتنبيهاً على الفاتورة Billing Alert، وأن تضع الطبقات السابقة أمام التوسع لا خلفه، فحد المعدل وال Cache يوقفان الطلب قبل أن يطلب سيرفراً جديداً.

خطة الاستجابة ومن تتصل به

أسوأ وقت لتعرف رقم الدعم عند مزودك هو أثناء الهجوم. ولهذا اكتب خطة استجابة Runbook قصيرة الآن، وفيما يلي ما يجب أن تحتويه:

1. قبل الهجوم: مقاييس أساسية Baseline لحركتك الطبيعية بالوحدات الثلاث bps وpps وrps حتى تعرف الشاذ، وتنبيهات عليها، وقائمة بأرقام الدعم عند مزود الإنترنت ومزود الاستضافة ومزود الحماية، ومن عنده صلاحية تفعيل وضع الهجوم.
2. عند الاشتباه: حدد الوحدة التي ارتفعت لتعرف المورد المستهدف، ثم الطبقة المناسبة: حجم أكبر من الخط يعني اتصالاً فورياً بالمزود، وطلبات على مسار واحد تعني حد معدل أو صفحة تحقق على ذلك المسار.
3. أثناء الهجوم: فعل وضع الحماية المشددة عند مزود الحماية، وأبلغ المزود بالتوقيت والوحدات، ولا تدفع فدية لمن يبتز، فالدفع لا يضمن التوقف ويجعلك هدفاً مجدداً.
4. بعد الهجوم: احفظ السجلات والمقاييس، وراجع ما الذي سقط أولاً، وأضف الطبقة الناقصة، وإذا كان الهجوم مصحوباً بابتزاز فأبلغ الجهات المختصة.

ماذا تطلب ضوابط ECC الأساسية في هذا الباب؟

إذا كانت جهتك في نطاق الضوابط الأساسية للأمن السيبراني ECC الصادرة عن الهيئة الوطنية للأمن السيبراني، فالإصدار الثاني ECC-2:2024 أضاف ضمن متطلبات إدارة أمن الشبكات الضابط الفرعي 2-5-3-9، ونصه في النسخة الإنجليزية من الضوابط الحماية من هجمات حجب الخدمة الموزعة DDoS للحد من المخاطر الناتجة عنها. ولاحظ أن الضابط يقول ماذا تريد ولا يقول كيف، فلا يسمي منتجاً ولا طبقة، والطبقات في هذا المقال هي الطريقة العملية لتحقيقه. وطريقة قراءة الضوابط كلها مشروحة في الضوابط الأساسية للأمن السيبراني NCA ECC بلغة بسيطة.

الخلاصة

• الحماية من DDoS طبقات، كل طبقة توقف نوعاً عند المورد الذي يستهدفه، ولا تغني طبقة عن أخرى.
• الهجوم الأكبر من خط سيرفرك لا يوقف إلا قبل الخط: عند المزود ومراكز التنظيف أو شبكة Anycast أكبر من الهجوم.
• كل الطبقات الأمامية تسقط إذا انكشف عنوان السيرفر الأصلي، فاقفله على مزود الحماية أو استعمل نفقاً.
• SYN Cookies توقف إغراق SYN دون حجز موارد، ومهل الترويسات وحد الاتصالات توقف الهجمات البطيئة.
• إغراق الطبقة السابعة يحتاج حد معدل وتخزيناً مؤقتاً وWAF معاً، وحد المعدل لكل عنوان يرفع كلفة الهجوم الموزع ولا يلغيه.
• التوسع التلقائي بلا سقف ينقل الهجوم إلى فاتورتك، وخطة الاستجابة تكتب قبل الهجوم لا أثناءه.
• الضابط 2-5-3-9 في ECC-2:2024 يطلب الحماية من DDoS، والطبقات هنا طريقة تحقيقه.

وفي الجزء الرابع والأخير سوف ننتقل إلى الأدوات: الخدمات المدارة بأسعارها، والطبقة التي تبنيها على سيرفرك، ونعيد هجمات الجزء الثاني عليها ونقيس الفرق.

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

سجل التحديثات

• أكتوبر 2026: كتابة المقال، والمعلومات من توثيق إعدادات شبكة النواة في Linux ونص الضوابط الأساسية للأمن السيبراني ECC-2:2024 كما قرئت في 12 أكتوبر 2026.