高性能零售IT系统的建设08-9年来在互联网零售O2O行业抗黑产、薅羊毛实战记录及打法

前言

        2012年左右转入互联网应用，由于本身在学校时就涉足过远程医疗影像中的DICOM安全领域这块，因此也是机缘巧合我进入互联网第一年就遇上了一次亿级的DDOS攻击以及千万级CC攻击短信系统的对抗。那时在公司一战成名，直接从team leader升到了主任架构师。

        其间前前后后8年多来，遇上真正的成规模、成体系的对抗共有4次。这4次和黑产“打”的惊天动地，4次战役每一次跨度达3-4个月，这其中大小战场不下100来场，攻防间有进有退，平均下来，我这边赢面是6分、黑产4分。

        因此积累下来了一整套打法，这套打法我认为不仅仅是计算机科学技术的体现、更多的是博弈学甚至加上一些兵法。

        比如说我在某全球著名连锁超市的-618保卫战中就画过一个这样的图：

         其中就用到了围点打援、迂回包抄。

        再譬如说我在另一家全球著名连锁超市的圣诞保卫战中总结过这样的一个黑产攻击矩阵图，一度被人称为“黑产攻击全业务功能”。

         我们在这个系列的：高性能零售IT系统的建设05-从0打造一个每秒万级并发的互联网交易系统的技术全架构中我提到了一个每秒万级并发交易的零售O2O交易中台它的6层削峰式设计中用红框画出来的部分，那么这些安全部分它们到底张成个什么样的呢？

         今天，我就把这套成体系打法全部向大家揭露这其中的奥秘。

黑产对抗光有硬件、设备、资质是远远不够的

        首先一个互联网系统它必须要有防火墙、WAF、CDN等一些硬设备。但光有这些设备你是远远不够的。

        如我一直在这个系列中所叙，架构是一种体系化打法，它一定是形成闭环的。把你的设计如果用图画出来，它一定是一个非常完整的闭环，你的逻辑设计应该从上到下到结尾处又返到头上再从上到下，如此循环、周而复使在运转的。

        如果你的设计中有一个地方没有形成闭环，那么这个设计就会有漏洞。因此90%的企业仅仅知道一个概念、知道一个名词就自以为拥有了一切，把没有做好归责于：是供应商的问题、是实施人员的问题。

不！

        我在此要说：这是思路的问题、是意识的问题、同时也是“作为总指挥员的CXO”们的问题。

        何谓体系打法？

        我们把上图红框处所标注的内容可以分解成7层：

1. 硬对抗即在互联网端也就是把这个任务落在了WAF、CDN上，就有三层；
2. 第四层，流量识别层对抗是一层；
3. 第五层，业务逻辑对抗是一层；
4. 第六层，底层系统补丁、漏洞是一层；
5. 第七层，最后是企业日常规范、历行的“巡查（含渗透、代码、漏洞扫描）”是一层；

        总共有这么7层“防线”。

        其中第4、第5点自不在话下，稍微成型点要上互联网、必须要有数字经营类执照的业务都要拿等保3级、2级资质的都有这两层来做保护。

        而难就难在第1到第3点，说白了，你有等保3资质照样被黑产打个鼻青脸肿。我看了和经历了太多了。

        因为等保3和黑产对抗本身就是两个层面的事。等保3只是数字资产的保护而己，而黑产做的一件事就是：我不要你的钱我只想要你的命！！！

        嘿嘿嘿，在此，各位请记住这句话，黑产就是“来要命”的，人家不要钱。

斗智斗勇、相互博弈甚至“共生”才是长久之道

        有人这边要开骂了，你和黑产共生什么？黑产哎，杀！！！

        我告诉你，在我早些年碰到过这样的CIO他就持有这样的非常的激进的思想，他说的没错可是他犯了一个致命的错误，结果差点把企业的命都赔进去，后面我会用大量例子来说明这种想法有多“危险”，因此我才把“共生”给提出来。

        因此，上面已经说了这么多，其实我总结就是一句话 ，叫：外吃大力丸、内部修内功。

        我们来看黑产是怎么搞死一个零售企业的。

