ما هو هجوم DDoS؟ التقنية والمستويات والدفاع

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

هذا المقال هو المدخل إلى الموضوع. فهو يشرح المستويات الثلاثة التي تجري عليها الهجمات، وبأي معاملات تضخيم يتحول بايت واحد من الطلب إلى 51,000 بايت من الجواب، ومن أين تأتي سعة الهجوم وكم تكلّف في السوق، وكيف تعرفون الهجوم من قياساتكم الخاصة، وما الذي ما زال يفيد على الخادم نفسه وأين يمر هذا الحد بالضبط. وكل الأرقام مذكورة مع مصدرها لكي تستطيعوا التحقق منها. وإذا كانت خدمتكم متوقفة الآن، فاقرأوا أولاً القسم «ما يجب فعله في حالة الهجوم» وقيسوا بدلاً من التعديل.

ما هو هجوم DDoS تقنياً

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

النطاق الترددي للوصلة. الوصلة بسرعة ⁦1 Gbit/s⁩ تنقل 125 ميغابايت في الثانية، ولا أكثر. ومن يرسل أكثر من ذلك يولّد فقداً، والفقد يصيب حزم مستخدميكم كما يصيب حزم المهاجم، لأن الوصلة المليئة لا تنتقي.

معدل الحزم. أصغر حزمة إيثرنت مسموح بها يبلغ طولها 64 بايت، وتحتل مع المقدمة والفاصل بين الحزم 84 بايت على الوصلة. وفي ⁦1 Gbit/s⁩ يتسع منها نحو 1.49 مليون في الثانية. أما نواة نظام الخادم العادية فتعالج بعض مئات الآلاف بحسب المعالج وبطاقة الشبكة، قبل أن تبدأ بالإسقاط. ولهذا يكون معدل الحزم دائماً تقريباً هو الحد الذي يُبلَغ قبل النطاق الترددي.

جداول الحالات. تحتفظ نواة النظام في ذاكرتها بالاتصالات TCP نصف المفتوحة وبمسارات الحزم. وهذه الجداول محدودة بالعدد، لا بالبت في الثانية. ويمكن ملؤها بنطاق ترددي ضئيل جداً، إذا كانت كل حزمة تحمل عنوان مرسل جديداً.

وقت معالجة التطبيق. طلب بحث، أو محاولة تسجيل دخول مع فحص كلمة المرور، أو استعلام خادم يُرجع قائمة إضافات كاملة، يكلّف الهدف أضعافاً بالآلاف مما يكلّف المرسل. وهنا لا يحتاج الهجوم الفعّال في الغالب إلى ⁦10 Mbit/s⁩ حتى.

DoS وDDoS: الفرق الذي يمكن قياسه

الأساس المفاهيمي يقدّمه ⁦RFC 4732⁩ بعنوان «Internet Denial-of-Service Considerations»، وهو منشور إعلامي من IETF بتاريخ نوفمبر 2006. ويرد فيه حرفياً: «A Denial-of-Service (DoS) attack is an attack in which one or more machines target a victim and attempt to prevent the victim from doing useful work.» أي أن هجوم DoS معرَّف بأثره، لا بعدد مصادره. وهو موزَّع، أي DDoS، حين تكون هذه المصادر عديدة ومستقلة بعضها عن بعض.

وعملياً يُحسَب الفرق في موضع واحد بالضبط: في طول قائمة الحجب لديكم. فهجوم DoS من مصدر واحد تنهونه بقاعدة واحدة. وقد وثّقت Cloudflare في مايو 2025 هجوماً جاء من 122,145 عنوان مصدر مختلف من 161 دولة و5,433 نظاماً مستقلاً، بمعدل 26,855 عنواناً جديداً في الثانية، وفي الذروة 45,097. ولا توجد ضد شيء كهذا قائمة حجب تنمو بالسرعة الكافية، وكل مُدخَل فيها يكلّف إضافةً إلى ذلك ذاكرةً ووقت بحث على الجهاز المُحمَّل أصلاً فوق طاقته.

والدليل المشترك «Understanding and Responding to Distributed Denial-of-Service Attacks» الصادر عن CISA وFBI وMS-ISAC يقسّم الهجمات إلى ثلاث تقنيات بالضبط: حجمية، وخاصة بالبروتوكول، وخاصة بالتطبيق. وهذا التقسيم الثلاثي هو الأنفع الموجود، لأنه يصف في الوقت نفسه أي مورد من مواردكم الأربعة يُهاجَم وأين يجب أن يجلس الدفاع.

المستويات الثلاثة لهجوم DDoS

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

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

وأكبر مثال موثّق علناً حالياً: تُبلّغ Cloudflare عن هجوم صُدَّ آلياً في الفترة حتى نهاية عام 2025 بسرعة ⁦31.4 Tbit/s⁩ ودام 35 ثانية. وهذه سعة نحو 31,400 وصلة خادم بسرعة ⁦1 Gbit/s⁩، في وقت واحد، ولنصف دقيقة ونيّف. وفي التقرير نفسه قيمة ثانية تجعل المقياس أوضح من قيمة الذروة: ففي عام 2025 صدّ المشغّل نفسه 47.1 مليون هجوم DDoS، بزيادة 121 بالمئة عن العام السابق، بمعدل 5,376 هجوماً في الساعة.

