نظام ويندوز الأمن تسجيل الأحداث القضايا



تحتوي أنظمة تشغيل Windows على نظام تسجيل أحداث أمان جيد جدًا. تمت كتابة الكثير من الأشياء الجيدة عنها في العديد من المنشورات والمراجعات ، ولكن هذا المقال سيكون حول شيء آخر. هنا نتحدث عن المشاكل وأوجه القصور في هذا النظام. ستكون بعض المشكلات التي تم بحثها غير حرجة ، مما يؤدي إلى تعقيد إجراءات تحليل الأحداث فقط ، بينما ستشكل مشكلات أخرى تهديدات أمنية خطيرة للغاية.

تم اختبار المشكلات التي تم تحديدها في Windows 7 Maximum (النسخة الروسية) ، و Windows 7 Professional (النسخة الإنجليزية) ، و Windows 10 Pro (النسخة الروسية) ، و Windows Server 2019 Datacenter (النسخة الروسية). تم تحديث جميع أنظمة التشغيل بالكامل.

المشكلة رقم 1. فشل نظام إدارة المعلمة التدقيق


تم تأكيد المشكلة على Windows 7/10 / Server 2019.

وصف المشكلة


خذ ويندوز 7 وتثبيته مع الإعدادات الافتراضية. لن ندخل المجال. لنرى إعدادات تدقيق حدث الأمان. للقيام بذلك ، افتح الأداة الإضافية لسياسات الأمان المحلية (secpol.msc أو لوحة التحكم -> أدوات إدارية -> سياسات الأمان المحلية) وانظر إلى إعدادات التدقيق الأساسية (إعدادات الأمان -> السياسات المحلية -> سياسات التدقيق) ).



كما ترون ، لم يتم تكوين التدقيق. الآن دعونا نرى سياسات التدقيق المتقدمة ("إعدادات الأمان -> تكوين سياسة التدقيق المتقدمة -> سياسات تدقيق النظام - كائن سياسة المجموعة المحلية").



هنا لم يتم تكوين التدقيق سواء. إذا كان الأمر كذلك ، فمن الناحية النظرية ، يجب ألا يكون هناك أي أحداث أمان في السجلات. نحن نتحقق. افتح سجل الأمان (eventvwr.exe ، أو "لوحة التحكم -> أدوات إدارية -> عرض الأحداث").



السؤال: "من أين يأتي الحدث في سجل الأمان إذا لم يتم تكوين التدقيق على الإطلاق؟!"

تفسير


لفهم سبب هذا السلوك ، تحتاج إلى الحصول على "غطاء محرك السيارة" لنظام التشغيل. بادئ ذي بدء ، سنتعامل مع سياسات التدقيق الأساسية والمتقدمة.

قبل نظام التشغيل Windows Vista ، كانت هناك سياسة تدقيق واحدة فقط ، والتي تسمى الآن الأساسية. كانت المشكلة أن دقة إدارة التدقيق في ذلك الوقت كانت منخفضة للغاية. لذلك ، إذا كان مطلوبًا لتتبع الوصول إلى الملفات ، فإنها تتضمن فئة السياسة الأساسية "تدوين الوصول إلى الكائنات". نتيجةً لذلك ، بالإضافة إلى عمليات الملفات ، سكبت مجموعة من أحداث "الضوضاء" الأخرى في سجل الأمان. هذا تعقيد كبير في معالجة سجلات والمستخدمين الأعصاب.

سمعت مايكروسوفت هذا "الألم" وقررت المساعدة. المشكلة هي أن Windows مبني على مفهوم التوافق مع الإصدارات السابقة ، وإجراء تغييرات على آلية إدارة التدقيق الحالية كان من شأنه أن يؤدي إلى قتل هذا التوافق. لذلك ، ذهب البائع في الاتجاه الآخر. ابتكر أداة جديدة وسماها سياسات التدقيق المتقدمة.

يكمن جوهر الأداة في حقيقة أن فئات السياسة المتقدمة قد تم إنشاؤها من فئات سياسات التدقيق الأساسية ، وأن هذه ، بدورها ، تم تقسيمها إلى فئات فرعية يمكن تشغيلها وإيقافها بشكل فردي. الآن ، إذا كنت بحاجة إلى تتبع الوصول إلى الملفات في سياسات التدقيق المتقدمة ، فأنت بحاجة إلى تنشيط الفئة الفرعية "نظام الملفات" فقط ، والتي يتم تضمينها في فئة "الوصول إلى الكائنات". في الوقت نفسه ، لن يتم إدراج أحداث "الضوضاء" المتعلقة بالوصول إلى السجل أو تصفية حركة مرور الشبكة في سجل الأمان.