黑产搞死零售企业招数一、占跑道

        嘿，几十家店，它们的前端流量一天达到这个点击数？你是淘宝呢还是拼多多？有这么多东西值得吸引人买吗？这些是真的流量吗？然后去每每在翻开它家手机APP、上了它家应用或者网站，白屏、卡、系统繁忙、老板鱼丸卖完了。

        我甚至碰到过业界排名前20的一个CTO告诉我：这是真实流量、因为无利而不往怎么会有人搞你？你不要大惊小怪！

        结果实际等到我把分析报告拉出来打脸everyday。

        我上面说过一种CIO叫：过激，这一种呢属于：轻敌。

        这两种都是很可怕的。

        零售业足够古老，它古老到比金融业都要古老，在没有任何科技时人类就已经有了零售。在很久远时，零售业内就经常会发生这样的事：

        一个店铺看到了隔壁的店生意比他的要好，于是每个人给50个铜板，天天雇100个人去隔壁家店排队，排到一个人了，他问这问那问半天然后不买东西。然后下一个排队的人上。天天这样连续1个月左右，最后隔壁的店想要真正买东西的人买不到，然后他自己店里卖和隔壁店一样的东西，生意马上飞速增涨。不久，隔壁那家店倒闭了。

        这种手法就是抢跑道！

        各位看过凡尔纳的：神秘岛一书，因该也对书内这么一段描写有印象吧，书中描写《纽约先驱报》记者热代翁.斯皮莱的一段：黑河战争结束后，为了能向自己的报社报道战役的结果，不惜一切代价独占电报局小窗口，连续两小时拍发了《圣经》前几章内容的记者就是他，为此报社虽花费了2000美元（在19世纪这相当于现在百万美元的巨款啊）但《纽约先驱报》首发了这则消息。

        因此这种抢跑道的事随时都存在着。它们往往会纠结起远远超过你网站的流量持续的这样来搞你的应用。堵死你的APP、小程序、网站从而让你卖不出去东西、顾客打开APP、小程序体验极差来让你“失客”，这是最最常用的手法。它当然有其“利”所在。

黑产搞死零售企业招数二、爬虫爬商品信息

        上百万个爬虫运行在你的APP、小程序上，然后这些爬虫本身就宿主在其它云上的。然后不少爬虫还不控制频率，一秒300、一秒150、东一个西一个、百万个一运行，试问你家的企业能比得过一朵“云”的计算能力呢吗？现在是主流的云的压力都压到你家应用身上了，你这应用就算是金刚钻打造的也顶不住啊？

        来看一下，一个商品排价口在早上15分钟内被人访问了这么多次，这只是全局应用中的一个接口而己。此时你家的应用APP、小程序打开是可以打得开，然而首页商品或者是分类页商品图片、价格不显示，只显示“灰色”的一些方框，你家CEO看了不劈死你家CIO哈？

黑产搞死零售企业招数三、先外爆破再导致“内爆”

        说一个购物APP，用户可以添加地址。可以添加20个地址，然后每次提交订单时不小心拿了20个地址去循环匹配一下5个配送渠道取最优物流配送方式。20*5=100次http调用。

        于是有黑产搞了100万新用户（我真遇到了）在4小时内全部注册好，然后再下一个小时每个用只下单（不付钱），光一个下单动作，一个用户是100次http调用。。。这都别100万用户运行完他们的Transaction，只要一半用户那么你的网站外部http通道就全部被堵住了。

        这还没完呢，这些信息是落库的。就算你MQ什么异步做好了，但这一通神操作架不住量大啊，直接mySQL在短期插入过多的信息，然后导致了主从延迟。主从延迟了哈各位。。。你家网站还玩什么毛线球呢？

        这就是先爆破再最终导致“内爆”的经典案例。

黑产搞死零售企业招数四、烧你钱没商量让你穷我乐意

        说是企业有短信平台，用户积分过期、商品退货、生日时、短信验证码登录时都需要使用到短信服务。一条几毛钱。

        黑产来了，老手法，同时注册100万用户，生日设同一天。然后这些用户生日到了，一个短信跑批启动，企业发觉：哎呀。。。我这个月冲了5万块钱短信费一天就没了。然后过了一段时间：哎呀我说小王啊，我这次多充了点怕出现上个月的情况，因此我充了10万块钱然后一天就没了。。。再过了一段时间：哎呀，小王啊，这个月短信费20万一天就没了，所以CEO把我炒了，你我携手一起离职吧。。。

 黑产搞死零售企业招数五、打个喷嚏“喷你一脸珍珠翡翠白玉汤”

         说你家应用可以晒图、可以发评论、可以上传头像。

         于是黑产集中一万个匿名IP在30分钟内给你一大陀的“珍珠翡翠白玉汤-见高烦华相生”，然后匿名报个警，你家应用、网站先别说什么，暂停运营一会，然后等查清了再开张。这损失。。。您品。。。你自己仔细去品。。。

 黑产搞死零售企业招数六、偷你网站内的用户注册信息

        我这边真诚的告诉你，初级黑客水平对于你应用的https破解属于“5分钟级别”，因此他们可以在5分钟内取得你https传输中的明文，有了明文他们就可以取得相应的权限甚至登录你的后台。

        不要以为你的DB处于最底层被IP Segregation分隔保护就一定是安全的，中级黑客取得你DB的密码不会超过30分钟。

        这不是剑鱼行动，而是比剑鱼行动还要夸张的现实，本人亲身就遇到过两次，身边的朋友发截图的有五次。

        一个初级黑客要绕过密码输入时用于反复试错防范的图形验证码如：随机输入四位数字、上下错位、4位数字字母带点打底线斜杠、花纹这些，他要要绕过这些只需要1-2秒钟。因为黑客手里的工具个个都是具有AI能力的，什么Tensorflow、OpenCV、什么自学习自建模，哎。。。你别忘了，黑客是通过几乎遍布在全云上的宿主机上的硬件资源，对于他们来说，用个算法、用个AI、用个大数据自建模或者干脆自己写一个AI是轻而易举的事。

         我就碰到过企业报案，抓到一大票黑产，结果发觉光是他们家用的大数据服务器就是我们整个企业所有应用服务器加一起的50倍。你和这种人去玩“躲猫猫”。光硬件配置就被他们所鄙视了。

