حماية خادم Garry's Mod من هجمات DDoS

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

تشير جميع المعطيات إلى خادم srcds يعمل على Debian 12 أو Debian 13 أو Ubuntu 22.04 LTS أو Ubuntu 24.04 LTS. ويقع ملف الإعدادات في garrysmod/cfg/server.cfg، والأوامر مكتوبة للمستخدم root، أما بمستخدم عادي فتضعون sudo في المقدمة. والمقصود دائماً هو التشغيل على خادم جذري أو خادم مخصص خاص بكم، لا مقعد عند مزود خوادم ألعاب.

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

لماذا يحتاج خادم Garry's Mod إلى حماية من DDoS

خادم Garry's Mod ينشر عنوان IP الخاص به ومنفذه بنفسه. وهذا ليس سهواً بل شرط عمل: من لا يظهر في متصفح الخوادم لا يحصل على لاعبين جدد. وهذا الظهور ينشأ لأن الخادم يسجّل نفسه لدى خادم Steam الرئيسي ثم يجيب على كل استعلام A2S يأتي من الخارج. فالسؤال ليس أبداً ما إذا كان المهاجم سيجد عنوانكم، بل ما يحدث عندما يفتح النار عليه.

ويضاف إلى ذلك طبيعة المجتمعات. فـ Garry's Mod لا يُلعب في الغالب على هيئة جولات، بل في عوالم دائمة: مجتمع DarkRP يحتفظ في قاعدة بيانات بحسابات اللاعبين وممتلكاتهم ووظائفهم وتقدّمهم على مدى أشهر. وبذلك يكلّف التوقف مساء الجمعة أكثر من مباراة خسرتموها، فهو يكلّفكم اللاعبين الدائمين. ولهذا السبب تحديداً تكون المجتمعات المنافسة واللاعبون المحظورون وخدمات القصف المأجورة (booters، أي خدمات تُطلق مقابل يوروهات قليلة في الشهر هجوماً على أي عنوان) هي المسبّبات الثلاثة الأكثر شيوعاً. ولا يحتاج المهاجم إلى مهارة ولا إلى مال يُذكر.

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

المنافذ المعنية فعلياً في Garry's Mod

يبدأ خادم Garry's Mod افتراضياً على المنفذ 27015، وذلك على UDP للعبة مع استعلام الخادم، وعلى TCP لـ RCON. ويُغيَّر الرقم عند التشغيل بالمعامل -port، وعند تشغيل عدة نسخ يُزاد الرقم تصاعدياً (27016 و27017 وهكذا). ويبدو أمر تشغيل نموذجي على هذا النحو:

./srcds_run -game garrysmod -console \
  -port 27015 \
  +maxplayers 64 \
  +gamemode darkrp \
  +map rp_downtown_v4c_v2 \
  +sv_setsteamaccount YOUR_GSLT_TOKEN \
  +host_workshop_collection 123456789 \
  -authkey YOUR_STEAM_WEB_API_KEY

ومن ذلك ينتج سطح الهجوم بكامله. والجدول التالي هو الأساس لكل قاعدة جدار حماية ترد أدناه:

من بين هذه المداخل الثمانية ينتمي واحد فقط إلى الإنترنت المفتوح دون قيد: 27015/UDP. وكل ما تبقّى يُقصر على عنوانكم الخاص، أو يُربط بـ 127.0.0.1، أو لا يُشغَّل من الأصل. وأغلى خطأ تفكير في هذا الميدان هو الافتراض بأن لدى Garry's Mod منفذ استعلام منفصلاً يمكن إغلاقه ببساطة. هذا المنفذ غير موجود.

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

هذا القسم هو الأطول، وذلك بقصد. فخادم Garry's Mod المضبوط بعناية يتحمّل الهجمات الصغيرة والمتوسطة بقوّته الذاتية، بغض النظر عن الجهة التي يعمل عندها. ولا شيء من ذلك يكلّف مالاً، ومعظمه يُنجَز في ربع ساعة.

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

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

ss -lntup

المثير للاهتمام هو عمود العنوان المحلي. فـ 0.0.0.0:27015 و[::]:27015 تعني «متاح من الإنترنت بأكمله»، و127.0.0.1:3306 تعني «محلياً فقط» ولا تحتاج إلى أي قاعدة في جدار الحماية. وعلى خادم DarkRP نما مع الوقت تظهر هناك دائماً خدمات أكثر مما يُتوقّع: MySQL، وخادم ويب لـ FastDL، ولوحة تحكم، وبوت Discord، وخادم اختبار ثانٍ على 27016، وخدمة صوت منسية. أما رؤية المهاجم فيوفّرها فحص المنافذ من الخارج:

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

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

