Ubuntu 12.04下Nginx+WordPress老旧系统部署与加固指南

1. 项目概述：为什么在 Ubuntu 12.04 上用 nginx 部署 WordPress 仍值得深挖

你点开这个标题，大概率不是为了怀旧——没人会主动选一个 2012 年发布的、2017 年就终止标准支持的 Ubuntu 12.04 系统来搭新站。但现实很具体：我去年接手的三套老系统里，有两套跑着金融行业内部文档平台，数据库是 MySQL 5.5，PHP 是 5.3.10，内核是 3.2.0-23-generic，所有补丁都打到最后一刻，但就是不能升；还有一套是某高校实验室的嵌入式教学演示环境，整套镜像固化在 ARM 开发板 SD 卡里，重刷等于重写实验手册。它们共同的关键词是：稳定压倒一切，变更必须零风险，而 nginx + WordPress 在这个组合里，是唯一被反复验证过十年不崩的轻量栈。

这不是教你怎么“装个 WordPress”，而是带你回到那个还没有 Docker、没有一键脚本、没有宝塔面板的时代，亲手把 nginx 的 worker 进程绑进 CPU 亲和性，把 PHP-FPM 的静态子进程数算到小数点后一位，把 WordPress 的 .htaccess 伪静态逻辑一比一翻译成 nginx 的 location + rewrite 规则。Ubuntu 12.04 的 apt 源早已归档，官方镜像站只保留 security 和 updates 两个通道，这意味着你不能apt-get install nginx-full就完事——你得确认nginx-light是否带http_rewrite_module，得手动编译pcre库避免正则崩溃，得把php5-fpm的 socket 权限从/var/run/php5-fpm.sock改到/tmp/php5-fpm.sock才能绕过 AppArmor 对/var/run的严格限制。这些细节，现在搜“WordPress 安装教程”根本不会提，因为主流教程默认你用的是 Ubuntu 22.04 或 CentOS Stream，但恰恰是这些被时代甩下的细节，决定了老系统能不能多撑三年、会不会在某个凌晨三点因一次日志轮转而 silently crash。

我实测过 12.04 上的三种部署路径：直接 apt 安装（最快但模块缺失）、源码编译 nginx（最稳但耗时）、用 dotdeb.org 的第三方源（折中但需校验 GPG 密钥）。最终上线的那套金融文档系统，选择的是第三种——不是因为它最先进，而是因为它的nginx-extras包里预编译好了http_geoip_module，而我们恰好要用 IP 归属地做访问白名单。这种“功能倒逼选型”的决策逻辑，在现代云原生环境里几乎消失，但在存量系统运维中，它每天都在发生。所以这篇内容的核心价值，不在于教你复刻一个过时环境，而在于训练一种能力：当技术栈被锁定、当升级路径被堵死、当你只能在螺丝钉大小的缝隙里做文章时，如何用最原始的工具链，打出最可靠的组合拳。它适合三类人：还在维护政企老旧系统的运维工程师、需要复现 CVE 漏洞环境的安全研究员、以及想真正理解 Web 服务底层耦合关系的开发者——因为只有亲手把fastcgi_pass指向一个不存在的 socket 文件并看它报什么错，你才会明白“502 Bad Gateway”背后到底是哪一层在掉链子。

2. 整体架构设计与方案选型逻辑

2.1 为什么坚持用 nginx 而非 Apache？

很多人看到 Ubuntu 12.04 就默认上 Apache2，毕竟apt-get install apache2一行命令搞定，.htaccess也天然支持。但我在金融文档系统上线前做了三组压力测试：用ab -n 1000 -c 50模拟并发请求，分别压测 Apache2（prefork MPM）和 nginx（event MPM），结果很反直觉——Apache2 在 50 并发下平均响应时间 186ms，内存占用 42MB；nginx 同配置下响应时间 93ms，内存仅 14MB。差距不是一倍，而是三倍。原因在于 12.04 的内核调度机制对 Apache 的 prefork 模型极度不友好：每个请求独占一个进程，进程创建销毁开销大，而 nginx 的 event loop 在单线程内处理数千连接，对老旧硬件的 CPU 缓存更友好。

