完整性检查与审计

完整性检查与审计

在 RHEL5 安全指南中,建议使用 AIDE 检查软件完整性。此外还内置了 RPM 完整性检查功能。但频繁检查会耗费资源,而且很少检查可能没什么用。另一方面,对关键部分的持续审计相对便宜。而且它仍然在一定程度上确保了完整性。

所以基本上我的问题是:在哪些情况下完整性检查(AIDE,RPM 或新的东西)比审计更好?

UPD:只是澄清一下。我说的“审计”是指基于特定 auditd 守护进程的 RHEL 审计服务。它可以适当调整以不断监督文件和目录。要未通过完整性检查,文件应该以某种方式被修改,审计系统会注意到这一点。那么,既然我们可以追踪修改的原因,为什么还要担心后果(例如校验和失败)呢?

答案1

我不知道这个问题是否可以得到有意义的回答,尽管我没有相当确信可以投票关闭它。

但我确实认为,在任何成本效益分析中,你都不能忘记好处:在本例中,避免失败的成本你说频繁检查可能会“耗费资源”,这很可能是真的:但是由于发生了一些入侵事件,从黄金备份重建后端基础设施对资源的要求有多高呢?

在系统安全方面投入多少资金取决于系统在完整性和功能性方面的价值。就我个人而言,任何暴露在互联网上的机器每天都会接受绊线检查,并通过电子邮件报告。几乎所有信息syslog都存储在系统外的集中日志主机上;入侵者在入侵过程中可能产生的任何痕迹都无法从远程系统记录器中删除。更敏感的机器还可以启用 RPM 完整性检查selinux(运行非标准软件时会带来所有可怕的麻烦)、从只读媒体运行绊线,甚至获得更多完整性保护。这一切都取决于机器的价值。

编辑:我不明白你指的是auditd软件服务,而不是审计的一般概念,确实如此,但即使我明白,我的答案也是一样的:纵深防御,深度由资产价值决定。如果有一种简单、便宜、绝对可靠的服务称为complete-securityd,我们都会使用它;因为没有,所以采取的预防措施越多,妥协发生的可能性就越小 (a),并且 (b) 即使发生了也未被发现。

既然您询问auditd可能错过和tripwire可能捕获的入侵类型,那么定制的内核模块漏洞就是其中之一,因为tripwire 可以从只读媒体和内核运行,但auditd不能。

相关内容