حماية خادم Unturned من هجمات DDoS

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

جميع المعطيات تتعلق بخادم Unturned المخصص (U3DS، تطبيق SteamCMD رقم 1110390) يعمل بنظام ⁦Debian 12⁩ أو ⁦Debian 13⁩ أو ⁦Ubuntu 22.04 LTS⁩ أو ⁦Ubuntu 24.04 LTS⁩. والأوامر مكتوبة للمستخدم root، وكمستخدم عادي تضعون sudo قبلها. وإذا كان الهجوم جارياً الآن، لا تغيّروا شيئاً في الإعدادات أولاً ولا تعيدوا تشغيل الخادم: احفظوا القياسات (القسم 10)، فهي تختفي بعد انتهاء الهجوم.

لماذا تُهاجَم خوادم Unturned على وجه الخصوص

تُهاجَم خوادم Unturned لأن عنوانها علني، ولأن حركة اللعب تعمل عبر UDP، ولأن الهجوم لا يكلّف من يطلقه مهارةً ولا مالاً يُذكر. والنقاط الثلاث كلها تسري هنا بقوة أكبر من معظم الألعاب الأخرى.

فخادم Unturned العام ينشر عنوان IP الخاص به من تلقاء نفسه. وهو مضطر إلى ذلك، وإلا لم يجده أحد: فمتصفح خوادم Steam يستعلم منه مباشرةً، والقوائم الخارجية مثل unturned-servers.net أو BattleMetrics تسجّل عنوان IP والمنفذ بنص صريح. ويفحص unturned-servers.net لذلك، وفق ما يذكره بنفسه، كل خمس دقائق ما إذا كان الخادم يقبل اتصالات UDP على منفذ الخادم. وهذا بالنسبة للمهاجم ليس جهداً، بل استمارة.

ويُضاف إلى ذلك جمهور اللاعبين. فـUnturned مجانية، وعتبة الدخول عند الصفر، وبين مشاريع لعب الأدوار والنجاة منافسة حقيقية على اللاعبين أنفسهم. ولا يحتاج لاعب محظور، أو مسؤول سابق مجروح، أو مشروع مجاور، إلى أي وصول إلى خادمكم لكي يجعله غير قابل للاستخدام لساعة. وما هو هجوم DDoS تقنياً ولماذا تجعل عناوين المرسل المزيفة تعقّبه بهذه الصعوبة، يشرحه المقال ما هو هجوم DDoS؟.

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

يحتل خادم Unturned منفذي UDP متتاليين بالضبط: القيمة المضبوطة في Commands.dat، وهذه القيمة زائد واحد. وفي الإعداد الافتراضي هما 27015 و27016. وتصف الوثائق الرسمية لشركة Smartly Dressed Games التقسيم على هذا النحو: المنفذ الأول يحمل استعلامات قائمة الخوادم، والثاني يحمل حركة اللعب. ولا يُضبط إلا الأول، أما الثاني فينتج آلياً.

Name خادم Unturned الخاص بي
Port 27015
MaxPlayers 24
Map PEI
Mode Normal
Perspective Both
Owner 76561198000000000

والملف Commands.dat موجود في U3DS/Servers/<instance>/Server/Commands.dat، وموضع instance هو اسم النسخة. وصيغته خاصة به وهي مصدر خطأ شائع: أمر واحد في كل سطر، دون علامة يساوي، والقيمة مفصولة بمسافة، والأوامر حساسة لحالة الأحرف. والأسطر التي تبدأ بـ// هي تعليقات.

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

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

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

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

1. الجرد: ما الذي يستمع فعلاً

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

ss -lnup
ss -lntp

يُظهر الأمر الأول مقابس UDP المستمعة، ويُظهر الثاني مقابس TCP. والمهم هو العمود الذي يحمل العنوان المحلي. فـ0.0.0.0:27015 و[::]:27015 يعنيان «قابل للوصول من الإنترنت بأكمله»، و127.0.0.1:3306 يعني «محلياً فقط» ولا يحتاج إلى قاعدة في جدار الحماية. وإلى جانب اللعبة تظهر هناك كثيراً إضافة RCON، ولوحة وِبّية، وقاعدة بيانات، وخادم اختبار قديم على 27017 لم يبقَ أحد يستخدمه. أما رؤية المهاجم فيوفرها فحص المنافذ من الخارج، ولأجل Unturned بـUDP صراحةً:

