万达电商主任工程师林鹏 出席IDC服务大会并为当天的安全运维分论坛做《安全电商之路》主题演讲。

　　万达电商主任工程师 林鹏

　　以下是演讲实录：

　　基本上做安全的都可能会经历过这三个阶段，我们也是从这三个阶段慢慢的爬过来。第一个阶段是背锅侠，说到背锅，做安全或者做运维的都会经历过这样的情况。之前我们发现了一个异常IP，我们发现这个IP的行为有问题，我们就干掉了，后来发现是自己的IP。当时也没有经过报备审核，我们发现它有问题就干掉。当然这个锅不是我们扣的，所以在做安全的时候，不一定需要我们去做事，可能更要会说这个事，还要发现锅甚至是甩锅的能力，不能老老实实把这个锅背上去。我相信一般做安全和运维的同学都是比较实干的，有的时候真的是好心办了坏事，这也是很正常的。包括像双十一的时候，可能是一个没有经过审核的变更，运维同学给上线，这个没有遵守一些制度去做，本来是一个好心但是差点酿成大祸。

　　第二个救火队，一个大公司招了安全人才，公司肯定是发展到一定规模了，有些制度、流程都已经固化掉，说白了有些坑已经在那儿，就需要招一些安全人把这些坑发展并解决掉，这样才可以把这个东西进一步推行下去。推行的好，把一些坑弥补了，安全部门在这个公司有一定话语权，这个时候我们就可以做一些规则，约定大家怎么干这个事比较好，甚至像之前说的大的SDL流程，我相信这些会比较好。

　　安全的本职行业就是挖一个漏洞，公司把你招来，除了把流程制度做好，还希望把漏洞进行梳理。我们这边也有漏洞挖掘的文档或者是思路。其实主要是两个方向，第一个方向就是主动发现的方式，主动发现的方式就不用说了，可以通过各个渠道，如果你有能力你去建一个SRC，比如像京东建立一个SRC的环境。如果没有能力可以找两个人，或者找外包团队帮你挖一些漏洞。第二被动发现是这样的，我们这块自己开发了一个扫描器，好多公司也利用了这样的一种被动扫描的原理，有两种方式，第一种方式就是把所有的漏洞挖掘的方式放到测试环节，这个东西有一个主动扫描和被动扫描，主动扫描是用扫描器扫的，被动扫描，我们会给测试人员在产品新上线的时候做测试。这样就把整个的安全漏洞扫描环节都打到测试里，只要通过扫描器扫到新上线的系统，新上线一个系统，测试肯定要点一些新的功能，我们把新的功能收集起来，我们就可以把这个漏洞进行自动地扫描。第二个方式就是把一些测试的服务器镜像做出来，再放到扫描器里，这样就完成了被动的扫描。就可以有效地把这个环节压缩到给测试团队，而不是给安全人员做。现在也提供了类似这样的服务，告诉这个测试人员，或者想上线的开发，自己去用，现象效果也是比较好的。

　　既然发现了漏洞一定要有漏洞处理的流程。漏洞处理的方式，我们这边包括有一些排名，主要是流程，跟这些漏洞的人怎么去打交道，我们这边打交道的方式，我们是找了两个妹子，跟一些开发的同学，或者跟运维的同学打交道。据反应，妹子跟开发人员沟通效果好一些。当然主要不是看排名，还是要看对高级漏洞、初级漏洞定义的方式，怎么定性，什么时候处理。这个流程包括了漏洞完整的闭环，这个漏洞处理流程比较好，大部分的公司都是大同小异。

　　告警可视化，我们也试着做了一点。这是一个早期的告警可视化的东西，大家可以看到屏幕上的一些点，其实意义不是特别的大，尤其是在误报，看到这个点满天飞，除了适合拍一些电视，没有什么好的效果。有的时候也可以从视觉上看到哪个地方的攻击者比较多，只能起到感知的作用。我们也做了一点关于攻击发现的东西，大家可以看一下告警可视化，首先我们这边基于实时数据处理的告警分析，说白了就是我们把流量抓下来，把里边的HDP五重新组了包，然后把关键字处理一下，发现有关键词，SDOM可以实时处理，做一个关键字匹配，从整个的URL里面可以看到设置一些关键字，这个关键字可以做不同维度的告警，这些告警可以表现出来当前的供给情况，这个数字实际意义对比这个图要好用的多。可视化的东西就是去看的。

