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

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

تنطبق جميع المعطيات على Bedrock Dedicated Server أو PocketMine-MP أو Nukkit على Debian 12 أو Debian 13 أو Ubuntu 22.04 LTS أو Ubuntu 24.04 LTS. الأوامر مكتوبة للمستخدم root، وكمستخدمين عاديين تضعون sudo قبلها. ومن يشغّل Java Edition يجد هجمات البروتوكول النموذجية هناك في حماية Minecraft من DDoS وحماية Nullping. أما تثبيت خادم Bedrock وحده فيشرحه مقال تثبيت خادم Minecraft Bedrock باستخدام Nukkit.

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

لماذا تكون خوادم Minecraft Bedrock هدفاً لهجمات DDoS بهذا التكرار

إصدار Bedrock هو النسخة التي تعمل على أجهزة الألعاب والهواتف الذكية والأجهزة اللوحية وWindows، وهو يمثّل أكبر قاعدة لاعبين في Minecraft على الإطلاق. وحيث توجد خوادم كثيرة ينشأ أكبر دافع للهجمات: شبكات منافسة، ولاعبون محجوبون، وخلافات داخلية. ولا يكلّف الهجوم صاحبه مهارة ولا مالاً يُذكر، فـ booter الخوادم يُباع باشتراك.

أما السبب التقني فأعمق. فخادم Bedrock يتحدث UDP لا TCP، وهو يجيب كل من يسأل، قبل أن يحدث أي تسجيل دخول بوقت طويل. وهاتان الخصيصتان بالذات تجعلان المنفذ 19132 UDP هدفاً سهلاً. أما ما هو هجوم DDoS من حيث الأساس، فيشرحه مقال ما هو هجوم DDoS؟.

RakNet: بروتوكول UDP يجيب قبل أن يسجّل أحد دخوله

RakNet هي مكتبة الشبكة القائمة على UDP التي يُجري عبرها إصدار Minecraft Bedrock كامل حركة اللعبة. وUDP لا يعرف بناء اتصال يمكن للخادم أن يطالب به، ولذلك يمكن تزييف عناوين المصدر. وتبني RakNet طبقة موثوقية خاصة بها فوق ذلك: أرقام تسلسلية، وتأكيدات (ACK)، وتأكيدات سلبية (NAK) يستطيع العميل بها أن يطلب الحزم المفقودة من جديد.

ويتكوّن بناء الاتصال من سبع حزم، أربع من العميل وثلاث من الخادم:

Client  -> Server   Open Connection Request 1
Server  -> Client   Open Connection Reply 1
Client  -> Server   Open Connection Request 2
Server  -> Client   Open Connection Reply 2
Client  -> Server   Connection Request
Server  -> Client   Connection Request Accepted
Client  -> Server   New Incoming Connection

وبعد ذلك فقط يرسل العميل حزمة تسجيل الدخول مع إثباتات Xbox Live الخاصة به. وهذه هي الجملة الحاسمة لكل من يريد تأمين خادم Bedrock لديه: يكون الخادم قد عالج سبع حزم، وأنفق وقت معالجة وذاكرة، وأجاب عدة مرات، قبل أن يعرف أصلاً من الذي يقرع الباب. أي أن كل تدبير يبدأ عند تسجيل الدخول لا يعمل إلا بعد أن يكون الحمل قد نشأ فعلاً.

ويضاف إلى ذلك مدخل ثانٍ، وهو أسبق من الأول. فلكي يظهر الخادم في قائمة خوادم لاعب ما بالاسم والإصدار وعدد اللاعبين، يجيب على Unconnected Ping (معرّف الحزمة 0x01) بـ Unconnected Pong (معرّف الحزمة 0x1C). ويجري هذا التبادل قبل بناء الاتصال الفعلي، ولا يتطلب أي إثبات، ولا يمكن تعطيله في Bedrock Dedicated Server دون إخراج الخادم من كل قائمة خوادم.

Unconnected Ping كمتجه تضخيم: الأرقام

