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

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

جميع المعطيات تتعلق بالخادم المخصص الرسمي من Pocketpair (معرّف تطبيق Steam 2394010) على Debian 12 أو Debian 13 أو Ubuntu 22.04 LTS أو Ubuntu 24.04 LTS. والأوامر مكتوبة للمستخدم root، وكمستخدم عادي تضعون sudo قبلها. وإذا كان الهجوم جارياً الآن فهناك ترتيب يسري: القياس أولاً، ثم التعديل. فإعادة التشغيل القاسية تحت الحِمل تُلغي كل ما حدث في العالم منذ آخر نقطة حفظ آلية، ومعطيات القياس الخاصة بالحادث تضيع بعدها كذلك.

لماذا تُعطَّل خوادم Palworld بشكل مقصود بهجمات DDoS

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

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

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

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

يحتاج خادم Palworld إلى منفذ مفتوح واحد بالضبط: 8211 UDP. وكل ما عدا ذلك اختياري، وهو حسب الوظيفة ضار حتى، إذا وُضع في الإنترنت. ومن ذلك ينتج تمييز مفيد: هجوم DDoS على المنفذ 8211 يصيب دائماً حركة اللعب نفسها، أما الهجوم على المنفذ 27015 UDP فيصيب الإدراج في قائمة الخوادم وحده.

وجميع مفاتيح ذلك موجودة في ملف واحد: Pal/Saved/Config/LinuxServer/PalWorldSettings.ini، وعلى Windows بالمقابل Pal\Saved\Config\WindowsServer\PalWorldSettings.ini. ويبدأ الملف بسطر القسم [/Script/Pal.PalGameWorldSettings]، ويليه سطر واحد OptionSettings=(...) يحتوي جميع الإعدادات كقائمة. وأي فاصل أسطر داخل القوسين يُبطل الإعداد بأكمله، فيعود الخادم دون أي تعليق إلى القيم الافتراضية. ولا تعدّلوا القالب DefaultPalWorldSettings.ini في مجلد الخادم، لأنه يُستبدل مع كل تحديث.

خادم Palworld في أرقام

القيم التالية هي الأساس لكل قرار بشأن قواعد التصفية والحدود.

لماذا منفذ الاستعلام 27015 هو أكثر النقاط حساسية

يجيب منفذ الاستعلام عن استعلامات الحالة بصيغة Steam المسماة A2S، أي الاستعلام نفسه الذي تخدمه خوادم Counter-Strike وARK كذلك. واستعلام A2S_INFO حزمة UDP بلا اتصال بحجم بضع عشرات من البايتات، أما الجواب الذي يحمل اسم الخادم والعالم وعدد اللاعبين وحالة اللعب فهو أضعاف ذلك. ولأن عنوان المرسل قابل للتزييف في UDP، يستطيع المهاجم مخاطبة منافذ استعلام غريبة وتوجيه الأجوبة الأكبر إلى هدفه الحقيقي. وخادمكم في هذه الحالة ليس الضحية بل المُضخِّم، ووصلته هي التي تدفع الحساب.

ولهذا أضافت Valve إلى A2S_INFO في 8 ديسمبر 2020 تحدياً مُسبَقاً: يجيب الخادم أولاً بـS2C_CHALLENGE، وعلى المستعلِم أن يعيد إرسال الرمز، فيُثبت بذلك أنه لا يزيّف عنوان المرسل. وهذا يُضعف التضخيم لكنه لا يُنهيه، وهو لا يعمل على الإطلاق ضد سيل بسيط من استعلامات متشابهة قادمة من عناوين حقيقية.