والحالة الأفضل توثيقاً من مايو 2025 تُظهر كيف يبدو هجوم كهذا عند تفكيكه: ⁦7.3 Tbit/s⁩ في الذروة، و37.4 تيرابايت من البيانات في 45 ثانية، أي نحو 830 غيغابايت في الثانية بالمعدل. والوصلة بسرعة ⁦1 Gbit/s⁩ كانت ستحتاج لنقل الكمية نفسها إلى ثلاثة أيام ونيّف. و99.996 بالمئة من الحركة كانت إغراق UDP خالصاً، موزَّعاً بالمعدل على 21,925 منفذ هدف في وقت واحد، وفي الذروة 34,517. وهذا التوزيع على كل المنافذ نموذجي: فالمهاجم لا يعرف أي منفذ هو المهم، فيأخذ كل المنافذ.

هجمات البروتوكول: الجداول، لا الوصلة

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

وطول هذا الطابور مكتوب في net.ipv4.tcp_max_syn_backlog ويقع على خادم عادي في نطاق أربعة أرقام. والطابور الذي يحمل 1,024 مكاناً يمتلئ عند 1.49 مليون حزمة SYN في الثانية في أقل من ميلي ثانية واحدة. ويكفي لذلك حسابياً ⁦1 Gbit/s⁩، وإذا كان الجدول وحده هو الهدف، كفى جزء يسير من ذلك.

وإلى العائلة نفسها ينتمي أسلوب لم يُوصَف إلا في عام 2021: انعكاس TCP عبر الأجهزة الوسيطة التي تحفظ الحالة. فالبحث «Weaponizing Middleboxes for TCP Reflected Amplification» يُظهر أن جدران الحماية وبنية الرقابة التي تتابع حالة TCP متابعةً نصفية فقط تتفاعل مع حزمة مزيفة واحدة بصفحات كاملة من الجواب. وبذلك أصبح من الممكن لأول مرة إساءة استخدام TCP للتضخيم أيضاً، وهو ما كان يُعَد حتى ذلك الحين مستحيلاً عملياً.

هجمات التطبيق على الطبقة السابعة

هجوم التطبيق يبدو كحركة عادية، لأنه حركة عادية فعلاً، لكن بكمية خاطئة. والقياس بالطلبات في الثانية. وهو يأتي عبر اتصال مُنشأ بالكامل، أي أنه ينجو من كل فحص يقيّم إنشاء الاتصال وحده، ولا يحتاج إلى نطاق ترددي كبير: فعشرة آلاف طلب HTTP في الثانية أقل من ⁦50 Mbit/s⁩ بحسب حجم الطلب، وكافية مع ذلك لإخضاع قاعدة بيانات.

والمعيار في ذلك اسمه ⁦HTTP/2 Rapid Reset⁩، وقد أُعلن في 10 أكتوبر 2023 تحت الرقم ⁦CVE-2023-44487⁩. وتقع الثغرة في قدرة ⁦HTTP/2⁩ على التعديد: يفتح المهاجم مجرى بيانات، ويرسل الطلب، ثم يقطع المجرى فوراً من جديد. فالخادم قد بدأ العمل بالفعل، أما المهاجم فلديه فوراً مكان حر في النافذة من جديد. والقيم التي بُلغت بذلك كانت 201 مليون طلب في الثانية (Cloudflare)، و398 مليوناً (Google)، و155 مليوناً (Amazon). وللمقارنة: أعلى هجوم قاسته Cloudflare على الطبقة السابعة حتى ذلك الحين بلغ 71 مليون طلب في الثانية.

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

المستويات الثلاثة في مقارنة

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

هجمات التضخيم: كيف يصبح البايت الواحد 51,000

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

والنسبة بين حجم الجواب وحجم الطلب اسمها Bandwidth Amplification Factor، واختصاراً BAF. ومعامل BAF يبلغ 50 يعني أن مهاجماً بوصلة ⁦1 Gbit/s⁩ خاصة به يوجّه ⁦50 Gbit/s⁩ إلى الهدف. ويلزم أمران معاً لكي ينجح ذلك: بروتوكول فوق UDP يجيب بأكثر مما يُسأل، وإمكانية تزييف عنوان المرسل. ولهذا يكون تزييف عنوان IP شرطاً لكل هجوم تضخيم، وليس مجرد تكتيك تمويه.

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

معاملات التضخيم للبروتوكولات المُستغَلة

المعاملات التالية مأخوذة من التحذير TA14-017A الصادر عن US-CERT أو CISA بعنوان «UDP-Based Amplification Attacks»، والذي يُوسَّع باستمرار منذ عام 2014. وهو المرجع الذي يستند إليه القطاع بأكمله.

ويشرح الجدول لماذا تتشابه قائمة المنافذ المحجوبة في كل جدار حماية جيد الصيانة. وما تستطيعون فعله بأنفسكم محدود لكنه مهم: تحقّقوا بالأمر ss -lnup مما إذا كانت على خادمكم خدمة من هذا الجدول مفتوحة في الشبكة. فـ memcached غير المربوط على 127.0.0.1 يجعل خادمكم سلاحاً ضد أطراف ثالثة، ويكلّفكم نطاقكم الترددي الصادر، ويضع عنوان IP الخاص بكم على قوائم حجب يصعب الخروج منها من جديد.

لماذا تنتمي بروتوكولات استعلام الألعاب إلى هذا الجدول

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

