一次DDOS攻击记录

  就在昨天儿童节的时候,大概9点半左右收到微信公众号的报警信息,发现是服务器没有响应,5分钟内6次请求没有及时返回。当时并没有过多在意,因为之前也有过1~2次失败,都是是偶然因素。过了几分钟又收到dnspod的邮件报警,内容是snapast.com主站连接超时,这才意识到可能服务器宕机了。

  立刻手动访问一次,果然是打不开了,ssh也连接不上,下意识认为可能是服务器被重启了,因为之前托管在linkcloud的时候,隔个把月总会挂掉一下,但迁移到阿里云后一直很稳定,不太会出问题。

  登录到阿里云后台,在实例监控看到CPU一直满负荷运行,入网流量达到22M/s(云盾基础防护中显示有接近30M/s,忘了PPS多少来着),出网也已经塞满2M带宽。

实例监控

  通过阿里的终端登录到主机上,发现CPU是被4个nginx进程占满,后端几个tomcat负载并不高,说明并不是一般的大规模http请求(cc攻击)。而且nginx access log也是正常,但error log有很多xxx worker_connections are not enough,说明确实连接数较高,超过设定值。通过netstat统计居然有1.6w左右的连接数,远高于平时的300左右。

root@snapast:~# netstat -an | wc -l
16089

  到这里基本能判断极有可能是SYN Flood,想到云盾有一定抵抗DDOS的能力,试着开启流量清洗看看,原来人家的默认触发条件是流量100M/s,PPS是1w,我这点攻击还没办法触发呢,于是手动设置了一个最低条件达到10M/s就开始清洗,然而事实证明清洗毫无用处,依旧连接超时。但有个好处是开始清理后可以抓包。

  下载cap到本地用Wireshark打开一看,好家伙,果然是SYN握手攻击,大量的不同IP(美国为主)往443端口发SYN请求,极少数有回应RST,我猜应该是上层路由回的。云盾的抓包并不是你主机网卡包,而是在接入口的设备上。这下明了了,对于这种TCP层的攻击也没啥好办法抵御的,考虑到目前仅有相册用了https,所以先停掉nginx监听443端口,将机器负载降了下来,但也没办法彻底解决。有意思的是当时阿里云解析也出了故障没办法修改域名解析,屋漏偏逢连夜雨。

抓包

  就这么瞎折腾了2个小时,攻击才停止,一切也都恢复正常。今天来看,在微信接口调用统计中失败次数最为“壮观”的一天。

  现在想想其实也有一些办法可以减小宕机损失:比如将受攻击的域名临时解析到别处。再如将多个业务分离开来,用不同的域名,不同的IP接入,iptables将多次密集连接请求的IP drop掉。