黑产搞死零售企业招数七、薅羊毛

        如果说以上还能防一防，到了这一步，嘿，我告诉你，我亲爱的CIO啦、CEO兄弟们。如果你不是成体系化的打法和思维模式，你到了这一步连“死”是怎么“死”的自己都不知道。

1. 秒光你优惠券让你起不到引流拉新的作用；
2. 短时间让一堆小号的积分涨得比你应用里一个钻石级会员还要多的积分再来兑换你的商品；
3. 锁你的库存让你物理上有库存、数字上无库存；
4. 用300万新会员来薅光你的新人注册大礼包；
5. 利用下单送好礼，几十万用户下单后直接再退款，但是把下单送的相关礼品给你薅干净；
6. 你只要敢发优惠券、任何优惠券，对不起，2秒内可以把你当天发的券全部抢完，真实用户一个都拿不到；

         这7招，还不是一个个来，每天给你混着来一下、来两下，连续这么玩个2-3个月。你如果搞不定。。。那么。。。兄弟。。。我们手拉拉一起辞职吧。

写在对抗黑前的话

        孙子曰：下兵伐战,中兵伐交,上兵伐谋。

        这就回到了前面那个著名的CIO其实这样的人不少，在业界占比达到50%。就是：黑产呀，你给我杀干净。

        要对付黑产，我们需要先认识黑产。因此我上面写了这通用的7大招，所以我后面的打法也是围绕着这7大招来展开的。

        所谓下兵伐战、上兵伐谋。怎么理解这个事呢？

黑产的目的是什么

        黑产来“要你企业的命”的。

黑产的技术水平如何

        个个可以独自写脚本、写AI、代码算法高手、手里不缺资源，拿你集团公司下所有IT加一起可能不顶他一个人的脑袋里想到的东西多。

从黑产的思维来考虑“攻击”

1. 找到一条URL，可以反复访问，我先用手上5%左右的资源访问一下，发觉5%的压力上去后这条URL的反映从单条访问：59毫秒变成了1.17秒。然后我再在投入10%左右的硬件资源下再并发访问一下。。。不错，它已经变慢到了15秒，这个网站不行。持续一个月访问一下他。于是此时黑产通过工具或者自己1小时内可以写出一个脚本把你APP或者小程序上所有的TO C端的URL凡是那些涉及到重要业务的如：商品展示、分类、搜索等接口找个30个出来，每个用他手上10%左右的资源并发的来访问你1个月，你家应用就此崩溃了；
2. 前一阵这30个URL还访问的挺顺利，怎么今天全是403？哦。。。这个商户家里用了WAF，都拦了？好好好，我写一个简单的算法，如果我一个IP来访问你这个URL这条URL返回了403，我马上把当前IP换一个IP，同样使用10%的硬件资源，只不过一次访问403后我下一次就换一个IP来访问，不额外占用我手上的硬件池子和IP池子。而商户如果不加思考的一刀切IP，那么当黑产把被403的IP还到IP公共资源池后，此时你的拦截还在起作用，此时这条IP已经被电信随机飘到了一个正常用户手里，然后这个正常用户用这条还在被你家应用继续封着的IP访问你家应用时，正常的用户会得到什么信息？同样也是一个：403，于是黑产通过你的防御手段不仅仅搞崩了你的网站还让你因为为了防住黑产而损失了真实用户的“体验与信誉”，一石二鸟；

        我只举这两点，大家就知道黑产的思维永远是超前你一步，像下象棋一样，它当前走的这一步不是表面的这一步而是为了两步以后的：checkmate-将军而设计的。

        这就是为什么我要在讲正式对抗前先讲：下兵伐战，上兵伐谋的原因。

