序幕：个人博客没人攻击？

之前我一直这么以为。一个小博客，既不涉及金钱交易，也没有用户数据，谁会这么有空来攻击？直到今天去翻服务器的登录日志，才意识到之前的想法有多一厢情愿。

过去九天，这台服务器的 SSH 端口累计收到了 62,766 次登录尝试。六十二次？六百二十六次？都不是。六万两千多次。每一次都是猜密码，每一次都在试图闯进来。

这篇文章记录我们的服务器从被各路脚本自动攻击，到一步步堵上所有漏洞的完整过程。所有数据都是真实日志里扒出来的。后半篇附了完整的防御实操教程，跟着敲命令就能把自己也加固起来。

SSH 暴力破解：62,766 次撞门

先看 SSH 登录失败记录。从7月1日到7月9日，lastb 命令统计的结果让人头皮发麻：

好笑的是 “hellolll” 也被列入了字典，说明攻击脚本自动把域名前缀也编进了用户名字典。最离谱的是一个叫 “admins” 的用户名，带了复数 s，在日志最后一行恰好是 09 日 23:30 的记录，直到我们把密码登录关掉的前一秒还在试。

攻击者们手里拿的是同一本”密码本”：一组最常见 Linux 用户名的字典，外加自动从网站上抓的关键词。他们不会思考，只会举着一串钥匙挨个试。试不开就换下一扇门。

不止撞密码，WordPress 全面扫描

SSH 攻击是站在门外撞锁。WordPress 扫描更”精巧”，它们假装正常访问，实则探测一切能找到的入口。

• xmlrpc.php 批量爆破：利用 XML-RPC 接口一次发送多个用户名密码组合，绕过登录频率限制。峰值单天（5月29日）收到 24,018 次 XML-RPC 请求。
• 用户枚举：访问 /?author=1 和 /wp-json/wp/v2/users/，收集真实用户名。
• 路径扫描：试探 /.env、/.git、wlwmanifest.xml 等敏感路径。累计产生 67,927 次 404 响应。

最大的单一源头来自德国柏林的一台 M247 服务器（IP 217.138.216.212），仅它一台就贡献了 34,020 次请求。

这类扫描没有针对性。脚本对互联网上所有 WordPress 博客都是同一套流程，你只是恰好被扫到了。但问题的本质不变：只要入口开着，被猜到密码是概率问题。

攻击原理详解

SSH 暴力破解是如何工作的

SSH（Secure Shell）默认监听 22 端口。用密码登录时的流程：

1. 客户端发起 TCP 连接到服务器的 22 端口
2. 双方交换加密密钥，建立加密通道
3. 服务器提示输入用户名
4. 服务器提示输入密码
5. 服务器验证用户名+密码，返回成功或失败
6. 如果失败，客户端可以立刻再试，没有硬性速率限制

问题出在第 6 步。SSH 协议本身没有内置的登录频率限制。攻击者的脚本可以这样写：

for user in root admin ubuntu debian ...; do
    for pass in 123456 password admin123 ...; do
        ssh $user@target -p 22
    done
done

从一台 5 美元的 VPS 上跑，一秒能试几十次。同时从 10 台 VPS 上跑，攻击量直接乘 10。我们的日志里看到的 91.92.x / 45.153.x 批量 IP 段，就是典型的分布式字典攻击：攻击者租了多台廉价 VPS，每台跑同样的脚本、试同样的字典，目标是穷举所有可能的用户名密码组合。

什么叫分布式？什么叫字典？你可以想象一个画面：一百个人站在一栋大楼前，每个人手里都拿着一本同样的电话号码簿。他们同时开始对每个房间喊话：”张三！123456！”、”张三！password！”、”李四！123456！”，没有人真的认识张三或李四，他们只是按照那本”字典”上的名字和密码挨个试。喊错了就下一个，喊对了门就开了。这就是字典攻击。而”分布式”指的是这一百个人站的位置不同：有人在美国，有人在德国，有人在土耳其。你封了一个人的 IP，其他九十九个人还在喊。IP 是攻击脚本里最不值钱的资源，每台 5 美元 VPS 就是一个新的”喊话点”。