يكفي Garry's Mod فتح منفذ واحد إلى الخارج، إضافةً إلى SSH ووصول RCON المقيّد. ومع UFW يبدو ذلك على هذا النحو، وبهذا الترتيب تحديداً حتى لا تحجبوا أنفسكم:

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'منفذ لعبة Garrys Mod واستعلام A2S'
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 بعنوانكم الخاص. أما SourceTV على 27020/UDP فلا تفتحوه إلا إذا كنتم تبثّون فعلاً. ويوجد الدليل الكامل مع طريق النجاة في إعداد جدار حماية UFW دون أن تحجبوا أنفسكم. وإذا حدث ذلك مع هذا: الخوادم الجذرية KVM والخوادم المخصصة من KernelHost لا تحتوي على IPMI ولا على iDRAC، وتعودون إليها عبر وحدة تحكم VNC في منطقة العملاء. وهذه الوحدة لا تعتمد على مكدس الشبكة في النظام الضيف، فلا تستطيع أي قاعدة جدار حماية داخل النظام الضيف حجبها.

أما قاعدة البيانات فلا تنتمي إلى الإنترنت المفتوح بأي حال. تحقّقوا في /etc/mysql/mariadb.conf.d/50-server.cnf من وجود هذا السطر:

bind-address = 127.0.0.1

3. تحديد استعلام A2S دون الخروج من قائمة الخوادم

هنا يكمن الخطأ الذي يكلّف معظم خوادم Garry's Mod. فلأن حركة اللعب واستعلام الخادم يتقاسمان المنفذ نفسه، فإن حجباً شاملاً أو تحديد معدل ضيقاً جداً على 27015/UDP يطرد لاعبيكم أنفسهم ويُتمّ الهجوم بالنيابة عن المهاجم. والمنطلق الصحيح هو التمييز بين حزم الاستعلام وحزم اللعب.

وتوفّر المحرّكة لذلك ثلاثة متغيرات وحدة تحكم توضع في server.cfg. وقيمها الافتراضية محافظة، لكنها مضبوطة أصلاً:

sv_max_queries_sec 3
sv_max_queries_sec_global 60
sv_max_queries_window 30

يحدّ sv_max_queries_sec من الاستعلامات المُجاب عليها لكل عنوان مُرسِل (الافتراضي 3 في الثانية)، ويضع sv_max_queries_sec_global سقفاً لمجموعها عبر كل العناوين (الافتراضي 60 في الثانية)، ويحدّد sv_max_queries_window نافذة حساب المتوسط (الافتراضي 30 ثانية). وهذه القيم تحمي المعالج من توليد إجابات بلا جدوى. لكنها لا تمنع وصول الحزم، ومن يشدّد القيمة العامة كثيراً يختفي أثناء الهجوم من متصفح الخوادم، لأن استعلامات صفحات القوائم تبقى أيضاً دون إجابة.

وعلى مستوى أدنى يمكن فصل حركة الاستعلام بنظافة. فكل الحزم بلا اتصال في محرّكة Source تبدأ بأربع بايتات مضبوطة (0xffffffff)، بينما حركة اللاعبين المتصلين أصلاً لا تحمل هذه الترويسة. وعلى ذلك بالتحديد يمكن وضع تحديد معدل لكل عنوان مصدر باستخدام nftables:

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

وتُحمّلون الملف بالأمر nft -f. والأولوية -10 تضمن أن القاعدة تعمل قبل سلسلة تصفية UFW، و@th,64,32 يقرأ أول أربع بايتات بعد ترويسة UDP. ومع iptables الكلاسيكي يؤدي تطابق u32 الغرض نفسه:

iptables -A INPUT -p udp --dport 27015 \
  -m u32 --u32 "0>>22&0x3C@8=0xFFFFFFFF" \
  -m hashlimit --hashlimit-name gmod_a2s --hashlimit-mode srcip \
  --hashlimit-above 8/sec --hashlimit-burst 20 -j DROP

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

4. تأمين RCON أو تعطيله كلياً

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

لا تتركوا rcon_password فارغة أبداً ولا قابلة للتخمين، وتكفي قيمة من openssl rand -base64 32. وضد محاولات تسجيل الدخول توفّر المحرّكة مكابح خاصة:

rcon_password "A_LONG_RANDOM_PASSWORD_HERE"
sv_rcon_minfailures 3
sv_rcon_maxfailures 5
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

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

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

