dns安全防护

去年帮一个朋友排查网站异常，首页时不时跳转到博彩页面。全防服务器日志干干净净，全防web目录没被篡改，全防查了半天，全防最后发现是全防DNS解析被动了手脚——域名被解析到一个境外IP，而那个IP上跑着个一模一样的全防钓鱼站。攻击者没碰他的全防服务器，只是全防通过DNS服务商的管理后台弱口令进去了，改了一条A记录。全防这事让我重新审视DNS的全防安全分量：它不像漏洞利用那么“炫”，但一旦失守，全防整条链路都成了别人的全防道具。

DNS的全防设计初衷是“查询-应答”，没考虑太多信任问题。全防UDP 53端口明晃晃地摆在那儿，谁都能发个包问问“example.com的IP是多少”。默认情况下，递归服务器会老老实实帮你问一圈，再把结果缓存下来。这个机制被玩坏的方式很多，最经典的是DNS缓存投毒。攻击者伪造一个应答包，抢在真实应答之前到达递归服务器，服务器就把假记录缓存了。所有后面来查这个域名的用户，拿到的都是假IP。2008年Dan Kaminsky披露的那个漏洞，能让攻击者在几秒内污染大部分递归服务器，当时几乎是核弹级的事件。后来虽然加了随机端口和事务ID，但如果你还在用老旧的BIND版本或者配置不当的Windows DNS，风险依然在。

另一种更隐蔽的玩法是DNS隧道。很多企业防火墙只放行53端口，觉得DNS流量“人畜无害”。攻击者就利用这一点，把C2指令和窃取的数据编码进DNS查询里。比如aGVsbG8=.evil.com，看起来是个正常的子域名查询，实际是base64编码的“hello”。服务器端把应答包也塞满数据，一来一回，一条隐蔽通道就建好了。我见过一个案例，某公司内网被渗透后，攻击者用DNS隧道往外传了三个月的数据库备份，流量监控完全没报警。后来是安全团队发现某个域名每秒被查询上千次，才顺藤摸瓜揪出来。

还有一类问题出在客户端。很多人不知道，你连上公共WiFi时，路由器下发的DNS服务器地址可能已经被篡改。你以为自己在访问bank.com，实际解析到了攻击者的服务器，证书一伪造，账号密码全丢。这种叫DNS劫持，在酒店、机场、咖啡厅太常见了。有个做渗透测试的朋友跟我说，他随身带个迷你路由器，专门在公共场所伪造DNS响应，十次有八次能钓到鱼。普通用户根本看不出来，地址栏还是那个域名，锁头图标也在，但数据全往他那儿走。

防护得从多个层面下手。递归服务器这边，DNSSEC是正解。它用数字签名给DNS记录做认证，你拿到应答能验证是不是真的来自权威服务器。但DNSSEC部署率一直上不去，配置复杂，密钥轮转麻烦，很多小服务商干脆不碰。另一个实用手段是DNS over HTTPS或DNS over TLS，把查询加密，中间人看不到你问了什么，也没法轻易篡改应答。Firefox和Chrome现在都支持DoH，Cloudflare的1.1.1.1和Google的8.8.8.8都能用。不过企业内网得小心，加密DNS可能绕过你的安全策略，得在网关层面做拦截或自建DoH服务。

客户端防护反而最简单：别用运营商默认的DNS，手动改成可信的公共DNS，或者干脆启用DoH。路由器管理密码别用admin/admin，固件保持更新。至于企业，监控DNS查询日志比什么都重要——那些长域名、高频查询、TXT记录异常增大的，十有八九有问题。我自己的做法是在内网DNS上挂个脚本，专门抓查询长度超过100字符或者每秒重复超过50次的请求，误报不少，但真能兜住底。

DNS这东西，平时没人注意，出事了就是大事。它像空气，存在感低，但断一下试试？防护没有银弹，DNSSEC、DoH、日志监控、弱口令整改，每样都做一点，攻击成本就上去了。别等到首页被改才想起来查解析记录，那时候数据可能已经在别人手里了。