【风控要略】互联网风控业务-反欺诈之路

序

2021大部分时间都沉浸在工作和学习任务的忙碌之中，很少有机会能够坐下来静静地写一篇博文，这次借着年终的一丝丝喘息机会，给大家介绍下博主最近在主要学习的“风控”相关的知识。我会从风控的起源来龙去脉，讲到黑产是通过什么样的方式对业务形成威胁，再简单介绍一些当前的风控业务流程和技术。

本文最大的知识来源就是《风控要略》这本书了，大家有兴趣的也可以自己买上一本读一读。

一、什么是风控

当前互联网安全产业大致可以分为基础安全和业务安全两个领域，基础安全，类似代码漏洞、提权、加密等领域近些年一直为人们所谈论，这一块对大家来说已经不再陌生；尤其是最近的log4j事件，它所带来的安全隐患之大，对我们开发同学的安全意识的加强也是可以预见的。

而我们今天要讨论的，是业务安全这个细分领域——它还是一个相对年轻的领域。随着互联网业务的爆炸式发展，黑产团伙开始从黑客一样的“攻击渗透系统获利”，逐渐演变成规模比较庞大，分工非常明确的黑色产业链。离我们最近的例子也有很多，例如：

京东自营店铺在设置打折活动时操作失误，将打折活动与满减活动的条件设置重合，原价200多元的产品成了免费的，这让京东面临着巨大的损失，初步预计直接损失超过7000万！

“7日晚上，很多‘薅羊毛群’都在发车，让去京东捡漏，我也参与了，并成功用低价买到了一台美的烤箱。”1月初时，她曾在京东APP上领取了小家电200、300元无门槛优惠券，1月7日晚听说京东有年货节促销活动后，她便打开京东APP尝试下单。

当晚8时50分，吴某在美的京东自营官方旗舰店内选中一款38升容量的家用多功能电烤箱，并将其添加至购物车。“电烤箱的型号是MG38CB-AA，原价为249元，但付款的时候我使用了200元优惠券，显示实际支付价格为49元。”考虑到最终价格比较划算，吴某便立即支付49元，成功下单。

我们在谈论业务安全领域-风控的时候，我们大抵都是在谈的类似于上面的案例，即：如何应对业务安全风险。

我们使用常见的风控场景继续举例：

1、注册和登录场景的风控：如何对抗机器人自动注册虚假账号，自动刷单，刷赞刷关注等行为。

2、营销活动的风控：活动发放的红包、游戏点券、或者其他的什么奖励如何才能够不被批量“薅羊毛”。

3、广告营销保护：业务需要往往会大量购买点击广告，如何识别这些点击是有效的真人点击广告而不是机器人的行为？

4、爬虫问题

......等等,风控的场景在互联网，现在阶段是必不可少的存在，可以说每一家具有一定规模的公司都一定会有一个风控团队。

二、黑产的情况

我们可以知道的是，目前黑产的日交易额可高达数亿，但这可能仅仅是冰山一角，而那些冰山下的更为复杂隐蔽、更加难以识别的黑产的整体规模难以估测，其未知的能力更让人感到恐惧。

黑产现如今已经有了十分成熟的商业运作模式，产业链复杂、隐蔽、高效，是一个紧密结合的复杂链条。

黑产的基本信息

在黑产的产业链的上游是一个基础性的环节，承担着挖掘、制作生产和供应的职责，支持着众多类型的网络黑产，为其提供重要资料。其中包括：

1、开发者-为黑产团伙开发群控工具、管理后台等工具

2、手机卡商-为黑产团伙批量提供验证码手机、注册手机、流量卡等

3、打码、听码平台

4、各种周边工具

而在中间的，就是各种用于突破人机识别、验证码、真机模拟的工具了：

上图就是一个可以自动化控制的群控平台，它通过系统自动化控制集成技术，把多个手机操作界面直接映射到电脑显示器，实现由一台电脑来控制几十台甚至上百台手机的效果。以某社交平台群控为例，它是在群控体系基础上，针对其定制化、批量模仿正常个人用户操作的软硬件集成体系。它以群控体系+各种批量模仿脚本的方法，完成批量操作，其所有任务执行都是同时进行的。你面对的可能不是自动化脚本执行，而是一台又一台的真实机器，只是站在几百个机器面前的，可能只是一堆数据连接线而已。