5. تحديد رسائل شبكة Lua، أكثر الأعطال المصنوعة منزلياً شيوعاً

جزء كبير من أعطال Garry's Mod المبلّغ عنها كهجمات DDoS ليس كذلك. إنها حالات إفراط في تحميل Lua، يطلقها عميل واحد متصل بسرعة كيلوبتات قليلة في الثانية. والسبب يكمن في بنية مكتبة net: فبمجرد أن تسجّل إضافة حدثاً شبكياً بـ util.AddNetworkString وتستمع إليه بـ net.Receive، يستطيع أي عميل إطلاق هذا الحدث في حلقة متكررة. وبدون تحديد خاص ينفّذ الخادم كل رسالة على حدة. وقد وثّقت Facepunch ذلك في تقارير الأخطاء الخاصة بها عدة مرات ولم تضع حلاً في المحرّكة، فالتحديد مهمة كاتب الإضافة صراحةً.

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

util.AddNetworkString("khrp_buy")

local budget = {}

net.Receive("khrp_buy", function(len, ply)
    if not IsValid(ply) then return end
    if len > 256 then return end

    local now = CurTime()
    local b = budget[ply]

    if not b or now - b.start >= 1 then
        b = { start = now, count = 0 }
        budget[ply] = b
    end

    b.count = b.count + 1
    if b.count > 10 then return end

    KHRP.HandleBuy(ply, net.ReadString())
end)

hook.Add("PlayerDisconnected", "khrp_budget_cleanup", function(ply)
    budget[ply] = nil
end)

ويضاف إلى ذلك سطران في server.cfg. فالمتغير sv_allowcslua قيمته الافتراضية في Garry's Mod هي 1 وهو يتيح للعملاء تنفيذ شيفرة خاصة بهم عبر lua_run_cl وlua_openscript_cl: وفي خادم عام تنتمي هذه القيمة إلى 0. والمتغير sv_kickerrornum يفصل العملاء الذين يولّدون أخطاءً من جهة العميل بعدد يتجاوز القيمة المحددة (الافتراضي 0، أي معطّل):

sv_allowcslua 0
sv_kickerrornum 25

6. فصل محتوى Workshop وFastDL عن خادم اللعبة

إضافات Steam Workshop ليست موضوعاً هامشياً في Garry's Mod بل هي الحالة الطبيعية: فمجتمع DarkRP يربط مجموعته بالمعامل +host_workshop_collection، ويُنزّل العملاء هذه المحتويات من Steam مباشرةً. وهذا لا يحمّل وصلتكم شيئاً. أما المفتاح الوارد في -authkey فهو مفتاح Steam Web API ويُعامل كأنه كلمة مرور: أي أنه يوضع في سكربت التشغيل، لا في مستودع عام ولا في قناة Discord.

أما النطاق الترددي فيكلّفه الطريق الثاني. فكل ما لا يأتي من Workshop (خرائطكم الخاصة والأصوات والمواد) يمر عبر قناة التنزيل. وبدون sv_downloadurl تمر هذه القناة عبر منفذ اللعبة نفسه وتنافس حركة اللعب مباشرةً. ومع FastDL تمر عبر HTTP. وإذا كان خادم الويب هذا على المضيف نفسه وعلى عنوان IP نفسه، يتقاسم الاثنان الوصلة نفسها: وبذلك تصيب موجة انضمام أو هجوم على 80/TCP اللعبة أيضاً. وهذه القيم معقولة:

sv_downloadurl "https://fastdl.your-domain.com/garrysmod/"
sv_allowdownload 1
sv_allowupload 0
net_maxfilesize 64

يسحب sv_allowupload 0 من العملاء إمكانية إرسال ملفات خاصة بهم إلى الخادم، وبذلك يغلق طريقاً لا يُحتاج إليه ولا يمكن التحكم فيه. ويحدّ net_maxfilesize من حجم الملفات المنقولة عبر قناة اللعبة بالميغابايت. وضعوا FastDL على مضيف آخر أو خلف اسم خاص به إن أمكن، فلا تقع الحِمْل على العنوان نفسه الذي يحمل منفذ اللعبة.

7. اعتراض سيل محاولات الانضمام واستنفاد المقاعد

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

