近来拼多多爆出的羊毛党事件使得计算机信息安全再次被提到人们的面前，原本属于计算机安全学科中的“薅羊毛”这一专有名词也被众多普通人所熟知。通过拼多多事件还原我们得知它其实是一个非常简单的“低级错误”导致。

只需花费4毛钱就可以领取一张100元的无门槛优惠券，而不设“总量限制与单用户限制”。这一消息瞬间在薅羊毛行业内流传开来。凌晨5点左右，在羊毛党内部已经彻底发酵的“抢券行动”，被发布到了一些公开论坛上，引发第二轮的抢券高潮，根据放在网上和微信圈的截图一些“大牛”更是一夜领了上千张券。拼多多损失惨重。。。

在当下，除了昔日的BAT外我们还有饿了吗、美团以及“二微一抖”。哪家不是以优惠券、活动、刷积分、秒杀来“吸流量”的？因此，越来越多的羊毛党黄牛党也纷纷加入了这个“战团”并且随着近来硬件成本的整体下降、网络流量成本的下降使得“机器人、自动工具”抢券刷活动的这些“黑产业”的入门成本变得越来越低。

你可能只要每月花上几十元最多上百元就能获得上千元、上万元的券！

各种黑客、自动化、爬虫技术层出不穷，从最早的撞库、暴力破解乃至到了基于大数据、自动建模、深度学习来爬网站的券。线上产业也面临着日益增加的被“黑”被“薅”的风险。

本人在现企业亲历了两次双11、双12，基于以18年的双11和双12遇到了不少“变种羊毛、黄牛甚至还碰到了每天都在自我进化的各种羊毛、黄牛、爬虫工具”。各“遭遇战、大小战役、防守”不下数十场，特记录下来抽象总结写出来供后人参考。

一、由短信炸弹引发的一次战役

那天临近双11，来到公司收到相关PM说我们的短信（SMS）网关在接近8点时突然并发量超过平时10倍但是在9点前恢复正常。虽然这件事的结尾是“恢复正常”可是这件事高度引起了我的警觉。

说实话本人和DDOS、羊毛党、黄牛党遭遇过5次，前面5次都是在以前“首席信息安全官”的配合下作战，因此对于类似事件有着本能的敏感。

出于历史教训，我的上家曾在春节前至年初三被人用SMS炸弹攻到每天损失10几万。在此有人会问，SMS炸弹是什么？

SMS炸弹就是通过“调用短信网关”的API，在同一时间使用大量的并发请求该相关的API，要知道一家公司接入SMS网关是需要付“通道费”的，多则1毛，2毛，少则也要几分钱，试想一下10万到20万量级的并发调用连续不停24小时持续几天来调用这些接口那么对于公司来说这是一个什么样的后果？

从用户角度来看，事发时将会有很多用户不定时或者有规律的每天收到大量的短信，而现今社会，假设我的手机每天要收10条淘宝推过来的短信，我敢保证我马上会注销掉我的淘宝帐户马上不用了，更不要说如果有用户在一天内收到几十条短信那将会是什么后果？

这次恰逢我司更换和升级了WAF，从原来的WAF升级到了腾讯云WAF的第二天

以下是我们使用的基本的一个网络拓扑图，无论是在DC还是在云上的服务器都是接入的腾讯云的CDN和WAF组件，当然实际架构比这个复杂的多了，只是碍于企业内安全保密制度因此我只能给出一个拓扑图。

以下是腾讯WAF+CDN的主功能界面

而腾讯云WAF尤其在“防BOT”上有着“功能完善、操作简便、学习曲线短、接入及可用”的特点，它的AI判断引擎和监控捕获机制以及“二级刹车机制”给到我们很大的帮助。

什么叫二级刹车机制？先简单的说一下这个机制：

在我上一篇的“OWASP Top 10十大风险 – 10个最重大的Web应用风险与攻防”中我介绍了DDOS攻击，即以大流量搞崩你的网站，那么还有一种“大量并发爬虫”也会给你的网站造成比在流量上遇到的更糟糕的攻击即“CC攻击”，WAF就是专防这种“攻击”的。而大家可能没有太多经验或者没有过“几次大战役”的朋友们可能还不知道，有一种比“CC攻击”还讨厌而且危害更多的攻击，也正是这种攻击造成了“拼多多优惠券”事件的杀手即“慢BOT攻击”，这种攻击在没有完善的机制、监控和防护工具时几乎是难于设防的。

一般来说CC攻击只能算是“先峰部队的攻击”，紧急着到来的就是“慢BOT攻击”或者是“CC伴随着慢BOT”的一起攻击。

因此对于一 个WAF来说需要有一种“二级刹车”的防护机制

前刹车

用于处理CC攻击，比如说“同一个IP每秒达到多少次”就认为一定是一次CC攻击，我举个例子：

同一个IP在5秒内对手机商城进行了50次登录，这肯定是一次“CC攻击”，因为人的手是点不到这么快的速度的，即使有某个人可以达到这个速度那么。。。这样的人我们也可以认为。。。不拦这种人拦谁？对吧！

