حماية خادم MTA:SA من هجمات DDoS

يتصرف خادم Multi Theft Auto: San Andreas تحت هجوم DDoS بشكل مختلف عن أي مشروع GTA آخر لتعدد اللاعبين، لأنه يعرض ثلاث خدمات شبكية منفصلة في وقت واحد: حركة اللعب على 22003 UDP، وخادم HTTP كامل على 22005 TCP، واستعلام ASE على 22126 UDP. وكل واحدة من هذه الخدمات الثلاث قابلة للهجوم منفردةً، وكل واحدة تسقط بشكل مختلف. يعرض هذا المقال أولاً ما تستطيعون تأمينه بأنفسكم دون تكاليف إضافية، ثم أين تنتهي هذه الإجراءات عند فيزياء الوصلة، وفي الختام ما يجب أن تقدّمه حماية فعّالة من DDoS لـMTA:SA في الشبكة الواقعة قبل الخادم.

وإذا كان الهجوم جارياً الآن، فالسؤال الأهم هو أي الخدمات الثلاث يُصاب. فإذا بقي اللاعبون متصلين لكنهم لم يعودوا يحمّلون الموارد عند الانضمام، فالإصابة في خادم HTTP على 22005. وإذا غاب الخادم عن المتصفح بينما يواصل اللاعبون المتصلون اللعب بشكل طبيعي، فالإصابة في استعلام ASE على 22126. وإذا انقطعت جميع الاتصالات في وقت واحد، فإما أن 22003 هو الهدف وإما أن الوصلة ممتلئة. وجميع المعطيات تتعلق بخادم MTA بنظام Debian 12 أو Debian 13 أو Ubuntu 22.04 LTS أو Ubuntu 24.04 LTS، والأوامر مكتوبة للمستخدم root، وكمستخدم عادي تضعون sudo قبلها.

لماذا تصبح خوادم MTA:SA هدفاً لهجمات DDoS بهذه الكثرة

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

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

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

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

يحتاج خادم MTA:SA إلى ثلاثة منافذ بالضبط: 22003 UDP للعبة، و22005 TCP لخادم HTTP الداخلي، و22126 UDP لاستعلام ASE. والمنفذ الثالث ليس إعداداً قابلاً للاختيار بحرية، بل ينتج بشكل ثابت عن منفذ اللعبة زائد 123. فمن يضبط serverport على 22010 يحصل على الاستعلام على 22133.

وتفصيلان مكتوبان على هذا النحو في ملف mtaserver.conf المرفق ويُغفَل عنهما بانتظام. يجوز أن يحمل httpport القيمة الرقمية نفسها التي يحملها serverport، لأن أحد المنفذين على TCP والآخر على UDP. وserverip مضبوط على auto وينبغي أن يبقى كذلك: فالقيمة الثابتة تربط مقبس ASE بهذا العنوان بالتحديد وتكسر الإدراج في القائمة بمجرد أن يتغير العنوان.

بروتوكول استعلام ASE ولماذا هو مُضخِّم

ASE (All-Seeing Eye) بروتوكول استعلام يعمل على UDP فقط: فالبايت الأول من الحزمة يحدد الجواب، ولا يوجد أي إنشاء اتصال. ويعرف خادم MTA خمسة استعلامات ويجيب عنها على 22126:

• s هو استعلام ASE الكامل. ويبدأ الجواب بـEYE1 ويحتوي على اسم الخادم ونوع اللعب واسم الخريطة والإصدار وحالة كلمة المرور وعدد اللاعبين والقائمة الكاملة لجميع القواعد المضبوطة عبر setRuleValue، ثم كل لاعب متصل باسمه ونقاطه وزمن استجابته. وهذا الجواب بلا أي حد لحجمه.
• b وr هما الاستعلامان الأنحف لمتصفح اللعبة. ويبدأ الجواب بـEYE2 ويُقطَع في الكود المصدري عند 1,340 بايت، تجنباً للتفتيت.
• x يقدّم رسالة حالة مختصرة، وv يقدّم مُعرّف إصدار ASE وحده.

