Nginx 防恶意解析失效了？2000 条拦截日志揪出 HTTPS 时代的默认站点陷阱

1. WAF 里的“奇怪”域名

十一假期的最后一天，我习惯性翻看服务器状态，打开 WordPress 的 Wordfence 拦截日志，第一眼我甚至以为自己进错了后台。（是的，这文章开始写的时候是10-08）

Wordfence 作为兜底的安全插件，正常情况下每天不会有几条新增日志，结果昨天晚上有个 93.123.109.178 足足刷出了 2000+ 条拦截记录。整个日志上密密麻麻地都是针对主题目录的爆破记录，但受访的请求 URL 却非常诡异：全都不是我的域名 tjsky.net，而是清一色的 https://www1.example.com/...、https://www9.example.com/... 之类的伪造域名。

这倒是勾起我的好奇心了，前端机和后端机都分别有不同的安全规则在过滤着大部分常见的扫描器行为，我自己都时不时被我自己的安全规则拦在服务器外边，平时 Wordfence 一天都没两位数的日志，昨晚可好直接整进来 2000+ 条记录。

PS：用过 Wordfence 的小伙伴应该会发现这不是插件自己的流量记录（实时流量），因为插件的页面实在是太卡了，一旦日志条数较多，整个页面卡死的情况时有发生，所以我就重写了一个看日志的小插件。

于是我就去翻了一下昨晚 Nginx 的日志，发现这个扫描器还挺有意思的，怎么说呢，非常“标准”且“智能”。

1. 摸底探测：他先请求了 /?feed=rss2 和 /wp-links-opml.php，随后通过 /wp-json/wp/v2/pages 枚举接口，确认了这里是 WordPress 环境。

2. 模板盲猜：开始以每秒数次的频率轮番扫描 JieStyle-Two-2.6.2 和 spacious 等主流主题目录下的常见模板文件。因触发了 404 阈值，被 Wordfence 判定为恶意扫描并封禁了 IP，给他回报了一堆 503。

3. 致命一击：眼见直接访问的目录遍历无果，他开始尝试经典的远程代码执行 Payload：

   GET /?pagename=templates%252f...%252fusr%252flocal%252flib%252fphp%252fpearcmd

   配合空 POST，企图通过双重 URL 编码绕过目录穿越限制，利用系统内的 pearcmd.php 写入后门。

这时候后端机 Nginx 上的安全规则识别出了这个如此典型的 RCE，直接以 444 切断了连接，并通过 fail2ban 通知前后端都将他的 IP 彻底拉黑。但我心中巨大的问号还是没能解决：这个扫描器是怎么拿着毫不相干的假域名，一路摸进我的 WordPress 核心并让 Wordfence 记录下日志的？

2. 谁把他放进来的？

仔细比对 Nginx 访问日志与 WAF 记录后，谜底倒是很快就揭开了：他并不是通过域名找过来的，大概率是在全网盲扫 IP，直接访问我的服务器 IP，并在 HTTP 请求头里随机伪造了一些类似 Host: www1.example.com 的域名。

而他之所以能一路穿透到 WordPress，根源在于 Nginx 的虚拟主机默认回退机制：

当访问发送的 Host 无法匹配配置文件中的任何一个 server_name 时，Nginx 会默认将请求扔给加载顺序中的第一个站点或用户自己设置的默认站点。

而在大部分运维场景和很多网上的教程里（尤其是使用各类管理面板的环境中），对这种扫描的防御思路往往是“后置拦截”。比如我之前就在博客的 Nginx 配置里写了这么一段：

# 以前写在博客 server 块内的防御逻辑
if ($host !~* '^((www|img)\.)?tjsky\.net') {
   return 444;
}

逻辑看似天衣无缝：只要不是我的合法域名，直接返回 444 断开连接。我甚至还写过一篇文章介绍了一下这个方案：《Nginx 解决被恶意解析域名到自己服务器的 IP》，但当时的我忽略了一个在现代 Web 架构下至关重要的问题——虽然这样确实能拦住 Host 不匹配的请求，但在这里拦截的话就太晚了。（而且这个规则因为和我其他的安全规则冲突，目前处于被注释掉、无法生效的状态，这才是他能够使用随便写的域名进行访问的根本原因）

