حماية خادم Call of Duty من هجمات DDoS

حماية خادم Call of Duty من هجمات DDoS مهمة محددة بشكل مُريح في الإصدارات الكلاسيكية: فالأمر يتعلق بمنفذ UDP واحد بالضبط، وبحفنة من إعدادات Dvar في server.cfg، وبمتجه تضخيم يحمله المحرّك معه منذ عام 2003. أما الخادم الذي يفقد مساءً في وسط الجولة جميع اللاعبين في وقت واحد فنادراً ما تكون مشكلته في العتاد. ففي الغالب يجري هجوم، وهو يجري بالضبط عندما يكون الخادم ممتلئاً.

يعرض هذا المقال أولاً أي الإصدارات يسري عليها أصلاً، ثم ما تستطيعون تأمينه بأنفسكم دون تكاليف إضافية، وبعد ذلك أين تنتهي هذه الإجراءات تقنياً، وفي الختام ما يجب أن يحدث بعدها في الشبكة الواقعة قبل الخادم. والأوامر مكتوبة لأنظمة Debian 12 وDebian 13 وUbuntu 22.04 LTS وUbuntu 24.04 LTS وتفترض المستخدم root، وكمستخدم عادي تضعون sudo قبلها.

إذا كان الهجوم جارياً الآن: لا تغيّروا شيئاً في server.cfg ولا تعيدوا تشغيل الخادم. احفظوا أولاً القياسات (انظروا قسم «التسجيل»)، فهي تختفي بعد انتهاء الهجوم.

أي إصدارات Call of Duty تستطيعون حماية خادمها من DDoS

لا تستطيعون حماية خادم Call of Duty من DDoS إلا في الإصدارات التي تتيح خوادم مخصصة خاصة. وهذه هي الإصدارات الأصلية من Call of Duty (2003) وCall of Duty United Offensive وCall of Duty 2 وCall of Duty 4 Modern Warfare وCall of Duty World at War، إضافةً إلى منصات المجتمع Plutonium (World at War وBlack Ops وBlack Ops II وModern Warfare 3) وIW4x (Modern Warfare 2) وCoD4X (Call of Duty 4). وكل هذه الإصدارات تحمل النمط نفسه: ملف server.cfg، ومنفذ UDP مفتوح، وإدراج في قائمة خوادم عامة.

أما الأجزاء الحديثة فلا يسري عليها هذا المقال صراحةً. فـ Warzone وModern Warfare (2019) وBlack Ops Cold War وVanguard وModern Warfare II وModern Warfare III وBlack Ops 6 لا تعرف خوادم مخصصة قابلة للاستئجار: فالجولات تعمل على بنية Matchmaking التابعة لـ Activision، ولا يوجد ملف server.cfg، ولا متصفح خوادم، ولا منفذ تستطيعون فتحه أو تأمينه. وقوائم المنافذ التي تنشرها Activision لهذه الإصدارات (ومنها TCP 3074 و27014 حتى 27050، وكذلك UDP 3074 و3478 و27000 حتى 27031) تصف منافذ العميل والمنصة، لا منافذ الخادم. ومن يعاني في Warzone من انقطاعات في الاتصال فلديه مشكلة في وصلته الخاصة أو مشكلة لدى Activision، لكن ليست مشكلة يحلها خادم مستأجر.

لماذا تُهاجَم خوادم Call of Duty على وجه الخصوص

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

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

المنافذ التي يتعلق بها الأمر فعلاً

يحتل خادم Call of Duty الكلاسيكي منفذ UDP واحداً بالضبط، وهو 28960. وعلى هذا المنفذ الواحد تعمل ثلاثة أمور في وقت واحد: حركة اللعب، واستعلامات الحالة القادمة من قائمة الخوادم، وأداة التحكم عن بعد RCON. ولا يوجد منفذ استعلام مستقل ولا منفذ RCON مستقل. وسطر تشغيل الخادم المخصص يبدو واحداً في كل الإصدارات، ولا يختلف سوى اسم الملف التنفيذي:

+set dedicated 2 +set net_ip 0.0.0.0 +set net_port 28960 +set sv_maxclients 32 +exec server.cfg +map_rotate

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

