inotify在安全审计中的作用与边界
结论与定位
可以用于安全审计，但更适合作为“实时变更感知与告警”的组件；若需要可落地的“谁在何时对哪个路径做了什么”的审计证据，应与auditd等审计子系统联动。inotify的优势在于内核级事件驱动、低开销、对创建/修改/删除/移动/属性变更等文件系统事件的高频监控；局限在于无法直接关联到具体用户/进程身份，且存在被绕过与资源上限等边界。
适用场景与典型用法
- 关键配置与系统核心文件保护：对**/etc/passwd、/etc/shadow、/etc/ssh/sshd_config、/usr/bin**等路径监控 modify/attrib 等事件，触发即时告警或自动恢复，快速发现后门植入与配置篡改。
- 日志防篡改与实时分析：监控**/var/log/auth.log、/var/log/syslog等日志文件的写入与删除，联动Fail2Ban**等进行自动封禁与取证，缩短MTTD/MTTR。
- 权限与提权风险监测：关注SUID/SGID位异常设置（attrib 事件），及时告警并回滚权限，降低提权攻击面。
- 容器与虚拟化环境：在Docker/Kubernetes容器内监控**/etc、/usr**等敏感目录，发现异常文件操作并阻断横向扩散。
- 自动化应急响应：当检测到高危变更（如**/etc/shadow**被改、sshd_config被动），自动重启服务、下发隔离策略或通知值守平台。
与auditd的互补与溯源
- 身份与溯源：inotify无法识别“哪个用户/进程”触发事件；通过auditd配置对关键路径的系统调用审计（如**-w /path -p wa或针对openat等），可在事件发生时记录auid/uid/euid、pid、ppid、comm、exit**等，实现“谁、何时、做了什么”的取证闭环。
- 协同工作流示例：inotify捕获到目标文件变更后，立即用ausearch -k 按时间窗口检索对应auid并告警；或让auditd持续记录、inotify仅负责“快告警+快处置”。
局限性与注意事项
- 可被绕过：直接操作块设备、卸载/重挂载、使用fanotify或将文件置于inotify监视之外的路径，均可能导致事件缺失；因此inotify不应作为唯一审计手段。
- 资源限制：需关注内核参数fs.inotify.max_user_watches、fs.inotify.max_user_instances、fs.inotify.max_queued_events，避免因上限不足导致漏报或监控中断。
- 事件覆盖：inotify不覆盖所有文件访问路径（如某些网络文件系统、删除后重建等场景），重要资产建议叠加auditd与完整性校验工具（如AIDE/Tripwire）。
快速上手示例
- 实时记录目录变更（inotifywait）
- 安装工具：sudo apt-get install inotify-tools 或 sudo yum install inotify-tools
- 监控命令：inotifywait -mr --timefmt ‘%Y-%m-%d %H:%M:%S’ --format ‘%T %w%f %e’ -e modify -e create -e delete -e attrib -e move /var/www/html
- 与auditd联动获取“谁”在变更
- 添加审计规则：sudo auditctl -w /var/www/html -p wa -k web_content
- 事件关联：ausearch -k web_content -ts recent | grep “<被改动文件路径>”
- 加固建议
- 将监控脚本与日志设为root属主、600权限；为inotify与auditd配置systemd持久化与日志轮转；对关键目录建立基线快照并定期比对。
