问题描述
用户发现录音数据文件丢失，但是查看audit审计日志没有相关文件删除的记录。用户需要排查文件是怎么被删除的。
问题分析
采用auditctl -l 查看审计规则的配置，确实对录音文件目录 /home/data/crm 添加了监控，对该目录的写入、属性变更都会记录相应日志。
采用 ausearch -i --ts "2025-04-25 00:00:00" | grep -i delete 获取删除的日志，发现无对应的审计日志。
crontab -l 有定时任务的配置，但都与删除是无关的。
从4月30日起，用户反馈说每天凌晨2点2分左右，录音文件目录大小都会变小。目录里没有任何压缩文件，判断文件在该时刻点被删除了。
建议用户在凌晨2点开启top监控，监控30分钟，监控脚本如下：
#!/bin/bash
OUTPUT\_FILE="top\_data.log"
DURATION=180
echo > OUTPUT\_FILE
end\_time=**(( **(date +%s) + DURATION ))
# 循环记录top数据，直到达到指定时长
while [ **(date +%s) -lt **end\_time ]; do
date >> \$OUTPUT\_FILE
top -b -n 1 >> \$OUTPUT\_FILE
sleep 1
done
crontab 设置如下：
2 \* \* \* \* /root/monitor.sh &
发现凌晨2点2分左右，服务器上的nfsd进程非常忙碌。
通过mount命令查看到该录音目录被nfs共享给其他客户端10.10.1.41。
进一步排查客户端发现有凌晨2点清理过期录音文件的脚本。
[root@ecs-umjp2hbx task]# crontab -l
0 2 \* \* \* /home/iflytek/znzj/source/clean\_wav.sh
0 1 \* \* \* /home/iflytek/znzj/source/clean\_log.sh
0 3 \* \* \* /home/iflytek/share/qingli.sh
0 5 \* \* \* /home/iflytek/znzj/epc-1094/epcclearlog.sh
[root@ecs-umjp2hbx task]# more /home/iflytek/znzj/source/clean\_wav.sh
#!/bin/bash
TARGET\_DIR="/home/iflytek/znzj/source"
find "\$TARGET\_DIR" -name "\*.wav" -type f -mtime +7 -exec rm -f {} ;
因此录音文件删除原因已查明。
为什么删除没有审计日志呢？
审计日志记录一般是通过syscall返回时记录的：
do_syscall_64
syscall_exit_to_user_mode
syscall_exit_work
__audit_syscall_exit
audit_log_exit
audit_log_start
或是配置的一些监控事件，通过用户态命令触发，记录审计日志：（如 用户登录/登出 ssh, 特权命令执行 sudo 等）
__sys_sendto
sock_sendmsg
netlink_sendmsg
netlink_unicast
audit_receive
audit_receive_msg
audit_log_start
从上面可以看出，nfs client端删除文件是不支持审计的。
为什么nfs client端删除文件不支持审计？
- 技术架构限制：NFS 协议与内核审计的交互方式
(1) NFS 服务端处理的是 RPC 请求，而非本地系统调用
- NFS 客户端 通过 RPC（远程过程调用） 向服务端发送文件操作请求（如 REMOVE、CREATE），而不是直接触发服务端的系统调用（如 unlink()、open()）。
- audit 子系统 的监控机制主要基于：
- 系统调用（syscall）（如 -S open、-S unlink）。
- 文件路径监控（-w /path）（依赖内核的 inotify 或 fanotify）。
- NFS 服务端 处理的是 RPC 层的操作，不会在本地触发对应的 syscall，因此 audit 无法捕获。
(2) NFS 服务端的内核实现不挂钩 audit 机制
- NFS 服务端（nfsd）在内核中的实现是独立的，它：
- 接收 RPC 请求 → 调用 VFS（虚拟文件系统）接口 → 修改文件系统。
- 不会经过syscall 路径，因此 audit 无法拦截。
- 性能与扩展性考量
(1) NFS 的高性能需求
- NFS 设计目标是 低延迟、高吞吐量，如果每个 NFS 操作都要经过 audit 子系统：
- 额外开销：每个 RPC 请求都需要审计日志记录，影响 I/O 性能。
- 日志爆炸：NFS 通常用于共享存储，频繁操作会导致 audit 日志量剧增（如 -w /shared 会记录所有读写）。
(2) 审计日志的适用场景
- audit 主要用于 安全合规（如 sudo、sshd、敏感文件访问），而不是 存储协议审计。
- NFS 的审计更适合由 网络层日志（如 tcpdump）或 专用存储审计工具（如 CIFS/samba 的完整日志）实现。
- 安全模型与责任边界
(1) 客户端 vs. 服务端的审计责任
(2) 分布式系统的复杂性
audit 主要用于 安全合规（如 sudo、sshd、敏感文件访问），而不是 存储协议审计。
NFS 的审计更适合由 网络层日志（如 tcpdump）或 专用存储审计工具（如 CIFS/samba 的完整日志）实现。
NFS 服务端 只负责提供共享存储，不感知客户端的操作细节（如哪个用户执行 rm）。
真正的操作者 是 NFS 客户端，因此：
- 客户端应该记录自己的操作（如 auditctl -w /mnt/nfs_share）。
- 服务端只需保证共享目录的访问控制（如 /etc/exports 的 rw/ro 权限）。
如果 NFS 服务端记录所有客户端操作：
- 日志归属问题：如何区分不同客户端的相同操作？（需额外记录客户端 IP、UID 等）
- 信任链问题：客户端可能伪造信息，服务端无法完全信任客户端提交的审计数据。
那么nfs client端删除文件如何监控呢？
只需要在nfs client端添加对应的审计即可。
问题结果
- 用户发现录音数据文件丢失，实际上是服务器将录音文件目录挂载到客户端，客户端上有定期清理的脚本，通过nfs协议删除过期的文件。
- 由于服务端audit不支持对nfs client端删除文件进行审计，因此如果要监控client端的行为，需要在对应的client端添加审计即可。
