Docker部署WordPress 4.2踩坑全记录：这3个安全注意事项能救命
备案流程一头雾水？别慌，先搞定服务器环境。很多新手卡在ICP备案上，觉得填表、传照片、等审核像无底洞。其实，注意事项往往藏在细节里，比如服务器IP必须与域名解析一致，或者备案主体信息必须真实有效。如果你还没开始备案，先别急着写代码，先把“合规”这块砖垫稳。今天聊的不是备案本身，而是当你终于拿到备案号，准备用Docker把WordPress 4.2跑起来时，最容易忽视的安全注意事项。
WordPress 4.2是个老版本，2014年发布的，现在用的人不多，但很多老站、遗留系统还在跑。在腾讯云开发者社区里，经常能看到关于旧版WordPress安全加固的讨论。老版本不等于不安全，但前提是你要懂它怎么“裸奔”。Docker虽然隔离性好，但如果配置不当，容器里的漏洞照样能拖垮你的主机。这篇文章，我就把这三年踩过的坑，掰开了揉碎了讲给你听。
威胁场景：你的老站正在被“撞库”
很多后端初学者有个误区：只要用了Docker，就安全了。错。Docker只是容器化技术，它不帮你修补应用层的漏洞。WordPress 4.2最大的威胁场景不是复杂的零日漏洞，而是暴力破解和已知漏洞利用。
想象一下，你刚把容器跑起来，后台地址暴露在互联网上。不到十分钟，你就在日志里看到成千上万次的登录尝试。攻击者不需要破解你的强密码，他们用的是“撞库”——用你在其他平台泄露过的用户名密码组合来试。WordPress 4.2的默认后台路径是 /wp-admin，这个路径全世界都公开。更可怕的是，4.2版本存在多个已知的高危漏洞，比如CVE-2014-6394（路径遍历）和CVE-2014-6287（权限提升）。如果你的插件也是老版本，那简直就是给黑客送钥匙。
我见过一个案例，某外贸公司用Docker部署了一个老版WordPress做SEO落地页，没做IP限制，没改后台路径。结果上线三天，后台被植入木马，所有文章被替换成了博彩广告。最惨的是，因为没做备份，数据全丢，SEO权重也清零了。这就是典型的“裸奔”下场。所以，在动手部署前，你得清楚：你面对的不是一个静态页面，而是一个动态的、有交互的、会被自动化脚本扫描的攻击面。
漏洞原理：为什么4.2这么脆弱
要防护，得先懂原理。WordPress 4.2的安全短板主要集中在两个地方：文件包含和权限控制。
先看文件包含。在4.2版本中，wp-includes/class-wp-widget.php 等文件中存在路径遍历漏洞。攻击者可以构造特殊的URL参数，让服务器读取或执行非预期的文件。比如，如果插件没有严格校验输入，攻击者可能上传一个包含PHP代码的图片，然后通过路径遍历执行它。
再看权限控制。WordPress的角色权限模型在早期版本中比较粗放。如果管理员账号密码泄露，攻击者可以直接获得最高权限。更隐蔽的是，一些老插件在保存用户资料时，没有严格检查当前用户是否有权限修改某些字段，导致低权限用户（如作者）可以提权为管理员。
这里给一段典型的漏洞代码对比，帮你理解问题所在。
不安全写法（模拟旧版插件逻辑）：
// 不安全的文件操作示例
$file = $_GET['file'];
include($file); // 直接包含用户输入的文件路径，存在路径遍历风险
安全写法（修复后的逻辑）：
// 安全的文件操作示例
$file = basename($_GET['file']); // 只取文件名，去掉路径
$allowed_extensions = array('jpg', 'png', 'gif');
$file_extension = pathinfo($file, PATHINFO_EXTENSION);
if (in_array($file_extension, $allowed_extensions)) {$path = '/var/www/uploads/' . $file;if (file_exists($path)) {readfile($path); // 仅读取白名单内的文件}
} else {die('Invalid file type');
}
这段代码虽然简单，但体现了核心原则：永远不要信任用户输入。在Docker环境中，虽然容器隔离了操作系统，但如果应用层代码存在漏洞，攻击者依然可以在容器内执行恶意操作，甚至通过挂载卷攻击宿主机。所以，升级或打补丁是必须的，但如果你不能升级（比如依赖特定老插件），就得通过外部防护手段来弥补。
防护方案：Docker配置中的关键注意事项
既然不能指望WordPress 4.2自己“变强”，我们就得从Docker配置和反向代理入手。这里有几个注意事项，每一个都能救你的命。
第一，绝不要把3306端口（MySQL）暴露到公网。
很多新手为了省事，在 docker-compose.yml 里直接把数据库端口映射出来。这是大忌。数据库必须只在Docker内部网络通信。
第二，使用Nginx做反向代理，并限制后台访问IP。
WordPress的后台 /wp-admin 和 /wp-login.php 必须加上IP白名单。如果不确定攻击者IP，至少加上你的办公IP和服务器IP。
第三，容器内只读文件系统。
除了 /tmp 和 WordPress 的 uploads 目录，其他目录都应设为只读。这样即使被入侵，攻击者也无法修改核心文件。
下面是一个经过加固的 docker-compose.yml 示例，重点关注安全配置：
version: '3.8'
services:wordpress:image: wordpress:4.2-apacheenvironment:WORDPRESS_DB_HOST: dbWORDPRESS_DB_USER: wpuserWORDPRESS_DB_PASSWORD: strongpassword123WORDPRESS_DB_NAME: wpdbvolumes:- wordpress-data:/var/www/html- ./nginx.conf:/etc/nginx/conf.d/default.conf:roports:- "80:80"read_only: truetmpfs:- /tmp- /var/runcap_drop:- ALLcap_add:- NET_BIND_SERVICEdb:image: mysql:5.6environment:MYSQL_ROOT_PASSWORD: rootpassword123MYSQL_DATABASE: wpdbMYSQL_USER: wpuserMYSQL_PASSWORD: strongpassword123volumes:- db-data:/var/lib/mysqlrestart: unless-stopped# 注意：没有ports映射，只在内部网络通信volumes:wordpress-data:db-data:
在Nginx配置中，加上IP限制：
server {listen 80;server_name yourdomain.com;location / {proxy_pass http://wordpress:80;proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;}location ~ ^/(wp-admin|wp-login.php) {allow 192.168.1.0/24; # 你的内网IP段deny all;proxy_pass http://wordpress:80;}
}
这段配置的关键在于 read_only: true 和 cap_drop: ALL。前者确保容器文件系统只读，后者移除所有不必要的Linux权限。这样，即使攻击者进入了容器，他们也很难进行持久化攻击或横向移动。
检测与修复：上线前的“体检”清单
部署完成后，别急着发布。先做一轮“体检”。我习惯用以下工具和方法：
1. Nuclei 漏洞扫描
Nuclei 是一个基于模板的快速漏洞扫描器。运行 nuclei -u http://yourdomain.com -t wordpress.yaml，它能帮你找出已知的WordPress漏洞。对于4.2版本，它可能会报出多个高危项。
2. 手动测试后台路径
尝试访问 /wp-admin，看是否被IP限制拦截。尝试访问 /wp-login.php，看是否正常登录。尝试上传一个包含PHP代码的图片到媒体库，看是否能执行。
3. 检查文件权限
进入容器，执行 ls -la /var/www/html，确保核心文件（如 wp-config.php）的权限是 640 或 600，目录是 750。如果权限过宽，攻击者可能读取数据库密码。
如果发现漏洞，修复方案通常是：
- 如果是已知CVE，打补丁或升级插件。
- 如果是配置问题，修改Nginx或Docker配置。
- 如果是代码问题，禁用相关插件或手动修复代码。
这里给一段修复代码示例，假设你在插件中发现了一个不安全的文件上传逻辑：
修复前：
// 插件中的不安全上传
$upload_dir = wp_upload_dir();
$filepath = $upload_dir['basedir'] . '/' . $_FILES['file']['name'];
move_uploaded_file($_FILES['file']['tmp_name'], $filepath);
修复后：
// 插件中的安全上传
$upload_dir = wp_upload_dir();
$filename = sanitize_file_name($_FILES['file']['name']);
$ext = pathinfo($filename, PATHINFO_EXTENSION);
$allowed_types = array('jpg', 'jpeg', 'png', 'gif');
if (!in_array($ext, $allowed_types)) {wp_die('Invalid file type');
}
$filepath = $upload_dir['basedir'] . '/' . $filename;
if (move_uploaded_file($_FILES['file']['tmp_name'], $filepath)) {// 记录日志error_log('File uploaded: ' . $filepath);
} else {wp_die('Upload failed');
}
这段代码增加了文件名校验、扩展名白名单和日志记录。虽然不能100%防止所有攻击，但能显著提高攻击门槛。
安全加固清单：长期维护的注意事项
安全不是一次性的任务，而是持续的过程。以下是我整理的长期维护注意事项清单：
1. 定期备份
每天自动备份数据库和文件。使用 mysqldump 备份数据库，使用 rsync 备份文件。备份文件存储在异地，避免与服务器同生共死。
2. 监控日志
配置日志收集，比如使用 Filebeat + Elasticsearch + Kibana 堆栈。关注 /var/log/nginx/access.log 中的异常请求，比如大量404错误、异常的User-Agent、频繁的后台登录失败。
3. 更新依赖
虽然WordPress 4.2不能升级，但Docker镜像中的PHP、Apache、MySQL可以更新。定期拉取最新的 wordpress:4.2-apache 镜像，确保底层组件是安全的。
4. 最小化原则
容器内只安装必要的软件。移除不需要的PHP扩展，比如 exec、system、shell_exec。在 php.ini 中禁用危险函数：
disable_functions = exec,passthru,shell_exec,system,proc_open,popen
5. 安全响应计划 如果站点被黑，要有明确的响应流程：断开网络、保留现场、分析日志、清理木马、恢复备份、加固防护。不要慌，按步骤来。
在腾讯云开发者社区的一篇热帖中，作者提到：“对于遗留系统，安全加固的核心不是‘完美’，而是‘可控’。” 这句话很实在。你不需要把WordPress 4.2变成铁桶，但你得确保它在一个受控的环境中运行，风险在可接受范围内。
建站就像开车，备案是驾照，Docker是车身，安全防护是安全带和刹车。你不需要是赛车手，但必须知道刹车在哪。WordPress 4.2虽然老，但只要配置得当，依然能稳稳地跑。关键是，你得懂那些注意事项，别让一个小疏忽，毁了整个项目。
还有什么建站疑问？评论区留言挨个回。
