圖形驗證碼+ip（用戶id）+https

http://www.cnblogs.com/han-1034683568/p/7040417.html

前言

承接前文《短信發送接口被惡意訪問的網絡攻擊事件(一)緊張的遭遇戰險勝》，在解決了短信發送的問題後，長長地舒了口氣，也就各忙各的事情去了，本以為應該是個完美的收場，哪知道只是泥濘道路的前一段，收場是收不了了，還是要去應付接下來的爛攤子，因為攻擊者並沒有停止攻擊，雖然惡意請求已經可以被識別並且不會被業務服務器處理，也不會去觸發短信發送接口，但是請求依然會源源不斷的到達服務器，而且絲毫沒有停止的意思。

像前文中說的，那種感覺就像葛大爺被麻匪給劫了，既然被賊給盯上了，你覺得是那麽輕而易舉的就能夠掙脫的了麽？

問題分析

公司用的是阿裏雲的雲服務器ECS，在ECS控制臺中查看入網流量：

雖然在程序中加入邏輯判斷可以阻止非法請求對短信接口的觸發，但是卻無法阻止攻擊者持續的向ECS發送請求，通過上圖ECS的入網流量可以看到，在流量上升之後，並沒有降下來的意思，得，這狗皮膏藥真的一時沒法撕下來了，雖然說這些個攻擊者無聊，但還是得跟他們杠上了，心累。

所以剛剛開心了沒多久，又陷入了困頓之中，剛剛踩完一個坑，爬上來沒多久，發現眼前又是一個坑，坑坑復坑坑，開發的坑是何其多，運維也一樣，都是一家人。

魯迅說過：

你盡管說，說得有用算我輸，坑還是得踩，誰讓你做開發的。

我們都知道流量攻擊，攻擊者用大流量來壓垮網絡設備和服務器，或者有意制造大量無法完成的不完全請求來快速耗盡服務器資源，現在看來這次的短信接口攻擊稱不上流量攻擊，因為數量級不在一個概念上，雖然也存在大量的非法請求，但是並不足以癱瘓設備，當然，這些話都是寫在事件結束之後的，與事件發生時的想法可能有些出入，因為當時並不確定攻擊者的請求是否會持續增加、是否會打滿服務器的帶寬，是否會影響正常請求，是否會使服務器癱瘓.....

看著持續不減的入網流量，思考了半天，最終是打算加入防火墻，通過封掉這些惡意請求的IP，讓ECS直接拒絕請求，在請求的第一步就把它弄死，將入口堵住應該可以一定程度的阻止攻擊者繼續攻擊，也使得流量降低不會影響到處理正常請求所用到的系統資源。

前文提到的只是針對具體的系統模塊，在應用層降低攻擊的危害，因為一開始認為這次攻擊只會影響短信接口，但是如果是流量攻擊的話，則是影響整個服務器層面，會影響所有在這臺服務器上的基礎設施，這個就比較麻煩了，想法只有一個：阻止入網請求。

應急方案--iptables防火墻

一開始想到的是用iptables來作為這次的防火墻工具，花了些時間，寫了一個分析日誌的shell腳本，把攻擊者的IP定位出來，然後把這些IP放到iptables的策略中給封掉，以下為iptables策略設置的腳本，運行腳本的前提是你的linux服務器中安裝了iptables工具。

#!/bin/sh

#iptables設置
#author:13

iptables -P INPUT ACCEPT
iptables -F
iptables -X
iptables -Z
iptables -A INPUT -i lo -j ACCEPT

iptables -I INPUT -s 111.147.220.88 -j DROP
iptables -I INPUT -s 101.68.56.76 -j DROP
iptables -I INPUT -s 106.6.90.58 -j DROP
iptables -I INPUT -s 111.147.212.230 -j DROP
......
（這裏省略了大部分的IP，因為太多了）

iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
iptables -A OUTPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

#保存設置
service iptables save
#重啟iptables服務
systemctl restart iptables.service

雖然選擇了這個方式，但是也知道這種方式比較笨拙和被動，而且不能完全的做到自動化，以後有時間會試著用nginx+lua+redis寫一個攔截器，作為限制惡意IP訪問的小工具，近期也會找一下其他的解決方案。

