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

前言

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

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

背景介绍

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

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

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

延缓性的CC攻击

攻击特点

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

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

防御思路

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

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

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

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

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

#!/bin/bash
DEV=$1 # 定义监听网卡
LIMIT=$2 # 定义触发阙值
WARN=$3 #定义报警阙值
TIME=$4 # 定义网卡数据采集频率
mobile_num="13xxxxxxxxxx" # 定义接收报警短信手机号码
LOCK="/tmp/.exchange_proxy.lock"

[ -z $DEV ] && echo "$0 ethx limit_band(kbps) warn_limit(kbps) seconds" && exit 0
[ -z $LIMIT ] && LIMIT=800000 # 800 kbps
[ -z $WARN ] && WARN=900000 # 900 kbps
[ -z $TIME ] && 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>$WARN"|bc` #判断是否为攻击
if [ $BOOL -eq 1 ];then
# 确认为攻击，执行策略并发送短信
send_fetion $mobile_num "$STR"
else
# 流量超标，发送短信，请留意
send_fetion $mobile_num "$STR"
fi
fi
sleep $TIME
done

过滤脚本实现原理就是在服务器上启动日志分析机制，在第一时间找出异常的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拉黑名单甚至直接拔线，让攻击对象自杀。这对本应该需要帮助的客户无疑是落井下石，雪上加霜。

防御思路

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

1.架设硬防火墙

2.租用高防节点

3.租用CDN分散目标流量

方案缺点

架设硬防火墙：市面上2G硬防单价在10W左右，集群防御代价更大，虽然硬件级的防御性能较高，但面对流量洪水也是杯水车薪，且副作用也不容小觑。

租用高防节点：高防节点有防御带宽，防御流量，共享独享区分，各个套餐的组合价格相差很大，分流策略也不同，超过高防承诺的流量后，防御失效或者再加钱，但都有性能损耗和副作用。

租用CDN分散目标流量：市面上的CDN提供商都是以流量为收费标准，这对于经常遭受流量攻击的网站来说，反而要为攻击流量买单，这着实让人哭笑不得。

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

处于弱势的被打击方

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

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

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

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

长久之计：自建CDN

自建CDN的好处有几个方面：

1.旁路做流量清洗（痘痘长在别人脸上最好）

2.资源充分利用：无攻击的时候，做路由加速，有攻击的时候，做节点切换（一物多用）

3.随着投入的资金增加，防御DDoS攻击的能力增强（长远规划，资金回报率高）

有关自建CDN具体建设的思路如何，成本多少，我们会在系列的下一篇文章中进行介绍。

自建CDN防御DDoS（2）：架构设计、成本与部署细节

在本系列的第一篇文章中，我们介绍了我们客服系统遇到DDoS攻击的情况，以及我们为什么决定采用自建CDN的方式来解决这个问题的原因。

下面，我们将介绍自建CDN的具体建设规划，主要从以下几个方面进行考量：硬件成本、带宽成本、架构设计、实际部署。

硬件成本

在硬件上，我们选型的需求是在1U的基础上具有强劲的性能，同时性价比要高。

我们选择了（强氧）双子星服务器，其硬件规格为：1U机身+支持双路至强CPU+最大支持48G内存+双千兆网口x2+H3C S1208八口千兆，提供三年质保服务，总价约1.5万。

带宽成本

单线机房的机房和带宽资源，由于不需要经过第三方拉线撮合，直接从运营代理商购买，因此选择余地大，性价比高。以租用电信、联通单线资源为例，每条线独享100M带宽，提供8个IP，有些机房自带硬防，能够防御5G-10G流量。

平均费用，每个节点带宽成本基本在1.6~2.5万/年。

架构设计

CDN架构上要充分体现出抗攻击能力和灵活应变的原则。因此，我们将CDN节点分解成反向代理+缓存加速+攻击防御这三个不同层次的功能结构。

1.反向代理功能（作用：路由加速，隐藏主节点，负载均衡）

2.缓存加速功能（作用：静态推送，节省后端主节点带宽）

3.攻击防御功能（作用：快速解析，匹配过滤恶意攻击）

开源世界里能够担当反向代理及缓存的软件不少，而且各有优劣。作为架构师，要考虑如何选型，我们从性能、功能、配置上来进行比较筛选。

