即刻反垃圾系统设计

在互联网内,黑产和广告营销号始终是追赶热点的第一梯队,只要是活跃的社区就不免看到 Spam 的踪影。即刻在从一个小 App 慢慢做到如今的规模的过程里,也曾经常被 Spam 内容所困扰,这篇分享就来讲一下目前即刻的反垃圾系统的系统组成和结构。

文章内主要围绕方法论和系统设计,不会涉及具体的策略和模型的讨论。因为 Spam 的形式千变万化,不会有一个策略或模型能够应对从今往后所有的 Spam,只有掌握了思考和设计的方法才能灵活得调整策略模型去应对复杂多变的网络环境。

Spam 的定义

在即刻 App 内,我们对于 Spam 定义是比较宽泛的概念,认为只要有悖于社区规则、有碍于社区健康发展的都是 Spam。除去常规的广告、色情、涉政等内容,不友善的发言、无意义灌水都算在 Spam 的范围内。

Spam 的种类

Spam 在即刻 App 中会以内容、用户和行为三种形式存在。

内容类是最容易理解的,指用户直接发布 Spam 内容(评论、动态)。动态会借助分发渠道散布给广大普通用户。而评论则会直接被动态的作者接收到。

用户类指的是使用 Spam 信息的个人头像、昵称、个人简介等信息。这样用户可以选择发送正常的动态或评论内容,以此绕过内容上的检查和限制,往往这样的 Spammer 会会比内容类的更加谨慎和隐蔽。

最后一类是行为类,指的是通过使用异常行为去获得 Spam 传播,例如使用大量账号对 Spam 内容刷赞,频发对正常用户点赞或者关注试图引起关注回馈等。

对此,我们设计了一套覆盖整个生命周期的反垃圾系统。

生命周期

一个 Spammer 的生命周期可以简单得总结为

  • 账号生成环节
  • 异常行为环节
  • 内容生产环节
  • 社区检查环节
  • 处理环节

在即刻 App 内,所有的操作和内容浏览都需要先获取帐号。在反垃圾体系还不完善的时候,即刻经常会受到大量 Spam 账号的攻击,其中一个很重要的漏洞就在于账号获取过于简单。只需要抓到客户端注册账号的 API,并伪造 header 等必要信息就可以进行注册,配合第三方的僵尸 QQ、微博黑产服务,可以瞬间获取到大量的 Spam 账号。

在拥有账号之后,Spammer 便可以开始生产之前已经说过的三类 Spam 内容。分别对应了内容生产异常行为两个环节。

随即,生产出来的 Spam 会开始在社区内散播,这个时候,社区检查承担起了发现 Spam 的重担。用户通过举报将 Spam 内容提交到我们的运营后台。运营的同事会立即将 Spam 内容进行删除,对 Spammer 账号进行封禁。这个环节就是处理环节。

当 Spammer 账号被处理之后,他的生命周期也在此结束了。

Spam 危机

通过上面的描述,我们可以很明显的感觉到,发现和清理 Spam 内容是一个响应非常迟钝、缓慢的过程。发现和清理会落后于 Spammer 对社区的攻击。这里我们引用 Facebook 的论文《Facebook Immune System》中的一段陈述来看这个问题。

我们可以将 Spam 内容划分成四个阶段,“攻击开始”、“被检测到”、“攻击被抵御”、“抵御被察觉”

对应的四个状态转换过程就是“攻击”、“检测”、“防御”和“变种”。

在图中有一个分水岭,在防御策略被部署上线之前,“攻击”和“检测”都属于被攻击者控制的时间。在有了针对性的防御策略后,Spam 内容会被清理,攻击者也需要作出修改和变种以突破现有的防御策略。这一部分时间就属于防御者控制的时间。

反垃圾系统设计的目标是缩短被攻击者控制的时间,并且延长防御者控制的时间。

即刻的反垃圾系统

有了目标之后,我们就可以开始针对 Spammer 的生命周期逐个击破。整个反垃圾系统对应每个生命周期都有一个子系统进行防御。系统之间相互配合、共享信息,共同完成整个系统的设计目标。

