Windows सिस्टम सुरक्षा इवेंट लॉगिंग समस्याएँ

विंडोज ऑपरेटिंग सिस्टम में एक बहुत अच्छा सुरक्षा इवेंट लॉगिंग सिस्टम है। विभिन्न प्रकाशनों और समीक्षाओं में उनके बारे में बहुत सारी अच्छी बातें लिखी गई हैं, लेकिन यह लेख कुछ और होगा। यहां हम इस प्रणाली में समस्याओं और कमियों के बारे में बात करते हैं। समस्याओं में से कुछ गैर-महत्वपूर्ण होगी, केवल घटनाओं के विश्लेषण के लिए प्रक्रियाओं को जटिल बनाना, जबकि अन्य बहुत गंभीर सुरक्षा खतरों का सामना करेंगे।

विंडोज 7 अधिकतम (रूसी संस्करण), विंडोज 7 प्रोफेशनल (अंग्रेजी संस्करण), विंडोज 10 प्रो (रूसी संस्करण), विंडोज सर्वर 2019 डाटासेंटर (रूसी संस्करण) पर पहचानी गई समस्याओं का परीक्षण किया गया था। सभी ऑपरेटिंग सिस्टम पूरी तरह से अपडेट हो गए हैं।

समस्या नंबर 1. विफल ऑडिट पैरामीटर प्रबंधन प्रणाली

Windows 7/10 / Server 2019 पर समस्या की पुष्टि की गई है।

समस्या का वर्णन

विंडोज 7 लें और इसे डिफ़ॉल्ट सेटिंग्स के साथ इंस्टॉल करें। हम डोमेन में प्रवेश नहीं करेंगे। आइए सुरक्षा इवेंट ऑडिट सेटिंग्स देखें। ऐसा करने के लिए, स्थानीय सुरक्षा नीतियां स्नैप-इन (secpol.msc, या कंट्रोल पैनल -> प्रशासनिक उपकरण -> स्थानीय सुरक्षा नीतियां) खोलें और बुनियादी ऑडिट सेटिंग्स (सुरक्षा सेटिंग्स -> स्थानीय नीतियां -> ऑडिट नीतियां) देखें। )।



जैसा कि आप देख सकते हैं, ऑडिट कॉन्फ़िगर नहीं है। अब हम उन्नत ऑडिट नीतियों ("सुरक्षा सेटिंग्स -> उन्नत ऑडिट नीति कॉन्फ़िगरेशन -> सिस्टम ऑडिट नीतियां - स्थानीय समूह नीति ऑब्जेक्ट") को देखते हैं।



यहां ऑडिट कॉन्फ़िगर नहीं है। यदि ऐसा है, तो सिद्धांत रूप में लॉग में कोई सुरक्षा घटना नहीं होनी चाहिए। हम जांच करते हैं। सुरक्षा लॉग खोलें (Eventvwr.exe, या "कंट्रोल पैनल -> प्रशासनिक उपकरण -> इवेंट देखें")।



प्रश्न: "ऑडिट को बिल्कुल भी कॉन्फ़िगर नहीं किया गया है तो सुरक्षा लॉग में ईवेंट कहां से आता है?"

व्याख्या

इस व्यवहार के कारण को समझने के लिए, आपको ऑपरेटिंग सिस्टम के "हुड के नीचे" प्राप्त करने की आवश्यकता है। शुरू करने के लिए, हम बुनियादी और उन्नत ऑडिट नीतियों से निपटेंगे।

Windows Vista से पहले, केवल एक ऑडिट नीति थी, जिसे अब बुनियादी कहा जाता है। समस्या यह थी कि उस समय ऑडिट प्रबंधन की ग्रैन्युलैरिटी बहुत कम थी। इसलिए, यदि फ़ाइलों तक पहुंच को ट्रैक करना आवश्यक था, तो उन्होंने मूल नीति "ऑब्जेक्ट्स के लिए ऑडिट एक्सेस" की श्रेणी को शामिल किया। नतीजतन, फ़ाइल संचालन के अलावा, अन्य "शोर" घटनाओं का एक गुच्छा सुरक्षा लॉग में डाला गया। यह लॉग्स और अनियोजित उपयोगकर्ताओं के प्रसंस्करण को बहुत जटिल करता है।

