問題描述
用戶(hu)發現錄(lu)音數據文件丟失，但是(shi)查看audit審計日志(zhi)沒(mei)有相關文件刪除(chu)的(de)記錄(lu)。用戶(hu)需要排查文件是(shi)怎么被刪除(chu)的(de)。
問題分析
采用auditctl -l 查看審計規則的配置，確實對錄音文件目錄 /home/data/crm 添加了監控，對該目錄的寫入、屬性變更都會記錄相應日志。
采用 ausearch -i --ts "2025-04-25 00:00:00" | grep -i delete 獲取刪除的(de)日志(zhi)，發現無對應的(de)審計日志(zhi)。
crontab -l 有定(ding)時(shi)任務的配(pei)置，但都與(yu)刪(shan)除是無關的。
從4月30日起，用戶反饋(kui)說每天凌晨2點2分(fen)左右，錄(lu)(lu)(lu)音文(wen)(wen)件目錄(lu)(lu)(lu)大(da)小都會變小。目錄(lu)(lu)(lu)里沒有任何壓縮文(wen)(wen)件，判斷文(wen)(wen)件在該時刻點被刪除了(le)。
建議用戶在(zai)凌晨(chen)2點開啟top監控(kong)，監控(kong)30分鐘(zhong)，監控(kong)腳(jiao)本如下：
#!/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命令查看到該(gai)錄音目錄被nfs共享給其他客(ke)戶端10.10.1.41。
進一步(bu)排查(cha)客戶端(duan)發(fa)現有(you)凌晨2點清理(li)過(guo)期錄音文件(jian)的腳本(ben)。
[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 {} ;
因此錄音文件刪除原因已查明。
為什么(me)刪除(chu)沒有審計日志(zhi)呢？
審(shen)計(ji)日志記錄一般是通過syscall返回時記錄的：
do_syscall_64
syscall_exit_to_user_mode
syscall_exit_work
__audit_syscall_exit
audit_log_exit
audit_log_start
或是配置的一些監控事(shi)件，通過用戶態命(ming)(ming)令觸(chu)發，記錄審計(ji)日志：（如 用戶登(deng)錄/登(deng)出(chu) ssh, 特權命(ming)(ming)令執行 sudo 等）
__sys_sendto
sock_sendmsg
netlink_sendmsg
netlink_unicast
audit_receive
audit_receive_msg
audit_log_start
從上面可以(yi)看出，nfs client端刪除文(wen)件是不支持審計(ji)的。
為什么nfs client端刪除文件不支持審計？
- 技術架構限制：NFS 協議與內核審計的交互方式
(1) NFS 服務端(duan)處理的是 RPC 請求，而(er)非本地系(xi)統調用(yong)
- NFS 客戶端 通過 RPC（遠程過程調用） 向服務端發送文件操作請求（如 REMOVE?、CREATE?），而不是直接觸發服務端的系統調用（如 unlink()?、open()?）。
- audit 子系統 的監控機制主要基于：
- 系統調用（syscall）（如 -S open?、-S unlink?）。
- 文件路徑監控（-w /path?）（依賴內核的 inotify? 或 fanotify?）。
- NFS 服務端 處理的是 RPC 層的操作，不會在本地觸發對應的 syscall?，因此 audit 無法捕獲。
(2) NFS 服務(wu)端的內(nei)核實現不掛鉤 audit 機制
- NFS 服務端（nfsd?）在內核中的實現是獨立的，它：
- 接收 RPC 請求 → 調用 VFS（虛擬文件系統）接口 → 修改文件系統。
- 不會經過syscall? 路徑，因此 audit 無法攔截。
- 性能與擴展性考量
(1) NFS 的高性能(neng)需(xu)求
- NFS 設計目標是 低延遲、高吞吐量，如果每個 NFS 操作都要經過 audit 子系統：
- 額外開銷：每個 RPC 請求都需要審計日志記錄，影響 I/O 性能。
- 日志爆炸：NFS 通常用于共享存儲，頻繁操作會導致 audit 日志量劇增（如 -w /shared? 會記錄所有讀寫）。
(2) 審計日志的適用(yong)場景
- audit 主要用于 安全合規（如 sudo?、sshd?、敏感文件訪問），而不是 存儲協議審計。
- NFS 的審計更適合由 網絡層日志（如 tcpdump?）或 專用存儲審計工具（如 CIFS/samba? 的完整日志）實現。
- 安全模型與責任邊界
(1) 客戶端(duan) vs. 服(fu)務端(duan)的審計責(ze)任
(2) 分布式系統的復雜(za)性
audit 主要(yao)用于(yu) 安(an)全合規（如(ru) sudo?、sshd?、敏感文件(jian)訪問(wen)），而不是 存儲(chu)協議審計(ji)。
NFS 的(de)審(shen)計更適合由(you) 網絡層日(ri)(ri)志（如(ru) tcpdump?）或 專用存儲(chu)審(shen)計工(gong)具（如(ru) CIFS/samba? 的(de)完整日(ri)(ri)志）實(shi)現。
NFS 服務端 只負責提供(gong)共享存儲，不感知客戶端的操作細節（如哪個用戶執行 rm?）。
真正的操(cao)作者(zhe) 是 NFS 客戶端，因此：
- 客戶端應該記錄自己的操作（如 auditctl -w /mnt/nfs_share?）。
- 服務端只需保證共享目錄的訪問控制（如 /etc/exports? 的 rw?/ro? 權限）。
如果 NFS 服務端記錄所有客戶(hu)端操作：
- 日志歸屬問題：如何區分不同客戶端的相同操作？（需額外記錄客戶端 IP、UID 等）
- 信任鏈問題：客戶端可能偽造信息，服務端無法完全信任客戶端提交的審計數據。
那(nei)么nfs client端刪除(chu)文(wen)件(jian)如何監控(kong)呢？
只(zhi)需要(yao)在nfs client端添加對應的(de)審計(ji)即(ji)可(ke)。
問題結果
- 用戶發現錄音數據文件丟失，實際上是服務器將錄音文件目錄掛載到客戶端，客戶端上有定期清理的腳本，通過nfs協議刪除過期的文件。
- 由于服務端audit不支持對nfs client端刪除文件進行審計，因此如果要監控client端的行為，需要在對應的client端添加審計即可。