ويترتب على ذلك لصالح Palworld أمر مهم أمام محرك Source: فحركة اللعب واستعلام الخادم يقعان على منفذين منفصلين. أما في Counter-Strike 2 فيتشارك الاثنان المنفذ 27015، وتحديد المعدل الخشن هناك يطرد اللاعبين أنفسهم معه. وفي Palworld تستطيعون تحديد 27015 UDP بقسوة أو إغلاقه بالكامل دون أن تمسّوا حركة لعب جارية واحدة على 8211 UDP. ومن لا يحتاج إلى الإدراج في القائمة يحذف -publiclobby ومنفذ الاستعلام دون بديل، وبذلك يُخرج من الشبكة سطح هجوم كاملاً.

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

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

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

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

ss -lntup

المهم هو العمود الذي يحمل العنوان المحلي. فـ0.0.0.0:8211 يعني «قابل للوصول من الإنترنت بأكمله»، و127.0.0.1:8212 يعني «محلياً فقط» ولا يحتاج إلى قاعدة في جدار الحماية. وإلى جانب عملية اللعبة تظهر هناك على خادم نما مع الوقت في الغالب لوحة إدارة، وخادم ويب لعرض الخريطة، وقاعدة بيانات. أما رؤية المهاجم فيوفرها فحص المنافذ من الخارج:

nmap -Pn -sU -p 8211,27015 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. فتح ما يحتاجه Palworld فعلاً وحده

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

ufw allow 22/tcp comment 'SSH'
ufw allow 8211/udp comment 'حركة لعب Palworld'
ufw allow 27015/udp comment 'استعلام Steam لـPalworld'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

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

3. إخراج RCON على 25575 وواجهة REST على 8212 من الإنترنت

المنفذان كلاهما وصولان إداريان بتحكم كامل في الخادم، وكلاهما معطّل من المصنع: RCONEnabled=False وRESTAPIEnabled=False. ومن يشغّلهما ينبغي أن يعرف ما الذي ينشره بذلك.

وواجهة REST على 8212 TCP تتحقق من الهوية عبر HTTP Basic Auth باسم المستخدم الثابت admin والقيمة المأخوذة من AdminPassword، وذلك عبر HTTP غير مشفّر. وبذلك تسير كلمة مرور الإدارة مع كل استعلام منفرد بصيغة قابلة للعكس عبر الوصلة. وRCON على 25575 TCP هو بروتوكول نصي غير مشفّر بالمثل، وقد وسمته Pocketpair بأنه متجاوَز لصالح واجهة REST. وللتثبيتات الجديدة تكون واجهة REST هي الاختيار الصحيح، وتسري على كليهما القاعدة نفسها: لا يُوضعان في الشبكة المفتوحة.

RESTAPIEnabled=True
RESTAPIPort=8212
AdminPassword="a long random value"

وتجعلون الواجهة قابلة للوصول عبر تمرير منفذ بواسطة SSH، ثم تعملون محلياً مقابل 127.0.0.1:8212:

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

ولا تتركوا AdminPassword فارغة أبداً، فالفراغ هو القيمة الافتراضية. وقيمة من openssl rand -base64 32 تكفي. والأمر نفسه يسري على ServerPassword، وعنها المزيد بعد قليل.

4. تحديد منفذ الاستعلام 27015 دون فقدان الإدراج في القائمة

تبدأ حزم Steam بلا اتصال بأربعة بايتات مضبوطة (0xffffffff)، وحركة اللعب النظامية لا تحمل هذا الرأس. وعلى ذلك يمكن وضع تحديد للمعدل لكل عنوان مصدر، يكبح الاستعلامات ويحفظ الإدراج في القائمة. ومع nftables، مُحمَّلاً عبر nft -f:

table inet palworld {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 10/second burst 20 packets } drop
    }
}

وتضمن الأولوية -10 أن تعمل القاعدة قبل سلسلة التصفية الخاصة بـUFW، ويقرأ @th,64,32 أول أربعة بايتات بعد رأس UDP. ومع iptables التقليدي يحقق الفصل نفسه مطابقةٌ على معرّف A2S_INFO:

iptables -A INPUT -p udp --dport 27015 \
  -m string --algo bm --hex-string "|ffffffff54536f7572636520456e67696e6520517565727900|" \
  -m hashlimit --hashlimit-name a2sflood --hashlimit-mode srcip \
  --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