开始正式对抗黑产

        接着上面这个黑产的思维，我们讲对抗手法。

        黑产很聪明，因为他的知识很全面，他知道有一种叫：因为企业在面临黑产流量压力时会用请求频次来作为判断依据去“杀”，而且。。。因为有“黑产哎，要什么共生，杀！”的思路存在，因此，企业就会疏忽了以下这么一种场景：

        我们在企业应用中往往会有若干接口，它的触发条件如果是正常客户，比如说：反复输入验证码，一秒输入一个188次，这种肯定不是正常行为。如果就算这是一个人拿着“筋膜枪”、“碎屏机”一类来点击我们的前端应用那这也不是一种正常的人了。因此对于这种行为我们肯定是求“杀”。  好。。。杀了！

        而实际上我们在平日里使用的手机4G、5G获得的IP都是动态的。

        然后再来看：太多恶意请求使用大量真实IP来“撞”->撞中规则后被杀，然后他在当前IP拦截后再马上把IP“还回IP池”->进一步污染IP池->当真实用户拿到了这个IP后如果还在WAF的最小封禁时间内，此时这个IP还处于封禁期间->用户此时来访问小程序，当真实用户拿着还在封禁期间的IP来访问我们的应用时此时这个IP还处于拦截期，这就造成了大量用户被“误杀”。由此造成了真实用户对我们的应用在使用体验上很差。我们把这种攻击就称为“反弹弧式攻击”，属于非常“恶意”。

        而且每个地区的IP池子里的IP都来自于一个地区的IP基站，比如说：我在上海从长征医院前这个高架口子上去时，如果在平日下午18：00-19：30这段时间那是相当的堵的，当车堵在高架上口时，由于该地段集中了大量的车流，于是服务于该地区的IP基站一时间把所有的IP都分配光了，导致后续进入该地段的人的手机在使用移动电信信号上网时因为IP基站来不及分配IP而无信号。

        再比如说：2019年上海城隍庙举办灯会，同时时间当地任何一处景地都聚焦了几十万的人流，此时我在城隍庙里想要买一个土耳其冰激凌，发现打开支付宝后移动4G信号根本连不上也是因为该地区的IP基站把所有的IP分配完了。

        而你的公司如果真的碰到了黑产他们盯上你了，要来搞你了，他手里的IP可是来自于五花八门四处基站的IP的。

        你要“杀光”，好。。。于是杀了越多，黑产借此把一个个IP池子里的IP就污染了越多、于是你拦截的真实客户也越多。

如何妨反弹弧式的这类攻击

        还是那句话，下兵伐战、上兵伐谋。

        对于这种黑产，不可能不杀，但不能杀尽、不能杀狠了。那么怎么杀呢？

        大家玩过打地鼠没？无数个地鼠随机在一个个洞里冒出头来。一冒头你敲一下，它就缩下去了。于是你再看谁敢冒头？冒头了就打一下。

        对于这种黑产就得用打地鼠法，你敢冒头，我就打你。打你一下，我就“收锤子”。

        简单的来说就是：我要封，但又不能封了时间太长，而且还要封了准。

        WAF对抗CC和BOT攻击我在“家乐福618保卫战”中有过详尽描写，但是那一篇只是初级入门，今天这一篇讲的才是真正的攻防。

        我们光设置WAF的频次+拦截时间是一点没有用的而是需要建立层次化的防御。

层次化的防御对付流量型黑产才能打得准、收得快

        要点：

1. 识别这是一次CC或者是一个BOT；
2. 打一下就收手

        CC和BOT我上面列出过一张矩阵表，无非就是：

1. 高频次，这种很好识别，根据业务接口规则就能判断哪些是非正常访问，比如说验证码重试，一秒同一个IP试了100次；
2. 一开始看着很正常的请求突然一下升高搞你一下，有规律的在一些时间点突然升高频次，这种叫脉冲式；
3. 随机式，随机的无规律的突然请求频次升高；
4. 隐藏式，通过几道代理、甚至通过外网绕进来玩你；

        因此，如果你用发现一条建一条规则那就成了眉毛胡子一把抓了。而且往往一开始有些企业好不容易抓准了一个黑产，动不动就封个12小时、24小时。好家伙，这正好落进了黑产的“反弹弧”攻击的圈套中去。

        因此，我们会在WAF上建立四层防御机制。

        第一层叫：直接识别类，包括了：我是一个手机APP、小程序而你现在在用浏览器来访问，那么我对不起你了，然后我封一下。或者国内有一些好点的云，这些云可以告诉我们这些手机是来自于VPN、或者是代理，那么对不起了，镜外VPN和代理过来的全拦掉。再说了，大部分零售O2O不做国外业务的，你让蜂鸟、饿了吗这种快递接一单及时达然后从上海给你送到奥大利亚去？ 怎么可能！

        另三层如下图所示。

 我们除去一些云上WAF自带识别请求特性后我们把其它所有的CC和BOT都可以归为：

• 爆击型
• 高频次持续型
• 持久但频次很低即耐久型

        一共有这么三类，对于这三类主要是最后一类，特别难识别，但是别急，如果是人的访问行为他的行为是离散的、随机的。

        而如果是机访，那么它再怎么打散它的行为也具有规律性，这个规律性用的就是AI鉴别，通过AI不断学习一段时间后，识别出这种耐久型频次又很低如：最多一秒中来请求个1次、2次的请求这一类的识别准确率达能到97%以上。

        然后对于所有的这些拦截，我们的拦截时间会非常的短。最短的话只会拦5分钟，最长不会超过10分钟。

        因为当黑产的IP如果被你的企业所拦截后，那么他会作的事是马上把当前的IP“还”掉，再换“新的IP”来攻击你。

        从IP被还回IP池到这个IP转到相应的用户手里差不多要有1-3分钟时间差不等。这样拦就起到了很好的：你敢冒头我就打你，打完你我就收锤子的效果了。

        以下是超过10分钟拦截会有一定误杀的原理解释示意图。因此拦截的时间不能太久

         这就叫打地鼠式防御。

