尧图网站建设 
1. 为什么攻击者总盯上DNS先想明白这个基础设施的命门做了这么多年网络运维和安全评估我越来越觉得DNS被人低估了。说句实话很多公司对防火墙、入侵检测那套投了大量预算却把DNS当免费的电话本看基本放任不管。直到出了事才追悔莫及。DNSDomain Name System的核心作用就一个把人类好记的域名翻译成机器能理解的IP地址。但问题恰恰出在这里——这个翻译过程发生在几乎每一台联网设备的每一次网络请求之前也就是说如果DNS出问题你后续所有的HTTP、HTTPS、邮件、文件传输全部白搭。攻击者显然也明白这个道理所以DNS成了网络攻击中最诱人的目标之一攻陷DN S等于拿到了整座大楼的钥匙。而且更要命的是DNS协议本身是上世纪80年代设计的它默认信任所有的应答数据没有内置任何认证机制。底层协议天生缺心眼再加上运维重视度不够两者叠加造成了今天我们看到的形形色色的DNS攻击手段。这篇文章我想从实际攻防视角出发系统地盘点一下现阶段最常见的几类DNS攻击把原理、场景、危害和防御思路一次讲清楚。适合运维工程师、安全初入门者以及所有负责公司基础设施的同行参考。先给大家吃个定心丸应对DNS攻击不需要都靠天价安全设备搞明白原理之后很多基础层面的加固动作自己就能做。下面我们一个一个来拆。2. DNS劫持与缓存投毒篡改名字解析结果的经典老路2.1 两者到底是什么关系很多人把DNS劫持和DNS缓存投毒混为一谈或者觉得这俩是一回事其实严格来说它们是包含和被包含的关系。DNS劫持是一个更大范围的概念泛指一切你无法获得正确DNS解析结果的攻击行为。它可能发生在网络链路的任意环节包括本地主机hosts文件被篡改路由器DNS设置被恶意修改ISP或网络出口设备被人为做了重定向运营商层面的HTTP劫持严格说这个不是DNS层面但用户感知类似。**DNS缓存投毒Cache Poisoning**则是劫持中最典型、技术含量最高的一种手法攻击目标直接指向DNS服务器自身。攻击者利用DNS查询过程中的漏洞伪造一个应答包让权威服务器或递归服务器错误地缓存下域名A对应到恶意IP这样的记录。缓存一旦生效所有向这台服务器发起查询的用户都会被骗到钓鱼站或恶意服务器上直到缓存过期。2.2 投毒攻击的技术内核从Kaminsky攻击说起这里必须提到2008年Dan Kaminsky公布的那个著名漏洞也就是Kaminsky攻击。在那之前大家对DNS投毒的理解还停留在猜测16比特的查询ID加上端口号这种难度极高的操作上。Kaminsky的突破在于他利用了一个几乎没人当回事的漏洞——递归服务器会接受**附加区Additional Section**里的额外域名解析记录。攻击者可以不断向目标DNS服务器发起一个根本不存在的域名解析请求比如xiaoming.test.example.com同时伪造大量应答包里面除了包含查询结果之外还附带一条example.com的权威NS记录指向我控制的服务器的附加信息。因为查询的是一个不存在的随机子域缓存里没有服务器必须发起递归查询攻击者就可以反复地盲打Blind Spoofing。只要有一次猜中查询ID和源端口后续整个example.com的控制权就被绑架了。打个比方你把传真发给对方公司前台前台不核对面孔就直接转交领导攻击者伪装成领导把新的通讯录塞给前台从此整个公司都照着假通讯录打电话。这个攻击给整个行业最大的教训就是当年DNS设计者根本没有想到缓存服务器会把一个查询附带返回的额外记录当成可信信息。虽然如今主流递归服务器BIND 9.9、Unbound、Knot Resolver等默认启用0x20编码随机化、端口随机化、DNSSEC验证等措施Kaminsky原始利用已经很难打穿了但它的设计思路至今仍有借鉴意义——凡是信任附加数据的协议都有被类似手段污染的风险。2.3 现实中的主要注入场景现在纯靠协议漏洞发起的缓存投毒在大厂公共DNS上基本不可能成功但在以下几种现实中依然常见内网DNS服务器版本老旧补丁跟不上DNS服务器直接暴露在公网没有做访问控制使用默认端口、固定ID投毒成本极低路由器或家用网关的DNS转发功能有漏洞被黑客批量修改DNS为恶意IP。我实际见过一个案例某公司分支机构的路由器管理密码使用默认admin/admin被攻击者登录后把上行DNS改成了一台恶意服务器。之后整个分支机构的终端每打开一个页面域名解析都经过黑客控制设备弹出的安全警告页面和假登录框做得和真实系统一模一样。最后是财务反馈网银登录后账户资金异常排查了好久才发现DNS被改了。这个案例里根本没有用任何高深协议攻击纯粹是管理松懈。2.4 防御思路会话加密与验证两条腿走路防御缓存投毒主流的方案我总结为启用DNSSEC域名系统安全扩展对DNS记录做数字签名递归服务器可以验证应答的真伪。这个落地难度不大但需要权威侧和递归侧都支持国内很多域名注册商支持一键开启DNSSEC建议有独立域名的都开升级递归软件到支持0x20随机化、端口随机化的版本同时避免在公网开放53端口定期审计解析记录对比权威源与本地缓存发现异常立即刷新缓存内网DNS绝不使用默认管理口令限制管理地址来源。注意DNSSEC不是万能的它只能防御数据在传输过程中被篡改不能防御合法服务器被入侵后篡改记录。对于后者还得靠服务器自身加固和监控。3. DNS反射放大攻击以小博大的流量洪峰制造机3.1 为什么DDoS界最偏爱DNS如果说投毒攻击是骗人那DNS反射放大攻击DNS Reflection/Amplification Attack就是以软打硬的阳谋。它是目前大规模DDoS攻击中最常见的手法之一原因很简单DNS协议允许很小的查询包却返回很大的响应包而且源地址可以伪造IP Spoofing。这给了攻击者一个极好的算账方式攻击者准备一个伪造了源IP受害者IP的查询包发给大量开放的DNS服务器DNS服务器以为受害者本人在查询于是把完整的、包含大量记录的响应发往受害者的IP攻击者只需要消耗非常小的带宽受害者却被各路径汇聚而来的大流量淹没。有一个常被引用的数字一个61字节的查询包可能触发超过4000字节的响应放大倍数将近70倍。实际攻击中恶意攻击者更喜欢用ANY记录类型或**DNSSEC相关的记录如DNSKEY、RRSIG**来获得更高的放大倍数。一个能响应DNSSEC记录的权威服务器响应包轻松超过3KB放大倍数可高达100倍以上。3.2 攻击链路中的角色分析整个攻击链条里有四个角色角色作用受害者视角攻击者控制僵尸网络发送伪造源IP的查询包不可见开放递归/权威DNS服务器无差别响应所有查询请求被利用的打手受害者被伪造源IP指向的对象遭受流量侵袭ISP/骨干网络被动转发流量被动参与严重时链路拥塞最讽刺的是源IP伪造至今在IPv4网络中依然大量存在。虽然BCP38网络入口过滤规范早就提出路由器应阻止源地址不属于本网段的包但很多中小ISP根本没启用攻击者伪造源IP几乎没有障碍。IPv6因为地址结构特性伪造难度略高但也不是不可能。3.3 实战中怎么判断自己是不是被打如果你是运维人员发现服务器或者专线流量突然暴增可以从以下特征判断是否遭遇DNS放大攻击抓包看数据包大小分布大量响应包集中在500字节以上源端口集中在53端口目的IP是你的服务器IP但你的服务器并没有发起过相应的DNS查询源IP五花八门来自全球各地很多是知名公共DNS或大机构DNS。一旦确认最快缓解办法在防火墙或流量清洗设备上丢弃来自非预期DNS服务器的53端口UDP流量同时联系ISP做黑洞路由或流量清洗。另外通过NetFlow/sFlow数据找出高频源IP加入黑名单。3.4 从源头治理关闭开放的递归服务这类攻击能成立的最大土壤是互联网上大量存在的开放递归DNS服务器。我扫描过一些公网段发现很多老设备默认配置允许所有人递归查询包括很多工控路由器和家用路由。它们被植入恶意脚本后就成了天然的放大池。所以从防御角度我真心建议各位同行在自查时做一件事# 测试本机DNS是否对外开放递归查询 dig 你的服务器IP www.baidu.com tries1 timeout3如果返回了正确的解析结果而该IP本来只应该服务内网说明配置有误需要立即限制ACL访问控制列表。主流DNS软件都支持限制递归范围BINDallow-recursion { 内网网段; };Unboundaccess-control: 内网网段 allowWindows DNS区域传输和递归需要单独做安全配置。只要开放递归的服务器数量降下来攻击者能找到的打手就少了很多整个攻击的规模上限也随之被拉低。4. DNS隧道攻击披着合法外衣的数据走私通道4.1 一个文件传输的骚操作DNS隧道DNS Tunneling属于一种隐蔽信道Covert Channel攻击攻击者把数据隐藏在DNS查询和响应中绕过防火墙限制实现数据外传或命令与控制C2通信。为什么会想到用DNS信道因为大多数企业的防火墙允许53端口UDP流量从内网出去——没有DNS解析内网就没法上网总不能全封了吧。攻击者看中的就是这个不得不开的端口。举个最直观的例子假设攻击者已经控制了内网一台机器他拿到敏感数据后可以这样传出去把数据拆成小块编码成子域名形如secret-data-piece1.evil-server.com内网机器向攻击者控制的DNS服务器发起请求攻击者服务器把应答包中的数据段提取出来拼凑回原始数据。整个过程在防火墙看来就是普通的DNS查询流量不会引起任何告警。国外不少恶意软件在实测中都是靠DNS隧道维持C2通信长达数月不被发现。4.2 常用工具和关键指标行业内最出名的三款DNS隧道工具iodine主打高带宽能在DNS隧道上跑出IPv4网络最高可达约1Mbit/s的吞吐。适合需要传输较大数据的场景。dnscat2专为C2设计支持加密、命令控制、文件传输、端口转发。安全团队做红队演练时非常喜欢。C2 over DNS如Metasploit的payload以DNS查询频率为心跳适合低交互要求。不过DNS隧道也不是完全无声无息它有几个明显特征安全监控层面可以反向利用子域名长度异常正常业务域名的子域很少超过20~30个字符隧道流量常见50字符以上随机字符串查询频率异常每秒钟几十甚至上百次DNS查询远超正常终端行为TXT记录、ANY记录查询异常多因为隧道工具偏爱高容量记录类型单一设备在短时间内访问大量不常访问的冷门域名。4.3 怎么发现和阻断要发现DNS隧道纯凭人工看日志不现实数据量太大了。建议在DNS服务器上开启日志同时建立一套基线统计每个内网IP一天内的DNS请求数量、请求类型分布、子域名长度分布设置告警阈值比如单IP每分钟超过60次DNS请求、子域名平均长度超过38字符、出现连续9个以上base32编码字符iodine特征DNS全量日志接入SIEM与威胁情报做关联分析内网终端侧可以禁用非标准DNS出口把53端口访问全部收敛到企业DNS服务器限制直接向外部IP发送UDP 53流量。在实际部署中我推荐先在防火墙上限制仅允许内网DNS服务器访问外部53端口其他终端一律只能访问内网DNS这一条就能挡掉绝大多数DNS隧道。代价是要保证内网DNS的稳定性否则全公司上网都会受牵连。4.4 隧道防御的盲区这里必须说一个苦头如果攻击者的隧道流量被伪装得很隐蔽、频率很低单纯靠流量特征很难抓出来。所以更可靠的不是抓特征而是默认不信任——出站DNS只允许走内网递归服务器内网递归服务器只允许访问必要的权威域名这样无论隧道怎么伪装出口已经封死。控制信道比检测信道更有效。5. DNS重绑定攻击跨界穿透浏览器的内网漫游5.1 一条域名两张面孔DNS重绑定DNS Rebinding是很多Web安全和IoT安全测试中常见的一招。核心思路攻击者让同一个域名在不同DNS解析阶段返回不同的IP地址。具体过程这样的受害者访问攻击者网站http://evil.example.com第一次DNS解析返回攻击者服务器的真实公网IP浏览器加载页面中的JavaScript脚本随后向http://evil.example.com发起后续请求比如请求http://evil.example.com:8080/admin.html此时攻击者控制DNS服务器对第二次解析返回内网IP比如192.168.1.1因为浏览器的同源策略是以域名端口划分的并不管IP是否变化所以这个请求依然被视为来自evil.example.com的合法请求从而可以访问内网资源。看到问题了吗浏览器认为域名没变属于同一来源但实际上该域名已经被解析到了内网地址。攻击者相当于借助不严谨的DNS解析让受害者浏览器化身为内网代理去探测和攻击内网系统。原理拆开看并不复杂但是真正的难点在于DNS缓存的TTL生存时间控制。如果第一次解析结果在系统或浏览器缓存里存活太久第二次请求会被缓存拦截重绑定就失败了。攻击者的通用做法是把TTL设置成0或者极短如1秒让每次解析都发起新的查询。5.2 实际攻击场景攻陷一台打印机或摄像头最常见的重绑定攻击目标是各类内网物联网设备。很多IP摄像头、打印机、路由器的管理后台默认只信任内网访问没有登录防护或使用弱口令。利用DNS重绑定一个网页就能让受害者的浏览器去GET、POST这些设备的接口。比如某品牌摄像头有一个未授权/config/getCameraStatus接口攻击者先让自己的域名DNS解析指向公网服务器页面加载后JS脚本立刻访问该域名下的/config/getCameraStatus第二次解析直接换成摄像头所在网段的IP。请求成功摄像头配置被读取攻击者再通过后续脚本修改管理员口令设备直接被接管。这类攻击最坑的地方在于整个过程受害者只是在浏览网页完全无感知防火墙认为流量来自浏览器进程属于合法Web访问安全设备因为无法感知DNS变化的语义几乎不会告警。5.3 防御DNS重绑定的实操清单对于企业、家庭用户和IoT厂商防御侧有不同的侧重点浏览器侧Firefox和Chrome都曾尝试实现DNS引脚DNS Pinning即一旦一个域名解析为公网IP就永久固定该IP不允许重绑定。但实际效果一般遇到代理、多线路场景会误伤。现在的主流做法是配合Private Network Access私有网络访问Chrome 130逐步强制限制公网页面访问内网资源。应用侧服务器端校验Host头不要盲目信任HTTP Host头关键管理接口必须验证客户端IP是否来自内网但注意不能仅依赖REMOTE_ADDR也要检查X-Forwarded-For至少不被轻易绕过物联网设备管理后台务必加上强认证禁止裸奔接口。网络侧在企业边界防火墙上禁止内网DNS服务器向公网解析内网IP这个限制很难做。更实际的是对敏感管理网段做额外的访问控制确保即使浏览器发起了请求也会被防火墙的ACL拒绝。6. 被低估的黑流量NXDOMAIN攻击与随机子域攻击6.1 什么是NXDOMAIN攻击NXDOMAIN是DNS协议里的域名不存在响应代码。平时没多少人关注它但攻击者可以专门利用这个机制做手脚。方法很简单向受害者的权威DNS服务器发起大量针对不存在子域的查询。举个例子受害者是example.com攻击者制造海量随机子域名如aksdfh823.example.com、vbcxueu787.example.com……这些域名无一存在所以权威服务器每收到一条查询都要做一次完整的数据库查找、回复NXDOMAIN并写入日志。当查询量足够大时权威服务器的CPU和磁盘I/O首先打满日志盘被撑爆进而影响正常业务域名的解析。说实话这种攻击的强度比不上反射放大DDoS但是它有两个小优点被攻击者看中看起来非常像真实的扫描行为不太容易被流量清洗误杀很多权威服务器运营者对日志和递归查询没有做限额很容易被打出资源瓶颈。6.2 随机子域攻击的进阶版本水刑攻击水刑攻击Water Torture Attack是NXDOMAIN攻击的变种思路类似但攻击更持久、更隐蔽。攻击者控制的僵尸网络向受害者的权威DNS服务器发送极其大量的子域名查询频率可能持续数小时甚至数天每次都查询不同的随机域名。由于每个域名都是新的递归服务器没有缓存只能反复向上游权威服务器发起真实查询导致权威服务器负载持续高企。这类攻击对使用第三方DNS解析服务的站点影响相对较小因为DNS服务商有专门的抗DDoS清洗设备。但如果是自建权威DNS的企业一个小型团队运维的服务器打一个晚上基本就该瘫痪了。6.3 负载与缓存层面的缓解方案自建权威DNS的团队可以从这几个层面做防护启用RRLResponse Rate LimitingBIND 9.9、Knot Resolver均支持对相同来源IP的重复查询限速大幅降低无意义响应对查询类型做白名单限制比如只允许A、AAAA、MX、TXT等常用记录查询关闭不必要ANY/HTTPS/SVCB查询部署Anycast分布式DNS网络多个节点分摊流量单点负载大幅度下降设置合理的缓存TTL如果业务对域名变更不敏感A记录建议TTL设为300秒以上随机子域攻击打过来时递归侧缓存能挡掉一部分日志独立到专用存储避免日志I/O拖累DNS响应。对于使用云解析服务的团队建议提前联系DNS服务商确认他们的RRL、QPS限制阈值把业务当前的真实QPS上报确保正常业务流量不会误触限速。7. 从攻击类型反推防御架构落地一套分层防线以上聊了缓存投毒、反射放大、隧道、重绑定、NXDOMAIN这几类主流攻击现在把思路反过来站在防御者视角怎么设计一套能同时抵御这些攻击的DNS防护体系7.1 分层防线模型我推荐在三个层面做纵深防御层级防护目标关键技术手段出口层反射放大攻击、外部洪峰防火墙QoS限速、IDS/IPS、流量清洗、协议合规检查基础设施层缓存投毒、NXDOMAIN、重绑定DNSSEC、EMAI算法、限速RRL、优化缓存策略、ACL限制递归终端/用户层隧道、恶意DNS解析出站DNS收敛、应用层防火墙、主机EDR、DNS日志审计7.2 我推荐的自建DNS基础配置BIND示例如果你用BIND做递归或权威以下配置片段经过多轮实战验证能挡掉大部分常规攻击options { directory /var/named; recursion yes; allow-recursion { 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; }; // 只允许内网递归 allow-query { any; }; // 权威查询对公网开放 dnssec-validation auto; // 递归侧开启DNSSEC验证 rate-limit { responses-per-second 10; // RRL window 5; qps-scale 10; }; minimal-responses yes; // 减少附加区信息降低投毒与放大面 }; zone example.com IN { type master; file /var/named/example.com.zone; allow-update { none; }; // 不允许动态更新 allow-transfer { 10.0.0.10; }; // 只允许备机来同步 };这段配置里minimal-responses yes很多人容易忽略它默认不带多余的附加区记录对降低Kaminsky类攻击成功率和反射放大倍数都有帮助。rate-limit那段是RRL配置能有效限制随机子域洪水。7.3 监控和告警没有日志就没有真相DNS攻击往往隐蔽但不代表没有痕迹。我建议至少做以下几类监控解析成功率监控权威侧和递归侧分别监控解析成功/NXDOMAIN/超时比例一旦NXDOMAIN比例异常飙升大概率在被打随机子域QPS监控正常业务QPS的3倍以上波动要立即告警特定记录类型监控ANY和TXT记录占比异常需要考虑隧道或探测行为DNS响应延迟如果权威服务器响应延迟由2ms涨到200ms以上CPU、数据库查询链路中必有瓶颈。如果能上流量分析工具把数据包特征和行为基线关联一下上述攻击基本都能在早期发现。我个人的经验是越早发现防御成本越低因为反射放大和NXDOMAIN攻击的流量峰值往往在开始的几十秒内就会飙上来等到监控大屏红了再处理已经晚了。7.4 高危时期的应急复盘模板如果真的被打了我建议每个团队都提前写好应急响应SOP而不是临时抱佛脚确认攻击类型抓包、看日志、流量特征5分钟内判断根据类型选择动作反射放大→上游清洗ACL丢包NXDOMAIN→开启RRL限速隧道→封禁出站53排查失陷主机重绑定→内网设备应急加白名单升级浏览器同步回滚方案防止误伤正常业务事后复盘解析记录快照对比、日志回溯、找出失陷入口。这套SOP不仅适用于DNS攻击也能平移到其他基础设施攻击的应急处理上。8. 从热搜词看真实运维场景三个高频疑难的排查思路我在设计这篇文章时结合了不少近期搜索热度较高的DNS相关疑问从实际运维角度抽三个典型场景展开讲讲因为它们跟攻击防御关系很大如果你正好也在值班可以直接参考。8.1 为什么我的Windows主机能上网但虚拟机只能手动指定DNS这个场景非常多见。物理机上网正常NAT网络下的虚拟机却无法解析域名手动指定DNS如8.8.8.8又能通。我排查下来多数情况下是VMware或VirtualBox的NAT模式下虚拟机的DNS代理VMware NAT Service / vmnat没有正确从宿主机继承DNS配置。排查链路在虚拟机里执行ipconfig /all看是否有有效的DNS服务器如果显示为空白或虚机网关IP而非宿主机真实的DNS通常就是NAT代理配置失效手动在虚拟机网络适配器里显式配置DNS为宿主机网段内的DNS如企业内部DNS或公共DNS如果想要永久修复检查宿主机防火墙是否拦截了NAT服务访问宿主DNS的请求。这类问题与攻击无直接关系但对新人来说是理解DNS配置正确性影响一切解析的最好入门案例。8.2 在AD域内DC的网卡DNS该如何配置这个热搜词背后其实隐含了一个高频安全风险很多人把域控服务器的DNS指向了外部公共DNS或者多个DC之间DNS指错了。正确的做法是域内每台DC的网卡DNS首选指向自己或同站点的主DC备选指向另一台DC。绝对不能把主DNS指向公网DNS如果AD域内有三台DC最简单的配置是DC1的首选DNS指向DC1自己的IP备选指向DC2DC2首选指向DC2自己备选指向DC1DC3同理首选自己备选指向DC1或DC2因为AD域依赖DNS做服务定位SRV记录如果DC解析不了域内SRV记录域控复制、组策略下发都会异常从攻击视角看如果DC的DNS被改成外部恶意DNS攻击者可以获得部分内部域名解析路径进一步开展重绑定或钓鱼攻击。因此在组策略里统一管理DNS配置非常必要。8.3 Linux修改DNS后重启网络被还原热搜词里有一条linux修改dns后重启网络还原这也是典型配置问题。问题根源往往是你手工改了/etc/resolv.conf但这文件现在默认由NetworkManager或systemd-resolved管理重启网络服务后会自动覆盖。正确修改姿势如果使用NetworkManager用nmcli con mod Wired ipv4.dns 8.8.8.8 114.114.114.114修改连接配置再nmcli con up Wired生效如果使用systemd-networkd在对应.network文件里写DNS8.8.8.8如果使用纯静态配置的/etc/resolv.conf需要确保没有其他进程抢管理权可以chattr i /etc/resolv.conf加锁防止覆盖但建议优先用正规配置入口。虽然这不是攻击问题但这里想提醒一句很多DNS攻击之所以能得手往往不是因为攻击者技术多高而是配置不严谨给了可乘之机比如出站53端口未收敛、递归服务对外开放、手工改的DNS被回滚后真实解析链根本没有被监控。本质上DNS安全的一半是安全设备的事另一半是配置纪律的事。9. 结尾我这几年的实战体会做安全评估这些年我最大的感受就是DNS攻击很少以单一杀手锏的形式出现。现实中攻击者往往先用低慢型方式侦察比如DNS隧道或随机子域名探测摸清你内外网资产的解析关系然后再组合反射放大或重绑定来打关键节点。如果你只盯着某一种攻击的单一防御很容易顾此失彼。以我个人的经验防御优先级排序是这样的第一优先保证解析链路的正确性和纯净性——出站53端口收敛、递归ACL收紧、DNSSEC能开就开第二优先建立DNS日志与基线监控做到任何异常能在小时级内被发现第三优先针对具体攻击类型重绑定、隧道、反射放大配置针对性的检测规则和应急预案。最后再分享一个小技巧每一季度做一次DNS配置审计把所有DNS服务器配置、ACL、转发规则、缓存TTL拉出来对照基线review一遍。虽然听起来很基础但我处理过的好几起事故根因都是半年前改配置时留了个后门——基础打牢了大部分攻击根本够不到你的业务。 DNS攻击全解析：从缓存投毒到隧道，构建分层防御体系
1. 为什么攻击者总盯上DNS先想明白这个基础设施的命门做了这么多年网络运维和安全评估我越来越觉得DNS被人低估了。说句实话很多公司对防火墙、入侵检测那套投了大量预算却把DNS当免费的电话本看基本放任不管。直到出了事才追悔莫及。DNSDomain Name System的核心作用就一个把人类好记的域名翻译成机器能理解的IP地址。但问题恰恰出在这里——这个翻译过程发生在几乎每一台联网设备的每一次网络请求之前也就是说如果DNS出问题你后续所有的HTTP、HTTPS、邮件、文件传输全部白搭。攻击者显然也明白这个道理所以DNS成了网络攻击中最诱人的目标之一攻陷DN S等于拿到了整座大楼的钥匙。而且更要命的是DNS协议本身是上世纪80年代设计的它默认信任所有的应答数据没有内置任何认证机制。底层协议天生缺心眼再加上运维重视度不够两者叠加造成了今天我们看到的形形色色的DNS攻击手段。这篇文章我想从实际攻防视角出发系统地盘点一下现阶段最常见的几类DNS攻击把原理、场景、危害和防御思路一次讲清楚。适合运维工程师、安全初入门者以及所有负责公司基础设施的同行参考。先给大家吃个定心丸应对DNS攻击不需要都靠天价安全设备搞明白原理之后很多基础层面的加固动作自己就能做。下面我们一个一个来拆。2. DNS劫持与缓存投毒篡改名字解析结果的经典老路2.1 两者到底是什么关系很多人把DNS劫持和DNS缓存投毒混为一谈或者觉得这俩是一回事其实严格来说它们是包含和被包含的关系。DNS劫持是一个更大范围的概念泛指一切你无法获得正确DNS解析结果的攻击行为。它可能发生在网络链路的任意环节包括本地主机hosts文件被篡改路由器DNS设置被恶意修改ISP或网络出口设备被人为做了重定向运营商层面的HTTP劫持严格说这个不是DNS层面但用户感知类似。**DNS缓存投毒Cache Poisoning**则是劫持中最典型、技术含量最高的一种手法攻击目标直接指向DNS服务器自身。攻击者利用DNS查询过程中的漏洞伪造一个应答包让权威服务器或递归服务器错误地缓存下域名A对应到恶意IP这样的记录。缓存一旦生效所有向这台服务器发起查询的用户都会被骗到钓鱼站或恶意服务器上直到缓存过期。2.2 投毒攻击的技术内核从Kaminsky攻击说起这里必须提到2008年Dan Kaminsky公布的那个著名漏洞也就是Kaminsky攻击。在那之前大家对DNS投毒的理解还停留在猜测16比特的查询ID加上端口号这种难度极高的操作上。Kaminsky的突破在于他利用了一个几乎没人当回事的漏洞——递归服务器会接受**附加区Additional Section**里的额外域名解析记录。攻击者可以不断向目标DNS服务器发起一个根本不存在的域名解析请求比如xiaoming.test.example.com同时伪造大量应答包里面除了包含查询结果之外还附带一条example.com的权威NS记录指向我控制的服务器的附加信息。因为查询的是一个不存在的随机子域缓存里没有服务器必须发起递归查询攻击者就可以反复地盲打Blind Spoofing。只要有一次猜中查询ID和源端口后续整个example.com的控制权就被绑架了。打个比方你把传真发给对方公司前台前台不核对面孔就直接转交领导攻击者伪装成领导把新的通讯录塞给前台从此整个公司都照着假通讯录打电话。这个攻击给整个行业最大的教训就是当年DNS设计者根本没有想到缓存服务器会把一个查询附带返回的额外记录当成可信信息。虽然如今主流递归服务器BIND 9.9、Unbound、Knot Resolver等默认启用0x20编码随机化、端口随机化、DNSSEC验证等措施Kaminsky原始利用已经很难打穿了但它的设计思路至今仍有借鉴意义——凡是信任附加数据的协议都有被类似手段污染的风险。2.3 现实中的主要注入场景现在纯靠协议漏洞发起的缓存投毒在大厂公共DNS上基本不可能成功但在以下几种现实中依然常见内网DNS服务器版本老旧补丁跟不上DNS服务器直接暴露在公网没有做访问控制使用默认端口、固定ID投毒成本极低路由器或家用网关的DNS转发功能有漏洞被黑客批量修改DNS为恶意IP。我实际见过一个案例某公司分支机构的路由器管理密码使用默认admin/admin被攻击者登录后把上行DNS改成了一台恶意服务器。之后整个分支机构的终端每打开一个页面域名解析都经过黑客控制设备弹出的安全警告页面和假登录框做得和真实系统一模一样。最后是财务反馈网银登录后账户资金异常排查了好久才发现DNS被改了。这个案例里根本没有用任何高深协议攻击纯粹是管理松懈。2.4 防御思路会话加密与验证两条腿走路防御缓存投毒主流的方案我总结为启用DNSSEC域名系统安全扩展对DNS记录做数字签名递归服务器可以验证应答的真伪。这个落地难度不大但需要权威侧和递归侧都支持国内很多域名注册商支持一键开启DNSSEC建议有独立域名的都开升级递归软件到支持0x20随机化、端口随机化的版本同时避免在公网开放53端口定期审计解析记录对比权威源与本地缓存发现异常立即刷新缓存内网DNS绝不使用默认管理口令限制管理地址来源。注意DNSSEC不是万能的它只能防御数据在传输过程中被篡改不能防御合法服务器被入侵后篡改记录。对于后者还得靠服务器自身加固和监控。3. DNS反射放大攻击以小博大的流量洪峰制造机3.1 为什么DDoS界最偏爱DNS如果说投毒攻击是骗人那DNS反射放大攻击DNS Reflection/Amplification Attack就是以软打硬的阳谋。它是目前大规模DDoS攻击中最常见的手法之一原因很简单DNS协议允许很小的查询包却返回很大的响应包而且源地址可以伪造IP Spoofing。这给了攻击者一个极好的算账方式攻击者准备一个伪造了源IP受害者IP的查询包发给大量开放的DNS服务器DNS服务器以为受害者本人在查询于是把完整的、包含大量记录的响应发往受害者的IP攻击者只需要消耗非常小的带宽受害者却被各路径汇聚而来的大流量淹没。有一个常被引用的数字一个61字节的查询包可能触发超过4000字节的响应放大倍数将近70倍。实际攻击中恶意攻击者更喜欢用ANY记录类型或**DNSSEC相关的记录如DNSKEY、RRSIG**来获得更高的放大倍数。一个能响应DNSSEC记录的权威服务器响应包轻松超过3KB放大倍数可高达100倍以上。3.2 攻击链路中的角色分析整个攻击链条里有四个角色角色作用受害者视角攻击者控制僵尸网络发送伪造源IP的查询包不可见开放递归/权威DNS服务器无差别响应所有查询请求被利用的打手受害者被伪造源IP指向的对象遭受流量侵袭ISP/骨干网络被动转发流量被动参与严重时链路拥塞最讽刺的是源IP伪造至今在IPv4网络中依然大量存在。虽然BCP38网络入口过滤规范早就提出路由器应阻止源地址不属于本网段的包但很多中小ISP根本没启用攻击者伪造源IP几乎没有障碍。IPv6因为地址结构特性伪造难度略高但也不是不可能。3.3 实战中怎么判断自己是不是被打如果你是运维人员发现服务器或者专线流量突然暴增可以从以下特征判断是否遭遇DNS放大攻击抓包看数据包大小分布大量响应包集中在500字节以上源端口集中在53端口目的IP是你的服务器IP但你的服务器并没有发起过相应的DNS查询源IP五花八门来自全球各地很多是知名公共DNS或大机构DNS。一旦确认最快缓解办法在防火墙或流量清洗设备上丢弃来自非预期DNS服务器的53端口UDP流量同时联系ISP做黑洞路由或流量清洗。另外通过NetFlow/sFlow数据找出高频源IP加入黑名单。3.4 从源头治理关闭开放的递归服务这类攻击能成立的最大土壤是互联网上大量存在的开放递归DNS服务器。我扫描过一些公网段发现很多老设备默认配置允许所有人递归查询包括很多工控路由器和家用路由。它们被植入恶意脚本后就成了天然的放大池。所以从防御角度我真心建议各位同行在自查时做一件事# 测试本机DNS是否对外开放递归查询 dig 你的服务器IP www.baidu.com tries1 timeout3如果返回了正确的解析结果而该IP本来只应该服务内网说明配置有误需要立即限制ACL访问控制列表。主流DNS软件都支持限制递归范围BINDallow-recursion { 内网网段; };Unboundaccess-control: 内网网段 allowWindows DNS区域传输和递归需要单独做安全配置。只要开放递归的服务器数量降下来攻击者能找到的打手就少了很多整个攻击的规模上限也随之被拉低。4. DNS隧道攻击披着合法外衣的数据走私通道4.1 一个文件传输的骚操作DNS隧道DNS Tunneling属于一种隐蔽信道Covert Channel攻击攻击者把数据隐藏在DNS查询和响应中绕过防火墙限制实现数据外传或命令与控制C2通信。为什么会想到用DNS信道因为大多数企业的防火墙允许53端口UDP流量从内网出去——没有DNS解析内网就没法上网总不能全封了吧。攻击者看中的就是这个不得不开的端口。举个最直观的例子假设攻击者已经控制了内网一台机器他拿到敏感数据后可以这样传出去把数据拆成小块编码成子域名形如secret-data-piece1.evil-server.com内网机器向攻击者控制的DNS服务器发起请求攻击者服务器把应答包中的数据段提取出来拼凑回原始数据。整个过程在防火墙看来就是普通的DNS查询流量不会引起任何告警。国外不少恶意软件在实测中都是靠DNS隧道维持C2通信长达数月不被发现。4.2 常用工具和关键指标行业内最出名的三款DNS隧道工具iodine主打高带宽能在DNS隧道上跑出IPv4网络最高可达约1Mbit/s的吞吐。适合需要传输较大数据的场景。dnscat2专为C2设计支持加密、命令控制、文件传输、端口转发。安全团队做红队演练时非常喜欢。C2 over DNS如Metasploit的payload以DNS查询频率为心跳适合低交互要求。不过DNS隧道也不是完全无声无息它有几个明显特征安全监控层面可以反向利用子域名长度异常正常业务域名的子域很少超过20~30个字符隧道流量常见50字符以上随机字符串查询频率异常每秒钟几十甚至上百次DNS查询远超正常终端行为TXT记录、ANY记录查询异常多因为隧道工具偏爱高容量记录类型单一设备在短时间内访问大量不常访问的冷门域名。4.3 怎么发现和阻断要发现DNS隧道纯凭人工看日志不现实数据量太大了。建议在DNS服务器上开启日志同时建立一套基线统计每个内网IP一天内的DNS请求数量、请求类型分布、子域名长度分布设置告警阈值比如单IP每分钟超过60次DNS请求、子域名平均长度超过38字符、出现连续9个以上base32编码字符iodine特征DNS全量日志接入SIEM与威胁情报做关联分析内网终端侧可以禁用非标准DNS出口把53端口访问全部收敛到企业DNS服务器限制直接向外部IP发送UDP 53流量。在实际部署中我推荐先在防火墙上限制仅允许内网DNS服务器访问外部53端口其他终端一律只能访问内网DNS这一条就能挡掉绝大多数DNS隧道。代价是要保证内网DNS的稳定性否则全公司上网都会受牵连。4.4 隧道防御的盲区这里必须说一个苦头如果攻击者的隧道流量被伪装得很隐蔽、频率很低单纯靠流量特征很难抓出来。所以更可靠的不是抓特征而是默认不信任——出站DNS只允许走内网递归服务器内网递归服务器只允许访问必要的权威域名这样无论隧道怎么伪装出口已经封死。控制信道比检测信道更有效。5. DNS重绑定攻击跨界穿透浏览器的内网漫游5.1 一条域名两张面孔DNS重绑定DNS Rebinding是很多Web安全和IoT安全测试中常见的一招。核心思路攻击者让同一个域名在不同DNS解析阶段返回不同的IP地址。具体过程这样的受害者访问攻击者网站http://evil.example.com第一次DNS解析返回攻击者服务器的真实公网IP浏览器加载页面中的JavaScript脚本随后向http://evil.example.com发起后续请求比如请求http://evil.example.com:8080/admin.html此时攻击者控制DNS服务器对第二次解析返回内网IP比如192.168.1.1因为浏览器的同源策略是以域名端口划分的并不管IP是否变化所以这个请求依然被视为来自evil.example.com的合法请求从而可以访问内网资源。看到问题了吗浏览器认为域名没变属于同一来源但实际上该域名已经被解析到了内网地址。攻击者相当于借助不严谨的DNS解析让受害者浏览器化身为内网代理去探测和攻击内网系统。原理拆开看并不复杂但是真正的难点在于DNS缓存的TTL生存时间控制。如果第一次解析结果在系统或浏览器缓存里存活太久第二次请求会被缓存拦截重绑定就失败了。攻击者的通用做法是把TTL设置成0或者极短如1秒让每次解析都发起新的查询。5.2 实际攻击场景攻陷一台打印机或摄像头最常见的重绑定攻击目标是各类内网物联网设备。很多IP摄像头、打印机、路由器的管理后台默认只信任内网访问没有登录防护或使用弱口令。利用DNS重绑定一个网页就能让受害者的浏览器去GET、POST这些设备的接口。比如某品牌摄像头有一个未授权/config/getCameraStatus接口攻击者先让自己的域名DNS解析指向公网服务器页面加载后JS脚本立刻访问该域名下的/config/getCameraStatus第二次解析直接换成摄像头所在网段的IP。请求成功摄像头配置被读取攻击者再通过后续脚本修改管理员口令设备直接被接管。这类攻击最坑的地方在于整个过程受害者只是在浏览网页完全无感知防火墙认为流量来自浏览器进程属于合法Web访问安全设备因为无法感知DNS变化的语义几乎不会告警。5.3 防御DNS重绑定的实操清单对于企业、家庭用户和IoT厂商防御侧有不同的侧重点浏览器侧Firefox和Chrome都曾尝试实现DNS引脚DNS Pinning即一旦一个域名解析为公网IP就永久固定该IP不允许重绑定。但实际效果一般遇到代理、多线路场景会误伤。现在的主流做法是配合Private Network Access私有网络访问Chrome 130逐步强制限制公网页面访问内网资源。应用侧服务器端校验Host头不要盲目信任HTTP Host头关键管理接口必须验证客户端IP是否来自内网但注意不能仅依赖REMOTE_ADDR也要检查X-Forwarded-For至少不被轻易绕过物联网设备管理后台务必加上强认证禁止裸奔接口。网络侧在企业边界防火墙上禁止内网DNS服务器向公网解析内网IP这个限制很难做。更实际的是对敏感管理网段做额外的访问控制确保即使浏览器发起了请求也会被防火墙的ACL拒绝。6. 被低估的黑流量NXDOMAIN攻击与随机子域攻击6.1 什么是NXDOMAIN攻击NXDOMAIN是DNS协议里的域名不存在响应代码。平时没多少人关注它但攻击者可以专门利用这个机制做手脚。方法很简单向受害者的权威DNS服务器发起大量针对不存在子域的查询。举个例子受害者是example.com攻击者制造海量随机子域名如aksdfh823.example.com、vbcxueu787.example.com……这些域名无一存在所以权威服务器每收到一条查询都要做一次完整的数据库查找、回复NXDOMAIN并写入日志。当查询量足够大时权威服务器的CPU和磁盘I/O首先打满日志盘被撑爆进而影响正常业务域名的解析。说实话这种攻击的强度比不上反射放大DDoS但是它有两个小优点被攻击者看中看起来非常像真实的扫描行为不太容易被流量清洗误杀很多权威服务器运营者对日志和递归查询没有做限额很容易被打出资源瓶颈。6.2 随机子域攻击的进阶版本水刑攻击水刑攻击Water Torture Attack是NXDOMAIN攻击的变种思路类似但攻击更持久、更隐蔽。攻击者控制的僵尸网络向受害者的权威DNS服务器发送极其大量的子域名查询频率可能持续数小时甚至数天每次都查询不同的随机域名。由于每个域名都是新的递归服务器没有缓存只能反复向上游权威服务器发起真实查询导致权威服务器负载持续高企。这类攻击对使用第三方DNS解析服务的站点影响相对较小因为DNS服务商有专门的抗DDoS清洗设备。但如果是自建权威DNS的企业一个小型团队运维的服务器打一个晚上基本就该瘫痪了。6.3 负载与缓存层面的缓解方案自建权威DNS的团队可以从这几个层面做防护启用RRLResponse Rate LimitingBIND 9.9、Knot Resolver均支持对相同来源IP的重复查询限速大幅降低无意义响应对查询类型做白名单限制比如只允许A、AAAA、MX、TXT等常用记录查询关闭不必要ANY/HTTPS/SVCB查询部署Anycast分布式DNS网络多个节点分摊流量单点负载大幅度下降设置合理的缓存TTL如果业务对域名变更不敏感A记录建议TTL设为300秒以上随机子域攻击打过来时递归侧缓存能挡掉一部分日志独立到专用存储避免日志I/O拖累DNS响应。对于使用云解析服务的团队建议提前联系DNS服务商确认他们的RRL、QPS限制阈值把业务当前的真实QPS上报确保正常业务流量不会误触限速。7. 从攻击类型反推防御架构落地一套分层防线以上聊了缓存投毒、反射放大、隧道、重绑定、NXDOMAIN这几类主流攻击现在把思路反过来站在防御者视角怎么设计一套能同时抵御这些攻击的DNS防护体系7.1 分层防线模型我推荐在三个层面做纵深防御层级防护目标关键技术手段出口层反射放大攻击、外部洪峰防火墙QoS限速、IDS/IPS、流量清洗、协议合规检查基础设施层缓存投毒、NXDOMAIN、重绑定DNSSEC、EMAI算法、限速RRL、优化缓存策略、ACL限制递归终端/用户层隧道、恶意DNS解析出站DNS收敛、应用层防火墙、主机EDR、DNS日志审计7.2 我推荐的自建DNS基础配置BIND示例如果你用BIND做递归或权威以下配置片段经过多轮实战验证能挡掉大部分常规攻击options { directory /var/named; recursion yes; allow-recursion { 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; }; // 只允许内网递归 allow-query { any; }; // 权威查询对公网开放 dnssec-validation auto; // 递归侧开启DNSSEC验证 rate-limit { responses-per-second 10; // RRL window 5; qps-scale 10; }; minimal-responses yes; // 减少附加区信息降低投毒与放大面 }; zone example.com IN { type master; file /var/named/example.com.zone; allow-update { none; }; // 不允许动态更新 allow-transfer { 10.0.0.10; }; // 只允许备机来同步 };这段配置里minimal-responses yes很多人容易忽略它默认不带多余的附加区记录对降低Kaminsky类攻击成功率和反射放大倍数都有帮助。rate-limit那段是RRL配置能有效限制随机子域洪水。7.3 监控和告警没有日志就没有真相DNS攻击往往隐蔽但不代表没有痕迹。我建议至少做以下几类监控解析成功率监控权威侧和递归侧分别监控解析成功/NXDOMAIN/超时比例一旦NXDOMAIN比例异常飙升大概率在被打随机子域QPS监控正常业务QPS的3倍以上波动要立即告警特定记录类型监控ANY和TXT记录占比异常需要考虑隧道或探测行为DNS响应延迟如果权威服务器响应延迟由2ms涨到200ms以上CPU、数据库查询链路中必有瓶颈。如果能上流量分析工具把数据包特征和行为基线关联一下上述攻击基本都能在早期发现。我个人的经验是越早发现防御成本越低因为反射放大和NXDOMAIN攻击的流量峰值往往在开始的几十秒内就会飙上来等到监控大屏红了再处理已经晚了。7.4 高危时期的应急复盘模板如果真的被打了我建议每个团队都提前写好应急响应SOP而不是临时抱佛脚确认攻击类型抓包、看日志、流量特征5分钟内判断根据类型选择动作反射放大→上游清洗ACL丢包NXDOMAIN→开启RRL限速隧道→封禁出站53排查失陷主机重绑定→内网设备应急加白名单升级浏览器同步回滚方案防止误伤正常业务事后复盘解析记录快照对比、日志回溯、找出失陷入口。这套SOP不仅适用于DNS攻击也能平移到其他基础设施攻击的应急处理上。8. 从热搜词看真实运维场景三个高频疑难的排查思路我在设计这篇文章时结合了不少近期搜索热度较高的DNS相关疑问从实际运维角度抽三个典型场景展开讲讲因为它们跟攻击防御关系很大如果你正好也在值班可以直接参考。8.1 为什么我的Windows主机能上网但虚拟机只能手动指定DNS这个场景非常多见。物理机上网正常NAT网络下的虚拟机却无法解析域名手动指定DNS如8.8.8.8又能通。我排查下来多数情况下是VMware或VirtualBox的NAT模式下虚拟机的DNS代理VMware NAT Service / vmnat没有正确从宿主机继承DNS配置。排查链路在虚拟机里执行ipconfig /all看是否有有效的DNS服务器如果显示为空白或虚机网关IP而非宿主机真实的DNS通常就是NAT代理配置失效手动在虚拟机网络适配器里显式配置DNS为宿主机网段内的DNS如企业内部DNS或公共DNS如果想要永久修复检查宿主机防火墙是否拦截了NAT服务访问宿主DNS的请求。这类问题与攻击无直接关系但对新人来说是理解DNS配置正确性影响一切解析的最好入门案例。8.2 在AD域内DC的网卡DNS该如何配置这个热搜词背后其实隐含了一个高频安全风险很多人把域控服务器的DNS指向了外部公共DNS或者多个DC之间DNS指错了。正确的做法是域内每台DC的网卡DNS首选指向自己或同站点的主DC备选指向另一台DC。绝对不能把主DNS指向公网DNS如果AD域内有三台DC最简单的配置是DC1的首选DNS指向DC1自己的IP备选指向DC2DC2首选指向DC2自己备选指向DC1DC3同理首选自己备选指向DC1或DC2因为AD域依赖DNS做服务定位SRV记录如果DC解析不了域内SRV记录域控复制、组策略下发都会异常从攻击视角看如果DC的DNS被改成外部恶意DNS攻击者可以获得部分内部域名解析路径进一步开展重绑定或钓鱼攻击。因此在组策略里统一管理DNS配置非常必要。8.3 Linux修改DNS后重启网络被还原热搜词里有一条linux修改dns后重启网络还原这也是典型配置问题。问题根源往往是你手工改了/etc/resolv.conf但这文件现在默认由NetworkManager或systemd-resolved管理重启网络服务后会自动覆盖。正确修改姿势如果使用NetworkManager用nmcli con mod Wired ipv4.dns 8.8.8.8 114.114.114.114修改连接配置再nmcli con up Wired生效如果使用systemd-networkd在对应.network文件里写DNS8.8.8.8如果使用纯静态配置的/etc/resolv.conf需要确保没有其他进程抢管理权可以chattr i /etc/resolv.conf加锁防止覆盖但建议优先用正规配置入口。虽然这不是攻击问题但这里想提醒一句很多DNS攻击之所以能得手往往不是因为攻击者技术多高而是配置不严谨给了可乘之机比如出站53端口未收敛、递归服务对外开放、手工改的DNS被回滚后真实解析链根本没有被监控。本质上DNS安全的一半是安全设备的事另一半是配置纪律的事。9. 结尾我这几年的实战体会做安全评估这些年我最大的感受就是DNS攻击很少以单一杀手锏的形式出现。现实中攻击者往往先用低慢型方式侦察比如DNS隧道或随机子域名探测摸清你内外网资产的解析关系然后再组合反射放大或重绑定来打关键节点。如果你只盯着某一种攻击的单一防御很容易顾此失彼。以我个人的经验防御优先级排序是这样的第一优先保证解析链路的正确性和纯净性——出站53端口收敛、递归ACL收紧、DNSSEC能开就开第二优先建立DNS日志与基线监控做到任何异常能在小时级内被发现第三优先针对具体攻击类型重绑定、隧道、反射放大配置针对性的检测规则和应急预案。最后再分享一个小技巧每一季度做一次DNS配置审计把所有DNS服务器配置、ACL、转发规则、缓存TTL拉出来对照基线review一遍。虽然听起来很基础但我处理过的好几起事故根因都是半年前改配置时留了个后门——基础打牢了大部分攻击根本够不到你的业务。