ومعامل تضخيم بروتوكول Steam منخفض عند 5.5، ومعامل بروتوكول Quake الأقدم مرتفع عند 63.9. لكن الأثر لا يتعلق بالمعامل وحده، بل بحجم الجواب في الحالة المفردة: فالخادم الذي يحمل 200 إضافة يقدّم جواباً أكبر بكثير من خادم بلا إضافات. وتوثّق Bohemia Interactive لـ ⁦Arma 3⁩ تحت التذكرة T83469 منذ عام 2015 أن ⁦4 Mbit/s⁩ من الاستعلامات المزيفة على منفذ استعلام Steam كفت لتجميد خادم. وأربعة ميغابت في الثانية أقل مما يوفره اشتراك منزلي واحد.

وتنتج عن ذلك القاعدة السارية على كل لعبة: تحديد معدل منفذ الاستعلام، لا حجبه. فمن يحجبه يختفي من قائمة الخوادم ولا يجده اللاعبون الجدد بعد ذلك. وأي منفذ هو ذلك في كل لعبة وإلى أي حد يجوز تضييقه، مذكور في المقالات الخاصة بكل لعبة أدناه، مثلاً لـ ⁦Arma 3⁩ أو CS2 وعناوين Source أو Rust.

حالة memcached: ⁦1.35 Tbit/s⁩ ضد GitHub

في 28 فبراير 2018 كان GitHub غير قابل للوصول من الساعة 17:21 حتى 17:26 بتوقيت UTC، وحتى 17:30 بشكل متقطع فقط. وبلغ الهجوم ⁦1.35 Tbit/s⁩ عند 126.9 مليون حزمة في الثانية وجاء من أكثر من 1,000 نظام مستقل مختلف ومن عشرات آلاف النقاط الطرفية المفردة. وقد ضُخِّم عبر memcached بمعامل يصل إلى 51,000: فبايت واحد من المهاجم ولّد ما يصل إلى 51 كيلوبايت في اتجاه الهدف.

وهذه الحالة ما زالت حتى اليوم أفضل درس، لأنها تُظهر ثلاثة أمور في وقت واحد. أولاً: التضخيم يتغلب على حجم شبكة البوتات. فالمهاجم لم يحتج إلى مئة ألف جهاز، بل احتاج إلى نسخ memcached مفتوحة، وكان منها حينها أكثر من 90,000 في الشبكة عالمياً. ثانياً: 126.9 مليون حزمة في الثانية هي نحو 85 ضعف ما تستطيع وصلة بسرعة ⁦1 Gbit/s⁩ نقله على الإطلاق. ولا يغيّر في ذلك أي إعداد على الخادم. ثالثاً: الدفاع نجح لأن الحركة حُوِّلت إلى شبكة تصفية، فانتهى زمن التوقف عند تسع دقائق بدلاً من تسع ساعات.

من أين تأتي سعة هجوم DDoS

شبكات البوتات من أجهزة مُستولى عليها

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

والمعيار هو Mirai، الذي نُشر كوده المصدري في نهاية سبتمبر 2016. والبحث «Understanding the Mirai Botnet» (⁦USENIX Security 2017⁩) يتابع الشبكة على مدى سبعة أشهر ويحدد ذروتها بـ أكثر من 600,000 جهاز مُصاب. والهجوم على صفحة Brian Krebs في سبتمبر 2016 بلغ ⁦620 Gbit/s⁩ وجاء من أكثر من 175,000 جهاز. وفي الهجوم على مشغّل DNS المسمى Dyn في 21 أكتوبر 2016، الذي جعل Twitter وSpotify وReddit غير قابلة للوصول في وقت واحد، أُحصي نحو 107,000 عنوان IP مهاجم.

وبعد تسع سنوات صار المقياس مقياساً آخر. فتعزو Cloudflare هجوم الرقم القياسي بسرعة ⁦31.4 Tbit/s⁩ إلى شبكة بوتات يُقدَّر حجمها بـ مليون حتى أربعة ملايين جهاز مُصاب، معظمها صناديق تلفزيون تعمل بنظام Android. وفي موجة الهجوم في ديسمبر 2025 أُحصي 902 هجوم فائق الحجم، بمعدل 53 في اليوم، بقيم ذروة تبلغ 9 مليارات حزمة في الثانية و⁦24 Tbit/s⁩ و205 ملايين طلب في الثانية. وبذلك نما حجم شبكات البوتات خلال عقد واحد بمعامل 5، والنطاق الترددي المُبلَغ بمعامل 50.

خدمات booter وstresser وكم يكلّف الهجوم

بين شبكة البوتات وطالب الهجوم تجلس خدمة تبيع سعة الهجوم بالاشتراك. وتظهر هذه الخدمات باسم «booter» أو «stresser» أو «IP-stresser» وتدّعي في شروط استخدامها أنها تخدم اختبار تحميل الأنظمة الخاصة. وهي لا تتحقق قط مما إذا كان الهدف المُدخَل يملكه المستخدم، وهذا بالضبط هو الفرق بين أداة وعرض.

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

وفي المقابل يوجد ضغط ملاحقة دائم. ففي أسبوع العمل الخاص بالعملية الدولية PowerOFF في أبريل 2026 استولت سلطات من 21 دولة على 53 نطاقاً لخدمات كهذه، وأوقفت أربعة أشخاص، ونفّذت 25 عملية تفتيش منازل. وحصل المحققون في ذلك على بيانات أكثر من ثلاثة ملايين حساب مستخدم، وتمت مخاطبة أكثر من 75,000 مستخدم مُعرَّف. وفي ديسمبر 2024 كانت 27 منصة قد أُغلقت في العملية نفسها. أي أن من يدفع لخدمة كهذه يترك أثر دفع في قاعدة بيانات تُحجَز عاجلاً أو آجلاً.

كيف تعرفون هجوم DDoS