3. “设置默认站点防恶意解析”，在 HTTPS 时代失效了

很多人在宝塔/1Panel 建站时，都会看到官方的一句经典提示：

“设置默认站点后，所有未绑定的域名和 IP 都被定向到默认站点，可有效防止恶意解析。”

这句话放在十年前纯明文 HTTP（80 端口）时代可能确实是一条真理。黑客如果把做灰产的域名恶意 A 记录解析到你的 IP 去积累域名权重，或者把未备案域名解析到已备案域名的服务器 IP 上，访问这些未绑定域名的访客会被重定向到默认站，你的主站内容也就不至于被镜像白嫖。

但在全站 HTTPS 时代，这个逻辑就彻底失效了。

在 HTTPS 的通信规则下：TLS 握手必须先于 HTTP 传输。

当扫描器带着不存在的 www1.example.com 发送第一个 SSL 握手请求时，还没有到 HTTP 协议阶段，Nginx 根本拿不到 Host 报头，但为了完成连接，它也必须先挑选一张证书交出去完成握手流程。

如果把主站当成了默认站点，或者直接在主站点配置的 server 块内部写 if ($host)，就会引发两个问题：

1. 源站 IP 与证书直接泄露：Nginx 这时候别无选择，只能把主站的 SSL 证书双手奉上。对方访问的明明是个八竿子打不着的 IP，你却把印着真实域名的证书递了过去。哪怕后面 HTTP 阶段用 444 直接掐断了连接，扫描器也早已从证书的 Common Name 和 SAN 列表中拿到了真实域名 tjsky.net。在各种网络空间搜索引擎面前，源站 IP 瞬间透明化。

2. 密钥协商的性能损失：TLS 握手中的密钥协商（ECDHE 等）是属于消耗 CPU 的非对称加密计算，虽然这玩意每次的性能消耗倒也不能说有多大。但在高频并发的扫描器访问下，每一个访问 VPS 都要掏出算力陪他算完一整套数学题，然后才在 HTTP 应用层把连接断开，属于虽然小偷还没进家门，但已经敲了一次门的情况。

4. 用 ssl_reject_handshake 在 TLS 握手层就阻断连接

这种最基础的安全防线，应该立在最外层：对于不认识的域名，应该连 TLS 握手都别想完成。

Nginx 1.19.4 就引入了一个指令：ssl_reject_handshake。它允许 Nginx 在 TLS 握手的 Client Hello 阶段提取客户端声明的 SNI；如果发现这个域名不是本机绑定的合法站点，直接在握手层拒绝并挂断，不向客户端提供任何证书。（不过这时候“SNI 域前置、SNI 伪装”之类技术也会失效，对我现在这种只是拿来建站的场景倒是没什么影响；强制验证 SNI 只会对拿来跑 Trojan、VLESS、SNI Proxy 这类工具的人有影响，因为在现在的网络环境下，基本工具都需要开 SNI 伪装，而开了验证 SNI，你就很可能会把你自己拦住）

因此，最干净的架构是关闭默认站点功能，不过嘛，原生 Nginx 和面板里的 Nginx 配置方式会有一些差异。

而无论是原生还是面板，整个操作的核心逻辑都是在 Nginx 主配置的最上方或默认配置中，建立一个优先级最高的兜底规则：

# 1. 拦截非法 HTTP (80 端口直接静默丢弃)
server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 444;
}

# 2. 拦截非法 HTTPS (443 端口在握手阶段断开)
server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    server_name _;
    ssl_reject_handshake on;
}

而正式站点（比如我的 tjsky.net），则要老老实实保留 server_name 和证书配置，绝对不要加 default_server，也不要在里面写 ssl_reject_handshake on。

情况一：原生 Nginx 环境

