حماية خادم Left 4 Dead 2 من هجمات DDoS

خادم Left 4 Dead 2 نادراً ما يتوقف في اللحظة المناسبة. إنه يتوقف في القسم الأخير من الحملة، أو في الجولة الثانية من مباراة Versus، أو تحديداً عندما يُرفض لاعب محظور للمرة الثالثة. ومن يتعرض للقصف الآن لا يحتاج إلى نقاش مبدئي حول تقنيات الشبكات، بل إلى ترتيب واضح. ويعرض هذا المقال أولاً كيف تحمون خادم Left 4 Dead 2 من هجمات DDoS ما دام ذلك ممكناً بالوسائل المتوفرة، ثم أين تنتهي هذه الإمكانات فيزيائياً، وفي الختام ما الذي يجب أن يحدث أمامها في الشبكة.

تشير جميع المعطيات إلى خادم مخصص (srcds) مثبَّت عبر SteamCMD تحت معرّف التطبيق 222860، على Debian 12 أو Debian 13 أو Ubuntu 22.04 LTS أو Ubuntu 24.04 LTS. والأوامر مكتوبة للمستخدم root، أما بمستخدم عادي فتضعون sudo في المقدمة. ونقطة واحدة مقدماً لأنها تحدّد الترتيب: لا تغيّروا شيئاً بشكل أعمى أثناء هجوم جارٍ ولا تعيدوا تشغيل الخادم قبل أن تحفظوا القياسات. فهي تزول بانتهاء الهجوم.

لماذا تُعد خوادم Left 4 Dead 2 هدفاً مُجزياً لهجمات DDoS

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

ويضاف إلى ذلك طريقة البناء. Left 4 Dead 2 يعمل على محرّكة Source، وخادم Source يمكن إيجاده علناً بعنوان IP ومنفذ. وهذا شرط عمل لا سهو: فالخادم الذي لا يجيب على أي استعلام لا يظهر في أي قائمة ولا يجده أي لوبي. فالسؤال ليس أبداً ما إذا كان المهاجم يعرف عنوانكم، بل ما يحدث عندما يفتح النار عليه. وحركة اللعب تمر عبر UDP، وUDP لا يعرف إنشاء اتصال يمكن اشتراطه، كما أن عناوين المُرسِل قابلة للتزييف. أما ما يجري فنياً في ذلك فيشرحه مقال ما هو هجوم DDoS؟.

وهناك نقطة ثالثة خاصة بـ Left 4 Dead 2 ولا نظير لها في Counter-Strike أو Garry's Mod أو Team Fortress 2: معظم اللاعبين لا يأتون عبر متصفح الخوادم، بل عبر نظام اللوبي. فيُوجَّه لوبي يصل إلى أربعة لاعبين عبر نظام Matchmaking في Steam إلى خادم مخصص، ويحصل هذا الخادم مقابل ذلك على حجز. وهذا الأسلوب هو في الوقت نفسه أقوى مصفاة وصول لديكم وسطح هجوم إضافي. وكلا الأمرين مشروح بالتفصيل أدناه.

المنافذ المعنية فعلياً

يشغل خادم Left 4 Dead 2 منفذ UDP واحداً بالضبط لكل ما يخص اللعبة. والافتراضي هو 27015، ويُحدَّد عبر -port أو +hostport في سطر التشغيل:

./srcds_run -game left4dead2 -console -nohltv \
  -port 27015 \
  +ip 203.0.113.10 \
  +maxplayers 4 \
  +exec server.cfg \
  +map c1m1_hotel

السطر الأول من هذا الجدول هو جوهر المشكلة. فحركة اللعب واستعلام الخادم يتقاسمان 27015/UDP، ولا يوجد في Left 4 Dead 2 منفذ استعلام منفصل. ومن يحجب هذا المنفذ بشكل شامل أو يحدّ معدله بخشونة يطرد لاعبيه أنفسهم في الحركة نفسها ويُتمّ الهجوم بالنيابة عن المهاجم.

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

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

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

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

قبل أن تكتبوا قاعدة، حدّدوا أي الخدمات متاحة. وعلى خادم Left 4 Dead 2 نما مع الوقت تكون هذه الخدمات دائماً أكثر مما يُتوقّع، لأن إلى جانب srcds يعمل خادم ويب للحملات وقاعدة بيانات للإحصاءات وأحياناً خادم ثانٍ لوضع Versus:

ss -lntup

