كيفية منع المشرفين من الوصول إلى السجلات من أنشطتهم الخاصة؟

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

قد يكون أحد الحلول هو منع جميع الحسابات الأساسية من الوصول إلى السجلات. تتم إدارة السجلات فقط من خلال العمليات المصرح بها على خوادم معينة من logrotate ، و syslog ، وجميع عناصر SIEM. لذا ، تستطيع شركة SOC فقط قراءة سجلات المشرفين وتحليلها. يمكن فقط إزالة عملية إزالة السجلات القديمة. يمكن لأي شخص أن يؤكد أن هذا ممكن؟

هل من الممكن أن يكون هناك شيء أكثر مرونة حيث يمكن للمسؤولين ذوي امتيازات الجذر الخاصة بهم قراءة سجلات حسابات الجذر الأخرى؟

26
*. */dev/lp0 .
وأضاف المؤلف Mike Caron, مصدر
لا ، كان من الواضح بالنسبة لي في الوصف الأولي أن السجلات كانت مركزية: "تتم إدارة السجلات على ملقمات محددة" . ولكن يبدو أنني كنت مخطئا. أقترح إزالة حسابي EDIT ، حدد أحد الإجابات ، وفتح سؤال جديد مستهدف على خادم السجل. ما رأيك هو الأفضل؟
وأضاف المؤلف Steve Powell, مصدر
لماذا ا؟ يمكن للمسؤولين عادة الوصول إلى خادم السجل المركزي. منع مسؤول الوصول إلى أو تعديل آثاره الخاصة ليست واضحة حتى مع ACL و SELinux. إجابتك §2 تبدو في الطريق الصحيح. مثال مفصل سيكون موضع ترحيب.
وأضاف المؤلف Steve Powell, مصدر
أوافق على أن تكون السجلات مركزية. فيما يتعلق بطلب مرن ، ماذا عن استرجاع أو نسخ كل حدث إداري يقدمه التدقيق في ملف سجل مخصص لهذا الحساب الإداري وإدارة الوصول إلى ملفات السجل هذه بسياسة تمنع أحد المشرفين من الوصول إلى سجلاته باستخدام مساعدة من SELinux؟ سوف يتم إجراء الاسترداد أو النسخ عن طريق قول 1 وظيفة كرون.
وأضاف المؤلف Steve Powell, مصدر
لن يتمكن مسؤول الخادم تلقائيًا من الوصول إلى أي شيء على خادم السجل. إذا كنت تتحدث عن تقييد وصول المستخدم الجذر لخادم السجل إلى خادم السجل ، فسيكون وصفك لحقيقة أن سجلاتك مركزية. وحتى إجابتي المقترحة أدناه غير مجدية. يبدو أنك قمت بالفعل بتغيير الجوانب الأساسية لسؤالك بعد تلقي الإجابات.
وأضاف المؤلف schroeder, مصدر
مع إضافة حقيقة أن لديك بالفعل مركزية قطع الأشجار ، فإن بقية التفاصيل لا معنى لها.
وأضاف المؤلف schroeder, مصدر
الإصدار العام للأجوبة: يجب أن يحدث أي سجل في موقع لا يمكن الوصول إليه للكيان الذي تم تسجيله . في حالة وجود جذور لينكس ، فهذا يعني بشكل أساسي تسجيل الدخول عن بعد إلى خوادم أخرى. لذلك سيكون قادراً على إيقاف تشغيل السجل ، ولكن ليس لإخفاء أثره قبل ذلك (بما في ذلك الخروج من التسجيل) ، إلا إذا كان يفعل ذلك بذكاء شديد.
وأضاف المؤلف peterh, مصدر
لدى Windows إصدار RBAC. أنا لست رجل نوافذ ، لذلك سيكون عليك البحث عن التفاصيل بنفسك ، ولكن قد يكون من المفيد التحقق من ذلك كبديل.
وأضاف المؤلف Tom, مصدر

6 إجابة

الحل المقبول لهذا هو عدم تخزين السجلات محليًا ، ولكن على خادم سجلات. بمجرد وجود السجلات ، يمكنك تقييد أو تقييد الوصول كما تراه مناسبًا.