Microsoft ने इस "दर्द" को सुना और मदद करने का फैसला किया। समस्या यह है कि विंडोज पिछड़े संगतता की अवधारणा पर बनाया गया है, और मौजूदा ऑडिट प्रबंधन तंत्र में परिवर्तन करने से इस संगतता को मार दिया जाएगा। इसलिए, विक्रेता दूसरे तरीके से चला गया। उन्होंने एक नया टूल बनाया और इसे एडवांस्ड ऑडिट पॉलिसीज़ कहा।

उपकरण का सार इस तथ्य में निहित है कि उन्नत नीति श्रेणियां बुनियादी ऑडिट नीतियों की श्रेणियों से बनाई गई थीं, और जिन्हें बदले में, उपश्रेणियों में विभाजित किया गया था जिन्हें व्यक्तिगत रूप से चालू और बंद किया जा सकता है। अब, यदि आपको उन्नत ऑडिट नीतियों में फ़ाइलों तक पहुंच को ट्रैक करने की आवश्यकता है, तो आपको केवल "फाइल सिस्टम" उपश्रेणी को सक्रिय करने की आवश्यकता है, जो "ऑब्जेक्ट एक्सेस" श्रेणी में शामिल है। उसी समय, नेटवर्क ट्रैफ़िक की रजिस्ट्री या फ़िल्टरिंग तक पहुँचने से संबंधित "शोर" घटनाओं को सुरक्षा लॉग में शामिल नहीं किया जाएगा।

इस पूरी योजना में एक बड़ा भ्रम यह है कि बुनियादी ऑडिट नीतियों और उन्नत की श्रेणियों के नाम मेल नहीं खाते हैं, और पहली बार में यह लग सकता है कि ये पूरी तरह से अलग चीजें हैं, लेकिन ऐसा नहीं है।

यहाँ लेखापरीक्षा प्रबंधन की मूल और उन्नत श्रेणियों के नामों की तालिका है

यह समझना महत्वपूर्ण है कि बुनियादी और उन्नत दोनों श्रेणियां अनिवार्य रूप से एक ही चीज़ को नियंत्रित करती हैं। एक बुनियादी ऑडिट पॉलिसी श्रेणी को शामिल करने से संबंधित विस्तारित ऑडिट पॉलिसी श्रेणी का समावेश होता है और, परिणामस्वरूप, इसकी सभी उपश्रेणियाँ। अप्रत्याशित परिणामों से बचने के लिए, Microsoft एक ही समय में मूल और उन्नत ऑडिट नीतियों के उपयोग की अनुशंसा नहीं करता है ।

अब यह पता लगाने का समय है कि ऑडिट सेटिंग्स कहाँ संग्रहीत हैं। शुरू करने के लिए, हम कई अवधारणाएँ प्रस्तुत करते हैं:

1. प्रभावी ऑडिट नीतियां - रैम में संग्रहीत जानकारी जो ऑपरेटिंग सिस्टम मॉड्यूल के वर्तमान ऑपरेटिंग मापदंडों को निर्धारित करती है जो ऑडिट फ़ंक्शन को लागू करती है।
2. सहेजे गए ऑडिट नीतियों - HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv पर रजिस्ट्री में संग्रहीत जानकारी और सिस्टम रिबूट के बाद प्रभावी ऑडिट नीतियों को निर्धारित करने के लिए उपयोग किया जाता है।

हम विभिन्न प्रशासनिक उपकरणों पर विचार करेंगे और संकेत देंगे कि वे कौन से ऑडिट पैरामीटर प्रदर्शित करते हैं और जो सेट करते हैं। तालिका में डेटा प्रयोगों पर आधारित हैं।

आइए हम उदाहरण के साथ तालिका की व्याख्या करें।

उदाहरण 1

यदि आप ऑडिट सेटिंग्स देखने के लिए ऑडिटपोल चलाते हैं:
auditpol /get /category:* , फिर सहेजे गए ऑडिट पैरामीटर प्रदर्शित किए जाएंगे, अर्थात, जो रजिस्ट्री में HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv पर संग्रहीत हैं।

