Nessus भेद्यता स्कैनिंग लैब — Azure

पूर्ण भेद्यता प्रबंधन जीवनचक्र — स्कैन, खोज, सुधार, सत्यापन — एक समर्पित, Terraform-तैनात Nessus स्कैनर का उपयोग करके मेरे लाइव Azure Active Directory लैब वातावरण के विरुद्ध निष्पादित किया गया।

यह लैब क्या प्रदर्शित करता है

मैंने अपने मौजूदा Azure AD लैब वातावरण में एक समर्पित Ubuntu 24.04 स्कैनर VM तैनात किया, एक डोमेन नियंत्रक, एक फ़ाइल सर्वर और एक डोमेन-संलग्न क्लाइंट के विरुद्ध एक बिना प्रमाणीकरण वाला बेसलाइन स्कैन और एक क्रेडेंशियल स्कैन चलाया, परिणामों का विश्लेषण किया, PowerShell रजिस्ट्री हार्डनिंग के माध्यम से एक उच्च-गंभीरता वाले निष्कर्ष (CVE-2013-3900) का सुधार किया, और पुनः-स्कैन के साथ सुधार को सत्यापित किया। यह पूर्ण कार्यप्रवाह है जिसे एंटरप्राइज़ भेद्यता प्रबंधन कार्यक्रम निरंतर चलाते हैं।

| | बिना प्रमाणीकरण का बेसलाइन | क्रेडेंशियल स्कैन | |---|---| | निष्कर्ष | 35 | 64 | | दृश्यता | केवल बाहरी आक्रमण सतह — हमलावर का दृश्य | OS के अंदर — पैच स्तर, रजिस्ट्री कॉन्फ़िगरेशन, स्थानीय जाँचें | | प्रमाणीकरण | विफल (सभी 3 होस्ट) | NTLMv2 के माध्यम से Windows क्रेडेंशियल, कभी भी स्पष्ट रूप में नहीं भेजे गए | | स्कैन समय | 15 मिनट | 23 मिनट |

निष्कर्षों में वह उछाल ही क्रेडेंशियल स्कैनिंग के पक्ष में पूरा तर्क है — मैंने इस लैब में जिस उच्च-गंभीरता वाले CVE-2013-3900 निष्कर्ष का सुधार किया, वह एक स्थानीय जाँच है जिसे बिना प्रमाणीकरण वाला स्कैन बिल्कुल नहीं देख सका।

आर्किटेक्चर

Subnet-Servers पर समर्पित NESSUS01 स्कैनर उपकरण, तीनों Windows लक्ष्यों तक क्रेडेंशियल स्कैन पथों के साथ। प्रबंधन प्लेन केवल एडमिन वर्कस्टेशन से SSH टनल के माध्यम से पहुँच योग्य है — पोर्ट 8834 कभी भी सार्वजनिक रूप से उजागर नहीं होता।

स्कैनर मेरी Enterprise Azure Infrastructure Automation श्रृंखला के मौजूदा लैब VNet से जुड़ता है, जिसे अपनी स्वयं की रिमोट स्टेट के साथ एक स्वतंत्र Terraform कॉन्फ़िगरेशन के रूप में तैनात किया गया है।

मेरे द्वारा लिए गए डिज़ाइन निर्णय:

• लक्ष्य पर Nessus स्थापित करने के बजाय समर्पित स्कैनर VM। एंटरप्राइज़ स्कैनर को स्वतंत्र नेटवर्क उपकरणों के रूप में रखा जाता है, जिनकी अपने लक्ष्यों तक अबाधित पहुँच होती है — किसी ऐसे होस्ट से स्कैन करना जो स्वयं भी एक लक्ष्य है, परिणामों को दूषित करता है।
• मौजूदा इन्फ्रास्ट्रक्चर के विरुद्ध Terraform डेटा स्रोत। स्कैनर कॉन्फ़िगरेशन मौजूदा VNet और सबनेट को दोहराने के बजाय data ब्लॉकों के माध्यम से संदर्भित करता है, जिसमें स्टेट अपनी स्वयं की nessus-scanner.tfstate कुंजी में पृथक होती है, ताकि स्कैनर को कोर लैब स्टेट को छुए बिना बनाया और नष्ट किया जा सके।
• Nessus वेब UI (पोर्ट 8834) कभी भी सार्वजनिक रूप से उजागर नहीं होता। NSG केवल मेरे एडमिन IP से SSH (22) की अनुमति देता है; मैं UI तक SSH टनल (ssh -L 8834:localhost:8834) के माध्यम से पहुँचता हूँ। प्रबंधन-प्लेन का उजागर होना स्कैनर उपकरणों के समझौता होने का सबसे बड़ा कारण है।
• केवल SSH कुंजी प्रमाणीकरण — ed25519 कुंजी जोड़ी, स्कैनर पर कोई पासवर्ड प्रमाणीकरण नहीं।