由此，最新阻止攻擊的方式已經變成了下圖中的模式：

根據日誌文件來分析請求，一旦被識別為惡意IP的話，之後的所有請求都會被iptables防火墻攔截，請求不會被處理，半天時間限制了500多個IP的訪問，但是依然會有新的IP加入到攻擊之中，散列IP攻擊真的很煩，限制了短信發送後，已經不會進一步造成損失，而今天又做了IP訪問限制，更進一步確保了攻擊造成的影響降低，同時也降低了流量陡增給系統帶來的危害。

這次攻擊並沒有造成進一步的影響，應該也算是送了一口氣，從數量級上來看，倒不是特別大的攻擊，就是這兩天的日誌文件比較大，因為在沒有限制IP訪問時，這幾百個IP搭配無數的手機號碼，發送的請求數量是挺驚人的。而至於這次的攻擊者到底是什麽人，出於什麽目的，完全不得而知，人民幣損失也是有的，但是還好發現和解決的及時，並沒有造成太大的影響，肯定不至於丟了工作，哈哈哈哈。

防火墻效果

流量攻擊由第一天的每分鐘1000次左右的惡意請求(統計對象僅包含非法請求，正常請求不包含在內)，通過采用封鎖IP的方法來進行防禦之後，目前為每分鐘10-20次左右的惡意請求，雖然已經攔截掉大部分的攻擊，但是依然不斷會有新的偽裝IP加入到攻擊當中，暫時也想不到其他辦法來應對，因為IP是一直在變的，雖然在半天內已經封鎖掉了500多條IP，不過依然還是會有新的IP帶著新的請求進來，但是好消息是，現在的流量已經不像剛開始那樣，像是開了閘口的洪水一樣噴湧而來了，目前已經是銳減成涓涓細流了，他奶奶的。

整個過程你來我往的，看似熱鬧，其實就是菜雞互啄，攻擊者通過工具發送惡意請求，惡意請求進來並被記錄到日誌文件中，被腳本檢測到之後加入到iptables策略中封鎖IP，然後攻擊者又會利用新的IP做攻擊，檢測到之後再次封鎖，周而復始。說難度嘛，倒是沒什麽技術難度，至於麻煩嘛，是有一些小麻煩，再說損失，通過參數驗證後，應該不會請求短信服務商再造成損失了，關鍵是被惡心到了，畢竟這個事情沒法徹底的解決掉，除非停掉這一個服務，這是不可能的，也只能等下次更新了，中間這段時間只能被惡心了。

防火墻的方案

雖然當時是選擇使用iptables來作為主要的防火墻工具，但是現在想想，也有其他方法的，事後諸葛亮一下，總結了以下四種方式，希望大家補充：

• iptables
• hosts.deny
• 阿裏雲的ECS安全策略
• WAF(這個是前一篇文章中一位朋友留言提到的方案)

結語

也想過在APP重新發版時，重新設計一套url，將原來的url廢棄掉，或者關閉一些服務器以杜絕這些攻擊，但是，這些都是沖動和極端的想法和做法，即使APP重新發版，也不可能立即關閉後端服務器，關閉後端服務意味著完全拋棄對上一個版本的支持，但是正確做法不可能對沒有更新版本的用戶不管不問，即使他們不更新也要保證原來的整體功能可用。不能因為一個服務的錯誤，讓用戶去承受錯誤，不能讓用戶來為我們埋單，停掉服務器的做法不可行，沒有到那個地步，因此只能是自己去解決和維護。

每次發生這種意料之外的事件，都會提醒自己做好安全保障工作，不可掉以輕心，不要給心懷惡意之人有可乘之機，這次損失一塊錢RMB，下次可能是一千塊，一萬塊，金錢的損失可以衡量，如果是給系統帶來影響或者給團隊招來不必要的麻煩就真的百口莫辯了。

目前來看，雖然是解決了一部分問題，用請求驗證阻止發送短信，用iptables阻止惡意IP的訪問，但是並沒有根本解除掉攻擊，不排除攻擊者會進一步攻擊的可能性，因此只能被動的防守，同時也做好web和服務器的安全防護。

首發於我的個人博客，地址在這裏

短信發送接口被惡意訪問的網絡攻擊事件(二)肉搏戰-阻止惡意請求