nmap -Pn -sU -p 27000-27050 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. إبقاء 27015 و27016 وحدهما مفتوحين

يكفي Unturned فتحان على UDP نحو الخارج. ولا يحتاج اللعب نفسه إلى منفذ TCP واحد: فالوثائق الرسمية تشترط UDP صراحةً للمنفذين، وطبقة الشبكة في اللعبة (Steam Networking Sockets، وهي الإعداد الافتراضي منذ أحد التحديثات) تعمل عبر UDP حصراً. ومن يفتح TCP إضافةً إلى ذلك فهو يتبع دليلاً قديماً.

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'استعلام Unturned'
ufw allow 27016/udp comment 'لعبة Unturned'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

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

ولا تنتمي اللوحة الوِبّية ولا قاعدة البيانات ولا إضافة RCON إلى الشبكة المفتوحة. قيّدوا المنفذ المعني على عنوانكم الخاص بالأمر ufw allow from 203.0.113.10 to any port 8080 proto tcp، أو صِلوا إلى الواجهة عبر تمرير SSH محلي بالأمر ssh -N -L 8080:127.0.0.1:8080 root@YOUR.SERVER.IP.ADDRESS. وقاعدة البيانات تُربَط على 127.0.0.1.

3. تأمين منفذ الاستعلام دون الطيران من قائمة الخوادم

منفذ الاستعلام هو أكثر نقطة حساسية في خادم Unturned. فعبره يجيب الخادم عن استعلامات Steam وهي A2S_INFO وA2S_PLAYERS وA2S_RULES. وإذا حجبتموه بالكامل، اختفى الخادم من كل قائمة خوادم، حتى لو كان يعمل بلا أي خلل.

وجواب A2S أكبر بكثير من الطلب. ويُدرج US-CERT بروتوكول Steam في نظرته العامة لهجمات التضخيم عبر UDP (التحذير TA14-017A) بمعامل تضخيم للنطاق الترددي يبلغ 5.5. وهذا يعني عملياً: المهاجم يرسل استعلامات بعنوان مرسل مزيف إلى خوادم لعب أجنبية ويوجّه الأجوبة، وهي أكبر بنحو خمسة أضعاف ونصف، إلى هدفه الحقيقي. وخادمكم في هذه الحالة ليس الضحية، بل المُضخِّم ضد طرف ثالث. وفي الاتجاه المقابل يكفي إغراق استعلامات لجعل الخادم يختفي من متصفح الخوادم، دون أن يطير لاعب واحد. ويُبلّغ المشغّلون عن ذلك بالضبط: الخادم يعمل، واللاعبون عليه لا يلاحظون شيئاً، لكنه لم يبقَ قابلاً للعثور عليه.

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

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name unturned_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 27016 -m hashlimit --hashlimit-name unturned_game --hashlimit-mode srcip --hashlimit-above 300/sec --hashlimit-burst 500 -j DROP

والرقم الثاني مشتق مباشرةً من اللعبة: فـUnturned يحدد اللاعب من المصنع بـ50 حزمة في الثانية (Max_Packets_Per_Second). فـ300 حزمة في الثانية لكل عنوان مصدر تترك إذن لاتصال واحد هامشاً وفيراً، حتى لو كان عدة لاعبين يجلسون خلف العنوان نفسه. والقيمتان كلتاهما قيمتا بداية، لا حقيقتان. قيسوا أولاً أسبوعاً في التشغيل الطبيعي، وإلا طردتم لاعبيكم أنفسكم.

وقواعد iptables المجردة تختفي بعد إعادة التشغيل. وعلى Debian وUbuntu تُحفَظ بالأمرين apt-get install -y iptables-persistent وnetfilter-persistent save. ومع UFW تنتمي هذه القواعد إلى /etc/ufw/before.rules، لأنها تختفي خلاف ذلك عند ufw reload التالي.

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

4. ضبط الحدود المدمجة في ملف Config.json

يأتي Unturned في الملف Config.json الموجود في مجلد Server نفسه الذي فيه Commands.dat بقسم أهم للدفاع مما يدل عليه اسمه. والإعدادات الافتراضية هي:

"Server": {
    "VAC_Secure": true,
    "BattlEye_Secure": true,
    "Max_Ping_Milliseconds": 750,
    "Timeout_Queue_Seconds": 15.0,
    "Timeout_Game_Seconds": 30.0,
    "Max_Packets_Per_Second": 50.0,
    "Join_Rate_Limit_Window_Seconds": 40.0,
    "Rate_Limit_Kick_Threshold": 10,
    "Use_FakeIP": false
}

