關鍵字：ngx_http_limit_conn_module, ngx_http_limit_req_module
1、常見的幾種服務器攻擊類型（快速瞄下就好）
一、注入腳本
利用后台漏洞通過URL、表單提交等行為將關鍵SQL、JavaScript等腳本帶入程序，從而在數據庫或應用中進行破壞。還有許多黑客會使用F12或postman等拼裝ajax請求，將非法數據發送給后台，造成程序的報錯使其暴露出異常信息，攻擊裝根據異常猜測后台使用的語言及框架。
| XXS | 跨站腳本攻擊（XSS）通常指的是通過利用網頁開發時留下的漏洞，通過巧妙的方法注入惡意指令代碼到網頁，使用戶加載並執行攻擊者惡意制造的網頁程序。這些惡意網頁程序通常是JavaScript，但實際上也可以包括Java、 VBScript、ActiveX、 Flash 或者甚至是普通的HTML。攻擊成功后，攻擊者可能得到包括但不限於更高的權限（如執行一些操作）、私密網頁內容、會話和cookie等各種內容 |
二、網絡嗅探程序
查看通過Internet的數據包來抓取口令和內容，通過偵聽器程序可以監視網絡數據流，從而獲得用戶登錄的賬號和密碼。數據的安全傳輸可以采用對稱加密、非對稱加密、走https協議、CSRF驗證、TOKEN驗證等手段相結合進行防治。
三、拒絕服務
這是常見的一種方式，通過向某個站點服務器反復發送請求，導致無法承載大量的請求而“拒絕服務”。
| CC | CC攻擊的原理就是攻擊者控制某些主機不停地發大量數據包給對方服務器造成服務器資源耗盡，一直到宕機崩潰◊ CC主要是用來攻擊頁面的，每個人都有這樣的體獫：當一個網頁訪問的人數特別多的時候，打幵網頁就慢了，CC就是模擬多個用戶(多少線程就是多少用戶)不停地進行訪問那些霓要大量數據操作(就是霓要大量CPU時間)的頁面，造成服務器資源的浪費，CPU長時間處於100%, 7：k遠都有處理不完的連接直至就網絡擁塞，正常的訪問被中止。 |
| DDoS |
全稱Distributed Denial of Service，中文意思為“分布式拒絕服務”，就是利用大量合法的分布式服務器對目標發送請求，從而導致正常合法用戶無法獲得服務。通俗點講就是利用網絡節點資源如：IDC服務器、個人PC、手機、智能設備、打印機、攝像頭等對目標發起大量攻擊請求，從而導致服務器擁塞而無法對外提供正常服務，只能宣布game over。@link https://www.jianshu.com/p/e7a5fdc67b8f
windows平台存在大量漏洞，流氓軟件，病毒，木馬大量充斥着網絡，黑客可以很容易入侵控制大量的個人計算機來發起DDOS攻擊從中謀利。攻擊已經演變成非常完善的產業鏈◊通過在大流量網站的網頁里注入病毒木馬，木馬可以通過windows平台的漏洞感染瀏覽網站的人，一旦中了木馬，這台計算機就會被后台操作的人控制，這台計算機也就成了所謂的肉雞，每天都有人專門收集肉雞然后以幾毛到幾塊的一只的價格出售，因為利益需要攻擊的人就會購買，然后遙控這些肉雞攻擊服務器。 |
四、釣魚網站
這種手段需要黑客會構建釣魚網站，對目標網站的請求方式比較了解，一般會通過在目標網站內利用留言功能留下網址，可能管理員會通過這個網址進入黑帽構造的網頁而觸發增加管理用戶的請求。
五、木馬植入
黑客直接通過向服務器種植木馬，開啟后門，取得控制權。
六、惡意小程序
攜帶在我們常用應用上的微型程序，可以修改硬盤上的文件，以竊取口令等。
2、短信接口被惡意調用，如何解決？
前段時間“聊天”被問“短信驗證碼登錄”的交互，需要幾個接口，怎么實現？因為平時有做過驗證碼登錄，所以回答：“第一個接口就是發送短信驗證碼，第二個是登錄接口；第一個接口為防止被惡意調用，需要加圖形驗證碼來過濾，巴拉巴拉...”。當時回答得不夠全面，后續提問“如何應對暴力破解驗證碼？”更是完全沒考慮過，所以現在想整理記錄下，最近呢湊巧商城服務器被CC攻擊了，商城的搜索功能平均1秒被請求2次（平時流量很小），所以我就以實戰防御並結合短信接口問題來總結API被惡意調用的解決方案。
- 封禁惡意IP（初級攻擊：攻擊者IP固定，未被偽造）
思路是找出頻繁請求的那些IP，在防火牆或者 web server 級別做限制，拒絕它們的請求。
首先通過分析日志（access_log）找出請求次數最多的前50個IPawk '{print $1}' /var/log/nginx/www.exanple.com.access.log | sort|uniq -c | sort -nr | head -n 50
其次配置Nginx，限制IP訪問，如下：
最后別忘記重啟Nginx。重啟之前可以“nginx -t”預先測試下有沒有語法問題#指定上下文deny掉指定的IP location / { deny 183.129.185.250; deny 112.17.245.112; deny 112.17.245.117; deny 36.23.223.191; deny 8.208.28.143; #allow 192.168.1.1/24; #allow 127.0.0.1; #deny all;
root $wwwroot;
... } - 檢測UA的合法性（初級攻擊：頭信息User-Agent沒有被偽造）
檢測工作可以放在web服務器（nginx、httpd等）上，也可以集成到具體的某個接口、應用中，檢測的方法網絡上有很多這里就不展開了。 - 加驗證碼
驗證碼檢驗可以有效防御大部分的攻擊，且做到以下幾個方面，可以有效防御驗證碼“暴力破解”：
① 驗證碼的位數最好不小於6位
② 根據使用場景合理設置有效期，如：1分鍾，5分鍾，30分鍾
③ 一次一碼原則：驗證后即銷毀
④ 驗證碼校驗錯誤次數超過上限，則采取賬戶鎖定、禁止訪問等策略
------------------------------------------------------------------------另外驗證碼最好有一定的破解難度，因為網絡上驗證碼識別工具很多，所以也可以考慮使用難度更大的文字、圖片相結合的圖文驗證碼，或需要鼠標去移動到指定位置拖拽類驗證碼等。不過復雜的驗證機制會降低用戶使用體驗，所以大家都視自己的情況而定。
- 設置 rate limit
前面提到DDoS是分布式拒絕服務的攻擊，它的攻擊是“分布式”的，來至四面八方，但是這些肉雞不是真正的黑客，他們只是被利用的受害者，所以這些肉雞的請求/攻擊不會主動偽裝，即請求會攜帶真實用戶標識、Client IP等，基於這個我們可以實現rate limit來有效防御部分DDoS。
服務器級別、應用級別分別實現rate limit：
① 服務器級別
以Nginx為例，可以利用 自帶模塊 ngx_http_limit_conn_module 和 ngx_http_limit_req_module 做一些防御工作，能達到不錯的效果，具體如何設置請查閱超鏈接的內容或自行百度google；
② 應用級別
以編程手段，配合緩存服務器如redis、memcached等實現訪問速率限制，通常做法是給訪問者分配密鑰、TOKEN等作為訪問的唯一標識。 - 封禁代理或機房IP
IP可以考慮對代理和機房IP的識別，自己識別成本太高，可以對接第三方的SaaS服務，但也不能保證100%識別代理，70%~80%是差不多的。
此處理解很模糊，待以后完善！ - 購買安全軟件、雲安全服務
針對短信驗證碼問題，還可以考慮“號碼真實性”的檢測，不過即使找短信供應商合作，也很難做到100%的准確率，並且不是實時的，只能說有一定的幫助。