攻击者手里有三样东西：

• 用户名字典：最常见的 Linux 用户名列表。root、admin、ubuntu、debian、test、user，以及从网站上自动抓取的关键词（所以 hellolll 也出现在字典里）。

• 密码字典：常见弱密码，比如 123456、password、admin123、qwerty，以及目标网站相关词汇。

• 代理 / VPS 集群：从不同 IP 同时攻击，规避单 IP 被临时封禁。

这不是什么高明的攻击，只不过是自动化脚本在批量扫描整个互联网。脚本不知道你是谁，也不在乎。它只是机械地试，试不开就下一台。但一旦你的密码在字典里，撞开只是时间问题，这样的事情在公网上每分每秒都在发生成千上亿次，攻击成功的概率很低，但攻击成本同样很低，因此可以用数量换质量，因为总有那么些完全不注重安全问题的人。

WordPress XML-RPC 为什么会成为突破口

XML-RPC 是 WordPress 早期用于远程发布文章、管理评论的接口（例如通过 Windows Live Writer 离线写博客）。它暴露在 /xmlrpc.php，默认开启。

这个接口有一个致命的设计缺陷：system.multicall 方法允许一次 HTTP 请求里打包多个认证尝试。攻击者可以在一个 POST 请求中塞进成百上千组用户名密码，服务器只返回一次结果。后果：

• 攻击速率被放大了数百倍。一次请求、一次 HTTP 连接，可以携带上千次密码尝试。

• Web 应用层的登录限制插件大多只拦截 wp-login.php 的请求频率，对 xmlrpc.php 完全不起作用。

• 即使攻击失败，每个 POST 请求本身的处理也会消耗服务器资源。

用生活中的例子来理解。普通的 wp-login.php 登录，相当于你去银行柜台，每次只递一张身份证，柜员核对一次。你一小时能递多少次？顶多几十次。而 xmlrpc.php 的 multicall，等于你把一千张身份证装在一个信封里递进去，柜员一口气全部核对完，然后把结果一股脑告诉你。你一小时可以递几百个信封，每个信封里还是一千张身份证。攻击效率就这样放大了一千倍。很多安全插件只盯着”柜台排队次数”，完全没注意到有人从”信封通道”走了。

其他扫描手法一览

如果被攻破，会发生什么？

很多人觉得：一个小博客有什么好偷的？又没有用户数据，又不涉及金钱。这个想法对了一半。攻击者确实不关心你是 hellolllworld 还是随便什么博客。他们关心的是：一台装了 4 核 CPU、4GB 内存、不限流量的 Linux 机器，刚好开着密码登录。

植入加密货币挖矿程序

这是最常见的结局，约 70% 的自动攻击就为这件事。脚本登进来第一件事不是偷数据，是下载一个门罗币（Monero）矿工程序。矿工把你的 CPU 拉到 100%，你付的是算力，攻击者收的是币。

云服务器上不直接付电费，你不会第一时间发现。但 CPU 被吃满之后，Nginx 响应变慢、PHP 连接超时，网站打不开了，访客走了，攻击者在默默挖币，从你这里每天赚走几毛到几块钱。

纳入僵尸网络

你的服务器变成一个节点，可以用来 DDoS 攻击别人的网站、发送垃圾邮件、扫描下一批受害者。一台 4GB 的 VPS 在僵尸网络里能同时干好几件事。

问题是：攻击来源 IP 成了你的 IP，追查到的也是你。云服务商会先找你的麻烦，你的账号被封、机器被回收，你可能完全不知道发生了什么。

当作代理跳板

攻击者把你的服务器配成 SOCKS5 代理，从你的 IP 去刷支付接口、发钓鱼邮件、访问暗网。你的服务器成了别人的数字手套，脏活是别人的，指纹是你的。

