DDoS（分散式拒絕服務）攻擊是無解的嗎？

12-29

本題已收入知乎圓桌 ? 白帽黑客與安全，歡迎關注討論。

【更新】從來都不是！

魔高一尺，道高一丈，道高一尺，魔高一丈。

這不是車軲轆話，這是事實，魔和道誰高要看雙方投入的資源。

假設攻擊者手上有數萬台肉雞，你是一個小站的管理員，就算你的水平比他高，你覺得後果會如何？

假設你是國家某重要部門的網站管理員，攻擊者只是個小黑客，你覺得他下場如何？

道消魔漲，魔消道漲，道漲魔消，魔漲道消。

這不是繞口令，這也是事實，是說攻擊成本和防禦成本：防禦做的越完善，攻擊者消耗的成本越高，被發現的風險也越大；攻擊做的越好，防禦所付出的代價越大，追蹤越難。

如果防禦者把防禦做到攻擊者要達到目的所需付出的代價大於攻擊帶來的收益減去由於攻擊而被懲罰的風險（我一口氣差點沒喘過來），那麼攻擊就沒意義了，因為這是個賠本生意，除非防禦方有個懂群嘲超級能拉仇恨的老闆（某人表示無辜躺槍。。。）

什麼？你說DDoS攻擊沒有成本？少年，你還是圖樣圖森破啊，手上那麼多肉雞不花錢的？不花錢要花精力吧？不花精力天上掉下來的出門撿的你干點什麼別的不好非要做這樣沒前途的事情？不知道就算是給肉雞裝軟體刷流量賣廣告也能賺的盆滿缽滿么？而且那是可~持~續~發~展~，你一發動DDoS就會開始掉粉，哦，不對，是掉肉雞，全掉光了你拿什麼養老？

養~老~不~能~靠~國~家~

要想富，少做攻擊多養雞。

而且你見過幾個發了財的還在混黑社會？人家都變成社團了，不對，國際化企（第四聲）業。

說幾個小故事吧：

1.某人用synflood偽造IP地址攻擊重要部門，惹了主管部門了，採用類似拉閘限電的方式分區搜捕，結果悲劇了。這個例子是DoS不是DDoS，但是可以告訴我們有關部門下了決心有多危險；

2.某人用肉雞DDoS某網站，反向追蹤很難，但是他有個壞習慣喜歡開著自己的筆記本（無跳板）保持一直Ping目標機器，確定有沒有攻擊成功，結果你們懂的，所以說常在河邊走哪能不濕鞋；

3.某人玩DDoS，覺得自己玩的很專業，肯定不會被查到，可是偵探小說告訴我們警察叔叔不需要懂技術，有種方法叫做「得到最大利益的人就是最可疑的」，被請進去協助調查的時候你會希望自己的情商也和智商一樣高，對了，還有你隊友的情商和智商。哦，還有，網監的同志們是知道進屋前拉掉電閘以防止你破壞證據的，我覺得他們好萊塢電影看多了，誰真的會在家裡的電腦上裝自毀裝置啊？再說，你裝了自毀裝置那不就是承認自己有問題么？你以為是拍香港律政劇還是美國警匪片？你有權利保持沉默？你有權利請律師？你有權利把牢底坐穿！

你還玩DDoS么？你說你沒有同伴，心智堅強，好，那掃描肉雞的0Day是你自己挖的？控制Botnet的程序也是自己寫的？DDoS攻擊的代碼也原創的？來來來，同學，我幫你介紹工作吧，你這樣的人才工作地點從太平洋東岸到太平洋西岸一定是隨便挑，我要的不多一個月薪水就好，對，你不用付我自己去找僱主要，你問我為啥不內推，嗯，內推只有幾千塊獎金我不幹。

什麼？你不喜歡打工只願意單幹，來來來，同學，我們來討論下風險投資和天使基金，這裡有幾百萬不夠的話我們再去拿，對對對是美刀不是人民幣，你看看想做什麼項目，占的不多10%就可以，報酬什麼的你也不用擔心，我拿項目提成就好。

……………………………………

DBA表示DDoS什麼的弱爆了，好多網站都存在性能Bug，有時候幾個簡單的請求資料庫系統就掛了我會告訴你怎麼幹嗎？

CCIE表示DDoS什麼的弱爆了，好多系統都有網路規劃/配置Bug，有時候幾個簡單的數據包發過去網路就癱瘓了我會隨便說嗎？

社會工程學高手表示DDoS什麼的弱爆了，好多機房一不小心就溜進去關電源拔硬碟如果BCP做得不好那可不是停機一兩天的事情我會跟你講嗎？

