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

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

جميع المعطيات تتعلق بخادم Mordhau المخصص الرسمي (تطبيق Steam رقم 629800، محرك Unreal Engine 4) بنظام Debian 12 أو Debian 13 أو Ubuntu 22.04 LTS أو Ubuntu 24.04 LTS. والأوامر مكتوبة للمستخدم root، وكمستخدم عادي تضعون sudo قبلها. وإذا كان الهجوم جارياً الآن، فلا تغيّروا شيئاً في الإعدادات ولا تعيدوا تشغيل الخادم، بل احفظوا أولاً القياسات (القسم 9)، فهي تختفي بعد انتهاء الهجوم. ويُضاف في Mordhau سبب ثانٍ يتعلمه كثير من المشغّلين بشكل مؤلم: فعملية الخادم تكتب عند الإيقاف حالتها من الذاكرة إلى الملف Game.ini. ومن يعدّل الملف والخادم يعمل يفقد تعديلاته عند الإيقاف التالي.

لماذا تحتاج خوادم Mordhau إلى حماية من DDoS ومن يهاجمها

تُهاجَم خوادم Mordhau لأن عنوانها علني، ولأن حركة اللعب كلها تجري عبر UDP، ولأن أي انقطاع يصبح مرئياً للجميع فوراً. فالإدراج في متصفح الخوادم يحتوي على عنوان IP ومنفذ اللعبة بنص صريح، وإلا لما استطاع اللاعبون العثور على الخادم. وتسحب قوائم الخوادم العامة وأدوات التتبع المعطيات نفسها عبر منفذ استعلام Steam وتنشرها مرة ثانية. وبذلك لا يكون عنوانكم سراً، بل معطىً من معطيات المنتج.

ويُضاف إلى ذلك أسلوب عمل اللعبة. ينقل Unreal Engine 4 الحركات والإصابات وصدّ الضربات عبر UDP. ولا يعرف UDP أي إنشاء اتصال يمكن اشتراطه، وعنوان مرسل حزمة UDP قابل للتزييف. فلا يحتاج المهاجم إلى الدخول إلى خادمكم ولا إلى مخاطبته بشكل صحيح لكي يولّد حِملاً. وفي Mordhau يكون وزن ذلك أثقل منه في كثير من الألعاب الأخرى: فتبادل الضربات يُحسَم في نطاق أعشار الثانية، وزيادة تأخير قدرها 200 ميلي ثانية تكفي لتجعل القتال القريب غير قابل للعب، وذلك قبل أن يسقط الخادم فعلاً بوقت طويل. ولهذا السبب بالضبط يكفي هجوم صغير لتدمير جولة كاملة. وما هو هجوم DDoS بالتفصيل يشرحه المقال ما هو هجوم DDoS؟.

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

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

يحتاج خادم Mordhau المخصص إلى أربعة منافذ UDP بالضبط نحو الخارج: 7777 و7778 و15000 و27015. وكل ما عدا ذلك إما اختياري وإما لا ينتمي إلى الشبكة المفتوحة. وتُمرَّر المنافذ عند التشغيل كمعاملات:

./MordhauServer.sh FFA_ThePit -log -Port=7777 -QueryPort=27015 -BeaconPort=15000 -RconPort=27020

وأمران يُفهَمان خطأً بانتظام هنا. أولاً: منفذ beacon رقم 15000 ليس أمراً ثانوياً. فالـbeacon يحجز الخانة في اللحظة التي ينضم فيها اللاعب، حتى لا يخرج منها مرة أخرى بعد تحميل الخريطة. فإذا كان 15000 محجوباً أو مُثقلاً، لم يعد اللاعبون يدخلون، رغم أن المنفذ 7777 يجيب. وثانياً: RCON غير مُعَدّ مسبقاً في Mordhau. فهو لا يعمل إلا إذا ضبطتم RconPassword وRconPort، ويعمل بعد ذلك عبر TCP لا عبر UDP.

وأهم مؤشرات خادم Mordhau في نظرة واحدة:

أنماط الهجوم التي تحدث في Mordhau

أربعة أنماط تغطي عملياً كل ما يُشَنّ على خادم Mordhau، وكل نمط منها يصيب منفذاً آخر.

