在本系列的第一篇文章中,我们介绍了我们客服系统遇到DDoS攻击的情况,以及我们为什么决定采用自建CDN的方式来解决这个问题的原因。
之后,我们介绍了自建CDN的具体建设规划,主要从以下几个方面进行考量:硬件成本、带宽成本、架构设计、实际部署。
本文是《自建CDN防御DDoS》系列的第三篇,介绍CDN架构的后续改进。后续改进主要包括三个方面:DNS智能解析+轮询+存活监测,集中式日志分析+攻击防御,以及多节点CDN的快速部署+图形化管理。
我们自建CDN的另外一个目的是做访问路径优化,因为这些加速节点是我们精心挑选之后部署的,无论是带宽质量、机房环境、安全风险等指标均能满足可靠可控的需求。
因此当部署完多个CDN节点后,为使这些节点协同运作,同时优化用户的访问路径,我们可以通过配置Bind的View视图把访客IP指定到相应的CDN节点,使得访客能够根据自己所在的区域和线路类型,就近从CDN节点上获取页面内容,从而优化访客的路由。
我们可以利用DNS轮询来为网站进行分流负载。如果条件充裕,可以在各个大区内部署冗余的CDN节点,这样既能缓解某个区域内单一节点的负载,同时能为这个节点作互备,当这个区内的CDN节点因故障失效之后,调度机制能在最快时间内将故障节点的流量牵引至当前可用节点,实现动态的剔除该节点,从而不影响访客的正常请求。
实现DNS轮询只需要在Bind中为同一域名添加多个A记录即可。Bind View视图功能和节点存活检查的相关技术已经相当成熟,相应的技术文档也比较多了,可以参考《使用Bind构建高可用智能DNS服务器》,这里我们就不再累述。
我们目前编写的脚本可以帮忙快速分拣出电信、联通的线路还包括华东、华南、华北和西部四个地区的IP范围,有兴趣的同学可以试用一下。
Default
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
|
# 这个脚本是从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下载获取。
CDN作为网站的前置节点,实时记录着所有访客的访问行为。可以说,日志当中蕴藏了丰富的奥秘。据了解,大部分网站并没有对其访问日志进行很好的利用,仅仅是对其做了归档备份。如能利用好这些访问日志,并对其进行深度的分析和挖掘,对于了解网站的运行状况、感知业务层面的一些异常活动,能够带来极大的帮助。尤其是当面临DDoS攻击时,能够提供出足够的依据来区分恶意的IP。
区分恶意攻击的主要依据类型有:
目前我们对HAProxy的日志分析仅作用于单节点,我们在实际应用场景中,是基于单位时间段的日志截断,把日志写入到/dev/shm内存中,使用了通用的shell,awk,sed语言来做行为分析,这样做的好处是避免了磁盘IO开销的短板。缺点是,日志分析行为比较粗糙,分析效率有待于提高。
由于作用于单节点的日志分析架构存在较大的局限性,主要体现为:
因此在多节点CDN架构下,如要及时感知到DDoS攻击并对其进行阻断,而且还要考虑尽可能少的开销用节点系统资源,需要站在全局层面来集中分析攻击行为,并且针对分析后的结果展开多节点协同处理防御/阻断规则,来应对DDoS攻击。
对难点进行梳理后,我们发现要实现这样的需求主要解决三个问题:
我们在上一篇文章中已经提到过,在CDN节点端,我们建议用HAProxy或Nginx作为防御性的反向代理,能够灵活的制定防御攻击的ACL过滤规则,并能够以热加载的方式实时生效。
这个环节主要包含两个部分,一是由节点到LogServer的日志传输,另一个是LogServer这一端的日志集中存储。由CDN节点产生的日志可以通过本地写入PIPE + Rsyslog UDP传输的方式将日志汇总到专用的LogServer,LogServer收到日志之后,按照域名分类的方式将日志存储在一起。
对于海量日志的存储可以用Hadoop作为载体,利用Map/Reduce算法分解日志,提升筛选效率。对此有兴趣深入了解的同学可以参考开源日志系统比较。
这里则是最为关键的一个环节:我们整个架构的重点在于“抗攻击”,而我们经过前面的分析,针对多节点CDN的攻击防御,最为高效的做法是:由专用的LogServer进行集中式分析运算,并将运算结果生成安全防护策略,实时对接到各个CDN节点,协同处理防御/阻断规则,以此来应对DDoS攻击。那么这里将会产生以下几个主要问题:
对此我们的设计思路如下:
当日志完整的存储在LogServer之后,使用分析脚本对其进行特征匹配,提取出恶意攻击的来源IP地址,将这些IP地址生成相应的HAProxy/Iptables的阻断规则,并下发到全局的CDN节点。这里可以通过两种方式来进行:
管理和运维一套CDN系统对于任何组织来讲都是个很大的挑战,尤其是部署了多区域多线路的CDN。需要随时掌控CDN加速的节点列表、需要定义哪些网页元素可以作为缓存、需要做什么样的ACL策略等等,这些都需要专业的系统运维人员来配置实现。
通常较为成熟的做法是通过主控机,预先配置好CDN规则 ,通过Rsync把配置文件推送到各个CDN节点中去。很显然,这种方案虽然效率高,但是对CDN部署者具有一定的门槛,加上服务器的权限控制要求非常严格,也不利于面向其它工程师做推广。
偶然的机会,我们有幸在黑客马拉松大赛初识了OpenCDN这个获奖作品,通过互补整合,更是弥补了我们这套CDN上的前端管理的不足。因此,可以跟OpenCDN这个项目做很好的深度整合,降低运维和管理门槛,造福于更多的IT运维的用户。
OpenCDN是一套快速部署CDN加速的工具,针对专门提供CDN加速服务的企业或对多节点CDN加速有需求的企业提供一套便捷的管理平台,可对每一个节点的状态、系统负载进行实时监测与统一管理。OpenCDN预制了多套常用缓存规则,支持多种复杂的CDN缓存场景。正如其名,OpenCDN是免费开源的。
OpenCDN的主体架构可分为CDN管理中心和CDN加速节点。CDN加速节点可以有很多个,在数量上没有任何限制。用户可以通过OpenCDN快速的部署多个CDN加速节点,并通过一个管理中心进行集中式的管理。
因此OpenCDN在这里主要做了两部分工作,一是将CDN节点的部署过程一键化,二是通过WebConsole工具将这些CDN加速节点统一的管理起来。
OpenCDN将致力于为多节点CDN加速有需求的网站,提供一套便捷的CDN加速管理平台,能够按需自建CDN节点,灵活控制成本,提高网站响应速度,轻松应对突发流量。
后续我们将在此基础上整合加入上述CDN防御大流量DDoS攻击的组合方案。我们对这套平台做了开源,希望有更多有需要的人能够以最低的成本获取它,同时也希望通过更多的开发者加入进来一起完善它。所谓人人为我,我为人人。
OpenCDN目前来看,比较适用于行业竞争比较大的网站:
游戏站、垂直电商、社区论坛、在线视频、聊天。
这些网站的共性特点:流量中型规模,竞争激烈,经常被攻击,行业利润高,愿意花钱。
至此,《自建CDN防御DDoS》系列便告一段落。如果有任何疑问,欢迎跟我们交流、探讨。
自建CDN防御DDoS(1):知己知彼,建设持久防线
自建CDN防御DDoS(2):架构设计、成本与部署细节
【via@邵海杨,张磊,来自infoq】 注:文章系13年的,也许有一天技术会过时,但思路不会。
Copyright © hongdaChiaki. All Rights Reserved. 鸿大千秋 版权所有
联系方式:
地址: 深圳市南山区招商街道沿山社区沿山路43号创业壹号大楼A栋107室
邮箱:service@hongdaqianqiu.com
备案号:粤ICP备15078875号