هجوم التضخيم (Amplification) هو هجوم يرسل فيه المهاجم طلبات صغيرة بعنوان مصدر مزيّف إلى خوادم غريبة، لكي تصل أجوبتها الأكبر إلى الضحية. ولا يكون خادم Bedrock في ذلك مُهاجَماً، بل مُستخدَماً. وفي حالة Unconnected Ping تكون الحسبة كالتالي:

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

ويظهر خلل التضخيم لسنة 2024 مدى سوء الأمر عندما تُستغَل طبقة الموثوقية نفسها. ففي مكتبة RakNet المستخدمة آنذاك كانت الحزمة Connection Request Accepted معلّمة كحزمة موثوقة. وكان بإمكان المهاجم أن يمثّل بناء الاتصال بعنوان مصدر مزيّف حتى هذه النقطة، ثم يرسل تأكيداً سلبياً واحداً بالمجال من 0 إلى 8191. فيرسل الخادم عندئذ آلاف الحزم إلى العنوان المزيّف، دون أن يفعل المهاجم أي شيء آخر. وقد عُولج ذلك بتحويل الحزمة إلى غير موثوقة، وبإرسال Cookie ضمن Open Connection Reply 1 يعكسه العميل الحقيقي، وبوضع حدود للحزم: 120 حزمة لكل عنوان مصدر في كل دورة من 10 مللي ثانية، و1٬000 حزمة إجمالاً في كل دورة.

إصدار Bedrock أو إصدار Java: ما الذي يختلف في حماية DDoS

من أمّن خادم Java مرة واحدة ينقل تقريباً كل شيء بشكل خاطئ. فالإصداران يتشاركان الاسم، لا بروتوكول الشبكة:

والسطر الخاص بكعكات SYN هو الأهم. ففي إصدار Java تصدّ نواة Linux طوفان SYN دون أن تلاحظ عملية Minecraft شيئاً من ذلك. أما في إصدار Bedrock فهذه المساعدة غير موجودة: فكل حزمة UDP على حدة تُمرَّر إلى عملية الخادم وتُقيَّم هناك. خادم Bedrock لا يملك ضد طوفان على المنفذ 19132 أي حماية مدمجة في نظام التشغيل، لأن UDP لا يعرف حماية كهذه.

وللسطر الخاص بغياب سجل SRV نتيجة عملية تفاجئ كثيرين: لا يمكنكم في إصدار Bedrock أن تخفوا المنفذ خلف سجل DNS. فاللاعبون يكتبون العنوان والمنفذ يدوياً. ومن ينقل المنفذ عليه أن يبلّغ كل لاعب بالمنفذ الجديد.

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

يرتبط Bedrock Dedicated Server بمنفذين بالضبط، وكلاهما عبر UDP. في ملف server.properties:

server-port=19132
server-portv6=19133
enable-lan-visibility=true
online-mode=true
allow-list=false
max-players=10
player-idle-timeout=30
max-threads=8

هذه هي الإعدادات الافتراضية من Microsoft، ويمكن قراءتها في مرجع Bedrock Dedicated Server. وحول هذين المنفذين توجد خدمات أخرى تعمل معهما بحسب برمجية الخادم:

والسطران الثالث والرابع هما أكثر الأخطاء القابلة للتجنّب شيوعاً على خوادم Bedrock. فعند Nukkit وPocketMine-MP تكون القيمة enable-query مفعّلة من المصنع، وعند Nukkit يهبط RCON المفعّل سهواً على 19132 TCP، أي على رقم المنفذ نفسه الذي تعمل عليه اللعبة. ومن ينظر فقط إلى «19132 مفتوح، لا مشكلة» يفوته ذلك.

وهناك خصوصية في Bedrock Dedicated Server الرسمي تنتمي إلى هنا أيضاً: فهو لا يعرف التوجيه server-ip. فـ PocketMine-MP وNukkit يملكانه (server-ip، وفي PocketMine إضافةً إلى ذلك server-ipv6)، أما الخادم الرسمي فلا. أي أنه يستمع دائماً على جميع عناوين النظام، وجدار الحماية هو إمكانيتكم الوحيدة لتقييد ذلك.

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

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

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

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

ss -lntup
ss -lnup sport = :19132