• إغراق UDP على منفذ اللعبة 7777. وهذا هو الهجوم القياسي لأي booter: أكبر عدد ممكن من الحزم المزيفة على المنفذ المكتوب في متصفح الخوادم. وهو يستهدف النطاق الترددي ومعدل الحزم، لا ثغرةً ما، ويظهر أولاً على شكل قفزات في التأخير، وذلك قبل أن يفقد أحد اتصاله بوقت طويل.
• إغراق الاستعلامات على منفذ الاستعلام 27015. فاستعلام A2S_INFO حجمه 25 بايت، والجواب الذي يحمل اسم الخادم والخريطة وطور اللعب وعدد اللاعبين أضعاف ذلك. وبذلك يستثمر المهاجم قليلاً ويفرض عليكم عمل معالجة وحركة صادرة.
• الانعكاس عبر منفذ الاستعلام الخاص بكم. وهنا لا يكون خادمكم هو الهدف، بل الأداة: فالمهاجم يرسل استعلامات بعنوان مرسل مزيف، وخادمكم يجيب الضحية. وتلاحظون ذلك على شكل حركة صادرة مرتفعة بشكل غير مفهوم على 27015، وعلى شكل بلاغ إساءة استخدام من مزودكم.
• إغراق الانضمام واستنفاد الخانات عبر منفذ beacon رقم 15000. فبدلاً من إحراق النطاق الترددي، تحتل انضمامات آلية الخانات المحجوزة. ويستمر الخادم في العمل، لكنه يبدو ممتلئاً، ولم يعد اللاعبون الحقيقيون يدخلون.

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

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

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

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

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

ss -lntup

المهم هو العمود الذي يحمل العنوان المحلي. فـ0.0.0.0:7777 و[::]:7777 يعنيان «قابل للوصول من الإنترنت بأكمله»، و127.0.0.1:27020 يعني «محلياً فقط» ولا يحتاج إلى قاعدة في جدار الحماية. وإلى جانب اللعبة تظهر هناك غالباً لوحة ويب وخدمة قاعدة بيانات وخدمة صوت منسية منذ زمن. أما رؤية المهاجم فيوفرها فحص من الخارج، ويجري على UDP بقائمة منافذ قصيرة، لأن فحص UDP الكامل بطيء جداً:

nmap -Pn -sU -p 7777,7778,15000,27015 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. إبقاء المنافذ الأربعة التي يحتاجها Mordhau فعلاً وحدها مفتوحة

تكفي لـMordhau أربع إتاحات على UDP نحو الخارج، وكل ما عداها يُقيَّد أو لا يُنشَر من الأصل. ومع UFW يبدو ذلك على النحو التالي، وبهذا الترتيب بالضبط حتى لا تحجبوا أنفسكم:

ufw allow 22/tcp comment 'SSH'
ufw allow 7777/udp comment 'Mordhau: اللعبة'
ufw allow 7778/udp comment 'Mordhau: Steam'
ufw allow 15000/udp comment 'Mordhau: beacon'
ufw allow 27015/udp comment 'Mordhau: الاستعلام'
ufw allow from 203.0.113.10 to any port 27020 proto tcp comment 'Mordhau: RCON'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

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

3. تهدئة منفذ الاستعلام 27015 دون السقوط من قائمة الخوادم

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

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name mh_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

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

iptables -L INPUT -n -v | head -20
tcpdump -ni eth0 udp port 27015 -c 200 -q

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

4. إخراج RCON من الشبكة المفتوحة

لا ينتمي RCON في Mordhau بأي حال إلى الإنترنت بلا قيود. ويُشغَّل الوصول في الملف Game.ini، في القسم [/Script/Mordhau.MordhauGameSession]:

[/Script/Mordhau.MordhauGameSession]
ServerName=My Mordhau Server
MaxSlots=64
ServerPassword=
AdminPassword=YourLongRandomPassword
RconPassword=AnotherLongRandomPassword
RconPort=27020

يتحدث Mordhau بروتوكول Source RCON، أي عبر TCP، ولهذا يعمل مع أي أداة RCON شائعة. وهذا بالضبط ما تستخدمه أيضاً السكربتات التي تجرّب بيانات الدخول. وثلاث قواعد تغطي هذه الحالة. أولاً: RconPassword وAdminPassword كلمتا مرور مختلفتان وطويلتان وعشوائيتان، وليستا تنويعاً على اسم الخادم. ثانياً: تقصرون إتاحة منفذ RCON على عنوانكم الخاص، كما في كتلة UFW أعلاه. ثالثاً، إذا لم يكن لديكم عنوان ثابت: أبقوا المنفذ مغلقاً من الخارج وصِلوا إليه عبر تمرير منفذ في SSH، ثم اتصلوا محلياً على 127.0.0.1:27020:

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

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

iptables -I INPUT -p tcp --dport 27020 --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP

5. تأمين منفذ beacon رقم 15000 ضد إغراق الانضمام

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

