完整性檢查與審計
在 RHEL5 安全指南中，建議使用 AIDE 檢查軟體完整性。並且還內置了 RPM 完整性檢查功能。但是頻繁的檢查可能需要資源，而且很少見可能不是很有用。另一方面，對關鍵部分的持續審計相對便宜。而且它在一定程度上仍然保證了完整性。
所以基本上我的問題是：在哪些情況下完整性檢查（AIDE、RPM 或新的東西）比審計更好？
UPD：只是為了澄清一點。“審計”是指基於特定 auditd 守護程序的 RHEL 審計服務。它可以適當地調整以不斷地監督文件和目錄。如果完整性檢查失敗，應該以某種方式修改文件，審計系統會注意到這一點。那麼，當我們可以追踪修改的原因時，為什麼還要擔心後果（例如校驗和失敗）呢？
我不知道這個問題是否可以得到有意義的回答，儘管我不太確定是否可以投票結束它。
但我確實認為，在任何成本收益分析中，您都不能忘記收益：在這種情況下，就是避免失敗的成本。您說頻繁檢查可能是“資源需求”，這很可能是這樣：但是由於發生了一些入侵，資源需求如何從黃金備份重建您的後端基礎架構？
在完整性和功能方面，您在保護系統上花費多少取決於系統的價值。對我自己來說，任何暴露在網際網路上的機器都會每天接受tripwire檢查，並通過電子郵件進行報告。幾乎所有內容都
syslog集中在系統外的集中式日誌主機上；入侵者可能在途中產生的任何足跡都無法從遠端系統記錄器中刪除。更敏感的機器也可能會獲得 RPM 完整性檢查，selinux啟用（執行非標準軟體時會帶來所有可怕的麻煩），從只讀媒體執行的tripwire，甚至更多的完整性保護。這一切都取決於機器的價值。編輯：我不明白你的意思是
auditd軟體服務，而不是審計的一般概念，這是真的，但即使我有我的答案也會是一樣的：深度防禦，由價值證明的深度資產。如果有一個名為 的單一、簡單、便宜、絕對可靠的服務complete-securityd，我們都會執行它；因為沒有，您採取的預防措施越多，妥協就越不可能（a）發生，並且（b）當它發生時未被發現。由於您詢問
auditd可能錯過和tripwire可能擷取的入侵類型，因此自定義核心模組漏洞利用就是其中之一，因為tripwire 可以從只讀媒體和核心執行，auditd但不能。