一味的打还是太“生硬”了我们希望有更多的“柔性”手法

        我们通过建立了层次化的防御、打一下就收手，一度取得了相当好的效果。但是我碰到过几次黑产就和你杠上了，因为它手里IP实在是太多，差不多一小时打掉20万个IP它又换了20万个IP，无时不刻每秒钟和你“耗”。

        此时你就算封了时间再短、收手了越快，但还是会有个至少5分钟的时间差。如果黑产手里IP太多了，那么一时间大量污染IP基站里的IP时，还是会有一定比例造成对真实用户的误杀。这个误杀率挺高的，有10%以上呢。这对企业的业务是造成不小的影响的。

        因此我们就在想，如果可以打得准、打得快、更不要伤害到真实用户呢？

        于是，有一种手法就产生了。它叫“温柔的杀戮”。我把它称为“这个杀手不太冷”。

        我们使用了图形验证码去和WAF结合。

        如：

        再如：

        但是我之前说过，现代化的黑客的水平是你一整个集团公司里所有的IT的人的脑子加一起都比不过的智商。

        它们会使用：图形自动识别、用AI算法来点击文字、用AI识图来去掉背景、水印并识别数字。

        就拿第一个滑块来说，你们知道我们碰到过的有一次黑产有多牛逼吧？

        这玩意叫“手机墙”，我们曾经报案然后公安抓过一波黑产给我们回传了黑产的设施。他们手里有几堵、利害点的有几十个窝点、每个窝点10几堵这样的手机墙。

        然后每个窝点有一台中控PC，这个PC上会在滑块唤起后它识别到过滑块的有效时间，再通过AI算法+计算机图形学、模拟鼠标动作控制着手机墙上的每一个手机，统一的在一个时间里“滑”一下滑块。好。。。几千上万的分布在全国各地的设备于是乎在同一秒过了你家的滑块然后造成了并发、流量、顺便薅走你家的券。

        因此，光有这些验证码哪怕你做了再花哨、再复杂也是没有用的。关键的在于这个让用户“滑”一下的动作对黑产来说和做1+1=几的简单程度一样。因此我们要解决的是不仅仅只是表面上的验证一下这个是人还是机，因为现在的AI技术已经让“机”比人还像人了。所以我们核心问题是要解决这么两个点：

1. 通过滑块类要验证这个动作延缓一下用户的并发，把瞬时并发打散一些以便于系统承受得住；
2. 在滑块内埋入一个精准识别的东西，即：识别操作者是人还是机

        在用户设备上滑块被唤起前我们其实是使用了一个SDK的，这个SDK会判断当前用户的手上正在操作的设备：

1. 有没有CPU
2. 有没有蓝牙
3. 有没有模块特征为市面己知模拟器
4. 有没有CCMOS

        我只列出几点，实际上我们一共列出了有10多项，进行综合判断然后判断用户的当前操作到底是人还是机。

        当然，这些特征不是一成不变的。每过一段时间黑产也会升级他们的模拟设备，因此我们的特征库即SDK也是定期进行升级的。

        当这个手段用上后，我们就把原来的“拦截”大都改成了弹滑块，在弹滑块时如果过了滑块操作还不算再要判断这个操作是人还是机。

        如果是机，就再弹滑块，过了滑块再验证是人还是机。

        反反复复，我们把它称作“逗你玩”。

        然后我们发觉，这个误拦截率一下就降低了很多，从原先有10%以上的真实用户受到误拦截一下变成了只有0.1%左右的真实客户会受影响，其表现就是偶尔一个月里会有2-3个客户被弹了滑块。而此时因为真实操作者是人，那么他去滑一下这个滑块，对体验的影响也是很小的。

        于是通过这个手段我们做到了精准打地鼠，因此它不是“生硬”的“杀”而是温柔的杀戮就是这个道理。

