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

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

جميع المعطيات تتعلق بخادم DayZ مخصص خاص بكم مع serverDZ.cfg، سواء عمل على Windows Server أو على Debian وUbuntu عبر طبقة توافق. فبرنامج خادم Linux أصلي جاهز للإنتاج لأجل الفرع المستقر لا تُسلّمه Bohemia Interactive، أما بناء Linux التجريبي فلا يقبل إلا العملاء التجريبيين. وأوامر Linux مكتوبة للمستخدم root، وكمستخدم عادي تضعون sudo قبلها.

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

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

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

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

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

رابعاً، تجري حركة DayZ بالكامل عبر UDP. ولا يعرف UDP أي إنشاء اتصال يمكن اشتراطه، وعنوان المرسل قابل للتزييف. لذلك لا يحتاج المهاجم إلى الدخول إلى خادمكم ولا إلى مخاطبته بشكل صحيح لكي يولّد حِملاً. وأن الشركة المنتجة نفسها تتعرض لذلك أظهره فبراير 2025: فالخدمات الإلكترونية لدى Bohemia Interactive لأجل DayZ وArma Reforger كانت تحت قصف DDoS أكثر من أسبوع، وقد تأكد ذلك في 3 فبراير 2025 ولم يكن قد انتهى بعد في 6 فبراير 2025، وخوادم المجتمع كانت متأثرة معها. وما هو هجوم DDoS بالتفصيل يشرحه المقال ما هو هجوم DDoS؟.

منافذ خادم DayZ: جدول الوقائع

يتكلم خادم DayZ عبر UDP حصراً. ولا يوجد منفذ لعبة على TCP. والقيمة الوحيدة الثابتة فعلاً في DayZ هي ⁦2302 UDP⁩ كمنفذ للعبة، وكل ما عداه قابل للضبط ويختلف حسب المزوّد. لذلك انظروا في سطر التشغيل الخاص بكم وفي serverDZ.cfg الخاص بكم، بدلاً من الاعتماد على قيمة افتراضية.

وقيمتان تثيران الالتباس بانتظام، ولذلك يأتي الحل هنا. منفذ استعلام Steam: الإعداد النموذجي المُسلَّم من Bohemia يضبط steamQueryPort = 2305;، بينما يستخدم جزء كبير من المزوّدين ⁦27016 UDP⁩. والقيمتان صحيحتان، والحاسم وحده هو القيمة الموجودة في ملفكم. منفذ BattlEye RCon: هنا لا يوجد أي معيار مُلزم على الإطلاق. والقاعدة الاستدلالية الشائعة هي منفذ اللعبة زائد ثلاثة، أي 2305، ومزوّدون آخرون يضبطون 2310. ومنذ الإصدار 1.13 من DayZ يقرأ BattlEye المعامل RConPort في BEServer_x64.cfg بشكل موثوق، أما قبل ذلك فكان المنفذ صعب التوقع.

ويترتب على ذلك فخ يقع فيه كثير من المشغّلين: لا تضبطوا steamQueryPort وRConPort أبداً على القيمة نفسها. فإذا كان إعدادكم يخصّص 2305 لاستعلام Steam، فمكان RCon منفذ آخر، مثلاً 2310.

لماذا يكون منفذ استعلام Steam أكثر المنافذ حساسية

يجيب منفذ استعلام Steam عن ثلاثة استعلامات هي A2S_INFO وA2S_PLAYERS وA2S_RULES. فـ A2S_INFO يسلّم اسم الخادم والخريطة وعدد اللاعبين والإصدار، وA2S_PLAYERS أسماء اللاعبين المتصلين، وA2S_RULES متغيّرات الخادم المضبوطة. وكل جواب من هذه الأجوبة أكبر بشكل واضح من الطلب الذي أطلقه، وهذا بالضبط ما يجعل المنفذ خطيراً مرتين.

فبالنسبة لكم كهدف يعني ذلك: يستطيع المهاجم أن يُشغل منفذ الاستعلام لديكم ببضعة بايتات لكل طلب، بينما يبني خادمكم في كل مرة جواباً كاملاً ويرسله. وبالنسبة لأطراف ثالثة يعني ذلك: يستطيع المهاجم أن يستعلم من خادمكم بعنوان مرسل مزيف ويوجّه الأجوبة إلى هدفه الحقيقي. وخادمكم عندئذٍ ليس ضحيةً فقط، بل مُضخِّماً. ولهذا أضافت Valve إلى A2S_INFO في ديسمبر 2020 استعلام تحقّق (Challenge): فالخادم يجيب أولاً برقم عشوائي يجب على صاحب الطلب أن يعيد إرساله. وهذا يُضعف التضخيم لكنه لا يُنهيه، لأن ليس كل استعلام يسلك هذا الطريق.

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

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

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

