反射放大型DDoS 攻击的预防策略研究

2021-03-09 08:07白翼铭李致成包正晶
网络安全与数据管理 2021年2期
关键词:键值字段报文

郝 帅,白翼铭,李致成,包正晶

(华北计算机系统工程研究所,北京102200)

0 引言

据CERNET 2014 年10 月的月报统计,其38 个主节点中有超过一半检测到来自国内次数超过2 200次、总流量超过16 TB 的NTP 反射放大攻击[1];2016年10 月美国Dyn 公司的DNS 服务器遭受DNS 反射放大攻击与SYN 洪水攻击,导致美国大范围断网;2017 年11 月13 日到2017 年11 月15 日 期 间,ZoomEye 网络空间探测引擎探测到一个活动频繁的攻击——CLDAP DDoS 反射放大攻击,随后对DDoS反射放大攻击进行了第三轮的探测,发布出《DDoS反射放大攻击全球探测分析-第三版》;2018 年3月CCERT 公布Memcached 反射放大攻击流量占比有大幅增长[2]。

ZoomEye 的四次网络空间探测结果显示全球依旧存在着大量会被利用来反射放大的主机。例如全球2 千万台UDP 53 端口相关的主机,约18.1%存在着放大倍率,1 千万台UDP 161 端口相关的主机,约14.36%(167 万台)存在着放大倍率,其中放大倍数在10 倍以上的主机占存在放大倍率总数的36.84%,尤其值得注意的是我国所占主机量上升到了第二位[3]。

显然,成本较低、放大效果显著、追溯困难等特点使得反射放大型DDoS 备受不法分子青睐[4]。 为了提高网络中IP 资源的防御能力,本文将结合反射放大型DDoS 攻击原理对预防策略给出一个详细的分析。

1 反射放大型DDoS

反射放大型DDoS 利用的是网络中存在配置漏洞的设备或服务器,向其发送特定构造的请求数据包,将数据包的源IP 替换为受害者IP,使得服务端将应答数据包返回给受害者主机,从而消耗受害者的网络资源[5],原理见图1。由于通过中间设备或服务器发送正常请求使其向受害者回包,因此更加难被追踪溯源。 结合反射型DDoS 与僵尸网络可以同时达到产生大量应答数据包和隐藏攻击者的效果,使攻击效率和隐蔽性大幅提升。

图1 僵尸网络+反射放大型DDoS 原理图

2 基于各协议的反射放大型DDoS 原理及其仿真研究

反射放大型DDoS 分为反射和放大两部分,反射指攻击者伪造被攻击目标的IP 地址向互联网上某些有开放特殊服务的服务器发送构造的请求报文,服务器将应答报文回复到被攻击目标;放大是指服务器应答报文数倍于攻击者发送的请求报文,对受害者间接形成DDoS 攻击[6]。

本文将介绍基于Memcached、DNS、NTP、SNMP、SSDP、CLDAP 六种协议的反射放大型DDoS 的漏洞所在、payload 构造原理及预防点,利用Python 的交互式数据包操作程序增加UDP 数据报文头和IP 数据报文头,添加目的端口、源IP 和目的IP 地址等参数,构造出完整的请求数据包。 仿真攻击关键步骤见图2,收到该数据包的服务器就会将应答数据包回复给受害者, 从而模拟出多种协议的反射放大型DDoS。

图2 仿真攻击实验关键步骤图

2.1 Memcached

2.1.1 漏洞分析

Memcached 是一种高性能的开源分布式key-value(键值对) 内存对象缓存系统,使用者通过set 或add 命令向Memcached 服务器中添加要存储的键值对, 通过get 或gets 命令向服务器发送key 以获取服务器端存储的value。 key 值与value 值相差多倍,因此set/get 功能可被利用来构造大流量的Memcached 反射放大型DDoS[7]。 此外,Memcached 服务器可以接受stats 请求以返回服务器的当前状态,stats 信息同样远大于请求数据。

2.1.2 构造payload

被利用的Memcached 服务器存在UDP 的11211端口开放、未设置访问控制规则、使用root 权限运行等漏洞,如:Memcached-p 11211-U 11211-u root(根用户名),并且未启用认证功能。 这类Memcached服务器允许任何用户存入或请求该服务器中已存在的键值对,选择合适的key-value,即可构造对应的payload。

本文仿真实验中存储键值对时使用的set 命令设置相应值格式如下:

set key flags exptime bytes

value

其中,flags 表示可以包括键值对的整型参数,客户机使用它存储关于键值对的额外信息;exptime 表示此键值对在服务器中保存的时间(0 表示永久保存);bytes 表示value 的大小。 触发Memcached 回应的请求报文最小为15 B,包含为8 B+3 B(get)+1 B(空格)+最小为1 B(键的名称)+2 B( )。

