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

من يريد حماية خادم Terraria الخاص به من هجمات DDoS فهو يتعامل مع حالة خاصة: فـTerraria يتكلم TCP حصراً. حركة اللعب تسير عبر منفذ واحد بالضبط، وهو ⁦7777 TCP⁩، ولا تفتح اللعبة أي منفذ UDP على الإطلاق. وجميع النصائح المتداولة في الشبكة حول حماية خوادم اللعب تقريباً مكتوبة لألعاب UDP، وهي تضرب هنا إما في الفراغ وإما في الموضع الخاطئ.

يعرض هذا المقال أولاً ما تستطيعون تأمينه بأنفسكم دون تكاليف إضافية، ثم أين تنتهي هذه الإجراءات تقنياً، وفي الختام ما يجب أن يحدث بعد ذلك في الشبكة الواقعة قبل الخادم. جميع المعطيات تتعلق بخادم Terraria مخصص (نسخة أصلية أو TShock أو tModLoader) يعمل بنظام ⁦Debian 12⁩ أو ⁦Debian 13⁩ أو ⁦Ubuntu 22.04 LTS⁩ أو ⁦Ubuntu 24.04 LTS⁩. والأوامر مكتوبة للمستخدم root، وكمستخدم عادي تضعون sudo قبلها. وإذا كان الهجوم جارياً الآن، فلا تغيّروا أولاً شيئاً في الإعدادات ولا تعيدوا تشغيل الخادم: احفظوا القياسات (انظروا قسم «التسجيل»)، فهي تختفي بعد انتهاء الهجوم.

لماذا تصيب هجمات DDoS خوادم Terraria بالتحديد

خوادم Terraria هدف مريح، لأن عنوانها علني بالضرورة. فـTerraria الأصلي لا يملك متصفح خوادم مدمجاً: فاللاعبون يتصلون عبر «Multiplayer» و«Join via IP»، أي عبر عنوان يجب أن يكون أحدهم قد أعلنه مسبقاً. ومن يريد لاعبين جدداً يسجّل خادمه على صفحات القوائم مثل terraria-servers.com أو tserverweb.com أو topg.org، أو يوزّع العنوان عبر Discord. وكل طريق من هذه الطرق يقدّم للمهاجم ما يقدّمه للاعب نفسه: عنوان IP والمنفذ بنص صريح.

ولذلك إذا كان خادم Terraria ينقطع باستمرار رغم أن شيئاً لم يتغيّر في العتاد والعالم وقائمة الإضافات، فالهجوم هو التفسير الأرجح. ويُضاف إلى ذلك التشكيل النموذجي لأي مشروع: أوقات لعب ثابتة، وخوادم متنافسة، ولاعبون محظورون، وخلافات داخل المجتمع. ولا يكلّف الهجوم من يطلبه مهارةً ولا مالاً يُذكر، فـTerraria Server Booter يُباع كاشتراك بأورو قليلة في الشهر. وما هو هجوم DDoS تقنياً وكيف يُبنى يشرحه المقال ما هو هجوم DDoS؟.

Terraria يعمل عبر TCP، لا عبر UDP

هذا هو أهم فرق عن أي خادم لعب آخر عملياً. فخادم Terraria المخصص يستقبل الاتصالات بمستمع TCP (وهو في محرك اللعبة الصنف Terraria.Net.Sockets.TcpSocket) ولا يفتح أي مقبس UDP. ولذلك أربع نتائج تحدد دفاعكم بأكمله:

• الاتصال TCP المُنشأ بالكامل لا يمكن تزييفه. فعلى المهاجم أن يستقبل رسالة SYN-ACK من الخادم لكي يُتم المصافحة. لذلك فمن يكون متصلاً فعلاً يأتي من عنوان حقيقي. ومن هنا تعمل حجب العناوين وحدود الاتصالات في Terraria بشكل أفضل بكثير منها في لعبة UDP.
• أما إغراق SYN فيمكن تزييفه تماماً، لأنه لا يُتم المصافحة أبداً. ولا يفيد ضد هذا النوع أي حجب للعناوين، بل SYN-Cookies والتصفية في الشبكة الواقعة قبل الخادم وحدهما.
• كل اتصال TCP مقبول إلى المنفذ 7777 يحتل موارد في عملية اللعبة، لا في نواة النظام وحدها. وهذا ما يجعل استنزاف الخانات أفعل هجوم بأقل نطاق ترددي.
• وإغراق UDP يصيب خادمكم مع ذلك. فالحزم لا تحتاج إلى أن تُقبَل لكي تملأ وصلتكم. وكون Terraria لا يتكلم UDP لا يحمي الوصلة، بل يمنع فقط أن تعالج عملية اللعبة نفسها هذه الحزم.

وهناك استثناء واحد: إذا شُغّل الخادم المخصص بالمعاملين -steam و-lobby friends أو -lobby private، فالاتصال يسير عبر شبكة Steam وبذلك عبر منافذ UDP في المجال من 27000 حتى 27100. وهذا وضع تشغيل آخر وليس الخادم الكلاسيكي القابل للوصول عبر عنوان IP.

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

يحتاج خادم Terraria إلى منفذ واحد بالضبط في الشبكة المفتوحة: ⁦7777 TCP⁩. وكل ما عداه في هذا الجدول لا ينتمي إلى الإنترنت من الأصل أو ينتمي إلى عنوانكم الخاص وحده.

وكون Terraria لا يعرف منفذ استعلام ولا RCON خبر جيد للتأمين: فالنقطتان اللتان تُساء استخدامهما بانتظام لهجمات الانعكاس في Counter-Strike أو Rust أو ARK لا وجود لهما هنا ببساطة. لكن في المقابل تتركز الأنماط الهجومية على المنفذ 7777 بشكل أقوى، ومن يستخدم TShock يجلب لنفسه بالمنفذ 7878 سطحاً ثانياً.

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

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

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

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

ss -lntup

المهم هو العمود الذي يحمل العنوان المحلي. فـ0.0.0.0:7777 يعني «قابل للوصول من الإنترنت بأكمله»، و127.0.0.1:7878 يعني «محلياً فقط» ولا يحتاج إلى قاعدة في جدار الحماية. وإذا ظهر في هذه القائمة مُدخَل UDP لعملية Terraria الخاصة بكم، فالخادم يعمل في وضع Steam. أما رؤية المهاجم فيوفرها فحص المنافذ من الخارج:

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

2. إبقاء ⁦7777 TCP⁩ وحده مفتوحاً وإغلاق كل ما عداه

يكفي لـTerraria إذن واحد نحو الخارج. ولا تحتاجون إلى قاعدة UDP، بل إن قاعدة UDP لأجل 7777 ستكون خاطئة ببساطة: فهي تُمرّر حركة إلى منفذ لا يستمع عليه شيء. ومع UFW يبدو ذلك على النحو التالي، وبهذا الترتيب بالضبط حتى لا تحجبوا أنفسكم:

ufw allow 22/tcp comment 'SSH'
ufw allow 7777/tcp comment 'Terraria'
ufw allow from 203.0.113.10 to any port 7878 proto tcp comment 'TShock REST'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

استبدلوا 203.0.113.10 بعنوانكم الخاص. والدليل الكامل مع طريق النجاة موجود في إعداد جدار حماية UFW دون حجب نفسكم. ومن يشغّل لوحة تحكم يقيّد كذلك 8080 و2022 على عنوانه الخاص.

3. ملف serverconfig.txt: الضبط الصحيح لكلمة المرور وmaxplayers وsecure

ملف الإعداد المركزي لخادم Terraria اسمه serverconfig.txt ويُمرَّر عند التشغيل بالمعامل -config serverconfig.txt. وأربع توجيهات حاسمة للتأمين:

port=7777
maxplayers=16
password=ALongRandomPassword
secure=1
upnp=0
banlist=banlist.txt

