记一次CC应急

前言:周五的时候私接了一单，一网站访问502，初步怀疑是被DD了。。。

1.初步判断及响应

排查：

先找对接人拿了log进行排查，发现log是access.log。里面80%几乎都是bot（爬虫的user-agent），找了其中一个IP进行威胁情报查询，发现是白名单。再加上网站没有配置robots.txt,网站带宽也不大，就初步研判是网站的业务逻辑有问题，被爬虫爬挂掉了。

响应:

叫对接人在网站上设置了robots.txt。

User-Agent: *Disallow: /

设置完，攻击消停了一会，以为成功了。

2.再次瘫痪，持续研判

过了十几分钟，网站又挂掉了。

排查：

找对接人要了服务器权限登陆查看,通过iftop和top持续观察

发现流量激增是间歇性的，找了一个大流量进行威胁情报查询，发现是恶意IP，反查日志(小插曲:发现日志和对接人发过来的不一致，这时候才发现对接人发过来的是CDN的日志，他们有部署CDN)发现这个IP的UA就是包含google-bot。继续反查几个bot发现均是恶意IP，第一次查询是运气差，查到了真的谷歌爬虫。确认网站是被竞争对手恶意攻击。

响应：

迅速分析日志，发现攻击的来源的user-agent，存在规律。以user-agent为黑名单，以CDN入口端进行拉黑，并设置频次限制，拉黑境外IP等操作。

3.实施对抗

拉黑完之后，流量瞬间下去。以为就此结束，哼着小曲，去厨房煮晚饭去了。不吹不黑，老子做的红烧肉贼棒。

分析：

过了大概一个小时，网站再次被打崩了,再次查询日志发现。对方绕过了策略继续干。神TM还给我整实施对抗。继续拉黑，继续被绕过。

响应:

这时候已经是凌晨，发了个朋友圈吐槽了一下,没想到万能的朋友圈真给力。

然后阿里的大腿过来询问下情况，并推荐了openstar,基于防火墙加规则

https://github.com/starjun/openstar

接着时间太晚，简单研究了一下就去睡觉了。

3.接入WAF

分析：

起床已是中午，不出所料又被干了一个晚上。

响应：

本来想徒手搭建一个WAF的，但是评估一下，还不如直接买云WAF。配置策略接入。自此整个响应到此结束

写在最后：这次响应的不足点在于没有弄清楚拓扑，环境以及配置就介入响应，造成了一系列的误判。遇到应急响应不要急，先弄清楚所有需要知道的。最好整个checklist。

本文始发于微信公众号（边界骇客）：记一次CC应急