0x00 / 多年運維，不敵攻擊
從05年開始做運維到現在也有13年了，幹過論壇，電商，遊戲，金融，直播這些業務的運維，活很雜，什麼WebServer，Database，Netfilter，Docker，Xen，KVM，OpenVZ，Ceph，iSCSI，DNS， 負載均衡等等。
那麼多年做運維以來，最讓人覺得棘手和絕望的便是DDoS攻擊了，每天晚上睡覺後，都怕接到電話說伺服器被DDoS了。
至於為什麼那麼恐怖，我想做過運維的人或者被攻擊過的企業都應該非常明白，那是一種怎樣的體驗。
0x01 / 噩夢初醒，惶惶不可終日
第一次和DDoS攻擊打交道，那是06年的冬天，第一份工作是為一家網絡廣告聯盟公司做伺服器運維。
基本上每天的任務就是看下伺服器的硬碟I/O負載，資料庫負載，還有是否有錯誤日誌，很平常。
直到06年冬季的某天，公司託管在浙江紹興電信機房的那臺Dell PowerEdge 1850伺服器突然無法訪問，WEB和SSH都無法訪問。
老闆那個急啊，客服那個急啊，真的是可以說熱鍋上的螞蟻，坐立不安。
要知道對於一個廣告聯盟來說，伺服器癱瘓了，站長的收入突然沒了，廣告主的流量突然沒了，這意味著站長和廣告主會流失。
於是乎，聯繫了紹興電信的網維，得知伺服器當時遭受了大流量的DDoS攻擊，攻擊規模在2Gbps左右，電信的網維為了保護機櫃內其他客戶伺服器正常運行，封了我們伺服器的外網IP位址。
為了不影響業務，最後找紹興電信付費做的DDoS防禦服務，雖然最後服務恢復了，但是伺服器的網絡延遲也增加了，因為DDoS攻擊一直在持續。
從那次事件後，公司所有人談DDoS色變。
0x02/ 揮金如土，只為續命
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保底防禦服務。
這次案例告訴我們，有錢真的是可以為所欲為。
0x03/ 這世上有很多悲哀，僅僅是因為沒錢
曾經在貓眼社區上看到一篇帖子，讓我感觸很深，那帖子標題叫做《我的老婆沒錢治病，死了》
當人處於真正的底層時，連選擇繼續生存的資格都沒有，談什麼機會去創造奇蹟。
創業公司不也是如此嗎？大量的創業公司在遭遇DDoS攻擊的時候如同生病，來的那麼突然，那麼措手不及，但有多少創業公司能那麼輕鬆的負擔每月高達數十萬的DDoS防禦費用呢？
有多少人懷著創業夢想，創造奇蹟，想改變行業，但是遇到DDoS攻擊，連選擇繼續生存的資格都沒有，這不是很可悲的事情嗎？
因為DDoS防禦成本太高，加上對DDoS攻擊的不了解，往往會出現病急亂投醫。
這是非常可怕的，猶如患了重病，而三甲醫院費用極高，而選擇那些號稱能根治但並不靠譜的私人和莆田系醫院，最後往往因為錯誤的治療和時間上的拖延導致病重，最後人財兩空。
0x04/ 細說DDoS攻擊
下面進入正題，說一下我遇到的各種DDoS攻擊類型和一些緩解手段，還有防止李鬼，騙子，垃圾高防服務商的一些經驗，以及教大家如何分辨高防服務的真假和水分。
老生常談的一種DDoS攻擊類型，從早期的利用TCP三次握手原理，偽造的IP源，以小博大，難以追蹤，堪稱經典的攻擊類型。
大量的偽造源的SYN攻擊包進入伺服器後，系統會產生大量的SYN_RECV狀態，最後耗盡系統的SYN Backlog，導致伺服器無法處理後續的TCP請求，導致伺服器癱瘓。
就和上面的圖片一樣，伺服器資源被耗盡，用戶無法和伺服器建立連接，攻擊者目的達到。
那如何防禦SYN Flood攻擊呢(其實是緩解，提高一下系統的處理能力，但是只限於小攻擊)？
方式1：軟體防火牆和系統參數優化 (適用於SYN Flood攻擊流量小於伺服器接入帶寬，並且伺服器性能足夠)
【Windows系統: 可以修改註冊表來提高SYN數據包的處理能力】
進入註冊表的[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters]項目
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協議的無連接特性，這讓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攻擊是我從業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和MySQL，一旦面臨這種慢連接和慢請求CC攻擊，基本上都會直接出現資料庫過載癱瘓，Web伺服器癱瘓。
慢請求攻擊示意圖:
防禦方式：
方案1：主要是擴展後端業務伺服器規模來死扛這種攻擊，成本極高，但是能解決。
A. 部署資料庫集群，支持橫向擴展，應對超大的CC攻擊帶來的資料庫查詢壓力。
B. 部署WEB伺服器集群，支持橫向擴展，對應超大CC攻擊帶來的CPU和內存以及內核連接數瓶頸壓力。
C. 業務熔斷機制和算法，需要自行研發業務熔斷保護算法，在遭受超大攻擊的時候能夠對業務進行熔斷和降級保護，防止所有業務全線崩潰。
方案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防禦商的做法和防禦方式，下篇文章將會詳細講解。敬請期待！
如果您痛恨DDoS，歡迎加WeChat，邀請進入討論群，拒絕任何廣告人員加入，純技術交流。