用 Wazuh 检查 WordPress 安全配置：逐项复核结果，避免照单整改

在独立 linux 服务器上维护 WordPress 时，引入 Wazuh 的安全配置评估（SCA, Security Configuration Assessment）模块可以自动化排查大量基础加固项。然而，直接依照 SCA 规则列表点击“全部修复”或套用示例脚本，极易导致生产事故。官方或社区提供的 WordPress 评估策略往往基于标准单站架构（如硬编码的 /var/www/html 路径、默认 www-data 用户以及单一文件系统权限假设）。一旦面对多站点、自定义部署路径、PHP-FPM 隔离运行或对象存储挂载，预设的检查规则往往会产生大量误报，甚至诱导运维人员下发破坏业务可用性的变更命令。

因此，安全配置评估的核心价值不在于追求控制台上的“100% 合规通过”，而在于将自动化扫描结果作为基准线，通过人工复核区分真实风险、规则不适用与执行失败。在此基础上，实施小范围试行、功能验证与可逆回滚，才能在保障业务连续性的同时提升系统防御水平。

资产盘点：对齐检查边界与运行时上下文

在解读 Wazuh 报表前，必须先在宿主机上核实 WordPress 的实际运行时属性。若扫描策略配置的上下文与实际系统脱节，后续的合规结果将失去参考意义。

通过 SSH 登录服务器，定位实际网站根目录、Web 服务运行身份以及 PHP 进程所有者：

# 1. 查找 Nginx/Apache 实际引用的 WordPress 路径与虚拟主机
grep -rn "root " /etc/nginx/sites-enabled/ 2>/dev/null || grep -rn "DocumentRoot" /etc/apache2/sites-enabled/ 2>/dev/null

# 2. 获取实际处理动态请求的 PHP-FPM 用户
ps -eo user,group,args | grep -E 'php-fpm|php[0-9]' | grep -v grep

# 3. 确认文件系统挂载属性（注意是否有 noexec 或网络共享挂载）
mount | grep $(df -P /path/to/wordpress | awk 'NR==2 {print $6}')

核对清单应重点记录以下四项边界要素：

• 站点根目录路径：是否为标准路径，是否存在多级子目录或符号链接（Symlink）。
• 运行用户与属组：PHP-FPM 与 Web 服务器（如 Nginx）是否采用分离账号（例如 Nginx 为 nginx，PHP-FPM 池使用独立的普通用户）。
• 静态资源托管架构：wp-content/uploads 是本地磁盘、独立挂载卷，还是通过插件直接写入对象存储。
• 管理运维通道：更新是由后台 Web 界面触发，还是通过 WP-CLI 结合 CI/CD 流水线以专属发布账号执行。

结果分类：判定真实风险与规则不适用

拿到 Wazuh SCA 报告后，不要急于执行修复，先将未通过项按判定逻辑归入三类：真实风险（True Positive）、规则不适用（Not Applicable）、探测失败（Check Error）。

检查项类型	典型报错/现象示例	判定依据与典型场景	处置建议
真实风险	wp-config.php 权限为 666 或 777；调试模式 WP_DEBUG 在生产环境开启	敏感信息直接暴露，不符合最小权限与信息隐藏原则	进入小步变更流程，收紧权限或修改配置
规则不适用	检查提示“/var/www/html 不存在”；提示核心目录属主不属于 www-data	自定义安装路径（如 /srv/www/site1）；采用 Git 自动化部署，核心文件故意设为只读且由构建用户持有	调整 SCA 策略参数，或在 Wazuh 中设置合理豁免理由，禁止盲目修改属主
探测失败	提示“文件未找到”或正则匹配错误	Wazuh Agent 运行身份对深层路径无读取权限，或规则内置的搜索正则无法适配定制的 wp-config.php 结构	调试 SCA 规则中的 file: 与 condition: 参数，修正检测逻辑

关键检查项复核要点

1. 核心与敏感文件权限

SCA 示例中常将所有文件建议设为统一的属主与模式。但在稳健的生产架构中，运行 PHP 进程的账号通常不应拥有对 wp-config.php、wp-admin 及 wp-includes 的写入权限。若盲目将其属主更改为 Web 运行用户，一旦存在任意文件上传或注入漏洞，攻击者即可篡改核心源码。

• 复核证据：执行 ls -la /path/to/wordpress/wp-config.php 查看属主和八进制权限（通常应为 400、440 或 640，具体取决于 Web 组架构）。

