服务器文件完整性检查怎么做？可信基线、变更确认与告警
配置文件被改动、程序包与发布记录不一致时，文件完整性检查能够提供进一步调查的线索。它回答的是“相对于已知状态，哪些文件发生了什么变化”，而不是自动判断每一个变化是否恶意。检查之前，首先要确定什么状态值得信任。
基线应来自可以解释的部署状态
刚发现异常就对全盘生成校验清单，会把当前可疑内容也记录进去。更合适的起点是经过核验的安装镜像、已审阅配置和明确的应用发布版本，并记录建立基线的时间、来源与负责人。基线本身也应受到保护，不能让普通应用进程同时改写被检查文件和对照数据。
可以先从少量关键对象开始，例如服务定义、部署脚本、站点配置和应用发布目录。临时目录、访问日志、缓存和正常上传内容变化频繁，应按用途另行管理。把所有文件都列成最高级告警，通常只会让重要事件埋在持续变化中。
单个文件校验适合什么任务
对受控目录中的一个发布包，可分别在可信来源和目标环境计算 SHA-256 并比较。以下示例只读取文件，不修改内容，路径需要替换成已确认的实际文件：
sha256sum /srv/releases/app-release.tar.gz
sha256sum 手册说明了计算与检查摘要的用法。相同摘要能够帮助检查传输或存储后内容是否一致，但如果预期摘要与文件都来自同一个不可信位置，这种比较不能证明发布者身份。供应方提供签名时，还应按其正式流程验证签名与公钥来源。
日常记录可以保存文件名、版本、摘要和校验时间，而不是把大量敏感配置内容复制到普通文档中。配置文件可能包含秘密，采集摘要不代表可以忽略文件权限和备份访问控制。
多文件检查要明确纳入与排除规则
AIDE 项目通过规则建立文件属性与摘要数据库，用于后续完整性比较。实际安装包的默认目录、数据库位置和可用选项可能不同，应先读取本机版本的手册，不直接把别的发行版配置覆盖进来。
设计规则时区分应用发布目录、运行时数据和系统配置。假设网站允许用户上传图片，那么上传目录出现新文件是正常业务行为，但该目录出现可执行脚本仍值得由应用与安全规则检查。完整性工具的排除项不能成为所有安全检查的豁免范围。
收到变化告警后怎样确认
把告警时间与发布记录、系统更新、管理员操作和文件归属对应起来。检查的是哪种变化：内容摘要、权限、属主、大小还是文件新增删除。只修改权限也可能影响安全，不能只关注内容校验值。
如果变化有明确授权，记录对应变更单和验证结果；如果无法解释，保留当前证据与原基线，按影响范围进一步调查。不要为了让面板恢复绿色就立即接受全部变化，也不要在证据不足时直接将文件删除。这样既可能破坏业务，也可能丢失分析线索。
更新基线需要独立的确认步骤
正常发布完成后，先确认新版本通过功能与权限检查，再生成下一版基线，并保留必要的历史记录。自动部署可以帮助生成候选基线，但是否接受变化，应与发布成功和审阅条件绑定，避免任何落盘修改都会自动变成“正常”。
检查任务还应有自己的健康信号：最近运行时间、扫描范围、失败原因和报告存放位置。如果任务已经连续数天没有运行，零告警不代表零变化。通过一次受控测试文件修改验证告警能够送达，再撤回测试并恢复基线，才能确认整条检查流程确实在工作。