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/)؛
در نهایت، آن‌هایی که به پیام‌های باقیمانده اعمال می‌شوند (که به عنوان رویدادهای سیستمی شناخته می‌شوند).
یک رویداد سیستمی همیشه ارسال می‌شود مگر یکی از قوانین موجود در دایرکتوری‌های /etc/logcheck/ignore.d.{paranoid,server,workstation}/ بگوید که این رویداد نادیده گرفته شود. البته، تنها دایرکتوری‌هایی به حساب می‌آیند که سطح گزارش برابر یا بیشتر از حالت عملیاتی انتخابی داشته باشند.
14.3.2. فعالیت مانیتورینگ
top یک ابزار تعاملی است که فهرستی از فرآیندهای در حال اجرا را نمایش می‌دهد. مرتب‌سازی پیشفرض آن مبتنی بر میزان استفاده فعلی از پردازنده است که می‌تواند با کلید P مشخص گردد. سایر انواع مرتب‌سازی شامل حافظه مصرفی (کلید M)، زمان کلی پردازنده (کلید T) و شناسه فرآیند (کلید N) می‌باشند. کلید k اجازه نابودی یک فرآیند با وارد کردن شناسه‌اش را فراهم می‌کند. کلید r امکان renice یک فرآیند را فراهم می‌کند، که همان تغییر اولویت در اجرا است.
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 بوده که تقریبا همان ویژگی‌ها را فراهم می‌کند.
بار پردازنده، ترافیک شبکه و فضای آزاد دیسک اطلاعاتی هستند که به صورت مداوم در حال تغییر می‌باشند. نگهداری تاریخچه‌ای از میزان مصرف آن‌ها درک خوبی از چگونگی کارکرد رایانه را در اختیار ما قرار می‌دهد.
ابزار اختصاصی متفاوتی برای این منظور وجود دارد. اغلب آن‌ها می‌توانند با استفاده از 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 into an unauthorized software system by performing multiple login attempts in a short period of time.
The best way to stop a brute-force attack 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 attempts 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
[...]
findtime = 10m
[...]
maxretry = 5
[...]
[sshd]
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
Fail2Ban will check for failed login attempts for sshd using Python regular expressions defined in /etc/fail2ban/filter.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 within 10 minutes, it will ban the IP address where those attempts originated for 10 minutes.
To enable, disable, or configure “jails“, the main configuration file /etc/fail2ban/jail.conf is not supposed to be altered. Instead this is supposed to be done in /etc/fail2ban/jail.d/defaults-debian.conf or files within the same directory.
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.
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 ابزار جالبی است چرا که امکان جستجوی فایل‌های تغییر یافته از زمان نصب را فراهم می‌کند (که احتمالا توسط مهاجم تغییر یافته‌اند) اما اینکار باید با احتیاط بیشتری صورت پذیرد. برای اینکه بتواند کار خود را انجام دهد نیازمند checksum ذخیره‌سازی شده در پایگاه‌داده dpkg روی هارد دیسک می‌باشد (این فایل‌ها می‌توانند در /var/lib/dpkg/info/package.md5sums پیدا شوند)؛ یک مهاجم بالقوه با بروزرسانی این فایل‌ها از تشخیص فایل‌های تغییر یافته جلوگیری بعمل می‌آورد.
اجرای 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
In the sample above, dpkg reports a change to SSH's service file that the administrator made to the packaged file instead of using an appropriate /etc/systemd/system/ssh.service.d/override.conf override (which would be stored below /etc like any configuration change should be). It also lists multiple configuration files (identified by the "c" letter on the second field) that had been legitimately modified.
14.3.4.2. بازرسی بسته‌ها: debsums و محدودیت‌های آن
debsums is the ancestor of dpkg -V and is thus mostly obsolete. It suffers from the same limitations than dpkg. Fortunately, some of the limitations can be worked-around (whereas dpkg does not offer similar workarounds).
از آنجا که نمی‌توان به داده روی دیسک اعتماد کرد، debsums پیشنهاد می‌کند که بجای پایگاه‌داده dpkg از فایل‌های .deb به منظور آزمون استفاده شود. برای دانلود فایل‌های .deb بسته‌های نصب شده، می‌توان روی مکانیزم احرازهویت APT حساب باز کرد. این عملیات می‌تواند کند و خسته‌کننده باشد، پس نباید به عنوان تکنیکی موثر به صورت روزانه مورد استفاده قرار گیرد.
# 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 purpose 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 امکان بررسی جامعیت فایل را فراهم می‌کند و هرگونه تغییر مقابل image نسخه پیشین از سیستم معتبر را تشخیص می‌دهد. این image به عنوان یک پایگاه‌داده ذخیره‌سازی می‌شود (/var/lib/aide/aide.db) که شامل اطلاعات مرتبط درباره تمام فایل‌های سیستم است (اثرانگشت‌ّها، مجوزها، بازه‌های زمانی و از این قبیل). این پایگاه‌داده ابتدا توسط aideinit راه‌اندازی می‌شود؛ سپس به صورت روزانه توسط اسکریپت /etc/cron.daily/aide به منظور بررسی برای عدم تغییر فایل‌های مرتبط استفاده می‌گردد. زمانی که تغییر تشخیص داده شود، AIDE آن‌ها را در فایل‌های گزارش (/var/log/aide/*.log) ثبت کرده و مشاهدات خود ار از طریق ایمیل برای مدیر سیستم ارسال می‌کند.
گزینه‌های بسیاری در /etc/default/aide وجود دارد که می‌تواند برای تغییر عملکرد بسته 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 an 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.
Configuring suricata involves reviewing and editing /etc/suricata/suricata.yaml, which is very long because each parameter is abundantly commented. A minimal configuration requires describing the range of addresses that the local network covers (HOME_NET parameter). In practice, this means the set of all potential attack targets. But getting the most of it requires reading it in full and adapting it to the local situation.
On top of this, you should also edit it to define the network interface. You might also want to set LISTENMODE=pcap because the default LISTENMODE=nfqueue requires further configuration to work properly (the netfilter firewall must be configured to pass packets to some user-space queue handled by suricata via the NFQUEUE target).
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.
Alternatively, oinkmaster (in the package of the same name) can be used to download Snort rule sets from external sources.