المهم هو العمود الذي يحمل العنوان المحلي. فالقيمتان 0.0.0.0:19132 و[::]:19133 تعنيان «قابل للوصول من الإنترنت كله». وإذا ظهر بجانبهما مدخل TCP على رقم المنفذ نفسه، فإن RCON يعمل. أما رؤية المهاجم فيوفّرها فحص منافذ من الخارج، ولـ UDP بالخيار -sU:

nmap -Pn -sU -p 19132,19133 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. إبقاء 19132 UDP مفتوحاً وحده وإغلاق كل ما سواه

يكفي خادم Bedrock سماح واحد إلى الخارج، واثنان مع IPv6. وبواسطة UFW يبدو الأمر كالتالي، وبهذا الترتيب بالضبط لكي لا تحجبوا أنفسكم:

ufw allow 22/tcp comment 'SSH'
ufw allow 19132/udp comment 'Bedrock IPv4'
ufw allow 19133/udp comment 'Bedrock IPv6'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

وإذا لم يكن لديكم لاعبو IPv6، فاتركوا السطر الخاص بـ 19133 واضبطوا في PocketMine-MP إضافةً إلى ذلك enable-ipv6=false. فكل منفذ لا تسمحون به هو منفذ لا تحتاجون إلى الدفاع عنه. ويوجد الدليل الكامل مع طريق النجاة في إعداد جدار حماية UFW دون أن تحجبوا أنفسكم.

3. تعطيل ظهور الخادم في الشبكة المحلية، وإلا بقي 19132 مفتوحاً

هذا هو الفخّ الذي يقع فيه تقريباً كل من يريد نقل المنفذ. فالتوجيه enable-lan-visibility مضبوط من المصنع على true ويجعل الخادم يجيب على استعلامات البحث في الشبكة المحلية. وتكتب Microsoft بهذا الخصوص صراحةً أن الخادم يرتبط بذلك إضافةً إلى ذلك بالمنفذين الافتراضيين 19132 و19133، حتى لو كانت لـ server-port وserver-portv6 قيم أخرى.

أي أن من ينقل المنفذ إلى 19140 ويطمئن، يبقى مستمعاً على 19132. ولذلك ينتمي إلى ملف server.properties في خادم على الإنترنت السطر التالي:

enable-lan-visibility=false

وبعد ذلك تفحصون بالأمر ss -lnup أن المنفذ 19132 اختفى فعلاً. والإعداد نفسه يحلّ بالمناسبة مشكلة أن يسلب خادما Bedrock على المضيف نفسه المنفذ أحدهما من الآخر.

4. تعطيل الاستعلام وRCON

يأتي PocketMine-MP وNukkit مع استعلام GS4، وهو استعلام خادم عبر UDP على نمط بروتوكول UT3، وهما يجيبان على هذه الاستعلامات على المنفذ 19132 نفسه الذي تعمل عليه اللعبة. والجواب المفصّل يحتوي اسم الخادم، والإصدار، واسم العالم، وحالة قائمة السماح، والعنوان والمنفذ، وعدد اللاعبين، وأسماء جميع اللاعبين المتصلين، وفي PocketMine-MP عند الطلب قائمة الإضافات الكاملة. وهذا عملي لصفحات الحالة وروبوتات Discord، لكنه يكشف للمهاجم بالضبط متى يستحق الهجوم عناءه، ويكلّف وقت معالجة عند كل استعلام.

enable-query=off
enable-rcon=off

وفي PocketMine-MP تكون القيم false بدلاً من off، وقائمة الإضافات تعطّلونها في ملف pocketmine.yml بالقيمة settings.query-plugins: false. وهنا تصنيف نادراً ما يُقرأ: استعلام GS4 في PocketMine-MP يتحقق من رمز مملّح بعنوان المصدر. وبذلك لا يمكن عكس الجواب الكبير إلى عنوان مزيّف. ومع ذلك يكلّف الاستعلام وقت معالجة، والبيانات المنشورة تساعد المهاجم في اختيار الهدف. أما Bedrock Dedicated Server الرسمي فلا يعرف الاستعلام ولا RCON، وهناك تسقط هذه النقطة.