窃取数据并植入垃圾链接

WordPress 的 wp-config.php 里明文存着数据库密码。拿到密码等于拿到了整个站点的内容、用户表、主题配置。有人会直接导出数据库转卖，有人往你的网页里植入 SEO 垃圾链接你，看不见，Google 能看到。你的 SEO 排名在不知情的情况下被搞烂。

勒索

比较少发生但确实存在：攻击者用 tar 打包整个网站目录，gpg 加密，删掉原文件，留一行字「付 BTC 解锁」。个人博客赎金不高，但脚本不挑，它在所有被黑的服务器上跑同一套逻辑。你的数据对别人而言不值钱，对你来说失去唯一备份就是真正的代价。

所以攻击者为什么要攻击你的小服务器？一台不够，一千台、一万台就够了。廉价 VPS 一个月 5 美元，攻击者一个都不租，他们靠爆破免费获取。单台被黑的服务器挖矿月收益不到一两美元，做代理节点月收益三到十美元。一万台呢？这些收入是被动的：脚本自己扫、自己登、自己部署，攻击者坐等收钱。你的服务器在他们眼里不是「一台叫 hellolllworld 的博客」，而是「一台可以赚钱的机器，刚好还没锁门」。

防御实操教程

下面每一步都可以在终端直接复制粘贴执行。所有操作都在我们的服务器上实测通过（Ubuntu + 宝塔面板 + Nginx）。如果你的环境不同，命令可能需要微调，原理完全一致。

第一步：生成 SSH 密钥对

如果你还没有 SSH 密钥，先在自己的电脑（本地）上生成。不要在服务器上生成。

# 在本地电脑的终端执行（不是服务器！）
# Windows 用 PowerShell 或 Git Bash，Mac/Linux 直接终端
ssh-keygen -t ed25519 -C "你的邮箱或备注"

一路回车就行。默认会生成两个文件：

• ~/.ssh/id_ed25519：私钥，绝不给任何人。

• ~/.ssh/id_ed25519.pub：公钥，这个上传到服务器。

公钥和私钥到底是什么关系？把它们想象成一个信箱：公钥是信箱的投递口，谁都可以往里面投信；私钥是信箱的钥匙，只有你手里的那一把能打开。你把公钥（投递口）装在服务器门上，每次登录时，服务器往投递口扔一个随机问题，你的私钥（钥匙）解开问题后把答案送回去。服务器一看答案对，就放你进去。整个过程不需要密码参与——拿不到私钥的人，猜一万年也答不对随机问题。这就是为什么关了密码登录之后，lastb 里的失败记录还在涨，但没有任何一次能成功。

第二步：把公钥上传到服务器

在本地电脑上执行（把 IP 换成你自己的服务器地址）：

ssh-copy-id root@你的服务器IP

如果 ssh-copy-id 不可用，可以手动操作。先 SSH 密码登录服务器，然后把本地 .pub 文件内容追加到服务器的 /root/.ssh/authorized_keys：

# 先复制本地公钥内容
cat ~/.ssh/id_ed25519.pub

# 然后 SSH 登录服务器，粘贴到下面这条命令
echo "刚才复制的公钥内容" >> /root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys

验证：新开一个终端窗口，用 ssh root@你的IP 连接。不再提示输入密码直接进去了，说明密钥生效。

第三步：禁用 SSH 密码登录

# 在服务器上执行
sed -i 's/^PermitRootLogin yes/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
sed -i 's/^#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl reload sshd

解释：PermitRootLogin prohibit-password 允许 root 登录但仅接受密钥。PasswordAuthentication no 彻底关闭所有用户的密码登录方式。

验证：现在任何人从任何 IP 用密码登录都会被静默拒绝。可以用 lastb 命令确认：记录仍然在增长（攻击者还在试），但全部返回失败，永远撞不开。