更关键的是安全隔离。Apache2 默认以www-data用户运行整个服务，而 WordPress 插件常需写入wp-content目录，一旦插件存在任意文件写入漏洞，攻击者就能直接拿到www-data权限执行系统命令。nginx 则不同——它本身不解析 PHP，只把请求转发给独立的php5-fpm进程池，而php5-fpm可以配置为以wordpress用户运行，这样即使 PHP 层被攻破，攻击者也无法读取/etc/shadow或写入/var/log/。我在某次渗透测试中复现过这个场景：用公开的 WordPress 插件 RCE 漏洞上传 webshell，Apache 环境下 shell 能直接执行cat /etc/passwd，而 nginx + php5-fpm（非 www-data 用户）环境下，cat命令返回 Permission denied。这个差异，在等保二级测评里就是“高危项”和“中危项”的分水岭。

2.2 为什么拒绝 Nginx 官方源，坚持用 Dotdeb？

Ubuntu 12.04 官方源里的nginx-light包体积仅 380KB，但它阉割了http_ssl_module、http_gzip_static_module和最关键的http_rewrite_module。而 WordPress 的固定链接（Permalink）功能依赖 rewrite 模块将/2024/06/post-name/这类 URL 重写为index.php?year=2024&monthnum=06&name=post-name。没有 rewrite，你只能用?p=123这种丑陋的 ID 链接，SEO 直接归零。有人建议自己编译 nginx，但 12.04 的gcc版本是 4.6.3，编译新版 nginx 会报error: ‘__sync_fetch_and_add_4’ was not declared in this scope，必须降级 pcre 到 8.21，而 pcre 8.21 又存在正则回溯 DOS 漏洞（CVE-2015-2325）。Dotdeb 的解决方案是：提供预编译的nginx-extras包，它基于 nginx 1.4.6（12.04 兼容性最佳版本），内置所有模块，且已打过 pcre 补丁。我对比过 Dotdeb 的nginx-extras和自己编译的版本：前者启动时间 0.12s，后者 0.38s，因为 Dotdeb 关闭了调试符号并启用了-O2优化。在资源紧张的老服务器上，这 0.26 秒就是多承载 12 个并发用户的物理极限。

2.3 PHP-FPM 的进程管理策略：静态模式才是 12.04 的最优解

12.04 的php5-fpm默认配置是dynamic模式：pm.max_children = 5，pm.start_servers = 2，pm.min_spare_servers = 1，pm.max_spare_servers = 3。这套参数在现代 SSD 服务器上没问题，但在 12.04 常见的 SATA 机械盘 + 2GB 内存机器上，会导致频繁的 fork() 和 kill() 进程震荡。我用vmstat 1监控过：每分钟有 17 次fork()调用，每次 fork() 需要复制整个 PHP 进程内存页，而 12.04 的copy-on-write机制在低内存下效率极低，导致si（swap-in）值飙升到 120KB/s。换成static模式后：pm = static，pm.max_children = 8，pm.max_requests = 500。8 这个数字怎么来的？计算公式是：可用内存 × 0.7 ÷ 单个 PHP 进程平均内存。用ps aux --sort=-%mem | head -5查到php5-fpm进程平均占 28MB，2GB 内存 × 0.7 = 1400MB，1400 ÷ 28 = 50，但实际不能这么激进——因为还要留 512MB 给 MySQL 和系统缓存，所以最终定为 8。pm.max_requests = 500是防内存泄漏的关键：WordPress 插件常有未释放的全局变量，跑满 500 次请求后自动重启子进程，比等 OOM killer 杀进程优雅得多。

3. 核心组件安装与配置详解

3.1 Ubuntu 12.04 环境初始化：绕过已失效的源和证书陷阱

Ubuntu 12.04 的默认源archive.ubuntu.com在 2017 年后已重定向到old-releases.ubuntu.com，但很多教程没更新，直接apt-get update会卡在Waiting for headers。正确做法是先备份原源列表：

sudo cp /etc/apt/sources.list /etc/apt/sources.list.backup

然后用 sed 一键替换所有源地址：

sudo sed -i 's/archive.ubuntu.com/old-releases.ubuntu.com/g' /etc/apt/sources.list sudo sed -i 's/security.ubuntu.com/old-releases.ubuntu.com/g' /etc/apt/sources.list

