inotify 在 Linux 下的安全性
总体结论
inotify 是 Linux 内核提供的文件系统事件通知机制，本身并非安全工具，不会阻止攻击；其安全性取决于如何使用。正确配置时，可用于实时监控关键文件/目录、触发告警与自动化响应，从而提升入侵检测与响应能力；错误使用（如监控范围过宽、以高权限运行、缺乏审计与联动）会带来信息泄露、权限滥用与资源耗尽等风险。总体建议：把它作为“检测与响应”的组件，配合审计与访问控制共同使用。
主要风险与限制
- 无法识别“谁”做了变更：inotify 只能报告“哪个路径发生了什么事件”，不记录触发者身份；若需“谁、何时、改了什么”，应与 auditd 联动做身份与溯源审计。
- 权限与运行身份风险：监控脚本若以 root 运行且被攻破，攻击者可借此执行任意操作；应遵循最小权限原则，仅授予必要权限。
- 资源耗尽与稳定性问题：大量 watch 或不设上限可能引发 “max_user_watches / max_user_instances / max_queued_events” 耗尽，导致监控失效或系统不稳定；需设置合理上限与监控队列。
- 监控范围过宽导致噪声与性能问题：盲目对 / 或 /tmp 等广泛路径监听会产生大量事件与日志，既难处置也易暴露敏感信息；应聚焦 /etc、/var/log、/root/.ssh 等高价值目标。
- 误报与对抗性场景：临时文件、包管理器、编辑器 swap 等会产生大量正常事件；攻击者也可通过延迟删除/重命名规避检测。需结合白名单、去抖与多源信号降低误报。
加固与最佳实践
- 最小权限与隔离：监控服务使用专用低权账户运行；必要时通过 sudo 精确授权单一操作；为日志与脚本设置严格权限（如日志 600），防止信息泄露与篡改。
- 精准监控与日志：仅监听必要路径与事件（如 -e modify,attrib,create,delete），避免递归过深；输出到受保护的日志（如 /var/log/inotify.log），并配置 rsyslog 集中与轮转；对关键文件变更触发即时告警。
- 身份溯源与合规审计：对敏感文件（如 /etc/passwd、/etc/shadow、/root/.ssh/authorized_keys）使用 auditd 配置规则（如 -w /path -p wa -k key），当 inotify 触发时以 ausearch 关联 auid 定位操作者，实现“人-时-事”闭环。
- 资源与稳定性控制：设置内核参数（如 fs.inotify.max_user_watches）与 systemd 服务限制，防止被滥用拖垮系统；按需调整队列与实例上限，并监控 inotify 自身资源占用。
- 纵深防御与联动：与 SELinux/AppArmor 限制监控进程权限；与 IDS/IPS、fail2ban 等联动做多信号检测；对关键事件执行自动隔离/回滚（如隔离新增公钥、恢复被改文件）。
典型安全用法示例
- 监控关键配置与授权密钥变更并告警：对 /etc/ssh/sshd_config、/root/.ssh/authorized_keys 监听 modify,attrib,create,delete，事件触发时记录审计线索并推送告警，必要时自动撤销新增密钥或回滚配置。
- 结合 auditd 实现“谁改了什么”：对 /etc/passwd、/etc/shadow 配置 auditd 规则并打标签；inotify 捕获修改事件后，用 ausearch -k 查询最近相关审计记录，提取 auid 并映射为用户名，完成溯源。