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

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

جميع المعطيات تتعلق بخادم FXServer يحمل gamename rdr3 ويعمل بنظام ⁦Debian 12⁩ أو ⁦Debian 13⁩ أو ⁦Ubuntu 22.04 LTS⁩ أو ⁦Ubuntu 24.04 LTS⁩. والأوامر مكتوبة للمستخدم root، وكمستخدم عادي تضعون sudo قبلها. وRedM هو تعديل ⁦Red Dead Redemption 2⁩ من Cfx.re والمشروع الشقيق لـFiveM. وكلاهما يعمل ببرنامج الخادم نفسه، ولهذا فإن جزءاً من تقنية الشبكة متطابق فعلاً. وحيث يصحّ ذلك، يُذكر هنا في جملة واحدة ويبقى الجزء المفصّل في المقال حماية خادم FiveM من هجمات DDoS. وكل ما عدا ذلك في هذا النص خاص بـRedM.

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

لماذا تصبح خوادم RedM هدفاً لهجمات DDoS بهذا التكرار

خادم RedM هدف أكثر جدوى مما يُستنتج من عدد لاعبيه. والسبب هو بالضبط صغر حجم المشهد. ففي سبتمبر 2026 أحصت أدوات تتبّع قوائم الخوادم العامة نحو 2,000 خادم RedM نشط مع نحو 12,400 لاعب في الوقت نفسه، مقابل نحو 39,000 خادم FiveM مع نحو 325,000 لاعب. ومن يُعطّل خادماً واحداً من 2,000 خادم RedM يسحب من الشبكة نسبةً من المشهد بأكمله أكبر بكثير من نسبة من يضرب خادماً واحداً من 39,000 خادم FiveM. فبالنسبة لمهاجم يريد إيذاء مشروع منافس، تكون الرافعة أكبر بما لا يقاس.

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

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

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

يرتبط خادم RedM افتراضياً بمنفذ واحد فقط، وذلك على البروتوكولين كليهما. وفي server.cfg يُكتب لذلك:

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"
set gamename rdr3
sv_enforceGameBuild 1491
sv_licenseKey "cfxk_..."

والسطر set gamename rdr3 هو الوحيد الذي يميّز خادم RedM عن خادم FiveM. فإذا غاب، سجّل FXServer نفسه خادماً لـGTA V، ولم يتصل به عميل RedM. ولا يملك RedM منفذ استعلام خاصاً ولا منفذ RCON خاصاً: فاستعلام الخادم وإنشاء الاتصال وحركة اللعب وRCON تسير كلها عبر المُدخَلين نفسيهما على 30120. وهذه هي الأرقام الصلبة:

ومن المنافذ الأربعة المذكورة ينتمي اثنان بالضبط إلى الشبكة المفتوحة: ⁦30120 TCP⁩ و⁦30120 UDP⁩. أما المنفذ 40120 والمنفذ 3306 فلا مكان لهما هناك، وينبغي تقييد SSH على المنفذ 22 على عناوينكم الخاصة. وهذا هو أكثر الأخطاء القابلة للتجنب شيوعاً على خوادم RedM، لأن مشاريع كثيرة تبدأ بوصفة txAdmin جاهزة ثم لا تتحقق أبداً مما يعرضه الخادم إلى الخارج.

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

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

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

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

ss -lntup

المهم هو العمود الذي يحمل العنوان المحلي. فـ0.0.0.0:30120 و[::]:30120 يعنيان «قابل للوصول من الإنترنت بأكمله»، و127.0.0.1:3306 يعني «محلياً فقط» ولا يحتاج إلى قاعدة في جدار الحماية. وإلى جانب FXServer يظهر على خادم RedM بانتظام txAdmin على 40120، وMariaDB على 3306، وخادم ويب لصفحة المشروع، وأحياناً خدمة صوت. أما رؤية المهاجم فيوفرها فحص المنافذ من الخارج:

