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

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

تنطبق جميع المعطيات على L2J ومشتقاته (L2J-Mobius وaCis) على Debian 12 وDebian 13 وUbuntu 22.04 LTS وUbuntu 24.04 LTS، وكذلك على توزيعات L2OFF المكوّنة من AuthD وCacheD وL2Server. الأوامر مكتوبة للمستخدم root، وكمستخدمين عاديين تضعون sudo قبلها.

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

حماية خادم Lineage 2 من DDoS: لماذا تُهاجَم خوادم L2 الخاصة

يجمع خادم Lineage 2 الخاص عدة خصائص تجعل منه هدفاً مريحاً، ومن هذه الخصائص بالضبط يجب أن تبدأ حماية Lineage 2 من DDoS. أولاً، عنوانكم علني، ومنذ البداية: ينزّل اللاعبون مجلد System معدّلاً، وفي ملف l2.ini داخله يوجد السطر ServerAddr= مع عنوان IP الخاص بخادم تسجيل الدخول لديكم. وكل من ثبّت مشروعكم مرة واحدة يعرف هذا العنوان، سواء أنشأ شخصية يوماً أم لم ينشئ.

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

لماذا يكون خادم تسجيل الدخول على المنفذ 2106 هو الهدف الحقيقي

Lineage 2 موزّعة على عمليتين منفصلتين: خادم تسجيل دخول، وخادم لعبة واحد أو أكثر. يتصل العميل أولاً على 2106 TCP بخادم تسجيل الدخول، ويسجّل دخوله، ويستلم من هناك قائمة الخوادم مع العنوان الخارجي ومنفذ خادم اللعبة، ثم يبني اتصالاً ثانياً على 7777 TCP بخادم اللعبة. ولكل من العمليتين ملفات إعداد خاصة، ومنافذ خاصة، وحدود تحمّل خاصة.

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

وخادم تسجيل الدخول هو أيضاً الهدف الأرخص، لأن الجهد موزّع بشكل غير متكافئ. فخادم تسجيل الدخول في L2J يولّد عند بدء التشغيل مخزوناً من عشرة أزواج مفاتيح RSA بطول 1024 بت وعشرين مفتاح Blowfish. وكل محاولة تسجيل دخول تكلّف العميل إرسال حزمة واحدة، وتكلّف الخادم عملية فكّ تشفير بمفتاح RSA الخاص. وتشغل الجلسة غير المكتملة مقعداً حتى يتخلص منها المؤقّت المدمج: القيمة LOGIN_TIMEOUT مضبوطة في الشيفرة المصدرية على 60 ثانية. والإعداد الافتراضي MaxConnectionPerIP = 50 يسمح لكل عنوان مصدر بخمسين اتصالاً متزامناً. وبذلك يكفي ألف عنوان مصدر لـ 50٬000 جلسة مفتوحة في الوقت نفسه، تبقى كل واحدة منها قائمة حتى دقيقة كاملة.

ويضاف إلى ذلك خصوصية في اللعبة تميّزها عن معظم خوادم الألعاب: تعمل Lineage 2 عبر TCP حصراً. فالشركة المنتجة تذكر للعبة منافذ TCP رقم 80 و2009 و2106 و7777، ومن UDP المنفذ 53 وحده لتحليل الأسماء. أي أنه لا توجد حركة لعب عبر UDP تحتاج إلى تصفية، لكن في المقابل يكون طوفان SYN الكلاسيكي بعناوين مصدر مزيّفة فعّالاً مباشرةً، ويصبح تتبّع الاتصالات في النواة أول عنق زجاجة.

لماذا تتركّز الهجمات على خوادم Lineage 2 موسمياً عند انطلاق الخوادم

تتكاثف الهجمات على خوادم Lineage 2 الخاصة حول مواعيد انطلاق الخوادم، لأن تاريخ الافتتاح وساعته معروفان علناً قبل أسابيع. فتقاويم الافتتاح الخاصة بمشاريع Lineage 2 تسرد الانطلاقات القادمة بحسب الحقبة (Interlude وHigh Five وClassic وEssence)، ومعها المعدلات وساعة البدء بالضبط، وتُحدَّث يومياً. ولا يحتاج المهاجم إلى أي استطلاع: أفضل وقت له مكتوب في إعلان المشغّل نفسه.

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

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

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

