2026年6月17日，凌晨三点，我的手机震了三次。第一次是监控告警，第二次是老板的电话，第三次是托管机房的通知——服务器被攻击了，流量尽数涌向一个与360DNS相关的异常IP。这不是我第一次遇到这种情况，但每次都能让人瞬间清醒。对很多运维或者自己搭站的站长来说，服务器受到攻击几乎是一门必修课，区别只是有的人学了怎么交学费，有的人学了怎么躲过一劫。
今天我想聊的，不是那种“从入门到入狱”的教科书式的安全指南，而是几个真实的场景和教训——关于你手头那台吃灰的OpenWrt路由器、那个你几乎忘了的2路机架服务器，以及那个你以为只在墙内用的360DNS服务器。
当你的OpenWrt web服务器成为攻击者的“后花园”
很多人把OpenWrt当成一个高级路由器固件来用，刷刷固件、跑个酸酸乳、挂个广告拦截就完事了。但我见过不少开发者，直接把OpenWrt当成一个轻量级的web服务器来用——跑个PHP论坛、挂个个人博客，甚至架个简单的API接口。这种做法的吸引力太大了：功耗低、24小时在线、还能顺便做路由。但代价是什么？
2025年底，我帮一个朋友排查他的个人站点，他当时用的就是一台刷了OpenWrt的旧路由器，上面跑着一个老旧的lighttpd+PHP环境。问题出在哪儿呢？他为了省事，直接在LuCI后台开了WAN口的80和443，并且启用了uHTTPd。结果不出两个月，他的站点就被植入了挖矿脚本。原因很简单：uHTTPd在默认配置下缺乏基本的安全加固，而且他关闭了automatic updates。
OpenWrt本身是极其优秀的嵌入式系统，但把它当成生产级的web服务器，需要你做几件反直觉的事情：
- 禁用uHTTPd，改用Nginx或Caddy：uHTTPd简单，但功能太少，安全配置基本没有。Nginx在OpenWrt上的opkg包可以做到WAF级别的过滤，配合GeoIP模块，可以自动封禁非目标地区的IP。
- 别让web服务暴露在全世界的WAN口下：很多攻击者通过扫描常见的物联网端口（比如80、443、8080）找到你的OpenWrt设备。用防火墙规则限制来源IP，或者只通过VPN回连访问你的web服务，这是最基本的操作。
- 定时重启是一种朴素的防御：对，就是重启。很多针对嵌入式设备的攻击是利用内存驻留的进程，重启可以清除大部分残留的恶意进程。至少每周一次，这比找什么安全补丁来得更直接。
说白了，OpenWrt web服务器这个组合，理想很丰满，现实很脆弱。它需要你有意识地牺牲一部分便利性来换取安全。
360DNS服务器：一个被低估的攻击面
聊到360DNS，很多人会觉得这是国内才用的东西。但在我经历的那次攻击中，攻击者恰恰是利用了一个配置不当的360DNS服务器作为跳板，对我客户的一台2路机架服务器发起了DNS放大攻击。那次攻击流量不大，只有十几Gbps，但因为DNS服务器是公开递归的，导致源IP被污染，清洗起来非常麻烦。
360DNS服务器的安全性，往往被忽视在一个误区里：很多人都以为DNS解析服务只需要保证可用性就行，不需要考虑太多安全。但恰恰相反，一个开放的DNS递归服务器（Open Resolver）是互联网上最容易被滥用的资源之一。攻击者可以通过伪造源IP向你的DNS服务器发送一个小请求，然后DNS服务器回传一个放大数十倍的响应，这个响应会被间接地打到真正的受害者身上。而你，就成了帮凶。
怎么避免这种事情发生在自己身上？三条硬性规则：
- 永远关闭DNS递归查询：只对你授权的域名做解析，拒绝所有来自外部的递归请求。这个配置在BIND或者PowerDNS中很容易做到，但很多人图方便就开启了。
- 限制查询来源IP：如果你的DNS服务器是只对你内部网络服务的，那就只让内网IP或者VPN IP来查询。全局开放查询，“大善人”当不得。
- 使用RRL (Response Rate Limiting)：这是针对DNS放大攻击的直接解决方案，限制相同源IP在单位时间内的查询频率。
说现实一点，360DNS这类服务本身是有成熟的商业防护能力的。但问题是，很多人是自己基于开源软件（比如BIND、Unbound）搭建的私有DNS，这些自建的系统在默认配置下几乎是透明墙。
2路机架服务器：你的“高性能”可能是最脆弱的
2路机架服务器，放在机房里，双路CPU、大内存、硬RAID，看着就踏实。但恰恰是这种看起来坚不可摧的设备，在遇到有针对性的应用层攻击时，表现得比一台树莓派还糟糕。
我说个真实发生的事：2026年3月，一个做电商的朋友，他的主力业务跑在一台Dell R750xs（2路Xeon）上。有一天，他的站突然响应极慢，但CPU和内存占用都不高，流量也正常。查了半天发现，是攻击者针对他网站的一个搜索接口发起了慢速HTTP攻击（Slowloris变种），每个请求只发一部分头信息，然后一直保持连接。他的Apache服务器默认的KeepAliveTimeout没配置好，导致所有可用连接被耗尽。2路机架服务器有再多的核心和内存，也架不住连接池被占满。
所以，别以为你用了2路机架服务器，就可以完全不考虑应用层的羊毛。这里有几个看似反常识的策略：
- 硬件的冗余是给正常业务用的，不是给攻击用的：双电源、双网卡、RAID10，这些是为了让你在硬盘坏了一块或者电源模块挂了的时候还能正常运行，而不是用来硬扛几百Gbps的DDoS的。
- 配置应用层的连接限制：不管是Nginx还是Apache，设置每个IP的最大并发连接数、限制请求速率、调整KeepAlive参数，这些比堆硬件有用得多。
- 把静态内容和服务逻辑彻底分离：用CDN加速静态资源，让2路机架服务器只处理动态请求。大多数攻击针对的是你的动态页面或API接口，把静态资源扔出去，能过滤掉不少低水平的攻击。
这句话可能有点得罪人，但我还是想说：很多时候，买昂贵的2路机架服务器，是一种偷懒的行为。因为觉得“性能强，扛得住”，所以忽视了对代码和中间件的优化。攻击者最爱这种心态，因为流量一旦稍微有针对性，你的服务器性能和它的价格就不成正比了。
关于tk服务器：别让域名后缀给你带来麻烦
tk服务器？这里可能有人会疑惑，tk不是域名后缀吗？对，我说的tk服务器并不指托克劳（Tokelau）那些免费域名，而是指那些用tk作为域名后缀的API服务器或者内网穿透服务。很多个人开发者、甚至一些创业公司，为了省每年几十块的域名续费，会直接用.free.tk这类免费域名指向自己的服务器。
但问题在于，tk域名在2026年的今天，已经成了很多安全扫描器和防火墙的默认黑名单。攻击者非常喜欢扫描tk域名段，因为这些域名的持有者往往安全意识薄弱，而且很多tk域名被用于各种槽点无数的服务——比如恶意软件分发、钓鱼、僵尸网络C2。这意味着，当你用tk域名指向你的服务器时，你不仅在攻击者面前“显眼”，在正当的WAF和CDN防护下也更容易被误伤。
如果你的业务确实挂在一个tk域名后面，我建议你尽快做两件事：第一，迁移到一个正规的、特别是支持DNSSEC的域名注册商；第二，确保你的服务器收到的请求经过了HTTPS加密，并且严格验证客户端证书。说实话，省那个域名钱，远不够你被攻击以后清洗流量的账单。
写在最后：服务器受到攻击时，别急着关电源
服务器受到攻击这件事，和火灾有点像——大部分时候不会发生，但一旦发生，你之前做的所有准备决定了你是损失一台设备的成本，还是损失一周数据和信誉。OpenWrt web服务器可以是好用的工具，但你需要管住它面向WAN的口子；360DNS服务器是好用的服务，但你不应该让它变成开放的递归节点；2路机架服务器是性能猛兽，但你要学会约束它面对的请求；tk服务器……还是算了吧。
还有一点，当攻击真的发生时，最重要的是保持冷静。别急着直接拔电源或者关防火墙——先尝试联系你的ISP或者云服务商，启用黑洞路由或者流量清洗。2026年的DDoS攻击，很多已经不是靠关服务器就能解决的。
这篇文章不一定让你变成一个安全专家，但至少下次你看到监控告警的时候，知道该先检查哪个配置，而不是对着CPU使用率发呆。