14.3. 监督：预防，检测，威慑

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 节 “监控”.

14.3.1. 使用 logcheck 监视日志

logcheck 程序默认每小时监视日志文件。它会把异常日志信息通过邮件发给管理员分析。

The list of monitored files is stored in /etc/logcheck/logcheck.logfiles; the default values work fine if the /etc/rsyslog.conf file has 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/violations.d/myfile 文件中的规则）只能由 /etc/logcheck/violations.ignore.d/myfile 或者 /etc/logcheck/violations.ignore.d/myfile-*extension* 文件中定义的规则忽略。

系统事件总是会被发送，除非在 /etc/logcheck/ignore.d.{paranoid,server,workstation}/ 目录中的规则指明某些事件要被忽略。当然，只有相应详细等级等于或大于所选择模式的目录会起作用。

14.3.2. 监视行为

14.3.2.1. 实时

top 是一个可以显示目前正在运行进程的交互工具。默认排序基于处理器的使用量，可以通过 P 键获取。其他排序方法包括内存使用量（M 键），总处理器时间（T 键）和处理器标识（N 键）。k 键允许输入进程标识结束进程。r 键可以 renicing 进程，例如改变优先级。

当系统过载时，top 是一个很好的工具，用来查看哪个进程抢占处理器或者消耗过多内存。特别是，检查那些进程所消耗的资源是宿主机器服务要使用的。以互联网数据用户身份运行的未知进程应该单列并调查，它很有可能是通过网络应用上的漏洞，在系统上安装并运行的软件。

top 是一个很灵活的工具，手册页中详列了如何定制显示并让其适于个人需求和习惯。

gnome-system-monitor 图形工具和 top 类似，并提供大体上相同的特性。

14.3.2.2. 历史

处理器负载，网络流量和空闲磁盘空间是一直在变化的信息。记录它们的演变常常可以用来确定电脑是如何使用的。

有很多专门工具可用于此类任务。很多可以通过 SNMP（简单网络管理协议）获取数据，集中信息。这样的好处之一是可以从非通用计算机，例如专用的网络路由器或者交换机上获取数据。

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/index.html) should be considered a prerequisite.

选择 mrtg

mrtg（在相似名称的软件包在）是一个较老的工具。尽管有些不足，但是它可以收集历史数据并以图形显示。它包含了一系列脚本用于收集最常用的监视数据，例如：处理器负载，网络流量，网页点击量，等等。

mrtg-contrib 和 mrtgutils 软件包含有可以直接使用的示例脚本。

14.3.3. 侦测变化

系统一旦安装和配置，除非安全更新，通常没有理由改变大部分文件和目录，数据除外。因此，要注意确保文件没有改变：任何非预期的变化都值得探究。本节介绍几个可以在非预期变化发生时监视文件并警告管理员（或者只列出变化）的工具。

14.3.3.1. Auditing Packages with dpkg —verify

进阶 防止上游变化

dpkg --verify is useful in detecting changes to files coming from a Debian package, but it will be useless if the package itself is compromised, for instance if the Debian mirror is compromised. Protecting against this class of attacks involves using APT’s digital signature verification system (see 第 6.5 节 “检查软件包真伪”), and taking care to only install packages from a certified origin.

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.

BACK TO BASICS File fingerprint

As a reminder: a fingerprint is a value, often a number (even though in hexadecimal notation), that contains a kind of signature for the contents of a file. This signature is calculated with an algorithm (MD5 or SHA1 being well-known examples) that more or less guarantee that even the tiniest change in the file contents implies a change in the fingerprint; this is known as the “avalanche effect”. This allows a simple numerical fingerprint to serve as a litmus test to check whether the contents of a file have been altered. These algorithms are not reversible; in other words, for most of them, knowing a fingerprint doesn’t allow finding the corresponding contents. Recent mathematical advances seem to weaken the absoluteness of these principles, but their use is not called into question so far, since creating different contents yielding the same fingerprint still seems to be quite a difficult task.

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).

#

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 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.3.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 work-arounds).

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.

#

注意本例使用 dctrl-tools 软件包中的 grep-status 命令，该命令默认情况下没有安装。

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）并将发现通过邮件发送给管理员。

实践 保护数据库

由于 AIDE 使用本地数据库来比较文件的状态，因此结果的有效性和数据库的有效性直接相关。如果攻击者获得超级用户权限，他就能替换数据库并覆盖其痕迹。一个可能的替代方案就是将参考数据储存在只读媒介上。

/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；如果所有记录的变化都是合法的，就可以用它替代参考数据库。

选择 Tripwire 和 Samhain

Tripwire 和 AIDE 非常相似；甚至是配置文件的语法都几乎相同。tripwire 所提供的额外特性是签名配置文件机制，这样攻击者就不能将其指向不同版本的参考数据库。

Samhain also offers similar features, as well as some functions to help detecting rootkits (see the sidebar 速览 checksecurity 和 chkrootkit/rkhunter 软件包). It can also be deployed globally on a network, and record its traces on a central server (with a signature).

速览 checksecurity 和 chkrootkit/rkhunter 软件包

三个软件包中，第一个包含了几个小脚本进行系统上的基础检查（空白口令，新的设置身份文件，等等）并警告管理员。尽管其名为“安全检查”，但是管理员不应该仅仅指望它来确保 Linux 系统安全。

chkrootkit 和 rkhunter 软件包可以搜索系统上安装的潜在 恶意软件（rootkits）。提示，此类软件被设计成掩盖系统已经被攻破，并谨慎的控制机器。检测并不能保证100%可靠，但是他们可以将管理员的注意力吸引到潜在问题上。

14.3.4. 侦测入侵（IDS/NIDS）

回到基础 拒绝服务

“拒绝服务”攻击只有一个目的：让服务不可用。不管是通过查询使服务器过载还是利用缺陷，最终目的都是一样的：服务不再运行。正常用户就会不悦，提供网络服务的实体声誉遭受损失（可能是营收，譬如，使用服务的是一个电子商务网站）。

Such an attack is sometimes “distributed”; this usually involves overloading the server with large numbers of queries coming from many different sources so that the server becomes unable to answer the legitimate queries. These types of attacks have gained well-known acronyms: DDoS and DoS (depending on whether the denial of service attack is distributed or not).

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.

→ http://suricata-ids.org

→ https://www.elastic.co/products/kibana

注意 行动范围

The effectiveness of suricata is limited by the traffic seen on the monitored network interface. It will obviously not be able to detect anything if it cannot observe the real traffic. When plugged into a network switch, it will therefore only monitor attacks targeting the machine it runs on, which is probably not the intention. The machine hosting suricata should therefore be plugged into the “mirror” port of the switch, which is usually dedicated to chaining switches and therefore gets all the traffic.

Configuring suricata involves reviewing and editing /etc/suricata/suricata-debian.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 /etc/default/suricata to define the network interface to monitor and to enable the init script (by setting RUN=yes). 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 behaviour, 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. Unfortunately that package is missing from Debian Jessie and should be retrieved from another Debian release like Testing or Unstable.

Alternatively, oinkmaster (in the package of the same name) can be used to download Snort rulesets from external sources.

进阶 与 prelude 集成

Prelude 将各种安全信息集中化。它的模块结构包含了服务器（prelude-manager 中的管理器）收集由各种类型的 传感器（sensors） 产生的警报信息。

Suricata can be configured as such a sensor. Other possibilities include prelude-lml (Log Monitor Lackey) which monitors log files (in a manner similar to logcheck, described in 第 14.3.1 节 “使用 logcheck 监视日志”).