Product SiteDocumentation Site

14.3. الإشراف: المنع، والاكتشاف، والردع

المراقبة هي جزء متمم لأي سياسة أمنية وذلك لعدة أسباب. منها، أن هدف الحماية لا ينحصر عادة في ضمان سرية البيانات فقط، بل يتعداه إلى ضمان توافر الخدمات. لا بد إذن من التحقق أن كل شيء يعمل كما هو متوقع. واكتشاف أي سلوك شاذ أو تغيّر في جودة الخدمة (أو الخدمات) المقدمة في الوقت المناسب. قد تساعد عملية المراقبة على اكتشاف محاولات التطفل وتفعيل ردود سريعة قبل أن تسبب عواقب جسيمة. يراجع هذا القسم بعض الأدوات المستخدمة لمراقبة عدة نواحي في نظام دبيان. بالتالي، فهو يكمل القسم المخصص للمراقبة العامة للنظام في فصل 12, الإدارة المتقدمة.

14.3.1. مراقبة السجلات باستخدام logcheck

يراقب البرنامج logcheck ملفات السجلات في كل ساعة افتراضياً حيث يرسل رسائل السجل غير الطبيعية إلى مدير النظام عبر البريد الإلكتروني لمتابعة تحليلها.
تُخزَّن لائحة الملفات التي يراقبها في /etc/logcheck/logcheck.logfiles؛ القيم الافتراضية جيدة إذا لم يكن الملف /etc/syslog.conf أعيد بناؤه بالكامل.
يمكن أن يعمل logcheck في وضع واحد من ثلاثة أوضاع تختلف بمستوى تفصيلها: paranoid (مُرتاب) و server (مُخدِّم) و workstation (محطة عمل). الوضع الأول مفصل جداً، ويجب عدم استخدامه على الأرجح إلا على مخدمات خاصة مثل الجدران النارية. الوضع الثاني (والافتراضي) هو الوضع المفضل لمعظم المخدمات. أما الوضع الأخير فهو مصمم لمحطات العمل، وهو أكثر إيجازاً (يحجب رسائل أكثر).
في جميع الحالات الثلاث. يجب تخصيص logcheck على الأغلب لاستبعاد بعض الرسائل الإضافية (اعتماداً على الخدمات المثبتة)، إلا إذا كان مدير النظام يريد فعلاً تلقي دفعات ساعية من رسائل بريدية طويلة وغير مهمة. بما أن آلية اختيار الرسائل معقدة نوعاً ما، يجب قراءة الملف /usr/share/doc/logcheck-database/README.logcheck-database.gz ودماغك نشط حتى تفهمها بشكل أفضل.
يمكن تقسيم القواعد المطبّقة إلى عدة أنواع:
  • القواعد التي تصنف الرسالة على أنها محاولة اختراق (مخزنة في ملف ضمن المجلد /etc/logcheck/cracking.d/
  • القواعد التي تلغي التصنيف السابق (/etc/logcheck/cracking.ignore.d/
  • القواعد التي تصنف الرسالة على أنها تحذير أمني (/etc/logcheck/violations.d/
  • القواعد التي تلغي التصنيف السابق (/etc/logcheck/violations.ignore.d/
  • وأخيراً، القواعد التي على بقية الرسائل (التي تعتبر كأحداث نظام system events).
كما تُرسَل أحداث النظام دائماً إلا في حال وجود قاعدة في أحد المجلدات /etc/logcheck/ignore.d.{paranoid,server,workstation}/ تُبيّن وجوب تجاهل هذا الحدث. طبعاً، لا تؤخذ بعين الاعتبار إلا المجلدات التي توافق مستوى التفصيل لوضع العمل المحدد والمستويات الأعلى منه.

14.3.2. مراقبة النشاطات

14.3.2.1. في الزمن الحقيقي

top هي أداة تفاعلية تعرض قائمة بالعمليات النشطة حالياً. يعتمد الترتيب الافتراضي على نسبة استخدام المعالج ويمكن الوصول لهذا الترتيب بالمفتاح P. من الخيارات الأخرى المتاحة للترتيب الترتيب حسب كمية الذاكرة المحجوزة (المفتاح M)، أو حسب الزمن الكلي للمعالج (المفتاح T) أو حسب مُعرّف العملية (المفتاح N). يسمح المفتاح k بقتل عملية عبر إدخال رقم تعريفها. ويسمح المفتاح r بإعادة تهذيب العملية، أي تغيير أولويتها.
عندما يبدو أن حمل النظام زائد، تسمح top بالتعرف على العمليات التي تتنافس على وقت المعالج أو التي تستهلك الكثير من الذاكرة. بالأخص، تفيد هذه الأداة في التحقق من توافق العمليات التي تستهلك الموارد مع الخدمات الحقيقية التي نعرف أن الجهاز يستضيفها. أي عملية غير معروفة تعمل بصلاحيات المستخدم www-data (مثلاً) يجب أن تبدو ظاهرة تماماً ويجب التحقق منها، لأنها على الأغلب نسخة من برمجية مثبتة ومنفّذة على النظام عبر استغلال ثغرة في أحد تطبيقات الوب.
top أداة مرنة جداً وتفصل صفحة دليلها طريقة تخصيص أسلوب عرضها للمعلومات وتكييفها مع احتياجاتك وعاداتك.
الأداتين الرسوميتين gnome-system-monitor و qps تشبهان top وتوفران المزايا نفسها تقريباً.

14.3.2.2. من الماضي

حمل المعالج ونشاط الشبكة والمساحة التخزينية الحرة هي معلومات متغيرة باستمرار يفيد تتبع تاريخ تطورها غالباً في التعرف على طريقة استثمار الحاسوب بدقة.
هناك أدوات عديدة مخصصة لهذه المهمة. معظمها قادر على جلب البيانات عبر SNMP‏ (Simple Network Management Protocol) وذلك لمركزة هذه المعلومات. من المكاسب المضافة هي أن هذا يسمح بجلب البيانات من العناصر الشبكية التي قد لا تكون بالضرورة حواسيباً عامة الأغراض، مثل موجهات الشبكة المتخصصة أو التحويلات.
يغطي هذا الكتاب Munin بالتفصيل (انظر قسم 12.4.1, “إعداد Munin”) في الفصل فصل 12: “الإدارة المتقدمة. توفر دبيان أيضاً أداة مشابهة هي cacti. وضع هذه الأداة في الخدمة أعقد قليلاً، لأنها تعتمد كلياً على SNMP. ورغم أنها تملك واجهة وب، إلا أن استيعاب مفاهيم إعدادها لا يزال صعباً. لا مفر من قراءة وثائق HTML‏ (/usr/share/doc/cacti/html/index.html) إذا كنت ستستعمل هذه الأداة.

14.3.3. اكتشاف التغيُّرات

بعد تثبيت النظام وإعداده، وفيما عدا التحديثات الأمنية، ليس هناك أي داعي عادة لتطور معظم الملفات والمجلدات، إلا البيانات. من المهم إذن التأكد من عدم تغيُّر الملفات فعلاً: أي تغيير غير متوقع عندئذ يستحق التقصي حوله. يعرض هذا القسم بضعة أدوات قادرة على مراقبة الملفات وتحذير مدير النظام عند حدوث أي تغيير غير متوقع (أو لسرد هذه التغييرات ببساطة).

14.3.3.1. فحص الحزم: debsums وحدودها

debsums أداة مفيدة ﻷنها تسمح باكتشاف الملفات المثبتة التي عُدّلت (نتيجة تطفلات خبيثة على النظام مثلا)، لكن عليك ألا تثق تماماً بهذا. لأنه أولاً، لاتقدم جميع حزم دبيان البصمات اللازمة لعمل هذا البرنامج (التي يمكن العثور عليها في /var/lib/dpkg/info/package.md5sums في حال توفرها). للتذكرة: البصمة هي قيمة، رقميّة غالباً (رغم أنها تكتب بالتدوين الست عشري)، تحوي شكلاً من التوقيع الرقمي لمحتويات الملف. يُحسَب هذا التوقيع بخوارزمية (من الأمثلة المشهورة MD5 أو SHA1) تضمن أن أي تغيير (تقريباً) على محتويات الملف، مهما كان صغيراً، سيؤدي لتغير البصمة؛ يعرف هذا ”بأثر التَّيْهور avalanche effect“. يسمح هذا باستخدام بصمة رقمية بسيطة للتحقق من عدم تغيّر محتويات الملف. هذه الخوارزميات غير عكوسة؛ أي أن معرفة البصمة، في معظم هذه الخوارزميات، لا تسمح بالعثور على المحتويات الموافقة لها. يبدو أن التطورات الأخيرة في الرياضيات قد أضعفت منعة هذه المبادئ، لكن لم تصل لمرحلة التشكيك في استخدامها حتى الآن، لأنه يبدو أن إنشاء محتويات مختلفة تعطي البصمة نفسها لا يزال صعباً جداً.
بالإضافة لذلك، تُخزّن ملفات md5sums على القرص الصلب؛ فالمهاجم الخبير سوف يُعدِّل هذه الملفات بحيث تحوي قيم شفرات التحقق الجديدة للملفات التي خربها.
يمكن تفادي القصور الأول عبر الطلب من debsums أن تستخدم حزمة .deb مباشرة عند التحقق من الملفات بدلاً من الاعتماد على ملف debsums. لكن ذلك يحتاج تنزيل ملفات .deb الموافقة أولاً:
# apt-get --reinstall -d install `debsums -l`
[ ... ]
# debsums -p /var/cache/apt/archives -g
كما يجدر بالملاحظة أن debsums، حسب الإعدادات الافتراضية، تولد ملفات md5sums المفقودة تلقائياً في كل مرة تستخدم فيها APT لتثبيت حزمة جديدة.
يمكن تفادي المشكلة الأخرى بأسلوب مشابه، يجب أن يعتمد التحقق على ملف .deb الأصلي ببساطة. بما أن هذا يعني ضمنياً ضرورة امتلاك جميع ملفات .deb لجميع الحزم المثبتة، وضمان سلامتها، فإن أبسط وسيلة هي الحصول عليها من مرآة دبيان. قد تكون هذه العملية بطيئة ومملة، لذلك يجب عدم اتخاذها كتقنية وقائية تستخدم على نحو منتظم.
# apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package`
[ ... ]
# debsums -p /var/cache/apt/archives --generate=all
لاحظ أن هذا المثال يستخدم grep-status من الحزمة dctrl-tools، وهي غير مثبتة افتراضياً.

14.3.3.2. مراقبة الملفات: AIDE

تسمح الأداة AIDE‏ (Advanced Intrusion Detection Environment) بالتحقق من سلامة الملفات، واكتشاف أي تغيّرات اعتماداً على صورة مسجلة سابقاً للنظام السليم. تُخزّن هذه الصورة كقاعدة بيانات (/var/lib/aide/aide.db) تحوي خصائص جميع ملفات النظام (البصمات، الصلاحيات، التواريخ وغيرها). تُهيّأ قاعدة البيانات هذه أولاً باستخدام aideinit؛ وبعدها تُستخدَم يومياً (يستخدمها السكربت /etc/cron.daily/aide) للتحقق من عدم تغير أي شيء. عند اكتشاف أي تغير، تسجله AIDE في سجلاتها (/var/log/aide/*.log) وترسل ما وجدته إلى مدير النظام عبر البريد الإلكتروني.
هناك العديد من الخيارات في /etc/default/aide التي يمكن استخدامها لتعديل سلوك حزمة aide. تخزن إعدادات هذا البرنامج في /etc/aide/aide.conf و /etc/aide/aide.conf.d/ (في الواقع، يستخدم update-aide.conf هذه الملفات فقط لتوليد /var/lib/aide/aide.conf.autogenerated). تدل الإعدادات على الملفات وخصائص الملفات المطلوب التحقق منها. مثلاً، تتغير محتويات ملفات السجلات بشكل متكرر، ويمكن تجاهل هذه التغيرات طالما أن صلاحيات الوصول لهذه الملفات لم تتغير، لكن بالنسبة للبرامج التنفيذية يجب أن تبقى محتوياتها وصلاحياتها ثابتة. رغم أن صيغة هذه الإعدادات ليست بالغة التعقيد، إلا أنها ليست بدهية أيضاً. قراءة صفحة الدليل aide.conf(5)‎ إذن سوف تفيد.
تُولّد نسخة جديدة من قاعدة البيانات يومياً في /var/lib/aide/aide.db.new؛ إذا كانت جميع التغييرات المسجّلة مشروعة، يمكن استخدام هذه النسخة لاستبدال قاعدة البيانات المرجعية.

14.3.4. اكتشاف التطفل (IDS/NIDS)

snort (في حزمة دبيان ذات الاسم نفسه) هو NIDS‏ — Network Intrusion Detection System (نظام كشف تطفل). مهمته هي الإنصات للشبكة ومحاولة اكتشاف محاولات الاختراق و (أو) الأفعال العدائية (بما فيها هجمات denial of service). تُسجّل جميع هذه الأحداث، ويرسل بريد إلكتروني يومي إلى مدير النظام يحوي ملخص آخر 24 ساعة.
يحتاج إعداده إلى تحديد مجال العناوين التي تغطي الشبكة المحلية. عملياً، هذا يعني مجموعة الأهداف المحتملة للهجوم. يمكن ضبط المتغيرات المهمة الأخرى باستخدام dpkg-reconfigure snort، بما في ذلك الواجهة الشبكية التي سيراقبها. ستكون هذه غالباً eth0 بالنسبة لاتصالات إيثرنت، لكن هناك إمكانيات أخرى مثل ppp0 لاتصالات ADSL أو PSTN‏ (Public Switched Telephone Network، شبكة الهاتف العامة أو مودمات الاتصال الهاتفي القديمة)، أو حتى wlan0 بالنسبة لبعض بطاقات الشبكات اللاسلكية.
ملف إعدادات snort‏ (/etc/snort/snort.conf) طويل جداً، والتعليقات الكثيرة تشرح كل مدخلة بتفصيل مسهب. للاستفادة منه بشكل كامل يجب قراءته كله وملائمته مع الوضع المحلي. مثلاً، يمكن أن يساعد تحديد الأجهزة التي تستضيف خدمات معينة على تقليل عدد الحوادث التي يبلغ عنها snort، لأن هجمات denial of service على جهاز مكتبي ليست أبداً بنفس أهمية الهجوم على مخدم DNS. من التعليمات المفيدة الأخرى تعليمة تسمح بتخزين التقابلات بين عناوين IP وعناوين MAC (التي تُعرّف بطاقات الشبكات بشكل فريد)، بحيث يمكن اكتشاف هجمات ARP spoofing (تزوير ARP) التي يحاول أحد الأجهزة المخترقة من خلالها التنكر بدور مخدم حساس.