وعشرة استعلامات في الثانية لكل عنوان قياس سخي: فخدمة القوائم تستعلم في العادة كل بضع دقائق، لا عدة مرات في الثانية. والمهم فقط أن تكون هذه القاعدة على 27015 وليست على 8211، وإلا أصبتم لاعبيكم أنفسهم.

5. تحديد معدلات الحزم على 8211 UDP

على منفذ اللعبة نفسه يفيد حدٌّ أعلى لكل عنوان مصدر ضد السيول الصغيرة القادمة من مصادر قليلة. وفي Palworld يكون ضبط هذا الحد غير خطر نسبياً، لأن 32 لاعباً على الأكثر يكونون متصلين في وقت واحد، وكل منهم يحتل عنوان مصدر واحداً بالضبط:

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

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

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

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

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

6. كلمة مرور الخادم وقائمة الحظر والخانات الـ32 ضد استنفاد الخانات

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

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

ServerPassword="a value only your group knows"
ServerPlayerMaxNum=32
bShowPlayerList=True
BanListURL="https://api.palworldgame.com/api/banlist.txt"

وServerPassword فارغة من المصنع، أي أن كل من يملك عنوان IP والمنفذ يدخل. ويشير BanListURL افتراضياً إلى القائمة التي تتولاها Pocketpair، ويمكن تحويله إلى ملف نصي خاص بكم إذا أردتم إدارة قوائم حظر خاصة بالمشروع. ولا تضبطوا ServerPlayerMaxNum فوق 32: فالقيم الأعلى غير مدعومة وتنقلب عليكم في التحديث التالي على أبعد تقدير. وشيء واحد يجب أن يكون واضحاً: كلمة مرور الخادم تحمي خاناتكم، لا وصلتكم. فالمهاجم الذي يُغرق خادمكم لا يريد الانضمام أصلاً.

7. تخفيف تتبّع الاتصالات وتكبير المخازن المؤقتة

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

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

والخطوة الأكثر فعالية هي ألا تُتَتَبَّع حركة اللعب من الأساس، فـPalworld يدير جلساته بنفسه:

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport { 8211, 27015 } notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport { 8211, 27015 } notrack
    }
}

ومع iptables يكون المقابل iptables -t raw -A PREROUTING -p udp --dport 8211 -j NOTRACK والسطر نفسه لأجل OUTPUT مع --sport. وتحتاج المنافذ بعد ذلك إلى إذن صريح، لأن أي قاعدة تتحقق من حالة قائمة لم تعد تعمل بدون التتبّع. وإذا وصلت الحزم أسرع مما تسحبها عملية الخادم، فاض إضافةً إلى ذلك مخزن الاستقبال المؤقت. وهذا يبدو للاعبين كفقدان حزم، مع أن الوصلة فارغة. وإضافة تحت /etc/sysctl.d/، تُنشَّط بـsysctl -p:

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

وما إذا كانت القيم ضرورية تكشفه نواة النظام بنفسها: فإذا ارتفع UdpRcvbufErrors في nstat -az، فهي تعمل. وإذا بقي العدّاد عند الصفر، فالتعديل لا يغيّر شيئاً.

8. جمع القياسات قبل أن يصبح الأمر جدياً

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

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

curl -s -u admin:YOUR_ADMIN_PASSWORD http://127.0.0.1:8212/v1/api/metrics

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

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

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

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

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

ويُضاف عند خادم Palworld نسبة غير مواتية. فخادم ممتلئ تماماً بـ32 لاعباً لا يستخدم إلا جزءاً صغيراً من وصلة بسرعة 1 Gbit/s. أي أن الهجوم لا يحتاج إلى أن يكون كبيراً ليبلغ أضعاف التشغيل الطبيعي، ولهذا بالتحديد تكفي هنا هجمات لا تكون ملحوظة على منصة كبيرة.

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

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

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

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

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

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

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

