企业网络安全之防御

一次性付费进群，长期免费索取教程，没有付费教程。

教程列表见微信公众号底部菜单

进微信群回复公众号：微信群；QQ群：460500587

网络安全是传统安全解决方案里关注最多的部分，在应用安全凸显以前的时代，网络安全几乎就是解决方案的“主体”了。本文介绍网络入侵检测的基本方案、T级DDoS防御策略、链路劫持的应对措施、应用防火墙建设策略等。

一、网络入侵检测

1、传统NIDS

随着APT一词的兴起，有些人认为IDS（入侵检测系统）要消亡了，APT的解决方案目前更多的还是在办公网络，对生产网络而言NIDS（网络入侵检测系统）不会消亡，HIDS（主机入侵检测系统）会大放光彩。顶多只能说NIDS的产品形态正在发生改变，但APT检测无法取代NIDS。

图1是绿盟的NIDS产品架构，图2是NIPS的产品架构，区别就是D和P，前者只检测，后者除了检测还会多一个P的功能，即匹配规则后最末追加一个动作：丢包或放行。对于大多数人而言，无论是NIDS还是NIPS都只是一个硬件盒子，很多人并不关心它的具体实现。最直观的就是部署，如图3所示。

图1  绿盟科技IDS体系架构

图2  绿盟科技IPS体系架构

图3  IDS/IPS部署示意图

比较典型的场景是在出口处部署NIDS，做统一流量监控，或者在此处部署NIPS。在这个位置部署NIPS相对于NIDS的好处并非真正意义上执行全流量P的功能，而在于当诸如shellshock等漏洞公布时，可以在这里定制临时过滤规则，只对这几条临时规则实施串联的防护，从而达到“虚拟补丁”的功能。

对于重要安全域的服务器内网，可以选择性地部署NIDS，对关键区域做更深层次的关注。

有人说传统的NIDS已经没有价值，其实不然。虽然对于大型互联网公司来说，传统NIDS捉襟见肘，但是目前大型网络的IDS除了自研之外没有第二条路可选，即便选择自研，在获得第一个版本之前要么选择没有，要么就是用传统NIDS。如果不差钱，购买商业NIDS、NIPS用做阶段性过度也是不错之选。对于流量不是特别大的情况，其实自研本身的ROI是不确定的，商业产品免去了自研交付的风险和持续维护的成本。另外在办公网络里，商业NIDS和NIPS完全适用。在具体选型上对于不差钱的公司可以直接参考Gartner MQ象限排名。

2、开源SNORT

对于要求不高、有时间与精力、爱折腾、不想花钱买商业产品又不打算去自研的人来说，开源的SNORT是一个选择：https://www.snort.org。

3、大型全流量NIDS

当互联网公司的业务成长速度比较快时，其IDC网络流量也很可能会超过单台NIDS的最大处理能力（40~80Gbps），虽然产品声称的吞吐能力比较高，由于NIDS的架构问题（如图4所示），采用的是基于攻击特征的签名库，只要加载的攻击特征一多，系统负载马上会飙升，远到不了系统的标称负载就会开始出现丢包和误报率的上升。传统NIDS在大型互联网场景下有如下几个明显的缺陷：

图4  NIDS原理图

● IDC规模稍大很容易超过商业NIDS处理带宽的上限，虽然可以多级部署，但无法像互联网架构一样做到无缝的水平扩展，不能跟基础架构一起扩展的安全解决方案最终都会掣肘。

● 硬件盒子单点的计算和存储能力有限，很容易在CPU时间和存储空间上达到硬件盒子的上限，即使有管理中心可以腾挪存储空间也解决不了这个问题。

● 规则数量是性能杀手，最不能被并行处理的部分会成为整个架构的瓶颈。

● 升级和变更成本高，可能对业务产生影响。

● IDC规模较大时，部署多台最高规格商业NIDS的TCO很高（Google如果用IBM的解决方案会破产）。

对于迟迟不愿意自研的人，有人想到了过渡性方案，如图5所示。

图5  NIDS硬件扩展方案

这样看上去比厂商提供的多层级联的方案稍微好一点，貌似解决了水平扩展问题，但是它仍然没有解决TCO的问题，无论如何这种方案都不适合拿到台面上来作为最佳实践，它只能用于暂时换取自研NIDS的时间。

为解决以上提到的几个痛点，针对大规模的IDC网络，把整个架构改良了一下（如图6所示）。

图6  基于大数据的NIDS架构

● 分层结构，所有节点全线支持水平扩展。

● 检测与防护分离，性能及可用性大幅提升，按需决定防护，支持灰度。

● 报文解析与攻击识别完全解耦，入侵检测环节“后移”。

● 依赖大数据集群，规则数量不再成为系统瓶颈，并且不再局限于基于静态特征的规则集，而是能多维度建模。

●“加规则”完全不影响业务。

这是全流量全协议全功能版本，也可以只取其中一部分，比如对于以HTTP/HTTPS为主的Web平台可以只关注HTTP类协议。

4、关于D还是P

对于单纯的检测来说，过分的实时性要求其实意义不是特别大，攻击行为发生后10秒钟告警和10分钟告警效果都差不多，慢一点也不会误事。按正常人的节奏，半小时顶多也就是从普通权限提到了root，而且不太可能因为秒级的机器告警就会有秒级的人肉应急处理速度，1个小时内反应都算快的了。因为可以延时处理，所以D（detection）方案的门槛比P（protection）方案要低。

对互联网服务而言，可用性是除了数据丢失以外的第二大严重问题，如果要实现P就会面临延迟和误杀的风险，因此P方案实际比D方案难了一个阶梯。在海量IDC环境中，想要做到全线业务实时防护基本是不可能的，但又确实有这样的需求，比如shellshock这样的漏洞可能要修一个礼拜，在这期间网上早有POC，那些有漏洞暴露在外的机器怎么办，既不能让它下线又不能任它被黑，那就需要在前端有一层虚拟补丁，把利用这个漏洞的攻击行为有针对性的过滤一下，为修漏洞赢得时间窗口。所以P方案最终是一个打折扣的版本，利用DDoS引流–清洗（过滤）–回注的防护原理，将需要防护的流量迁移到清洗集群，清洗集群上的过滤规则绝对不会是商业NIPS广告宣称的那种大而全的，而是有针对性的几条高危漏洞规则，做一层很轻的过滤。可以支持灰度是因为能决定牵引哪些目标地址的流量，而剩余的选择维持原路由，这样能做到对业务的影响降至最低，尽可能做到对用户是一种无感知状态。在“和平时期”，一般不需要启用P功能，只使用D就可以。

