假冒谷歌爬蟲成為第三大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原創文章 ?作者:李智勇