يُستخدم توجيه المنافذ Port Forwarding للسماح بالوصول إلى جهاز أو خدمة داخل الشبكة المنزلية من خارجها، وهو إعداد مفيد في بعض الحالات مثل تشغيل خادم منزلي أو الوصول إلى خدمة معينة عن بُعد. لكن فتح منفذ على الراوتر يعني أيضًا إنشاء نقطة دخول يمكن الوصول إليها من الإنترنت.
تكمن المشكلة في أن الجهاز أو الخدمة التي أصبحت متاحة عبر الإنترنت قد تحتوي على ثغرات أمنية أو إعدادات ضعيفة، ما يزيد مساحة الهجوم على الشبكة. وحتى عندما يكون الهدف مشروعًا، فإن ترك المنافذ مفتوحة دون الحاجة إليها أو دون حماية مناسبة قد يحول إعدادًا بسيطًا إلى مخاطرة أمنية حقيقية.
لذلك، من المهم فهم مخاطر توجيه المنافذ وكيف يمكن للمستخدم اكتشاف المنافذ المكشوفة وتقليل احتمالات استغلالها. ولا يعني ذلك أن Port Forwarding غير آمن دائمًا، بل إن مستوى الخطر يعتمد على ما يتم كشفه للإنترنت وكيفية تأمين الخدمة والجهاز المستهدف.
لستُ متخصصاً في اختبار الاختراق الهجومي (Red Teaming) أو باحثاً أمنياً، لكن خلفيتي المهنية تتركز في هندسة النظم وممارسات DevOps؛ لذا أقضي وقتاً طويلاً في التعامل مع أنظمة Linux، والشبكات، وجدران الحماية، وتقنيات المحاكاة الافتراضية (Virtualization)، وأمن البنية التحتية. وكنتُ على دراية مسبقة بقواعد الأمان البديهية.
كان هدفي هو التحقق مما إذا كانت شبكتي الفعلية لا تزال تطابق الصورة الذهنية التي لدي عنها. فقد كانت لدي عدة قواعد لتوجيه المنافذ (port-forwarding) على جهاز التوجيه (الراوتر) لخدمات كنت أحتاج للوصول إليها عن بُعد من حين لآخر. كنت أعرف الغرض من معظم تلك القواعد، واعتبرتُ أن الإعدادات خاضعة لسيطرة معقولة. ولكن، عند إجراء فحص لعنوان IP العام الخاص بي من خارج الشبكة، اكتشفتُ وجود بعض الخدمات التي كنت قد نسيت أمرها تماماً.
كشفت لي أداة Nmap تفاصيل أكثر مما توقعت.
وعثرتُ على خدمات لم أعد أستخدمها.
بدأتُ بإجراء فحص مباشر باستخدام أداة Nmap على عنوان IP العام الخاص بي. كانت المنافذ المفتوحة الأولى مطابقة تماماً لما توقعته، إذ تعرفتُ على الخدمات المرتبطة بها وأدركتُ سبب كونها مكشوفة. لكن Nmap بدأ بعد ذلك في العثور على منافذ لم ألتفت إليها منذ فترة طويلة جداً، وكان عددها لا بأس به؛ ومن بينها منفذ خدمة MinIO (المنفذ 9000). ونظراً لأنني توقفت عن استخدام MinIO وانتقلت إلى SeaweedFS، فقد كان ذلك النشر للخدمة مهجوراً فعلياً.
لقد نسيت الأمر ببساطة؛ إذ كانت الخدمة لا تزال قيد التشغيل، وقاعدة إعادة التوجيه لا تزال نشطة. وكان هذا بالضبط نوع الأمور التي أردت أن يكشفها الفحص الخارجي. كنت أعرف الخدمات التي أتحت الوصول إليها عمداً، لكنني لم أحتفظ بسجل ذهني دقيق للتجارب والخدمات القديمة التي توقفت عن استخدامها. ومن السهل جداً إغفال مثل هذه الأمور في بيئة المختبر المنزلي (homelab)؛ فأنت تتذكر ما تستخدمه فعلياً وما تقوم بصيانته حالياً، بينما يسهل كثيراً تجاهل خدمة منسية تعود لتجربة أجريتها قبل أشهر.
بعد تحديد المنافذ غير المتوقعة، استخدمت ميزة الكشف عن الخدمات في أداة Nmap لمعرفة ما الذي كان يعمل فعلياً خلف تلك المنافذ.
منحني ذلك صورة أوضح بكثير عما يمكن لنظام خارجي رصده دون الحاجة إلى مصادقة؛ إذ تمكنت من رؤية البروتوكولات المتاحة، وتحديد التطبيقات المرتبطة بالخدمات في الحالات التي كشفت فيها تلك الخدمات عن معلومات كافية. عند تلك النقطة، توقفت عن النظر إلى نتائج الفحص باعتبارها مجرد قائمة بقواعد إعادة توجيه منسية، وبدأت في فحص كل خدمة مكشوفة على حدة. وهنا ظهرت النتائج الأكثر إثارة للاهتمام.
بدأت في فحص التطبيقات المكشوفة.
كان المنفذ 5000 يعاني من مشكلة كنت قد أغفلتها.
كانت إحدى الخدمات التي فحصتها تعمل على المنفذ 5000. كان تطبيق Flask مألوفاً بالنسبة لي، وربما كان ذلك أحد الأسباب التي جعلتني أغفل عنه في المقام الأول. قمت بفتح الخدمة من خارج الشبكة ووجدت أنها لا تزال تعرض صفحة تسجيل الدخول عبر بروتوكول HTTP، دون وجود أي إعادة توجيه إلى HTTPS. بعد ذلك، استخدمت أداة curl لفحص الصفحة وعثرت على ما يلي في كود HTML:
<input type=”hidden” id=”prefer_https” name=”prefer_https” value=”false”>
كان التطبيق مُعدّاً صراحةً بحيث لا يُفضّل استخدام بروتوكول HTTPS؛ وهذا يعني أن أي شخص يُجري عملية المصادقة عبر نقطة نهاية HTTP سيرسل بيانات اعتماده دون تشفير أثناء النقل. وبالتالي، كان بإمكان أي مهاجم يراقب حركة البيانات تلك أن يستولي على بيانات الاعتماد هذه.
لم تكن المشكلة ثغرة أمنية معقدة أو نادرة، بل كانت مجرد تفصيل بسيط في الإعدادات ظل قائماً لأن الخدمة كانت تعمل بشكل طبيعي. فمن داخل شبكتي، لم تكن هناك أسباب تدعوني للتفكير في هذا الأمر، لكن الوضع كان يبدو مختلفاً تماماً عند النظر إليه من شبكة الإنترنت.
كلما تعمقت في البحث، اتضحت المشكلة الكامنة أكثر فأكثر. لم تكن الخدمات الفردية بحد ذاتها كارثية، بل كانت المشكلة الأكبر تكمن في أن بعضها لم يعد ينبغي أن يكون متاحاً للعامة. لقد قمت بإعداد قواعد إعادة التوجيه (forwarding rules) لأسباب مشروعة؛ فبعضها كان مخصصاً للتجارب، وبعضها الآخر للوصول عن بُعد بشكل مؤقت، بينما ظلّت مجموعة منها قائمة لمجرد أن إزالتها لم تكن أمراً ملحاً في أي وقت مضى.
لا تضمن الخبرة الحماية من “انحراف الإعدادات” (configuration drift)؛ فقد كنت مدركاً تماماً لما أفعله عند إنشاء قواعد إعادة التوجيه تلك، كما كنت أعلم المخاطر المرتبطة بإتاحة الخدمات للوصول الخارجي. لكن ما لم أكن أعلمه هو أن بعض تلك القرارات القديمة كانت لا تزال سارية المفعول. ولهذا السبب تبرز أهمية الحصول على منظور خارجي؛ إذ يتيح ذلك اختبار البيئة كما هي موجودة بالفعل، وليس كما أتذكر أنني قمت بإعدادها.
لقد أتاحت لي أداة Headscale وسيلةً للحد من نطاق الإتاحة (exposure)؛
إذ لم أكن بحاجة سوى إلى الوصول عن بُعد لبعض هذه الخدمات فقط.
بعد الانتهاء من فحص الخدمات المكشوفة، بدأت أتساءل عما إذا كان من الضروري حقاً أن تكون أي منها متاحة للعامة؛ وكانت الإجابة “لا” بالنسبة للعديد منها. ونظراً لأنني أستخدم بالفعل Headscale لشبكتي الخاصة، فقد تمكنت من حل هذه المسألة دون الحاجة إلى كشف كل تطبيق عبر جهاز التوجيه (الراوتر). لذا، قمت بتنظيف الخدمات القديمة، وإزالة قواعد إعادة توجيه المنافذ (port forwarding) التي لم تعد ضرورية، ونقلت الخدمات الخاصة لتصبح ضمن نطاق شبكة Headscale الخاصة بي.
توقف عن استخدام إعادة توجيه المنافذ (Port Forwarding) للوصول إلى وحدة تخزين الشبكة (NAS): إليك الطريقة الأكثر أماناً للوصول إلى الملفات عن بُعد.
أدى ذلك إلى تقليل عدد التطبيقات المكشوفة مباشرةً للإنترنت مع الحفاظ على إمكانية الوصول عن بُعد التي كنت أحتاج إليها فعلياً. لقد أبقيتُ على الإتاحة العامة فقط في الحالات التي استدعت ذلك لسبب وجيه، وأصبحت القواعد الآن أسهل بكثير من حيث التتبع والإدارة؛ إذ بات بإمكاني تبرير وجود كل منفذ عام متبقٍ. لقد كان هذا وضعاً أفضل بكثير مقارنةً بمجرد العلم بوجود تلك المنافذ وحسب.
لا ينبغي أن تخشى استخدام خاصية “توجيه المنافذ” (Port Forwarding)
إن توجيه المنافذ ليس غير آمن بطبيعته؛ فهناك أسباب مشروعة عديدة لجعل خدمة ما متاحة للعموم. تكمن المشكلة في أن إنشاء قاعدة لتوجيه المنافذ أمر سهل، وكذلك نسيانها أمر وارد جداً. وتُعد نسخة MinIO التي كانت تعمل على المنفذ 9000 مثالاً نموذجياً على ذلك؛ فقد توقفت عن استخدام MinIO قبل أشهر، إلا أن الخدمة وقاعدة التوجيه الخاصة بها ظلتا موجودتين بانتظار من يكتشفهما. وهذا النوع من الأمور قد يغيب حتى عن بال مسؤولي الأنظمة ذوي الخبرة. والآن، قمت بإعداد اختبار خارجي دوري لشبكتي للتأكد من أن “مساحة الهجوم” (attack surface) المتاحة للعامة تتطابق فعلياً مع ما أعتقده. ورغم أن هذا الإجراء يُعد إضافة بسيطة لروتين الصيانة الخاص بي، إلا أنه يمنحني شيئاً لا توفره ملفات الإعدادات: نظرة مستقلة عما يمكن للإنترنت الوصول إليه فعلياً.
يمكن أن يكون توجيه المنافذ مفيدًا للوصول إلى خدمات محددة من خارج الشبكة، لكنه يزيد في المقابل من تعرض تلك الخدمات للإنترنت. لذلك، فإن فتح منفذ دون معرفة الخدمة التي يستهدفها أو طريقة تأمينها قد يخلق ثغرة غير ضرورية.
إذا كنت لا تحتاج إلى منفذ مفتوح، فمن الأفضل إغلاقه. أما عند الحاجة إلى Port Forwarding، فاستخدم أقل قدر ممكن من الوصول، وحافظ على تحديث الجهاز والخدمة، وراجع إعدادات الراوتر دوريًا للتأكد من عدم وجود منافذ مكشوفة دون داعٍ.
