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

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

جميع المعطيات تتعلق بالخادم المخصص (تطبيق Steam رقم 380870) على Debian 12 أو Debian 13 أو Ubuntu 22.04 LTS أو Ubuntu 24.04 LTS، للبناء 41 كما للبناء 42. وملف الإعداد اسمه servertest.ini ويقع تحت ~/Zomboid/Server/، وبيانات العالم تقع تحت ~/Zomboid/Saves/Multiplayer/. والأوامر مكتوبة للمستخدم root، وكمستخدم عادي تضعون sudo قبلها.

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

لماذا تصبح خوادم Project Zomboid هدفاً لهجمات DDoS

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

ويُضاف إلى ذلك أن الهجوم نفسه لا يكلّف شيئاً ولا يتطلب مهارة. فخدمات الهجوم المأجورة، وتُسمّى في هذا الوسط booter أو stresser، تُوجَّه ببضع نقرات ضد عنوان IP ومنفذ، والهدف في Project Zomboid هو دائماً الشيء نفسه: 16261 UDP. ومن كان في خلاف مع لاعب محظور أو يدير مجتمعاً منافساً، يملك بذلك أداةً لا يحتاج لأجلها إلى معرفة ولا إلى مال يُذكر.

ويُضاف إلى ذلك أن خادم اللعب مضطر إلى نشر عنوانه. فإذا كان Public=true في servertest.ini، ظهر الخادم في متصفح اللعبة، والخادم المرتبط بـSteam مرئي في متصفح خوادم Steam على أي حال. فالسؤال ليس أبداً ما إذا كان المهاجم سيجد عنوان IP الخاص بكم، بل فقط ما يحدث إذا صوّب عليه.

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

ما المنافذ التي يحتاجها خادم Project Zomboid فعلاً

يحتاج خادم Project Zomboid المخصص إلى منفذين مفتوحين بالضبط: 16261 UDP و16262 UDP. وقائمة المنافذ الرسمية للعبة لا تذكر منفذاً ثالثاً. وهما مكتوبان في servertest.ini كإعدادين منفصلين، فالمنفذ الثاني لا ينتج عن الأول آلياً:

DefaultPort=16261
UDPPort=16262
SteamPort1=8766
SteamPort2=8767
RCONPort=27015
RCONPassword=

وتوزيع المهام واضح. فـ16261 UDP يحمل حركة اللعب وإنشاء الاتصال ويجيب عن استعلامات متصفح الخوادم. و16262 UDP هو منفذ الاتصال المباشر للعملاء. فإذا غاب الأول، لم يجد الخادمَ أحد، وإذا غاب الثاني، رأى لاعبوكم الإدراج ولم يدخلوا مع ذلك. ومن هنا بالتحديد تأتي أشهر رسالة خطأ في اللعبة، وهي أن المنفذ 16262 مغلق.

ونقطتان تسبّبان الإزعاج بانتظام. أولاً: كل نسخة من الخادم تحتاج إلى منفذي UDP حرّين. فمن يشغّل عالماً ثانياً على الجهاز نفسه يخصّص لذلك زوجاً ثانياً، مثلاً 16274 و16275، ويكتب القيمتين في servertest.ini الخاصة بالنسخة الثانية. ثانياً: SteamPort1 وSteamPort2 مكتوبان بالقيمتين 8766 و8767 في ملف الإعداد، لكنهما ينتميان إلى ربط Steam وليس إلى حركة اللعب. لا تفتحوهما إلا إذا لم يظهر خادمكم في قائمة Steam بدونهما، وليس على سبيل الاحتياط.

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

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

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

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

ss -lntup

المهم هو العمود الذي يحمل العنوان المحلي. فـ0.0.0.0:16261 و[::]:16261 يعنيان «قابل للوصول من الإنترنت بأكمله»، و127.0.0.1:27015 يعني «محلياً فقط» ولا يحتاج إلى أي إذن. وقارنوا النتيجة بإعدادكم بدلاً من الاعتماد على القيم الافتراضية:

grep -E "^(DefaultPort|UDPPort|SteamPort1|SteamPort2|RCONPort|Public|Open|MaxPlayers|MaxAccountsPerUser)=" ~/Zomboid/Server/servertest.ini

