auditd 可精准监控 phpMyAdmin 目录真实文件修改，需基于 inode 监控实际路径（非软链/NFS/容器卷）、用 -p wa 规则、加 -k 标签写入 /etc/audit/rules.d/ 并 augenrules --load，查日志必须 ausearch -k phpmyadmin_mod -i。
auditd 不能直接监控 phpMyAdmin 源码目录的“改动”——它只记录系统调用级写入与属性变更，不识别应用层逻辑（比如 Git 提交、Web 界面上传、解压覆盖）。但你可以精准捕获真实文件修改行为，前提是规则写对、路径真实、权限位选准。
确认 phpMyAdmin 目录的真实路径和 inode
auditd 的 -w 基于 inode 绑定，软链接、挂载点、容器卷都会导致规则失效。必须用 ls -i 验证：
- 执行
ls -ld /var/www/html/phpmyadmin，确认是目录且存在；若为软链（如指向/usr/share/phpmyadmin），则应监控目标路径而非链接名 - 若目录在 Docker 卷或 NFS 挂载上，auditd 可能无法可靠捕获（虚拟文件系统限制）；优先监控宿主机上的实际存储路径
- 避免监控整个
/var/www/html/—— 高频读写会触发日志爆炸，只锁死 phpMyAdmin 根目录及其关键子路径（如config.inc.php）
用 -p wa 而不是 -p rwxa 监控写入与属性变更
phpMyAdmin 目录被篡改，99% 是通过 cp、unzip、vim :w 或 Web 上传（触发 write 系统调用）完成的，-p w 就够了；加 a 是为了捕获攻击者隐藏痕迹的 chmod 600 config.inc.php 或 chown www-data:www-data 操作。
-
-p wa：覆盖绝大多数真实篡改场景（内容写入 + 权限/所有者变更） -
-p r绝对禁用：Web 服务频繁读取index.php等文件，加r会导致每秒数百条日志，迅速填满磁盘 -
-p x不必要：监控执行权限变更意义不大，phpMyAdmin 本身不依赖可执行脚本
必须加 -k 标签并写入 /etc/audit/rules.d/ 永久生效
临时规则 auditctl -w /var/www/html/phpmyadmin -p wa -k phpmyadmin_mod 在重启 auditd 或机器重启后就消失，生产环境必须落盘。
立即学习“PHP免费学习笔记（深入）”；
- 创建文件：
/etc/audit/rules.d/phpmyadmin.rules，内容严格为（无空格开头，每行一条）：-w /var/www/html/phpmyadmin -p wa -k phpmyadmin_mod<br>-w /var/www/html/phpmyadmin/config.inc.php -p wa -k phpmyadmin_config
- 执行
sudo augenrules --load加载，再用sudo auditctl -l | grep phpmyadmin确认是否生效 - 别直接改
/etc/audit/audit.rules—— 它由augenrules自动生成，手动修改会被下次--load覆盖
查日志时必须用 ausearch -k phpmyadmin_mod -i
原始审计日志全是数字 ID，不加 -i 就等于没查。真正有用的字段是：
-
comm="unzip"或comm="cp"：说明是批量覆盖操作 -
exe="/usr/bin/php"+cwd="/var/www/html/phpmyadmin"：可能是 WebShell 执行的写入 -
auid=1001对应登录用户（ausearch -m USER_LOGIN -i | grep 1001可反查是谁登录的） - 看到
comm="(unknown)"别慌，看exe和ppid向上追溯父进程（常见于 CGI 或 PHP-FPM 子进程）
真正容易被忽略的是：auditd 记录的是“谁调用了 write 系统调用”，不是“谁点了上传按钮”。如果 phpMyAdmin 运行在 PHP-FPM 下，exe 显示的是 /usr/sbin/php-fpm，而真实攻击者 IP 需结合 Nginx/Apache access.log 关联分析 —— auditd 提供的是内核层证据链起点，不是终点。