这些由黑产团伙开发使用的群控，制造了互联网的虚假流量，是流量黑产王国里的重要一环。

在不断升级的黑产打击猫鼠游戏中，群控已经出现了第五代，黑产开始转向技术手段更先进、隐蔽性更强的新型云控系统。

黑产的工具链条

1、虚假号码

“虚假号码”这个词，目前还没有被大多数人所接受，而关于虚假号码的来源、危害、各种特性，外界也了解的很少，更不要提如何针对虚假号码进行风险防控了。

在人们的朴素观念中总会有这么一个念头：“运营商出售的卡必然是实名的，为什么会有这么多的假号码呢？难道国家就不管管？”。

2、虚假号码的来源

在互联网黑色产业链条中源源不断地有人给黑产提供大量可用的手机号。这些手机号几乎成了所有互联网欺诈活动的根源，我们统一把它称之为“虚假号码”，这并不意味着这些号码是假的，它们很有可能是真实的、被出售的运营商内部号码。

虚拟号码被对接到接码平台、提供短信验证码代收等服务，进一步被黑产所利用。在整个黑色产业链中，手机卡商处于产业链上游并且是整个产业链的非常关键的节点。

在2017年以前，接码平台会从卡商（运营商）手上大量收购手机卡，不过目前这些都已经被公安机关依法取缔。在这之后，很多就是我们所熟悉的那几个种类了。

* 流量卡

比如腾讯的“大王卡”，各家互联网公司推出的联名流量卡，量大且便宜，很容易被黑产所利用

* 物联网卡

这类卡片一般是应用在公共服务上的，例如共享单车，它们的互联网接入方式是由运营商提供大量的sim卡片，然后将它们接入可移动的网络设备，从而达到实时接入互联网的目的。这类卡片有些并不能像正常的卡一样能够接打电话或发送短信，但是在特殊情况下，它们还是可以实现接打电话或发送短信的。

* 手机劫持

在手机中植入木马，通过技术手段屏蔽被拦截的短信上报到在线平台。——这类手机卡看起来就和真人一般无二，一般出现在一些老年机、儿童机上，黑产团伙预先在售价低廉的这些机器上植入自己的系统，直接在系统层面拦截收到的验证码短信并上报，从而做到真实的使用人完全没有感知的情况下劫持手机号和身份。

3、猫池

“猫池”定义：

英文名 Modem Pool。 Modem，即调制解调器，普通的家用宽带拨号所使用的"猫"也是一种modem。字面翻译过来，就是猫池。

Modem中一般封装了拨号协议，宽带所使用的Modem，封装的是PPPOE协议。猫池所使用的Modem，封装的是GSM、CDMA或其他的一些通讯协议。两种Modem都可以通过AT指令集来进行控制。

这是目前国内比较普遍的一种猫池，16个卡槽，每个卡槽，是一个GSM模块。设备通过USB和PC连接，挂载为一个串口设备。通过软件或驱动程序，向Modem发送AT指令，来完成特定的操作。

比如：电话呼叫13xxxxxxxx 转换为指令是： ATD+13xxxxxxxx\r\n

基于这样的批量命令式技术，黑产团伙开发了一系列自动控制软件：

通过软件，这些人可以实现批量通话、批量短信等常见的操作。

与黑产的对抗

在业务安全领域中，与黑产的对抗是永恒的话题，而且很大程度上是资源和技术的对抗。新的欺诈手段千奇百怪，它趋势互联网平台和风控厂商不断的更新迭代更先进的防控体系，甚至现在的大型厂家通过大数据和人工智能的手段动态的去计算指标生成标签等手段来防御，这些都是这些黑产团伙所带来的衍生因素。

三、验证码的前世今生

验证码的早期

根据百科的描述，验证码的历史要追溯到十多年前，那个时候黑客们肆无忌惮地编写脚本程序来模拟登录破解账户密码，还通过恶意代码在论坛或者邮箱自动发布诈骗信息及垃圾广告，使得用户和企业主们深受其害。