我们对这三层功能结构分别进行了测试调优及生产线的实践检验，从以下方面评估：

1.HTTP防御性能：HAProxy在应对大流量CC攻击时，做正则匹配及头部过滤时，CPU消耗只占10%~20%。其它软件均狂占CPU资源约90%以上，容易成瓶颈导致整个系统无响应。

2.反向代理性能：单纯转发效率以内存缓存型的Varnish性能最强，ATS和Nginx次之，考虑大容量缓存因素，ATS也是个不错的选择，但文档缺乏，需要持续关注。Nginx是专门针对C10K的产物，性能不错，配合众多插件，改造性很强。

3.过滤规则的可配置性：HAProxy，ATS，Squid均支持规则文件读取、ACL定制和热加载、热启动。Nginx则不支持外部文件正则匹配，略差一点，但可塑性强。

因此，综合上述考虑，最终我们采用的架构是HAProxy+Varnish/ATS/Nginx的组合，即防御型反向代理缓存方案，功能角色如下：

1.前面由HAProxy全力负责动静资源分离，实现会话粘滞，节点负载均衡，故障转移，遇到危急时承担基于Http协议的CC类型攻击防御。

2.后面为可插拔替换的反向代理缓存引擎：根据生产线上的实际应用场景及缓存对象的容量来决定使用内存型的varnish或者是磁盘型的ats，如果需要定制功能很强（防盗链）的反向代理如Nginx+plugins。

这个组合最大的特点是：

l.支持外部过滤规则的读取，尤其是关键字符串无需转义，可直接追加到文件中。

2.支持配置文件热加载生效，都支持reload，服务平滑生效。

3.可插拔式的缓存组件灵活应对各种业务需求。

4.部署简单，节点失效/生效切换方便。

LVS缺席：为什么这里没有提及LVS，因为LVS是个重量级、高效稳定的四层转发，不能作七层HTTP协议的识别，但完全可以架设在七层之前。所以，LVS的使用并不会影响网络结构，后续仍然可以想上就上，只是前提要兼顾到LVS的单点故障。

实际部署

最终我们在主节点周围一共部署了8个CDN节点（节点数量根据自身公司实力及实际生产环境要求而灵活调整，此数字仅作参考），这些节点又按照地域划分成了四个大区：北方（以山东，河北为主）、西南（以四川为主）、华东（以宁波，嘉兴为主） 华南（以福建，湖南为主 ）兼顾全国各个省份。

总体成本情况

8个单线加速节点，每个节点100Mx8，8台双子星服务器，总共投资约30W（后续费用只考虑带宽支出，约15W/年），我们应急拨款为10W，每个月CDN预算为2W。

项目进度安排：

1～4个月抓进度：特点是快速部点。这里有个诀窍，前期可以先跟IDC按月或者季度签约，然后通过监控看连续的节点质量，如果节点质量不佳，更换提供商，这样损失不会太大，如果节点质量好，就半年付或者年付，这样就可以保证质量和性价比最高；

5～8个月为完善期：根据预算，有节奏的加点，加带宽，保证带宽的冗余度；

8个月以后为稳定期：根据实际情况保证节点的最大可用性，同时也提升了整体防御能力。

如何做防护策略

开启HAProxy的httplog功能，记录日志。

HAProxy的配置策略：

global
nbproc 24
pidfile /var/run/haproxy.pid
daemon
quiet
user nobody
group nobody
chroot /opt/haproxy
spread-checks 2

defaults
log 127.0.0.1 local5
mode http
option forwardfor
option httplog
option dontlognull
option nolinger # reduce FIN_WAIT1
option redispatch
retries 3
option http-pretend-keepalive
option http-server-close
option accept-invalid-http-request
timeout client 15s
timeout connect 15s
timeout server 15s
timeout http-keep-alive 15s
timeout http-request 15s

stats enable
stats uri /stats
stats realm 53KF\ Proxy\ Status
stats refresh 60s
stats auth admin:adminxxx

listen Web_FB 0.0.0.0:80
option httpchk GET /alive.php HTTP/1.0

acl invalid_referer hdr_sub(referer) -i -f /opt/haproxy/etc/bad_ref.conf
acl invalid_url url_sub -i -f /opt/haproxy/etc/bad_url.conf
acl invalid_methods method -i -f /opt/haproxy/etc/bad_method.conf
block if invalid_referer || invalid_url || invalid_methods

