扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
震惊网络的熊猫烧香病毒。
成都创新互联公司坚持“要么做到,要么别承诺”的工作理念,服务领域包括:成都网站设计、网站制作、外贸营销网站建设、企业官网、英文网站、手机端网站、网站推广等服务,满足客户于互联网时代的鲅鱼圈网站设计、移动媒体设计的需求,帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴!
十四年前,中国骇客whboy(李俊)发布熊猫烧香病毒,因中毒电脑桌面上出现“熊猫烧香”图案名噪一时,这也成为了当时一度让人谈网色变的病毒。
熊猫烧香病毒可通过感染系统的*.exe、*.com、*.pif、*.src、*.html、*.asp文件,导致打开网页文件时IE自动跳转到指定病毒网址中下载病毒,同时出现蓝屏、频繁重启以及系统硬盘中数据文件被破坏等现象。
在短短几个月的时间,熊猫烧香感染门户网站、击溃数据系统、导致网络瘫痪,在全国范围内带来了无法估量的损失,“熊猫烧香”已经永远停留在十几年前。
总结如下:
如今看来,随着科学技术的发展和变革,熊猫烧香跟今天的勒索病毒、木马、黑客攻击等带来的危害完全不能相比,但该病毒却是国内民众第一次对计算机病毒的危害有了真实的感受,因此成为病毒史上的经典案例,对国内未来的网络安全发展起到了推动和警示作用。
一般来说,安全应急响应服务指的是一个组织为了应对各种意外事件的发生所做的准备以及在事件发生后所采取的措施。要弄清楚什么是数据中心安全应急响应服务的关键在于数据中心会针对哪些时间进行应急响应,以及数据中心在应急响应的时候具体要做哪些事情。
据成都电信西信中心IDC机房的专家介绍,数据中心作为网络的枢纽,数据云集,服务的客户各种各样,可能出现的安全事件也是层出不穷。比如服务器可能会因为访问客户数量过于庞大而导致系统崩溃、设备宕机,并进而导致数据丢失,对用户则将造成更大的损失。或者是系统中存在漏洞,使黑客、病毒有机可乘,进而导致信息泄露……等等。
至于安全响应即针对以上各种安全事件所采取的响应处理措施。一般应包括两个方面的内容:
1.未雨绸缪,即在事件发生前事先做好准备,比如风险评估、制定安全计划、安全意识的培训、以发布安全通告的方式进行的预警、以及各种防范措施;
2.亡羊补牢,即在事件发生后采取的措施,其目的在于把事件造成的损失降到最小。这些行动措施可能来自于人,也可能来自系统,是发现事件发生后,系统备份、病毒检测、后门检测、清除病毒或后门、隔离、系统恢复、调查与追踪、入侵者取证等一系列操作。
具体来说,以成都电信的西信IDC机房为例,在安全事件造成客户系统出现非正常运行时,电信安全工程师将按照SLA合同规定的时间,通过网络远程或现场服务的方式,利用多种安全技术手段根据工程师的丰富经验,分析事件的原因,协助客户在尽可能短的时间内恢复系统正常工作,并及时提供事故分析报告和安全建议。
解决办法:
1、点击抄浏览器上右上方的工具选项。
2、然后在展开的百列表项中选择Internet选项。
3、然后在Internet属性中选择高级设置。
4、拖动到安全区,把“检查发行商的证书是度否吊销知和“检查服务器证书吊销”前面的√去掉。
5、把选框里的√去掉后,在下面记得点击确定按钮。
6、最后重启浏览器道。(重启Internet explorer后生效)。
按照以上解决办法,可以解决弹出安全证书的吊销信息不可用问题。
关闭windows的安全警报的具体操作步骤如下:
1、在键盘上同时按住键盘组合键WIN+R。
2、调出运行任务栏之后,在运行框中输入知服务指令services.msc,然后点击确定按钮道。
3、之后进入服务(本地)列表,双击服务(本地)选项,然后就可以看到所有计算机的服务项目。
4、在服务(本地)列表中找到Security Center服务,然后双击鼠标左键内打开。
5、鼠标右键点击Security Center,然后双击属性选项,之后进入Security Center服务属性界面,选择启动类型--禁止。
6、选择完成后点击确定按钮,以后你的电脑就不会显示安全警报了。
按照以容上步骤操作即可关闭windows安全警报。
事件一:Google Gmail邮箱爆发全球性故障
Gmail是Google在2004年愚人节推出的免费邮件服务,但是自从推出这项服务以来,时有发生的“中断”事件就成为业界的广泛讨论的话题。
2009年2月24日,谷歌的Gmail电子邮箱爆发全球性故障,服务中断时间长达4小时。谷歌解释事故的原因:在位于欧洲的数据中心例行性维护之时,有些新的程序代码(会试图把地理相近的数据集中于所有人身上)有些副作用,导致欧洲另一个资料中心过载,于是连锁效应就扩及到其它数据中心接口,最终酿成全球性的断线,导致其他数据中心也无法正常工作。
事件过去数日之后,Google宣布针对这一事件,谷歌向企业、政府机构和其他付费GoogleAppsPremier Edition客户提供15天免费服务,补偿服务中断给客户造成的损失,每人合计2.05美元。
事件二:微软的云计算平台Azure停止运行。
2009年3月17日,微软的云计算平台Azure停止运行约22个小时。
虽然,微软没有给出详细的故障原因,但有业内人士分析,Azure平台的这次宕机与其中心处理和存储设备故障有关。Azure平台的宕机可能引发微软客户对该云计算机服务平台的安全担忧,也暴露了云计算的一个巨大隐患。
不过,当时的Azure尚处于“预测试”阶段,所以出现一些类似问题也是可接受。提前暴露的安全问题,似乎也给微软的Azure团队敲了一次警钟,在云计算平台上,安全是客户最看重的环节。
2010年,Azure平台正式投入商用,成为开发者喜爱的云平台之一。
Salesforce.com宕机事件
事件三:Rackspace云服务中断。
2009年6月,Rackspace遭受了严重的云服务中断故障。供电设备跳闸,备份发电机失效,不少机架上服务器停机。这场事故造成了严重的后果。
为了挽回公司声誉,Rackspace更新了所有博客,并在其中详细讨论了整个经过。但用户并不乐意接受。
同年11月,Rackspace再次发生重大的服务中断后。事实上,它的用户是完全有机会在服务中断后公开指责这位供应商的,但用户却表示“该事故并不是什么大事。”看来Rackspace不是走好运,而是持续提供了充足更新并快速修复了这些错误。
在服务中断致使其业务脱机15到20分钟后,博客服务提供商Posterous的创建者之一Sachin Agarwal就发表了自己的观点。Agarwal对此并不生气,相反,他表示Rackspace在这件事上做得“很透明”,处理问题也很及时到位。
看来,如果没有严重数据的丢失,并且服务快速恢复,用户依旧保持愉快的使用体验。对于所谓的“100%正常运行”,大多数用户似乎不会因为偶尔的小事故而放弃供应商,只是不要将问题堆积起来。
事件四:Salesforce.com宕机。
2010年1月,几乎6万8千名的Salesforce.com用户经历了至少1个小时的宕机。
Salesforce.com由于自身数据中心的“系统性错误”,包括备份在内的全部服务发生了短暂瘫痪的情况。这也露出了Salesforce.com不愿公开的锁定策略:旗下的PaaS平台、Force.com不能在Salesforce.com之外使用。所以一旦Salesforce.com出现问题,Force.com同样会出现问题。所以服务发生较长时间中断,问题将变得很棘手。
这场服务中断还没有对公司造成很大影响,它同VMware合作的VMforce在今年春季引起很大反响,同时Salesforce.com首席执行官在服务中断出现后的一个月内又开始宣称Salesforce.com是“最大的云计算企业”。
这次中断事故让人们开始质疑Salesfore.com的软件锁定行为,即将该公司的Force.com平台绑定到Salesforce.com自身的服务。但总之,这次事件只是又一次地提醒人们:百分之百可靠的云计算服务目前还不存在。
微软爆发BPOS服务中断事件
事件五:Terremark宕机事件。
2010年3月,VMware的合作伙伴Terremark就发生了七小时的停机事件,让许多客户开始怀疑其企业级的vCloud Express服务。此次停机事件,险些将vCloud Express的未来断送掉,受影响用户称故障由“连接丢失”导致。据报道,运行中断仅仅影响了2%的Terremark用户,但是造成了受影响用户的自身服务瘫痪。此外,用户对供应商在此次事情上的处理方式极为不满意。
Terremark官方解释是:“Terremark失去连接导致迈阿密数据中心的vCloud Express服务中断。"关键问题是Terremark是怎么解决这个突发事件的,这家公司并没有明确的方案,只是模糊地对用户担保,并对收到影响的用 户进行更新。如果一个运供应商想要说服企业用户在关键时刻使用它们的服务,这样的方式是达不到目的的。
Terremark的企业客户Protected Industries的创立者John Kinsella,在抱怨服务中断让他心灰意冷时称该供应商是“杂货铺托管公司”。Kinsella将Terremark与Amazon做了比较,他抱怨说,Terremark才开始考虑使用的状态报告和服务预警Amazon早已实现。
当然,在对vCloud Director的大肆宣传以及VMworld 2010兴奋地揭幕过后,Terremark服务中断事件似乎只留下了很小的余波。
事件六:Intuit因停电造成服务中断。
2010年6月,Intuit的在线记账和开发服务经历了大崩溃,公司对此也是大惑不解。包括Intuit自身主页在内的线上产品在内近两天内都处于瘫痪状态,用户方面更是惊讶于在当下备份方案与灾难恢复工具如此齐全的年代,竟会发生如此大范围的服务中断。
在赔偿方面,亚马逊表示,将向在此次故障中受到影响的用户提供10天服务的点数(Credit),这些点数将自动充值到受影响的用户帐号当中。但是,对于以后如何避免出现类似事件,并没有提到任何法律上的保证。
据了解,亚马逊云服务中断持续了近4天,但是在法律上却没有违反亚马逊EC2服务的服务等级协议(简称SLA)。亚马逊的解释是,亚马逊出现故障的是EBS和RDS服务,而不是EC2服务,从法律上讲,它并没有违反服务等级协议。并且,对于亚马逊提出的应对宕机事件的建议——多点备份,仅仅是一个技术规范并非合同保障。这些,似乎都不能给云服务的用户带来信心。
表面看来,亚马逊宕机事件似乎有一个完美结局:厂商及时修复漏洞,书面道歉,赔偿损失。但是,用户心理上对云服务的恐惧似乎并不那么容易康复,未来,亚马逊可能不仅仅要在技术上、还需要在制度和法律上给予用户更多的保证,才能才能渐渐修复被此次宕机事件损坏的名声。
历数频频发生的云服务事件
历数频频发生的云服务事件
不仅亚马逊,云计算领域充满竞争的其他公司,如谷歌和微软等,在近几年也频频发生云服务“中断”事件。
事件一:Google Gmail邮箱爆发全球性故障
Gmail是Google在2004年愚人节推出的免费邮件服务,但是自从推出这项服务以来,时有发生的“中断”事件就成为业界的广泛讨论的话题。
2009年2月24日,谷歌的Gmail电子邮箱爆发全球性故障,服务中断时间长达4小时。谷歌解释事故的原因:在位于欧洲的数据中心例行性维护之时,有些新的程序代码(会试图把地理相近的数据集中于所有人身上)有些副作用,导致欧洲另一个资料中心过载,于是连锁效应就扩及到其它数据中心接口,最终酿成全球性的断线,导致其他数据中心也无法正常工作。
事件过去数日之后,Google宣布针对这一事件,谷歌向企业、政府机构和其他付费GoogleAppsPremier Edition客户提供15天免费服务,补偿服务中断给客户造成的损失,每人合计2.05美元。
事件二:微软的云计算平台Azure停止运行。
2009年3月17日,微软的云计算平台Azure停止运行约22个小时。
虽然,微软没有给出详细的故障原因,但有业内人士分析,Azure平台的这次宕机与其中心处理和存储设备故障有关。Azure平台的宕机可能引发微软客户对该云计算机服务平台的安全担忧,也暴露了云计算的一个巨大隐患。
不过,当时的Azure尚处于“预测试”阶段,所以出现一些类似问题也是可接受。提前暴露的安全问题,似乎也给微软的Azure团队敲了一次警钟,在云计算平台上,安全是客户最看重的环节。
2010年,Azure平台正式投入商用,成为开发者喜爱的云平台之一。
Salesforce.com宕机事件
事件三:Rackspace云服务中断。
2009年6月,Rackspace遭受了严重的云服务中断故障。供电设备跳闸,备份发电机失效,不少机架上服务器停机。这场事故造成了严重的后果。
为了挽回公司声誉,Rackspace更新了所有博客,并在其中详细讨论了整个经过。但用户并不乐意接受。
同年11月,Rackspace再次发生重大的服务中断后。事实上,它的用户是完全有机会在服务中断后公开指责这位供应商的,但用户却表示“该事故并不是什么大事。”看来Rackspace不是走好运,而是持续提供了充足更新并快速修复了这些错误。
在服务中断致使其业务脱机15到20分钟后,博客服务提供商Posterous的创建者之一Sachin Agarwal就发表了自己的观点。Agarwal对此并不生气,相反,他表示Rackspace在这件事上做得“很透明”,处理问题也很及时到位。
看来,如果没有严重数据的丢失,并且服务快速恢复,用户依旧保持愉快的使用体验。对于所谓的“100%正常运行”,大多数用户似乎不会因为偶尔的小事故而放弃供应商,只是不要将问题堆积起来。
事件四:Salesforce.com宕机。
2010年1月,几乎6万8千名的Salesforce.com用户经历了至少1个小时的宕机。
Salesforce.com由于自身数据中心的“系统性错误”,包括备份在内的全部服务发生了短暂瘫痪的情况。这也露出了Salesforce.com不愿公开的锁定策略:旗下的PaaS平台、Force.com不能在Salesforce.com之外使用。所以一旦Salesforce.com出现问题,Force.com同样会出现问题。所以服务发生较长时间中断,问题将变得很棘手。
这场服务中断还没有对公司造成很大影响,它同VMware合作的VMforce在今年春季引起很大反响,同时Salesforce.com首席执行官在服务中断出现后的一个月内又开始宣称Salesforce.com是“最大的云计算企业”。
这次中断事故让人们开始质疑Salesfore.com的软件锁定行为,即将该公司的Force.com平台绑定到Salesforce.com自身的服务。但总之,这次事件只是又一次地提醒人们:百分之百可靠的云计算服务目前还不存在。
微软爆发BPOS服务中断事件
事件五:Terremark宕机事件。
2010年3月,VMware的合作伙伴Terremark就发生了七小时的停机事件,让许多客户开始怀疑其企业级的vCloud Express服务。此次停机事件,险些将vCloud Express的未来断送掉,受影响用户称故障由“连接丢失”导致。据报道,运行中断仅仅影响了2%的Terremark用户,但是造成了受影响用户的自身服务瘫痪。此外,用户对供应商在此次事情上的处理方式极为不满意。
Terremark官方解释是:“Terremark失去连接导致迈阿密数据中心的vCloud Express服务中断。"关键问题是Terremark是怎么解决这个突发事件的,这家公司并没有明确的方案,只是模糊地对用户担保,并对收到影响的用 户进行更新。如果一个运供应商想要说服企业用户在关键时刻使用它们的服务,这样的方式是达不到目的的。
Terremark的企业客户Protected Industries的创立者John Kinsella,在抱怨服务中断让他心灰意冷时称该供应商是“杂货铺托管公司”。Kinsella将Terremark与Amazon做了比较,他抱怨说,Terremark才开始考虑使用的状态报告和服务预警Amazon早已实现。
当然,在对vCloud Director的大肆宣传以及VMworld 2010兴奋地揭幕过后,Terremark服务中断事件似乎只留下了很小的余波。
事件六:Intuit因停电造成服务中断。
2010年6月,Intuit的在线记账和开发服务经历了大崩溃,公司对此也是大惑不解。包括Intuit自身主页在内的线上产品在内近两天内都处于瘫痪状态,用户方面更是惊讶于在当下备份方案与灾难恢复工具如此齐全的年代,竟会发生如此大范围的服务中断。
但这才是开始。大约1个月后,Intuit的QuickBooks在线服务在停电后瘫痪。这个特殊的服务中断仅仅持续了几个小时,但是在如此短时间内发生的宕机事件也引起了人们的关注。
即使一些用户要求“武装”其品牌,Intuit依旧拥有4百万用户并继续进军PaaS和Web服务供应商之路。公司没有Amazon和Rackspace这样的知名度,中断也没有造成很大的影响。Intuit主要因Quicken而闻名。
事件七:微软爆发BPOS服务中断事件。
2010年9月,微软在美国西部几周时间内出现至少三次托管服务中断事件向用户致歉。这是微软首次爆出重大的云计算事件。
事故当时,用户访问BPOS(Business Productivity Online Suite)服务的时候,如果使用微软北美设施访问服务的客户可能遇到了问题,这个故障持续了两个小时。虽然,后来微软工程师声称解决了这一问题,但是没有解决根本问题,因而又产生了9月3日和9月7日服务再次中断。
微软的Clint Patterson说,这次数据突破事件是由于微软在美国、欧洲和亚洲的数据中心的一个没有确定的设置错误造成的。BPOS软件中的离线地址簿在"非常特别的情况下"提供给了非授权用户。这个地址簿包含企业的联络人信息。
微软称,这个错误在发现之后两个小时就修复了。微软称,它拥有跟踪设施,使它能够与那些错误地下载这些数据的人取得联系以便清除这些数据。
微软的这一系列事件让那些一度考虑使用云计算的人感到忧虑,特别是让考虑使用与Office套装软件捆绑在一起的微软主要云计算产品Office 365的那些人感到担心。可见,就算是著名的微软公司,面对提供公有云服务的安全问题,也显得有些束手无策。所以,业界流程2011年将成为云计算应用之年,这一观点就很难让人信服了。
谷歌邮箱用户数据泄漏事件
事件八:谷歌邮箱再次爆发大规模的用户数据泄漏事件。
2011年3月,谷歌邮箱再次爆发大规模的用户数据泄漏事件,大约有15万Gmail用户在周日早上发现自己的所有邮件和聊天记录被删除,部分用户发现自己的帐户被重置,谷歌表示受到该问题影响的用户约为用户总数的0.08%。
谷歌在Google Apps状态页面表示:"部分用户的Google Mail服务已经恢复过来,我们将在近期拿出面向所有用户的解决方案。"它还提醒受影响的用户说:"在修复帐户期间,部分用户可能暂时无法登录邮箱服务。"
Google过去也曾出现故障,但整个帐户消失却是第一次。在2009年出现最严重的一次故障,有两个半小时服务停顿,许多人当时曾向Google投诉需用这个系统工作。接二连三出错,令全球用户数小时不能收发电邮。Google及微软等科技企业近年大力发展云计算,盼吸引企业客户,但云计算储存多次出事,恐打击用户信心。
事件九:亚马逊云数据中心服务器大面积宕机。
2011年4月22日,亚马逊云数据中心服务器大面积宕机,这一事件被认为是亚马逊史上最为严重的云计算安全事件。
由于亚马逊在北弗吉尼亚州的云计算中心宕机,包括回答服务Quora、新闻服务Reddit、Hootsuite和位置跟踪服务FourSquare在内的一些网站受到了影响。
4月30日,针对上周出现的云服务中断事件,亚马逊周五在网站上发表了一份长达近5700字的报告,对故障原因进行了详尽解释,并向用户道歉。亚马逊还表示,将向在此次故障中受到影响的用户提供10天服务的点数(Credit),将自动充值到受影响的用户帐号当中。
亚马逊在周五的报告中指出,公司已经知道漏洞和设计缺陷所在的地方,它希望通过修复那些漏洞和缺陷提高EC2(亚马逊ElasticComputeCloud服务)的竞争力。亚马逊已经对EC2做了一些修复和调整,并打算在未来几周里扩大部署,以便对所有的服务进行改善,避免类似的事件再度出现。
此事件也引起人们对转移其基础设施到云上的担忧:完全依靠第三方来去报应用程序的可用性是否可行。
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流