يحدد Max_Packets_Per_Second اللاعب المتصل بـ50 حزمة في الثانية. ويطرد Join_Rate_Limit_Window_Seconds وRate_Limit_Kick_Threshold الاتصال الذي يتجاوز الحد أكثر من عشر مرات خلال 40 ثانية. ويشترط VAC_Secure وBattlEye_Secure نظامي مكافحة الغش كليهما على جهة اللاعب، ويُبعدان بذلك الجزء الأكبر من العملاء المؤقتين.

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

5. تخفيف الحِمل عن تتبّع الاتصالات

تُغفَل هذه النقطة دائماً تقريباً، وهي تفسّر انقطاعات تبدو كهجوم حجمي لكنها ليست كذلك. فنواة النظام تُنشئ مُدخلات في تتبّع الاتصالات (conntrack) لحركة UDP أيضاً، وعند عناوين المرسل المزيفة يعني كل عنوان جديد مُدخَلاً جديداً. وإذا امتلأ الجدول، أسقطت نواة النظام الحزم دون تمييز: فالهجوم ولاعبوكم يطيرون معاً. ويظهر في سجل النظام عندها nf_conntrack: table full, dropping packet.

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
dmesg -T | grep -i conntrack

وأكثر خطوة فعالية هي ألّا تُترك حركة Unturned لتُتتبَّع من الأساس. فاللعبة تدير جلساتها بنفسها ولا تحتاج إلى تتبّع حالة في نواة النظام:

iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK
iptables -t raw -A PREROUTING -p udp --dport 27016 -j NOTRACK

وانتبهوا إلى أن فتحاتكم لهذين المنفذين لا يحق لها بعد ذلك أن تعمل عبر ESTABLISHED,RELATED، بل يجب أن تقف كقواعد قبول خاصة بها. وبعد ذلك فقط يستحق الأمر رفع nf_conntrack_max. فمن يكبّر الجدول أولاً يؤجّل المشكلة دقائق فقط ويستهلك لذلك ذاكرة عمل.

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

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

ضعوا القيم في /etc/sysctl.d/ وشغّلوها بالأمر sysctl --system. وما إذا كانت لازمة تكشفه نواة النظام: فإذا ارتفع UdpRcvbufErrors في nstat -az، أو بقي شيء بشكل دائم في طابور الاستقبال في ss -lunp، فهي تعمل. وإذا بقي الاثنان عند الصفر، فالتعديل لا يغيّر شيئاً. فهذا احتياط، لا حماية.

6. إغراق الانضمام وقائمة الانتظار والقائمة البيضاء

إغراق الانضمام هو هجوم يستخدم فيه المهاجم طريق الانضمام النظامي لاستهلاك الخانات ووقت المعالجة، بدلاً من ملء الوصلة. ويأتي Unturned في المقابل بأربع أدوات، وكلها موجودة في Commands.dat:

• Queue_Size 32 يضبط قائمة الانتظار. والإعداد الافتراضي 8 أماكن، والحد الأقصى 64. وقائمة الانتظار الكبيرة جداً تفيد المهاجم، والصغيرة جداً تُسقط لاعبين حقيقيين عند كل إعادة تشغيل.
• Whitelisted يحوّل الخادم إلى قائمة وصول. ويُسجَّل عبر وحدة التحكم بالأمر permit <SteamID64>، ويُحذَف بالأمر unpermit <SteamID64>.
• Password YourPassword يستبعد كل من لا يملك غير العنوان المأخوذ من قائمة.
• Filter يرفض اللاعبين الذين تحمل أسماؤهم رموزاً غير مسموحة، وMaxPlayers 24 يُبقي عدد الخانات عند ما يحمله العتاد فعلاً.

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

7. RocketMod وOpenMod وجهة الإضافات

لـUnturned منصتا إضافات شائعتان، وكلتاهما تعمل في العملية نفسها التي يعمل فيها الخادم. وRocketMod هي الأقدم: فقد أوقف المشرفون الأصليون صيانتها في 20 ديسمبر 2019 ووضعوا الشيفرة المصدرية تحت رخصة MIT. وتتولى Smartly Dressed Games منذ ذلك الحين صيانة الفرع Legally Distinct Missile (LDM)، وهو يُسلَّم أصلاً مع الخادم المخصص: فيُنسَخ Rocket.Unturned من المجلد Extras إلى المجلد Modules. ويوصي المطورون بهذا الفرع صراحةً، لأنه يعالج مشكلات Rocket القديمة مثل أخطاء المسارات المتعددة وثغرات الانتقال الآني.

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

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

