针对DNS防护方法进行DNS攻防测试，防护方法如下：
1.默认(限速)
2.TC重传
3.cname跳转
4.首次query丢弃
重点针对攻击原理、防护原理进行说明，针对测试提供参考方法。
DNS request flood攻击篇
1、DNS request flood攻击原理其实很简单，就是黑客控制僵尸网络向DNS服务器发送大量的不存在域名的解析请求，最终导致服务器因大量DNS请求而超载，无法继续响应正常用户的DNS请求，从而达到攻击的目的。
2、在DNS request flood攻击过程中，攻击的目标可能是DNS授权服务器，也可能是DNS缓存服务器。
3、黑客伪造的客户端IP地址可能是虚假源IP地址，也可能是现网真实存在的IP地址。
如果攻击的是DNS授权服务器，大量不存在的域名解析请求会导致服务器应接不暇，最终耗尽服务器性能。
4、如果攻击的是缓存服务器，同时会导致缓存服务器不停的向授权服务器发送这些不存在域名的解析请求，一收一发更加重服务器的负担，直到最终导致服务器瘫痪。
TC防护方法
1、当客户端发送的DNS请求报文超过告警阈值后，防护系统启动源认证机制。
防护系统拦截DNS请求，并进行回应，要求客户端以TCP方式重新发起DNS查询。
如果这个源是虚假源，则不会正常响应这个DNS回应报文，更不会重新通过TCP方式重新进行DNS查询。
2、如果是真实客户端，则会重新发送SYN报文，请求建立三次握手。
防护系统对客户端源进行TCP层面的认证。源认证通过，客户端源IP加入白名单。
3、客户端重新请求建立三次握手，将客户端第二次发送的三次握手请求直接放行，送给服务器。
4、客户端与服务器之间建立三次握手成功，并通过TCP方式完成本次DNS查询。
注意：
这种方式是防御DNS request flood的一种基本的认证模式，适用于客户端是浏览器的认证。
随着这种防御方式在现网中的应用，其限制也渐渐的显现出来。比如现网中有一些真实客户端，
并不支持通过TCP方式进行DNS查询，这样的话，这种防御方式就不适用了。
所以现在对于缓存服务器的DNS request flood已经逐渐被另一种“被动防御”模式所取代。
需考虑服务器的承受能力。对虚假源有效，对肉鸡无效。反向探测包数量等于攻击包数量，攻击包数量大+反向探测回堵死上行带宽。
1、其实被动模式，就是“以不变应万变”，利用DNS协议的重传机制，不对DNS查询报文进行反弹，而是直接不处置，直接丢弃，然后看客户端是否重传。
2、防护系统在第一次收到DNS请求后，就会记录DNS请求的域名、源IP等基本信息，并HASH成一个值，记录到系统一张表里。
3、后续一定时间戳内，如果再收到这个HASH值相同的DNS请求，就认定为重传包，放行。时间戳会随着收到的每一个相同HASH值的DNS请求包而不断的刷新。
4、被动防御模式是一种比较通用的防御手段，适用于攻击源不断变换的DNS请求攻击。
对客户端的类型没有限制，无论缓存服务器还是授权服务器都适用。那么对于授权服务器，除了被动模式外，还有一种常用的防御模式CNAME。
1、客户端发送DNS查询的请求，查询的域名是www.ddos.com。
防护系统代替服务器进行回应，并将www.ddos.com的域名重定向为GksbtkNgmpldezpe.www.ddos.com，让客户端重新请求这个别名。
2、客户端重新请求重定向后的新域名：GksbtkNgmpldezpe.www.ddos.com。客户端正常响应这个重定向域名后，防护系统对客户端的源认证就通过了。
3、防护系统第二次重定向，将GksbtkNgmpldezpe.www.ddos.com再冲定向回最初访问的域名www.ddos.com。
4、客户端重新请求www.ddos.com，这次发送的DNS请求会直接送到服务器。后续服务器会回应这个域名的解析地址，完成此次DNS查询。
无论是TC源认证、被动防御还是CNAME模式，其实都是利用DNS协议对客户端是否真实存在所做的源探测。
其中，TC源认证利用的是DNS协议的TCP查询方式；被动模式利用的是DNS协议的重传机制；而CNAME则是利用DNS的别名机制。
Reply Flood攻击篇
DNS服务器收到DNS reply报文时，不管自己有没有发出去过解析请求，都会对这些DNS reply报文进行处理。
DNS reply flood就是黑客发送大量的DNS reply报文到DNS缓存服务器，导致缓存服务器因为处理这些DNS reply报文而资源耗尽，影响正常业务。
1、针对dns缓存服务器，reply报文通常为授权服务器发给缓存服务器。
2、防护系统部署在防护目标前，并对到达防护目标的DNS reply报文进行统计。当到达防护目标的DNS reply报文超过告警阈值时，防护系统启动防御。
3、防护系统收到某个源IP地址发来的DNS reply报文后，会重新构造一个新的DNS request报文，然后记录构造查询报文的Query ID和源端口号。
4、如果是虚假源，则不会对这个DNS request报文进行回应，认证不通过。
5、如果是真实DNS授权服务器，则会重新回应DNS reply报文。
6、收到DNS reply报文后，会与之前记录的Query ID和源端口号进行匹配。如果完全一致，则判定此DNS reply报文就是反弹DNS request报文的回应，源认证成功，加入白名单。
7、后续这个源再发送的DNS reply报文，直接通过，直到白名单老化
DNS反射攻击原理
1、DNS反射攻击是DNS reply flood的一种变异，是一种更高级的DNS reply flood。
2、DNS服务器是互联网最基础的设施之一，网络中有很多开放的免费DNS服务器。
3、DNS反射攻击正是利用这些开放的DNS服务器制造的攻击。这种DNS反射攻击通常比普通的DNS reply flood攻击性更强，追踪溯源困难，更善于伪装。
1、传统DNS reply flood一般攻击目标是DNS缓存服务器；而DNS反射攻击一般攻击目标是客户端。
2、传统DNS reply flood大多是虚假源攻击，而DNS反射攻击中，DNS请求是真实的，所以DNS回应报文也都是真实的，是由网络中真实的DNS服务器发出的，
属于真实源攻击。这种情况下，再使用前面刚讲过的源认证方式，对于DNS反射攻击就不适用了。
3、防护系统借鉴防火墙的会话表机制，利用DNS交互交互过程中，DNS request报文首包建会话的机制，防御DNS反射放大攻击
除了源认证和会话检查以外，对于DNS flood攻击还可以通过限速的方式进行防御。DNS限速有两种，针对DNS request和DNS reply报文都生效。
限速防御方法
1、如果某个域名的DNS请求或回应报文速率过高，可以针对这个域名进行限速。通常某个域名在攻击前访问量并不算高，突然有一天访问量是平时的好多倍，那这个域名可能就是受攻击了。
2、源IP地址限速和域名限速相比，属于另一个维度的限制。如果某个源IP地址域名解析的速率过大，就可以有针对性的对这个源IP地址进行限制，这样也不会对其他源有影响。
参考文章
原文链接：https://blog.csdn.net/realmardrid/article/details/106349390
原创文章，作者：优速盾-小U，如若转载，请注明出处：https://www.cdnb.net/bbs/archives/20970
