码迷,mamicode.com
首页 > 其他好文 > 详细

开源waf在阿里云waf之后大战低频CC的一次真实记录

时间:2021-02-19 13:48:19      阅读:0      评论:0      收藏:0      [点我收藏+]

标签:特征   就是   恢复   防火   安全   傻傻   受害者   请求   计算资源   

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

1、阿里云waf流量清洗

飞泊云停是一款基于微信支付的智能停车管家,公司是智慧城市倡导者,让出行更便捷,让停车更简单,在行业内有很高的知名度和口碑。同时,公司非常注重网络安全,购买了CDN和最高防护级别的阿里云盾web应用防火墙作为第一道安全屏障,经过阿里云waf清洗后的流量变得非常干净,过滤了大量的威胁(如SQL注入、XSS、高频CCDDOS等),为马爸爸和王坚博士的网络安全团队点赞。阿里云waf基本架构是:

 技术图片

 

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

 技术图片

 

 

2、增加开源waf保护源站

公司无奈报警,但警察叔叔每天大案要案非常忙的,给出的建议是用专业技术对抗。于是经过大量搜索发现:aihttps是hihttps的升级版,是一款基于人工智能的开源waf,专门对抗未知攻击,或许对低频CC有效,于是公司决定用其商业部源代码的方式部署,在阿里云waf和真实服务器之间,再加一层waf过滤,之所以用源代码部署,是为了保证服务器安全,杜绝恶意代码和后门程序。于是网络架构变成了这样的模式:

 

互联网---CDN---阿里云waf---aihttps开源waf---F5负载均衡---真实web服务器

 

果然,开源waf一部署上去,报警很少(毕竟大量攻击被阿里云waf过滤了),但立刻从流量里面就发现了异常,每天高达几十万的IP地址访问记录,而且大量IP地址的访问次数不超过10次,这远远超过了公司正常的业务IP数量,从而判断基本确定95%以上的IP都是低频CC攻击,这正是服务器CPU过高的元凶。

这个时候任何waf都不敢贸然封杀正常流量,我们用人工的方式分析溯源日志里的流量,很快发现了特征:攻击构造的HTTP头,和真实微信支付里面的HTTP头如Cookie内容字段上有一定区别。如下图所示的user_agentcookie、traceid等,总有地方和真实的微信支付不一样。

 

 技术图片

 

于是根据这些特征,生成了专家对抗规则用于检测HTTP非法头部和非法的Cookie信息,在aihttps上运行检测报警模式:

天哪,结果每天都有数十万攻击IP,最多的1天有60IP,而且这些IP基本来自国内,无法通过禁用国外IP等地域方式阻挡。

技术图片 

攻击IP触目惊心,意味着国内排名前三位的江苏、山东、广东,每天至少数万的IP地址已经被木马团伙沦陷,用于跳板做攻击。我们终于明白警察叔叔的良苦用心了,这些IP也是受害者,网络安全绝非某个组织、专家的事情,而是全民都要重视了。

3、欺骗攻击者

检测模式运行了三天,确认没有误报后,公司领导迫不及待想改变为阻断模式,精确阻断才能有效保护服务器。由于aihttps开源waf默认的阻断方式是http 302响应跳转到某个网址,专家给出的意见是不能用这种方式。原因是:这种阻断方式,攻击者很快就会知道我们有防御,攻防乃顶级智商的较量,兵者,诡道也。于是我们修改了开源waf的源码(httpx.c)文件,把阻断返回方式从302 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地址调整到数千万级别,也是扛不住的,但它的进攻成本已经远远大于我们的防御成本了。

开源waf在阿里云waf之后大战低频CC的一次真实记录

标签:特征   就是   恢复   防火   安全   傻傻   受害者   请求   计算资源   

原文地址:https://www.cnblogs.com/hihttps/p/14412695.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!