前期回顾
某天晚上运维老哥反映,公司某业务系统接到大量的注册请求,最高频率可达到4w/分钟。
前期猜测有两种可能:1.因为优惠券来薅羊毛的;2.某短信提供商在刷费用。
前期思路:
对注册接口进行限速以及禁止机制,API网关限速
应急流程
- Splunk,nginx access log
- web服务架构: Front ->cdn-> nginx reverse proxy ->waf-> WebServer
踩过的坑
封禁IP
**思路:**在waf上配置封禁策略,当请求次数达到30次/minute,将其封禁一小时。
坑点1:
waf上配置封禁策略,因为waf是在nginx的后面,所以流量在转发到waf时,已经被nginx解析了一次,所以应该考虑nginx转发的包到waf的样子。
坑点2:
因为网络架构的原因(waf在nginx的后面),所以当流量到达nginx时,nginx将其转发给waf,请求频率达到阈值之后,waf会触发规则将其封禁,然后返回502给nginx。当流量再次到达nginx时,nginx依旧会把它转发给waf,但此时waf已将该IP封禁,会返回502。此时的nginx再收到502之后,它会以为后端服务器出问题了,然后就会输出大量错误日志。这傻逼的网络架构,我也是无力吐槽。
短信验证码
坑点1:限制 60s 发送一次短信 ,但是未对短信发送的最大条数进行限制。
坑点2:客户端和服务器为设置同步,导致客户端限制了短信发送的次数,但在服务端未生效。
解决办法
- 实行注册用户打分机制(基于 IP 信誉值,手机号),当用户注册 时,分数越低,获得的奖励越低,并增加其注册成本
- 限制每个账户每天发送短信的最大条数
- 增加验证码(在请求次数大于等于3次时,弹出滑块验证码)
- 对注册接口进行限速已经禁止机制,API网关限速
代码层面解决思路
从JavaScript AntiDebug 开始
一般来讲是有以下几种技术:
- 异常环境检测(我们只想自己的代码运行在浏览器中)
- 调试工具检测
- 代码完整性检测
- 数据流完整性检测
- 反模拟
当然前提是前端也要做好反调试和加密。
前后端接入之后,但依旧不能完全的阻止攻击,在攻击者花费一定时间之后还是有可能被攻破的。那么如何在后面的阶段检测到脚本作弊,则需要对用户行为进行分析。
用户行为分析
对用户行为进行分析,将非正常用户进行标记,为降低误杀率, 增加被标记用户的操作成本(例如:短信验证码改为语音验证码)
简单的鼠标行为记录,加上事件记录,单击,输入focus input,等等,将其序列化,做分类即可。这个方法目前正在测试环境收集用户行为日志,将其导入到s3,然后后期分析。
字段记录:
- 鼠标轨迹
- 单击事件
- 输入事件:时长
- 登录后行为
一下为简单的记录坐标轨迹:
document.onmousemove = function(e){
var pageCoords = "( " + e.pageX + ", " + e.pageY + " )";
console.log(pageCoords);
};
更骚的操作是:
monitorEvents(document.body); // logs all events on the body
monitorEvents(document.body, 'mouse'); // logs mouse events on the body
monitorEvents(document.body.querySelectorAll('input')); // lo
其他
- 行为日志收集之后用于分析
- Javascript 加密混淆深入了解
总结
SDL的推进真的十分必要,研发那帮人真的是啥方便干啥,总是遇到问题才会着急,平时真特么拽得不行。实在荒谬,然而现在给我的感觉是技术好管,人难管。真是让人一言难尽。还应该学习一些管理学的知识才行。