ومن ذلك تنشأ المشكلة. فالطلب يتكون من بايت حمولة واحد، أي من 29 بايت على السلك (20 بايت رأس IP، و8 بايت رأس UDP، وبايت حمولة واحد). والجواب بحمولة 1,400 بايت يصبح على السلك 1,428 بايت. والنسبة نحو 49 ضعفاً، ولأن UDP لا يعرف أي إنشاء اتصال، فعنوان المرسل قابل للتزييف. وبذلك يستطيع المهاجم استخدام خادمكم كمُضخِّم ضد هدف ثالث، دون أن يدخل لعبتكم أبداً. وفي الاستعلام الكامل ينمو المعامل مع عدد اللاعبين ومع كل قاعدة يضبطها الـgamemode لديكم.

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

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

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

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

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

ss -lntup

والمتوقع ثلاثة أسطر لعملية MTA: 0.0.0.0:22003 على UDP، و0.0.0.0:22005 على TCP، و0.0.0.0:22126 على UDP. فإذا ظهرت هناك إضافةً إلى ذلك قاعدة بيانات على 0.0.0.0:3306، أو خادم ويب، أو خدمة صوت منسية، فهذا ما يجب إيقافه. أما رؤية المهاجم فيوفرها فحص المنافذ من الخارج:

nmap -Pn -sU -p 22003,22126 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p 22005 YOUR.SERVER.IP.ADDRESS

ويحمل الخادم لذلك أمراً خاصاً به في وحدة التحكم. ففي وحدة تحكم الخادم يتحقق الأمر openports مما إذا كانت المنافذ الثلاثة كلها قابلة للوصول من الخارج.

2. إبقاء المنافذ الثلاثة التي يحتاجها MTA فعلاً وحدها مفتوحة

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

ufw allow 22/tcp comment 'SSH'
ufw allow 22003/udp comment 'MTA: اللعبة'
ufw allow 22005/tcp comment 'MTA: HTTP'
ufw allow 22126/udp comment 'MTA: ASE'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

والدليل الكامل مع طريق النجاة موجود في المقال إعداد جدار حماية UFW. وفي الخوادم الجذرية KVM والخوادم المخصصة من KernelHost تصلون إلى النظام عند الطوارئ عبر وحدة تحكم VNC في منطقة العملاء، وذلك حتى لو كانت الوصلة مشبعة.

ولا تنتمي قاعدة البيانات إلى الشبكة المفتوحة. فإذا أظهر الأمر ss -lntp | grep 3306 القيمة 0.0.0.0:3306، فاضبطوا في الملف /etc/mysql/mariadb.conf.d/50-server.cnf السطر bind-address = 127.0.0.1 وأعيدوا تشغيل الخدمة.

3. تهدئة منفذ ASE دون السقوط من قائمة الخوادم

بخلاف SA-MP، يقع الاستعلام في MTA:SA على منفذ خاص به، أي تستطيعون تحديد معدله بشكل مستقل عن تشغيل اللعب. وهذه هي أكبر ميزة عملية في هذه البنية: فقاعدة على 22126 لا تطرد لاعباً واحداً.

ومع nftables في جدول خاص، حتى لا يتعارض مجموع القواعد مع UFW:

nft add table inet mtaguard
nft add chain inet mtaguard input '{ type filter hook input priority -150 ; policy accept ; }'
nft add rule inet mtaguard input udp dport 22126 meter aseperip '{ ip saddr limit rate over 3/second burst 6 packets }' drop
nft add rule inet mtaguard input udp dport 22126 limit rate over 2000/second burst 500 packets drop
nft list table inet mtaguard

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

iptables -A INPUT -p udp --dport 22126 -m hashlimit --hashlimit-name mta_ase \
  --hashlimit-mode srcip --hashlimit-above 3/sec --hashlimit-burst 6 \
  --hashlimit-htable-expire 30000 -j DROP

ومحاولة إغلاق المنفذ بالكامل هي موازنة لا نصيحة سرية: فبدون ASE يختفي خادمكم من متصفح اللعبة ومعه التدفق العضوي للاعبين. وإذا أردتم ذلك مع هذا، فلا يكفي <ase>0</ase>. ففي الكود المصدري تتعلق إتاحة المنفذ بالربط «أو» بين وضع الإنترنت ووضع الشبكة المحلية، أي أن المقبس يبقى مفتوحاً مع <ase>0</ase> ما دام <donotbroadcastlan>0</donotbroadcastlan> مضبوطاً. ومن أراد إغلاق المنفذ فعلاً يضبط القيمتين:

<ase>0</ase>
<donotbroadcastlan>1</donotbroadcastlan>

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

4. تخفيف الحِمل عن خادم HTTP الداخلي

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

وأكثر الإجراءات فعالية هو إخراج التنزيلات من خادم اللعب بالكامل. ويجهّز MTA الملفات الواجب تسليمها لذلك بنفسه، وذلك في mods/deathmatch/resource-cache/http-client-files. فتُخرجون هذا المجلد عبر nginx أو lighttpd وتُدرجون العنوان في الملف mtaserver.conf:

<httpdownloadurl>http://cdn.your-domain.tld/mta</httpdownloadurl>

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

وإذا بقي الخادم الداخلي في الخدمة، فاستخدموا حدوده الخاصة. في الملف mtaserver.conf:

<httpmaxconnectionsperclient>5</httpmaxconnectionsperclient>
<httpdosthreshold>20</httpdosthreshold>
<http_dos_exclude></http_dos_exclude>
<httpthreadcount>8</httpthreadcount>

يحدد httpmaxconnectionsperclient الاتصالات المتزامنة لكل عميل بـ5 في المجال المسموح من 1 إلى 8. ويحدد httpdosthreshold عدد الاتصالات التي يحق لعنوان IP واحد بناؤها في وقت قصير، وقيمته الافتراضية 20. ويستثني http_dos_exclude عناوين مفردة من ذلك، مثل صفحة الحالة الخاصة بكم. ويحدد httpthreadcount عدد خيوط المعالجة، وقيمته الافتراضية 8 في المجال من 1 إلى 20. والقيمة الأعلى تفيد مع كثرة الملفات الصغيرة، لكنها تستهلك وقت معالجة ينقص من تشغيل اللعب.

وتذكّروا إضافةً إلى ذلك ما يُسلَّم أيضاً على المنفذ نفسه. فالموردان webadmin وresourcebrowser مشغَّلان في الإعداد المرفق وقابلان للوصول عبر 22005 في المتصفح. وواجهة الإدارة لا تنتمي إلى الشبكة المفتوحة دون حماية: امنحوا صلاحيات نظيفة في acl.xml، وأنشئوا حساباً خاصاً بكلمة مرور عشوائية طويلة، وأوقفوا المورد إذا لم تكونوا بحاجة إليه.

5. استخدام الحدود المدمجة في mtaserver.conf

يحمل MTA حدود حماية أكثر مما تستخدمه معظم المشاريع. وبعضها ثابت في الكود المصدري، وبعضها في الملف mtaserver.conf. ويجمع هذا الجدول تلك التي تلعب دوراً أثناء الهجوم:

وثلاثة إعدادات تستحق قراراً واعياً. فـmaxplayers مضبوط على 32 وينبغي أن يطابق الواقع: فكل خانة إضافية تُكبّر الاستعلام الكامل وترفع عدد الاتصالات التي يستطيع مهاجم احتلالها. وbandwidth_reduction مضبوط على medium، والقيمة maximum تخفض الحِمل الصادر بشكل ملحوظ، لكنها تكلّف دقة في التزامن. أما <password></password> فيجعل خادمكم دون أي جهد دائرة مغلقة، مع بقاء الإدراج في القائمة قائماً: وهو أسرع مكبح طوارئ أثناء إغراق انضمام جارٍ.

6. التمييز بين إغراق الانضمام وإغراق الأحداث

نمطا هجوم لا يستهدفان الوصلة، بل منطق اللعبة، ويُخلَط بينهما بانتظام.

فـإغراق الانضمام يبني اتصالات حقيقية متتالية بسرعة، حتى تُحتل جميع الخانات أو حتى لا يعود الخادم قادراً على ملاحقة إنشاء الاتصالات. ويحدد MTA ذلك من نفسه بأربعة اتصالات لكل عنوان مصدر في 30 ثانية، ثم يتجاهل العنوان 30 ثانية. وما يفعله المكبح في هذه اللحظة يُظهره الأمر debugjoinflood في وحدة التحكم. والحد يعمل لكل عنوان، وشبكة بوتات بألف عنوان تمر بجانبه. ويفيد في مواجهة ذلك كلمة مرور للخادم، وقائمة بيضاء في الـgamemode، وتحديد المعدل على 22003.

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

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

7. قائمة الخوادم وعنوان IP وما يفشيه أيضاً

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