سبب الالتباس الهائل في هذا المخطط بالكامل هو أن أسماء فئات سياسات التدقيق الأساسية والمتقدمة لا تتزامن ، وقد يبدو في البداية أن هذه أشياء مختلفة تمامًا ، لكن هذا ليس كذلك.

فيما يلي جدول مطابق لأسماء الفئات الأساسية والمتقدمة لإدارة التدقيق
اسم سياسات المراجعة الأساسيةاسم سياسة التدقيق الموسعة
دليل الوصول إلى خدمة التدقيقالوصول إلى خدمة الدليل (DS)
كائن تدقيق الوصولالوصول إلى المرافق
امتياز التدقيقاستخدام الحقوق
تسجيل الدخول التدقيقالدخول / الخروج
مراجعة أحداث تسجيل الدخولتسجيل الدخول إلى الحساب
تغييرات سياسة التدقيقتغيير السياسة
أحداث نظام التدقيقالنظام
تدقيق إدارة الحسابإدارة الحساب
تتبع عملية المراجعةتتبع مفصل

من المهم أن نفهم أن كلا من الفئات الأساسية والمتقدمة تتحكم بشكل أساسي في نفس الشيء. يؤدي إدراج فئة سياسة التدقيق الأساسية إلى إدراج فئة سياسة التدقيق الموسعة المقابلة ، وبالتالي جميع فئاتها الفرعية. لتجنب العواقب غير المتوقعة ، لا توصي Microsoft باستخدام سياسات التدقيق الأساسية والمتقدمة في نفس الوقت.

الآن هو الوقت المناسب لمعرفة مكان تخزين إعدادات التدقيق. بادئ ذي بدء ، نقدم عددًا من المفاهيم:

  1. سياسات التدقيق الفعالة - المعلومات المخزنة في ذاكرة الوصول العشوائي والتي تحدد معلمات التشغيل الحالية لوحدات نظام التشغيل التي تنفذ وظائف التدقيق.
  2. سياسات التدقيق المحفوظة - المعلومات المخزنة في السجل على HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv وتستخدم لتحديد سياسات التدقيق الفعالة بعد إعادة تشغيل النظام.

سننظر في الأدوات الإدارية المختلفة ونشير إلى معايير التدقيق التي يعرضونها وأي مجموعة. تستند البيانات الموجودة في الجدول إلى التجارب.
اسم الأموالسياسات التدقيق المعروضةسياسات التدقيق المستمرة
سياسات التدقيق الأساسية لسياسات الأمان المحليةسياسات التدقيق الفعالةسياسات التدقيق الفعالة ، سياسات المراجعة المحفوظة
سياسات التدقيق المتقدمة لسياسات الأمان المحليةملف %SystemRoot%\System32\GroupPolicy\Machine\Microsoft\Windows NT\Audit\audit.csv
Auditpol فائدةإعدادات التدقيق المحفوظةضبط التدقيق الفعال ، حفظ إعدادات التدقيق

دعونا شرح الجدول مع أمثلة.

مثال 1

إذا قمت بتشغيل auditpol لعرض إعدادات التدقيق:
auditpol /get /category:* ، سيتم عرض معلمات المراجعة المحفوظة ، أي المعلمات المخزنة في السجل على HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv.

مثال 2

إذا قمت بتشغيل الأداة المساعدة نفسها ، ولكن بالفعل لضبط المعلمات:
auditpol /set /category:* ، سيتم تغيير إعدادات التدقيق الفعالة وإعدادات التدقيق المحفوظة.

يتطلب تعليق منفصل الترتيب الذي يتم به عرض إعدادات التدقيق في "سياسات التدقيق الأساسية" الخاصة بـ "سياسات الأمان المحلية" الإضافية. يتم عرض فئة سياسة التدقيق الأساسية على النحو المحدد إذا تم تثبيت جميع الفئات الفرعية لسياسة التدقيق الموسعة المقابلة. إذا لم يتم تثبيت واحد على الأقل ، فسيتم عرض السياسة على أنها غير مثبتة.

