自建CDN防御DDoS（1）：知己知彼，建设持久防线

最新推荐文章于 2023-07-01 22:08:19 发布

糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖

最新推荐文章于 2023-07-01 22:08:19 发布

阅读量214

点赞数

本文链接：https://blog.csdn.net/cpongo4/article/details/89091479

版权

前言

本议题是我们在OWASP杭州区2013年岁末年初安全沙龙中进行分享的内容，在此我们对这个议题的整体内容进行了重新归纳梳理，形成了文字版。

在本文中，DDoS的案例与应对经验均来自于某市场占有率很高的客服系统所遇到的实际场景，分别从成本、效率和具体架构设计（选型、配置、优化等）角度来分析通过自建CDN来应对不同类型的DDoS攻击。

背景介绍

客服系统的主要业务是提供基于网页的实时动态的文字聊天，主要应用在各类网络商品销售、网站在线客服等领域，总用户数58万，同时在线活跃的用户约12万/天。

这些应用领域通常行业之间的竞争比较激烈，其中包括在线下无法名正言顺的灰色+暴利产业，导致竞争对手之间经常发动DDoS恶意攻击。但营销网站往往是单面加速，加上推广时效性很强，很难被彻底打击，于是一些自作聪明的黑客通过攻击网站的在线客服系统，导致网站无法跟访客沟通，不能交易，从而达到恶意攻击的目的。因此客服系统这个原本有助于网站营销的工具反而成了被攻击的主要对象，虽然伤得委屈，但也不得不面对挑战。

我们遭遇的DDoS攻击类型包括：延缓性的CC攻击和致命的大流量攻击。下面将对两种攻击方式的攻击特点、防御思路和我们用过的一些防御方案进行简单的介绍。

延缓性的CC攻击

攻击特点

攻击者借助网络上提供的大量代理服务器IP，利用攻击软件，生成指向受害主机的合法请求。

这类攻击对攻击者来说成本低，而且网上现成的软件多，攻击的风格相对比较”温柔谨慎”，其目的是通过逐渐增多的垃圾请求，消耗服务器的正常应用开销如CPU,内存,网卡压力，甚至是网络拥堵，然后请求无响应，无出口流量，导致网站变慢，达到网站无法访问的目的。

防御思路

对于这类攻击，有两个漏洞特点可以被我们利用，从而阻止这类恶意的CC攻击，关键是响应一定要快。

第一个特征，由于是人为生成了大量的非法请求，引发网络的incoming流量会异常增大（正常情况下，incoming流量小，outgoing流量大）；第二个特征，攻击力度有一个渐增过程，我们要充分利用这个宝贵的时间，让机器第一时间智能的做出反应，调用日志分析脚本做决策，加以防御或者引流。

具体的方法有多种，这里只列举我们所使用的两种：

\\t
使用监控软件的流量监控图来触发日志分析脚本，如图所示（zabbix为例）：
\\t\\t

\\t

利用bash脚本来统计incoming流量，发现异常时，调用相应日志分析脚本，实现阻击。

\\\t

\ #!/bin/bash                                                                                        \ DEV=$1   # 定义监听网卡\ LIMIT=$2 # 定义触发阙值 \ WARN=$3 #定义报警阙值\ TIME=$4 # 定义网卡数据采集频率\ mobile_num=\"13xxxxxxxxxx\"   # 定义接收报警短信手机号码\ LOCK=\"/tmp/.exchange_proxy.lock\"\\ [ -z $DEV ] \u0026amp;\u0026amp; echo \"$0 ethx limit_band(kbps) warn_limit(kbps) seconds\" \u0026amp;\u0026amp; exit 0\ [ -z $LIMIT ] \u0026amp;\u0026amp; LIMIT=800000     # 800 kbps\ [ -z $WARN ]  \u0026amp;\u0026amp;  WARN=900000 # 900 kbps\ [ -z $TIME ]  \u0026amp;\u0026amp;  TIME=10              # 10s\\ send_fetion() {\ #定义飞信报警短信接口\ }\\ while : ; do\     net_flood=`ifconfig $DEV|sed -n \"8\"p`\     rx_before=`echo $net_flood|awk '{print $2}'|cut -c7-`\\     sleep $TIME\\     net_flood=`ifconfig $DEV|sed -n \"8\"p`\     rx_after=`echo $net_flood|awk '{print $2}'|cut -c7-`\\     rx_result=$[(rx_after-rx_before)/$TIME]\\     over_bw=$[(rx_result-LIMIT)]\     if [ $over_bw -gt 0 ];then\         BOOL=`echo \"$rx_result\u0026gt;$WARN\"|bc` #判断是否为攻击\         if [ $BOOL -eq 1 ];then\             # 确认为攻击，执行策略并发送短信\             send_fetion $mobile_num \"$STR\"\         else\             # 流量超标，发送短信，请留意\             send_fetion $mobile_num \"$STR\"\         fi\     fi\ sleep $TIME\ done\