但光换域名还不够——12.04 的ca-certificates包太老，无法验证 HTTPS 证书。比如https://dotdeb.org的证书链用的是 SHA-256，而 12.04 默认只信任 SHA-1。解决方法是手动下载并安装新版证书包：

wget http://archive.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20160104ubuntu0.12.04.1_all.deb sudo dpkg -i ca-certificates_20160104ubuntu0.12.04.1_all.deb sudo update-ca-certificates

这步做完，apt-get update才能真正成功。我见过太多人卡在这里三天，最后重装系统——其实只是证书过期这个“看不见的墙”在作祟。

3.2 Dotdeb 源的添加与 GPG 密钥验证：安全与可用的平衡

Dotdeb 的 GPG 密钥在 2020 年已过期，但它的软件包签名依然有效。直接apt-key add会报gpg: WARNING: This key has expired!，导致apt-get update失败。正确姿势是强制信任该密钥：

wget https://www.dotdeb.org/dotdeb.gpg sudo apt-key add dotdeb.gpg # 强制标记密钥为有效 sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 89DF5277 sudo apt-key adv --edit-key 89DF5277 trust << EOF 5 EOF

然后添加源：

echo "deb http://packages.dotdeb.org precise all" | sudo tee /etc/apt/sources.list.d/dotdeb.list echo "deb-src http://packages.dotdeb.org precise all" | sudo tee -a /etc/apt/sources.list.d/dotdeb.list

注意：precise是 Ubuntu 12.04 的代号，千万别写成trusty（14.04）或xenial（16.04），否则 apt 会报404 Not Found。添加完后apt-get update，你会看到 dotdeb 的包出现在列表里。这里有个经验：不要apt-get upgrade全局升级，因为 dotdeb 的mysql-server-5.5会覆盖 Ubuntu 自带的mysql-client-core-5.5，导致mysql命令失效。应该只安装明确需要的包：sudo apt-get install nginx-extras php5-fpm php5-mysql php5-curl php5-gd php5-intl php5-mcrypt php5-xmlrpc

3.3 nginx 配置文件深度解析：从默认站点到 WordPress 专用规则

Ubuntu 12.04 的 nginx 默认配置在/etc/nginx/sites-available/default，但直接改它风险太大。最佳实践是新建一个独立配置文件：

sudo nano /etc/nginx/sites-available/wordpress-site

核心配置如下（逐行解释）：

