怎样使用 Tripwire 来检测 Ubuntu VPS 服务器的入侵

介绍

当管理联网服务器时，服务器的安全是一个非常复杂的问题。尽管可以配置防火墙、设置日志策略、购买安全服务或者锁定应用，如果你想确保阻止每次入侵这远远不够。
一个 HIDS 可以收集你电脑的文件系统和配置，存储这些信息用来参考和判断系统当前的运行状态。如果在已知安全的状态和当前状态之间发生了改动，就表明可能已经并不安全了。
Linux 下一个流行的 HIDS 是 Tripwire。这个软件可以跟踪许多不同的文件系统数据，以检测是否发生未经授权的更改。
在本文中，我们将讨论如何在 Ubuntu 12.04 上安装和配置 Tripwire。由于 IDS 的特性，最好在创建服务器不久后就运行 IDS，以便可以确定文件系统是没有问题的。

安装 Tripwire

幸运的是，Tripwire 已经在 Ubuntu 的默认存储库中。我们可以使用apt-get来安装 Tripwire：

sudo apt-get updatesudo apt-get install tripwire

在经过需要的相当多的包依赖的配置后就可以运行了。
首先，你要配置推送依赖的邮件应用程序。如果你想配置电子邮件通知，请选择 Internet Site
它会询问你是否想在安装过程中配置密码，对这些提示都选择yes。它会询问你是否想要重新生成配置文件，选yes。对于策略文件一样选yes。
接下来你将要被要求输入site key。Tripwire使用两个密钥来确保配置文件的安全：
Site key这个密钥被用来确保配置文件的安全，我们需要确认配置文件没有被修改过，这直接导致了整个监测系统的结果是否可信。相同的配置文件可以在不同的服务器上使用，site key也可以在不同的服务器上使用。
Local key这个密钥用来确认是用户授权运行。
你会先输入 site key 然后是 local key，推荐使用强密码。

初始化数据库

安装完成之后，你必须初始化数据库。就像大多数安全程序一样，tripwire自带默认配置。也许你需要定制自己的规则，这就要修改默认设置了。
首先，如果你没有选择在安装时创建一个策略，你可以通过以下命令来创建一个：
Sudo twadmin –create-polfile /etc/tripwire/twpol/txt
你必须提供在配置时输入的site key才能执行。
这将会在我们指定的目录（/etc/tripwire）中，根据一个纯文本文件创建一个加密的策略文件。在 Tripwire 运行时会检查这个文件。
现在我们可以初始化 Tripwire 的数据库来确认我们的系统。这次将只会检查策略文件中我们特别指定的那些关键点。
因为该策略文件并不是为我们的系统定制的，所以我们会看到很多警告和错误。我们把这些错误当作调整我们配置文件时的参考。
初始化数据库的基本方法是：
Sudo tripwire –init
这将会创建我们的数据库文件，还有那些我们必须在调整配置时参考的错误。
我们想要保存配置后的结果，可以把他们保存到 tripwire 配置目录下的一个文件中。我们可以执行check，并且把文件列表存入在 tripwire 配置目录中的 test_results 文件中。
sh -c 'tripwire --check | grep Filename > test_results'
如果我们查看这些文件，我们可以这样

Less /etc/tripwire/test_resultsFilename: /etc/rc.bootFilename: /root/mailFilename: /root/MailFilename: /root/.xsession-errors. . .

配置适合你自己系统的策略文件

现在我们有了那些tripwire不能监控的文件列表，我们可以通过配置策略文件来将这些文件移除。
在编辑器中以root权限打开一个纯文本文件：
Sudo nano /etc/tripwire/twpol.txt
搜索每一个在test_results中的文件，注释掉所有你找到的匹配中的那些行。
在“Boot Script”部分，你应该注释掉/etc/rc.boot这一行，因为这在Ubuntu系统中并不存在。

