هجمات DDoS: الأنواع والأعراض وطرق الحماية

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

هذا المقال ليس لإثارة الذعر، بل لوضع الأمور في سياقها: ما الذي يعنيه DDoS فعلا، وما هي فئات الهجمات المهمة عمليا، وكيف تلاحظها أثناء التشغيل، وما هي الإجراءات التي تستحق وقتك.

ما هو (D)DoS؟

في هجوم Denial-of-Service (DoS) يحاول المهاجم جعل الخدمة غير قابلة للاستخدام ليس عبر سرقة البيانات بل عبر إغراقها أو استنزاف مواردها. الهدف هنا هو التوافر: موقعك لا يفتح، واجهة API تفشل بسبب timeout، بوابة VPN تتوقف عن قبول الجلسات، أو محللات DNS لا تستطيع المواكبة.

يشير حرف “D” في Distributed إلى أن الحركة لا تأتي من مصدر واحد بل من مصادر كثيرة. قد تكون شبكة بوت من أجهزة مخترقة، أو بنية تحتية شرعية (reflection/amplification)، أو مزيجاً من الاثنين. بالنسبة للمشغل، النتيجة واحدة: ليست هناك “جهة واحدة” بل سيل موزع.

الدوافع: لماذا تُطلق هجمات DDoS؟

الدوافع غالبا ليست مثيرة، لكنها فعالة:

• ابتزاز: “ادفع وإلا سنسقط خدمتك مجددا”.
• نشاط/سياسة: لفت الانتباه، إيصال رسالة، تعطيل.
• تشتيت: يمكن لهجوم DDoS أن يشغل الفريق بينما يحدث شيء آخر بالتوازي.
• منافسة/تخريب: في الأوقات الحساسة (ticketing، إصدارات، إطلاق منتجات) حتى توقف قصير يسبب ضررا.
• ضغط تكاليف: ليس كل هجوم يهدف إلى إسقاط كامل؛ أحيانا الهدف رفع تكلفة السحابة أو الضغط على الدعم أو زيادة الإرهاق التشغيلي.

الطبقات المهمة (ولماذا تهم)

يُشرح DDoS غالبا بحسب الطبقات لأن الطبقة تحدد الإشارات التي تراقبها والدفوع الممكنة.

• الطبقة 3 (IP): من أين يأتي وإلى أين يذهب.
• الطبقة 4 (TCP/UDP): المنافذ، الاتصالات، الـ handshakes، الحالة (state).
• الطبقة 7 (Application): طلبات HTTP(S) وواجهات API ونقاط النهاية.
• “الطبقة 8” (منطق الأعمال): ليست طبقة رسمية، لكنها واقعية: منطق مكلف داخل التطبيق يمكن استغلاله.

الخلاصة: دفاع ممتاز على الطبقة 3/4 قد يفشل أمام هجمات الطبقة 7، لأن الطلبات قد تبدو شرعية ولا تصبح مكلفة إلا عندما تصل إلى التطبيق.

فئة الهجوم 1: الحجم والتضخيم (غالبا UDP)

تهدف الهجمات الحجمية إلى إغراق عرض النطاق أو معالجة الحزم (pps). مثال شائع هو reflection/amplification:

1. يرسل المهاجم طلبات صغيرة إلى خوادم متاحة علنا (مثل open DNS resolvers).
2. يزوّر عنوان المصدر (spoofing) ويضع IP الضحية كـ “source”.
3. ترسل تلك الخوادم ردودا أكبر بكثير إلى الضحية.

إذا أدى طلب بحجم 100 بايت إلى رد بحجم 1,000 بايت فقد حصلت على عامل 10. وبحسب البروتوكول والـ payload يمكن أن يكون العامل أعلى بكثير. المشكلة أن الحركة تبدو قادمة من خدمات “طبيعية” لا تريد عادةً حظرها.

نقطة مهمة: يعتمد التضخيم غالبا على تزوير IP المصدر. لهذا يعد ingress filtering (BCP 38) بالغ الأهمية. عندما يحظر المزودون عناوين المصدر المزورة عند الحافة (edge)، يصبح هذا المسار أصعب بكثير.

فئة الهجوم 2: استنزاف البروتوكول والحالة (TCP/الطبقة 4)

ليس كل DDoS يتعلق بأقصى bandwidth. أحيانا يكون الأكثر كفاءة هو إنشاء state لدى الهدف حتى تمتلئ الجداول أو تُستنزف الموارد.

مثال كلاسيكي هو SYN flood على TCP:

• عادةً يبني TCP اتصالا عبر three-way handshake (SYN -> SYN/ACK -> ACK).
• في SYN flood يرسل المهاجم كميات هائلة من SYN لكن ACK الأخير لا يصل أبدا.
• يحتفظ الخادم باتصالات نصف مفتوحة (state) ويحاول الإعادة حتى timeouts.

هذا يستهلك الذاكرة وCPU وقد يؤثر أيضا على حركة الخروج. وحتى لو كان لديك bandwidth كافٍ: عندما يمتلئ تتبع الجلسات، يصبح التعطل قريبا.

وهناك فئة قريبة تُسمى low and slow: يفتح المهاجم اتصالات حقيقية ويُبقيها مفتوحة بحركة قليلة جدا حتى يصل خادم الويب أو الـ load balancer إلى حد الاتصالات. وغالبا ما تكون أقل وضوحا من قفزة كبيرة في الترافيك.

فئة الهجوم 3: الطبقة 7 و"الطبقة 8" (HTTP وAPI ونقاط نهاية مكلفة)

هجمات الطبقة 7 غالبا الأكثر إزعاجا لأنها أصعب في التمييز عن الترافيك الشرعي. أمثلة:

• HTTP floods: طلبات كثيرة إلى صفحات ديناميكية، أو endpoints للبحث، أو تدفقات تسجيل الدخول.
• Slowloris/slow headers: إبقاء الاتصالات مفتوحة عبر إرسال headers أو body ببطء شديد.
• منطق أعمال “مكلف”: endpoints تشغل استعلامات DB أو تستدعي APIs خارجية أو توليد PDF أو عمليات تشفير أو حتى workflows للـ AI/agents.

الخدعة ليست دائما “مزيد من الترافيك” بل مزيد من العمل لكل طلب. كمية صغيرة من الترافيك المصمم بعناية قد تكون أكثر كلفة من موجة كبيرة من GET ثابتة ومُخزنة.

كيف تكتشف DDoS في بيئة الإنتاج؟

إذا راقبت فقط CPU وRAM فستكتشف بعض الهجمات متأخرا. عمليا، تساعد baselines مع بعض المقاييس القوية:

• الترافيك: bps وpps على الحافة (router، firewall، load balancer).
• مقاييس الاتصالات: اتصالات جديدة/ثانية، جلسات مفتوحة، SYN backlog، TLS handshakes/ثانية.
• مقاييس HTTP: RPS، زمن الاستجابة (p95/p99)، نسب 4xx/5xx، timeouts.
• أعراض upstream: فقدان الحزم، ارتفاع RTT، تشبع الوصلات، أحداث BGP.
• إشارات من السجلات وWAF: مسارات غير معتادة، headers غير صالحة، طلبات غير مكتملة بكثرة، user agents/أنماط مشبوهة.

الأهم بسيط: أنت بحاجة إلى baseline. بدونها كل شيء يبدو “كثيرا”. مع baseline ترى مباشرة أن “حزم صغيرة” أو “طلبات غير مكتملة” انحرفت بقوة عن الطبيعي.

التخفيف: ما الذي ينجح فعليا؟

هناك نهجان أساسيان: make (تبني بنفسك) أو buy (تشتري خدمة). لمعظم الفرق، “buy” أكثر واقعية لأن التخفيف من DDoS يتحول بسرعة إلى مشكلة لا يمكن إدارتها كمشروع جانبي.

1) ضع طبقة أمام التطبيق: CDN/WAF/مزوّد DDoS

بالنسبة للمواقع وواجهات API، غالبا ما يكون هذا أكثر الإجراءات فاعلية:

• Anycast يوزع الترافيك على مواقع عديدة.
• قواعد WAF ترشح أنماطا واضحة على الطبقة 7.
• Bot management وrate limits وآليات challenge/response تقلل الهجمات “الرخيصة”.

مهم: ليست كل الهجمات عبر HTTP. إذا كنت تعرض خدمات مثل VPN أو VoIP أو game servers أو بروتوكولات UDP أخرى، فستحتاج طبقات حماية مختلفة بحسب تصميمك.

2) اضبط rate limiting والمهل بشكل صحيح

بسيط لكنه فعال إذا نُفذ بشكل صحيح:

• ICMP/“ping”: حدده ولا تمنعه تماما (تحتاجه للتشخيص).
• HTTP: حدده حسب IP/token/route خصوصا لنقاط النهاية المكلفة.
• Slow requests: مهل صارمة للـ headers/bodies غير المكتملة.

مثال (Nginx مبسط جدا) لحد الطلبات على route:

limit_req_zone $binary_remote_addr zone=api_per_ip:10m rate=10r/s;