ما يُبلّغ عنه المستخدمون، وما يدل عليه ذلك أصلاً

المعلومة الأولى تأتي دائماً تقريباً من المستخدمين، وهي أصلح للاستخدام مما تبدو. وأربع بلاغات لها معنى واضح:

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

القياسات الأربعة على الخادم

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

sar -n DEV 1 10
ip -s link show eth0
ss -s
ss -tn state syn-recv | wc -l
nstat -az TcpExtListenDrops TcpExtListenOverflows TcpExtTCPReqQFullDrop UdpRcvbufErrors UdpInErrors UdpNoPorts
cat /proc/sys/net/netfilter/nf_conntrack_count /proc/sys/net/netfilter/nf_conntrack_max

الأمر sar -n DEV 1 10 يقدّم الحزم والبايتات في الثانية لكل واجهة على مدى عشر ثوانٍ. والحاسم هو النسبة: فحزم كثيرة ببايتات قليلة تعني حزماً صغيرة، أي هجوم بروتوكول. وحزم قليلة ببايتات كثيرة جداً تعني حزماً كبيرة، أي هجوم تضخيم. والأمر ip -s link show يُظهر في العمودين dropped وoverrun ما إذا كانت نواة النظام تُسقط أصلاً. والأمر ss -tn state syn-recv يعدّ الاتصالات نصف المفتوحة: فالقيمة من ثلاثة أرقام عادية، والقيمة من خمسة أرقام إغراق SYN. والأمر nstat يقدّم العدّادات التي تبقى، وإن انتهى الهجوم.

وأهم خطوة هي تلك التي لا يفعلها أحد تقريباً مسبقاً: بناء أساس مقارنة ما دام كل شيء يعمل بشكل عادي. فبدون قيمة عادية لا تستطيعون القول إن 40,000 حزمة في الثانية كثيرة أم أنها ليلة سبت عادية. وبالأمر apt-get install -y vnstat sysstat يعمل القياس بشكل دائم. والدليل المفصّل للتحليل موجود في التعرف على هجوم DDoS.

أسطر السجل التي لا لبس فيها

أربع رسائل في سجل نواة النظام وفي سجل خادم الويب تُعَد عملياً دليلاً قاطعاً. والأمر dmesg -T | tail -50 يُظهر الثلاث الأولى:

kernel: TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies.  Check SNMP counters.
kernel: nf_conntrack: nf_conntrack: table full, dropping packet
kernel: net_ratelimit: 2247 callbacks suppressed
nginx: [alert] 1123#1123: 768 worker_connections are not enough

والسطر الأول يعني أن طابور الاتصالات نصف المفتوحة قد طفح وأن نواة النظام تحولت إلى كعكات SYN. وإذا كان مكتوباً هناك Dropping request بدلاً من ذلك، فإن net.ipv4.tcp_syncookies مضبوط على 0، والخادم يُسقط الطلبات بما فيها الحقيقية. والسطر الثاني يعني أن تتبّع الاتصالات قد امتلأ، ومن هذه اللحظة يُسقط الخادم الحركة المشروعة أيضاً. والسطر الثالث أثر جانبي: فنواة النظام تكبت الرسائل، لأنها ستكون منصرفة إلى التسجيل خلاف ذلك. والسطر الرابع ينقل المشكلة إلى التطبيق.

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

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

ما يفيد على الخادم نفسه

على الخادم يمكن تحقيق أكثر مما يُقال في الغالب، وذلك ضد كل ما يبقى صغيراً: البوتات غير النظيفة، والمصادر المفردة، وإغراق الاستعلامات، وهجمات التطبيق. والأدوات لذلك هي nftables، وتتبّع الاتصالات، وكعكات SYN، وتحديد المعدل لكل عنوان مصدر. وكل المعطيات التالية تسري على ⁦Debian 12⁩ و⁦Debian 13⁩ و⁦Ubuntu 22.04 LTS⁩ و⁦Ubuntu 24.04 LTS⁩ ومكتوبة للمستخدم root.

nftables: الإسقاط مبكراً والحساب قليلاً

والمبدأ: الحزمة التي ستُسقَط يجب أن تُسقَط في أبكر وقت وبأرخص ثمن ممكن. فكل قاعدة تعمل قبل ذلك تكلّف وقت معالجة مضروباً بمعدل الحزم. ومجموعة القواعد التالية لملف /etc/nftables.conf تسمح بمرور خادم ويب وخدمة لعب وتُسقط الباقي، مع تحديد معدل للاتصالات TCP الجديدة لكل عنوان مصدر:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    set adminips {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.10 }
    }

    set newconn {
        type ipv4_addr
        size 131072
        flags dynamic,timeout
        timeout 1m
    }

    chain input {
        type filter hook input priority filter; policy drop;

        iif lo accept
        ct state established,related accept
        ct state invalid counter drop

        ip saddr @adminips tcp dport 22 accept

        tcp dport { 80, 443 } ct state new add @newconn { ip saddr limit rate over 30/second burst 60 packets } counter drop
        tcp dport { 80, 443 } accept

        udp dport 25565 accept

        icmp type echo-request limit rate 5/second accept
        icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert } accept

        counter drop
    }

    chain forward { type filter hook forward priority filter; policy drop; }
    chain output  { type filter hook output  priority filter; policy accept; }
}

أدرجوا تحت adminips عنوانكم الثابت الخاص قبل التحميل، وإلا حجبتم أنفسكم عن SSH. والفحص والتنشيط يجريان كالتالي:

nft -c -f /etc/nftables.conf
systemctl enable --now nftables
nft list ruleset
nft list set inet filter newconn

وثلاث نقاط تحدد الأثر. السطر ct state established,related accept موضوع بقصد كقاعدة ثانية، لكي لا تمر الاتصالات القائمة عبر مجموعة القواعد بأكملها. والسطر ct state invalid counter drop يزيل تراكيب الأعلام المعطوبة والأجزاء المتأخرة، دون أن تحتاجوا إلى وصفها واحداً واحداً. والكلمة counter قبل كل drop هي السبب في أنكم تعرفون لاحقاً أي قاعدة عملت: فإذا بقيت العدّادات عند صفر، فالقاعدة لا تُبلَغ، وهذا تشخيص مختلف تماماً عن مجموعة قواعد بلا أثر.

كعكات SYN وحد الطابور

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

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192
net.core.netdev_max_backlog = 16384
net.core.rmem_max = 16777216

وهذه القيم تنتمي إلى ملف تحت /etc/sysctl.d/ وتُؤخَذ بالأمر sysctl --system، وإلا اختفت بعد إعادة التشغيل التالية. وعلى Debian وUbuntu يكون tcp_syncookies من المصنع على 1، وهذا صحيح. والقيمة 1 لا تعني «كعكات دائماً»، بل «كعكات حين يطفح الطابور».

والثمن حقيقي ويندر ذكره. فلا يوجد في الكعكة مكان لخيارات TCP الخاصة بالطرف المقابل. ولا ينقذ Linux تكبير النافذة والإقرار الانتقائي إلا إذا كان net.ipv4.tcp_timestamps على 1، لأن المعطيات تسافر حينها مع الطابع الزمني. وبدون الطابع الزمني تسقط هذه المعطيات، ويعمل الاتصال أبطأ لبقية عمره. وإضافةً إلى ذلك لا تتوفر لحجم الحزمة الأقصى إلا ثلاثة بتات، أي ثماني درجات تقريبية بدلاً من القيمة الدقيقة. فكعكات SYN تشغيل طارئ ينقذ الاتصالات، وليست إعداداً للحالة العادية.

conntrack: الجدول الذي يمتلئ أولاً

يُنشئ تتبّع الاتصالات في نواة النظام مُدخَلاً لكل مسار حزم، ولـ UDP أيضاً، وإن كان UDP لا يعرف الاتصالات. وهذا الجدول بالضبط هو أول مورد ينتهي في هجوم موزَّع، وهو ينتهي بسرعة كبيرة: فعند 1.49 مليون حزمة في الثانية بعنوان مرسل جديد في كل مرة، يمتلئ جدول يحمل 262,144 مكاناً في أقل من خُمس ثانية.

net.netfilter.nf_conntrack_max = 524288
net.netfilter.nf_conntrack_udp_timeout = 10
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20

ويحتل المُدخَل الواحد نحو 300 بايت، أي أن 524,288 مُدخَلاً تحتل نحو 150 ميغابايت من ذاكرة نواة النظام. وحجم جدول الهاش لا يُضبَط عبر sysctl، بل كمعامل وحدة، وفي العادة على ربع الحد الأعلى، في ملف /etc/modprobe.d/nf_conntrack.conf:

options nf_conntrack hashsize=131072

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

nft add table ip raw
nft add chain ip raw prerouting '{ type filter hook prerouting priority raw; }'
nft add rule ip raw prerouting udp dport 25565 notrack

وانتبهوا: notrack والقواعد التي تحفظ الحالة يستبعد كل منهما الآخر. فمن يستثني منفذاً من التتبّع، لم يجز له بعد ذلك استخدام أي قاعدة بـ ct state لهذا المنفذ، وإلا لم يعمل التصريح وصارت الخدمة مغلقة.

تحديد المعدل لكل عنوان مصدر

تحديد المعدل لكل عنوان مصدر هو أكثر إجراء مفرد فعالية على الخادم، لأنه يصيب بالضبط ما يفعله المهاجم ويمرّر بالضبط ما يفعله المستخدم. والفرق كبير: فمتصفح الخوادم الحقيقي يستعلم بضع مرات في الدقيقة، والمهاجم مئات المرات في الثانية. ومع nftables يُعمَل لذلك بمجموعات ديناميكية، كما في مجموعة القواعد أعلاه، ومع iptables الكلاسيكي بـ hashlimit:

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 27015 -m length --length 0:27 -j DROP

وكل الأرقام في قواعد كهذه قيم بداية، لا حقائق. قيسوا أولاً أسبوعاً في التشغيل الطبيعي، وإلا أخرجتم مستخدميكم، وفي أسوأ لحظة. وراعوا إضافةً إلى ذلك أن قواعد iptables الصريحة تختفي بعد إعادة التشغيل (apt-get install -y iptables-persistent، ثم netfilter-persistent save) وأنها تنتمي تحت UFW إلى /etc/ufw/before.rules، لأنها تختفي خلاف ذلك عند ufw reload التالي. ومجموعة القواعد الكاملة للتشغيل الجاري موجودة في حماية الخادم من هجمات DDoS.

أين تنتهي كل تصفية على الخادم

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

