DDOS防御抗D平台方案_系统抗d

1 抗D平台需求分析

1.1 网站服务拓扑示意图

如上示意图，存在三个方面可能被攻击的点：

1. 递归DNS服务器
   这个点在运营商环境里，且全网分布众多，攻击成功存在一定的难度。但目前已经有类似的攻击成功案例，即攻击者针对一个个递归服务器进行攻击，攻击的目标是同一个域名，导致各个递归服务器运行很艰难，服务器的维护者会采取的措施是简单粗暴的过滤这一域名的所有请求，从而达到全网不响应该域名请求的结果。目前这类故障需要通过客户端来解决，本方案仅针对此类攻击提出关注。

2. 权威DNS服务器
   用户自建权威DNS服务器的情况下很容易遭受攻击导致服务中断，即使使用了一些服务商的DNS解析服务，这类服务商在提供服务的过程中，由于缺少足够的攻击防御能力，被攻击时一般会停止解析被攻击域名来达到整体服务器的稳定，所以权威DNS服务器是需要保护的一个关键点。

3. WEB服务器
   WEB服务器是用户提供WEB服务的服务器，有的用户通过CDN来提供更快速的响应，但攻击者的攻击一般会直接攻击到源站上来，这种情况下，源站的带宽和性能都不具备攻击防御的基本条件，所以这里也是需要保护的另一个关键点。

1.2 防御后服务的拓扑示意图

以上的DNS服务防御以NS切入的方式进行设计，因为CNAME方式切入时，无法保护DNS，用户的DNS仍然存在被攻击至无法服务的局面。

1.3 设计需求

1.3.1 独立抗D服务

抗D平台作为独立的平台运行，提供拥有账户的用户使用高级抗D服务的完整流程，同时也提供接口支持与CDN平台分享用户的配置，以满足CDN用户的高级抗D需求，同时抗D平台的后续完善中也可以基于动静分离或CDN分发的技术来为常规抗D用户提供相应的加速需求，以改善抗D环境下的WEB服务质量。

独立运营状态下，抗D平台提供独立的WEB入口，支持用户添加网站、维护子域名、开启或关闭服务、配置策略以及查看报表等操作。平台支持系统由防御集群、调度中心、配置中心、数据中心和监控中心等系统组件组成。

1.3.2 CDN增值服务

CDN平台运行过程中，所服务的用户也会遭受DDOS攻击，这种情形下存在两种情况：

1. 有明确的被攻击域名，即被攻击的IP上只有唯一的域名；
2. 没有明确的被攻击域名，即被攻击的IP上有多个域名，通过其他手段也无法确定具体被攻击的域名。
   当然也有CDN的用户意识到需要更高级别的抗D需求。
   抗D平台设计时要支持CDN平台运行过程中的上述几种高级抗D需求。

2 防御集群架构

构建一套平台，用于保护常规的WEB服务，确保在大流量及超大流量攻击下，被保护的目标仍然能够正常或基本正常的提供服务，尽可能的减少监控点或网民对该服务因攻击可能产生的临时性故障的感知。基于对WEB服务的保护，主要防御的攻击包括针对WEB站点对应域名DNS服务的内容攻击、流量攻击、4层有状态攻击和针对WEB服务的内容攻击。

平台具备高可用性及可扩展性，支持多点并存的特性。具备高可用包括单机故障高可用和机房故障高可用两种，可护展性则明确为在网络出口带宽足够的情况下，可能通过简单的扩展硬件设备来提升处理能力。

针对大流量攻击的防御，主要拼的是带宽，所以不管是DNS服务还是WEB服务，都需要这样一道防御体系，而且这一体系应该可以复用，以节约资源。

2.1 流量型攻击的防御架构

通过ECMP+n个server的部署模式，可以实现云防御平台的可扩展性。建立在较高背板处理能力的交换机上，开启ECMP模式，将流量分发到多个server上去分布式处理，由驱动清洗后的流量才提交到协议栈进行处理，协议栈确认正确的提交到nginx处理，nginx支持CC攻击流量的清洗。

2.1.1 机房防御部署

机房的部署示意图如下：

攻击者发起的流量和网民的正常流量混在一起，以攻击流量为主，巨大的流量通过入口处的路由器涌向交换机，通过配置ECMP功能，将流量通过源IP hash到各个server上，通过server系统来清洗攻击流量。

2.1.2 Server分层防御

Server分层防御逻辑图示意如下：

攻击者发起的流量和网民的正常流量混在一起，以攻击流量为主，巨大的流量通过入口处的路由器涌向交换机，通过配置ECMP功能，将流量通过源IP hash到各个server上，通过server系统来清洗攻击流量。

2.1.3 运营商协助防御