第四步：锁定 MySQL，禁止外网访问

先检查 MySQL 当前监听状态：

ss -tlnp | grep 3306

如果看到 0.0.0.0:3306 或 *:3306，说明数据库暴露在公网上。任何知道（或扫描到）你 IP 的人都可以直接尝试连接。我已经把 MySQL 绑到 127.0.0.1 了，现在跑会显示 127.0.0.1:3306。

什么叫”绑定到 127.0.0.1″？你可以把数据库想象成服务器内部的一个房间。bind-address = 0.0.0.0 的意思是”这个房间对所有方向开门”，任何从互联网来的连接都可以敲门，包括攻击者的数据库扫描脚本。bind-address = 127.0.0.1 的意思是”这个房间只在内部走廊开一个门”，只有服务器自己（你的 WordPress、你的命令行）能走内部走廊进去。外面的人根本看不到这扇门。对我们来说，WordPress 和 MySQL 跑在同一台机器上，走 localhost 即可，完全不需要让数据库对外开门。

修复办法：在 MySQL 配置文件（宝塔通常在 /etc/my.cnf）的 [mysqld] 段落中添加一行：

bind-address = 127.0.0.1

保存后重启 MySQL：

systemctl restart mysqld
ss -tlnp | grep 3306  # 确认现在显示 127.0.0.1:3306

这样一来，只有服务器自己（通过 localhost）能连数据库。WordPress 运行在同一台机器上，不受影响。外网连接全部被操作系统拒绝，连防火墙都不需要到达。

第五步：防火墙规则清理

先看看当前有哪些端口对外开放：

ufw status

删除不再需要的放行规则：

ufw delete allow 20/tcp           # FTP（如果不用）
ufw delete allow 21/tcp           # FTP
ufw delete allow 31058/tcp        # 未知服务
ufw delete allow 8000/tcp         # 未知服务
ufw delete allow 39000:40000/tcp  # FTP 被动模式端口范围

端口是什么？为什么每多一个就是多一道门？端口是服务器向外暴露的服务编号。比如 80 是网页、22 是 SSH。每个端口就像大楼的一个入口：开着的门越多，能扫描的点就越多。FTP 的 20、21 端口、被动模式端口范围 39000-40000——如果你已经不用 FTP 传文件了，它们就是几扇忘了锁的后门。攻击脚本不会判断这个门后面有没有东西，它们会试每一个开着的门。原则很简单：只保留真正在用的端口。我们最终剩下来的只有 22（SSH）、80/443（Nginx）、888/8889（宝塔面板），以及机器人和 Docker 服务的几个端口。

第六步：PHP-FPM 进程数调优

宝塔 PHP 的默认配置通常偏大。检查当前设置：

grep 'pm.' /www/server/php/84/etc/php-fpm.conf

如果 pm.max_children 是 50 或者更高，4GB 内存的服务器有被 PHP 吃穿的风险。建议值：

什么情况下 PHP 进程会吃光内存？当一个访客请求你的 WordPress 页面时，PHP-FPM 会从进程池里分配一个”子进程”来处理这个请求。这个子进程在处理期间大约占用 50MB 内存。如果同时有 50 个请求进来，max_children=50 就意味着 PHP 可以开 50 个子进程，占用 50 × 50 = 2500MB（约 2.5GB）内存。再加上 MySQL 和 Nginx 的内存占用，4GB 的服务器直接就到极限了。而个人博客每秒能有几个访问者？大多数时候 2-3 个就顶天了。把 max_children 从 50 降到 15是为了降低内存请求。

# 一键修改
sed -i 's/pm.max_children = 50/pm.max_children = 15/' /www/server/php/84/etc/php-fpm.conf
sed -i 's/pm.start_servers = 5/pm.start_servers = 3/' /www/server/php/84/etc/php-fpm.conf
sed -i 's/pm.min_spare_servers = 5/pm.min_spare_servers = 2/' /www/server/php/84/etc/php-fpm.conf
sed -i 's/pm.max_spare_servers = 20/pm.max_spare_servers = 8/' /www/server/php/84/etc/php-fpm.conf
systemctl reload php-fpm-84