后刹车

有了前刹车后，一般“低等”的CC是可以防住的，它充其量起到防护你的网站不会被人“搞崩”，但是我前面说过有另一种攻击，它用的是一种叫“慢Bot攻击”，比如说：

每秒0.9次左右的速度（平均值除下来）然后连续10几天“挂”在你家网站上。

那你也受不了。

此时，慢Bot防护将成为我们的第二道防线即后刹车机制。

我们这次的短信炸弹我登录进了WAF进行了查看，发觉在零晨和接近9点时 mobileSmsAPI接口被访问的频次特别高，再展开细化日志分析发觉有诸多个IP以每分钟达470-500次的速度在访问这个mobileSmsAPI接口。于是当时我们对这个短信接口做了前刹车，每分钟设制了150次的调用限制。

除了设限制外还需要在WAF设置一个“惩罚措施”，这也是WAF的一种被动反击机制。

于是当天几乎是立马止血!

但是我们的防范措施并未就此停止，因为这只是第一道防线而己，设想一个用户他在一个线上商城中使用到短信的场景有哪些？基本的有：

1. 登录验证

2. 注册验证

3. 忘记密码时验证

4. 支付时有时也有验证

基本一个用户我们说如果他是一个正常用户，在一天内会使用短信的次数不会多于20次，以这个界限来设置后刹车即慢BOT。

于是我们开启腾讯云WAF的BOT界面设置后刹车

于是在CC攻击策略和Bot策略生效5分钟不到这件事几乎立刻止血。但是。。。故事并未就此结束。

二、因为防范短信炸弹而带来的麻烦

第二天还未上班在路上时，我微信开始收到了业务的投诉。投诉的内容为很多客户说无法登录我们的电商网站了。我让我们的客服发给我看截屏，截屏显示均为“WAF拦截页面”

我以前碰到过是有一些使用机器人、工具的“客户”被封了后故意来投诉，但是如此之多的投诉我还是第一次碰见，而且我到公司后查了一些投诉的客户的会员号，可以从历史购买记录看出，这些确实是真实的商城客户。

在我的追问和分析之一下，发觉这些客户有一个共性，即：

这些客户的IP均为共享IP，什么是共享IP？如：

• 在星吧克使用WIFI，客户的出口IP为星吧克IP；
• 在线下门店使用店内WIFI，客户的出口IP为店内IP；
• 在办公大楼内使用楼宇内的WIFI，客户的出口IP为整个办公大楼的IP；

那么好，假设这个楼内、或者是属于我们的线下门店内真的因为我们的线上商城某些活动做了好，那么同时有多个人出自该IP来访问我们的APP，那么在WAF上的表现就是同时会有可能在一分钟内同一个IP的访问次数达到CC攻击阀值或者是慢Bot攻击阀值呀，对吧？

比如说，我们的一些线下门店它们会在店内做线下促销人员的“递推”工作，那么这个店内就会发生多个客户同时来访问商城的情况，这样就太糟了，这个误伤就会很大。

于是我们第一件事就是：

放开CC攻击的频次，把它放到60秒内500次并关闭慢BOT攻击。

但是这个放开后前天泛滥我们短信接口的那些个机器人、爬虫、工具几乎马上又上线来攻击我们了，这怎么办？

于是我们再次做了一个推演：

假设我们的CC频次为60秒内500次（这个是根据和业务并结合门店销售情况商量的结果），它防的是那些个以高频次如：

• 来自广西的IP：192.168.0.1
• 访问/api/mobile/sendSMS
• 每秒访问：557次
• 总计15分钟

这种属于典型的“不动脑子Low水平攻击”，使用CC几乎一防一个准。

但是这次的攻击是混合着Low水平也有高水平的攻击，因为当你降低了CC攻击的防问频次势必就会漏放过一些慢Bot。

当时由于考虑到“误伤”，因此我们关闭了慢Bot攻击，现在我们需要把它开启起来于是我们又进行了一次推演：

假设以下四个场景，每个用户重试允许3次，正常的访问用户一天也不过在12次左右。

1. 登录验证

2. 注册验证

3. 忘记密码时验证

4. 支付时有时也有验证

因此下面这个Bot策略看似没有错呀？

等等。。。等等。。。这边有问题了，我们想到了这个慢Bot它防的是“同一个IP，对于某个行为，以多少频次，总计访问了多少次”这样的防范策略。

可是别忘了这个场景可是对于“共享式IP”来说啊，假设一个线下门店同时有20个用户真的在“促销员”的指引下来使用我们的线上商城了，那么这个值几乎是瞬间“爆机”的。而且无论是Bot还是CC它都会有一个惩罚措施，根据腾讯云WAF的策略它的惩罚措施表现如下（其它WAF类似）：

• CC策略被触发时它会封锁用户几十分钟到几十小时
• Bot策略被触发时它会把这个IP加入到WAF的自定义策略作为“黑IP”封禁几天，几天到期后再从“黑IP”中移走该IP