كل ما هو مربوط بـ 127.0.0.1 أو ::1 لا يحتاج إلى أي فتح. وكل ما يستمع على 0.0.0.0 أو [::] متاح من الإنترنت. أما رؤية المهاجم فيوفّرها فحص المنافذ من الخارج، وهي تختلف عن التوقعات الذاتية بحسب الخبرة:

nmap -Pn -sU -sT -p 27000-27050,80,443,3306 YOUR.SERVER.IP.ADDRESS

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

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

منفذ UDP واحد إلى الخارج، ومنفذ TCP واحد لعنوانكم الخاص، ولا شيء أكثر. فـ RCON لا ينتمي إلى الإنترنت المفتوح، لأن من يملك RCON يغيّر الخريطة ويحظر جميع اللاعبين ويوقف الخادم:

ufw allow 27015/udp comment "منفذ لعبة L4D2 واستعلام A2S"
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment "RCON"
ufw allow from 203.0.113.10 to any port 22 proto tcp comment "SSH"
ufw default deny incoming
ufw default allow outgoing
ufw --force enable

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

3. كبح استعلام A2S دون السقوط من بحث اللوبي

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

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

export STEAM_GAMESERVER_RATE_LIMIT_200MS=50
./srcds_run -game left4dead2 -console -port 27015 +exec server.cfg +map c1m1_hotel

وفي وحدة systemd تنتمي القيمة نفسها إلى القسم [Service] بصيغة Environment=STEAM_GAMESERVER_RATE_LIMIT_200MS=50، وإلا فهي تزول بعد إعادة التشغيل التالية. وهذا الكابح لا يعمل إلا إذا كانت بِنْية خادمكم تجلب الأساس البرمجي الحالي من Steamworks، وهو يحمي وقت المعالجة في خادمكم لا وصلتكم: فالحزم قد وصلت أصلاً.

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

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

وتُحمّلون الملف بالأمر nft -f. والأولوية -10 تضمن أن القاعدة تعمل قبل سلسلة تصفية UFW، و@th,64,32 يقرأ أول أربع بايتات بعد ترويسة UDP. ابدؤوا بسخاء ولا تشدّوا الحد إلا بعد أن يثبت مرور الاستعلامات المشروعة: فظهوركم في قائمة الخوادم معلّق بذلك.

4. استخدام نظام اللوبي كمصفاة وصول

هذه هي الرافعة التي لا يملكها سوى Left 4 Dead 2 وسابقه. فالخادم يقرّر بنفسه ما إذا كان سيقبل اتصالات من خارج نظام Matchmaking أصلاً. وأربع تعليمات في server.cfg تحدّد ذلك:

sv_allow_lobby_connect_only 1
sv_search_key "your-own-key"
sv_steamgroup "103582791400000000"
sv_steamgroup_exclusive 2

• sv_allow_lobby_connect_only 1 لا يسمح إلا بالانضمام من لوبي Matchmaking. فالأمر connect 203.0.113.10:27015 في وحدة تحكم المطوّر ودعوة Steam يُرفضان. أما القيمة 0 فتسمح بكليهما.
• sv_search_key مفتاح بحث تختارونه بحرية. فلا يجد الخادم عبر Matchmaking إلا لوبي ضُبط فيه المفتاح نفسه. وبدون هذا المفتاح لا يظهر الخادم في البحث العام.
• sv_steamgroup يربط الخادم بمجموعة Steam ويجعله يظهر ضمن خوادم تلك المجموعة.
• sv_steamgroup_exclusive يعرف ثلاث درجات: 0 يسمح للجميع، و1 يتصرّف مثل 0 لكنه يشترط الانضمام عبر لوبي، و2 لا يسمح إلا لأعضاء المجموعة وللوصول المباشر عبر عنوان IP.

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

والآن الجزء الذي تتركه النصوص الترويجية عادةً: هذه التعليمات تحمي منطق لعبتكم، لا وصلتكم. فالمهاجم الذي يُغرق 27015/UDP لا يريد الانضمام أصلاً. حزمه تُرفض، لكنها وصلت مع ذلك، واستهلكت نطاقاً ترددياً وكلّفت مروراً في مكدس الشبكة. فضد سيل محاولات انضمام من حسابات للاستخدام مرة واحدة يعمل sv_allow_lobby_connect_only 1 بامتياز، أما ضد booter فلا يعمل إطلاقاً.

5. حجز اللوبي ومتى يكون sv_force_unreserved الخيار الأفضل

