الفصل : 9
الجزء : 3
العنوان : تصلب والأمن (Hardening and Security)
ال Advanced Threat Analytics – نهاية الدعم
برأيي، واحدة من أروع ميزات الأمان التي ظهرت في Microsoft هي Advanced Threat Analytics (ATA)، ومع ذلك نادرًا ما سمعت أي شخص يتحدث عنها. ربما لأنها لم تُضف كميزة أصلية مدمجة في نظام Windows Server OS. ال ATA هو برنامج محلي يعمل على نظام Windows لإنتاج وظائف مذهلة. أساسًا، ما يقوم به ATA هو مراقبة جميع حركة المرور في Active Directory وتحذيرك من السلوك الخطير أو غير العادي في الوقت الفعلي، فور حدوثه.
للأسف، وصل ATA إلى نهاية الدعم الأساسي في يناير 2021. سيستمر الدعم الموسع حتى عام 2026، لذلك اخترت الاحتفاظ بالمعلومات في هذا الإصدار الأخير من الكتاب لأن هذه التقنية لا تزال صالحة وستستمر في الوجود في البيئات حيث تم تثبيتها لسنوات قادمة. \
ما هو (كان) ATA؟
فكرة ATA بسيطة للغاية ومفهومة جدًا بحيث أننا جميعًا سنتساءل لماذا استغرق الأمر سنوات عديدة لكي يتوصل شخص ما إلى هذه الفكرة. لقد كان Active Directory موجودًا منذ فترة طويلة، وكانت الهجمات على بيئتك باستخدام حسابات المستخدمين موجودة منذ ذلك الحين. اكتشاف ومعالجة الهجمات داخل الدليل معقد وفوضوي؛ هناك الكثير من المعلومات التي يتم تسجيلها طوال الوقت داخل AD مما يجعل من المستحيل تقريبًا القبض على الأشرار أثناء تنفيذ هجماتهم. بعد نوع من الهجوم، يمكنك بالتأكيد التحقق من بيانات السجلات من وحدات تحكم النطاق المتعددة وتجميع بعض التفاصيل حول ما حدث، لكن القدرة على التعرف على ذلك أثناء حدوثه كانت مجرد حلم بعيد. أو ربما لا؟
ال ATA هو شكل متقدم من مراقبة Active Directory يستخدم التعلم الآلي. هذه هي الجزء الأروع من ATA. تقوم بتكوين شبكتك بحيث تصل كل حركة المرور الداخلة أو الخارجة من وحدات تحكم النطاق إلى نظام ATA أيضًا. الطريقة الأكثر أمانًا لتحقيق ذلك هي على مستوى الشبكة، من خلال إعداد port mirroring بحيث تصل جميع حزم وحدات تحكم النطاق إلى ATA أيضًا، ولكن بطريقة لا يستطيع المهاجم رؤيتها.
بهذه الطريقة، حتى إذا كان هناك شخص سيء داخل شبكتك ويبحث عن نوع من الحماية ضدهم، يظل ATA غير مرئي لأعينهم المتطفلة. ومع ذلك، قد يكون port-mirroring لتلك الحركة شيئًا لا تستطيع الشركات الصغيرة القيام به أو قد يكون معقدًا للغاية للإعداد الأولي، لذلك توجد خيار ثانٍ لتثبيت وكيل ATA خفيف الوزن مباشرة على وحدات تحكم النطاق نفسها. يقوم هذا الوكيل بعد ذلك بإرسال المعلومات الضرورية إلى خوادم معالجة ATA.
في كلتا الحالتين، تتلقى خوادم معالجة ATA جميع هذه البيانات وتبدأ في العثور على الأنماط. إذا كانت Betty تستخدم كمبيوتر مكتبي يسمى BETTY-PC وجهاز لوحي يسمى BETTY-TABLET، سيرى ATA هذا النمط ويربط حساب المستخدم الخاص بها بهذه الأجهزة. كما يراقب أنماط حركتها العادية. عادةً ما تسجل Betty الدخول حوالي الساعة 8 صباحًا وتتوقف حركتها عادةً حوالي الساعة 5 مساءً. عادةً ما تصل إلى عدد قليل من خوادم الملفات وخادم SharePoint. بعد أسبوع أو نحو ذلك من جمع ومراقبة البيانات، يكون لدى ATA فكرة جيدة جدًا عن الأنماط العادية لـ Betty.
الآن، في ليلة ما، يحدث شيء ما. يرى ATA عددًا كبيرًا من فشل كلمات المرور ضد حساب Betty. قد لا يكون هذا في حد ذاته شيئًا يدعو للقلق، ولكن فجأة تسجل Betty الدخول إلى خادم طرفي لا تصل إليه عادةً. من هناك، تُستخدم بيانات اعتمادها للوصول إلى وحدة تحكم النطاق. يا للهول، هذا يبدو بوضوح وكأنه هجوم بالنسبة لي. مع الأدوات المدمجة في Active Directory التي لدينا حاليًا تحت تصرفنا، ماذا نعرف؟ لا شيء في الواقع. قد نرى فشل كلمات المرور إذا بحثنا في سجلات الأحداث، وبناءً على ذلك، يمكننا محاولة التحقق من سجلات أحداث الخوادم الأخرى لمعرفة ما كان هذا الحساب يصل إليه، ولكن لن يكون لدينا أي سبب للاشتباه في أي شيء، ولا أي تحذيرات أو تنبيهات بأن شيئًا ما يحدث. قد يكون هذا بداية لخرق كبير جدًا، ولن نراه أبدًا. لحسن الحظ، يعرف ATA أفضل.
واجهة الإدارة لـ ATA تشبه موجز الوسائط الاجتماعية، يتم تحديثها تقريبًا في الوقت الفعلي. خلال الأحداث التي وضعتها للتو، إذا كنا ننظر إلى موجز الوسائط الاجتماعية الخاص بـ ATA، كنا سنرى كل هذه العناصر تحدث، كما حدثت، وكان سيكون واضحًا فورًا أن شخصًا ما اخترق حساب Betty واستخدمه للوصول إلى وحدة تحكم النطاق. لم يكن هناك أي تقنية من قبل تراقب حركة المرور في Active Directory بهذه الكثافة، ولم يكن هناك بالتأكيد أي شيء يتعلم الأنماط والانحرافات السلوكية مثل هذا. إنها تقنية مذهلة حقًا، ولا أقول ذلك فقط لأنني أعرف الأشخاص الذين بنوها. ولكن نظرًا لأنني أعرفهم، يمكنني أن أخبرك أنهم أذكياء جدًا، وهو ما يظهر بوضوح لأن مايكروسوفت التقطتهم.
على الرغم من أن هذه التقنية تتحول الآن إلى شيء على مستوى السحابة، دعونا نأخذ بضع دقائق ونراجع بعض لقطات الشاشة من واجهة ATA حتى يكون لديك فكرة عن شكل هذا الموجز على نمط وسائل التواصل الاجتماعي. تم أخذ هذه اللقطة من عرض توضيحي لـ Microsoft حيث سرقوا عمدًا تذكرة Kerberos من مستخدم، ثم استخدموها على جهاز كمبيوتر آخر للوصول إلى بعض الملفات السرية التي كان يجب أن يكون بإمكان Demi Albuz الوصول إليها فقط. بينما لم يمنع ATA هذا النشاط، إلا أنه تنبه فورًا - وأعني في غضون ثوانٍ - داخل هذا الموجز لإظهار هجوم Pass-the-Ticket:
إليك مثال آخر حيث وصل مستخدم يسمى Almeta Whitfield فجأة إلى 16 جهاز كمبيوتر لا تصل إليها عادةً، وهو علامة حمراء كبيرة أخرى على أن شيئًا ما يحدث مع حساب المستخدم الخاص بها:
ال Microsoft Defender for Identity
بينما تعتبر ATA حلاً محلياً، فإن بديلها يوجد في السحابة. Microsoft Defender for Identity هو منزلنا الجديد لهذا النوع من التكنولوجيا، حيث يستضيف بالطبع في بيئات Microsoft Azure وM365. لم يكن Defender for Identity دائمًا يحمل هذا الاسم، وستجد بعض الوثائق المتعلقة بهذه التكنولوجيا تحت اسم Azure Advanced Threat Protection، وهو الاسم الذي كان مخصصًا ليكون البديل المباشر لـ ATA قبل أن تندرج هذه القدرات تحت مظلة Defender.
ما زالت الوثائق متاحة عبر الإنترنت لـ ATA، ويمكن العثور على مواد تعليمية إضافية هنا: https://docs.microsoft.com/en-us/advanced-threat-analytics/what-is-ata.
لمزيد من المعلومات حول Microsoft Defender for Identity الجديد، فإن الرابط التالي يعد نقطة انطلاق جيدة: https://learn.microsoft.com/en-us/defender-for-identity/.
ممارسات الأمان العامة
أحيانًا نحتاج إلى الاعتماد على أنفسنا فقط، وليس بالضرورة على الوظائف التي يوفرها نظام التشغيل، لتأمين أنظمتنا. هناك العديد من النهج المنطقية للإدارة (من الممتع أن أكون خلف هذا الكيبورد: أستطيع اختراع كلمات جديدة طوال اليوم) التي يسهل تنفيذها ولكن نادرًا ما تستخدم في الميدان.
التخلص من المديرين الدائمين
هل يمتلك جميع موظفي تقنية المعلومات لديك حقوق domain admin في اليوم الذي يتم تعيينهم فيه؟ هل يمتلك أي من موظفي تقنية المعلومات لديك كلمة مرور حساب domain administrator المدمج؟ هل لديك مستخدمون عاديون يمتلكون حقوق إدارية على أجهزتهم الخاصة؟ تعرف إلى أين أذهب بهذا - كل هذه أفكار سيئة!
لسوء الحظ، كان هذا الوضع القائم لسنوات عديدة في كل شبكة تقريبًا، وما زال الاتجاه مستمرًا حتى اليوم. ما زلت أشاهد المهندسين بانتظام يستخدمون حساب domain administrator للعديد من المهام عند إعداد خوادم جديدة. وهذا يعني أنهم لا يمتلكون فقط الوصول إلى الحساب الأكثر أهمية في شبكتك ويستخدمونه للمهام اليومية، ولكنه يعني أيضًا أن أي شيء يتم إعداده بهذا الحساب غير قابل للمحاسبة. ماذا أعني بذلك؟ عندما أقوم بإعداد خادم جديد أو إجراء تغييرات على خادم موجود باستخدام حساب المدير العام، وإذا انتهى بي الأمر بإحداث مشكلة كبيرة، لا يمكن لأحد إثبات أنني فعلت ذلك. استخدام الحسابات العامة هو طريقة مؤكدة لإحباط المسؤولية في حال حدوث خطأ ما. أنا لا أحاول الإيحاء بأنك دائمًا تبحث عن "من فعلها"، ولكن إذا أخطأت في شيء ما على خادم التطبيقات الذي لا أديره عادة، سيكون من الجيد إذا استطاع الأشخاص الذين يحاولون إصلاحه معرفة أنني فعلت ذلك وسؤالني عما فعلته حتى يتمكنوا من عكسه. هناك العديد من الأسباب التي تجعل استخدام حساب المدير المدمج محظورًا علينا جميعًا.
لمعالجة الجانب العميل، هل يحتاج المستخدمون لديك فعلاً إلى حقوق إدارية على أجهزة الكمبيوتر الخاصة بهم؟ حقاً؟ أعتقد أنه يمكنك العثور على طرق للتغلب على ذلك. تقليل حقوق المستخدمين العاديين إلى حقوق المستخدم أو حتى حقوق power user على أنظمتهم يمكن أن يكون له تأثير كبير على أمان تلك الأجهزة. يمنح الفيروسات وقتًا أكثر صعوبة في التثبيت إذا كان على المستخدم المرور عبر مطالبة تطلب حقوق إدارية قبل أن يتمكنوا من متابعة التثبيت. كما أنه يحافظ على سلوكيات أجهزتك أكثر اتساقًا، دون إدخال تطبيقات وإعدادات جديدة وغير معروفة من قبل المستخدم.
استخدام حسابات منفصلة للوصول الإداري
هذه الفكرة تتماشى مع الفكرة السابقة وهي شيء بدأت في تطبيقه حتى على جميع أجهزة الكمبيوتر المنزلية التي أقوم بتثبيتها للأصدقاء وأفراد العائلة. الأمر يتلخص في هذا: استخدم حسابي مستخدم مختلفين. واحد بصلاحيات إدارية وآخر بدونها. عندما تكون مسجلًا للدخول للقيام بالمهام اليومية والأعمال الروتينية، تأكد من أنك مسجل الدخول بحساب المستخدم العادي الذي لا يمتلك حقوق إدارية، سواء على الكمبيوتر المحلي أو على النطاق. بهذه الطريقة، إذا حاولت تثبيت أي شيء، أو إذا حاول شيء ما تثبيت نفسه، فستظهر لك نافذة User Account Control (UAC) تطلب منك إدخال اسم المستخدم وكلمة المرور الإداريين قبل السماح للمثبت بالقيام بأي شيء. أستطيع أن أقول لك أن هذا يعمل، حيث أوقفت عددًا من الفيروسات و/أو برامج bloatware على جهاز الكمبيوتر الخاص بي من تثبيت نفسها أثناء تصفحي للإنترنت لمحاولة البحث عن مشروع أو آخر. إذا تلقيت مطالبة UAC تطلب مني كلمة مرور المسؤول ولم أقم بالنقر عمدًا على ملف المثبت، أعرف أنه شيء لا أريده. كل ما علي فعله هو النقر على "لا"، ولن يتمكن المثبت من الاستيلاء على جهاز الكمبيوتر الخاص بي. من ناحية أخرى، إذا كان شيئًا أنوي تثبيته، فإنها مجرد إزعاج بسيط لإدخال كلمة المرور لحسابي الإداري والسماح للمثبت بالمتابعة.
استخدام حسابات منفصلة يتيح لك العمل على معظم المهام اليومية وأنت مطمئن أنك لا تملك الحقوق للقيام بشيء خاطئ لنظامك بشكل غير مقصود. هذه العقلية تقلل أيضًا بشكل طبيعي من كمية النشاط أو التغييرات التي يتم إجراؤها على أي جهاز معين بواسطة حساب إداري، مما يجعل تسجيل وتتبع التغييرات بواسطة تلك الحسابات أسهل. هذا يؤدي إلى قدر أكبر من المساءلة وعمليات إدارة تغيير أفضل.
استخدام جهاز كمبيوتر مختلف لإتمام المهام الإدارية
إذا كنت تريد التقدم أكثر في فكرة حسابات المستخدم المنفصلة، يمكنك جعل تجربتك الحاسوبية أكثر أمانًا باستخدام جهاز كمبيوتر منفصل تمامًا عند القيام بالمهام الإدارية: جهاز كمبيوتر واحد للمهام اليومية وآخر للإدارة. سيساعد هذا بالتأكيد في الحفاظ على نظامك الإداري آمنًا، وكذلك الأنظمة البعيدة التي يمكنه الوصول إليها. وبينما يبدو الأمر مرهقًا إلى حد ما بوجود جهازين فعليين على مكتبك، تذكر أنه مع معظم إصدارات Windows 10، يمكننا تشغيل Hyper-V على أجهزة الكمبيوتر المكتبية لدينا.
أقوم بذلك بالضبط مع جهاز الكمبيوتر الخاص بي. لدي جهاز كمبيوتر يعمل بنظام Windows 10، ثم داخل هذا الكمبيوتر، أقوم بتشغيل جهاز افتراضي عبر Hyper-V حيث أقوم بجميع المهام الإدارية على الخوادم الحساسة. بهذه الطريقة، لا يعني تعرض نظام التشغيل اليومي الخاص بي للخطر تعرض البيئة بأكملها للخطر.
يمكنك أيضًا تطبيق هذه الفكرة بالعكس. عند الحاجة إلى اختبار برنامج جديد أو وظيفة جديدة أو رابط، يمكنك إنشاء جهاز افتراضي في Hyper-V على محطة العمل الخاصة بك، والحفاظ عليه منفصلًا تمامًا عن أي شبكات حتى يكون معزولًا، واختبار أي شيء جديد أو مشبوه تحتاج إلى اختباره. إذا أفسد جهازك الافتراضي، فلا مشكلة. فقط احذفه وأنشئ جهازًا جديدًا.
سواء اخترت تقسيم الوصول الإداري على مستوى حساب المستخدم أو مستوى الكمبيوتر، تذكر هذه القاعدة البسيطة: لا تدير Active Directory من نفس المكان الذي تتصفح فيه Facebook. أعتقد أن هذا يلخص الأمر جيدًا.
عدم تصفح الإنترنت من الخوادم
يبدو ذلك بديهيًا، لكن الجميع يفعل ذلك. نقضي طوال اليوم في العمل على الخوادم وغالبًا ما نحتاج إلى الوصول والتحقق من شيء ما من متصفح الويب. بما أن Edge وInternet Explorer موجودان على خوادم Windows، أحيانًا يكون من الأسرع والأسهل التحقق من أي شيء نحتاج إلى التحقق منه من وحدة تحكم الخادم حيث نعمل، بدلاً من العودة إلى مكاتبنا. أحيانًا (وربما في كثير من الأحيان) نتخذ الخطوة الإضافية، ونثبت بوعي متصفحًا مختلفًا وأفضل على الخوادم فقط ليكون هناك إذا احتجنا إليه في أي وقت. قاوم الإغراء! من السهل جدًا التقاط الأشياء السيئة من الإنترنت، خاصةً على الخوادم لأن الأجهزة في شبكتنا التي تعمل بدون حماية مضادة للفيروسات هي في الغالب على الجانب الخادم. نفس الشيء ينطبق على مرشحات الإنترنت. نحرص دائمًا على أن يتدفق حركة مرور العميل عبر الوكيل الخاص بالشركة (إذا كان لدينا واحد) أو آليات حماية أخرى، لكننا لا نهتم دائمًا بما إذا كانت حركة مرور الخادم تتحرك بنفس الطريقة.
لا تفعل ذلك حتى لمواقع الويب التي تثق بها. يمكن أن يؤدي هجوم man-in-the-middle أو اختراق الموقع نفسه إلى إفساد خادمك، أو الأسوأ من ذلك منح شخص ما الوصول إليه ومن ثم إلى بقية شبكتك. من الأسهل بكثير إعادة بناء جهاز عميل بدلاً من إعادة بناء خادم.
التحكم في الوصول بناءً على الأدوار (RBAC)
عبارة التحكم في الوصول بناءً على الأدوار (RBAC) ليست واحدة تقتصر على بيئات Microsoft. كما أنها ليست تقنية معينة يمكن استخدامها داخل Windows Server 2022، بل هي أيديولوجية تتعلق بفصل الأدوار والواجبات الوظيفية.
عندما نفكر في فصل الأدوار الوظيفية لموظفينا من منظور تكنولوجيا المعلومات، نفكر تقليديًا من حيث مجموعات Active Directory. بينما تحل إضافة حسابات المستخدمين إلى المجموعات العديد من المشكلات المتعلقة بتقسيم مستويات الأذونات والوصول، يمكن أن يكون الأمر معقدًا للنمو في
هذه العقلية، وفي النهاية ما زالت مجموعات AD تمكن المسؤولين من الوصول الكامل إلى المجموعات نفسها.
تقنيات RBAC تقسم الأدوار على مستوى مختلف، وتهتم بأكثر من الأذونات فقط. تركز RBAC أكثر على أوصاف الوظائف الوظيفية للموظفين بدلاً من قيود الوصول. هناك عدد من التقنيات المختلفة التي تستفيد من أدوات RBAC المدمجة فيها، وهناك حتى حلول RBAC من طرف ثالث تعمل على رأس جميع البنية التحتية الحالية الخاصة بك، مما يجعلها متاحة على نطاق واسع في جميع أنحاء مؤسستك وليس مقيدة بالعمل في نطاق أو غابة واحدة.
الإدارة بالمقدار الكافي فقط (JEA)
مثال رائع على تقنية RBAC المضمنة في Windows Server 2022 هو Just Enough Administration (JEA)، التي تعد جزءًا من PowerShell. توفر JEA طريقة لمنح وصول مميز خاص للأشخاص، دون الحاجة إلى منحهم حقوق إدارية، وهو ما كان مطلوبًا لتحقيق نفس المهام في الماضي. كانت الضرورة لإضافة شخص ما إلى مجموعة المسؤولين على الخادم حتى يتمكن من القيام بعمله شائعة جدًا، ولكن JEA هي الخطوة الأولى بعيدًا عن هذه الضرورة.
في طريقتنا القديمة في التفكير، قد يكون من السهل التفكير في JEA على أنها تفعل شيئًا مثل السماح للمستخدمين بالحصول على وصول إداري داخل PowerShell حتى عندما لا يمتلكون وصولًا إداريًا إلى نظام التشغيل نفسه، ولكنها أقوى من ذلك. تم تصميم JEA بحيث يمكنك السماح للمستخدمين بالوصول فقط لتشغيل أوامر PowerShell معينة وأدوات cmdlets على مستوى إداري، مع ترك الأوامر الأخرى التي لا يحتاجون إلى الوصول إليها في الظلام.
في الواقع، إذا كان المستخدم يعمل داخل سياق JEA لـ PowerShell وحاول استدعاء cmdlet ليس جزءًا من أدوات cmdlets المسموح بها، فإن PowerShell يتصرف كما لو أنه لا يتعرف حتى على تلك cmdlet. لا يقول: آسف، لا يمكنك فعل ذلك - إنه يتجاهل الأمر فقط! هذا بالتأكيد يساعد في إبقاء الأيدي المتطفلة بعيدة عن جرة الكوكيز، ما لم ترغب في السماح لهم بالدخول.
إليك سيناريو يساعد في تصوير قدرات JEA. ربما تكون مدير DNS، وقد تحتاج أحيانًا إلى إعادة تشغيل خدمات DNS. بما أننا نتبنى عقلية JEA/RBAC، لن تكون لديك حقوق إدارية على نظام التشغيل لخادم DNS، ولكن سيكون لديك حقوق مستندة إلى JEA داخل PowerShell حتى تتمكن من تشغيل الأدوات التي تحتاجها للقيام بعملك.
إعادة تشغيل خدمة DNS تتطلب الوصول لاستخدام cmdlet Restart-Service، صحيح؟ لكن أليس هذا يعني أنني سأتمكن من إعادة تشغيل أي خدمة على هذا الخادم ويمكنني القيام بأشياء كثيرة لا أحتاج إلى القيام بها؟ JEA قوية بما يكفي للتعامل مع هذا السيناريو. عند إعداد مستوى الوصول الذي يحتاجه المستخدم، يمكنك التعمق في أدوات cmdlets معينة وتقسيم الأذونات. في مثالنا، يمكنك تزويد مدير DNS بإمكانية استخدام cmdlet Restart-Service، ولكن فقط منح الأذونات لإعادة تشغيل خدمات معينة، مثل تلك المتعلقة بـ DNS. إذا حاول مديرك استخدام Restart-Service على WINrm، سيتم رفضه.
تغيير منفذ RDP بعيدًا عن 3389
أي مهندس IT يعرف كيفية استخدام RDP للاتصال بخوادم Windows، ومن المحتمل جدًا أن هذه هي الطريقة التي تستخدمها غالبًا عند التحكم في الخوادم عن بُعد في بيئتك. أي مخترق يستحق هذا اللقب يعرف أيضًا ذلك، ويعلم أن كل جهاز Windows، سواء كان محطة عمل للعميل أو خادمًا، يستمع افتراضيًا على المنفذ TCP 3389 لتدفقات اتصالات RDP.
ما هو الغرض من هذا البيان؟ إذا تمكن مهاجم من الوصول إلى جهاز في شبكتك، فإن لديهم أدوات سريعة وسهلة لاكتشاف أسماء الخوادم في شبكتك. يمكنهم فورًا محاولة بدء الاتصال بخوادمك عبر RDP، ببساطة عن طريق كتابة اسم الخادم واستخدام المنفذ الافتراضي 3389. إذا كانوا قد حصلوا بالفعل على بيانات اعتماد في شبكتك، فيمكنهم الوصول إلى جميع الخوادم الهامة لديك في ثوانٍ من دخولهم للبيئة.
إحدى الحواجز التي يمكنك وضعها في طريق الأشرار هي استخدام أرقام منافذ غامضة لاتصالات RDP. لا يزال هناك العديد من الأشياء السيئة التي يمكنهم القيام بها دون استخدام RDP للوصول إلى الخوادم، وفي النهاية سيظلون يبحثون عن هذه المنافذ العشوائية إذا أرادوا ذلك حقًا، لكنك بالتأكيد ستبطئ العملية كثيرًا إذا كان كل خادم يستمع لاتصالات RDP على رقم منفذ مختلف.
ألن يصبح هذا مصدر إزعاج وعبء على فريق إدارة IT لدينا إذا كان عليهم الآن توثيق أو تذكر كل هذه المنافذ المختلفة؟ بالطبع سيكون كذلك. ولكنه سيزعج ويثقل كاهل أعدائك أيضًا، وهذا هو الهدف.
العديد منكم الذين يقرؤون هذا قد لا يعرفون حتى أن هذا ممكن، وكيف يمكن أن تعرفوا ذلك ما لم تكونوا قد فعلتم ذلك من قبل؟ لا يوجد إعداد قائم على الرسوم لتغيير أرقام منافذ RDP، ولكن هذه القدرة موجودة منذ عدة أجيال من نظام التشغيل Windows.
لنوضح. تم تمكين RDP على خادم WEB1 الخاص بي. حاليًا، يمكنني الاتصال به بسهولة عن طريق فتح MSTSC.EXE، كتابة WEB1، والنقر على Connect. بعد إدخال بيانات الاعتماد، أتصل فورًا بـ WEB1 وأتحكم في واجهته. أداة Remote Desktop Connection (MSTSC) ذكية بما يكفي لتعرف أنه إذا لم أحدد رقم منفذ مع اسم الخادم الخاص بي، فأنا أقصد استخدام المنفذ الافتراضي 3389 للاتصال.
لتغيير رقم المنفذ الذي يستخدمه WEB1 للاستماع لاتصالات RDP، أحتاج إلى تعديل السجل وزيارة المفتاح التالي:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
داخل هذا المفتاح، القيمة التي نريد تغييرها تسمى PortNumber. إذا لم تقم بتعديل هذا من قبل، فستجد 3389 محددًا في شكل عشري.
كل ما تحتاجه هو إدخال رقم منفذ جديد (تأكد من أنه ليس قيد الاستخدام بالفعل على الخادم عن طريق مراجعة إخراج أمر netstat)، ثم إعادة تشغيل الخادم. الآن بعد أن عاد خادم WEB1 الخاص بي إلى العمل، يمكنك أن ترى في لقطة الشاشة التالية أنه لم يعد بإمكاني إنشاء اتصال RDP إلى WEB1 بمجرد استخدام اسم الخادم؛ الآن يجب أن أحدد يدويًا رقم المنفذ الجديد الذي استخدمته (4095) لإنشاء ذلك الاتصال.
تعطيل RDP الخارجي… الآن
نحن جميعًا نعرف كيفية استخدام RDP للوصول إلى الخوادم، وبالفعل أراهن أن 99% من كل من يقرأ هذا يستخدم RDP للوصول إلى الخوادم معظم أيام الأسبوع. القيام بذلك من داخل شبكة الشركة هو وسيلة سريعة وسهلة للتفاعل مع الخوادم، ويعقل تمامًا أن نستخدم هذه التقنية. هل فكرت يومًا في إمكانية السماح بالوصول إلى RDP عبر الإنترنت؟ ألا سيكون من الجميل إذا كان بإمكانك ببساطة فتح MSTSC على جهاز الكمبيوتر المنزلي والاتصال مباشرة بخوادمك دون الحاجة أولاً إلى إنشاء VPN مرهقة؟ هل فعلت ذلك؟ هل لديك خوادم حاليًا لديها قواعد NAT مهيأة في جدار الحماية الخاص بك بحيث يمكنك الوصول إلى منفذ معين باستخدام RDP من أي مكان في العالم والاتصال مباشرة بالخادم الخاص بك؟
توقف عن ذلك الآن!
أغلق المنفذ، احذف قاعدة NAT، لا تمر من هنا، لا تجمع 200 دولار.
هذه هي أسوأ فكرة على الإطلاق، ومع ذلك أكتشف قواعد NAT مثل هذه بانتظام كبير. أعمل غالبًا مع شركات جديدة، داعمًا أجزاء مختلفة من بنيتهم التحتية، وأثناء اكتشاف هذه الشبكات العميلة، نتحقق دائمًا من قواعد جدران الحماية. إنه لأمر مدهش حقًا كم عدد الأماكن في العالم التي لديها وصول RDP إلى الخوادم مفتوح إلى الإنترنت بالكامل.
الآن، ربما تقول لنفسك، "بالطبع لا أفعل ذلك! حسنًا، أنا أفعل، لكنني ماكر وأستخدم أرقام منافذ غامضة لهذا الوصول. بالتأكيد لن تجد منفذ RDP 3389 مفتوحًا على جدار الحماية الخاص بي لأنني أعددت قواعد NAT الخاصة بي بحيث يتعين عليك الاتصال بأشياء مجنونة مثل المنفذ 33343 و5896؛ لن يجدها أحد أبدًا. أنا مندهش أنك حتى تسألنا عن هذا، جوردان، لأنك أظهرت لنا قبل صفحتين فقط كيفية تغيير منافذ RDP الخاصة بنا!"
أنت. مخطئ.
نحن نتحدث عن الإنترنت هنا. نحن نتحدث عن الآلاف من عشاق Minecraft الذين يبلغون من العمر 12 عامًا والذين لديهم كمية لا نهائية من الوقت بين أيديهم. أوه لا، قد أكون قد أهانت أي "مخترق محترف" يقرأ هذا. آسف ليس آسف.
لا فرق سواء كانت منافذك الخارجية هي 3389 أو 12345 أو أي شيء آخر. لدى المهاجمين أدوات فحص المنافذ التي يمكنها بسهولة البحث عن أي قنوات RDP مفتوحة؛ المنفذ الذي تستخدمه تلك القنوات لا يهمهم.
ما هو الخطر؟ كل شيء. برامج الفدية. تعطل شبكتك بالكامل. هذا هو الخطر. كيف أعرف ذلك؟ لأنني ساعدت العديد من الشركات في استعادة كل شيء من النسخ الاحتياطية، جميع الخوادم الخاصة بهم، بسبب قاعدة NAT صغيرة واحدة سمحت بالوصول إلى RDP إلى خادم واحد من الإنترنت. فقط قاعدة صغيرة واحدة إلى خادم صغير واحد وأُغلق البنية التحتية بالكامل ببرنامج الفدية بين عشية وضحاها.
إذا سمحت باتصالات RDP بالدخول إلى شبكتك عبر قاعدة NAT تسمح بالاتصال من الإنترنت، فإنه مجرد مسألة وقت قبل أن يكون شخص ما سيء داخل شبكتك. سيحدث ذلك. عدم حدوثه حتى الآن هو مجرد حظ.
احذف قواعد الجدار الناري وقم بإغلاقها فورًا، ثم ابحث عن طريقة أفضل لتوفير الوصول إلى RDP عن بُعد. قد يعني ذلك إطلاق VPN من جهاز العميل الخاص بك، أو إعداد خادم RD Gateway في بيئتك. RD Gateways آمنة، ولا أقول بأي حال أن خوادم RD Gateway الخاصة بك هي مخاطر لأنها تسمح بوصول RDP إلى الأجهزة الداخلية من الإنترنت. هذا هو هدفها، ولديها آليات لجعل هذا النوع من الاتصالات آمنًا.
تعطيل بروتوكولات التشفير غير الآمنة
أولئك الذين أداروا خوادم الويب في السنوات الأخيرة من المحتمل أن يكونوا على دراية بتعطيل بروتوكولات وأصفار وخوارزميات التشفير التي عفا عليها الزمن ولم تعد آمنة وفقًا لمعايير الأمان الحالية. أي شخص جديد في تكنولوجيا المعلومات أو إدارة الخوادم قد لا يكون قد سمع عن هذه الأمور، لذا دعونا نتحدث عنها الآن. عندما تعبر المعلومات الإنترنت بين أجهزة الكمبيوتر الخاصة بمستخدميك وخوادمك، نأمل أن يكون هناك تشفير يحدث على هذا المرور. إذا لم يكن هناك، فهناك مشاكل أكبر مما نتحدث عنه الآن.
بافتراض وجود تشفير يحدث، فمن المحتمل أن يكون مرورك يستخدم نوعًا من تقنيات التشفير التي تحتوي على إصدارات قديمة وجديدة. الأنواع التي أتحدث عنها هي SSL، TLS، AES، DES، Triple DES، SHA، Diffie-Hellman... والقائمة تطول وتطول. هذه الاختصارات المضحكة هي الآليات الداخلية لكيفية نقل مرورك نفسه بأمان بين العميل والخادم. أحيانًا، تصبح هذه الأمور عفا عليها الزمن ولم تعد مدعومة. كمثالين حقيقيين، SSL 3.0 و TLS 1.0 لا يزالان بروتوكولات صالحة، لكنهما أصبحا أخبارًا سيئة في السنوات القليلة الماضية. تم استبدال هذه البروتوكولات بإصدارات أحدث، والإصدارات القديمة لم تعد مدعومة أو مصححة بأي شكل من الأشكال، وإذا كانت لديك مواقع ويب أو تطبيقات تستخدم هذه البروتوكولات القديمة، فإن كل هذا المرور في خطر حقيقي من الاختراق.
ال Windows Registry
في Windows Server، يمكنك تمكين أو تعطيل هذه البروتوكولات والأصفار عن طريق تعديل السجل. هذا الأمر مباشر إلى حد ما بمجرد أن يكون لديك المواقع المحفوظة وقد مررت بالعملية عدة مرات، لكن بغض النظر عن عدد المرات التي أقوم بها بهذه الطريقة، لم أكن أشعر أبدًا بثقة 100% أنني حققت التغيير بشكل صحيح. على أي حال، لإكمال المعرفة حول هذه الطريقة الأساسية لضبط البروتوكولات في Windows Server، إليك الموقع الرئيسي في السجل حيث يمكنك إضافة أو إزالة قيم السجل لتمكين أو تعطيل بروتوكولات وأصفار محددة:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
سيستغرق الأمر صفحات عديدة لكتابة جميع قيم السجل المختلفة التي تتعلق بالبروتوكولات والأصفار المختلفة، لذلك لن أقوم بذلك. بدلاً من ذلك، إليك رابط لمقالة من Microsoft توضح العديد من الإعدادات الممكنة لخادم AD FS:
https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/operations/manage-ssl-protocols-in-ad-fs
اطلع على جميع تغييرات السجل الممكنة هنا، وأعتقد أنك ستوافقني الرأي أن الأمر يصبح سريعًا فوضى مربكة. لذا، بينما من الممكن تمامًا تعطيل الأصفار القديمة وغير الآمنة باستخدام طريقة السجل، أوصي بشدة باستخدام...
ال IIS Crypto
هذه الأداة المجانية التي أنشأتها Nartac Software تجعل تعديلات البروتوكولات والأصفار والخوارزميات وطرق تبادل المفاتيح أسهل بكثير من تحرير السجل. كل ما عليك فعله هو البحث على الويب لتحميل سريع وتشغيل هذا البرنامج على الخادم الذي تريد إجراء تغييرات عليه. إنها أداة تنفيذية مستقلة، لا حاجة لتثبيت برامج لجعل هذا يحدث. بمجرد فتح IIS Crypto، ستعرض لك جميع البروتوكولات والأصفار المختلفة التي يمكن استخدامها على هذا الخادم، مع مربعات اختيار بجانب كل منها. لتمكين أو تعطيل كل بروتوكول، ما عليك سوى تحديد أو إلغاء تحديد المربع بجوار اسمه. إنه بهذه السهولة! ما تفعله هذه الأداة حقًا هو إجراء تغييرات السجل نيابة عنك، بحيث لا تضطر للقلق بشأن العثور عليها وإدخال الصيغة الصحيحة. عندما تحدد مربعًا، فإنها تخلق قيمة السجل المقابلة وتضبطها على ممكّن. عندما تلغي تحديد مربع، فإنها تغير قيمة السجل إلى معطل.
ستلاحظ العديد من العلامات الرمادية عند تشغيل IIS Crypto لأول مرة، وهذا يشير إلى عدم وجود قيمة سجل حاليًا لهذا البروتوكول المعين، وهو الحالة الافتراضية على أي خادم. عندما تحدد أو تلغي تحديد مربع وتضغط على زر Apply، فإنها تخلق بعد ذلك قيمة السجل وتضبطها وفقًا لذلك.
يمكنك أن ترى في لقطة الشاشة التالية أنني قمت بتعطيل بعض البروتوكولات على هذا الخادم، بما في ذلك SSL 3.0 و TLS 1.0.
ملخص
البند الأول على جدول أعمال العديد من مدراء تقنية المعلومات هو الأمان. أمان لأجهزة العملاء الخاصة بك، أمان لشبكاتك، أمان لمواردك السحابية، والأهم من ذلك أمان لبياناتك. لا يوجد حل واحد لتأمين بنيتك التحتية؛ يتطلب ذلك العديد من الأجزاء المتحركة والعديد من التقنيات المختلفة التي تعمل معًا لتوفير الأمان لمواردك. كان الغرض من هذا الفصل هو تقديم أمثلة على تدابير الأمان والتقنيات التي يمكن استخدامها في أي بيئة، وكذلك لإعادة ترتيب أولويات الأهمية التي يحتلها الأمان في عالم تكنولوجيا المعلومات اليوم. يجب مناقشة المخاوف بشأن الخصوصية والأمان لأي حل تكنولوجي نقوم بتطبيقه. في كثير من الأحيان أجد تطبيقات جديدة يتم تنفيذها داخل المنظمات دون أي اعتبار لكيفية أمان تلك المنصة التطبيقية. التطبيقات التي تنقل أو تخزن البيانات غير مشفرة تحتاج إلى تعديل أو إيقاف. حماية المعلومات ضرورية لطول عمر أعمالنا.
لا يمكننا إكمال مناقشة حول الأمان في Windows Server 2022 دون مناقشة خيار التثبيت الآخر لنظام التشغيل الذي تجاهلناه حتى الآن طوال هذا الكتاب. في الفصل التالي، سنتعمق في Server Core، وهو نسخة خفيفة وأقل عرضة للهجمات من Windows Server.
النهاية
نكون هنا انتهينا من الفصل 9 تماما من شهادة MCSA المقدمة من Microsoft الأن نغوص في الأعماق
و لا بد وانت تقرا ان تكون مركز جيدا لكل معلومة ومعك ورقة وقلم , لانك بالتاكيد ستحتاجها
واذا واجهتك اي مشكلة في الفهم او ما شابه , يمكنك على الفور الذهاب الى المجتمع الخاص بنا في Telegram للمناقشة والتواصل معنا من هنا
او اذا واجهتك مشكلة في الموقع او تريد اجابة سريعة يمكنك الذهاب الى اخر صفحة في الموقع ستجد صفحة اتصل بنا موجودة يمكنك ارسالة لنا مشكلتك , وسيتم الرد عليها بسرعة جدا ان شاء الله
ويمكنك الأنضمام الى المجتمع Hidden Lock بالكامل مع جميع قنواته للأستفادة في اخر الأخبار في عالم التقنية وايضا الكتب بالمجان والكورسات والمقالات من خلال الرابط التالي لمجموعة القنوات من هنا
يمكنك ايضا متابعتنا في منصات X او Twitter سابقا , لمشاهدة الاخبار والمقالات السريعة والمهمة من
وفقط كان معكم Sparrow اتمنى ان تدعوا لي وتتذكروني في الخير دوما
