बड़ा सवाल है।
सबसे पहली बात - मैं ज्यादातर "पैठ परीक्षकों" को स्क्रिप्ट किडिज़ मानता हूँ। मेरा पूर्वाग्रह उचित या सटीक नहीं हो सकता है, लेकिन मैं इस अस्वीकरण में लगा रहा हूं ताकि यदि आप मेरे स्वर में किसी भी तरह के उन्माद का पता लगाते हैं, तो आप जानते हैं कि यह कहां से आ रहा है। मैं यह नहीं कह रहा हूं कि कोई कुशल पेंटर नहीं हैं , लेकिन यह मेरी व्यापकता है।
(जीवन के लिए ब्लू टीम!)
मेरा प्रश्न: 1) क्या केंद्रीय निर्देशिका में इन विफल उपयोगकर्ता नाम अनुरोधों को लॉग करने के लिए सक्रिय निर्देशिका प्राप्त करने का एक तरीका है ताकि हम उनमें एक कील नोटिस कर सकें?
आपने किसी को भी इस जानकारी का पूरी तरह से और आत्मविश्वास के साथ जवाब देने में सक्षम होने के लिए पर्याप्त जानकारी की आपूर्ति नहीं की। आपने कहा कि आपके आवेदन में एक दोष पाया गया है जिससे हमलावरों को उपयोगकर्ता खातों की गणना करने की अनुमति मिली। मैं यह समझने की कोशिश कर रहा हूं कि आपको किस तरह से लगता है कि AD को आपके आवेदन के लिए लॉगिंग करने की आवश्यकता है ।
जाहिरा तौर पर विफलताओं को केवल उस सर्वर के स्थानीय ईवेंट लॉग में दिखाया गया जहां एप्लिकेशन इंस्टॉल किया गया था।
जाहिर है सर्वर पर इवेंट लॉग में विफलताओं को दिखाया? या सर्वर पर इवेंट लॉग में विफलताओं को दिखाया? यदि हां, तो घटनाओं ने वास्तव में क्या कहा? उन्हें किसने लॉग इन किया? आपका आवेदन? या विंडोज? पता करें और मैं अपने उत्तर में अतिरिक्त स्पष्टीकरण जोड़ने में सक्षम हो सकता हूं।
मैं आपके अनुमान के आधार पर यहाँ एक अंग पर जा रहा हूँ कि इन घटनाओं को सक्रिय निर्देशिका द्वारा किसी भी तरह लॉग इन किया जाना चाहिए ... क्या होगा यदि आपके पंचर वास्तव में आपके आवेदन में दोष का शोषण नहीं कर रहे थे, लेकिन इसके बजाय उपयोग कर रहे थे कर्बरोस में एक बहुत ही प्रसिद्ध दोष है जो उपयोगकर्ता नाम रखने के लिए है? केर्बरोस में खुद ही शामिल है कि मैं एक डिज़ाइन दोष पर विचार करूंगा जिसमें एक हमलावर हजारों और हजारों "पूर्व-प्रमाणीकरण" प्रयास (यानी एक क्रूर बल हमला) का प्रयास कर सकता है और केडीसी अलग-अलग जवाब देगा कि उपयोगकर्ता खाता मौजूद है या नहीं। यह सक्रिय निर्देशिका-विशिष्ट व्यवहार नहीं है, लेकिन एमआईटी केर्बरोस, हेमडाल, आदि के साथ ही लागू होता है। केडीसी जवाब देगाKDC_ERR_PREAUTH_REQUIREDयदि कोई मान्य उपयोगकर्ता नाम बिना किसी पूर्व-प्रमाणीकरण डेटा के साथ प्रस्तुत किया गया था, भले ही वास्तविक प्रमाणीकरण का प्रयास किए बिना। इस तरह आप एक KDC से उपयोगकर्ता नाम की गणना कर सकते हैं। लेकिन क्योंकि हमलावर (या उपकरण जो हमलावर ऐसे उपयोग कर रहा है जैसे कि क्रबग्यूस - क्योंकि अन्य लोगों के उपकरण का उपयोग करते समय पेंटेस्टर्स अपने सर्वश्रेष्ठ पर हैं) को पूर्ण प्रमाणीकरण प्रयास पर जारी रखने की आवश्यकता नहीं है, क्योंकि कुछ भी लॉग नहीं किया गया है क्योंकि वास्तविक प्रमाणीकरण का प्रयास किया गया था!
अब, अपने अगले प्रश्न पर:
2) यदि नहीं, तो भविष्य में इस प्रकार के हमले की निगरानी और सक्रिय रूप से पता लगाने का सबसे अच्छा तरीका क्या है (उम्मीद है कि बहुत अधिक नए उपकरण खरीदने के बिना)।
कुछ चीजें।
सबसे पहले, भुगतान किया जाता है, एंटरप्राइज़-ग्रेड उत्पादों को इन प्रकार के हमलों का पता लगाने के लिए डिज़ाइन किया गया है (बहुत अधिक के बीच।) कई विक्रेता ऐसे उत्पादों की पेशकश करते हैं, और उत्पाद सिफारिशें सर्वरफॉल्ट के लिए ऑफ-टॉपिक हैं, लेकिन यह कहना है कि वे बाहर हैं वहाँ। इनमें से कई उत्पाद आपके डोमेन नियंत्रकों और इन "डेटा कलेक्टरों" के बीच पोर्ट मिररिंग को कॉन्फ़िगर करने की आवश्यकता के अनुसार काम करते हैं ताकि वे आपके डोमेन नियंत्रकों में प्रवेश करने या बाहर निकलने वाले प्रत्येक पैकेट को शाब्दिक रूप से देखें और विश्लेषण करें।
(क्षमा करें, कि थोड़े बहुत नए सामान खरीदने के बिना "थोड़े आपके" में गिर जाता है। "
एक और चीज़ जो आपकी मदद कर सकती है वह है रजिस्ट्री प्रविष्टि:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
LogLevel = 1
यहां दस्तावेज दिया गया है ।
यदि आप इस रजिस्ट्री प्रविष्टि को सक्षम करते हैं, तो आपको Kerberos त्रुटियों के बारे में अपने सुरक्षा ईवेंट लॉग में ईवेंट्स से भर जाना चाहिए जो उल्लेख करते हैं कि Kerberos प्री-ऑथेंटिकेशन की आवश्यकता है। इस तरह की घटना का एक उदाहरण:
A Kerberos Error Message was received:
on logon session DOMAIN\serviceaccount
Client Time:
Server Time: 12:44:21.0000 10/9/2012 Z
Error Code: 0x19 KDC_ERR_PREAUTH_REQUIRED
Extended Error:
Client Realm:
Client Name:
Server Realm: DOMAIN
Server Name: krbtgt/DOMAIN
Target Name: krbtgt/DOMAIN@DOMAIN
Error Text:
File: e
Line: 9fe
Error Data is in record data.
लेकिन यह आपकी मदद कर सकता है या नहीं कर सकता है यदि यह निर्दिष्ट नहीं करता है कि केर्बरोस अनुरोधों की सुनामी कहां से आ रही है। यह हमें उन उद्यम घुसपैठ का पता लगाने वाले उत्पादों की ओर ले जाता है, जिनका मैंने पहले उल्लेख किया था।
और विंडोज इवेंट फ़ॉरवर्डिंग को मत भूलना, जो आपके सर्वर को एक केंद्रीकृत स्थान पर घटनाओं को अग्रेषित करने के लिए हो सकता है, जो आपके निपटान में आपके पास जो भी उपकरण हो उसका विश्लेषण किया जा सकता है।
इस पूरे उत्तर को अभी तक केर्बोस प्रोटोकॉल पर समर्पित किया गया है, जिसे मैं वास्तव में स्वीकार नहीं कर सकता क्योंकि आपने अपनी पोस्ट में इतना कम विवरण दिया था। फिर भी, मुझे उम्मीद है कि यह कम से कम मदद करता है।