kingsrule50/nessus-vulnerability-scanning-labإدارة ثغرات المؤسسات على Azure — ماسح Nessus المنشور عبر Terraform، فحص باستخدام بيانات الاعتماد، معالجة CVE-2013-3900 مع إعادة فحص مُتحقَّق منها
دورة حياة كاملة لإدارة الثغرات الأمنية — فحص، اكتشاف، إصلاح، تحقق — نُفِّذت ضد بيئة مختبر Azure Active Directory المباشرة الخاصة بي باستخدام ماسح Nessus مخصص تم نشره عبر Terraform.
قمت بنشر جهاز افتراضي مخصص لـ Ubuntu 24.04 كجهاز ماسح ضوئي في بيئة مختبر Azure AD الحالية، ونفّذت فحصًا أساسيًا غير مُصادَق وفحصًا مُصادَقًا ضد وحدة تحكم المجال، وخادم ملفات، وعميلًا منضمًا للمجال، ثم حللت النتائج، وعالجت نتيجة عالية الخطورة (CVE-2013-3900) عبر تقوية تسجيل Windows باستخدام PowerShell، وتحققت من الإصلاح بإعادة الفحص. هذا هو سير العمل الكامل الذي تعمل به برامج إدارة الثغرات المؤسسية بشكل مستمر.
| الفحص الأساسي غير المُصادَق | الفحص المُصادَق | |
|---|---|---|
| النتائج | 35 | 64 |
| الرؤية | سطح الهجوم الخارجي فقط — منظور المهاجم | داخل نظام التشغيل — مستويات التصحيحات، إعدادات التسجيل، الفحوصات المحلية |
| المصادقة | فشل (جميع المضيفين الثلاثة) | بيانات اعتماد Windows عبر NTLMv2، لا تُرسل أبدًا كنص واضح |
| مدة الفحص | 15 دقيقة | 23 دقيقة |
هذه القفزة في النتائج هي الحجة الكاملة للفحص المُصادَق — النتيجة عالية الخطورة CVE-2013-3900 التي عالجتها في هذا المختبر هي فحص محلي لم يتمكن الفحص غير المُصادَق من رؤيته إطلاقًا.
جهاز NESSUS01 مخصص للفحص على Subnet-Servers مع مسارات فحص مُصادَق إلى جميع أهداف Windows الثلاثة. سطح الإدارة لا يمكن الوصول إليه إلا عبر SSH tunnel من محطة العمل الإدارية — المنفذ 8834 لا يُكشف أبدًا للجمهور.
ينضم الماسح إلى الشبكة الافتراضية (VNet) الموجودة من سلسلتي Enterprise Azure Infrastructure Automation series، ويُستخدم كإعداد Terraform مستقل بحالة خاصة به عن بُعد.
| المضيف | الدور | نظام التشغيل | العنوان IP الخاص |
|---|---|---|---|
| NESSUS01 | ماسح الثغرات | Ubuntu 24.04 LTS | 10.0.1.8 |
| DC01 | وحدة تحكم المجال (lab.local) | Windows Server 2025 | 10.0.1.5 |
| FS01 | خادم الملفات | Windows Server 2025 | 10.0.1.6 |
| CLIENT01 | محطة عمل منضمة للمجال | Windows 11 Pro | 10.0.1.7 |
قرارات التصميم التي اتخذتها:
data بدلًا من تكرارهما، مع عزل الحالة في مفتاح خاص بها nessus-scanner.tfstate بحيث يمكن إنشاء الماسح وتدميره دون المساس بحالة المختبر الأساسية.ssh -L 8834:localhost:8834). كشف سطح الإدارة هو الطريقة الأولى التي تتعرض بها أجهزة الماسح للاختراق.قبل نشر أي شيء، دققت قواعد NSG الحالية — ووجدت بالضبط نوع سوء الإعداد الذي وُجد هذا المختبر ليكشفه: قاعدة RDP كانت تسمح بالمصدر * (أي عنوان IP على الإنترنت).
مراجعة ما قبل النشر: استعلام az network nsg list يكشف أن Allow-RDP-3389 مفتوح لأي مصدر (*).
قمت بتقييده إلى عنوان IP العام الحالي الخاص بي قبل المتابعة:
az network nsg rule update -g RG-FileServerLab --nsg-name NSG-RDP \
-n Allow-RDP-3389 --source-address-prefixes $(curl -s ifconfig.me)
القاعدة نفسها بعد المعالجة — المصدر مقيد بعنوان IP إداري واحد.
إن اكتشاف وإصلاح ثغرة في بيئتك الخاصة قبل توجيه الماسح إليها هو التحول العقلي من "تشغيل أداة" إلى "ممارسة الأمن".
خمسة موارد — عنوان IP عام، NSG، بطاقة شبكة (NIC)، ربط NSG، وجهاز Ubuntu الافتراضي — نُشرت في أقل من دقيقتين:
terraform apply: 5 إضافات، 0 تغييرات، 0 عمليات حذف. تشمل المخرجات أمر SSH الجاهز للاستخدام.
ثم اتصلت عبر SSH ونفّذت التثبيت الرأسي (headless) لـ Nessus Essentials 10.12.1:
أول اتصال SSH بـ NESSUS01 بمصادقة المفاتيح — Ubuntu 24.04 يعمل على 10.0.1.8، جاهز لتثبيت Nessus الرأسي.
الفحص الأول: بدون بيانات اعتماد — هذا هو ما يراه المهاجم على مقطع الشبكة.
فحص شبكة أساسي يستهدف المضيفين الثلاثة: 10.0.1.5، 10.0.1.6، 10.0.1.7.
النتائج الأساسية: 35 نتيجة عبر 3 مضيفين، عمود Auth يُظهر Fail — لم يتمكن Nessus من تسجيل الدخول، لذلك تأتي كل نتيجة من الملاحظة الخارجية فقط.
الفحص المُصادَق هو المعيار المؤسسي لإدارة الثغرات الداخلية. جهّزت أهداف Windows بتمكين خدمة Remote Registry وفتح مجموعات قواعد جدار الحماية المطلوبة على ملف تعريف المجال (Domain profile):
Set-Service -Name RemoteRegistry -StartupType Automatic
Start-Service RemoteRegistry
Set-NetFirewallRule -DisplayGroup "File and Printer Sharing" -Enabled True -Profile Domain
Set-NetFirewallRule -DisplayGroup "Windows Management Instrumentation (WMI)" -Enabled True -Profile Domain
تجهيز الهدف على FS01 — RemoteRegistry يعمل مع بدء تلقائي، وقواعد WMI و File & Printer Sharing مفعّلة لملف تعريف المجال.
قمت بإعداد بيانات اعتماد Windows في الفحص مع خيارات الأمان التي تطلبها المؤسسات: عدم إرسال بيانات الاعتماد كنص واضح أبدًا، وNTLMv2 فقط.
إعداد بيانات اعتماد Windows — مجال LAB، تعطيل NTLMv1، تعطيل إرسال بيانات الاعتماد كنص واضح، تفعيل بدء Remote Registry التلقائي للفحص.
النتائج المُصادَق عليها: 64 نتيجة — بزيادة 83% عن الأساس غير المُصادَق ضد نفس المضيفين الثلاثة تمامًا.
النتائج مرتبة حسب الخطورة، مع ظهور الفحص المحلي WinVerifyTrust عالي الخطورة الآن — وهي نتيجة لم تكن لدى الفحص غير المُصادَق أي طريقة لاكتشافها.
الملحق رقم #166555 حدد التحقق من توقيع WinVerifyTrust (CVE-2013-3900) على كل من DC01 وFS01 — درجة أساسية CVSS v3 تبلغ 8.8، وVPR تبلغ 9.0 في Tenable. كانت قيمة التسجيل EnableCertPaddingCheck مفقودة، ما يترك المضيفين في حالة يمكن فيها للمهاجم إلحاق محتوى خبيث بملف تنفيذي موقّع دون إبطال توقيع Authenticode الخاص به.
تحليل كامل للنتيجة: مخرجات الملحق تؤكد غياب قيمة التسجيل على 10.0.1.5 و10.0.1.6، مع توثيق مسار المعالجة الدقيق في قسم Solution.
لماذا تهم هذه النتيجة: إنها ثغرة تخفيف عبر الإعداد (mitigation-by-configuration) — لا يوجد تصحيح لأن Microsoft جعلت الإصلاح اختياريًا (opt-in). وصلت مفقودة على صور Windows Server 2025 الجديدة في 2026، بعد ثلاثة عشر عامًا من نشر CVE. هذه بالضبط فئة المشكلات التي لا يلتقطها سوى الفحص المُصادَق وإدارة الإعدادات.
طبّقت الإصلاح على المضيفين المتأثرين وفقًا لقسم Solution في الملحق — تعيين EnableCertPaddingCheck = 1 في مساري التسجيل 64-bit وWow6432Node — ثم تحققت من المفتاحين قبل إعادة الفحص:
New-Item -Path "HKLM:\Software\Microsoft\Cryptography\Wintrust\Config" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\Software\Microsoft\Cryptography\Wintrust\Config" `
-Name "EnableCertPaddingCheck" -Value "1" -Type String
New-Item -Path "HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" `
-Name "EnableCertPaddingCheck" -Value "1" -Type String
تم تطبيق المعالجة والتحقق منها باستخدام Get-ItemProperty — يعيد كلا مساري التسجيل الآن EnableCertPaddingCheck : 1.
ثم الخطوة التي يتجاهلها معظم الناس — إعادة الفحص للتحقق. لا تُغلق التذكرة حتى يؤكد الماسح أن النتيجة اختفت:
فحص التحقق (History: 2): النتيجة عالية الخطورة CVE-2013-3900 قد حُلّت. أعلى خطورة متبقية هي متوسطة.
اكتشف → حلّل → أصلح → تحقق. الحلقة مغلقة.
| المهارة | مكانها |
|---|---|
| دورة حياة إدارة الثغرات | من البداية للنهاية: الفحص الأساسي، الفحص المُصادَق، التحليل، المعالجة، التحقق |
| نشر وتشغيل Nessus | Essentials 10.12.1 على Ubuntu، إعداد سياسات الفحص، الفحص المُصادَق |
| بنية الماسح الآمنة | جهاز افتراضي مخصص، سطح إدارة عبر SSH tunnel فقط، مصادقة بالمفاتيح، NSG بأقل الصلاحيات |
| البنية التحتية كرمز (IaC) | Terraform مع data sources مقابل البنية التحتية القائمة، حالة عن بُعد معزولة |
| أمان شبكة Azure | مراجعة وتقوية NSG عبر Azure CLI، سير عمل تقييد عنوان IP المصدر |
| تقوية Windows | تخفيف قائم على التسجيل (CVE-2013-3900)، تجهيز Remote Registry / WMI / جدار الحماية |
| تفسير CVSS وتقييم المخاطر | تحليل CVSS 8.8 / VPR 9.0، مقارنة الرؤية بين الفحص المُصادَق وغير المُصادَق |
| إدارة PowerShell | إعداد الخدمات، مجموعات قواعد جدار الحماية، معالجة التسجيل مع التحقق |
إدارة الثغرات هي وظيفة أساسية في جميع أدوار عمليات الأمن (SecOps) وأمن السحابة وGRC تقريبًا. يغطي هذا المختبر الوظيفة بأكملها — ليس فقط تشغيل ماسح، بل أيضًا هندسة موضعه بشكل آمن، وتجهيز الأهداف بشكل صحيح، وتمييز الإشارة عن الضوضاء في النتائج، وتنفيذ المعالجة، وإثبات نجاحها. المقارنة بين الفحص غير المُصادَق والمُصادَق، وإعادة فحص التحقق، هما الأمران اللذان يفصلان الممارسين عن مشغلي الأدوات.
التسليم الاحترافي الكامل — الملخص التنفيذي، المنهجية، التحليل التفصيلي لنتيجة CVE-2013-3900، معالجة المخاطر المتبقية، والتوصيات مرتبة حسب الأولوية — متاح كملف PDF:
لا يتضمن Nessus Essentials تصدير التقارير، لذلك أُعدّ هذا التسليم بشكل مستقل من بيانات الفحص — وهي بحد ذاتها مهارة إعداد تقارير التقييم التي تتركها النسخة المجانية.
هذا الماسح يُنشر في البيئة التي بنتها سلسلتي Enterprise Azure Infrastructure Automation series:
لا توجد أسرار مخزنة في هذا المستودع — يستخدم الماسح مصادقة مفتاح SSH فقط، وأُدخلت بيانات اعتماد الفحص مباشرة في وحدة تحكم Nessus، ولم تُضف أبدًا إلى الكود المصدري.