2026-10-30 00:26:17
#运维 #吐槽 我又双叒叕被自己的安全配置拦到服务器外边了😂
这次是自己的锅，最近扫描器泛滥，每天光试图访问/.user.ini的IP就有1000+个，于是呢，我就大手一挥，在前端机的Nginx加了4行配置
location = /.user.ini {
access_log /var/log/nginx/blocked.log combined;
return 444;
}
（实际location 是写了一个很复杂的正则表达式啦，写成上边这样是方便大家理解）
fail2ban会盯着这个blocked.log文件，把里面444的IP都给封掉（DROP），结果啊结果，我居然忘了把后端机的IP放到fail2ban的白名单里了。😂
于是后端机的IP就被前端机的fail2ban给封掉了，偏偏WordPres和里面的插件一些请求涉及自己请求自己时，用的是域名而不是本地回环请求，于是，很多请求就只能等网络20秒超时了。
这也是最近大家发现在博客里发评论后，需要等好久评论才能成功发出去的根本原因。
表层原因原因是缓存管理插件在出现新评论后需要刷新页面缓存，升级到最新的PHP版本后，他代码逻辑出了点问题，导致报错，偏偏他这里报错的逻辑里是请求的主站域名路径，而不是本地路径，还重试了1次（正好DROP是10+10秒超时）所以导致评论最少也需要20多秒才能显示出来。
总而言之：是我自己犯傻了
2026-10-28 18:09:57
#运维 #吐槽 宝塔免费防火墙，我现在是强烈建议你们删了，永远别用了。
我静默明文上传问题的文章是10点半发的，下午18点作者就更新了8.5版本。
你们猜他怎么修的？一共修了7行代码
6行是给http加了个s，1行是在静默上传用户文件的函数处加了一行注释# 云端查杀。需要上传到云端进行研判。
我… 我直接笑出猪叫好不。他这行注释是写给谁看的？！是写给作者的 Python 解释器看的吗？还是写给作者的良心看的？还是说宝塔面板可以智能到，发现这行注释，当用户在前端面板里点下“木马查杀”的时候，屏幕上会凭空弹出一行大字：“请注意，作者已经在源码里留了注释，即将把你的 PHP 源码送去云端研判”？！
以前不声不响静默上传，真掰扯，我也只能说有“未经授权的数据外传”；
作者现在加了这行注释，行为直接原地升华了，好嘛，变成了自欺欺人的“坦白从宽”。
然后，8.4 升 8.5 这种小数点后一位的升版，居然只是加个6个字母s和一行中文注释？？？纯粹就是傲慢与敷衍的结合体：“我看了到了报告，但我就是不修，我就偷偷上传你们的文件，我就是给黑客的攻击参数留下后门，我就是不修，你们免费的用户不配浪费我的时间去修复这些复杂问题”
2026-10-26 10:43:48
声明：本文基于本地源码审计与测试机全新安装后的实测记录整理。感谢大肥鱼（DeepSeek）、克劳德（Claude）、奥特曼（ChatGPT）、北美豆包（Gemini）各路 AI 评审员协助完成交叉代码复核。
这事儿得从上周四下午的一条读者留言说起：
【安全咨询】宝塔 Nginx 免费防火墙是否存在自动上传源码和凭据明文传输的问题？
……
静态检查发现以下行为：
send_baota2()在 WebShell 扫描匹配规则后，可能把完整文件内容上传至http://www.bt.cn/api/panel/btwaf_submit。……
目前仅有静态代码检查结果，没有证据表明存在恶意后门或已经发生实际数据泄露。
其实之前给宝塔 Nginx 免费防火墙 8.3 打补丁的时候，我确实扫到过这段代码，但当时根本没往深处细想，只当是某种云查杀样本库逻辑，加上我日常也不用面板自带的木马查杀，脑子里一下就划过去了。
今天下午看到这条评论，我翻出源码看了一眼这部分的代码逻辑
好家伙，居然是真的！而且确实走的是明文的 HTTP！！
我整个人都惊呆了：不是，这玩意私底下走 HTTP 的地方还有什么？！（我第一个反应：这不就是某输入法明文上传用户输入信息事件的翻版嘛）
简单肉眼过了一下代码，我当场差点从工位上蹦起来：
userInfo.json，把面板绑定的 access_key 和 uid 直接走明文 HTTP 发给云端？！make && make install 现场编译运行？！有点离谱了吧？！这哪是防火墙，这分明是个”特洛伊木马全家桶”啊！
整个插件本体加规则，足足有接近2万行，指望我一个人看是看不过来的（而且我这个纯业余的水平）于是索性直接把 宝塔 Nginx 免费防火墙 8.4（署名作者”民国三年一场雨”，官方发布页在这儿）的代码结构拉出来，把相关文件和脚本都扒出来，摇上大肥鱼（DeepSeek）、克劳德（Claude）、奥特曼（ChatGPT）、北美豆包（Gemini）四路 AI 一起做了一轮交叉全量静态审计。
看完最终整理出的4方审查报告，我脑瓜子嗡嗡的，忍不住先在博客里发了一条碎碎念说说给大伙儿预警一下。
周末忙完工作，我抽空在自己的测试机上全新安装了 宝塔 Nginx 免费防火墙 8.4，做了真机实测（走本地回环链路闭环测，不碰公网，我能构造出测试环境的都实测了）。
真机跑下来，推翻了部分 AI 过度推断的吓人言论，将 P0 级问题数量从 20 多个压缩到了 13 个，比如：
multipart 头就能绕过 POST 防护——2024 年之后云端下发的规则给后面加了独立的 post_data() 来兜底，实测 -F "id=1 union select..." 仍然是 403；但真实现状，也没好到哪里去。
几条逆天漏洞，在真机上全·部·复·现·了。
属于那种但凡稍微不那么业余的 Linux 运维或者 Web 开发，看完都会当场吸氧的神奇代码。
顺便说一句，这插件上一回就出过事，上次那个 undefined 的锅还没凉透呢。
http改成了HTTPS，从明文上传，变成了加密上传。该偷偷外传的还偷偷外传，该绕过的还能绕过，最他居然在8.5里偷偷上传用户文件的地方，加了一行注释# 云端查杀。需要上传到云端进行研判，有时间加注释，给自己免责，没时间在面板上写一句“Webshell扫描会自动静默上传一切疑似文件”。所以我只能理解为：插件的静默上传和漏洞绕过都是作者允许并故意设计的。触发条件：在面板点过一次「扫描木马」，且站点里有任意 .php 文件命中规则。
代码位置：free_waf_main.py:142-160（scan 函数）与 304-309（send_baota2 函数）
你在宝塔面板点”webshell查杀”，以为这只是在本地拿规则扫一遍文件？
天真了我的朋友，现实是：只要你服务器上的任何一个 .php 文件命中了规则，它就会在后台神不知鬼不觉地调用 self.send_baota2(file)。它既不需要你点击确认，更不会弹窗问你”是否上传样本分析”。
# free_waf_main.py 第 154-158 行
result = {}
result[file] = r
self.__webshell_data.append(result)
# 云端查杀。需要上传到云端进行研判 # <--- 8.5新增注释，但用户界面上完全没提示过会上传云端
self.send_baota2(file) # <--- 毫无征兆地直接把文件送走
那这个 send_baota2 到底准备干什么呢？咱们继续看代码：
# free_waf_main.py 第 304-309 行
def send_baota2(self, filename):
cloudUrl = 'http://www.bt.cn/api/panel/btwaf_submit' # <--- http明文上传
pdata = {
'codetxt': public.ReadFile(filename), # <--- 文件全文
'md5': self.read_file_md5(filename),
'type': '0',
'host_ip': public.GetLocalIp(),
'size': os.path.getsize(filename),
}
ret = public.httpPost(cloudUrl, pdata)
return True # <--- 永不检查结果，绝对是true
啥玩意，直接上传？？还是 http 链路？
为了抓包验证，我在测试机上写了一个只有 108 字节的测试文件，在里面故意留了一行假数据库密码：$db_pass = "SECRET_MARKER_DB_PASSWORD_42";。
实测截获的数据包如下：
url : http://www.bt.cn/api/panel/btwaf_submit
codetxt len : 108
codetxt : '<?php\n// WAF-SEC-AUDIT-MARKER-20261022-UNIQUE\n$db_pass = "SECRET_MARKER_DB_PASSW...'
host_ip : <面板请求的 Host 头>
md5 : f6e4c135a97d1616562346fd2edfdebc
108 字节的代码全文，连同里面的假数据库密码，一字不差地打包走明文 http:// 送出去了！
这个 host_ip 字段public.GetLocalIp() 在面板里取的是 request.headers.get('host')，也就是你访问面板时用的那个 Host 头（1.2.3.4:8888 之类）对于大部分人来说，就是你服务器的公网 IP。
更绝的是它的查杀规则写得极其宽泛："str_rot13"、base64_decode\($_、"eval(" 这些都能命中（rule.json 一共 52 条规则，含 eval 的 8 条、含 base64_decode 的 4 条、含 str_rot13 的 2 条）。就问你，随便找个现代 PHP 程序、WordPress 插件、甚至任何涉及加解密的程序，有几个能逃过这些规则？
这他喵的一命中，你的项目代码、里面的数据库链接信息，就在不经意间顺着明文 HTTP 裸奔到了外部。
其实下边的 send_baota()（311-323 行）更厉害：它接收的是一个服务器本地文件路径（不是上传的临时文件），代码只做了一次 os.path.exists() 检查，没有任何后缀或目录限制，/etc/shadow、panel/data/default.db、root/.ssh/id_rsa 都能当”待检样本”发出去（用户在面板里手动上传文件的链路）。也就是说，只要面板接口被调用，它就等价于”读本地任意文件并外传”。
触发条件：任何一次 POST 请求，只要参数名落进白名单，或参数名长度超过 64 字符。
代码位置：4.7.lua:1668-1678（continue_key 函数）
如果说上面的文件外传是内鬼行为，那这条过滤规则就是给黑客铺红毯。Nginx 免费防火墙 8.4 在检查 POST 请求参数时，很贴心地写了一个白名单：
（你在面板安装免费防火墙时，安装脚本会自动从宝塔的 CDN 拉取 free_waf_data.zip——这是防火墙的数据文件，4.7.lua 就是其中给 Nginx 用的脚本）
function continue_key(key)
if method ~='POST' then return true end
key = tostring(key)
if string.len(key) > 64 then return false end; -- <--- 参数名的长度超过 64 个字符
local keys = {"content","contents","body","msg","file","files","img","newcontent","message","subject","kw","srchtxt",""} -- <--- 参数名叫这些名字的话
for _,k in ipairs(keys)
do
if k == key then return false end; -- <--- 直接返回 false
end
return true;
end
啥意思呢：就是在处理 POST 请求时，只要参数名的长度超过 64 个字符，或者参数名叫 kw（搜索关键字）、body（正文）、content（内容）、msg（留言）、file 之类的名字……它就直接返回 false。
然后呢，你注意看啊，它在外层的处理逻辑里，可是只要返回 false，就让整个参数直接跳过检测的！
我在测试机上跑了几个测试：
id=<script>alert(1)</script> → 拦截（拦截了XSS，正常工作）[65个字符的长参数名]=union select 1,2,3 → 放行（绕过成功！）kw=union select 1,2,3 → 放行（绕过成功！）body=<script>alert(1)</script> → 放行（绕过成功！）同一个 XSS 载荷，参数名叫 id 就被 403 铁拳制裁，但是只需要改一个名字，咱们叫 kw 或者 body，防火墙就当场直接给放行了。
我琢磨了一下作者可能的心路历程：”啊啊啊啊，规则怎么总误伤常见的正常程序啊，有了，我直接把它们设置成白名单不就减少误拦截率了嘛。”
然后直接把最容易在XSS上出事的正文、留言、搜索框全设置为免检了？一次 WAF 绕过就这么简单，这 WAF 到底在防什么？
PS：而且他这白名单也没白到位，如果开着防火墙的 POST 检测，像是这篇文章这种正文代码块中有涉及加解密参数、外源加载命令的文章，反而会被他的POST检测拦截掉。攻击者能走白名单，管理自己反而被拦截是什么鬼啊。
config.json：一次响应就能把 WAF 配置写坏触发条件：网络遭遇中间人劫持，或宝塔的接口被投毒，返回了非预期结构的 JSON。
代码位置：free_waf_main.py:936-942（test_check_zhilist 函数）
在同步所谓”云端蜘蛛列表”时，插件代码写成了这样：
# free_waf_main.py 第 936-942 行
url = 'http://www.bt.cn/api/bt_waf/getSpiders'
data_list = json.loads(public.httpPost(url, data22, timeout=3))
if data_list:
for i22 in data_list:
path = "/www/server/free_waf/%s.json" % i22 # <--- 哪有这么写的？
if os.path.exists(path):
ret = json.loads(public.ReadFile(path))
localhost_json = list(set(ret).union(data_list[i22]))
public.WriteFile(path, json.dumps(localhost_json))
宝塔 Nginx 免费防火墙先从明文 HTTP 接口拉取一个字典，然后拿字典的 Key（i22）直接拼接文件路径。
作者大概非常笃定，返回的 Key 只会是 1、2 这种编号，所以代码里没有任何校验和限制！
如果链路上遭遇中间人劫持，或者远端接口返回一个 {"config": ["x"]}，会发生什么？
咱自己当自己的中间人实际测试一下呗，原本结构完好的 config.json 字典对象（{"open": true, "log": true, ...}）瞬间被变成了一个JSON 字符串数组：["retry_cycle", "log", "retry", "open", "x", ...]。
注意，它此时还是一个合法的 JSON。语法完全正确，json.decode 照样能解析。问题出在类型上——现在解析出来的是个数组，不是字典了。配置结构一旦被破坏，Lua 在加载时读到的 config['open'] 就是 nil。
紧接着，4.7.lua:2054 的逻辑被触发：
if not config['open'] then return false end
WAF 就不再执行后面那一整套检测了。
那到底会怎样？开始我以为会直接让WAF失效，实测了一下，解决比”直接让WAF失”还更麻烦：
| 阶段 | 操作 | 实测结果 |
|---|---|---|
| ① 文件改坏了，不 reload |
config.json 变成数组 |
WAF 完全不受影响，SQLi 照样 403。因为 config 是 init_by_lua 阶段读的，只改文件不会触发重载 |
② 执行 nginx -s reload
|
触发新 worker | 40 次 SQLi 请求，35 次放行、5 次 403。新旧 worker 的 Lua VM 并存，请求落到哪个 worker，结果就不同 |
| ③ 继续访问 | — | 出现站点返回 000（连接失败），nginx 重启后恢复 |
也就是说：它不是”立刻就让WAF关了”，是”下次你改Nginx配置或打开防火墙页面改了东西关闭后开始漏拦截，而且漏得很随机”。
这个”不确定”本身就是灾难：同一个风险，有时拦有时放，看日志定位原因的难度大幅提升。
再说面板这边的情况，宝塔 Nginx 免费防火墙的界面会变成这样的：防火墙已经开启的绿色开关还在 + 一个”请求过程发现错误!”的弹窗 + 拦截统计和安全天数全空。所以你可能怀疑防火墙面板坏了，但可能不会怀疑防火墙已经不工作了。
?btwaf=nil 秒破：白送 1 小时免检金牌触发条件：站点开启了「CC 增强模式」（cc.increase），触发验证码后，在 URL 后面挂一个 ?btwaf=nil。
代码位置：4.7.lua:573-582（security_verification 函数）
这里得先补一个前提，这个「CC 增强模式」默认是关闭的，在默认配置下根本不会被激活：这部分代理代码cc2() 的第一行是 if not site_config[server_name]['cc']['increase'] then return false end，而全新安装的 site.json 里，站点的 cc 只有 open / cycle / limit / endtime 四个可用键值，压根没有 increase 字段。我是手动加了 "increase": true 再 reload，才让这段逻辑跑起来的。（属于残留的无用逻辑，但可以看出作者那时候的代码水平）
前提说完了，我们来看实际代码：
function security_verification()
if uri_request_args['btwaf'] then
vn3,_ = ngx.shared.free_waf:get(ip)
if tostring(vn3) == uri_request_args['btwaf'] then -- <--- 这就直接比了？
ngx.shared.free_waf:delete(ip)
ngx.shared.free_waf:set(ip,666,3600) -- <--- 贴心的1小时免检
return false
end
end
注意看第 4 行：它在拿到缓存值 vn3 后，它完全没有判断 vn3 ~= nil，而是直接把它转成字符串去跟 URL 传进来的 ?btwaf= 比较！
蛤？在 Lua 里，tostring(nil) 的返回值正是字符串 "nil" 好不！
在测试机实测：触发了 CC 防护验证码时，只要在 URL 后面挂上 ?btwaf=nil，校验当场通过！
实测记录（对照组很关键）：
| 请求 | 结果 |
|---|---|
127.0.0.2 首次触发 + ?btwaf=nil
|
404 放行 |
127.0.0.2 第二次（不带参数） |
404，因为 666 还在生效 |
127.0.0.3 首次（对照） |
弹验证码 4 + 18 = ?
|
127.0.0.5 首次（对照） |
弹验证码 17 + 17 = ?
|
通过之后，代码下一行还贴心地附赠一道护身符：ngx.shared.free_waf:set(ip, 666, 3600)。只要拿到这个 666 标记，接下来整整 1 小时内，该 IP 会被视为受信任访客，跳过所有 CC 频率检测。
所以刷量脚本连识别验证码的步骤都省了，直接在请求后缀挂上 ?btwaf=nil 就能畅行无阻。当然前提是你手动去把这个”增强模式”打开了——默认配置下这段逻辑压根不执行，我只是想吐槽下这个代码写的真的是有点毛糙。
真要防刷流，还是去看对抗刷流攻击的那套 Nginx 打法吧，至少规则是自己写的、自己看得懂。
触发条件：管理员打开防火墙插件设置面板，触发 get_total_all 逻辑。getSpiders 受 session 限制每天一次，addSpider 则是每次都会跑。
代码位置：free_waf_main.py:929-946, 978-983
如果你在看上边第 3 个问题时稍微往上看几行就会发现一个更加神奇的逻辑：
# free_waf_main.py 第 929-946 行
def test_check_zhilist(self, get):
try:
userInfo = json.loads(public.ReadFile('/www/server/panel/data/userInfo.json'))
data22 = {"access_key": userInfo['access_key'], "uid": userInfo['uid']}
url = 'http://www.bt.cn/api/bt_waf/getSpiders' # <--- http明文上传
data_list = json.loads(public.httpPost(url, data22, timeout=3))
# free_waf_main.py 第 978-983 行
userInfo = json.loads(public.ReadFile('/www/server/panel/data/userInfo.json'))
data22 = {"type": i, "ip_list": json.dumps(tt),"access_key": userInfo['access_key'], "uid": userInfo['uid']}
url='http://www.bt.cn/api/bt_waf/addSpider' # <--- 还是http明文上传
if len(tt)>=1:
public.httpPost(url, data22)
public.WriteFile('/www/server/free_waf/zhizhu'+i+'.json',"")
session_id = self.__get_md5("free_waf_test" + time.strftime('%Y-%m-%d'))
if not session_id in session:
self.test_check_zhilist(None)
getSpiders 这条每个管理员每天只会触发一次；而下面的 addSpider 部分，只要 zhizhu*.json 里有内容，每次打开面板都会触发。
不管是每天一次还是每次吧，咱们的结论不会变：它会把 access_key 和 uid 装进 JSON，直接通过明文 HTTP 发送给了远端接口（http://www.bt.cn/api/bt_waf/getSpiders 和 addSpider）。
这东西发给宝塔服务器本身的行为是没问题的，这属于插件的鉴权措施，宝塔面板里的很多收费插件也有类似的逻辑，来验证你是否有启用插件的权限。
但问题是，宝塔 Nginx 免费防火墙用的是 HTTP，是明文不加密的，中间链路随便搞点劫持嗅探，你的宝塔官方账号凭据就直接拱手送人了。
而且这事还有下半场：addSpider 拿回来的那个”蜘蛛 IP 列表”会被写进 zhizhu*.json，而 4.7.lua 的 zhizu_chekc() 会把这些 IP 直接塞进 ngx.shared.spider 全量放行。HTTP 明文通道是能被中间人劫持注入的，就等于能远程往防火墙的”免检名单”里塞人——这其实比凭据泄露本身更吓人。
触发条件：系统里缺 /usr/local/lib/lua/5.1/cjson.so，然后你打开一次插件设置页。
代码位置：free_waf_main.py:1163-1188（__check_cjson 函数）
# free_waf_main.py:1163行-1188行
def __check_cjson(self):
cjson = '/usr/local/lib/lua/5.1/cjson.so'
if os.path.exists(cjson):
if os.path.exists('/usr/lib64/lua/5.1'):
if not os.path.exists('/usr/lib64/lua/5.1/cjson.so'):
public.ExecShell("ln -sf /usr/local/lib/lua/5.1/cjson.so /usr/lib64/lua/5.1/cjson.so");
if os.path.exists('/usr/lib/lua/5.1'):
if not os.path.exists('/usr/lib/lua/5.1/cjson.so'):
public.ExecShell("ln -sf /usr/local/lib/lua/5.1/cjson.so /usr/lib/lua/5.1/cjson.so");
return True
c = '''wget -O lua-cjson-2.1.0.tar.gz http://download.bt.cn/install/src/lua-cjson-2.1.0.tar.gz -T 20
tar xvf lua-cjson-2.1.0.tar.gz
rm -f lua-cjson-2.1.0.tar.gz
cd lua-cjson-2.1.0
make
make install
cd ..
rm -rf lua-cjson-2.1.0
ln -sf /usr/local/lib/lua/5.1/cjson.so /usr/lib64/lua/5.1/cjson.so
ln -sf /usr/local/lib/lua/5.1/cjson.so /usr/lib/lua/5.1/cjson.so
/etc/init.d/nginx reload
'''
public.writeFile('/root/install_cjson.sh', c) # <--- 脚本内容里含 http 下载
public.ExecShell('cd /root && bash install_cjson.sh') # <--- 不校检直接root权限运行了
return True
明明安装包里已经带了编译好的 cjson.so（install.sh:109-111 会把它复制到 /usr/local/lib/lua/5.1/、/usr/lib64/lua/5.1/、/usr/lib/lua/5.1/），但偏偏作者以防万一写了一个校验函数：每次打开插件首页（get_total_all() 第一行就是它），如果发现系统路径缺了文件，就在 /root 下生成一个 Shell 脚本，通过明文 http:// 下载源码包，并以 root 权限就地执行 make && make install。
不是，这是什么胆子啊，用 HTTP 拉取云端文件，然后看都不看就写入本地文件，直接用 root 权限编译并执行了？
到了 P1 级别，看似是一些”虽然存在但不太好直接利用”的问题，但这几个逻辑依然让人哭笑不得：
hackcnm 木马免杀后门代码位置：free_waf_main.py:120-140
在遍历站点文件准备查杀木马时，作者留下了这样一段神仙逻辑：
# free_waf_main.py 第 133-140 行
def getdir_list(self, get):
path = get.path
if os.path.exists(path):
pc = 'hackcnm' # <--- 不是，这啥玩意？
rs = self.getdir(path, pc)
return rs
而在递归查询站点根目录搜索文件时：
elif str(l.lower())[-4:] == '.php' and str(dir + '/' + l).find(pc) == -1:
lis.append(dir + '/' + l)
啥？只要路径或者文件名里包含 hackcnm，Webshell 查杀就直接跳过该文件！？
所以，只要把 Webshell 命名为 hackcnm.php，或者扔在 hackcnm/ 目录下，在木马查杀里就能享受到永久免检待遇了？？？
代码位置：4.7.lua:1953-2026, 2095-2103
宝塔 Nginx 免费防火墙为了不误伤搜索引擎蜘蛛，设计了 PTR 反查机制，这确实是个很好的机制。但是，但是啊，在匹配域名时，使用的是无头无尾的模糊匹配，比如对百度的：string.find(ptrdname, "baidu")。只要含有baidu就行
而且更离谱的是，一旦请求被判定为合法的搜索引擎蜘蛛，WAF 在 run_btwaf() 里会把完整检测步骤里 18 个函数中的 14 个直接跳过：drop()（黑名单）、drop_abroad()（海外阻断）、cc() / cc2()（CC 防护）、user_agent()（UA检测）、url()（GET防护）、cookie()（cookie检测）、ThinkPHP_RCE5_0_23()、ThinkPHP_3_log()、scan_black()，以及站点级 URL 检测——只留下 args()、post()、post_data()、post_data_chekc() 四个参数级检测。
还记得前边「P0-2」是什么问题不？「处理 POST 请求时，只要参数名的长度超过 64 个字符，或者参数名叫 kw（搜索关键字）、body（正文）、content（内容）、msg（留言）、file 之类的名字，POST检测就可以跳过」
所以只要攻击者给自己的一台 VPS 配个类似 baidu.攻击者自己的域名.com 的 PTR 记录，再带上百度蜘蛛的 UA 发起请求，这套防火墙的防护模块就只剩args()对他有效了。
百度起码是匹配的 baidu，你猜对 360 爬虫它匹配的是什么？是 0，是数字 0 啊！！
123-45-60-78.static.isp.com 这种默认 rDNS 里带个 0 太常见了，虽然不能说人人都能变成 360 的蜘蛛，但这个几率真的不低，毕竟为了格式补位，PTR 里含有0的几率实在是太高了。
min_route 零鉴权一键清空黑名单代码位置：4.7.lua:1777-1786
Lua 里开了一个本地管理路由：
function min_route()
if ngx.var.remote_addr ~= '127.0.0.1' then return false end
if uri == '/get_btwaf_drop_ip' then
return_message(200,get_btwaf_drop_ip())
elseif uri == '/remove_btwaf_drop_ip' then
return_message(200,remove_btwaf_drop_ip())
elseif uri == '/clean_btwaf_drop_ip' then
return_message(200,clean_btwaf_drop_ip())
end
end
它只判断 remote_addr == '127.0.0.1'，完全没有任何 Token 校验……我该说点什么好呢。
当然这个洞的利用要分场景，不能一概而论：
remote_addr 就是真实客户端 IP，外部直接打 GET /clean_btwaf_drop_ip 是打不进来的；remote_addr 全是 127.0.0.1，这时候一打一个准；curl、图片代理、webhook 回调、被拿下的低权限进程），只要能访问 http://127.0.0.1/，就能把封禁名单清空。也就是说，它用”来源地址”当”身份凭证”，把”本机来源”等同于”可信来源”。
如果说上面的漏洞是安全意识淡薄，那 P2 级问题就是纯正的软件工程事故：
4.7.lua 里的 run_btwaf() 定义了十几个核心变量（ip、uri、server_name、request_header），全都没加 local 声明！ 这些变量统统挂在全局 _G 表里。当系统发起异步 DNS 查询协程挂起时，只要有并发请求进来，全局变量瞬间就被后一个请求覆盖。你的 IP、我的 URL 混在同一个 Worker 里，误封、漏封全看运气。（此条未做实测——测试需要足够的并发测试资源）
【磁盘】每次拦截无锁全量读写 total.json：每次触发拦截，都要把整个统计文件全量重写一遍。
| 场景 | 请求数 |
total 增量 |
磁盘写入 |
|---|---|---|---|
| 正常请求（404） | 200 | 0 | 220 KB |
| 拦截请求（403），串行 | 200 | +200（100%） | 1.18 MB |
| 拦截请求（403），并发 | 200 | +120（60%） | — |
说人话就是，会漏统计数据，多个 Worker 同时并行读-改-写，后写的会直接覆盖先写的。从而使得统计不可信，你看着面板上那个”已拦截 XXX 次”，实际可能少了一半。
.+）的畸形正则去跑匹配，虽然不能下一定会出事的结论，但确实存在可 ReDoS 攻击的点位。
【证书】下载扫描结果时关闭了证书校验： 上传文件给百度的接口检测webshell时走 HTTPS，这时候curl 默认会验证证书；但是”取扫描结果”时，却又特意把证书验证给关了。这导致中间人可以伪造返回的扫描结果：把真 webshell 说成”未查出风险”，或者把正常文件说成木马。
【白名单】你以为你开了禁止国外 IP 就真进不来了？ 其实作者偷偷写了 5 个硬编码的白名单 IP：91.199.212.132/133/148/151/176。我查了一下，91.199.212.0/24 归属 AS48447 SECTIGO（英国，2008 年 RIPE 分配），是 CA 机构做 AutoSSL 域名控制验证的节点——所以这5个IP不是后门，防火墙之所以给白名单，是怕你开了”禁止海外访问”后，面板的证书续签功能炸了。但怎么保证这 5 个 IP 永远不会变呢？IP 一回收重分配，新持有者就自动继承了这份免检权。
【XSS】存在反射 XSS。 位于站点访客看到的 403 错误页，站长自己倒是没事
【权限】试图规则库全局可写：代码里是 chmod -R 666 /www/server/free_waf/rule 和 chmod 777 /www/wwwlogs/free_waf_log，归属 www:www。不过实测部署后目录是 drwx------ www:www（700）、文件 -rwx------——幸好宝塔的兜底目录策略把脚本意图覆盖掉了。
【写文件】任意文件写入 JSON：s_Name / ruleName 未校验直接拼 rule/xxx.json，攻击者可以玩路径穿越 ../ 穿越，以 root 向任意可写位置落 JSON，配置投毒好帮手啊。
【启动判断】神一样的判断 Nginx 成功启动的方式：判断 Nginx 成功居然是检测 netstat 输出中有没有出现字符串 80（netstat -nltp | grep nginx | grep 80 | wc -l）。这导致两个效果：
is_status 判 0，安装脚本会误以为把 Nginx 搞炸了，会走安装失败清理流程——删掉 free_waf.conf、重启 nginx、删掉 /www/server/panel/plugin/free_waf 这个插件目录（脚本自己也在里面），然后提示”安装失败”。注意它没删 /www/server/free_waf 主目录，会有残留文件。（把安装成功判定为安装失败）netstat 输出里还有 PID 字段呢，万一 PID 含 80（如 18042/nginx），脚本会因为匹配到 80 而判定”安装完成”，从 PID 的分布概率上来说误判率 4~5% 吧（把安装失败判定为安装成功）宝塔 Nginx 免费防火墙的普及率有多高，就不用我说了吧，我感觉基本只要在用这个面板的都会装一个。下面这份卸载清单，装过的都建议照着走一遍。
先花 30 秒思考一下三个问题：
/www/server/panel/plugin/free_waf/webshell.log 这个文件存在吗？存在且有内容 = 确认已经静默发出去了三条里中了一条，按下面的步骤操作，先确保自己的机器别成为筛子：
打开宝塔面板 → 软件商店 → 已安装，找到这个免费防火墙，停用并卸载。随后登录终端，先逐行确认下面的路径没写错——rm -rf 没有回收站，手一抖就是运维事故了——再执行清理：
# 检查并清理残留规则与运行目录（不放心就去面板的文件管理里手动删）
rm -rf /www/server/free_waf
rm -rf /www/server/panel/plugin/free_waf
rm -f /root/install_cjson.sh
# 检查 Nginx 配置中是否已解除挂载（确认没有残留 access_by_lua_file）
grep -rn "free_waf" /www/server/panel/vhost/nginx/
nginx -t && nginx -s reload
由于该插件会后台通过明文 HTTP 发送你的 userInfo.json，强烈建议登录宝塔官方后台（bt.cn），进入用户中心：
如果你之前在面板里点过”木马查杀”，去看一下这个查杀日志：
cat /www/server/panel/plugin/free_waf/webshell.log
凡是在这个日志里留下过名字的 .php 文件，都应当视为文件已经明文上传。（严格说 send_baota2 若因网络问题发送失败，文件未必被发出去过，但你没有证据证明它没送达，所以按”已泄露”处理。）
如果里面包含你的生产数据库配置文件（例如包含数据库密码、Redis 密码、第三方支付 Secret），请立刻全部改密码！
如果你需要基础的防 CC 和简单防护：
root:root 644，决不能图省事给它挂上可写权限。
免费的往往才是最贵的。这话我上次聊那个藏了 13 年的 Nginx 上古漏洞时就说过一遍，这次又应验了。
很多个人站长用宝塔，图的就是个开箱即用、省心省事。遇到”免费版 Nginx 防火墙”，很多人想都不想就装上去了，以为给自己服务器雇了个保镖。
谁能想到，这哪是保镖啊？
continue_key 只要参数名对上就直接免检放行）；send_baota2 全自动静默上传）；0的面具，它就主动递上一杯茶，顺手给发了一张 VIP 通行证（判定为360的爬虫，免检）。
审查报告的全文我就不发了，我就列个数字：完整报告里是 P0 级 13 个、P1 级 16 个、P2 级 12 个，这里只挑了最能说明问题的几条。
从本质上来说，宝塔 Nginx 免费防火墙这些漏洞，看起来都不像是恶意埋的雷（不存在故意制造漏洞或后门的行为），但作者为了使用方便、兼容性和不误判，留下来太多可以绕过防火墙的地方，说实话这东西要是自己写了给自己用的倒也算了，但是被大家这样广泛在生产环境使用，会给用户一种虚假的安全感。
不要建立：开源=安全、隐私的错误思想，更可能的情况是，确实开源了，但有技术的人不会用这个项目，没技术的看不懂这个项目，漏洞和问题代码就这么明晃晃的放在那里，很多年都无人发现。
以及宝塔面板因此收集了这么多年的用户文件，就算用户到宝塔的 HTTP 链路从来没有被劫持过，文件真的只发给了宝塔面板的官方接口http://www.bt.cn/api/panel/btwaf_submit，宝塔自身是否妥善保存了这些被自动上传的“待检测”文件呢？
虽然作者免费这么多年，并且坚持无偿更新的好心要领，但是面对这套代码，我除了苦笑，也就只剩那句老话了：
毁灭吧，赶紧的，累了。
2026-10-22 18:38:40
这真的是防火墙吗？论宝塔 Nginx 免费防火墙8.3/ 8.4 的代码写得有多离谱：
等我明天有空，再细看看代码（以上都是纯看代码得出的结论，没经过实际环境验证，但应该没差很多…吧…），给大家好好掰扯掰扯这里边的门道，我之前知道这玩意儿写得很粗糙，但没想到居然如此炸裂。
你以为你是给自己的服务器请了一个保安，其实这保安搞不好才是服务器里最大的威胁。
2026-10-21 17:22:15
麻了，毁灭吧，赶紧的……感觉自己现在越来越不像个写博客的，倒像个天天打补丁的业余网管。Linux 刚消停两天，Nginx 刚升完没多久，甚至前天还被某插件的供应链攻击连累，服务器被植入远控全站回档了十几个小时（还好做了全盘镜像），这回轮到 PHP 爆雷了。
今天下午刷群消息和 RSS 阅读器，满屏都在刷 PHP 官方刚发的紧急安全预警：PHP 从 5.4 版本开始，存在两个底层核心的远程代码执行（RCE）漏洞，CVSS v4.0 评分高达 9.2 分。
给没看到消息的各位博友和读者们梳理一下现在的状况：
PHP2Shell）都流出来了。这意味着今晚 10 点官方补丁一发，随便一个人拿到补丁代码让 AI 做个逆向，搞不好 5 分钟就搞出扫描器原型，15分钟后全网无差别扫描脚本就该满天飞了。PHP 官方昨天半夜紧急发出来的原话是这样的：
The PHP security team would like to give advance notice of an upcoming security release scheduled for Wednesday, October 21, 2026 at 14:00 UTC. This release will address two critical vulnerabilities, both rated CVSS v4.0 9.2. Full details, affected versions, and the fixed versions will be published with the release. Should details of either vulnerability become public, or should evidence of active exploitation appear in the wild, the release may be brought forward.
翻译总结一下：
就是 PHP 核心底层出了两个编号为 CVE-2026-109618 和 CVE-2026-109619 的超高危远程代码执行（RCE）漏洞，满分 10 分它俩拿了 9.2 分。
蛋疼的地方在于，根据目前安全机构（watchTowr 和 Sansec）确认的泄露消息，这俩漏洞应该是属于 PHP 底层核心逻辑的问题，疑似从 PHP 5.4.0 开始往后的版本全军覆没，而且看他们的语气大概率也不需要什么太苛刻的前置条件，默认安装配置就能触发。
千万别觉得“小破站没几个人看，黑客看不上我”——自动化扫描程序可不管你是大厂还是个人博客，只要扫到 IP 返回的是 PHP 响应（甚至不管你用的是什么网站程序，哪怕只放了个探针），上来就先打一发攻击试试，打穿了直接往机器里塞挖矿木马或者拿去当肉鸡。
先登服务器敲个命令看下自己的 PHP 版本：
php -v
当然，如果机器上装了多版本 PHP（面板的常见操作），命令行是不准的，需要看你网站实际挂载的 php-fpm 是哪个版本：
ps aux | grep php-fpm
session.upload_progress.enabled 设为 0 能防住吗？各大技术群和推特上都在疯传去 php.ini 里把 session.upload_progress.enabled 改成 0（或者 Off）就可以防住这次的漏洞，也就是所谓的“一行配置免打补丁”。
这个我在群里和一些大佬交流了一下，结论是：这招挡不住所有攻击，只能帮你挡一半
因为这次爆出来的是两个漏洞
session.upload_progress（泄露出来的那份 PHP2Shell 脚本走的就是这条路）PHP 底层的 multipart 请求解析器。把 upload_progress 关了，甚至把 file_uploads = Off 关了（彻底禁止文件上传），但是 PHP 在收到请求时，按照设计必然需要先解析 multipart 请求体，导致触发第二条攻击路径。PHP 的核心开发者 Gina Peter Banyard 也说了
“The only thing I can say is that the only mitigation is patching/upgrading PHP. I sadly know too much.”
我唯一能说的是，唯一的缓解办法就是打补丁/升级 PHP。很遗憾我知道得太多了。
影响是这几个小时里你自己没法在博客后台传图片和更新插件了，不过下边这些都是网传措施，有说有效，也有说没效的，不过能确定的一条是 session.upload_progress.enabled = 0确实已经被宣布无效化了。
session.upload_progress.enabled = 0 先改上虽然防不住第二个攻击路径，但起码能先拦住一些脚本是不，起码先把脚本小子防住
session.upload_progress.enabled，把后面的 On 或 1 都改成 0，保存并重载配置。session.upload_progress.enabled = 0，保存并重载配置。multipart 请求既然网传的两条攻击路径都必须通过发送 multipart/form-data 格式的请求体来触发，那最直接的缓解办法就是：在请求到答 PHP-FPM 之前，让 Nginx 直接干死所有带 multipart 头的请求！
在你站点的 Nginx 主配置文件的 server {} 块里塞入这三行：
if ($http_content_type ~* "multipart") {
return 403;
}
宝塔面板可以在这里配置：
/www/server/nginx/conf/pathinfo.conf文件
把前边三行代码写在，文件的第一行，大概是这样的感觉
if ($http_content_type ~* "multipart") {
return 403;
}
set $real_script_name $fastcgi_script_name;
if ($fastcgi_script_name ~ "^(.+?\.php)(/.+)$") {
set $real_script_name $1;
set $path_info $2;
}
fastcgi_param SCRIPT_FILENAME $document_root$real_script_name;
fastcgi_param SCRIPT_NAME $real_script_name;
fastcgi_param PATH_INFO $path_info;
curl -i -F "test=1" https://网站域名/index.php 如果返回是HTTP/1.1 403 Forbidden 就是缓解措施生效了等今晚 22:00 官方发版后，第一时间把 PHP 升到 8.2 ~ 8.5 各自最新的小版本（具体版本号以今晚发布的为准）。
具体怎么升，要看你当初是怎么装的 PHP 了：
如果是 Ubuntu / Debian 用 ondrej/php 源，或者 Rocky / AlmaLinux 用 Remi 源装的，等源同步之后直接更新就行（虽然 Debian 系的系统一般默认开了无人值守自动安全更新，每天会自动帮你检查并安装 2 次安全补丁，但今晚这情况还是强烈建议手动敲一下，尤其是用服务商自带镜像的，鬼知道他们怎么配置的）：
# Ubuntu / Debian
sudo apt update && sudo apt --only-upgrade install php8.2-* -y # 把这里 8.2 换成你自己的版本
sudo systemctl restart php8.2-fpm
# Rocky / Alma / RHEL
sudo dnf upgrade --security php\* -y
sudo systemctl restart php-fpm
独立博客圈里用 1P 和宝塔的博友应该占一大半：
1Panel：直接去「应用商店」-「已安装」里检查更新，拉取最新镜像重装容器就行。
很多人会选的“极速安装”往往要等面板官方打包，起码会比源码慢个把小时；如果你服务器性能好（满血 2 核及以上的），着急的话建议直接切“编译安装”更新。
因为我已经很久很久都不用这种一键包了，下边的命令不一定百分百对，仅供参考：
# 先进入你的 LNMP 安装包目录
cd /root/lnmp2.0/
# 运行升级脚本，指定升级目标为 php
sudo ./upgrade.sh php
# 脚本就会问你要升到哪个版本，去官网看一眼今晚刚发的版本号填进去就行
肯定有不少博友还在死守 PHP 7.4 和 5.6 的，懂得都懂——手里有些祖传的 WordPress 主题、老插件，或者一些年久失修的开源小项目，一升 PHP 8.2 直接满屏 Fatal Error 白屏给你看。
如果确实没法立刻升级到 PHP 8.2+，那只能想办法在外部把攻击路径给堵死了：
先备份一下服务器，做好最坏的打算，然后把前边临时保命的两招缓解措施先部署上。
面板党其实可以趁现在还没到 10 点，在软件商店里先装一个 PHP 8.2 或 8.3 备用。然后把网站的 PHP 版本切过去试一下。现在的 WordPress 核心和主流插件其实早就兼容 PHP 8.2 了，万一能跑通，今晚就能直接打上官方补丁，一劳永逸是不。万一不行，炸了，切回来就好了。
根据安全公司 Sansec 的说法，由于漏洞出在 PHP 底层解析阶段，还没走到你网站的业务代码（比如 WordPress 的防护插件 Wordfence）那一步，攻击就已经触发了，所以指望网站后台的安全插件拦住它是没戏的。
看起来唯一有戏能拦的地方就是前端反代和 WAF——这招也叫“WAF 虚拟补丁”，漏洞修不了就先把攻击流量挡在门外。今晚 10 点漏洞细节一公布，像 Cloudflare、阿里云、腾讯云这种带 WAF 的 CDN，雷池、南墙这些商业 WAF，宝塔、1Panel 面板内置的 WAF，这些厂商的 WAF 肯定会连夜更新拦截规则。先开起来，或者盯紧今晚社区放出来的拦截正则，扔到前端的防火墙里，先把问题请求拦在 PHP-FPM 门外。
如果你用的是 Ubuntu Pro（开启了 ESM）或者 Debian LTS 的系统原生 PHP 包（比如 Debian 自带的旧版 PHP），这种重大安全漏洞，发行版维护团队大概率会把这次的安全补丁移植回旧版本 PHP 里。这几天勤快点跑 apt update && apt upgrade，看系统源有没有推送安全更新包。
要是你既没套 CDN/WAF、用的是早就停更的 PHP 7.x、跑的又是裸奔在公网上的玩具站点，今晚 10 点又不想熬夜运维……
那不如：今晚 10 点前直接把 php-fpm 停了，或者干脆关机睡大觉！
管他呢，我就没 PHP，你能攻击个啥。等明天一觉睡醒，再看安全圈放出来的具体触发条件（比如是不是特定模块、特定运行模式才会触发）以及 Nginx 层的通用屏蔽规则，配好防护再启动 PHP。毕竟停机一晚上最多掉点爬虫流量，真要是被脚本刷穿拿去挖矿或者删库，那才叫纯纯的无妄之灾。
（反正我是打算这么办，虽然所谓的网传缓解措施也做了，但是反正我是前后端动静分离的架构，PHP 停了，只是无法评论和外链跳转罢了，不影响看文章和爬虫访问。 「只要我没有PHP，针对PHP的攻击就奈何不了我」）
最后还是忍不住吐槽一句：原本今晚打算早点休息的，结果半路杀出这么个 9.2 分的王炸级漏洞，看来今晚 10 点全球起码有一半的站长和运维得守在电脑前抢着更新服务器了（合理怀疑到时候各大软件源和面板更新节点又要被挤爆卡死咯😂）。
等今晚 22:00 官方具体细节和修复版本号放出来之后，如果有什么可以在 Nginx 配置文件里直接“一行代码阻断漏洞”的奇技淫巧，我再在本文更新补充。各位站长先赶紧去检查一下自家的机器吧！
刚才收到邮件，一向佛系的 CloudCone 居然宣布要主动强制给大家打 PHP 补丁
一些博客貌似开始关机了，开始访问不到了
PHP准时放出补丁，目前最新安全版本是
php_82=‘8.2.35’
php_83=‘8.3.36’
php_84=‘8.4.27’
php_85=‘8.5.12’
好消息：缓解措施被 cloudflare 证明有效，目前观测到的全部攻击流量都集中在 multipart 请求。只要你前端 web 服务器不是Apache + mod_php模式，基本就没事，被打了基本只会让 PHP 进程崩溃。
Ubuntu / Debian 已经做好了 PHP 补丁，直接sudo apt update && sudo apt upgrade就行，甚至连 Ubuntu 20 都可以通过 Ubuntu Pro（ESM）获得 PHP 官方都没提供的 PHP 7.4 的补丁……
宝塔面板的 PHP 也更新了，不过宝塔如果你死活刷不出来新版本，你需要先看下/www/server/panel/install/php.sh里面是否列的版本号是不是最新版，如果不是，手动改成最新版号，保存。然后终端里执行 bash /www/server/panel/install/php.sh update 8.2（8.2换成你实际要的版本），直接调用脚本安装（面板其实就是帮你执行的这个脚本罢了）
本文 毁灭吧，赶紧的：PHP 爆出 9.2 分”上古”RCE 漏洞，大家今晚 10 点熬夜打补丁吧 最初发表于 秋风于渭水。
2026-10-18 15:12:30
十一假期的最后一天，我习惯性翻看服务器状态，打开 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 的日志，发现这个扫描器还挺有意思的，怎么说呢，非常“标准”且“智能”。
/?feed=rss2 和 /wp-links-opml.php，随后通过 /wp-json/wp/v2/pages 枚举接口，确认了这里是 WordPress 环境。
模板盲猜：开始以每秒数次的频率轮番扫描 JieStyle-Two-2.6.2 和 spacious 等主流主题目录下的常见模板文件。因触发了 404 阈值，被 Wordfence 判定为恶意扫描并封禁了 IP，给他回报了一堆 503。
致命一击：眼见直接访问的目录遍历无果，他开始尝试经典的远程代码执行 Payload：
GET /?pagename=templates%252f...%252fusr%252flocal%252flib%252fphp%252fpearcmd
配合空 POST，企图通过双重 URL 编码绕过目录穿越限制，利用系统内的 pearcmd.php 写入后门。
这时候后端机 Nginx 上的安全规则识别出了这个如此典型的 RCE，直接以 444 切断了连接，并通过 fail2ban 通知前后端都将他的 IP 彻底拉黑。但我心中巨大的问号还是没能解决：这个扫描器是怎么拿着毫不相干的假域名，一路摸进我的 WordPress 核心并让 Wordfence 记录下日志的？
仔细比对 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 不匹配的请求，但在这里拦截的话就太晚了。（而且这个规则因为和我其他的安全规则冲突，目前处于被注释掉、无法生效的状态，这才是他能够使用随便写的域名进行访问的根本原因）
很多人在宝塔/1Panel 建站时，都会看到官方的一句经典提示：
“设置默认站点后，所有未绑定的域名和 IP 都被定向到默认站点，可有效防止恶意解析。”
这句话放在十年前纯明文 HTTP（80 端口）时代可能确实是一条真理。黑客如果把做灰产的域名恶意 A 记录解析到你的 IP 去积累域名权重，或者把未备案域名解析到已备案域名的服务器 IP 上，访问这些未绑定域名的访客会被重定向到默认站，你的主站内容也就不至于被镜像白嫖。
但在全站 HTTPS 时代，这个逻辑就彻底失效了。
在 HTTPS 的通信规则下：TLS 握手必须先于 HTTP 传输。
当扫描器带着不存在的 www1.example.com 发送第一个 SSL 握手请求时，还没有到 HTTP 协议阶段，Nginx 根本拿不到 Host 报头，但为了完成连接，它也必须先挑选一张证书交出去完成握手流程。
如果把主站当成了默认站点，或者直接在主站点配置的 server 块内部写 if ($host)，就会引发两个问题：
tjsky.net。在各种网络空间搜索引擎面前，源站 IP 瞬间透明化。
密钥协商的性能损失：TLS 握手中的密钥协商（ECDHE 等）是属于消耗 CPU 的非对称加密计算，虽然这玩意每次的性能消耗倒也不能说有多大。但在高频并发的扫描器访问下，每一个访问 VPS 都要掏出算力陪他算完一整套数学题，然后才在 HTTP 应用层把连接断开，属于虽然小偷还没进家门，但已经敲了一次门的情况。
这种最基础的安全防线，应该立在最外层：对于不认识的域名，应该连 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。
如果你是直接 apt install nginx 或者用什么一键脚本安装的，设置的要点在于搞清楚 Nginx 配置文件的加载优先级，也就是 Nginx 对于一个访问最优先是匹配哪个配置文件里的指令。
Nginx 寻找虚拟主机（网站）遵循的优先级，从高到低是这样的：
listen 指令上显式写了 default_server 参数的站点，拥有最高优先级。
加载顺序兜底：如果没有任何站点声明自己是 default_server，Nginx 则会默认以读取顺序中的第一个虚拟主机充当默认站。
http { ... } 块中的通配符引入时（比如很多一键脚本和面板用的 include /etc/nginx/conf.d/*.conf;），系统底层采用的是标准 C 库 glob() 函数，按照文件名 ASCII 码字母顺序加载。所以这种时候正确的操作姿势是：
/etc/nginx/conf.d/00-default.conf，将上述兜底规则粘进去。以 00- 开头可以确保它在所有业务站点之前第一个被解析，就算漏写了 default_server，它也是排序第一的默认站。
方法 B（最纯粹）：直接打开 /etc/nginx/nginx.conf，将上述兜底规则写在 include /etc/nginx/conf.d/*.conf; 这一行的正上方。
如果你是使用宝塔或 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。兼容性倒是挺好，但是也埋了个大坑。
面板环境下正确的操作姿势是：
tjsky.net.conf）内部注入的 default_server 声明，将控制权还给底层。/www/server/nginx/conf/nginx.conf 或者 /home/1panel/apps/openresty/openresty/conf/nginx.conf 之类的主配置文件路径）。include /.../.../*.conf; 这一行。nginx -t 测试一下语法（大部分面板会在你保存配置时自动执行一次语法测试，确保你没把配置搞坏，不过嘛，最好手动执行一次，万一你的面板没帮你做语法测试呢）。nginx -s reload 重载配置。新的配置生效后，在本地终端用 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...
握手直接失败，连接秒断，那些使用奇奇怪怪的域名的访问再也进不来啦。从那之后，日志又清净得一天不到两位数了。