5、对厂商的建议

互联网公司选择自研有时是出于无奈，而非为了自我标榜。如果安全公司的NIDS，NIPS能解决扩展性的问题，那对甲方安全团队来说真的没必要再去搞一套。但是这里面的诉求是分级和差异化的，有的客户需要的是傻瓜的一站式解决方案，而互联网公司，尤其是大一点的都有自己的安全团队，有安全团队就爱“折腾”，更加需要的是一个开放式的平台，而不是一个完全封闭的硬件盒子，过去厂商卖的产品竞争力是基于攻击特征的规则库，但现在安全团队往往能自己建规则，不完全依赖于厂商提供的已有规则集，他们根据自己的业务往往能制定出更加有效的规则，但是他们需要一个平台，这个平台可以解决包括大流量，高性能的抓包和解包问题，能有渠道自定义规则，包括packet头部各字段以及payload可以全部自定义，最好能有一种简单的类脚本语言支持，这样安全团队能专注于自己的核心业务，而不用变成安全产品研发团队。

二、T级DDoS防御

1、DDoS分类

在讲防御之前，先简单介绍一下各类攻击，因为DDoS不是一种攻击，而是很多种类的攻击，并且DDoS的防御可以做到相对自动化但做不到绝对自动化，很多演进的攻击方式自动化工具不一定能识别，还需要专家进一步用肉眼判断。

（1）网络层攻击

● Syn-flood——利用TCP建立连接时3次握手的“漏洞”，通过原始套接字发送源地址虚假的SYN报文，使目标主机永远无法完成3次握手，占满了系统的协议栈队列，资源得不到释放，进而拒绝服务，是互联网中最主要的DDoS攻击形式之一。网上有一些加固的方法，例如调整内核参数的方法，可以减少等待及重试，加速资源释放，在小流量syn-flood的情况下可以缓解，但流量稍大时完全不抵用。防御syn-flood的常见方法有：syn proxy、syn cookies、首包（第一次请求的syn包）丢弃等。

近年攻击者开始采用1000字节的SYN包进行攻击，试图在消耗CPU资源的同时，堵塞边缘带宽，攻击流量相比标准SYN包大大增加，目前已观察到的最大的SYN攻击可达680Gbps，这使得防御也更加困难。带payload的syn包在不需要TFO（TCP Fast Open）的地方可以直接丢弃，前提是有ADS设备。

● ACK-flood——对于虚假的ACK包，目标设备会直接回复RST包丢弃连接，所以伤害值远不如syn-flood。DDoS的一种原始方式。

● UDP-flood——使用原始套接字伪造大量虚假源地址的UDP包，目前以DNS协议为主。

● ICMP-flood——Ping洪水，是一种比较古老的方式。

（2）应用层攻击

● CC——ChallengeCollapsar的名字源于挑战国内知名安全厂商绿盟的抗DDoS设备–“黑洞”，通过botnet的傀儡主机或寻找匿名代理服务器，向目标发起大量真实的http请求，最终消耗掉大量的并发资源，拖慢整个网站甚至彻底拒绝服务。

互联网的架构追求扩展性本质上是为了提高并发能力，各种SQL性能优化措施：消除慢查询、分表分库、索引、优化数据结构、限制搜索频率等本质都是为了解决资源消耗，而CC大有反其道而行之的意味，占满服务器并发连接数，尽可能使请求避开缓存而直接读数据库，读数据库要找最消耗资源的查询，最好无法利用索引，每个查询都全表扫描，这样就能用最小的攻击资源起到最大的拒绝服务效果。

互联网产品和服务依靠数据分析来驱动改进和持续运营，所以除了前端的APP、中间件和数据库这类OLTP系统，后面还有OLAP，从日志收集，存储到数据处理和分析的大数据平台，当CC攻击发生时，不仅OLTP的部分受到了影响，实际上CC会产生大量日志，直接会对后面的OLAP产生影响，影响包括两个层面，一个当日的数据统计完全是错误的。第二个层面因CC期间访问日志剧增也会加大后端数据处理的负担。

CC是目前应用层攻击的主要手段之一，在防御上有一些方法，但不能完美解决这个问题。

● DNS flood——伪造源地址的海量DNS请求，用于淹没目标的DNS服务器。对于攻击特定企业权威DNS的场景，可以将源地址设置为各大ISP DNS服务器的ip地址以突破白名单限制，将查询的内容改为针对目标企业的域名做随机化处理，当查询无法命中缓存时，服务器负载会进一步增大。

DNS不只在UDP-53提供服务，同样在TCP协议提供服务，所以防御的一种思路就是将UDP的查询强制转为TCP，要求溯源，如果是假的源地址，就不再回应。对于企业自有权威DNS服务器而言，正常请求多来自于ISP的域名递归解析，所以将白名单设置为ISP的DNS server列表。对于源地址伪造成ISP DNS的请求，可以通过TTL值进一步判断。

● 慢速连接攻击——针对HTTP协议，以知名的slowloris攻击为起源：先建立HTTP连接，设置一个较大的content-length，每次只发送很少的字节，让服务器一直以为HTTP头部没有传输完成，这样的连接一多很快就会出现连接耗尽。

目前出现了一些变种，HTTP慢速的post请求和慢速的read请求都是基于相同的原理。

● DOS攻击——有些服务器程序存在bug、安全漏洞，或架构性缺陷，攻击者可以通过构造的畸形请求发送给服务器，服务器因不能正确处理恶意请求而陷入僵死状态，导致拒绝服务。例如某些版本的应用服务器程序存在缓冲区溢出，漏洞可以触发但无法得到shell，攻击者可以改变程序执行流程使其跳转到空指针或无法处理的地址，用户态的错误会导致进程挂起，如果错误不能被内核回收则可能使系统当掉。