黑帽子表示DDoS什麼的弱爆了，我手上有0Day若干，一般我都是黑進去直接rm -rf /*你家裡人都知道嗎？

某主管部門表示DDoS什麼的弱爆了，我們一般都是整個機房拔網線的，只要你敢播在線視頻。

We have a winner now!

The End.

………………

看完全文和演職員表的同學，你們幸運了，以下是彩蛋時間，楊威利和尤里安亂入中：

尤里安：「提督，什麼是必勝的秘訣？」

楊威利：「集結六倍於敵人的兵力，有著完全的補給和裝備。」

尤里安：「如果沒有這麼多兵力呢？」

楊威利：「相同兵力補給的情況下，要看指揮運用的能力。」

尤里安：「如果兵力不足呢？」

楊威利：「以少勝多之所以被稱為奇蹟，就是因為發生的實在太少啦。」

尤里安：「提督您一定有辦法的吧？您不是奇蹟的楊么？我對您有信心！」

楊威利：「尤里安，尤里安，"若是你就有信心"，自古以來，有多少人為了這耀人的名譽，而捨身去做那些不可能的事啊！

1. 防禦基礎

1.1. 攻擊流量到底多大

談到DDoS防禦，首先就是要知道到底遭受了多大的攻擊。這個問題看似簡單，實際上卻有很多不為人知的細節在裡面。

以SYN Flood為例，為了提高發送效率在服務端產生更多的SYN等待隊列，攻擊程序在填充包頭時，IP首部和TCP首部都不填充可選的欄位，因此IP首部長度恰好是20位元組，TCP首部也是20位元組，共40位元組。

對於乙太網來說，最小的包長度數據段必須達到46位元組，而攻擊報文只有40位元組，因此，網卡在發送時，會做一些處理，在TCP首部的末尾，填充6個0來滿足最小包的長度要求。這個時候，整個數據包的長度為14位元組的乙太網頭，20位元組的IP頭，20位元組的TCP頭，再加上因為最小包長度要求而填充的6個位元組的0，一共是60位元組。

但這還沒有結束。乙太網在傳輸數據時，還有CRC檢驗的要求。網卡會在發送數據之前對數據包進行CRC檢驗，將4位元組的CRC值附加到包頭的最後面。這個時候，數據包長度已不再是40位元組，而是變成64位元組了，這就是常說的SYN小包攻擊，數據包結構如下：

到64位元組時，SYN數據包已經填充完成，準備開始傳輸了。攻擊數據包很小，遠遠不夠最大傳輸單元（MTU）的1500位元組，因此不會被分片。那麼這些數據包就像生產流水線上的罐頭一樣，一個包連著一個包緊密地擠在一起傳輸嗎？事實上不是這樣的。

乙太網在傳輸時，還有前導碼（preamble）和幀間距（inter-frame gap）。其中前導碼佔8位元組（byte），即64比特位。前導碼前面的7位元組都是10101010，1和0間隔而成。但第八個位元組就變成了10101011，當主機監測到連續的兩個1時，就知道後面開始是數據了。在網路傳輸時，數據的結構如下：

也就是說，一個本來只有40位元組的SYN包，在網路上傳輸時占的帶寬，其實是84位元組。

有了上面的基礎，現在可以開始計算攻擊流量和網路設備的線速問題了。當只填充IP頭和TCP頭的最小SYN包跑在乙太網絡上時，100Mbit的網路，能支持的最大PPS（Packet Per Second）是100×106 / (8 * (64+8+12)) = 148809，1000Mbit的網路，能支持的最大PPS是1488090。

1.2. SYN Flood防禦

前文描述過，SYN Flood攻擊大量消耗伺服器的CPU、內存資源，並佔滿SYN等待隊列。相應的，我們修改內核參數即可有效緩解。主要參數如下：

net.ipv4.tcp_syncookies = 1

net.ipv4.tcp_max_syn_backlog = 8192

net.ipv4.tcp_synack_retries = 2

分別為啟用SYN Cookie、設置SYN最大隊列長度以及設置SYN+ACK最大重試次數。

SYN Cookie的作用是緩解伺服器資源壓力。啟用之前，伺服器在接到SYN數據包後，立即分配存儲空間，並隨機化一個數字作為SYN號發送SYN+ACK數據包。然後保存連接的狀態信息等待客戶端確認。啟用SYN Cookie之後，伺服器不再分配存儲空間，而且通過基於時間種子的隨機數演算法設置一個SYN號，替代完全隨機的SYN號。發送完SYN+ACK確認報文之後，清空資源不保存任何狀態信息。直到伺服器接到客戶端的最終ACK包，通過Cookie檢驗演算法鑒定是否與發出去的SYN+ACK報文序列號匹配，匹配則通過完成握手，失敗則丟棄。當然，前文的高級攻擊中有SYN混合ACK的攻擊方法，則是對此種防禦方法的反擊，其中優劣由雙方的硬體配置決定

tcp_max_syn_backlog則是使用伺服器的內存資源，換取更大的等待隊列長度，讓攻擊數據包不至於佔滿所有連接而導致正常用戶無法完成握手。net.ipv4.tcp_synack_retries是降低伺服器SYN+ACK報文重試次數，儘快釋放等待資源。這三種措施與攻擊的三種危害一一對應，完完全全地對症下藥。但這些措施也是雙刃劍，可能消耗伺服器更多的內存資源，甚至影響正常用戶建立TCP連接，需要評估伺服器硬體資源和攻擊大小謹慎設置。

除了定製TCP/IP協議棧之外，還有一種常見做法是TCP首包丟棄方案，利用TCP協議的重傳機制識別正常用戶和攻擊報文。當防禦設備接到一個IP地址的SYN報文後，簡單比對該IP是否存在於白名單中，存在則轉發到後端。如不存在於白名單中，檢查是否是該IP在一定時間段內的首次SYN報文，不是則檢查是否重傳報文，是重傳則轉發並加入白名單，不是則丟棄並加入黑名單。是首次SYN報文則丟棄並等待一段時間以試圖接受該IP的SYN重傳報文，等待超時則判定為攻擊報文加入黑名單。

首包丟棄方案對用戶體驗會略有影響，因為丟棄首包重傳會增大業務的響應時間，有鑒於此發展出了一種更優的TCP Proxy方案。所有的SYN數據報文由清洗設備接受，按照SYN Cookie方案處理。和設備成功建立了TCP三次握手的IP地址被判定為合法用戶加入白名單，由設備偽裝真實客戶端IP地址再與真實伺服器完成三次握手，隨後轉發數據。而指定時間內沒有和設備完成三次握手的IP地址，被判定為惡意IP地址屏蔽一定時間。除了SYN Cookie結合TCP Proxy外，清洗設備還具備多種畸形TCP標誌位數據包探測的能力，通過對SYN報文返回非預期應答測試客戶端反應的方式來鑒別正常訪問和惡意行為。

清洗設備的硬體具有特殊的網路處理器晶元和特別優化的操作系統、TCP/IP協議棧，可以處理非常巨大的流量和SYN隊列。

1.3. HTTP Flood防禦

HTTP Flood攻擊防禦主要通過緩存的方式進行，盡量由設備的緩存直接返回結果來保護後端業務。大型的互聯網企業，會有龐大的CDN節點緩存內容。

當高級攻擊者穿透緩存時，清洗設備會截獲HTTP請求做特殊處理。最簡單的方法就是對源IP的HTTP請求頻率做統計，高於一定頻率的IP地址加入黑名單。這種方法過於簡單，容易帶來誤殺，並且無法屏蔽來自代理伺服器的攻擊，因此逐漸廢止，取而代之的是JavaScript跳轉人機識別方案。

HTTP Flood是由程序模擬HTTP請求，一般來說不會解析服務端返回數據，更不會解析JS之類代碼。因此當清洗設備截獲到HTTP請求時，返回一段特殊JavaScript代碼，正常用戶的瀏覽器會處理並正常跳轉不影響使用，而攻擊程序會攻擊到空處。

1.4. DNS Flood防禦

DNS攻擊防禦也有類似HTTP的防禦手段，第一方案是緩存。其次是重發，可以是直接丟棄DNS報文導致UDP層面的請求重發，可以是返回特殊響應強制要求客戶端使用TCP協議重發DNS查詢請求。

特殊的，對於授權域DNS的保護，設備會在業務正常時期提取收到的DNS域名列表和ISP DNS IP列表備用，在攻擊時，非此列表的請求一律丟棄，大幅降低性能壓力。對於域名，實行同樣的域名白名單機制，非白名單中的域名解析請求，做丟棄處理。

1.5. 慢速連接攻擊防禦

Slowloris攻擊防禦比較簡單，主要方案有兩個。

第一個是統計每個TCP連接的時長並計算單位時間內通過的報文數量即可做精確識別。一個TCP連接中，HTTP報文太少和報文太多都是不正常的，過少可能是慢速連接攻擊，過多可能是使用HTTP 1.1協議進行的HTTP Flood攻擊，在一個TCP連接中發送多個HTTP請求。

第二個是限制HTTP頭部傳輸的最大許可時間。超過指定時間HTTP Header還沒有傳輸完成，直接判定源IP地址為慢速連接攻擊，中斷連接並加入黑名單。

2. 企業級防禦

互聯網企業防禦DDoS攻擊，主要還是使用上文的基礎防禦手段，重點在於使用監控、組織以及流程等東西來保障及時、正確的使用這些手段，並根據攻擊策略的改變而改變。

2.1. 異常監控

監控需要具備多層監控、縱深防禦的概念，從骨幹網路、IDC入口網路的BPS、PPS、協議分布，負載均衡層的VIP新建連接數、並發連接數、BPS、PPS到主機層的CPU狀態、TCP新建連接數狀態、TCP並發連接數狀態，到業務層的業務處理量、業務連通性等多個點部署監控系統。即使一個監控點失效，其他監控點也能夠及時給出報警信息。多個點的信息結合起來，有助於準確的判斷攻擊目標和攻擊手法。

2.2. 流程以及預案、演習

一旦發現異常，立即啟動在虛擬防禦組織中的應急流程。防禦組織需要囊括到足夠全面的人員，至少包含監控部門、運維部門、網路部門、安全部門、客服部門、業務部門等，所有人員都需要2-3個備份。流程啟動後，除了人工處理，還應該包含一定的自動處理、半自動處理能力。例如自動化的攻擊分析，確定攻擊類型，自動化、半自動化的防禦策略，在安全人員到位之前，最先發現攻擊的部門可以做一些緩解措施。

除了DDoS到來之時的流程等工作之外，更多的工作是在攻擊到來之前。主要包含CDN節點部署、DNS設置、流程演習等。對於企業來說，具備多個CDN節點是DDoS防禦容量的關鍵指標。當一個機房承擔不住海量數據時，可以通過DNS輪詢的方式，把流量引導到多個分布節點，使用防禦設備分頭處理。因此DNS的TTL值需要設置得足夠小，能夠快速切換，每個CDN節點的各種VIP設置也需要準備充分。

3. 總結

在虛擬化時代，海量用戶的不同業務共處在相同的物理機平台，遭受DDoS攻擊的可能性越來越高。而且一個用戶被攻擊可能牽扯到大量的其他用戶，危害被顯著放大，因此防禦顯得尤為重要。阿里雲的虛擬化雲計算業務，平均每天遭受約200起DDoS攻擊，最大流量達到接近80Gbit/s，所有這些攻擊都在1分鐘內自動處理完成，讓客戶遠離DDoS的威脅，專心發展業務。

總地來說，對DDoS防禦，主要的工作是幕後積累。台上十分鐘，台下十年功，沒有充分的資源準備，沒有足夠的應急演練，沒有豐富的處理經驗，DDoS攻擊將是所有人的噩夢。

power by http://www.icylife.net/blog/?p=945

看到shotgun等各位同學的精彩回答收穫頗豐，有關DDoS攻擊，遊戲行業是一個公認的重災區，社區昨日首發了一篇來自阿里雲安全團隊的：《遊戲行業DDoS 6年談：什麼樣的架構才可以對DDoS免疫？ - 知乎專欄》期望能夠對各位同學在DDoS防護方面有所幫助，同時也歡迎各位在原文評論中一起進行探討，以下是原文：

接觸DDoS相關技術和產品8年，其中6年，都在探究遊戲行業的DDoS攻擊難題。

在我看來，遊戲行業一直是競爭、攻擊最複雜的一個「江湖」。許多遊戲公司在發展業務時，對自身的系統、業務安全，存在諸多盲區；對DDoS攻擊究竟是什麼，怎麼打，也沒有真正了解。

我曾看到充滿激情的創業團隊、一個個玩法很有特色的產品，被這種互聯網攻擊問題扼殺在搖籃里；也看到過一個運營很好的產品，因為遭受DDoS攻擊，而一蹶不振。

這也是為什麼想把自己6年做遊戲行業DDoS的經驗，與大家一起分享，幫助在遊戲領域內全速前進的企業，了解本行業的安全態勢，並給出一些可用的建議。

在與遊戲公司安全團隊接觸的過程中，看到遊戲行業對安全有兩個很大的誤區。

第一個誤區是：沒有直接損失，就代表我很安全。

事實上，相比其它行業，遊戲行業的攻擊量和複雜度都要高一籌。每個遊戲公司，每個應用，其實都遭受過攻擊。但許多遊戲安全負責人，仍然會「蒙在鼓裡聽打雷」，沒有察覺正在發生的攻擊，或者乾脆視而不見，由此埋下安全隱患。

第二個誤區是：很多遊戲行業安全負責人會認為，只要裝了防火牆，就能擋住絕大部分的攻擊。

然而，防火牆的功能其實很有限。這也從側面說明了許多遊戲行業安全薄弱的根源：只去做好一個點，卻看不到整個面。

然而，攻擊者總會從意想不到的薄弱點，攻陷整個遊戲行業的內部系統。

以DDoS攻擊為例，2016年，全球有記錄的DDoS峰值已近600G，300G以上的DDoS攻擊，在遊戲行業內已經毫不稀奇。

為什麼遊戲會是DDoS攻擊的重災區呢？這裡說幾點主要的原因。

首先是因為遊戲行業的攻擊成本低廉，是防護成本的1/N，攻防兩端極度不平衡。隨著攻擊方的打法越來越複雜、攻擊點越來越多，基本的靜態防護策略無法達到較好的效果，也就加劇了這種不平衡。

其次，遊戲行業生命周期短。一款遊戲從出生，到消亡，很多都是半年的時間，如果抗不過一次大的攻擊，很可能就死在半路上。黑客也是瞄中了這一點，認定：只要發起攻擊，遊戲公司一定會給「保護費」。

再次，遊戲行業對連續性的要求很高，需要7*24在線，因此如果受到DDoS攻擊，遊戲業務很容易會造成大量的玩家流失。我曾經見過在被攻擊的2-3天後，遊戲公司的玩家數量，從幾萬人掉到幾百人。

最後，遊戲公司之間的惡性競爭，也加劇了針對行業的DDoS攻擊。

而針對遊戲行業的DDoS攻擊類型也非常的複雜多樣。總結下來，大致分為這幾種：

首先是空連接：攻擊者與伺服器頻繁建立TCP連接，佔用服務端的連接資源，有的會斷開，有的一直保持；比如開了一家麵館，「黑幫勢力」總是去排隊，但是並不消費，那麼此時正常的客人也會無法進去消費。

其次是流量型攻擊：攻擊者採用udp報文攻擊伺服器的遊戲埠，影響正常玩家的速度；還是上面的例子，流量型攻擊相當於坏人直接把麵館的門給堵了。

再次，CC攻擊：攻擊者攻擊伺服器的認證頁面，登陸頁面，遊戲論壇等，這是一類比較高級的攻擊了。這種情況相當於，壞人霸佔了收銀台結賬，找服務員去點菜，導致正常的客人無法享受到服務。

而後，假人攻擊：模擬遊戲登陸和創建角色過程，造成伺服器人滿為患，影響正常玩家。

還有對玩家的DDoS攻擊：針對對戰類遊戲，攻擊對方玩家的網路使其遊戲掉線或者速度慢和對網關DDoS攻擊:攻擊遊戲伺服器的網關，遊戲運行緩慢。

最後是連接攻擊：頻繁的攻擊伺服器，發垃圾報文，造成伺服器忙於解碼垃圾數據。

我以常見的DDoS和CC攻擊為例，對他們的攻擊方式做一個解釋。

DDoS攻擊的主要的方式是syn flood,ack flood,udpflood等流量型的攻擊，本身從攻擊方式來是非常簡單的，無論是哪種方式，流量大是前提。如果防禦方有充足的帶寬資源，目前的技術手段防禦都不會是難事；針對UDPflood，實際上很多遊戲目前都不需要用到UDP協議，可以直接丟棄掉。

而CC攻擊分為兩種。一般針對WEB網站的攻擊叫CC攻擊，但是針對遊戲伺服器的攻擊，很多人一般也叫CC攻擊，兩種都是模擬真實的客戶端與服務端建立連接之後，發送請求。

針對網站的CC如下，一般是建立連接之後，偽造瀏覽器，發起很多httpget的請求，耗盡伺服器的資源。

針對遊戲伺服器的CC，一般是建立連接之後，偽造遊戲的通信報文保持連接不斷開，有些攻擊程序甚至也不看遊戲的正常報文，而是直接偽造一些垃圾報文保持連接。

那麼，遊戲公司如何才能判斷自己是否正在被攻擊？

假定可排除線路和硬體故障的情況下，突然發現連接伺服器困難，正在遊戲的用戶掉線等現象，則說明很有可能是遭受了DDoS攻擊。

目前，遊戲行業的IT基礎設施一般有兩種部署模式：一種是採用雲計算或者託管IDC模式，另外一種是自拉網路專線。但基於接入費用的考慮，絕大多數採用前者。

無論是前者還是後者接入，在正常情況下，遊戲用戶都可以自由流暢的進入伺服器並參與娛樂。所以，如果突然出現下面這幾種現象，就可以基本判斷是「被攻擊」狀態：

（1）主機的IN/OUT流量較平時有顯著的增長；

（2）主機的CPU或者內存利用率出現無預期的暴漲；

（3）通過查看當前主機的連接狀態，發現有很多半開連接，或者是很多外部IP地址，都與本機的服務埠建立幾十個以上的ESTABLISHED狀態的連接，則說明遭到了TCP多連接攻擊；

（4）遊戲客戶端連接遊戲伺服器失敗或者登錄過程非常緩慢；

（5）正在進行遊戲的用戶突然無法操作或者非常緩慢或者總是斷線。

在知道難點，和攻擊狀態的判斷方法之後，來說說我所了解的DDoS防護方法。

目前，可用的DDoS緩解方法，有三大類。首先是架構優化，其次是伺服器加固，最後是商用的DDoS防護服務。

遊戲公司需要根據自己的預算、攻擊嚴重程度，來決定使用哪一種。

在預算有限的情況下，可以從免費的DDoS緩解方案，和自身架構的優化上下功夫，減緩DDoS攻擊的影響。

a. 如果系統部署在雲上，可以使用雲解析，優化DNS的智能解析，同時建議託管多家DNS服務商，這樣可以避免DNS攻擊的風險。

b. 使用SLB，通過負載均衡減緩CC攻擊的影響，後端負載多台ECS伺服器，這樣可以對DDoS攻擊中的CC攻擊進行防護。在企業網站加了負載均衡方案後，不僅有對網站起到CC攻擊防護作用，也能將訪問用戶進行均衡分配到各個web伺服器上，減少單個web伺服器負擔，加快網站訪問速度。

c. 使用專有網路VPC，防止內網攻擊。

d. 做好伺服器的性能測試，評估正常業務環境下能承受的帶寬和請求數，確保可以隨時的彈性擴容。

e. 伺服器防禦DDoS攻擊最根本的措施就是隱藏伺服器真實IP地址。當伺服器對外傳送信息時，就可能會泄露IP，例如，我們常見的使用伺服器發送郵件功能就會泄露伺服器的IP。

因而，我們在發送郵件時，需要通過第三方代理髮送，這樣子顯示出來的IP是代理IP，因而不會泄露真實IP地址。在資金充足的情況下，可以選擇DDoS高防伺服器，且在伺服器前端加CDN中轉，所有的域名和子域都使用CDN來解析。

也可以對自身伺服器做安全加固。

a. 控制TCP連接，通過iptable之類的軟體防火牆可以限制某些IP的新建連接；

b. 控制某些IP的速率；

c. 識別遊戲特徵，針對不符合遊戲特徵的連接可以斷開；

d. 控制空連接和假人，針對空連接的IP可以加黑；

e. 學習機制，保護遊戲在線玩家不掉線，通過伺服器可以搜集正常玩家的信息，當面對攻擊的時候可以將正常玩家導入預先準備的伺服器，新進玩家可以暫時放棄；

f. 確保伺服器系統安全；

g. 確保伺服器的系統文件是最新的版本,並及時更新系統補丁；

h. 管理員需對所有主機進行檢查，知道訪問者的來源；

i. 過濾不必要的服務和埠：可以使用工具來過濾不必要的服務和埠（即在路由器上過濾假IP，只開放服務埠）。這也成為目前很多伺服器的流行做法。例如，「WWW」伺服器，只開放80埠，將其他所有埠關閉，或在防火牆上做阻止策略；

j. 限制同時打開的SYN半連接數目,縮短SYN半連接的timeout 時間,限制SYN/ICMP流量；

k. 認真檢查網路設備和主機/伺服器系統的日誌。只要日誌出現漏洞或是時間變更,那這台機器就可能遭到了攻擊；

l. 限制在防火牆外與網路文件共享。這樣會給黑客截取系統文件的機會,若黑客以特洛伊木馬替換它，文件傳輸功能無疑會陷入癱瘓；

m. 充分利用網路設備保護網路資源；

n. 禁用 ICMP。僅在需要測試時開放ICMP。在配置路由器時也考慮下面的策略：流控，包過濾，半連接超時，垃圾包丟棄，來源偽造的數據包丟棄，SYN 閥值，禁用 ICMP 和 UDP 廣播；

o. 使用高可擴展性的 DNS 設備來保護針對 DNS 的 DDoS 攻擊。可以考慮購買DNS商業解決方案，它可以提供針對 DNS 或 TCP/IP3 到7層的 DDoS 攻擊保護。

再就是商用的DDoS解決方案。

針對超大流量的攻擊或者複雜的遊戲CC攻擊，可以考慮採用專業的DDoS解決方案。目前，通用的遊戲行業安全解決方案，做法是在IDC機房前端部署防火牆或者流量清洗的一些設備，或者採用大帶寬的高防機房來清洗攻擊。

當寬頻資源充足時，此技術模式的確是防禦遊戲行業DDoS攻擊的有效方式。不過帶寬資源有時也會成為瓶頸：例如單點的IDC很容易被打滿，對遊戲公司本身的成本要求也比較高。

在阿里雲，我們團隊去顛覆帶寬「軍備競賽」的策略，是提供一個可信的訪問網路，這也是遊戲盾誕生的初衷。

遊戲盾風控模式的初衷，是從收到訪問的第一刻起，便判斷它是「好」還是「壞」，從而決定它是不是可以訪問到它想訪問的資源；而當攻擊真的發生時，也可以通過智能流量調度，將所有的業務流量切換到一個正常運作的機房，保證遊戲正常運行。

（某棋牌行業基於遊戲盾的架構示意圖）

所以，通過風控理論和SDK接入技術，遊戲盾可以有效地將黑客和正常玩家進行拆分，可以防禦超過300G以上的超大流量攻擊。

風控理論需要用到大量的雲計算資源和網路資源，阿里雲天然的優勢為遊戲盾帶來了很好的土壤，當遊戲盾能調度10萬以上節點進行快速計算和快速調度的時候，那給攻擊者的感覺是這個遊戲已經從他們的攻擊目標裡面消失。

遊戲盾，是阿里雲的人工智慧技術與調度演算法，在安全行業中的成功實踐。

而隨著攻防進程的推進，網路層和接入層逐步壯大，我們希望「遊戲盾」的風控模式，會逐步延展到各個行業中，建立起一張安全、可信的網路。這張網路中，傳輸著乾淨的流量，而攻擊被前置到網路的邊緣處。所有的端，在接入這張網路時，都會經過風險控制的識別，網內的風控系統，也讓壞人無法訪問到他鎖定資源。

未來，以資源為基礎的DDoS防護時代終將被打破，演進出對DDoS真正免疫的風控架構。

而我們所做的，只是一個開始。

前一陣大名鼎鼎的「匿名者」號稱要攻擊中國政府網站的時候，阿里巴巴也跟著躺槍了，有一天監控到了300M的攻擊流量，堅持了約10分鐘。然後大家都樂了，拿這點流量來玩，馬總可是備了那麼多的帶寬在準備雙十一呢，這點流量根本不用採取任何措施好么。敗家娘們的攻擊力遠大於黑客組織好么！

謝邀。喝多了怒答此題。

黑產的的ddoser們你們玩卵去吧，攻擊分千萬種，你們偏偏選擇最下作的一種，既然不相信報應，那就讓報應快點來。

shutgun說的很好了，我不在重複。一句話，ddos是無法徹底解決的。防ddos純屬是燒錢的事情，防到什麼程度就看你願投入多少。溯源也是一樣，看你有能力動用多大的成本，你若是國家機器的話，甚至是動用外交手段，黑客直接過來跪了。

有一種誤區，很多人認為ddos在於協議設計的不完善，或者存在漏洞。我不說三次握手這種協議缺陷，也不說slowery這種漏洞的情況，我只說說前端xss引發的ddos為例。

假如有微博上的xss蠕蟲，去干一個中小網站是沒什麼問題的，而且完全都是正常的請求，首先跪的是ddos防火牆，另外請求的頁面也不是隨便選的，而是要連接資料庫的頁面，這個佔用資源多，再控制個可變的參數來防止緩存，例如網站的搜索功能，這樣cdn也跪了。此時蠕蟲感染到50萬，你的網站已經被正常的請求干到抬不起頭來了，好了，你限制了微博referer，這是絕對有效的手段，大大降低了伺服器資源的開銷，可是降低了開銷不等於沒有開銷，請問正則匹配referer就不消耗資源么，就算忽略資源消耗也是要消耗帶寬的吧。好吧，現在感染的用戶超過500w，看你網站跪不跪。

反正我也是鍵盤俠，那我就繼續站著說話不腰疼吧，希望各位站長寧願把錢花在防D的成本上，也不要給那些威脅你們的大(tu)黑(zai)客(zi)們。

首先第一點，如果你說理論上，ddos攻擊還沒有辦法真正防禦，那麼有人會問，那豈不是國家的網路，網站，美國中情局，等等網站只要有足夠的肉雞，也就是傀儡主機，都可以使其癱瘓？答案是肯定的，但同時也是否定的第一，現在攻擊者的立場講，他攻擊肯定會帶來利益，而且肯定大於投入成本，先不說他攻擊國家機關，別國國家網站能不能又那麼多肉雞，就說利益，我想從黑產的角度來說這樣帶來的利益微乎其微，虧本的買賣誰會做，而同時也會有被請去喝茶的機會也就是說剛剛的問題，是否定的，而題主的問題是肯定的，就目前來說，也和其他幾位答友說的，沒有足夠的利益不會有人花很大代價用這樣的方法攻擊你，同時可以進行伺服器等硬體防護升級，還有軟體上一些埠禁用，以及國內一些工資的安全防護，引流等等來防禦，正常來說是沒問題的。

怎麼會無解

你要硬挺幾天不管他，對方玩夠了就解了

有錢把帶寬加到比攻擊方流量還大就解了

有關係直接報警把攻擊者抓了就解了

有幾個黑客是吃飽了撐的沒事攻擊你啊？對方有啥要求你滿足了也解了，比如買個對方的防火牆什麼的。

但是，限定時間內沒有錢沒有資源還真是沒啥辦法。

得看你有沒有錢，沒錢無解。

不要妄想幾台小破伺服器搞搞安全設置就能防d了，沒可能的。

這玩意就是兩邊拼錢，專業ddos都是有成本的，而且還老貴的。

一般沒有深仇大恨不至於玩太凶。

要看是哪種ddos

如果是帶寬消耗類的，用運營商提供的抗d服務理論上效果比用阿里這類服務商的好，原因很簡單，運營商可以在最外層把流量清洗掉，比如電信的雲堤。阿里或者騰訊的抗d只是利用有限租用帶寬的保護機制，但是如果d流量擁塞了骨幹網那就不是阿里之類可以想像的

如果是對其它類型的，比如tcp或者dns類的，隱藏入口並且結合抗d能力基本可以搞定

無論怎樣，這種事都要花錢，錢才是最後的抵抗資源

樓上有人說有關部門什麼的，沒什麼意義，來自國外的攻擊有關部門也就是有關部門而已

運營商部署urpf 主要節點netflow 入網的伺服器和用戶簽訂好信息安全管理的協議骨幹網路上部署流量清洗基本能做到這幾點就差不多了。

跟天朝春運的感覺差不多，人太多走不了怎麼辦？增加運力。

雖然說技術主可以區分出一些明顯非正常的請求，但這並不能保證有效請求都得到處理。最終原因仍然是資源不足以處理這麼多請求，解決方案就是提升系統整體性能。

只有手段最低劣的人才用DDoS。

上大學之前我玩過一個月的黑，最開始的時候，我接觸的第一個攻擊工具就是DDoS工具，操作最簡單，最沒有技術含量。

後來買了個遠端，還有點肉雞，去攻擊某島國網站，玩了幾天感覺沒意思就送人了。

然後我把硬碟格了系統重做。

那之後我開始玩阿D工具，就是沒成功幾次，但是一旦成功。。。DDoS？一邊玩卵去把~

後來我把硬碟又格了，系統又重做一次，所有電腦上登錄過的密碼都改了一次。

所有東西都被我刪除。收拾東西準備大學((╯‵□′)╯︵┻━┻明明是大專)生活

參考事件，XX年，ping死美國佬。

然而人家搞定了ping死命令。

╮(╯▽╰)╭

順便補充一下，政府網站最好攻擊了

前面有說什麼政府網站最好打的，政府網站需要DDOS么，我半小時寫個webbench腳本，放到raspberry上跑一跑都能把政府網站跑趴下。

真正做DDOS的人不傻，沒有人願意去攻擊正規網站，都是找黃，賭，私服搞，這些都是不正規的，不敢報警。

所以解決辦法只有一個：買高防。

最後求個職：前面那位大哥，我專搞Linux，集群真的是我自己寫的，rootkit也是自己寫的，爆破器，抓雞工具都是我自己寫的，大哥能介紹一個太平洋彼岸的工作么。。。

本人不是什麼網路安全大咖，只不過是一家大型國企公司的一個小小的網路管理員。經驗不足，在這裡想和大家就DDOS防禦探討幾個觀點，希望能拋磚引玉。好了，這是我的觀點：

大多數的網頁服務都過於集中，便於攻擊，導致了因為防禦成本的成倍提升而防禦困難，而我們可以依照「菜籃子」原理設計網路架構，既然網路攻擊能分散式攻擊，那麼我們同樣可以將服務端做成分散式的

要明白我的觀點，首先要了解DDOS的原理，有個很生動的例子（轉自百科）：

一群惡霸試圖讓對面那家有著競爭關係的商鋪無法正常營業，他們會採取什麼手段呢？（只為舉例，切勿模仿）惡霸們扮作普通客戶一直擁擠在對手的商鋪，賴著不走，真正的購物者卻無法進入；或者總是和營業員有一搭沒一搭的東扯西扯，讓工作人員不能正常服務客戶；也可以為商鋪的經營者提供虛假信息，商鋪的上上下下忙成一團之後卻發現都是一場空，最終跑了真正的大客戶，損失慘重。此外惡霸們完成這些壞事有時憑單幹難以完成，需要叫上很多人一起。

例子中的商鋪就是DDOS中受害的伺服器，惡霸就是DDOS攻擊者。攻擊者追尋這以下幾點思路進行攻擊：

1.特定的一家餐廳（基於IP地址的對指定某伺服器的攻擊）

2.這家餐廳的服務對象上限（伺服器承受的帶寬上限）

3.堵塞該店鋪的路徑（解決掉中間通道運營商）

4.這家餐廳提供的服務（針對伺服器中的某個服務）

看了大家關於DDOS的發言，很多人願意在第二項上面下手，即提升帶寬上限來增加硬防，為在無法判斷數據交換請求的硬性需求是否是真正所需的情況下，這種土豪做法是最明顯的提升方法，也是成本最高的方法。在我國通道流量算比較貴的情況下，這種方法的代價太高使防禦變成了一種瓶頸。但我探討以下幾種觀點及其延伸：

針對基於IP地址的攻擊，是受攻擊面過於集中，但如果我們擁有足夠多的IP、使用多個DNS域名解析，甚至啟用DDNS動態域名（技術可能還不成熟），將域名分散式建立，然後進行加上疏流管理，是不是能緩解一些壓力？

換句話說，我們是不是可以這樣，既然很多用戶（好用戶和壞用戶）都選擇從餐廳的正門進入，我們開通其他後備通道，在正門相對擁擠的情況下，選擇規範正門進入用戶數量，開通備用通道計入的方式？就好比我們的交通規則，從A到B原先只有1條路，當人滿為患時，我們除了將道路修寬之外，可以新增道路（訪問地址1，訪問地址2）、可以安裝交通燈（提示：當前地址1用戶已滿，前面排隊用戶還有88個，或者選擇地址2）、增加訪問時間限制（距您在本網頁處理還有998秒）等這些可能性能不能實現？在我所管轄的網路里，我們公司擁有自己的內部網路，使用的做法之一就是建立多通道的伺服器分散式集群，有一個前端掛了的時候，我們可以使用另外一個前端進行備投。許多網遊公司都有這樣的概念：用戶分為電信、聯通、鐵通用戶，這樣能有效的進行數據交換請求的分流，能一定程度上緩解DDOS壓力，但這並不能從根本上緩解壓力，所以很多人說這個方法然並卵。

針對基於帶寬上限的攻擊，這個現有的技術只能做到土豪做法，即給錢，提升硬防。我探討的是三點：

1.減少數據交換需求。進行類似數據流進行壓縮和檢測排除的做法，減少對通道的壓力

比如用戶提出需求：「老闆，今天天氣很不錯，給我來兩斤白酒」。這個就是一個數據交換的過程，作為「老闆」，我們可以辨別出「今天天氣很不錯」這句話是費詞，可以去掉以減少通話時間（通道流量），那麼能做到壓縮並檢測排除數據流的東西，我第一個想到的就是登錄客戶端了，一方面可以對數據流進行加密處理，一方面可以優化數據交換需求。

2.減少通道成本。

這個可以根據各個地域不同的通道費用，選擇相應較低費用的通道，甚至考慮服務端對外使用並行多路動態（使用動態域名技術）+靜態網路（專線VPN），伺服器集群之間使用靜態固定網路，這樣做的原因是由於動態網路的成本要遠低於靜態成本，減少通道投入成本相應的就減少了防禦成本。

3.將需求資料庫建設成雲資料庫。

如果做雲資料庫呢？將重要資料庫分地區存放，再建立專用的多通道城域網（伺服器內網）DDoS最多能攻擊到幾處，我們可以關閉其中幾條通道，並將服務轉移呢？

DDoS 攻擊本身是無解的，因為DDoS的原因並不是因為伺服器或者路由器的安全性出現問題，而是因為機器必須連接到互聯網。而在防禦DDoS上存在一個權衡問題，也就是"there is always a trade-off between accuracy of the detection and how close to the source of attack the prevention and response mechanism can stop or respond to the attack."

我覺得一些高票的回答可能有一些偏頗。可能提問者想問的是DDoS是否在技術上可以進行防禦的，但是感覺回答都有點偏原始的方法了。就像人家問線性規劃是不是可以標準化求解的，前邊的回答都是說在問題簡單的情況下可以通過枚舉解決問題。

即使對於最基本的IRC-based這樣一個樹狀結構（也就是最高票說的可以通過一台電腦一台電腦找的方式找到攻擊者的那種結構）也沒有從技術上進行解決的確切方案。更何況還有低軌道離子炮這種Web-based的，不是簡簡單單關掉一台主機就能解決的DDoS攻擊種類。以及目前幾乎沒有人注意的P2P方式的殭屍網路結構。

然而最近幾年有人在試著用機器學習在整個網路的路由器層級進行結構學習，分辨殭屍網路，並且聲稱取得了很高的準確率。但這樣的聲明想必也只能在學界看看吧。

綜上，DDoS並不是最low的攻擊方式，任何東西一旦涉及到網路就能弄出花來，最後把這個DDoS防禦弄成一個NP－hard求解問題，怎麼解？

以一般人的經濟水平（不是高富帥），也就捨得一天花幾十，幾個月花個幾千，然後他就窮逼了。你可以先趁不能訪問備個案，再用個國內的免費cdn，能擋一部分。有錢的話，他燒錢買肉雞你就不會燒錢買高防么？雲主機時代帶防火牆的主機遍地都是。

如果通過社工或者本來就知道對方在哪兒，建議線下解決，玩網的人一般線下是很虛的。也可以試著報警，有句話說得好，技術手段好用就用技術手段，行政手段好用就用行政手段。

估計很多混到現在的站長都有被ddos牛打擊的經歷，與題主共勉。

Google問道：你進來了嗎？

首先了解DDOS 攻擊的三種類型：

1、帶寬消耗型攻擊；例如TCP
SYN-ACK Flood、IP
Fragment Flood、UDP
FLOOD；通過大量的數據包佔用帶寬；

2、資源消耗型攻擊；利用了HTTP 伺服器的一些漏洞，構建特殊結構的數據包或者請求，從而導致伺服器計算資源耗盡無法提供服務。例如HTTP Get Flood。

3、DNS 攻擊; 嚮應用系統發送大量的錯誤DNS解析請求，通過DNS遞歸查詢機制（NS伺服器需要進行頻繁的字元串匹配，本地無法查到結果，必須使用遞歸查詢向上層域名伺服器提交解析請求），佔用伺服器的緩存，導致資源不足無法正常提供服務。例如DNS query flood、DNS reply flood；

其次針對性的了解應對措施：

1、帶寬消耗型攻擊，部署流量清洗設備，設定一定的閾值，超過閾值則丟棄數據包。也可加大帶寬，提供業務訪問帶寬保障；或者識別出DDOS攻擊網段，在本地的運營商配合在骨幹路由器上將流量引入「路由黑洞」。

2、資源消耗型。部署流量清洗設備過濾異常流量。對應用系統進行補丁、設置加固，消除漏洞。

3、DNS 攻擊類型。需要流量清洗設備進行攻擊防護，需要進行相關的安全設置。如限制每個源 IP 地址每秒的域名解析請求次數，對突然發起大量頻度較低的域名解析請求的源 IP 地址進行帶寬限制等等。

通過分析可以了解到，DDOS攻擊是多種類型的，每種攻擊都有一定的防護手段，採取有效的手段是完全可以控制DDOS攻擊的影響範圍。但是要攔截DDOS攻擊，需要耗費大量的人力物力，並協調運營商解決等等，非常難以有效防範。

如果沒有做好充足的應對措施，短時間內使無法防範DDOS攻擊的影響。

針對DDoS防禦的手段一直以來都是以流量清洗為主，但事實上流量清洗的手段也在不斷發生著變化。過去的DDoS防護以本地的軟硬體配合為主。比如，許多操作系統自帶的防火牆都可以針對異常流量進行檢測提醒並且攔截，伺服器上部署的抗D軟體可以攔截非法IP，或者在企業內網布置一個流量清洗的設備。但是這種方法的流量清洗能力非常有限，而且不能清洗帶寬外流量。具體而言，因為每個企業的帶寬資源都是非常有限的，一旦企業從運營商那裡租用的帶寬資源被攻擊擠滿，那麼即便布有清洗設備也失去了功效。並且，越來越多的企業選擇將自身的業務放在雲上，對這些企業來說，本地的流量清洗設備將毫無用武之地。那麼為了追趕時代的步伐，流量清洗的模式也在悄然發生著變化。

這並不是指流量清洗設備已經過時了，而是這些軟硬體設備的應用場景發生了變化。現在安全廠商都會選擇將自身的流量清洗設備放在數據中心，通過SaaS的形式提供給用戶租用。而這種方式有一個很大的優勢：IDC的出口帶寬很大，因此流量清洗設備不會再被出口帶寬所制約。另外，這種模式還降低了運維成本。一個專業的安全運維人員成本以及設備的運維費用是相當高的，採用這種方式，運維的壓力都在安全廠商那裡。不過我們還需要注意的是，即便採用這種模式，抗DDoS成本對於一個中小規模的企業來說並不算低。

既然說到DDoS防禦，那麼知道創宇雲安全旗下產品抗D保的抗D能力到底有多強呢？很多用戶在選擇抗D服務時，都會關心你能不能抵擋400Gbps甚至更高的流量峰值的DDoS攻擊呢？就在2016年7月29日晚，知道創宇雲安全旗下產品抗D保幫助其平台上的某金融客戶成功抵擋峰值為685Gbps的DDoS攻擊，刷新了全球抗D記錄。從結果上來看，知道創宇的抗D本領是非常過硬的，用戶大可以放心。

2016年7月29日晚DDoS攻擊流量示意圖

知道創宇是從2011年開始做DDoS防禦服務的，在國內起步比較早。那個時候，知道創宇推出了一款名叫加速樂的解決方案，為用戶提供網站加速、Web防護以及DDoS防禦三方面服務。而在加速樂推出之前，不論是專業提供CDN服務的廠商（如網宿科技、藍汛等），還是流量清洗設備，其成本相對來說都比較高，知道創宇就希望通過一種低成本、輕維護的方式將這些安全能力交付給客戶，於是以SaaS模式交付的加速樂就出現了。後來隨著業務的不斷發展，去年知道創宇對旗下業務做了重新整合，統一叫做知道創宇雲安全，其抗D業務也從加速樂中分離出來，也就是現在知道創宇雲安全旗下的抗D保。

DDoS攻擊的解決方案無疑是一種攻擊和防禦的成本博弈，但是如何在這場博弈中選擇性價比高的策略則更需要大家思考。

現階段無解！要麼大幅度提升運算性能，要麼修改tcp協議機制。貌似兩種辦法都不是短時間能實現的。