उदाहरण 2

यदि आप एक ही उपयोगिता चलाते हैं, लेकिन पहले से ही पैरामीटर सेट करने के लिए:
auditpol /set /category:* , प्रभावी ऑडिट सेटिंग्स और सहेजे गए ऑडिट सेटिंग्स को बदल दिया जाएगा।

एक अलग टिप्पणी के लिए उस आदेश की आवश्यकता होती है जिसमें ऑडिट सेटिंग "लोकल सिक्योरिटी पॉलिसीज" के "बेसिक ऑडिट पॉलिसियों" में दिखाई जाती हैं। मूल ऑडिट नीति की श्रेणी को सेट के रूप में प्रदर्शित किया जाता है, यदि संबंधित विस्तारित ऑडिट नीति के सभी उपश्रेणियाँ स्थापित की जाती हैं। यदि उनमें से कम से कम एक स्थापित नहीं है, तो नीति को स्थापित नहीं होने के रूप में प्रदर्शित किया जाएगा।

उदाहरण 3

auditpol /set /category:* कमांड का उपयोग करके, auditpol /set /category:* ने ऑडिट सक्सेस मोड में सभी ऑडिट उपश्रेणियों को सेट किया। इसके अलावा, यदि आप "स्थानीय सुरक्षा नीतियों" स्नैप-इन के "मूल ऑडिट नीतियों" पर जाते हैं, तो प्रत्येक श्रेणी के विपरीत सफलता का एक ऑडिट स्थापित किया जाएगा।

उदाहरण 4

अब प्रशासक ने auditpol /clear कमांड को auditpol /clear और सभी ऑडिट सेटिंग्स को रीसेट किया है। फिर उसने auditpol /set /subcategory:" " चलाकर फाइल सिस्टम ऑडिटिंग की auditpol /set /subcategory:" " । अब, यदि आप "स्थानीय सुरक्षा नीतियों" स्नैप-इन की "मूल ऑडिट नीतियों" पर जाते हैं, तो सभी श्रेणियों को "नो ऑडिट" राज्य में परिभाषित किया जाएगा, क्योंकि विस्तारित ऑडिट पॉलिसी की एक भी श्रेणी पूरी तरह से परिभाषित नहीं है।

अब, आखिरकार, हम इस सवाल का जवाब दे सकते हैं कि लॉग्स हौसले से स्थापित ऑपरेटिंग सिस्टम में कहां से आते हैं। बात यह है कि स्थापना के बाद, विंडोज में ऑडिट कॉन्फ़िगर किया गया है और सहेजे गए ऑडिट सेटिंग्स में परिभाषित किया गया है। आप auditpol /get /category:* कमांड चलाकर इसे सत्यापित कर सकते हैं।



स्नैप-इन स्थानीय सुरक्षा नीतियों की मूल ऑडिट नीतियों में, यह ऑडिट जानकारी प्रदर्शित नहीं की जाती है, क्योंकि सभी श्रेणियों में एक या अधिक उपश्रेणियाँ परिभाषित नहीं हैं। स्थानीय सुरक्षा नीतियों के उन्नत ऑडिट नीतियों में स्नैप-इन, यह जानकारी प्रदर्शित नहीं होती है क्योंकि स्नैप-इन केवल% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows \ NT \ लेखा परीक्षा \ Aud.csv फ़ाइल में संग्रहीत ऑडिट सेटिंग्स के साथ काम करता है।

समस्या का सार क्या है?

सबसे पहले यह लग सकता है कि यह सब एक समस्या नहीं है, लेकिन यह नहीं है। यह तथ्य कि सभी उपकरण ऑडिट मापदंडों को अलग-अलग तरीकों से दिखाते हैं, नीतियों के दुर्भावनापूर्ण हेरफेर के लिए अवसर बनाता है और, परिणामस्वरूप, ऑडिट परिणाम।

संभावित परिदृश्य पर विचार करें