基于电信的机房防御时，在分析出有特定的攻击流量特征时，可以采用“云堤”接口，封堵流量，避免这类流量堵塞机房带宽，按被攻击的目标IP为对象，可以支持的封堵行为如下：

1. IP指黑，到这个IP的流量全部丢弃
2. 拦截国内流量（电信网除外）
3. 拦截国外流量
4. 拦截国内外流量（电信网除外）

通常情况下，我们使用的最多的是IP指黑，这是分析到该IP的流量超大时，避免把机房打跨的情况下，对IP的所有流量丢弃，再启用新的IP来提供服务，这也可以应对“扫段”式攻击；另一种常用的就是拦截国外流量，在运营商处拦截国外流量，可以节约机房的带宽来确保可以提供正常的服务。

总之，有了“云堤”的协助，平台的防御流量可以增大近一倍。

2.2 CC攻击的防御架构

2.2.1 CC防御组件拓扑关系图

在防御集群中，存在多个server，server上分析处理的数据由ccap汇总上报到数据中心的asic，如上图所示拓扑关系。
1. Nginx
负责处理网络上的请求数据，包括响应和过滤，实时的把处理情况输出到ccap，并接收ccap下发的策略，根据策略进行处理。
2. 网络层
网络层负责拦截恶意IP的请求，这些IP是由ccap分析后下发的，并统计这些IP被拦截数据。
3. Ccap
实时接收nginx外发的处理信息，综合分析，并汇总上报给asic，接收asic下发的综合状态形成策略下发到nginx中。同时把分析到的恶意IP添加到网络层的拦截规则中，定期清理。
4. Asic
运行在数据中心上，接收所有的ccap上报数据，汇总结合并把状态同步到各个ccap中。

2.2.2 CC防御组件逻辑关系图

2.3 DNS攻击的防御架构

DNS采用CF的DNS解决方案，该方案目前可以防御主流攻击，优势在于采用了AnyCast，国内防御不了的情况下，用国外的系统和带宽来防御。
DNS服务器部署在各个server上，针对DNS服务的流量型攻击也由前端的防御平台统一防御。

2.4 防御架构高可用设计

1. 机房高可用
提供大流量防御的机房按相同标准下要建设两个或两个以上，通过DNS同时解析到这些机房时可以避免单一机房因停电或关键设备故障情况下的服务失效问题；同时也可以检测到机房故障时，更新DNS解析来达到较快速的机房切换目标，实现机房高可用。
两个机房建设时要考虑跨地域特性。
2. Server设备高可用
通过IP漂移功能，准备1~2台备用空闲机器，用于集群内server设备故障时，快速接管故障机器的工作，实现设备的高可用。

2.5 防御架构高可扩展设计

由于国内无法实现AnyCast，所以针对流量型攻击时，无法进行多机房分担负载，所以防御平台的最大可防御流量受限于机房的最大可使用带宽，在这个条件之下，通过ECMP+server的模式，可以实现倍数扩展能力，可扩展性较好。

2.6 防御目标

2.6.1 单机目标

采用双网卡bind实现每server处理10G小包的能力。

2.6.2 机房目标

单机房160G的机房防御能力，可扩展为320G。

2.6.3 设备需求

1. Server
16台正式使用server，2台备用server
2. 数据中心
安装asic的系统，用于支撑报表
3. 交换机
一台支持ECMP功能且背板能力达到700G+的交换机，要考虑交换机的丢包率，越少丢包越好。接口数如果考虑后期扩展的情况下，16台2(双接口) + 16台2 + 2台(备用)*2 = 68个接口。

3 抗D平台支撑系统

3.1 配置中心

提供用户配置的域名及其相应子域名记录的信息，包括安全防护相关的配置。也支持从CDN导入相应域名的配置。

3.2 监控中心

监控防御平台下的设备和用户配置的网站，包括异常数据监控，发现攻击的变化并进行告警。

3.3 数据中心

采集各个系统产生的日志数据，进行数据分析和汇总，提供数据查询接口。

3.4 报表中心

提供用户登录平台后的配置、查看等操作。

3.5 调度中心

协调抗D资源，合理安排防御和定位被攻击的域名。调度中心满足独立抗D服务需求，也同时满足CDN增值服务需求。

3.6 机房协助机制

超过40G的攻击，如果IP不想被封掉的情况下，需要把IP通知到机房，机房在有可用资源的情况下尽可能优先不封该IP。

4 CDN增值服务设计

当使用CDN的用户被攻击或用户有自主的高级抗D需求时，可以通过CDN增值的方式切入抗D平台，同时CDN某节点被攻击时，也有抗D定位的需求，也可以切入抗D平台。
支持CDN平台用户的高级抗D需求时，抗D平台提供接口与CDN平台对接，这类接口实现如下功能需求：