那么这样一来它的误伤带来的伤害其实是很大的。因此我们没法使用Bot策略防范，只能防那些“不动脑子的高频CC”而放过一部分攻击，但也正是放过的这一部分攻击也为一家企业或多或少带来损失的。积少成多，每天几百块，一个月得多少钱？

当推演到这一步时，于时我结合我若干年前的防短信被刷的经验马上联系了这个商城的开发团队，在询问和共同分析下果然发觉这属于代码逻辑的问题了，即代码逻辑上未做防护，于是我马上给出了如下的规则：

1. 对于来自于同一个手机号的对于登录、注册、忘记密码设置每次访问时的间隔如：60秒；

2.对于来自于同一个手机号的对于登录、注册、忘记密码设置每天总次数，你觉得一个正常用户一天内登录或者是注册或者是忘记密码重试6次以上属正常行为吗？

3.对于用户侧来自于同一个手机号一天接收到总的短信控制在20条；

4.以上阀值一旦被触发，那么用户侧会收到一个小提示“亲，请稍侯再试哟”；

1小时左右上述代码逻辑紧急上线后，这个“短信问题”再也没有出现过了。

这就叫“温柔的杀戮”，因为前面说过了：

• WAF的杀伤是属于“硬杀伤”，当你触发了WAF的阀值，它会封掉你一段时间，在这段时间内你的整个IP对于整个商城的任何操作来说是“被禁止”的；
• 程序代码逻辑的杀伤是属于“软杀伤”，当你触发了某个逻辑阀值时，它会善意的提醒你不要再做这个操作了而对于其它操作你还可以继续；

故事到此还没有完，因为这次有效的防范却惹闹了我们的“羊毛、黄牛党”。

三、网站被“核了"-从"外爆"到"内爆"

短信泛滥被遏止后不出2天，又是早上8：00不到那阵子正好线下门店有活动，8点不到我的手机被微信发爆。说是公司的APP严重卡死、白屏。当时我收到消息后打开看了一下发觉情况不妙。

到了公司登上CDN后看了一下发觉入站流量只比往常多了0.3-0.4倍，这样的流量怎么会把网站和APP搞死？于是我翻阅了CDN的相关日志发觉多出的流量都是来自于几个特定的url，这几个url非常的特殊，我列举几个如下：

• 手机端用户行为采集
• APP版本检查
• 查商品库存

好，我们就对上面的4个URL一个个来说它们是怎么被“Nuke（核）”爆的。

4个url是在我们的CDN里排名TOP 4，先来看这个手机端用户行为采集。

手机端用户行为采集的防范

使用慢Bot策略

这个url做的事就是用户打开我们的应用即开始有规律的记录用户手机端、网页端的行为了。然后它会以异步方式进行写数据库操作。

于是有人对于这个url进行频率高达300-400次左右的连续刷机。当然，这块我们用CC防范即可防住。

按下【添加】按钮，瞬间觉得很开心，看着看板上显示的大量的IP被封马上脑子里闪过一个念头，不对，要出事！为什么？

试想一下，一个用户从打开我们的应用开始这根接口就会被调用，那么对于线上商城、淘宝类APP一个用户肯定会花点时间挑挑拣拣、这边看看那边看看、货比三家，虽然说“小张”同学说哪个APP能让用户停留30分钟哪个APP就算胜利了，但是那必竟是二微一抖+美团或者是饿了吗，但我们的应用至少让用户停留个15分钟-22分钟那也很正常的对吧。

这15-22分钟单个IP会造成多少的url访问呢？虽然上述规则下去马上可以看到网站开始“减负”但是它会造成多少“误伤”呢？因为WAF的“惩罚”可是硬杀伤啊！

好，那我们马上把这条规则disable掉。

但是disable掉后又纠解了，网站频繁的报卡甚至连前端web服务器、数据库的CPU都告警了，不防也不行？

怎么办呢？

于是我们想到了“后刹车机制”即采用慢bot策略。

我们试想一下，如果是正常用户我们就算他一天有累积1小时使用我们的线上商城，然后和开发团队取得了这个用户采集行为的规律性频次，得出一个值来。

我们说：一个合理正常的用户打开我们的线上商城后这个用户行为采集以每秒钟X次（我们为了举例用3这了数字吧，这也是一个举例用的数字，实际不是这个值）的频率主动调用后台并以异步写数据库，一个用户累计2小时会造成：（2*60分钟*60秒钟）/3=2400次请求，这个2400次请求是当中不掺杂任何其它请求的连续性请求的。举一例来说用户从：

2. 用户行为采集

4. 用户行为采集

以上是一个正常的用户登录，试想2400次请求已经说明这个用户在我们的APP上停留了很久了。但是我们分析和收集到的这根url 被访问的次数那可都是超过5位数的，它是类似于下面这样的登录方式：

2. 用户行为采集

3. 用户行为采集

4. 用户行为采集

5. 用户行为采集5万次

所以我们设上这么一条策略：来自于同一个IP每秒以大于3次的速率连续访问了2400次用户行为采集这根url，它在WAF上设置的具体表现如下：

