真實案例：網站遭遇DOS攻擊

真實案例：網站遭遇DOS攻擊
網站遭遇DOS攻擊一、事件背景

長假對於IT人員來說是個短暫的休整時期，可IT系統卻一時也不能停，越是節假日，越可能出大問題，下面要講述的就是一起遭受DOS攻擊的案例。

春節長假剛過完，小李公司的Web伺服器就出了故障。下午1點，吃完飯回來，小李習慣性的檢查了Web伺服器。Web伺服器的流量監控系統顯示下行的紅色曲線，與此同時收到了郵件警示，可以判斷伺服器出現了狀況。

根據上述問題，小李馬上開始核查Web伺服器的日誌，嘗試發現一些關於引起中斷的線索。正當查詢線索過程中，部門經理告訴小李，他已經接到客戶的投訴電話，說無法訪問他們的網站。

在Web伺服器的記錄檔中沒有發現任何可疑之處，因此接下來小李仔細查看了防火牆日誌和路由器日誌。列印出了那台伺服器出問題時的記錄，並過濾掉正常的流量，保留下可疑的記錄。表1顯示了列印出來的結果。

表 1 防火牆日誌統計

源IP地址	目的IP地址	源連接埠	目的連接埠	協議
172.16.45.2	192.168.0.175	7843	7	17
10.18.18.18	192.168.0.175	19	7	17
10.168.45.3	192.168.0.175	34511	7	17
10.18.18.18	192.168.0.175	19	7	17
192.168.89.111	192.168.0.175	1783	7	17
10.18.18.18	192.168.0.175	19	7	17
10.231.76.8	192.168.0.175	29589	7	17
192.168.15.12	192.168.0.175	17330	7	17
10.18.18.18	192.168.0.175	19	7	17
172.16.43.131	192.168.0.175	8935	7	17
10.23.67.9	192.168.0.175	22387	7	17
10.18.18.18	192.168.0.175	19	7	17
192.168.57.2	192.168.0.175	6588	7	17
172.16.87.11	192.168.0.175	21453	7	17
10.18.18.18	192.168.0.175	19	7	17
10.34.67.89	192.168.0.175	45987	7	17
10.65.34.54	192.168.0.175	65212	7	17
192.168.25.6	192.168.0.175	52967	7	17
172.16.56.15	192.168.0.175	8745	7	17
10.18.18.18	192.168.0.175	19	7	17

他在路由器日誌上做了同樣的工作並列印出了看上去異常的記錄。在表5-1中是網站遭受攻擊期間，經過規整化處理後的路由器日誌資訊。

為了擷取更多資訊，小李接著查看了路由器中NetFlow綜合統計資訊，詳情如下：

 

為了有參考基準，他還列印了在Web伺服器開始出現問題的前幾周他儲存的快取資料（這些是正常狀態的資料）。正常路由日誌，如下所示：IP packet size distribution 這個標題下的兩行顯示了資料包按大小範圍分布的百分率。這裡顯示的內容表明：只有2%的資料包的大小在33～64位元組之間。

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

二、疑難問答

1.小李的Web伺服器到底發生了什嗎？可能的攻擊類型是什嗎？

2.如果地址未偽裝，那麼小李如何才能追蹤到攻擊者？

3.如果地址偽裝過，那麼他怎樣才能跟蹤到攻擊者？

三、事件推理

小李的Web伺服器遭受到什麼樣的攻擊呢？這一攻擊是通過對回顯連接埠（echo連接埠號碼為7），不斷髮送UDP資料包實現。攻擊看似發自兩個地方，可能是兩個攻擊者同時使用不同的工具。在任何情況下，超負荷的資料流都會拖垮Web伺服器。然而攻擊地址源不確定，不知道是攻擊源本身是分布的，還是同一個真真實位址偽裝出許多不同的虛假IP地址，這個問題比較難判斷。假如源IP地址不是偽裝的，則可以諮詢ARINI美國Internet號碼註冊處，從它的“Whois”資料庫查出這個入侵IP地址屬於哪個網路。接下來只需聯絡那個網路的管理員就可以得到進一步的資訊不過這對DOS攻擊不太可能。

假如源地址是偽裝的，追蹤這個攻擊者就麻煩得多。若使用的是Cisco路由器，則還需查詢NetFlow快取。但是為了追蹤這個偽裝的地址，必須查詢每個路由器上的NetFlow緩衝，才能確定流量進入了哪個介面，然後通過這些路由器介面，逐個往回追蹤，直至找到那個IP地址源。然而這樣做是非常難的，因為在Web Server和攻擊者的發起PC之間可能有許多路由器，而且屬於不同的組織。另外，必須在攻擊進行中時做這些分析。如果不是由司法部門介入很難查到源頭。

