Debian OSSEC文件完整性

在Debian服务器上部署OSSEC后，文件完整性监控（FIM）的默认配置往往无法直接满足生产环境的需求。最常见的两个问题是：频繁的非关键目录变更导致告警风暴，以及syscheck扫描周期与数据库更新频率不匹配造成的性能瓶颈。解决这些问题的核心在于精细调整ossec.conf中<syscheck>模块的配置，并建立一套基线更新机制。

OSSEC的文件完整性监控由syscheck进程负责，其所有行为都受/var/ossec/etc/ossec.conf文件中的<syscheck>区块控制。你可以使用任何文本编辑器打开它。默认配置通常只监控/etc和/usr/bin等少数目录，且报告所有变更。我们需要改变这种粗放模式，让监控精准聚焦于那些不可变的系统二进制文件和极易被篡改的Web目录，同时排除动态变化的数据目录。

直接编辑<syscheck>区块内的<directories>标签。对于Debian系统，/bin、/sbin、/usr/bin、/usr/sbin这些二进制目录应当被设置为实时监控，因为任何非包管理器触发的变更都极可能是入侵指标。对于/etc目录，虽然重要，但Debian的包更新会频繁修改其内容。建议将其check_all属性设为yes，但关闭实时监控，改为每日定时扫描，以减少IO开销。对于/var/www或你的Web根目录，必须开启实时监控，但只需关注文件新增和修改，忽略访问时间的变化。具体的配置示例如下：

<syscheck>
  <frequency>86400</frequency>
  
  <directories check_all="yes" realtime="yes" report_changes="yes">/bin,/sbin,/usr/bin,/usr/sbin</directories>
  
  <directories check_all="yes" realtime="no" report_changes="yes">/etc</directories>
  
  <directories check_all="no" check_sum="yes" check_size="yes" check_owner="yes" check_perm="yes" check_mtime="yes" realtime="yes" report_changes="yes">/var/www</directories>
  
  <ignore type="sregex">/var/www/.*\.log$</ignore>
  <ignore type="sregex">/etc/mtab</ignore>
  <ignore type="sregex">/etc/hosts.deny</ignore>
</syscheck>

Debian系统上有大量文件会随着系统正常运行而发生合法变更。如果不忽略它们，OSSEC的告警日志会迅速膨胀，淹没真正的攻击信号。在<syscheck>区块内使用<ignore>标签是解决这一问题的唯一有效途径。你需要忽略/var/log下的所有日志文件，因为它们在持续写入。忽略/proc和/sys这两个虚拟文件系统，因为它们反映的是内核和硬件的瞬时状态，监控它们毫无意义且会引发错误。忽略/tmp和/var/tmp中临时文件的变更，但注意不要忽略整个目录的权限变更。忽略包管理器的数据库文件，如/var/lib/dpkg/status，因为每次安装或更新软件都会修改它。具体的忽略配置如下：

<ignore type="sregex">/var/log/.*</ignore>
<ignore type="sregex">/var/lib/dpkg/.*</ignore>
<ignore type="sregex">/proc/.*</ignore>
<ignore type="sregex">/sys/.*</ignore>
<ignore type="sregex">/tmp/.*</ignore>
<ignore type="sregex">/var/tmp/.*</ignore>

在Debian服务器上，如果syscheck进程扫描到过大的文件，比如数据库的原始数据文件或日志归档文件，会消耗大量CPU和内存，甚至导致扫描超时。通过设置<file_limit>标签，可以跳过对超大文件的哈希计算。但这会带来风险，因为攻击者可能将恶意软件隐藏在超大文件中。更稳妥的做法是，在定义目录时，通过更精确的路径或正则表达式，从一开始就排除这些数据目录。例如，如果你在/var/lib/mysql目录下运行MySQL，不应监控整个数据目录，而应只监控其上级目录的权限和所有者，或者监控MySQL的配置文件/etc/mysql/。同时，调整<frequency>标签的值，将全盘扫描的频率从默认的6小时延长到24小时或48小时，以降低对生产系统性能的影响。

OSSEC的FIM工作流程是：首次扫描建立基线数据库，后续扫描对比基线并报告差异。每次通过apt-get进行合法的系统更新或部署新应用后，基线就会过时，下一次扫描会产生海量告警。你必须在每次计划内变更后，立即更新基线。最直接的方法是在变更完成后，以root身份运行/var/ossec/bin/syscheck_update -f -a。这个命令会强制进行一次全盘扫描，并将当前文件状态更新为新的基线。将这一步骤固化为运维流程，是维持OSSEC FIM长期有效运行的关键。如果你使用的是集中式管理架构，也可以在OSSEC Manager上通过agent_control命令来触发指定Debian客户端的基线更新。

配置完成后，当文件完整性被破坏时，OSSEC会在/var/ossec/logs/alerts/alerts.log中生成详细告警。一条典型的告警会包含被修改文件的完整路径、新旧哈希值、修改时间、以及导致变更的用户。你需要教会团队解读这些信息，快速区分合法变更和恶意行为。更进一步，可以在ossec.conf中配置<active-response>模块，当检测到关键二进制文件（如/bin/ps）被修改时，立即执行预定义的脚本，比如阻断攻击者的IP地址或关闭服务器网络。在Debian上，一个实用的主动响应命令是结合iptables进行实时阻断。

每次修改ossec.conf后，都需要重启OSSEC服务使配置生效，命令是systemctl restart ossec。重启后，立即检查/var/ossec/logs/ossec.log，搜索包含“syscheck”的错误条目。常见错误包括目录路径不存在、正则表达式语法错误或权限不足导致无法读取文件。如果监控没有生效，首先确认你定义的目录确实存在，并且OSSEC的运行用户（通常是root或ossec）拥有读取权限。可以使用/var/ossec/bin/syscheck -t来测试配置文件的语法正确性，并使用/var/ossec/bin/syscheck -d来以调试模式运行一次扫描，实时观察输出，快速定位问题。

如果你管理着多台Debian服务器，通过OSSEC Manager进行集中策略下发是最佳实践。你无需登录每台服务器修改ossec.conf，而是在Manager的/var/ossec/etc/shared/目录下，为Debian系统创建或修改agent.conf文件。在这个文件中，你可以定义专门适用于Debian系统的syscheck规则，并通过<agent>标签的os属性来匹配Debian平台。这样，当新的Debian Agent注册时，会自动获取到正确的文件完整性监控策略，确保整个服务器集群的基线一致，并极大降低维护成本。