Product SiteDocumentation Site

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

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

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. مراقبة النشاطات

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

top هي أداة تفاعلية تعرض قائمة بالعمليات النشطة حالياً. يعتمد الترتيب الافتراضي على نسبة استخدام المعالج ويمكن الوصول لهذا الترتيب بالمفتاح P. من الخيارات الأخرى المتاحة للترتيب الترتيب حسب كمية الذاكرة المحجوزة (المفتاح M)، أو حسب الزمن الكلي للمعالج (المفتاح T) أو حسب مُعرّف العملية (المفتاح N). يسمح المفتاح k بقتل عملية عبر إدخال رقم تعريفها. ويسمح المفتاح r بإعادة تهذيب العملية، أي تغيير أولويتها.
When the system seems to be overloaded, top is a great tool to see which processes are competing for processor time or consume too much memory. In particular, it is often interesting to check if the processes consuming resources match the real services that the machine is known to host. An unknown process running as the www-data user should really stand out and be investigated, since it is probably an instance of software installed and executed on the system through a vulnerability in a web application.
top أداة مرنة جداً وتفصل صفحة دليلها طريقة تخصيص أسلوب عرضها للمعلومات وتكييفها مع احتياجاتك وعاداتك.
الأداة الرسومية gnome-system-monitor تشبه top وتوفر المزايا نفسها تقريباً.

14.3.2.2. من الماضي

حمل المعالج ونشاط الشبكة والمساحة التخزينية الحرة هي معلومات متغيرة باستمرار يفيد تتبع تاريخ تطورها غالباً في التعرف على طريقة استثمار الحاسوب بدقة.
هناك أدوات عديدة مخصصة لهذه المهمة. معظمها قادر على جلب البيانات عبر SNMP‏ (Simple Network Management Protocol) وذلك لمركزة هذه المعلومات. من المكاسب المضافة هي أن هذا يسمح بجلب البيانات من العناصر الشبكية التي قد لا تكون بالضرورة حواسيباً عامة الأغراض، مثل موجهات الشبكة المتخصصة أو التحويلات.
This book deals with Munin in some detail (see قسم 12.4.1, “إعداد Munin”) as part of فصل 12: “الإدارة المتقدمة. Debian also provides a similar tool, cacti. Its deployment is slightly more complex, since it is based solely on SNMP. Despite having a web interface, grasping the concepts involved in configuration still requires some effort. Reading the HTML documentation (/usr/share/doc/cacti/html/Table-of-Contents.html) should be considered a prerequisite.

14.3.3. Avoiding Intrusion

Attackers try to get access to servers by guessing passwords, which is why strong passwords must always be used. Even then, you should also establish measures against brute-force attacks. A brute-force attack is an attempt to log in to an unauthorised software system by performing multiple login attempts in a short period of time.
The best way to stop a brute-force atack is to limit the number of login attempts coming from the same origin, usually by temporarily banning an IP address.
Fail2Ban is an intrusion prevention software suite that can be configured to monitor any service that writes login attemps to a log file. It can be found in the package fail2ban.
Fail2Ban is configured through a simple protocol by fail2ban-client, which also reads configuration files and issues corresponding configuration commands to the server, fail2ban-server. It has four configuration file types, all stored in /etc/fail2ban:
  • fail2ban.conf. Global configuration (such as logging).
  • filter.d/*.conf. Filters specifying how to detect authentication failures. The Debian package already contains filters for many common programs.
  • action.d/*.conf. Actions defining the commands for banning and unbanning of IP addresses.
  • jail.conf. It is where jails, the combinations of filters and actions, are defined.
Let us have a look at the configuration of sshd in /etc/fail2ban/jail.conf to better understand how Fail2Ban works...
[...]
[DEFAULT]
[...]
bantime  = 10m
[...]
maxretry = 5
[...]
[sshd]
port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
Fail2Ban will check for failed login attepts for sshd using Python regular expressions defined in /etc/fail2ban/filters.d/sshd.conf against the log file of sshd, which is defined in the variable sshd_log in the file /etc/fail2ban/paths_common.conf. If Fail2Ban detects five failed login attempts in a row, it will ban the IP address where those attempts originated.
Fail2Ban is a very simple and effective way to protect against the most common brute-force attacks, but it cannot protect against distributed brute-force attacks, which is when an attacker uses a large number of machines spread around the Internet.
A good way to provide extra protection against distributed brute force attacks is to artificially increase the login time after each failed attempt.

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

Once the system is installed and configured, and barring security upgrades, there is usually no reason for most of the files and directories to evolve, data excepted. It is therefore interesting to make sure that files actually do not change: any unexpected change would therefore be worth investigating. This section presents a few tools able to monitor files and to warn the administrator when an unexpected change occurs (or simply to list such changes).

14.3.4.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.4.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، وهي غير مثبتة افتراضياً.
debsums can be run frequently as a cronjob setting CRON_CHECK in /etc/default/debsums. To ignore certain files outside the /etc directory, which have been altered on purpuse or which are expected to change (like /usr/share/misc/pci.ids) you can add them to /etc/debsums-ignore.

14.3.4.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.5. اكتشاف التطفل (IDS/NIDS)

suricata (in the Debian package of the same name) is a NIDS — a Network Intrusion Detection System. Its function is to listen to the network and try to detect infiltration attempts and/or hostile acts (including denial of service attacks). All these events are logged in multiple files in /var/log/suricata. There are third party tools (Kibana/logstash) to better browse all the data collected.
لضبط suricata يجب مراجعة الملف /etc/suricata/suricata-debian.yaml وتعديله. هذا الملف طويل جداً بسبب التعليقات المسهبة لكل متغير. يتطلب أصغر إعداد ممكن تحديد مجالات العناوين التي تغطيها الشبكة المحلية (المتغير HOME_NET). عملياً، هذا يعني مجموعة العناوين التي يحتمل استهدافها بالهجمات. لكن لتحقيق الاستفادة القصوى يجب قراءة الملف كاملاً وتعديله بما يناسب الوضع محلياً.
بالإضافة لهذا عليك تحرير /etc/default/suricata وتعريف الواجهة الشبكية التي ستُرَاقَب وتفعيل سكريبت الإقلاع (عبر ضبط القيمة RUN=yes). كما قد ترغب بضبط القيمة LISTENMODE=pcap لأن القيمة الافتراضية LISTENMODE=nfqueue تتطلب إعدادات إضافية حتى تعمل بشكل صحيح (يجب ضبط الجدار الناري netfilter بحيث يمرر الرزم إلى رتل في ساحة المستخدم يتحكم به suricata عبر استخدام الهدف NFQUEUE).
To detect bad behavior, suricata needs a set of monitoring rules: you can find such rules in the snort-rules-default package. snort is the historical reference in the IDS ecosystem and suricata is able to reuse rules written for it.
هناك حل بديل وهو استخدام oinkmaster (من الحزمة ذات الاسم نفسه) لتنزيل مجموعات قواعد Snort من مصادر خارجية.