يسرد الجدول التالي منافذ خادم Lineage 2 الخاص، وملف الإعداد الموافق لكل منها، والتوجيه الذي يضبط القيمة. والإعدادات الافتراضية مأخوذة من ملفات الإعداد المرفقة مع L2J، أو من أدلة تركيب توزيعات L2OFF.

ويجيب هذا الجدول على سؤالين إضافيين: Lineage 2 ليس لها منفذ استعلام ولا منفذ RCON. فلا توجد خدمة منفصلة تسلّم حالة اللاعبين إلى قائمة خوادم، ولا منفذ تحكّم عن بُعد كما في الألعاب المبنية على Source. فقائمة الخوادم يولّدها خادم تسجيل الدخول بنفسه، ويرسلها عبر الاتصال نفسه على 2106 إلى العميل المسجَّل. أما التحكم عن بُعد فيجري في L2J عبر أوامر داخل اللعبة وعبر قاعدة البيانات. وبذلك يسقط متجهان للهجوم موجودان في ألعاب أخرى، ويبقى ما هو أكثر منهما معلّقاً بالمنفذ 2106.

مقادير ينبغي أن تعرفوها

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

هذا القسم هو الأطول، وذلك بقصد. فخادم Lineage 2 المضبوط بعناية يتحمّل الهجمات الصغيرة والمتوسطة بقوته الذاتية، بصرف النظر عن الجهة التي يقيم عندها.

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

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

ss -lntp

المهم هو العمود الذي يحمل العنوان المحلي. فالقيمتان 0.0.0.0:2106 و0.0.0.0:7777 تنتميان إلى هناك. أما 0.0.0.0:9014 و0.0.0.0:3306 فهما خطأ: هذان هما المنفذان اللذان يمكن للمهاجم عبرهما أن يعلّق نفسه في قائمة خوادمكم أو أن يتحسّس قاعدة بياناتكم. في المقابل تعني القيمة 127.0.0.1:3306 «محلياً فقط» ولا تحتاج إلى قاعدة في جدار الحماية. أما رؤية المهاجم فيوفّرها فحص منافذ من الخارج:

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

2. إبعاد المنفذ 9014 وقاعدة البيانات عن الشبكة المفتوحة

المنفذ 9014 هو القناة التي يسجّل خادم اللعبة نفسه عبرها عند خادم تسجيل الدخول، وهو لا ينتمي إلى الشبكة المفتوحة بأي حال من الأحوال. وL2J يأتي بالإعداد الافتراضي الصحيح لذلك: القيمة LoginHostname = 127.0.0.1 تربط المنفذ بواجهة الاسترجاع المحلية، فلا يكون قابلاً للوصول من الخارج أصلاً. وإذا كان خادم تسجيل الدخول وخادم اللعبة يعملان على جهازين مختلفين، فاكتبوا العنوان الداخلي المحدد بدلاً من *، واسمحوا بالمنفذ للطرف المقابل وحده.

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

bind-address = 127.0.0.1

واستبدلوا مستخدم قاعدة البيانات. فالملف المرفق Server.properties مضبوط على Login = root، والملف نفسه يعلّق على ذلك بالإشارة إلى أن هذا بالتحديد غير مستحسن. وكيف تنشئون مستخدماً خاصاً بأقل الصلاحيات، فذلك موجود في تأمين MariaDB وMySQL. وبعد ذلك تفحصون النتيجة:

ss -lntp | grep -E ':9014|:3306'

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

ufw allow 22/tcp comment 'SSH'
ufw allow 2106/tcp comment 'L2 Login'
ufw allow 7777/tcp comment 'L2 Game'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

وتجدون الدليل الكامل مع طريق النجاة في إعداد جدار حماية UFW دون أن تحجبوا أنفسكم.