\\t\

过滤脚本实现原理就是在服务器上启动日志分析机制，在第一时间找出异常的IP、Agent，URL或者其它特征码，从内核层利用iptables对恶意IP进行过滤，在应用层上利用nginx的http关键词进行过滤，直接返回badcode 444进行拦截。

方案缺点

无论是从内核级别还是应用级别，对服务器本身的CPU和内存的依赖度高，如iptables的过滤本身对服务器的CPU压力很大，在阻止IP超过15K个，服务器基本不可用了；Nginx在阻止HTTP请求时，由于nginx会给每个http请求分配内存和处理链规则，内存资源耗尽；随着流量的不断增大和攻击时间的持续，网卡压力也大，资源最终被耗尽。

所以，这个方案治标不治本。

致命的大流量攻击

攻击特点

这种攻击通常以tcp syn，icmp和UDP（尤其是UDP包，单UDP的数据包可以很大）方式为主。客服系统遭遇到的最大的一次为16G的攻击流量，整个机房都被影响到。攻击者通常控制大量肉鸡或者直接勾结IDC里的服务器和带宽资源，对目标进行流量打击。此时流量会快速占满服务器的网络带宽，导致无法响应任何用户请求。

这类攻击需要购买大量带宽资源，对于攻击方来说，成本挺高，但是下手“快狠准”，目的是让网站在短时间内彻底无响应。

由于这类攻击会引起流量陡增，IDC里的流量监控设备也会很明显的察觉到这个现象。IDC通常采取的措施一般是丢车保帅，直接将这个被攻击的IP拉黑名单甚至直接拔线，让攻击对象自杀。这对本应该需要帮助的客户无疑是落井下石，雪上加霜。

防御思路

应付此类流量攻击的防御方式有：

架设硬防火墙\\t
租用高防节点\\t
租用CDN分散目标流量\

方案缺点

架设硬防火墙：市面上2G硬防单价在10W左右，集群防御代价更大，虽然硬件级的防御性能较高，但面对流量洪水也是杯水车薪，且副作用也不容小觑。\\t
租用高防节点：高防节点有防御带宽，防御流量，共享独享区分，各个套餐的组合价格相差很大，分流策略也不同，超过高防承诺的流量后，防御失效或者再加钱，但都有性能损耗和副作用。\\t
租用CDN分散目标流量：市面上的CDN提供商都是以流量为收费标准，这对于经常遭受流量攻击的网站来说，反而要为攻击流量买单，这着实让人哭笑不得。\

无论是采购的硬件成本和高防资源还是CDN加速，都成本昂贵，闲时资源利用率低，攻击高峰时面对有组织有规模的流量时又捉襟见肘，还伴有副作用（参见绿盟黑洞防火墙的原理），并非长久之计。

处于弱势的被打击方

综上所述，我们无论做哪个抉择都很痛苦。

我们跟发起攻击的人有过长达近一年的交流，目前了解到这是一个非常完整的产业链（上游人员早已身居海外，远程遥控指挥行动，根本无法查处），他们手上控制了大量的攻击资源，并且攻击资源本身就来自于IDC。攻击者为了快速牟利，本身也喜欢和推荐这种直接了当的方式来对目标进行打击，在发动攻击时，他们能够调集到多个IDC的带宽资源来对目标打击（这一现象也折射出了当前国内不规范的IDC管理）。

从这一角度来看，被打击方永远都处于弱势地位，以势单力薄的架构和极其有限的资源，根本无法抵抗强大的集群资源攻击。

我们一直思考一个问题：如果我们持续投入这些资金，危机过去或者若干年后，能给我们留下些什么？因此，我们跳出了单节点防御和租用CDN的思路，综合上述方案的优点，转而自建CDN的方案。