我们没有直接开启“拦截”而是打开了“监控”，因为对于Bot的防范我给到大家的建议是先观察是否你的策略有效以及命中率是否高后再做拦截，而不要直接“贸然”去点拦截。

我们观察了一下，发觉这条规则还的命中率还是很高的。

• 首先正常客户肯定到不了这个阀值
• 其次有那种特别聪明的典型慢bot，它以每秒钟点一下然后连续在我们网站吊了近“17,000次=17,000秒/60秒=283.3分钟”的bot，试问如果是一个正常人它会打开着这个应用然后用手捧着还要不让手机锁屏随时随地要保持这个被打开的应用被激活着并以这样的状态保持283.3分钟。。。那可是11.8天啊，这是人吗？肯定是机器人，就算这是一个人。。。那这样的人也不应该属于被考虑的对象对吧，因此杀了是很正常的。
• 最后就是有一些每分钟40，50次甚至以每秒钟50次的速率来访问我们这根接口的bot、自动化工具，那更该被封杀没话说

可是，事情又有变化了！

有策略的慢Bot

这条规则生效不超过8小时，公司投入了新的硬件并使得我们的网站有了成倍的抗压性，于是业务要求考虑那些真的可能是吊了超过2小时的那些“客户”，因为事实是有一些“中小型零售商”他们确实是会用我们的APP来采购几百上千件商品的，那么这些中小型零售商的操作者也确实会在我们的线上应用挑挑拣拣、这边看看那边看看并最终可能超过2小时以上的使用者。

有些人停留超过2小时，有些人停留超过4小时，有些人是登录的我们的PC端（因为这些操作者是一种小B端因此大都时间他们都是在办公室用电脑访问）然后这些登录我们的PC端的用户最“坑爹”的可能是打开我们的应用网站、登录后就不关电脑了，把屏幕一关然后下班回家了。

因此对于这样的客户，业务极其希望我们可以照顾到他们的感受而不要把它们硬杀伤，而且每次如有“客诉”过来要求解封一类的操作这着实也让业务和我们的技术部很累。

所以上面那条Bot策略需要放宽，但是又要把一些恶意的请求给挡住，因为策略不能不设不设马上服务器集群的CPU会飙升，放了太宽等于没设。

于是我们利用上面的这条策略再次进行修改，修改如下：

哎！加了一个叫“UA类型”即user-agent，同时我们把“访问总次数改成>99，999，但是同时把unknown给选上。一般来说用户的浏览器无论是手机端还是PC端都会带有一个user-agent过来，如果是unkown的90%为以下类型手机：

• 非法操作用户端如：Bot或者是自动化工具
• 刷过机的Android
• 非正版偏门自破解类手机

所以把上述4个条件组合在一起，那么可以说这个误杀的概率对于“真正用户”甚至包含了上述的“长时间吊机的真实用户”是很低的，就算偶尔有一个“小B端用户”告诉我们，它的浏览器被“封”了，我们只需要电话寻问一下并告诉他使用chrome或者是mozilar几点几版再重新获得一下新的IP 100%可以解决类似的“误杀”问题。

而混合了“UA=unknown”的规则（它与其它三条规则是&&的关系）它比原来的Bot策略要显得宽松，宽的是它考虑到了那些长时间吊用的那些真实用户，同时对于“100%的非正常用户”那就是“杀”。

但是它的缺点也是有的，即它还是会有“漏网之鱼”的。而且这部分的漏网之鱼那可是穿透了我们的“后刹车”的啊，根据我之前的经验和之前防短信验证码被刷时的设计一样，再在代码逻辑层设计一道防线即第三道防线：

代码逻辑端的防线有多种，有温柔的杀戮如前面对于短信接口被刷的设计，而对于这次用户行为采集防线的设计我们使用的是“建水坝”。

设计如下：

• 增加一个API Gateway，对于用户行为采集这根接口进行“HTTP流量”的限流
• 限流后不抛弃，通过MQ缓存进入NOSQL
• 还是使用MQ，在系统负载最小的时候把“缓存的请求”做异步请求回放然后入库写日志
• 使用定时任务，当相关日志库到达一个磁盘容量阀值时做自动备份后再清理

其中的API Gateway的设计可以见下图所示

以上设计被实现后该问题立刻得到解决。以上这就是一个典型的外部攻击造成内部“内爆”的例子！

APP版本检查

APP版本检查遭到攻击是一个什么样的鬼？

每个手机端APP都会有一个latestVersion用以和后台保持心跳以检查是否后台有新APP发版的信息。

这个latestVersion一般把用户当前所使用的APP的版本发回后台以作校验，如果后台有更新那么会返回一个版本号和新版本APP的下载URL，此时用户端的APP即自动开启“最新APP版本的更新”操作。如果后台没有发布新版那边会返回一个“1”代表前后端APP版本一致用户端APP不会作任何更新动作。

出现这个问题还正正好是我们后台有一个新版本发布不超过1周的时间内，我们来看一下被攻击当时那几天内的情况：

