记一次大战低频CC的真实记录
前言
我们服务器经历了长时间低频CC的困局，CPU居高不下，历经周折，终于找到了解决方法，写点东西出来给大家分享一下吧。
一、阿里云WAF流量清洗
飞泊云停是一款基于微信支付的智能停车管家，公司是智慧城市倡导者，让出行更便捷，让停车更简单，在行业内有很高的知名度和口碑。同时，公司非常注重网络安全，购买了CDN和最高防护级别的阿里云盾web应用防火墙作为第一道安全屏障，经过阿里云waf清洗后的流量变得非常干净，过滤了大量的威胁（如SQL注入、XSS、高频CC、DDOS等），为马爸爸和王坚博士的网络安全团队点赞。阿里云waf基本架构是：
然而，总有那么个别不怀好意的人，通过人工分析飞泊云停的停车记录接口，精准选择了几个计算资源最多（最消耗CPU和内存）的动态API接口，同时动用了数以十万计的肉鸡（或代理IP），向源站服务器发动频繁请求。由于这些请求都是合法的，并且单个IP频率很低（不超过10个），阿里云waf视为合法流量，全部被穿透了打在源站服务器上，导致服务器长期CPU占用99%经常报警甚至重启，严重影响了客户停车体验。
二、增加开源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_agent、cookie、traceid等，总有地方和真实的微信支付不一样。
于是根据这些特征，生成了专家对抗规则用于检测HTTP非法头部和非法的Cookie信息，在aihttps上运行检测报警模式：
天哪，结果每天都有数十万攻击IP，最多的1天有60万IP，而且这些IP基本来自国内，无法通过禁用国外IP等地域方式阻挡。
攻击IP触目惊心，意味着国内排名前三位的江苏、山东、广东，每天至少数万的IP地址已经被木马团伙沦陷，用于跳板做攻击。我们终于明白警察叔叔的良苦用心了，这些IP也是受害者，网络安全绝非某个组织、专家的事情，而是全民都要重视了。
三、欺骗攻击者
检测模式运行了三天，确认没有误报后，公司领导迫不及待想改变为阻断模式，精确阻断才能有效保护服务器。由于aihttps开源waf默认的阻断方式是http?302响应跳转到某个网址，专家给出的意见是不能用这种方式。原因是：这种阻断方式，攻击者很快就会知道我们有防御，攻防乃顶级智商的较量，兵者，诡道也。于是我们修改了开源waf的源码（httpx.c）文件，把阻断返回方式从302 location，调整为和服务器返回的json格式一样：
{code:666, ?msg:”没有余额”}这样攻击者得到的响应，和原来服务器返回的结果一样。
四、总结
这样低频CC的所有流量被WAF阻断了，后端WEB服务器CPU恢复到了正常的水平，总结起来就是以下几点：
用cdn和阿里云waf集群防御高频攻击。
用开源waf保护源站服务器。自定义HTTP头和开源waf联动，修改源码，让开源waf深入理解服务器业务，精准阻断低频攻击。
如果是APP，还可以学学淘宝接口，用公私钥对关键接口的HTTP头做加密校验，可以精准检测攻击。
产品较量上升到顶级智商的较量，即在HTTP头和响应里面互相欺骗。如果攻击者升级构造了http头，我们已经做好了升级预案：在开源waf里和后端redis服务器互动校验cookie头部session的真实性来对抗。
攻防同源，对抗远远没有结束，直到发稿的时候，每天几十万IP地址的低频CC攻击仍然傻傻的打到了aihttps开源WAF上。如果攻击者把每天IP地址调整到数千万级别，也是扛不住的，但它的进攻成本已经远远大于我们的防御成本了。