ويجيب هذا الجدول عن سؤال ما إذا كانت الحماية الذاتية تكفي، في كل حالة مفردة. فالهجوم على GitHub بـ 126.9 مليون حزمة في الثانية يتسع في معدل الحزم بالكاد على وصلة بسرعة ⁦100 Gbit/s⁩، أما بحجم ⁦1.35 Tbit/s⁩ فيلزم منها أربع عشرة في وقت واحد. وهجوم الرقم القياسي بسرعة ⁦31.4 Tbit/s⁩ يقابل 314 وصلة بسرعة ⁦100 Gbit/s⁩ مُشبَعة بالكامل. وخادم اللعب معلّق نموذجياً على ⁦1 Gbit/s⁩ أو على ⁦1 Gbit/s⁩ مرتين: أي أن حد الحماية الذاتية يقع عند نحو 1.5 حتى 3 ملايين حزمة في الثانية، وعملياً أدنى من ذلك بوضوح، لأن نواة النظام تستسلم قبله.

وهناك حد ثانٍ أكثر إزعاجاً. فبمجرد أن تُشبَع الوصلة، قد لا تصل إليكم حتى جلسة SSH التي أردتم القياس بها. ومن لا يملك حينها وصولاً مستقلاً عن الشبكة، مثل وحدة VNC في منطقة العملاء، لا يستطيع حتى أن ينظر ما يجري.

ما لا يفيد إلا قبل الخادم: التصفية في الشبكة والتنقية

لا يستطيع التصفية بفعالية إلا من يملك سعة أكبر من الهجوم. وهذا يفترض موضعاً تتجمع فيه وصلات كثيرة، أي شبكةً لا جهازاً. وهناك أسلوبان يكمّل كل منهما الآخر.

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

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

والإجراء المضاد البنيوي ضد عناوين المرسل المزيفة معروف بالمناسبة منذ عام 2000 ومكتوب في ⁦RFC 2827⁩، أي ⁦BCP 38⁩: من يوصل عميلاً، يُسقط على هذه الحدود كل الحزم التي لا ينتمي عنوان مرسلها إلى هذا العميل. ويوسّع ⁦RFC 3704⁩ ذلك إلى الشبكات الموصولة بعدة جهات. ولو نفّذ جميع مشغّلي الشبكات ذلك، لانتهى صنف هجمات التضخيم بأكمله. لكنه لم ينتهِ، لأنه يكفي أن لا يفعل ذلك بعضهم.

وهناك أسلوب ثالث يجب معرفته، لأنه يُباع في الغالب على أنه حماية: التوجيه إلى العدم (Nullrouting)، وتقنياً Remote Triggered Black Hole Filtering وفق ⁦RFC 5635⁩. وفيه يُعلَن عنوان IP المُهاجَم في الشبكة على أنه غير قابل للوصول، وتُسقَط الحركة كلها إليه، حركة الهجوم وحركة مستخدميكم على حد سواء. وهذا يحمي شبكة المزوّد، أما لكم فالنتيجة مماثلة لهجوم ناجح، وفي الغالب لساعات بعده أيضاً. اسألوا عند الشك ما إذا كانت التصفية هي المستخدمة أم التوجيه إلى العدم. فالجواب يحدد في توافركم أكثر من أي معطى عن العتاد.

ما تضعه KernelHost في المقابل

الحماية الدائمة المشمولة في كل حزمة خادم

الحماية من DDoS لدى KernelHost مبنية على مستويين وفعّالة بشكل دائم، دون أن تحتاجوا إلى تشغيل شيء أو طلبه أو إعداده:

• المستوى 1: سعة تخفيف تبلغ ⁦17 Tbps⁩ في شبكة التنقية العالمية. تُنقّى الهجمات الحجمية قريباً من مصدرها، قبل أن تصل إلى مركز البيانات.
• المستوى 2: تصفية Arbor في الوقت الفعلي بسعة ⁦3.2 Tbps⁩ في فرانكفورت أم ماين. وقبل الخادم مباشرةً تُكشَف الأنماط الخاصة بكل بروتوكول وتُسقَط، حزمةً حزمة.

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

Advanced DDoS Protection للمشاريع التي تتعرض للقصف باستمرار

بعض المشاريع لا تُهاجَم من حين إلى آخر، بل تُهاجَم بشكل مقصود وعلى مدى أسابيع، كل مساء في الوقت نفسه وبأنماط متغيرة. ولهذا توجد Advanced DDoS Protection ابتداءً من ⁦50.00 EUR⁩ في الشهر، بنظام PrePaid، دون حد أدنى لمدة الالتزام ودون رسوم إعداد. والفرق ليس في سعة أكبر، بل في التحكم:

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

وتتوجه Advanced DDoS Protection إلى عملاء KernelHost وتفترض وجود خادم لدى KernelHost. وإذا كان مشروعكم يعمل حالياً في مكان آخر ويتعرض هناك للهجوم بانتظام، فالنقل إلى هنا هو الطريق، لا رعاية عنوانكم السابق من بعد.

مقارنة بين المستويين

أربعة هجمات حقيقية صُفّيت في التشغيل

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

خادم صوت ⁦TeamSpeak 3⁩، المنفذ ⁦9987 UDP⁩. هجوم مركّب بعدة أنماط في وقت واحد، أكثر من ⁦473.4 Gbit/s⁩ وأكثر من 41.5 مليون حزمة في الثانية. وهذا نحو 28 ضعف معدل الحزم لوصلة بسرعة ⁦1 Gbit/s⁩.

خادم لعب ARK، المنفذ ⁦7777 UDP⁩. إغراق UDP بسيط دون بنية مركّبة، لكن بأكثر من ⁦112.2 Gbit/s⁩ وأكثر من 8.7 مليون حزمة في الثانية. وكيف يُؤمَّن عنقود ARK بنفسه إلى جانب ذلك، مذكور في حماية خادم ARK من DDoS.