बता दें कि कॉर्पोरेट नेटवर्क में विंडोज 7 पर आधारित एक तकनीकी वर्कस्टेशन काम करता है।

मशीन डोमेन में शामिल नहीं है और एक रोबोट के कार्यों को करता है जो प्रतिदिन नियामक अधिकारियों को रिपोर्ट भेजता है। एक तरह से या किसी अन्य पर हमलावरों को प्रशासक अधिकारों के साथ उस पर दूरस्थ पहुंच मिली। इसी समय, हमलावरों का मुख्य लक्ष्य जासूसी है, और कार्य प्रणाली में अनिर्धारित रहना है। हमलावरों ने गुप्त रूप से फैसला किया कि फ़ाइल एक्सेस ऑडिटिंग को अक्षम करने के लिए सुरक्षा लॉग में कोड 4719 "ऑडिट नीति में बदलाव" के साथ कोई घटना नहीं होनी चाहिए, लेकिन एक ही समय में सभी प्रशासन उपकरण कहते हैं कि ऑडिटिंग सक्षम है। कार्य को प्राप्त करने के लिए, उन्होंने निम्नलिखित क्रियाएं कीं:

1. हमला किए गए कार्य केंद्र पर, उन्होंने खुद को HKEY_LOCAL_MACHINE \ SECURITY \ नीति \ PolAdtEv रजिस्ट्री कुंजी को अनुमतियाँ दीं और इस कुंजी को "+ fs.reg" नामक फ़ाइल में निर्यात किया।
2. हमने इस फ़ाइल को दूसरे कंप्यूटर पर आयात किया, रिबूट किया, और फिर ऑडिटपोल का उपयोग करके फ़ाइल सिस्टम का ऑडिट बंद कर दिया, जिसके बाद हमने उपरोक्त रजिस्ट्री कुंजी को "-fs.reg" फ़ाइल में निर्यात किया।
3. हमला मशीन पर, "-fs.reg" फ़ाइल को रजिस्ट्री में आयात किया गया था।
4. हमने हमला किए गए मशीन पर स्थित% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ Aud.csv फ़ाइल का बैकअप लिया और फिर फ़ाइल सिस्टम उपश्रेणी को उसमें से हटा दिया।
5. उन्होंने हमला किए गए कार्य केंद्र को रिबूट किया, और फिर फ़ाइल% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ Audit.csv को बदल दिया और उस पर पहले से सहेजी गई बैकअप प्रतिलिपि के साथ फ़ाइल "fs.reg" भी आयात कर दी।

इन सभी जोड़तोड़ों के परिणामस्वरूप, सुरक्षा लॉग में कोई नीति परिवर्तन प्रविष्टियां नहीं हैं, सभी उपकरण दिखाते हैं कि ऑडिट सक्षम है, लेकिन वास्तव में यह काम नहीं करता है।

समस्या संख्या 2. फ़ाइलों, निर्देशिकाओं और रजिस्ट्री कुंजियों को हटाने के लिए संचालन का असफल लॉगिंग

Windows 7/10 / Server 2019 पर समस्या की पुष्टि की गई है।

समस्या का वर्णन

किसी फ़ाइल, निर्देशिका या रजिस्ट्री कुंजी को हटाने के लिए एक ऑपरेशन के लिए, ऑपरेटिंग सिस्टम कोड 4663 और 4660 के साथ घटनाओं का एक क्रम उत्पन्न करता है। समस्या यह है कि घटनाओं की पूरी धारा से, यह युगल एक-दूसरे से जुड़ना इतना आसान नहीं है। ऐसा करने के लिए, विश्लेषण की गई घटनाओं में निम्नलिखित पैरामीटर होने चाहिए:

घटना 1. कोड 4663 "ऑब्जेक्ट तक पहुंच प्राप्त करने का प्रयास किया गया था।" इवेंट पैरामीटर:
"ObjectType" = फ़ाइल।
"ObjectName" = फ़ाइल या निर्देशिका का नाम हटाया जाना।
"HandleId" = हटाए जाने के लिए फ़ाइल को संभालें।
"AcessMask" = 0x10000 (यह कोड DELETE ऑपरेशन से मेल खाता है। आप Microsoft वेबसाइट पर सभी ऑपरेशन कोड का डिक्रिप्शन पा सकते हैं)।