وإذا كنتم تحتاجون RCON فعلاً، فاضبطوا في Nukkit القيمة rcon.port على قيمة خاصة بها بكل تأكيد، واسمحوا بها لعنوانكم الخاص وحده. فالارتداد إلى server-port يعني غير ذلك أن تحكّماً عن بُعد في خادمكم يستمع على 19132 TCP، أي على الرقم نفسه الذي أدرجتموه في كل مكان على أنه «مفتوح».

5. فرض التحقق من الهوية عبر Xbox Live

التحقق من الهوية عبر Xbox Live هو فحص ما إذا كان اللاعب المنضم يملك حساباً حقيقياً موقّعاً من Microsoft. وهو مفعّل من المصنع في برمجيات الخادم الثلاث كلها، ويجب أن يبقى كذلك هناك.

في Bedrock Dedicated Server يسمى التوجيه online-mode، وفي PocketMine-MP وNukkit يسمى xbox-auth. وفي الحالتين تكون القيمة true هي حالة المصنع والقيمة الصحيحة:

online-mode=true
xbox-auth=true

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

والآن الجزء الذي يساعد ضد سوء الفهم: التحقق من الهوية عبر Xbox Live يحمي منطق لعبتكم، لا وصلتكم. فهو يجري في حزمة تسجيل الدخول، أي بعد بناء اتصال RakNet الكامل. والمهاجم الذي يغرق خادمكم لا يريد الانضمام أصلاً. فحزمه تُرفض، لكنها وصلت مع ذلك، وهذه هي النقطة بالضبط.

6. قائمة السماح والحد الأعلى للاعبين، وما لا تقدّمانه

قائمة السماح (allowlist، وسابقاً whitelist) هي قائمة اللاعبين الذين يحق لهم الانضمام. وفي Bedrock Dedicated Server تفعّلونها بالقيمة allow-list=true، والمداخل موجودة في ملف allowlist.json مع الاسم وXUID والحقل ignoresPlayerLimit. أما في Nukkit وPocketMine-MP فيبقى اسم التوجيه white-list.

allow-list=true
max-players=60
player-idle-timeout=15

ومدة خمول قصيرة عبر player-idle-timeout فعّالة ضد استنفاد المقاعد: فاللاعبون الذين يشغلون مقعداً فقط يخرجون بعد عدد الدقائق المحدد. والقيمة 0 تعني أن أحداً لا يُفصل أبداً بسبب الخمول، وهذا بالضبط ما يستغله مهاجم يحجب مقاعدكم بحسابات حقيقية.

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

7. تقييد معدلات الحزم لكل عنوان مصدر

ضد الهجمات الصغيرة والبوتات غير النظيفة يفيد حدّ أعلى لكل عنوان مصدر. ولـ UDP يُعمل بـ hashlimit لا بـ connlimit، لأن UDP لا يعرف اتصالات:

iptables -I INPUT -p udp --dport 19132 -m hashlimit --hashlimit-name bedrock_udp --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

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

ويحق لكم أن تضبطوا الأمر أشدّ بكثير عند Unconnected Ping، لأن العميل الحقيقي لا يسأل عن حالة الخادم إلا طالما كانت قائمة الخوادم مفتوحة، وحينها بمعدل مرة في الثانية. وبواسطة nftables يمكن إصابة هذه الحزمة الواحدة بالضبط، لأن معرّف الحزمة هو البايت الأول بعد ترويسة UDP:

nft add table inet bedrock
nft add chain inet bedrock prerouting '{ type filter hook prerouting priority -150 ; policy accept ; }'
nft add rule inet bedrock prerouting udp dport 19132 @th,64,8 0x01 limit rate over 500/second drop

التعبير @th,64,8 يقرأ ثماني بتات بدءاً من البت 64 من ترويسة النقل، أي البايت الأول من حمولة UDP. والقيمة 0x01 هي معرّف حزمة Unconnected Ping. ويمكنكم استخدام الموضع نفسه للمراقبة قبل أن تُسقطوا أي شيء:

tcpdump -ni eth0 'udp dst port 19132 and udp[8] = 0x01' -c 200 -q
tcpdump -ni eth0 'udp src port 19132 and udp[8] = 0x1c' -c 200 -q