构造get 查询请求或stats 查询请求命令如下:

"x00x00x00x00x00x01x00x00get"+key+" "

通过分析,可见Memcached 服务器的漏洞预防点是可选择的传输层协议以及访问控制规则、运行权限等。

2.2 DNS

2.2.1 漏洞分析

DNS(Domain Name System)协议为互联网提供域名和IP 地址对应的相互映射查询服务,理论上ISP的DNS 服务器只会响应来自它自己客户IP 的DNS Query 响应,然而由于互联网中大量DNS 服务默认配置缺失,导致其会响应任何DNS Query 请求。

这类DNS 服务器接收到一个域名查询请求时,如果该服务器未缓存对应域名,其会向更高一级的DNS 服务器请求查询域名对应的IP 信息,当请求一个复杂的或不存在的域名时,DNS 服务器会经过多层迭代查询,这样不论是否查询到结果,都会产生一个数倍于请求包的DNS 应答包。 同时EDNS(Extension Mechanisms for DNS)支持请求更多字段内容(如A 记录、CNAME 记录、TXT 等),使得应答包最大可至4 096 B[8]。

2.2.2 构造payload

被利用的DNS 服务器在配置中未关闭迭代查询,并且注释掉listen-address。 DNS 请求数据包qd字段包含域名信息qname, 选定特定的域名或者伪造虚假域名进行查询请求的DNS 数据包使得DNS服务器可以进行更多次数的递归请求,以更大程度地增大应答包。 由于DNS 单个应答包超过512 B 会被截断,因此改用TCP 协议进行请求传输,本文仿真实验中进行如下设计:

将arcount 的值改为1,并在请求包头添加dns.ar=DNSRROPT(type=′OPT′,rclass=4096)形成EDNS 请求包,此时应答包最大可达到rclass 值的大小。 EDNS应答包中additional records 额外增加type 为OPT 字段,同时可以修改qtype 的值,如将其改为255,使其查询所有内容并返回。

通过分析,可见DNS 服务器的漏洞预防点是查询请求中域名的选择、是否开放EDNS 服务以及可响应的qtype。

2.3 NTP

2.3.1 漏洞分析

NTP(Network Time Protocol)协议使计算机与时钟源进行同步化并且提供高精准度的时间校正,各客户端由从时间服务器经主服务器获得时间同步。 在CVE-2013-5211 漏洞中指出,NTPD4.2.7p26 之前的版本,对于特定配置信息的NTP 服务器,存在monlist命令请求服务,会去响应NTP 中的mode7“monlist”请求,返回进行时间同步的最近多个客户端的IP 地址及其他信息[9],远大于请求数据包的应答包会被利用来构造大流量NTP 反射放大型DDoS。

2.3.2 构造payload

NTP 协议基于UDP 协议的123 端口进行通信,本文仿真实验中进行如下设计:

对可利用的NTP 服务器构造请求数据包模拟受害者发送monlist 请求。NTP 数据包的flags 字段共有四条信息,分别如下:

信息一:第1 个bit 表示请求(0)还是应答(1);

信息二:第2 个bit 表示是否闰秒,通过这个bit对时间进行一次校正;

信息三:第3、4 个bit 合在一起表示版本;

信息四:第5~7 个bit 合在一起表示模式:0 表示未定义,1 表示主动对等体模式,2 表示被动对等体模式,3 表示客户模式,4 表示服务器模式,5 表示广播模式或组播模式,6 表示此报文为NTP 控制报文,7 表示预留给内部使用,monlist 请求即表示为010。

通过分析,可见NTP 服务器的漏洞预防点是服务器版本和配置漏洞。

2.4 SNMP

2.4.1 漏洞分析

SNMP 协议(Simple Network Management Protocol)专门设计用于在IP 网络管理网络节点(服务器、工作站、路由器、交换机及HUBS 等)。 常用的版本有1、2c 和3 三个,其中2c 版本最为通用。

根据RFC1441-RFC1452 文档说明,在SNMP2c 版本中引入了getbulk 命令来实现单个请求中获取大量的管理数据,snmpbulkget 命令则允许client 端反复请求getbulk 的内容。 同时,如果网络实体在处理请求数据包时出错,将返回错误数据包帮助查明请求格式错误的原因。

2.4.2 构造payload

SNMP 协议基于UDP 协议的161 端口进行通信,本文仿真实验中进行如下设计:

community=′public′

max_repetitions=200

b.varbindlist=[SNMPvarbind(oid=ASN1_OID(′1.3.6.1.2.1.1′)),SNMPvarbind(oid=ASN1_OID(′1.3.6.1.2.1.19.1.3′))]