هجوم على كل المنافذ، المنافذ 0-65535 على TCP وUDP. أكثر من اثني عشر نمط هجوم رئيسي مختلف ضد جميع المنافذ في وقت واحد، بإجمالي أكثر من ⁦21.3 Gbit/s⁩ وأكثر من 3.9 مليون حزمة في الثانية. وتُظهر هذه الحالة التوزيع على كل المنافذ، وهو ما تحمله أيضاً حالة Cloudflare من مايو 2025 بمعدل 21,925 منفذ هدف.

Minecraft وOpenVPN، المنفذان ⁦25565 TCP⁩ و⁦1194 UDP⁩. هجوم مشترك بأكثر من ستة عشر نمط هجوم رئيسي مختلف، وأكثر من 4 ملايين حزمة في الثانية وأكثر من ⁦8.6 Gbit/s⁩. وبقيت الخدمتان قابلتين للوصول باستمرار، مع أنهما تتحدثان بروتوكولين مختلفين.

ما يجب فعله في حالة الهجوم، بهذا الترتيب

الترتيب أهم من الخطوات المفردة، لأن أكثر الأخطاء شيوعاً تحدث في الدقائق الخمس الأولى.

1. القياس، لا التعديل. احفظوا أولاً القيم من sar -n DEV 1 10 وip -s link show وss -s وdmesg -T في ملف. فهي تختفي بعد الهجوم، وبدونها لا يستطيع أحد مساعدتكم.
2. لا تعيدوا التشغيل. فإعادة التشغيل تمحو كل العدّادات وكل حالات الاتصال وكل دليل، والحِمل يعود بعد ثوانٍ قليلة.
3. تحديد المستوى الذي يجري عليه الهجوم. البايتات مقسومة على الحزم تعطي حجم الحزمة المتوسط. فأقل من 100 بايت يشير إلى هجوم بروتوكول، وأكثر من 1,000 بايت إلى هجوم تضخيم، والأحجام العادية مع حِمل معالج مرتفع إلى الطبقة السابعة.
4. إغلاق منافذ الإدارة. اللوحة، وقاعدة البيانات، والتحكم عن بعد، وكل ما لا يجب أن يكون علنياً، ينتمي إلى تقييد على عنوانكم الخاص. وهذا يقلّص سطح الهجوم فوراً ودون خطر على المستخدمين.
5. ضبط تحديد المعدل، ضيقاً على منفذ الاستعلام وواسعاً على منفذ الاستخدام. لا تحجبوا منفذ الاستعلام، وإلا اختفيتم من كل قائمة خوادم.
6. لا تبدّلوا عنوانكم على عجل. فتبديل العنوان لا يعمل إلا ما دام العنوان الجديد غير معلن من جديد، ومُدخَل DNS قديم منسي يُبطل أثر التبديل.
7. إشراك المزوّد بالأرقام. افتحوا تذكرة بالوقت، ومنفذ الهدف، ومعدل الحزم، والنطاق الترددي، وحجم الحزمة المتوسط. فهذه المعطيات الخمسة تحدد سرعة إعادة ضبط قواعد التصفية لعنوانكم.
8. التوثيق بعد ذلك. سجّلوا متى بدأ، وكم دام، وأي نمط كان. فالهجمات المتكررة في الوقت نفسه هي المعيار على أن المشروع يحتاج إلى عنوان IP مخصص للحماية.

والتفصيل الكامل لهجوم شديد وطويل الأمد موجود في هجوم DDoS شديد: ما العمل.

الوضع القانوني: هجوم DDoS جريمة

في النمسا يقع هجوم DDoS تحت ⁦§ 126b StGB⁩، أي «الإخلال بقدرة نظام حاسوبي على العمل» في قانون العقوبات النمساوي. وتنص الحالة الأساسية على الحبس حتى ستة أشهر أو على غرامة حتى 360 قسطاً يومياً. وإذا دام الإخلال زمناً أطول، صارت العقوبة حتى سنتين. وإذا هُجِمت أنظمة كثيرة ببرنامج صُنِع لذلك بشكل ظاهر، صارت حتى ثلاث سنوات. وعند ضرر يتجاوز 300,000 يورو، أو عند هجوم على بنية تحتية حرجة، أو بصفة عضو في جماعة إجرامية، يقع الإطار بين ستة أشهر وخمس سنوات. وتكمّل ذلك ⁦§ 126c StGB⁩ بتجريم إنتاج البرامج المخصصة لذلك ونشرها وإتاحتها أصلاً.

وفي ألمانيا تسري ⁦§ 303b StGB⁩، أي «تخريب الحاسوب»: الحبس حتى ثلاث سنوات أو الغرامة، وحتى خمس سنوات إذا كانت معالجة البيانات تخدم منشأةً أو شركةً أو جهةً رسمية، وفي الحالات الشديدة بشكل خاص من ستة أشهر إلى عشر سنوات، مثلاً عند العمل على وجه الاحتراف أو عند المساس ببنية تحتية حرجة. والمحاولة معاقَب عليها، وبخصوص أعمال التحضير تُحيل ⁦§ 303b Abs. 5 StGB⁩ إلى ⁦§ 202c StGB⁩.