这类问题效果也表现为拒绝服务，但本质上属于漏洞，可以通过patch程序的最新版本解决，不属于DDoS的范畴。

3、攻击方式

● 混合型攻击——在实际大流量的攻击中，通常并不是以上述一种数据类型来攻击，往往是混杂了TCP和UDP流量，网络层和应用层攻击同时进行。

● 反射型攻击——2004年时反射型攻击（DRDOS）第一次披露，通过将SYN包的源地址设置为目标地址，然后向大量的真实TCP服务器发送TCP的SYN包，而这些收到SYN包的TCP Server为了完成3次握手把SYN|ACK包“应答”给目标地址，完成了一次“反射”攻击，攻击者隐藏了自身，如图7所示。但有个问题是攻击者制造的流量和目标收到的攻击流量是1：1，且SYN|ACK包到达目标后马上被回以RST包，整个攻击的投资回报率不高。反射型攻击的本质是利用“质询–应答”式协议，将质询包的源地址通过原始套接字伪造设置为目标地址，则应答的“回包”都被发送至目标，如果回包体积比较大或协议支持递归效果，攻击流量会被放大，成为一种高性价比的流量型攻击。反射型攻击利用的协议目前包括NTP、Chargen、SSDP、DNS、RPC Portmap等等。

图7  反射型攻击原理图

● 流量放大型攻击——以上面提到的DRDOS中常见的SSDP协议为例，攻击者将Search type设置为ALL，搜索所有可用的设备和服务，这种递归效果产生的放大倍数是非常大的，攻击者只需以较小的伪造源地址的查询流量就可以制造出几十甚至上百倍的应答流量发送至目标。常见反射式攻击放大倍数参见表1。

表1  常见反射型攻击放大倍数

● 脉冲型攻击——很多攻击持续的时间非常短，通常5分钟以内，流量图上表现为突刺状的脉冲，如图8所示。

图8  脉冲型DDoS流量特征

这样的攻击之所以流行，是因为“打–打–停–停”的效果最好，刚触发防御阈值，防御机制开始生效攻击就停了，周而复始。蚊子不叮您，却在耳边飞，刚开灯想打它就跑没影了，当您刚关灯它又来了，您就没法睡觉。

自动化的防御机制大部分都是依靠设置阈值来触发。尽管很多厂商宣称自己的防御措施都是秒级响应，但实际上比较难。

网络层的攻击检测通常分为逐流和逐包，第一种逐流检测是根据netflow以一定的抽样比例（例如1000：1）检测网络是否存在DDoS攻击，这种方式因为是抽样比例，所以精确度较低，做不到秒级响应。第二种逐包检测，检测精度较高且响应时间较短，但成本比较高，一般厂商都不会无视TCO全部部署这类方案。即便用逐包检测，其防御清洗策略的启动也依赖于阈值，加上清洗设备一般情况下不会串联部署，触发清洗后需要引流，因此大部分场景可以做秒级检测但做不到秒级防御。近源清洗尚且如此，云清洗的触发和转换过程就更慢了。所以利用防御规则的生效灰度期，在触发防御前完成攻击会有不错的效果，在结果上就表现为脉冲。

● 链路泛洪型攻击——随着DDoS攻击技术的发展，又出现了一种新型的攻击方式：链路泛洪（link-flooding），这种方式不直接攻击目标，而是以堵塞目标网络的上一级链路为目的。对于使用了IP anycast的企业网络来说，常规的DDoS攻击流量会被“分摊”到不同地址的基础设施，这样能有效缓解大流量攻击，所以攻击者发明了一种新方法，攻击至目标网络traceroute的倒数第二跳，即上联路由，致使链路拥塞。国内ISP目前未开放anycast，所以这种攻击方式的必要性有待观望，如图9所示。

图9  链路泛洪示意图

对一级ISP和IXP的攻击都可以使链路拥塞。

2、多层防御结构

DDoS攻击本质上是一种只能缓解而不能完全防御的攻击，它不像漏洞那样打个补丁就是完全解决了，DDoS就算购买和部署了当前市场上比较有竞争力的防御解决方案也完全谈不上彻底根治。防火墙、IPS、WAF这些安全产品都号称自己有一定的抗DDoS能力，而实际上它们只针对小流量下应用层的攻击比较有效，对于稍大流量的DDoS攻击则无济于事。

例如，国内的DDoS攻击在一个月内攻击流量超过300G的就有20次左右，这个数值将随着国内家庭宽带网速提升而进一步放大。对于200~500G的攻击流量该如何防御，下面将展示完整的防御结构，通常可以分为4层，如图10所示。

图10  DDoS纵深防御体系

这4层不是严格意义上的纵深防御结构，也不是在所有的防御中都需要4层，可能有时候只需要其中的2层。但对于超大流量攻击而言，就是需要4层防御机制，再没有其他手段了。跟厂商的市场宣传可能有所不同，大流量攻击的防护并不是靠厂商单方面就能解决，而是进行多层防御才有效。

（1）ISP/WAN层

这一层通常对最终用户不可见，如果只是中小企业，那这一层可能真的不会接触到。但如果是大型互联网公司、公有云厂商，甚至是云清洗厂商，这层是必不可少的。因为当流量超过自己能处理的极限时，必须要借助电信运营商的能力。大型互联网公司虽然自身储备的带宽比较大，但还没到达轻松抵抗大流量DDoS的程度，毕竟带宽是所有IDC成本中最贵的资源，没有之一。目前无论是云计算厂商、大型互联网公司向外宣称的成功抵御200G以上攻击的新闻背后都用到了运营商的抗D能力，另外像第三方的云清洗平台实际上或多或少地依赖电信运营商，如果只依靠本身的清洗能力，都是非常有限的。

