創業耗費百萬，為何DDoS如此要命Part 1
*本文原創作者：羅永浩的迷弟，本文屬FreeBuf原創獎勵計劃，未經許可禁止轉載
0×00 多年運維，不敵攻擊
從05年開始做運維到現在也有13年了，幹過論壇，電商，遊戲，金融，直播這些業務的運維，活很雜，什麼WebServer，Database，Netfilter，Docker，Xen，KVM，OpenVZ，Ceph，iSCSI，DNS， 負載均衡等等。那麼多年做運維以來最讓人覺得棘手和 絕望的便是DDoS攻擊了，每天晚上睡覺後都怕接到電話說伺服器被DDoS了，至於為什麼那麼恐怖，我想做過運維的人或者被攻擊過的企業都應該非常明白那是一種怎麼樣的體驗。
0×01 噩夢初醒，惶惶不可終日
第一次和DDoS攻擊打交道，那是06年的冬天，第一份工作是為一家網路廣告聯盟公司做伺服器運維。
基本上每天的任務就是看下伺服器的硬碟I/O負載，資料庫負載，還有是否有錯誤日誌，很平常。
直到06年冬季的某天，公司託管在浙江紹興電信機房的那臺Dell PowerEdge 1850伺服器突然無法訪問，WEB和SSH都無法訪問。
老闆那個急啊，客服那個急啊，真的是可以說熱鍋上的螞蟻，坐立不安，要知道對於一個廣告聯盟來說，伺服器癱瘓了，站長的收入突然沒了，廣告主的流量突然沒了，這意味著站長和廣告主會流失。
於是乎，聯絡了紹興電信的網維，得知伺服器當時遭受了大流量的DDoS攻擊，攻擊規模在2Gbps左右，電信的網維為了保護機櫃內其他客戶伺服器正常執行，封了我們伺服器的外網IP地址。
為了不影響業務，最後找紹興電信付費做的DDoS防禦服務，雖然最後服務恢復了，但是伺服器的網路延遲也增加了，因為DDoS 攻擊一直在持續。
從那次事件後，公司所有人談DDoS色變。
0×02 揮金如土，只為續命
15年，視訊直播爆發式地發展，全民網紅，進入這家公司就職半年後，公司融資2000多萬，對於視訊直播行業可能不多，但是對於整個公司來說已經是走向成功的第一步了。
隨著公司快速的發展，直播平臺的流水和日活每天都在增長，漂亮的小姐姐也越來越多。
正當大家士氣十足甚至都在幻想上市的時候，沒過多久，公司就遭到了重挫。
16年9月15號，那天正是中秋節，晚上應該是全家一起吃月餅賞月的時候，可是一起蓄謀已久的DDoS攻擊，讓大家在 公司裡度過了極為煎熬的中秋漫漫長夜。
當晚6點，剛吃完晚飯，準備和家人一起去公園賞月，還沒動身，就接到公司電話，要求趕到公司處理突發情況。
趕到公司時，運維同事說平臺的登陸系統伺服器和主播打賞系統伺服器被大規模DDoS攻擊，由於攻擊規模較大，CDN服務商直接將域名做了回源處理，大量的 攻擊流量湧入源伺服器，IDC機房直接將被攻擊的IP地址做了封堵處理。
詢問了IDC接入服務商本次的DDoS攻擊規模，得知入向的DDoS攻擊流量高達200Gbps+(IDC接入服務商表示機房總接入頻寬是200Gbps，這次攻擊直接將機房出口打滿，為了不影響其他使用者，只能將被攻擊的IP地址做封堵處理。)
由於本次DDoS攻擊規模超過了IDC服務商的接入頻寬，IDC服務商沒有能力防禦，於是求助於雲服務商。
最後雲服務商給出的高防IP報價非常之高，按天計算，300G防禦的每天費用為2.5萬元，按月費用為 37萬元，如果攻擊超出300G，費用還需要支付額外防禦費用。
但是公司業務處於癱瘓狀態，為了儘快恢復業務，公司開通了按天的DDoS防禦服務，在預存10萬的防禦費用後，當晚8點，DDoS防禦服務開通。
防禦開通後，經過雲服務商的DDoS清洗服務，攻擊流量被攔截，平臺暫時恢復了正常，經過一晚上的觀察和溝通，最終防禦了這次DDoS攻擊。
此後我們遭受了更大規模的DDoS攻擊，每天黑客都會發起數小時的攻擊，這使得我們按天支付DDoS防禦費用非常不划算，最終公司購買了 37萬每月的DDoS保底防禦服務。
這次案例告訴我們，有錢真的是可以為所欲為。
0×03 這世上有很多悲哀，僅僅是因為沒錢
曾經在貓眼社群上看到一篇帖子，讓我感觸很深，那帖子標題叫做《我的老婆沒錢治病，死了》
當人處於真正的底層時，連選擇繼續生存的資格都沒有，談什麼機會去創造奇蹟。
創業公司不也是如此嗎？大量的創業公司在遭遇DDoS攻擊的時候如同生病，來的那麼突然，那麼措手不及，但有多少創業公司能那麼輕鬆的負擔每月高達數十萬的DDoS防禦費用呢？
有多少人懷著創業夢想，創造奇蹟，想改變行業，但是遇到DDoS攻擊，連選擇繼續生存的資格都沒有，這不是很可悲的事情嗎？
因為DDoS防禦成本太高，加上對DDoS攻擊的不瞭解，往往會出現病急亂投醫。
這是非常可怕的，猶如患了重病，而三甲醫院費用極高，而選擇那些號稱能根治但並不靠譜的 私人和莆田系醫院，最後往往因為錯誤的治療和時間上的拖延導致病重，最後人財兩空。
0×04 細說DDoS攻擊
下面進入正題，說一下我遇到的各種DDoS攻擊型別和一些緩解手段，還有防止李鬼，騙子，垃圾高防服務商的一些經驗，以及教大家如何分辨高防服務的 真假和水分。
SYN Flood攻擊和防禦方式
老生常談的一種DDoS攻擊型別，從早期的利用TCP三次握手原理，偽造的IP源，以小博大，難以追蹤，堪稱經典的攻擊型別。
大量的偽造源的SYN攻擊包進入伺服器後，系統會產生大量的SYN_RECV狀態，最後 耗盡系統的SYN Backlog，導致伺服器無法處理後續的TCP請求，導致伺服器癱瘓。
就和上面的圖片一樣，伺服器資源被耗盡，使用者無法和伺服器建立連線，攻擊者目的達到。
那如何防禦SYN Flood攻擊呢(其實是緩解，提高一下系統的處理能力，但是隻限於小攻擊)？
方式1：軟體防火牆和系統引數優化 (適用於SYN Flood攻擊流量小於伺服器接入頻寬，並且伺服器效能足夠)
【Windows系統: 可以修改登錄檔來提高SYN資料包的處理能力】
進入登錄檔的[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]專案
1. 啟用syn攻擊防護模式 （可以顯著提高Windows的SYN處理能力） SynAttackProtect=2 [dword] 2. 加大TCP半開連線數的佇列數量 TcpMaxHalfOpen=10000 [dword] 3. 啟用動態Backlog佇列長度 EnableDynamicBacklog=1 [dword]
通過修改這三處登錄檔資訊可以防止一些小規模並且較為簡單的SYN Flood攻擊
【Linux系統: 修改sysctl核心引數提高SYN資料包的處理能力】
1. 開啟SYN Cookies，當出現SYN等待佇列溢位時，啟用cookies來處理 net.ipv4.tcp_syncookies = 1 2. 增加SYN Backlog佇列長度 net.ipv4.tcp_max_syn_backlog = 65535 3. iptables限制SYN頻率，每秒鐘只允許每個源IP發起2個SYN資料包，超出則丟棄 iptables -N syn-flood iptables -A INPUT -p tcp –syn -j syn-flood iptables -A syn-flood -p tcp -m limit –limit 2/s –limit-burst 50 -j RETURN iptables -A syn-flood -j DROP
方式2: 購買專業的DDoS雲清洗和雲防禦服務 (適用於SYN Flood攻擊流量較大，強度較高的場景)
購買專業的DDoS雲清洗服務之前可以諮詢一下服務商採用的SYN Flood防禦演算法和模式，這個非常重要，SYN Flood防禦演算法和模式對於不同業務產生的影響是完全不同的。錯誤的SYN Flood防禦演算法和模式雖然可以防禦SYN Flood攻擊，但是也會導致業務無法正常訪問。
常見的SYN Flood防禦演算法有:
SYN Cookies SYN Proxy SYN Reset SYN SafeGuard
如果您諮詢的高防服務商無法回答或者不專業的話基本都是代理商和一些騙子。
以上都是我做運維和各種DDoS防護服務商接觸後總結的關於SYN Flood防禦的經驗，上述的演算法都有缺點，所以需要根據業務選擇合適的SYN Flood防禦演算法。
DDoS防禦服務和其他網路安全防禦服務不一樣，由於DDoS攻擊大小一切由服務商說了算，使用者無法核實DDoS攻擊的實際大小，導致了這個行業魚龍混雜， 以次充好的佔據95%以上。後面會重點教會大家如何辨識真假高防！
(ACK RST PSH FIN) Flood攻擊和防禦方式
ACK Flood / RST Flood / PSH Flood / FIN Flood 這類攻擊本質上不如SYN Flood危害那麼大， 但是也足夠輕鬆的導致伺服器癱瘓。
如上圖，這類攻擊雖然不會導致伺服器系統中出現大量的SYN_RECV，但是會出現伺服器向偽造源IP傳送大量的RST報文。
舉個例子：
如果你的伺服器接入頻寬有1Gbps，並假設伺服器OS的PPS處理能力達到1.4Mpps，並且OS設計非常牛逼，沒有導致大量的中斷和鎖的開銷為前提。
那麼你遭受500Mbps的ACK Flood攻擊時，你的伺服器也會出現上行頻寬用到500Mbps左右。
這可非常不划算，而且正常情況下，伺服器OS根本沒辦法處理大量的ACK Flood攻擊。
所以針對這種攻擊，我建議直接上DDoS雲清洗和雲防禦服務，沒必要調整系統，因為沒什麼意義。
UDP Flood攻擊和防禦方式
UDP Flood攻擊目前來說越來越普遍，得益於各種軟體設計缺陷和UDP協議的無連線特性，這讓UDP Flood攻擊非常容易發起，並且可以得到數十倍數千倍的攻擊放大。
我簡單做了一張圖，大家可以看下UDP放大攻擊的原理
對於網站業務來說，是用不到UDP協議的，所以防禦這種攻擊只需要擁有足夠大的接入頻寬(只要接入頻寬比DDoS攻擊更大)，你只需要一條ACL策略 丟棄UDP協議便可以防禦這種攻擊。
但是對於遊戲業務和視訊直播業務來說，那就是噩夢了，因為很大一部分的遊戲和視訊直播業務都是基於UDP協議開發的，因為UDP協議的傳輸速度和 效率比TCP協議更高，延遲也更低，這是UDP的優點，但是也是導致UDP攻擊極難防禦的關鍵原因。
恰好我之前在的公司是做視訊直播的，在這方面和DDoS防護服務商接觸的蠻多，我可以非常負責的說，目前國內能給基於UDP協議的業務防禦這種UDP攻擊的 DDoS防護服務商不超過5家。
為什麼那麼難？
因為UDP資料到了防火牆上的時候，防火牆是不知道這個UDP資料包是好的還是壞的，也沒辦法通過一些類似TCP攻擊的防禦演算法來做源的可信認證。
不過也不是完全沒辦法解決，之前的視訊直播公司是採用了雲服務商提供的端雲聯動方式做的UDP Flood攻擊防禦，效果非常理想。
但是能做這種端雲聯動的防禦演算法的服務商沒幾家，因為大部分DDoS雲清洗和雲防禦服務商都是買的硬體防火牆，沒有實質性的 研發能力和技術實力來驅動這種端雲聯動的防禦演算法。而只有真正擁有完全自研DDoS防禦演算法能力的服務商才可以做到這點。
所以遇到UDP攻擊，恰好你是用UDP協議承載業務的，別想多，準備好錢(每個月至少10萬起步了)，然後 找一家非常專業的DDoS雲清洗服務商給你做保護吧。
DNS Query攻擊和防禦方式
DNS Query攻擊是我從業10多年來，最具備威脅的攻擊方式，普遍存在於棋牌遊戲，私服，菠菜，AV等暴利，競爭不是你死就是我活的行業。
雖然我沒遇到過，但是沒吃過豬肉，也見過豬跑。
攻擊的原理示意圖如下：
這種攻擊最大的威脅便是，通過隨機構造並查詢被攻擊域名的二級域名，繞過遞迴DNS伺服器的解析記錄快取， 各地區地市的遞迴DNS伺服器向權威DNS伺服器發起大量的DNS查詢請求，如果被攻擊域名所在的權威DNS伺服器 效能和頻寬無法支撐查詢所需要的頻寬，那麼就會直接癱瘓，並影響這個權威DNS伺服器上的其他域名。
所以防禦這種DNS Query攻擊，不但難度極大，而且成本極高，並且還不一定是100%防禦。
尤其是遞迴DNS伺服器壓力過大的時候，運營商可以直接封禁被攻擊的域名，就算權威DNS伺服器能夠支撐，此時你的域名還是無法解析，等於說服務癱瘓。
怎麼防禦？
這種只能找專業的DNS服務商和運營商配合來做，否則都是無效的，費用也應該是天價了。
HTTP(s) Flood攻擊(CC攻擊)和防禦方式
HTTP(s) Flood攻擊和SYN Flood攻擊一樣非常棘手，但是也非常經典，攻擊效果非常顯著，而防禦難度卻比SYN Flood攻擊高出幾個數量級！
攻擊發起看似非常簡單，實則暗藏玄機！
HTTP(s) Flood攻擊早在08年的時候，防禦還是較為簡單的，因為瀏覽器單一(大部分都是IE瀏覽器)，通常硬體防火牆會採用JS-Redirect演算法來做CC防禦，效果非常 顯著，但是99%的DDoS硬體防火牆是不支援HTTPS場景防禦的。
到了12年移動網際網路高度發達的時候，傳統的硬體防火牆對於CC攻擊的防禦早已力不從心(根本防不住)，各種瀏覽器百花齊放，PC端的360瀏覽器，Chrome，FireFox，IE，手機端的UC瀏覽器，QQ瀏覽器，Chrome，Firefox瀏覽器等。
同時攻擊軟體也日新月異，各種攻擊模式，很大一部分的攻擊軟體甚至都可以完全模擬使用者行為，使用headless瀏覽器攻擊網站，真真假假很難分辨。
針對CC攻擊的防禦，也是分攻擊規模的。
如果攻擊規模不大的，可以考慮將被攻擊的頁面靜態化，避開資料庫查詢，和動態語言。
如果攻擊規模巨大，每秒QPS高達數萬以上的CC攻擊，有兩種辦法。
方法1: 購買大量的伺服器和頻寬，以及專業的硬體負載均衡裝置做負載均衡，將WEB伺服器和資料庫伺服器做成叢集和高可用架構，這樣可以極大的提高CC攻擊的防禦能力。但是這個成本可能會很高。
方法2: 購買專業的DDoS雲清洗和雲防禦服務商的服務，專業的事情交給專業的人去做。
這裡我友情提示一下，CC攻擊防禦難度很高，建議讓防禦服務商免費提供1-3天的防禦試用，如果三天期間防禦效果不滿意可以換一家，而不至於被騙。
慢請求攻擊和防禦方式
慢請求攻擊是這幾年新興的攻擊方式，通過大量的肉雞發起大量的請求，每個肉雞每秒只請求1次，大量肉雞會導致伺服器遭受大量的攻擊請求，但每個源IP看著卻 沒有異常行為。
慢請求型的CC攻擊危害較大，但是發起的難度和成本也會高一些，通常攻擊者為了利用有限的肉雞打出較大的攻擊，通常會將單個肉雞的每秒查詢速度設定到較大的值，例如每秒5到10次，這種攻擊方式往往可以通過源IP頻率限制等方式攔截，而慢請求型的CC攻擊反其道而行，攻擊者往往有足夠多的肉雞資源。
例如攻擊者有10萬肉雞線上量，那麼每個肉雞每秒只發起一次請求，10萬個肉雞也可以發起10萬每秒的請求，這對於WEB伺服器來說壓力是巨大的，尤其是中小型企業，沒有那麼多預算去做Web叢集和資料庫叢集，以及動態可伸縮的Web和SQL/">MySQL，一旦面臨這種慢連線和慢請求CC攻擊，基本上都會直接出現資料庫過載癱瘓，Web伺服器癱瘓。
慢請求攻擊示意圖:
防禦方式：
方案1：主要是擴充套件後端業務伺服器規模來死扛這種攻擊，成本極高，但是能解決。
部署資料庫叢集，支援橫向擴充套件，應對超大的CC攻擊帶來的資料庫查詢壓力。
部署WEB伺服器叢集，支援橫向擴充套件，對應超大CC攻擊帶來的CPU和記憶體以及核心連線數瓶頸壓力。
業務熔斷機制和演算法，需要自行研發業務熔斷保護演算法，在遭受超大攻擊的時候能夠對業務進行熔斷和降級保護，防止所有業務全線崩潰。
方案2：尋找專業的雲安全服務提供商，解決這種攻擊。
脈衝型攻擊和防禦方式
還有一種攻擊我們叫做脈衝型的攻擊，啥叫脈衝型，就是攻擊流量不持續，每秒發動數次，並且可以及時停止，及時發起，這種攻擊的危害非常巨大，基本上所有防禦服務商都不願意防禦這種攻擊，原因我下面會詳細講解。
先放一張之前看到的脈衝型DDoS攻擊的PPS圖：
這種攻擊可以在短時間內發起多次DDoS攻擊，並且快速停止，快速打擊，這對於很多雲安全防禦服務商來說就是噩夢。
為啥那麼說呢？我們先來梳理一下雲安全服務商和IDC服務商的DDoS硬體防火牆的部署模式。
模式A: 串聯模式(In-line)
串聯模式部署的DDoS防禦系統對於攻擊流量檢測和防禦可以非常及時，通常可以在1秒左右檢測到DDoS攻擊並啟用防禦，最快的可以做到毫秒級別。
只要頻寬足夠，對付這種脈衝型DDoS攻擊還是比較輕鬆，但是對於黑洞牽引檢測來說是有威脅的，因為脈衝型攻擊的快起快落會讓取樣準確率會下降，非常容易出現不能及時封堵這種DDoS攻擊，如果瞬間攻擊流量超過IDC出口，但黑洞牽引系統沒有如此高效的檢測，就會出現 服務斷斷續續，影響整個IDC出口下的服務。
模式B: 旁路模式(Out-of-path)
旁路部署模式需要由DDoS清洗裝置和DDoS檢測裝置組成，通常90%的雲安全服務商和IDC機房是採用旁路部署模式，這種部署需要DDoS檢測裝置檢測到DDoS攻擊後才可以將被攻擊IP地址的路由 牽引到DDoS清洗裝置上。
通常DDoS檢測裝置大都採用取樣方式檢測，而不是全量檢測，取樣檢測的效率較低，響應時間會比較高，通常需要攻擊持續一段時間，而脈衝型DDoS攻擊每次持續時間可能就數秒，這種情況下，旁路部署的防禦服務基本會失效，需要防禦服務商手工牽引到DDoS清洗裝置上進行流量清洗。
脈衝型攻擊還可以實現Bypass Mitigation的攻擊方式，足量的肉雞和足夠快的脈衝攻擊頻率，只需要100G-200G的攻擊流量即可癱瘓T級別的防禦，並且防禦難度極高，對於DDoS清洗裝置的壓力和可靠性要求巨大。
防禦脈衝型攻擊確實沒辦法自己解決，只能依靠專業的雲安全服務商解決，並且是有足夠強大的研發能力和技術支撐能力的。
混合向量(Multi-Vector )攻擊方式和防禦方式
其實也不用那麼高大上的叫混合向量攻擊，接地氣的名字叫做混合DDoS攻擊，這種DDoS攻擊通常只存在於利潤巨大，競爭巨大，並且有著血海深仇對手的攻擊。
這種攻擊通常會利用所有可利用的攻擊方式來攻擊目標，初期的目的是讓DDoS硬體防火牆處理不過來，但現在的DDoS硬體防火牆根本不在怕的(除非這家ddos防火牆的程式碼和業務邏輯有問題)，唯一要擔心的是你防禦演算法能否精細的過濾掉這些惡意流量，否則多種攻擊方式混合，但凡漏了一些攻擊流量進入後端伺服器，那就是災難性的。
關於這種攻擊的配圖，也沒什麼好的配圖，所以我就隨便來一張吧
由於篇幅有限，我就先寫到這裡，這篇文章我偏重對於DDoS攻擊方式和危害性的科普，下篇文章來詳細說明DDoS防禦商的那些小算盤和防禦方式，因為筆者今年和運營商打了蠻多交道，也瞭解了一些DDoS防禦商的做法和防禦方式，下篇文章將會詳細講解。敬請期待！
*本文原創作者：羅永浩的迷弟，本文屬FreeBuf原創獎勵計劃，未經許可禁止轉載