真实记录一次用开源waf在阿里云waf之后大战低频CC（云waf部署）

真实记录一次用开源waf在阿里云waf之后大战低频CC（云waf部署）

前言：我们服务器经历了长时间低频CC的困局，CPU居高不下，历经周折，终于找到了解决方法，写点东西出来给大家分享一下吧。

1、阿里云waf流量清洗

然而，总有那么个别不怀好意的人，通过人工分析飞泊云停的停车记录接口，精准选择了几个计算资源最多（最消耗CPU和内存）的动态API接口，同时动用了数以十万计的肉鸡（或代理IP），向源站服务器发动频繁请求。由于这些请求都是合法的，并且单个IP频率很低（不超过10个），阿里云waf视为合法流量，全部被穿透了打在源站服务器上，导致服务器长期CPU占用99%经常报警甚至重启，严重影响了客户停车体验。

2、增加开源waf保护源站

公司无奈报警，但警察叔叔每天大案要案非常忙的，给出的建议是用专业技术对抗。于是经过大量搜索发现：ai302响应跳转到某个网址，专家给出的意见是不能用这种方式。原因是：这种阻断方式，攻击者很快就会知道我们有防御，攻防乃顶级智商的较量，兵者，诡道也。于是我们修改了开源waf的源码（location，调整为和服务器返回的json格式一样：

{code:666, msg:”没有余额”}

这样攻击者得到的响应，和原来服务器返回的结果一样。

4、总结

这样低频CC的所有流量被WAF阻断了，后端WEB服务器CPU恢复到了正常的水平，总结起来就是以下几点：1、用cdn和阿里云waf集群防御高频攻击。2、用开源waf保护源站服务器。自定义HTTP头和开源waf联动，修改源码，让开源waf深入理解服务器业务，精准阻断低频攻击。3、如果是APP，还可以学学淘宝接口，用公私钥对关键接口的HTTP头做加密校验，可以精准检测攻击。4、产品较量上升到顶级智商的较量，即在HTTP头和响应里面互相欺骗。如果攻击者升级构造了http头，我们已经做好了升级预案：在开源waf里和后端redis服务器互动校验cookie头部session的真实性来对抗。

攻防同源，对抗远远没有结束，直到发稿的时候，每天几十万IP地址的低频CC攻击仍然傻傻的打到了aihttps开源WAF上。如果攻击者把每天IP地址调整到数千万级别，也是扛不住的，但它的进攻成本已经远远大于我们的防御成本了。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。