直到路易斯·冯·安（Louis Von Ahn）在雅虎提出一个解决方案：“在用户操作过程中，把机器人从正常用户里揪出来”。

大致的思路就是通过一些人类能轻松做到但机器做不到的事情来进行鉴定。

Louis甚至专门写了一篇论文来给这个技术做了一个更加清晰的定义 CAPTCHA- Using Hard AI Problems For Security。
这里列举一下它的摘要：

Abstract. We introduce captcha, an automated test that humans can pass, but current computer programs can’t pass: any program that has high success over a captcha can be used to solve an unsolved Artificial Intelligence (AI) problem. We provide several novel constructions of captchas. Since captchas have many applications in practical security, our approach introduces a new class of hard problems that can be exploited for security purposes. Much like research in cryptography has had a positive impact on algorithms for factoring and discrete log, we hope that the use of hard AI problems for security purposes allows us to advance the field of Artificial Intelligence. We introduce two families of AI problems that can be used to construct captchas and we show that solutions to such problems can be used for steganographic communication. captchas based on these AI problem families, then, imply a win-win situation: either the problems remain unsolved and there is a way to differentiate humans from computers, or the problems are solved and there is a way to communicate covertly on some channels.

在这片论文的讲述中，Louis认为验证码会是一个“双赢”的产品。因为如果这些问题无法通过机器来自动化解答，那么它就能达到区分人机的效果，反之，如果这个问题被AI攻破了，那么在机器学习领域里，会是一个非常重大的进展。——实际上我们在这十几二十年中所看到的正是如此。

在Louis之后，图形化验证码在被证明有效后，在互联网上迅速得到了推广。国内外各大网站，在关键的业务点上都加入了这一类型的验证码。这种验证码通常是一些字符加上一些扭曲的方法，生成一张图片返回给前端展示，然后匹配用户输入是否正确：

早期的验证码大抵都长这样：

后来，在机器学习的发展下，这样的验证码明显是挡不住攻击者的了；即使是入门级的“knn”算法也可以很轻松的达到非常高的识别准确率。

工程师们逐渐加大了识别的难度：

这样的：

也有这样的：

这些验证码在这个时期有效的防止了大量的攻击请求。

验证码的发展

图片字符的验证码，随着机器学习的发展变得越来越复杂，扭曲程度越来越高，这样不可避免的会遇到一系列问题：

1、首先这些图片对有着视觉缺陷的人士非常的不友好，他们几乎无法辨别如此复杂的图形

2、其次机器学习在这些领域有了非常明显的进步

3、有些验证码甚至连正常人都无法分辨，影响用户体验

在这之后，陆续出现了一些识图验证码，例如我们都知道的12306的图片验证码：

但是12306的验证码推出后不久就被攻陷了，攻击者们先通过人工打码平台，以非常低廉的成本招聘一些社会人员进行图片的人工识别，并对其打上对应的标签，然后生成自己的图片枚举库，渐渐的就把12306的图片数据库翻了个底朝天。

后来有些厂商推出了自动生成图片的验证码，每一次的图片都是由AI自动生成的，是独一无二的，避免了被枚举的可能。但是这类验证码普遍体验更差，连正常人都很难识别的东西大大降低了站点的用户体验。

智能验证码

智能验证码抛弃了传统字符型验证码展示-填写字符-比对答案的流程，采用验证码展示-采集用户行为-分析用户行为流程，用户只需要产生指定的行为轨迹，不需要键盘手动输入，极大优化了传统验证码用户体验不佳的问题；同时验证码后台针对用户产生的行为轨迹数据进行机器学习建模，结合访问频率、地理位置、历史记录等多个维度信息，快速、准确的返回人机判定结果。

智能验证码还可以通过智能的风控判断，当一个用户被识别为高危用户时才会弹出对应等级的验证码告知用户填写。在这方面比较典型的就是阿里云:

当系统判定你属于风险登录的时候，将会提高验证等级，你必须通过多因素验证才能够正常登录你的账号。

四、风控技术体系

上图来自美团技术团队发布的文章：https://tech.meituan.com/2017/01/13/risk-control-system-experience-sharing.html

