الخلاصة

  • حوّل COPS مشكلات Unix المعروفة — كلمات المرور الضعيفة، والصلاحيات المفرطة، وملفات البدء المكشوفة — إلى فحوص قابلة للتكرار على المضيف المحلي.
  • أبلغت برامجه القابلة للتهيئة عن مشكلات محتملة من دون إصلاحها. لم تكن معظم الفحوص تحتاج إلى root؛ أما البحث الأوسع عن ملفات SUID فكان منفصلاً ويتطلب امتيازات.
  • يصف التقرير الخالي من التنبيهات الفحوص المحددة وما بلغته وقت التشغيل. ولا يثبت الأمان الكامل أو بقاء المضيف على حاله بعد الفحص.

تكرار البحث عن الأخطاء المعتادة

بدأت ورقة 1990 من ملاحظة عملية: كانت كتابات أمن Unix تعود إلى المشكلات نفسها. برامج SUID، وصلاحيات الملفات المتساهلة، وكلمات المرور الضعيفة، غالباً ما يسهل إصلاحها بعد اكتشافها. لكن البحث عنها مجدداً داخل أنظمة تتغير يحتاج إلى عمل مستمر. أراد Farmer وSpafford جعل هذه المراجعة قابلة للتكرار.

اسم COPS اختصار لـ “Computerized Oracle and Password System”، لكنه ليس ماسحاً للشبكات. كان برنامج shell رئيسي يجمع مخرجات نحو اثني عشر برنامجاً فرعياً، ثم يرسلها إلى مسؤول النظام المحلي أو يسجلها في ملف. اعتمد معظمها Bourne shell وأدوات Unix المعتادة، مع برامج C صغيرة عند الحاجة. أمكن تهيئة المكونات أو استبدالها وفق احتياجات الموقع.

استهدفت الفحوص عناصر إدارية محددة: الملفات والمجلدات المضبوطة بحيث يستطيع الجميع الكتابة فيها؛ كلمات المرور المطابقة لاسم المستخدم أو المبنية على كلمات شائعة؛ أخطاء سجلات الحسابات والمجموعات؛ الملفات القابلة للتعديل التي تستدعيها cron أو نصوص بدء التشغيل؛ صلاحيات بعض الأجهزة؛ مجلدات المستخدمين وملفات تهيئتهم؛ وumask الخاص بـroot ومسارات البحث التي تشمل المجلد الحالي. قارن suidchk مجموعة ملفات SUID بالتشغيل السابق. أما Kuang فطبّق قواعد لاختبار ما إذا كان مستخدم يستطيع الوصول إلى حالة اختراق الحساب المستهدف وفق تلك القواعد.

تتضح قيمة COPS في خفض كلفة تكرار مجموعة معروفة من الفحوص المحلية، لا في «فحص الأمان كله». لم تغطّ كل عيب ممكن، ولم تقرر ما إذا كانت كل صلاحية تخالف سياسة الموقع.

الفحص لا يتخذ قرار الإصلاح

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

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

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

ما الذي تدعمه الأدلة؟

تلقى Farmer وSpafford تعليقات من مواقع أكاديمية وحكومية وتجارية. وذكرا أن أكثر من نصف الأنظمة التي فحصاها أو وصلتهما عنها ملاحظات تضمنت مشكلات قد تمكّن من اختراق root، لكنهما أوضحا أنه لا يمكن تعميم تلك الملاحظة المحدودة على مجموعة أكبر. فهي ليست تقديراً لكل أنظمة Unix.

فحص COPS وSATAN اللاحق لـFarmer سطحين مختلفين: راجع الأول حسابات Unix المحلية وملفاتها وصلاحياتها وبدء تشغيلها؛ أما الثاني فاهتم بخدمات الشبكة وما يظهر للمضيفات الأخرى. لا يجعل اشتراك المؤلف التقريرين قابلين للاستبدال.

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

المصادر