1、DDOS攻擊的來源linux
任何攻擊都不會憑空產生,DDOS也有特定的來源。絕大多數的DDOS攻擊都來自於僵屍網絡。僵屍網絡就是由數量龐大的可聯網殭屍主機組成,而殭屍主機能夠是任何電子設備(不只是X86架構的設備,更多反而是物聯網中的ARM架構設備),只要被植入殭屍程序便可!web
僵屍網絡有一個特色:控制者和殭屍主機之間存在一對多的關係,在控制者發佈命令後就能夠斷開與僵屍網絡的鏈接,以後控制命令會在殭屍主機之間自行傳播和執行。算法
僵屍網絡架構通常有如下兩種:後端
一、client—to—server型:緩存
client—to—server型僵屍網絡是一種典型的星型拓撲,由若干殭屍主機和控制服務器兩部分組成。安全
這種僵屍網絡相對比較傳統,殭屍主機在被植入殭屍程序後會主動鏈接一個固定的地址(即控制服務器),而後由控制服務器進行集中管理。服務器
這類的僵屍網絡控制相對較容易,並且能快速分發控制者的命令,可是這種控制方式也存在兩個重要的不足:網絡
①、控制服務器一旦故障則整張網絡失效架構
②、從殭屍主機側能夠查出控制服務器的地址(容易被抓)併發
P2P型:
相比client—to—server型P2P型就顯得略微複雜一些。在P2P型僵屍網絡中充當控制服務器的節點再也不單一,而是每臺殭屍主機既扮演控制服務器的角色又扮演客戶端角色。這樣就解決了傳統client—to—server型僵屍網絡控制服務器單點故障的問題。固然,隨之而來的是更加複雜的網絡拓撲維護算法。
這種僵屍網絡每臺殭屍主機都有一張有限的鄰居表,並週期性的向其鄰居表內的主機發送keeplive包來維護整個僵屍網絡。每臺殭屍主機在被植入殭屍程序的時候會將上游的鄰居表一同植入,並將上游殭屍主機做爲主下一跳,鄰居表內的其餘主機做爲備下一跳(主失效後備上位,確保網絡不中斷),而後繼續感染其餘主機,在成功感染下一臺主機後將對自身鄰居表進行優化(將自身做爲鄰居表中的一員,並隨機刪掉一個老鄰居)後傳遞給被感染主機,以此遞歸循環下去,最終構成一張龐大的僵屍網絡。(學過網絡的同窗必定以爲這跟路由協議一模一樣)
那麼攻擊者是怎樣來控制這樣一張僵屍網絡呢? 攻擊者只須要與這張網絡中的任意一臺殭屍主機進行通訊(通常須要通過認證)便可今後節點注入其控制命令,而後指令就如同走馬觀花的水波同樣向周圍擴散,直到擴散至這張網絡的邊緣。固然,在殭屍主機收到指令後會先判斷該指令是否已經存在,如已存在則不處理(僵屍網絡也須要防環)
站在監察者的角度來講,經過捕獲一個節點能夠發現此僵屍網絡的許多殭屍主機,但卻很難看到其全貌(這根繩子不知道捋到何時算個頭)
2、DDOS攻擊類型:
攻擊服務端的:
一、攻擊帶寬型:
①、直接攻擊目標型:
向目標發送大量數據包,以佔滿被攻擊者的帶寬,從而實現拒絕服務的目的。例:
UDP洪水攻擊:
這是一種最簡單粗暴的方法,利用UDP協議直接向目標發送大量的數據包來堵塞對方帶寬。可是這種方法對自身要求也極高,屬於傷敵一千自損也一千的行爲(假如對方帶寬10G,那本身這邊也須要10G的帶寬才能夠)。
每每攻擊者在帶寬資源方面處於劣勢,這時他們就會想,有沒有能夠以小博大的方法呢?有!那就是利用反射攻擊。。。即:自身發出1G的流量,通過反射器放大後變爲10G甚至更大的流量!
反射攻擊的原理:
攻擊者使用殭屍主機向放大器發送大量請求數據包,這些數據包的特別之處在於源IP地址爲被被攻擊目標的IP地址。反射器在收到數據包時會認爲數據包是由攻擊目標所發來的請求,因此會將響應數據發送給攻擊目標。當大量的響應數據包發向攻擊目標時就會耗盡攻擊目標的網絡帶寬,形成拒絕服務攻擊。
反射攻擊通常用來作放大攻擊使用,不少網絡協議的請求和響應數據量差異很大(有的協議最大響應數據能夠是請求數據的成百上千倍),反射放大攻擊也正是利用了這點,故反射器的放大倍數越大攻擊所產生的流量也就越大。
在互聯網上能夠用來作反射器的設備不少,一般只需無需認證或握手就行。由於增長了一個反射步驟,因此更加難以溯源攻擊來源。
下面列舉一些比較常見的反射放大攻擊類型:
DNS反射攻擊
NTP反射攻擊
SNMP反射攻擊
②、攻擊中間鏈路型:
攻擊鏈路型與攻擊目標型相比,最根本的區別在於攻擊的目標不一樣。攻擊鏈路型攻擊的目標不是做爲互聯網端點的服務器帶寬資源,而是骨幹網上的鏈路帶寬資源。當黑客將用戶到達目標服務器中間的鏈路帶寬資源耗盡時,用戶的流量就不能正確轉發至目標服務器了,從而形成拒絕服務工具。(不過這種攻擊有一個反作用,就是被攻擊骨幹網下游的全部服務器都將受牽連。筆者所在公司就曾由於微博被打而誤傷)
二、攻擊系統資源型:
不少雲安全廠商在宣傳時都會以「咱們防住了XXXGB流量的DDOS攻擊」來描述攻擊的猛烈程度,這種宣傳方式容易讓人誤覺得只有大流量纔是DDOS。其實是除了帶寬資源,DDOS攻擊還能夠是消耗系統(好比CPU、內存、網絡鏈接表等)。例如SYN洪水攻擊,不少時候人們容易把它認爲是消耗帶寬型的DDOS攻擊,實則否則,它最大的危害在於消耗系統鏈接表資源。
在消耗系統資源型中大體可分爲這麼三類:
①、消耗網絡鏈接表型
在TCP三次握手進行中,服務器會建立並保存TCP鏈接的信息,這個信息一般被保存在鏈接表結構中。可是鏈接表的大小是有限的,linux默認一個端口最大支持1024個鏈接(能夠經過ulimit -n來查看支持最大鏈接數),一旦服務器的鏈接表滿了就沒法再建立新的TCP鏈接了。
此時,攻擊者就能夠利用大量殭屍主機,經過創建大量惡意的TCP鏈接佔滿被攻擊目標的鏈接表,使目標沒法接受新的TCP鏈接請求,從而達到拒絕服務的目的。
②、消耗內存型
在服務端優化了最大鏈接數後鏈接數將再也不是瓶頸,可是每條鏈接總要佔用內存資源吧,這麼說來只要和目標創建足夠多的TCP鏈接就能夠將目標設備內存佔滿了。可是有個前提,就是創建TCP鏈接後不能撒手。
相比其餘洪水攻擊來說這種方式在速度上能夠不用那麼快,不是一拳就把對方打到,而是在前面壓力不釋放的前提下一點一點的給對方累加壓力,直到到達對方的性能瓶頸爲止。這種攻擊也俗稱:慢速DOS攻擊!
面對web服務有這麼幾種常見的維持長連接手段:
一、將content-length設爲一個較大的值,可是每次http body只緩慢的發送一個較小的值,這樣將一個大數據分屢次且有間隔時間的發送就可延長和服務端的鏈接
二、攻擊者將自身的TCP窗口調爲一個很小的值,這樣目標就會將一個較大的數據切成很小的塊分屢次返回,以此來拖延傳輸時長
三、在http協議中規定,http頭部以連續的'\r\n\r\n'做爲結束標誌,所以攻擊者能夠一直不發'\r\n\r\n'好讓服務端覺得客戶端的請求還沒發送完畢而處於等待狀態
經典的慢速DOS攻擊工具:slowhttptest
③、消耗CPU型
在系統資源裏還有最重要的一項資源,那就是cpu! 若是目標設備開啓的服務裏有須要大量計算的地方那對於攻擊者來講將會是很大的誘惑。好比說你提供的服務有3項功能,其中一項明顯比另外兩項更加消耗cpu資源,那攻擊者就能夠專挑你這個最耗cpu的功能來瘋狂使用,直至將你的cpu資源耗盡!
最多見的消耗cpu攻擊爲ssl攻擊。在ssl協議握手過程當中須要使用非對稱密鑰算法進行加解密運算,而非對稱加解密運算又十分消耗cpu資源,因此ssl協議成了攻擊者實行DOS攻擊的樂土。攻擊者能夠經過反覆不斷地進行ssl協商來耗盡目標cpu資源,以達到拒絕服務的目的
經典的SSL協商DOS攻擊工具:thc-ssl-dos
三、攻擊應用資源型:
一些應用程序可能自身就存在拒絕服務漏洞,此時不用大量的殭屍主機,只須要使用一臺設備向目標程序發送指定惡意代碼就可以使目標服務程序崩潰,以此達到拒絕服務攻擊的目的。
四、攻擊場景舉例(彩蛋! 站在攻擊者視角來進行一次DDOS攻擊,請勿用於實際環境):
①、DNS攻擊:
小明想讓某小區不能上網。但因爲本身手頭帶寬資源有限,沒有能力來堵塞小區出口帶寬。因而小明就想,你們上網除了要使用網絡外還須要什麼呢?對!DNS服務器!並且小區用戶的DNS大可能是使用DHCP的方式來獲取的,那就是說有很大機率他們用的是同一臺服務器,並且這臺服務器的地址很容易獲取到(假設這裏的DNS服務器地址是1.1.1.1)。
如今被攻擊目標就肯定了,只須要把這臺DNS服務器搞定就能夠搞定一片用戶。那麼這臺DNS服務器該怎麼拿下呢? 滲透?一時半會兒恐怕搞不定。。。 社工?好像有點難度。。。 拒絕服務?好像能夠琢磨琢磨。。。
小明想,DNS的正常業務邏輯是提供域名解析服務,那隻須要讓它超負荷工做就能起到拒絕服務攻擊的目的了呢。那怎麼才能讓它超負荷工做呢?正常狀況下DNS服務器收到一個查詢請求後先看是否能命中本身的緩存,若是不命中才會向上級DNS進行查詢。。。就是這!DNS的緩存機制緩解了它很大一部分壓力,我只須要讓它的緩存機制失靈就能夠增大它的壓力了!因而小明使用多臺肉雞向該DNS服務器瘋狂發送不一樣域名的解析請求,致使該DNS服務器的緩存不斷被刷新,而大量解析請求不能命中緩存從而必須消耗額外的資源進行迭代查詢,最終致使這臺DNS不堪重負不能及時處理正常的業務請求。
隨後小區居民紛紛向運營商投訴寬帶不給力,網太卡甚至網不通。(網絡工程師們哭暈在廁所,又躺槍!)
②、WEB攻擊
小明此次又瞄上了某網站,爲了讓用戶不能正常的訪問該網站小明真是撓破了頭,偵查了半個月也沒找到能夠滲透的點。因而小明決定來個魚死網破,直接D它!
仍是因爲上面那個緣由,小明這種個體戶手裏的帶寬資源比較有限,打大流量的DDOS不太現實。而後小明就想了,雖然我手裏的肉雞都比較「瘦」,但麻雀雖小五臟俱全啊,它再「瘦」也總有65535個端口吧! 打打慢鏈接攻擊消耗消耗目標設備的內存仍是能夠的嘛!
小明想,既然目標提供的是web服務,那隻須要和目標創建HTTP後不撒手就行了。在HTTP的頭部信息中正好有一種頭部信息能夠用在這裏,那就是Content-Length。當web服務器收到含有Content-Length的請求時,服務會將該字段的值做爲http請求包的body長度,利用這個特色就能夠長時間與web服務器保持鏈接。若是目標服務器上新來的全是這種只握手不撒手的鏈接,那用不了多久服務端的內存資源就耗盡了。想到這裏小明還有有點小激動呢。。。
心動不如行動,因而小明將手裏肉雞的每一個端口都儘量的利用起來,向目標發送一個Conetent-Length爲10000的POST請求,而後將POST body以很是緩慢的速度一個字節一個字節的向web服務器發送。此時,目標服務器須要一直維持與小明的鏈接來等待其數據傳輸結束。因爲小明一臺肉雞就可產生幾萬的併發,那麼沒用多少臺肉雞就成功將目標服務器內存撐滿(假設目標服務器內存爲32G,32G內存最大也就支持幾十萬併發),最終致使目標服務器不能與新來的正經常使用戶創建鏈接。
攻擊客戶端的:
在傳統概念裏通常提到DDOS通常都是打服務端,其實否則,攻擊客戶端側也有相似的攻擊。好比說RST洪水攻擊!
在已經創建TCP握手的鏈接中,若是收到對方發來的RST置位的TCP包,該TCP鏈接將強制斷開。正是利用這點,攻擊者能夠冒充客戶端來向服務端發送RST報文以打斷客戶端與服務端的鏈接,起到對客戶端拒絕服務的目的。可是想要讓服務端接受本身僞造的RST報文須要端口號和序列號都對得上才行。大多數環境下攻擊者又難以捕獲實際流量,此時攻擊者就能夠利用大量殭屍主機冒充客戶端向服務端發送隨機的端口號和序列號組合來撞運氣,一旦撞對了該客戶端就將失去與服務端的鏈接關係。
3、DDOS的緩解方案
DDOS這種攻擊如今誰也不能保證能夠100%根治,只能是最大限度的緩解這種攻擊帶來的影響。經常使用的緩解DDOS手段有三種:
一、CDN:
CDN技術的初衷實際上是爲了提升互聯網用戶對網站靜態資源的訪問速度。但因爲其分佈式的特色,用戶訪問過來的流量實際上是分散在不一樣機房的。一樣的,它也可以對分佈式拒絕服務攻擊的流量產生稀釋分散做用。
其實CDN的本質就是在互聯網範圍內設置多個節點做爲代理緩存,並將用戶的訪問請求導向最近的緩存節點,以減小網絡訪問延遲的一種技術。
那用戶是怎麼就被導向最近的緩存節點了呢?這個裏面就要用到DNS調度了。在DNS系統中,一個域名會對應一張IP地址表,當收到域名解析請求時,DNS會查看DNS請求的源IP地址,再根絕這個源IP地址來決定將域名解析解析至哪一個CDN節點。當CDN節點收到用戶的請求時,首先在其緩存內容中尋找用戶請求的資源,若是找到則直接返回給用戶;若是找不到,則CDN節點會做爲代理服務器向源站請求該資源,獲取資源後再將結果緩存並返回給用戶。
根據這個原理,在發生DDOS時,DNS會未來自不一樣位置的攻擊流量分散到就近位置的CDN節點上,從而達到稀釋流量、緩解攻擊的效果。
不過這種方式也有兩個弱點: 一、若是攻擊者攻擊的不是域名,而是一個IP的話就沒轍了 二、這種技術只適用於靜態業務,對於動態業務就沒轍了(因此遊戲業務每每是DDOS的重災區)
二、IP_Anycast
IP_Anycast是一種基於路由協議實現負載均衡的技術。在網絡中部署多臺IP地址相同的服務器,並使用動態路由協議對外進行宣告,此時因爲路由開銷緣由對於請求報文會被網絡路由到拓撲中最近的一臺服務器上去。
其實IP_Anycast本質上也是經過分佈式部署來稀釋攻擊流量,從而達到緩解DDOS攻擊的效果
三、流量清洗系統
在市面上有這樣一種流量清洗系統,它通常由DDOS攻擊預警模塊和DDOS攻擊清理集羣兩部分組成。 攻擊預警模塊負責攻擊發現,攻擊清理集羣負責流量清洗。
流量清洗系統能夠從所有的網絡流量中區分出正常流量和惡意流量,而後將惡意流量丟棄,只將正常的流量交付給後端業務服務器。
流量清洗系統部署方式:
在網絡入口處部署一個分光器來將流量鏡像一份給DDOS攻擊預警模塊,當攻擊預警模塊發現攻擊流量時將進入機房內的流量牽引至DDOS攻擊清理集羣進行流量清洗,清洗完後將乾淨流量再回注至後端業務服務器
清理集羣經常使用的惡意流量檢測方式有這麼幾種:
基於威脅情報的過濾:對數據包的源IP地址進行檢查,將其和威脅情報庫內的IP進行比對,若是存在於威脅情報庫則丟棄相應數據包。
特徵碼匹配:特徵碼分爲靜態特徵碼和動態特徵碼。靜態特徵碼是與事先規定好的特徵碼進行比對;動態特徵碼是基於機器學習現場學習攻擊特徵。
速率檢查與限制:一些攻擊方法在數據包載荷上可能不存在明顯特徵,沒有辦法進行攻擊特徵匹配。這時就能夠經過速率檢查來進行清洗了
協議完整性校驗:大多數攻擊每每只發送攻擊請求,而不接收服務器響應數據,此時清理集羣就能夠代替後端業務服務器向數據包的源IP地址進行應答,若是數據包的源IP沒有響應則認爲該IP爲攻擊者IP。
向客戶端發起挑戰:對於協議完整性校驗能夠還有漏網之魚,這時能夠主動向客戶端發送一個問題,需客戶端進行正確應答後方可經過,例如驗證碼等。