當網站遭遇DDOS攻擊的解決方案及展望

仲介交易 SEO診斷 淘寶客 雲主機 技術大廳

一、事件發生

春節長假剛過完，WEB就出現故障，下午1點吃完回來，立即將桌面解鎖並習慣性的檢查了Web伺服器。 通過Web伺服器效能監控軟體圖像顯示的向下滑行的紅色曲線看到WEB出現問題了。

根據上述的問題，我馬上開始核查Web伺服器的日誌，試試是否能檢測到問題究竟什麼時候開始，或者發現一些關於引起中斷的線索。 正當查詢線索過程中。 公司首席運營官(COO)告訴我，他已經接到客戶的投訴電話，報告說無法訪問他們的網站。 於是從桌上型電腦中敲入網站位址，試著從臺式電腦訪問他們的網站，但是看到的只是無法顯示此頁面的消息。

回想前幾天也未對Web伺服器做了任何改變也未對Web伺服器做過任何改變，伺服器曾經出現過的性能問題。 在Web伺服器的日誌檔中沒有發現任何可疑之處，因此接下來我去仔細查看防火牆日誌，和路由器日誌。 仔細查看了防火牆日誌，列印出了那台伺服器出問題時的記錄。 並過濾掉正常的流量並保留下可疑的記錄。 表中顯示了列印出來的結果。

表一 防火牆日誌

之後在路由器日誌上做了同樣的工作並列印出了看上去異常的記錄。

攻擊期間的路由器日誌

圖一

解釋：

IP packet sizedistribution 這個標題下的兩行顯示了資料包按大小範圍分佈的百分率。 這裡顯示的內容表明：98.4%的資料包的大小在33位元組到64位元組之間(注意紅色標記)。

參數解釋：

IP packet sizedistribution 這個標題下的兩行顯示了資料包按大小範圍分佈的百分率。 這裡顯示的內容表明：98.4%的資料包的大小在33位元組到64位元組之間。

Protocol 協定名稱

Total Flows 自從最後一次清除統計資訊後，這種協定的資訊流的個數。

Flows/Sec 每秒鐘時間內出現這種協定的資訊流的平均個數，它等於總資訊流數/綜合時間的秒數。

Packets/Flow 遵守這種協定的資訊流中平均的資料包數。 等於這種協定的資料包數，或者在這段綜合時間內，這種協定的資訊流數。

Bytes/Pkt 遵守這種協定的資料包的平均位元組數(等於這種協定總位元組數，或者在這段綜合時間內，這種協定的資料包數)。 B/Pkt ，這一資訊流中每個資料包的平均位元組數

Packets/Sec 每秒鐘時間內這種協定的平均資料包數(它等於這種協定的總數據包)，或者這段綜合時間的總秒數。

Active(Sec)/Flow 從第一個資料包到終止資訊流的最後一個資料包的總時間(以秒為單位，比如TCP FIN，終止時間量等等)，或者這段綜合時間內這種協定總的資訊流數。

Idle(Sec)/Flow 從這種協定的各個非終止資訊流的最後一個資料包起，直到輸入這一命令時止的時間總和(以秒為單位)，或者這段綜合時間內資訊流的總時間長度。

正常路由日誌

圖二

IP packet sizedistribution 這個標題下的兩行顯示了資料包按大小範圍分佈的百分率。 這裡顯示的內容表明：2%的資料包的大小在33位元組到64位元組之間。

注意網站的訪問量直線下降。 很明顯，在這段時間沒人能訪問他的Web伺服器。 我開始研究到底發生了什麼，以及該如何儘快地修復。

二、事件分析

我的Web伺服器發生了什麼?很有可能攻擊，那麼受到什麼樣的攻擊呢?從這一攻擊是對回顯埠看，即是埠7，不斷發送小的UDP資料包來實現。 攻擊看似發自兩個策源地，可能是兩個攻擊者同時使用不同的工具。 在任何情況下，超負荷的資料流程都會拖垮Web伺服器。 然而攻擊位址源不確定，不知道是攻擊源本身是分佈的，還是同一個位址偽裝出許多不同的IP位址，這個問題比較難判斷。 假如源位址不是偽裝的，是真真實位址，則可以諮詢ARIN I美國Internet號碼註冊處，從它的「Whois」資料庫查出這個入侵1P位址屬於哪個網路。 接下來只需聯繫那個網路的管理員就可以得到進一步的資訊。