أخطاء شائعة في خوادم Palworld وحلولها

«حجبت 27015 والآن اختفى الخادم من قائمة المجتمع»: هذا هو السلوك المتوقع، لأن منفذ الاستعلام هو الذي يحمل الإدراج في القائمة. فلا تحجبوه جملةً، بل حدّدوا الحزم بلا اتصال لكل عنوان مصدر كما في الخطوة 4. وإذا لم تكونوا محتاجين إلى الإدراج في القائمة أصلاً، فاتركوا المنفذ مغلقاً، واحذفوا -publiclobby، وأعطوا لاعبيكم عنوان IP والمنفذ 8211 للاتصال المباشر.

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

«الخادم يعاني طفرات في اللاج، لكن الوصلة هادئة»: هذا في Palworld حِمل أكثر مما هو هجوم. فعملية الخادم تحتل على مدى التشغيل ذاكرة عاملة أكثر باستمرار، ولهذا فإن إعادة التشغيل المُخطَّطة جزء من التشغيل الطبيعي ولا تُفهَم كحل اضطراري. تحقّقوا من معدل إطارات الخادم عبر نقطة نهاية المقاييس ومن استهلاك العملية للذاكرة. فإذا بقي sar -n DEV 1 10 عادياً مع ذلك، فلم يكن هجوم DDoS.

«الخانات الـ32 كلها محتلة، لكن لا أحد ظاهر في اللعبة»: هذا استنفاد للخانات ويصيب منطق اللعبة، لا الوصلة. اضبطوا ServerPassword، واحظروا الحسابات الملحوظة عبر قائمة الحظر، وحدّدوا الحزم لكل عنوان مصدر على 8211 UDP.

«واجهة REST كانت قابلة للوصول علناً بضعة أيام»: إذاً كلمة مرور الإدارة الخاصة بكم مكشوفة، لأن HTTP Basic Auth عبر HTTP غير مشفّر ينقلها مع كل استعلام بصيغة قابلة للعكس. غيّروا AdminPassword، وأغلقوا 8212 TCP نحو الخارج، ولا تصلوا إلى الواجهة إلا عبر تمرير منفذ بواسطة SSH.

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

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

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

باختصار

• يحتاج خادم Palworld إلى منفذ مفتوح واحد بالضبط: 8211 UDP. أما منفذ الاستعلام 27015 UDP فهو ضروري للإدراج في قائمة خوادم المجتمع وحده.
• RCON على 25575 TCP وواجهة REST على 8212 TCP لا تنتمي أبداً إلى الشبكة المفتوحة، لأن كلتيهما تنقل بيانات الدخول دون تشفير. وقد وسمت Pocketpair RCON إضافةً إلى ذلك بأنه متجاوَز.
• ولأن حركة اللعب واستعلام الخادم يقعان في Palworld على منفذين منفصلين، يمكن تحديد 27015 UDP بقسوة دون مساس حركة اللعب الجارية على 8211 UDP.
• الخادم المخصص محدود بـ32 خانة، ولهذا فإن استنفاد الخانات هو أرخص هجوم. وضبط ServerPassword هو أكثر إجراء منفرد فعالية ضد ذلك، لأن Palworld لا يملك قائمة بيضاء مدمجة.
• الإجراءات المحلية تنتهي عند الوصلة: 1 Gbit/s تعني 125 ميغابايت في الثانية، وعند حزم بحجم 64 بايت تتسع لنحو 1.49 مليون حزمة في الثانية. وكل ما فوق ذلك يجب أن ينتهي في الشبكة الواقعة قبل الخادم.
• لدى KernelHost تكون الحماية الدائمة ذات المستويين مشمولة في كل حزمة خادم دون زيادة في السعر وفعّالة من لحظة التسليم، دون توجيه إلى العدم. وتبدأ Advanced DDoS Protection بعنوان IP مخصص للحماية وقواعد لكل منفذ تديرونها بأنفسكم من 50.00 EUR في الشهر.

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