acl dyn_host hdr(host) -i -f /opt/haproxy/etc/notcache_host.conf
acl static_req path_end -i -f /opt/haproxy/etc/allow_cache_file.conf
use_backend img_srv if static_req !dyn_host

# acl shaohy
acl geek hdr_dom(host) -i 17geek.com
use_backend geek if geek

# backend shaohy
backend geek
mode http
balance source
cookie SESSION_COOKIE insert indirect nocache
option tcpka
server geek_1 127.0.0.1:81 cookie geek_1 maxconn 10000 weight 8

backend img_srv
mode http
option tcpka
server img_srv 127.0.0.1:88 maxconn 30000 weight 8

Varnish的配置策略：

backend h_17geek_com_1 {
.host="127.0.0.1";
.port="81";
.connect_timeout=300s;
.first_byte_timeout=300s;
.between_bytes_timeout=300s;
}

director geek srv {
{ .backend=h_17geek_com_1; .weight=3;}
}

sub vcl_recv {
if (req.http.host~"^(www).?17geek.com$"){
set req.backend=geek_srv;
if (req.request != "GET" && req.request != "HEAD") {
return (pipe);
}
if(req.url ~ "\.(php|jsp)($|\?)") {
return (pass);
}
else {
return (lookup);
}
}
}

对于CC类型的DDoS攻击，通过第一篇当中介绍的监控异常流量的方法依然适用，而且优势更明显，因为：

1.节点各自承担相应的日志记录，分析日志的系统开销，发现异常请求后直接在haproxy前端做ACL规则 过滤，因此，攻击压力不会传递给后端服务器，保证后端安全。

2.节点受到的攻击流量过大，机房可以拉黑IP或者引流，后端智能DNS会自动把这个节点剔除，后续请求不要通过此节点。

在本系列的下一篇文章中，我们会介绍这个CDN架构的一些后续改进工作，包括智能DNS、大规模日志分析、利用OpenCDN改善后台管理等。

自建CDN防御DDoS（3）：架构的后续改进

在本系列的第一篇文章中，我们介绍了我们客服系统遇到DDoS攻击的情况，以及我们为什么决定采用自建CDN的方式来解决这个问题的原因。

之后，我们介绍了自建CDN的具体建设规划，主要从以下几个方面进行考量：硬件成本、带宽成本、架构设计、实际部署。

本文是《自建CDN防御DDoS》系列的第三篇，介绍CDN架构的后续改进。后续改进主要包括三个方面：DNS智能解析+轮询+存活监测，集中式日志分析+攻击防御，以及多节点CDN的快速部署+图形化管理。

1、DNS智能解析+轮询+存活监测

A. 部署智能DNS就近匹配CDN节点

我们自建CDN的另外一个目的是做访问路径优化，因为这些加速节点是我们精心挑选之后部署的，无论是带宽质量、机房环境、安全风险等指标均能满足可靠可控的需求。

因此当部署完多个CDN节点后，为使这些节点协同运作，同时优化用户的访问路径，我们可以通过配置Bind的View视图把访客IP指定到相应的CDN节点，使得访客能够根据自己所在的区域和线路类型，就近从CDN节点上获取页面内容，从而优化访客的路由。

B. DNS自动轮询+故障监测

我们可以利用DNS轮询来为网站进行分流负载。如果条件充裕，可以在各个大区内部署冗余的CDN节点，这样既能缓解某个区域内单一节点的负载，同时能为这个节点作互备，当这个区内的CDN节点因故障失效之后，调度机制能在最快时间内将故障节点的流量牵引至当前可用节点，实现动态的剔除该节点，从而不影响访客的正常请求。

实现DNS轮询只需要在Bind中为同一域名添加多个A记录即可。Bind View视图功能和节点存活检查的相关技术已经相当成熟，相应的技术文档也比较多了，可以参考《使用Bind构建高可用智能DNS服务器》，这里我们就不再累述。

C. Bind View IP分拣脚本

我们目前编写的脚本可以帮忙快速分拣出电信、联通的线路还包括华东、华南、华北和西部四个地区的IP范围，有兴趣的同学可以试用一下。

