DDoS攻防战：CC攻击及ip黑白名单防火墙frdev的原理与实现
【编者按】DDoS攻击的模式改变了传统的点对点的攻击模式，使攻击方式出现了没有规律的情况，而且在进行攻击的时候，通常使用的也是常见的协议和服务，这样只是从协议和服务的类型上是很难对攻击进行区分。在进行攻击的时候，攻击数据包都是经过伪装的，在源IP 地址上也是进行伪造的，这样就很难对攻击进行地址的确定，在查找方面也是很难的。本文将针对应用层的DDoS攻击的实现、防范，以及一个防火墙内核模块的实现做了详细解读，本文来作者个人博客。
免费订阅“CSDN云计算”微信公众号，实时掌握第一手云中消息！
CSDN作为国内最专业的云计算服务平台，提供云计算、大数据、虚拟化、数据中心、OpenStack、CloudStack、Hadoop、Spark、机器学习、智能算法等相关云计算观点，云计算技术，云计算平台，云计算实践，云计算产业资讯等服务。
概述
DDoS，即 Distributed Denial of Service ，可译为分散式阻断服务攻击。
上图与DDoS的字面已经清楚的表述出了此类攻击的原理，勿需多言。这类攻击泛滥存在的主要原因之一是网络服务的开放性，这一特点导致了DDoS攻击无法根本杜绝，目前主要应对策略是积极防御与消极防御。
典型DDoS的攻击方式：
死亡之Ping
icmp封装于IP报文之中，而IP对于很大的数据载荷采用分片传输的策略，而接收方需要对这些IP分片进行重组，如果接收方的重组算法不能很好地处理意外情况，后果会很严重，典型的意外情况包括：
1.连续分片的偏移量之间不符合它们应该的逻辑关系，攻击者伪造出这样的一系列分包是很容易的；
2.重组完成后的IP头与数据载荷，总长度竟超过了IP报文总长2^16字节（64kB）的限制，一个实现的例子是，前面各分片一律正常，唯有最后一个IP分片的数据载荷尽量填充到最大，如达到以太网最大传输单元MTU 1500字节上限，这样重组后的报文总长度就达到了约（64kB+1500B-20B-8B=65.44kB）的大小。
这种攻击方式附加了对目标系统协议栈算法的漏洞利用。
泪滴TearDrop
泪滴攻击指的是向目标机器发送损坏的IP包，诸如重叠的包或过大的包载荷。借由这些手段，该攻击可以通过TCP/IP协议栈中分片重组代码中的bug来瘫痪各种不同的操作系统。(此段摘自维基百科中文，实现方式可参考上死亡之Ping）
UDP洪水
UDP是一种无连接协议，当数据包通过 UDP 发送时，所有的数据包在发送和接收时不需要进行握手验证。当大量 UDP 数据包发送给受害系统时，可能会导致带宽饱和从而使得合法服务无法请求访问受害系统。遭受 DDoS UDP 洪泛攻击时，UDP 数据包的目的端口可能是随机或指定的端口，受害系统将尝试处理接收到的数据包以确定本地运行的服务。如果没有应用程序在目标端口运行，受害系统将对源IP发出 ICMP 数据包，表明“目标端口不可达”。某些情况下，攻击者会伪造源IP地址以隐藏自己，这样从受害系统返回的数据包不会直接回到僵尸主机，而是被发送到被伪造地址的主机。有时 UDP 洪泛攻击也可能影响受害系统周围的网络连接，这可能导致受害系统附近的正常系统遇到问题。然而，这取决于网络体系结构和线速。（此段摘自维基百科中文）
TCP RST 攻击
TCP协议存在安全漏洞，正常的TCP连接可以被非法的第三方复位，这是因为TCP连接通讯不包含认证的功能。如，在已知连接的五元组的情况下，攻击者可以伪造带有RST/SYN标志的TCP报文或普通数据报文，当其sequence number落在TCP连接的滑动窗口范围内，可能导致会话终止或者虚假数据插入。（这里仅仅提一下，详细可参考文章《 从TCP协议的原理来谈谈rst复位攻击》、《 忆龙2009：TCP非法复位漏洞及解决方法》）
TCP 全连接攻击
庞大的攻击群同时地、不断地与目标服务器建立正常的TCP连接，从而严重影响正常用户的连接服务。
Syn Flood
攻击者向目标服务器发送大量（伪造源IP地址、伪造源端口、正确目标IP地址、正确目标端口）tcp syn数据包，目标服务器为了维持这么大量的虚假连接，大量的tcp状态机维持在了SYN_RCVD状态，严重地影响了处理速度与消耗了系统资源，而反观攻击者，伪造并发送这些小数据包，各项资源消耗都极低，对于网络传输速度为3Mb/s的一个攻击者来说，攻击包的速率大约可达每秒(3Mb/8/40=9830)个，如果网络传输速度达到30Mb/s，单个攻击者的攻击包速率可为98300/s，如果再考虑到分布式攻击，情况将变得极为恶劣。
CC攻击
CC，即 Chanllenge Collapsar ,可直译为 黑洞挑战，CC攻击是 DDoS 攻击的一种类型，使用代理服务器向受害服务器发送大量貌似合法的请求，巧妙之处在于，网络上有许多免费代理服务器，甚至很多都支持匿名代理，所以其优点为：
1.攻击者事先不需要抓取攻击傀儡，但仍需得到可用的、符合要求的代理 ip:port 列表;
2.匿名代理，使得追踪变得非常困难，但并非不可能！
四层及以下的DDoS防御：
新型攻击方式的产生、流行，必然导致对应防御策略的出现。
而针对四层及四层以下的DDoS攻击，现在的硬件防火墙大多都能对死亡之Ping、icmp洪水、泪滴等做到很好的防御效果，所以，这里重点介绍SynFlood的若干防御策略：
SynCookie：等到系统资源到达某一临界点，内核协议栈启用SynCookie机制，进行Syn包源IP:PORT验证，它本身是一种非常巧妙的实现，具体可参考文章《 SYN Cookie的原理和实现》；
SynProxy：即Syn代理，一般可在前端防火墙上实现，不过，淘宝开源项目ipvs维护者吴佳明先生已经在内核层实现了这一功能，可理解为SynCookie+Proxy，请访问 https://github.com/alibaba/LVS/获得最新源码与项目文档；
SynCheck：对Syn包依据一定的规则进行检验,以过滤掉一部分不规则的包；
SynFirstDrop：Syn首包丢弃策略，但如果攻击者将伪造的Syn报文发送两次，这种方法就失去了效果。
以上的这些常见防御方法都可以分别通过硬件和软件来实现，一般来讲，硬件防火墙处理能力要比软件方法强，但价格也更加昂贵，尽管软件实现性能会有下降，但也没有太差，例如，ipvs工作于内核层，淘宝在大部分网站使用其作为Director，下面是一些官方数据：
如果在上面这些数据的基础之上，前端Director实现集群以分担系统负载，性能将会更佳，可见软件防火墙在使用的得当的情况之下，能极大降低系统成本，而且性能理想，这是经过淘宝的系统实际验证了的。
CC攻击工具实现与防御理论
我们将要实现一个进行应用层DDoS攻击的工具，综合考虑，CC攻击方式是最佳选择，并用bash shell脚本来快速实现并验证这一工具，并在最后，讨论如何防御来自应用层的DDoS攻击。
第一步：获取大量可用代理ip:port列表
网上所处可见免费代理，我们使用http的GET方法抓取html文档，接着使用正则过滤出我们需要的ip port对，然后逐一验证各代理的可用性，最终得到可用的代理ip port对。
参数：
declare check_threads=10 #验证代理可用性时的并发数，看一下代码就会发现，我们使用的是GET http://baidu.com方法，所以，并发数请不要也太高，除非你的目标就是......
总结：应征入伍的士兵共计600人，经过考核的共计449人，如果你还想招募更多的士兵，奉劝一句，苦海无边，回头是岸。
第二步：吹响战争号角
笔者在一台VPS上建立了一个薄弱的靶机，各位读者请不要太暴力，测试一下就可以了，地址 http://eecs.cc:8080/
读者可自行尝试攻击这个站点，然后使用浏览器访问查看服务器网络状况，此时大量连接处于TIME_WAIT状态，参考TCP状态机，这一状态为主动关闭一方的最终等待状态。（编者注：请不要恶意攻击别人的网站）
应用层DDoS的防御理论：
问题模型描述：
每一个页面，都有其资源消耗权重，静态资源，权重较低，动态资源，权重较高。对于用户访问，有如下：
用户资源使用频率=使用的服务器总资源量/s
命题一：对于正常访问的用户，资源使用频率必定位于一个合理的范围，当然会存在大量正常用户共享ip的情况，这就需要日常用户访问统计，以得到忠实用户ip白名单。
命题二：资源使用频率持续异常的，可断定为访问异常的用户。
防御体系状态机：
1.在系统各项资源非常宽裕时，向所有ip提供服务，每隔一段时间释放一部分临时黑名单中的ip成员；
2.在系统资源消耗达到某一阈值时，降低Syn包接受速率，循环：分析最近时间的日志，并将访问异常的ip加入临时黑名单；
3.若系统资源消耗慢慢回降至正常水平，则恢复Syn包接受速率，转到状态1；若目前策略并未有效地控制住系统资源消耗的增长，情况继续恶劣至一极限阈值，转到状态4；
4.最终防御方案，使用忠实用户ip白名单、异常访问ip黑名单策略，其他访问可慢慢放入，直到系统资源消耗回降至正常水平，转到状态1。
上述的防御状态机，对于单个攻击IP高并发的DDOS，变化到状态3时，效果就完全体现出来了，但如果防御状态机进行到4状态，则有如下两种可能：
1.站点遭到了攻击群庞大的、单个IP低并发的DDOS攻击；
2.站点突然间有了很多访问正常的新用户。
建议后续工作：
保守：站点应尽快进行服务能力升级。
积极：尽所能，追溯攻击者。
追溯攻击者：
CC：proxy-forward-from-ip
单个IP高并发的DDOS：找到访问异常的、高度可疑的ip列表，exploit，搜集、分析数据，因为一个傀儡主机可被二次攻占的概率很大（但不建议这种方法）
单个IP低并发的DDOS：以前极少访问被攻击站点，但是在攻击发生时，却频繁访问我们的站点，分析日志得到这一部分ip列表
追溯攻击者的过程中，snat与web proxy增加了追踪的难度，如果攻击者采用多个中继服务器的方法，追溯将变得极为困难。
防御者：
1.应对当前系统了如指掌，如系统最高负载、最高数据处理能力，以及系统防御体系的强项与弱点
2.历史日志的保存、分析
3.对当前系统进行严格安全审计
4.上报公安相关部分，努力追溯攻击者
5.网站，能静态，就一定不要动态，可采取定时从主数据库生成静态页面的方式，对需要访问主数据库的服务使用验证机制
6.防御者应能从全局的角度，迅速及时地发现系统正在处于什么程度的攻击、何种攻击，在平时，应该建立起攻击应急策略，规范化操作，免得在急中犯下低级错误
对历史日志的分析这时将会非常重要，数据可视化与统计学的方法将会很有益处：
1.分析每个页面的平均访问频率
2.对访问频率异常的页面进行详细分析 分析得到ip-页面访问频率
3.得到对访问异常页面的访问异常ip列表
4.对日志分析得到忠实用户IP白名单
5.一般一个页面会关联多个资源，一次对于这样的页面访问往往会同时增加多个资源的访问数，而攻击程序一般不会加载这些它不感兴趣的资源，所以，这也是一个非常好的分析突破点
ip黑白名单防火墙frdev的原理与实现
实现方案选择：
硬件实现或者软件实现？
在面对诸如大量畸形包这样的攻击时，硬件实现将会是非常好的选择，这是因为在进行此类型的封包过滤时，系统需要记忆的状态很少（对于FPGA、ASIC诸多硬件实现方案来讲，记忆元件的成本决不可忽视，寄存器与静态RAM都非常昂贵，所以当需要记忆的信息很少时，纯硬件方案的速度优势使得其完胜软件方案）。
但是，当状态机需要处理庞大的记忆信息时，我们就需要选择廉价的存储器――动态随机存储器（如SDRAM中的DDR3）来作为系统状态机的存储介质，以降低系统的成本和复杂度。这时，软件实现更胜一筹。尽管纯硬件实现的速度会比软件的方式高出很多，但我们也从第一篇文章《 DDoS攻防战 （一） ： 概述》中lvs性能的测试结果中看到，软件实现的、作为服务器前端均衡调度器的lvs，性能理想并且能胜任实际生产环境中的、庞大的用户请求处理，可见，如果设计合理，软件实现的性能无需过多担忧。
最终，我们决定采用软件的方法来实现所需的ip黑白名单模块。
最终系统鸟瞰：
笔者花费大约二十天的时间，使用C语言实现了这一模块，其中，内核空间的核心代码约2300行，用户空间管理工具的代码总行数约为700行。下为系统的鸟瞰：
- 用户空间管理工具fripadm，通过ioctl与工作于内核态的frdev模块进行通信
- frdev维护两个double_hash_table的实例，并提供了一个挂在NF_INET_PRE_ROUTING的钩子函数，其通过操作这两个double_hash_table的实例以分别实现ip黑名单、白名单的功能
- frdev通过内核中设备驱动的ioctl机制，向用户空间提供这两个double_hash_table实例的操作函数，而我们的用户空间管理工具fripadm正是基于此而实现的
下面是内核态的主要数据结构与其对应的操作函数：
为什么使用双哈希表缓冲？
请考虑如下场景：
情况1：来自应用层的DDoS攻击常常是瞬间涌入大量非法ip请求，例如数万个非法ip，所以，对于防火墙黑白名单功能的要求至少有如下：能在很短的时间内更新大量数据项，且不能造成系统服务停顿。
分析：如果只使用一个全局的哈希表，当在短时间内进行大量的数据项增删时，例如，成千上万个，此时，即使采用多把读写锁分割哈希表的策略，对共享资源的竞争也依然将严重影响系统响应速度，严重时系统可能会停顿或者更糟，对于生产环境中的高负载服务器，这是无法容忍的。
解决：以空间换时间
采用双哈希表缓冲的策略，将系统共享资源的竞争热点压缩至两个hash表指针主备切换的极短时间内，此方法能显著降低系统在大量数据项更新时共享资源的竞争。
系统查询将会直接访问master指向的fr_ip_hash_array，而用户的更新操作将直接针对mirror所指向的另一个fr_ip_hash_array实例，直到switch_mirror_update操作的执行，master将被瞬间“更新”。这是其主要的工作特点。
对于SMP与多队列网卡的系统，可采用如下策略：多数cpu核心专门负责处理内核的softirq任务，剩下的少数cpu负责进行双哈希表的更新、切换与重建等操作。这样可提高系统对攻击的快速防御响应。
但此方案将使得系统需要维护两个互为镜像的哈希表，这将加重系统内存的读写负担。
具体实现细节如下：
挂到协议栈上的钩子函数：
在模块初始化函数fr_ip_dev_init的最后，即当两个双哈希表实例（分别用作黑名单与白名单）初始化成功、fedev设备注册成功之后，其将会执行nf_register_hook，将指定的钩子函数fr_nf_hook_sample挂到NF_INET_PRE_ROUTING之上。
fr_nf_hook_sample的主要处理代码如下：
其中，double_hash_white_ptr指向白名单fr_ip_double_hash实例，double_hash_ptr则指向黑名单fr_ip_double_hash实例，由于支持模糊ip匹配，故，上述代码使得对源ip过滤的“通”、“堵”策略皆可使用。
内核空间frdev的ioctl处理函数：
目前，ioctl支持来自用户空间的如下操作：
上述各功能的具体实现请阅读frdev源码中的fr_ip_dev_ioctl_routine函数。
用户空间管理工具：fripadm
第一步，实现fripadm_black_in_exe与fripadm_white_in_exe，是分别管理黑白名单的工具，不过，较为简陋，第二步，使用shell脚本对其进行二次封装得到fripadm_black_in.sh与fripadm_white_in.sh这两个较用户友好的工具。
fripadm为用户空间的C语言开发者们提供了如下API：
fripadm_black_in_exe、fripadm_white_in_exe、fripadm_black_in.sh与 fripadm_white_in.sh的具体实现请参看frdev源码。
按照README所述的过程，编译、安装完毕frdev设备后，便可进行如下测试：
原本被black所DROP的数据包，在更新了white的ip条目后，被white所ACCEPT，上图红线标出了数据包被截断的icmp_seq的区间。
关于frdev的陈述到此为止。
最近笔者在阅读《白帽子讲Web安全》这本书时，发现了雅虎公司用于防护应用层DDoS攻击的系统Yahoo Detecting System Abuse，yahoo为此系统申请了专利保护。下面是关于这个系统的描述：
A system continually monitors service requests and detects service abuses.
First, a screening list is created to identify potential abuse events. A screening list includes event IDs and associated count values. A pointer cyclically selects entries in the table,advancing as events are received.
An incoming event ID is compared with the event IDs in the table. If the incoming event ID matches an event ID in the Screening list,the associated count is incremented. Otherwise, the count of a selected table entry is decremented. If the count value of the selected entry falls to Zero, it is replaced With the incoming event.
Event IDs can be based on properties of service users,such as user identifications, or of service request contents,such as a search term or message content. The screening list is analyzed to determine whether actual abuse is occurring.
大概思路如下：
此系统通过维护一个筛选表来得到用户的请求频率，以判断其是否存在service abuse，然采取相关措施，例如BLOCK。
这种防御思想，与我们之前所提出的防御状态机有着异曲同工之妙。笔者认为这是必然的。
前面的文章已经提过，DDoS攻击存在的主要原因之一是网络服务的开放性，我们不可能从下层来解决这样的问题（因为服务的可用性是第一要求），只能从上层分析解决.
而应用层已经处于协议栈的最高层，所以，要防御应用层DDoS攻击，只能从应用层以上来寻找解法，故，在这种情况下，除了借助数据统计分析，难道还会有更好的方法么？
原文链接：DDoS攻防战 （一） ： 概述
DDoS攻防战 （二） ：CC攻击工具实现与防御理论
DDoS攻防战（三）：ip黑白名单防火墙frdev的原理与实现