السطر الأول يعدّ استعلامات الحالة الواردة، والثاني يعدّ أجوبتكم الخاصة. وإذا بلغ الاثنان الآلاف بمعدل ثانية بعد ثانية بينما لا يكاد أحد يلعب، فأنتم ترون طوفان Ping لا لاعبيكم.

وملاحظتان بشأن الثبات. فقواعد iptables المجردة تزول بعد إعادة التشغيل، وعلى Debian وUbuntu تُحفظ على هذا النحو:

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

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

8. تخفيف الحمل عن تتبّع الاتصالات في النواة

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

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

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

iptables -t raw -I PREROUTING -p udp --dport 19132 -j NOTRACK
iptables -t raw -I OUTPUT -p udp --sport 19132 -j NOTRACK

وبعد ذلك لا تعمل القواعد المعتمدة على الحالة على هذه الحركة. أي أن سماحكم للمنفذ 19132 UDP يجب أن يكون سماحاً حقيقياً للمنفذ، ولا يجوز أن يعتمد على الحالة ESTABLISHED. تحقّقوا بعد الضبط بالأمر conntrack -L | grep 19132 من أنه لم تعد تنشأ مداخل، واتصلوا باللعبة مرة واحدة قبل أن تحفظوا القواعد بشكل دائم.

9. تشغيل Geyser وFloodgate بشكل نظيف

Geyser هو جسر يتيح لعملاء Bedrock أن يلعبوا على خادم إصدار Java: فهو يستقبل اتصالات Bedrock على 19132 UDP، ويترجم البروتوكول، ويتحدث على الجهة الأخرى مع خادم Java على 25565 TCP. وFloodgate هو المكمّل الذي يتيح لهؤلاء لاعبي Bedrock الانضمام دون حساب Java. وهذا يعني ثلاثة أمور لحماية DDoS.

أولاً: أبقوا Geyser محدّثاً. فهذا الجسر بالذات كان مرتين سبباً لهجمات موثّقة. في مارس 2024 استُغِل على نطاق واسع خلل التضخيم الموصوف أعلاه في مكتبة RakNet، وعُولج ابتداءً من الإصدار Build 478. وفي يوليو 2025 تبعته حالة ثانية: حزمة تُرسل بشكل متكرر لتأكيد حزم الموارد كانت تولّد عدة جلسات لكل لاعب، وكان بإمكان العملاء المفصولين أن يواصلوا إرسال الحزم، لأن قناة الشبكة لم تكن تُغلق. وعُولج ذلك ابتداءً من الإصدار Build 897. والحالتان كلتاهما نشرهما المشروع نفسه مع خط زمني.

ثانياً: خادم Java لا ينتمي إلى الشبكة المفتوحة. في إعداد Geyser تشير القيمة remote.address إلى auto أو إلى 127.0.0.1، والقيمة remote.port إلى 25565. اربطوا خادم Java محلياً وفقاً لذلك، ولا تسمحوا بالمنفذ 25565 TCP إلى الخارج. وإلا صار لديكم مساحتا هجوم بدلاً من واحدة، والثانية هي تلك التي لم تفكّروا لها في قواعد أبداً.

ثالثاً: الملف key.pem سِرّ. فهو المفتاح الذي يتجاوز Floodgate به التحقق من الهوية في Java لحسابات Bedrock. ومن يضعه في مستودع عام، أو ينسخه في تذكرة دعم، أو يعرضه في لقطة شاشة، فقد وهب تسجيل الدخول إلى خادمه. والمشروع يحذّر من ذلك صراحةً.

10. جمع القياسات قبل أن تنفجر الأمور

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

sar -n DEV 1 10
ip -s link show eth0
ss -lunp sport = :19132
nstat -az | grep -E 'UdpInDatagrams|UdpNoPorts|UdpInErrors|UdpRcvbufErrors'
dmesg -T | tail -50

