2月27日18时整，虎嗅收到4个监控平台的各种监控报警，提示异常：
1、tcp链接数升速异常
2、cpu使用率飙升
3、http响应时间过长
4、带宽利用率异常
5、数据库压力升高
我们随即登陆服务器查看，18时4分，网站开始出现服务异常，开始收到故障报警：
1、tcp链接数超限
2、cpu使用率100%
3、http服务失去响应
4、带宽利用率100%
5、icmp无响应
远程直接链接直接失去响应，我们只能绕道进入服务器继续查看服务器状况，初步确认虎嗅受到的攻击方式为 ack flood + icmp flood + udp flood +cc。这种组合式攻击复杂程度比较高，可以确信对方做了十足的准备。虎嗅随即对服务器做了相应调整，但攻击流量过大，已经超过我们的总带宽。
实际上，虎嗅前段时间已经遭遇了很多莫名其妙的扫瞄和密码破解。看上去，伏击者准备已久了。
18：05，根据阿里云的流量清洗规则，“云盾”被触发，阿里云对攻击虎嗅的流量进行清洗，我们接到各种恢复提示，看起来一切正常了，虎嗅的流量只剩下被攻击时的1-3%，攻击者的流量基本稳定在虎嗅带宽10倍多点的流量上。
19：50，攻击者开始加压。攻击流量飙升到云盾清洗上限（云盾免费清洗上限），服务器瞬间倒地。
在阿里云同学的帮助下，21点左右，虎嗅开始恢复正常。而同时，攻击者再次加压。
虎嗅网跟阿里盾接受了第二次考验，最高流量一度达到虎嗅网总带宽接近40倍，但在阿里云的服务支持下，始终未对虎嗅网造成致命打击。
随后攻击者改变了攻击方式，嗅哥再次倒地。这时，远在杭州的阿里云团队协助虎嗅网使用了阿里的负载均衡（slb）。虎嗅网再次站了起来。攻击失效后，流量渐渐退去。
第二天白天，虎嗅再次遭受各种形势的攻击，但每次一遭受短暂的影响，我们的云服务商阿里云就及时提供协助，外部攻击始终没有对虎嗅造成太大的影响。
到3月1日攻击还在持续，但已经对虎嗅造不成什么威胁。这次虎嗅服务器反击战基本就收在了2013年2月。
借着这次虎嗅保卫战，我们感受到的是，云时代的攻击与防护方式与传统服务器托管时代有着鲜明的对比。
几年前网站遇到外部攻击，如果是小量，就提高自己的抗攻击能力，从性能和过滤方面着手；如果量级比较大，只能联系机房加大带宽、联系防火墙厂商提供更强大的过滤设备、增加物理服务器数量；攻击再猛烈一些，只能举白旗投降。
传统服务器托管时代，因为办公场所与托管机房之间有物理距离，所以整个过程折腾下来，至少需要6小时。
而在云时代，反击时间已经大大缩短：小攻击自动被过滤；云服务商们的弹性计算也可以提供无缝的性能提升来临时抵御攻击，响应速度、资源匹配上都更快更灵活，这使得网络攻击在未来可能再形不成恶意力量。
深度感谢靠谱的阿里云。感谢期间主动关心、给虎嗅伸出援手的安全宝、绿盟、湖盟、乌云、360以及诸多行内朋友，你们是嗅哥的安全感。