WordPress 网站安全加固与服务器防护及 Podman 容器化部署实践

本文详细记录了 WordPress 网站安全加固与服务器安全优化的步骤。文章内容包括 攻击行为分析 、 WordPress 代码与用户加固 、 Nginx 防护配置 以及基于 Podman 的容器化部署 方案，这些措施有效提升系统抵御自动化脚本攻击的能力。

前言 (Preface)

我在查看 Umami 的网站统计数据时发现有异常访问流量，仔细一看才发现原来是我的网站被攻击了。

我让 Gemini 分析了一下访问历史记录，基本可以判定这是一次自动化漏洞扫描或是脚本小子的攻击。

虽然最终也没攻破我的网站，也没入侵进我的服务器，但也促使我对网站的安全防护进行新一轮的加固。

当然了，退一步来说即使服务器被入侵了我也没啥损失，毕竟重要数据不可能放在云服务器上保存。

自动化攻击行为分析

分析 Umami 访问记录可以发现，攻击行为具有明显的自动化特征。探测范围覆盖了从基础的代码注入到复杂的数据库盲注，以及针对不同操作系统的文件系统遍历尝试。

代码注入与非法执行

攻击者频繁利用算术表达式测试后端模板引擎的解析能力，并尝试直接调用 PHP 系统函数。

此类行为试图验证服务器是否存在未经身份验证的远程代码执行漏洞。

URL 访问历史中尝试执行算术运算的代码注入攻击特征

URL 访问历史中尝试测试 Java、Python 及 PHP 后端模板引擎漏洞

URL 访问历史中尝试直接通过 URL 运行 PHP 函数的记录

数据库 SQL 注入探测

访问历史记录了大量包含 SLEEP() 等函数的 Payload 注入数据。

攻击者利用布尔型或时间盲注手段探测数据库结构，通过响应延迟判断注入点是否存在及数据表构成。

URL 访问历史中对 MySQL 与 PostgreSQL 数据库进行时间盲注的特征

URL 访问历史中对 Oracle 数据库进行延迟测试的注入尝试

尝试使用 extractvalue 与 md5 函数引发数据库报错以泄露数据

路径穿越与文件获取

攻击请求中包含对 /etc/passwd 以及 win.ini 等系统核心配置文件的访问尝试。

这种无视操作系统差异的路径穿越行为，表现出明显的自动化漏洞扫描器无差别探测特征。

URL 访问历史中尝试 Linux 系统路径穿越的特征

URL 访问历史中尝试 Windows 系统路径穿越的特征

尝试获取 Java Web 项目核心配置文件的访问历史记录

WordPress 核心安全配置

WordPress 的默认配置往往会暴露过多的系统信息，给攻击者提供便利。通过修改主题的 functions.php 文件，可以实现关键接口的访问控制和元数据的深度隐藏。

深度隐身与代码加固

通过清理 WordPress 头部元数据和脚本版本参数，可以有效隐藏站点的技术架构信息。

这种策略可以增加攻击者识别站点具体版本的难度，从而降低遭受针对性漏洞利用的风险。

/**
 * WordPress 安全加固与深度隐身代码
 */

// 1. 隐藏 WordPress 版本号（移除头部 generator 标签）
remove_action('wp_head', 'wp_generator');

// 2. 移除 CSS/JS 文件后的版本号参数（让扫描器无法通过加载项猜版本）
function dancying_remove_version_scripts( $src ) {
    if ( strpos( $src, 'ver=' ) )
        $src = remove_query_arg( 'ver', $src );
    return $src;
}
add_filter( 'style_loader_src', 'dancying_remove_version_scripts', 9999 );
add_filter( 'script_loader_src', 'dancying_remove_version_scripts', 9999 );

// 3. 禁用 REST API 用户枚举（保护用户名）
add_filter('rest_endpoints', function($endpoints) {
    if (isset($endpoints['/wp/v2/users'])) unset($endpoints['/wp/v2/users']);
    if (isset($endpoints['/wp/v2/users/(?P<id>[\d]+)'])) unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']);
    return $endpoints;
});

// 4. 拦截 ?author=n 扫描（防止通过 URL 猜测用户名）
if (!is_admin()) {
    if (isset($_GET['author']) && is_numeric($_GET['author'])) {
        wp_die('出于安全考虑，本站已禁用作者存档扫描。', '禁止访问', array('response' => 403));
    }
}

// 5. 隐藏登录报错信息（不具体提示“密码错误”还是“用户名不存在”）
function dancying_login_error_message() {
    return '登录信息错误，请重试。';
}
add_filter( 'login_errors', 'dancying_login_error_message' );

// 6. 禁用离线发布接口 XML-RPC
add_filter('xmlrpc_enabled', '__return_false');

在 WordPress 主题 functions.php 文件中添加安全加固代码

以下是添加 WordPress 加固代码前后的数据信息展示的对比截图。

WordPress 隐藏前端页面版本号信息的实际对比效果

禁用 WordPress REST API 用户名枚举功能的防御效果截图

WordPress 登录失败时隐藏具体错误信息的防护展示

用户体系安全增强

在 WordPress 用户管理层面，建议将登录用户名与对外显示的作者别名进行分离。

WordPress 本身不支持修改登录用户名，需要进入数据库修改或使用插件修改。

在 WordPress 后台搜索 Username 插件的结果列表

