对抗爬虫的一点小策略

临近1111、1212这种时间节点,伴随活动到来的还有一大堆爬虫。

一些低端的爬虫很容易造成目标系统的过载,这点从访问日志和设备资源监控上可以看出来。这部分爬虫不太喜欢(或不太在意)进行频度控制,希望尽可能多且快地获取目标系统上的资源。我们把这些爬虫称为“搞事儿的”。

最初,我们的业务监控系统发现这类搞事儿的出现后,通过特征抽取,在前端负载均衡器或者WAF上对它们进行【封禁】。这招往往一开始效果立竿见影,目标系统一下子负载轻了很多,监控系统也立即不再告警。

这样的处置方案我们是根据日常对“扫描器”的行为特征中总结出来的,实质上对业务爬虫并不适用。原因在于【扫描器往往是非特异性的,以求尽量通用和覆盖率尽可能高;而业务爬虫很大程度上是专门为业务系统定制的,甚至有专人会不定时的维护】。

如此一来,我们采取的封禁策略会被搞事儿的发现。这时候,立即陷入一个循环:发现告警->特征抽取->执行封禁->攻击者发现->变更特征->继续祸害->发现告警。(我们把执行业务爬虫的家伙也称为攻击者)

更让人担心的是,随着攻防对抗的轮数增加,我们对特征抽取的难度也不断增加。爬虫开始使用大量“拟人”的行为来绕过我们的特征抽取。很快地,这个循环以我们主动break而告终。

我们不得不考虑更有趣、更有用的防护方案了。

一、图灵测试

团队内部考虑到的第一方案就是图灵测试。简而言之,就是验证码。

显然,这种方案对于机械爬虫的解决能力是非常不错的,它能极大提升攻击者获取信息的难度和门槛。因其采用“非阻断性”的方式处理异常访问,除了会对少部分被误判的用户增加体验上的不适之外,并没有太多的额外副作用。也是我们最喜欢应用的一个方式。

然而,图灵测试会“逼迫”攻击者扩展攻击面,或者深研业务。同志们!不怕贼偷就怕贼惦记着就是在说这事儿啊。攻击者发现我们上了验证码策略后,开始升级攻击手法。又回到了无尽的攻防对抗之上来。

二、尔虞我诈

攻击者修正爬虫策略往往会在我们下班之后甚至是夜间凌晨进行。是可忍,孰不可忍。我们决定换一种思路去解决它们。

回到攻击者的出发点来:它为什么需要爬虫。原因有两个:一是为了获取我们的数据,二是为了获取我们的活动利益(例如刷单)。

前面的方法是通过技术手段使它们的期望【不再成立】,换言之,防护策略下发后会有一个很明显的时间分界线,这个分界线前后攻击者获取的数据具有明显的异同:true和false就是傻子也能发现这两单词是不同的。我们需要模糊这个分界线,同时也要模糊这个异同。

举个案例,攻击者通过某个API去获得一个类Wiki产品的释意内容。当我们的业务监控系统发现这种行为后,并没有执行传统的封禁或者弹验证码,而是通过某个特定的算法,“随机”从数据库中获取一个非当前词条内容的释意返回给攻击者。这和Discuz!在反爬虫中往帖子中随机插入用户UI上不可见、但内容中的确存在的字符有异曲同工之妙。

通过这个“尔虞我诈”的方法,使得攻击者的爬虫程序仍然能够正常获取数据,甚至可以在它爬完所有内容之前都不知晓自己已经被我们发现。直到攻击者人工review爬虫数据时才会发现,自己耗费大量时间精力和实际成本爬去到的数据根本就是一堆不能用的shit。

三、优化业务设计

当然了,最好或者说最根本的解决方案是通过优化业务设计来避免被人利用,这是一个很空泛泛的概念。

我们“借口”近来发生的多次业务爬虫事件,找到领导要了鸡毛令箭,逐步开始介入各个产品线重要业务的设计审查中。原先被人刷的高潮迭起的活动,经过一番在业务上的限制和策略之后,套利者已有很长一段时间没有出现了。

 

以上,一点人生的经验,谢谢大家。

 

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*