NEWS動態我們的動態!
Our dynamic!

網站遭遇DOS攻擊

點擊數:1020發布時間: 2014-10-23 15:44:55
一、事件背景

    長假對于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)端口進行洪泛式攻擊,因此小李他們的下一步任務就是阻止這一攻擊行為。首先,小李在路由器上堵截攻擊??焖俚貫槁酚善髟O置了一個過濾規則。因為源地址的來源隨機,他們認為很難用限制某個地址或某一塊范圍的地址來阻止攻擊,因此決定禁止所有發給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三次握手原理分析可知,這肯定不是正?,F象,網絡肯定存在問題,需要進一步查實,如果數值很高,例如達到上千數值,那么很有可能是受到了攻擊。如圖1所示。



圖 1 Ossim發現DOS攻擊

在圖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防護策略可以起到監控的作用。

wKiom1RBKOeTcnlLAAMyJ_kCQ90126.jpg

 

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的負擔,減少對緩沖區和路由器之后的主機的占用。

黑粗硬大欧美在线视频,男女牲交过程视频播放免费,男女性高爱潮免费视频