2. 上传目录（wp-content/uploads）执行权限

配置评估通常要求禁止上传目录具有写入可执行文件的风险。如果规则提示上传目录“未限制执行”，直接修改目录权限位可能造成媒体库无法写入。

• 复核证据：检查 Web 服务器层面的配置，确认是否已经在 Nginx/Apache 中全局阻断了该目录下的 .php 请求，而非仅依赖文件系统权限。

小步整改：单站点试行与功能影响控制

确定属于“真实风险”的项，必须采取单站点试行机制。以下以最典型的“收敛 wp-config.php 敏感配置与文件权限”为例，展示标准化变更流程。

1. 变更准备与回滚备份

在执行任何系统级或配置级修改前，留存原始凭证并创建带时间戳的恢复备份：

# 记录变更前状态作为证据
stat /path/to/wordpress/wp-config.php > /root/wp-config-perm-before.txt

# 备份目标文件及 Web 配置文件
cp -p /path/to/wordpress/wp-config.php /path/to/wordpress/wp-config.php.bak_$(date +%F)

恢复路径：若变更导致数据库连接中断或 Web 进程无法读取配置，直接执行：

cp -p /path/to/wordpress/wp-config.php.bak_$(date +%F) /path/to/wordpress/wp-config.php
systemctl reload php-fpm

2. 实施收敛与配置更新

针对生产环境关闭调试日志回显，同时仅允许所有者及授权组成员读取：

# 修改权限（以 php-user 为所有者、web-group 为共享组为例，依前文盘点结果调整）
chmod 640 /path/to/wordpress/wp-config.php
chown php-user:web-group /path/to/wordpress/wp-config.php

在 wp-config.php 中确保调试模式关闭或仅写入离线日志：

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
define( 'DISALLOW_FILE_EDIT', true ); // 禁止后台在线编辑主题/插件文件

业务影响：启用 DISALLOW_FILE_EDIT 会导致后台“主题文件编辑器”不可见，对于依赖后台直接改代码的非规范流程存在破坏性，需提前与站点管理员确认。

验证与复核：业务全流程测试

变更完成后，必须立即按预设功能路径进行验证，而不仅仅依赖 Wazuh 控制台的状态刷新。

核心功能测试清单

1. 前台与 CDN 穿透访问：清理本地缓存，发起携带动态参数的请求，验证页面响应码是否为 200，检查静态资源加载状态。
2. 管理后台登录与 Session 维持：打开隐私窗口访问 /wp-login.php，提交认证信息，验证能否正常进入仪表盘。
3. 媒体上传与缩略图生成：在“媒体”库中上传一张测试图片，确认 PHP 进程对 wp-content/uploads 具有写入权限，并检查缩略图生成是否正常。
4. 插件与翻译更新机制：在“控制板 -> 更新”中检查更新通道，确认是按预期的外部部署方式报错，还是按内置方式正常通信。
5. 计划任务（WP-Cron）：检查系统 Cron 或访问 /wp-cron.php?doing_wp_cron，确认自动化任务队列未受权限阻塞。

# 观察日志窗口：实时捕获 PHP-FPM 致命错误与 Web 500 状态
tail -f /var/log/nginx/error.log /var/log/php-fpm/www-error.log

保持观察窗口 15 到 30 分钟。如果日志中未出现 Permission denied 或 failed to open stream 异常，再进入复查阶段。

持续复盘与规则基线调优

当业务验证无误后，返回 Wazuh 端进行对账与复盘：

1. 触发 SCA 本地重新扫描：

在服务器上向 Agent 发送通知或重启服务以触发即时评估：

   systemctl restart wazuh-agent

1. 审计报告对账：

在 Wazuh 管理平台上，确认已修复项的状态转为 Passed。

1. 策略规则调优（SCA Policy Customization）：

对于因架构不适用而产生“未通过”但经评估属合理的配置，不要放任其长期处于红色告警状态。应克隆官方的 WordPress/linux SCA YAML 规则文件，调整其中的判定路径或通过规则排除。例如，在规则的 rules: 判定块中，将默认的路径变量调整为本机的部署路径，或将非标准架构的安全补偿措施写入豁免逻辑。

自动化评估工具的作用是提供基线镜子，而不是绝对指令。始终以实际架构为准绳，以业务功能不受损为底线，建立“盘点上下文、核验风险、灰度变更、全链路验证”的运维闭环，才能让安全工具真正服务于站点的稳健运行。