自建CDN防御DDoSWord文档格式.docx
《自建CDN防御DDoSWord文档格式.docx》由会员分享，可在线阅读，更多相关《自建CDN防御DDoSWord文档格式.docx（22页珍藏版）》请在冰豆网上搜索。
下面将对两种攻击方式的攻击特点、防御思路和我们用过的一些防御方案进行简单的介绍。
延缓性的CC攻击
攻击特点
攻击者借助网络上提供的大量代理服务器IP，利用攻击软件，生成指向受害主机的合法请求。
这类攻击对攻击者来说成本低，而且网上现成的软件多，攻击的风格相对比较”温柔谨慎”，其目的是通过逐渐增多的垃圾请求，消耗服务器的正常应用开销如CPU,内存,网卡压力，甚至是网络拥堵，然后请求无响应，无出口流量，导致网站变慢，达到网站无法访问的目的。
防御思路
对于这类攻击，有两个漏洞特点可以被我们利用，从而阻止这类恶意的CC攻击，关键是响应一定要快。
第一个特征，由于是人为生成了大量的非法请求，引发网络的incoming流量会异常增大（正常情况下，incoming流量小，outgoing流量大）；
第二个特征，攻击力度有一个渐增过程，我们要充分利用这个宝贵的时间，让机器第一时间智能的做出反应，调用日志分析脚本做决策，加以防御或者引流。
具体的方法有多种，这里只列举我们所使用的两种：
1.使用监控软件的流量监控图来触发日志分析脚本，如图所示（zabbix为例）：
2.利用bash脚本来统计incoming流量，发现异常时，调用相应日志分析脚本，实现阻击。
3.#!
/bin/bash
4.DEV=$1#定义监听网卡
5.LIMIT=$2#定义触发阙值
6.WARN=$3#定义报警阙值
7.TIME=$4#定义网卡数据采集频率
8.mobile_num="
13xxxxxxxxxx"
#定义接收报警短信手机号码
9.LOCK="
/tmp/.exchange_proxy.lock"
10.
11.[-z$DEV]&
&
echo"
$0ethxlimit_band（kbps）warn_limit（kbps）seconds"
&
exit0
12.[-z$LIMIT]&
LIMIT=800000#800kbps
13.[-z$WARN]&
WARN=900000#900kbps
14.[-z$TIME]&
TIME=10#10s
15.
16.send_fetion（）{
17.#定义飞信报警短信接口
18.}
19.
20.while:
;
do
21.net_flood=`ifconfig$DEV|sed-n"
8"
p`
22.rx_before=`echo$net_flood|awk'
{print$2}'
|cut-c7-`
23.
24.sleep$TIME
25.
26.net_flood=`ifconfig$DEV|sed-n"
27.rx_after=`echo$net_flood|awk'
28.
29.rx_result=$[（rx_after-rx_before）/$TIME]
30.
31.over_bw=$[（rx_result-LIMIT）]
32.if[$over_bw-gt0];
then
33.BOOL=`echo"
$rx_result>
$WARN"
|bc`#判断是否为攻击
34.if[$BOOL-eq1];
35.#确认为攻击，执行策略并发送短信
36.send_fetion$mobile_num"
$STR"
37.else
38.#流量超标，发送短信，请留意
39.send_fetion$mobile_num"
40.fi
41.fi
42.sleep$TIME
43.done
过滤脚本实现原理就是在服务器上启动日志分析机制，在第一时间找出异常的IP、Agent，URL或者其它特征码，从内核层利用iptables对恶意IP进行过滤，在应用层上利用nginx的http关键词进行过滤，直接返回badcode444进行拦截。
方案缺点
无论是从内核级别还是应用级别，对服务器本身的CPU和内存的依赖度高，如iptables的过滤本身对服务器的CPU压力很大，在阻止IP超过15K个，服务器基本不可用了；
Nginx在阻止HTTP请求时，由于nginx会给每个http请求分配内存和处理链规则，内存资源耗尽；
随着流量的不断增大和攻击时间的持续，网卡压力也大，资源最终被耗尽。
所以，这个方案治标不治本。
致命的大流量攻击
这种攻击通常以tcpsyn，icmp和UDP（尤其是UDP包，单UDP的数据包可以很大）方式为主。
客服系统遭遇到的最大的一次为16G的攻击流量，整个机房都被影响到。
攻击者通常控制大量肉鸡或者直接勾结IDC里的服务器和带宽资源，对目标进行流量打击。
此时流量会快速占满服务器的网络带宽，导致无法响应任何用户请求。
这类攻击需要购买大量带宽资源，对于攻击方来说，成本挺高，但是下手“快狠准”，目的是让网站在短时间内彻底无响应。
由于这类攻击会引起流量陡增，IDC里的流量监控设备也会很明显的察觉到这个现象。
IDC通常采取的措施一般是丢车保帅，直接将这个被攻击的IP拉黑名单甚至直接拔线，让攻击对象自杀。
这对本应该需要帮助的客户无疑是落井下石，雪上加霜。
应付此类流量攻击的防御方式有：
∙架设硬防火墙
∙租用高防节点
∙租用CDN分散目标流量
∙架设硬防火墙：
市面上2G硬防单价在10W左右，集群防御代价更大，虽然硬件级的防御性能较高，但面对流量洪水也是杯水车薪，且副作用也不容小觑。
∙租用高防节点：
高防节点有防御带宽，防御流量，共享独享区分，各个套餐的组合价格相差很大，分流策略也不同，超过高防承诺的流量后，防御失效或者再加钱，但都有性能损耗和副作用。
∙租用CDN分散目标流量：
市面上的CDN提供商都是以流量为收费标准，这对于经常遭受流量攻击的网站来说，反而要为攻击流量买单，这着实让人哭笑不得。
无论是采购的硬件成本和高防资源还是CDN加速，都成本昂贵，闲时资源利用率低，攻击高峰时面对有组织有规模的流量时又捉襟见肘，还伴有副作用（参见绿盟黑洞防火墙的原理），并非长久之计。
处于弱势的被打击方
综上所述，我们无论做哪个抉择都很痛苦。
我们跟发起攻击的人有过长达近一年的交流，目前了解到这是一个非常完整的产业链（上游人员早已身居海外，远程遥控指挥行动，根本无法查处），他们手上控制了大量的攻击资源，并且攻击资源本身就来自于IDC。
攻击者为了快速牟利，本身也喜欢和推荐这种直接了当的方式来对目标进行打击，在发动攻击时，他们能够调集到多个IDC的带宽资源来对目标打击（这一现象也折射出了当前国内不规范的IDC管理）。
从这一角度来看，被打击方永远都处于弱势地位，以势单力薄的架构和极其有限的资源，根本无法抵抗强大的集群资源攻击。
我们一直思考一个问题：
如果我们持续投入这些资金，危机过去或者若干年后，能给我们留下些什么？
因此，我们跳出了单节点防御和租用CDN的思路，综合上述方案的优点，转而自建CDN的方案。
长久之计：
自建CDN
自建CDN的好处有几个方面：
∙旁路做流量清洗（痘痘长在别人脸上最好）
∙资源充分利用：
无攻击的时候，做路由加速，有攻击的时候，做节点切换（一物多用）
∙随着投入的资金增加，防御DDoS攻击的能力增强（长远规划，资金回报率高）
有关自建CDN具体建设的思路如何，成本多少，我们会在系列的下一篇文章中进行介绍。
作者简介
邵海杨（个人页面），来自杭州Linux用户组。
网名“海洋之心”，系统架构师，业余撰稿人，致力于开源软件及前沿科技的研究和探索。
张磊（微博，博客 ），来自杭州谷歌开发者社区。
专注于信息安全技术领域，曾主导多项银行/证券行业网站安全测试和入侵取证分析项目，为四大银行提供安全防护技术支持。
目前创业做互联网安全防护。
相关阅读
1.自建CDN防御DDoS
（2）：
架构设计、成本与部署细节
2.自建CDN防御DDoS（3）：
架构的后续改进
自建CDN防御DDoS
（2）：
发布于2013年2月21日
CDN
DDoS
安全
在本系列的第一篇文章中，我们介绍了我们客服系统遇到DDoS攻击的情况，以及我们为什么决定采用自建CDN的方式来解决这个问题的原因。
下面，我们将介绍自建CDN的具体建设规划，主要从以下几个方面进行考量：
硬件成本、带宽成本、架构设计、实际部署。
硬件成本
在硬件上，我们选型的需求是在1U的基础上具有强劲的性能，同时性价比要高。
我们选择了（强氧）双子星服务器，其硬件规格为：
1U机身+支持双路至强CPU+最大支持48G内存+双千兆网口x2+H3CS1208八口千兆，提供三年质保服务，总价约1.5万。
带宽成本
单线机房的机房和带宽资源，由于不需要经过第三方拉线撮合，直接从运营代理商购买，因此选择余地大，性价比高。
以租用电信、联通单线资源为例，每条线独享100M带宽，提供8个IP，有些机房自带硬防，能够防御5G-10G流量。
平均费用，每个节点带宽成本基本在1.6~2.5万/年。
架构设计
CDN架构上要充分体现出抗攻击能力和灵活应变的原则。
因此，我们将CDN节点分解成反向代理+缓存加速+攻击防御这三个不同层次的功能结构。
∙反向代理功能（作用：
路由加速，隐藏主节点，负载均衡）
∙缓存加速功能（作用：
静态推送，节省后端主节点带宽）
∙攻击防御功能（作用：
快速解析，匹配过滤恶意攻击）
开源世界里能够担当反向代理及缓存的软件不少，而且各有优劣。
作为架构师，要考虑如何选型，我们从性能、功能、配置上来进行比较筛选。
软件名称
性能
功能
过滤规则配置
Squid
不能多核是硬伤，磁盘缓存容量有优势，性能中等
多，支持ACL角色控制，也支持ICP缓存协议
支持外部规则文件读取及热加载，支持热启动
Varnish
多核支持，内存缓存，性能强
够用，不支持集群，支持后端存活检查
不支持外部文件读取，需要转义，支持热启动
Nginx
多核支持，支持代理插件，性能较强
多，通过插件可以充当多角色服务器
ATS
多核支持，磁盘/内存缓存，性能强
够用，支持插件开发，也支持ICP协议
支持外部规则文件读取及热加载，支持热启动，但缺乏文档
HAProxy
多核支持，无缓存，HTTP头支持语法操作，性能强
少，只专注HTTP头部解析和转发功能，支持ACL角色控制，支持后端存活检查
支持外部规则文件读取及热加载，支持热启动，支持会话粘滞和长连接
我们对这三层功能结构分别进行了测试调优及生产线的实践检验，从以下方面评估：
∙HTTP防御性能：
HAProxy在应对大流量CC攻击时，做正则匹配及头部过滤时，CPU消耗只占10%~20%。
其它软件均狂占CPU资源约90%以上，容易成瓶颈导致整个系统无响应。
∙反向代理性能：
单纯转发效率以内存缓存型的Varnish性能最强，ATS和Nginx次之，考虑大容量缓存因素，ATS也是个不错的选择，但文档缺乏，需要持续关注。
Nginx是专门针对C10K的产物，性能不错，配合众多插件，改造性很强。
∙过滤规则的可配置性：
HAProxy，ATS，Squid均支持规则文件读取、ACL定制和热加载、热启动。
Nginx则不支持外部文件正则匹配，略差一点，但可塑性强。
因此，综合上述考虑，最终我们采用的架构是HAProxy+Varnish/ATS/Nginx的组合，即防御型反向代理缓存方案，功能角色如下：
∙前面由HAProxy全力负责动静资源分离，实现会话粘滞，节点负载均衡，故障转移，遇到危急时承担基于Http协议的CC类型攻击防御。
∙后面为可插拔替换的反向代理缓存引擎：
根据生产线上的实际应用场景及缓存对象的容量来决定使用内存型的varnish或者是磁盘型的ats，如果需要定制功能很强（防盗链）的反向代理如Nginx+plugins。
这个组合最大的特点是：
∙支持外部过滤规则的读取，尤其是关键字符串无需转义，可直接追加到文件中。
∙支持配置文件热加载生效，都支持reload，服务平滑生效。
∙可插拔式的缓存组件灵活应对各种业务需求。
∙部署简单，节点失效/生效切换方便。
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
nbproc24
pidfile/var/run/haproxy.pid
daemon
quiet
usernobody
groupnobody
chroot/opt/haproxy
spread-checks2
defaults
log127.0.0.1local5
modehttp
optionforwardfor
optionhttplog
optiondontlognull
optionnolinger#reduceFIN_WAIT1
optionredispatch
retries3
optionhttp-pretend-keepalive
optionhttp-server-close
optionaccept-invalid-http-request
timeoutclient15s
timeoutconnect15s
timeoutserver15s
timeouthttp-keep-alive15s
timeouthttp-request15s
statsenable
statsuri/stats
statsrealm53KF\Proxy\Status
statsrefresh60s
statsauthadmin:
adminxxx
listenWeb_FB0.0.0.0:
80
optionhttpchkGET/alive.phpHTTP/1.0
aclinvalid_refererhdr_sub（referer）-i-f/opt/haproxy/etc/bad_ref.conf
aclinvalid_urlurl_sub-i-f/opt/haproxy/etc/bad_url.conf
aclinvalid_methodsmethod-i-f/opt/haproxy/etc/bad_method.conf
blockifinvalid_referer||invalid_url||invalid_methods
acldyn_hosthdr（host）-i-f/opt/haproxy/etc/notcache_host.conf
aclstatic_reqpath_end-i-f/opt/haproxy/etc/allow_cache_file.conf
use_backendimg_srvifstatic_req!
dyn_host
#aclshaohy
aclgeekhdr_dom（host）-i
use_backendgeekifgeek
#backendshaohy
backendgeek
balancesource
cookieSESSION_COOKIEinsertindirectnocache
optiontcpka
servergeek_1127.0.0.1:
81cookiegeek_1maxconn10000weight8
backendimg_srv
serverimg_srv127.0.0.1:
88maxconn30000weight8
Varnish的配置策略：
backendh_17geek_com_1{
.host="
127.0.0.1"
;
.port="
81"
.connect_timeout=300s;
.first_byte_timeout=300s;
.between_bytes_timeout=300s;
}
directorgeeksrv{
{.backend=h_17geek_com_1;
.weight=3;
}
subvcl_recv{
if（req.http.host~"
^（www）.?
$"
）{
setreq.backend=geek_srv;
if（req.request!
="
GET"
req.request!
HEAD"
）{
return（pipe）;
if（req.url~"
\.（php|jsp）（$|\?
）"
）{
return（pass）;
else{
return（lookup）;
}
对于CC类型的DDoS攻击，通过第一篇当中介绍的监控异常流量的方法依然适用，而且优势更明显，因为：
∙节点各自承担相应的日志记录，分析日志的系统开销，发现异常请求后直接在haproxy前端做ACL规则过滤，因此，攻击压力不会传递给后端服务器，保证后端安全。
∙节点受到的攻击流量过大，机房可以拉黑IP或者引流，后端智能DNS会自动把这个节点剔除，后续请求不要通过此节点。
在本系列的下一篇文章中，我们会介绍这个CDN架构的一些后续改进工作，包括智能DNS、大规模日志分析、利用OpenCDN改善后台管理等。
1.自建CDN防御DDoS
（1）：
自建CDN防御DDoS（3）：
发布于2013年2月27日
开源
架构
新浪微博腾讯微博豆瓣网TwitterFacebooklinkedin邮件分享更多2
QCon全球软
升级会员 