ثانياً: لأن Unturned لا يملك منفذ RCON خاصاً به، فكل تحكم عن بعد يأتي من إضافة. تحقّقوا بعد التثبيت بالأمر ss -lntp من منفذ TCP الذي فتحته، وقيّدوه على عنوانكم الخاص. فمنفذ تحكم عن بعد مفتوح بكلمة مرور ضعيفة ليس مشكلة DDoS، بل مشكلة استيلاء.

8. محتويات Workshop وعملية الانضمام

تجعل محتويات Workshop الانضمام مكلفاً، وهذا يؤثر مباشرةً في قابلية الخادم للهجوم. ويُتحكَّم في ذلك عبر الملف WorkshopDownloadConfig.json في مجلد Server نفسه:

{
    "File_IDs": [],
    "Ignore_Children_File_IDs": [],
    "Query_Cache_Max_Age_Seconds": 600,
    "Max_Query_Retries": 2,
    "Use_Cached_Downloads": true,
    "Should_Monitor_Updates": true,
    "Shutdown_Update_Detected_Timer": 600
}

وفي File_IDs تُوضع معرّفات Workshop الخاصة بالخرائط والتعديلات. وعند التشغيل ينزّلها الخادم مع تبعياتها، وكل لاعب ينزّلها آلياً عند الاتصال. وثلاث نتائج ينبغي أن تعرفوها. أولاً، يطول الانضمام عند قوائم التعديلات الكبيرة، وبعد الهجوم يعود جميع اللاعبين في وقت واحد، وهذا يُحمّل الخادم مرة ثانية. وثانياً، يوقف Should_Monitor_Updates الخادم بمجرد تحديث أحد ملفات Workshop: فالقيمة الافتراضية لـShutdown_Update_Detected_Timer وهي 600 ثانية تؤدي عندها إلى إعادة تشغيل يعتبرها المشغّلون بانتظام نجاحاً للهجوم في حالة وجود هجوم. وثالثاً، كل تعديل هو شيفرة أجنبية على خادمكم.

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

9. قائمة الخوادم ورمز الخادم وخاصية العنوان الوهمي

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

ولأجل التشغيل على الإنترنت تحتاجون على أي حال إلى رمز دخول خادم اللعب (GSLT) من إدارة خوادم Steam لمعرّف التطبيق 304930. وهو يضمن إضافةً إلى ذلك أن يبقى رمز الخادم الخاص بخادمكم كما هو عبر إعادات التشغيل، بدلاً من أن يُولَّد من جديد عند كل تشغيل.

ويقدّم Unturned كذلك خاصية العنوان الوهمي (Fake IP). وتُشغَّل بالإعداد "Use_FakeIP": true في Config.json، وأمر وحدة التحكم CopyFakeIP يقدّم العنوان الذي تنشرونه بعد ذلك. وتسير الحركة بعدها عبر شبكة الترحيل Steam Datagram Relay، والعناوين الممنوحة تقع في المجال من 169.254.0.0 حتى 169.254.255.255، ولا يُعرَض عنوان الخادم الحقيقي على اللاعبين بعد ذلك. وتصف Valve هذه الحركة بأنها موثَّقة ومشفَّرة ومحدودة المعدل.

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

10. التسجيل، حتى لا تخمّنوا أثناء الهجوم

أهم خطوة هي تلك التي لا يفعلها أحد تقريباً مسبقاً: إنشاء خط أساس للمقارنة ما دام كل شيء يعمل بشكل طبيعي. فبدون قيمة طبيعية لا تستطيعون القول بعد الحادث إن 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 portrange 27015-27016 -c 200 -q

وفي tcpdump تسري قاعدة ثابتة: قيّدوا دائماً بالمعامل -c، فالتسجيل تحت الحِمل الكامل يُثقل خادماً مُثقلاً أصلاً. وكيف تحلّلون القيم وتميّزون الهجوم عن خطأ برمجي يوضحه المقال كشف هجوم DDoS على الخادم.

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

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

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

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

