作者：洪小叶
配置
SNARE安装完成并开始运行后，还需要对其进行一些配置。就像syslogd监控程序有syslog.conf一样，auditd监控程序也有audit.conf文件。安装完成后，该文件会被置于/etc/audit目录下。应该说，该文件很直观，但为确保其格式正确，所以建议只通过GUI进行修改。要配置该文件，你可以到“Setup,Audit Configuration”菜单。在此可修改下列一些参数：
AuditType：缺省为“Objective”；另外一个选项为“Event”。
HostID：可以在此指定远程主机的名字来显示其SNARE日志文件。
Objectives：想要审查的级别。
Events：所有可审查的内核调用。
Output：你想要存储日志文件的地方；缺省为/var/log/audit/audit.log。
Audit.conf文件也由相同的内容组成。如果选择了Objective审查，那么显示的规则文件就会被应用。如果选择了Events日志，那么在Event章节的调用列表就会显示0或者1，以指示其是否被进行日志记录。注意在此可以选择Objective日志或者Kernel日志，但是不可以同时选择二者。
SNARE的灵活性，主要还是体现在通过Objective日志来配置规则方面。当然，我们选择使用哪一种类型，主要取决于我们使用该工具的原因，但是如果想对所审查的内容有更多的控制，那么最好使用Objective审查方式。
当添加一个目标规则(在Audit Configuration的Current Objectives标签页上点击“Add an Objective”按钮)，我们就可以看到配置规则的选项(见图2)。
图2 配置规则时的选项
SNARE将其为了5个步骤：
1． 高级别的配置；
2． 想要审查的过滤器；
3． 是否审查事件的成功、失败或者成功和失败的过滤器；
4． 是否审查所有使用的事件，或者选择审查某一用户的事件；
5． 当该事件发生时，为其选拔警报级别。
其中警告级别包括从Critical到Clear。其中Clear表示无关紧要，它只是提示有某件事情发生了。信息提示时，如果有好的事情发生，使用的是绿色；Warning使用的是黄色；Priority使用的是橙色；Critical使用的是红色。
Objective日志
事实上，缺省的Objective配置已经涵盖了想要审查的基本内容，它监控读写或者创建/etc/shadow文件、读或者创建/etc/passwd文件、读写或者创建audit文件。此外，/sbin、/usr/sbin、/bin和/usr/bin目录的使用，su程序的使用，接受一个新的连接，切换到/etc和/var/log目录，打开一个向外的连接等都会受到监控。对于一个更完善的审查系统，建议还应该监控一些其它的文件。这主要取决于可用资源和磁盘空间。
我关注的是是否有人修改、增加或者使用了我系统中的一些重要文件。这些文件包括：login、telnet、ftp、netstat、ifconfig、ls、ps、ssh、find、du、df、sync、reboot、halt和shutdown。可以设置一个规则来监测对每一个文件的操作，此外还要注意在/sbin、/usr/sbin、/bin和/usr/bin目录中对文件写及创建的操作。这看起来是有些麻烦，但却十分的必要。因为缺省的规则集并不对这些内容进行监控，所以一些潜在的问题很容易被忽略。
此外，其它一些我们可能想要监控其修改行为的文件是/etc/lilo.conf、/etc/syslog.conf、/etc/resolv.conf和/etc/sendmail.cf文件。如果lilo.conf文件被修改，一定要引起注意，尤其是在最近没有升级内核的话，更是要知道其被修改的原因。如果resolv.conf文件被修改了，很有可能是有人试图想让你的主机变成一个非你所期望的DNS服务器。如果一个攻击者想要掩盖其痕迹的话，他很有可能就要修改你的syslog.conf文件。还有，如果你的服务器上运行有Sendmail的话，建议你最好为Sendmail.cf设置一个过滤器。如果有人修改该文件，很有可能是有人想在你的Sendmail环境中开启一些你并不想开启的服务(比如VRFY和EXPN)，这将直接导致很多电子邮件账号信息泄露。
也许你想要监控所有在你的Linux服务器上运行的非本地的应用程序的客户应用程序文件，那么你在设置规则集时需要先进行测试，看一看你的硬件平台是否有足够的处理负载的能力。当然了，这主要取决于所监控文件的多少。
Event(Kernel)日志
正如前面所提到的，如果使用内核日志，那么一定要注意到底有多少可用的磁盘空间以及到底要做多少内核日志。因为有很多选项可以选择是否做日志，并且在内核级别上，相对要敏感得多。
在这个级别上，可以通过SNARE监控的内容包括：资源访问和安全、命令的执行和资源的创建和删除。资源的访问和安全，这其中包括setuid、open、rename、chmod和chown等调用。命令执行包括chroot、reboot以及套接字调用等。资源创建和删除则包括symlink、create_module和mknod。这些调用的审查都不考虑用户，也就是说对所有用户都要审查。可以把它们都选上，但是事实上只有在服务器上时才有必要对这个级别的日志进行详细的设置。
测试配置
我们测试Objective和Kernel日志，以观察二者实现的功能。在现实中，不管我们多么确信自己的设置万无一失，都要对其进行一下测试。我们进行最小的测试(测试Objective使用了audit.conf的缺省设置，而测试Event时则使用了选择性的内核调用)来感受一下SNARE的操作过程。然后，以一个用户的身份登录，并且在系统上做了一些随机的事情，观察一下auditd对信息的传输到底有什么影响。
首先我尝试着查找audit.conf文件，并且试图使用telnet进行向外的连接。在audit.conf文件中，这两个行为都是被设置为需要监控的。然后我查看了审查日志，发现记录的内容很少，主要是关于telnet会话的一些内容(比如进行了什么类型的调用、程序的权限、以及返回代码等)，但是这已经完全记录了我的操作的相应过程。
然后，再进行更多的测试，比如更改用户的密码。这个行为没有被记录，因为在配置规则中，这一行为是以root的身份执行的。接着我改变了我的密码(被记录)，试着把ls程序拷贝到/tmp。我不仅被允许这样做，并且在日志中只记录了mv程序曾被执行。我在规则中加入了监控对/bin/ls的修改，然后再次移动该文件，结果这次被记录了。
