前言

  互联网发展已经进入了存量期,一开始低廉的获客成本已经不复存在,互联网公司通过付出诱人而高昂的补贴以此来拉新的方式,催生了大量的黑产,灰产.并且越来越多的公司爆出数据泄露,暗网上用户的密码和隐私信息已经被打包明码标价出售.记得年前我司遭遇了撞库的攻击,部分用户的登陆凭证和密码被窃取.黑客通过其他渠道获得的手机号和密码字典,来请求我们的登陆接口.虽然最后造成的损失有限,但暴露了很多服务架构和业务安全性上的问题.

  首先,签名算法暴露和弱密码的问题.验签算法暴露在目前反编译解包如此成熟的情况下,很难防止.目前想到方案就是控制签名的salt分发.弱密码需要从业务层改造,成本比较高.或者弱化用账号密码登陆,转为第三方授权.

  其次,这次攻击发生的很早,但是几个小时后才通过接口流量监控发现请求量异常.发现时已经有大量的用户密码被拿到,造成后面的被动局面.如何才能发现这些异常的请求.

  最后,通过分析日志,黑客请求的ip数量都集中在有限个ip,完全可以通过规则去拒绝这些非法的请求.

  上述的后两个问题都可以通过今天要探讨的方案解决.

谁是狼人

  服务器每天都在接受上亿次的请求,怎么样判别哪些请求是无辜的平民,哪些是请求是要你命的狼人.

  通过分析请求log,可以发现非法的请求有几个特征:

1. 业务纬度的单一性:黑客攻击往往有目的,只会攻击那些比较重要的接口.比如上述案例里的登陆和校验手机号.
2. 时间纬度的集中性:为了短时间内拿到大量数据,黑客会通过批量频繁的请求.
3. ip有限性:这种窃取数据型的攻击行为有别于DDOS,一般ip代理池的数量不会太过庞大,每个ip请求的次数都比较多

  因此,采用{uri}+{ip}作为key,在某个时间纬度上,去统计请求量,从而鉴别非法请求的方法,能够有效的抵御案例的攻击

谁是猎人

  那么问题来了,谁来当猎人,抵挡狼人的攻击呢.

  服务架构上无非就几个地方,lb,nginx,server.个人觉得放在哪层区别不大,遵循非法请求尽早丢弃的原则和考虑改造的难度,我选择了在nginx层.

nginx魔法

  作为nginx的菜鸡选手,又因nginx版本比较低,当时配置规则遇到了很多问题.所幸最后摸索出可行的方式.主要用到nginx的geo,map,limit_req

• 规则配置

        ##IP白名单geo $whiteiplist {default 1;127.0.0.1 0;10.0.0.0/8 0;}map $whiteiplist $limit {1 $limit_key;0 "";}## 接口白名单map $uri $limit2{default $limit;/api/sample "";}limit_req_status 406;### 频率控制limit_req_zone $limit2 zone=freq_controll:100m rate=10r/s;limit_req_zone $limit2 zone=freq_controll_2:100m rate=500r/m;

  这段规则写的比较繁琐 主要是受限于nginx版本较低 limit_req_zone 这里不支持两个变量,以及要支持接口白名单和ip白名单

    location / {limit_req zone=freq_controll burst=5 nodelay;limit_req zone=freq_controll_2 burst=10 nodelay;error_page 406 =406  @f406;location @f406 {access_log syslog:server=127.0.0.1:12301;return 406;}}

  注意到limit_req中两个奇怪的参数 burst ,nodelay 开始的时候我也感到疑惑,了解了背后的逻辑和算法,才理解了其中的奥义.

流量控制

  流量控制的算法中常见的有漏斗算法,有两种思路:1:当水的量已经达到桶的上限时,先暂时停止接收,等到桶的水漏了一部分后再继续接收.2.超出桶的流量直接丢弃.总的来说,两种思路无非就是,等待和丢弃.

  而limit_req 模块的算法又与漏斗算法有些不同,属于令牌桶算法.两者最大的区别在于,漏斗算法只能强制性限制流量的大小,没有办法应对某些突发的负载.而令牌桶恰恰弥补了这个不足.

  令牌桶的核心有几个:

1.定义一个有个数上限的令牌桶,以固定速率投放令牌到桶里. 2.当桶里有n个令牌,则处理n个请求.并且消耗掉相应的令牌. 

  而这时候burst参数就发挥了作用.假设一秒内同时有120个请求发到服务器.按照传统的漏斗算法,多出的这20个请求会被直接拒绝 或者是放到队列中等待.而在令牌桶算法中又是另外一种景象了.令牌桶中实际上有100个令牌.但是允许并发10个请求.那么多出来10个请求会被拒绝 .

  在没有配置nodelay的情况下,这10个请求会被放到队列.以0.001秒的速率被取出,共计消耗0.1秒.处理110个请求用了1.1秒.实际上这个等待是没有必要的.

  而配置了nodelay,这多出的十个请求会被正常处理,只是burst的数量会被清空.等待令牌重新补充,才会重新接收请求.处理110个请求用了1秒.但上面的情况一样,都要等令牌补充才能接收请求.