如果你是直接 apt install nginx 或者用什么一键脚本安装的，设置的要点在于搞清楚 Nginx 配置文件的加载优先级，也就是 Nginx 对于一个访问最优先是匹配哪个配置文件里的指令。

Nginx 寻找虚拟主机（网站）遵循的优先级，从高到低是这样的：

1. 显式指定优先：任何在 listen 指令上显式写了 default_server 参数的站点，拥有最高优先级。

2. 加载顺序兜底：如果没有任何站点声明自己是 default_server，Nginx 则会默认以读取顺序中的第一个虚拟主机充当默认站。

• 而这个读取顺序，在子配置通过主配置文件 http { ... } 块中的通配符引入时（比如很多一键脚本和面板用的 include /etc/nginx/conf.d/*.conf;），系统底层采用的是标准 C 库 glob() 函数，按照文件名 ASCII 码字母顺序加载。

所以这种时候正确的操作姿势是：

• 方法 A（最直观）：直接新建一个 /etc/nginx/conf.d/00-default.conf，将上述兜底规则粘进去。以 00- 开头可以确保它在所有业务站点之前第一个被解析，就算漏写了 default_server，它也是排序第一的默认站。

• 方法 B（最纯粹）：直接打开 /etc/nginx/nginx.conf，将上述兜底规则写在 include /etc/nginx/conf.d/*.conf; 这一行的正上方。

情况二：宝塔 / 1Panel 面板里的默认站点

如果你是使用宝塔或 1Panel 的小伙伴，那就不能照搬原生思路直接去改主配置，因为当你在面板后台将某个站点设为“默认站点”时，面板程序会自动在该站点的 .conf 文件插入一行 listen 80 default_server;。此时如果你手动在主配置 nginx.conf 里又加了一个 listen 80 default_server;，同一个端口就会出现两个默认主机，那就必然会在语法测试阶段报错给你看。

nginx: [emerg] a duplicate default server for 0.0.0.0:80 in /.../www.tjsky.net.conf:3
nginx: configuration file test failed

这是因为宝塔、1Panel 这类面板底层的实现机制非常之粗暴：他没有按现代主流 Nginx 推荐的设计思路（用兜底全局文件）来实现，而是当你把站点 A 设置为默认站点时，直接打开你站点 A 的 Nginx 配置文件，硬生生在监听指令后面追加个 default_server。兼容性倒是挺好，但是也埋了个大坑。

面板环境下正确的操作姿势是：

1. 先通过面板解除默认站点

• 进入面板后台的「网站」列表，找到顶部的「高级设置」，再找到「默认站点」下拉菜单，将其切换为「未设置」或「无」。
• 此时面板程序会自动扫描并删除你业务站点（如 tjsky.net.conf）内部注入的 default_server 声明，将控制权还给底层。

2. 在全局主配置加入安全配置

• 打开面板的 Nginx 设置 → 「配置修改」（即编辑 /www/server/nginx/conf/nginx.conf 或者 /home/1panel/apps/openresty/openresty/conf/nginx.conf 之类的主配置文件路径）。
• 找到第一个 include /.../.../*.conf; 这一行。
• 就在这行的正上方，粘贴上面的兜底 server 代码块。
• 保存并执行 nginx -t 测试一下语法（大部分面板会在你保存配置时自动执行一次语法测试，确保你没把配置搞坏，不过嘛，最好手动执行一次，万一你的面板没帮你做语法测试呢）。
• 确定没问题了，执行 nginx -s reload 重载配置。

用 curl 验证一下拦截效果

新的配置生效后，在本地终端用 curl --resolve 模拟伪造域名发起探测测试：

curl -vk --resolve www1.example.com:443:机器的IP https://www1.example.com/

终端瞬间返回：

* schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed.)
* closing connection #0
curl: (35) schannel: next InitializeSecurityContext failed...

握手直接失败，连接秒断，那些使用奇奇怪怪的域名的访问再也进不来啦。从那之后，日志又清净得一天不到两位数了。