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 कॉन्फ़िगरेशन के रूप में तैनात किया गया है।

होस्ट	भूमिका	OS	निजी 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

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

लक्ष्य पर 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) की अनुमति देता था।

सख्तीकरण से पहले NSG प्री-फ्लाइट ऑडिट: 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)

सख्तीकरण के बाद NSG सुधार के बाद वही नियम — स्रोत एकल एडमिन IP तक सीमित।

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

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

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

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

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

स्कैनर SSH सत्र कुंजी-आधारित प्रमाणीकरण के साथ 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 ऑटो-स्टार्ट सक्षम।

nessus-vulnerability-scanning-lab

सबसे लोकप्रिय