目前，中国电信专门做抗DDoS的云堤提供了“流量压制”和“近源清洗”的服务（如图11所示），流量压制是一种分方向的黑洞路由，对于购买其服务的厂商来说可以自定义需要黑洞路由的IP，并选择在哪些国家及省份上生效，如图12所示。黑洞路由是一种简单粗暴的方法，除了攻击流量，部分真实用户的访问也会被一起黑洞掉，对用户体验是一种打折扣的行为。但因为攻击流量分布与业务流量分布往往区别较大，根据受攻击时，业务与攻击流量具体分布，在某些攻击流量特别大而用户流量极小的方向上进行黑洞路由，可以在保证大部分业务前提下解决边缘带宽拥塞问题，这对具备一定带宽储备和清洗能力但仍需保证出口带宽的云清洗厂商特别有意义，对中小型网站用户体验影响较大。

图11  近源清洗示意图

图12  电信云堤移动端管理界面

相比之下，近源清洗可以在靠近攻击源位置对攻击进行清洗，在几乎不增加时延的前提下完成流量清洗。这种对攻击流量的牵引、清洗、回注的防御方式对用户体验的挑战没那么大，但是跟黑洞路由比防御方的成本比较高，且触发到响应的延时较大。

在运营商防御这一层的主要的参与者是大型互联网公司、公有云厂商、云清洗厂商，其最大的意义在于应对超过自身带宽储备和自身DDoS防御能力之外的超大攻击流量时作为补充性的缓解措施。

（2）CDN/Internet层

CDN并不是一种抗DDoS的产品，但对于Web类服务而言，却正好有一定的抗DDoS能力。以大型电商的抢购为例，这个活动的访问量非常大，从很多指标上看不亚于DDoS的CC，而在平台侧实际上在CDN层面用验证码过滤了绝大多数请求，最后到达数据库的请求只占整体请求量的很小一部分。

对HTTP CC类型的DDoS，不会直接到源站，CDN会先通过自身的带宽硬抗，抗不了的或者穿透CDN的动态请求会到源站，如果源站前端的抗DDoS能力或者源站前的带宽比较有限，就会被彻底DDoS。

云清洗厂商提出的策略是，预先设置好网站的CNAME，将域名指向云清洗厂商的DNS服务器，在一般情况下，云清洗厂商的DNS仍将穿透CDN的回源的请求指向源站，在检测到攻击发生时，域名指向自己的清洗集群，然后再将清洗后的流量回源，检测方式主要是在客户网站前部署反向代理（Nginx），托管所有的并发连接。在对攻击流量进行分流的时候，准备好一个域名到IP的地址池，当IP被攻击时封禁并启用地址池中的下一个IP，如此往复。

以上是类Cloudflare的解决方案，国内云清洗厂商的实现原理都相似，如图13所示。

图13  云清洗示意图

不过这类方案都有一个通病，由于国内环境不支持anycast，通过DNS引流的方式需要比较长的生效时间，这个时间依赖于DNS递归生效的时长，对自身完全不可控，很多用户使用的DNS递归服务器最小TTL值长达24小时。同时CDN仅对Web类服务有效，对游戏类TCP直连的服务无效。

网上很多使用此类抗D服务的过程可以概括为一句话：更改CNAME指向，等待DNS递归生效。

（3）DC层

Datacenter这一层的DDoS防御属于近目的清洗，就是在DC出口的地方部署ADS设备。

产品照片如图14所示。

图14  华为AntiDDoS 8000系列产品

目前国内厂商华为的AntiDDoS产品的最高型号支持T级高达1440Gbps带宽的防护，产品系列如图14所示。DC级清晰方案的原理如图15所示，在DC出口以镜像或分光部署DDoS探针（检测设备），当检测到攻击发生时，将流量牵引到旁路部署的DDoS清洗设备，再将经过清洗的正常流量回注到业务主机，以此完成一轮闭环。

图15  DC级清洗方案

部署设备本身并没有太大的技术含量，有技术含量的部分都已经作为防御算法封装在产品盒子里了。不过要指出的一点是，目前市场上的ADS盒子既有的算法和学习能力是有限的，仍然需要人的介入，比如：

● 对业务流量基线的自适应学习能力是有限的，例如电商行业双11大促日子的流量模型可能就超越了ADS的学习能力，正常流量已经触发攻击判定。

● 自动化触发机制建立在阈值之上，就意味着不是完全的自动化，因为阈值是一个经验和业务场景相关的值。

● 全局策略是通用性策略，不能对每一个子业务起到很好的防御效果，有可能子业务已经被D了，全局策略还没触发。

● 常见的DDoS类型ADS可以自动处理，但变换形式的DDoS类型可能还需要人工识别。

● 默认的模板策略可能不适用于某些业务，需要自定义。

DDoS防御除了整体架构设计外，比较需要专业技能的地方就是在上述例子的场景中。目前在ADS设备里覆盖了3~4、7这三层的解决方案。表2是常见ADS设备的功能简介。

表2  常见ADS设备功能

一般情况下ADS设备可以缓解大部分常见的DDoS攻击类型，相对而言3-4层的攻击手法比较固定，而7层的攻击，由于涉及的协议较多，手法变化层出不穷，所以ADS有时候对7层的防护做不到面面俱到，比如对CC，ADS提供了HTTP 302、验证码等，但还是不能很好地解决这个问题。应用层的防护需要结合业务来做，ADS则在能利用的场景下承担辅助角色，比如对于游戏封包的私有协议，通过给packet添加指纹的方式，ADS在客户端和服务端中间鉴别流入的数据包是否包含指纹。

（4）OS/APP层

这是DDoS的最后一道防线。这一层的意义主要在于漏过ADS设备的流量做最后一次过滤和缓解，对ADS防护不了的应用层协议做补充防护。比如NTP反射，可以通过服务器配置禁用monlist，如果不提供基于UDP的服务，可以在边界上直接阻断UDP协议。

互联网在线服务中最大的比重就是Web服务，因此有些互联网公司喜欢自己在系统层面去做应用层的DDoS防护，例如对抗CC，有时这些功能也能顺带关联到业务安全上，比如针对黄牛抢单等。