المقادير المعتادة في Call of Duty

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

لماذا تقع اللعبة والاستعلام وRCON على المنفذ نفسه

هذه هي الخصوصية الحاسمة في Call of Duty. فمحرّك id Tech 3، الذي تُبنى عليه جميع إصدارات Call of Duty الكلاسيكية، لا يعرف منافذ منفصلة للعبة والاستعلام والتحكم عن بعد. فكل شيء يجري عبر ما يسمى حزماً بلا اتصال على المنفذ UDP الواحد. والحزمة بلا اتصال هي حزمة UDP تبدأ بأربعة بايتات 0xFF وتحمل بعدها اسم الأمر بنص صريح: getstatus أو getinfo أو getchallenge أو connect أو rcon.

والنتيجة العملية غير مريحة: لا تستطيعون فصل RCON عن اللعبة بجدار الحماية دون حجب اللعبة معه. فالقاعدة الموضوعة على المنفذ 28960 تصيب كل شيء دائماً. ومن يريد فرز إغراق الاستعلامات وهجمات RCON بشكل موجّه، فعليه أن ينظر في محتوى الحزمة لا في رقم المنفذ وحده. ولهذا السبب بالضبط تصل قواعد جدار الحماية القائمة على المنافذ في Call of Duty إلى حدها أبكر مما تصل في الألعاب التي تملك منفذ استعلام منفصلاً.

ما هو انعكاس getstatus في Call of Duty؟

انعكاس getstatus هو هجوم تضخيم يرسل فيه المهاجم استعلامات حالة صغيرة بعنوان مرسل مزيف إلى خوادم ألعاب كثيرة، لكي تصل أجوبتها الأكبر بكثير إلى الضحية الحقيقية. وخوادم الألعاب هنا ليست الهدف، بل المُضخِّم. وهذا المتجه موثّق لمحرّك id Tech 3 منذ أكثر من عقد، ويصيب Call of Duty كما يصيب Quake 3 وبقية مشتقاته.

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

كيف تبدو حزمة getstatus

يتكوّن الطلب من أربعة بايتات 0xFF ومن كلمة getstatus، أي 13 بايت حمولة في المجموع. ومع ترويستي IP وUDP يصبح ذلك 41 بايت على الوصلة. وهذا بالضبط ما يستهدفه فحص الطول في قواعد جدار الحماية التي تتناقلها منتديات Call of Duty منذ سنوات:

iptables -A INPUT -p udp -m length --length 41:45 -m recent --set --name getstatus_cod
iptables -A INPUT -p udp -m string --algo bm --string "getstatus" -m recent --update --seconds 1 --hitcount 20 --name getstatus_cod -j DROP

أما الجواب فهو أكبر بما لا يُقاس. فالحزمة statusResponse تحتوي على إعداد الخادم بكامله كسلسلة نصية، إضافةً إلى سطر لكل لاعب متصل، أي عدة كيلوبايتات عندما يكون الخادم ممتلئاً. وتُدرج CISA بروتوكول شبكة Quake في نظرتها العامة على هجمات تضخيم UDP (التحذير TA14-017A) بمعامل تضخيم يبلغ 63.9، وتسمّي صراحةً تبادل معلومات الخادم كالأمر الذي يُساء استخدامه. وبذلك يتحول 1 Mbit/s من الطلبات المزيفة إلى نحو 64 Mbit/s عند الضحية. وللمقارنة: يقع DNS في النظرة العامة نفسها بين 28 و54، ويقع NTP عند 556.9.

المكابح المدمجة: sv_queryIgnoreTime وsv_queryIgnoreMegs

يملك Call of Duty 4 منذ إصدار الخادم 1.7 مكابح استعلام مدمجة. فهي تتذكر كل عنوان أرسل استعلام حالة، وتتجاهل الاستعلامات الأخرى القادمة من العنوان نفسه لمدة قابلة للضبط. وأربعة إعدادات Dvar تتحكم في ذلك، بالقيم الافتراضية التالية:

sv_queryIgnoreMegs        1
sv_queryIgnoreTime        2000
sv_queryBounceIgnoreTime  12000
sv_queryIgnoreDebug       0