iptables -I INPUT -p udp --dport 15000 -m hashlimit --hashlimit-name mh_beacon --hashlimit-mode srcip --hashlimit-above 20/sec --hashlimit-burst 40 -j DROP
iptables -I INPUT -p udp --dport 7777 -m hashlimit --hashlimit-name mh_game --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

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

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

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

ومع UFW تنتمي هذه القواعد إلى /etc/ufw/before.rules، لأنها تختفي خلاف ذلك عند ufw reload التالي.

6. الملفان Game.ini وEngine.ini: ما يفيد فعلاً

لـMordhau ملفا إعداد، وكلاهما يقع على Linux في Mordhau/Saved/Config/LinuxServer/، وعلى Windows في Mordhau\Saved\Config\WindowsServer\. ينظّم Game.ini اسم الخادم والخانات وكلمات المرور وقائمة المديرين ودورة الخرائط ومُعرّفات التعديلات من mod.io، وينظّم Engine.ini سلوك الشبكة. ولا تعدّلوا أياً منهما إلا والخادم متوقف، وإلا كتبت عملية الخادم عند الإيقاف حالتها من الذاكرة فوق تعديلاتكم.

وثلاثة إعدادات مهمة فعلاً لسطح الهجوم. أولاً ServerPassword: فهو يُبعد كل من ليس مدعواً، لكنه يكلّف إمكانية العثور العلني، ولا يفيد ضد إغراق المنفذ 7777 على الإطلاق، لأن المهاجم لا يريد الانضمام أصلاً. ثانياً رقم MaxSlots واقعي: فـMordhau مصمم لما يصل إلى 64 لاعباً، وكل خانة إضافية مصدر حزم إضافي يجب أن يخدمه معالجكم. ثالثاً معدل التحديث في Engine.ini:

[/Script/OnlineSubsystemUtils.IpNetDriver]
NetServerMaxTickRate=60
LanServerMaxTickRate=60

[IpDrv.TcpNetDriver]
NetServerMaxTickRate=60

معدل التحديث الافتراضي لخادم Mordhau هو 60. ورفعه إلى 120 يضاعف معدل الحزم لكل لاعب ويضاعف حِمل المعالج، وهو بالضبط ما لا تحتاجونه تحت الهجوم. فخادم بـ64 خانة ومعدل تحديث 120 يولّد في التشغيل الطبيعي بحدود 8,000 حزمة في الثانية لكل اتجاه أصلاً. ومن يتعرض للقصف باستمرار يعمل بمعدل 60 بثبات ملحوظ أكثر مما يعمل بمعدل 120.

7. تخفيف الحِمل عن تتبّع الاتصالات ومخازن الاستقبال المؤقتة

وهناك عنق زجاجة يُغفَل عنه كثيراً، وهو تتبّع الاتصالات في نواة النظام. فهي تحمل مُدخَلاً خاصاً لكل تيار UDP، وإغراقٌ من عشرات آلاف عناوين المرسل المزيفة يملأ الجدول في ثوانٍ. وعندما يمتلئ، يُسقط الخادم الحزم المشروعة أيضاً، ويظهر في السجل «nf_conntrack: table full». والوضع الحالي والحد الأعلى يُظهرهما الأمر:

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

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

iptables -t raw -I PREROUTING -p udp --dport 7777 -j NOTRACK
iptables -t raw -I PREROUTING -p udp --dport 15000 -j NOTRACK
iptables -t raw -I PREROUTING -p udp --dport 27015 -j NOTRACK

ومن المفيد كذلك توسيع مخازن الاستقبال المؤقتة وتعميق طابور بطاقة الشبكة، حتى لا تؤدي الذُرى القصيرة إلى الإسقاط فوراً:

sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.rmem_default=4194304
sysctl -w net.core.netdev_max_backlog=5000

وبشكل دائم تنتمي هذه القيم إلى ملف تحت /etc/sysctl.d/، مثل 99-gameserver.conf. والمهم للفهم: المخازن الأكبر لا ترفع قدرتكم على التحمل أمام هجوم كبير، بل تمنع فقط أن تكلّفكم ذروة قصيرة حزماً مفقودة.

8. عنوانكم مكتوب في قائمة الخوادم، وهذا لا يمكن تغييره

