موازن تحميل داخلي باسم DNS عام: هل هو مكشوف فعلاً؟

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

الخطوة الأولى: اقرأ المخطط، لا عنوان IP

حقل المخطط هو إفادة موازن التحميل نفسه عن حدوده. يعيد aws elbv2 describe-load-balancers --names app-internal قيمة Scheme إما internal أو internet-facing، مع نوع عنوان لـ IPv4 أو حزمة مزدوجة. يمكن لموازن تحميل مواجه للإنترنت أن يمرّر إلى أهداف خاصة، لذا فإن رؤية عناوين خلفية خاصة لا تثبت شيئاً عن الواجهة الأمامية.

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

الخطوة الثانية: انظر إلى ما يحلّ إليه الاسم

استعلم من خارج VPC باستخدام dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com ولاحظ ما إذا كانت الإجابات ضمن 10.0.0.0/8 أو 172.16.0.0/12 أو 192.168.0.0/16. الإجابة الخاصة من خادم تحليل عام هي السلوك المتوقع لاسم موازن تحميل داخلي؛ وليست دليلاً على أن العنوان قابل للتوجيه من الإنترنت.

حلّل الاسم نفسه من داخل VPC وقارن. إذا اختلفت الإجابتان فأنت أمام تسمية منقسمة الأفق، وذلك الاختلاف تفصيل تصميمي وليس تسريباً.

الخطوة الثالثة: اسرد المسارات التي يمكنها الوصول إليه

العنوان الخاص يمكن الوصول إليه من أي مكان يوجد فيه مسار وقاعدة أمان. أحصِ تلك المسارات عمداً: VPN من موقع إلى موقع، وVPN للعملاء، واقتران VPC، ومرفقات بوابة العبور، وDirect Connect، وأي وكيل أو حصن داخل VPC. أحدها هو المسار المقصود، والباقي هو ما سيبحث عنه المهاجم.

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

الخطوة الرابعة: اختبر المستمع والتطبيق كل على حدة

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

المستمع القابل للوصول ليس هو التطبيق المتاح. افحص شهادة TLS وسياسة البروتوكول، ثم مصادقة التطبيق وتفويضه. أداة داخلية تقبل أي متصل على VPN المؤسسة تكون مكشوفة لكل حاسوب مخترق على تلك VPN، وهو خطر مختلف عن الخطر المواجه للإنترنت لكنه يبقى خطراً.

تذكّر أن الضوابط تختلف حسب النوع. جدران الحماية على طبقة التطبيق ترتبط بعائلة موازنات تحميل واحدة دون الأخرى، لذا تأكد مما هو متاح فعلاً للمخطط والنوع أمامك بدلاً من افتراض التكافؤ.

الخطوة الخامسة: قرّر ما إذا كان الاسم نفسه مهماً

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

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

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