أما رؤية المهاجم فيوفرها فحص المنافذ من الخارج. ولأن Project Zomboid يستخدم UDP حصراً، يحتاج ذلك إلى فحص UDP، فالفحص المقتصر على TCP لا يُظهر منفذ اللعبة على الإطلاق:

nmap -Pn -sU -p 16261,16262,8766,8767 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

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

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

ufw allow 22/tcp comment "SSH"
ufw allow 16261/udp comment "Project Zomboid"
ufw allow 16262/udp comment "الاتصال المباشر لـProject Zomboid"
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment "RCON"
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

استبدلوا 203.0.113.10 بعنوانكم الخاص. والترتيب عند التشغيل هو ما يقرر إن كنتم ستحجبون أنفسكم. وهو مذكور مع طريق العودة في المقال إعداد جدار حماية UFW دون حجب نفسكم. وإذا حدث ذلك مع ذلك: في خوادم KVM الجذرية والخوادم المخصصة من KernelHost تصلون إلى النظام عبر وحدة تحكم VNC في منطقة العملاء، وهي تعمل بشكل مستقل عن شبكة النظام الضيف.

وكلمة عن قواعد البيانات والخدمات الإضافية: Project Zomboid لا يحتاج إلى أي منها. فما يستمع إلى جانب اللعبة على 0.0.0.0 يأتي من تثبيت سابق أو من لوحة إدارة، وهو ينتمي إما إلى الربط على 127.0.0.1 أو إلى الإطفاء.

3. إخراج RCON على المنفذ 27015 من الإنترنت

RCON هو التحكم عن بعد في الخادم، ويعمل في Project Zomboid على 27015 TCP. وفي servertest.ini المُسلَّمة مكتوب RCONPassword= بدون قيمة. ومن يستخدم RCON يضبط كلمة مرور عشوائية طويلة، لأن البروتوكول ينقل دون تشفير، ومنفذ RCON قابل للوصول بكلمة مرور ضعيفة يسلّم الخادم بالكامل، دون أن تكون هناك حاجة إلى حزمة واحدة من حركة الهجوم.

والطريق الآمن هو ألا تفتحوا المنفذ نحو الخارج من الأساس، وأن تصلوا إليه عبر تمرير منفذ بواسطة SSH. وبعد ذلك تتحدثون محلياً مع 127.0.0.1:27015:

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

ومن لا يحتاج إلى RCON يترك حقل كلمة المرور فارغاً والمنفذ مغلقاً. فالخدمة غير القابلة للوصول لا يمكن تجربة كلمات مرورها ولا إغراقها.

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

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

iptables -I INPUT -p udp --dport 16261:16262 -m hashlimit --hashlimit-name pz_udp --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP
iptables -L INPUT -n -v

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

وملاحظتان في هذا الصدد. قواعد 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. تخفيف تتبّع الاتصالات

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

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

وحركة اللعب في Project Zomboid لا تحتاج إلى تتبّع الحالة، لأن UDP لا يملك حالة. لذلك تستطيعون إبقاء منفذي اللعبة خارج الجدول:

iptables -t raw -I PREROUTING -p udp --dport 16261:16262 -j NOTRACK

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

6. تأمين الانضمام والخانات

الأسطر التالية لا تكلّف شيئاً وتعمل ضد كل ما يأتي عبر طريق الانضمام النظامي:

Password=A-LONG-RANDOM-PASSWORD
Open=false
MaxAccountsPerUser=1
MaxPlayers=32
DenyLoginOnOverloadedServer=true

Password هي كلمة مرور الخادم المشتركة وهي منفصلة عن حساب اللاعب الفرد. وOpen=false يعني أن الحسابات التي أنشأها مدير مسبقاً وحدها يحق لها الانضمام، وهذه هي القائمة البيضاء في اللعبة. وMaxAccountsPerUser يحدد عدد الحسابات التي يحق لمستخدم Steam واحد أن ينشئها على خادمكم، والقيمة الافتراضية 0 تعني بلا حد. وMaxPlayers مضبوط من المصنع على 32، وفوق ذلك تُحذّر الوثائق صراحةً من سوء تحميل الخريطة ومن فقدان التزامن.

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

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

