云计算之路-阿里云上:9:55-10:08因流量攻击被进黑洞,造成主站不能正常访问

在宇宙中有黑洞,在阿里云上也有。

9:52-10:08期间,由于遭受大流量的攻击,主站被阿里云云盾打入黑洞,造成主站不能正常访问,给大家带来了很大的麻烦!在这里我们表示深深的歉意,望大家能够谅解!

整个事情发生的过程是这样的:

9:52,收到阿里云的通知短信:

【阿里云】尊敬的用户:您的IP正遭受外部流量攻击,已启动云盾DDoS基础防护的免费套餐。当攻击流量超过免费套餐的阈值时,服务器所有访问将被屏蔽。为避免影响云服务器正常使用,请登录官网购买DDoS高防IP服务,轻松解决DDoS攻击困扰。

这时攻击流量不是很大,云盾正常进行清洗,网站正常访问未受影响。

上云盾控制台查看,触发清洗是由于入网报文速率达到 609535 个/秒。

9:55,突然发现主站不能访问!同时收到阿里云的通知短信:

【阿里云】尊敬的用户:您的IP受到攻击流量已超过云盾DDoS基础防护的带宽峰值,服务器的所有访问已被屏蔽,2.5小时后将自动解除。您可登录官网购买DDoS高防IP服务,轻松解决DDoS流量攻击困扰,保障服务器的正常运行。

也收到了阿里云的通知邮件:

阿里云盾黑洞开始通知

尊敬的用户:
 
    您的云服务器当前受到大流量攻击,已被流量屏蔽,2.5小时后自动解除。

疯掉了!竟然进黑洞了,要被屏蔽2.5小时。

紧接着,我们立即采取了这样的行动:

1)立即更改DNS解析,将主站解析到另外一台SLB。虽然DNS解析完全生效需要一定的时间,但至少可以让新访问或者DNS缓存已更新的用户能正常访问。幸好主站使用了2个SLB,只需要更改DNS解析就行了,不然购买SLB加上挂服务器需要一些时间。这样的措施让大部分用户在5分钟内能恢复正常访问,减少了故障影响。

2)联系阿里云,争取能帮我们临时解除屏蔽。攻击可能只是短时间,强行屏蔽2.5小时实在太残忍。

10:08,阿里云解除屏蔽,将主站被攻击IP从黑洞中救了出来之后,主站所有访问恢复正常。

出黑洞之后,由于“连接数超过清洗阈值”,继续被云盾清洗,但网站访问不受影响。

10:52,云盾清洗也结束了。

上云盾控制台查看,9:55触发进黑洞的攻击流量是25G。

整个“攻击->清洗->黑洞”的过程在云盾控制台也有清楚的记录:

时间: 2024-10-27 07:50:12

云计算之路-阿里云上:9:55-10:08因流量攻击被进黑洞,造成主站不能正常访问的相关文章

云计算之路-阿里云上:排查“黑色30秒”问题-为什么请求会排队

http://www.cnblogs.com/cmt/p/3682642.html 针对Web服务器“黑色30秒”问题(详见云计算之路-阿里云上:Web服务器遭遇奇怪的“黑色30秒”问题),经过分析,我们准备从这个地方下手——为什么会出现\ASP.NET\Request Queued大于0的情况(为什么请求会排队)? 首先, 通过Windows性能监视器去观察,看能不能找到这样的线索——在什么条件下会触发请求排队? 我们在性能监视器中增加了1个监视指标——\HTTP Service Reques

云计算之路-阿里云上:Wireshark抓包分析一个耗时20秒的请求

这篇博文分享的是我们针对一个耗时20秒的请求,用Wireshark进行抓包分析的过程. 请求的流程是这样的:客户端浏览器 -> SLB(负载均衡) -> ECS(云服务器) -> SLB -> 客户端浏览器. 下面是分析的过程: 1. 启动Wireshark,针对内网网卡进行抓包. 2. 在IIS日志中找出要分析的请求(借助Log Parser Studio) 通过c-ip(Client IP Address)可以获知SLB的内网IP,在分析Wireshar抓包时需要依据这个IP进

云计算之路-阿里云上:超过70秒的请求抓包分析

