auditd 不直接监控 Swap 访问,但可通过三步法实现异常进程追溯:1. 审计高危内存操作;2. 用 /proc/[pid]/smaps 识别高 Swap 进程;3. 关联 PID 与 auditd 日志还原行为链。

auditd 本身不直接监控 Swap 分区的“访问请求”,因为 Swap 是内核内存管理子系统(mm/swap)的底层机制,其读写行为不经过文件系统路径、不触发 VFS 层审计点,也不对应传统意义上的“文件访问”或“系统调用审计规则”(如 openat, mmap 等虽可间接关联,但无法精准捕获 swap-in/out 动作)。
但你可以通过组合 auditd 日志 + 内核内存事件 + /proc 接口分析,实现对“高 Swap 使用进程”的事后追溯与非法行为关联分析。关键不是“拦截 swap 访问”,而是“发现异常进程并锁定其审计上下文”。
以下是实用、可落地的三步方案:
1. 用 auditd 监控可能诱发 Swap 暴涨的高危行为
Swap 异常往往由以下操作引发: - 大量匿名内存分配(如 `malloc` 后未释放) - 非法 fork 爆炸(如 fork bomb) - 恶意 mmap 大块私有内存(`MAP_ANONYMOUS | MAP_PRIVATE`) - 特权进程越权修改内存策略(如 `mlock`, `swapon`)你可在 /etc/audit/rules.d/swap-related.rules 中添加:
# 监控可疑内存分配与锁定行为 -a always,exit -F arch=b64 -S mmap,mremap,brk -F uid!=0 -k swap_suspicious_alloc -a always,exit -F arch=b64 -S mlock,mlockall -F uid!=0 -k swap_privilege_abuse -a always,exit -F arch=b64 -S fork,vfork,clone -F uid!=0 -F a0>1000000 -k fork_bomb_suspect # 监控 swap 设备启停(需 root 权限) -w /sbin/swapon -p x -k swap_admin_action -w /sbin/swapoff -p x -k swap_admin_action
然后加载规则:
Linux 安全审计工具,检查 SSH 配置、开放/监听端口、防火墙规则(ufw/iptables/nftables)、失败登录尝试、sudoers 权限...
sudo augenrules --load && sudo systemctl restart auditd
这些规则不会记录“谁正在 swap”,但能捕获 触发 swap 压力的源头操作,并打上自定义 key(如 `swap_suspicious_alloc`),后续可用 `ausearch -k swap_suspicious_alloc` 快速检索。
2. 实时识别高 Swap 占用进程(不依赖 auditd)
利用内核暴露的 `/proc/[pid]/smaps` 中的 `Swap:` 字段(Linux ≥ 2.6.16): ```bash # 一行命令列出占用 Swap 最多的前 10 个进程(单位 MB) for pid in /proc/[0-9]*; do [ -r "$pid/smaps" ] || continue swap_kb=$(awk '/^Swap:/{sum+=$2} END{print sum+0}' "$pid/smaps" 2>/dev/null) [ "$swap_kb" = "0" ] && continue comm=$(awk '{print $1; exit}' "$pid/comm" 2>/dev/null | tr -d '\0') echo "$pid $comm $swap_kb" done | sort -k3nr | head -10 | awk '{printf "%-8s %-16s %6.1f MB\n", substr($1,7), $2, $3/1024}' ```输出示例:
12345 java 248.3 MB<br> 6789 nginx-worker 89.1 MB
该 PID 可立即用于下一步审计溯源。
3. 关联 PID 到 auditd 日志,还原行为链
拿到高 Swap 进程 PID(如 12345)后,用以下命令查它启动以来的审计事件: ```bash # 查该进程的完整启动命令和父进程(含参数) ausearch -m execve -i --start recent --pid 12345 | grep -E "(comm=|exe=|cmdline=)"查该进程所属用户的所有敏感操作(如文件写、权限变更)
ausearch -ui $(ps -o uid= -p 12345) -k swap_suspicious_alloc -i --start recent
查该进程是否曾执行过 mmap/mlock 等系统调用(需 auditd 已启用 syscall 规则)
ausearch -m mmap,mlock -p 12345 -i --start 24h
<p>若发现某 java 进程在启动后 2 小时内持续调用 `mmap` 分配数百 MB 私有内存,且无对应 `munmap`,再结合其 cmdline 含可疑 JAR 路径,即可判定为异常行为——<strong>auditd 提供的是行为证据链,而非 swap 流量镜像</strong>。</p> 不复杂但容易忽略:真正有效的 Swap 安全监控,是把 auditd 当作“行为证人”,把 `/proc/*/smaps` 当作“现场物证”,二者交叉印证,才能定位非法请求背后的进程实体与操作意图。

















