为了账号安全,请及时绑定邮箱和手机立即绑定

API接口访问频次限制 / 网站恶意爬虫限制 / 网站恶意访问限制 方案

标签:
API

API接口访问频次限制 / 网站恶意爬虫限制 / 网站恶意访问限制 方案

采用多级拦截,后置拦截的方式体系化解决

1 分层拦截

1.1 第一层 商业web应用防火墙(WAF)

直接用商业服务

传统的F5硬件,不过现在用的很少了
云时代就用云时代的产品,典型代表 阿里云 web应用防火墙

1.2 第二层 API 网关(API Gateway)层

API 网关(API Gateway)

kong为代表的开源 API 网关 实现
openresty + lua 自实现
windows平台 安全狗、云锁 实现

1.3 第三层 应用层

用Redis内置lua脚本

redis是块砖,哪里需要哪里搬
redis内置了lua引擎,2.6版本后你可以编写一段lua脚本,完成逻辑判断流程

常见的有对某维度计数器法 对某维度令牌桶法
维度的概念比如就是IP或者IP+模块等, 多个字段合并成一个维度

本方案满足绝大多数应用层的限流需求
当然也可以自己用应用层程序实现,前提是redis+lua满足不了你的需求

2 后置拦截

基本的套路其实很简单,从日志这里计算出恶意IP,恶意用户,再给其他系统用
分控的基本思想也是这样的

已经在用ELK日志系统:可以用ES中定时查询高频IP,送入WAF做拦截
已经在用流计算系统:flink和spark等流计算系统计算出高频恶意IP,用户等

然后就可以应用这些计算出的结果数据做限制,封禁等

3 一+二+三+后置协同工作

第一层Waf当然有拦截,但是对于新IP他不会马上生效, 会有几分钟的时间才会拦截
特别是恶意爬虫IP池一上,大量新IP就来了,第一层会放过来,如果只是一层,结果就是数据库慢查询告警叮叮叮

配合上二层 三层 一层一层拦截
如果没有精力搞二层,那么第一层用买的,第二层不做,搞第三层

后置拦截的结果可以作为长期封禁使用
这种多次拦截的策略和多级缓存的概念是不是很像
多层次的拦截保障源站监控告警静悄悄

面向C端的产品被爬虫,被恶意访问的概率会大很多
面向B端的网页也不是没有风险
面向B端的API也有限流的需求

流水理鱼 发布!

点击查看更多内容
TA 点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
  • 推荐
  • 评论
  • 收藏
  • 共同学习,写下你的评论
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消