經過分析之後，將防火牆日誌和路由器日誌裡的資訊關聯起來，發現了一些有趣的相似性，如表5-1中粗黑體黑色標記處。攻擊的目標顯然是Web伺服器（192.168.0.175，連接埠為UDP 7。這看起來很像拒絕服務的攻擊(但還不能確定，因為攻擊的源IP地址分布隨機）。地址看起來是隨機的，只有一個源地址固定不變，其源連接埠號碼也沒變。這很有趣。他接著又將注意力集中到路由器日誌上。

他發現，攻擊發生時路由器日誌上有大量的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攻擊並沒有什麼靈丹妙藥。本質上，這是一種“粗管子打敗細管子”的攻擊。攻擊者能“指使”更多頻寬，有時甚至是巨大的頻寬，就能擊潰頻寬不夠的網路。在這種情況下，預防和緩解應相輔相成。

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

網路入口過濾網路服務供應商應在他的下遊網路上設定入口過濾，以防止假資訊包進入網路。這將防止攻擊者偽裝IP地址，從而易於追蹤。網路流量過濾軟體過濾掉網路不需要的流量總是不會錯的。這還能防止DOS攻擊，但為了達到效果，這些過濾器應盡量設定在網路上遊。

網路流量速率限制。一些路由器有流量速率的最高限制。這些限制條款將加強頻寬策略，並允許一個給定類型的網路流量匹配有限的頻寬。這一措施也能預先緩解進行中的攻擊。

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

單點傳送RPF（Reverse Path Forwarding），這是CEF（路由器的Cisco Express Forwarding功能簡稱）用於檢查在介面收到的資料包的另一特性。如果源IP地址CEF表上不具有與指向接收資料包時的介面一致的路由，路由器就會丟掉這個資料包。丟棄RPF的妙處在於，它阻止了所有偽裝源IP地址的攻擊。

1）檢測DOS攻擊

利用主機監測系統和IDS系統聯合分析，可以很快發現問題，例如通過EtherApe工具(一款監視串連的開源工具)，當然，利用Sniffer Pro以及科萊網路分析工具可以達到同樣效果。Sniffer能即時顯示網路連接情況，如果遇到DOS攻擊,從它內部密密麻麻的連線，以及IP地址就能初步判定攻擊類型，這時可以採用Ossim系統中的流量監視軟體例如Ntop，以及IDS系統來仔細判斷。後兩者將在《Unix/Linux部落格分析與流量監控》一書中詳細講解。最快捷的方式還是命令列，我們輸入以下命令：

# netstat -an|grep SYN_RECV|wc –l

通過結果可以發現網路中存在大量TCP同步資料包，而成功建立TCP串連的卻寥寥無幾，根據TCP三向交握原理分析可知，這肯定不是正常現象，網路肯定存在問題，需要進一步查實，如果數值很高，例如達到上千數值，那麼很有可能是受到了攻擊。1所示。

在圖1中OSSIM系統中的Snort檢測到DOS攻擊並以圖形方式顯示出大量警示資訊。例如，某網站在受到DOS攻擊時TCP串連如下：

我們統計“SYN_RECV”狀態的數量，命令如下：

#netstat –na |grep SYN_RECV |wc –l

1989

這麼大數值，在配合上面5-1圖形可以判斷網站受到DOS攻擊。

小技巧：還可以用下面的Shell命令，顯示哪個IP串連最多。

#netstat -nta |awk ‘{print $5}’ |cut –d:f1 |sort|uniq –c |sort –n

1 192.168.150.10

2 192.168.150.20

… …

1987 192.168.150.200

這條命令得到的資訊更詳細。數值達到1989，有近兩千條，這明顯說明受到了DOS攻擊。 這時我們利用Wireshark工具進行資料包解碼可以法相更多問題，當前通訊全都是採用TCP協議，查看TCP標誌發送所有的資料包均為SYN置1，即TCP同步請求資料包，而這些資料包往往指向同一個IP地址。至此可以驗證上面的判斷：這台主機遭受到DOS攻擊，而攻擊方式為SYN Flood攻擊。

五、疑難解答

1.小李的伺服器遭到了DOS攻擊，攻擊是通過對連接埠7不斷髮送小的UDP資料包實現的。這次攻擊看起來源自兩個地方，很可能是兩個攻擊者使用不同的工具。大量的資料流很快拖垮Web伺服器。痛點在於攻擊地址源不確定，攻擊源本身是分布的，還是同一個地址偽裝出的許多不同IP地址不好確定。

2.假設地址不是偽裝的，小李查詢ARIN，從它的Whois資料庫中查出這個入侵IP地址屬於哪個網路。

3.如果IP地址是偽裝的，這種追蹤比較麻煩，需要查詢每台路由器上的NetFlow資料，才能確定流量進出在哪些介面，然後對這些路由器一次一個介面的往回逐跳追蹤查詢，直到找到發起的IP地址源。但是這樣做涉及多個AS（自治系統），如果在國內尋找其攻擊源頭

的過程往往涉及很多電訊廠商，以及司法機關，工作量和時間都會延長，如果涉及跨國追查工作就更加複雜。最困難的是必須在攻擊期間才能做準確分析，一旦攻擊結束就只好去日誌系統裡查詢了。

看了上面的實際案例我們也瞭解到，許多DoS攻擊都很難應對，因為搞破壞的主機所發出的請求都是完全合法、符合標準的，只是數量太大。我們可以先在路由器上藉助恰當的ACL阻斷ICMP echo請求。

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會用3秒的時間處理網路介面插斷要求，之後用1秒執行其他任務。對於較早的系統，可能必須使用命令scheduler interval<milliseconds>。

另一種方法是利用Iptables預防DOS指令碼

#!/bin/bash

netstat -an|grep SYN_RECV|awk '{print$5}'|awk -F: '{print$1}'|sort|uniq -c|sort -rn|awk '{if ($1 >1) print $2}'

for i in $(cat /tmp/dropip)

do

/sbin/iptables -A INPUT -s $i -j DROP

echo “$i kill at `date`” >>/var/log/ddos

done

該指令碼會對處於SYN_RECV並且數量達到5個的IP做統計，並且把寫到Iptables的INPUT鏈設定為拒絕。

六、案例總結

無論是出於何種目的而發起更大規模攻擊或其他目的DOS/DDoS攻擊都必須重視。防範這種攻擊的辦法主要有及時打上來自廠商的補丁。同時，要關閉有漏洞的服務，或者用存取控制清單限制訪問。常規的DOS攻擊，特別是DDOS攻擊更難防範。如果整個頻寬都被Ping洪流耗盡，我們能做的就很有限了。針對DOS攻擊，首先要分析它的攻擊方式，是ICMP Flood 、UDP Flood和SYN Flood等流量攻擊，還是類似於TCP Flood、CC等方式，然後再尋找相對有效應對策略。對於這種攻擊可以採取下面介紹的幾種方法：

1）.利用“蜜網”防護,加強對攻擊工具和惡意樣本的第一時間分析和響應。大規模部署蜜網裝置以便追蹤殭屍網路的動態,捕獲惡意代碼。部署網站運行監控裝置,加強對網頁掛馬、訪問重新導向機制和網域名稱解析的監控,切斷惡意代碼的主要感染途徑。採用具備沙箱技術和各種脫殼技術的惡意代碼自動化分析裝置,加強對新型惡意代碼的研究,提高研究的時效性。

2).利用Ossim系統提供的Apache Dos防護策略可以起到監控的作用。