那麼假如源位址是偽裝的，追蹤這個攻擊者就麻煩得多。 若使用的是Cisco路由器，則還需查詢NetFlow快取記憶體。 NetFlow是Cisco快速轉發(CEF)交換框架的特性之一。 為了追蹤這個偽裝的位址，必須查詢每個路由器上的NetFlow緩存，才能確定流量進入了哪個介面，然後通過這些路由器一次一個介面地往回一路追蹤，直至找到那個IP位址源。 然而這樣做是非常難的，因為在Web Server和攻擊者的發起pc之間可能經由許多路由器，而且屬於不同的組織。 另外，必須在攻擊正在進行時做這些分析。

經過分析之後，將防火牆日誌和路由器日誌裡的資訊關聯起來，發現了一些有趣的相似性，如表黑色標記處。 攻擊的目標顯然是Web伺服器192.68.0.175，埠為UDP 7，即回顯埠。 這看起來很像拒絕服務攻擊(但還不能確定，因為攻擊的分佈很隨意)。 位址看起來多多少少是隨意而分散的，只有一個源位址是固定不變的，其源埠號也沒變。 這很有趣。 接著又將注意力集中到路由器日誌上。

立刻發現，攻擊發生時路由器日誌上有大量的64位元組的資料包，而此時Web伺服器日誌上沒有任何問題。 他還發現，案發時路由器日誌裡還有大量的「UDP-other」資料包，而Web伺服器日誌也一切正常。 這種現象與基於UDP的拒絕服務攻擊的假設還是很相符的。

攻擊者正是用許多小的UDP資料包對Web伺服器的回顯(echo 7)埠進行洪泛式攻擊，因此他們的下一步任務就是阻止這一行為。 首先，我們在路由器上堵截攻擊。 快速地為路由器設置了一個過濾規則。 因為源位址的來源很隨機，他們認為很難用限制某個位址或某一塊範圍的位址來阻止攻擊，因此決定禁止所有發給192.168.0.175的UDP包。 這種做法會使伺服器喪失某些功能，如DNS，但至少能讓Web伺服器正常工作。

路由器最初的臨時DOS存取控制鏈表(ACL)

access-list 121 remark Temporary block DoS attack on web server 192.168.0.175

access-list 105 deny udp any host 192.168.0.175

access-list 105 permit ip any any

這樣的做法為Web伺服器減輕了負擔，但攻擊仍能到達web，在一定程度上降低了網路性能。 那麼下一步工作是聯繫上游頻寬供應商，想請他們暫時限制所有在他的網站埠7上的UDP入流量。 這樣做會顯著降低網路上到伺服器的流量。

三、針對DOS預防措施

對於預防及緩解這種頻寬相關的DoS攻擊並沒有什麼靈丹妙藥。 本質上，這是一種「粗管子打敗細管子」的攻擊。 攻擊者能「指使」更多頻寬，有時甚至是巨大的頻寬，就能擊潰頻寬不夠的網路。 在這種情況下，預防和緩解應相輔相成。

有許多方法可以使攻擊更難發生，或者在攻擊發生時減小其影響，具體如下：

Ø 網路入口過濾

網路服務提供者應在他的下游網路上設置入口過濾，以防止假資訊包進入網路(而把它們留在Internet上)。 這將防止攻擊者偽裝IP位址，從而易於追蹤。

Ø 網路流量過濾

過濾掉網路不需要的流量總是不會錯的。 這還能防止DoS攻擊，但為了達到效果，這些篩檢程式應儘量設置在網路上游。

Ø 網路流量速率限制 一些路由器有流量速率的最高限制。

