尽管我们希望我们强化的系统坚不可摧，但安全并非绝对的游戏：必须认识到系统遭到破坏的可能性。Tripwire 开源版是一个免费且开源的软件包，它使我们有合理的机会在可能的漏洞发生时立即收到通知。

诸如 Tripwire 之类的完整性检查器会创建系统二进制文件、配置文件以及其他可能在安全漏洞发生期间或之后被篡改的内容的加密“指纹”。然后，它们会定期对照存储的指纹检查这些文件，并将差异通过电子邮件发送给您。

Tripwire 是最著名和最成熟的完整性检查系统，也是我们即将深入讨论的系统。您可能还会对 AIDE 感兴趣，它比 Tripwire 开源版在更多平台上运行；以及 FCheck，它完全用 Perl 编写，因此，甚至比 AIDE 或 Tripwire 更少依赖平台（它甚至可以在 Windows 上运行）。有关 AIDE 和 FCheck 网站的链接，请参见本文末尾的“资源”部分。

完整性检查机制就像系统备份；我们希望永远不需要它们，但如果我们确实需要它们而它们又不存在，那将是灾难。此外，与系统备份一样，完整性检查是更大计划的重要组成部分。如果系统已按照行业最高标准（或至少常识）进行了强化、修补和维护，则完整性检查器将提供最后的安全网，以帮助最大限度地减少任何高明的破解者设法潜入所造成的损害。

完整性检查器运行的原则很简单：如果文件意外更改，则很可能是被入侵者更改了。例如，系统破解者在“rooting”系统后通常会做的第一件事之一是用“rootkit”替换常见的系统实用程序，例如 ls、ps 和 netstat，这使得它们看起来可以正常工作，但会方便地无法列出可能暴露破解者存在的文件、进程和连接（分别是）。

完整性检查器可用于创建重要系统二进制文件、配置文件或我们不希望或不希望更改的任何其他内容的哈希值（校验和）数据库。通过定期对照完整性检查器的数据库检查这些文件，我们可以最大限度地减少我们的系统在不知不觉中被攻破的可能性。系统被攻破与管理员得知此事之间的时间越短，管理员抓住或至少驱逐入侵者的机会就越大。

一个警告：任何数据库不可靠的完整性检查器都是毫无价值的。在从可信介质安装主机操作系统后，尽快创建此数据库至关重要。我再说一遍：除非完整性检查器的数据库是在干净的系统上初始化的，否则安装、配置和维护完整性检查器是不值得的。