超过70秒的请求是通过分析IIS日志发现的: 10.159.63.104是SLB的内网IP. 通过Wireshark抓包分析请求是9:22:21收到的(tcp.stream eq 23080): 09:22:21.299838000 10.159.63.104 10.161.241.208 HTTP 291 GET /eastsea/p/3764040.html HTTP/1.0 这个请求响应内容的长度是:Content-Length 1154110(1.1MB) 云服务器(ECS)在收到请求后

云计算之路-阿里云上:对“黑色n秒”问题的最终猜想——CPU C-states引起的

如果说2013年云计算之路的主题是"踩坑",那么2014年我们希望云计算之路的主题变成"填坑"--当然填坑是阿里云来完成的,我们只是见证曾经的坑坑洼洼变成平坦大道. 15号(周四)晚上我们发现了SLB会话保持的坑,16号晚上阿里云成功定位并进行修复,这两天正式发布后会填平这个坑.这次从踩坑到填坑的过程是最痛快的一次. 接下来我们的目标锁定在"黑色n秒"(刚发现一个英文说法:stuck for x seconds)这个坑我们最多.最神秘.最诡异的坑

云计算之路-阿里云上:CPU 100%引发的状况

今天下午17:00-17:05之间,在请求量没有明显变化的情况下,SLB中的1台云服务器的CPU突然串到100%(当时SLB中一共有3台云服务器),见下图: 造成的直接后果是请求执行时间变得超长,最长竟然达到了53秒(下图中的紫色线条). 另外伴随的表现是大量请求排队. 再看看这个时间段其它2台服务器的表现: 从这些现象分析,我们猜测CPU 100%这台云服务器出现了CPU资源争抢问题,将之从SLB中摘除后恢复正常. 云计算之路-阿里云上:CPU 100%引发的状况,布布扣,bubuko.com

云计算之路-阿里云上:什么是“黑色1秒”?

为了更好地分享我们解决"黑色1秒"问题的过程,在这篇博文中我们将专门描述一下"黑色1秒"问题的表现. "黑色1秒"是我们使用阿里云以来继"黑色10秒"之后遭遇的最奇特.最诡异.最难以捉摸.最富有戏剧性的问题. 它有2个最显著的特征: 第一个是最直观的表现,在Windows性能监视器(Performace Monitor)中会出现1秒的ASP.NET Applications -> Requests/Sec(简称QPS)为

云计算之路-阿里云上:消灭“黑色n秒”第一招——不让CPU空闲

昨天对"黑色n秒"问题的最终猜想以失败而告终,从而让我们结束了被动猜想阶段,进入了主动进攻阶段--出招. 今天出第一招--用C#写个小程序,让其在每个CPU核上运行一个线程,不让任何一个CPU核进入空闲(idle)状态,以进一步排除CPU idle引起的"黑色n秒". 在这一招中,借助的最重要的武器是System.Diagnostics.ProcessThread.ProcessorAffinity.通过给ProcessorAffinity设置一个掩码,就可以指定当

云计算之路-阿里云上:消灭“黑色n秒”第二招——给w3wp进程指定CPU核

虽然昨天的第一招失败了,但是从失败中我们学到了与多核CPU相关的Processor Affinity(处理器关联)的知识. 既然我们可以让.NET程序的不同线程运行于指定的CPU核,那是不是也可以让IIS应用程序池的进程w3wp运行于指定的CPU核? 虽然看起来"黑色n秒"似乎与w3wp运行于哪些CPU核没有什么关系,但是我们既然把怀疑对象锁定在CPU,那么任何与CPU相关的线索都不能放过.即使失败,也会满载而归,因为如果没有"黑色n秒"这个问题的驱动,我们根本不会

云计算之路-阿里云上:“黑色1秒”问题与2009年Xen一个补丁的故事

在之前对"黑色1秒"问题的分析博文中,我们将最大嫌疑对象锁定在了Xen,在这篇博文我们将从Xen的角度进行分析.也许有人会问,为什么不知道天多高地多厚地去研究不属于自己范围的问题?只因我们对一个问题的强烈好奇心--究竟是不是我们用Windows的错? 2009年3月20日,来自Intel的Yu Ke通过Xen-dev Mailing List给来自Citrix的Keir Fraser(负责的Xen开发者之一)发了一封邮件,提交了Xen的一个patch--cpuidle: suspend