1. 发送版本检查更新请求每小时达七百万次

2. 含返回版本号需要下载新版本的请求达180万次

3. 含返回1代表前后端版本一致的请求达520万次

接下来好玩的事情来了，我们的“CDC即数据中心”外网出口在那几天被堵死，有人会说就一个版本检查返回最少是一个JSON的1最多的是一个JSON的版本号。

唉。。。你不要小看这个只有1K、2K的东西，你把它乘以520万次的规模算算它会造成多少外出流量？近5个GB！

你家是淘宝还是腾讯啊？外出流量的瞬时带宽可以达到5个GB啊？对吧！而且还是每小时5个GB，更不要说那“需要下载新版本的请求达180万次”，每个用于更新的安装包达到近4MB呢。。。那瞬间这个数据中心的出口带宽会被占满呀。

再查看我们外网出口宽带明显进来流量不大而外出流量远超进口流量好几倍。

在云上分分钟我们是可以实现“外出带宽扩容”的，而在数据中心本化化部署的一些应用这个宽带要扩那就是联系电信、联通等更不要说公司还有采购流程，一圈流程走下来，黄花菜都凉啦！

有了上述的“用户行为收集经验”攻防后，我们迅速制定了一条Bot策略：

新增后发觉从策略生效到下午我们的外出带宽还是暴满，这条策略没起作用吗？

它起作用了，从拦截策略来看，它确实是拦截了一堆的恶意请求，可是，拦截的量还不到攻击量的百分之三！

怎么这么低的拦截率？

原因在于这条unknown。

因为这次我们碰到的黑客工具它自我进化了，比如说我们发觉有这样的请求：

1. User-Agent: IPhone/Browser（Firefox Mozilar)
2. 每秒请求次数：27次
3. 总请求次数：9,700次
4. 访问URL：手机APP版本检查

前面提到过，Bot的策略是&&的关系即每一条都为“真”才触发该规则，而经过和开发团队一起商量分析下来每秒钟这个请求不可能超过2次的，因此这显然是一个经过伪造的爬虫或者是自动化工具的请求样本。

那么把请求频率或者次数调低点呀？

那么又来了一个问题，即：有些IP是“共享型IP”，即真的来自于我们的线下门店或者是办公楼宇内的IP呀？对吧！这时一个线下卖场在生意好时真的有顾客“蹭WIFI”，每秒假设有20个人同时通过门店WIFI打开了我们的APP，这个请求就会达到每秒至少20个请求发过来呀？那如果一味的降低频率不是要产生误杀吗？

再加上现在这个请求它又进行了伪造，这可怎么办？

哎。。。不知道各位注意过了没有，刚才上述的样本是：

User-Agent: IPhone/Browser（Firefox Mozilar)

既然用户用的是手机端APP才会产生的请求，怎么可能会有带Browser的user-agent过来啊？而且我们再三检查过，如果用户侧手机APP版本是旧版本只要一打开一定会带着手机的user-agent这个头信息过来，所以带着user-agent为浏览器过来的请求肯定是伪造的或者说是不合法的，就算是真人他知道了我们的这个版本检查的API的全url路径并用浏览器来访问这样的访问请求也是完全无效的。

于是，马上我们把上述规则改一下，改成如下：

紧急着再加入另一条策略和这条策略平行如下图所示

上述两条规则生效后过了15分钟我们再来看我们的出口线路宽带，可以发觉它已经开始“萎缩”到了“限值”以上但是它还是高于“告警线”。

但是至少它不会把我们的出口带宽搞爆了，我们对它进行了持续一天的观察并且未收到任何的客诉。于是我们决定彻底把这个问题解决掉，必竟长时间宽带处于告警线内运维和相关业务owner的手机、邮箱无时不刻也会受到Alert，Alert，Cylons Base Star, Set Condition 1 Through Out The Ship：）

怎么解决呢？

很简单，我们不是有CDN吗？直接使用CDN！

我们把需要下载的那个4MB的包挂在CDN上，当用户侧检测到了用户手机端应用版本需要更新时直接走CDN上下载这个4MB的更新包，这一步一上线立刻流量从我们的“警戒线”上被彻底抬升，抬升浮度还是有一些的，平均每分钟比原来节约了9MB左右。但是它还是属于接近警戒线的，还是属于Set Condition 2 Throught The Ship状态的。

我们仔细分析这个“版本检查”的返回，如上面所说它虽然只有1KB左右，但是也抗不住几百万甚至后来达到了上千万级别的请求，而且经过了上述2道策略的拦截剩下的80%以上肯定是真实用户的请求了，同时通过和业务分析以及结合最近几天的活动证实我们的业务量确实是上升了，那我们不可能再切再切就把真实用户量给切掉了，对吧？

那么我们想把这个“版本检查”的返回也放到CDN上去，但是这边就碰到一个这样的问题：

我们都知道CDN是静态文件加速而不是动态资源，而这个API是一个动态资源，它会有一个判断，旧版本更新否则返回一个值叫1。