وهنا تُجدي الصراحة بدلاً من التفكير الرغبي: عنوان IP لخادم Mordhau عام لا يمكن إبقاؤه سراً. فهو مكتوب في الإدراج في متصفح الخوادم، ومكتوب في قوائم الخوادم العامة لأطراف ثالثة تقرأ منفذ الاستعلام بانتظام، وكل لاعب اتصل مرة واحدة يعرفه. ولهذا يمنحكم تغيير العنوان ساعات، ونادراً أياماً، لأن المهاجم يجد العنوان الجديد بالطريق نفسه الذي وجد به القديم.

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

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 7777 or udp port 15000 or udp port 27015' -c 200 -q

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

أين تنتهي هذه الإجراءات: النطاق الترددي ومعدل الحزم

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

احسبوا معنا مرة. خادم اللعب النموذجي معلّق على 1 Gbit/s، أي 125 ميغابايت في الثانية، والوصلة تمتلئ بمجرد أن يرسل أحد أكثر من ذلك. وخادم Mordhau ممتلئ بـ64 خانة لا يحتاج من ذلك إلا جزءاً صغيراً: فعند معدل تحديث 60 تبلغ حركة اللعب بحدود 4,000 حزمة في الثانية لكل اتجاه. أما booter مستأجر فيقدّم بلا عناء من 5 إلى 50 Gbit/s، أي من خمسة أضعاف وصلتكم إلى خمسين ضعفاً. وأما إن كانت قاعدة iptables خلفها جيدة أم لا، فلم يبق لذلك أي معنى، لأن حزم لاعبيكم لم تعد تمر من قبل ذلك.

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

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

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

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

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

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

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

Advanced DDoS Protection لخوادم Mordhau التي تتعرض للقصف باستمرار

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

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

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

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

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

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

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

«اللاعبون لا يدخلون رغم أن الخادم يعمل»: تحققوا أولاً من المنفذ 15000 UDP. فالـbeacon يحجز الخانة أثناء التحميل. فإذا كان محجوباً أو مُصفّى بضيق شديد أو مُثقلاً، بقي الانضمام معلّقاً، رغم أن المنفذ 7777 يجيب والخادم مدرج في المتصفح.

«تعديلاتي في Game.ini تختفي بعد إعادة التشغيل»: لقد عدّلتم الملف والخادم يعمل. فعملية خادم Mordhau تكتب عند الإيقاف حالتها من الذاكرة، وتكتب بذلك فوق نسختكم. أوقفوا الخادم، ثم عدّلوا، ثم شغّلوا، بهذا الترتيب.

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

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

«مزودي يُبلّغ عن إساءة استخدام صادرة من المنفذ 27015»: لقد أُسيء استخدام خادمكم كمُضخِّم لانعكاس. فالاستعلامات وصلت بعنوان مرسل مزيف، وخادمكم أجاب ضحية غريبة. وتحديد المعدل على 27015 UDP لكل عنوان مصدر يُنهي ذلك.

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

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

باختصار

• يحتاج خادم Mordhau المخصص نحو الخارج إلى أربعة منافذ UDP بالضبط: 7777 (اللعبة) و7778 (Steam) و15000 (beacon) و27015 (استعلام Steam). وكل ما عدا ذلك يُغلَق.
• يعمل RCON في Mordhau عبر TCP وفق بروتوكول Source RCON، ولا يصبح فعّالاً إلا بضبط RconPassword وRconPort في Game.ini. اقصروا المنفذ على عنوانكم الخاص.
• يحق لكم تحديد معدل المنفذ 27015 UDP، لا إغلاقه: فبدونه يختفي خادمكم من متصفح الخوادم، لأن عدد اللاعبين والخريطة والاسم تُستعلَم عبر هذا المنفذ.
• المنفذ 15000 UDP هو منفذ beacon، وهو يحجز الخانة أثناء التحميل. فإذا كان محجوباً أو مُثقلاً، لم يدخل اللاعبون رغم أن الخادم يعمل.
• لا تعدّلوا Game.ini وEngine.ini إلا والخادم متوقف، لأن عملية الخادم تكتب عند الإيقاف حالتها من الذاكرة.
• قواعد جدار الحماية المحلية تنتهي عند النطاق الترددي: 1 Gbit/s تعني 125 ميغابايت في الثانية، وعند حزم بحجم 64 بايت نحو 1.49 مليون حزمة في الثانية. وما فوق ذلك تحسمه الشبكة الواقعة قبل الخادم وحدها.
• لدى KernelHost تكون الحماية الدائمة ذات المستويين مشمولة في كل حزمة خادم دون زيادة في السعر وفعّالة من لحظة التسليم، دون توجيه إلى العدم. ومن أراد التحكم في التصفية بنفسه يحصل عليها مع Advanced DDoS Protection ابتداءً من 50.00 EUR في الشهر.

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