这个是整个系统的顶层设计图,系统中有“设备安全中心”、“行为监控中心”、“内容安全中心”、“举报中心”和“数据中心”五个子系统。

设备安全中心

对应账号生成环节。目标是提高注册门槛,降低虚假账号、盗号的情况。

我们会从客户端中收集硬件信息、网络环境、同设备账号信息等许多有用的脱敏数据。并为每一台设备生成唯一的设备指纹。

虚假账号

设备信息的作用在于,我们可以轻松的分辨出虚拟机、设备农场、机房 IP等风险。并且我们还接入了第三方的设备检测、手机号黑库等服务。这些第三方服务对于黑库的更新速度和联动信息可以帮助我们快速发现有问题的设备和手机号。例如,一个设备最近在别的 App 中进行了攻击操作,那这个设备也会在我们的 App 中被标记为高风险。

伪造设备,甚至是无设备的脚本攻击,是成本最低的账号获取方式。将这个最大的漏洞口堵上之后,Spammer 只能通过多开账号来完成获取更多新账号的目的。

因此除了设备维度的检查,我们还会针对同设备的账号进行关联检查,比如最简单的策略是检查一个设备下的账号数量,这个策略在我们集中拉新活动的时候非常有用。

盗取账号

在新账号获取上受阻之后,攻击者往往会采用弱密码暴力破解、社工库破解的方式去盗取老账号用于 Spam 攻击。

我们在客户端预埋了人机验证的机制,去抵御客户端内的暴力破解和弱密码。再配合重试次数策略、ip 限制等方法进一步限制暴力破解的速度。对于弱密码和社工库,常用设备和常用网络环境可以帮助我们快速察觉到账号的异常登录行为。这些有危险的账号会被重置密码,强制下线盗号攻击者,而账号所有者则可以通过验证码、第三方绑定账号的方式重新夺回账号的控制权。系统会使用短信、站内通知等方式去告知账号所有者。

行为监控中心

对应异常行为环节。我们将行为分为主动行为和被动行为两类

  • 主动行为:指用户的在 App 内的自发行为,例如浏览、点击、发布内容等。
  • 被动行为:指其他用户对该用户的行为,比如给他点赞、评论、拉黑、举报。
  • 被动行为:还包括官方处理结果,例如内容被删除。

行为监控中心根据我们设计好的策略,实时计算用户的行为次数、频率、持续时长等指标。

从方法论的角度看,Spammer 会和正常用户有非常不一样的操作行为。因为对于 Spammer 来说,快速散布 Spam 内容、尽快骚扰到目标受害群体是他们的首要利益点。

举个例子,正常用户往往会浏览行为次数大于生产行为次数,并且伴随较深度的点击行为。而 Spam 用户则可能高频得进行内容生产或在获取到账号之后立刻就进行内容发布。

通过收集行为和数据分析,我们会努力寻找难以被绕过且具有分辨度的特征,找到一个低误伤率的阈值去制定策略。

内容安全中心

这里所说的内容是一个宽泛的概念,涵盖动态、评论、用户资料等。

内容安全中心对应了内容生产环节。在这里,所有的内容在生产出来之后会立即经过机器的检测,对于识别出有风险的内容会交给后面会说到的惩罚中心。所有的机器检测都非常迅速,经过长时间的策略和数据积累,我们可以做到大部分的 Spam 内容会在生产出来之后被立即清理。

我们针对每一种数据类型制定了若干组策略,通过简单的策略引擎去编排和执行这些策略。

策略引擎

简单讲一下策略引擎的设计。

策略引擎按 Task 执行,一种数据类型往往会有多组 Task。一个 Task 由 Skippers、Policies 和 RunMode 组成。

Skipper 用来控制是否执行这个 Task,RunMode 则用来控制检查完成之后的流程(退出或继续)

Policy 是具体进行内容检查的部分。Policy 可以是直接获取数据进行风险计算,也可以是通过算法模型检测来获得风险结果。我们将具体的检测逻辑封装在 Policy 内,保持 Policy 的独立性和复用性,引擎和使用者则不必关心其内部实现。

模型上,我们根据不同应用场景设计不同的算法模型,例如广告、不友善、色情等模型。关于模型的相关内容可以查看之前的 BERT 模型分享