server { listen 80; server_name example.com; # 必须填你的域名，不能用 localhost root /var/www/wordpress; # WordPress 根目录 index index.php; # 关键：禁止访问敏感文件 location ~ /\. { deny all; } location ~ ^/(wp-config\.php|readme\.html|license\.txt) { deny all; } # WordPress 伪静态规则：把 /post-name/ 重写为 index.php location / { try_files $uri $uri/ /index.php?$args; } # PHP 处理：必须用 unix socket，比 TCP 更快且绕过防火墙 location ~ \.php$ { include fastcgi_params; fastcgi_pass unix:/var/run/php5-fpm.sock; # 注意路径！12.04 默认是这个 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; } # 静态文件缓存：浏览器缓存 1 年，减少服务器压力 location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ { expires 1y; add_header Cache-Control "public, immutable"; } }

重点讲三个易错点：

1. fastcgi_pass必须用unix:/var/run/php5-fpm.sock，不能写127.0.0.1:9000。因为 12.04 的 AppArmor 配置默认禁止 nginx 访问网络端口，但允许访问/var/run/下的 socket。
2. try_files $uri $uri/ /index.php?$args中的$args不能省略，否则 WordPress 的搜索功能（?s=keyword）会失效。
3. add_header Cache-Control这行必须加，否则某些老旧手机浏览器（如 Android 4.4 的 WebView）会反复请求 CSS，导致页面闪烁。

启用配置：

sudo ln -sf /etc/nginx/sites-available/wordpress-site /etc/nginx/sites-enabled/wordpress-site sudo rm /etc/nginx/sites-enabled/default sudo service nginx reload

提示：service nginx reload比restart更安全，它会检查配置语法再平滑切换，避免因配置错误导致服务中断。用nginx -t可手动验证：输出syntax is ok且test is successful才算通过。

3.4 PHP-FPM 用户与权限精细化控制：安全边界的最后一道门

默认的php5-fpm配置以www-data用户运行，这是最大安全隐患。必须为 WordPress 创建独立用户：

sudo adduser --disabled-password --gecos "" wordpress sudo usermod -a -G www-data wordpress

然后编辑/etc/php5/fpm/pool.d/www.conf：

; 注释掉默认的 user/group ; user = www-data ; group = www-data ; 改为 wordpress 用户 user = wordpress group = wordpress ; socket 文件权限必须匹配 nginx 用户 listen.owner = www-data listen.group = www-data listen.mode = 0660 ; 关键：设置进程工作目录，防止跨目录访问 chdir = /var/www/wordpress

重启服务：

sudo service php5-fpm restart sudo service nginx restart

验证是否生效：ps aux | grep php5-fpm应该显示wordpress用户，而不是www-data。再检查 socket 权限：ls -l /var/run/php5-fpm.sock输出应为srw-rw---- 1 www-data www-data。如果权限不对，WordPress 会报502 Bad Gateway，因为 nginx 无法向 socket 写入请求。

4. WordPress 核心部署与生产级调优

4.1 WordPress 安装包获取与完整性校验：拒绝“来路不明”的 zip

别用wget https://wordpress.org/latest.tar.gz——这个链接在 12.04 的wget版本（1.13.4）下会因 TLS 协议不兼容而失败。正确方式是下载特定版本的 tarball，并用 GPG 校验：

# 下载 WordPress 4.9.22（最后一个完全支持 PHP 5.3 的版本） wget https://wordpress.org/wordpress-4.9.22.tar.gz wget https://wordpress.org/wordpress-4.9.22.tar.gz.md5 wget https://wordpress.org/wordpress-4.9.22.tar.gz.asc # 校验 MD5 md5sum -c wordpress-4.9.22.tar.gz.md5 # 导入 WordPress GPG 密钥（需提前安装 gnupg） gpg --import wordpress-pubkey.asc gpg --verify wordpress-4.9.22.tar.gz.asc wordpress-4.9.22.tar.gz

解压后，必须修改wp-config.php的数据库连接方式。12.04 的 MySQL 5.5 不支持mysqli的长连接，所以DB_HOST不能写localhost（它会走 socket），必须写127.0.0.1（强制走 TCP）：

define('DB_HOST', '127.0.0.1:3306'); define('DB_USER', 'wordpress'); define('DB_PASSWORD', 'your_strong_password'); define('DB_NAME', 'wordpress_db');

注意：DB_PASSWORD一定要用强密码，12.04 的mysql_secure_installation脚本不完善，容易漏掉匿名用户。手动清理：mysql -u root -p -e "DELETE FROM mysql.user WHERE User=''; FLUSH PRIVILEGES;"

4.2 WordPress 固定链接（Permalink）的 nginx 实现原理

WordPress 后台设置固定链接为/year/month/day/postname/后，Apache 用.htaccess的RewriteRule实现，而 nginx 必须手动写location。很多人照抄网上的规则却失败，原因是没理解try_files的执行顺序。正确逻辑是：

1. 先查$uri是否对应真实文件（如/wp-content/themes/twentytwenty/style.css）
2. 再查$uri/是否对应真实目录（如/wp-admin/）
3. 都不命中，则交给/index.php?$args处理

所以location /块必须放在location ~ \.php$之前，否则.php文件会被优先匹配，导致index.php本身也被重写，形成无限循环。我在某次部署中就因此触发了 nginx 的rewrite or internal redirection cycle错误，日志里全是*1122348 rewrite or internal redirection cycle while internally redirecting to "/index.php"。解决方法是在location /里加一个显式排除：

location / { try_files $uri $uri/ @wordpress; } location @wordpress { fastcgi_pass unix:/var/run/php5-fpm.sock; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root/index.php; }

这样就把重写逻辑和 PHP 执行彻底分离，万无一失。

4.3 生产环境必备的 WordPress 配置加固

在wp-config.php末尾追加以下加固代码（非插件，纯配置）：

// 禁用文件编辑功能（防止后台被黑后直接改主题） define('DISALLOW_FILE_EDIT', true); // 设置自动更新为仅核心小版本（12.04 的 PHP 不支持大版本更新） define('WP_AUTO_UPDATE_CORE', 'minor'); // 数据库错误不显示在前端（避免泄露表结构） define('WP_DEBUG', false); define('WP_DEBUG_DISPLAY', false); define('WP_DEBUG_LOG', true); // 日志写入 wp-content/debug.log // 设置 Cookie 安全标志（即使没 HTTPS 也要加） define('COOKIE_DOMAIN', 'example.com'); define('COOKIEPATH', '/'); define('SITECOOKIEPATH', '/'); define('ADMIN_COOKIE_PATH', '/wp-admin/'); define('PLUGINS_COOKIE_PATH', '/wp-content/plugins/'); define('COOKIEHASH', md5('example.com')); // 关键：禁用 XML-RPC（12.04 的 WordPress 4.9.22 的 xmlrpc.php 是 DDoS 攻击入口） add_filter('xmlrpc_enabled', '__return_false');

最后一条add_filter必须加——2016 年的 WordPress XML-RPC 暴力破解攻击（system.multicall）在 12.04 环境下尤其致命，因为它的max_connections默认值是 100，而攻击脚本能瞬间发起 500+ 并发，直接拖垮 MySQL。加了这行，/xmlrpc.php返回 403，攻击流量自然消散。

5. 常见问题排查与独家避坑指南

5.1 “502 Bad Gateway” 的七层排查法

这是 12.04 + nginx + WordPress 环境下最高频的错误。我整理了一张速查表，按发生概率从高到低排序：

实操心得：我遇到过最诡异的一次 502，是php5-fpm进程明明在运行，socket 文件也存在，但curl -I http://127.0.0.1一直超时。最后发现是/etc/apparmor.d/usr.sbin.php5-fpm里有一行deny /proc/*/status r,被错误启用，导致 PHP-FPM 无法读取自身状态，自动退出。删掉这行，sudo service apparmor reload，问题立解。这种问题，官方文档绝不会写，只有在/var/log/syslog里翻apparmor="DENIED"才能找到线索。

5.2 WordPress 后台“无法建立到 WordPress.org 的连接”终极修复

12.04 的curl版本太老（7.22.0），无法验证 WordPress.org 的 HTTPS 证书。后台更新插件时总提示“无法连接”，但ping api.wordpress.org是通的。根本原因是curl缺少 SNI（Server Name Indication）支持，而 WordPress.org 的 CDN 要求 SNI。解决方案是强制 WordPress 用fsockopen替代curl：

在wp-config.php加：

// 强制 WordPress 用 fsockopen（兼容 12.04） if (!defined('ALTERNATE_WP_CRON')) define('ALTERNATE_WP_CRON', true); if (!defined('WP_HTTP_BLOCK_EXTERNAL')) define('WP_HTTP_BLOCK_EXTERNAL', false); if (!defined('WP_ACCESSIBLE_HOSTS')) define('WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,downloads.wordpress.org');

然后在wp-includes/class-http.php的request()方法开头加：

// 强制使用 fsockopen（12.04 兼容） if (extension_loaded('openssl') && version_compare(PHP_VERSION, '5.6.0', '<')) { $args['sslverify'] = false; // 老版 OpenSSL 不验证证书 }

注意：sslverify = false只影响 WordPress 自身的 HTTP 请求，不影响前台用户访问，所以安全风险可控。这是在“可用”和“绝对安全”之间做的务实妥协。

5.3 nginx 日志分析实战：从 access.log 挖掘真实攻击行为

12.04 的默认 nginx 日志格式太简陋，log_format combined只记录$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent，但攻击者常伪造User-Agent或用代理 IP。必须自定义日志格式：

在/etc/nginx/nginx.conf的http块里加：

log_format custom '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' '$request_time $upstream_response_time $pipe';

然后在server块里用：

access_log /var/log/nginx/wordpress-access.log custom;

重启 nginx 后，用以下命令分析日志：

# 查找 5 分钟内同一 IP 的 POST 请求超过 10 次（疑似暴力破解） awk '$6==\"POST\" {ip[$1]++} END {for (i in ip) if (ip[i]>10) print i, ip[i]}' /var/log/nginx/wordpress-access.log # 查找访问 xmlrpc.php 的异常 UA（如 python-requests） grep "xmlrpc.php" /var/log/nginx/wordpress-access.log | grep -i "python\|curl\|wget" # 查找 404 页面中的可疑路径（如 /wp-admin/admin-ajax.php?action=xxx） awk '$9==404 {print $7}' /var/log/nginx/wordpress-access.log | sort | uniq -c | sort -nr | head -10

我用这套方法在金融系统里抓到过一个持续 3 个月的扫描器：它每天凌晨 2 点用sqlmap的 UA 访问/wp-content/plugins/xxx/readme.txt，试图枚举插件版本。加了location ~ /wp-content/plugins/.*/readme\.txt { return 403; }后，扫描流量直接归零。

6. 性能压测与长期稳定性验证

6.1 使用 ab（ApacheBench）进行基准测试：12.04 的真实承载力

ab是 12.04 自带的压测工具，无需额外安装。但默认参数会误导你——ab -n 1000 -c 100测试时，如果服务器响应慢，ab会堆积大量连接，导致结果失真。必须加-k（启用 Keep-Alive）和-H（模拟真实 UA）：

ab -n 5000 -c 100 -k -H "User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0" http://example.com/

关键指标解读：

• Time per request（平均响应时间）：低于 200ms 为优秀，300~500ms 为可接受，超过 800ms 需优化
• Requests per second（QPS）：12.04 + nginx + PHP5-FPM 的理论极限是 120 QPS（2GB 内存 + SATA 硬盘）
• Failed requests：必须为 0，否则说明有资源瓶颈（如 MySQL 连接数超限）

我实测过：当max_children = 8时，QPS 稳定在 112，Time per request189ms；当max_children = 12时，QPS 降到 98，Time per request升到 320ms，因为内存交换开始频繁。这证明 8 是 2GB 内存下的黄金值。

6.2 长期运行监控：用 sysstat 抓取 7×24 小时资源曲线

12.04 自带sysstat，但默认不启用。启用后，它每 10 分钟记录一次 CPU、内存、IO 数据：

sudo apt-get install sysstat sudo sed -i 's/ENABLED="false"/ENABLED="true"/g' /etc/default/sysstat sudo service sysstat restart

数据存于/var/log/sysstat/，用sar查看：

# 查看昨天的 CPU 使用率 sar -u -f /var/log/sysstat/sa$(date -d yesterday +%d) # 查看过去一小时的内存使用（单位 MB） sar -r -s $(date -d '1 hour ago' '+%H:%M:%S') -e $(date '+%H:%M:%S') # 查看磁盘 IO 等待时间（iowait > 20% 说明硬盘是瓶颈） sar -q -f /var/log/sysstat/sa$(date +%d)

我曾用这个方法发现一个隐藏问题：某天凌晨 3 点，iowait突然飙升到 45%，但top显示 MySQL 进程 CPU 占用只有 5%。深入查iotop，发现是rsyslogd在疯狂写/var/log/kern.log，因为某个内核模块日志级别设成了 debug。关掉 debug，iowait回归正常。这种问题，不靠长期监控根本发现不了。

6.3 WordPress 插件兼容性黑名单：哪些插件在 12.04 上必然崩溃

不是所有 WordPress 插件都适配 PHP 5.3 和 MySQL 5.5。我整理了一份 12.04 环境下的插件黑名单（附原因）：

实操心得：插件更新前，务必在测试环境wp-cli plugin update --dry-run检查依赖。我吃过一次亏：某次wp plugin update --all后，wp-cron.php报Fatal error: Call to undefined function password_hash()，整个后台瘫痪。恢复方法是 FTP 进入wp-content/plugins/，重命名出问题的插件文件夹，再用wp plugin activate逐个启用测试。

7. 安全加固与应急响应预案

7.1 防止 WordPress 被植入后门的三道防线

“120 万 WordPress 站点被植入后门”事件中，90% 的受害者是因弱口令 + 未禁用 XML-RPC。针对 12.04 环境，我部署了三层防护：

第一道：Web 层过滤（nginx）
在server块里加：

# 禁止访问 .php 文件以外的可执行脚本 location ~ \.(php|php5|phtml|pl|py