| 编辑推荐: |
本文给大家好好聊聊DNS相关的各种攻击，包括：DNS协议基础，DNS request
flood攻击与防御等相关内容。
本文来自于华为企业互动社区，由火龙果软件Anna编辑、推荐。
|
|
0x01 DNS协议基础
要想弄明白DNS攻击的原理，就要先明白DNS协议的基础，我们还是从DNS协议本身讲起。DNS由RFC1034、1035协议定义规范，属于应用层协议。在前一篇中，我们也说了，DNS域名解析是互联网上非常重要的一项服务，我们每天上网都伴随着大量的DNS服务来支撑。在Internet上，用户更容易记住的是域名，但是网络中的计算机互相进行访问是通过IP地址，DNS最常用的是给用户提供域名解析服务，将用户的域名解析成网络上能够访问的IP地址。
DNS报文格式
下面结合DNS查询报文和响应报文的抓包信息来看理解一下报文格式中的几个关键字段，先看一下DNS查询报文的抓包：
DNS报文由12字节长的首部和4个长度可变的字段组成。标识字段由客户端程序设置并由服务器返回结果，客户端通过标识来确定响应与查询是否匹配。报文中涉及的字段很多，我们重点解释几个和本节相关的字段。
UDP：表示DNS查询基于UDP协议传输数据。DNS服务器支持TCP和UDP两种协议的查询方式。
Destination port：目的端口默认是53。
QR：0表示查询报文；1表示回应报文。
TC：表示“可截断的”。如果使用UDP时，当应答报文超过512字节时，只返回前512个字节。
通常情况下，DNS查询都是使用UDP查询，UDP提供无连接服务器，查询速度快，可降低服务器的负载。当客户端发送DNS请求，并且返回响应中TC位设置为1时，就意味着响应的长度超过512个字节，而仅返回前512个字节。这种情况下，客户端通常采用TCP重发原来的查询请求，并允许返回的响应报文超过512个字节。直白点说，就是UDP报文的最大长度为512字节，而TCP则允许报文长度超过512字节。当DNS查询超过512字节时，协议的TC标志位会置1，这时则使用TCP发送。
Queries：表示DNS请求的域名和类型。
再来看一下DNS回应报文的抓包：
在回应报文中，比查询报文多了后三个字段：回答字段、授权字段和附加信息字段。其中回答字段是放置的域名对应的IP地址等信息。
Name：DNS查询中的请求域名。
Type：每一个查询都有一个查询类型，每一个响应也都有一个类型。这个类型大约有20多种，但是很多种类型现在已经过时了。最常用的查询类型是A类型，表示期望获得查询域名的IP地址。查询类型也可以是CNAME，这个在后面的详细介绍。
TTL：生存时间，表示客户端保留该解析资源记录的时间。
DNS交互
假设一个用户要去华为商城买个手机，那么从他在浏览器上敲下华为商城域名，到打开商城网页，这短暂的一瞬间，其实发出的DNS请求报文已经经历了下面这几步查询过程：
为了便于理解，我们简化一下DNS报文交互的流程。像递归服务器这种有官方域名授权的服务器，我们暂且把它统一归类为“授权服务器”。这样DNS服务就可以分为两大类：
一种是授权存储域名和IP地址映射关系的授权服务。
一种是临时存放域名和IP地址映射关系的缓存服务。
DNS查询通常都是基于UDP协议的，这就导致了在查询过程中缺少验证机制，容易被黑客利用。下面，我们就分析一下这两类服务可能面临的DNS攻击风险。
第一类：黑客伪造客户端源IP发送大量的DNS请求报文，造成DNS request flood攻击。DNS
request flood是当前最常见的DNS攻击，这类攻击可以针对缓存服务器，也可以针对授权服务器。
第二类：黑客伪造成授权服务器发送大量的DNS回应报文，造成DNS reply flood攻击。
第三类：篡改某些网站的域名和IP地址对应关系，导致用户访问被导向至钓鱼网站、**网站等。
第四类：向DNS服务器发送大量错误格式的DNS异常报文，或者发送大量超长DNS报文，导致DNS服务器处理这些报文时出现异常，拒绝正常服务。
当然了，DNS的查询过程主要是基于UDP协议的，少量基于TCP协议，所以除了应用层攻击外，可能也会遭受传输层的TCP或UDP类攻击，比如SYN
flood、UDP flood等等。TCP和UDP类的攻防会在后续的专题中详细介绍，今天我们只重点讲解DNS类的攻击和防御。
上一节暴风影音案例中，我们介绍一些和案例本身相关的DNS攻击，以及适合此场景的防御措施。其实DNS的攻击和防御措施远不止那些，今天我们就详细介绍一下最常见的DNS
request flood攻击以及相应的防御措施。
0x02 DNS request flood攻击与防御
DNS request flood攻击原理其实很简单，就是黑客控制僵尸网络向DNS服务器发送大量的不存在域名的解析请求，最终导致服务器因大量DNS请求而超载，无法继续响应正常用户的DNS请求，从而达到攻击的目的。
在DNS request flood攻击过程中，攻击的目标可能是DNS授权服务器，也可能是DNS缓存服务器。黑客伪造的客户端IP地址可能是虚假源IP地址，也可能是现网真实存在的IP地址。如果攻击的是DNS授权服务器，大量不存在的域名解析请求会导致服务器应接不暇，最终耗尽服务器性能；如果攻击的是缓存服务器，同时会导致缓存服务器不停的向授权服务器发送这些不存在域名的解析请求，一收一发更加重服务器的负担，直到最终导致服务器瘫痪。
对于缓存服务器和授权服务器，虽然都是DNS request flood攻击，但由于请求的客户端类型不同，所以防御的手段也不同。对于缓存服务器，正常向它发送DNS请求的是上网的终端用户，所以防御过程中，需要判定的是这个DNS请求是否由真实、正常的浏览器客户端发出；而对于授权服务器，向它发送DNS请求的可能就是缓存服务器了。所以对于不同的对象，认证方式当然也就不同了。
我们先从缓存服务器说起，看看华为Anti-DDoS系统是怎么防御DNS request flood攻击的。Anti-DDoS系统最初防御DNS
request flood采用的方式是TC源认证方式。
TC源认证
前面我们也讲过了，DNS查询有TCP和UDP两种方式，通常情况下，DNS查询都是用的UDP协议，此时TC位置0，但是可以通过将TC位置1，将查询协议改为TCP方式。Anti-DDoS系统利用的就是通过修改DNS报文中的TC标识位，对客户端进行认证。
当客户端发送的DNS请求报文超过告警阈值后，Anti-DDoS系统启动源认证机制。
Anti-DDoS系统拦截DNS请求，并进行回应，要求客户端以TCP方式重新发起DNS查询。
如果这个源是虚假源，则不会正常响应这个DNS回应报文，更不会重新通过TCP方式重新进行DNS查询。
如果是真实客户端，则会重新发送SYN报文，请求建立三次握手。
Anti-DDoS系统对客户端源进行TCP层面的认证。源认证通过，客户端源IP加入白名单。
客户端重新请求建立三次握手，Anti-DDoS系统将客户端第二次发送的三次握手请求直接放行，送给服务器。
客户端与服务器之间建立三次握手成功，并通过TCP方式完成本次DNS查询。
我们再来结合一组抓包看一下。
1、客户端向DNS服务器发送DNS请求，从抓包中可以看到，DNS请求报文基于UDP协议，TC标记位是0，请求的域名是www.ddos.com。
2、Anti-DDoS系统代替服务器进行回应，并将TC标记位设置为1，希望客户端通过TCP方式重新发起DNS查询。
3、从这张图可以看出客户端重新用TCP方式进行了DNS查询。
这种方式是防御DNS request flood的一种基本的认证模式，适用于客户端是浏览器的认证。随着这种防御方式在现网中的应用，其限制也渐渐的显现出来。比如现网中有一些真实客户端，并不支持通过TCP方式进行DNS查询，这样的话，这种防御方式就不适用了。所以现在对于缓存服务器的DNS
request flood已经逐渐被另一种“被动防御”模式所取代。
被动防御
其实被动模式，就是“以不变应万变”，Anti-DDoS系统利用DNS协议的重传机制，不对DNS查询报文进行反弹，而是直接不处置，直接丢弃，然后看客户端是否重传。
1、Anti-DDoS系统在第一次收到DNS请求后，就会记录DNS请求的域名、源IP等基本信息，并HASH成一个值，记录到系统一张表里。
2、后续一定时间戳内，如果再收到这个HASH值相同的DNS请求，就认定为重传包，放行。时间戳会随着收到的每一个相同HASH值的DNS请求包而不断的刷新。
我们再来抓包看看：
1、第一次DNS请求。这个DNS查询报文会被Anti-DDoS系统丢弃，并且不回应任何报文。
2、第二次DNS请求。客户端一段时间内没有收到DNS回应报文，重新发送DNS请求。
被动防御模式是一种比较通用的防御手段，适用于攻击源不断变换的DNS请求攻击。对客户端的类型没有限制，无论缓存服务器还是授权服务器都适用。那么对于授权服务器，除了被动模式外，还有一种常用的防御模式CNAME。
CNAME模式
授权服务器通常直接服务的“客户”是缓存服务器，是个服务器，而不是客户端的浏览器。所以在源认证的时候，和缓存服务器的防御机制不同。授权服务器利用的是DNS的CNAME（别名）机制。
DNS协议中，允许将多个域名映射到同一个IP地址，此时可以将一个域名做A记录指向服务器IP，然后将其他域名作为别名，指向之前做A记录的域名上。这样类型的存在是为了解决IP地址变更时，不必一个一个域名做更改指向。只需要更改A记录的那个域名到新IP上，其他别名将自动更改到新IP地址上。
下面我们就看看Anti-DDoS系统如何利用CNAME机制进行源认证，这种方式也就是我们上一篇中介绍过的重定向方式。
再来看一组抓包。
1、客户端发送DNS查询的请求，查询的域名是www.ddos.com。
2、Anti-DDoS系统代替服务器进行回应，并将www.ddos.com的域名重定向为GksbtkNgmpldezpe.www.ddos.com，让客户端重新请求这个别名。
3、客户端重新请求重定向后的新域名：GksbtkNgmpldezpe.www.ddos.com。客户端正常响应这个重定向域名后，Anti-DDoS系统对客户端的源认证就通过了。
4、Anti-DDoS系统第二次重定向，将GksbtkNgmpldezpe.www.ddos.com再冲定向回最初访问的域名www.ddos.com。
5、客户端重新请求www.ddos.com，这次发送的DNS请求会直接送到服务器。后续服务器会回应这个域名的解析地址，完成此次DNS查询。
了解了这三种模式后，我们再来回顾一下。大家不难发现，无论是TC源认证、被动防御还是CNAME模式，其实都是利用DNS协议对客户端是否真实存在所做的源探测。其中，TC源认证利用的是DNS协议的TCP查询方式；被动模式利用的是DNS协议的重传机制；而CNAME则是利用DNS的别名机制。
好啦，这一期我们就先讲到这里，下一期，我们再继续学习DNS reply flood攻击的防御。
|