3）.利用雲端運算和虛擬化等新技術平台，提高對新型攻擊尤其是應用程式層攻擊和低速率攻擊的檢測和防護的效率。國外己經有學者開始利用Hadoop平台進行Http Get Flood的檢測演算法研究。

4）.利用IP信譽機制。在資訊安全防護的各個環節引入信譽機制,提高安全防護的效率和準確度。例如對應用軟體和檔案給予安全信譽評價，引導網路使用者的下載行為，通過發布權威IP信譽資訊，指導安全裝置自動產生防護策略，詳情見《Unix/linux部落格分析與流量監控》2.1節。

5）.採用被動策略即購買大的頻寬，也可以有效減緩DDOS攻擊的危害。

6）.構建分布式的系統，將自己的業務部署在多地機房，將各地區的訪問分散到對應的機房，考慮部署CDN，在重要IDC節點機房部署防火牆（例如Cisco、Juniper防火牆等）這樣即使有攻擊者進行DOS攻擊，破壞範圍可能也僅僅是其中的一個機房，不會對整個業務造成影響。

7）.如果規模不大，機房條件一般，那可以考慮在系統中使用一些防DDos的小工具，如DDoS Deflate，它的官網地址是http://deflate.medialayer.com ,它是一款免費的用來防禦和減輕DDOS攻擊的指令碼，通過系統內建的netstat命令，來監測跟蹤建立大量網路連接的IP地址，在檢測到某個結點超過預設的限制時，該程式會通過APF或IPTABLES禁止或阻擋這些IP。當然此工具也僅僅是減輕，並不能全部防止攻擊。

最後還要用不同供應商、不同AS路徑並支援負載平衡功能的不止一條到網際網路的串連，但這與應對消耗高頻寬的常規DOS/DDOS洪流的要求還有差距。我們總是可以用CAR（Committed Access Rate，承諾訪問速率）或NBAR(Network-Based Application Recognition，網路應用識別)來拋棄資料包或限制發動進攻的網路流速度，減輕路由器CPU的負擔，減少對緩衝區和路由器之後的主機的佔用。