14.3.1. مانیتورینگ گزارش‌ها با استفاده از logcheck
برنامه logcheck به صورت پیشفرض در هر ساعت به فایل‌های گزارش نظارت کرده و پیام‌های گزارش غیر معمول را از طریق ایمیل به مدیر سیستم برای تحلیل بیشتر ارسال می‌کند.
The list of monitored files is stored in /etc/logcheck/logcheck.logfiles and /etc/logcheck/logcheck.logfiles.d/; the default values work fine with systemd and rsyslog if their configuration files have not been completely overhauled.
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 ابزار بسیار منعطفی است و صفحه راهنمای آن جزئیات بیشتری را درباره سفارشی‌کردن برای نیازهای خاص کاربر نمایش می‌دهد.
The gnome-system-monitor graphical tool is similar to top and it provides roughly the same features. Alternatives are atop and htop, which provide similar functionality, but differ in usability features, like the scrolling ability.
Processor load, memory usage, network traffic and free disk space are information that are constantly varying. Keeping a history of their evolution is often useful in determining exactly how the computer is used.
There are many dedicated tools for this task. The sysstat package, for example, collects and displays system performance statistics locally. The data can then be visualized with the sar command. Most tools, though, can fetch data via SNMP (Simple Network Management Protocol) in order to centralize this information. An added benefit is that this allows fetching data from network elements that may not be general-purpose computers, such as dedicated network routers or switches.
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 or the system journal. 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 and fail2ban.d/*.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 and jail.d/*.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 = 1h
[...]
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 1 hour.
The default backend used now is systemd. The old log files, like auth.log are only available if rsyslog has been installed and enabled.
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.
If docker containers are involved, the rules injected into iptables by fail2ban to block traffic from specific IPs must be applied to the right chain by chain = DOCKER-USER. Otherwise, the ban will not work.
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. It is also possible to increase the block time with each ban for the same IP.
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 (or dpkg -V) is an interesting tool since it allows finding what installed files have been modified (potentially by an attacker), but this should be taken with a grain of salt. To do its job it relies on checksums stored in dpkg's own database which is stored on the hard disk (they can be found in /var/lib/dpkg/info/package.md5sums); a thorough attacker will therefore update these files so they contain the new checksums for the subverted files. The same is true for debsums.
اجرای dpkg -V تمام بسته‌های نصب شده را مورد بررسی قرار داده و به ازای هر کدام که در این آزمون شکست بخورند در خط جداگانه‌ای نمایش داده می‌شود. قالب خروجی مشابه با rpm -V است که در آن هر کاراکتر بیانگر یک آزمون روی اطلاعات جانبی بسته است. متاسفانه dpkg اطلاعات جانبی مورد نیاز بسته را ذخیره‌سازی نمی‌کند و آن‌ها را به صورت علامت سوال در خروجی نمایش می‌دهد. در حال حاضر تنها آزمون checksum منجر به تولید "5" در سومین کاراکتر آن (زمانی که شکست بخورد) می‌شود.
# dpkg -V
??5?????? c /etc/logcheck/logcheck.logfiles.d/syslog.logfiles
??5?????? c /etc/logrotate.d/apt
??5?????? /lib/systemd/system/ssh.service
??5?????? c /etc/systemd/journald.conf
??5?????? c /etc/lvm/lvm.conf
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 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. The tool can be considered the successor of
snort, which has been removed from Debian.
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 to define the network interface. You might also want to set LISTENMODE=pcap in /etc/default/suricata 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.
Unfortunately, the mentioned packages are not part of the current Debian
Bookworm release. But they can still be retrieved via the Debian package search or from the Debian snapshot archive.
