2016年6月

刚刚收到警告通知,一台机器的宽带使用率异常。通过top和ps aux等却看不出异常用户,负载正常;且低于常规。通过iftop看到基本都是一个IP在发送数据出去,请求数据的IP(攻击IP)有十多个段,封锁了请求IP后。查了下这些IP是CloudFlare和百度云加速的,很明显是被CC但CloudFlare和百度云加速没过滤掉发送给后端了。

发送数据的IP(被攻击网站IP)是共享的,下面有很多网站,直接封这IP会导致这IP下的所有网站挂掉。所以只能找到具体被攻击的网站和用户进一步操作,一个个看明显是不可能的。

DirectAdmin 用户的每个网站都有单独的apache日记,我们可以根据这特性,把请求数据持续时间相对长、大的ip拿出来,对所有用户的网站日记进行过滤搜索。

[root@****** ~]# grep -c 141.101.98.211 /var/log/httpd/domains/*.log | grep -v :0

/var/log/httpd/domains/****1g.com.log:1
/var/log/httpd/domains/****1g.com.error.log:30
/var/log/httpd/domains/****xv.com.log:12266

[root@****** ~]# grep -c 162.158.88.52 /var/log/httpd/domains/*.log | grep -v :0
/var/log/httpd/domains/****xv.com.log:6385

只拿出2个IP就找到了,很明显的是:****xv.com,然后具体检查该网站日记,发现从凌晨1点30分开始,到50分拒绝百度加速的请求,其实封十几个段还只是部分,这之间GET请求量已经有35万多次了,请求的IP数量未统计,非常之多,尾巴也是特别随机定制为穿透百度CDN的。之后联系到该用户,要求马上把百度云加速CC防护开到最高。然后解除刚刚封锁的IP段恢复该CDN的正常请求。算是解决了。

也许会问为什么服务器本身不能做防护?这次是比较特殊的,用户使用CDN隐藏了后端真实IP,所以攻击者不能直接对我们进行攻击,而是请求CDN,最终导致宽带占用异常的是CDN的IP,同样我们也无法正确获取到攻击者的IP,也无法对真实攻击者ip进行屏蔽,当然有方案可以做到,但我们屏蔽并没有用,CDN还是会放行;除非获取到真实攻击IP后反扑。CDN很多在用,我们肯定是不能封的。即使制定规则丢弃CC请求返回301给CDN,结局也是一样的;因为请求不会因此停止和减少,会继续对301页面请求,因为量大,宽带占用率并不会下降。只能与用户共同处理该问题。