حجز اللوبي هو شَغل مؤقت لخادمكم من قِبل لوبي Matchmaking. وما دام قائماً يُعد الخادم مشغولاً بالنسبة إلى اللوبيات الأخرى، وهو لا ينتهي من تلقاء نفسه إلا بعد حين. وبالنسبة إلى خادم بأربعة مقاعد يكون ذلك مورداً نادراً: فعلى خلاف لعبة تصويب بـ 32 أو 64 مقعداً، يكفي القليل جداً لتعطيل مباراة.

ومن لا يشغّل خادمه عبر Matchmaking فليُخرج هذا السطح كاملاً:

sv_force_unreserved 1
sv_allow_lobby_connect_only 0

يؤدي sv_force_unreserved 1 إلى أن الخادم لم يعد يجيب على طلبات الحجز الواردة من نظام اللوبي وأنه يرفض الانضمام الذي يحمل سمة حجز. وتحتاجون إلى هذا الإعداد نفسه على أي حال إذا كنتم تشغّلون أكثر من أربعة مقاعد تعاونية بأداة L4DToolZ، وإلا فسيحصل اللوبي على حجز بمجرد امتلاء المقاعد الأربعة الأولى وتبقى المقاعد الباقية غير قابلة للوصول. والوجه الآخر واضح: فلاعبوكم لن يدخلوا بعد ذلك إلا عبر متصفح الخوادم أو عبر connect.

اختاروا بوعي إحدى طريقتي التشغيل. فالخلط بين Matchmaking نصف مفتوح وانضمام مباشر نصف مفتوح هو الصيغة التي تجمع عيوب الاثنين.

6. تأمين RCON

منفذ RCON مفتوح بكلمة مرور ضعيفة ليس مشكلة DDoS، بل استيلاء. لا تتركوا rcon_password فارغة أبداً ولا قابلة للتخمين، وتكفي قيمة من openssl rand -base64 32. وتوفّر عناوين Source إضافةً إلى ذلك كابحاً ضد محاولات تسجيل الدخول:

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

وبذلك يُحظر العنوان لمدة يوم بعد ثلاث محاولات فاشلة خلال 30 ثانية، ويُظهر الأمر find sv_rcon في وحدة تحكم الخادم أي هذه المتغيرات تعرفها بِنْيتكم. ويبقى تقييد جدار الحماية من الخطوة 2 أكثر فعالية مع ذلك، لأنه لا يسمح للمحاولة بالوصول إلى التطبيق أصلاً. وإذا لم تكونوا تحتاجون RCON فاتركوا كلمة المرور فارغة: فحينها لا يستمع الجزء TCP من المنفذ 27015.

7. إخراج الحملات المخصصة بدلاً من تسليمها عبر منفذ اللعبة

الحملات المخصصة هي السبب في أن Left 4 Dead 2 ما زال يُلعب بعد خمسة عشر عاماً، وهي في الوقت نفسه مصدر حِمْل لا وجود له بهذا الشكل في Counter-Strike. فالحملة حزمة VPK تضم خرائط وأشكالاً وخامات وأصواتاً، أي أضعاف ما تزنه خريطة تنافسية واحدة.

والطريق المريح للاعبين هو Steam Workshop: فالحزمة تأتي حينها من Steam لا من خادمكم ولا تكلّفكم أي نطاق ترددي. وإذا سلّمتم ملفات مفردة بأنفسكم، فالتسليم ينتمي إلى خادم ويب لا إلى منفذ اللعبة:

sv_allowdownload 1
sv_allowupload 0
sv_downloadurl "https://cdn.example.org/l4d2/"
sv_consistency 1

الملفات الخاصة بـ sv_downloadurl تنتمي إلى خادم الويب كأرشيف bzip2، أي أن mymap.bsp تصبح mymap.bsp.bz2. وبدون sv_downloadurl يرسل srcds الملفات بنفسه عبر اتصال اللعبة، وحينها يسري ما يلي: كل محاولة اتصال من لاعب جديد تكلّفكم التنزيل الكامل، وكل انقطاع في منتصف التنزيل كذلك. وهذه طريقة رخيصة إلى حد بعيد لملء وصلة، وهي لا تبدو في أي إحصاء كهجوم.

وثلاث نقاط تؤلم في الواقع العملي. يجب ضبط sv_allowupload 0، لأنكم لا تحتاجون إلى رفع ملفات من العميل إلى الخادم. وإذا كان خادم الويب الخاص بـ sv_downloadurl على المضيف نفسه الذي عليه اللعبة، فيتقاسم التنزيل وحركة اللعب الوصلة نفسها وعنوان IP نفسه، وحينها يصيب هجوم على 443/TCP مباراتكم الجارية أيضاً. والمتغير sv_consistency 1 ليس حماية من الهجمات بل من ملفات العميل المختلفة؛ ولا تعطّلوه إلا إذا ثبت أن حملة ما لا تبدأ بدونه.