而CDN上做这种动态资源的判断不是一个合适的途径。

那么我们当下的痛点是数据中心的带宽扩宽至少也需要5-7天，而我们眼下如果真的再来几个大活动就目前眼下的宽带来看随时还是会“崩溃”的，这样的崩溃是很影响我们的“业务”的，我们最多只有4小时时间来解决这个问题。

于是我们想到了云，云上的出口带宽可是弹性的，因此我们迅速在云上再次使用我们的API Gateway，这次我们在API GATEWAY里会把这个版本检查的请求url给截住，截住后在云上的服务器处做一个判断如果是新版本直接在云上返回一个。

如果是旧版本云上的API GATEWAY会把用户的请求forward到CDN上的缓存了新版本下载的那个网址，如下设计

2小时内上述设计完成上线，外网出口带宽问题几乎是在上线后的10分钟内迅速萎缩，观察到下班前整个出口流量和进口流量无太大差异，目前来说这个外出流量是我们真实的业务流量了，其实是远未到我们当初设计的这根出口带宽的瓶劲的。

在经历上述的“对抗”时我们还额外发现了好几个类似的URL，有通过访问前端开放在internet上的API造成后台记.log并进一步造成服务器磁盘“爆满”的，也有通过前端的访问造成数据库日志记录爆满的，如以下这2个案例：

查购物车和查商品库存造成后端服务器磁盘及数据库爆满

和上面用户侧手机APP版本检测相反，查购物车和商品库存带来的“内爆”反而是少量的请求即带来了磁盘的爆满。

经过观察大部分的外部请求为真实或者接近真实的值，比如说下面这样的一个访问样本：

1. 访问频率为：每秒钟平均0.92次（平均值求下来所得值）

2. 访问总次数：830次

3. 访问时长：15分钟左右

4. 访问URL：查询我的购物车

这样的访问竟然造成了后台数据库磁盘爆满（包括数据库表）？

首先我们先按照ua=unknown并结合一个合理的阀值来对一些非法的请求进行封禁，然后发觉根本无效这时就变成了系统优化的分析了。

因为这根本就已经不属于WAF所能做的事了，于是我们直接挂APM探针对SQL进行探索，发觉其实这个问题是后台相关动作牵连到了一系列的API的调用，而按照最新的网安法相关的用户侧请求日志要求保留至少近6个月的历史记录而造成了写库太多，而随着系统上线后数据量的日益增多，写和查库的SQL未做优化而造成了全库表扫描的查询那么一条简单的查询可能靠成过大的磁盘I/O读写以及回滚日志的增大而导致数据库被“Nuke”。

但是为什么这边要提这个案例呢？

因为我们发觉了一个很严重的事，这也是我一开始在这个项目开始时的担忧，即我们面临的攻击果然是遵循着我在若干年前经历过的那几场“大战”的步伐正在发生着同样的“进化和演变”，而业务和开发正忙于版本上线的工作并未意识到这个危险正在一步步演变和接近中。。。。。。

黑客、黄牛羊毛党的攻击节奏

DDOS攻击

为什么是以DDOS为攻击的第一步呢？

因为一个看似平常运行良好的企业网站，在DDOS的高流量大并发面前会变得漏洞百出进而变得不堪一击。

自动化攻击脚本和工具已经不单单只是一个“穷举工具”了，它往往背后依托的是一个大数据采集平台并结合有AI自建模型能力并会自我根据给定的规则进行切换的一种“智能化机器人工具”。

这种工具只需要在有限人为干涉的前提下自我开展工作并以友好的报表、Dashboard等界面给到黑客们数据用以辅助决策。

举一例来说：

一个企业的网站先被外爆，然后企业网站卡、慢，它就会有各个URL的请求响应时间的反馈，这些自动化工具收集到了相应的“慢URL”后进行整理分析，接下去它会进入到第二步骤即“尝试取得企业网站漏洞”

当黑客们把取到手的URL进行自动化工具的自我编排、组合后它会找出这样的一个分类图：

1. 哪些URL可以直接内爆企业

2. 哪些URL的组合可以“获券”，“刷积分”

对于第1种，我们可以通过有TO C端架构设计经验的架构师在之前做到防范。

而对于第2种攻击，往往一些企业都是在事后才发觉的，而当企业发觉时黑客已经自我切换到了第三步骤。

试探性探测

在这个步骤内，经过工具自动编排和有限人为干涉组合的URL会以一种不为人肉运维所查觉的，并且可以伪造成正常请求的手段并在有限频率下对企业网站进行“功能性测试”。

一个伪装成user-agent为android/iphone的请求，组合成注册、登录、搜索、查看购物车、看积分、购物、退款、获券或者积分这几个步骤。而且它的频次还很低，有时低到一分钟只有1次左右。

当然，对于做了5年以上的有这方面风控意识的老鸟来说，这样的尝试也是可以通过一些蛛丝马迹来获得攻击的趋势。而对于一些后知后觉一味只求业务KPI的企业来说却往往都真的是后知后觉，而当企业查觉到时这样的攻击已经发生了，因为这是一个自动化工具它不是人，它会根据一个阀值当到了这个尝试阀值后它会切换到真正的攻击阶段即

