假冒谷歌爬虫成为第三大DDoS攻击工具

在安全牛之前发布的文章《 Prolexic发布2014年第一季度全球DDoS攻击报告》中,我们了解到采用“反射放大”技术发起的攻击流量比上一季度增加了39%,同时攻击者也在不断发掘利用其他一些互联网基础服务来发动DDoS攻击,例如今年3月安全公司Sucuri发现 黑客利用超过16.2万WordPress网站的Pingback功能进行大规模DDoS放大攻击

近日,新的研究表明,假冒谷歌爬虫已经成为第三大DDoS攻击工具,详情如下:

Incapsula研究人员在调查了搜索引擎在1万家网站上的4亿次搜索访问后,发现超过23%的假冒谷歌爬虫被用于DDoS攻击,10.8%被用于窃取数据的恶意软件、垃圾邮件和扫描器。

 

分析结果中的一些亮点对于很多对于SEO专业人士和网站运营者来说非常有趣:

谷歌的web爬虫比其竞争对手(如MSN/Bing、百度和Yandex bots)的要活跃深入得多。

被谷歌爬虫访问次数多的网站,其自然流量份额并不会随之增长,这意味着谷歌对网站并没有特殊关照。

平均每个网站每天会被谷歌爬虫访问187次,每次访问平均抓取深度是4页。内容密集型以及频繁更新的网站,例如论坛、新闻站点、大型电商网站被爬虫光顾的次数较多。

由于谷歌依然是全球第一搜索引擎,因此绝大多数网站运营者都不会屏蔽谷歌爬虫,但遗憾的是,这也导致假冒谷歌爬虫得以大行其道,发起DDoS攻击、剽窃内容、发送垃圾信息甚至入侵系统。

假冒的谷歌爬虫能以谷歌的身份获取网站信息,它们利用了谷歌爬虫的HTTP(S)用户代理——功能相当于一个访客的ID。根据Incapsula收集的数据,超过4%的使用用户代理的爬虫都不是真正的谷歌爬虫。

通过分析5000万个假冒谷歌爬虫会话数据,Incapsula发现高达34.3%的假冒爬虫都是恶意的,其中23.5%被用于7层DDoS攻击。

假冒谷歌爬虫发起的DDoS攻击让网站经营者非常难办:要么屏蔽所有谷歌爬虫,从搜索引擎中消失,要么购买更多带宽来防范DDoS。

假冒谷歌爬虫的访问通常来自僵尸网络,排名靠前的流量大国依次是美国(25.2%)、中国(15.6%)、土耳其(14.7%)、巴西(13.49%)和印度(8.4%),而正牌的谷歌爬虫则98%都来自美国。

好消息是,人们如今可以通过一系列安全手段精确识别假冒谷歌爬虫,包括IP和ASN核对——一种通过来源地识别爬虫的技术流程,但遗憾的是,中小网站通常不掌握这些手段。

Infonetics:截止2016年将有87%的机构使用SDN

近日,市场调研公司Infonetics公开了2014 SDN Strategies的部分信息。在North American Enterprise Survey中,他们对机构在数据中心及园区LAN中部署SDN的需求趋势进行了分析。Infonetics Research的数据中心、云计算、SDN分析师Cliff Grossner表示:

现下SDN的需求给已存或者未来的供应商提供了大量机会,SDN市场中的企业级领先供应商将在两年内得到大力的发展。鉴于SDN的发展年限,在2015年将发生大量的SDN测试到生产环境部署,而在2016年更会有一个飞速的增长。

即使SDN拥有如此大的需求,但是这里仍然有许多工作需要完善,其中最大的担心来自技术成熟度和业务的模型,解决方案提供商需要与他们顶级客户一起完成实验环境到生产环境的转变过程。

相关数据

Infonetics的受访企业已经计划在两年内扩大他们数据中心及LAN规模,并在服务器和LAN交换机设备上投入大量的资金,其中有大量的受访企业已经开始SDN实验环境部署,也有一部分表示会在今年内部署。