يحدد sv_queryIgnoreMegs حجم الذاكرة الذي يحق لقائمة التجاهل أن تحتله. وميغابايت واحد يتسع لنحو 65,000 عنوان، وكل ميغابايت إضافي لنحو 87,000 عنوان إضافي. والقيمة 0 تعطّل المكابح بالكامل، وهذا هو الحال بالضبط على خوادم كثيرة، لأن الإعداد مأخوذ من قالب قديم. والإعداد sv_queryIgnoreTime هو مدة الحجب بالميلي ثانية. ويعمل sv_queryBounceIgnoreTime عندما يرتد جواب بالرسالة «ICMP Port Unreachable»، أي بالضبط عندما يُساء استخدام خادمكم كمُضخِّم ضد ضحية غريبة. أما sv_queryIgnoreDebug 1 فيكتب المطابقات في السجل، لكي تروا أصلاً إن كان شيء يحدث.

ومن يستخدم CoD4X يملك إضافةً إلى ذلك حدوداً عليا ثابتة في كود الخادم: 20 جواب getstatus على الأكثر كل 20 ثانية، و100 جواب getinfo على الأكثر كل 100 ثانية، ورسالة خطأ RCON واحدة على الأكثر كل 100 ميلي ثانية. ويسمّي التعليق في الكود المصدري القصد بوضوح: لا مانع من أن يُغرَق الخادم، لكن لا يجوز أن يهدر في ذلك نطاقاً ترددياً صادراً. وهذا ترتيب صحيح للأولويات، لكنه لا يعوّض التصفية قبل الخادم.

لماذا يمثّل RCON في Call of Duty مشكلة تاريخية

RCON هو أداة التحكم عن بعد بالخادم، وهو في Call of Duty حزمة UDP غير مشفّرة على منفذ اللعبة. وأمر RCON يبدو على الوصلة كما يلي: أربعة بايتات 0xFF، ثم كلمة rcon، ثم كلمة المرور بنص صريح، ثم الأمر الفعلي. ولا يوجد تشفير، ولا جلسة، ولا حساب مستخدم، ولا عامل ثانٍ. ويترتب على ذلك ثلاث مشكلات، وكلها واقعية:

• التقاط الحركة. من يرى الحركة في أي موضع على الطريق يقرأ كلمة مرور RCON لديكم بنص صريح. وهذا يسري على كل شبكة بينكم وبين الخادم، وعلى كل أداة تمنحونها كلمة المرور.
• التخمين. لا يوجد تسجيل دخول يمكن حجبه، ولا قفل حساب بعد عشر محاولات فاشلة. فالمهاجم يجرّب كلمات المرور بأي سرعة يريدها. والخادم الأصلي لا يكبح ذلك إطلاقاً، أما CoD4X فيكبح الجواب فقط إلى رسالة خطأ واحدة كل 100 ميلي ثانية ويسجّل المحاولة على أنها «Bad rcon».
• الانعكاس. ورسالة خطأ RCON هي أيضاً جواب على حزمة مزيفة. فمن يقصف خادمكم بحزم RCON مزيفة يستخدمه كمُضخِّم صغير، ويملأ خادمكم في الوقت نفسه سجله بنفسه.

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

ما تستطيعون فعله بأنفسكم قبل أن تدفعوا مالاً

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

1. الجرد: ما الذي يستمع أصلاً؟

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

ss -lntup

المهم هو العمود الذي يحمل العنوان المحلي. فـ 0.0.0.0:28960 و[::]:28960 يعنيان «قابل للوصول من الإنترنت بأكمله»، و127.0.0.1:3306 يعني «محلياً فقط» ولا يحتاج إلى قاعدة في جدار الحماية. وإلى جانب اللعبة تظهر هناك كثيراً أداة IW4MAdmin، وخادم ويب لأجل Fast Download، وقاعدة بيانات للإحصاءات، ونسخة لعب ثانية منسية. أما رؤية المهاجم فيوفرها فحص المنافذ من الخارج:

nmap -Pn -sU -p 28960-28970,4976,27016 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. إبقاء ما تحتاجه اللعبة فعلاً وحده مفتوحاً