实现方式可以是Web服务器模块，也可以是独立部署的旁路系统，反向代理将完整的HTTP请求转发给检测服务器，检测服务器根据几方面的信息，如图16所示：

图16  七层HTTP抗DDoS示意图

● 来自相同IP的并发请求。

● 相同ip+cookie的并发请求。

● 相同HTTP头部可设置字段。

● 相同的request URL。

然后保存客户端的连接信息计数表，例如单位时间内相同IP+cookie再次发起连接请求则此客户端IP的计数器+1，直到触发阈值，然后服务器会进行阻断。为了避免误杀，也可以选择性地弹出验证码。

以上是拿CC防御举了个例子，ADS设备本身提供了HTTP 302跳转、验证码、Java-Script解析等防御方式，尽管OS和应用层可以做更多的事情，但毕竟有自己去开发和长期维护的代价，这个收益要看具体情况。

（5）链路带宽

大部分介绍DDoS防御策略的文章里似乎很少提及这一点：增加带宽，但这个方法却是以上所有防御的基础，例如第二层次的CDN实际上就是拼带宽，很多大型企业选择自建CDN，本质上就是自己增加带宽的行为。除了CDN之外，要保障DC出口的多ISP链路、备份链路，到下层机柜交换机的带宽都不存在明显的单点瓶颈，否则抗DDoS的处理性能够了，但是流量流经某个节点时突然把一个杂牌交换机压垮了，最后的结果还是表现为有问题。

对运维经验成熟的互联网公司而言，一般都有能容管理，对于促销活动，高峰时段的带宽，IDC资源的波峰波谷都有预先的准备，DDoS防御主要是消除这些网络方案中内在的单点瓶颈。

3、不同类型的企业

DDoS的防御本质上属于资源的对抗，完整的4层防御效果虽好，但有一个明显问题就是TCO，这种成本开销互联网行业排名TOP10以外的公司基本都吃不消。就算付得起这钱，在IT整体投资的占比会显得过高，付得起不代表这种投资是正确的。所以针对不同的企业分别描述DDoS缓解方案的倾向和选择性。

（1）大型平台公司

这里的“大”有以下几层意思：

● 公司很有钱，可以在补贴具体的业务上不“太”计较投入，对土豪来说只选效果最优方案。

● 公司不一定处在很赚钱的阶段，但IDC投资规模足够大，这样为了保障既有的投入，安全的总投资维持一个固定百分比也是非常有必要的，在IDC盘子很大的时候没必要省“小钱”。

● 与潜在的由于服务中断造成的损失比，DDoS防御的投资可以忽略不计。

映射到现实中与这几条相关的公司：

● 市值100亿美元以上互联网公司。

● 大型公有云厂商，IaaS、PaaS平台。

● 利润比较高的业务，比如游戏、在线支付假如被DDoS的频率较高。

对于IDC规模比较大又有钱的公司来说，防DDoS的口诀就是“背靠运营商，大力建机房”，在拥有全部的DDoS防御机制的前提下，不断提高IDC基础设施的壁垒给攻击者制造更高的门槛。对于网络流量比较高的公司而言，抗DDoS是有先天优势的，因为业务急速增长而带来的基础设施的扩容无意识间就成了一种防御能力。但对于没有那么大业务流量的公司，空买一堆带宽烧钱恐怕也没人愿意。

对于比较有钱，但没那么多线上服务器的公司而言，自己投入太多IDC建设可能是没必要的，此时应该转向通过购买的手段尽可能获得全部的DDoS防御机制。

（2）中小企业

资源的对抗肯定不是中小企业的强项，所以追求ROI是主要的抗DDoS策略。第一种情况极度省钱模式，平时裸奔，直到受攻击才找抗DDoS厂商临时引流，这种方案效果差一点，但绝大多数企业都是这种心理，得过且过，能省则省，这也无可厚非，不过遇到关键事件要知道上哪儿去找谁，知道做哪些事。

第二种情况追求效果，希望有性价比高的方案。如果本身业务运行于公有云平台，可以直接使用云平台提供的抗DDoS能力，对于Web类企业可以考虑提前购买云清洗厂商的服务。

4、不同类型的业务

不同的类型的服务所需要的DDoS防御机制不完全相同，所以不能直接拿前述4层生搬硬套。

（1）Web

对于Web类服务，攻击发生时终端用户可以有一定的延迟容忍，在防御机制上4层全部适用，大型平台的一般都是4层全部拥有，规模小一点的企业一般购买云清洗，cloudflare类的服务即可。

（2）游戏类

Web API形式的轻游戏跟Web服务类似，而对于TCP socket类型的大型网游，稍有延迟很影响用户体验，甚至很容易掉线。云WAF、CDN等措施因为是针对Web的，所以在该场景下无效，只有通过DNS引流和ADS来清洗。ADS不能完美防御的部分可以通过修改客户端、服务端的通信协议做一些辅助性的小动作，例如封包加tag标签，检测到没有tag的包一律丢弃，防御机制基本都依赖于信息不对称的小技巧。DNS引流的部分对于有HTTPDNS的厂商可以借助其缓解DNS递归生效的时间。

5、服务策略

● 分级策略——对于平台而言，如果有些服务被DDoS会导致全站服务不可用，例如DNS不可用则相当于全线服务不可用，对于强账号体系应用，例如电商、游戏等，如果SSO登录不可用则全线服务不可用，攻击者只要击垮这些服务就能做到“擒贼擒王”。所以安全上也需要考虑针对不同的资产使用不同等级的保护策略，根据BCM的要求，先将资产分类分级，划分出不同的可用性SLA要求，然后根据不同的SLA实施不同级别的防护，在具体防护策略上，能造成平台级SPOF（单点故障）的服务或功能应投入更高成本的防御措施，所谓更高成本不仅指购买更多的ADS设备，同时可以建立多灾备节点，并且在监控和响应优先级上应该更高。

● Failover机制——DDoS防御不只是依赖于DDoS防御的那4层手段，同时依赖于基础设施的强大，例如做分流，就需要多点异地灾备，mirror site & hot site & standby system，云上的系统需要跨AZ部署，这些是可以随时切换的基础。把鸡蛋放在一个篮子里会导致没什么选择。