# 这个脚本是从Apnic下载属于中国的IP列表，然后把属于联通，电信及其它的IP进行归类
get_apnic(){
FILE=$PWD/ip_apnic
CNC_FILE=$PWD/CNC
CTC_FILE=$PWD/CTC
TMP=/dev/shm/ip.tmp
rm -f $FILE
wget http://ftp.apnic.net/apnic/stats/apnic/delegated-apnic-latest -O $FILE

grep 'apnic|CN|ipv4|' $FILE | cut -f 4,5 -d'|'|sed -e 's/|/ /g' | while read ip cnt
do
echo $ip:$cnt
mask=$(cat << EOF | bc | tail -1

pow=32;
define log2(x) {
if (x<=1) return (pow);
pow--;
return(log2(x/2));
}

log2($cnt)
EOF
)

whois $ip@whois.apnic.net > $TMP.tmp
sed -n '/^inetnum/,/source/p' $TMP.tmp | awk '(/mnt-/ || /netname/)' > $TMP
NETNAME=`grep ^netname $TMP | sed -e 's/.*: \(.*\)/\1/g' | sed -e 's/-.*//g'|sed 's: ::g'`

egrep -qi "(CNC|UNICOM|WASU|NBIP|CERNET|CHINAGBN|CHINACOMM|FibrLINK|BGCTVNET|DXTNET|CRTC)" $TMP
if [ $? = 0 ];then
echo $ip/$mask >> $CNC_FILE
else
egrep -qi "(CHINATELECOM|CHINANET)" $TMP
if [ $? = 0 ];then
echo $ip/$mask >> $CTC_FILE
else
sed -n '/^route/,/source/p' $TMP.tmp | awk '(/mnt-/ || /netname/)' > $TMP
egrep -qi "(CNC|UNICOM|WASU|NBIP|CERNET|CHINAGBN|CHINACOMM|FibrLINK|BGCTVNET|DXTNET|CRTC)" $TMP
if [ $? = 0 ];then
echo $ip/$mask >> $CNC_FILE
else
egrep -qi "(CHINATELECOM|CHINANET)" $TMP
if [ $? = 0 ];then
echo $ip/$mask >> $CTC_FILE
else
echo "$ip/$mask $NETNAME" >> $PWD/OTHER
fi
fi
fi
fi
done
rm -rf $TMP $TMP.tmp
}

# 从whois信息中提取address登记人地址信息，从而判断在哪个省份
gen_zone(){
FILE=$2
[ ! -s $FILE ] && echo "$FILE file not found." && exit 0

rm -rf $FILE.zone
while read LINE;do
LINE=`echo "$LINE"|awk '{print $1}'`
echo "$LINE @ "
echo -n "$LINE @ " >> $FILE.zone
whois $LINE|egrep "address"|xargs echo >> $FILE.zone
sleep $TIME
done < $FILE
}

# 分别挑选出华东，华南，华北，西部四大区的IP地址列表
gen_area(){
FILE=$2
[ ! -s $FILE.zone ] && echo "$FILE.zone file not found." && exit 0

STRING="none"
echo $FILE|egrep -i -q "cnc"
[ $? = 0 ] && STRING="cnc"
echo $FILE|egrep -i -q "ctc"
[ $? = 0 ] && STRING="ctc"
echo $FILE|egrep -i -q "other"
[ $? = 0 ] && STRING="other"

[ $STRING = "none" ] && echo "Not cnc or ctc file" && exit 0

cp -a $FILE.zone $FILE.tmp

egrep -i "$HD_STR" $FILE.tmp > $HD_FILE.$STRING
egrep -i -v "$HD_STR" $FILE.tmp > aaa
mv aaa $FILE.tmp

egrep -i "$HN_STR" $FILE.tmp > $HN_FILE.$STRING
egrep -i -v "$HN_STR" $FILE.tmp > aaa
mv aaa $FILE.tmp

egrep -i "$XI_STR" $FILE.tmp > $XI_FILE.$STRING
egrep -i -v "$XI_STR" $FILE.tmp > aaa
mv aaa $FILE.tmp

egrep -i "$HB_STR" $FILE.tmp > $HB_FILE.$STRING
egrep -i -v "$HB_STR" $FILE.tmp > aaa
mv aaa $FILE.tmp

grep ^[0-9] $FILE.tmp |awk '{print $1}' >> $HD_FILE.$STRING
sed -r -i 's#@.*##g' *.$STRING

rm -rf $FILE.tmp
}