يكفي لخادم Call of Duty واحد أن تفتحوا منفذاً واحداً نحو الخارج، وكل ما عداه يُقيَّد أو لا يُنشَر من الأساس. ومع UFW يبدو ذلك على النحو التالي، وبهذا الترتيب بالضبط حتى لا تحجبوا أنفسكم:

ufw allow 22/tcp comment 'SSH'
ufw allow 28960/udp comment 'Call of Duty'
ufw allow from 203.0.113.10 to any port 1624 proto tcp comment 'IW4MAdmin'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

استبدلوا 203.0.113.10 بعنوانكم الخاص. وفي Plutonium T6 يحلّ 4976/udp محل 28960/udp، وفي Plutonium IW5 يكون 27016/udp. وإذا شغّلتم عدة نسخ، فافتحوا المجال المستخدم فعلاً حصراً، أي مثلاً 28960:28962/udp وليس 28960 حتى 28970 جملةً. فكل منفذ لا يستمع عليه شيء ليس بوابة دخول، لكنه يكلّف نواة النظام عملاً في حالة الهجوم على أي حال. والدليل الكامل مع طريق النجاة تجدونه في إعداد جدار حماية UFW دون حجب نفسكم.

3. تشغيل مكابح الاستعلام في server.cfg

هذه الأسطر الأربعة تنتمي إلى كل server.cfg لخادم Call of Duty 4 ولا تكلّف شيئاً سوى بضعة ميغابايتات من الذاكرة:

set sv_queryIgnoreMegs "4"
set sv_queryIgnoreTime "2000"
set sv_queryBounceIgnoreTime "12000"
set sv_queryIgnoreDebug "0"

أربعة ميغابايتات تتسع لنحو 326,000 عنوان، وهذا يكفي حتى لإغراق جدّي. ولا ترفعوا sv_queryIgnoreTime فوق القيمة الافتراضية 2000 ميلي ثانية إلا بحذر: فقائمة الخوادم وكل متصفح خوادم يستعلمان من خادمكم عبر الآلية نفسها، ومن يرفع مدة الحجب أكثر من اللازم يختفي من القائمة. واضبطوا sv_queryIgnoreDebug مؤقتاً على 1 إذا أردتم معرفة ما إذا كانت المكابح تعمل أصلاً، ثم أعيدوه إلى 0 لكي لا يملأ السجل القرص عليكم.

4. فرز إغراق الاستعلامات في جدار الحماية

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

iptables -A INPUT -p udp --dport 28960 -m length --length 41:45 -m recent --set --name cod_query --rsource
iptables -A INPUT -p udp --dport 28960 -m string --algo bm --string "getstatus" -m recent --update --seconds 2 --hitcount 4 --name cod_query --rsource -j DROP

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

وقواعد iptables المجردة تختفي بعد إعادة التشغيل، وتُحفظ على Debian وUbuntu على النحو التالي:

apt-get install -y iptables-persistent
netfilter-persistent save

ومع UFW تنتمي هذه القواعد إلى /etc/ufw/before.rules، لأنها تختفي خلاف ذلك عند ufw reload التالي. وتحقّقوا بعد ذلك بالأمر iptables -L INPUT -n -v مما إذا كانت عدّادات المطابقات ترتفع. فإذا بقيت عند الصفر، فالقاعدة لا يُوصَل إليها.

5. تعطيل RCON أو تشغيله بحدود ضيقة

أكثر وصول RCON أماناً هو الوصول غير الموجود. فقيمة rcon_password الفارغة ترفض كل حزمة RCON:

set rcon_password ""

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

iptables -A INPUT -p udp --dport 28960 ! -s 203.0.113.10 -m string --algo bm --string "rcon " -j DROP

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

6. صد إغراق الانضمام واستنفاد الخانات

لا يستهدف إغراق الانضمام الوصلة، بل منطق اللعبة: فالمهاجم يرسل بتتابع سريع حزم getchallenge وconnect، حتى تُحتل جميع الخانات باتصالات نصف مكتملة. وعندها يحصل اللاعبون الحقيقيون على الرسالة «Server is full»، مع أنه لا يوجد أحد في اللعبة. وتعمل هذه الإعدادات ضد ذلك:

set sv_maxclients "32"
set sv_reconnectLimit "3"
set sv_floodProtect "1"
set sv_connectTimeout "30"
set sv_timeout "120"

يحدد sv_reconnectLimit عدد المرات التي يحق للاعب نفسه أن يعيد فيها الاتصال بشكل متتابع. ويحدد sv_floodProtect عدد أوامر العميل التي يعالجها الخادم لكل لاعب، ويمنع بذلك أن يُبطئ عميل واحد الخادم بالأوامر. ويحدد sv_connectTimeout وsv_timeout المدة التي يحجب فيها اتصال نصف مكتمل أو اتصال صامت خانةً: فمن يترك هنا قيماً سخية مأخوذة من قالب قديم فهو يُسهّل على المهاجم استنفاد الخانات.

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

7. الإدراج في قائمة الخوادم وعنوانكم الخاص

وهنا تستحق الصراحة أكثر من التمنّي: لا يمكن إبقاء عنوان IP الخاص بكم سرّاً. فكل لاعب اتصل مرة يعرفه، والإدراج في القائمة ينشره على أي حال ومعه المنفذ. وتستطيعون تعطيل الإدراج بألّا تضبطوا خادماً رئيسياً في server.cfg (وتُسمّى إعدادات Dvar المعنية sv_master1 وsv_master2 وهكذا). لكن ذلك يكلّفكم كل الظهور أمام اللاعبين الجدد، ولا يفيد إلا ضد أكثر المهاجمين اتكالاً على الراحة.

وملاحظة عن موقع القوائم: الخوادم الرئيسية الأصلية لدى Activision (codmaster.activision.com على 20510، وcod2master.activision.com على 20710، وcod4master.activision.com على 20810) لم تعد تجيب عن شيء للإصدارات القديمة. ومن يريد أن يكون مُدرَجاً اليوم يستخدم قوائم المجتمع: فـ CoD4X يشغّل قائمة خاصة به ويشترط لذلك رمزاً في sv_authtoken، وPlutonium يأتي بقائمة خوادم خاصة به. وهذا لا يغيّر شيئاً في جوهر الأمر، فالعنوان مكتوب هناك بنص صريح كما هو.

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

8. إخراج الواجهات الوِبّية وقاعدة البيانات وFast Download من الشبكة المفتوحة

إلى جانب اللعبة يعمل على معظم خوادم Call of Duty ما هو أكثر من ذلك: أداة IW4MAdmin بواجهتها الوِبّية على المنفذ 1624، وخادم ويب لأجل Fast Download للخرائط، وأحياناً قاعدة بيانات للإحصاءات. وكل خدمة من هذه سطح هجوم مستقل، ولا تنتمي أي منها إلى الشبكة المفتوحة دون قيود.

قيّدوا المنفذ 1624 على عنوانكم الخاص، أو صِلوا إلى الواجهة عبر تمرير SSH وافتحوا بعد ذلك محلياً http://127.0.0.1:1624:

ssh -N -L 1624:127.0.0.1:1624 root@YOUR.SERVER.IP.ADDRESS

واربطوا قاعدة البيانات على 127.0.0.1، فلا شأن لها بالشبكة المفتوحة بأي حال. وضعوا Fast Download على خادم ويب مستقل بدلاً من وضعه في عملية اللعبة: فخادم الويب تحت الحِمل يسلب اللعبة خلاف ذلك وقت المعالجة الذي تحتاجه للمحاكاة بالضبط.

9. التسجيل، حتى تملكوا بيانات عند الجدّ

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

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 udp port 28960 -c 200 -q

ولأجل Call of Duty يوجد أمر خامس يجيب عن السؤال الحاسم. فهذا التسجيل يُظهر الحزم بلا اتصال حصراً، أي بالضبط getstatus وgetinfo وgetchallenge وconnect وrcon:

tcpdump -ni eth0 'udp port 28960 and udp[8:4] = 0xffffffff' -c 200 -A