مثال 3

باستخدام الأمر auditpol /set /category:* ، قام auditpol /set /category:* بتعيين جميع فئات التدقيق الفرعية على وضع تدقيق النجاح. علاوة على ذلك ، إذا ذهبت إلى "سياسات التدقيق الأساسية" الخاصة بـ "سياسات الأمان المحلية" الإضافية ، فسيتم تثبيت تدقيق النجاح مقابل كل فئة.

مثال 4

الآن قام المسؤول auditpol /clear وإعادة تعيين جميع إعدادات التدقيق. ثم قام بإعداد تدقيق نظام الملفات عن طريق تشغيل auditpol /set /subcategory:" " . الآن ، إذا انتقلت إلى "سياسات التدقيق الأساسية" الخاصة بـ "سياسات الأمان المحلية" الإضافية ، فسيتم تحديد جميع الفئات في حالة "عدم التدقيق" ، حيث لا يتم تعريف فئة واحدة من سياسة التدقيق الموسعة بالكامل.

الآن ، أخيرًا ، يمكننا الإجابة على سؤال حول مصدر السجلات في نظام التشغيل المثبت حديثًا. الشيء هو أنه بعد التثبيت ، يتم تكوين التدقيق في Windows وتعريفه في إعدادات التدقيق المحفوظة. يمكنك التحقق من ذلك عن طريق تشغيل الأمر auditpol /get /category:* .



في سياسات التدقيق الأساسية لسياسات الأمان المحلية الإضافية ، لا يتم عرض معلومات التدقيق هذه ، لأن فئة فرعية واحدة أو أكثر غير محددة في جميع الفئات. في "نُهج التدقيق المتقدمة لسياسات الأمان المحلية" الإضافية ، لا يتم عرض هذه المعلومات لأن الأداة الإضافية تعمل فقط مع إعدادات التدقيق المخزنة في ملف٪ SystemRoot٪ \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv.

ما هو جوهر المشكلة؟


في البداية قد يبدو أن كل هذا ليس مشكلة على الإطلاق ، لكنه ليس كذلك. حقيقة أن جميع الأدوات تُظهر معلمات التدقيق بطرق مختلفة تخلق فرصة للتلاعب الخبيث بالسياسات ، ونتيجة لذلك ، نتائج التدقيق.

النظر في السيناريو المحتمل

دع محطة عمل تقنية قائمة على Windows 7 تعمل في شبكة الشركة.

لا يتم تضمين الجهاز في المجال ويقوم بوظائف الروبوت الذي يرسل التقارير يوميًا إلى السلطات التنظيمية. حصل المهاجمون بطريقة أو بأخرى على إمكانية الوصول عن بُعد باستخدام حقوق المسؤول. في الوقت نفسه ، فإن الهدف الرئيسي للمهاجمين هو التجسس ، والمهمة هي أن تظل غير مكتشفة في النظام. قرر المهاجمون سرًا عدم وجود أحداث برمز 4719 "تغييرات سياسة التدقيق" في سجل الأمان ، وقم بتعطيل تدقيق الوصول إلى الملفات ، ولكن في الوقت نفسه تقول جميع أدوات الإدارة أن التدقيق قد تم تمكينه. لإنجاز المهمة ، قاموا بتنفيذ الإجراءات التالية:

  1. على محطة العمل التي تمت مهاجمتها ، منحوا أذونات الكتابة لأنفسهم لمفتاح التسجيل HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv وقاموا بتصدير هذا المفتاح إلى ملف باسم "+ fs.reg".
  2. لقد قمنا باستيراد هذا الملف على كمبيوتر آخر ، ثم أعيد تشغيله ، ثم أوقفنا تدقيق نظام الملفات باستخدام auditpol ، وبعد ذلك قمنا بتصدير مفتاح التسجيل أعلاه إلى ملف "-fs.reg".
  3. على الجهاز الذي تمت مهاجمته ، تم استيراد الملف "-fs.reg" إلى السجل.
  4. قمنا بنسخ نسخة احتياطية من الملف٪ SystemRoot٪ \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.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 "كائن محذوف".
معلمات الحدث:

"HandleId" = "أحداث HandleId 1"
"System \ EventRecordID" = "System \ EventRecordID من الحدث 1" + 1.



