Monitoring is an integral part of any security policy for several reasons. Among them, that the goal of security is usually not restricted to guaranteeing data confidentiality, but it also includes ensuring availability of the services. It is therefore imperative to check that everything works as expected, and to detect in a timely manner any deviant behavior or change in quality of the service(s) rendered. Monitoring activity can help detecting intrusion attempts and enable a swift reaction before they cause grave consequences. This section reviews some tools that can be used to monitor several aspects of a Debian system. As such, it completes
第 12.4 节 “监控”.
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}/ 目录中的规则指明某些事件要被忽略。当然，只有相应详细等级等于或大于所选择模式的目录会起作用。
top 是一个可以显示目前正在运行进程的交互工具。默认排序基于处理器的使用量，可以通过 P 键获取。其他排序方法包括内存使用量（M 键），总处理器时间（T 键）和处理器标识（N 键）。k 键允许输入进程标识结束进程。r 键可以 renicing 进程，例如改变优先级。
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.
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 是一种非常简单而有效的方法，可以抵御最常见的暴力攻击，但它无法抵御分布式暴力攻击，即当攻击者使用大量分散在互联网上的计算机时。
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.
Running dpkg -V will verify all installed packages and will print out a line for each file with a failing test. The output format is the same as the one of rpm -V where each character denotes a test on some specific meta-data. Unfortunately dpkg does not store the meta-data needed for most tests and will thus output question marks for them. Currently only the checksum test can yield a "5" on the third character (when it fails).
# 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).
Since the data on the disk cannot be trusted, debsums offers to do its checks based on .deb files instead of relying on dpkg's database. To download trusted .deb files of all the packages installed, we can rely on APT's authenticated downloads. This operation can be slow and tedious, and should therefore not be considered a proactive technique to be used on a regular basis.
# apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package`
[ ... ]
# debsums -p /var/cache/apt/archives --generate=all
注意本例使用 dctrl-tools 软件包中的 grep-status 命令，该命令默认情况下没有安装。
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.
AIDE（Advanced Intrusion Detection Environment ）工具可以检查文件完整性，侦测系统之前文件镜像的任何变化。这种影响以数据库（/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；如果所有记录的变化都是合法的，就可以用它替代参考数据库。
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.