基础设施和应用层面建立冗余是技术形式上的基础，光有这些还远远不够，需要有与之配套的DRP&BCP策略集，并且需要真实的周期性的演练，意在遇到超大流量攻击时能够从容应对。

● 有损服务——在应用服务设计的时候，应该尽量避免“单点瓶颈”，避免一个点被DDoS了整个产品就不好用了，而是希望做到某些服务即使关闭或下线了，仍然不影响其他在线的服务（或功能），能在遇到需要弃卒保帅的场景时有可以“割肉”的选择，不要除了“0”就是“1”，还是要存在灰度，比如原来10个服务在线，遇到攻击时只要保底重要的3个服务在线即可。

 补充手段 

DDoS攻击的目的不一定完全是出于想打垮服务，比如以前遇到玩家DDoS服务器的目的竟然是因为没抢到排在第一的房间，这种因素通过产品设计就可以根治。而有很多应用层DDoS只是为了达成另外一种目的，都跟上述4层纵深防御机制无关，而跟产品设计有关。所以防御DDoS这事得看一下动因，不能盲目应对。

6、NIPS场景

ADS本质上是一个包过滤设备，虽功用不同却跟IPS有点相似，有时候需要提供全站IPS的虚拟补丁功能，ADS设备就可以充当这一角色，只是条目不宜多，只上有限的条目，下面的是NSFOCUS的ADS设备的规则编辑界面，payload可自定义，如图17所示。

图17  绿盟“黑洞”规则自定义界面

当安全团队能力尚可的话，可以通过运行POC exploit，然后抓包找出攻击payload的特征，编辑16进制的匹配规则，即可简单实现人工定制。

7、破防和反制

从安全管理者的角度看，即便是拥有完整的4层防御机制也并非无懈可击，号称拥有400-500G防护能力的平台是完全有可能被打垮的，完全的防护能力是建立在人、策略、技术手段都生效的情况才有的，如果这些环节出了问题，抗DDoS的整个过程可能会失败。例如下面提到的这些问题：

● 超大流量攻击时需要用到黑洞路由，但黑洞路由的IP需要由防御方定义和联动，“联动”的过程就是向上游设备发送封禁IP的通知，如果接口不可用，那么此功能会失效，所以ISP级的防御是有失效可能性的。

● CDN云清洗服务依赖于清洗服务商接管域名解析，如果云清洗服务商本身的DNS不可用，也将导致这一层面的防御失效，诸如此类的问题还有不少，这些抗D厂商自身并非无懈可击。

● ADS平时不一定串联部署，但攻击发生引流后一定是业务的前端设备，假如这个设备本身存在DOS的可能，即使是触发了bypass也相当于防御完全失效了，另一方面策略下发通常是ADS设备跟管理节点互通，如果管理节点出现可用性问题，也将导致ADS防御的一系列问题。

● 超大流量攻击需要人工干预时，最基本的需求是安全或运维人员能在办公网络连接到ADS的管理节点，能远程运维ADS设备，如果此时办公网络的运维管理链路出现故障，不仅切断了人员操作，还会把现场应急的紧张气氛提升一个量级，使人更加手忙脚乱。

以上并不在于提供新的攻击的思路，而在于向抗DDoS方案的制定者提供另类视角以便于审视方案中的短板。

8、立案和追踪

目前对于流量在100G以上的攻击是可以立案的，这比过去幸福了很多。过去没有本土特色的资源甚至都没法立案，但是立案只是万里长征的第一步，如果想找到人，必须成功完成以下步骤：

● 在海量的攻击中，寻找倒推的线索，找出可能是C&C服务器的IP或相关域名等。

●“黑”吃“黑”，端掉C&C服务器。

● 通过登录IP或借助第三方APT的大数据资源（如果能得到的话）物理定位攻击者。

● 陪叔叔们上门抓捕。

● 上法庭诉讼。

如果抓到这个人没有特殊身份，也许您能如愿；但假如遇到一些特殊人物，几个月都白忙乎。而黑吃黑的能力则依赖于安全团队本身的渗透能力，且有闲情逸致做这事。这个过程对很多企业来说成本还是有点高，光有实力的安全团队这条门槛就足以砍掉绝大多数公司。

三、链路劫持

1、HTTPDNS

运营商为了减少跨ISP的流量结算，会在本网内缓存ICP的内容，广告联盟等甚至也会劫持域名替换广告，劫持域名解析是安全上的一大隐患，意味着可以任意操纵缓存，随意挂马。

HTTPDNS原来是一个为优化用户体验发明的东西，其本质就是利用HTTP协议来完成域名解析，防止被运营商劫持，原理如图18所示。通常情况下使用HTTPDNS的客户端域名解析会走互联网公司自己的服务器，跳过运营商的本地DNS，这个产品原来的目的虽然不是为了安全设计，但从安全上来看缓解了一些问题。当然并不是绝对的，HTTPDNS的请求由于是明文的，理论上完全可以劫持。只不过劫持的代价比原来更大一些。

图18  HTTPDNS原理

如果希望完全规避DNS解析劫持的问题，需要使用加密的DNS请求，目前IETF已经有了DNS over TLS的草案：（https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls/?include_text=1），相信随着刚需会很快变成现实。

2、全站HTTPS

全站HTTPS主要解决当前越来越严峻的网民隐私泄露问题，减少被中间人监听和会话劫持的可能。之前HTTPS多用在登录和交易环节，现在国内也开始紧跟国外互联网的趋势逐渐进入全站HTTPS时代。

升级成全站HTTPS对于大型站点来说是一个比较复杂的工程，这里只强调一下与安全相关的部分：

● SSL/TLS协议——对于常用的协议TLS1.2，TLS1.1，TLS1.0和SSL3.0，目前只有TLS1.1和TLS1.2暂时没有曝已知的安全漏洞，基本上互联网公司的在线业务都使用这两个版本，在TLS1.3面世之前没有太多选择。