2、集中式日志分析+攻击防御

CDN作为网站的前置节点，实时记录着所有访客的访问行为。可以说，日志当中蕴藏了丰富的奥秘。据了解，大部分网站并没有对其访问日志进行很好的利用，仅仅是对其做了归档备份。如能利用好这些访问日志，并对其进行深度的分析和挖掘，对于了解网站的运行状况、感知业务层面的一些异常活动，能够带来极大的帮助。尤其是当面临DDoS攻击时，能够提供出足够的依据来区分恶意的IP。

区分恶意攻击的主要依据类型有：

1.某个IP发起大量的并发请求

2.大量连续的IP段发起请求

3.大量无规则的IP发起请求

目前我们对HAProxy的日志分析仅作用于单节点，我们在实际应用场景中，是基于单位时间段的日志截断，把日志写入到/dev/shm内存中，使用了通用的shell，awk，sed语言来做行为分析，这样做的好处是避免了磁盘IO开销的短板。缺点是，日志分析行为比较粗糙，分析效率有待于提高。

A. 多节点CDN集中式日志分析+攻击阻断架构

由于作用于单节点的日志分析架构存在较大的局限性，主要体现为：

1.日志散落在各个节点，分析时忽略了其他节点的数据，无法获悉全局的情况

2.当防御规则启用后，仅作用于单节点，其他节点依旧面临该特性的攻击

3.单节点的实时分析当面临攻击时，会占用较大系统资源

因此在多节点CDN架构下，如要及时感知到DDoS攻击并对其进行阻断，而且还要考虑尽可能少的开销用节点系统资源，需要站在全局层面来集中分析攻击行为，并且针对分析后的结果展开多节点协同处理防御/阻断规则，来应对DDoS攻击。

对难点进行梳理后，我们发现要实现这样的需求主要解决三个问题：

汇集多个CDN节点的海量日志存储

针对海量日志的集中式风险分析

协同运作的攻击阻断机制

具体架构：

Nginx/HAProxy作为防御攻击系统的终端

节点产生的访问日志通过syslog传送到专用的LogServer进行汇集

专用的LogServer作为日志的存储和风险分析、阻断规则推送

a. HAProxy/Nginx作为防御攻击系统的载体

我们在上一篇文章中已经提到过，在CDN节点端，我们建议用HAProxy或Nginx作为防御性的反向代理，能够灵活的制定防御攻击的ACL过滤规则，并能够以热加载的方式实时生效。

b. 日志存储解决思路

这个环节主要包含两个部分，一是由节点到LogServer的日志传输，另一个是LogServer这一端的日志集中存储。由CDN节点产生的日志可以通过本地写入PIPE + Rsyslog UDP传输的方式将日志汇总到专用的LogServer，LogServer收到日志之后，按照域名分类的方式将日志存储在一起。

对于海量日志的存储可以用Hadoop作为载体，利用Map/Reduce算法分解日志，提升筛选效率。对此有兴趣深入了解的同学可以参考开源日志系统比较。

c. 协同运作的攻击阻断机制

这里则是最为关键的一个环节：我们整个架构的重点在于“抗攻击”，而我们经过前面的分析，针对多节点CDN的攻击防御，最为高效的做法是：由专用的LogServer进行集中式分析运算，并将运算结果生成安全防护策略，实时对接到各个CDN节点，协同处理防御/阻断规则，以此来应对DDoS攻击。

那么这里将会产生以下几个主要问题：

采用什么样的脚本和规则来分析日志

分析后的结果如何形成HAProxy/Iptables的ACL策略

生成的ACL策略如何作用到全局的CDN节点，并形成联动

对此我们的设计思路如下：

当日志完整的存储在LogServer之后，使用分析脚本对其进行特征匹配，提取出恶意攻击的来源IP地址，将这些IP地址生成相应的HAProxy/Iptables的阻断规则，并下发到全局的CDN节点。这里可以通过两种方式来进行：

1.通过开发专用的接口与Iptables、Nginx/HAProxy进行联动