PHP-FPM 从 50 降到 15 后内存余量更多

第七步：添加 Swap 保底

内存用满时如果没有 Swap，Linux 的 OOM Killer 会随机强行暂停占用内存最高的进程。可能是 MySQL，可能是 Nginx，可能是 PHP。加一个 1GB 的 Swap 文件当缓冲区：

OOM Killer 是个什么东西？“OOM” 是 Out of Memory（内存耗尽）的缩写。当服务器内存被全部吃光，连操作系统自己都分不到新的内存时，内核里的 OOM Killer 就会启动。它的任务很粗暴：找一个占用内存最多的进程，直接杀掉，立刻释放内存。它不会问你”可以停止该进程吗？”，也不会优雅地保存数据。它会随机挑选一个程序Kill掉。被挑中的可能是 MySQL，你的数据库当场崩了。可能是 PHP-FPM，站点打不开了。也可能是你的机器人进程，所有服务突然停摆。Swap 的作用是在这之前提供一个缓冲区：内存快满的时候，不常用的数据被暂时挪到硬盘上的 Swap 空间，给正在运行的进程腾出地方。Swap 比内存慢很多，平时用不上，但 OOM 危机时它能给你几分钟的反应时间。

fallocate -l 1G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
free -h | grep Swap  # 确认 Swap 已生效

可选增强：禁用 XML-RPC

如果不需要通过离线客户端（如 Windows Live Writer）远程发布文章，可以在 WordPress 主题的 functions.php 中添加以下代码来拦截 XML-RPC 请求：

// 禁用 XML-RPC 认证（保留 pingback 等基本功能）
add_filter('xmlrpc_enabled', '__return_false');

或者在 Nginx 配置中直接拦截对 xmlrpc.php 的访问：

location = /xmlrpc.php {
    deny all;
}

攻击者的”IP 肖像画”

全部来自廉价 VPS 和租用服务器。都是自动脚本，拿一份扫描列表挨个撞。

几点思考

一、个人博客也是靶子。
互联网上的扫描流量从不挑食。你的服务器上线那一分钟起，就已经在字典里了。区别只在于：你是开着门等人撞，还是提前把门闩好。

二、密码登录是最大的破绽。
SSH 密码登录像给门上锁但没拔钥匙。孔在外面，够耐心总能撬开。密钥登录等于换了一把只认指纹的锁，爆破攻击对它毫无意义。

三、安全不是一次性工程。
今天做了 SSH 加固、MySQL 限制、防火墙精简、PHP 缩容，这些让服务器”现在”很安全。但下次装新服务的时候，又可能无意中打开了新的门。安全需要长期维护和随时代进步。

四、62,766 次不是上限。
我们只分析了 SSH 和 WordPress HTTP 请求的日志。如果把所有端口的扫描流量全算上，包括那些在防火墙层面就被 DROP 掉的，实际数字恐怕翻倍不止。没关系。只要防御策略到位，一千万次扫描和零次扫描效果一样。

结语

这篇文章不是炫耀我们防住了什么。事实上，这些攻击本来就不算高明。真正值得记录的，是”从一个漏洞百出的服务器到一条一条堵上所有缝隙”的过程。

如果你也有自己的 VPS 和 WordPress 博客，花十分钟检查一下：

• SSH 是不是还在用密码登录？

• MySQL 是不是监听了 0.0.0.0？

• 防火墙是不是开了一堆没用过的端口？

• xmlrpc.php 是不是还在接受 POST 请求？

不需要做什么复杂的操作。上面这些问题，每一条都有五分钟以内的修复方案。我们的经验和教训都在这里了。希望你用不上，万一需要，这篇文章就在这里。