فإذا ظهرت هناك كلمة getstatus مئات المرات من عناوين جديدة دائماً، فلديكم إغراق استعلامات. وإذا ظهرت هناك كلمة rcon، فأحدهم يحاول تخمين كلمة مروركم. وإذا ظهرت هناك getchallenge وconnect فقط، فهو إغراق انضمام. وفي tcpdump تسري قاعدة ثابتة دائماً: قيّدوا بالمعامل -c، فالتسجيل تحت الحِمل الكامل يُثقل خادماً مُثقلاً أصلاً. وكيف تحلّلون القيم يوضحه المقال كشف هجوم DDoS.

أين تنتهي هذه الإجراءات

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

احسبوا معنا مرة. خادم ممتلئ بـ 32 خانة يولّد صادراً نحو 6.4 Mbit/s، أي أقل من واحد بالمئة من وصلة بسرعة جيغابت. والوصلة نفسها تمتلئ بمجرد أن يرسل أحد 125 ميغابايت في الثانية، وهذا بالضبط ما تُصمّم عليه الهجمات التي يمكن طلبها بعشرة يوروهات في الشهر. وعندها لا يعود مهماً إن كانت قاعدة iptables لديكم جيدة أم لا، لأن حزم لاعبيكم لا تمر من قبل ذلك.

والمقدار الثاني هو معدل الحزم، وهو يضرب في Call of Duty بانتظام أبكر من النطاق الترددي. فمع الحزم الصغيرة بحجم 64 بايت تتسع وصلة بسرعة 1 Gbit/s لنحو 1.49 مليون حزمة في الثانية. أما نواة النظام العادية فتعالج، حسب المعالج وبطاقة الشبكة، بعض مئات الآلاف منها قبل أن تبدأ بالإسقاط. وطلب getstatus أصغر من ذلك أيضاً بحجمه البالغ 41 بايت: فهجوم لا يملأ وصلتكم حتى إلى الثلث يُعطّل خادمكم مع ذلك، لأن وقت المعالجة كله يذهب إلى الإسقاط. ويعيش المشغّلون ذلك على شكل «الاستخدام لم يكن مرتفعاً أصلاً، ومع ذلك ضاع كل شيء».

ويُضاف في Call of Duty خصوصية تزيد الحساب سوءاً. فلأن اللعبة والاستعلام وRCON تقع على المنفذ نفسه، لا تستطيعون إغلاق 28960 عند الضرورة: فذلك يعني إيقاف الخادم. ولأن المحرّك يجيب عن كل استعلام حالة بأضعاف حجم الطلب، يستهلك المهاجم نطاقاً ترددياً خاصاً أقل مما يستهلكه في ألعاب أخرى للأثر نفسه.

ولوضع الأمر في سياقه، أي أي المقادير تحدث فعلاً: صُفّي على خوادم KernelHost، في جملة ما صُفّي، هجوم بأكثر من 473.4 Gbit/s وبأكثر من 41.5 مليون حزمة في الثانية على خادم صوت، وإغراق UDP بأكثر من 112.2 Gbit/s على خادم لعب. ولا يوجد لذلك إعداد محلي. فالهجمات الحجمية يجب أن تنتهي في الشبكة الواقعة قبل الخادم.

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

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

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

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

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

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

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

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

وتتوجه Advanced DDoS Protection إلى الخوادم القائمة لدى KernelHost. فإذا كان خادم Call of Duty الخاص بكم يعمل حالياً في مكان آخر ويُسحب هناك من الشبكة بانتظام، فالانتقال إلى KernelHost هو الطريق الذي يغيّر شيئاً.

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

ولمعظم خوادم Call of Duty تكفي الحماية الدائمة المشمولة مع ملف server.cfg نظيف. أما Advanced DDoS Protection فهي الجواب على أن يأخذ أحدهم الأمر على المستوى الشخصي.

أخطاء شائعة وحلولها

«غيّرت عنوان IP وكنت بعد ساعتين غير متصل من جديد»: المهاجم حصل على العنوان الجديد من المصدر نفسه الذي حصل منه على القديم، وهو في الغالب الإدراج في القائمة، أو بوت Discord يعرض الحالة، أو مُدخَل DNS قديم. فتغيير العنوان كسب للوقت، لا حلٌّ.