其中community 字段对应命令行访问时指定的密码。 max_repetitions 字段会指定重复变量上的最大迭代次数。 ASN1(Abstract Syntax Notation One,抽象语法定义)定义SNMP 的协议数据单元PDU 和管理对象MIB 的格式。 OID 意味对象标识符,是获取SNMP 具体信息内容的一个标识,SNMP 中存的信息是一个树状的信息结构,每一个节点都由一个OID进行唯一标识,如1.3.6.1.2.1.1 表示系统信息。

通过分析,可见SNMP 服务器的漏洞预防点是SNMP协议的版本以及snmpbulkget 请求的支持与否。

2.5 SSDP

2.5.1 漏洞分析

互联网中的智能设备普遍采用UPnP(即插即用)协议作为网络通信协议,而UPnP 设备的发现是通过源端口为1900 的SSDP(Simple Service Discovery Protocol)进行相互感知。

当新设备被添加到网络时,SSDP 协议不会检验查询方是否与设备在同一网络中,直接通过特定地址和端口(239.255.255.250:1900)使用M-SEARCH 方法通过广播的方式搜索具有目标设备或目标服务的类型、标识符等数据以及目标的其他相关消息。 SSDP支持两种“通用”ST 查询类型:搜索根设备(upnp:rootdevice)和搜索所有UPnP 设备和服务(ssdp:all),监听多播地址并支持这种特定ST(搜索目标)多屏幕类型的其他设备使用单播的方式响应[10],因此这种“组播请求,单播响应”的特点会使得请求包与应答包大小悬殊。

2.5.2 构造payload

SSDP 协议基于UDP 协议的1900 端口进行通信,本文仿真实验中进行如下设计:

构造特定IP 的ssdp:all 查询请求的SSDP 数据包,flags 字段四条信息如下:

M-SEARCH * HTTP/1.1

HOST:239.255.255.250:1900

MAN:"ssdp:discover"

MX:1

ST:ssdp:all

第一个字段表示发送了HTTP 请求;第二个字段HOST 表示该请求发送到组播IP 地址;第三个字段表示这是一个查询请求;第四个字段MX 表示最长等待时间;第五个字段ST 表示查询目标,upnp:rootdevice 为仅搜索网络中的根设备,ssdp:all 为搜索所有UPnP 设备和服务。

通过分析,可见SSDP 协议的漏洞预防点是ST字段的可查询目标以及组内设备的应答规则。

2.6 CLDAP

2.6.1 漏洞分析

CLDAP(C Lightweight Directory Access Protocol)是面向无连接的轻量目录访问协议, 在不提供身份验证功能的情况下进行数据传输。 目前开源软件openLDAP不再支持UDP 协议的请求,只有利用Windows 服务器的活动目录服务Active Directory(AD)。 通常AD 域服务会在UDP 端口389 上使用CLDAP 协议来等待执行rootDSE 的搜索操作, 客户端使用UDP 数据包向389 端口发起searchRequest 服务, 一般情况下该操作会得到远大于请求数据包的应答包[11]。

2.6.2 构造payload

通过CLDAP 协议存在的漏洞分析,本文仿真实验中进行如下设计:

基于RFC2251 文档可知searchRequest 操作共有8 个字段,其中接收自定义字符输入的字段只有baseObject、filter、attributes 三 个,baseObject 值 设 为 空,filter 字段值设为objectclass,attributes 设为空[12],进一步将searchRequest 操作转化为十六进制payload。

通过分析,可见CLDAP 协议的漏洞预防点是Windows 服务器活动目录服务Active Directory 的开启与否。

3 反射放大效果验证

3.1 实验环境搭建

实验环境为:Linux 系统(Ubuntu 16.04,kali)、Python3、wireshark。

3.2 仿真环境下反射放大payload 效果验证

服务器端1 开启NTP 服务和SNMPD 服务,服务器端2 开启DNS 服务查询和Memcached 服务,Windows Server 2008 开启CLDAP 服务,客户端和受害客户端开启wireshark 抓包服务,客户端发送payload 数据包至服务器端,观察到客户端未收到回应数据包,受害客户端接收到各服务器端的大量回应数据包,证明可实现IP 欺骗和放大效果。

3.3 真实环境下反射放大payload 效果验证

通过ZoomEye 获取真实网络环境中一定数量的六种协议服务器IP 列表,利用上述的客户端向这些IP 发送payload 数据包,打开wireshark 监控服务器回包和带宽变化,利用监听函数对回包IP 和放大倍数进行统计,根据常见的反射放大型DDoS 评判方法,选取payload 字节数、理论放大倍数[13]、最大放大倍数和流量峰值作为实验评判标准,详细结果见表1。