● 加密算法——密钥交换算法建议使用RSA或ECDHE_RSA。内容传输加密建议使用AES-GCM，目前google推出的boring ssl支持新型的流式加密算法ChaCha20也可用于内容加密。

● 防降级攻击——降级攻击一般手法是伪造客户端请求，试图改变加密算法为不安全的加密或改变协议版本为低版本，针对这样的攻击，需要配置SCSV（Signaling Cipher Suite Value）选项，另外需要禁止客户端主动重协商。

● 其他问题——如果为提升性能支持TFO（TCP Fast Open-RFC7413），TFO实际上允许TCP|SYN包带payload，对现有的抗DDoS策略会产生比较大的影响。

大型站点除了Web服务器需要支持HTTPS以外，CDN也需要支持HTTPS，一般情况下需要把网站的私钥提供给CDN服务商，但这样就引入了第三方的风险，不得不提的是cloudflare，它提供了keyless的HTTPS服务，分成几种实现，从轻度到重度，如图19所示。

图19  HTTPS的三种不同模式

Flexible SSL只做客户端浏览器到CDN之间的HTTPS加密，回源使用HTTP。Full SSL这个层次不止实现前者，还包括CDN到源站之间也是用HTTPS，但不校验服务端证书，而第三个层次不仅全HTTPS，且会校验服务端证书的有效性。目前对于大多数站点而言，也就是做到Flexible SSL这个层次，就能缓解靠近用户那一侧被劫持的问题，后面的部分由厂商自己来保证。但Flexible SSL是否就够用，要看具体业务，对于安全性和隐私保护极高的业务，例如金融行业的在线服务的HTTPS需要使用严格版本的SSL加密。

3、登录过程加密

即便在HTTPS的状态下传输口令，假如网关流量被劫持，证书被替换，无知的小白用户还是选择了不安全的连接怎么办，另一方面现在还出现了在IDC测劫持流量的攻击行为，后一种盗号的效果直逼拖库，于是有的厂商想到了在HTTPS的基础上，在应用层再实现一次加密，即便劫持了流量，也看不到明文。以某厂账号的网页登录为例，登录过程中，在客户端利用JavaScript先将用户输入的口令加密，然后再提交给服务端。

function preprocess(A){

var B = "";

B += A.verifycode.value;     //获取验证码的值

B = B.toUpperCase();         //将验证码转换成大写字母

A.p.value = md5(md5_3(A.p.value) + B);

//先将口令进行md5_3()加密，然后和验证码再做一次MD5

return true

}

这是早期的一个版本，后来变成如下加密方式：

md5(md5(hexchar2bin(md5(pwd))+uin)+verifycode.toUpperCase())

其加密算法一直在更新，不过这里只是为了举例说明javaScript加密在对抗劫持下的作用。当然JavaScript加密用于传输密文只是一方面，另一方面也是为了防止协议逆向后引发的业务安全问题，例如自动化注册机。

4、跨IDC传输加密

对于真正发生于IDC链路层的劫持，目前没有很好的解决方案，只能尽可能做到在跨IDC传输，跨安全域传输的时候使用加密通道。应用层支持全流量TLS或加密的VPN点对点连接。

AWS（亚马逊的公有云）是业内公认安全做得比较好的平台。作为第三方平台AWS的合规性支持是目前种类最多的，包括：

● SOC 1/SSAE 16/ISAE 3402（formerly SAS 70）

● SOC 2

● SOC 3

● FISMA，DIACAP，and FedRAMP

● DOD CSM Levels 1-5

● PCI DSS Level 1

● ISO 27001

● ITAR

● FIPS 140-2

● MTCS Level 3

● HIPAA

● Cloud Security Alliance（CSA）

● Motion Picture Association of America（MPAA）

之所以能做到这个程度是因为基础安全做得比较好，表现在一些细节上，比如AWS几乎所有的上层产品都支持TLS加密传输，例如：S3存储、Glacier备份、所有类型RDS服务、DynamoDB（Cache）、Redshift（BI）、EMR（大数据）、Kinesis（流式计算）等。

四、应用防火墙WAF

应用防火墙（Web Application Firewall，WAF）是Web应用防护系统，也称“网站应用级入侵防御系统”。通过针对基于HTTP/HTTPS协议的流量建立检测或拦截规则，实现安全防护的目的。因其部署较为灵活，且对业务的侵入性比较小，是近几年非常受欢迎的一类安全系统，且商业化产品层出不穷。

1、WAF架构分类

WAF架构根据部署方式的不同，通常分为cname部署、module部署、网络层部署。也有部分公司根据自身需要实施混合部署与运营的架构，这通常需要一定的架构设计和开发能力，包括业务方的配合。国外几款商业产品的WAF支持导入证书的方式来解决HTTPS环境的安全防护，通常国内各甲方安全团队自研WAF产品基本不支持HTTPS。

（1）cname部署

这是近几年国内非常流行的WAF部署，知道创宇推出的“加速乐”就是其代表产品。其部署方式非常简单方便。只需将域名Cname方式解析指向加速乐分配的cname别名就完成了部署。对于用户来说，整个WAF的防护和运营几乎是透明的。

cname方式最大的优势就是部署方便快速，且理论上还有加速网站性能还和阻断DDoS攻击等效果，实现了安全防护和性能优化双重目标。这也是常见的厂商宣。但其缺陷也是非常明显的，HTTPS流量是无法防护的，因为中间代理无法解析请求内容，进而无法对其攻击负载做检测与防护。

（2）module部署

module部署的WAF典型产品是开源软件ModSecurity。最初ModSecurity是基于Apache httpd上的module开发出来的，针对HTTP/HTTPS协议攻击做检测和防护的开源产品。现在已经衍生出IIS版和Nginx版。

这种部署方式相比cname方式麻烦得多，需在webserver部署\编译时支持modules，编译完ModSecurity模块之后，修改webserver配置文件生效。它通常默认就已经有大量的安全策略规则，但如果全启用，一方面性能消耗很大，另一方面也未必适用于自身环境安全问题。所以后续还要对规则进行优化精简和按需增加，对运营人员的要求相对较高。