«مزودي يرسل لي إشعار إساءة استخدام، مع أنني الضحية»: إذاً فخادمكم ليس الهدف، بل المُضخِّم. فأحدهم يرسل طلبات getstatus مزيفة، وخادمكم يجيب بكل طيبة إلى ضحية غريبة. تحقّقوا أولاً مما إذا كان sv_queryIgnoreMegs على 0، واضبطوا إعدادات Dvar الأربعة الخاصة بالاستعلام وقاعدة جدار الحماية الواردة في القسم 4.

«الخادم مُدرَج في القائمة كممتلئ، لكنه فارغ»: هذا إغراق انضمام، وهو يصيب منطق اللعبة لا الوصلة. وتعمل ضده الإعدادات sv_reconnectLimit، وقيم أقصر لـ sv_connectTimeout وsv_timeout، وعند الشك كلمة مرور للخادم.

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

«قواعد iptables لدي لا تعمل»: ثلاثة أسباب شائعة. القواعد موضوعة بعد سلاسل UFW ولا يُوصَل إليها أبداً، أو أنها اختفت بعد إعادة التشغيل الأخيرة (وهنا يفيد netfilter-persistent save أو مُدخَل في /etc/ufw/before.rules)، أو أن الهجوم حجمي والقاعدة تعمل بشكل صحيح على وصلة ممتلئة أصلاً. تحقّقوا بالأمر iptables -L INPUT -n -v مما إذا كانت عدّادات المطابقات ترتفع.

«الخادم يعمل، لكن جميع اللاعبين يعانون من قفزات في التأخير»: انظروا أولاً إلى معدل الحزم على الواجهة، لا إلى حِمل المعالج. فإذا بقي sar -n DEV 1 10 عادياً وتقطّعت اللعبة مع ذلك، فالسبب في الغالب إضافة، أو قيمة sv_maxRate مبالغ فيها، أو بساطةً عدد كبير جداً من البوتات في الجولة.

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

«لا أرى في tcpdump شيئاً ملحوظاً»: إذا كانت الحركة تُصفّى في الشبكة الواقعة قبل الخادم، فلا يصل إلى الخادم شيء كما هو متوقع. وهذه هي الحالة الطبيعية عند عمل التصفية. وفي المقابل: إذا كانت الوصلة مشبعة، فقد لا تصلكم حتى جلسة SSH التي أردتم القياس بها. استخدموا في هذه الحالة وحدة تحكم VNC في منطقة العملاء، فهي تعمل بشكل مستقل عن شبكة النظام الضيف.

باختصار

• يحتاج خادم Call of Duty الكلاسيكي إلى منفذ مفتوح واحد بالضبط: 28960 UDP. وفي Plutonium T6 يكون 4976 UDP، وفي Plutonium IW5 يكون 27016 UDP.
• تقع اللعبة واستعلام الحالة وRCON في Call of Duty على المنفذ نفسه. ولا تستطيعون فصل RCON عن اللعبة بقاعدة قائمة على المنفذ، بل تحتاجون لذلك إلى قاعدة تنظر في محتوى الحزمة.
• انعكاس getstatus هو متجه التضخيم النموذجي لهذه اللعبة: 41 بايت طلباً، ووفق تحذير CISA رقم TA14-017A معامل 63.9 لبروتوكول شبكة Quake، أي نحو 2,600 بايت جواباً.
• شغّلوا مكابح الاستعلام: sv_queryIgnoreMegs 4 وsv_queryIgnoreTime 2000 وsv_queryBounceIgnoreTime 12000. فهي على خوادم كثيرة مضبوطة على 0 وبذلك معطّلة.
• لا تضبطوا rcon_password إلا إذا كنتم تحتاجون RCON فعلاً: فكلمة المرور تمر غير مشفّرة عبر UDP ويمكن تخمينها بلا حدود دون قفل للحساب.
• منفذا الخادم الرئيسي 20810 و20800 منفذا هدف صادران ولا ينتميان إلى فتحاتكم الواردة.
• من نحو 1 Gbit/s أو بعض مئات الآلاف من الحزم في الثانية، تحسم الشبكة الواقعة قبل الخادم وحدها، لا إعداداتكم.

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