nmap -Pn -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. إبقاء 30120 على TCP وUDP وحدهما مفتوحين

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

ufw allow 22/tcp comment 'SSH'
ufw allow 30120/tcp comment 'RedM'
ufw allow 30120/udp comment 'RedM'
ufw allow from 203.0.113.10 to any port 40120 proto tcp comment 'txAdmin'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

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

ولا تنتمي قاعدة البيانات إلى الشبكة المفتوحة بأي حال. فـVORP وRSGCore وRedEM:RP تحتاج كلها إلى MariaDB أو MySQL، وغالباً عبر oxmysql بسلسلة اتصال في server.cfg. وهذا الاتصال يسير محلياً، فلا حاجة إلى أن يكون المنفذ قابلاً للوصول من الخارج. تحقّقوا في /etc/mysql/mariadb.conf.d/50-server.cnf من وجود هذا السطر:

bind-address = 127.0.0.1

3. تأمين نقاط النهاية HTTP في FXServer

يجيب FXServer على الجزء TCP من 30120 عن طلبات HTTP، دون أن يحتاج أحد إلى تشغيل ⁦Red Dead Redemption 2⁩. انظروا ما الذي يسلّمه خادم RedM الخاص بكم هناك:

curl -s http://127.0.0.1:30120/info.json | head -c 600
curl -s http://127.0.0.1:30120/players.json | head -c 600
curl -s http://127.0.0.1:30120/dynamic.json

يسرد /players.json اللاعبين المتصلين مع مُعرّفاتهم، ويسرد /info.json إعداد الخادم والموارد المحمّلة، ويسرد /dynamic.json الإشغال الحالي. وهذه النقاط الثلاث بالضبط هي طريق الهجوم الموثّق على الطبقة السابعة ضد خوادم FiveM وRedM: فهي قابلة للوصول دون تسجيل دخول، ويمكن استعلامها عدداً غير محدود من المرات، وكل استعلام يكلّف خادمكم عملاً، ومحتواها يكشف للمهاجم متى يكون الهجوم مُجزياً. وهناك إجراءان مضادان لا يكلّفان شيئاً. أولاً، لا تنتمي نقاط اتصال اللاعبين إلى الجواب، ويكفي لذلك سطر واحد في server.cfg:

sv_endpointPrivacy true

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

4. إخراج txAdmin على المنفذ 40120 من الشبكة المفتوحة

txAdmin هي واجهة الإدارة المضمّنة في بناء FXServer لأجل FiveM وRedM، وهي تستمع افتراضياً على ⁦40120 TCP⁩. ووراءها يقع الوصول الكامل إلى خادمكم: إعادة التشغيل، وقائمة الحظر، وقاعدة بيانات اللاعبين، وإدارة الموارد. وإذا لم يكن لديكم عنوان IP ثابت للإذن، فاتركوا المنفذ مغلقاً من الخارج وصِلوا إليه عبر تمرير منفذ محلي بواسطة SSH، ثم افتحوا في المتصفح http://127.0.0.1:40120:

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

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

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

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

iptables -I INPUT -p tcp --dport 30120 --syn -m connlimit --connlimit-above 8 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 30120 -m hashlimit --hashlimit-name redm_udp --hashlimit-mode srcip --hashlimit-above 500/sec --hashlimit-burst 750 -j DROP

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

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

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

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

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

6. تأمين الخانات الـ32 ضد إغراق الانضمام

يملك خادم RedM دون ⁦OneSync 32⁩ خانة بالضبط. ومع OneSync تصبح 48، وما فوق ذلك يحتاج إلى اشتراك Element Club لأجل ما يصل إلى 1,024 خانة. وهذا الرقم ذو صلة بالأمن، لأنه الحد الأعلى الذي يجب على المهاجم أن يملأه: فمن يُبقي 32 محاولة انضمام مفتوحة في وقت واحد يشغل خادماً قياسياً بالكامل، دون أن يصل لاعب واحد فعلاً إلى اللعبة. أما في مشروع FiveM بـ128 خانة فتكون العتبة نفسها أعلى بأربعة أضعاف.