चरण 0 — प्री-फ्लाइट सुरक्षा समीक्षा (जो स्कैन करते हैं, उसका अभ्यास करें)

कुछ भी तैनात करने से पहले, मैंने मौजूदा 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 तक सीमित।

स्कैनर को इंगित करने से पहले अपने स्वयं के वातावरण में किसी उजागरता को खोजना और ठीक करना ही "टूल चलाने" से "सुरक्षा करने" की ओर मानसिकता का बदलाव है।

चरण 1 — Terraform के साथ स्कैनर तैनात करें

पाँच संसाधन — सार्वजनिक IP, NSG, NIC, NSG संबद्धता, और Ubuntu VM — दो मिनट से भी कम समय में तैनात:

terraform apply: 5 जोड़े गए, 0 बदले गए, 0 नष्ट हुए। आउटपुट में उपयोग-के-लिए-तैयार SSH कमांड शामिल है।

फिर मैंने SSH के माध्यम से कनेक्ट किया और हेडलेस Nessus Essentials 10.12.1 इंस्टॉल किया:

कुंजी-आधारित प्रमाणीकरण के साथ NESSUS01 से पहला SSH कनेक्शन — Ubuntu 24.04 10.0.1.8 पर चालू, हेडलेस Nessus इंस्टॉल के लिए तैयार।

चरण 2 — बिना प्रमाणीकरण का बेसलाइन स्कैन

पहला स्कैन: कोई क्रेडेंशियल नहीं — यह वही है जो नेटवर्क सेगमेंट पर एक हमलावर देखता है।

सभी तीन होस्टों को लक्षित करने वाला बेसिक नेटवर्क स्कैन: 10.0.1.5, 10.0.1.6, 10.0.1.7।

बेसलाइन परिणाम: 3 होस्टों पर 35 निष्कर्ष, Auth कॉलम Fail दिखा रहा है — Nessus लॉग इन नहीं कर सका, इसलिए हर परिणाम केवल बाहरी अवलोकन से आता है।

चरण 3 — क्रेडेंशियल स्कैन

क्रेडेंशियल स्कैनिंग आंतरिक भेद्यता प्रबंधन के लिए एंटरप्राइज़ मानक है। मैंने Remote Registry सेवा को सक्षम करके और Domain प्रोफ़ाइल पर आवश्यक फ़ायरवॉल नियम समूहों को खोलकर Windows लक्ष्यों को तैयार किया:

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 Automatic स्टार्टअप के साथ चल रही है, Domain प्रोफ़ाइल के लिए WMI और File & Printer Sharing नियम सक्षम हैं।

मैंने स्कैन में Windows क्रेडेंशियल उन सुरक्षा विकल्पों के साथ कॉन्फ़िगर किए जिनकी एंटरप्राइज़ आवश्यकता होती है: क्रेडेंशियल को कभी भी स्पष्ट रूप में न भेजें, और केवल NTLMv2।

Windows क्रेडेंशियल कॉन्फ़िगरेशन — डोमेन LAB, NTLMv1 अक्षम, क्लियरटेक्स्ट क्रेडेंशियल ट्रांसमिशन अक्षम, स्कैन के लिए Remote Registry ऑटो-स्टार्ट सक्षम।

क्रेडेंशियल परिणाम: 64 निष्कर्ष — ठीक उन्हीं तीन होस्टों के विरुद्ध बिना प्रमाणीकरण के बेसलाइन की तुलना में 83% की वृद्धि।

गंभीरता-क्रमित निष्कर्ष, जिसमें उच्च-गंभीरता वाली WinVerifyTrust स्थानीय जाँच अब दिखाई दे रही है — एक ऐसा निष्कर्ष जिसे बिना प्रमाणीकरण वाला स्कैन किसी भी तरह से पहचान नहीं सका।

चरण 4 — उच्च खोज का विश्लेषण करें: CVE-2013-3900