(  rulename = "Boot Scripts",  severity = $(SIG_HI)){        /etc/init.d             -> $(SEC_BIN) ;        #/etc/rc.boot            -> $(SEC_BIN) ;        /etc/rcS.d              -> $(SEC_BIN) ;

有许多文件在/root目录下，这在我的系统中应该被注释掉，只要在你的系统中没有的东西都应该被注释掉。

(  rulename = "Root config files",  severity = 100){        /root                           -> $(SEC_CRIT) ; # Catch all additions to /root        #/root/mail                     -> $(SEC_CONFIG) ;        #/root/Mail                     -> $(SEC_CONFIG) ;        #/root/.xsession-errors         -> $(SEC_CONFIG) ;        #/root/.xauth                   -> $(SEC_CONFIG) ;        #/root/.tcshrc                  -> $(SEC_CONFIG) ;        #/root/.sawfish                 -> $(SEC_CONFIG) ;        #/root/.pinerc                  -> $(SEC_CONFIG) ;        #/root/.mc                      -> $(SEC_CONFIG) ;        #/root/.gnome_private           -> $(SEC_CONFIG) ;        #/root/.gnome-desktop           -> $(SEC_CONFIG) ;        #/root/.gnome                   -> $(SEC_CONFIG) ;        #/root/.esd_auth                -> $(SEC_CONFIG) ;        #/root/.elm                     -> $(SEC_CONFIG) ;        #/root/.cshrc                   -> $(SEC_CONFIG) ;        /root/.bashrc                   -> $(SEC_CONFIG) ;        #/root/.bash_profile            -> $(SEC_CONFIG) ;        #/root/.bash_logout             -> $(SEC_CONFIG) ;        /root/.bash_history             -> $(SEC_CONFIG) ;        #/root/.amandahosts             -> $(SEC_CONFIG) ;        #/root/.addressbook.lu          -> $(SEC_CONFIG) ;        #/root/.addressbook             -> $(SEC_CONFIG) ;        #/root/.Xresources              -> $(SEC_CONFIG) ;        #/root/.Xauthority              -> $(SEC_CONFIG) -i ; # Changes Inode number on login        #/root/.ICEauthority            -> $(SEC_CONFIG) ;}

应该检查的最后一部分是在/proc文件系统中出错的文件描述符。这些文件时刻更改，如果我们不在配置文件中删除，将会定期触发误报。
在“Devices & Kernel information”中，你可以看到要检查的/proc文件系统检查的列表。

(  rulename = "Devices & Kernel information",  severity = $(SIG_HI),){        /dev            -> $(Device) ;        /proc           -> $(Device) ;}

然而，我们并不希望它检查目录下的每一个文件，我们要为/proc下的所有目录配置不需要检查。

{        /dev                    -> $(Device) ;        #/proc                  -> $(Device) ;        /proc/devices           -> $(Device) ;        /proc/net               -> $(Device) ;        /proc/tty               -> $(Device) ;        /proc/sys               -> $(Device) ;        /proc/cpuinfo           -> $(Device) ;        /proc/modules           -> $(Device) ;        /proc/mounts            -> $(Device) ;        /proc/dma               -> $(Device) ;        /proc/filesystems       -> $(Device) ;        /proc/interrupts        -> $(Device) ;        /proc/ioports           -> $(Device) ;        /proc/scsi              -> $(Device) ;        /proc/kcore             -> $(Device) ;        /proc/self              -> $(Device) ;        /proc/kmsg              -> $(Device) ;        /proc/stat              -> $(Device) ;        /proc/loadavg           -> $(Device) ;        /proc/uptime            -> $(Device) ;        /proc/locks             -> $(Device) ;        /proc/meminfo           -> $(Device) ;        /proc/misc              -> $(Device) ;}

当我们在文件这个部分时，我们也想要对/dev/pts文件系统做些事情。Tripwire默认不会检查这个目录，为了让tripwire也检查这个目录，我们可以显式的指定：

{        /dev                    -> $(Device) ;        /dev/pts                -> $(Device) ;        #/proc                  -> $(Device) ;        /proc/devices           -> $(Device) ;        /proc/net               -> $(Device) ;        /proc/tty               -> $(Device) ;        . . .

最后一件事儿是要注释掉/var/run和/var/lock的所在行，使我们的系统不会因为系统的正常服务更改而产生标记。

(  rulename = "System boot changes",  severity = $(SIG_HI)){        #/var/lock              -> $(SEC_CONFIG) ;        #/var/run               -> $(SEC_CONFIG) ; # daemon PIDs        /var/log                -> $(SEC_CONFIG) ;}

当你完成这些编辑之后保存并关闭文件。
现在我们的配置文件就修改好了，我们需要重新创建一个加密的策略文件来让tripwire能够读取使用：
sudo twadmin -m P /etc/tripwire/twpol.txt
创建之后，我们必须重新初始化数据库以执行我们的策略：
sudo tripwire –init
之前得到的警告现在应该都没有了。如果还有警告，你就要编辑/etc/tripwire/twpol.txt文件直到警告完全消失。

检验配置

如果你的数据库初始化没有报错，配置文件就和你的系统相匹配了。但是我们应该运行一下Check来看看是否tripwire确实没有错误。
基本的语法检查：
sudo tripwire --check
你应该看到屏幕上定制了一个输出报告，指出你的系统里没有错误。
一旦完成，你就可以确信你的配置是正确的。我们应该从我们的系统中清理掉敏感信息。
我们应该删除掉我们之前创建的test_results：
Sudo rm /etc/tripwire/test_results
另一个需要做的事情就是把纯文本的配置文件删除。我们已经经过密码加密了，可以确保安全。
我们必须把一个纯文本文件加密之后才能交给twadmin执行，同样的，我们也都要生成加密的版本。我们通过管道就可以再一次把它变成纯文本文件：
Sudo sh –c ‘twadmin –print-polfile > /etc/tripwire/twpol.txt’
现在把他移动去备份位置，再重新创建它

sudo mv /etc/tripwire/twpol.txt /etc/tripwire/twpol.txt.baksudo sh -c 'twadmin --print-polfile > /etc/tripwire/twpol.txt'

如果执行正常，你可以安全的删除纯文本文件了：

sudo rm /etc/tripwire/twpol.txtsudo rm /etc/tripwire/twpol.txt.bak

设置邮件提醒

我们会配置Tripwire每天自动运行并自动通知。在运行时，当系统发生更改时，需要升级数据库。
我们将使用mail命令来给我们的电子邮件地址发送我们的通知。在我们的系统暂时没有安装，需要从存储仓库下载。
这给我们一个很好的机会通过tripwire来查看系统做了哪些更改。
安装如下：
Sudo apt-get install mailutils
现在我们已经安装完成了，让我们测试一下是否可以发送报告。这份报告会同时把警告和改变都发送，当我们安装新软件时不需要通知tripwire:
Sudo tripwire --check | mail –s “Tripwire report for ‘uname –n’” [e-mail]
很快你的邮箱将会收到一封报告，关于刚刚安装软件的详细信息。这表明，Tripwire可以把文件系统的更改通过邮件发送给我们了。
我们现在应该进行更新数据库进行交互检查，通过以下命令：
sudo tripwire --check --interactive
这是和平时相同的运行测试，但是最后不会输出到屏幕，而是生成文本文件在默认编辑器中打开。
这份报告会包含每一个文件更改的全部细节。事实上，在我的机器上，报告通常有2275行那么长。其中大量的信息对于解决安全问题相当有帮助，但是对于我们来说，我们对其大部分都不感兴趣。
最重要的部分都在顶部，在一些介绍信息后，你应该能看到表明新增或修改的复选框。
这些复选框表明你需要更新数据库，以完成这些更改。你应该搜索每一个带有×的复选框，然后确认这些更改是否经过你的同意。
如果你不认可这些更改，就把×删除。数据库的文件将不会更新，这将导致下次报告时tripwire还会报告这次标记。
在你决定好哪些文件需要更改后，保存并关闭这个文件。
这它会要求你输入local key以便tripwire可以更新数据库文件。
如果我们在接受这些更改之后再次运行命令，报告肯定会更短。

用Cron使Tripwire自动化

现在我们已经可以手动让这些功能运行，我们也可以设置定时任务让tripwire可以每天早上都执行检查。
我们要使用root的定时任务，因为编辑系统定时任务可以不包括系统更新。
可以提供过以下命令来确认root是否已经存在定时任务：
sudo crontab -l
如果定时任务已经存在，你应该把这个任务通过管道备份一下：
sudo sh -c 'crontab -l > crontab.bad'
之后我们可以编辑这个定时任务：
sudo crontab -e
如果这是你第一次运行定时任务，它会问你希望用哪个编辑器打开。如果你没有习惯的编辑器，nano也是个不错的选择。
打开文件后，我们就可以定制自动化的Tripwire了。因为我们只需要tripwire每天运行，我们只需要设置启动时间就够了。
通常服务会在非繁忙时段运行以免干扰繁忙时段。
我们需要使用的命令格式是 min hour * * * command。这个命令和我们之前配置邮件发送报告使用的是一个命令。此时运行的就是root所以我们不需要使用sudo。
为了让tripwire在每天上午3：30运行，我们可以这么写：

30 3 * * * /usr/sbin/tripwire --check | mail -s "Tripwire report for `uname -n`" [e-mail]

你可以根据你的需要进行调整。

结语

你现在拥有了一个自动的入侵检测系统，它会向您发送您文件系统上的更改报告。你应该定期检查通过电子邮件发送的报告监控出现的更改。无论是发现可疑的活动还是正常的更改，都应该升级Tripwire的数据库。

原文地址