وضد ذلك تعمل أربعة أمور. أولاً سقف واقعي: فرفع +maxplayers إلى ما يتجاوز قدرة نمط اللعب لديكم لا يفعل سوى توسيع سطح الهجوم. ثانياً sv_timeout الذي يحدّد بعد كم ثانية دون رسالة يُفصل العميل (وهو 120 في الإعدادات الشائعة): ومن يريد التخلص أسرع من أنصاف الاتصالات المعلّقة يضع قيمة أقل. ثالثاً تحديد معدل الحزم بلا اتصال من الخطوة 3، لأن إنشاء الاتصال يمر عبرها تحديداً. رابعاً، وللمجموعات المغلقة، كلمة مرور للخادم:

sv_password "regulars_2026"
sv_timeout 90
sv_filterban 1
sv_region 3

لا يوفّر Garry's Mod قائمة بيضاء حقيقية، بل تأتي عبر امتدادات مثل ULX أو عبر فحص خاص بكم في الخطاف CheckPassword. وأمر واحد يجب أن يكون واضحاً: القائمة البيضاء تحمي منطق لعبتكم، لا وصلتكم. فالمهاجم الذي يُغرق خادمكم لا يريد الانضمام أصلاً. حزمه تُرفض، لكنها وصلت مع ذلك، وهذا هو بيت القصيد.

8. تخفيف الحِمْل عن النواة: تتبع الاتصالات ومخزن الاستقبال

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

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

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

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

ومع iptables يكون المقابل iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK والسطر نفسه لـ OUTPUT مع --sport. ويحتاج المنفذ بعد ذلك إلى فتح صريح، فبدون تتبع لا تعمل أي قاعدة تتحقق من حالة قائمة. وإذا وصلت الحزم أسرع من التقاط srcds لها، يفيض مخزن الاستقبال، ويبدو ذلك للاعبين كفقدان حزم على وصلة فارغة:

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

تنتمي هذه الأسطر إلى ملف داخل /etc/sysctl.d/ وتُفعَّل بالأمر sysctl --system. أما إن كانت لازمة فالنواة نفسها تخبركم: إذا ارتفع UdpRcvbufErrors في nstat -az فهي تعمل. وإذا بقي العدّاد عند صفر فلا يغيّر التعديل شيئاً. هذا احتياطي، لا حماية.

9. حفظ القياسات ما دام كل شيء طبيعياً

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

sar -n DEV 1 10
ip -s link show eth0
nstat -az | grep -i udp
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xffffffff"

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

ما هي ثغرة انعكاس A2S وهل ما زالت تخصّني

انعكاس A2S هجوم لا يكون خادمكم فيه الهدف بل الأداة. يرسل المهاجم استعلاماً صغيراً بعنوان مُرسِل مزيّف إلى آلاف خوادم الألعاب، فتتجمع إجاباتها الأكبر حجماً بكثير عند الضحية الحقيقية. وتاريخياً كان حجم طلب A2S_INFO يبلغ 25 بايتاً (4 بايتات 0xFFFFFFFF، وبايت واحد 0x54، إضافةً إلى 20 بايتاً للسلسلة النصية «Source Engine Query»)، بينما كانت الإجابة عدة مئات من البايتات. ويُدرج US-CERT بروتوكول Steam في قائمته لهجمات التضخيم بمعامل 5.5، ومعنى ذلك: من جيجابت واحد عند المهاجم تصبح 5.5 جيجابت عند الضحية.

وقد أغلقت Valve هذه الثغرة بدءاً من نوفمبر 2020، وذلك بطريقتين. فحزم الاستعلام بلا اتصال يجب من ذلك الحين أن يحشوها المُرسِل حتى 1,200 بايت، وبذلك يصبح الطلب أكبر من الإجابة ويهبط معامل التضخيم إلى ما تحت 1. وأثناء مرحلة التحول أمكن للمشغّلين فرض السلوك الأكثر صرامة مسبقاً عبر متغير البيئة STEAM_GAMESERVER_MIN_CONNECTIONLESS_PACKET_SIZE=1200. إضافةً إلى ذلك لا يجيب الخادم على A2S_PLAYER وA2S_RULES ببيانات فوراً، بل بتحدٍّ (S2C_CHALLENGE) يجب على السائل أن يعيد إرساله في طلب ثانٍ. ومن يزيّف عنوان المُرسِل لا يرى هذا التحدي أبداً.

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

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

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

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

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