प्लगइन #166555 ने DC01 और FS01 दोनों पर WinVerifyTrust सिग्नेचर सत्यापन (CVE-2013-3900) फ़्लैग किया — CVSS v3 बेस स्कोर 8.8, Tenable VPR 9.0। EnableCertPaddingCheck रजिस्ट्री मान अनुपस्थित था, जिससे होस्ट ऐसी स्थिति में रह गए जहाँ एक हमलावर बिना उसके Authenticode सिग्नेचर को अमान्य किए एक हस्ताक्षरित निष्पादन योग्य में दुर्भावनापूर्ण सामग्री जोड़ सकता था।

पूर्ण खोज विश्लेषण: प्लगइन आउटपुट पुष्टि करता है कि 10.0.1.5 और 10.0.1.6 पर रजिस्ट्री मान अनुपस्थित है, जिसमें Solution अनुभाग में सटीक सुधार पथ प्रलेखित है।

यह खोज क्यों महत्वपूर्ण है: यह एक कॉन्फ़िगरेशन-द्वारा-शमन भेद्यता है — कोई पैच मौजूद नहीं है क्योंकि Microsoft ने इस सुधार को वैकल्पिक बनाया है। CVE प्रकाशित होने के तेरह साल बाद, यह 2026 में नई Windows Server 2025 इमेजों पर अनुपस्थित शिप हुआ। यह ठीक उसी प्रकार की समस्या है जिसे केवल क्रेडेंशियल स्कैनिंग और कॉन्फ़िगरेशन प्रबंधन पकड़ते हैं।

चरण 5 — सुधार और सत्यापन

मैंने प्लगइन के Solution अनुभाग के अनुसार प्रभावित होस्टों पर सुधार लागू किया — 64-बिट और Wow6432Node दोनों रजिस्ट्री पथों पर EnableCertPaddingCheck = 1 सेट किया — फिर पुनः-स्कैन करने से पहले दोनों कुंजियों को सत्यापित किया:

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 निष्कर्ष हल हो गया। शेष उच्चतम गंभीरता Medium है।

खोजें → विश्लेषण करें → सुधारें → सत्यापित करें। लूप बंद।

प्रदर्शित कौशल

नौकरी के लिए यह क्यों महत्वपूर्ण है

भेद्यता प्रबंधन लगभग हर सुरक्षा संचालन, क्लाउड सुरक्षा और GRC भूमिका में एक मुख्य कार्य है। यह लैब पूरी नौकरी को कवर करता है — केवल स्कैनर चलाना नहीं, बल्कि उसके स्थान को सुरक्षित रूप से आर्किटेक्ट करना, लक्ष्यों को सही ढंग से तैयार करना, परिणामों में संकेत को शोर से अलग करना, सुधार को निष्पादित करना और यह साबित करना कि यह काम कर गया। बिना-प्रमाणीकरण-बनाम-क्रेडेंशियल तुलना और सत्यापन पुनः-स्कैन वे दो चीज़ें हैं जो व्यवसायियों को टूल ऑपरेटरों से अलग करती हैं।

मूल्यांकन रिपोर्ट

पूर्ण पेशेवर डिलीवरेबल — कार्यकारी सारांश, कार्यप्रणाली, विस्तृत CVE-2013-3900 खोज विश्लेषण, अवशिष्ट-जोखिम निपटान, और प्राथमिकता वाली अनुशंसाएँ — PDF के रूप में उपलब्ध है:

Vulnerability-Assessment-Report.pdf

Nessus Essentials में रिपोर्ट निर्यात शामिल नहीं है, इसलिए यह डिलीवरेबल स्कैन डेटा से स्वतंत्र रूप से लिखा गया था — जो स्वयं वह मूल्यांकन-रिपोर्टिंग कौशल है जिसे मुफ़्त टियर छोड़ देता है।

संबंधित लैब

यह स्कैनर मेरी Enterprise Azure Infrastructure Automation श्रृंखला द्वारा निर्मित वातावरण में तैनात होता है:

• लैब 1 — Terraform इन्फ्रास्ट्रक्चर
• लैब 2 — Active Directory
• लैब 3 — NTFS फ़ाइल सर्वर और RBAC
• लैब 4–6 — Azure RBAC

इस रिपॉज़िटरी में कोई सीक्रेट संग्रहीत नहीं हैं — स्कैनर केवल SSH कुंजी प्रमाणीकरण का उपयोग करता है, और स्कैन क्रेडेंशियल सीधे Nessus कंसोल में दर्ज किए गए थे, कोड में कभी प्रतिबद्ध नहीं किए गए।