這些限制條款將加強頻寬策略，並允許一個給定類型的網路流量匹配有限的頻寬。 這一措施也能預先緩解正在進行的攻擊，同時，這些篩檢程式應儘量設置在網路上游(盡可能靠近攻擊者);

Ø 入侵偵測系統和主機監聽工具

IDS能警告網路系統管理員攻擊的發生時間，以及攻擊者使用的攻擊工具，這將能協助阻止攻擊。 主機監聽工具能警告管理員系統中是否出現DoS工具

Ø 單點傳送RPF

這是CEF用於檢查在介面收到的資料包的另一特性。 如果源IP位址CEF表上不具有與指向接收資料包時的介面一致的路由的話，路由器就會丟掉這個資料包。 丟棄RPF的妙處在於，它阻止了所有偽裝源IP位址的攻擊。

針對DDOS預防措施

看了上面的實際案例我們也瞭解到，許多DDoS攻擊都很難應對，因為搞破壞的主機所發出的請求都是完全合法、符合標準的，只是數量太大。 借助恰當的ACL，我們可以阻斷ICMP echo請求。 但是，如果有自己的自治系統，就應該允許從網際網路上ping你。 不能ping通會使ISP或技術支援小組(如果有的話)喪失某些故障排解能力。 也可能碰到具有Cisco TCP截獲功能的SYN洪流：

Router(config)#ip tcp intercept list 101

Router(config)#ip tcp intercept max-incomplete high 3500

Router(config)#ip tcp intercept max-incomplete low 3000

Router(config)#ip tcp intercept one-minute high 2500

Router(config)#ip tcp intercept one-minute low 2000

Router(config)#access-list 101 permit any any

如果能採用基於上下文的存取控制(CoNtext Based Access Control，CBAC)，則可以用其超時和閾值設置應對SYN洪流和UDP垃圾洪流。 例如：

Router(config)# ip inspect tcp synwait-time 20

Router(config)# ip inspect tcp idle-time 60

Router(config)# ip inspect udp idle-time 20

Router(config)# ip inspect max-incomplete high 400

Router(config)# ip inspect max-incomplete low 300

Router(config)# ip inspect one-minute high 600

Router(config)# ip inspect one-minute low 500

Router(config)# ip inspect tcp max-incomplete host 300 block-time 0

警告：建議不要同時使用TCP截獲和CBAC防禦功能，因為這可能導致路由器超載。

打開Cisco快速轉發(Cisco Express Forwarding，CEF)功能可説明路由器防禦資料包為隨機源位址的洪流。 可以對調度程式做些設置，避免在洪流的衝擊下路由器的CPU完全超載：

Router(config)#scheduler allocate 3000 1000

在做了這樣的配置之後，IOS會用3s的時間處理網路介面插斷要求，之後用1s執行其他任務。 對於較早的系統，可能必須使用命令scheduler interval《milliseconds》。

四、總結

無論是出於報復、敲詐勒索、發起更大規模攻擊，DoS或DDoS攻擊都是一種不容輕視的威脅。 非同一般的DoS攻擊通常是某種不完整的漏洞利用—使系統服務崩潰，而不是將控制權交給攻擊者。 防範這種攻擊的辦法是及時打上來自廠商的補丁，或者對於Cisco系統，及時將作業系統升級到更新版本。 同時，要關閉有漏洞的服務，或者至少要用存取控制清單限制訪問。 常規的DoS攻擊，特別是DDoS攻擊，經常不是那麼有章法，也更難防範。 如果整個頻寬都被蹩腳的ping洪流所耗盡，我們所能做的就很有限了。 最後，必須與ISP和權力部門協作，盡可能從源頭上阻止攻擊。 要用不同供應商、不同AS路徑並支援負載均衡功能的不止一條到網際網路的連接，但這與應對消耗高頻寬的常規DoS/DDoS洪流的要求還相差很遠。 我們總是可以用CAR或NBAR來拋棄資料包或限制發動進攻的網路流速度，減輕路由器CPU的負擔，減少對緩衝區和路由器之後的主機的佔用。

文章來源：HTTP://www.cnblogs.com/chenguang/archive/2011/02/26/1965918.html