移动端设备内APP应用加固的重要性

        温柔的杀戮上线后一个月后，又来了一件事，这件事把我鼻子都给气的冒了烟。是什么样的事呢？就是黑产通过反编译（没错，你没看错，IOS、ANDROID都可以被反编译）知道了我们的特征库规则，因此黑产仅仅在一个月内就写了一套“反制”我们特征库的攻击规则。

        你们说这黑产牛逼不牛逼，不过那次我们是真的被全国最大的黑产（来自内部的消息）给盯上了。这太恶心了。

        对于这种属于在早期我对付黑产时经验不足，其实后来一些大厂都这么干。那就是你的手机端应用包括小程序都可以去做“混淆”和加固的。联系国内的三大云厂商或者百度安全、绿盟一类的厂商都有这种服务，他们把你的应用加固后的加密了的应用还给你你再去上架到APP市场或者是上架到小程序里，对性能的影响不会超过3%。所以一旦当混淆或者加固后就算有人反编译都看不了你前端应用的代码。此时我们的特征库在加固后又做了一次规则上的改变，才稳住了阵脚。

        所以以上图形验证码+人机识别+加固，总结一下我画了以下这么一张总结性的图

        这就叫“人机对抗”，很多企业，大约达90%的零售O2O企业竟然不知道“对抗”到底是怎么打法的。因此这才导致了眉毛胡子一把抓、东拼西凑乱打一通。最后效果没有达到还损害了真实用户的使用体验，就是不具备这个体系化对抗的手法。

        嘿嘿嘿！

        打得利害吧？打呀，继续打，下面继续再来。

抵御薅羊毛

        顺着以上温柔的杀戮，我们继续可以把此种方案用到我们的抵御羊毛党的战法上。

羊毛党经常干的是抢券

        遇有活动周、活动月，零售商们往往会发券。一发券就被秒光。一发券就被秒光。让零售商们无不头大痛苦。

        如果我们仅仅有WAF一类的设备结合着温柔的杀戮，我们充其量可以保护我们的系统、除去那些非必要的流量来影响我们的应用。但根本没办法抵御羊毛党的“攻击”的。

        因为羊毛党是黑产中最利害的，如果说用流量、抢跑道来攻击你的算是困难防御模式，那么羊毛党简直就是黑产防御里的“僵尸”模式。

        你网站不是发券吗？券也不可能发很多的吧？我算你一天发30万张满199减50的券，我就用30万个IP，排着队、卡着点、低频次来把你的券给秒了。

        羊毛党更像寄生虫，它不会一下搞死“宿主”，因为一下搞死了你他没有长远的利益，但是他会慢慢“让你失血”。

        等到他“肥”了，你也就死了。

        因此对付羊毛党大都企业一开始也都只想到了WAF，或者干脆不分三七二十一，只要你点“抢券”就让你输一个验证码。

        此时如果你碰到了“手机墙+统一滑块控制过验证”这种，你连被薅了都查觉不到。当发觉了，有些企业又因为求胜心迫切使然就搞“一刀切”，来个硬杀伤，然后受伤害的其实是我们的真实用户。

        此时，我们仍然可以使用温柔的杀戮手法。

用手机号历史行为来识别羊毛党

        有一种东西叫“手机信用分”，大都数人可能不知道，我们的手机号码其实是有其在经历生命周期时的各种行为被一些运营厂商“打分”的一种机制。比如说：网安那、或者电信那或者如：微信、QQ。特别是微信由于它拥于几乎全国手机号一大半的使用者在注册使用，因此这些第三方都会对用户的手机号曾经参与过什么不好的事、是否手机被root、是否手机里有恶意进程、是否曾经参加过或者被标注过“羊毛党”甚至这个手机号的机主已经“过世”了的这些行为来进行进行打分。

        这个分值从0-4分不等 。

• 0分-为无任何不良记录优质手机号码；
• 1分-号码所处手机环境有异常或者被Root过；
• 2分-号码曾参与过一些不良行为；
• 3分-号码为小号、环境中有木马、手机号有过严重违纪记录；
• 4分-黑产，严重有问题号码或者号码已经无主；

        我们在领券时就会连接上这种第三方手机号引擎然后来取得正在发生相应的业务行为的手机号的分值，然后通过分值做相应的领券行为判断。

通过手机号的行为分值判断业务行为中的博弈学

        有了手机号分数段值，的确给我们判断黑产行为带来了极大的易处，但它同时也存在一个巨大的引患。

        我们先来看把前面WAF、人机对抗和手机号的行为分值结合起来的业务防护是怎么样的

        看上去似乎很完美。于是我们开始设计我们的领券场景了：