وثلاث من هذه القيم شديدة الدلالة في خادم Bedrock. فقيمة Recv-Q المختلفة عن الصفر بشكل دائم على مقبس UDP الخاص بالمنفذ 19132 تعني أن عملية الخادم لم تعد تسحب الحزم الواردة بسرعة كافية. والعدّاد UdpRcvbufErrors يعدّ بالضبط الحزم التي أُسقطت لهذا السبب، وهو أقوى دليل على أن عنق الزجاجة ليس الوصلة بل العملية. والعدّاد UdpNoPorts يرتفع عندما يقصف أحد منافذ لا يستمع عليها شيء أصلاً، وهي صورة نموذجية لفحص منافذ واسع الانتشار قبل الهجوم الفعلي.

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

حيث تنتهي هذه التدابير: عرض النطاق الترددي ومعدل الحزم

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

احسبوا معنا مرة. تمتلئ وصلتكم بمجرد أن يرسل أحد أكثر من 125 ميغابايت في الثانية. وهجوم من 5 إلى 50 غيغابت/ث يعادل خمسة إلى خمسين مثلاً من ذلك. وسواء كانت قاعدة hashlimit لديكم خلف ذلك جيدة أم لا، فهذا لم يعد يهمّ، لأن حزم لاعبيكم لا تعبر أصلاً قبل ذلك.

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

ولا يوجد لذلك أي إعداد محلي. فالهجمات الحجمية يجب أن تنتهي في الشبكة الواقعة أمام الخادم.

ما تضعه KernelHost في مواجهة هجمات DDoS على خوادم Bedrock

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

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

• المستوى 1: سعة تخفيف تبلغ 17 تيرابت/ث في شبكة التنقية (scrubbing) العالمية. تُنقّى الهجمات الحجمية قريباً من مصدرها، قبل أن تصل إلى مركز البيانات.
• المستوى 2: تصفية Arbor في الوقت الفعلي بسعة 3٫2 تيرابت/ث في فرانكفورت أم ماين. تُكتشف الأنماط الخاصة بكل بروتوكول أمام الخادم مباشرةً وتُسقَط، حزمةً حزمةً. ويشمل ذلك أيضاً أنماط UDP على 19132 التي لا تُظهر سلوك RakNet.

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

Advanced DDoS Protection للمشاريع المستهدفة بشكل دائم

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

• عنوان IP محمي مخصّص من قلب شبكة فرانكفورت، يُنقل إليه خادمكم داخل شبكتنا. ولا حاجة إلى أي تعديل من جانبكم.
• قواعد حماية تديرونها بأنفسكم لكل منفذ وبروتوكول في منطقة العملاء: تضبطون ما هو مسموح على 19132 UDP، وما هو مسموح على 19133 UDP، وما هو مسموح على منفذ مختلف إذا كنتم قد نقلتم خادمكم.
• التغييرات تسري في الوقت الفعلي، أي يمكنكم التعديل أثناء هجوم جار بدلاً من انتظار نافذة صيانة.
• ملف حماية مطابق لكل لعبة. فلـ Minecraft توجد ملفات جاهزة، وكذلك للتطبيقات المعدّلة والخاصة على أي منفذ TCP أو UDP، أي أيضاً لـ Nukkit أو PocketMine-MP أو نسخة Geyser على منفذ من اختياركم.

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

ولمعظم مشاريع Bedrock تكفي الحماية الدائمة المشمولة مع إعداد نظيف للخادم. أما Advanced DDoS Protection فهي الجواب على أن يأخذ أحدهم الأمر على المحمل الشخصي. ومن يشغّل خادمه حالياً في مكان آخر فأقرب حلّ لمشكلته هو الانتقال: فالتصفية تعمل في الشبكة الواقعة أمام الخادم، وهذه الشبكة يجب أن تكون ملكاً لنا.

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

«غيّرت المنفذ إلى 19140، ومع ذلك 19132 مفتوح»: هذا هو enable-lan-visibility=true. فـ Bedrock Dedicated Server يرتبط عندئذ إضافةً إلى ذلك بالمنفذين 19132 و19133، أياً كانت القيمة في server-port. اضبطوه على false، وأعيدوا تشغيل الخادم، وافحصوا بالأمر ss -lnup.

