前言

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

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

問題分析

公司用的是阿里雲的雲伺服器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和伺服器的安全防護。

首發於我的個人部落格，地址在這裡