1. 对于0-1分的手机，用户在领券时畅通无阻；
2. 对于2分的手机，我们弹滑块；
3. 对于3-4分手手机，我们在其领券时会告诉他“亲，领券活动已经结束了哦”；

      上线两天后，原来从发出券只用了2秒就会被领光的势头得到了抑制，然而第三天这样的事又来了。

        这是因为黑产他也在分析你公司应用的“行为”，当他发觉3-4分的手机号全部碰到了“亲，领券活动已经结束了哦”后，于是他就全部使用2分分值的手机来进行“中央PC端控制数堵手机墙”统一划各个手机上的滑块来领券。

        然后我们开始值入人机对抗，发觉2分的手机行为也被阻止了，而我们的券依旧在被秒光。

        这就奇芭了，于是我们坐了下来好好开始分析我们的一些用户行为，我们发觉黑产玩了这么一手。

        他们干了什么你们知道不？

        黑产这一次干脆放弃了所有的2分手机，把精力全部集中在1分的手机上，并且这些1分的手机号都是早在1-2年前就已经预先“养”在各个零售、社交类网站里的，这种小号非常有意思，它们达数以百万计，平时不会做下单或者几乎很少下单。但是这些号也会被中央控制端的AI脚本控制着频频进行着一些搜索、登录、登出、浏览商品等行为。在百万、千万级会员的系统里这些小号在平时看起来一切正常，它的分值也始终在1分左右。它们是属于黑产的“后备役”部队，就是在势在必行必须搞定你家的所有优惠券对抗中派上用场的。因此这种号我们才会管它们叫小号。

        当我们发觉了这些现象后我们开始重新审视我们的业务规则，我们发觉我们的业务规则也如我们一开始在WAF上一样生硬。

        要么不给券（杀）、要么给券（放)。只能退不进。

        因此当业务说如果我们在领券时只放0分优质手机来领券，而对只要不是0分的手机全“杀”即不给领券时，我们拉了一下报表

        如果我们把1分的手机全部杀掉了，是可以杀干净羊毛党的，可是1分手机的领券在我们整个领券人群的占比>60%，这也就意味着我们在杀干净羊毛党时，也同时把真实的用户给杀了。

        当我们分析得到这样的一个事实时，我们马上做出了策略上的调整。

        这个策略就是之前WAF上使用的“温柔的杀戮”，即我们在业务上也要有“温柔的杀戮”。

        于是我们开始如此设计我们的业务规则

        这是一道全闭环的对抗黑产中的羊毛党的打法。它的核心在于：

1. 业务上在这种每天放30万个券，抢光为止的话术调整为“不一定抢到，可以有机会获取面额为5-199元券”；
2. 然后在过了人机对抗后，根据用户在领券时的分值进行判断，如果你>=1分的话我们只会给到用户最多15元的券而不是那种大额券。同时对于2分的客户我们只会给他5元或者没有里面进行随机领券；
3. 结合实时数据清洗技术能力。对领券的用户不断的进行事后清洗，清洗规则会根据：就算你现在的手机行为分值是1分但如果你是注册和活跃在比如说：云南的人，但就今天跑到上海来领券，我们也会因此不给这个手机发券。或者说一个注了1年的手机但从未下单，今天突然跑来领券了那么我们只会给他一张5元券意思意思打发走。再或者一个拥有7个不同收货地址，3天内会出现在2-3个城市间来回领券的用户，就算他是1分那么经过这样的业务规则清洗后他也会变成2分或者更低分，然后下场就是没有券或者只有5元这种小额券用来打发人的；

        以上就是结合业务规则的温柔的杀戮。它起到的效果相当的有效，在这样的闭环逻辑上线后我们再连续对抗了7天，黑产逐步消失了。然后就再也没有来薅过我们。

        为什么呢？

        你这样想一个例子：假设你在小学，老是被一个校园恶霸在下课时追着打。当有一天你回身突然对着这个恶霸的鼻子给了他一拳把他打出了鼻血，此时这个恶霸就会衡量下次再来打你时要付出的代价。当这个代价累积到一定的程度后，他就会放弃了你。这就是我说的与黑产对抗时的博弈学。

        因此和黑产对抗绝对不可以求“杀尽”，而是要求“提高或者增加黑产来搞你付出的代价和成本”。

来到应用逻辑层的对抗

Redis布隆的使用

        当流量层防护住了后，依旧是有更聪明的流量漏过我们的层层防御的。此时当流量来到了我们的应用层通常来说就是落到了K8S集群里了，此时还是会因为流量过大系统受不住。因此在此时你依旧需要“削流量”。

        而使用的手法依旧是“温柔的杀戮”。在此我们用的是Redis Bloom。

        我们来看几个例子：

1. 一个网站有800万会员，300个TO C端Restful API接口。这300个TO C端的Restful接口里有50%接口要求必须登录后才能访问。那么没有登录的人或者不是这个系统内的会员如：伪造的手机号或者我们说是伪造的userid来访问这些接口，你有必要让他们访问吗？因此此时我们就可以把所有的会员和需要登录才能访问的那些个Restful API接口装入Redis。然后没有登录的用户或者是伪造登录的用户来访问这些接口那么你可以直接拦住，或者你也可以在此设一道人机对抗让他们反复的弹验证码去“逗你玩”；
2. 每个企业做优惠券、活动、大促都有一个内部活动ID。如果TO C端的请求某个活动带的ID都不是你系统中存在的ID，你也可以完全把它们拦住。而你要做的也是把系统中几万个ID都Load进布隆；
3. 每个系统的商品ID都有其“特殊含议”，此时如果有一个查询请求带着一个你系统中都不存在的商品ID过来，你就可以把它拦住。而你要做的就是把所有的商品*门店的Mapping关系Load进你的Redis布隆中去来做防御。这招同样适合于订单查询，我们遇到过黑产猜订单ID搞垮过我们的Redis和Mongo；

        这样的例子还可以举出50多种来，关键在于你需要精细化梳理本公司的业务和应用规则。