我们可以比较清晰的看见，在整个风控技术体系中，数据处理和数据计算是比较关键的环节，它一般是通过实时计算平台对用户海量的数据进行计算。使用spark streaming进行秒级的数据指标计算，使用flink进行毫秒级别的指标计算等。

规则平台

规则引擎是风控决策的核心，模块主要包括：

1、规则管理

2、规则推送

3、规则执行

等。

它是一个同时面向技术和业务的一体化平台，规则平台的主要特点有：

1、流程分支复杂，条件多

2、不确定需求多

3、业务规则时效性要求

4、业务可在线配置规则，无需二次开发

互联网风控团队面向风控业务的规则引擎的研发，可以基于Groovy等脚本引擎开发；也可以基于自身的需求在开源商业规则引擎上进行二次开发，例如drools、ITOG Jrules等。

实时计算平台

在风控业务中，为了实时进行业务事件的风险判断，我们经常要做这样的事情：

1、在用户登录的时候，根据用户过去的登录行为判断他的风险程度。

2、在用户付款的时候，根据用户的风险路径，实时判断是否可以使用一键付款等业务。

3、给用户贷款，实时判断用户的信誉等级

等等。

这些都离不开实时的指标计算系统，我们需要通过一个可以秒级、甚至是毫秒级的指标计算系统来完成这样的工作，而目前市面上大抵基于两种技术开发：

SparkStreaming和Flink。

SparkStreaming

Spark Streaming 支持的数据输入源很多，例如：Kafka、 Flume、Twitter、ZeroMQ 和简单的 TCP 套接字等等。数据输入后可以用 Spark 的高度抽象原语如：map、reduce、join、window 等进行运算。而结果也能保存在很多地方，如HDFS，数据库等。另外Spark Streaming 也能和 MLlib（机器学习）以及 Graphx 完美融合。

SparkStreaming特点

易用；
容错；
易整合到Spark体系中；

在SparkStreaming之前, 用户往往要借助多种开源组件才能够构建出流处理和批处理系统，SparkStreaming的出现不仅能很好的解决这些问题，还统一了技术框架，使用了跟Spark一致的编程模型和处理引擎。

Flink

现在，各大厂商都在探索机遇flink的实时计算方式，熟悉的比如爱奇艺、唯品会、oppo等大型互联网公司都在用它，不久前flink也被阿里收购。

flink是一个真正的流式系统——为什么要这么说呢？因为spark是基于批处理形式的“类”实时系统，spark只能够做到秒级的数据计算，而flink轻松就能达到毫秒级别。

数据流的运行流程

Flink程序在执行后被映射到流数据流，每个Flink数据流以一个或多个源（数据输入，例如消息队列或文件系统）开始，并以一个或多个接收器（数据输出，如消息队列、文件系统或数据库等）结束。Flink可以对流执行任意数量的变换，这些流可以被编排为有向无环数据流图，允许应用程序分支和合并数据流。

Flink的数据源和接收器

Flink提供现成的源和接收连接器，包括Apache Kafka、Amazon Kinesis、HDFS和Apache Cassandra等。

Flink程序可以作为集群内的分布式系统运行，也可以以独立模式或在YARN、Mesos、基于Docker的环境和其他资源管理框架下进行部署。

Flink的状态(state)

Flink检查点和容错：检查点是应用程序状态和源流中位置的自动异步快照。在发生故障的情况下，启用了检查点的Flink程序将在恢复时从上一个完成的检查点恢复处理，确保Flink在应用程序中保持一次性（exactly-once）状态语义。检查点机制暴露应用程序代码的接口，以便将外部系统包括在检查点机制中（如打开和提交数据库系统的事务）。

Flink保存点的机制是一种手动触发的检查点。用户可以生成保存点，停止正在运行的Flink程序，然后从流中的相同应用程序状态和位置恢复程序。保存点可以在不丢失应用程序状态的情况下对Flink程序或Flink群集进行更新。

Flink的数据流API

Flink的数据流API支持有界或无界数据流上的转换（如过滤器、聚合和窗口函数），包含了20多种不同类型的转换，可以在Java和Scala中使用。