في بعض حلول ملقم/تجميع السجل ، يمكنك تقييد مستخدم من رؤية الإدخالات التي تحتوي على مراجع لبيانات معينة (مثل حسابات المستخدمين الخاصة بهم أو عناوين IP الخاصة بالأجهزة). وهذا يعني أنه يمكنك تمكين المشرفين من رؤية نشاط مشرف آخر ، وليس نشاطهم الخاص.

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

خوادم Syslog و SIEMs ومجمّعات السجلات ومجموعات ELK إلخ. هناك العديد من الخيارات التي يمكنك استكشافها.

45
وأضاف
بالطبع ، هذا فقط يثير السؤال "كيف يمكنني تقسيم امتيازات في نظام موزع؟" وهو واحد IMHO أكثر من ذلك بكثير للاهتمام.
وأضاف المؤلف klkitchens, مصدر
@ schroeder مثالا ملموسا للمادة 2 الخاصة بك مع بعض الحل خادم/خادم تجميع القياسي سيكون موضع ترحيب من فضلك
وأضاف المؤلف Steve Powell, مصدر
@ Joshua تسجيل البرامج في كثير من الأحيان يخنق سجلات الزناد المفرط ويعطي الأولوية لرسائل الطوارئ أو التنبيه. سيكون من الصعب ملء القرص فقط عن طريق إغراق بعض الإجراءات التي تقوم بإنشاء سجل (على سبيل المثال الكتابة إلى إدخال procfs المتوقف) ، وما لم يكن لديك الجذر ، لن تتمكن من ملء القرص بأكمله على أي حال ، يتم حجز بعض المساحة الإضافية لـ daemons (مثل daemons تسجيل) يعمل كجذر ، على الأقل في أنظمة ملفات معينة.
وأضاف المؤلف forest, مصدر
lalebarde لا ترغب في الترويج لأي منتج معين ، يمكن لـ Splunk القيام بذلك. أعلم أنه يمكن استخدام المنطق أيضًا بواسطة منتجات أخرى. إذا كان المنتج يستطيع إخفاء أشياء مثل أرقام بطاقات الائتمان أو أرقام الهوية الوطنية ، فيمكنه منع وصول المستخدم إلى بيانات محددة (مثل أسماء المستخدمين).
وأضاف المؤلف schroeder, مصدر
اعتقدت أن حل المدرسة القديمة للسجلات الآمنة كان طابعة خط ...
وأضاف المؤلف Phil Miller, مصدر
وأضاف المؤلف dave_thompson_085, مصدر
حل المدرسة القديمة المفضل لدي. املأ القرص الذي يتم التسجيل عليه. ما لم يكن هذا القرص عدة عشرات من السل ، سأمتلئ بسجلات وهمية في وقت قصير.
وأضاف المؤلف Joshua, مصدر
forest: الخدعة مستهدفة جيدًا لإخراج أنظمة تسجيل الدخول عن بُعد. إنه يعمل بشكل أقل جيدًا على الأجهزة المحلية لأنك تحتاج بالفعل إلى الجذر لتزوير مداخل السجل بأدوات التسجيل المحلية.
وأضاف المؤلف Joshua, مصدر

أي سجلات على مضيف الاختراق هي المشتبه به. تحتاج إلى منصة تسجيل مركزية ، إما خادم سجل نظام مركزي/splunk/logrhythm/أيا كان. احتفظ بمجموعة مختلفة من المشرفين والحسابات. هذه هي الفكرة كلها.

بمجرد الحصول على منصة في مكان يمكنك تفويض الحقوق لعرض إجراءاتهم ، إما الخاصة بهم أو مدراء آخرين - يمكن القيام بها. لدينا حقوق قراءة مصادر سجلات محددة ومضيفين مفوضين.

12
وأضاف

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

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

2
وأضاف