根据用户历史行为洗数据不断的发现系统中养的小号

        前面我们提到过，每家人的系统中都有小号。这些小号有的养了有几年有的至少也有半年之久。这些小号他们在第三方征信库里的手机行为分最低也有1分。那么你就信了这些小号了吗？

        请看以下几个清洗逻辑，我们使用相应的逻辑把这些小号洗完后给打上2分或者3分的标志，以及时把这些小号从我们的应用中自动“逼走”。

        前面提到过比如说一个住在广州的人收货在广州，30分钟前还在广州活跃的手机号突然跑到了北京来领券或者下单下到了他在北京的地址，你们觉得这种行为正常吗？或许一次还能说得过去但如果这样的事连续发生3次、5次呢？

        再譬如说一个人上一秒登录在上海、下一秒竟然去领广州的券且这个人从注册到现在1年里从未下过一单，这是什么样的行为呢？值不值得怀疑呢？

        因此我们在建立事前、事中机制的同时还要有着事后的清洗机制并伴随着“温柔的杀戮”的手法才能最终把黑产控制在一个可以接受的合理的阀值里而不是去一味的求杀尽，如果是杀尽这就意味着杀敌1000自损800，这也是我之前说到的“要学会和黑产共生”的终极意义所在。

除去流量攻击、羊毛党其它几个要你命的防御机制

        回到上面提到的除去流量攻击、羊毛党其它几个要你命的手法我们该怎么去打防御呢？

内容上的防护

        把你的一切可以评论、上传图片处接入云厂商的WAF、CDN的“鉴黄、鉴黑”机制。当发生涉及黄、反、暴时可以第一时间把不良内容抑制在“沙盒”里而不是直接公布或者事后已经公布在了internet上了再去删除，并同时有及时的系统报警通知机制。

        同时把这些接口做成随时可以关闭的机制。

遵循基本的Web编程规范

         目前大都国内企业包括甲方乙方都不重视这个OWASP TOP10。这块遵循了好75%以上的风险就可以被消除。

        因此请让以下两个手法作为例行任务贯穿在你们的公司运作的生命周期里吧：

1. 每年至少做两次代码安全扫描，扫描后的报告里的每一条请去修改；
2. 每年至少做两次渗透测试，渗透测试后的报告里的每一条请去修改；

硬件层、中间件层周期性升极、打补丁

        我曾经遇到过一些。。。银行系统竟然使用的还是TLS1.1协议，此处我真的不想多说什么了，去看看TLS1.3吧。虽然是内网系统，但这个梗太可怕了。

        如果你打补丁相对来说较勤，这从另一个方面也说明了你的系统的设计比较完善，不会因为打补丁造成的不可测的意外情况而中断你对外的业务运营，一般这样的系统都要至少有蓝绿发布、AB TESTING能力。周期性的补丁你也因此可以逃过一些史诗级别的灾难。

        比如说，我们经常升级和采纳云厂商给我们WAF推的补丁、同时在我们的流量端中间件、组件我们会对spring的小版本或者是如：nacos的小版本的更新去进行升级。

        而恰恰就是在有一次升级后的第二天，log4j史诗级漏洞爆发即：CVE-2021-44228。而我们的所有的对外运营业务因为我们有这个打补丁的习惯，因此因为我们的WAF层、中间件层及时卡断了JNDI这种非法请求，因此就算我们的log4j有问题也构不成严重的影响。其最直接的表现就是：

        当我的一些在大厂里的同学通宵了一周未在应用里打log4j补丁时，我们可以有一周的时间稳定的、逐步的按照批次和正常作息的去打我们的log4j补丁而不用担心任何“穿透”。

        当周未过后我们同学听到了log4j2.15.1还是有漏洞还要升2.16时，他们几乎是处于崩溃的边缘的。而这样的事我们都知道漏洞的升级计划竟然赶不上变化，最终这个补丁升级在一周内连续发生了3，4次，即：出来一个补丁，过48小时再告诉你这个补丁还有问题还需要再升，而我们这3次都没造成任何一小时加班，就是按步就班正常作息的升了第一次。再来一次就把一个全局pom里的version变一变就搞定了。

总结

        这篇到此基本已经覆盖了绝大部分和黑产对抗的攻防策略了。内容挺多，可是只要我们始终记住在面临对抗黑产时的那几句心法和深入领会了其要领就能做到临阵不乱、游刃有余。

        对抗黑产心法

        求“减损”不要“止损”，更谈不上“防损”！

        不要求打败，而是增加“黑产”的攻击成本！

        着眼于全局战役，而不要打“阵地战”！

        流量我要，权益你木有！