الإعداد password= هو أفعل إجراء مجاني ضد إغراقات الانضمام التي تسلك الطريق النظامي. والسبب يقع في البروتوكول: فالعميل يرسل أولاً الرسالة 1 مع مُعرّف إصداره (مثلاً Terraria279)، ويجيب الخادم عند ضبط كلمة مرور بالرسالة 37، وعلى العميل أن يجيب بالرسالة 38 بشكل صحيح، وبعد ذلك فقط يرسل الخادم بالرسالة 3 الإذن مع خانة اللاعب. لذلك لا يصل المهاجم دون كلمة المرور الصحيحة إلى نقل العالم أبداً، وهو الجزء المكلف من أي انضمام.

ويقبل maxplayers قيماً من 1 حتى 255، والقيمة الافتراضية هي 16 (وقبل الإصدار 1.4.0.1 كانت 8). والحد الأعلى 255 ليس رقماً اعتباطياً: فـTerraria يعنون اللاعبين ببايت واحد. ولا تضبطوا maxplayers أعلى مما تحتاجونه فعلاً، لأن كل خانة مورد يستطيع المهاجم أن يشغله. ويُشغّل secure=1 فحص الغش المدمج (وعلى سطر الأوامر -secure)، ويمنع upnp=0 أن يفتح الخادم منافذ على موجّه من تلقاء نفسه.

4. تأمين TShock: واجهة REST على 7878 وإغراق تسجيل الدخول

TShock هو امتداد الخادم الأكثر انتشاراً لأجل Terraria، وهو يجلب معه بواجهة REST سطحاً هجومياً ثانياً كامل الأهلية. وهي تقع افتراضياً على المنفذ ⁦7878 TCP⁩ وتُعَدّ في tshock/config.json، أي ليس في serverconfig.txt. وهي مُطفأة في حالة التسليم ("RestApiEnabled": false)، وينبغي أن تبقى كذلك بالضبط ما لم تحتاجوها.

وإذا احتجتموها، فهذه القيم هي المهمة:

"RestApiEnabled": true,
"RestApiPort": 7878,
"EnableTokenEndpointAuthentication": true,
"LogRest": true,
"RESTMaximumRequestsPerInterval": 5,
"RESTRequestBucketDecreaseIntervalMinutes": 1

وشيئان مهمان في ذلك. أولاً، تسلّم نقطة النهاية /status دون رمز وصول اسم الخادم والمنفذ وعدد اللاعبين وأسماء اللاعبين، ما دام EnableTokenEndpointAuthentication على false. وهذا مريح لصفحات الحالة وبوتات Discord، وهو في الوقت نفسه استطلاع مجاني لكل مهاجم يريد معرفة متى يكون الهجوم مُجزياً. وثانياً، تُولّد نقطة النهاية /v2/token/create من اسم المستخدم وكلمة المرور رمز وصول، وهي قابلة للوصول من الخارج بمجرد أن يكون المنفذ 7878 مفتوحاً: أي هجوم تخمين كلمة مرور على حساب الإدارة لديكم، يكلّف وقت معالجة على الهامش. والدلو المؤلَّف من RESTMaximumRequestsPerInterval وRESTRequestBucketDecreaseIntervalMinutes يكبح ذلك، لكنه لا يُغني عن قاعدة في جدار الحماية.

أما لأجل الدخول إلى اللعبة نفسه فتسري قيم أخرى في TShock. فـMaximumLoginAttempts مضبوط على 3 ويطرد اللاعب بعد ثلاث محاولات فاشلة. ويطلب RequireLogin (والافتراضي false) حساباً لكل لاعب. أما EnableIPBans (والافتراضي true) وKickProxyUsers (والافتراضي true) فهما فعّالان بشكل خاص في لعبة تعمل بـTCP، لأن عنوان المصدر لاتصال مُنشأ لا يمكن أن يكون مزيفاً. وضد التخريب داخل اللعبة (Griefing)، الذي يُبلَّغ عنه كهجوم كثيراً، تعمل العتبات TileKillThreshold (60) وTilePlaceThreshold (20) وTileLiquidThreshold (15) وProjectileThreshold (50)، وكلها أفعال في الثانية.

