Team Fortress 2: حماية خادم TF2 من هجمات DDoS

الخادم المجتمعي لـ⁦Team Fortress 2⁩ الذي يفقد مساءً في وسط الجولة جميع اللاعبين في وقت واحد ثم يختفي لدقائق من متصفح الخوادم نادراً ما تكون مشكلته في العتاد. ففي معظم الحالات يجري هجوم على ⁦27015 UDP⁩. يعرض هذا المقال كيف تحمون خادم TF2 من هجمات DDoS: أولاً ما تستطيعون فعله بأنفسكم في الدقائق العشر القادمة دون تكاليف إضافية، ثم الموضع الذي تنتهي عنده هذه الإجراءات فيزيائياً، وفي الختام ما يجب أن يحدث قبل ذلك في الشبكة.

جميع المعطيات تتعلق بخادم Source مخصص مثبَّت بواسطة SteamCMD (srcds_run -game tf) يعمل بنظام ⁦Debian 12⁩ أو ⁦Debian 13⁩ أو ⁦Ubuntu 22.04 LTS⁩ أو ⁦Ubuntu 24.04 LTS⁩. والأوامر مكتوبة للمستخدم root، وكمستخدم عادي تضعون sudo قبلها. وإذا كان الهجوم جارياً الآن: لا تغيّروا شيئاً أولاً ولا تعيدوا تشغيل الخادم، بل احفظوا القياسات الواردة في القسم 9. فهي تختفي بعد انتهاء الهجوم.

لماذا تحتاج خوادم ⁦Team Fortress 2⁩ إلى حماية من DDoS

⁦Team Fortress 2⁩ قابلة للعب بالمجان منذ عام 2011، وهذا بالضبط ما يُزحزح اقتصاد الهجوم. فالمهاجم يملك عدداً غير محدود من الحسابات المؤقتة، ولا يدفع عن أي منها شيئاً، ولا يخسر شيئاً عند الحظر. وما يكلّف مالاً في لعبة مدفوعة يكلّف هنا دقيقة واحدة.

ويُضاف إلى ذلك خصوصية تميّز TF2 عن معظم الألعاب الأخرى: فمنذ تحديث «Meet Your Match» في يوليو 2016 لم يبقَ أي Quickplay يوزّع اللاعبين الجدد آلياً على خوادم المجتمع. فاللاعبون الجدد ينتهون في وضع Casual على خوادم Valve، أما خوادم المجتمع فلا يمكن العثور عليها إلا عبر متصفح الخوادم. ومن يسقط من هذه القائمة يصبح عملياً غير موجود بالنسبة للاعبين الجدد، حتى لو كانت عملية الخادم تعمل بلا أي خلل. ولهذا فالهجوم الذي يكتفي بدفع خادمكم خارج القائمة يكون قد حقق هدفه.

والأهداف النموذجية هي بالتالي: خوادم المجتمع العاملة بشكل دائم وذات اللاعبين الثابتين (2Fort على مدار الساعة، وTrade وJailbreak وSurf وDodgeball وMann vs. Machine)، وخوادم الدوريات ذات موعد المباراة الثابت في دوريات ETF2L وRGL وozfortress، إضافةً إلى الخوادم التي حظر مشغّلوها أحداً للتو. والسبب المُحرِّك ليس تقنياً في الغالب. وما هو هجوم DDoS أصلاً يشرحه المقال ما هو هجوم DDoS؟.

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

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

وعند تشغيل عدة نسخ على جهاز واحد ترتفع الأرقام: 27016 و27017 وهكذا للعبة، و27021 و27022 لأجل SourceTV. وملف الإعداد موجود في tf/cfg/server.cfg، ويُقرأ من جديد عند كل تغيير للخريطة.

لماذا يكون المنفذ المشترك 27015 أكثر نقطة حساسية

تتقاسم حركة اللعب واستعلام الخادم في TF2 منفذ UDP نفسه، ولا يوجد منفذ استعلام مستقل. وطلب A2S_INFO طوله 25 بايت بالضبط: أربعة بايتات FF FF FF FF، وبايت واحد 0x54، والسلسلة النصية "Source Engine Query" بطول 20 بايت مع صفر ختامي. أما الجواب الذي يحمل اسم الخادم والخريطة وعدد اللاعبين والوسوم فهو أضعاف ذلك. وتحدد الهيئة الأمريكية CISA معامل تضخيم بروتوكول Steam في التحذير TA14-017A بـ5.5.

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

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

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

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

1. الجرد: ما الذي يستمع، وبأي سطر تشغيل

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

ss -lntup