　　关于实时响应应急，主要还是该什么时候做什么方案，这需要安全人员自己靠经验去管理，首先要监控到位，知道这些人有什么动机，还要及时地响应，当然这里边最重要的一点就是沟通，沟通还有一个事前的预案，事前的预案包括你需要跟一些业务部门，或者根据需要，跟一些运维的人打好招呼。比如像我们之前发现了一个撞户的事情，这样的话我们立刻发现了问题在哪儿，我们可以直接地启用事先预案，把该去掉的东西去掉。比如之前有一个地方没有验证码，登录这个环节有问题，我们按照预案直接把这个网站关掉，如果说没有事先的预案，没有跟其他部门打招呼，你想想一封邮件过去，两天之后才会有解决方案，两天之后的撞户情况是什么就不好说了。

　　前面讲了基础安全的东西，我再给大家分享一下业务安全。首先说双十一的事情，分享两个小的数据。双十一我们监测到刷单的笔数在1.5亿次+，我们的黑名单用户在双十一期间增加了250万左右，这个数据量是非常的恐怖。如果有对业务安全感兴趣也可以算一下，我们是一千万的请求，大概可以看到屏幕上日志一件万，大家心里发毛，其实里边真正的用户数也就一千个手机，向一千个用户左右发出的请求在一千万左右，而这是一个比例。

　　大家可以看一下这是某个业务的UA情况，大家可以明显地看出来，IP可能是相同的。大家看这个UA是完全一样的，这完全是通过一些统计学的方法就可以把刷单的人给弄出来。包括飞凡的零花钱数量，包括我们在论坛上抓的对我们独立的消息，我们会分析他们是怎么做的，我们会发现我们的问题在哪儿，这也是一个。还有一个是靠情报，我们这边没有问题，我们只靠自己的网站抓流量。

　　双十一过来之后的一些经验可以分享。首先就是风控的介入时间和接入点问题，大家都应该知道，其实在风险控制这一块，也不能叫风险控制，比如说刷单，应该是风控拿的数据越全，接入点越早越好，这个时候就会有一个问题，风控肯定要介入，包括风控之后默认的策略，风控系统一上去之后会使整体的性能有所下降，如果有所下降，在高频发的时候，有些业务是需要一些规则。我们原来默认的规则是超时就放掉，可以想象一下，即使是万分之一的中奖率，肯定也会比一个普通的用户概率要高，这个时候一定要跟业务部门来确定风控。如果风控超时，除非是必得的奖项，如果不是必得的奖项，一定要建议这边采用的方式是风控超时返回不中将的会比较好一些。

　　第二个是有没有新的注册渠道，因为刷单的人注册完一批帐号之后，这批帐号就废掉了，他们就会反复地去注册新的帐号来去做。我们可以默认一条规则，可以基本上认为刷单的这帮人的手机号是无限注册的，如果有新的注册渠道，没有加拦截，验证码可以破戒，短期验证码对刷单的人来说不是什么问题，如果你连一个图形验证码都没有，尤其是那种，比如说有一个活动默认登录即是注册，他们一定会找这种渠道去进行批量注册，批量注册完了之后再反过来刷一些单，这个时候一定要卡住新注册渠道。

