前言：我們服務器經歷了長時間低頻CC的困局，CPU居高不下，歷經周折，終於找到了用開源waf解決方法，寫點東西出來給大家分享一下吧。
1、阿里雲waf流量清洗
飛泊雲停是一款基於微信支付的智能停車管家，公司是智慧城市倡導者，讓出行更便捷，讓停車更簡單，在行業內有很高的知名度和口碑。同時，公司非常注重網絡安全，購買了CDN和最高防護級別的阿里雲盾web應用防火牆作爲第一道安全屏障，經過阿里雲waf清洗後的流量變得非常乾淨，過濾了大量的威脅（如SQL注入、XSS、高頻CC、DDOS等），爲馬爸爸和王堅博士的網絡安全團隊點贊。阿里雲waf基本架構是：
然而，總有那麼個別不懷好意的人，通過人工分析飛泊雲停的停車記錄接口，精準選擇了幾個計算資源最多（最消耗CPU和內存）的動態API接口，同時動用了數以十萬計的肉雞（或代理IP），向源站服務器發動頻繁請求。由於這些請求都是合法的，並且單個IP頻率很低（不超過10個），阿里雲waf視爲合法流量，全部被穿透了打在源站服務器上，導致服務器長期CPU佔用99%經常報警甚至重啓，嚴重影響了客戶停車體驗。
2、增加開源waf保護源站
公司無奈報警，但警察叔叔每天大案要案非常忙的，給出的建議是用專業技術對抗。於是經過大量搜索發現：aihttps是hihttps的升級版，是一款基於人工智能的開源waf，專門對抗未知攻擊，或許對低頻CC有效，於是公司決定用其商業部源代碼的方式部署，在阿里雲waf和真實服務器之間，再加一層waf過濾，之所以用源代碼部署，是爲了保證服務器安全，杜絕惡意代碼和後門程序。於是網絡架構變成了這樣的模式：
互聯網---CDN---阿里雲waf---aihttps開源waf---F5負載均衡---真實web服務器
果然，開源waf一部署上去，報警很少（畢竟大量攻擊被阿里雲waf過濾了），但立刻從流量裏面就發現了異常，每天高達幾十萬的IP地址訪問記錄，而且大量IP地址的訪問次數不超過10次，這遠遠超過了公司正常的業務IP數量，從而判斷基本確定95%以上的IP都是低頻CC攻擊，這正是服務器CPU過高的元兇。
這個時候任何waf都不敢貿然封殺正常流量，我們用人工的方式分析溯源日誌裏的流量，很快發現了特徵：攻擊構造的HTTP頭，和真實微信支付裏面的HTTP頭如Cookie內容字段上有一定區別。如下圖所示的user_agent、cookie、traceid等，總有地方和真實的微信支付不一樣。
於是根據這些特徵，生成了專家對抗規則用於檢測HTTP非法頭部和非法的Cookie信息，在aihttps上運行檢測報警模式：
天哪，結果每天都有數十萬攻擊IP，最多的1天有60萬IP，而且這些IP基本來自國內，無法通過禁用國外IP等地域方式阻擋。
攻擊IP觸目驚心，意味着國內排名前三位的江蘇、山東、廣東，每天至少數萬的IP地址已經被木馬團伙淪陷，用於跳板做攻擊。我們終於明白警察叔叔的良苦用心了，這些IP也是受害者，網絡安全絕非某個組織、專家的事情，而是全民都要重視了。
3、欺騙攻擊者
檢測模式運行了三天，確認沒有誤報後，公司領導迫不及待想改變爲阻斷模式，精確阻斷纔能有效保護服務器。由於aihttps開源waf默認的阻斷方式是http 302響應跳轉到某個網址，專家給出的意見是不能用這種方式。原因是：這種阻斷方式，攻擊者很快就會知道我們有防禦，攻防乃頂級智商的較量，兵者，詭道也。於是我們修改了開源waf的源碼（httpx.c）文件，把阻斷返回方式從302 location，調整爲和服務器返回的json格式一樣：
{code:666, msg:”沒有餘額”}
這樣攻擊者得到的響應，和原來服務器返回的結果一樣。
4、總結
這樣低頻CC的所有流量被WAF阻斷了，後端WEB服務器CPU恢復到了正常的水平，總結起來就是以下幾點：
1、 用cdn和阿里雲waf集羣防禦高頻攻擊。
2、 用開源waf保護源站服務器。自定義HTTP頭和開源waf聯動，修改源碼，讓開源waf深入理解服務器業務，精準阻斷低頻攻擊。
3、 如果是APP，還可以學學淘寶接口，用公私鑰對關鍵接口的HTTP頭做加密校驗，可以精準檢測攻擊。
4、 產品較量上升到頂級智商的較量，即在HTTP頭和響應裏面互相欺騙。如果攻擊者升級構造了http頭，我們已經做好了升級預案：在開源waf裏和後端redis服務器互動校驗cookie頭部session的真實性來對抗。
攻防同源，對抗遠遠沒有結束，直到發稿的時候，每天幾十萬IP地址的低頻CC攻擊仍然傻傻的打到了aihttps開源WAF上。如果攻擊者把每天IP地址調整到數千萬級別，也是扛不住的，但它的進攻成本已經遠遠大於我們的防禦成本了。