服务器层级安全策略

服务器层面的防护是过滤恶意流量的核心环节。通过 Nginx 的正则匹配规则与容器化的运行环境，可以构建起多层防御体系，确保即便应用层出现漏洞，宿主机依然处于安全受控状态。

Nginx 高级防护规则

Nginx 处于防护链条的最前端，通过配置精准的正则表达式，在请求到达 WordPress 之前拦截具备注入特征的非法访问。

这不仅能有效减轻后端的处理压力，也提升了系统的整体响应效率。

# 禁止在关键目录执行 PHP 或其他脚本
location ~* ^/(wp-content/uploads|wp-content/plugins|wp-content/themes|wp-includes)/.*(\.php|\.php5|\.sh|\.py|\.pl|\.jsp|\.asp)$ {
    deny all;
    access_log off;
    log_not_found off;
}

# 锁定并保护 wp-config.php 配置文件
location = /wp-config.php {
    deny all;
    access_log off;
    log_not_found off;
}

# 拒绝访问所有以点开头的隐藏文件
location ~ /\. {
    deny all;
    access_log off;
    log_not_found off;
}

# 拦截日志中出现的路径穿越攻击特征
location ~* (etc/passwd|win.ini|web\.xml|self/environ|proc/self) {
    deny all;
    access_log off;
}

# 屏蔽自动化工具经常扫描的备份目录
location ~* /(WEB-INF|META-INF|backup|old-wp|db-backup|sql-dump) {
    deny all;
    access_log off;
}

# 彻底关闭被频繁利用的 XML-RPC 接口
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

# 强制限制 HTTP 请求方法仅限基础类型
if ($request_method !~ ^(GET|POST|HEAD)$ ) {
    return 444;
}

# 针对 URL 查询字符串进行简单的注入过滤
if ($query_string ~* "union.*select.*\(") { 
    return 403; 
}

# 拦截常见的拼接型 SQL 注入特征
if ($query_string ~* "concat.*\(") { 
    return 403; 
}

容器技术隔离部署

采用容器化技术进行 WordPress 网站服务部署，可以实现 Web 环境与宿主机操作系统的逻辑隔离。

这样即便 Web 应用出现安全破口，风险也被限制在容器内部，可以有效防止攻击向宿主机的横向渗透。

以下为使用 podman 部署和运行 WordPress 容器的 Linux 代码命令，可以用作部署参考。

#!/bin/bash

# 定义容器、Pod 及持久化卷的规范化名称变量
POD_NAME="wp-stack-pod"
VOL_DB="wp-db-data"
VOL_HTML="wp-app-data"
DB_CONTAINER="wp-db-server"
WP_CONTAINER="wp-app-server"

# 设置数据库初始化所需的名称与安全凭据
DB_NAME="wordpress_db"
DB_USER="wp_admin"
DB_PASS="SecurePass123"
DB_ROOT_PASS="RootSecurePass456"

echo "开始部署 WordPress Stack..."

# 创建用于存放数据库文件和网页文件的命名卷
podman volume create $VOL_DB
podman volume create $VOL_HTML

# 创建 Pod 实例并预留 8080 端口用于外部访问
podman pod create --name $POD_NAME -p 8080:80

# 使用 docker.io 完整地址启动 MariaDB 数据库容器
podman run -d \
  --name $DB_CONTAINER \
  --pod $POD_NAME \
  -v $VOL_DB:/var/lib/mysql:Z \
  -e MYSQL_ROOT_PASSWORD=$DB_ROOT_PASS \
  -e MYSQL_DATABASE=$DB_NAME \
  -e MYSQL_USER=$DB_USER \
  -e MYSQL_PASSWORD=$DB_PASS \
  docker.io/library/mariadb:10.11

# 使用 docker.io 完整地址启动 WordPress 容器并连接本地数据库
podman run -d \
  --name $WP_CONTAINER \
  --pod $POD_NAME \
  -v $VOL_HTML:/var/www/html:Z \
  -e WORDPRESS_DB_HOST=127.0.0.1 \
  -e WORDPRESS_DB_NAME=$DB_NAME \
  -e WORDPRESS_DB_USER=$DB_USER \
  -e WORDPRESS_DB_PASSWORD=$DB_PASS \
  docker.io/library/wordpress:latest

# 输出部署状态汇总信息及后续管理命令提示
echo "------------------------------------------"
echo "部署完成！"
echo "访问地址: http://localhost:8080"
echo "------------------------------------------"

容器化部署适合使用域名根目录访问网站的情况，如果想要配置子路径访问网站会比较麻烦。

总结 (Summary)

网络安全在本质上是防御维度与攻击成本的持续博弈过程，通过增加探测门槛能有效逼退大多数脚本小子。

通过隐藏系统特征与收紧权限管理能过滤掉自动化扫描请求，使站点在茫茫互联网中处于相对隐身的状态。

实施容器化隔离部署可以确保即便 Web 应用层受损也不会波及宿主机，将潜在风险锁定在受控的沙箱内。

定期执行日志审计并动态更新防护规则是维持稳定的核心工作，通过实战反馈不断查漏补缺才是长久之计。

建立多维度的纵深防御体系比单纯依赖安全插件要更具有实效，这不仅是技术选型更是运维思路的转变。

参考链接 (References)

WordPress – Docker Official Image