وهناك ميزة خاصة بـRedM تعوّض ذلك جزئياً: فـRedM يشترط نسخة حقيقية من ⁦Red Dead Redemption 2⁩، سواء اشتُريت عبر Steam أو Epic Games أو Rockstar، ويشترط معها مُشغّل Rockstar. لذلك يكلّف إغراق الانضمام بآلاف الحسابات المؤقتة، كما هو معتاد في الألعاب المجانية، مالاً حقيقياً هنا. وبذلك تنتقل الهجمات إلى مستوى الشبكة وإلى نقاط النهاية HTTP، حيث لا حاجة إلى نسخة من اللعبة.

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

sv_authMaxVariance 1
sv_authMinTrust 5
sv_maxclients 32

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

7. التقدير الصحيح للإدراج في قائمة خوادم RedM

هنا تفيد الصراحة بدلاً من التفكير الرغبوي: عنوان IP الخاص بكم لا يمكن إبقاؤه سراً. فـRedM يستخدم بنية خوادم Cfx.re الرئيسية نفسها التي يستخدمها FiveM، والإدراج في القائمة يحتوي في الحقل connectEndPoints على نقطة نهاية الاتصال بنص صريح. وعبر الواجهة العامة على servers-frontend.fivem.net يمكن استعلام العنوان المرتبط بأي رمز cfx.re، في RedM كما في FiveM. ومن لا يحتاج إلى الإدراج العام من الأصل، لأن مشروعه يعمل عبر Discord والاتصال المباشر وحدهما، يستطيع إدارة الخادم كخادم خاص بواسطة sv_master1 "": فلا يعود الانضمام إليه ممكناً عبر قائمة الخوادم. لكن ذلك يكلّف كامل الظهور أمام اللاعبين الجدد، وفي مشهد يضم 2,000 خادم يكون الظهور هو محرك النمو الحقيقي.

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

8. التحقق من أحداث VORP وRSGCore وRedEM من جهة الخادم

كثير من الانقطاعات التي تُبلَّغ كهجوم DDoS يعود إلى سكربت واحد. فموارد RedM تتواصل عبر أحداث الشبكة، والحدث الذي يُنفّذه الخادم دون تحقّق هو باب مفتوح: فمن يُصدر في العميل TriggerServerEvent بقيم عشوائية يستطيع توليد دولارات، أو إنشاء خيول، أو إطلاق استعلامات قاعدة بيانات في حلقة حتى يتوقف الخادم. وهذا يصيب أطر العمل الثلاثة الشائعة بالقدر نفسه: VORP Core الذي يملك أكبر قاعدة سكربتات منذ عام 2020، وRSGCore، وRedEM:RP الأقدم.

والأكثر عرضةً للخطر هي موارد المخزون والشخصيات، لأنها تكتب في قاعدة البيانات عند كل نداء. وحلقة أحداث تحفظ حالة المخزون عشر مرات في الثانية تُثقل خادم RedM أكثر من بعض إغراقات الحزم، وهي تأتي من الداخل حيث لا يعمل أي جدار حماية.

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

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 port 30120 -c 200 -q

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

أين تنتهي هذه الإجراءات

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

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

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

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

ما يختلف في RedM عن FiveM

الجواب القصير: تقنية الشبكة متطابقة، والمحيط ليس كذلك. فكلاهما يعمل على FXServer نفسه، وكلاهما يستخدم 30120 على TCP وUDP، وكلاهما يُدار عبر txAdmin على 40120. وكل ما تقرؤونه أعلاه عن المنافذ والمعدلات ونقاط النهاية يسري على كليهما. أما المختلف فهو الظروف الإطارية، وهي بالضبط ما يحدد سرعة تأثير الهجوم:

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

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

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

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

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

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

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

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

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

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

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

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

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