8. SourceMod وMetamod والامتدادات

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

• إبقاء Metamod:Source وSourceMod متوافقين مع إصدار المحرّكة. فـ Left 4 Dead 2 ما زال يتلقى تحديثات، والامتداد غير المتوافق هو السبب الأكثر شيوعاً للانهيارات مباشرةً بعد التحديث.
• استخدام Left4DHooks بدلاً من التدخلات الخاصة. فالأحداث المميزة لـ L4D2 متوفرة مجمّعة في هذا الامتداد. والتدخلات الخاصة في الدوال نفسها هي أسرع طريق إلى ملف خادم تنفيذي يتعطل عند تتابعات حزم معينة.
• استخدام L4DToolZ بوعي فقط. فالامتداد يرفع حدود المقاعد المدمجة. وكل مقعد إضافي يعني لاعباً إضافياً يولّد وقت معالجة، وهو يحتاج مع نظام اللوبي إلى sv_force_unreserved 1.
• امتدادات أقل. فكل إضافة هي شيفرة في العملية نفسها. والامتدادات التي تحمل خدمات ويب خاصة بها تفتح منافذ إضافية وتنشر غالباً العنوان نفسه الذي تريدون حمايته.

والحظر يجب تخزينه بشكل دائم، وإلا فهو يزول بعد إعادة التشغيل. وتعرف عناوين Source لذلك الأمر banid مع writeid، والأمر addip مع writeip، وتُقرأ الملفات الناتجة من جديد عبر exec banned_user.cfg وexec banned_ip.cfg.

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

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

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 notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport 27015 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 -p. أما إن كانت القيم لازمة أصلاً فالنواة نفسها تخبركم: إذا ارتفع UdpRcvbufErrors في nstat -az فهي تعمل. وإذا بقي العدّاد عند صفر فلا يغيّر التعديل شيئاً. هذا احتياطي، لا حماية.

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

أهم سؤال أثناء الهجوم هو: كم يصل، وعلى أي منفذ، وهل هو حركة استعلام أم حركة لعب. وأربعة أوامر تكفي:

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

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

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

أين تنتهي هذه التدابير

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

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

وفي المقابل توجد هجمات حقيقية. مثالان من التشغيل لدى KernelHost، وقد صُفّي كلاهما في الوقت الفعلي: سيل UDP ضد خادم ألعاب على 7777/UDP بأكثر من 112٫2 جيجابت/ث وأكثر من 8٫7 مليون حزمة في الثانية، وهجوم متعدد المتجهات ضد خادم صوتي على 9987/UDP بأكثر من 473٫4 جيجابت/ث وأكثر من 41٫5 مليون حزمة في الثانية. احسبوا ذلك مقابل وصلتكم: 473٫4 جيجابت/ث تعادل نحو 470 ضعفاً لوصلة بسرعة 1 جيجابت/ث، وما زالت تعادل نحو 47 ضعفاً لوصلة بسرعة 10 جيجابت/ث.

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

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

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

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

• المستوى 1: سعة تخفيف 17 تيرابت/ث في شبكة التنظيف العالمية. تُنقّى الهجمات الحجمية قريباً من مصدرها، قبل وقت طويل من وصولها إلى مركز البيانات.
• المستوى 2: تصفية Arbor في الوقت الفعلي بسعة 3٫2 تيرابت/ث في فرانكفورت أم ماين. فأمام الخادم مباشرةً تُكتشف الأنماط الخاصة بكل بروتوكول على الطبقات 3 إلى 7 وتُسقط، حزمةً حزمة.

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

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

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

• عنوان IP مخصص للحماية. يُحوَّل خادمكم في شبكتنا إلى هذا العنوان، ولا يلزم أي تعديل من جهتكم.
• قواعد حماية تديرونها بأنفسكم لكل منفذ وبروتوكول. فتحدّدون في منطقة العملاء أي منفذ يُصفّى بأي ملف، أي 27015/UDP بشكل مختلف عن خادم الويب الذي يسلّم حملاتكم.
• التغييرات تسري في الوقت الفعلي، دون تذكرة ودون انتظار. أي أنكم تستطيعون التعديل أثناء هجوم جارٍ.
• ملف حماية مناسب لكل لعبة. لـ Left 4 Dead 2 وبقية عناوين Source، وكذلك لأكثر من 40 لعبة وبروتوكولاً آخر، إضافةً إلى ملفات TCP وUDP حرة للخوادم المعدَّلة.

