背景

我向来是对Openclaw不感兴趣的。因为我觉得这东西实际上做不了什么有用的工作，只会消耗token，真想干点什么直接用对应的agent不就得了。
不过朋友前几天在Discord拉了个群里搞了个聊天机器人，觉得虽然不能拿来干活，但是放在群里整活倒也不错，所以就在家里的服务器上跑了一下Openclaw的docker，这一跑才发现服务器被挂马了两周多，多了三个不知道哪来的容器在跑pcdn之类的东西。

于是我紧急排查了一下，发现是之前用的哪吒面板出了一大堆高危漏洞，包括CVE-2026-46716和CVE-2026-53519等，不少人都中招了。有的是被植入了挖矿程序，有的是像我这种被挂常驻任务容器的。

检查了一下服务器，觉得应该是彻底废了，因为攻击者直接给他自己的SSH公钥放到了root账户的authorized_keys里了，也就是说我的服务器全部的权限都被对方拿走了，而且在这期间对方在我这服务器里干了什么我根本不得而知。

最离谱的是，哪吒面板是主从模式，只要master机被攻破，所有的运行agent的机器也一并被植入恶意程序，也就是说，我的所有服务器甚至NAS都全部沦陷。没办法，只能把所有服务器都停机，然后一点点把里面存的重要文件取出来，重置所有服务器的系统，能换IP的就换IP，所有的密码默认已泄露进行修改，所有的SSH密钥都重新生成。

安全架构

完成了止损后，我就在思考，到底用什么样的架构才能最大可能地保证服务器的安全。

作为个人站长，以往我对零信任原则是不太在乎的，毕竟我就几个小服务器，而且也是纯爱好不是拿来赚钱的，就觉得挺无所谓的，谁会来攻击我。现在看来，人家跑脚本可不在乎你是什么服务器，只要检测到了就直接干。虽然我服务器上的数据也不值钱吧，但是重新装这么一次还是挺费劲的，看来是时候必须正视零信任了。

服务器安全无非三大块，物理安全，网络安全和系统安全。用的云服务器，自然不需要考虑物理安全，就只有网络安全和系统安全需要考虑了。

网络安全上，虽然最开始我用了一阵子阿里云WAF，OSS，CDN，后来发现这些按量付费的虽然每个月价格都不高吧，但是难保哪天被人恶意利用，第二天房子就会阿里了，于是就都给撤下来了，网络安全全靠那薄弱的入站防火墙，当时只保留了443，80和22端口的开放，现在想想即便如此也是有着不小的安全隐患的。

至于系统安全，之前其实完全没考虑过，甚至很多服务都不是docker运行，都是直接运行在物理机上的，而且我用的docker也都是root docker，但凡出个0day就直接玩完，这次哪吒面板的事就是出在这个上面。

网络安全

本身我的网站就不是为了赚钱，根本没有收入，所以让我花大价钱去上阿里云那套安全系统我是肯定不干的，于是就想到了Cloudflare。其实我很久以前把域名托管到Cloudflare上过，但是当年一个是觉得麻烦另一个是觉得Cloudflare在国内的访问速度实在是太慢了，于是就放弃了。

但是现在，一个是我人就在海外，服务器也基本都是海外机房，再加上我觉得安全总归是大于速度的，所以又考虑回了Cloudflare。

既然用了Cloudflare，域名解析和CDN流量代理的小黄云那是自然要用的，但是如果只是套了层全站CDN再直接回源到服务器IP和端口，感觉还是不够保险，毕竟源站的端口还是开放的，只要有人知道IP还是能进行攻击。

思考了一下，唯一能关闭所有入站流量的办法，貌似也只有反向代理了。恰好，大善人也提供了这个方案，只需要配置一个Cloudflare Zero Trust Tunnel就好了，甚至想发布站点，也只需要在后台添加一下域名即可，完全不需要手动管理域名解析，最重要的是，全部免费。所以Cloudflare是真的赛博活佛互联网大善人。想起了之前沈逸评Cloudflare是境外势力还有大把粉丝支持的事，合着在这帮人眼里凡是能给老百姓提供免费服务的大企业都是反动势力呗，敌人太邪恶了竟然给灾民发粮。

于是乎，现在我的网络架构就是：用户请求->Cloudflare DNS->Cloudflare CDN->Cloudflare Tunnel->源站。

至于SSH，当然也不开放端口，在本地启一个WARP就完事了，然后用内网地址连接SSH。不仅如此，我还关闭了root登录和密码登录，密钥也从原来的无密码RSA密钥换成了带密码的ED25519密钥，虽然带密码麻烦点但是更安全。

然后，像是我的主页导航之类的，因为是纯静态站点，所以也没必要回源源站了，直接用Cloudflare Pages就完事了，还省得我源站崩溃导致整个站点都访问不了了，默认用Cloudflare Pages还能在上面挂一个公告提示一下服务器状态。

系统安全

如果想要系统保持完全的安全，那最好的办法就是给所有服务都分配到沙箱里运行，或者每个服务单独起一个虚拟机并且每日同步，被攻破也只有虚拟环境受到污染，恢复快照就完事。不过这样太麻烦而且也没那么多资源，简单研究了一下，最后打算用rootless docker来实现。

虽然docker也曾爆出过逃逸漏洞，不过不用特权模式运行的话，而且只用非root用户运行rootless docker相对来说还是比较安全的。起一个nginx，然后每个站点都对应一个php环境，最后用compose统一管理所有的站点。至于非php网页，就直接单独启container然后用tunnel把对应端口映射到Cloudflare CDN上即可。这样保证了所有的文件环境都是独立的，一个容器出现问题不会导致传染，在一定程度上限定了污染发生的区域。

唯一的缺点就是这样实在是太费资源了，alpine版本的php还好说，但是有些环境需要完整的php环境，比如typecho的notice插件，那样一个image就得占1G大小，对我这个2H2G 40G硬盘的小机器来说压力还是有点大，不过目前现在暂时是够用的，所以先这么跑吧，不行再说。

用btop看了一下核心网站服务器的资源情况，目前还好。如果不行的话，到时候给部分服务迁移到别的空闲服务器上或者我家里的本地服务器上应该都问题不大，毕竟都用tunnel了，本地服务器和云服务器的区别也不大了，等找时间给我以前因为云服务器资源不够导致停运的gitlab放到本地跑起来试试。

总结

虽然这次的事情没造成什么影响吧，但是也算是敲响警钟了，无论什么时候都不能为了方便去用一些不安全的软件，如果非要用也一定要放在隔离环境里用，不然出了问题是真的麻烦。

什么宝塔什么哪吒，以后我是都不打算用了，真要搞探针，我直接写一个不可执行的仅显示信息的API不是更方便，占用还更小。

总之，零信任原则还是很有用的，希望大家引起重视。

关于本篇博客，因为只是记录，所以并没有讲太多如何部署方面的问题，只是从架构上简单讲了一下我目前的构思，如果各位也想了解的话，建议去查一查教程，或者在本篇下面留言。

2026-07-17 16:23 (JST, UTC+9)
UtopiaXC
于日本茨城县筑波市