工具尝试了几次组合后获得一定比例的好处后它会迅速切换到持续的攻击，这样的攻击也不需要太久，30分钟到1小时足以让企业损失上万至上百万。

而这样的精准攻击一般发生在零晨或者是节假日阶段，此时当人肉运维发觉时已经来不及了损失已经造成了，如拼多多事件。

我举一例来说：

业务逻辑如果是：注册、登录、搜索、查看购物车、看积分、购物、退款、获券或者积分，而工具发觉在购物篮提交后到真实付款间有一个时间差，这个时间差就算它只有1秒内，工具也可以获得大量积分时，它会这么干：

添加足够的购物篮，提交，然后马上发起退款。另一波线程驱动获券/刷积分接口狂收优惠券或者是抽奖机会。

要知道我之前说过了，这些自动化工具可都是有备而来，它们可以伪造手机号并通过大量的肉机从全国多个点并发的来做这样的操作，而获得的积分和券最终都会流向到同一个“团伙”的手里。

• 现今社会低成本获得大量伪手机号不难；
• 现今社会低成本获得大量IP也不难；
• 现今社会获得大量用于在全国各个点发起攻击的肉机成本更低；

加上科技的普及，这4个因素加在一起会导致一次这样的攻击很可能它的成本不超过6位数，而我们要知道它攻击企业的行为那可是并发式攻击的，不只一个企业这么被它攻击往往在一个时间点内是有数十个甚至达百个企业被这种工具“并发的攻击”的。

那么对于BAT这样的体量来说他们会自建风控系统，做到防范于事前。

对于一些大企业来说他们会去买一些第三方风控系统；

但是对于多数中小型或者是创业型公司来说上述2种都比较耗成本，怎么办？所以我们下面要开始聊的是一个止损而不仅仅是在防损，因为就算防终也有漏网之鱼的。

在攻与防的较量中永远是攻的成本较低（最好的防守就是进攻-嘿嘿），那么一旦有了漏网之鱼如何止呢？这是有一定的讲究的。

攻、防、与止损

这边不想做太多学术性探讨或者是算法探讨只讲干货，就按照我的风格直接给出通用答案。

API列表的精细化梳理

一个网站在上线或者是上线后不久需要马上梳理出一个API列表，这个列表里必须包括所有暴露在公网的API URL并辅以文字进行每个API的业务功能概要说明，尤其对于一些涉及抽奖、敏感信息、刷积分、获券的API需要放在第一优先级高亮标出。然后和业务商量每一个API的频次、逻辑限制，用至少三道防火墙：CC+BOT+代码逻辑去做控制如我上面的“短信验证码一例”。

对于一些敏感的API列表不要急于“封禁”，先在WAF上作观察再作“下手”的准备，我们在腾讯云WAF上是使用类似这样的策略：

对于显示成“监控”状态的API列表进行判读，甚至可以通过WAF提供的API接口用程序辅以“规则”去批量做“判读”。黑客用了自动化工具我们当然也要使用自动化工具才能和他们“赛跑”呀？不是吗？难道一味被动的“后知后觉”？对不？

比如说当我们自己的自动化工具或者是人肉在观察到诸如此类的攻击时：

这个URL重复指数越接近“1”代表这一段时间内比如说“5分钟”内的请求几乎都为对同一个URL的请求，如果当URL重复指数为“1”时并且持续了5分钟10分钟且频率很高比如说一分钟超过17次，那么铁定这是一个工具在做“试探性”攻击，哪个正常用户会吃饱了饭没事干以每分钟17次的速度去连续点击一个URL还战了10几甚至几十分钟呀？这时就直接可以写一个策略把这样的请求给封禁掉。

这点是腾讯云WAF的好处，确实在分析上给到了我们很多的参考数据以及提供了很多的便利性。

一切登录、身份验证有关需要加频次和总次数限制

对于登录、注册、忘记密码、邀请等涉及到用户身份认证信息不仅仅只考虑到为了获客而给到客户在使用上的“便利性”，更多的是需要把频次和总计次数考虑进去，这一块需要业务+技术一起来做决定。从一个正常用户的角度来说，你限制了它每次收到短信验证码的频率，这是业界的通则大家都知道这是有必要的，但是很多时候我们忘记了一个“总收到条数”的限制，比如说我一天收到淘宝50条短消息，就算它是淘宝还是支付宝我会立刻把它给注销了同时去投诉的，对吧？

这边说的是比较理想状况，很多一味追求KPI的企业甚至连频次都不设限，那就更夸张了。

更不要只依赖于WAF去拦，我前面举的例子中就有实际一个门店真的地推做的好，于是来自该门店共享IP的用户数就会增多，这时你用WAF去挡那是一刀切，一定要用“温柔的杀戮”

• 亲，请过一会再登录哦。。。
• 亲。。。你登录的太频繁了。