2.通过统一配置管理工具Puppet推送来实现，LogServer作为消息的推送端与命令下发主控端，各个CDN节点作为策略的接收端与生效命令执行端，在接收完防护策略后，自动加入ACL列表，执行热加载的命令

B. 该架构的优势

这套架构得以实现之后，系统的横向扩展将变得非常容易，能根据节点的流量/资源负载情况，动态的添置或下线CDN节点，无需对源站点进行任何改动。

能够从容的应对DDoS攻击，在分散攻击流量的同时，能够自动阻断攻击来源。

并且对于新的攻击，只要在某一站点发现异常，即可快速编制新防护规则，将屏蔽措施应用到所有加入CDN的站点，实现全局的安全防护。

将各个CDN节点上的日志进行汇总收集/分析，能够获取到所有用户详细的访问行为，同时对所有的非法访问行为进行均记录在案，通过编制业务安全规则，可提供事前预警、事后追踪。

3、多节点CDN的快速部署与图形化管理

管理和运维一套CDN系统对于任何组织来讲都是个很大的挑战，尤其是部署了多区域多线路的CDN。需要随时掌控CDN加速的节点列表、需要定义哪些网页元素可以作为缓存、需要做什么样的ACL策略等等，这些都需要专业的系统运维人员来配置实现。

通常较为成熟的做法是通过主控机，预先配置好CDN规则 ，通过Rsync把配置文件推送到各个CDN节点中去。很显然，这种方案虽然效率高，但是对CDN部署者具有一定的门槛，加上服务器的权限控制要求非常严格，也不利于面向其它工程师做推广。

偶然的机会，我们有幸在黑客马拉松大赛初识了OpenCDN这个获奖作品，通过互补整合，更是弥补了我们这套CDN上的前端管理的不足。因此，可以跟OpenCDN这个项目做很好的深度整合，降低运维和管理门槛，造福于更多的IT运维的用户。

A. OpenCDN主要解决什么问题？

OpenCDN是一套快速部署CDN加速的工具，针对专门提供CDN加速服务的企业或对多节点CDN加速有需求的企业提供一套便捷的管理平台，可对每一个节点的状态、系统负载进行实时监测与统一管理。OpenCDN预制了多套常用缓存规则，支持多种复杂的CDN缓存场景。正如其名，OpenCDN是免费开源的。

B. OpenCDN当前是怎么做的？

OpenCDN的主体架构可分为CDN管理中心和CDN加速节点。CDN加速节点可以有很多个，在数量上没有任何限制。用户可以通过OpenCDN快速的部署多个CDN加速节点，并通过一个管理中心进行集中式的管理。

因此OpenCDN在这里主要做了两部分工作，一是将CDN节点的部署过程一键化，二是通过WebConsole工具将这些CDN加速节点统一的管理起来。

C. OpenCDN未来要做出什么样？达到怎么样的效果？

OpenCDN将致力于为多节点CDN加速有需求的网站，提供一套便捷的CDN加速管理平台，能够按需自建CDN节点，灵活控制成本，提高网站响应速度，轻松应对突发流量。

后续我们将在此基础上整合加入上述CDN防御大流量DDoS攻击的组合方案。我们对这套平台做了开源，希望有更多有需要的人能够以最低的成本获取它，同时也希望通过更多的开发者加入进来一起完善它。所谓人人为我，我为人人。

D. OpenCDN进行自建CDN的优势

首先是降低了获取CDN的成本，同时最为关键的是提升了CDN节点的性能。对比租用商业CDN，我们无需再为购买流量而计算成本，形成固定开销的租用模式。

不局限于节点的介质，物理服务器或者VPS均可以适用，可利用不同服务商的VPS构建起一张覆盖全国全网的低成本CDN加速集群。

商业CDN的节点要共享给多个站点同时使用，而这意味着节点的有限资源（并发数）将在同一时间内分享使用，对于带宽/流量要求较高的用户，比较适合自建的架构。

OpenCDN适用于哪些用户？

OpenCDN目前来看，比较适用于行业竞争比较大的网站：游戏站、垂直电商、社区论坛、在线视频、聊天。

这些网站的共性特点：流量中型规模，竞争激烈，经常被攻击，行业利润高，愿意花钱。

总结

至此，《自建CDN防御DDoS》系列便告一段落。如果有任何疑问，欢迎跟我们交流、探讨。