ما تضعه 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 مخصص للحماية من نواة فرانكفورت، يُحوَّل خادمكم إليه داخل شبكتنا الخاصة. ولا يلزم أي تعديل من جهتكم.
• قواعد حماية تديرونها بأنفسكم لكل منفذ وبروتوكول في منطقة العملاء: فتحدّدون ما هو مسموح على 27015/UDP وما هو مسموح على 27015/TCP، دون أن تكتبوا تذكرة لذلك.
• التغييرات تسري في الوقت الفعلي، أي أنكم تستطيعون التعديل أثناء هجوم جارٍ، بدلاً من انتظار نافذة الصيانة التالية.
• ملف حماية مناسب لكل لعبة، لـ Garry's Mod وبقية عناوين Source، وكذلك ملفات TCP وUDP حرة للخوادم المعدَّلة والتطبيقات الخاصة.

وهنا أيضاً يسري نموذج PrePaid: دون حد أدنى لمدة الالتزام، ودون مهلة إشعار للإلغاء، ودون عقد، ودون رسوم إعداد. وإذا انتهت موجة الهجوم فلا تجدّدون، وهذا كل شيء. ومن يشغّل خادم Garry's Mod الخاص به في مكان آخر حتى الآن فيحصل على هذه الحماية عبر الانتقال إلى KernelHost، لأن التصفية تجري في شبكتنا الخاصة لا على بنية تحتية غريبة.

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

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

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

«الخادم يعمل لكنه اختفى من متصفح الخوادم»: في الغالب حُجب 27015/UDP بشكل شامل أو حُدّد معدله بضيق مفرط. ولأن حركة اللعب والاستعلام يتقاسمان المنفذ نفسه، تصيب القاعدة الخشنة كليهما. اعملوا بدلاً من ذلك بالتطابق على الحزم بلا اتصال. وإذا بقي الخادم غير مرئي رغم أن المنفذ متاح، فتحقّقوا من sv_setsteamaccount: فبدون رمز تسجيل دخول صالح لخادم اللعبة يُخفَّض تقييم خادم Garry's Mod في القائمة بشدة، ويحتاج كل خادم إلى رمز خاص به.

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

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

«RCON توقف عن العمل بشكل مفاجئ»: ليس DDoS، بل في الغالب حظر ذاتي. لوحة إدارة تحمل كلمة مرور قديمة تُطلق sv_rcon_minfailures، ويحجب sv_rcon_banpenalty العنوان لعدد الدقائق المضبوط. صحّحوا كلمة المرور، وأزيلوا الحظر، ثم اقصروا المنفذ على عنوانكم الخاص.

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

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

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

الخلاصة باختصار

• يحتاج خادم Garry's Mod إلى منفذ مفتوح واحد بالضبط: 27015/UDP. وتمر عليه حركة اللعب واستعلام A2S معاً، ولا يوجد منفذ استعلام منفصل.
• يقع RCON على 27015/TCP وينقل كلمة المرور بنص واضح، ويجب ألا يُفتح إلا لعنوانكم الخاص أو يُوصل إليه عبر إعادة توجيه منفذ SSH.
• لا تحدّوا المنفذ، بل حدّوا الحزم بلا اتصال ذات الترويسة 0xffffffff. فالحجب الشامل على 27015/UDP يطرد لاعبيكم أنفسهم.
• أكثر أعطال Garry's Mod شيوعاً ليس هجوم DDoS، بل حدث شبكي بلا تحديد: فكل حدث مسجَّل بـ util.AddNetworkString يحتاج إلى سقف لكل لاعب وثانية.
• عند حزم بحجم 64 بايتاً تحمل وصلة بسرعة ⁦1 Gbit/s⁩ نحو 1.49 مليون حزمة في الثانية. وفوق ذلك ينشأ الفقدان عند الموجّه الذي أمامها، وتصبح كل قاعدة محلية بلا أثر.
• لدى KernelHost تكون الحماية الدائمة ذات المستويين مشمولة في كل حزمة خادم دون زيادة في السعر: سعة تخفيف ⁦17 Tbps⁩ في شبكة التنقية العالمية، وتصفية Arbor في الوقت الفعلي بسعة ⁦3.2 Tbps⁩ في فرانكفورت أم ماين، دون التوجيه إلى العدم.
• ومن يُقصف بشكل موجّه وبصورة دائمة يضيف Advanced DDoS Protection ابتداءً من ⁦50.00 EUR⁩ في الشهر: عنوان IP مخصص للحماية، وقواعد تديرونها بأنفسكم لكل منفذ وبروتوكول، تسري في الوقت الفعلي.

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

ومن يشغّل إلى جانب Garry's Mod عناوين Source أخرى فيجد الأساسيات المشتركة في حماية خوادم CS2 وSource من هجمات DDoS، أما كيف يُهيَّأ الأساس بنظافة فيوضّحه تثبيت خادم ألعاب باستخدام SteamCMD.