घटना 2. कोड 4660 "ऑब्जेक्ट डिलीट।"
इवेंट पैरामीटर:

"हैंडल" = "हैंडलेड इवेंट 1"
"सिस्टम \ EventRecordID" = "सिस्टम \ EventRecordID इवेंट 1" + 1 से।



रजिस्ट्री कुंजी (कुंजी) को हटाने के साथ, सब कुछ समान है, केवल पहली घटना में कोड 4663 के साथ, पैरामीटर "ObjectType" = कुंजी।

ध्यान दें कि रजिस्ट्री में मूल्यों को हटाने का वर्णन किसी अन्य ईवेंट (कोड 4657 ) द्वारा किया जाता है और इस तरह की समस्याओं का कारण नहीं बनता है।

विंडोज 10 और सर्वर 2019 में फ़ाइलों को हटाने की विशेषताएं

विंडोज 10 / सर्वर 2019 में, फ़ाइल को हटाने के दो तरीके हैं।

1. यदि फ़ाइल को कचरा में हटा दिया जाता है, तो, पहले की तरह, घटनाओं का क्रम 4663 और 4660।
2. यदि फ़ाइल स्थायी रूप से हटा दी जाती है (रीसायकल बिन को अतीत में), तो कोड 4659 के साथ एकल घटना के साथ।

एक विचित्र बात हुई। यदि पहले, हटाई गई फ़ाइलों को निर्धारित करने के लिए, 4663 और 4660 घटनाओं की निगरानी करना आवश्यक था, अब Microsoft "उपयोगकर्ताओं से मिलने गया" है, और दो घटनाओं के बजाय, अब हमें तीन पर नज़र रखने की आवश्यकता है। यह भी ध्यान देने योग्य है कि निर्देशिकाओं को हटाने की प्रक्रिया में बदलाव नहीं हुआ है, यह पहले की तरह, दो घटनाओं 4663 और 4660 के होते हैं।

समस्या का सार क्या है?

समस्या यह है कि फ़ाइल या निर्देशिका को हटाने का पता लगाना एक गैर-तुच्छ कार्य बन जाता है। सुरक्षा लॉग में संबंधित ईवेंट की प्रतिबंधात्मक खोज के बजाय, ईवेंट के अनुक्रम का विश्लेषण करना आवश्यक है, जो मैन्युअल रूप से करना मुश्किल है। इस बारे में हब्र पर भी एक लेख था: " Phellhell का उपयोग करके लॉग फ़ाइल में फ़ाइलों को हटाने और रिकॉर्डिंग की घटनाओं की ऑडिटिंग । "

समस्या संख्या 3 (महत्वपूर्ण)। फ़ाइलों, निर्देशिकाओं और रजिस्ट्री कुंजियों के लिए पुनर्नामित संचालन का असफल लॉगिंग

Windows 7/10 / Server 2019 पर समस्या की पुष्टि की गई है।

समस्या का वर्णन

इस समस्या के दो उपप्रकार हैं:

1. नाम बदलने के दौरान सिस्टम द्वारा उत्पन्न घटनाओं में, नया ऑब्जेक्ट नाम कहीं भी तय नहीं होता है।
2. नाम बदलने की प्रक्रिया विलोपन के समान है। यह केवल इस तथ्य से अलग किया जा सकता है कि कोड "AcessMask" = 0x10000 (DELETE) के साथ पहली घटना 4660 इवेंट नहीं है ।

यह ध्यान देने योग्य है कि रजिस्ट्री के संबंध में, यह समस्या केवल कुंजियों पर लागू होती है। रजिस्ट्री में मानों का नाम बदलना घटनाओं 4657 के अनुक्रम द्वारा वर्णित किया गया है और इस तरह की शिकायतों का कारण नहीं है, हालांकि, निश्चित रूप से, यह बहुत सुविधाजनक होगा यदि केवल एक घटना थी।

समस्या का सार क्या है?

