Wazuh项目中eBPF事件丢失问题的技术分析与解决方案

问题背景

在Wazuh安全监控平台的开发过程中，团队发现了一个与eBPF(扩展伯克利包过滤器)相关的重要问题。该问题主要影响Fedora 41云镜像环境，表现为在某些特定文件系统路径下，文件创建、修改和删除事件会出现丢失现象。这一问题直接影响了文件完整性监控(FIM)功能的可靠性，特别是当使用whodata模式进行监控时。

问题现象

在Fedora 41环境中，当监控特定目录时，系统会出现以下异常行为：

1. 监控/test/目录时，所有删除事件会丢失，因为文件路径以/root/开头
2. 监控/home/vagrant/test/目录时，所有添加/修改事件会丢失，因为文件路径同样以/root/开头

通过详细日志分析，可以观察到eBPF事件中文件路径与实际监控路径不一致的情况：

eBPF事件: 文件: /test/test1.txt | CWD: /root/home/vagrant
eBPF事件: 文件: /root/test/test1.txt | CWD: /root/home/vagrant

根本原因分析

经过深入调查，发现问题根源在于Fedora 41使用了Btrfs文件系统，并且采用了特殊的子卷(subvolume)配置方式。具体表现为：

1. 主卷(/)挂载时使用了subvol=/root参数
2. 这意味着在Btrfs物理层面，系统根目录实际上位于名为"root"的顶级子卷内
3. 内部路径结构表现为/root/home/vagrant/...，而对用户则显示为/home/vagrant/...

这种配置导致eBPF在解析dentry和mount层次结构时，获取到的路径包含额外的/root/前缀，与用户期望监控的路径不匹配，从而造成事件丢失。

技术挑战

解决这一问题面临多个技术难点：

1. 路径获取方式不一致：不同hook点获取路径的方式不同，有些通过struct path参数，有些只能通过struct dentry手动构建路径
2. 文件系统多样性：不同文件系统(EXT4、Btrfs、OverlayFS、XFS)对路径处理方式不同
3. eBPF环境限制：BPF验证器的严格限制使得复杂字符串操作(如路径拼接)难以实现
4. 内核版本兼容性：不同内核版本对eBPF功能的支持程度不同

解决方案探索

团队评估了多种技术方案，最终确定了以下解决路径：

1. bpf_d_path函数方案

bpf_d_path()函数能够根据struct path参数正确获取各种文件系统下的完整路径。该方案具有以下特点：

• 优点：路径获取准确，兼容多种文件系统
• 限制：
  • 仅适用于特定内核版本(5.10+)
  • 只能在允许的hook点使用
  • 不同内核版本对LSM hook的支持不同

经过测试，以下hook点最适合我们的需求：

• lsm/file_open：能正确获取完整路径，但无法获取inode和dev信息
• lsm/path_unlink：能获取目录路径，需要与dentry文件名拼接

2. 路径拼接实现

针对lsm/path_unlink场景，团队成功实现了BPF程序中的路径拼接功能：

1. 使用bpf_d_path()获取目录路径
2. 从dentry结构中提取文件名
3. 在BPF程序中实现安全的字符串拼接
4. 支持最大4096字节的路径长度(与FIM功能匹配)

这一实现克服了BPF验证器的限制，能够在不同架构上预编译BPF程序。

解决方案实施

最终解决方案结合了多种技术手段：

1. 双hook策略：针对不同操作类型使用最适合的hook点

   • 文件创建/修改：使用lsm/file_open
   • 文件删除：使用lsm/path_unlink+路径拼接

2. 文件系统感知：识别Btrfs等特殊文件系统，调整路径处理逻辑

3. 缓冲区管理：优化路径缓冲区使用，确保不超过BPF程序限制

4. 内核版本适配：根据运行环境内核版本自动选择可用hook点

效果验证

解决方案在多种环境下进行了全面测试：

1. EXT4文件系统：所有事件正常捕获，与Auditd表现一致
2. Btrfs文件系统：解决了路径前缀问题，事件捕获完整
3. OverlayFS：相比Auditd能捕获更多事件
4. XFS：解决了直接路径与挂载点路径不一致的问题

经验总结

本次问题排查和解决过程提供了宝贵的经验：

1. 文件系统差异：现代Linux发行版采用的文件系统配置可能影响监控工具的准确性
2. eBPF复杂性：eBPF虽然强大，但其安全限制增加了开发复杂度
3. 全面测试：跨文件系统、跨内核版本的全面测试至关重要
4. 替代方案：在某些场景下，传统Auditd仍可作为备选方案

未来改进方向

基于本次经验，团队规划了以下改进方向：

1. 增强文件系统支持：进一步优化对ZFS、NFS等文件系统的支持
2. 动态hook选择：根据运行环境动态选择最优hook点
3. 性能优化：减少路径处理带来的性能开销
4. 错误处理：完善异常路径下的错误处理和日志记录

这一解决方案不仅解决了Fedora 41云镜像下的特定问题，还提升了Wazuh在不同文件系统环境下的整体监控可靠性，为用户提供了更加稳定的安全监控体验。