常见的DNS攻击与防御措施

　　DNS查询通常都是基于UDP的，这就导致了在查询过程中验证机制的缺失，黑客很容易利用该漏洞进行分析。DNS服务可能面临如下DNS攻击风险： 黑客伪造客户端源IP地址发送大量的DNS请求报文，造成DNS request flood攻击。 黑客伪造成授权服务器发送大量的DNS回应报文，造成DNS reply flood攻击。 黑客篡改某些网站的域名和IP地址对应关系，导致用户访问被导向至其他网站。 黑客向DNS服务器发送大量错误格式的DNS异常报文，或者发送大量超长DNS报文，导致DNS服务器处理这些报文时出现异常，拒绝正常服务。
　　接下来我们就重点介绍安全领域比较常见的一些DNS攻击以及相应的防御措施。 DNS Request Flood攻击与防御
　　DNS request flood 的攻击原理是黑客控制僵尸网络向DNS服务器发送大量不存在的域名的解析请求，最终导致服务器因大量DNS请求而超载，无法继续响应正常用户的DNS请求，从而达到攻击的目的。
　　在DNS request flood的攻击过程中，攻击源可能是虚假源， 也可能是真实源；攻击目标可能是DNS授权服务器，也可能是DNS缓存服务器。针对不同类型的攻击源，采取的防御方式也不同。
　　针对于虚假源攻击缓存服务器，Anti-DDoS系统防御DNS request flood攻击最初采用的方式是TC源认证方式。
　　TC源认证
　　DNS查询有TCP和UDP两种方式。通常情况下，DNS查询都是基于UDP的，此时TC标志位置为0，可以通过将TC标志位置为1来将UDP改为TCP方式。华为Anti-DDoS系统就是通过修改DNS报文中的TC标志位，对客户端进行源认证的。
　　TC源认证交互过程如下：
　　Anti-DDoS设备基于目的地址对DNS Request报文的速率进行统计，当DNS Request报文的速率超过阈值时，启动源认证机制：拦截DNS请求，将TC标志位置为1并进行回应，要求客户端以TCP方式重新发起DNS查询。 如果这个源是虚假源，则Anti-DDoS系统不会正常响应这个DNS回应报文，更不会通过TCP方式重新进行DNS查询。 如果是真实客户端发送的请求，则Anti-DDoS系统会重新发送SYN报文，请求建立3次握手。Anti-DDoS系统对客户端源进行TCP层面的认证。源认证通过后，客户端源IP地址被加入白名单。客户端重新请求建立3次握手，Anti-DDoS系统将客户端第2次发送的3次握手请求直接放行，发送给服务器。 客户端与服务器之间建立 3 次握手成功，并通过 TCP 方式完成本次 DNS查询。
　　我们再来结合一组抓包深入了解一下此过程。
　　① 客户端向DNS服务器第一次发送DNS请求报文，DNS请求报文基于UDP,TC标志位是0，请求的域名是www. .com。
　　② Anti-DDoS系统代替Web服务器进行回应，并将TC标志位设置为1，希望客户端通过TCP方式重新发起DNS查询。
　　③ 客户端重新用TCP方式进行了DNS查询，源认证成功后，客户端以TCP方式与服务器建立连接，进行DNS查询。
　　这种方式是防御DNS request flood攻击的一种基本的认证模式，适用于客户端是浏览器的认证方式。但现网中有一些真实的客户端，并不支持通过TCP方式进行DNS查询，在这种情况下，这种防御方式就不适用了。所以，现在对于缓存服务器的DNS request flood攻击的防御模式已经逐渐被另一种＂被动防御＂模式所取代。
　　被动防御
　　被动防御模式利用DNS的重传机制，不反弹 DNS 查询报文，而是直接不处置，将其丢弃，然后看客户端是否重传。
　　如上图所示，当客户端发送的DNS请求报文速率超过告警阈值后，Anti-DDoS系统启动源认证机制：Anti-DDoS系统在第一次收到收到DNS请求报文后，记录DNS请求报文的域名、源 IP 地址等基本信息生成的HASH 值，并丢弃首包。后续一定时间戳内，如果Anti-DDoS系统再收到与这个HASH值相同的DNS请求报文时，就认定其为重传包，对其执行放行操作。
　　被动防御模式是一种比较通用的防御手段，适用于攻击源不断变换的 DNS 请求攻击。其对客户端的类型没有限制，无论缓存服务器还是授权服务器都适用。对于授权服务器，除了被动模式外，还有一种常用的防御模式——CNAME。
　　CNAME模式
　　授权服务器直接服务的＂客户＂通常是缓存服务器，而不是客户端的浏览器。所以在源认证的时候，授权服务器的防御机制和缓存服务器的机制不同。授权服务器利用的是DNS的CNAME（别名）机制。
　　CNAME（别名）:
　　DNS协议允许将多个域名映射到同一个IP地址上，此时可以将一个域名作为A记录指向服务器 IP 地址，然后将其他域名作为别名，指向之前有 A 记录的域名。这样类型的存在是为了保证在IP地址变更时，系统不必一个一个地对域名做出相应更改指向。应用此种机制后，系统只需要更改 A 记录的相应域名到新 IP 地址上，其他别名将自动被更改到新IP地址上。
　　CNAME机制进行源认证的交互过程如下：
　　Anti-DDoS 系统部署在授权服务器前，统计到达授权服务器的流量。流量达到告警阙值后，Anti-DDoS系统启动源认证，对请求报文进行重定向： 如果是真实存在的源，Anti-DDoS 系统会正常响应源认证报文，认证通过的后，Anti-DDoS 系统会将此源记录进白名单，后续这个源发送的请求将被直接通过，不需重复认证。
　　如果是虚假源，Anti-DDoS 系统不会正常响应源认证报文，所有它发送的请求报文也不会到达授权服务器。
　　接下来我们再以一组抓包为例了解一下此过程。
　　① 客户端发送DNS查询的请求，查询的域名是www. .com。
　　② Anti-DDoS系统代替Web服务器进行回应，并为www. .com的域名加了一个前缀将其重定向为GksbtkNgmpldezpe.www. .com，让客户端重新请求这个别名。
　　③ 客户端重新请求重定向后的新域名：GksbtkNgmpldezpe.www. .com。客户端正常响应这个重定向域名后，Anti-DDoS系统对客户端的源认证就通过了。
　　④ Anti-DDoS系统第2次重定向，将GksbtkNgmpldezpe.www. .com再重定向回最初访问的域名www. .com。
　　⑤ 客户端重新请求www. .com，这次发送的DNS请求报文会直接到达服务器。后续服务器会回应这个域名的解析地址，完成此次DNS查询。
　　DNS Reply Flood攻击与防御
　　DNS服务器收到DNS回应报文时，不管自己有没有发过解析请求，都会处理这些DNS回应报文。DNS reply flood攻击是黑客发送大量的DNS回应报文到DNS缓存服务器，导致缓存服务器因为处理这些DNS回应报文而耗尽资源，影响正常业务的过程。
　　DNS reply flood攻击大多都是虚假源攻击，黑客控制僵尸主机发出的DNS回应报文的源IP地址通常都是伪造的，是不存在的。所以在防御的时候，系统就可以从回应源IP地址的真假性切入，判定这个源IP是否是真实源。
　　针对这种攻击行为，Anti-DDoS 系统一般可使用源认证方式进行防御。源认证的方法就是通过构造一个DNS请求报文，试探客户端是否能正常回应的过程。
　　源认证过程如下： Anti-DDoS系统部署在受保护服务器前，并统计到达服务器的DNS回应报文。当到达服务器的DNS回应报文超过告警阈值时，Anti-DDoS系统启动防御。 Anti-DDoS系统收到某个源IP地址发来的DNS回应报文后，会重新构造一个新的DNS请求报文，然后记录构造查询报文的Query ID和源端口号。 如果是虚假源，则Anti-DDoS系统不会回应这个DNS回应报文，认证不通过。 如果是真实DNS授权服务器，则Anti-DDoS系统会重新回应DNS回应报文。 Anti-DDoS系统收到DNS回应报文后，会将其与之前记录的Query ID和源端口号进行匹配。如果完全一致，则系统判定此DNS回应报文就是反弹DNS请求报文的回应，源认证成功，将其加入白名单。后续这个源再发送的DNS回应报文都会被直接通过，直到白名单老化。
　　这是一种传统的DNS reply flood攻击和防御形式。近几年，还有一种升级版的DNS reply flood攻击，因为危害性较大，而备受安全界的关注，这就是DNS反射攻击。
　　如下图所示，黑客将自己的源IP地址伪造成被攻击目标（主机A）的IP地址，然后向网络中开放的DNS服务器发送大量的查询请求。黑客通过伪造DNS请求报文的源IP地址，控制DNS回应报文的流向，这些DNS回应报文都会被引导到被攻击目标，导致被攻击目标的网络拥塞，从而拒绝正常服务。全球有几千万台开放式的DNS服务器，这些服务器的接入带宽往往都比较高，而且，DNS回应报文的大小通常也是DNS请求报文的几倍甚至几十倍，因此，这种攻击可达到放大攻击的效果。
　　DNS反射攻击和前面介绍的传统DNS reply flood攻击有两点本质的不同。 传统DNS reply flood攻击的攻击目标一般是DNS缓存服务器；而DNS反射攻击的攻击目标一般是客户端。 传统DNS reply flood攻击大多是虚假源攻击，而在DNS反射攻击中，DNS请求报文都是真实的，DNS回应报文也都是真实的。
　　在这种情况下，源认证方式便不适用DNS反射攻击了。Anti-DDoS系统借鉴防火墙的会话表机制进行防御：当DNS请求报文经过Anti-DDoS系统时，Anti-DDoS 系统会创建一张会话表，记录 DNS 请求报文的这五元组信息。当Anti-DDoS系统再收到DNS回应报文时，就会查会话表。 如果它与会话表匹配，系统就判定它是真实的回应报文，允许它通过； 如果它与会话表不匹配，则系统判定这个回应报文为攻击报文，禁止它通过。
　　除了源认证和会话检查以外，DNS 攻击还可以通过限速的方式被防御。DNS 限速有两种：域名限速和源IP地址限速，针对DNS请求报文和DNS回应报文都生效。 指定域名限速
　　如果某个域名的DNS请求或回应报文速率过高，我们可以针对这个域名进行限速。通常某个域名遭受的访问量一直高，但突然有一天某访问量增长到平时的很多倍，此时我们可判断这个域名可能遭受了攻击。 源IP地址限速
　　如果某个源IP地址域名解析的速率过大，源IP地址限速就可以有针对性地限速这个源IP地址的DNS请求报文或者DNS回应报文，这样也不会对其他源造成影响。 DNS缓存投毒攻击与防御
　　路由器DNS劫持
　　黑客利用路由器的漏洞入侵受害者的路由器，篡改路由器中DNS服务器的地址，将该 DNS服务器地址指向恶意的 DNS服务器地址。
　　这种劫持方式不容易被发现，受害者只要输入真实域名或者合法网站地址，黑客就可将其重定向到一个恶意网站上。一旦这种情况发生，对于受害者来说后果是非常可怕的。他访问的每一个域名可能都是假的，看到的淘宝页面可能不再是淘宝页面，登录的网银可能也不再是网银，用户的各种敏感信息都会受到严重威胁。
　　对于这种方式，最有效的防御办法就是用户为路由器设置安全系数高的密码，然后定期修改密码。
　　授权服务器的修改
　　直接在授权服务器上修改域名和IP地址的映射关系是最直接的一种方式。黑客如果使用这种方式作为攻击的手段，需要通过特殊手段获取授权服务器的管理员权限，此方式的难度系数其实是非常大的。当然，也有另一种可能，就是出于某种特殊目的，管理员直接修改授权服务器上的域名和IP地址的映射关系，这种类型比较少见，也不是我们能控制的。
　　缓存服务器的修改
　　缓存服务器并不知道域名和IP地址的映射关系，一旦缓存服务器从授权服务器获取了映射关系后，会将其在内存中存储一段时间，直到记录老化。老化时间由DNS回应报文中的TTL决定。在这个有效期内如果再有客户端请求这个相同域名的解析，缓存服务器就会直接用缓存中的IP地址进行回应。记录老化以后，如果有客户端再次请求这个域名时，缓存服务器就会重新向授权服务器请求这个域名的解析。
　　缓存投毒攻击就是黑客伪造了恶意的DNS回应报文，导致缓存服务器无意中将恶意的域名和IP地址映射关系存储到自己的缓存中。当客户端再通过缓存服务器请求这个域名解析时，就会被指向恶意主机。
　　缓存投毒攻击过程如下图所示：
　　黑客向DNS缓存服务器发送一个不存在的子域名，请求解析。 缓存服务器查找本地缓存项查不到该域名，就会向授权服务器发起查询请求。 在授权服务器回应这个请求前，黑客就会伪造大量的DNS回应报文发向缓存服务器。
　　为了达到攻击的目的，黑客伪造的DNS回应报文的源IP地址必须是授权服务器的源IP地址，目的端口必须是缓存服务器的源端口；同时，DNS回应报文的Query ID和DNS请求报文的Query ID也要一致。
　　源IP地址和目的端口都很好伪造，但是成功伪造Query ID是有一定难度的。因此黑客伪造大量DNS回应报文时，会不断变换Query ID字段，一旦该Query ID先于授权服务器被发送给缓存服务器，缓存服务器就会将黑客发送的伪解析IP地址作为解析地址，保存到本地的缓存表中。 之后，当授权服务器再将真正的回应报文发送到缓存服务器时，缓存服务器也不会接收，直接将其丢弃。
　　在 DNS 缓存服务器中，如果仅仅伪造的子域名的解析地址是假的也没有多大影响。因为黑客利用投毒的这个子域名通常都是不存在的，正常客户端不会请求这个不存在的子域名。
　　但是如下图所示的DNS reply报文中：第一个框内是对该子域名的解析地址；第二个框内则是主域名 ddos.com 所在的 DNS 授权服务器和IP 地址的对应关系，授权服务器在回答缓存服务器请求时，也会将这部分内容一起发送过去，缓存服务器不仅仅会存储子域名的解析地址，还会将主域名的解析地址一并更新到自己的缓存列表中。这样后续再有客户端请求这个主域名时，也会一并被指向虚假的IP地址。
　　对于缓存投毒攻击，Anti-DDoS系统采用会话检查模式进行防御。在防御过程中，Anti-DDoS系统检查DNS回应报文的会话五元组信息（源IP地址、目的IP地址、源端口号、目的端口号、协议）,Query ID和域名是否与缓存服务器发出的DNS请求报文一致。
　　当缓存服务器向授权服务器发出域名查询请求时，Anti-DDoS 系统记录会话信息及请求报文中的Query ID和域名。 Anti-DDoS 系统收到回应报文后，需检查会话五元组、回应报文中的 Query ID和域名与请求报文中的Query ID和域名是否匹配。 如果报文命中会话五元组，并且Query ID和域名与记录的请求报文中的Query ID和域名匹配，则放行该报文。 如果报文没有命中会话，则被丢弃。 如果该报文命中会话，但是其域名或Query ID与请求报文不匹配，则该报文被丢弃，同时该会话被删除，以免后续投毒报文完成投毒攻击。