　　第三个是有没有冻结的机制，大家在做活动的时候一定要有这样的想法，像我们之前吃了点亏，如果发现我们的零花钱被刷只能被刷，一定要想到有没有什么地方可以把零花钱和用户获利的地方冻结住，这样会为公司挽回很大的损失。包括有积分也是一样，这个积分可以冻结，当然你也可以想办法扣除，扣除的话就要想到，风控测别不准一刀见血，这块冻结是比较好的办法。还有一些带血的是一些公司做活动，大家会直接使用爱奇艺的会员卡或者京东的会员卡，这个时候你会发现如果你的风控没有做拦截，刷单的人会直接把这里边的卡立马套现出来，变成自己的会员。如果你反应过来去找爱奇艺的人说这批卡能不能冻结，爱奇艺的人也是没有办法的，或者他们人员直接跟我们说，这批卡已经被人家使用了，那就没有办法了。如果说可以设置一个合理的兑换流程，内外码的流程，这样就会好很多。他们首先拿到的是公司内部码，他们需要进行一次批量的转换，你就可以卡住他们，让他们做不了更多的东西。

　　活动前的一些安全验证，这块回到了漏洞发觉这块，有没有一些地方明显设置上的逻辑权限，有明显的漏洞，这些需要安全工作做检测，看看有没有什么样的问题。

　　接下来后续还有几个，好多人喜欢用前端做验证，包括像我们之前也有些作为防刷单，防作弊的人，我们喜欢用的一些设备指南之类的东西。我们吃的一个亏，前端验证的设备指南，设备指南出现了问题，前端去改这个代码会非常的费劲，慢的话需要三个小时到一天，快的话需要一个小时。因为我们主要还是以APP为主，还需要去发版、审核，这样造成的影响会非常大，如果大家控制安全，尽量不要在前端做特别大的验证，一切的东西都放在后端，放到自己的服务端会比较好一些，而且它是可控的。可以考虑到业务延续性的问题，包括你的预案怎么处理，如果说每一个环节出现了挂机怎么做降级的处理，这些都要考虑。

　　后边也是我们这边的一个案例，好多同学在运维的时候，会做一些关键字的匹配，关键字的匹配，可能里边会有空格，这个时候由于不同的编码方式，有的时候里边的URL的空格就被转成了%20。

　　还有一个活动后期的帐号问题，我们这边也吃了点小亏，我们发现我们确实给用户发了爱奇艺的奖券，也采取了兑换码的流程，但是活动刚一结束，黑客觉得这帮用户的验证码已经兑的差不多了，他们就开始批量地进行撞户，我们发现有批量撞户的事，这是我们当时没有考虑到的情况，好在我们发现比较及时，直接把这个问题发现了，所以大家一定要考虑到这个周期，活动周期完事了，后期的帐号保护问题也需要关注。大型活动完后一定会有一些账户的人来试图撞那些东西，他们来撞户一定是有利益可图，否则他们不会用进行撞户。

　　还有设立门槛，比如有一个活动A，这个活动A可以设立一个门槛B，必须有一个前置的活动，他首先要经过活动B才能参加到活动A，这样的话，可以在B上做一些防范，防范掉刷单的用户。我们可以把这个环节设置到任何一个地方，比如登录环节、注册环节、活动时间的页面，既然是机器批量来，一定会有批量的特征，你在B上做验证发现这个特征，就会有效地环节A被刷单的风险，这是我们这边总结比较好的经验，当然设立门槛一定要跟前期的业务沟通。

　　还有一个就是黑名单机制，好多时候做活动会有一些黑名单的用户，当然这些黑名单的用户有的时候居然敢挂电话，想进行出黑的处理，这时候也不得不佩服这帮人的胆量比较高，他们甚至会投诉到一些工商局，这样会给安全的人员造成很大的压力，无论谁接黑名单这个活，首先是前期的一个便利，后期的维护是很大的工作量。后来我们改了说辞，我们也不说你的帐号是黑名单，我们就说你的帐号有异常行为需要你验证，我们以考虑用户帐号安全的出发点来进行说明，善意的用户会觉得很配合，如果自己都知道自己有问题他一定不敢扎这个刺，当我们改变了说辞之后，我们不说你是黑名单用户，我们只说你有问题，我们的压力就会少了很多，讲了这么多，安全行业的同学确实很不容易。