फ़ाइल का नाम बदलने के संचालन के लिए खोज करने की कठिनाई के अलावा, जर्नलिंग की यह सुविधा फ़ाइल सिस्टम ऑब्जेक्ट्स या रजिस्ट्री कुंजी के पूर्ण जीवन चक्र को ट्रैक करने की अनुमति नहीं देती है। नतीजतन, एक फ़ाइल का इतिहास निर्धारित करना बेहद मुश्किल हो जाता है जिसे एक सक्रिय रूप से उपयोग किए जाने वाले फ़ाइल सर्वर पर कई बार नाम दिया गया है।

समस्या संख्या 4 (महत्वपूर्ण)। निर्देशिका और रजिस्ट्री कुंजी निर्माण ट्रैक करने में असमर्थ

Windows 7/10 / Server 2019 पर समस्या की पुष्टि की गई है।

समस्या का वर्णन

विंडोज एक फाइल सिस्टम निर्देशिका और रजिस्ट्री कुंजी के निर्माण को ट्रैक नहीं करता है। यह इस तथ्य में शामिल है कि ऑपरेटिंग सिस्टम एक ऐसी घटना उत्पन्न नहीं करता है जिसमें बनाई गई निर्देशिका या रजिस्ट्री कुंजी का नाम होगा, और जिसके मापदंडों से संकेत मिलेगा कि यह निर्माण ऑपरेशन है।

सैद्धांतिक रूप से, अप्रत्यक्ष संकेतों से, एक कैटलॉग बनाने का तथ्य संभव है। उदाहरण के लिए, यदि यह "एक्सप्लोरर" के माध्यम से बनाया गया था, तो निर्माण प्रक्रिया के दौरान, नई निर्देशिका की विशेषताओं के लिए मतदान कार्यक्रम उत्पन्न होंगे। समस्या यह है कि यदि आप mkdir कमांड के माध्यम से एक निर्देशिका बनाते हैं, तो कोई भी घटना उत्पन्न नहीं होती है। रजिस्ट्री में चाबियाँ बनाने के लिए सभी समान है।

समस्या का सार क्या है?

यह मुद्दा सूचना सुरक्षा घटनाओं की जांच करना बहुत मुश्किल बनाता है। इस तथ्य के लिए कोई उचित स्पष्टीकरण नहीं है कि यह जानकारी पत्रिकाओं में दर्ज नहीं है।

समस्या संख्या 5 (महत्वपूर्ण)। विंडोज के रूसी संस्करणों में खराब ऑडिट सेटिंग्स

विंडोज 7/10 / सर्वर 2019 के रूसी संस्करणों पर समस्या की उपस्थिति की पुष्टि की जाती है।

समस्या का वर्णन

विंडोज के रूसी संस्करणों में एक त्रुटि है जो सुरक्षा ऑडिट प्रबंधन प्रणाली को निष्क्रिय करती है।

लक्षण

उन्नत सुरक्षा नीतियों को बदलने से प्रभावी ऑडिट सेटिंग्स प्रभावित नहीं होती हैं, या, दूसरे शब्दों में, नीतियां लागू नहीं होती हैं। उदाहरण के लिए, व्यवस्थापक ने "लॉगिन" उपश्रेणी को सक्रिय किया, सिस्टम को रिबूट किया, auditpol /get /category:* कमांड चलाया, और यह उपश्रेणी auditpol /get /category:* बनी हुई है। समस्या समूह नीतियों और गैर-डोमेन कंप्यूटरों के माध्यम से प्रबंधित दोनों डोमेन कंप्यूटरों के लिए प्रासंगिक है और स्थानीय सुरक्षा नीतियों स्नैप-इन के माध्यम से कॉन्फ़िगर किए गए स्थानीय GPO का उपयोग करने में कामयाब रहे।

कारणों

यदि समस्या उन्नत ऑडिट नीतियों की "विफल" उपश्रेणियों में से कम से कम एक को सक्रिय कर देती है तो समस्या उत्पन्न होती है। ऐसी विफल श्रेणियां, विशेष रूप से, शामिल हैं:

1. अधिकारों का उपयोग -> गोपनीय डेटा को प्रभावित करने वाले अधिकारों के उपयोग की ऑडिट करें। GUID: {0cce9228-69ae-11d9-bed3-505054503030}।
2. अधिकारों का उपयोग -> उन अधिकारों के उपयोग का ऑडिट करें जो गोपनीय डेटा को प्रभावित नहीं करते हैं। GUID: {0cce9229-69ae-11d9-bed3-505054503030}।
3. वस्तुओं तक पहुंच -> अनुप्रयोगों द्वारा बनाई गई ऑडिट घटनाओं। GUID: {0cce9222-69ae-11d9-bed3-505054503030}।

समस्या को हल करने के लिए सिफारिशें

यदि समस्या अभी तक नहीं हुई है, तो संकेतित "विफल" उपश्रेणियों को सक्रिय न करें। यदि इन उपश्रेणियों की घटनाएं बहुत आवश्यक हैं, तो उन्हें सक्रिय करने के लिए ऑडिटपोल उपयोगिता का उपयोग करें या बुनियादी नीतियों का उपयोग करके ऑडिट का प्रबंधन करें।

यदि कोई समस्या होती है, तो आपको चाहिए:

1. डोमेन समूह नीति निर्देशिका से, फ़ाइल \ Machine \ microsoft \ windows nt \ Audit \ aud.csv हटाएं
2. ऑडिटिंग की समस्या वाले सभी कंप्यूटरों से, फ़ाइलों को हटा दें:% SystemRoot% \ Security \ ऑडिट \ Aud.csv,% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv

समस्या का सार क्या है?

इस समस्या की उपस्थिति उन्नत ऑडिट नीतियों के माध्यम से नियमित आधार पर निगरानी की जा सकने वाली सुरक्षा घटनाओं की संख्या को कम करती है, और कॉर्पोरेट नेटवर्क में ऑडिट सिस्टम के प्रबंधन को डिस्कनेक्ट, ब्लॉक, और अस्थिर करने के लिए खतरे भी पैदा करती है।

समस्या संख्या 6 (महत्वपूर्ण)। धिक्कार है "नया पाठ document.txt ... साथ ही नया बिटमैप। बीएमपी"

विंडोज 7 पर समस्या की पुष्टि की गई है। विंडोज 10 / सर्वर 2019 में समस्या गायब है।

समस्या का वर्णन

यह एक बहुत ही अजीब समस्या है जिसे दुर्घटना से पता चला था। समस्या का सार यह है कि ऑपरेटिंग सिस्टम में एक खामी है जो आपको फ़ाइलों को बनाने के ऑडिट को बायपास करने की अनुमति देती है।

प्रारंभिक भाग:

1. एक ताजा स्थापित विंडोज 7 लें।
2. auditpol /clear कमांड का उपयोग करके सभी ऑडिट सेटिंग्स को रीसेट करें। यह आइटम वैकल्पिक है और केवल पत्रिकाओं के विश्लेषण की सुविधा के लिए कार्य करता है।
3. हम auditpol /set /subcategory:" " चलाकर फाइल सिस्टम ऑडिटिंग auditpol /set /subcategory:" " ।
4. आइए C: \ TEST निर्देशिका बनाएं और "सब कुछ" खाते के लिए ऑडिट पैरामीटर असाइन करें: "फ़ाइलें बनाएँ / डेटा लिखें", "फ़ोल्डर बनाएँ / डेटा लिखें", "विशेषताएँ लिखें", "अतिरिक्त विशेषताएँ लिखें", "सबफ़ोल्डर और हटाएँ" फ़ाइलें "," हटाएं "," अनुमतियों का परिवर्तन "," स्वामित्व का परिवर्तन ", अर्थात, फ़ाइल सिस्टम में डेटा लिखने से संबंधित सब कुछ।

स्पष्टता के लिए, प्रत्येक प्रयोग से पहले, हम ऑपरेटिंग सिस्टम के सुरक्षा लॉग को साफ़ कर देंगे।

प्रयोग १।
हम करते हैं:

कमांड लाइन से, कमांड निष्पादित करें: echo > "c:\test\ .txt"
हम निरीक्षण करते हैं:

फ़ाइल के निर्माण पर, कोड 4663 के साथ एक घटना सुरक्षा लॉग में दिखाई दी जिसमें फ़ाइल का नाम "ObjectName" फ़ील्ड में बनाया जा रहा है और "AccessMask" फ़ील्ड में 0x2 ("डेटा लिखना या फ़ाइल जोड़ना")।



निम्नलिखित प्रयोगों को करने के लिए, हम फ़ोल्डर और ईवेंट लॉग को साफ़ करते हैं।

प्रयोग २।
हम करते हैं:

एक्सप्लोरर के माध्यम से C: \ TEST फ़ोल्डर खोलें और राइट-क्लिक करके कॉन्टेक्स्ट मेनू "क्रिएट -> टेक्स्ट डॉक्यूमेंट" का उपयोग करें, फाइल "न्यू टेक्स्ट डॉक्यूमेंट.टेक्स्ट" बनाएँ।



हम निरीक्षण करते हैं:

यह क्रिया ईवेंट लॉग में परिलक्षित नहीं हुई थी !!! साथ ही, "बिटमैप" बनाने के लिए समान संदर्भ मेनू का उपयोग करने पर कोई प्रविष्टि नहीं होगी।



प्रयोग ३।
हम करते हैं:

एक्सप्लोरर का उपयोग करके, फ़ोल्डर को खोलें C: \ TEST और संदर्भ मेनू का उपयोग करके "आरटीएफ प्रारूप में" बनाएं -> दस्तावेज़ ", राइट-क्लिक करके कहा जाता है," आरटीएफ.आरटीएफ प्रारूप में नया दस्तावेज़ "फ़ाइल बनाएं।

हम निरीक्षण करते हैं:

जैसा कि कमांड लाइन के माध्यम से फ़ाइल के निर्माण के मामले में, कोड 4663 और इसी सामग्री के साथ एक घटना लॉग में दिखाई दी।

समस्या का सार क्या है?

बेशक, पाठ दस्तावेज़ या चित्र बनाना विशेष रूप से हानिकारक नहीं है। हालांकि, यदि "एक्सप्लोरर" फ़ाइल संचालन के लॉगिंग को बायपास करने में सक्षम है, तो मैलवेयर ऐसा करने में सक्षम होगा।

यह समस्या शायद सभी में सबसे महत्वपूर्ण मानी जाती है, क्योंकि यह गंभीरता से फ़ाइल संचालन के ऑडिट के परिणामों की विश्वसनीयता को कम करती है।

निष्कर्ष

समस्याओं की उपरोक्त सूची संपूर्ण नहीं है। इस प्रक्रिया में, हम अभी भी काफी बड़ी संख्या में विभिन्न छोटी-मोटी खामियों पर काबू पाने में कामयाब रहे, जिनमें कई घटनाओं के लिए पैरामीटर मान के रूप में स्थानीयकृत स्थिरांक का उपयोग शामिल है, जो हमें ऑपरेटिंग सिस्टम के प्रत्येक स्थानीयकरण के लिए हमारी विश्लेषण करने वाली स्क्रिप्ट लिखने के लिए मजबूर करता है, जो घटनाओं के अतार्किक विभाजन को संचालन में है जो अर्थ में करीब हैं। उदाहरण के लिए, एक रजिस्ट्री कुंजी को हटाना 4663 और 4660 की घटनाओं का एक क्रम है, और रजिस्ट्री में एक मूल्य को हटाना 4657, ठीक है, और यहां तक ​​कि छोटी चीजें भी हैं ...

निष्पक्षता में, हम ध्यान दें कि सभी कमियों के बावजूद, विंडोज में सुरक्षा ईवेंट लॉगिंग सिस्टम में बड़ी संख्या में सकारात्मक पहलू हैं। यहां सूचीबद्ध महत्वपूर्ण मुद्दों को ठीक करने से बॉक्स के बाहर सुरक्षा घटनाओं को लॉग करने के लिए बेहतर समाधान के लिए ताज वापस आ सकता है।

बनाने के लिए सुरक्षा सुरक्षा महान आग लग रही है!