nginx限流防刷方案
前言
互联网发展已经进入了存量期,一开始低廉的获客成本已经不复存在,互联网公司通过付出诱人而高昂的补贴以此来拉新的方式,催生了大量的黑产,灰产.并且越来越多的公司爆出数据泄露,暗网上用户的密码和隐私信息已经被打包明码标价出售.记得年前我司遭遇了撞库的攻击,部分用户的登陆凭证和密码被窃取.黑客通过其他渠道获得的手机号和密码字典,来请求我们的登陆接口.虽然最后造成的损失有限,但暴露了很多服务架构和业务安全性上的问题.
首先,签名算法暴露和弱密码的问题.验签算法暴露在目前反编译解包如此成熟的情况下,很难防止.目前想到方案就是控制签名的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秒.但上面的情况一样,都要等令牌补充才能接收请求.
nginx限流防刷方案相关推荐
- Java自定义注解-请求限流/防刷
兄弟们,相信遇到过重复请求的痛点吧,我也遇过,因此,写了一个自定义注解去解决这个问题,接下来看代码. 首先:创建一个自定义注解 RequestLimit .然后字段的话是 second.maxCoun ...
- 十七、安全优化(拦截器实现接口限流防刷)
接口限流防刷 防止用户大量重复访问,一分钟之内或几秒钟内限制访问多少次 思路:对接口做限流,计时,并记录访问次数 将一个用户的访问次数写到缓存里,同时给数据加有效期,次数增加直接对数据+1 如果在有效 ...
- java 接口防刷_java轻量级接口限流/防刷插件
简介 call-limit提供接口限流.防刷的功能,插件基于spring开发,在应用应用的任何一个逻辑层皆可使用(web.service.dao), 插件支持单机应用下的限流和分布式应用的限流(分布式 ...
- 自定义注解和拦截器,实现接口限流防刷
我们的目的是在指定时间内,每个用户只能进行秒杀请求指定次数. 首先,定义一个注解 写一个拦截器.就是当执行某个方法之前,将请求截获: (这里实现的只是一个思路,由于StringRedisTemplat ...
- 十分钟搞懂Java限流及常见方案
点击关注公众号:互联网架构师,后台回复 2T获取2TB学习资源! 上一篇:Alibaba开源内网高并发编程手册.pdf 文章目录 限流基本概念 QPS和连接数控制 传输速率 黑白名单 分布式环境 限流 ...
- 一文搞懂Nginx限流(简单实现)
Nginx现在已经是最火的负载均衡之一,在流量陡增的互联网面前,接口限流也是很有必要的,尤其是针对高并发的场景.Nginx的限流主要是两种方式:限制访问频率和限制并发连接数. 限流(rate limi ...
- Nginx源码研究之nginx限流模块详解
这篇文章主要介绍了Nginx源码研究之nginx限流模块详解,小编觉得挺不错的,现在分享给大家,也给大家做个参考.一起跟随小编过来看看吧 高并发系统有三把利器:缓存.降级和限流: 限流的目的是通过对并 ...
- sql server 配置管理器里为什么是32位_死磕 Nginx 系列:Nginx 限流配置
点击上方 Java后端,选择 设为星标 优质文章,及时送达 限流算法:令牌桶算法 算法思想是: 令牌以固定速率产生,并缓存到令牌桶中: 令牌桶放满时,多余的令牌被丢弃: 请求要消耗等比例的令牌才能被处 ...
- nginx 限流,以及nginx直接返回json格式数据
2019独角兽企业重金招聘Python工程师标准>>> 高并发系统有三把利器用来保护系统:缓存.降级和限流 今天我们这里说说限流.一般会在应用层配合redis做限流策略,这里我们聊聊 ...
最新文章
- 如何调试Node.js应用程序?
- 如何制作一款HTML5 RPG游戏引擎——第四篇,情景对话
- 当React Native 遇到了Google reCAPTCHA
- Boost:双图bimap与range范围的测试程序
- 在 远程桌面 权限不足无法控制 UAC 提示时,可使用 计划任务 绕开系统的 UAC 提示...
- linux的nice命令用法,nice命令详解
- Java中反射主要应用在哪里_Java学习:反射的应用场景和解析方法
- android 说出密码,关于未来的住宅的作文400字5篇
- blocks bytes extents比较
- Atitit lucence es solr的各种query 与sql运算符的对比 目录 1.1. 等于运算 TermQuery	1 1.2. 范围运算	1 1.3. 大小运算	1 1.4. Wi
- PMP考试重点总结四——规划过程组(2)
- AR VR MR三者的区别
- 如何实现用户不登记就不让用户继续使用正常功能
- bootstrap 轮播插件
- 【DBA】 Oracle 学习路线
- 论文阅读:**CTF: Anomaly Detection in High-Dimensional Time Series with Coarse-to-Fine Model Transfer
- 一篇较为详细的 Storyboard使用方法 总结
- python数据分析师下载_2020云开见明Python数据分析师特训营,全套课程资源下载...
- 沉静型人格分析,沉静型性格的职业发展
- MATLAB:方程组的求解