«عدّلت ملف allowlist.json ولم أعد أستطيع الدخول بنفسي»: سببان شائعان. إما أن ملف whitelist.json قديماً لا يزال في المجلد ويقرأه الخادم بدلاً منه، وإما أن مدخل XUID ناقص أو خاطئ. فالاسم وحده لا يكفي بشكل موثوق عند تفعيل التحقق من الهوية عبر Xbox Live.

«مضيفي حجب خادمي، رغم أنني كنت الطرف المُهاجَم»: تحقّقوا مما إذا كان خادمكم نفسه قد أرسل حزماً. فهذا بالضبط ما حدث في خلل التضخيم في RakNet سنة 2024: أرسلت الخوادم المعنية آلاف الحزم إلى عناوين غريبة، وفي بلاغات إساءة الاستخدام كان المنفذ 19132 مذكوراً كمصدر. وبالأمر tcpdump -ni eth0 'udp src port 19132' -c 200 -q ترون إلى أين يجيب خادمكم. والإصدار المحدّث يزيل السبب.

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

«الخادم موجود في القائمة، لكن لا أحد يدخل»: إذا كان المدخل يعرض الاسم وعدد اللاعبين، فإن Unconnected Pong يعمل، أي أن المنفذ قابل للوصول من حيث الأساس. وإذا فشل الانضمام مع ذلك، فالأمر متعلق في الغالب بتسجيل الدخول عبر Xbox Live أو بقائمة السماح. وإذا كان لاعبو IPv6 وحدهم هم الذين لا يدخلون، فالسماح للمنفذ 19133 UDP ناقص.

«الخادم يعمل، لكن الجميع يشكون من قفزات تأخير»: هذا يكون إضافةً أكثر مما يكون هجوماً. انظروا أولاً ما إذا كانت قيمة Recv-Q على مقبس UDP تنمو، وما إذا كان العدّاد UdpRcvbufErrors يرتفع. فإذا بقي الاثنان هادئين وكان الأمر sar -n DEV 1 10 غير ملفت، فلم يكن الأمر هجوم DDoS بل عملية الخادم نفسها. وفي Bedrock Dedicated Server تساعد عندئذ مراقبات السكربتات، وحدودها موجودة في ملف server.properties تحت script-watchdog-hang-threshold وscript-watchdog-slow-threshold.

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

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

باختصار

• يحتاج خادم Minecraft Bedrock إلى منفذ مفتوح واحد بالضبط إلى الخارج: 19132 UDP، ويضاف إليه 19133 UDP للاعبي IPv6 فقط. أما الاستعلام وRCON ومُنقّح السكربتات على 19144 TCP وخادم Java خلف Geyser على 25565 TCP فلا تنتمي إلى الشبكة المفتوحة.
• من ينقل المنفذ عليه أن يضبط enable-lan-visibility=false، وإلا بقي Bedrock Dedicated Server مرتبطاً إضافةً إلى ذلك بالمنفذين 19132 و19133.
• التحقق من الهوية عبر Xbox Live وقائمة السماح لا يعملان إلا في حزمة تسجيل الدخول، أي بعد بناء اتصال RakNet الكامل. فهما يحميان منطق لعبتكم ومقاعدكم، لا وصلتكم.
• يُطلب Unconnected Ping بـ 33 بايت ويُجاب عليه بنحو 131 بايت، أي معامل تضخيم يقارب أربعة. واسم خادم قصير يبقي هذا المعامل صغيراً.
• في UDP يفيد hashlimit بدلاً من connlimit، وتتبّع الاتصالات في النواة هو أول ما يمتلئ عند عناوين المصدر المزيّفة. وكلا الأمرين ينبغي أن تكونوا قد قستموهما قبل الهجوم الأول.
• من نحو 1 غيغابت/ث تكون وصلتكم ممتلئة، ومع حزم بحجم 64 بايت تتسع فيها نحو 1٫49 مليون حزمة في الثانية. وفوق ذلك تقرر التصفية في الشبكة أمام الخادم وحدها.
• عند KernelHost تكون الحماية الدائمة ذات المستويين مشمولة في كل حزمة خادم، وفعّالة من لحظة التسليم، ودون null-routing. وتكمّلها Advanced DDoS Protection بعنوان IP محمي مخصّص وقواعد تديرونها بأنفسكم لكل منفذ.

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