14.3.1. مراقبة السجلات باستخدام logcheck
يراقب البرنامج logcheck ملفات السجلات في كل ساعة افتراضياً حيث يرسل رسائل السجل غير الطبيعية إلى مدير النظام عبر البريد الإلكتروني لمتابعة تحليلها.
تُخزَّن لائحة الملفات التي يراقبها في /etc/logcheck/logcheck.logfiles؛ القيم الافتراضية جيدة إذا لم يكن الملف /etc/rsyslog.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.1. في الزمن الحقيقي
top هي أداة تفاعلية تعرض قائمة بالعمليات النشطة حالياً. يعتمد الترتيب الافتراضي على نسبة استخدام المعالج ويمكن الوصول لهذا الترتيب بالمفتاح P. من الخيارات الأخرى المتاحة للترتيب الترتيب حسب كمية الذاكرة المحجوزة (المفتاح M)، أو حسب الزمن الكلي للمعالج (المفتاح T) أو حسب مُعرّف العملية (المفتاح N). يسمح المفتاح k بقتل عملية عبر إدخال رقم تعريفها. ويسمح المفتاح r بإعادة تهذيب العملية، أي تغيير أولويتها.
عندما يبدو أن حمل النظام زائد، تسمح top بالتعرف على العمليات التي تتنافس على وقت المعالج أو التي تستهلك الكثير من الذاكرة. بالأخص، تفيد هذه الأداة في التحقق من توافق العمليات التي تستهلك الموارد مع الخدمات الحقيقية التي نعرف أن الجهاز يستضيفها. أي عملية غير معروفة تعمل بصلاحيات المستخدم www-data (مثلاً) يجب أن تبدو ظاهرة تماماً ويجب التحقق منها، لأنها على الأغلب نسخة من برمجية مثبتة ومنفّذة على النظام عبر استغلال ثغرة في أحد تطبيقات الوب.
top أداة مرنة جداً وتفصل صفحة دليلها طريقة تخصيص أسلوب عرضها للمعلومات وتكييفها مع احتياجاتك وعاداتك.
الأداة الرسومية gnome-system-monitor تشبه top وتوفر المزايا نفسها تقريباً.
حمل المعالج ونشاط الشبكة والمساحة التخزينية الحرة هي معلومات متغيرة باستمرار يفيد تتبع تاريخ تطورها غالباً في التعرف على طريقة استثمار الحاسوب بدقة.
هناك أدوات عديدة مخصصة لهذه المهمة. معظمها قادر على جلب البيانات عبر 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. فحص سلامة الحزم باستخدام dpkg --verify
dpkg --verify (أو dpkg -V) هي أداة مهمة لأنها تسمح بمعرفة أي الملفات المثبتة قد عدلت (نتيجة هجوم) مثلاً، لكن لا تكن واثقاً من هذا تماماً. تعتمد هذه الأداة في عملها على checksums مخزنة في قاعدة بيانات dpkg التي تُخزَّن على القرص الصلب (يمكنك العثور عليها في /var/lib/dpkg/info/package.md5sums)؛ والمهاجم الخبير سوف يحدث هذه الملفات بحيث يسجل فيها قيم checksum الجديدة للملفات المخربة.
عند استدعاء dpkg -V سيتحقق من كافة الحزم المثبتة وسيطبع سطراً يقابل كل ملف يفشل اختبار سلامته. صيغة الخرج هي صيغة خرج rpm -V نفسها حيث يمثل كل محرف اختباراً على بيانات فوقية محددة. لسوء الحظ، لا يخزن dpkg البيانات الفوقية اللازمة لمعظم الاختبارات ولذلك يطبع علامات استفهام مكانها. حالياً اختبار التحقق من checksum هو الوحيد الذي يمكن أن يطبع "5" عند المحرف الثالث (إذا فشل الاختبار).
# dpkg -V
؟؟5؟؟؟؟؟؟ /lib/systemd/system/ssh.service
؟؟5؟؟؟؟؟؟ c /etc/libvirt/qemu/networks/default.xml
؟؟5؟؟؟؟؟؟ c /etc/lvm/lvm.conf
؟؟5؟؟؟؟؟؟ c /etc/salt/roster
في العينة أعلاه، يبين dpkg حدوث تغيير على ملف تابع لخدمة SSH حيث عدل عليه مدير النظام بدلاً من استخدام ملف /etc/systemd/system/ssh.service صحيح يلغي تأثيره (والذي كان سيُخزَّن في /etc وهذا ما يفترض أن يكون لأي تغيير على الإعدادات). كما يذكر أيضاً عدة ملفات إعداد (يميزها المحرف "c" في الحقل الثاني) التي عُدِّلت بشكل نظامي.
14.3.3.2. فحص الحزم: debsums وحدودها
الأمر debsums هو سالف dpkg -V وقد أصبح مهجوراً تقريباً. يعاني debsums من قيود dpkg نفسها. لكن ولحسن الحظ، يمكن تفادي بعض القيود فيه (بينما لا يمكن تفاديها في dpkg).
بما أن البيانات على القرص الصلب غير موثوقة، يقدم debsums خيار فحص الملفات المُثبّتة اعتماداً على ملفات .deb بدلاً من الاعتماد على قاعدة بيانات dpkg. يمكننا الاعتماد على تنزيلات APT المصدقة لتنزيل ملفات .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.3. مراقبة الملفات: 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)
suricata (في حزمة دبيان ذات الاسم نفسه) هو NIDS —
Network Intrusion Detection System (نظام كشف تطفل). مهمته هي الإنصات للشبكة ومحاولة اكتشاف محاولات الاختراق و (أو) الأفعال العدائية (بما فيها هجمات denial of service). تُسجّل جميع هذه الأحداث في عدة ملفات في
/var/log/suricata. هناك أدوات من أطراف ثالثة (Kibana/logstash) تستعرض كافة البيانات الملتقطة بشكل أفضل.
لضبط suricata يجب مراجعة الملف /etc/suricata/suricata-debian.yaml وتعديله. هذا الملف طويل جداً بسبب التعليقات المسهبة لكل متغير. يتطلب أصغر إعداد ممكن تحديد مجالات العناوين التي تغطيها الشبكة المحلية (المتغير HOME_NET). عملياً، هذا يعني مجموعة العناوين التي يحتمل استهدافها بالهجمات. لكن لتحقيق الاستفادة القصوى يجب قراءة الملف كاملاً وتعديله بما يناسب الوضع محلياً.
بالإضافة لهذا عليك تحرير /etc/default/suricata وتعريف الواجهة الشبكية التي ستُرَاقَب وتفعيل سكريبت الإقلاع (عبر ضبط القيمة RUN=yes). كما قد ترغب بضبط القيمة LISTENMODE=pcap لأن القيمة الافتراضية LISTENMODE=nfqueue تتطلب إعدادات إضافية حتى تعمل بشكل صحيح (يجب ضبط الجدار الناري netfilter بحيث يمرر الرزم إلى رتل في ساحة المستخدم يتحكم به suricata عبر استخدام الهدف NFQUEUE).
يحتاج suricata إلى مجموعة من قواعد المراقبة حتى يكتشف السلوك الضار: يمكنك الحصول على هذه القواعد من الحزمة snort-rules-default. snort هو المرجع القديم في مجال اكتشاف التطفل، ويستطيع suricata إعادة استخدام القواعد المكتوبة له. للأسف تلك الحزمة مفقودة في دبيان جيسي وعليك الحصول عليها من إصدارة دبيان أخرى مثل الاختبارية أو غير المستقرة.
هناك حل بديل وهو استخدام oinkmaster (من الحزمة ذات الاسم نفسه) لتنزيل مجموعات قواعد Snort من مصادر خارجية.
