إضافة قاعدة سماح لـ RDP لا تضيّق وصولك عبر VPN

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

القاعدة التي تضيفها ليست القاعدة المهمة

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

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

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

اكتشف أي عنوان يراه الخادم

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

إذا كانت بوابة VPN تحافظ على عناوين العملاء، يرى الخادم عنوان النفق الخاص بالعميل، وتكون قاعدة محددة بالعنوان ذات معنى. وإذا كانت البوابة تترجم العناوين، يصل كل عميل بعنوان البوابة، وتقييد القاعدة بذلك العنوان يمنح الوصول لكل عميل خلفها. وعندئذ تكون القاعدة دقيقة في الشيء الخطأ.

يحتاج هذان التصميمان إلى إجابتين مختلفتين. يمكن التعبير عن الأول في قاعدة جدار حماية؛ أما الثاني فيجب فرضه حيث تبقى الهوية موجودة، أي في VPN نفسه أو في بوابة موثّقة أمام الخدمة.

لا يستطيع مرشّح جدار الحماية استعادة هوية أسقطتها ترجمة العناوين، مهما كُتب العنوان بعناية.

غيّر مالك القاعدة الفعلية

افحص سياسة الدخول الفعلية واعثر على كل قاعدة تسمح حاليًا بحركة RDP، بما في ذلك القواعد التي لا يذكر اسمها الظاهر المنفذ 3389. وتُحتسب أيضًا القواعد المحددة بالخدمة أو بالتطبيق، وكذلك نقل UDP الذي تفعّله بعض عمليات نشر RDP.

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

تعثر هذه الأوامر على القواعد النشطة، وتعرض مرشّح العناوين المرتبط بإحداها، وتعاين تغييرًا في النطاق:

Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound | Where-Object DisplayName -match RDP
Get-NetFirewallAddressFilter -AssociatedNetFirewallRule (Get-NetFirewallRule -Name Reviewed-RDP-TCP)
Set-NetFirewallRule -Name Reviewed-RDP-TCP -RemoteAddress 10.63.4.17 -WhatIf

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

الحجب ثم السماح نموذج مختلف

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

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

أثبته بمصدر ثانٍ

اختبر من العميل المسموح به ومن مصدر ينبغي أن يفشل الآن. فاتصال ناجح واحد يثبت فقط أن المسار المسموح يعمل؛ ولا يقول شيئًا عن الاستبعاد الذي أجريته للتو.

أعد الاختبار عبر IPv6 إذا كان الخادم يفعّله، لأن نية خاصة بـ IPv4 وحدها يمكن أن تتعايش مع سماح واسع لـ IPv6 لم ينظر إليه أحد.

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