在跑完所有的 Task 之后,策略引擎会收集到所有的 Policy 执行结果,综合判断优先级、权重等因素之后,获得这个内容的最终风险等级。

人工检查标注

在内容安全中心里,除了策略引擎,我们还加入了对检测结果的人工检查。人工检查的意义在于对数据进行了标注,我们可以根据人工标注结果计算出每个策略、模型的精确率、召回数量,并且持续提供了干净的数据样本。这些样本会最终用于模型、策略的训练、迭代,一步步改善各项指标。

举报中心

社区检查对于整个 Anti-Spam 体系来说是非常重要的一个环节,因为它承担了发现漏网之鱼的重要责任。就像文章最开始说的 Spam 危机一样,Spam 的处理都是滞后于生产的,可能需要过几小时甚至几天,我们才能意识到有一种新型的、不能自动处理的 Spam 在社区蔓延。

举报中心接收来自社区的用户举报,进过有效性过滤,去掉重复的、已经被处理的内容,将举报按优先级组织交由人工处理。

这个过程听起来并没有得到太多效率上的提升,但配合行为中心的被动行为策略,可以加速 Spammer 被处理的速度。

另外,我们在举报中心里增加了舆情监控的功能,我们会对数据在不同维度进行聚合、关键词提取,例如举报频发的动态,包含敏感关键词的内容等。对异常值预警,运营同学能够及时知道社区热点和举报高发区域。

在客户端内,我们也需要持续加强对用户的教育,鼓励用户举报看到的 Spam 内容。配合一定社区激励,让社区生产消费过程进入良性循环。

仅仅是发现漏网之鱼并没有办法使整个反垃圾系统得到进化和增强。所以对于社区状况最敏感的运营审核人员在发现有规律的或固定特征的 spam 后,会和工程师一起将规律和特征制定成策略或是模型回馈到整个 Anti Spam 系统中,实现针对该类型的自动处理。这也是攻击防御的分水岭。

惩罚中心

我们将所有数据类型的惩罚接口抽象,聚合在惩罚中心里,并且隐藏了具体惩罚的细节。上述的几个系统不必关心最终内容是被删除、隐藏或者只是预警,他们只需要提交数据类型、风险级别和处理对象即可。

在惩罚中心里,每个数据类型有删除、隐藏、预警和通过四种结果。最基本的判断逻辑是,不同的风险对应了不同的结果。除此之外,我们还会加入用户等级、设备风险、画像标签等元素一起考量最终惩罚方式。我们会对优质用户降低惩罚,而对有风险的用户提高惩罚。这里的辅助信息可能来自于其他的子系统,例如设备安全中心里标记的风险账号、异常行为中心里标记的异常账号,也有可能是来自用户画像系统等外部数据。

值得一提的是,在最终惩罚方式上,隐藏的效果会好于直接删除内容。隐藏内容会令 Spammer 难以察觉自己已经被盯上,发布的内容都已经被清理,会继续使用已经无效的 Spam 模式进行攻击。而相对的,立即删除内容则会引起 Spammer 的快速反弹和变种。

数据中心

整个系统的最后一部分是数据中心。它收集了各个系统中的处理结果,建立在即刻大数据平台之上。所有子系统的数据都会回流到数据中心里,因此我们可以一站式搞定所有的模型、策略评估、特征工程、数据分析提取等工作。

良好的数据平台支持可以加快模型和策略的开发速度。速度对于反垃圾系统来说至关重要,上面系统里提到的许多设计细节都是为了加速开发、部署上线的速度。

最后

以上就是即刻反垃圾系统的组成和设计思考的方法。显而易见,其中还有许多的不足之处,例如策略的开发上线速度不够快、社区发现效率仍旧比较低下等。我们会继续优化和开发,系统可视化管理后台、无监督学习用于弥补社区举报效率等都在计划之中。也希望对此感兴趣的同学可以加入我们,邮箱是 haotianchai@okjike.com

项目参与者 @柴昊天 @夏雨 @Benb

参考资料:

《Facebook Immune System》

《快速部署基于BERT预训练模型的文本广告anti-spam服务》

编辑于 2019-06-23

文章被以下专栏收录