1. 先从DNS本身说起为什么它总被攻击1.1 DNS的核心角色与攻击面如果你在网上做了几年运维或安全一定对DNS又爱又恨。爱它是因为没有它我们连一个网站都访问不了恨它是因为一旦它出问题整个业务就像没头苍蝇一样乱转。DNSDomain Name System本质上是互联网的“电话簿”把我记忆中的域名“example.com”翻译成服务器能识别的IP地址“93.184.216.34”。这个翻译过程发生在每一次网页访问、每一次邮件收发、每一次App调接口的背后频率高到普通人完全感知不到。但正因为它是“基础设施中的基础设施”攻击者盯上它几乎是必然的。DNS协议从1987年RFC 1034/1035定下来到现在底层设计一直保留着早期互联网时代的特点明文传输、无认证机制、依赖UDP的53端口。后来虽然有DNSSEC域名系统安全扩展补丁打了上去但实际部署率远谈不上乐观。换句话说互联网的“电话簿”在很长一段时间里是裸奔的拦截、篡改、伪造都相对容易。攻击面主要集中在三个环节客户端发起的递归解析请求、递归服务器向权威服务器发起的迭代查询、以及权威服务器本身的响应数据。任何一环被信任关系破解或数据包被伪造都会直接污染最终解析结果。更麻烦的是DNS流量常常被防火墙放行因为业务必须依赖它这就给攻击者留了一个“合法通道”。1.2 攻击者的动机与影响范围攻击者为什么要打DNS动机通常不外乎这几种第一搞垮业务。直接把DNS打到不可用用户解析不了域名网站再快也白搭这是成本最低的拒绝服务方式。第二钓鱼与欺诈。DNS劫持或缓存投毒能把用户引导到仿冒站点窃取账号、密码、支付信息。第三隐蔽通信。DNS查询报文体积小、频率高、容易被信任特别适合做数据外传的隧道。第四中间人流量监听。如果攻击者控制了某个解析环节他能看到你访问了哪些域名进而推测业务结构和个人隐私。影响范围也分几个层次个人层面DNS被污染可能只是抱怨“网页打不开”企业层面DNS故障可能导致核心业务中断、客户流失、品牌信誉受损基础设施层面针对公共DNS或根服务器的攻击理论上会影响一大片区域的正常解析。2016年那次针对Dyn的DNS DDoS攻击让半个美国的互联网瘫痪代价极其惨痛。所以盘点DNS攻击类型不只是学术问题是每个做运维、做安全的人必须掌握的排查基本功。2. 五大常见DNS攻击类型逐一拆解2.1 DNS缓存投毒污染解析结果的鼻祖DNS缓存投毒是最经典也最“考验手法”的攻击之一。它的核心思路是让递归DNS服务器相信一个伪造的解析记录并把这个假记录保存在缓存里之后一段时间内所有向这台服务器请求该域名的客户端都会拿到攻击者指定的IP地址。原理上递归服务器在前面会携带一个Transaction ID并与请求的端口号一起构成“识别码”。早年很多实现里Transaction ID是递增或可预测的端口也是固定的某个源端口攻击者只要伪造一个应答包同时猜对ID和端口就能让服务器接受假数据。后来随机化改善了但攻击者又结合了“生日攻击”的思路——在短短几秒内发送海量伪造响应只要其中一个ID碰对就成功投毒。实操里我见过最典型的案例是攻击者先向目标递归服务器发送一个针对“login.bank.com”的查询紧接着以每秒几十万个伪造包冲击服务器的53端口每个包都携带不同的Transaction ID但应答内容一律指向一个钓鱼网站IP。由于服务器本身要处理大量其他查询对重复查询只接受第一个匹配的响应概率再低也架不住量堆。防御缓存投毒最有效的还是DNSSEC。它通过数字签名让递归服务器能验证应答的真实性从根上掐断伪造数据。同时务必要启用源端口随机化、Transaction ID随机化并缩短缓存TTL到合理范围比如A记录5分钟、MX记录10分钟既不影响性能又降低投毒后的影响时长。顺便说一句很多人以为投毒只影响那个被伪造的域名实际上攻击者可以对一个不存在的子域做NXDOMAIN投毒直接把整个域名解析“黑掉”这一点很容易被忽略。2.2 DNS劫持把用户流量引向钓鱼站DNS劫持和缓存投毒经常被混为一谈但严格来说劫持的对象范围更广。缓存投毒发生在服务器缓存的层面而DNS劫持可以发生在路由器、运营商链路、本地Hosts文件、甚至浏览器层面。攻击者一旦控制了客户端到递归服务器之间的网络设备就能直接改写响应内容把“example.com”解析成攻击者自己的IP。这类攻击不依赖任何协议漏洞纯粹是“我能看见就能改”。具体场景里家用路由器弱口令曾经是重灾区。攻击者登录路由器后修改DNS设置把查询全部转向一个恶意DNS服务器这服务器平时正常解析但碰到特定银行或支付域名就返回仿冒IP。用户完全无感知因为域名栏里输入的还是正确地址HTTPS证书报错也被很多人习惯性跳过。企业内网也出现过在出口网关部署嗅探脚本的案例直接对UDP 53流量做响应速度比真实DNS还快导致真实响应被丢弃。检测DNS劫持的土办法是交叉对比抓到你本机解析的IP再用知名公共DNS比如114.114.114.114前提是它本身没被污染或直接dig 8.8.8.8解析同一域名如果结果不同就得警惕链路问题。进阶做法是用DNS over HTTPSDoH或DNS over TLSDoT来加密通道让劫持者看不到也改不了。不过DoH也有成本它会增加延迟也可能和现有的审计方案冲突部署前要自己权衡。2.3 DNS放大攻击用39字节换3.6MB流量DNS放大攻击是DDoS领域的一朵“奇葩”。它的原理很简单利用DNS的响应体积远大于请求体积这一特性借助开放递归解析器把流量放大几十倍甚至上百倍。经典手法是向受害目标发送大量伪源IP的查询请求目标是那些支持EDNS0扩展且配置不当的开放DNS服务器。攻击者构造一个短小的任意域名查询或ANY类型查询响应可以拉到数百字节一个请求被放大成几十倍的响应流量随后全部涌向被伪装成源IP的受害目标。给我印象最深的数据是一个大约39字节的欺骗源IP查询经过特定配置的DNS服务器能返回约3,600字节的响应。如果攻击者控制一个僵尸网络同时驱动几千台开放递归器单次攻击带宽就能轻松到几十Gbps。在GitHub那次著名的攻击中虽然用的是主要碰上了Memcached但DNS放大攻击一直是DDoS报告里常年霸榜的类型。防御思路分两个方向。作为潜在受害方你只能通过流量清洗和上游带宽冗余来扛这需要和IDC或云服务商协作。作为运维你要确保自己的DNS服务器不会被变成放大器关闭递归功能给外部用户、只对内部网段开放、限制ANY查询、在出口防火墙限制伪源IP包。用dig命令自测也很简单dig short version.bind CH TXT your-server dig ANY example.com your-server如果第二条响应很大或第一条暴露了软件版本都说明配置有问题。2.4 DNS隧道数据走私的秘密通道DNS隧道是我个人觉得“最安静”的攻击方式。它不追求搞垮或重定向而是把数据伪装成DNS查询或响应包在看似正常的解析行为里传递任意内容。攻击者通常在公共DNS里布置一个“隧道服务器”对应自己的一个域名。客户端向这个域名发起DNS查询每一条查询的子标签或请求类型里都隐藏了要传出或接收的数据片段服务器端再解包重组。为什么这玩意难防因为DNS请求往往是小包、高频、随机的很少有威胁引擎会认为一个频繁查询“a1b2.example.com”的客户端是有问题的。攻击者甚至能把二进制数据编码进行拆成多个查询记录每秒钟可以传输几十KB虽然比不上直连但用来偷数据文件、盗取源码、外传密码库绰绰有余。更激进的用法是直接把DNS隧道做成远程控制通道受害主机定期向域内发出指令请求命令就藏在TXT记录或CNAME记录里。排查DNS隧道的主线是“行为审计”。观察某段IP对单一域名的查询频率、查询类型的比例、TXT记录查询占比以及请求域名的熵值特征——正常用户不会去查询“Xk9zLp2qCv4r”这种随机子域。实用命令可以用tcpdump抓53端口包然后配合脚本统计tcpdump -i eth0 port 53 -c 10000 -w dns.pcap之后用dnsmap或dnstop这类工具分析重点看有没有异常大的TXT记录或长时间高频的特定域。防御上最有效的还是收紧出口规则只允许内部DNS服务器向外部解析普通客户端一律走内部递归禁止对外直连53端口。2.5 DNS重绑定绕过同源策略的老手DNS重绑定和前面几种不一样它的目标往往是“端上代码”也就是浏览器或本地应用。攻击者的域名解析策略是第一次查询返回一个正常的IP比如攻击者自己的服务器第二次、第三次或特定用户查询时又返回一个内网IP比如127.0.0.1或192.168.1.1。浏览器在同源策略下本来不能直接访问内网资源但如果你访问了攻击者的页面页面脚本里请求同一个域名解析结果突然指向内网浏览器就觉得这是同一个源于是放行攻击脚本就可以借机探测或操作内网服务。这种攻击在物联网时代杀伤力显著。很多智能设备的管理后台跑在局域网IP的80端端口上没有任何CSRF防护或基于域名的鉴权DNS重绑定直接就能打成“跨域”控制中继。即便没有真实的内网服务攻击者也能通过重绑定扫描内网端口绘制拓扑。防御DNS重绑定最干净的办法是服务端验证HTTP请求里的Host字段和实际IP是否匹配并拒绝未预期的内网请求。同时可以用浏览器插件或企业终端策略禁用异常域名重绑定。如果你是自己写服务务必给内网管理端加上强认证和CSRF Token至少让脚本拿不到可用的Session。3. 怎么判断你的DNS系统正在被攻击排查实录3.1 常见异常指标与日志特征很多人问我怎么知道自己是不是被攻击了其实DNS攻击的异常指标比想象中明显只是没被注意到。我把这些指标整理成了一张表方便你自己对标指标正常情况异常情况查询失败率小于1%突然飙到5%以上或全失败响应延迟个位数毫秒到几十毫秒出现数秒级超时或抖动缓存命中率通常60%以上骤降至10%以下怀疑缓存被清请求类型比例以A/AAAA为主ANY或TXT记录异常多特定域名查询量无明显热点某个域名请求量爆炸式上升响应内容预期IP解析结果突然指向陌生IP段日志层面DNS服务器最常见的是大量“formerr”格式错误和“timeout”。如果同一客户端IP在短时间内对同一个不存在的记录反复查询很像在试探你的缓存行为。缓存投毒后你会看到日志里出现对同一域名的大量重复查询但都命中了一个异常的解析结果。放大攻击场景下你的服务器日志会记录大量来自随机源地址的ANY查询并且全是正常业务不用的类型。3.2 一个模拟案例的排查流程说个我经历过的模拟攻防场景。某天下午业务群突然有人说“公司官网打不开”但能上微信。我第一反应是本地DNS缓存问题让同事清理缓存结果没用。接着我打开终端直接dig公司域名发现返回了一个完全陌生的IP再用公共DNS解析返回却是正确IP基本可以判定是链路或本地递归服务器被污染。排查流程大概是第一步确认是本机还是服务器问题。dig www.example.com noall answer对比不同解析器结果。第二步抓包看链路是否被劫持。tcpdump -i eth0 host 10.2.3.4 -c 50重点看回应包的源IP和ID是否符合预期。如果包里有明显高于真实查询次数的伪造响应八九不离十是投毒。第三步检查递归服务器缓存。如果用的是BIND或Unbound清空缓存后重新解析观察是否恢复正常。不恢复正常就进一步看面向外部的查询确认是不是权威源出了问题。第四步检查服务器配置和历史日志。querylog打开后逐个核对外部查询尤其注意非标准端口或高频随机子域。那次最终定位到内网一台Windows机器被装了后门反复对外发出大量特定域名查询配合DNS隧道在偷数据。整个过程前后不到半小时但如果没有会看日志的习惯很可能只是重启电脑了事。4. 防御与加固踩坑之后的经验总结4.1 基础加固从配置层面堵漏洞我见过太多防火墙买得贼贵、性能拉满但DNS配置裸奔的公司。基础加固不复杂但每一条踩过坑的都值得写下来。递归与权威分离对外只开放权威域名服务的端口递归查询仅限内网IP段。BIND里用allow-recursion { 内部网段; };免得变成放大器。限制ANY查询多数业务根本不需要ANY响应。在配置里直接禁止或限制响应大小可以降低放大倍数。开启端口随机化要么升级版本要么显式配置随机源端口。这能直接提升投毒难度。使用DNSSEC虽然部署成本高但对关键域至少签个ZSK/SKS很多托管DNS云服务现在都支持一键开启比自己搓证书方便。配置访问控制策略在云防火墙或安全组层面限制哪些外部IP可以访问你的53端口业务发起的递归只允许内网DNS出口。加固每台终端把本地Hosts文件锁起来管理路由器的密码不用的DNS转换工具别乱装。这里有一个非常容易翻车的点很多人为了性能把TTL设成0结果每次请求都去权威刷新一旦权威源抖动业务全断但TTL设太长投毒后的影响时间也长。折中方案是A记录1800秒MX记录3600秒动态记录用自动刷新机制。4.2 监控与应急预案别等出事了才动手攻击往往发生在周末凌晨所以监控和预案才是真正的护城河。我是一个绝对支持“先建基线再设阈值”的人没有基线任何告警都是放屁。监控层面至少需要三块第一是服务器性能监控包括CPU、内存、网络流量和53端口连接数第二是DNS业务质量监控定期主动探测解析延迟和失败率第三是数据层监控重点记录查询类型、异常域名、缓存命中率变化。开源方案里Prometheus配合blackbox_exporter可以轻松搞定主动探测Exporter里还能带一个dns_query探针直接测域名解析结果。如果怀疑被投毒建议加一个“黄金对比”任务定期用可靠的递归服务器解析你的关键域名和自己服务器的结果比对有偏差就告警。应急预案至少要写清楚三件事谁负责处理、怎么临时切换流量、如何回滚配置。实操里我吃过一次亏某个业务DNS被大流量打挂了按预案切到备用线路但备用线路配置缺了一个老域名的记录导致部分客户访问异常。所以预案切流量之前务必做一次完整配置对比重点检查记录数量、类型、TTL是否一致。5. 常见问题速查与避坑清单5.1 攻击类型速查表我把前面讲过的类型整理成一个速查表方便团队里新手快速定位问题。攻击类型典型特征主要危害首选应对缓存投毒同一域名大量重复查询、结果IP异常把用户导向钓鱼站、业务瘫痪清缓存、开DNSSEC、随机化端口DNS劫持本机独立解析与公共DNS结果不同流量被监听、账号密码泄露检查路由器/网关、启用DoH/DoT放大攻击出口流量暴涨、大量ANY查询DDoS打垮带宽、业务不可用清洗流量、关闭开放递归、限ANYDNS隧道高频随机子域、TXT记录占比高数据外传、隐蔽远控封禁异常域名、限制直接外联53重绑定目标域名解析结果忽内忽外绕过同源策略攻击内网设备服务端校验Host、管理端加固认证5.2 我踩过的几个坑与额外心得第一个坑是“全怪DNS”。遇到网站打不开了第一反应就冲到递归服务器那边排查。后来发现HTTP服务本身挂了也会表现为DNS解析慢因为浏览器要等待连接超时。所以排查顺序一定要先分网络、再分DNS、最后才分应用别让DNS背锅。第二个坑是“过度防御”。也给一台内部DNS服务器做了完整的ANY限制、递归ACL结果把上游某台合法监控设备的查询也挡了害得监控数据断了一晚。配置ACL前一定先问清楚有哪些合法消费方再写规则。第三个坑是日志量过大。开启querylog后每秒几万条查询记录直接把磁盘写满报警电话连环追命。建议要么用远程日志服务要么只对特定客户端IP抓包别全量记录。最后分享两个小白也能上手的自查技巧。一个是手动清理DNS缓存不同系统命令不同Windows用ipconfig /flushdnsmacOS用sudo killall -HUP mDNSResponderLinux用systemd-resolve --flush-caches方法虽土但很有效。另一个是偶尔手动改下DNSSEC状态再改回来能逼你熟悉自己的权威服务器配置出问题时恢复速度会快很多。DNS攻击既没有想象中神秘也绝不能掉以轻心。从我个人的经验看大多数企业最缺的不是新技术而是把基础配置做干净的耐心。下次再收到“DNS解析异常”的报警先别急着动Config翻一遍你写的这篇盘点对照排查大概率能节约半天时间。
DNS攻击类型与防御全解：缓存投毒、劫持、放大等常见威胁
1. 先从DNS本身说起为什么它总被攻击1.1 DNS的核心角色与攻击面如果你在网上做了几年运维或安全一定对DNS又爱又恨。爱它是因为没有它我们连一个网站都访问不了恨它是因为一旦它出问题整个业务就像没头苍蝇一样乱转。DNSDomain Name System本质上是互联网的“电话簿”把我记忆中的域名“example.com”翻译成服务器能识别的IP地址“93.184.216.34”。这个翻译过程发生在每一次网页访问、每一次邮件收发、每一次App调接口的背后频率高到普通人完全感知不到。但正因为它是“基础设施中的基础设施”攻击者盯上它几乎是必然的。DNS协议从1987年RFC 1034/1035定下来到现在底层设计一直保留着早期互联网时代的特点明文传输、无认证机制、依赖UDP的53端口。后来虽然有DNSSEC域名系统安全扩展补丁打了上去但实际部署率远谈不上乐观。换句话说互联网的“电话簿”在很长一段时间里是裸奔的拦截、篡改、伪造都相对容易。攻击面主要集中在三个环节客户端发起的递归解析请求、递归服务器向权威服务器发起的迭代查询、以及权威服务器本身的响应数据。任何一环被信任关系破解或数据包被伪造都会直接污染最终解析结果。更麻烦的是DNS流量常常被防火墙放行因为业务必须依赖它这就给攻击者留了一个“合法通道”。1.2 攻击者的动机与影响范围攻击者为什么要打DNS动机通常不外乎这几种第一搞垮业务。直接把DNS打到不可用用户解析不了域名网站再快也白搭这是成本最低的拒绝服务方式。第二钓鱼与欺诈。DNS劫持或缓存投毒能把用户引导到仿冒站点窃取账号、密码、支付信息。第三隐蔽通信。DNS查询报文体积小、频率高、容易被信任特别适合做数据外传的隧道。第四中间人流量监听。如果攻击者控制了某个解析环节他能看到你访问了哪些域名进而推测业务结构和个人隐私。影响范围也分几个层次个人层面DNS被污染可能只是抱怨“网页打不开”企业层面DNS故障可能导致核心业务中断、客户流失、品牌信誉受损基础设施层面针对公共DNS或根服务器的攻击理论上会影响一大片区域的正常解析。2016年那次针对Dyn的DNS DDoS攻击让半个美国的互联网瘫痪代价极其惨痛。所以盘点DNS攻击类型不只是学术问题是每个做运维、做安全的人必须掌握的排查基本功。2. 五大常见DNS攻击类型逐一拆解2.1 DNS缓存投毒污染解析结果的鼻祖DNS缓存投毒是最经典也最“考验手法”的攻击之一。它的核心思路是让递归DNS服务器相信一个伪造的解析记录并把这个假记录保存在缓存里之后一段时间内所有向这台服务器请求该域名的客户端都会拿到攻击者指定的IP地址。原理上递归服务器在前面会携带一个Transaction ID并与请求的端口号一起构成“识别码”。早年很多实现里Transaction ID是递增或可预测的端口也是固定的某个源端口攻击者只要伪造一个应答包同时猜对ID和端口就能让服务器接受假数据。后来随机化改善了但攻击者又结合了“生日攻击”的思路——在短短几秒内发送海量伪造响应只要其中一个ID碰对就成功投毒。实操里我见过最典型的案例是攻击者先向目标递归服务器发送一个针对“login.bank.com”的查询紧接着以每秒几十万个伪造包冲击服务器的53端口每个包都携带不同的Transaction ID但应答内容一律指向一个钓鱼网站IP。由于服务器本身要处理大量其他查询对重复查询只接受第一个匹配的响应概率再低也架不住量堆。防御缓存投毒最有效的还是DNSSEC。它通过数字签名让递归服务器能验证应答的真实性从根上掐断伪造数据。同时务必要启用源端口随机化、Transaction ID随机化并缩短缓存TTL到合理范围比如A记录5分钟、MX记录10分钟既不影响性能又降低投毒后的影响时长。顺便说一句很多人以为投毒只影响那个被伪造的域名实际上攻击者可以对一个不存在的子域做NXDOMAIN投毒直接把整个域名解析“黑掉”这一点很容易被忽略。2.2 DNS劫持把用户流量引向钓鱼站DNS劫持和缓存投毒经常被混为一谈但严格来说劫持的对象范围更广。缓存投毒发生在服务器缓存的层面而DNS劫持可以发生在路由器、运营商链路、本地Hosts文件、甚至浏览器层面。攻击者一旦控制了客户端到递归服务器之间的网络设备就能直接改写响应内容把“example.com”解析成攻击者自己的IP。这类攻击不依赖任何协议漏洞纯粹是“我能看见就能改”。具体场景里家用路由器弱口令曾经是重灾区。攻击者登录路由器后修改DNS设置把查询全部转向一个恶意DNS服务器这服务器平时正常解析但碰到特定银行或支付域名就返回仿冒IP。用户完全无感知因为域名栏里输入的还是正确地址HTTPS证书报错也被很多人习惯性跳过。企业内网也出现过在出口网关部署嗅探脚本的案例直接对UDP 53流量做响应速度比真实DNS还快导致真实响应被丢弃。检测DNS劫持的土办法是交叉对比抓到你本机解析的IP再用知名公共DNS比如114.114.114.114前提是它本身没被污染或直接dig 8.8.8.8解析同一域名如果结果不同就得警惕链路问题。进阶做法是用DNS over HTTPSDoH或DNS over TLSDoT来加密通道让劫持者看不到也改不了。不过DoH也有成本它会增加延迟也可能和现有的审计方案冲突部署前要自己权衡。2.3 DNS放大攻击用39字节换3.6MB流量DNS放大攻击是DDoS领域的一朵“奇葩”。它的原理很简单利用DNS的响应体积远大于请求体积这一特性借助开放递归解析器把流量放大几十倍甚至上百倍。经典手法是向受害目标发送大量伪源IP的查询请求目标是那些支持EDNS0扩展且配置不当的开放DNS服务器。攻击者构造一个短小的任意域名查询或ANY类型查询响应可以拉到数百字节一个请求被放大成几十倍的响应流量随后全部涌向被伪装成源IP的受害目标。给我印象最深的数据是一个大约39字节的欺骗源IP查询经过特定配置的DNS服务器能返回约3,600字节的响应。如果攻击者控制一个僵尸网络同时驱动几千台开放递归器单次攻击带宽就能轻松到几十Gbps。在GitHub那次著名的攻击中虽然用的是主要碰上了Memcached但DNS放大攻击一直是DDoS报告里常年霸榜的类型。防御思路分两个方向。作为潜在受害方你只能通过流量清洗和上游带宽冗余来扛这需要和IDC或云服务商协作。作为运维你要确保自己的DNS服务器不会被变成放大器关闭递归功能给外部用户、只对内部网段开放、限制ANY查询、在出口防火墙限制伪源IP包。用dig命令自测也很简单dig short version.bind CH TXT your-server dig ANY example.com your-server如果第二条响应很大或第一条暴露了软件版本都说明配置有问题。2.4 DNS隧道数据走私的秘密通道DNS隧道是我个人觉得“最安静”的攻击方式。它不追求搞垮或重定向而是把数据伪装成DNS查询或响应包在看似正常的解析行为里传递任意内容。攻击者通常在公共DNS里布置一个“隧道服务器”对应自己的一个域名。客户端向这个域名发起DNS查询每一条查询的子标签或请求类型里都隐藏了要传出或接收的数据片段服务器端再解包重组。为什么这玩意难防因为DNS请求往往是小包、高频、随机的很少有威胁引擎会认为一个频繁查询“a1b2.example.com”的客户端是有问题的。攻击者甚至能把二进制数据编码进行拆成多个查询记录每秒钟可以传输几十KB虽然比不上直连但用来偷数据文件、盗取源码、外传密码库绰绰有余。更激进的用法是直接把DNS隧道做成远程控制通道受害主机定期向域内发出指令请求命令就藏在TXT记录或CNAME记录里。排查DNS隧道的主线是“行为审计”。观察某段IP对单一域名的查询频率、查询类型的比例、TXT记录查询占比以及请求域名的熵值特征——正常用户不会去查询“Xk9zLp2qCv4r”这种随机子域。实用命令可以用tcpdump抓53端口包然后配合脚本统计tcpdump -i eth0 port 53 -c 10000 -w dns.pcap之后用dnsmap或dnstop这类工具分析重点看有没有异常大的TXT记录或长时间高频的特定域。防御上最有效的还是收紧出口规则只允许内部DNS服务器向外部解析普通客户端一律走内部递归禁止对外直连53端口。2.5 DNS重绑定绕过同源策略的老手DNS重绑定和前面几种不一样它的目标往往是“端上代码”也就是浏览器或本地应用。攻击者的域名解析策略是第一次查询返回一个正常的IP比如攻击者自己的服务器第二次、第三次或特定用户查询时又返回一个内网IP比如127.0.0.1或192.168.1.1。浏览器在同源策略下本来不能直接访问内网资源但如果你访问了攻击者的页面页面脚本里请求同一个域名解析结果突然指向内网浏览器就觉得这是同一个源于是放行攻击脚本就可以借机探测或操作内网服务。这种攻击在物联网时代杀伤力显著。很多智能设备的管理后台跑在局域网IP的80端端口上没有任何CSRF防护或基于域名的鉴权DNS重绑定直接就能打成“跨域”控制中继。即便没有真实的内网服务攻击者也能通过重绑定扫描内网端口绘制拓扑。防御DNS重绑定最干净的办法是服务端验证HTTP请求里的Host字段和实际IP是否匹配并拒绝未预期的内网请求。同时可以用浏览器插件或企业终端策略禁用异常域名重绑定。如果你是自己写服务务必给内网管理端加上强认证和CSRF Token至少让脚本拿不到可用的Session。3. 怎么判断你的DNS系统正在被攻击排查实录3.1 常见异常指标与日志特征很多人问我怎么知道自己是不是被攻击了其实DNS攻击的异常指标比想象中明显只是没被注意到。我把这些指标整理成了一张表方便你自己对标指标正常情况异常情况查询失败率小于1%突然飙到5%以上或全失败响应延迟个位数毫秒到几十毫秒出现数秒级超时或抖动缓存命中率通常60%以上骤降至10%以下怀疑缓存被清请求类型比例以A/AAAA为主ANY或TXT记录异常多特定域名查询量无明显热点某个域名请求量爆炸式上升响应内容预期IP解析结果突然指向陌生IP段日志层面DNS服务器最常见的是大量“formerr”格式错误和“timeout”。如果同一客户端IP在短时间内对同一个不存在的记录反复查询很像在试探你的缓存行为。缓存投毒后你会看到日志里出现对同一域名的大量重复查询但都命中了一个异常的解析结果。放大攻击场景下你的服务器日志会记录大量来自随机源地址的ANY查询并且全是正常业务不用的类型。3.2 一个模拟案例的排查流程说个我经历过的模拟攻防场景。某天下午业务群突然有人说“公司官网打不开”但能上微信。我第一反应是本地DNS缓存问题让同事清理缓存结果没用。接着我打开终端直接dig公司域名发现返回了一个完全陌生的IP再用公共DNS解析返回却是正确IP基本可以判定是链路或本地递归服务器被污染。排查流程大概是第一步确认是本机还是服务器问题。dig www.example.com noall answer对比不同解析器结果。第二步抓包看链路是否被劫持。tcpdump -i eth0 host 10.2.3.4 -c 50重点看回应包的源IP和ID是否符合预期。如果包里有明显高于真实查询次数的伪造响应八九不离十是投毒。第三步检查递归服务器缓存。如果用的是BIND或Unbound清空缓存后重新解析观察是否恢复正常。不恢复正常就进一步看面向外部的查询确认是不是权威源出了问题。第四步检查服务器配置和历史日志。querylog打开后逐个核对外部查询尤其注意非标准端口或高频随机子域。那次最终定位到内网一台Windows机器被装了后门反复对外发出大量特定域名查询配合DNS隧道在偷数据。整个过程前后不到半小时但如果没有会看日志的习惯很可能只是重启电脑了事。4. 防御与加固踩坑之后的经验总结4.1 基础加固从配置层面堵漏洞我见过太多防火墙买得贼贵、性能拉满但DNS配置裸奔的公司。基础加固不复杂但每一条踩过坑的都值得写下来。递归与权威分离对外只开放权威域名服务的端口递归查询仅限内网IP段。BIND里用allow-recursion { 内部网段; };免得变成放大器。限制ANY查询多数业务根本不需要ANY响应。在配置里直接禁止或限制响应大小可以降低放大倍数。开启端口随机化要么升级版本要么显式配置随机源端口。这能直接提升投毒难度。使用DNSSEC虽然部署成本高但对关键域至少签个ZSK/SKS很多托管DNS云服务现在都支持一键开启比自己搓证书方便。配置访问控制策略在云防火墙或安全组层面限制哪些外部IP可以访问你的53端口业务发起的递归只允许内网DNS出口。加固每台终端把本地Hosts文件锁起来管理路由器的密码不用的DNS转换工具别乱装。这里有一个非常容易翻车的点很多人为了性能把TTL设成0结果每次请求都去权威刷新一旦权威源抖动业务全断但TTL设太长投毒后的影响时间也长。折中方案是A记录1800秒MX记录3600秒动态记录用自动刷新机制。4.2 监控与应急预案别等出事了才动手攻击往往发生在周末凌晨所以监控和预案才是真正的护城河。我是一个绝对支持“先建基线再设阈值”的人没有基线任何告警都是放屁。监控层面至少需要三块第一是服务器性能监控包括CPU、内存、网络流量和53端口连接数第二是DNS业务质量监控定期主动探测解析延迟和失败率第三是数据层监控重点记录查询类型、异常域名、缓存命中率变化。开源方案里Prometheus配合blackbox_exporter可以轻松搞定主动探测Exporter里还能带一个dns_query探针直接测域名解析结果。如果怀疑被投毒建议加一个“黄金对比”任务定期用可靠的递归服务器解析你的关键域名和自己服务器的结果比对有偏差就告警。应急预案至少要写清楚三件事谁负责处理、怎么临时切换流量、如何回滚配置。实操里我吃过一次亏某个业务DNS被大流量打挂了按预案切到备用线路但备用线路配置缺了一个老域名的记录导致部分客户访问异常。所以预案切流量之前务必做一次完整配置对比重点检查记录数量、类型、TTL是否一致。5. 常见问题速查与避坑清单5.1 攻击类型速查表我把前面讲过的类型整理成一个速查表方便团队里新手快速定位问题。攻击类型典型特征主要危害首选应对缓存投毒同一域名大量重复查询、结果IP异常把用户导向钓鱼站、业务瘫痪清缓存、开DNSSEC、随机化端口DNS劫持本机独立解析与公共DNS结果不同流量被监听、账号密码泄露检查路由器/网关、启用DoH/DoT放大攻击出口流量暴涨、大量ANY查询DDoS打垮带宽、业务不可用清洗流量、关闭开放递归、限ANYDNS隧道高频随机子域、TXT记录占比高数据外传、隐蔽远控封禁异常域名、限制直接外联53重绑定目标域名解析结果忽内忽外绕过同源策略攻击内网设备服务端校验Host、管理端加固认证5.2 我踩过的几个坑与额外心得第一个坑是“全怪DNS”。遇到网站打不开了第一反应就冲到递归服务器那边排查。后来发现HTTP服务本身挂了也会表现为DNS解析慢因为浏览器要等待连接超时。所以排查顺序一定要先分网络、再分DNS、最后才分应用别让DNS背锅。第二个坑是“过度防御”。也给一台内部DNS服务器做了完整的ANY限制、递归ACL结果把上游某台合法监控设备的查询也挡了害得监控数据断了一晚。配置ACL前一定先问清楚有哪些合法消费方再写规则。第三个坑是日志量过大。开启querylog后每秒几万条查询记录直接把磁盘写满报警电话连环追命。建议要么用远程日志服务要么只对特定客户端IP抓包别全量记录。最后分享两个小白也能上手的自查技巧。一个是手动清理DNS缓存不同系统命令不同Windows用ipconfig /flushdnsmacOS用sudo killall -HUP mDNSResponderLinux用systemd-resolve --flush-caches方法虽土但很有效。另一个是偶尔手动改下DNSSEC状态再改回来能逼你熟悉自己的权威服务器配置出问题时恢复速度会快很多。DNS攻击既没有想象中神秘也绝不能掉以轻心。从我个人的经验看大多数企业最缺的不是新技术而是把基础配置做干净的耐心。下次再收到“DNS解析异常”的报警先别急着动Config翻一遍你写的这篇盘点对照排查大概率能节约半天时间。