بوابة VPN لديك مخترقة: ما الذي يتعرّض فعلاً للكشف
البوابة المخترقة ترى داخل نفقها، لكن هذا لا يعني امتلاك كل جلسة. افصل بين حركة المرور والوصول والأسرار المخزّنة قبل الاستعادة.
تقع بوابة VPN في نهاية النفق الذي تحميه، أي أنها تنهي ذلك التشفير بدلاً من تمريره. إذا سيطر مهاجم على المضيف، يستمر النفق في الظهور بصحة جيدة من الخارج بينما لم تعد الآلة الموجودة في المنتصف موثوقة. السؤال المفيد ليس ما إذا كان كل شيء مفكوك التشفير. بل ما الذي كان بإمكان ذلك المضيف رؤيته، وما الذي كان بإمكانه الوصول إليه، وأي الأسرار كانت مخزّنة عليه فعلاً. هذه الإجابات الثلاث تختلف كثيراً، وتختلف الاستجابة معها.
البوابة تنهي النفق، لذلك ترى ما بداخله
التشفير في VPN يتم قفزةً بقفزة، والبوابة هي القفزة. فهي تزيل الطبقة الخارجية، وتطبّق السياسة، وتُمرّر الحزمة الداخلية، لذا توجد كل حزمة محمولة في شكل قابل للقراءة في ذاكرة ذلك المضيف في مرحلة ما. هذا هو التصميم وليس عيباً. وهو أيضاً سبب أن اختراق البوابة حدث مختلف عن اختراق تشفير النفق.
ما يحصل عليه المهاجم أولاً هو الموقع: القدرة على مراقبة حركة المرور المحمولة، أو تغيير إعادة التوجيه، أو الرد بدلاً من نظام خلفي. وما يحصل عليه بعد ذلك يعتمد على المضيف، وهنا يبالغ الناس. الوصول إلى البوابة وحده لا يمنح مفاتيح جلسة TLS الخاصة بالمتصفح، لأنها لم تكن على البوابة يوماً.
ثلاثة تعرّضات ليست بالحجم نفسه
قسّم السؤال إلى حركة المرور المحمولة، والأنظمة التي يمكن الوصول إليها، والأسرار المخزّنة، ثم أجب عن كل منها على حدة.
| Exposure | What the attacker gains | What does not follow |
|---|---|---|
| Carried traffic | Plaintext of whatever the tunnel forwards without its own encryption | Keys for TLS sessions that terminate at the application |
| Reachable systems | Whatever the backends accept from the gateway's address | Control of every connected client endpoint |
| Stored secrets | The specific keys, tokens and accounts present on that host | Possession of every client certificate or of a CA key |
الصف الأوسط هو الذي يُتجاهل. عادةً ما يكون للبوابة مسار إلى الشبكات الخاصة وعنوان مصدر تثق به الأنظمة الخلفية مسبقاً، لذا فالسؤال المثير للانتباه هو ما تسمح به تلك الأنظمة الخلفية من ذلك العنوان. سياسة ضيّقة للوصول من العملاء تحكّم جيد، لكن المهاجم الموجود على المضيف ليس محدوداً بالواجهة التي يستخدمها عميل عادي.
الصف الأسفل يحدّد مدة استمرار الحادث. مفتاح خادم ومفتاح CA لهما نطاقان مختلفان تماماً، وكذلك حساب مسؤول محلي ورمز مراقبة للقراءة فقط.
HTTPS داخل النفق يبقى HTTPS
تشفير TLS للتطبيق ينتهي عند التطبيق، وليس عند بوابة VPN، لذا ترى البوابة المخترقة نصاً مشفّراً لتلك التدفقات. هذا حدّ حقيقي لما يحصل عليه المهاجم، ويستحق القول بوضوح، لأن الادعاء المعاكس ينشر الذعر والقرارات السيئة. هناك شرطان يبطلان ذلك. إذا كان في المسار مكوّن فحص يحمل شهادة موثوقة، فقد ترى البوابة نصاً صريحاً بحسب التصميم. وإذا كانت نقطة نهاية التطبيق نفسها مخترقة، فالنفق غير ذي صلة.
لذا فالإجابة عن ما رأوه مشروطة، وينبغي تدوينها كشروط بدلاً من الإعلان عنها كحكم.
ما الذي يجب أن يتغيّر قبل أن تثق بها مجدداً
إعادة بناء المضيف ضرورية ونادراً ما تكون كافية. المهاجم الذي لا يزال يحمل حساب إدارة أو بيانات اعتماد نشر أو مفتاح توقيع يمكنه إعادة المضيف كما يشاء. يجب أن يبدأ التعافي من مسار إدارة لا يعتمد على الجهاز المخترق.
احصر ما كان عليه قبل أن تقرّر ما ستدوّره. المفاتيح وحسابات الخدمة ورموز API والمستخدمون المحليون والمهام المجدولة وعلاقات الثقة وخط النشر كلها مرشحة، ولكل منها مالك ينبغي أن يؤكدها.
ss -lntup
getent passwd
crontab -l
ip route show table allتلك القائمة هي أسرع طريقة لمعرفة ما كان المضيف يقدّمه وإلى أين يمكنه الوصول. احفظ الأدلة أولاً، وفق إجراء مالك الاستجابة، لأن إعادة البناء تدمّر بالضبط ما يحتاجه التحقيق. يعامل NIST SP 800-61 المراجعة 3 التحضير والكشف والاستجابة والتعافي كأجزاء من عملية مخاطر واحدة لا كتعليمات إعادة تشغيل.
حدود تجعل الحادث التالي أرخص
هناك أربعة حدود تستحق البناء قبل أن تحتاج إليها. احتفظ بمسار تعافٍ مستقل لا يصادق عبر البوابة. أبقِ سلطة التوقيع منفصلة عن المضيف الذي يخدم حركة المرور. حدّد ما يمكن للبوابة الوصول إليه، بحيث لا تكون بوابة مخترقة بالضرورة شبكة إدارة مخترقة. وسجّل من يملك كل بيانات اعتماد، حتى يكون التدوير مكالمة هاتفية بدل مشروع تنقيب أثري.
لا شيء من هذا يمنع الاختراق. إنه يحدّ منه، ويصنع الفرق بين أسبوع سيئ وربع سيئ.