وتحققوا بدلاً من ذلك مما يفشيه عنوانكم أيضاً. والثقوب المعتادة في مشاريع MTA هي مُدخلات A وAAAA قديمة في DNS، وصفحة المشروع على الجهاز نفسه، وبوت Discord بعرض حالة يقرأ استعلام ASE علناً، وشهادات TLS بأسماء مضيفين قديمة، ومنشورات منتديات من مرحلة البداية. ويترتب على ذلك قاعدة تتعلمها مشاريع كثيرة متأخرةً: إذا انتقلتم إلى عنوان محمي، فغيّروا العنوان القديم في الوقت نفسه. فإذا بقي قائماً، فهو مكتوب في كل قاعدة بيانات للفاحصين، والهجوم يمر بجانب الحماية.

ومُدخلان في الملف mtaserver.conf يتعلقان بالظهور مباشرةً. يبقى <serverip>auto</serverip> على auto، إلا إذا كنتم تعرفون بالضبط لماذا لا. و<owner_email_address> ينتمي إلى الحقول التي تُملأ: فإذا غاب المُدخَل أو كان خاطئاً، فقد يضر ذلك بالظهور في قائمة الخوادم الرئيسية.

8. التسجيل، حتى تملكوا بيانات عند الجدّ

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

وأثناء الحادث تفصلون أولاً بين المنافذ الثلاثة. وهذه الأوامر الأربعة تكفي:

sar -n DEV 1 10
nstat -az | grep -E 'Udp(InDatagrams|InErrors|NoPorts|RcvbufErrors)'
tcpdump -ni eth0 -c 200 -q 'udp port 22126'
ss -tn state established '( dport = :22005 or sport = :22005 )' | wc -l

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

وسجل الخادم نفسه يقع في logs/server.log، وسجل السكربتات في logs/scripts.log. وكلا المسارين مكتوب في الملف mtaserver.conf وقابل للنقل.

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

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

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

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

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

وللتصنيف، أي المقادير تحدث فعلاً: على خوادم KernelHost صُفّي، من بين أمور أخرى، هجوم بسرعة تتجاوز 473.4 Gbit/s وبمعدل يتجاوز 41.5 مليون حزمة في الثانية على خادم صوتي، وإغراق UDP بسرعة تتجاوز 112.2 Gbit/s وبمعدل يتجاوز 8.7 مليون حزمة في الثانية على خادم لعب. والحالة الأولى نحو 473 ضعف النطاق الترددي ونحو 28 ضعف معدل الحزم الذي تستطيع وصلة بسرعة 1 Gbit/s استقباله أصلاً. ولا يوجد لذلك أي إعداد محلي. فالهجمات الحجمية يجب أن تنتهي في الشبكة الواقعة قبل الخادم.

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

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

كل خادم لدى KernelHost يقف خلف تصفية فعّالة بشكل دائم وذات مستويين:

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

وثلاث خصائص هنا حاسمة. الحماية فعّالة بشكل دائم، أي لا توجد مرحلة كشف يصبح خادمكم فيها غير متصل. ولا يُستخدم التوجيه إلى العدم: فالعنوان المُهاجَم يبقى في الشبكة، وتُسقَط الحزم الضارة وحدها، بينما تستمر اتصالات اللاعبين الحقيقيين. وهي لا تكلّف شيئاً إضافياً، بل مشمولة من لحظة التسليم في كل حزمة خادم، من الخادم الجذري KVM إلى خادم اللعب إلى الخادم المخصص. والتصفية تجري على الطبقات 3 و4 و7 على كل منفذ TCP أو UDP، أي على 22003 UDP و22005 TCP و22126 UDP في وقت واحد. ويجري تشغيل ذلك في مركز بيانات maincubes في فرانكفورت أم ماين في ألمانيا. أما الألعاب والبروتوكولات التي تملك ملفات خاصة بها فيُظهرها المقال حماية خوادم اللعب من DDoS في الوقت الفعلي.

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

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

