频道栏目
首页 > 安全 > 网络安全 > 正文

一次DDOS攻击记录

2016-06-06 09:50:00           
收藏   我要投稿

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

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

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

 

\

 

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

到这里基本能判断极有可能是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掉。

相关TAG标签
上一篇:Spywaller恶意代码分析
下一篇:验证码对抗之路及现有验证机制介绍
相关文章
图文推荐

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站