بعض الطرق الممكنة لحماية السجلات من المسؤول:

  • تسجيل الدخول عن بُعد إلى جهاز لا يتحكم فيه المسؤول المعني
  • اكتب السجل إلى وسائط الكتابة مرة واحدة (على سبيل المثال ، Bluray Recordable) ، ولاحظ أنك قد تحتاج أيضًا إلى استراتيجية لمنع ملء الوسائط بشكل زائد ، مثل فصل جميع المسؤولين إذا كانت السجلات على وشك الحصول على
  • نشر تجزئة السجلات إلى blockchain عام ، وهذا يكتشف العبث ، على الرغم من عدم تدميره
  • فرض الوصول إلى الجهاز عبر خادم mitm ، يمكن للمسؤولين فقط الاتصال بالجهاز الذي يتم إدارته من خلال خادم mitm ، والذي سيسجل جميع المدخلات الرئيسية/الماوس ومخرجات الشاشة/المحطة الطرفية (باستخدام إما ssh mitm أو vnc/rdp mitm) </لى>
1
وأضاف
لن نشر خادم mitm زيادة الكثير من سطح الهجوم؟ هل هو easyto آمن؟
وأضاف المؤلف Steve Powell, مصدر
يعد "كتابة مرة واحدة" كابوسًا لوجستيًا ، ولكنه حل بسيط وفعال لمنع تعديل السجلات الملتقطة (ولكن ليس الوصول إلى السجلات). تعتبر ملقمات الوصول المميزة حلاً رائعًا للوصول إلى المشرف ، ولكنها لا تساعد إذا تم تحقيق وصول كبير إلى الهدف من خلال الوصول المنخفض (المهاجم).
وأضاف المؤلف schroeder, مصدر

الخطوة الأولى هي إرسال السجلات إلى خادم آخر ، بحيث بعد أن يتم اختراق الخادم الأول (وبالتالي يمكن تغيير سجلاته) ، سيكون لدى خادم السجل هذا إدخالات السجل هذه. ويمكن (يجب) حماية هذا الخادم بشكل أكثر إحكامًا.

ومع ذلك ، يجب أن يكون شخص ما قادرًا على إدارة هذا الخادم ، حتى إذا كان يمكن تحديث الخادم!

طرق يمكنك بالإضافة إلى ذلك حماية السجلات في هذا الخادم:

  • مطالبة المسؤولين المتعددين بأي إجراء (غير تافه) (على سبيل المثال ، تتطلب الأوامر المقدمة التأكيد من N المشرفين)
  • يمكن تخزين السجلات المرتبطة بأدوات سابقة في شجرة Merkle ، بحيث تتم إزالة أو أي تعديل في إدخال ما من شأنه أن يؤثر على أي إدخال لاحق
  • يمكن إرسال تجزئة السجل الحالي إلى طرف خارجي (الحصول على خادم ختم الوقت ، وإرسال شركة شريكة ، أو إرسالها ببساطة إلى موجز تويتر).

¹ عند الجدال باستخدام هذا ، قد يكون من الأفضل بيع أن يستخدم هذا تقنية blockchain .

² أو إذا كانت السجلات نفسها ليست سرية ، يمكنك حتى الضغط على بعض أحداث خادم السجل بوضوح: "jdoe تسجيل الدخول إلى خادم السجل وتشغيل rm -rf/"

1
وأضاف
هناك طريقة يتم نشرها في كثير من الأحيان لنشر تجزئة السجل في الوقت الحاضر وهي نشر التجزئة في blockchain عامة موجودة تسمح بالرسائل العشوائية مثل Bitcoin. هذا سيجعل السجل كدليل للتلاعب على أنه blockchain نفسه. على الرغم من أن هذه الملاحظة لا تزال تمنع فقط العبث غير القابل للكشف ، لكنها لن تمنع تدمير اللوغاريتم. لذلك ، ستحتاج إلى نسخ احتياطي مناسب.
وأضاف المؤلف Jay Corbett, مصدر
ما هي الأدوات الملموسة التي تكمن خلف حلولك ، خصوصًا المدراء المتعددين وشجرة Merkle؟
وأضاف المؤلف Steve Powell, مصدر

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

0
وأضاف
في الواقع ، إنها مكلفة بعض الشيء
وأضاف المؤلف Steve Powell, مصدر
لماذا يكون دايود البيانات الحل؟ ما المشكلة في الاتصال ثنائي الاتجاه مع الخادم إذا كان لديك عمليات مصادقة على الخادم؟ يعد دايود البيانات محلولًا مفرطًا هندسيًا لحالة الاستخدام هذه.
وأضاف المؤلف schroeder, مصدر