表1 实验结果统计表

通过观察流量变化可以发现应答包字节数远大于payload 数据包,网络返回带宽最大可达到28 Mb/s,其中Memcached、SSDP、SNMP 和NTP 请求应答数据变化如图3 ~图6 所示,CLDAP 客户端带宽变化如图7 所示。

其中最大放大倍数计算方式如下:

图3 Memcached 客户端请求应答数据图

图4 SSDP 客户端请求应答数据图

图5 SNMP 客户端请求应答数据图

图6 NTP 客户端请求应答数据图

图7 CLDAP 客户端带宽变化图

探测开启一段时间后,客户端的流量峰值最大可达到28 Mb/s,各个协议的平均流量峰值都超过5 Mb/s,说明实验结果很好地测试了真实环境下payload 的放大效果,同时可以发现六种常见协议的最大放大倍数都非常可观。

4 防范反射放大型DDoS

反射放大型DDoS 危害大、成本低、溯源难,为不法分子和黑色产业等从业者所热爱,查看ZoomEye公布的全球各协议可利用主机探测结果,全球范围内可利用主机数量相当可观,我国作为重灾区,很容易被人利用来实现反射和放大,因此重视防范是非常必要的。 通常来说反射放大型DDoS 的防范方法可分为用于放大的服务器上的防范和用于受害者用户上的防范[14]。

4.1 服务器角度的防范措施

对于文中所列协议,在服务器管理员角度,根据反射放大型DDoS 预防点应尽量做到如下配置:

(1)Memcached 服务可在配置服务器时禁止UDP传输;

(2)DNS 服务可在配置时关闭递归查询功能;

(3)NTP 服务器可升级到4.2.7p26 或者更高的版本,或关闭当前NTP 服务器的monlist 功能[15];

(4)SNMP 服务器可以禁用snmpbulkget 请求命令;

(5)对于不需要使用UPnP 服务的设备关闭SSDP 服务;

(6)在非必要的情况下,关闭AD 域服务器的root-DSE 功能;

(7)在服务器上通过变更服务端口或限制请求IP 来进行防范。

4.2 受害者角度的防范

对于可能成为受害者的目标用户来说,可以通过采用下列方法降低遭受反射放大型DDoS 的风险并减少损失:

(1)在路由器或防火墙上配置ACL 以限制可通过的协议和IP,或限制对外部请求所返回的响应包的大小,对超过阈值的包进行丢弃。

(2)在路由器或防火墙处安装流量清洗设备。在检测到可能发生反射放大型DDoS 时,将所有流量引入清洗集群,使多对一的攻击变为多对多,并通过特征、基线、回复确认等方式对攻击流量进行识别与清洗,之后将经过清洗之后的正常访问流量注入到原有网络中,访问目的IP。 此时在用户来看,并不存在DDoS 攻击,服务保持正常[16]。

(3)使用高防IP,在多个IP 上通过负载均衡模式进行轮询,将DDoS 攻击流量均摊到多个IP 地址上,将大攻击变为多个小攻击。

(4)采用CDN 技术,利用具有一定DDoS 保护能力的CDN 节点来实现DDoS 保护。在使用CDN 的情况下,攻击者获得的目标IP 为CDN 节点的地址,而不是服务器地址,因此攻击者攻击的是一个CDN节点,其他节点仍可以使用,不影响对服务器内容的正常访问[17]。

(5)采用双机或多机热备,搭建备用服务器,在主用服务器遭受DDoS 宕机时启用备用设备以保持服务。

5 结论

反射放大型DDoS 攻击频频出现,对个体、公司甚至国家造成不可预估的危害。 本文针对常见的DNS、SNMP、SSDP、NTP、Memcached 和 CLDAP 六 种协议存在的安全漏洞进行分析,利用Python 库设计DDoS payload,搭建仿真环境验证反射放大效果,并测试真实环境放大效果,进一步突出反射放大型DDoS 的危害。 本研究希望帮助安全人员优化完善服务器配置信息,防御反射放大型DDoS,从而尽可能地减小受害几率,同时帮助更多的人认识和规防反射放大型DDoS。

猜你喜欢
键值字段报文
基于J1939 协议多包报文的时序研究及应用
图书馆中文图书编目外包数据质量控制分析
非请勿进 为注册表的重要键值上把“锁”
CTCS-2级报文数据管理需求分析和实现
浅析反驳类报文要点
一键直达 Windows 10注册表编辑高招
ATS与列车通信报文分析
CNMARC304字段和314字段责任附注方式解析
无正题名文献著录方法评述
关于CNMARC的3--字段改革的必要性与可行性研究