基于业务环境webserver功能的不同，还出现了一些非典型不知名的简易WAF类产品，这些相对小众，也可能是企业安全团队自身开发和运营的。例如基于Nginx的LUA脚本开发的WAF，基于IIS筛选器开发的WAF。理论上成熟的webserver均有module等二次开发接口，均可以按需开发建设相应WAF类功能产品。

Module WAF在应对HTTPS类业务时非常适用，缺点是产品开发与运营成本非常高。部署过程需要业务中断且运营人员工作量较大，需逐台Server部署，对于规则的运营也需要投入大量人力。所以适合有一定开发和运营能力，且业务规模较小的公司。

（3）网络层部署

此类WAF产品是最易部署的方式，它可部署在机房或某被防护的网络入口位置。这不同于其他几类，它的部署和运营可以算是真正的透明。不需要对业务有太多侵入与变更，特别适合互联网公司变更多、架构复杂的环境。

它的缺点明显，对于HTTPS协议无能为力。优势也明显，无侵入性，易部署。不影响业务性能，可旁路接入，通过RESET包阻断HTTP会话。

（4）混合型WAF架构

为满足业务的多样性架构的灵活性，很多大型互联网公司还建立了混合型的WAF集群。可以通过前述几类WAF的组合，实现相互补防覆盖不到的地方，真正实现无死角防守。如图20所示。

图20  混合型WAF产品架构

2、WAF安全策略建设

通常一个WAF产品起码会有两类规则：1）通用型主流漏洞检测与防护；2）最近出现高危1day\0day漏洞检测与防护。有运营能力和重要资产的公司会针对业务特点制定出第三类业务风险类型的检测与防护。

（1）主流Web漏洞检测规则

为了确认是否覆盖“主流高危Web漏洞”这个标准，我们需要选择参照物。通常推荐使用以下平台：

● owasp测试指南（http://www.owasp.org.cn/owasp-project/OTG）

●各主流Web漏洞扫描器（WVS https://www.acunetix.com/vulnerability-scanner/）（APPS-CAN http://www-03.ibm.com/software/products/zh/appscan）

● 漏洞测试演示平台bWAPP（http://www.itsecgames.com/）

借用以上平台，在规则建设中对于自研和部署的WAF产品的实际能力做出客观的评判。同时注意，此测试与迭代优化过程需要周期性进行，如图21所示，安全工作有一个重要的特点：需要及时更新。

图21  WAF规则建设流程

（2）最新高危漏洞检测规则

安全系统运营最重要的工作内容之一，除了部署覆盖就是检测能力的迭代更新。每当爆出最新漏洞的时候，运营人员必须第一时间跟进，分析POC和漏洞原理，提取相应的检测规则，及时部署新规则到WAF系统。WAF系统对最新漏洞攻击的阻断也称为“虚拟补丁”，意为非真正的安全补丁，只是临时封堵攻击行为，为业务方真正更新补丁赢得宝贵的响应时间。

在0day\1day爆发的时候，赢得时间是第一目标，而第一步也是最重要的一步就是及时获取威胁情报（threat information），如图22所示。在获取到情报之后，组织运营人员测试分析，提取规则上线，到这里与之前的规则建设流程相同。

图22  WAF新增规则建设流程

威胁情报的获取通常可以通过情报渠道、订阅安全工具开发社区RSS、关注相应APP官方安全信息等方式。

（3）业务风险监测规则

在有足够的运营能力前提下，业务方可提出某类规则借用WAF等安全系统帮助监控某些业务异常行为。这里的规则多数分两类：1）已发现的业务漏洞，需临时封堵攻击行为，为漏洞修补赢得时间；2）某些高危或异常行为的监控，主要目的生产数据，为业务异常行为分析提供数据基础。

3、WAF性能优化

在中小型网络中购买一个商业WAF产品基本能满足需求，且根据流量大小还可以选择适配的型号。但在大型和超大型网络中，性能的优劣变成关系到项目和系统生死存亡的关键性问题。

（1）架构优化

在WAF项目评估与预研初期，架构的选择是评估重点，也同样影响最终产品的性能。选择考量的因素包括团队能掌控与选择的资源，业务方对性能的敏感度，最后才是安全运营与检测能力效果的考量：

● 资源——如果拥有整个机房的网络建设管理权限，则可以考虑在机房核心交换机处流量镜像到我们的WAF设备，此时无论WAF的性能如何，均不会影响业务的正常运营，是较为理想的以检测为目的的WAF架构。

● 业务性能——安全产品对性能的影响通常是业务方最为敏感的问题，往往业务方耗费大量资源投入优化为提升业务性能毫秒级的响应，可能因安全产品的接入立马消耗殆尽。如果不能解决业务方挑战的问题，那么您的产品基本没有被接纳的机会。所以核心业务基本不会接受类似ModSecurity那种侵入性的安全产品，所以更应该优先选择Cname或接入层module WAF方式。

（2）规则优化

在实际检测能力中，规则计算应该是WAF性能最大的开销，既可能影响业务性能指标QPS，在大型网络中对计算集群的资源耗用也较大。比如ModSecurity历史上就出现过多次DOS攻击漏洞，并且未经优化的规则也会导致WAF因资源消耗的问题主动阉割掉部分检测能力。

● 算法优化——WAF的流量匹配不能粗暴地直接丢给正则引擎，那会带来大量的不必要的开销。首先对流量进入WAF到最终遍历各种规则的整个流程要考虑清楚，层层筛选直至剩下真正需要进入正则匹配的流量，如图23所示。

图23  算法优化原则

● 正则优化——Google出品的正则引擎RE2是目前公认的较好引擎，相比传统古老的PCRE引擎更快速高效，可以作为引擎的首选。但在实际使用过程中RE2存在一个明显的问题，那就是对二进制数据流匹配存在问题，例如“隐含恶意代码的图片文件上传”这类场景中无法使用。那么就要求WAF支持规则配置不同的正则引擎，当评估某类规则可能碰到二进制数据流时，可配置为PCRE引擎，默认则用RE2。