مع إزالة مفتاح التسجيل (مفتاح) ، كل شيء هو نفسه ، فقط في الحدث الأول مع رمز 4663 ، المعلمة "ObjectType" = مفتاح.

لاحظ أن إزالة القيم في السجل تم وصفه بواسطة حدث آخر (الرمز 4657 ) ولا يسبب مثل هذه المشكلات.

ميزات حذف الملفات في Windows 10 و Server 2019


في Windows 10 / Server 2019 ، هناك طريقتان لحذف ملف.

  1. إذا تم حذف الملف إلى سلة المهملات ، فكما حدث من قبل ، تسلسل الأحداث 4663 و 4660.
  2. إذا تم حذف الملف نهائيًا (بعد سلة المحذوفات) ، فحينها حدث واحد برمز 4659 .

حدث شيء غريب. إذا كان في وقت سابق ، لتحديد الملفات المحذوفة ، فقد كان من الضروري مراقبة مجمل الأحداث 4663 و 4660 ، والآن أصبحت Microsoft "ذهبت لمقابلة المستخدمين" ، وبدلاً من حدثين ، نحتاج الآن إلى مراقبة ثلاثة. تجدر الإشارة أيضًا إلى أن إجراء حذف الدلائل لم يتغير ؛ كما حدث من قبل ، يتكون من حدثين 4663 و 4660.

ما هو جوهر المشكلة؟


المشكلة هي أن معرفة من قام بحذف الملف أو الدليل يصبح مهمة غير تافهة. بدلاً من البحث العادي عن الحدث المقابل في سجل الأمان ، من الضروري تحليل تسلسل الأحداث ، وهو أمر شاق جدًا للقيام به يدويًا. على habr حتى حول هذا الموضوع ، كان هناك مقال: "تدقيق الإزالة والوصول إلى الملفات وتسجيل الأحداث في ملف سجل باستخدام Powershell . "

المشكلة رقم 3 (حرجة). تسجيل غير ناجح لعملية إعادة تسمية الملفات والدلائل ومفاتيح التسجيل


تم تأكيد المشكلة على Windows 7/10 / Server 2019.

وصف المشكلة


هذه المشكلة لها جهازي مشاكل فرعية:

  1. في الأحداث التي تم إنشاؤها بواسطة النظام أثناء إعادة التسمية ، لم يتم إصلاح اسم الكائن الجديد في أي مكان.
  2. يشبه إجراء إعادة التسمية الحذف. يمكن تمييزه فقط بحقيقة أن الحدث الأول بالكود 4663 ، مع المعلمة "AcessMask" = 0x10000 (DELETE) لا يحتوي على الحدث 4660.

تجدر الإشارة إلى أنه فيما يتعلق بالسجل ، تنطبق هذه المشكلة فقط على المفاتيح. يوصف إعادة تسمية القيم في السجل بتسلسل الأحداث 4657 ولا يسبب مثل هذه الشكاوى ، على الرغم من أنه بالطبع سيكون أكثر ملاءمة إذا كان هناك حدث واحد فقط.

ما هو جوهر المشكلة؟


بالإضافة إلى صعوبة البحث عن عمليات إعادة تسمية الملفات ، لا تسمح ميزة دفتر اليومية هذه بتتبع دورة الحياة الكاملة لكائنات نظام الملفات أو مفاتيح التسجيل. نتيجة لذلك ، يصبح من الصعب للغاية تحديد محفوظات الملف الذي تمت إعادة تسميته عدة مرات على خادم ملفات نشط.

المشكلة رقم 4 (حرجة). غير قادر على تتبع دليل وإنشاء مفتاح التسجيل


تم تأكيد المشكلة على Windows 7/10 / Server 2019.

وصف المشكلة


لا يتعقب Windows إنشاء دليل نظام الملفات ومفتاح التسجيل. يتكون هذا من حقيقة أن نظام التشغيل لا ينشئ حدثًا من شأنه أن يحتوي على اسم الدليل الذي تم إنشاؤه أو مفتاح التسجيل ، وأن معلماته تشير إلى أن هذه هي عملية الإنشاء.