1. 允许CDN平台告知需要高级抗D的域名及其相应的子域名网站记录，同时下发网站的安全配置；
2. 允许CDN平台告知需要抗D拆分的域名组，包括这些域名下属的子域名网站记录，同时下发网站的安全配置；
3. 允许CDN平台提取抗D期间内的访问日志、防御日志等信息，用于报表展示；
   同时，由于存在抗D平台处理后的一些异步响应的操作，需要CDN平台提供相关的回调接口，这些接口包括：
4. 取消抗D状态，如抗D拆分过程中，确认为没有被攻击的域名，应取消抗D状态；
5. 域名修改接口，切入抗D后，不再做NS切入或CNAME切入变更，所以需要CDN平台提供域名修改接口，以便于抗D过程中域名指向的变更操作。

4.1 业务流程

1. CDN用户抗D需求业务

2. CDN平台抗D定位需求业务

4.2 抗D平台提供的接口

4.2.1 切入域名接口

每次切入编组，同时统计组内域名个数，抗D平台针对切入个数为1的编组实施正常防御方案，编组数大于1的实话抗D定位方案。接口内容包含开保护状态的各子域名记录。
抗D定位成功的域名视为正常防御切入。

4.2.2 套餐定购接口

以实施防御进行切入的域名都应该有相应的套餐，首次防御无套餐情况下，使用默认套餐，默认套餐的内容可以另行设计。
各套餐按产品设计定义。

4.2.3 更新配置接口

通过该接口把各记录的源站IP、别名等和防御配置等更新到抗D平台。

4.2.4 撤回域名接口

通过该接口，告知抗D平台不再为该域名提供抗D服务，但保留一定时间内的有效配置，以保证各地DNS缓存期内的正常访问。

4.2.5 查询接口

根据查询类型，可以获取指定域名的状态、套餐信息、实时报表、历史报表等。

4.3 CDN平台提供的接口

4.3.1 退回域名接口

抗D定位后明确不需要再呆在抗D环境下的域名通过此接口通知到CDN平台。

4.3.2 DNS修改接口

切入抗D的域名，所有需要防御的记录需要分配抗D资源，这些域名对应的IP需要通过该接口来修改。
从CDN切入抗D的域名不使用抗D系统内的DNS服务，因为NS切入的情况下，必须要最终用户重新修改NS切入点，CNAME方式的可以再做一次CNAME，但整体上不合理，如果需要DNS防御的用户，建议直接启用抗D中心的服务，走独立抗D服务流程。

4.3.3 日志采集接口

根据CDN平台对日志需求的具体内容来设计

5 测试验证方案

5.1 DNS防御验证方案

Usage:
./dnsflood <target ip> <base_name> [<pkt_then_sleep> <sleep_time>]
send dns query to <target ip>, sleep <sleep_time> microseconds per <pkt_then_sleep> paskets.
please set base_name like '.xxxx.com'
1
2
3
4

5.2 流量型攻击防御验证方案

Usage:
	./flood -v
	./flood [-i] [-t type] [-s srcip|-r iprange] -d dest [-p dport] [-l packetlen] [-w bandwidth|-q qps|-n sendnum] [-c thread_num] [-e dns_basename]

		-i: if set, show thread send info
		-t type: icmp|syn|udp|dns, if null, use icmp
		-s srcip|-r iprange: if null, use random ip 
				srcip: single ip 
				iprange: 192.168.10.1/20,10.10.1.1/22
		-p dport: if null, use 80, when dns flood, use 53
		-l packetlen: if null, use 60
		-w bandwidth|-q qps|-n sendnum: if null, set sendnum=10
			bandwidth: check bandwidth
			qps: check qps
			sendnum: check sendnum
		-c thread_num: if null, default 1 thread
		-e dns_basename: '.test.com'
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

5.3 CC攻击防御验证方案

Usage:
	./cc -v
	./cc [-i] [-t type] [-x proxyipfilename] [-p siteip] -s sitename -u url [-q qps|-n sendnum] [-c thread_num]

		-i: if set, show thread send info
		-t type: normal|slow,n,m , if null, use normal
			normal attack has 3 type, with url config
				fixed: fixed url 
				randurl: url be '/rand_int/rand_str/index.php
				randparam: url be '/index.php?type=5&id=rand_int&msg=rand_str
				'rand_int' or 'rand_str' will be change when running with random
			slow,n,m attack can't use proxyip, and must be set init_time and wait_time
				'n': init_time, how long to create sendnum connections
				'm': wait_time, how long to send data every connection
		-x proxyipfilename: proxy ip list, if use, we need '*.cctest.com' by aqb server node
		-p siteip: dest site ip, if null, use gethostbyname with sitename
		-s sitename: dest sitename
		-u url: match type, can use multi '-u'
		-q qps|-n sendnum: if null, set sendnum=10
				qps: total qps
				sendnum: attack times
		-c thread_num: if null, default 1 thread
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22