3. تعطيل AcceptNewGameServer بمجرد تسجيل خادمكم

في ملف LoginServer.properties توجد من المصنع القيمة AcceptNewGameServer = True، والتعليق فوقها يصف بدقة ما يعنيه ذلك: يحق لأي خادم لعبة أن يسجّل نفسه في مقعد حرّ من خادم تسجيل الدخول لديكم. وطالما بقي المنفذ 9014 على واجهة الاسترجاع المحلية وحدها، فلا أثر لذلك. لكنه يصبح باباً مفتوحاً بمجرد أن يصير المنفذ قابلاً للوصول لسبب آخر. لذلك اضبطوا القيمة على False بمجرد أن يسجّل خادم اللعبة الخاص بكم نفسه مرة واحدة ويحصل على معرّفه:

AcceptNewGameServer = False

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

4. الضبط الصحيح للحماية من الطوفان في خادم تسجيل الدخول

يأتي L2J بمكابح اتصال خاصة به في خادم تسجيل الدخول. وهي موجودة في ملف LoginServer.properties، وجميع القيم الزمنية بالمللي ثانية:

EnableFloodProtection = True
FastConnectionLimit = 15
NormalConnectionTime = 700
FastConnectionTime = 350
MaxConnectionPerIP = 50

والقيم مترابطة. فالاتصال الذي يصل من عنوان المصدر نفسه بعد أقل من FastConnectionTime من الاتصال السابق يُحسب سريعاً. وبعد عدد FastConnectionLimit من هذه الاتصالات يُرفض العنوان. والقيمة NormalConnectionTime هي الفاصل الذي يبدأ عنده العدّاد بالتراجع. أما MaxConnectionPerIP فهي الحد الأعلى للاتصالات المفتوحة في الوقت نفسه لكل عنوان.

وخمسون اتصالاً متزامناً قيمة سخية جداً للاعب واحد، والقيم الأدنى تساعد بشكل ملموس. ومع ذلك يجب الحذر هنا: فعدة لاعبين في المنزل نفسه، ومقهى إنترنت، وقبل كل شيء الوصلات الواقعة خلف Carrier-NAT (وهذا يشمل في أوساط L2 كثيراً من اللاعبين من تركيا والبرازيل وأجزاء من أوروبا الشرقية) يتشاركون عنواناً عاماً واحداً. ومن يضبط القيمة هنا على 3 يحجب لاعبين حقيقيين. قيسوا أولاً أسبوعاً في التشغيل العادي، ثم اخفضوا القيمة بخطوات.

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

5. تقييد المحاولات الفاشلة واستخدام banned_ip.cfg

يوجد في ملف LoginServer.properties توجيهان آخران يحكمان مدة السماح بالتخمين:

LoginTryBeforeBan = 5
LoginBlockAfterBan = 900

القيمة LoginTryBeforeBan هي عدد التركيبات غير الصحيحة من الحساب وكلمة المرور التي يُحجب العنوان بعدها، والقيمة LoginBlockAfterBan هي مدة الحجب بالثواني (900 تساوي 15 دقيقة). ثم يبدأ العدّ من جديد.

أما الحجب الدائم فتكتبونه في الملف banned_ip.cfg في مجلد إعداد خادم تسجيل الدخول. ويُسمح فيه بعناوين مفردة، وبشبكات كاملة، وبوقت انتهاء اختياري كطابع زمني Unix بالمللي ثانية، وكل ما يأتي بعد # هو تعليق:

198.51.100.7
203.0.113.0
198.51.100.44 1789689600000

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

6. تقييد معدلات الاتصال على 2106 و7777 في النواة

ما تقرره مكابح Java متأخراً، تقرره النواة أبكر وأرخص. فضد الهجمات الصغيرة والبوتات غير النظيفة يفيد حدّ أعلى لكل عنوان مصدر:

iptables -I INPUT -p tcp --dport 2106 --syn -m connlimit --connlimit-above 8 --connlimit-mask 32 -j DROP
iptables -I INPUT -p tcp --dport 2106 --syn -m hashlimit --hashlimit-name l2login --hashlimit-mode srcip --hashlimit-above 6/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p tcp --dport 7777 --syn -m connlimit --connlimit-above 6 --connlimit-mask 32 -j DROP

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

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

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

أما تحت UFW فمثل هذه القواعد تنتمي إلى /etc/ufw/before.rules، لأنها تختفي غير ذلك عند تنفيذ ufw reload التالي.

7. صدّ طوفان SYN: syncookies والطابور الخلفي وتتبّع الاتصالات

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

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sysctl -w net.core.somaxconn=4096
sysctl -w net.ipv4.tcp_synack_retries=2

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

وهناك عنق زجاجة كثيراً ما يُغفَل: تتبّع الاتصالات في النواة. فإذا امتلأ، أسقط الخادم أيضاً حزماً مشروعة، وظهر في السجل النص "nf_conntrack: table full, dropping packet". والحالة والحد الأعلى يظهرهما:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

8. الموقع وخادم تسجيل الدخول وخادم اللعبة على عناوين IP منفصلة

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

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

وهنا موضع الصراحة بدلاً من التفكير الرغبوي: عنوان خادم تسجيل الدخول لديكم لا يمكن إبقاؤه سراً. فهو موجود في ملف l2.ini في مجلد System الذي ينزّله كل لاعب. أما عنوان خادم اللعبة فيوزّعه خادم تسجيل الدخول بنفسه: في L2J يوجد كعنوان خارجي في ملف ipconfig.xml (وفي المشتقات الأقدم كقيمة ExternalHostname في Server.properties)، ويُبلَّغ به كل عميل سجّل دخوله بنجاح. الإخفاء ليس استراتيجية، أما التصفية فهي استراتيجية.

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

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

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

والسطر الثاني هو الأكثر دلالة في Lineage 2: فهو يعدّ الاتصالات نصف المفتوحة. وقيمة من خمس خانات مع بضع مئات من اللاعبين هي طوفان SYN ولا شيء آخر. وفي tcpdump تسري القاعدة: قيّدوا دائماً بالخيار -c، فالتقاط الحركة تحت الحمل الكامل يثقل خادماً مثقلاً أصلاً. وكيف تحلّلون القيم، فذلك موجود في كشف هجوم DDoS.

حيث تنتهي هذه التدابير

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

احسبوا معنا مرة. خادم ألعاب نموذجي معلّق على 1 غيغابت/ث، أي 125 ميغابايت في الثانية، وتمتلئ الوصلة بمجرد أن يرسل أحد أكثر من ذلك. وضد خادم Lineage 2 لا يحتاج الأمر حتى إلى هجوم كبير، لأن المقدار الثاني يضرب أبكر: معدل الحزم. فمع حزم صغيرة بحجم 64 بايت تتسع في وصلة بسعة 1 غيغابت/ث نحو 1٫49 مليون حزمة في الثانية. ونواة خادم عادية تعالج منها، بحسب المعالج وبطاقة الشبكة، بضع مئات الآلاف قبل أن تبدأ بالإسقاط.

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

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

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

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

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

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

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

Advanced DDoS Protection للمشاريع المستهدفة بشكل دائم

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

• عنوان IP محمي مخصّص من قلب شبكة فرانكفورت، يُنقل إليه خادمكم داخل شبكتنا. ولا حاجة إلى أي تعديل من جانبكم.
• قواعد حماية تديرونها بأنفسكم لكل منفذ وبروتوكول في منطقة العملاء: تضبطون بشكل منفصل ما هو مسموح على 2106 TCP وما هو مسموح على 7777 TCP. وهذه هي النقطة الحاسمة في Lineage 2، لأن للمنفذين نمطي حركة مختلفين تماماً: اتصالات كثيرة وقصيرة من جهة، واتصالات قليلة وطويلة جداً من الجهة الأخرى.
• التغييرات تسري في الوقت الفعلي، أي يمكنكم التعديل أثناء هجوم جار، ويمكنكم تشديد القواعد قبل ساعة الافتتاح وتخفيفها بعدها.
• ملف حماية مطابق للتطبيق، وكذلك لملفات الخادم المعدّلة والخاصة على أي منفذ TCP أو UDP. وسواء شغّلتم L2J أو L2J-Mobius أو aCis أو توزيعة L2OFF، فذلك لا يهمّ سلسلة القواعد، لأنها تعتمد على المنفذ والبروتوكول.

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

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

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