ولهذا فخدمات booter وstresser ليست منطقة رمادية، بل هي الجزء المدفوع من جريمة. وثلاث نقاط يُساء فهمها بانتظام هنا. أولاً، لا تجعل الإشارة «لاختبار تحميل الأنظمة الخاصة فقط» شيئاً مشروعاً، لأن هذه الخدمات لا تتحقق مِن مالك الهدف المُدخَل. ثانياً، طالب الهجوم معاقَب عليه أيضاً، لا المشغّل وحده: فقد خاطبت Europol بعد أسبوع العمل في أبريل 2026 أكثر من 75,000 مستخدم مُعرَّف صراحةً لتوضيح ذلك بالضبط. ثالثاً، اختبار التحميل على خادمكم الخاص عبر خدمة كهذه ليس حلاً أيضاً، لأن حركة الهجوم تمر عبر شبكة المزوّد وبالتالي عبر وصلات عملاء آخرين، وهو ما يمنعه كل عقد استضافة. ومن يريد قياس قدرة خدمته على التحمل فعلاً، يفعل ذلك بإعلان مسبق وبالتنسيق مع المزوّد. وهذا القسم يعرض حال التشريع وليس استشارة قانونية.

الدليل المناسب لخدمتكم

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

• الأساسيات والمسار: التعرف على هجوم DDoS، حماية الخادم من هجمات DDoS، هجوم DDoS شديد: ما العمل، حماية الألعاب من DDoS بالتصفية في الوقت الفعلي
• Minecraft والصوت: Minecraft وNullping، Minecraft Bedrock، ⁦TeamSpeak 3⁩، Hytale
• لعب الأدوار على أساس GTA: FiveM، RedM، RAGE MP وalt:V، SA-MP وopen.mp، MTA:SA
• البقاء والبناء: Rust، ARK، DayZ، Palworld، Conan Exiles، Project Zomboid، Terraria، Unturned
• التكتيك والرمي: CS2 وSource، ⁦Arma 3⁩، Call of Duty، ⁦Team Fortress 2⁩، ⁦Left 4 Dead 2⁩، Garry's Mod، Mordhau، ⁦Lineage 2⁩

باختصار

• هجوم DDoS يشغل مورداً واحداً من أربعة موارد محدودة: النطاق الترددي، أو معدل الحزم، أو جدول حالات في نواة النظام، أو وقت معالجة التطبيق. وهو لا يستغل ثغرة أمنية، ولهذا لا يحمي التحديث وحده.
• يعرّف ⁦RFC 4732⁩ هجوم DoS بأثره، لا بعدد مصادره. وهو موزَّع حين تكون المصادر عديدة: في حالة Cloudflare من مايو 2025 كانت 122,145 عنواناً من 161 دولة.
• تميّز CISA وFBI وMS-ISAC ثلاث تقنيات: حجمية تُقاس بـ ⁦Gbit/s⁩، وخاصة بالبروتوكول تُقاس بالحزم في الثانية، وخاصة بالتطبيق تُقاس بالطلبات في الثانية. ولكل منها دفاع مختلف.
• هجمات التضخيم تُسيء استخدام خدمات UDP المفتوحة. والمعاملات تمتد من 5.5 في بروتوكول Steam، و30.8 في SSDP، و556.9 في NTP، حتى 51,000 في memcached، وفق التحذير TA14-017A الصادر عن US-CERT.
• السعة تأتي من شبكات بوتات من أجهزة مُستولى عليها، من 600,000 لدى Mirai في عام 2016 حتى ما يُقدَّر بمليون إلى أربعة ملايين خلف هجوم الرقم القياسي بسرعة ⁦31.4 Tbit/s⁩، وتُعاد بيعها ابتداءً من نحو 10 يورو في الشهر.
• على الخادم تعمل nftables، وكعكات SYN، وحدود تتبّع الاتصالات المعدَّلة، وتحديد المعدل لكل عنوان مصدر. وهي تنتهي عند نحو 1.5 مليون حزمة في الثانية، لأن وصلة بسرعة ⁦1 Gbit/s⁩ لا تنقل أكثر من ذلك.
• وفوق هذا الحد لا تحدد النتيجة إلا التصفية في الشبكة الواقعة قبل الخادم. والتوجيه إلى العدم ليس دفاعاً، بل هو النتيجة التي أرادها المهاجم.
• لدى KernelHost تكون الحماية الدائمة ذات المستويين مشمولة في كل حزمة خادم دون زيادة في السعر وفعّالة من لحظة التسليم، دون توجيه إلى العدم: سعة تخفيف تبلغ ⁦17 Tbps⁩ في شبكة التنقية العالمية إضافةً إلى تصفية Arbor في الوقت الفعلي بسعة ⁦3.2 Tbps⁩ في فرانكفورت أم ماين. وتُكمّلها Advanced DDoS Protection ابتداءً من ⁦50.00 EUR⁩ في الشهر بعنوان IP مخصص للحماية وقواعد لكل منفذ تديرونها بأنفسكم.
• هجوم DDoS معاقَب عليه في النمسا وفق ⁦§ 126b StGB⁩ وفي ألمانيا وفق ⁦§ 303b StGB⁩، لطالب الهجوم كما لمشغّلي الخدمات.

إذا كان مشروعكم يعمل لدى KernelHost أصلاً، فالتصفية فعّالة دون أن تفعلوا شيئاً. وإذا لاحظتم مع ذلك أموراً غير معتادة، افتحوا تذكرة دعم بالمعطيات الخمسة من الخطوة 7، ليُعاد ضبط قواعد التصفية لعنوان IP الخاص بكم. وأثناء هجوم جارٍ تستطيعون الوصول إلينا إضافةً إلى ذلك عبر محادثة الطوارئ على WhatsApp على الرقم +43 650 8209883.