http://www.infoq.com/cn/articles/anti-ddos-cdn-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
}

具体脚本可以通过https://github.com/shaohaiyang/easyMyDNS下载获取。

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

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

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

• 某个IP发起大量的并发请求

• 大量连续的IP段发起请求

• 大量无规则的IP发起请求

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

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

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

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

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

• 单节点的实时分析当面临***时，会占用较大系统资源

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

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

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

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

3. 协同运作的***阻断机制

具体架构：

• 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***。那么这里将会产生以下几个主要问题：

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

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

3. 生成的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的优势

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

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

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

OpenCDN适用于哪些用户？

OpenCDN目前来看，比较适用于行业竞争比较大的网站：

游戏站、垂直电商、社区论坛、在线视频、聊天。

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

总结

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

作者简介

邵海杨（个人页面），来自杭州Linux用户组。网名“海洋之心”，系统架构师，业余撰稿人，致力于开源软件及前沿科技的研究和探索。

张磊（微博，博客），来自杭州谷歌开发者社区。专注于信息安全技术领域，曾主导多项银行/证券行业网站安全测试和***取证分析项目，为四大银行提供安全防护技术支持。目前创业做互联网安全防护。