在普渡大学 COAST 项目 (http://www.cerias.purdue.edu/coast/) 中最著名和最有用的成果之一是由 Eugene Spafford 博士和 Gene Kim 创建的 Tripwire。Tripwire 最初是开源且免费的，但在 1997 年转为商业化，免费使用仅限于学术和其他非商业环境。

令人高兴的是，去年 10 月，Tripwire, Inc. 发布了 Tripwire 开源版，Linux 版本。在那之前的 Tripwire 商业版本包含旧的学术源代码版本中没有的功能。相比之下，Tripwire 开源版是商业产品的或多或少当前的版本。除了缺少企业功能（例如多系统的集中管理）之外，它与 Tripwire for Servers 产品非常相似。

请注意，Tripwire 开源版仅在非商业 Unix 系统（即 Linux 和 Free/Net/OpenBSD）上免费使用。实际上，它仅在 Red Hat Linux 和 FreeBSD 上获得官方支持，尽管没有理由它不应在其他 Linux 和 BSD 发行版上同样良好地编译和运行。只有较旧的学术源代码版本才可在商业 Unix 系统（例如 Sun Solaris 和 IBM AIX）上免费使用；这些系统必须购买专有版本。

但我们都是 Linux 极客，对吧？在接下来的讨论中，我将重点关注 Tripwire 开源版，Linux 版本。

截至撰写本文时，Tripwire 开源版的最新版本是 2.3.1-2。可以从 http://sourceforge.net/projects/tripwire/ 下载源代码 tarball。我强烈建议您获取、编译和安装此版本。虽然 Tripwire 的历史上只有一个重大的安全问题（而且只是拒绝服务风险），但我们使用 Tripwire 是因为我们很偏执。对于偏执狂来说，只有最新的（稳定）版本才足够好。

话虽如此，Red Hat 7.0 随附的二进制版本相当新。据我所知，Red Hat 的 v2.3-55 RPM 和官方源代码发布 v2.3.1-2 之间的差异涉及非安全相关的错误修复；因此，使用您的库存 RH 7.0 RPM 可能不会冒很大的风险。但不要说是我告诉你的！

要编译 Tripwire 开源版，请将存档移动到 /usr/src 并解压缩，例如，tar -xzvf ./tripwire-2.3.1-2.tar.gz。接下来，检查您是否具有从 /usr/bin/gmake 到 /usr/bin/make 的符号链接（非 Linux Unix 系统并非都带有 GNU make，因此 Tripwire 明确查找 gmake——当然，在大多数 Linux 系统上，这只是称为 make）。如果您没有，则创建此链接的命令是 ln -s /usr/bin/make /usr/bin/gmake。

另一个要检查的是 /usr/share/man 中是否有一整套子目录——Tripwire 需要将 man 页面放置在 man4、man5 和 man8 中。在我的 Debian 系统上，/usr/man/man4 丢失了，结果安装程序创建了一个名为 /usr/share/man/man4 的文件，该文件当然实际上是一个错误地复制到该名称而不是其中的 man 页面。

最后，阅读源代码的 README 和 INSTALL 文件，更改为源代码树的 src 目录（例如，/usr/src/tripwire-2.3.1-2/src），并对 src/Makefile 中的变量定义进行您认为必要的任何更改。确保验证是否取消注释了适当的 SYSPRE 定义（SYSPRE = i386-pc-linux、SYSPRE = sparc-linux 等）。

现在我们准备好编译了，输入 make release。这将需要一段时间，所以现在是吃三明治的好时机。构建完成后，向上导航一个目录级别，例如 /usr/src/tripwire-2.3.1-2，并执行以下两个命令

cp ./install/install.cfg .
cp ./install/install.sh .

现在用您喜欢的文本编辑器打开 install.cfg；虽然默认路径可能很好，但您至少应检查“邮件选项”部分。这是我们最初告诉 Tripwire 如何路由其日志的地方。如果我们设置 TWMAILMETHOD=SENDMAIL 并为 TWMAILPROGRAM 指定一个值，Tripwire 将使用指定的本地邮件程序（默认为 sendmail）将其报告传递给本地用户或组。

相反，如果我们设置 TWMAILMETHOD=SMTP 并为 TWSMTPHOST 和 TWSMTPPORT 指定值，Tripwire 将通过指定的 SMTP 服务器和端口将其报告通过邮件发送到外部电子邮件地址。请注意，如果您稍后改变主意，“邮件选项”设置可以随时在 Tripwire 的配置文件中更改。

如果您安装 Tripwire 的系统是多用户系统，并且您或其他系统管理员经常登录并阅读电子邮件的系统，则 SENDMAIL 方法可能是首选。如果系统是您通常从其他系统远程管理的系统，则 SMTP 方法可能更好。

一旦 install.cfg 设置为您喜欢的样子，就该安装 Tripwire 了。只需输入 sh ./install.sh。系统将提示您输入站点和本地密码；站点密码保护 Tripwire 的配置和策略文件，而本地密码保护 Tripwire 数据库和报告。这允许在多个主机上使用单个策略，以便集中控制 Tripwire 策略，但分配数据库管理和报告生成的责任。

毋庸置疑，安装 RPM 更简单、更快捷（但再次注意，最新版本的 Tripwire 可能无法以这种格式提供）。您唯一需要知道的是，在运行 rpm 后，您需要输入 /etc/tripwire/twinstall.sh 以生成站点和本地密码。此脚本的行为与源代码分发 install.sh 脚本的结尾非常相似——请参阅上一段。

尽管 Tripwire 非常有用，但它以难以配置而闻名（这对于大多数功能强大且灵活的工具来说当然是如此）。但这实际上并没有那么糟糕，并且通过遵循我即将提出的简单说明，您可以有效地使用 Tripwire 来抓住一些坏人。所以现在，让我们进入不仅安装了 Tripwire，而且实际上使用了 Tripwire 的精英用户行列！

我们需要做的第一件事是仔细检查我们的配置文件 tw.cfg。实际上，此文件刚刚由安装脚本加密，但为了方便起见，名为 twcfg.txt 的明文副本应位于 /etc/tripwire 中。这是更改您在运行安装脚本后对任何设置有其他想法的地方，并且变量也相应地命名。

如果您进行任何更改，请使用以下命令重新加密配置文件

twadmin --create-cfgfile --site-keyfile ./site.key twcfg.txt

其中 site.key 是安装时创建的站点密钥的名称，而 twcft.txt 是您刚刚编辑并希望加密的明文配置文件的名称。鉴于这些是这些文件的默认名称，这似乎很明显，但您可以随意命名它们。无论如何，不要忘记指定密钥文件，否则 twadmin 将返回错误（请记住，此练习的目的是加密配置文件）。

警告：作为一种惯例，您不应将 Tripwire 配置 (tw.cfg) 或策略 (tw.pol) 文件的明文副本留在您的硬盘驱动器上。编辑并加密它们后，删除明文版本。您始终可以使用以下命令稍后检索它们

twadmin --print-cfgfile > mycfg.txt

其中，可以预见的是，您可以将 mycfg.txt 替换为您喜欢的任何名称。

虽然我还没有详细描述 Tripwire 二进制文件（在上下文中解释它们更有用），但您无疑已经猜到 twadmin 用于管理 Tripwire 的配置、密钥和（最初，至少）策略文件。

与 Tripwire 配置文件一样，策略以文本文件形式编辑，但在安装前会进行加密和签名。但是，与配置文件不同，我们仅使用 twadmin 命令在给定系统上首次安装策略文件；随后我们将使用策略更新模式下的 tripwire 命令。

无论如何，在安装 Tripwire 后首次安装策略的命令是

twadmin --create-polfile twpol.txt

其中 twpol.txt 是您要安装的明文策略文件的名称。

与配置文件一样，您不应将明文策略文件留在您的系统上。如果您以后需要参考或编辑策略，可以通过键入以下内容来检索它

twadmin --print-polfile > mypol.txt

mypol.txt 可以是您希望调用策略的明文副本的任何名称。（在这里看到模式了吗？）

现在我们开始认真的巫术。Tripwire 的策略文件是它的大脑：它指定要查看什么、要查找什么以及对此做什么。它在用户友好性方面也有点欠缺，尽管在这方面远没有 sendmail.cf 那么糟糕（但准备记住一些缩写）。

自然地，Tripwire 开源版附带一个默认策略文件，并且自然地，如果您愿意，可以使用它作为您自己的个人 Tripwire 策略。但是，由于默认策略是为运行发行版中几乎所有内容的 Red Hat 系统创建的，因此您应该大量编辑此策略，而不是按原样使用它。

首先，关于调整。如果您的策略没有检查足够的文件，或者没有足够仔细地查看它检查的文件，则 Tripwire 的目的就会落空，并且恶作剧将无法被检测到。相反，如果策略过于批判性地查看您期望以任何方式更改的文件，Tripwire 将生成“误报”，除了分散您对实际差异的注意力外，没有任何作用。

您第一次不太可能创建健全的基线。您几乎肯定需要持续调整您的策略，尤其是在您第一次运行完整性检查之后。因此，即使您确实拥有与设计默认 Tripwire 开源策略的系统配置完全相同的 Red Hat 系统，您仍然需要学习正确的 Tripwire 策略语法。让我们开始破解。

我将通过将工作策略文件分解为可管理的块来解释策略文件结构和语法。我们将首先查看的块来自我们的示例策略文件的开头，并列出一些变量定义

WEBROOT=/home/mick/www;
CGIBINS=/home/mick/www/cgi-bin;
TWPOL="/etc/tripwire";
TWDB="/var/lib/tripwire";

我们可以使用这些变量来节省宝贵的触摸打字精力。接下来是下一个块，一些更高级的变量定义

BINS          = $(ReadOnly) ; # Binaries that should
                                not change
SEC_INVARIANT = +tpug ;       # Dir.s that shouldn't
                                change perms/ownership
SIG_MED       = 66 ;          # Important but not
                                system-critical files

第二行定义了“属性掩码”；属性掩码是 Tripwire 检查的文件属性的缩写。由于属性掩码字符串可能晦涩难懂且笨拙，因此大多数人更喜欢使用变量来引用它们。实际上，Tripwire 附带了许多预先声明的变量，这些变量设置为常见的属性掩码，第一行实际上引用了其中一个，ReadOnly，这是一个用于不应以任何方式更改的文件（如二进制文件）的属性掩码。我们将详细讨论属性掩码，但一切都会在适当的时候进行。

第三行创建了严重性级别的名称。严重性级别可用于区分不同重要性规则。当使用 --severity N 参数调用 tripwire 命令时，只会解析分配了严重性级别等于或大于 N 的规则。如果未使用此参数，则将解析所有规则。另请注意，如果规则没有关联的严重性级别，则该级别将默认为零。也就是说，只有在未指定 --severity 参数时才会解析该规则。

现在我们已经对策略变量及其用途有所了解，让我们开始查看实际规则

# Mick's Web Junk
(
  rulename = "MickWeb",
  severity = $(SIG_MED),
  emailto = mick@uselesswebjunk.com
)
{
  $(WEBROOT)             -> $(ReadOnly) (recurse=1) ;
  !$(WEBROOT)/guestbook.html ;
  $(CGIBINS)             -> $(BINS)     ;
  /var/log/httpd         -> $(Growing)  ;
}

这是一个非常丰富的块，因此我们将从规则结构开始。规则可以单独存在，也可以根据共同属性分组在一起；此列表显示了一组规则（包含在花括号内），其中包含几个共享属性（在规则上方的括号中）。此组的规则名称为“MickWeb”，该组的严重性为 66，并且涉及该组的报告将通过电子邮件发送到 mick@uselesswebjunk.com。请注意，属性用逗号分隔，而每个规则都以分号结尾。

属性也可以分配给单个规则。此组中的第一个规则的属性 recurse 设置为 1，这意味着将向下检查一级目录 /home/mick/www（即，目录本身加上紧靠“下方”的所有内容，但不进一步）。请注意，默认情况下，目录将尽可能向下递归；实际上，recurse 属性的默认值为“True”。

规则语句中列出的属性通常会覆盖规则组上方括号中列出的属性。例外情况是属性“emailto”，它是累积的：如果组具有共享的 emailto 字符串，并且该组的规则之一具有不同的 emailto 字符串，则与该规则相关的报告将通过电子邮件发送到这两个字符串中的所有电子邮件地址。

顺便说一句，只有四个属性：rulename、severity、emailto 和 recurse。有关这些属性的更多详细信息，请参阅“资源”部分。

在 MickWeb 的组属性之后，我们有一些实际规则。请注意使用变量来指定对象（Tripwire 用于文件和目录的术语）和属性掩码。实际上，没有一个规则使用“longhand”属性掩码。这是常见的做法，并且完全可以接受。

紧接在第一个规则下方，该规则告诉 Tripwire 将我的 WWW 目录的第一级视为只读，我们有一个以感叹号开头的语句。此语句称为停止点，它定义了规则的例外。在本例中，停止点告诉 Tripwire 忽略对文件 /home/mick/www/guestbook.html 的更改。属性不适用于（也不能分配给）停止点。

好了，这是一个完整的策略文件（至少在技术上是这样——它根本不检查任何系统二进制文件或配置文件——真正的策略要长得多）。清单 1 显示了它的所有未解剖的荣耀。

清单 1. 示例策略文件

您可能已经注意到，整个文件仅包含一个对属性掩码的显式引用：SEC_INVARIANT 设置为“+tpug”的变量声明。这是什么意思？

属性掩码是一系列文件/目录属性，应针对给定对象检查或忽略这些属性。加号后面的属性将被检查；减号后面的属性将被忽略。这些属性缩写如表 1 所示。

表 1. 属性掩码值

Tripwire 自己的文档深入描述了这些属性。如果您不熟悉某些更深奥的文件属性（例如，inode 引用计数），我建议阅读 Card、Ts'o 和 Tweedie 的论文“第二扩展文件系统的设计和实现”（请参阅下面的“资源”）。至于哈希类型，请注意，通常您不希望每个规则使用超过一两个加密哈希：这些都是 CPU 密集型的。另一方面，不要仅仅依赖 CRC-32 哈希，它速度很快，但更容易被破坏。

正如我之前提到的，Tripwire 有许多预定义（硬编码）的变量来描述属性掩码，如表 2 所示。

表 2. 预定义的 Tripwire 属性掩码变量

在大多数情况下，使用这些预定义的掩码比“自己滚动”它们更简单。但是，请注意，您可以将这些变量与附加属性组合，例如，

/dev/console  -> $(Dynamic) -u ;
# Dynamic, but UID can change

与

/dev/console  -> +pingutd-srlbamcCMSH-u

twadmin --create-polfile policyfile.txt

要初始化数据库，我们现在使用 tripwire 命令：tripwire --init。没有比这更简单的了，不是吗？但仅在创建新数据库时使用 --init 指令。如果您以后需要更改 Tripwire 策略，最好使用以下命令

twadmin --print-polfile > mypolicy.txt
  # dump current installed plcy
vi mypolicy.txt
  # make changes to policy
tripwire --update-policy mypolicy.txt
  # install new policy --
  # DON'T USE TWADMIN FOR THIS!

安装数据库后，我们可以针对它运行定期检查。最简单的命令是：tripwire --check。这会将所有受保护的文件与哈希数据库进行比较，并将报告打印到屏幕和二进制文件。可以使用以下命令再次查看报告

twprint --print-report --report-level N --twrfile /path/file

其中 N 是 0 到 4 之间的数字，0 是单行摘要，4 是包含完整详细信息的完整报告。/path/file 是最新报告的完整路径和名称（默认情况下它应位于 /var/lib/tripwire/report 中）。

要让 Tripwire 自动通过电子邮件将报告发送给策略中指定的所有收件人，我们可以改为这样运行我们的检查

tripwire --check --email-report

请注意，报告仍会打印到标准输出并保存到 /var/lib/tripwire/report 中。

如果您在 Red Hat 7 系统上安装了 Tripwire RPM，则您的系统已经设置为定期在检查模式下运行 Tripwire。RPM 包括脚本 /etc/cron.daily/tripwire-check。但是，如果您在 Tripwire 策略中使用了 emailto 属性，则您可能希望编辑此脚本的倒数第二行以读取

test -f /etc/tripwire/tw.cfg && /usr/sbin/tripwire --check --email-report

（此行默认缺少 --email-report 标志。）

除非您定期手动、通过 cron/anacron 或它们的某种组合运行检查，否则 Tripwire 不会告诉您太多信息。

那么，当 Tripwire 报告违规时会发生什么？这取决于您。通常，违规是 Tripwire 策略过于严格而不是实际欺骗行为的结果。您需要确定哪些是哪些以及如何处理它们。

无论哪种方式，您都可能希望在发现违规后更新 Tripwire 数据库，以便它反映对正在监视的文件和目录的任何合法更改。有两种方法可以做到这一点。第一种是以更新模式运行 tripwire 命令

tripwire --update --twrfile /var/lib/tripwire/report/myhost-date.twr

最后一个参数是您希望用作此更新基础的报告的绝对路径。这将使用 tw.cfg 中指定的编辑器打开报告，以便您可以指示您希望 Tripwire 不在其数据库中更新的更改文件/目录（如果有）。换句话说，当您退出编辑会话时，Tripwire 将仅更新数据库中旁边带有 X 的报告条目的属性和哈希值（默认情况下它们都是）。

以下是 tripwire-update 会话的摘录

Remove the "x" from the adjacent box to prevent
updating the database with the new values for this
object.
Modified:
[x] "/home/mick/www"

如果我从此条目中删除“x”，退出编辑器并运行检查，则 /home/mick/www 更改将再次报告；数据库将不会更新以反映此更改。简而言之，如果更改是合法的，请将“x”留在那里。如果不是，或者您不确定，请删除“x”。

更新 Tripwire 数据库的第二种方法是以“交互式”模式执行实际检查，这会在检查完成后立即触发更新会话。因此，

tripwire --check --interactive

与

tripwire --check
tripwire --twrfile /var/lib/tripwire/report/reportname.twr

当您获得误报时，通常有必要微调您的策略。请记住按照上面“编辑或创建策略”部分末尾描述的方式执行此操作。

在本月结束之前，我向您介绍 Ron Forrester（Tripwire 开源版项目经理）教给我的两个优秀技巧

我希望这足以让您入门；我在这里没有涵盖或只是浅尝辄止的内容还有很多。请相信我，此工具的功能值得其学习曲线，并且 Tripwire 开源版手册（见下文）既全面又写得非常好。祝你好运！

资源

侧边栏