5. تحديد الاتصالات لكل عنوان مصدر والتحقق من SYN-Cookies

لأن Terraria يعمل على TCP، فأفعل قاعدة محلية هي حد أعلى للاتصالات المتزامنة لكل عنوان مصدر. واللاعب الحقيقي يحتاج اتصالاً واحداً بالضبط:

iptables -I INPUT -p tcp --dport 7777 --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP
iptables -I INPUT -p tcp --dport 7777 --syn -m hashlimit --hashlimit-name terraria_syn --hashlimit-mode srcip --hashlimit-above 10/min --hashlimit-burst 20 -j DROP

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

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

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

ومع UFW تنتمي هذه القواعد إلى /etc/ufw/before.rules، لأنها تختفي خلاف ذلك عند ufw reload التالي. أما ضد حزم SYN المزيفة التي لا تُتم المصافحة أبداً، فلا تفيد أي من هذه القواعد، بل نواة النظام نفسها. تحقّقوا من القيم الثلاث:

sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_max_syn_backlog net.core.somaxconn

يجب أن يكون net.ipv4.tcp_syncookies على 1، وعلى Debian وUbuntu يكون ذلك قائماً في العادة. فـSYN-Cookies تتخلى عن طابور الاتصالات نصف المفتوحة وتعيد بناء الحالة من جواب العميل، وبذلك يضرب إغراق SYN في الفراغ ما دامت الوصلة غير ممتلئة. أما net.core.somaxconn فهو على 4096 منذ ⁦Linux 5.4⁩ وعلى 128 قبل ذلك: فإذا كانت القيمة صغيرة، أسقطت نواة النظام اتصالات مُنشأة بالكامل قبل أن تستطيع عملية اللعبة قبولها من الأصل.

6. منع استنزاف الخانات: لماذا يملأ فحص المنافذ خادمكم

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

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

وهناك إعدادان يفيدان إضافةً إلى ذلك. من يستخدم TShock يضبط MaxSlots على عدد اللاعبين المطلوب وmaxplayers في serverconfig.txt أعلى منه بخانتين: فعندها يُسقط TShock الاتصالات الزائدة برسالة نظيفة، بدلاً من أن تُدخلها عملية اللعبة في الفجوة الأخيرة. والحد الأعلى للاتصالات من القسم السابق هو بالضبط القاعدة التي تمنع عنواناً واحداً من شغل جميع الخانات في وقت واحد.

7. إيقاف UPnP وعدم نشر العنوان بأنفسكم

يحاول خادم Terraria افتراضياً أن يفتح منفذه على موجّه بواسطة UPnP. وعلى خادم مستأجر يكون ذلك بلا أثر، وفي شبكة منزلية يفتح منافذ لن تعلموا عنها شيئاً لاحقاً. أوقفوه بالإعداد upnp=0 في serverconfig.txt أو بالمعامل -noupnp على سطر الأوامر.

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

8. حفظ استعلامات الحالة مؤقتاً بدلاً من تمريرها

لأن Terraria لا يملك بروتوكول استعلام، تحدد صفحات الحالة وبوتات Discord وصفحات القوائم حالة خادمكم بإحدى طريقتين: فهي تُنشئ اتصال TCP حقيقياً إلى 7777 وتقدّم نفسها كعميل، أو تستعلم واجهة REST في TShock. وكلا الطريقين يكلّف خادمكم عملاً، وكلاهما يتوسع مع عدد المستعلمين.

والإجراء المضاد لا يكلّف شيئاً: لا تستعلموا أبداً من جهة الزائر. اجعلوا خدمة واحدة تجلب الحالة على فترات ثابتة (30 أو 60 ثانية تكفي)، واحفظوا النتيجة مؤقتاً، وسلّموا جميع الزوار الحالة المحفوظة. وبذلك تولّد صفحة حالة كثيرة الزيارات استعلاماً واحداً في كل فترة بدلاً من استعلام لكل زائر. ومن يستخدم واجهة REST لذلك يقيّد المنفذ 7878 على عنوان هذه الخدمة الواحدة.

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

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