من الناحية النظرية ، من خلال علامات غير مباشرة ، فإن حقيقة إنشاء كتالوج أمر ممكن. على سبيل المثال ، إذا تم إنشاؤه من خلال "Explorer" ، فعند عملية الإنشاء ، سيتم إنشاء أحداث الاقتراع لسمات الدليل الجديد. المشكلة هي أنه إذا قمت بإنشاء دليل من خلال الأمر mkdir ، فلن يتم إنشاء أي أحداث على الإطلاق. كل نفس صحيح لإنشاء مفاتيح في التسجيل.

ما هو جوهر المشكلة؟


تجعل هذه المشكلة من الصعب للغاية التحقيق في حوادث أمن المعلومات. لا يوجد تفسير معقول لحقيقة أن هذه المعلومات غير مسجلة في الصحف.

المشكلة رقم 5 (حرجة). إعدادات التدقيق سيئة في الإصدارات الروسية من ويندوز


تأكيد وجود المشكلة في الإصدارات الروسية من Windows 7/10 / Server 2019.

وصف المشكلة


يوجد خطأ في إصدارات Windows الروسية يجعل نظام إدارة تدقيق الأمان غير فعال.

الأعراض


لا يؤثر تغيير سياسات الأمان المتقدمة على إعدادات التدقيق الفعالة ، أو بمعنى آخر ، لا يتم تطبيق السياسات. على سبيل المثال ، قام المسؤول بتنشيط الفئة الفرعية "تسجيل الدخول" ، وإعادة تشغيل النظام ، وتشغيل الأمر auditpol /get /category:* ، وتظل هذه الفئة الفرعية auditpol /get /category:* . المشكلة ذات صلة بكل من أجهزة كمبيوتر المجال التي تتم إدارتها من خلال سياسات المجموعة وأجهزة الكمبيوتر غير التابعة التي تتم إدارتها باستخدام كائن نهج محلي محلي تم تكوينه من خلال الأداة الإضافية لسياسات الأمان المحلية.

أسباب


تنشأ المشكلة إذا قام المسؤول بتنشيط واحدة على الأقل من الفئات الفرعية "الفاشلة" لسياسات التدقيق المتقدمة. وتشمل هذه الفئات الفاشلة ، على وجه الخصوص ، ما يلي:

  1. استخدام الحقوق -> تدقيق استخدام الحقوق التي تؤثر على البيانات السرية. GUID: {0cce9228-69ae-11d9-bed3-505054503030}.
  2. استخدام الحقوق -> تدقيق استخدام الحقوق التي لا تؤثر على البيانات السرية. GUID: {0cce9229-69ae-11d9-bed3-505054503030}.
  3. الوصول إلى الكائنات -> تدوين الأحداث التي أنشأتها التطبيقات. GUID: {0cce9222-69ae-11d9-bed3-505054503030}.

توصيات لحل المشكلة


إذا لم تحدث المشكلة بعد ، فلا تقم بتنشيط الفئات الفرعية "الفاشلة" المشار إليها. إذا كانت أحداث هذه الفئات الفرعية ضرورية للغاية ، فاستخدم الأداة Auditpol لتنشيطها أو إدارة التدقيق باستخدام السياسات الأساسية.

في حالة حدوث مشكلة ، يجب عليك:

  1. من دليل سياسة مجموعة المجال ، احذف ملف \ Machine \ microsoft \ windows nt \ Audit \ audit.csv
  2. من جميع أجهزة الكمبيوتر التي تواجه مشكلات في التدقيق ، احذف الملفات:٪ SystemRoot٪ \ security \ audit \ audit.csv ،٪ SystemRoot٪ \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv

ما هو جوهر المشكلة؟


يقلل وجود هذه المشكلة من عدد أحداث الأمان التي يمكن مراقبتها بشكل منتظم من خلال سياسات التدقيق المتقدمة ، كما أنه يخلق تهديدات بقطع إدارة نظام التدقيق في شبكة الشركة وحظره وزعزعة استقراره.

المشكلة رقم 6 (حرجة). اللعنة "New text document.txt ... وكذلك bitmap.bmp جديد"


تم تأكيد المشكلة على Windows 7. المشكلة مفقودة في Windows 10 / Server 2019.

وصف المشكلة


هذه مشكلة غريبة للغاية تم اكتشافها عن طريق الصدفة. جوهر المشكلة هو أن نظام التشغيل يحتوي على ثغرة تسمح لك بتجاوز تدقيق إنشاء الملفات.

