Security ❀ DNS协议常见DOS攻击详解

文章目录

[1. DNS协议基础概述](#1. DNS协议基础概述)
[2. DNS报文详解](#2. DNS报文详解)
- [2.1. DNS Request 请求包](#2.1. DNS Request 请求包)
- [2.2. DNS Reply 响应包](#2.2. DNS Reply 响应包)
[3. DNS Request Flood](#3. DNS Request Flood)
- [3.1. 攻击原理](#3.1. 攻击原理)
- [3.2. 防护方法](#3.2. 防护方法)
- - [3.2.1. TC源认证](#3.2.1. TC源认证)
  - [3.2.2. 被动防御](#3.2.2. 被动防御)
  - [3.2.3. CNAME防护模式](#3.2.3. CNAME防护模式)
  - [3.2.4. *CANME类型解析过程](#3.2.4. *CANME类型解析过程)
[4. DNS Reply Flood](#4. DNS Reply Flood)
- [4.1. 攻击原理](#4.1. 攻击原理)
- [4.2. 防护方法](#4.2. 防护方法)
[5. DNS 反射攻击](#5. DNS 反射攻击)
- [5.1. 攻击原理](#5.1. 攻击原理)
- [5.2. 防护方法](#5.2. 防护方法)
[6. DNS 缓存投毒](#6. DNS 缓存投毒)
- [6.1. 攻击原理](#6.1. 攻击原理)
- [6.2. 防护方法](#6.2. 防护方法)
[7. 总结](#7. 总结)

1. DNS协议基础概述

DNS - Domain Name System 域名解析服务，提供客户端域名解析服务，将域名解析成网络上能够访问的IP地址。

参考文档：Linux系统DNS服务部署参考

2. DNS报文详解

2.1. DNS Request 请求包

Client发送请求到Server侧，请求某个域名的解析IP地址。

QR标识位：为0代表为DNS请求，为1代表DNS响应；
TC标识位：表示"可截断的"。如果使用UDP时，当应答报文超过512字节时，只返回前512个字节；

通常情况下，DNS查询都是使用UDP查询，UDP提供无连接服务器，查询速度快，可降低服务器的负载。当客户端发送DNS请求，并且返回响应中TC位设置为1时，就意味着响应的长度超过512个字节，而仅返回前512个字节。这种情况下，客户端通常采用TCP重发原来的查询请求，并允许返回的响应报文超过512个字节。直白点说，就是UDP报文的最大长度为512字节，而TCP则允许报文长度超过512字节。当DNS查询超过512字节时，协议的TC标志位会置1，这时则使用TCP发送。

Queries：请求域名与请求类型，常见类型有A、AAAA、CNAME、NS、MX等。

2.2. DNS Reply 响应包

Server侧收到Client请求后，做出域名解析的回应报文。

TTL：客户端保留该解析资源记录的时间，上图为5s；
TYPE：DNS解析类型，常见类型有A、AAAA、CNAME、NS、MX等。

3. DNS Request Flood

3.1. 攻击原理

黑客控制僵尸网络向DNS服务器发送大量的不存在的域名解析请求，消耗解析资源，直至服务器无法正常响应合理的解析请求。

3.2. 防护方法

3.2.1. TC源认证

（TC标识位作用参考本文2.1章节内容）当DNS请求达到设置防护的阈值时，开启TC位源认证，当新的一个DNS请求到达时，防护设备修改TC=1，并返回到Client，使得Client使用TCP连接请求DNS域名解析操作，此时防护设备与Client进行三次握手，Client发送SYN到防护设备，防护设备将Client IP加白并且返回错误序列号，Client触发TCP机制发送RST，且重新发送SYN连接三次握手，此时由于加白，报文直接转发到DNS服务器侧，此时建立三次握手成功，可正常请求。

优点：避免无效不合理域名的请求，同时可防止无效IP的地址发送DNS请求（无效IP无法发送TCP连接）；
缺点：部分Client无法使用TCP连接请求DNS解析（多适用于客户端是浏览器的解析请求），无法防止肉机多点请求（肉机可以正常发送TCP连接）。

3.2.2. 被动防御

当DNS请求达到设置的防护阈值时，去掉修改TC=1的机制，直接丢弃新收到第一个DNS请求包并同时记录其HASH值（通常为报文三元组信息和时间戳），查看是否会重新发送（DNS重传机制），若重传的报文可以命中前面保存的HASH值和时间戳，则正常转发并提供解析。

优点：适用于攻击源不断变化的DNS请求攻击手段，对客户端的类型并无任何限制；
缺点：会产生丢包现象，但属于合理丢包。

3.2.3. CNAME防护模式

此防护需要理解CNAME类型的使用方法。当DNS请求达到设置的防护阈值时，防护设备使用CNAME类型指定Client请求某个域名的别名，若Client继续请求该域名的别名解析地址，则通过源认证且重新使用CNAME类型指定为正确的域名（即正常请求的域名），且后续某个时间段内不在进行拦截（类比会话保持效果）。

优点：可以防护较多场景下的DNS请求Flood攻击；
缺点：解析多了两次CNAME别名解析，整体解析耗时更久。

3.2.4. *CANME类型解析过程

CNAME解析类型解释：域名b、c、d分别为域名a的别名1、2、3，当解析域名d时，域名d返回解析结果会携带CNAME类型为域名a，域名a解析类型为A类型，解析IP为1.1.1.1，若需要替换解析IP，只需要将域名a的映射IP 1.1.1.1替换为2.2.2.2即可，其他CNAME域名均不需要进行修改（具体可参考本文2.2章节请求包图例中的CNAME类型）。

4. DNS Reply Flood

4.1. 攻击原理

黑客控制僵尸网络机器发出大量的伪造DNS Reply报文，由于UDP协议为无连接状态的，DNS服务器收到大量Reply报文时，无论有没有发出过解析请求，都会对这些Reply作出处理动作，导致资源消耗巨大而影响到正常服务功能。

4.2. 防护方法

当达到防护阈值时，开启源认证功能，防护设备构造Query ID和源端口的DNS请求包，若Client正常返回Reply包，则认证通过（伪造源无法回复Reply），短时间内不再拦截此IP。

5. DNS 反射攻击

DNS反射攻击属于DNS Reply Flood的一种变异方式，属于更高级的DNS Reply Flood。

5.1. 攻击原理

黑客将自己的SIP伪造成被攻击目标的IP地址，然后向一系列网络中开放的DNS服务器发送大量的查询请求，通过伪造DNS请求报文的SIP控制DNS回应流量的流向，引导到被攻击的目标，导致其发生网络拥塞从而产生拒绝服务现象。

5.2. 防护方法

反射攻击的DNS请求均为合理请求，而DNS Reply也全部为真实报文，因此源认证方式就无法进行防护了。此时可以借鉴防火墙的会话表机制，利用DNS交互过程中Request报文首包建立会话机制来做防护手段。防护设备设置会话检查机制，使用五元组校验DNS请求，若匹配成功则允许通过，反之丢弃；

会话检查之后可以结合限速机制来约束流量拥塞，常见的有两种：

限速流量TOP的域名请求；
限速流量TOP的SIP。

6. DNS 缓存投毒

6.1. 攻击原理

DNS缓存服务器并不需要知道IP和域名的映射关系，只需要缓存到Client请求到的授权服务器上的解析记录即可，等到TTL老化时间到达后清理缓存，并重新缓存新的记录，若此时黑客伪造了大量的恶意的DNS Reply报文发送给缓存服务器抢先命中Query ID，导致缓存服务器无意将恶意的域名和IP的映射关系存储到缓存中，当Client再次通过缓存解析时，就会被指向恶意目标。

6.2. 防护方法

仍可以以五元组方式进行防护，防护设备可记录缓存服务器的Query ID等信息，若Reply报文中携带的信息与所记录的信息一致时放行，反之丢弃即可。

7. 总结

常见的DNS DOS防护手段的方法：

DDOS SIP源认证，使用构造数据包以是否可以触发重传机制进行防护，若SIP真实存在则会响应，反之丢弃或拉黑IP；
若源认证无效则统计访问域名的TOP，使用五元组方法记录会话进行限速设置，避免影响其他服务流量；