sar -n DEV 1 10
ss -s
ss -tn state syn-recv | wc -l
ip -s link show eth0
tcpdump -ni eth0 tcp port 7777 -c 200 -q

والأمر الثالث هو الخاص بـTerraria: فهو يعدّ الاتصالات نصف المفتوحة. والقيمة من رقمين طبيعية، أما القيمة من أربعة أو خمسة أرقام فهي إغراق SYN. ويُظهر ss -s إلى جانب ذلك العدد الكلي لاتصالات TCP، وإذا كان هذا العدد مساوياً تقريباً لـmaxplayers لديكم بينما لا يوجد أحد في اللعبة، فأنتم ترون استنزافاً للخانات. وفي tcpdump تسري قاعدة ثابتة: قيّدوا دائماً بالمعامل -c، فالتسجيل تحت الحِمل الكامل يُثقل خادماً مُثقلاً أصلاً. وكيف تحلّلون القيم مذكور في كشف هجوم DDoS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«الخادم ممتلئ، لكن لا يوجد فيه أحد»: هذا استنزاف للخانات. تحقّقوا بالأمر ss -tn dst :7777 | wc -l من عدد الاتصالات المفتوحة فعلاً، وقارنوه بقائمة اللاعبين (في وحدة تحكم الخادم: playing). فإذا لم يتوافق العددان، فاتصالات غريبة تشغل الخانات. والعلاج هو الحد الأعلى للاتصالات لكل عنوان مصدر، وكلمة مرور للخادم، وإصدار خادم محدَّث.

«فتحت ⁦7777 UDP⁩ ولم يتغيّر شيء»: هذا صحيح، فلا شيء يستمع على ⁦7777 UDP⁩. وTerraria يستخدم TCP حصراً. والإذن على UDP لا يضر مباشرةً، لكنه فتحة غير ضرورية وعلامة أكيدة على أن دليلاً لأجل لعبة أخرى قد نُسخ.

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

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

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

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

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

باختصار

• يحتاج خادم Terraria إلى منفذ واحد مفتوح بالضبط: ⁦7777 TCP⁩. واللعبة لا تفتح أي مقبس UDP، ولا تملك بروتوكول استعلام ولا RCON.
• واجهة REST في TShock على المنفذ ⁦7878 TCP⁩ هي السطح الهجومي الثاني. اتركوا RestApiEnabled على false أو قيّدوا المنفذ على عنوانكم الخاص.
• كلمة مرور الخادم في serverconfig.txt هي أفعل إجراء مجاني، لأن المهاجم دون جواب صحيح على الرسالة 37 لا يصل إلى نقل العالم أبداً.
• استنزاف الخانات هو أرخص هجوم في Terraria: فكل اتصال TCP مقبول إلى 7777 يشغل خانة، دون نطاق ترددي يُذكر. ويعمل ضده حد أعلى لكل عنوان مصدر، وكلمة مرور، وإصدار خادم محدَّث.
• لأن Terraria يستخدم TCP، فعنوان المصدر لاتصال مُنشأ لا يمكن تزييفه: ولذلك تعمل حجب العناوين هنا بشكل أفضل منها في ألعاب UDP. أما ضد إغراقات SYN المزيفة فلا تفيد إلا SYN-Cookies والتصفية في الشبكة الواقعة قبل الخادم.
• إغراق UDP يُعطّل خادم Terraria الخاص بكم رغم أنه لا يتكلم UDP، لأنه يملأ الوصلة قبل أن ترى عملية اللعبة أي شيء.
• ابتداءً من حجم يقارب نطاق وصلتكم الصاعد، تحسم الشبكة الواقعة قبل الخادم وحدها. ولدى KernelHost تكون هذه التصفية على مستويين، وفعّالة بشكل دائم، ومشمولة في كل حزمة خادم دون زيادة في السعر.

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