1 背景介绍
1.1 客户网络状况
3月13日，接到紧急救助电话，描述客户网络遭遇DDOS攻击，被攻击目标为某知名网站的Web服务器，攻击来源无法确定，被攻击目标对外正常服务已经中断，无法提供正常服务。
1.2 该网站网络逻辑拓扑结构如下所示：
客户使用2台华为8512设备为核心设备，启用VRRP；接入层为若干华为5024，后台为Linux系统平台的服务器，开放Web服务；在接入层与服务器之间使用负载均衡器，为后台约20组，共计200台web服务器做分发。
2 防御部署
鉴于客户的实际网络情况与黑客攻击情况，与客户方工程师主管协商后，决定将DDOS防御设备放置在网络边界上，充当安全边界设备。但考虑到接入到华为8512外部网络时路由协议可能会重新收敛问题，故将DDOS防御设备放置于华为 8512内部。具体放置情况如下图所示：
在图2所述客户网络实际拓扑结构中，由于网络核心设备启用了VRRP协议，故首先将华为8512 Active 核心交换的流量切换到华为8512 Standby核心交换上，同时将DDOS防御设备接入Active侧网络，在做好所有防护配置后，再将流量切换到8512 Active核心交换设备上；通过此方法，使得DDOS防御设备实现无缝平滑上架；（其实也可以直接在Standby侧上线后再切过来）。
3 数据统计分析以及防御实施
3.1 黑客攻击分析
通过现场检测，发现黑客攻击手段为复合型攻击，其攻击手段为Connection Flood + SYN Flood + Connections Per Second 攻击。
A、 被攻击服务器上打开了大量的TCP SYN_RCVD连接，Client IP地址散列，服务器本地端口为80，是非常明显的DDOS 的SYN Flood 攻击；
B、 攻击源IP地址来自10.0.0.0，127.0.0.0 ，219.148.0.0 ，221.23.0.0，218.5.0.0 ，211.94.0.0 ，221.23.0.0 ，120.160.0.0 ，20.170.218.0 ， 22.82.205.0 ，59.33.0.0等数十个网段，既有私有地址，也有实际地址，也就是说源地址散列，同时源端口散列，使得无法通过一般的ACL技术来屏蔽攻击；所有攻击来源中，大约有50%为127.0.0.0网段地址；
C、 网络流量为900~1000M每秒，而用户反映平时正常流量仅为200M多。在此情况下，后台服务器已经完全不能工作，而负载均衡设备也在强大的压力下频繁切换 Active/Standby，从而造成网络不稳定。
鉴于黑客攻击手段较多，计划采取多种复合防御手段防护此次攻击。
所谓分布式拒绝服务攻击，就是通过分布在不同地点的计算机同时发起大量的无效的、无用的、非法请求，达到占用网络带宽、占用服务器系统资源等方式，从而使服务器不能正常地提供服务；下面我们来分析黑客进攻所使用DDOS攻击：
SYN Flooding：通过TCP协议的3次握手原理，只发送SYN到服务器，当服务器响应SYN+ACK时，不回应ACK，从而使得服务器的TCP连接表被大量的Time Waiting 连接所占满，使得合法用户无法建立起新的连接，达到拒绝服务攻击的目的；该网站此次所遭遇到的攻击之一，就是属于此类攻击。
对于此种攻击，可采取SYN Proxy技术，通过校验访问链接来源的有效性，从而防范了该种类型的攻击。
Connections Flooding：由于防御SYN Flooding攻击的方法越来越多，使得一般的SYN Flooding攻击不再具有足够的威胁，于是黑客们发展出更多的DOS攻击种类；所谓Connections Flooding，是指黑客控制大量的傀儡机（行话叫“肉鸡”），对服务器发起大量的Connections，与常规SYN Flooding不同的是，这次“肉鸡”们将完成与服务器的TCP 3次握手，但是在连接建立起来以后，所有肉鸡将不传送任何数据，从而达到通过占满服务器TCP Connection Table表或者服务器访问人数上限，使得服务器无法对外提供服务的攻击；
针对此类攻击，在实现SYN proxy的基础上，通过采用限制每个IP的同时连接数，从而有效地防范了该种类型攻击并降低服务器负担。
此外，此种攻击还用一个变种，名为实载攻击，就是所谓CC攻击，既是正常与服务器建立连接，然后发送大量的http请求，但是请求内容为无效或高负载内容，且请求数据非常庞大，导致服务器不断读取请求数据内容，从而占用大量内存直至死机；对于这种类型的攻击，由于是属于正常连接类型，所以不能提通过简单的阻止连接来实现防御，否则将会阻挡正常用户的访问从而形成误报；在该网站所遭受的攻击中，即有此种类型攻击。
通过限制每个Client总连接数，可达到一定的防御目的，但对于未达到Client连接总数限制的请求，DDOS防御设备将予以放行，所以乃有少量的合法连接接入了服务器，并向服务器传递非法请求；对此，可以对Client连接总数的阀值进行修改，适当减少或者增加连接数，在2者之间取一个平衡点；
此外，还可以抓取非法请求的内容，然后针对内容进行清洗；其原理为抓包然后分析这些CC攻击所请求的页面或内容，找出其规律，然后将此类CC攻击请求报文的特征码提交到DDOS防御设备上，并实行过滤。
一个附加的问题是，如果找不到请求的报文内容特征码，可用过一些其他的特征，如HTTP GET/ HTTP POST请求报文的大小,字长等其它第三特征来做简单过滤，虽然可能产生误伤，但可作为最后手段使用。
在此次防御过程中，抓包后发现黑客的HTTP请求报文的内容居然是射雕英雄传的小说内容，大小为4K左右，这个黑客真是懒到家了，估计是直接从某些小说网站上Copy下来直接塞进攻击软件中的。
Connection Per Second Flooding ：此类型攻击方法的原理是，通过在同一时间内向服务器发起大量的TCP 连接请求，并完成3次握手，然后再断开连接，再建立连接，如此反复；此种攻击使得服务器在短时间内无法相应正常用户的访问请求，从而达到拒绝服务攻击的目的；该网站所受攻击中，这也是其中之一。
可采取通过限制每个Client在同一时间内的CPS数来实现防御该种类型的攻击。
3.2 防御实施
在分析黑客的进攻手法后，实施了如下防护手段：
A、首先打开DDOS防御设备的TCP SYN Proxy功能实现对源地址的校验，把来自虚假地址的攻击进行屏蔽；
B、 限定CPS（Connection Per Second ）值，即限定每秒新建连接数为50 次/秒。
C、 针对Connection Flooding攻击，激活对Connections Flooding攻击的防护功能，限定每Client同时保持连接数为25个
D、打开包过滤功能，对所有来自10.x.x.x，127.x.x.x等这些非正常源地址的报文进行过滤，
E、 最后的CC攻击，通过手工取样后，发现无法从请求的内容中找到规律，因此采用了第三方特征来进行过滤，即手工书写了过滤条件，判断所有请求报文，对于大于4K的请求报文一律丢弃，并将此策略在DDOS防御设备上启用。
在打开上述防御措施后，对于SYN Flooding类攻击被彻底防范；而CPS攻击也被限定在一定的范围内，从而使得黑客的CPS/Connection Flooding攻击对于服务器不再具有压倒性的威胁；由于每个Client仅仅能同时与服务器建立25个连接，所以远远不能达到DDOS攻击的目的，从而不再对服务器严重威胁。
3.3 防御情况
在经过上述攻击防护策略防护后，通过日志分析以及监控，网络情况如下：
A、 在后台服务器上，TCP半连接基本消失；说明SYN Proxy技术对于防御SYN Flood 攻击有着非常明显的有效防护。
B、 数据流量已经从900M左右降低到250M左右，说明对于实载型Connection Flooding攻击与CPS攻击提供了有效防护；同时，可以通过调整同时连接数与CPS数的阀值，进一步的降低黑客攻击流量，但误伤肯定存在，因此要找到策略的平衡点。
C、 通过日志分析，我们发现从19:27:33 到20:49:46 短短1个小时时间内，客户网络受到了高强度的攻击，黑客能够在短短几秒秒内，让一台服务器因资源耗尽而死机。
D、 在经过防护后，后台服务器基本能够恢复工作，能够提供服务。
4 安全建议
通过以上数据统计与分析，我们得出如下结论：
A、 目前对于DDOS类攻击的防御措施不够强健，建议对网络安全实施加固。
为避免再度遭受相同攻击，建议安全解决方案如下图所示：
建议在网络中部署2台DDOS设备作为安全边界，同时在设备之间启用HA，从而提高可靠性，采取上述网络安全设计后，能够实现：
A. 能够提供我们所遇见的SYN Flooding、Connection Flooding、CPS等各种类型DDOS攻击，但对于UDP Flooding等类型的毫无技术含量的纯粹堵带宽的攻击，可让上级ISP的协助启用路由下水道技术。
B. 在保证安全性的同时，设备的性能是很高的，设备的处理能力完全可以满足现有网络环境下对设备性能的要求，目前的性能是在启用了894个攻击过滤器的条件下获得的。由于采用了FPGA芯片技术，因此所有的策略均可现场编程至芯片中执行，而该芯片可以支持多达10，000条过滤器的并行处理，保证扩展能力，完全可以满足客户对性能的高要求。
5 总结
A. 任何设备都不是万能的，最重要的还是人，而不是机器。
B. 误伤是肯定存在的，不要相信任何零误报的谎言。
C. DDOS的攻击有很多种类，某些种类是不能靠客户端来防御的，必须与上级ISP合作。
D. 现在的鸟人们真懒，连个数据包都懒的构造，直接抓小说内容来填充。
E. 本文内容仅供参考，如有雷同，实属巧合；请勿与任何实际案例挂钩，本人不负任何法律责任，谢谢。
[/img]..
社区：