الجزء التحضيري:

  1. خذ ويندوز 7 المثبتة حديثا.
  2. إعادة ضبط جميع إعدادات التدقيق باستخدام الأمر auditpol /clear . هذا العنصر اختياري ويعمل فقط من أجل راحة تحليل المجلات.
  3. قمنا بإعداد تدقيق نظام الملفات عن طريق تشغيل auditpol /set /subcategory:" " .
  4. لنقم بإنشاء دليل C: \ TEST وتعيين معلمات التدقيق لحساب "كل شيء": "إنشاء ملفات / كتابة بيانات" ، "إنشاء مجلدات / كتابة بيانات" ، "كتابة سمات" ، "كتابة سمات إضافية" ، "حذف مجلدات فرعية و ملفات "،" حذف "،" تغيير الأذونات "،" تغيير الملكية "، أي كل ما يتعلق بكتابة البيانات إلى نظام الملفات.

من أجل الوضوح ، قبل كل تجربة ، سنقوم بمسح سجل الأمان لنظام التشغيل.

التجربة 1.
نحن نفعل:

من سطر الأوامر ، قم بتنفيذ الأمر: echo > "c:\test\ .txt"
نلاحظ:

عند إنشاء الملف ، ظهر حدث برمز 4663 في سجل الأمان الذي يحتوي على اسم الملف الذي يتم إنشاؤه في حقل "ObjectName" و 0x2 في حقل "AccessMask" ("كتابة البيانات أو إضافة ملف").



لإجراء التجارب التالية ، نقوم بمسح المجلد وسجل الأحداث.

التجربة 2.
نحن نفعل:

افتح المجلد C: \ TEST من خلال "Explorer" واستخدم قائمة السياق "إنشاء -> نص مستند" ، التي تم استدعاؤها بالنقر بزر الماوس الأيمن ، وقم بإنشاء ملف "New Text Document.txt".



نلاحظ:

لم ينعكس هذا الإجراء في سجل الأحداث !!! أيضًا ، لن يكون هناك أي إدخالات في حالة استخدام قائمة السياق نفسها لإنشاء "صورة نقطية".



التجربة 3.
نحن نفعل:

باستخدام Explorer ، افتح المجلد C: \ TEST وباستخدام قائمة السياق "إنشاء -> مستند بتنسيق RTF" ، يسمى بالنقر بزر الماوس الأيمن ، قم بإنشاء ملف "مستند جديد بتنسيق RTF.rtf."

نلاحظ:

كما هو الحال مع إنشاء الملف من خلال سطر الأوامر ، ظهر حدث برمز 4663 والمحتوى المقابل في السجل.



ما هو جوهر المشكلة؟


بالطبع ، إنشاء مستندات نصية أو صور ليس ضارًا بشكل خاص. ومع ذلك ، إذا كان "Explorer" قادرًا على تجاوز تسجيل عمليات الملفات ، فسيكون بإمكان البرامج الضارة القيام بذلك.

ربما تكون هذه المشكلة هي الأهم من ذلك كله نظرًا لأنه يقوض بشكل خطير مصداقية نتائج تدقيق عمليات الملفات.

استنتاج


قائمة المشاكل المذكورة أعلاه ليست شاملة. في هذه العملية ، تمكنا من التعثر بعدد كبير جدًا من العيوب الطفيفة المختلفة ، والتي تشمل استخدام الثوابت المترجمة كقيم المعلمات لعدد من الأحداث ، مما يفرض علينا كتابة البرامج النصية التحليلية لكل تعريب لنظام التشغيل ، التقسيم غير المنطقي لرموز الأحداث إلى عمليات قريبة من المعنى ، على سبيل المثال ، يعد حذف مفتاح التسجيل سلسلة من الأحداث 4663 و 4660 ، وحذف قيمة في السجل هو 4657 ، جيدًا ، وحتى الأشياء الصغيرة ...

في الإنصاف ، نلاحظ أنه على الرغم من جميع أوجه القصور ، فإن نظام تسجيل الأحداث الأمنية في Windows لديه عدد كبير من الجوانب الإيجابية. يمكن أن يؤدي إصلاح المشكلات الحرجة المدرجة هنا إلى إعادة التاج إلى حل أفضل لتسجيل أحداث الأمان خارج الصندوق.

جعل WINDOWS الأحداث الأمنية تسجيل عظيم مرة أخرى!

Source: https://habr.com/ru/post/ar476464/


All Articles