45%的受访者表示希望在2015年投入生产环境,而到2016年这个比率将上升到87%。在所有调查者中,最大的需求来自管理能力和应用程序性能的提升,而网络的突然中断和互操作性则是最大的障碍。与此同时,允许混合云的需求排在了最后一位,因此提供商还需要做更多的推广,让用户了解SDN对于混合云架构的重要性。在所有受访者中,17%机构的数据中心直接建立在实体交换机之上,只有21%的受访者使用了SDN。接近有1/4的被调查者准备考虑非传统网络提供商。

【畅言】从程序员到架构师的方法与逻辑

架构师是什么?

架构师这词其实很有意思,很多人的Title是这个,但其实我们对架构师都干什么并没有太统一的认识。往大了说,比尔盖茨当年好像也称自己为架构师,往小了说随便一个小的软件上做设计的也说自己是架构师。所以如果把这个词泛化而不局限于特定的场景,估计单是说清楚什么是架构师就要花费不少口水。下面我们用一个取巧的办法,在一个具体的场景下来看看,架构师都该干什么,而不把这个词泛化,如果在特定场景下这个角色应该干什么清楚了,那它就可以为其它场景下提供不错的参考。

我们只考虑从头开发一款产品的场景,不考虑这款产品可能是个家族,可能需要在公司里与许多东西配合这样繁琐的事情。这样问题就简化成:当我们要开发一款新产品的时候,架构师都要干些什么?为让事情更具体,我们进一步假设公司想做一个Trello,Worktile这样的协同办公工具。

在产品初期除了UI这类东西,还能明确的一些关键需求大概是这样:

 

  • 简单、迅速,追求极致的用户体验,这时也许能想到看板这样的功能
  • 打入社交元素(任务分配与沟通时打入信息流的机制)
  • 移动端支持
  • 公司判断:如果产品能在1年内上线,时机比较好

 

其他的需求呢就是感觉上肯定有,但暂时说不清楚

基于这样的简单提示,长做程序的可能脑子里会立刻冒出来无数东西,比如:

 

  • 快的确保?
  • 看板里拖动的实现?
  • SaaS时伸缩性的确保?
  • 数据库中表的设计?
  • 数据库类型的选择?
  • 移动端的支持方式?
  • 人员的现状?
  • 迭代式开发的支持?
  • … …

 

但显然不是每个事情都要在架构设计阶段搞定,否则等于是被弄蒙了,这时候架构师的一个关键职责就是要能区分出哪些东西预先需要搞定,而哪些东西则要在迭代过程中解决。

一般来讲重置成本越大,牵涉的人越多的事情越应该由架构师预先搞定,否则就容易做无用功,对开发工作产生致命伤害。具体来讲这类事情由三个核心部分组成:

 

  • 选定Tech Stack
  • 概要设计,确立分工的基础
  • 协同方式

 

下面来分别解释下这三个方面的具体含义。

选定Tech Stack是指要选定包括编程语言,基本框架等一系列东西,比如Trello选完之后大致是下面这个样子:

图片来自网络(出处

这事情几乎是不可重置的,因为重置成本已经到了正常团队不可能负担的地步。所以Tech Stack与待开发产品的吻合程度是非常体现架构师价值的地方。选了Tech Stack但发现无法达成产品目标是架构设计上最差的结果,也正因为输不起,在这个环节上可以慎重些。这种Tech Stack的选择受限于上述所说的关键需求,比如快,支持移动端等。也就是常说的从需求的模型想技术模型的映射。

了解些技术的应该一眼可以看出来上面这张图是MEAN(MongoDB,Express,AngularJS。。。,NodeJS)架构,这架构满足上面关键需求是没问题的,但如果关键需求里有一条叫以灵活的插件结构来满足不同用户的定制化需求,上面这架构可能就有点麻烦了。

不管怎么样Tech Stack架构师第一个需要搞定的事情,没这个什么活也干不了。

再其次则是相对比较传统一点的部分,不管从哪里开始迭代,总是要切分前端后端的职责,设计彼此交互的接口,要区分出来哪些是纯工具型的模块(比如日志),哪些是基础设施型的(比如用户管理与权限),哪些是可以彻底进行迭代的(比如具体的某个功能)。这些东西之间是有一种内在的时序关联的,不是简单一句:我们迭代吧,我们测试驱动开发吧,就可以的,那会导致很大的混乱,所以这里也是架构师要扮演角色的地方。传统上管这个叫概要设计,虽然这词现在不怎么用了,但这词其实还不错的。当然架构师不一定要一个人搞定所有这些事情,而是要肩负起协调大家搞定这些事情的职责。这个地方依赖于产品的类型对业务知识的要求程度不同:一般来讲越是面向个人的产品,在业务知识上要求越低;越是面向企业的产品业务知识的要求越高。简单讲做天气应用的时候可能直接做就行了,但做财务应用时了解财务的某些知识就挺必须的。

最后一项则是分工后的一种协作的方法,这里面包含着分支策略,持续集成策略等。

显然的,下面两种分支策略下,团队的协作方式不一样.。

图片来自网络(出处

这是又一个全局性的工作,干活前需要预先定下来应该也是没疑问的,但是不是架构师搞定这事上,不同人的认知可能会不一样,有的人会认为应该是项目经理类的角色来搞定这事情。我个人则坚持认为理想情形下应该架构师搞定这事,因为分支策略等受技术的约束更大。

这就是我理解中架构师的要干的三类活:选择Tech Stack,概要设计来确立分工的基础,确立协同的方式。

在开发产品时,这三样事情不搞定,迭代都不好迭代。抽象点来看是这样:假设说在现有人员的基础上,预先搞定某问题需要耗费的成本为X,而迭代后,事到临头再处理,其耗费的成本为Y,那么无疑的Y>X的问题都应该是尽可能预先处理的问题,而不能以迭代为借口堂而皇之的进行忽视。而上述三方面问题,基本上是Y>X这类。

如何成为架构师?

首先想说的是程序员不一定要成为架构师的,优秀的程序员一样很有价值,但关键要看技术领域,我在程序员可以只关心技术么? 专门说过这事,这里不再展开。

真要想成为架构师事实上总是有两类方法,这两类方法倒不局限于架构师的学习,而是普适于任何学习。

一种是从概念规则到实践,一种则是从实践总结出概念和规则。数学更近似前者,而历史更近似后者。当我们试图先抽象出什么是架构设计,架构设计又有那些原则,之后再让大家了解现实中的架构设计如何做时,无疑的采取的也是前者的方式,也就是数学的方式。这种方式在现实中比较常见,但在逻辑上是有问题的:正是因为对架构设计的不理解,才尝试学习架构设计,即如此想学习的人天生在了解架构设计的概念与原则会遭遇困难。

出于这样一种考虑,最好的办法其实是先了解一些最基本概念,比如前面说的那些,再了解一些最基本的原则,比如:正交,信息隐藏等。之后就不在抽象概念层面打转了。而了解多个现有典型产品的架构,比如上面说的Trello,WordPress等。这时候最好对产品归类,在特定类别下抽象出来一些典型的架构模式。比如:软硬一体产品的架构,CMS的架构等。这样一来,如果一个人可以主要学习其中之一,顺道了解其余,那就可以比较迅速的掌握架构设计的知识,至少是上面说的架构设计中的前两类知识:Tech Stack的选择与概要设计。在开源的时代里,这已经成为一个人坐在家里就可以完成的事情了。

一点呼吁

最后做一点呼吁。现在各种架构设计的课程还是比较多的,但基本上都是按照第一条思路来的,比如:讲架构设计时会去尝试把架构设计分解为逻辑架构,运行架构等。从身边人的效果来看,普遍不太理想。有实力的培训机构可以尝试总结架构的模式,以一个总纲带领几个典型领域的架构分析,比如:CMS就参照WordPress来讲架构,基础JavaScript库就参照Backbone这种等。也不用太多,覆盖典型的4~5个领域就可以解决很大的问题了。这应该会更有效果,但课程创建上会比较吃力些,真想做的人要有思想准备。我个人曾经尝试和南京的TalenCamp按照第二条路来设计课程,但由于各种原因暂时进展不太大。

本文为CSDN原创文章  作者:李智勇