بنجي في سطور
BungeeCord هو خادم وكيل يسمح لمشاريع الألعاب بدمج خوادم Minecraft المتعددة مع القدرة على التبديل بسرعة بين اللاعبين.
في هذه المقالة سوف أشارك تجربتي مع النواة ، وأتحدث عن مشاكل الأمان على الخوادم التي تستخدمها ، وأقدم أيضًا بعض النصائح البسيطة التي قد تساعد في منع اختراق مثل هذا الخادم.
باختصار حيث يتم استخدام BungeeCord بشكل شائع:
- خوادم بأوضاع لعب متعددة (بما في ذلك الخوادم ذات الألعاب المصغرة)
- خوادم ذات حمولة عالية والحاجة للتوزيع عبر الإنترنت
- الخوادم التي تستخدم الحماية المستندة إلى BotFilter ضد هجمات الروبوت (السمة المميزة لهذا الخادم هي "التحقق من الإسقاط" أو captcha عند تسجيل الدخول)
نقاط الضعف الأكثر شيوعًا لهذه الخوادم:
- الوصول غير المتحكم فيه إلى أوامر الخادم الوكيل
- تجاوز خادم التفويض
- انتحال بيانات اللاعب
- نقاط الضعف في وحدات الخادم المرحلي
كيف تعمل
معظم المشاريع التي تديرها BungeeCord هي سلسلة الخوادم التالية (والتي يمكن أن توجد على IP واحد على الأقل بمنافذ مختلفة ، حتى على الأجهزة الموجودة في أجزاء مختلفة من العالم).
الوكيل
المرحلة الأولى - في الواقع ، هذا هو الخادم نفسه الذي يتصل به اللاعبون. ليس لديه نقطة ولادة أو عوالم لعبة - مهمته هي إعادة توجيه المتصل إلى المرحلة التالية.
يبدو أن كل شيء بسيط هنا - لكن لا.
السحر الرئيسي ، وفي نفس الوقت المشكلة في هذه المرحلة ، هي إعادة التوجيه نفسها - لا يقوم الخادم بإعادة توجيه اللاعب إلى عنوان IP آخر فحسب ، بل يلعب دور خادم وسيط.
ببساطة ، تتم معالجة جميع الأوامر التي يرسلها المشغل ، وجميع حزم المزامنة ، وكل رسالة في الدردشة هنا أولاً.
كيف هذا يهددنا؟
اسمحوا لي أن أشرح بمثال افتراضي: مطورنا Drygok ، الذي يقوم بعمله ببسالة ، لديه حقوق على الخوادم قريبة من الحد الأقصى. لقد قام بحماية حسابه بشكل مثالي من خلال نظام التفويض الخاص به - كلمة مرور معقدة ، ومصادقة ثنائية ، وحتى الارتباط بمجموعة معينة من عناوين IP لمزود الخدمة الخاص به ، وبعد ذلك يترك الخادم براحة البال ، ولكن بعد 10 دقائق "يطير" جميع اللاعبين وتتوقف الخوادم لأن شخصًا ما نفذ أمر النهاية / نيابة عنه.
ماذا حدث؟ الأمر بسيط: دخل شخص مجهول اللعبة باسم مستعار لمطورنا ، وتجاهل طلبات الخادم لتسجيل الدخول ، وأدخل أمرًا تتم معالجته بواسطة خادم الوكيل نفسه ، مما يعني أنه لا يمكن منعه حتى بالنسبة للمستخدمين غير المصرح لهم.
كيف تمنع؟
أسهل طريقة لمنع مثل هذه المواقف هي تعطيل جميع أوامر kernel الداخلية وإعادة تعيين أي حقوق في هذه المرحلة. حتى بالنسبة للمطور. خاصة للمطور.
خادم التفويض
المرحلة الثانية في السلسلة هي الخادم حيث يسجل اللاعب ويسجل الدخول.
هنا سيشعر المستخدم أولاً بأرض المكعب الصلب أسفل أقدامه الهندسية.
غالبًا ما تبدو خوادم هذه المرحلة كما يلي:
- قطعة أرض صغيرة في مساحة لا نهاية لها من عالم فارغ ، حيث يقف اللاعب أمام تفويض ناجح (أو ليس كذلك)
- الإضافات الأساسية:
SkinsRestorer - , , -
( , )
, ( )
, ( AI , , .)
,
AutoSaveWorld
- عدم وجود أي سيطرة على الحقوق
- عدم وجود أي أنظمة حماية ضد ثغرات kernel أو اللعبة نفسها
المشكلة الرئيسية في هذه المرحلة هي حقوق الطوارئ للاعبين. نادرًا ما يقوم أحدهم بتكوينها ، لأنه لا يمكن إلا للاعب المصرح استخدامه ، وعندما يتم تفويض اللاعب ، يقوم بإعادة التوجيه على الفور إلى المرحلة التالية.
كيف هذا يهددنا؟
في بعض الحالات ، يمكن للاعب منع إعادة التوجيه إلى خادم آخر بعد الإذن: في كثير من الأحيان ، يتم منع عمليات إعادة الاتصال السريع بخادم اللعبة بواسطة النواة أو المكونات الإضافية لذلك الخادم. لذلك ، إذا أعاد اللاعب الاتصال فورًا بعد التفويض الناجح ، فقد يرفض الخادم في المرحلة التالية الاتصال وسيظل اللاعب المصرح له على خادم التفويض.
علاوة على ذلك ، يتعلم اللاعب الذي يتمتع بحقوق رفيعة بهدوء قائمة المكونات الإضافية المثبتة في بلدنا (/ المكونات الإضافية) ، ومن ثم ، بعد أن يتعلم قدراتها بحقوقه ، يبدأ عمله المظلمة.
سأقدم مثالين قابلتهم شخصيًا أكثر من مرة.
المثال الأول. الوصول إلى ASW.
عالم الحفظ التلقائيهو مكون إضافي مفيد للغاية وخطير في نفس الوقت لأي خادم. إمكانياتها في روايتي باختصار:
- حفظ العالم تلقائيا
- النسخ الاحتياطي التلقائي للعالم
- تنظيف العالم حسب الإعدادات المحددة
- الاتصال وإعادة التشغيل وفصل المكونات الإضافية دون إعادة تشغيل خادم اللعبة (/ asw pmanager)
- بدء العمليات الناتجة وإيقافها والتحكم فيها (/ عملية ASW)
نحن مهتمون بالعنصر الأخير من هذه القائمة.
لا ، هذا ليس خطأ. على عدد كبير من الخوادم ، يوجد بالفعل مكون إضافي يسمح لك ببدء أي عملية بالوصول المناسب ، والذي توفره بعض الخوادم لجميع اللاعبين في هذه المرحلة.
في هذه الحالة ، سيكون البعض
/asw process start QQHABR rm -rf / (لا تنفذ هذا الأمر!) أقل المشاكل. أعتقد أنه لا يستحق معرفة ما يمكن أن يفعله "جهاز تكسير" بالوصول إلى الجهاز.
المثال الثاني. جلود غير مؤذية
جلودهو مكون إضافي شائع للغاية يستخدم على عدد كبير من الخوادم. يتم استخدامه بشكل أساسي لاستعادة الأسطح المفقودة بسبب استخدام جلود البروكسي ، ولكن لديه أيضًا القدرة على تثبيت الجلود الخاصة بك. هذه الفرصة بالذات هي نقطة ضعف محتملة.
باستخدام الأمر / skin ، لا يمكنك فقط تحميل المظهر الخارجي للاعب آخر باسمه المستعار ، ولكن يمكنك أيضًا تعيين اسمك الخاص عن طريق تحديد عنوان الصورة (/ عنوان URL للسطح). يكمن خطر هذا الفريق في حقيقة أن الوصول إليه في البداية يُفترض للاعبين (وليس فقط إذا تم تكوين الحقوق بشكل غير صحيح ، كما في حالة ASW).
كيف نستطتيع ان نستعمل هذا؟ تحميل صورة إلى العنوان المحدد هو طلب GET عادي. طلب مقدم من الخادم نفسه.
هناك العديد من الخيارات للاستخدام الإضافي - بدءًا من استدعاء واجهة برمجة تطبيقات مغلقة (على سبيل المثال ، إصدار تبرع) ، يتم توفير الوصول إليها لبعض عناوين IP ، وتنتهي بفيضان منتظم.
كيف تمنع؟
يمكنك منع ذلك عن طريق تقييد حقوق اللاعبين (وهو أمر موصى به على أي خادم) ، وحظر جميع الأوامر الممكنة باستثناء أوامر الترخيص والتسجيل ، وكذلك حظر تثبيت بشرتك عن طريق عنوان URL (أوصي بالقيام بذلك على جميع الخوادم)
المركز رئيسي
Hub - مساحة مشتركة حيث يذهب اللاعبون لتحديد خادم ووضع اللعبة في
أغلب الأحيان ، تكون المحاور ، مثل خوادم اللعبة الرئيسية ، فريدة لكل خادم ، ولكن بعض مشكلات الأمان هي نفسها بالنسبة لهم.
اتصال مباشر
من خلال الاتصال بهذا الخادم مباشرة (إلى IP الخاص به) ، يمكن للاعب تجاوز المراحل السابقة ، بما في ذلك التفويض
كيف هذا يهددنا؟
بعد تخطي مرحلة التفويض ، يمكن للاعب استخدام جميع حقوق المستخدم الذي تم استخدام لقبه للاتصال
كيف تمنع؟
تحتوي معظم مراكز الخادم على إعداد مضمن لحظر الاتصالات دون استخدام BungeeCord. على سبيل المثال Spigot في spigot.yml:
settings:
bungeecord: trueإذا كنت تستخدم هذا الإعداد ، فتأكد من قراءة الفقرة التالية!
انتحال بيانات اللاعب
تحتوي جميع نوى الخادم تقريبًا التي تحظر الاتصال المباشر بالخادم (بما في ذلك Spigot) على ثغرة أمنية نشطة تتعلق باستبدال بيانات اللاعب من خلال خادم BungeeCord الخاص بهم: يضع اللاعب خادم الوكيل الخاص به مع إعادة توجيه الاتصالات إلى خادم اللعبة الرئيسي ، وبالتالي فإن النواة يقرر خادم اللعبة أن BungeeCord يُستخدم للاتصال ويثق في جميع البيانات المرسلة منه (لم يتم التحقق من تطابق IP للخادم مع عنوان IP للخادم في هذه الحالة)
كيف هذا يهددنا؟
في أغلب الأحيان ، يتم استبدال ما يلي بهذه الطريقة: IP الخاص باللاعب (تجاوز الجلسات والوصول إلى حساب شخص آخر) و UUID (تستخدمه بعض المكونات الإضافية والخادم نفسه لتحديد اللاعب ، وتجاوز التحكم في الحقوق والوصول إلى حقوق اللاعبين الآخرين).
عند استخدام BungeeCord ، تحتاج إلى إصلاحه بنفسك ، وإلا فقد يسمح للمهاجم بالوصول ليس فقط إلى حسابات اللاعب ، ولكن أيضًا إلى قدرات المسؤولين!
كيف تمنع؟
أسهل طريقة لمنع ذلك هي إغلاق المنافذ غير الضرورية لاتصالات الطرف الثالث ، و => أي احتمال للاتصال بالخادم يتجاوز الخادم الوكيل.
يوصى بإغلاق جميع منافذ جميع الخوادم للاتصال الخارجي باستثناء خادم BungeeCord الرئيسي!
خوادم اللعبة
خوادم اللعبة بأوضاعها الخاصة. كل ما سبق له صلة بالموضوع.