概念 CC攻擊的原理就是攻擊者控制某些主機不停地發大量資料包給對方服務器造成服務器資源耗盡，一直到宕機崩潰，CC主要是用來攻擊頁面的，每個人都有這樣的體驗：當一個網頁訪問的 人數特別多的時候，打開網頁就慢了， CC就是模擬多個用戶(多少執行緒就是多少用戶)不停地進行訪問那些需要大量資料操作(就是需要大量CPU時間)的頁面，造成服務器資源的浪費， CPU長時間處于100%， 永遠都有處理不完的連接直至就網路擁塞，正常的訪問被中止， 攻擊方式 通常發起 CC 攻擊是使用專門的攻擊工具，同時模擬成多個用戶，向目標網站發起多個請求，一般這些軟體為了防止地址被屏蔽，還內置通過代理攻擊的功能，可以通過多個代理服務器對 目標發起攻擊，使封 IP 的防御方式變的失效， 防御思路 我們拋開購買的軟體來防護 下面主要從程式角度來做防護， 某人使用過某某網站衛士來預防攻擊他的評價： 從界面上看，似乎是防止了大量的CC攻擊，但登錄網站后發現，流量依舊例外，攻擊還是依舊，看起來這個網站衛士的效果并沒有達到， 從原理上看，基本上所有的防火墻都會檢測并發的TCP/IP連接數目，超過一定數目一定頻率就會被認為是Connection-Flood，但如果IP的數量足夠大，使得單個IP的連接數較少， 那么防火墻未必能阻止CC攻擊， 啟用了某某網站衛士之后，反而更容易被CC攻擊，因為這個網站衛士并不能過濾掉CC攻擊，攻擊的IP經過其加速后，更換成為這個網站衛士的IP，在網站服務器端顯示的IP都是相同的， 導致服務器端無法過濾這些IP， 因為 CC 攻擊通過工具軟體發起，而普通用戶通過瀏覽器訪問，這就是區別，我們只有想到辦法對這二者作出正確的判斷，屏蔽來自機器的流量攻擊就沒問題了， 思路一： 普通瀏覽器發起請求時，除了要訪問的地址以外， Http 頭中還會帶有 Referer ， UserAgent 等多項資訊，遇到攻擊時可以通過訪問日志查看訪問資訊，看攻擊的流量是否有明顯特征， 比如固定的 Referer 或 UserAgent ，如果能找到特征，就可以直接屏蔽掉了， HTTP_Referer 名詞解釋 看單詞知道大概意思是 http的訪問來源 HTTP Referer是header的一部分，當瀏覽器向web服務器發送請求的時候，一般會帶上Referer，告訴服務器我是從哪個頁面連接過來的， UserAgent 名詞解釋 HTTP_USER_AGENT是用來檢查瀏覽頁面的訪問者在用什么作業系統（包括版本號）瀏覽器（包括版本號）和用戶個人偏好的代碼， UserAgent 標準格式是 ： 瀏覽器標識 (作業系統標識; 加密等級標識; 瀏覽器語言) 渲染引擎標識 版本資訊（但是不同的瀏覽器的格式是不同的，大體都包括這些內容） 下圖就是 瀏覽器的 HTTP_Referer 和 HTTP_USER_AGENT
大家明白了的吧 如果這兩個有固定的特征就可以直接用程式屏蔽了） 這里用useragent做了一個判斷邏輯是這樣的 快取最近訪問的二十條記錄， 如果到了二十條就開始做對比，如果這二十條的user-agent 一樣就把這個user-agent 給封了， 如果不一樣就繼續回到0 開始， 為了避免網站一個人訪問的情況下誤殺，加上一個時間判斷效果最好 比如 三秒內， 上代碼
然后對比
計算時間差
我這里是根據實際情況判斷的 （考慮到白名單， 黑名單， ip斷等場景需要）
好了 userAgent 防御大概就說這么多， 思路二： 上面也說了用userAgent可以根據情況來屏蔽， 但是這個玩意還是可以偽造的(ps： 雖然 比較困難)，如果偽造了我們就要像其它辦法了；我們知道一般的 攻擊軟體一般來說功能都比較簡單，只有固定的發包功能，是不支持完成的http協議的 而瀏覽器會完整的支持 Http 協議，我們可以利用這一點來進行一下防御， 用戶初次訪問的時候我們定義個規則 token（ps：這個應該是有唯一key 生成的），保存在 COOKIE 中作為 Token ，用戶必須要帶有正確的 Token 才可以訪問后端服務，當用戶第一次訪問時，會 檢測到用戶的 COOKIE 里面并沒有這個 Token ，則回傳一個 302 重定向跳轉，目標地址為當前頁面，同時在回傳的 Http 頭中加入 ，對 COOKIE 進行設定，使用戶帶有這個 Token ， 客戶端如果是一個正常的瀏覽器，那么就會支持 HTTP 頭中的 SET COOKIE 和 302 重定向指令，將帶上正確的 Token 再次訪問頁面，這時候后臺檢測到正確的 Token ，就會放行， 這之后用戶的 Http 請求都會帶有這個 Token ，所以并不會受到阻攔，客戶端如果是 CC 軟體，那么一般不會支持這些指令，那么就會一直被攔在最外層，并不會對服務器內部造成壓力， 代碼：這里主要用php 代碼來說明
token 生成演算法 大致這樣 UserAgent + client_ip + key 這樣就避免了無法偽造，保證了相同的客戶端的 token 的一致性，
對 CC 攻擊者來說，在使用固定或者唯一 Token 的情況下，攻擊成本是有差別的， 很多攻擊軟體是可以設定 http 頭的，如果使用固定 Token ，攻擊者只需要在本機獲取一次 Token ，然后設定好 http 頭就可以直接發起攻擊了，攻擊成本低的可以, 但是如果使用可變 Token ，基本市面上所有 CC 軟體全都無法使用了 ,我們這個就是可變的token (隨 IP 地址變化是為了防止通過一臺機器獲取 Token 之后，再通過代理服務來進行攻擊) 實際上 token 只能擋普通攻擊，計算 token 這個事情本身就消耗 CPU 資源，攻擊的時候為了省帶寬也有只發不收，只要入口帶寬沒有被塞滿，普通 cc 攻擊都可以擋住， 但是如果暴力發包，只發不收的攻擊來說，帶寬都滿了，并并不能通過這種方式進行防御， 弊端： 這樣的token 對搜索引擎不夠友好，這 token 校驗第一波擋住的是搜索引擎的爬蟲，所以，最好只是在被攻擊的時候開啟這個功能，平時關閉掉. 其它： 如果你的網站是使用的是Nginx做的反向代理，那么可以利用Nginx原生的limit_req模塊來針對請求進行限制，ngx_http_limit_req_module 總結： 綜上所述：最好在受到攻擊的時候才開啟token， ps: 并沒有絕對的防御方式，我們所能做的也就是不斷提高攻擊者的成本，通過手段把不合法的流量攔住，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/45211.html
標籤：其他
下一篇：簡單模擬三層內網滲透