1. الجرد: ما المنافذ التي يفتحها خادم DayZ فعلاً

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

ss -lnup
ss -lntup

وعلى Windows Server يسلّم موجّه الأوامر الصورة نفسها:

netstat -ano -p UDP | findstr "2302 2303 2304 2305 27016"

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

grep -iE "steamQueryPort|maxPlayers|password|enableWhitelist|verifySignatures" serverDZ.cfg
grep -iE "RConPort|RestrictRCon" battleye/BEServer_x64.cfg

أما رؤية المهاجم فيوفرها فحص منافذ UDP من الخارج، يُنفَّذ من جهاز آخر:

nmap -Pn -sU -p 2302-2310,27015-27020 YOUR.SERVER.IP.ADDRESS

2. فتح ما يحتاجه سطر التشغيل وserverDZ.cfg فعلاً وحده

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

ufw allow 22/tcp comment 'SSH'
ufw allow 2302:2305/udp comment 'DayZ Game Port'
ufw allow 27016/udp comment 'DayZ Steam Query'
ufw allow from 203.0.113.10 to any port 2310 proto udp comment 'BattlEye RCon'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

استبدلوا 203.0.113.10 بعنوانكم الخاص، و27016 بالقيمة الموجودة فعلاً في سطر steamQueryPort لديكم. والدليل الكامل مع طريق النجاة تجدونه في إعداد جدار حماية UFW دون حجب نفسكم. وعلى خادم Windows يسري المبدأ نفسه: قاعدة واردة لكل مجموعة منافذ، وسطح المكتب البعيد مقصور على العنوان الخاص، وكل ما عدا ذلك محجوب.

3. تحديد معدل منفذ استعلام Steam بدلاً من إغلاقه

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

iptables -I INPUT -p udp --dport 27016 -m hashlimit --hashlimit-name dayz_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 2302 -m hashlimit --hashlimit-name dayz_game --hashlimit-mode srcip --hashlimit-above 600/sec --hashlimit-burst 900 -j DROP

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

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

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

ومع UFW تنتمي هذه القواعد إلى /etc/ufw/before.rules، لأنها تختفي خلاف ذلك عند ufw reload التالي. وإضافةً إلى ذلك تملك مكتبة خوادم Steam مكبحاً خاصاً بها للحزم بلا اتصال: فمتغيّر البيئة STEAM_GAMESERVER_RATE_LIMIT_200MS يُسقط جميع حزم A2S القادمة من عنوان ما، بمجرد أن يصل في نافذة مقدارها 200 ميلي ثانية أكثر من القيمة المضبوطة.

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

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

BattlEye هو مكوّن مكافحة الغش في DayZ ويُشغَّل في serverDZ.cfg بالسطر BattlEye = 1;. أما الإدارة عن بُعد فتقع في ملف خاص بها، هو BEServer_x64.cfg في مجلد BattlEye إلى جانب BEServer_x64.dll، وهو المجلد الذي يضبطه سطر التشغيل بالمعامل -BEpath=:

RConPassword ALongRandomPassword
RConPort 2310
RestrictRCon 0

وثلاث قواعد في هذا الشأن. أولاً: منفذ RCon هو UDP لا TCP. وقاعدة جدار حماية تقول proto tcp بالخطأ لا تُصفّي شيئاً، وتجعل أدوات الإدارة تعمل في الفراغ في الوقت نفسه. ثانياً: اقصروا المنفذ على عناوين مديريكم. ومن لا يملك عنواناً ثابتاً فليحجب المنفذ من الخارج بالكامل ويشغّل أداة الإدارة على الخادم مباشرةً، بالوصول عبر SSH أو سطح المكتب البعيد. ثالثاً: RestrictRCon 1 يحدّ من الأوامر القابلة للتنفيذ عبر RCon، وهو الإعداد الصحيح بمجرد أن يملك أكثر من شخص واحد وصولاً.

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

5. طابور تسجيل الدخول والقائمة البيضاء واستنفاد الخانات

لا يعالج DayZ الاتصالات كلها في وقت واحد، بل عبر طابور. وخمس قيم في serverDZ.cfg تتحكم فيه:

maxPlayers = 60;
loginQueueConcurrentPlayers = 5;
loginQueueMaxPlayers = 100;
guaranteedSlots = 10;
maxPing = 200;

يحدد loginQueueConcurrentPlayers عدد اللاعبين الذين يُدخَلون في وقت واحد (والقيمة الافتراضية 5)، ويحدّ loginQueueMaxPlayers من الطابور نفسه (والقيم المعتادة بين 100 و500). وهنا بالضبط يبدأ استنفاد الخانات: فالمهاجم لا يحتاج نطاقاً ترددياً، بل يحتاج فقط ما يكفي من الحسابات أو محاولات الاتصال لاحتلال الطابور. وعندها لا يعود اللاعبون الحقيقيون يمرّون، مع أن الخادم يعمل تقنياً بشكل سليم. ويحفظ guaranteedSlots أماكن لفريقكم، حتى تستطيعوا في هذه الحالة بالتحديد الوصول إلى الخادم بأنفسكم.

وتفيد ضد ذلك القائمة البيضاء المدمجة. وهي تُفعَّل بالسطر enableWhitelist = 1; ثم تقرأ الملف profiles/whitelist.txt، بمعرّف Steam64 واحد في كل سطر. وكل معرّف غير مُدرَج يُرفَض عند الاتصال. والملف يُقرأ عند تشغيل الخادم، أي أن التغييرات تحتاج إلى إعادة تشغيل. والإعداد الإضافي password في serverDZ.cfg يعمل بشكل مشابه، لكنه أضعف، لأن كلمة المرور تُمرَّر بين الناس ومعرّف Steam64 لا يُمرَّر.

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

6. الإضافات والتحقق من التوقيعات والنافذة الزمنية بعد إعادة التشغيل

الإضافات في DayZ ليست مسألة راحة فقط، بل هي جزء من سطح الهجوم. وأربعة إعدادات في serverDZ.cfg يجب أن تكون مضبوطة في كل الأحوال:

verifySignatures = 2;
forceSameBuild = 1;
allowFilePatching = 0;
BattlEye = 1;

يفحص verifySignatures = 2 كل ملف PBO مقابل توقيع .bisign التابع له، ويحتاج لذلك إلى ملفات .bikey المناسبة في المجلد keys. ويشترط forceSameBuild = 1 إصدار لعبة مطابقاً تماماً لإصدار الخادم. ويرفض allowFilePatching = 0 العملاء الذين يبدأون بملفات لعبة معدَّلة. ولا يُوقف أي من هذه الإعدادات هجوماً حجمياً، لكن ثلاثتها تُغلق الطريق الذي يُخرج فيه عميل مُتلاعَب به خادمكم عن مساره.

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

./DayZServer -config=serverDZ.cfg -port=2302 -profiles=./profiles -BEpath=./battleye -mod=@CF;@YourMod;@AnotherMod -cpuCount=4 -dologs -adminlog -netlog -freezecheck

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

7. تتبّع الاتصالات ومخزن الاستقبال ومعاملات نواة النظام

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

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

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

iptables -t raw -A PREROUTING -p udp --dport 2302 -j NOTRACK
iptables -t raw -A OUTPUT -p udp --sport 2302 -j NOTRACK
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.rmem_default=1048576
sysctl -w net.core.netdev_max_backlog=5000
sysctl -w net.netfilter.nf_conntrack_max=524288

انتباه: NOTRACK والقواعد التي تتحقق من الحالة يستبعد كل منهما الآخر. فمن يُخرج منفذ اللعبة من التتبّع لا يحق له أن يستخدم لهذا المنفذ أي قاعدة تحتوي -m conntrack --ctstate، وإلا لم يعد الفتح يعمل. وبشكل دائم تنتمي قيم sysctl إلى /etc/sysctl.d/، وإلا اختفت بعد إعادة التشغيل التالية.

8. عنوان IP الخاص بكم مكتوب في متصفح الخوادم

وهنا تستحق الصراحة أكثر من التمنّي: لا يمكن إبقاء عنوان IP لخادم DayZ عام سرّاً. فكل لاعب اتصل مرة يعرفه، ومتصفح الخوادم ينشره، ومشغّل DZSA يخزّنه مؤقتاً. وتغيير العنوان يمنحكم ساعات، ونادراً أياماً.

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

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