«تسجيل الدخول لا يعمل، لكن خادم اللعبة يعمل بشكل طبيعي»: هذه ليست مصادفة، بل الشكل المعتاد لهجوم على خادم Lineage 2. فخادم تسجيل الدخول وخادم اللعبة عمليتان على منفذين. قيسوا بالأمر ss -tn state syn-recv | wc -l وبالأمر sar -n DEV 1 10. فإذا ارتفعت الاتصالات نصف المفتوحة بينما بقي عرض النطاق الترددي عادياً، فهو طوفان اتصالات على 2106.

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

«ضبطت MaxConnectionPerIP على 3، والآن يشتكي اللاعبون»: تشغيل حسابين معاً أمر معتاد في Lineage 2، واللاعبون الواقعون خلف Carrier-NAT يتشاركون عنواناً عاماً واحداً مع مئات غيرهم. ارجعوا إلى قيمة تغطي قياساتكم من التشغيل العادي، وقيّدوا بدلاً من ذلك معدل الاتصالات الجديدة في النواة.

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

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

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

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

«افتتاحي الكبير بعد أسبوعين»: إذن انتقلوا الآن لا في أسبوع الانطلاق. فالانتقال يكلّف مجلد System جديداً للاعبين، وتحويل DNS، وتشغيلاً تجريبياً. وكل ذلك تريدون أن يكون خلفكم قبل أن تعلنوا التاريخ، فمن لحظة الإعلان يعرف كل منافس أسوأ وقت لديكم.

باختصار

• يحتاج خادم Lineage 2 الخاص إلى منفذين بالضبط في الشبكة المفتوحة: 2106 TCP لخادم تسجيل الدخول و7777 TCP لخادم اللعبة. أما المنفذ 9014 وقاعدة البيانات (3306 في L2J و1433 في L2OFF) ومنافذ L2OFF الداخلية 2002 و2006 و2008 و2104 و2108 فلا تنتمي إلى ذلك.
• تعمل Lineage 2 عبر TCP حصراً، وليس لها منفذ استعلام ولا منفذ RCON. ولذلك يكون الهجوم النموذجي طوفان SYN أو طوفان اتصالات على المنفذ 2106، لا طوفان UDP.
• الهجوم على خادم تسجيل الدخول يعطّل تسجيلات الدخول الجديدة وحدها. فإذا لم يدخل أحد بينما يواصل اللاعبون في العالم لعبهم، فالسبب يُبحث عنه على المنفذ 2106 لا على 7777.
• اضبطوا EnableFloodProtection وMaxConnectionPerIP وLoginTryBeforeBan وAutoCreateAccounts بوعي، واضبطوا AcceptNewGameServer على False بعد التسجيل، وقيّدوا معدلات الاتصال إضافةً إلى ذلك في النواة، لأن مكابح Java لا تعمل إلا خلف الوصلة.
• تتكاثف الهجمات على خوادم Lineage 2 عند انطلاق الخوادم، لأن التاريخ والساعة معروفان علناً قبل أسابيع، ولأن الضرر الاقتصادي يكون في يوم الافتتاح في أقصاه. فالحماية يجب أن تكون قائمة قبل الإعلان لا بعده.
• فوق سعة الوصلة وفوق بضع مئات الآلاف من الحزم في الثانية، تقرر التصفية في الشبكة أمام الخادم وحدها. وهي عند KernelHost ذات مستويين، وفعّالة بشكل دائم، ودون تكلفة إضافية، ودون null-routing.

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