7. مطابقة الإضافات عند الاتصال هي أغلى ثانية في خادمكم

يفحص Project Zomboid عند الاتصال أكثر من كلمة مرور. وقائمة إضافات الخادم مكتوبة في سطرين من servertest.ini: يحتوي WorkshopItems معرّفات Workshop الرقمية، ويحتوي Mods معرّفات تحميل الإضافات، وكلاهما مفصول بفاصلة منقوطة. وعند الانضمام يطابق العميل هذه القائمة، ويُنزّل محتويات Workshop الناقصة آلياً عبر Steam، ولا يتلقى بيانات العالم بالتدفق إلا بعد ذلك. وإضافةً إلى ذلك يقارن الخادم عند DoLuaChecksum=true المجاميع الاختبارية لملفات اللعبة ويطرد العملاء الذين لا تطابق ملفاتهم ملفاته.

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

DenyLoginOnOverloadedServer=true
LoginQueueEnabled=true
LoginQueueConnectTimeout=60

يرفض DenyLoginOnOverloadedServer التسجيلات الجديدة ما دام الخادم مُثقلاً، بدلاً من أن تُقطَع الجولة الجارية معها. ويضع LoginQueueEnabled المنضمين في طابور بدلاً من معالجتهم في وقت واحد، ويحدد LoginQueueConnectTimeout المدة التي يحق لعملية انضمام أن تستغرقها، والقيمة الافتراضية 60 ثانية، والمسموح من 20 حتى 1200.

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

8. قائمة الخوادم وUPnP والعنوان الخاص

والصراحة هنا أجدى من التفكير الرغبوي: عنوان IP الخاص بكم لا يمكن إبقاؤه سراً. فـPublic=true يُظهر الخادم في متصفح اللعبة، والخادم المرتبط بـSteam مرئي وفق الوثائق في متصفح خوادم Steam على أي حال. أي أن Public=false يسلبكم الظهور أمام اللاعبين الجدد دون أن يجعلكم غير مرئيين.

Public=true
PublicName=My Zomboid Server
UPnP=false
server_browser_announced_ip=

UPnP مضبوط من المصنع على true ويترك الخادم يحاول إنشاء إذن منفذ بنفسه على بوابة إنترنت. وعلى خادم مستأجر لا توجد بوابة كهذه، فتضيع المحاولة هدراً وتنتمي إلى الإطفاء. ويبقى server_browser_announced_ip فارغاً، إلا إذا كان خادمكم يملك عدة عناوين وكان مطلوباً أن يظهر تحت أحدها بالتحديد. وهذا الحقل بعينه تحتاجونه لاحقاً من جديد، عندما تنتقلون إلى عنوان IP مخصص للحماية.

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

9. القياس ما دام كل شيء يعمل بشكل طبيعي

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

sar -n DEV 1 10
ip -s link show eth0
tcpdump -ni eth0 "udp port 16261 or udp port 16262" -c 200 -q
journalctl -u zomboid --since "-15 min" | tail -50

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

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

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

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

والهجمات المعتادة على مجتمعات خوادم اللعب تقع بين 5 و50 Gbit/s، أي بين خمسة أضعاف وخمسين ضعفاً من وصلة عادية. ولا يوجد لذلك أي إعداد محلي. فالهجمات الحجمية يجب أن تنتهي في الشبكة الواقعة قبل الخادم.

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

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

الحماية من 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 مخصص للحماية من النواة الفرانكفورتية، يُحوَّل خادمكم إليه داخل شبكتنا. ولا يلزم أي تغيير في جهتكم، فالعنوان الجديد تكتبونه فقط في المكان الذي يجد فيه لاعبوكم الخادم.
• قواعد حماية تديرونها بأنفسكم لكل منفذ وبروتوكول في منطقة العملاء: تحدّدون ما المسموح على 16261 و16262 UDP، ويبقى كل ما عدا ذلك مغلقاً، دون أن تكتبوا تذكرة لذلك.
• التغييرات تسري في الوقت الفعلي، أي تستطيعون التعديل أثناء هجوم جارٍ.
• ملف حماية مناسب. فللألعاب الشائعة توجد ملفات جاهزة، وللتطبيقات المعدَّلة والخاصة تضبطون القواعد لكل منفذ وبروتوكول بأنفسكم. وProject Zomboid يمكن تحديده بدقة خاصة في هذا السياق، لأن حركة اللعب بأكملها تجري عبر منفذي UDP متجاورين.

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

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

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