当然。。。。。。如果你嫌这个“亲”真够烦的，直接扔出一个“前端行为判断的验证码”如那种拖动的滑块，不要小看这个滑块，它后面是一个SAAS或者是本地化部署的行为模式分析引擎，它通过前端用户的拖动滑块是可以直接分析得出当前操作是人还是机器的，如果前端操作的真的是个机器，那么施以惩罚。

并发锁与自动化测试很重要

对于并发锁一类做足够的自动化测试，我们现在很多网站使用Redis做秒杀、抢TOP10的一些活动，而这个并发锁没有设计好，很多时候测试人员只是通过最多2个不同用户的操作来测这个“功能性测试”，而自动化测试讲究的是你可以设任意多不同用户然后编排好规则让他们就去全真的模拟做一次抢券、抽奖活动，然后再来看这个结果好了，很少有企业会去这么做？为什么？嘿。。。说到底还是一个投入的问题。那么好！！！不肯投入吃大血亏在后面。

合理编排你的业务逻辑

合理编排你的业务逻辑，让一次交易过程无泄可击。在国内很多中小型企业的业务需要动嘴皮让开发加班、压缩开发时间进而导致业务逻辑停留在“口口相传”，要知道把一个业务的逻辑用UML或者是最最基本的“菱型、方框”画出来并且保持实时的更新、变更是和程序开发上的“接口文档”一样重要的，因为有了这个业务逻辑大家就可以坐下来，把它打成投影然后一起来进行推演，比如说下面这段业务逻辑：

注册、登录、搜索、查看购物车、看积分、购物、退款、获券或者积分被我刚才举的一个打时间差的例子可以大量获券

黑客的作法就是：添加足够的购物篮，提交，然后马上发起退款。另一波线程驱动获券/刷积分接口狂收优惠券。

如果我们加一个我们从支付开始到第三方支付渠道返回状态的判断后再给券呢？这就可以防损了呀。

当攻击不可避免时的止损

当代码还来不及改时当业务还没有意识到时。。。本来我会损失10块钱那么我让它损失控制在5块钱，这是可以做到的。

举一例来说：

用户完善一次地址或者个人信息即可以拿到一张无门槛优惠券20元，然后这个API暴露在公网上。而开发团队和业务都没有意识到或者是根本没有时间去做这样的一般看上去的“非功能性需求”防范时，WAF能做的就是需要从“常理上”来做这个判断了。

• 想像一下，一个正常消费者可能会在一分钟内添加20个地址吗？
• 想像一下，一个正常消费者可能会在一分钟内更改60次手机号吗？

触犯了上述的常理，那就罚呀！

怎么罚，喏，来一个永久惩罚：

再举一例来说：

对于一组伪装的很好的攻击我们可以抓重点来防，如添加购物车->查看积分->删除购物车，在一段时间内有一个IP反复如此规律性的操作10次，你需要高度注意了。

这个次数不仅仅是当天或者是一段时间内你要联系起最近一段时间这个IP出现的次数，哪怕每天只有一次但是因为它必竟是机器因此它的重复指数是有矩可循的，那么你也可以写一个大数据分析这些规律后再通过WAF提供的API接口调用自动对类似这样的“规律性操作”进行封禁。

再来一例：

点击抽奖，你需要用积分或者是先达成一个什么条件再能点击抽奖，试想一下一个正常消费者可能会在20分钟内或者是一小时内连续“拥有50”次抽奖机会吗？不可能，那么封。

有人就会说了，哎。。。万一50次内有一次中了怎么办？

请注意，我们这边在讨论的是当代码来不及改以及业务还未意识到的时候，那么就算50次内中一次那也比你被人连着试了一天然后中个几十次的损失要小吗？

两害同存，取其轻。

但是，最后这边还是需要多说一句：

WAF不是万能，它的杀伤是硬杀伤。

关键还是需要靠代码逻辑的组合以及精细化的技术管理并辅以业务（这对一些以业务为导向的传统公司较难做到）方的配合才能真正做到止损、防损。

我们要的是温柔的杀戮，千万要忌讳“暴力的杀伤”。

那么当暴力杀伤不可避免时，除非对于一些老油子我们可以采取永久封禁策略一般来说这个封禁也是需要一些“策略”的。

前面说过，黑客调用大量IP是很“廉价”的一件事，当这些IP被黑客使用了一段时间或者被WAF封禁一段时间后它会被黑客“释放”出来，一旦释放，这些IP就会回到一些真实用户的手里，而当真实用户来访问我们的网站时，这些IP如果还处于封禁状态那么此时损伤的将是这些真真实实的“金主”了。

因此，一般来说WAF的的封禁会采取比如说：

封你3天，3天后自动解锁，解锁后如果该IP回到了真实用户手里那么他是不可能触发相应的封禁策略的。

如果它还在黑客的手里，那么不消1分钟它还会被封禁，如果黑客不断使用这些IP那么正好，这个IP就会永远被这样封下去。

以此来达到“我不一定全防得住但是我会让你增加你的攻击成本”。