ولتقدير المقادير التي تحدث فعلاً: على خوادم 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 EUR⁩ في الشهر، بنظام PrePaid، دون حد أدنى لمدة الالتزام ودون رسوم إعداد. والفرق ليس في سعة أكبر، بل في التحكم:

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

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

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

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

«دليلي يقول إنني يجب أن أفتح من 27015 حتى 27017»: الدليل أقدم من نوفمبر 2021. فمنذ الإصدار 3.21.30.0 لم يبقَ خادم Unturned يحتاج غير منفذين، لأن استعلام Steam لم يبقَ على المنفذ زائد اثنين. أغلقوا 27017، إلا إذا كانت تعمل هناك نسخة ثانية.

«الخادم يعمل، لكنه لم يبقَ في أي قائمة خوادم»: هذه هي الصورة النموذجية لإغراق استعلامات أو لقاعدة خاصة بكم حادة جداً على ⁦27015 UDP⁩. تحقّقوا بالأمر iptables -L INPUT -n -v مما إذا كانت قاعدتكم الخاصة تحسب مطابقات. فإذا ارتفعت العدّادات بقوة، فأنتم تُصفّون الآن مُدخلات القوائم الخاصة بكم. لا تحجبوا 27015 بالكامل أبداً.

«جميع اللاعبين يطيرون في وقت واحد بمهلة انتهاء الوقت»: انظروا أولاً ما إذا كان تتبّع الاتصالات قد فاض (dmesg -T | grep -i conntrack). فإذا امتلأ الجدول، أسقطت نواة النظام دون تمييز. والإعداد Timeout_Game_Seconds قيمته من المصنع 30 ثانية: فمن يعود خلال هذه المدة يحتفظ بمكانه.

«الخادم يعيد التشغيل في وسط التشغيل»: هذا نادراً ما يكون هجوماً. تحقّقوا من السجل بحثاً عن رسالة تحديث Workshop المكتشَف. فالإعداد Should_Monitor_Updates يوقف الخادم بعد الفترة الافتراضية وهي 600 ثانية.

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

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

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

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

باختصار

• يحتاج خادم Unturned إلى منفذي UDP مفتوحين بالضبط: المنفذ المضبوط في Commands.dat عبر Port (الإعداد الافتراضي 27015)، وهذه القيمة زائد واحد (27016). أما TCP فلا تحتاجه اللعبة نفسها.
• المنفذ 27017 زائد عن الحاجة منذ الإصدار 3.21.30.0 الصادر في 21 نوفمبر 2021، لأن استعلام Steam لم يبقَ على المنفذ زائد اثنين. ومن يتركه مفتوحاً حتى الآن فهو يتبع دليلاً قديماً.
• Unturned لا يملك منفذ RCON مدمجاً. فكل تحكم عن بعد يأتي من إضافة، ويجرّ معه منفذ TCP خاصاً به، وعليكم أن تقيّدوه بأنفسكم.
• منفذ الاستعلام 27015 هو أكثر نقطة حساسية: فإغراق الاستعلامات يجعل الخادم غير مرئي في قائمة الخوادم دون أن يصيب لاعباً واحداً، وبروتوكول Steam يملك وفق US-CERT TA14-017A معامل تضخيم يبلغ 5.5.
• الحدود الموجودة في Config.json (Max_Packets_Per_Second 50.0، وRate_Limit_Kick_Threshold 10 لكل 40 ثانية) لا تعمل إلا ضد العملاء الذين ينضمون فعلاً، لا ضد عناوين المرسل المزيفة.
• وصلة بسرعة ⁦1 Gbit/s⁩ تمتلئ عند 125 ميغابايت في الثانية، وعند الحزم بحجم 64 بايت تمتلئ أصلاً عند نحو 1.49 مليون حزمة في الثانية. والتشغيل الطبيعي عند 24 لاعباً يقع عند نحو 1,200 حزمة في الثانية. وكل ما يزيد على ذلك تحسمه الشبكة الواقعة قبل الخادم، لا جدار الحماية الخاص بكم.
• لدى KernelHost تكون الحماية الدائمة ذات المستويين مشمولة في كل حزمة خادم دون زيادة في السعر وفعّالة من لحظة التسليم، دون توجيه إلى العدم. ومن يريد التحكم في قواعد التصفية بنفسه يضيف Advanced DDoS Protection ابتداءً من ⁦50.00 EUR⁩ في الشهر.

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