وكل ما هو مربوط على 127.0.0.1 أو ::1 لا يحتاج إلى فتح. وكل ما هو على 0.0.0.0 أو [::] قابل للوصول من الإنترنت، ومن ذلك أيضاً قاعدة بيانات MySQL التي جاءت مع إضافة إحصاءات، وخادم الويب الذي توجد عليه ملفات FastDL الخاصة بكم. قارنوا النتيجة بسطر التشغيل الخاص بكم:

./srcds_run -game tf -console \
  -port 27015 -steamport 26901 -nohltv \
  +maxplayers 24 +map ctf_2fort +sv_pure 1 \
  +sv_setsteamaccount YOUR_GSLT_TOKEN

وكل منفذ في هذا السطر قرار واعٍ. وكيف تُثبَّت البنية التحتية يوضحه المقال تثبيت خادم لعب بواسطة SteamCMD.

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

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

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'لعبة TF2 و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 هنا بقصد: فمن لا يبثّ يبدأ التشغيل بالمعامل -nohltv ولا يحتل ⁦27020 UDP⁩ من الأساس. وهذا يُنصّف سطح UDP القابل للوصول من الخارج في خادم TF2. وإذا كنتم تبثّون مباريات الدوريات، يُضاف ufw allow 27020/udp، وعندها ينتمي إلى الإعداد ضبط tv_password.

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

3. تحديد استعلامات A2S دون السقوط من متصفح الخوادم

وهنا يكمن أغلى خطأ في هذا المجال: فحجب ⁦27015 UDP⁩ جملةً أو تحديد معدله بشكل فجّ يطرد لاعبيكم أنفسهم ويُنهي الهجوم بما يوافق مراد المهاجم. ولأن حركة اللعب والاستعلام يحتلان المنفذ نفسه، يجب أن يمرّ الحد بين أنواع الحزم، لا على المنفذ.

ويأتي المحرّك لذلك بثلاثة متغيرات وحدة تحكم، وهي تنتمي إلى الملف tf/cfg/server.cfg:

sv_max_queries_sec 3
sv_max_queries_sec_global 60
sv_max_queries_window 30

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

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

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