location /api/ {
  limit_req zone=api_per_ip burst=40 nodelay;
}

هذا ليس حلا سحريا، لكنه يغير المعادلة: الهجمات “الرخيصة” تصبح أصعب.

3) الهندسة المعمارية: افصل العمل المكلف

هجمات الطبقة 7 غالبا لا تضرب bandwidth مباشرة، بل تضرب الأماكن التي يكون فيها الطلب الواحد مكلفا بشكل غير متناسب. وفي بيئات الشركات “العادية” توجد أمثلة كثيرة: تسجيل الدخول، البحث، تصدير PDF، التقارير، الرفع، أو أي شيء يتضمن استعلامات DB معقدة أو استدعاءات APIs خارجية.

مثال واقعي: بوابة عملاء لديها زر تصدير (“فاتورة PDF”، “توليد تقرير”، “تحميل الكل كملف ZIP”). في التشغيل الطبيعي يستخدمه أحدهم كل بضع دقائق. أثناء هجوم، يُستدعى نفس الـ endpoint مئات أو آلاف المرات في الدقيقة. المشكلة ليست bandwidth بل CPU (rendering) وقاعدة البيانات (queries) وworker pools (threads/connexions). من الخارج يبدو فقط أن “الموقع بطيء”. داخليا تظهر timeouts وطوابير وقاعدة بيانات لا تلحق.

الخبر الجيد: لا تحتاج لإعادة البناء من الصفر. غالبا تكفي بعض الخيارات المعمارية لفصل الجزء المكلف عن مسار الطلب وإضافة فرامل:

• Caching (بما في ذلك صفحات الخطأ)، TTLs منطقية، edge caching.
• معالجة غير متزامنة (queues) للمهام المكلفة: بدلا من “PDF الآن” شغّل job وقدم النتيجة لاحقا.
• تحقق صارم من المدخلات وإيقاف مبكر: حد التعقيد، وحدود صلبة لكل طلب.
• حماية منفصلة لتسجيل الدخول والبحث والرفع والتصدير: rate limits وtimeouts مخصصة، وربما worker pools مخصصة.
• “وضع متدهور” (feature flags): تعطيل ميزات مؤقتا بدون ضغط نشر.

4) خيارات upstream: الترشيح وscrubbing وخطط الطوارئ

إذا أصبح الحجم كبيرا جدا، يجب ترشيح الترافيك قبل أن يصل إلى اتصالك:

• ترشيح لدى المزود / scrubbing center
• قواعد حظر مؤقتة (مثل: “لماذا يصل UDP إلى خادم الويب؟”)
• توجيه طوارئ (مثل: نقل الترافيك إلى IP “محمي”)

هذا لا ينجح إلا إذا ناقشته مع المزود مسبقا. البدء بشكل “ad hoc” أثناء الحادث مكلف وبطيء.

قائمة تحقق عملية (للفرق بدون خبراء DDoS)

• جرد: ما الخدمات العامة؟ HTTP وDNS وVPN والبريد وVoIP وغيرها؟
• نقاط فشل وحيدة: مزود DNS، reverse proxy، load balancer، منطقة واحدة؟
• Observability: bps/pps وRPS والكمونات والأخطاء وعدد الاتصالات وتنبيهات مرتبطة بالـ baseline.
• تقسية الإعدادات الافتراضية: timeouts، limits، أقصى حجم headers، حدود الاتصالات، backpressure.
• خطة مع المزود: من يقوم بالـ scrubbing ومن يرشح وما هي مسارات التصعيد.
• Runbook: “إذا حدث X افعل Y” مع جهات الاتصال والعتبات والمفاتيح (feature flags).
• التدريب: اختبارات حمل مضبوطة وتمارين حادث (قانونية ومنسقة).

أخيرا: اختبر، لكن بشكل قانوني ومفيد

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

• اختبارات حمل في بيئة staging لديك (خصوصا لنقاط النهاية المكلفة).
• Chaos tests للاعتماديات (تعطل الكاش، بطء DB، تشديد limits).
• تدريب عملية الاستجابة: التنبيهات، التواصل، تصعيد المزود، إجراءات الطوارئ.

المصادر وقراءات إضافية

• Cloudflare: Defending the Internet: How Cloudflare blocked a monumental 7.3 Tbps DDoS attack (2025)
• Cloudflare: DDoS threat report for 2025 Q1
• CISA: Understanding Denial-of-Service Attacks
• RFC 2827 (BCP 38): Network Ingress Filtering
• RFC 3704: Ingress Filtering for Multihomed Networks

حتى المرة القادمة، جو