• عنوان IP مخصص للحماية من النواة الفرانكفورتية. يُحوَّل خادمكم إليه داخل شبكة KernelHost، ولا تغيّرون شيئاً في جهتكم.
• قواعد حماية تديرونها بأنفسكم لكل منفذ وبروتوكول في منطقة العملاء. وهذا بالضبط هو بيت القصيد في MTA:SA: فتضبطون قواعد منفصلة للمنفذ 22003 UDP وللمنفذ 22005 TCP وللمنفذ 22126 UDP، بدلاً من معاملة ثلاث خدمات مختلفة جداً بمعيار واحد.
• التغييرات تسري في الوقت الفعلي، دون تذكرة ودون انتظار. أي تستطيعون التعديل في وسط هجوم جارٍ.
• ملف حماية مناسب للعبة. فـMulti Theft Auto موجود كملف خاص، وكذلك خوادم الويب والخوادم الصوتية والتطبيقات الخاصة على TCP أو UDP التي تناسب عنوان الحماية نفسه.

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

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

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

«حجبت 22126، والخادم مع ذلك ليس في أي قائمة، لكن الاستعلامات ما زالت تصل»: إذاً المقبس ما زال مفتوحاً. فـ<ase>0</ase> وحده لا يغلق المنفذ ما دام <donotbroadcastlan>0</donotbroadcastlan> مضبوطاً. تحقّقوا بالأمر ss -lnup | grep 22126 مما إذا كان شيء ما ما زال يستمع فعلاً.

«اللاعبون معلّقون في شاشة التحميل، واللعبة نفسها تعمل بشكل طبيعي»: هذا ليس هجوماً على 22003، بل خادم HTTP على 22005 عند حده. أخرِجوا التنزيلات عبر httpdownloadurl، وتحقّقوا من httpmaxconnectionsperclient وhttpthreadcount.

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

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

«ضبطنا حداً قدره 20 حزمة في الثانية لكل عنوان على 22003»: هذا ضيق جداً. فلاعب واحد وحده يتجاوز ذلك عند التزامن النشط، وعدة لاعبين خلف عنوان NAT نفسه يتقاسمون الكمية نفسها. وبذلك تطردون لاعبيكم أنفسكم. أما على 22126 فالقيم الضيقة غير مشكلة.

«حجبنا أنفسنا بجدار الحماية»: إعادة التشغيل لا تفيد، لأن UFW يستعيد قواعده عند الإقلاع. ولدى KernelHost تفتحون وحدة تحكم VNC في منطقة العملاء وتنفّذون هناك الأمر ufw disable. ووحدة تحكم VNC تعمل بشكل مستقل عن شبكة النظام الضيف.

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

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

باختصار

• يحتاج خادم MTA:SA إلى ثلاثة منافذ بالضبط: 22003 UDP للعبة، و22005 TCP لخادم HTTP الداخلي، و22126 UDP لاستعلام ASE. والثالث ينتج بشكل ثابت عن منفذ اللعبة زائد 123.
• استعلام ASE يقع على منفذ خاص به، ولهذا يمكن تحديد معدله دون استبعاد لاعب واحد. وهذا هو أهم فرق عن SA-MP، حيث يتقاسم اللعب والاستعلام المنفذ نفسه.
• بايت طلب واحد على 22126 يولّد جواباً يصل إلى عدة كيلوبايتات، وعنوان المرسل قابل للتزييف. وبذلك يكون منفذ ASE غير المكبوح هدفاً ومُضخِّماً في الوقت نفسه.
• مكابح MTA المدمجة تعمل لكل عنوان مصدر: خمسة استعلامات في ست ثوانٍ، وأربعة انضمامات في 30 ثانية. وعند أكثر من 100 عنوان مصدر متزامن يُتجاوَز عدّ الاستعلامات، أي أن الإغراق الموزّع يمر.
• خادم HTTP الداخلي على 22005 سطح هجوم قائم بذاته. ومن يُخرج التنزيلات عبر httpdownloadurl إلى خادم ويب خارجي يُخرجها من تشغيل اللعب.
• كل ما يعمل على الخادم لا يحسم إلا في الهجمات الصغيرة. فعند 1 Gbit/s تنتهي القصة عند نحو 1.49 مليون حزمة في الثانية، بصرف النظر عن جودة قواعدكم.
• الحماية الدائمة ذات المستويين لدى KernelHost مشمولة في كل حزمة خادم دون زيادة في السعر وتعمل دون توجيه إلى العدم. ومن أراد التحكم في القواعد لكل منفذ بنفسه يضيف Advanced DDoS Protection ابتداءً من 50.00 EUR في الشهر.

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