أهم خطوة هي تلك التي لا يفعلها أحد تقريباً مسبقاً: إنشاء خط أساس للمقارنة ما دام كل شيء يعمل بشكل طبيعي. فبدون قيمة طبيعية لا تستطيعون القول بعد الحادث إن 40,000 حزمة في الثانية كانت كثيرة أم كانت مجرد مساء سبت. وعلى جانب الخادم تُشغّلون لذلك السجلات المدمجة:

timeStampFormat = "Short";
logAverageFps = 300;
logPlayers = 300;
logFile = "server_console.log";

وlogAverageFps هو أصدق قيمة يسلّمها DayZ. فإذا انهار معدل إطارات الخادم بينما يبقى عدد اللاعبين كما هو، فهذه مشكلة إضافة أو اقتصاد. وإذا بقي معدل الإطارات ثابتاً بينما يُطرَد اللاعبون، فالسبب في الشبكة. وعلى جانب النظام يستمر القياس دائماً بالأمر 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 2302 -c 200 -q

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

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

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

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

الهجمات الحجمية يجب أن تنتهي في الشبكة الواقعة قبل الخادم. وهذه ليست عبارة تسويقية، بل فيزياء.

حماية DayZ من DDoS: ما تضعه 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 مخصص للحماية من النواة الفرانكفورتية، يُحوَّل خادمكم إليه داخل شبكتنا. ولا يلزم أي تغيير في جهتكم.
• قواعد حماية تديرونها بأنفسكم لكل منفذ وبروتوكول في منطقة العملاء: تضبطون بشكل منفصل ما المسموح على ⁦2302 UDP⁩، وما المسموح على منفذ الاستعلام، وما المسموح على منفذ RCon. وهذا الفصل بالذات هو الرافعة في DayZ، لأن حركة اللعب وحركة الاستعلام تبدوان مختلفتين تماماً.
• التغييرات تسري في الوقت الفعلي، أي تستطيعون التعديل أثناء هجوم جارٍ بدلاً من انتظار تذكرة.
• ملف حماية مناسب لكل لعبة، وكذلك للخوادم المعدَّلة بشدة وللتطبيقات الخاصة على أي منفذ TCP أو UDP.

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

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

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

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

«RCon لم يعد يتصل منذ أن صفّيت المنافذ»: يعمل BattlEye RCon عبر UDP. والفتح بالقيمة proto tcp على المنفذ نفسه لا يفعل شيئاً. وتحقّقوا إضافةً إلى ذلك مما إذا كان RConPort وsteamQueryPort مضبوطين بالخطأ على القيمة نفسها.

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

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

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

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

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

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

باختصار

• يحتاج خادم DayZ نحو الخارج إلى أمرين بالضبط: كتلة منفذ اللعبة بدءاً من ⁦2302 UDP⁩، ومنفذ استعلام Steam من سطر steamQueryPort لديكم. وكل ما عدا ذلك يُقيَّد أو يُغلق.
• منفذ BattlEye RCon لا يملك معياراً مُلزماً، ويعمل عبر UDP، ويُضبط في BEServer_x64.cfg بالمعامل RConPort. ولا ينتمي أبداً إلى الشبكة المفتوحة ولا يكون أبداً على القيمة نفسها التي عليها منفذ الاستعلام.
• حدّدوا معدل منفذ الاستعلام بدلاً من إغلاقه: فمن يُغلقه يغيب عن متصفح الخوادم وعن مشغّل DZSA، مع أن الاتصال المباشر يبقى يعمل.
• القائمة البيضاء وguaranteedSlots وطابور تسجيل الدخول تحمي أماكن لاعبيكم من استنفاد الخانات، لكنها لا تحمي وصلتكم من النطاق الترددي.
• أخطر نافذة زمنية في خادم DayZ هي إعادة التشغيل المجدولة كل ثلاث إلى أربع ساعات، لأن الإضافات والاقتصاد المركزي يُحمَّلان لدقائق والموعد معروف للعموم.
• من حجم هجوم يبلغ نحو ⁦1 Gbit/s⁩ أو بعض مئات الآلاف من الحزم في الثانية، تحسم الشبكة الواقعة قبل الخادم وحدها، لا جدار حمايتكم.
• لدى KernelHost تكون الحماية الدائمة ذات المستويين مشمولة في كل حزمة خادم دون زيادة في السعر ودون توجيه إلى العدم. وتُضاف Advanced DDoS Protection ابتداءً من ⁦50.00 EUR⁩ في الشهر عندما تريدون التحكم بأنفسكم في القواعد لكل منفذ.

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