«خادمي لا يظهر في قائمة خوادم RedM، وأشتبه في وجود هجوم»: تحقّقوا أولاً من الإعداد. فإذا غاب set gamename rdr3، سجّل FXServer نفسه خادماً لـGTA V ولم يظهر في قائمة RedM. وإذا غاب مفتاح الترخيص من portal.cfx.re أو كان غير صحيح، لم يتم الإدراج كذلك. والهجوم يبدو مختلفاً: فالإدراج يبقى قائماً، والاتصال هو الذي يفشل.

«مئات اللاعبين يحصلون على خطأ عند الانضمام، وهذا يبدو كإغراق»: في الغالب هي مشكلة في إصدار بناء اللعبة. فإذا لم يتوافق sv_enforceGameBuild مع ما تتوقعه مواردكم، أبلغ العميل عن «server specified an invalid game enforcement». اضبطوا القيمة التي يطلبها إطار العمل لديكم، والمعتاد 1436 أو 1491، وأعيدوا تشغيل الخادم بالكامل.

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

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

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

«txAdmin يعرض مئات محاولات الاتصال الفاشلة»: هذا إغراق انضمام ويصيب منطق اللعبة، لا الوصلة. ويعمل ضده القائمة البيضاء، وفحص الحساب عبر sv_authMinTrust، والحد الأعلى للاتصالات لكل عنوان مصدر.

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

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

باختصار

• يحتاج خادم RedM إلى منفذين مفتوحين بالضبط: ⁦30120 TCP⁩ و⁦30120 UDP⁩، ويُضبطان عبر endpoint_add_tcp وendpoint_add_udp. ولا يوجد منفذ استعلام خاص ولا منفذ RCON خاص.
• لا ينتمي txAdmin على ⁦40120 TCP⁩ ولا قاعدة البيانات على ⁦3306 TCP⁩ إلى الشبكة المفتوحة، بل ينتميان إلى عنوانكم الخاص وإلى 127.0.0.1 على التوالي.
• يُخرج sv_endpointPrivacy true عناوين IP الخاصة باللاعبين من المُخرَجات العامة، وحالة خادم محفوظة مؤقتاً تخفّف الحِمل عن /players.json، وهو طريق الهجوم الموثّق على الطبقة السابعة ضد خوادم Cfx.re.
• يملك خادم RedM دون ⁦OneSync 32⁩ خانة، ومع ⁦OneSync 48⁩، ومع Element Club حتى 1,024. وكلما صغر عدد الخانات كان إغراق الانضمام أرخص، وكانت القائمة البيضاء وفحص الحساب أهم.
• يعمل RedM وFiveM على FXServer نفسه، ويتميّزان بـset gamename rdr3 وحده. ولهذا فالدفاع الشبكي متطابق، أما المحيط فلا: نحو 2,000 خادم RedM مقابل نحو 39,000 خادم FiveM يجعلان كل مشروع RedM على حِدة هدفاً أكثر قيمة.
• تنتهي قواعد جدار الحماية المحلية حيث تمتلئ الوصلة: فـ⁦1 Gbit/s⁩ تعني 125 ميغابايت في الثانية، وعند حزم بحجم 64 بايت تتسع لنحو 1.49 مليون حزمة في الثانية. وكل ما زاد على ذلك يجب أن ينتهي في الشبكة الواقعة قبل الخادم.
• لدى KernelHost تكون الحماية الدائمة ذات المستويين مشمولة في كل حزمة خادم، وفعّالة من لحظة التسليم، ودون توجيه إلى العدم. ومن يريد التحكم في التصفية بنفسه يحصل مع Advanced DDoS Protection ابتداءً من ⁦50.00 EUR⁩ في الشهر على عنوان IP مخصص للحماية وقواعد خاصة لكل منفذ وبروتوكول.

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