table inet tf2 {
    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. صد إغراق الحزم المجزّأة الذي يظهر في السجل كـNET_GetLong

هذا الهجوم خصوصية من خصوصيات محرّك Source، ويصيب TF2 بشكل خاص، لأن TF2 يعمل حتى اليوم على فرع المحرّك القديم. فإلى جانب الحزم العادية بلا اتصال يعرف المحرّك حزماً مجزّأة: وهي تبدأ بـFE FF FF FF بدلاً من FF FF FF FF وتُعلن أن رسالة أكبر ستأتي على عدة أجزاء. وعلى الخادم أن يخزّن الأجزاء مؤقتاً وأن ينتظر الباقي.

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

ولأن عميل TF2 النظامي لا يكاد يملك سبباً لإرسال حزم مجزّأة إلى الخادم، فإن وضع حد ضيق هنا مقبول:

udp dport 27015 @th,64,32 0xfffffffe \
    meter tf2split { ip saddr limit rate over 5/second burst 10 packets } drop

ويُوضع هذا السطر في السلسلة نفسها التي فيها قاعدة القسم 3. وأحد الأسباب المشروعة القليلة لتحميلات العملاء الصاعدة تُخرجونه إضافةً إلى ذلك من اللعبة بالإعداد sv_allowupload 0 (انظروا القسم 7).

5. إخراج RCON من الشبكة المفتوحة

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

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

rcon_password "YOUR_RANDOM_VALUE"
sv_rcon_maxfailures 3
sv_rcon_minfailures 3
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

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

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

6. وضع سقف للمعدلات وإبقاء الإسبات مشغّلاً

تعمل ⁦Team Fortress 2⁩ بشكل ثابت على 66.67 تكّة في الثانية. وكمية الحركة الناتجة عن ذلك لا تحددها التكّة، بل ما يحق لعميل واحد أن يطلبه. فبدون حد أعلى يجلب كل لاعب ما يطلبه عميله، وأنتم تدفعون ذلك من نطاقكم الترددي الصادر:

sv_minrate 50000
sv_maxrate 100000
sv_mincmdrate 40
sv_maxcmdrate 66
sv_minupdaterate 40
sv_maxupdaterate 66

احسبوا ذلك مرة: عند sv_maxrate 100000 يحق لكل لاعب أن يسحب 100 كيلوبايت في الثانية، وعلى 24 خانة يكون ذلك 2.4 ميغابايت في الثانية أو نحو ⁦19 Mbit/s⁩ صادراً. وإذا ضبطتم sv_maxrate 0 فلا يوجد أي حد أعلى. وخوادم الدوريات تفعل ذلك بقصد، أما الخادم العام ذو الخانات الكثيرة فينبغي ألّا يفعله. والإضافات التي تفتح معدل التكّات تُضاعف معدل الحزم لكل لاعب ومعه هذه الحسبة نفسها.

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

sv_hibernate_when_empty 1
sv_hibernate_postgame_delay 5
tf_allow_server_hibernation 1

7. فصل FastDL وتعطيل التحميلات الصاعدة

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

sv_allowdownload 1
sv_allowupload 0
net_maxfilesize 64
sv_downloadurl "https://fastdl.example.org/tf/"

والإعداد net_maxfilesize قيمته الافتراضية 15 ويمكن رفعه إلى 64 ميغابايت على الأكثر. ويمنع sv_allowupload 0 أن يرسل العملاء ملفاتهم الخاصة (مثل صور الرشّ) إلى الخادم، ويُزيل بذلك أحد الأسباب المشروعة القليلة للحزم المجزّأة من القسم 4.

والحاسم هو موضع مضيف FastDL. فإذا كان على عنوان IP نفسه الذي عليه خادم اللعبة، كفى إغراق HTTP ضد ⁦443 TCP⁩ لملء الوصلة وبذلك خنق ⁦27015 UDP⁩ أيضاً. ضعوا التحميل السريع على مضيف آخر أو خلف شبكة توصيل محتوى، وعندها لا يصيب الهجوم على الملفات اللعبة.

8. تحديد نظام التصويت وإغراق الانضمام والإضافات

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

sv_allow_votes 1
sv_vote_issue_kick_allowed 0
sv_vote_allow_spectators 0
sv_vote_creation_timer 150
sv_vote_failure_timer 300
sv_vote_quorum_ratio 0.6

وهذه هي القيم الافتراضية: التصويتات مسموحة، وتصويتات الطرد غير مسموحة، والمشاهدون لا يصوّتون، وبين تصويتين 150 ثانية، وبعد تصويت فاشل 300 ثانية، والتصويت يحتاج 60 بالمئة موافقة. ومن يضبط sv_vote_issue_kick_allowed 1 ينبغي أن يعلم أنه يفتح بذلك أداةً يُساء استخدامها على خادم عام بشكل مؤكد.

وكل ما يزيد على ذلك يأتي في TF2 من SourceMod وMetamod:Source. وكلاهما موجود في tf/addons/ ويعرّف عن نفسه في وحدة التحكم بالأمرين meta version وsm version. وبخلاف ⁦Counter-Strike 2⁩، فالبنية التحتية هنا ناضجة، والإضافات الخاصة بقوائم الحظر وفحص الانضمام وتحديد الدردشة هي الطريق المعتاد. وقاعدتان في هذا الصدد: كل إضافة هي شيفرة في العملية نفسها، والإضافة التي تنهار تأخذ الخادم معها. والإضافات التي تأتي بخدمات وِبّية خاصة بها تفتح منافذ أخرى وتنشر أحياناً العنوان نفسه الذي تريدون حمايته بالضبط. والأمر sm plugins list يُظهر ما يعمل فعلاً.

وكم يجب أن تُؤخذ جهة المحرّك بجدية يُظهره أبريل 2020: فبعد تسرّب نسخ أقدم من الشيفرة المصدرية لـTF2 وCS:GO، أوقف مشغّلو مجتمعات كبار مثل Creators.TF وRed Sun خوادمهم مؤقتاً خوفاً من الاستغلال. أبقوا ملف الخادم التنفيذي محدّثاً والإضافات مناسبةً لإصدار المحرّك.

9. القياس والتسجيل قبل أن تقع المشكلة

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

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

يُظهر الأمر الأول الحزم والأخطاء والمُسقَط لكل واجهة؛ نفّذوه مرتين بفاصل عشر ثوانٍ، وعندها تملكون معدلاً بدلاً من قيمة مطلقة. والتسجيلان يفصلان إغراق الاستعلامات عن إغراق الحزم المجزّأة، ويجيبان بذلك عن السؤال: أي القاعدتين من القسمين 3 و4 يجب أن تعمل أصلاً. قيّدوهما دائماً بالمعامل -c، فالتسجيل تحت الحِمل الكامل يكلّف وقت معالجة بنفسه.

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

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

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

ضعوا التشغيل الطبيعي لخادم TF2 ممتلئ جانب هجوم حقيقي، وتتضح النسبة:

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

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

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

ما تضعه KernelHost في مواجهة الهجمات على خوادم TF2

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

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

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

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

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

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

• عنوان IP مخصص للحماية من النواة الفرانكفورتية، يُحوَّل خادمكم إليه داخل شبكتنا. ولا يلزم أي تغيير في جهتكم.
• قواعد حماية تديرونها بأنفسكم لكل منفذ وبروتوكول في منطقة العملاء: تضبطون بشكل منفصل ما المسموح على ⁦27015 UDP⁩، وما المسموح على ⁦27020 UDP⁩، وما المسموح على ⁦27015 TCP⁩، دون كتابة تذكرة لذلك.
• التغييرات تسري في الوقت الفعلي، أي تستطيعون التعديل أثناء هجوم جارٍ بدلاً من الانتظار إلى نهاية المباراة.
• ملف حماية مناسب للعبة، لأجل ⁦Team Fortress 2⁩ وبقية عناوين Source، وكذلك ملفات TCP وUDP حرة للتطبيقات الخاصة.

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

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

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

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

«الخادم يعمل، لكنه لم يبقَ في متصفح الخوادم»: تحقّقوا أولاً من رمز دخول خادم اللعب. فخوادم TF2 تحتاج للإدراج العام إلى رمز يُضبط عبر sv_setsteamaccount ويُولَّد لمعرّف التطبيق 440. وSteam يسحب الرموز التي لم تُستخدم 30 يوماً. فالخادم الذي يختفي بعد توقف طويل يحتاج غالباً إلى رمز جديد فقط ولا يكون مُهاجَماً على الإطلاق. وبعد ذلك فقط يأتي الاحتمال أن يكون sv_max_queries_sec_global منخفضاً جداً أو أن تكون قاعدة جدار الحماية على ⁦27015 UDP⁩ فجّة جداً.

«المعالج على 100 بالمئة، والوصلة فارغة تقريباً»: هذه هي الصورة النموذجية لإغراق استعلامات أو إغراق حزم مجزّأة. انظروا في سجل الخادم إلى الأسطر التي تحمل NET_GetLong وقيسوا بسطري tcpdump من القسم 9 أي نوع من الحزم يصل.

«قواعد nftables أو iptables لدي لا تعمل»: ثلاثة أسباب شائعة. القاعدة موضوعة بعد سلاسل UFW ولا يُوصَل إليها أبداً (ولهذا الأولوية -10)، أو أنها اختفت بعد إعادة التشغيل الأخيرة، أو أن الهجوم حجمي والقاعدة تعمل بشكل صحيح على وصلة ممتلئة أصلاً. تحقّقوا بالأمر nft list ruleset مما إذا كانت العدّادات ترتفع. فإذا بقيت عند الصفر، فالقاعدة لا يُوصَل إليها.

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

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

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

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

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

باختصار

• يحتاج خادم TF2 نحو الخارج إلى ⁦27015 UDP⁩ بالضبط. وRCON على ⁦27015 TCP⁩ ينتمي إلى ما يجب تقييده على عنوانكم الخاص، وSourceTV على ⁦27020 UDP⁩ يُعطَّل بالمعامل -nohltv إذا لم تكونوا تبثّون.
• تتقاسم حركة اللعب واستعلام A2S المنفذ نفسه. ومن يحجب ⁦27015 UDP⁩ جملةً أو يحدد معدله يطرد لاعبيه أنفسهم. ويجب أن يمرّ الحد بين أنواع الحزم، ويُعرَف ذلك من أول أربعة بايتات بعد ترويسة UDP.
• إغراق الحزم المجزّأة ذات الترويسة FE FF FF FF يولّد حِمل معالج لا نطاقاً ترددياً، ويظهر في السجل كـNET_GetLong. ووضع حد ضيق على هذا النوع من الحزم مقبول في TF2.
• منذ «Meet Your Match» لا يجد اللاعبون الجدد خوادم المجتمع إلا عبر متصفح الخوادم. وكل إجراء يدفعكم خارج القائمة يعمل مثل الهجوم نفسه.
• يعالج خادم ممتلئ بـ24 خانة نحو 1,600 حزمة واردة في الثانية. والهجمات ضد خوادم اللعب المجتمعية تقع في المعتاد بين 5 و⁦50 Gbit/s⁩ وعند عدة ملايين حزمة في الثانية.
• تحمل ⁦1 Gbit/s⁩ عند الحزم الصغرى نحو 1.49 مليون حزمة في الثانية. وفوق هذا الحد تحسم الشبكة الواقعة قبل الخادم وحدها، لا أي قاعدة على الخادم.
• لدى KernelHost تكون الحماية الدائمة ذات المستويين مشمولة في كل حزمة خادم دون زيادة في السعر وفعّالة من لحظة التسليم، دون توجيه إلى العدم. وتُضاف Advanced DDoS Protection ابتداءً من ⁦50.00 EUR⁩ في الشهر إذا أردتم أن تتحكموا بأنفسكم في القواعد لكل منفذ.

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