وهنا أيضاً يسري نموذج PrePaid: لا مدة التزام دنيا، ولا مهلة إشعار للإلغاء، ولا عقد، ولا رسوم إعداد. وإذا انتهت موجة الهجوم فلا تجدّدون، وهذا كل شيء.

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

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

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

الخادم اختفى من بحث اللوبي لكنه ما زال يعمل: في الغالب حُجب 27015/UDP بشكل شامل أو حُدّد معدله بضيق مفرط، ولأن حركة اللعب والاستعلام يتقاسمان المنفذ نفسه تصيب القاعدة الخشنة كليهما. اعملوا بدلاً من ذلك بتطابق على الحزم عديمة الاتصال. وإذا كان المنفذ متاحاً والخادم غير مرئي مع ذلك، فتحقّقوا من sv_search_key وsv_steamgroup_exclusive وsv_lan 0 وsv_region 255، ومما إذا كان التشغيل قد جرى سهواً بالمعامل -nomaster.

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

جميع اللاعبين يعانون من ping مرتفع، لكن الوصلة ليست ممتلئة: هذا يشير إلى معدل الحزم لا إلى الحجم. انظروا إلى الحزم المُسقطة في ip -s link show وإلى عدّادات UDP في nstat -az. وإذا ظهر في سجل النظام nf_conntrack: table full فأخرِجوا منفذ اللعبة عبر notrack.

قاعدة جدار الحماية صحيحة ومع ذلك لا تعمل: تحقّقوا بالأمر iptables -L INPUT -n -v مما إذا كانت عدّادات التطابق ترتفع. فإذا بقيت عند صفر فلا يُوصل إلى القاعدة، لأنها تقع خلف سلاسل UFW أو لأنها فُقدت بعد آخر إعادة تشغيل. وإذا ارتفعت ولم يتغير شيء، فالوصلة أمام الخادم مشبعة، ومن هنا لا تفيد إلا التصفية في الشبكة.

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

اللاعبون الجدد يحمّلون إلى ما لا نهاية والوصلة ممتلئة أثناء ذلك: إذاً srcds يسلّم ملفات الحملة بنفسه عبر منفذ اللعبة. اضبطوا sv_downloadurl على خادم ويب وضعوا الملفات هناك كأرشيف bzip2، أو دلّوا لاعبيكم على Steam Workshop.

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

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

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

• يحتاج خادم Left 4 Dead 2 إلى منفذ مفتوح واحد بالضبط إلى الخارج: 27015/UDP. وحركة اللعب واستعلام A2S يتقاسمانه، ولا يوجد منفذ استعلام منفصل.
• المنفذ 27015/TCP هو RCON ويجب أن يُقصر على عنوانكم الخاص حصراً. ومن لا يحتاج RCON فليترك rcon_password فارغة.
• نظام اللوبي هو أقوى مصفاة وصول مجانية تعرفها اللعبة: فـ sv_allow_lobby_connect_only 1 ومفتاح sv_search_key خاص بكم وsv_steamgroup_exclusive 2 تحجب كل ما لا يأتي عبر Matchmaking. لكنه يصفّي الانضمام، لا الحزم.
• الحملات المخصصة تنتمي إلى Steam Workshop أو إلى ما خلف sv_downloadurl، ولا تُسلَّم عبر منفذ اللعبة أبداً. وإلا فكل محاولة اتصال متوقفة تُدفع من نطاقكم الترددي.
• يجب أن يميّز تحديد المعدل بين الحزم عديمة الاتصال (التي تبدأ بـ 0xffffffff) وحركة اللعب. فالقاعدة الخشنة على 27015/UDP تطرد لاعبيكم أنفسهم.
• عند حزم بحجم 64 بايتاً تحمل وصلة بسرعة 1 جيجابت/ث نحو 1٫49 مليون حزمة في الثانية. وفوق ذلك تقرّر الشبكة أمام الخادم وحدها، لا أي إعداد على الخادم نفسه.
• لدى KernelHost تصفّي سعة 17 تيرابت/ث من التنظيف العالمي وتصفية Arbor في الوقت الفعلي بسعة 3٫2 تيرابت/ث في فرانكفورت أم ماين بشكل دائم ودون أي رسوم إضافية، دون null-routing ودون زمن تبديل.

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

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