编辑推荐

网易数帆开源API网关与容器云项目，让云原生生产落地“多快好

网易汪源：统一负载与多云环境的“开放姿态”，才是云原生

网易数帆如何用 Kubernetes“原语”搞定云原生中间件

快手打新挤爆券商系统，网易数帆推出券商稳定性保障方案

探索智慧校园新模式，网易有数在教育行业的实践分享

金融行业大数据治理之路——数据模型篇

网易严选风控实践（中）-剑走偏锋，我们的搏击技法

达芬奇密码2018-08-02 11:34

网易严选风控团队成立了一个风控基础设施虚拟项目组，项目组的主要工作是构建一些能给风控业务带来巨大帮助的工具链，帮忙我们更精准的识别用户的异常。目前基础设施项目落地的服务主要包括了：严选APP可信ID服务，严选浏览器ID服务，严选虚拟机识别服务，IP反查服务，Nginx Canal Module；正在研发中的服务包括TMD-安全Nginx集群，用户页面行为跟踪等。在这篇分享中我简单为大家介绍其中几个小而有趣的项目

客户端技术

虚拟机识别服务

风控的一个重要议题就是人机识别，虚拟机是人机识别的一个重要指标；同时由于虚拟机的关键设备特征不持续（设备号，imei，mac地址等），也常常被灰产用户用于破解各种基于设备信息的识别模型。因此，准确的识别虚拟机对于风控系统而言非常关键。

严选风控的设备虚拟机识别包括两部分：APP端收集核心指标，服务端做出决策。

我们先说服务端决策。有些虚拟机的识别需要一些比较持续的指标，常见的比如非充电状态下的用电量，手机抖动频率等，往往需要根据6个小时，或者12个小时以上的数据才能做出准确的决策。因此虚拟机识别服务端有一个单独的模型运行在实时计算平台上。

当然其实，我们有更加简单直接的办法。严选APP开发同学研究发现ARM架构的CPU与普通虚拟机依赖的CPU对一些关键内存区域，以及一些机器指令的执行权限控制上有着比较明显的差异。这些CPU架构上的差异是很好的虚拟机特征。我们测试了市面上主流的各种模拟器和50多种安卓真机，识别正确率为100%，误判率为0%。

图1 感谢ARM同志

可信ID服务

用户的设备，特别是安卓设备，它的基础信息，比如mac地址，imei，序列号，蓝牙mac等等都可以通过接口层hook的方式来修改，从而导致依赖这些基础信息生成的设备序列号变的不可靠。灰产使用只要使用对应的工具对这些基础信息进行修改，那么他的设备就能在严选变成一个全新的设备，从而躲避各种风控的模型检测。因此，需要有一个唯一可信的ID来标识一个唯一的设备。有一些第三方公司，比如数盟等在出售可信ID服务。严选APP研发团队与风控团队一起对可信ID做了调研，觉得这个服务的研发成本比较低，技术门槛不高，需要投入的人力很少，因此决定自己研发。

跟虚拟机识别服务的做法类似，可信ID的识别依然是app收集核心数据，服务端生成可信ID。这么处理的优势比较明显：

1. 当识别算法出现误判时，能及时调整；而不需要app发布版本。

2. 当出现新的特征时，能及时加强算法，适应新的情况，而不需要app发布版本。

可信ID可以使用在很多不同的风控场景，除了常见的新用户下单，优惠券领取，积分获取等场景；还可以用于识别渠道刷量欺诈等情况。

浏览器技术

可信ID服务和虚拟机识别服务上线后，灰产们都比较郁闷，总不能不停的买新设备来刷严选吧——这样成本太高了。所以他们转战了战场，他们的异常行为集中在了iOS的某些版本（容易越狱），集中在了WAP页面和PC页面，这种没有唯一ID标识的场景。我们的数据监控也证实了这一点。这都我们来说是好事，坏人的特征越集中，越容易被我们掌控。

我们也把战场延续到了没有唯一ID环境的浏览器中。浏览器没有唯一特征，用户只要清空Cookie，买一个新帐号，买一个新手机号，我们风控就很难发现原因他是一个我们熟识的坏人了。

我们的做法也很简单，为浏览器分配一个唯一ID。这个ID可以不必跟浏览器具体的指纹（比如插件列表，系统信息等等）绑定，它只需要确保唯一就行。我们工作的重点是怎么想办法把这个服务器生成的唯一ID在浏览器端存储下来。狡兔三窟，浏览器有很多办法让我们把ID默默的存储下来，比如Cookie，比如LocalStorage，再比如，浏览器会对浏览过的一些图片做个缓存等等。相关细节就不详述了。

当然，所有的策略都是可以被破解的，构建永不被破的防线也不是我们风控系统的工作目标，我们的核心目标是提高他们的作恶成本。让他们知难而退。

有黑客在一些羊毛群里提供破解严选风控，代替下单的服务。这个服务的价格从5毛一单，到1块一单，再到2块一单，到2.5快一单，成本不断的在提高，甚至部分黑客已经不提供这种服务了，因为他每接一单不光没得赚，还可能引起亏损——一旦风控系统认为他的行为特别恶劣，对应帐号里的高价值券可能会被冻结。其实这也是风控的成果所在。

有一些论文从其他方向提供了解决浏览器没有唯一ID的办法：为每一个用户构建单独的行为模型，无论是灰产，还是正常用户，还是机器人，他的行为特征都是比较明确的，明确到可以使用一个单独的模型来描述。我们可以根据这个模型来标识唯一性。当然这个计算成本比较高，风控的模型研发同学也在做一些这方面的尝试。

业务护城河

这里提到的护城河跟前文提到的护城河-城墙模型是两个不同的概念。严选风控在跟灰产斗争的过程中，每次赢得胜利，都会引来黑客疯狂的报复——接口层面的攻击。在双十一大促期间，黑客的报复到了丧心病狂的地步：一天有上亿次尝试下单行为。因此，严选风控系统与严选主站研发团队需要共同构建业务层面的护城河，来面对这种报复行为。

我们的严选业务防护体系架构上也很简单：入口Nginx分流，保护业务tomcat；业务层tomcat频控，保护后端基础服务。

Canal & Safe Nginx Cluster

Canal是一个风控研发团队提供的Nginx模块，部署在入口Nginx服务中，针对用户的一些特征，比如IP，Username等，对特定的接口做频控，正常情况下，用户的访问能通过Canal的频控审查，直接转发到业务tomcat进行处理。当请求被标识为可疑时，Canal模块会将其ProxyPass到一个Safe Nginx Cluster. 这个风控的Nginx集群会对用户请求做更细致的审查，确认有问题时会直接拒绝这个请求，通过审查后，继续按原有流程转发到业务层tomcat。目标是尽量提前丢弃明确有问题的请求，尽量降低tomcat层的无差别频控，避免遭受攻击时，影响正常用户使用严选。当请求流转到业务tomcat时，依然会按原先的风控流程，重新做审核。