«لاعبيّ يتلقون رسالة بأن المنفذ 16262 مغلق»: هذا ليس هجوماً، بل إذناً ناقصاً. فالخادم يحتاج إلى المنفذين كليهما، 16261 UDP و16262 UDP، وذلك كقاعدة UDP. والإذن على TCP بالرقمين نفسيهما لا يفعل شيئاً. تحقّقوا بالأمر ufw status verbose وبفحص UDP من الخارج مما إذا كان المنفذان مفتوحين فعلاً.

«غيّرت عنوان IP وكنت غير متصل من جديد بعد ساعتين»: المهاجم حصل على العنوان الجديد من المصدر نفسه الذي حصل منه على القديم، وهو في الغالب الإدراج في القائمة، أو بوت Discord بعرض للحالة، أو مُدخَل DNS قديم. وفي Project Zomboid يكلّف التغيير إضافةً إلى ذلك: فالعملاء يحفظون بيانات الخريطة محلياً تحت العنوان والمنفذ، في مجلد على النمط 123.45.0.12_16261_... تحت Zomboid/Saves. وبعد التغيير يُنزّل كل لاعب الخريطة المستكشفة من الخادم من جديد. أي أن تغيير العنوان ربح للوقت بتكاليف إضافية، لا حل.

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

«اللاعبون يُطرَدون عند الانضمام، لكن الخادم يعمل بشكل طبيعي»: هذه هي المطابقة في الغالب الأعم، وليست هجوماً. والأسباب هي اختلاف في الإصدار بين العميل والخادم، أو مُدخَل Workshop ناقص أو قديم، أو مجموع اختباري غير مطابق. والعميل يذكر في العادة الإضافات التي لا تتطابق. طابقوا WorkshopItems وMods سطراً بسطر.

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

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

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

باختصار

• يحتاج خادم Project Zomboid المخصص إلى منفذين مفتوحين بالضبط: 16261 UDP (DefaultPort) و16262 UDP (UDPPort). وكلاهما مكتوب كإعدادين منفصلين في servertest.ini.
• RCON يعمل على 27015 TCP ومكتوب من المصنع بدون كلمة مرور. والمنفذ لا ينتمي إلى الإنترنت المفتوح، بل يُقيَّد على العنوان الخاص أو يُغلق.
• مطابقة الإضافات عند الاتصال هي أغلى موضع: فالإصدار والمجموع الاختباري وقائمة Workshop وبيانات الخريطة تكلّف وقت معالجة، وكذلك في كل محاولة مرفوضة. وDenyLoginOnOverloadedServer وطابور الانضمام هما المكبحان المدمجان ضد ذلك.
• كلمة مرور الخادم وOpen=false وMaxAccountsPerUser=1 تحمي منطق اللعبة. ولا يعمل أي من هذه الإعدادات ضد وصلة مشبعة.
• الحد الفيزيائي ثابت: 1 Gbit/s تعني 125 ميغابايت في الثانية، وعند حزم بحجم 64 بايت نحو 1.49 مليون حزمة في الثانية. والهجمات المعتادة على خوادم اللعب تقع بين 5 و50 Gbit/s.
• الهجمات الحجمية يجب أن تنتهي في الشبكة الواقعة قبل الخادم. ولدى KernelHost تكون هذه 17 Tbps سعة تخفيف في شبكة التنقية العالمية وتصفية Arbor في الوقت الفعلي بسعة 3.2 Tbps في فرانكفورت أم ماين، دون زيادة في السعر ودون توجيه إلى العدم.
• ومن يتعرض للقصف بشكل دائم يتحكم في التصفية بنفسه عبر Advanced DDoS Protection: عنوان IP مخصص للحماية، وقواعد لكل منفذ وبروتوكول، وتغييرات في الوقت الفعلي، ابتداءً من 50.00 EUR في الشهر.

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