拒絕服務(wù)攻擊原理及解決方法

1、拒絕服務(wù)攻擊原理及解決方法Internet給全世界的人們帶來了無限的生機，真正實現(xiàn)了無國界的全球村。但是還有很多困繞我們的因素，象IP地址的短缺，大量帶寬的損耗，以及政府規(guī)章的限制和編程技術(shù)的不足。現(xiàn)在，由于多年來網(wǎng)絡(luò)系統(tǒng)累積下了無數(shù)的漏洞，我們將面臨著更大的威脅，網(wǎng)絡(luò)中潛伏的好事者將會以此作為缺口來對系統(tǒng)進(jìn)行攻擊，我們也不得不為以前的疏忽付出更大的努力。雖然大多的網(wǎng)絡(luò)系統(tǒng)產(chǎn)品都標(biāo)榜著安全的旗號，但就我們現(xiàn)在的網(wǎng)絡(luò)協(xié)議和殘缺的技術(shù)來看，危險無處不在。拒絕服務(wù)攻擊是一種遍布全球的系統(tǒng)漏洞，黑客們正醉心于對它的研究，而無數(shù)的網(wǎng)絡(luò)用戶將成為這種攻擊的受害者。TribeFloodNetwork,tfn

2、2k,smurf,targa還有許多的程序都在被不斷的開發(fā)出來。這些程序想瘟疫一樣在網(wǎng)絡(luò)中散布開來，使得我們的村落更為薄弱，我們不得不找出一套簡單易用的安全解決方案來應(yīng)付黑暗中的攻擊。在這篇文章中我們將會提供： 對當(dāng)今網(wǎng)絡(luò)中的拒絕服務(wù)攻擊的討論。 安全環(huán)境中的一些非技術(shù)性因素以及我們必須克服的一些障礙問題。 如何認(rèn)清產(chǎn)品推銷商所提供的一些謊言。在我們正式步入對這些問題的技術(shù)性討論之前，讓我們先從現(xiàn)實的生活中的實際角度來看一下這些困繞我們的問題。當(dāng)前的技術(shù)概況在我們進(jìn)入更為詳細(xì)的解決方案之前，讓我們首先對問題做一下更深入的了解。與安全相關(guān)的這些小問題如果詳細(xì)來講的話都能成為一個大的章節(jié)，但限于篇

3、幅的原因，我們只能先作一下大體的了解。 軟件弱點是包含在操作系統(tǒng)或應(yīng)用程序中與安全相關(guān)的系統(tǒng)缺陷，這些缺陷大多是由于錯誤的程序編制，粗心的源代碼審核，無心的副效應(yīng)或一些不適當(dāng)?shù)慕壎ㄋ斐傻?。根?jù)錯誤信息所帶來的對系統(tǒng)無限制或者未經(jīng)許可的訪問程度，這些漏洞可以被分為不同的等級。 典型的拒絕服務(wù)攻擊有如下兩種形式：資源耗盡和資源過載。當(dāng)一個對資源的合理請求大大超過資源的支付能力時就會造成拒絕服務(wù)攻擊（例如，對已經(jīng)滿載的Web服務(wù)器進(jìn)行過多的請求。）拒絕服務(wù)攻擊還有可能是由于軟件的弱點或者對程序的錯誤配置造成的。區(qū)分惡意的拒絕服務(wù)攻擊和非惡意的服務(wù)超載依賴于請求發(fā)起者對資源的請求是否過份，從而使得其

4、他的用戶無法享用該服務(wù)資源。 錯誤配置也會成為系統(tǒng)的安全隱患。這些錯誤配置通常發(fā)生在硬件裝置，系統(tǒng)或者應(yīng)用程序中。如果對網(wǎng)絡(luò)中的路由器，防火墻，交換機以及其他網(wǎng)絡(luò)連接設(shè)備都進(jìn)行正確的配置會減小這些錯誤發(fā)生的可能性。如果發(fā)現(xiàn)了這種漏洞應(yīng)當(dāng)請教專業(yè)的技術(shù)人員來修理這些問題。如果換個角度，也可以說是如下原因造成的： 錯誤配置。錯誤配置大多是由于一些沒經(jīng)驗的，無責(zé)任員工或者錯誤的理論所導(dǎo)致的。開發(fā)商一般會通過對您進(jìn)行簡單的詢問來提取一些主要的配置信息，然后在由經(jīng)過專業(yè)培訓(xùn)并相當(dāng)內(nèi)行的專業(yè)人士來解決問題。 軟件弱點。由于使用的軟件幾乎完全依賴于開發(fā)商，所以對于由軟件引起的漏洞只能依靠打補丁，安裝hotf

5、ixes和Servicepacks來彌補。當(dāng)某個應(yīng)用程序被發(fā)現(xiàn)有漏洞存在，開發(fā)商會立即發(fā)布一個更新的版本來修正這個漏洞。 拒絕服務(wù)攻擊。拒絕服務(wù)攻擊大多是由于錯誤配置或者軟件弱點導(dǎo)致的。某些DoS攻擊是由于開發(fā)協(xié)議固有的缺陷導(dǎo)致的，某些DoS攻擊可以通過簡單的補丁來解決，還有一些導(dǎo)致攻擊的系統(tǒng)缺陷很難被彌補。最后，還有一些非惡意的拒絕服務(wù)攻擊的情況，這些情況一般是由于帶寬或者資源過載產(chǎn)生瓶頸導(dǎo)致的，對于這種問題沒有一個固定的解決方案。深入DoSDoS的攻擊方式有很多種。最基本的DoS攻擊就是利用合理的服務(wù)請求來占用過多的服務(wù)資源，致使服務(wù)超載，無法響應(yīng)其他的請求。這些服務(wù)資源包括網(wǎng)絡(luò)帶寬，文件

6、系統(tǒng)空間容量，開放的進(jìn)程或者向內(nèi)的連接。這種攻擊會導(dǎo)致資源的匱乏，無論計算機的處理速度多么快，內(nèi)存容量多么大，互連網(wǎng)的速度多么快都無法避免這種攻擊帶來的后果。因為任何事都有一個極限，所以，總能找到一個方法使請求的值大于該極限值，因此就會使所提供的服務(wù)資源匱乏，象是無法滿足需求。千萬不要自認(rèn)為自己擁有了足夠?qū)挼膸捑蜁幸粋€高效率的網(wǎng)站，拒絕服務(wù)攻擊會使所有的資源變得非常渺小。傳統(tǒng)上，攻擊者所面臨的主要問題是網(wǎng)絡(luò)帶寬，由較小的網(wǎng)絡(luò)規(guī)模和較慢的網(wǎng)絡(luò)速度，無法使攻擊者發(fā)出過多的請求，然而，類似"thepingofdeath"的攻擊類型緊需要很少量的包就可以摧毀一個沒有打過補丁的U

7、NIX系統(tǒng)。當(dāng)然，多數(shù)的DoS攻擊還是需要相當(dāng)大的帶寬的，但是高帶寬是大公司所擁有的，而以個人為主的黑客很難享用。為了克服這個缺點，惡意的攻擊者開發(fā)了分布式的攻擊。這樣，攻擊者就可以利用工具集合許多的網(wǎng)絡(luò)帶寬來對同一個目標(biāo)發(fā)送大量的請求。以下的兩種情況最容易導(dǎo)致拒絕服務(wù)攻擊： 由于程序員對程序錯誤的編制，導(dǎo)致系統(tǒng)不停的建立進(jìn)程，最終耗盡資源，只能重新啟動機器。不同的系統(tǒng)平臺都會采取某些方法可以防止一些特殊的用戶來占用過多的系統(tǒng)資源，我們也建議盡量采用資源管理的方式來減輕這種安全威脅。 還有一種情況是由磁盤存儲空間引起的。假如一個用戶有權(quán)利存儲大量的文件的話，他就有可能只為系統(tǒng)留下很小的空間用來

8、存儲日志文件等系統(tǒng)信息。這是一種不良的操作習(xí)慣，會給系統(tǒng)帶來隱患。這種情況下應(yīng)該對系統(tǒng)配額作出考慮。從安全的角度來看，本地的拒絕服務(wù)攻擊可以比較容易的追蹤并消除。而我們這篇文章主要是針對于網(wǎng)絡(luò)環(huán)境下的DoS攻擊。下面我們大體討論一下較為常見的基于網(wǎng)絡(luò)的拒絕服務(wù)攻擊： Smurf（directedbroadcast）o廣播信息可以通過一定的手段（通過廣播地址或其他機制）發(fā)送到整個網(wǎng)絡(luò)中的機器。當(dāng)某臺機器使用廣播地址發(fā)送一個ICMPecho請求包時（例如PING）,一些系統(tǒng)會回應(yīng)一個ICMPecho回應(yīng)包，也就是說，發(fā)送一個包會收到許多的響應(yīng)包。Smurf攻擊就是使用這個原理來進(jìn)行的，當(dāng)然，它還需

9、要一個假冒的源地址。也就是說在網(wǎng)絡(luò)中發(fā)送源地址為要攻擊主機的地址，目的地址為廣播地址的包，會使許多的系統(tǒng)響應(yīng)發(fā)送大量的信息給被攻擊主機（因為他的地址被攻擊者假冒了）。使用網(wǎng)絡(luò)發(fā)送一個包而引出大量回應(yīng)的方式也被叫做"放大器"，這些smurf放大器可以在網(wǎng)站上獲得，一些無能的且不負(fù)責(zé)任的網(wǎng)站仍有很多的這種漏洞。 SYNflooding一臺機器在網(wǎng)絡(luò)中通訊時首先需要建立TCP握手，標(biāo)準(zhǔn)的TCP握手需要三次包交換來建立。一臺服務(wù)器一旦接收到客戶機的SYN包后必須回應(yīng)一個SYN/ACK包，然后等待該客戶機回應(yīng)給它一個ACK包來確認(rèn)，才真正建立連接。然而，如果只發(fā)送初始

10、化的SYN包，而不發(fā)送確認(rèn)服務(wù)器的ACK包會導(dǎo)致服務(wù)器一直等待ACK包。由于服務(wù)器在有限的時間內(nèi)只能響應(yīng)有限數(shù)量的連接，這就會導(dǎo)致服務(wù)器一直等待回應(yīng)而無法響應(yīng)其他機器進(jìn)行的連接請求。 Slashdoteffect這種攻擊手法使web服務(wù)器或其他類型的服務(wù)器由于大量的網(wǎng)絡(luò)傳輸而過載，一般這些網(wǎng)絡(luò)流量是針對某一個頁面或一個鏈接而產(chǎn)生的。當(dāng)然這種現(xiàn)象也會在訪問量較大的網(wǎng)站上正常發(fā)生，但我們一定要把這些正?，F(xiàn)象和拒絕服務(wù)攻擊區(qū)分開來。如果您的服務(wù)器突然變得擁擠不堪，甚至無法響應(yīng)再多的請求時，您應(yīng)當(dāng)仔細(xì)檢查一下這個資源匱乏的現(xiàn)象，確認(rèn)在10000次點擊里全都是合法用戶進(jìn)行的，還是由5000個合法用戶和一

11、個點擊了5000次的攻擊者進(jìn)行的。拒絕服務(wù)一般都是由過載導(dǎo)致的，而過載一般是因為請求到達(dá)了極限。拒絕服務(wù)攻擊的發(fā)展由于我們防范手段的加強，拒絕服務(wù)攻擊手法也在不斷的發(fā)展。TribeFloodNetwork(tfn)和tfn2k引入了一個新概念：分布式。這些程序可以使得分散在互連網(wǎng)各處的機器共同完成對一臺主機攻擊的操作，從而使主機看起來好象是遭到了不同位置的許多主機的攻擊。這些分散的機器由幾臺主控制機操作進(jìn)行多種類型的攻擊，如UDPflood,SYNflood等。操作系統(tǒng)和網(wǎng)絡(luò)設(shè)備的缺陷在不斷地被發(fā)現(xiàn)并被黑客所利用來進(jìn)行惡意的攻擊。如果我們清楚的認(rèn)識到了這一點，我們應(yīng)當(dāng)使用下面的兩步來盡量阻止網(wǎng)

12、絡(luò)攻擊保護我們的網(wǎng)絡(luò)：A)盡可能的修正已經(jīng)發(fā)現(xiàn)的問題和系統(tǒng)漏洞。B)識別，跟蹤或禁止這些令人討厭的機器或網(wǎng)絡(luò)對我們的訪問。我們先來討論一下B),在B)中我們面臨的主要問題是如何識別那些惡意攻擊的主機，特別是使用拒絕服務(wù)攻擊的機器。因為這些機器隱藏了他們自己的地址，而冒用被攻擊者的地址。攻擊者使用了數(shù)以千記的惡意偽造包來使我們的主機受到攻擊。"tfn2k"的原理就象上面講的這么簡單，而他只不過又提供了一個形象的界面。假如您遭到了分布式的拒絕服務(wù)攻擊，實在是很難處理。解決此類問題的一些專業(yè)手段-包過濾及其他的路由設(shè)置有一些簡單的手法來防止拒絕服務(wù)式的攻擊。最為常用的一種當(dāng)然是時

13、刻關(guān)注安全信息以期待最好的方法出現(xiàn)。管理員應(yīng)當(dāng)訂閱安全信息報告，實時的關(guān)注所有安全問題的發(fā)展。：)第二步是應(yīng)用包過濾的技術(shù)，主要是過濾對外開放的端口。這些手段主要是防止假冒地址的攻擊，使得外部機器無法假冒內(nèi)部機器的地址來對內(nèi)部機器發(fā)動攻擊。我們可以使用CiscoIOS來檢查路由器的詳細(xì)設(shè)置，當(dāng)然，它也不僅限于Cisco的設(shè)備，但由于現(xiàn)在Cisco設(shè)備在網(wǎng)絡(luò)中占有了越來越多的市場份額(83%),所以我們還是以它為例子，假如還有人有其他的例子，我們也非常高興你能提出您的寶貴信息。登陸到將要配置的路由器上，在配置訪問控制列表之前先初始化一遍：c3600(config)#access-list100p

14、ermitip55anyc3600(config)#access-list100denyipanyany然后我們假設(shè)在路由器的S0上進(jìn)行ACL的設(shè)置，我們進(jìn)入S0口，并進(jìn)入配置狀態(tài)：c3600(config)#intser0c3600(config-if)#ipaccess-group100out通過顯示access-list來確認(rèn)訪問權(quán)限已經(jīng)生效：c3600#shoaccess-lists100ExtendedIPaccesslist100permitip55any(5matches)denyipanyany(252

15、02matches)對于應(yīng)該使用向內(nèi)的包過濾還是使用向外的包過濾一直存在著爭論。RFC2267建議在全球范圍的互連網(wǎng)上使用向內(nèi)過濾的機制，但是這樣會帶來很多的麻煩，在中等級別的路由器上使用訪問控制列表不會帶來太大的麻煩，但是已經(jīng)滿載的骨干路由器上會受到明顯的威脅。另一方面，ISP如果使用向外的包過濾措施會把過載的流量轉(zhuǎn)移到一些不太忙的設(shè)備上。ISP也不關(guān)心消費者是否在他們的邊界路由器上使用這種技術(shù)。當(dāng)然，這種過濾技術(shù)也并不是萬無一失的，這依賴于管理人員采用的過濾機制。我們經(jīng)常會聽到設(shè)備銷售或集成商這樣的推脫之詞，他們總是說使用ACL會導(dǎo)致路由器和網(wǎng)絡(luò)性能的下降。ACL確實會降低路由器的性能并加

16、重CPU的負(fù)載，但這是微乎其微的。我們曾經(jīng)在Cisco2600和3600系列路由器上作過實驗：以下是不使用和使用ACL時的對照表：TestSpeedw/oACL(Mbps)w/ACL(Mbps)w/oACL(totaltime)w/ACL(totaltime)%changeCisco2600100Mbps-»100MbpsFiletransfers36.17Mbps35.46Mbps88.590.22.50%Cisco360010Mbps-»10MbpsFiletransfers7.95Mbps8.0Mbps3973950.30%使用的路由器配置如下： Cisco3640(

17、64MBRAM,R4700processor,IOSv12.0.5T) Cisco2600(128MBRAM,MPC860processor,IOSv12.0.5T)由表我們可以看出，在使用ACL前后對路由器性能的影響并不是很大。使用DNS來跟蹤匿名攻擊也許大家仍舊保存著僥幸心理，認(rèn)為這些互連網(wǎng)上給我們帶來無數(shù)麻煩DoS漏洞或許隨著路由器包過濾，網(wǎng)絡(luò)協(xié)議升級到IPv6或者隨時的遠(yuǎn)程響應(yīng)等手段變得越來越不重要。但從一個具有責(zé)任感的網(wǎng)管的觀點來看，我們的目標(biāo)并不是僅僅阻止拒絕服務(wù)攻擊，而是要追究到攻擊的發(fā)起原因及操作者。當(dāng)網(wǎng)絡(luò)中有人使用假冒了源地址的工具(如tfn2k)時，我們雖然沒有現(xiàn)成的工具來

18、確認(rèn)它的合法性，但我們可以通過使用DNS來對其進(jìn)行分析：假如攻擊者選定了目標(biāo),他必須首先發(fā)送一個DNS請求來解析這個域名，通常那些攻擊工具工具會自己執(zhí)行這一步，調(diào)用gethostbyname()函數(shù)或者相應(yīng)的應(yīng)用程序接口，也就是說，在攻擊事件發(fā)生前的DNS請求會提供給我們一個相關(guān)列表，我們可以利用它來定位攻擊者。使用現(xiàn)成工具或者手工讀取DNS請求日志，來讀取DNS可疑的請求列表都是切實可行的，然而，它有三個主要的缺點：l攻擊者一般會以本地的DNS為出發(fā)點來對地址進(jìn)行解析查詢，因此我們查到的DNS請求的發(fā)起者有可能不是攻擊者本身，而是他所請求的本地DNS服務(wù)器。盡管這樣，如果攻擊者隱藏在一個擁有

19、本地DNS的組織內(nèi)，我們就可以把該組織作為查詢的起點。l攻擊者有可能已經(jīng)知道攻擊目標(biāo)的IP地址，或者通過其他手段(host,ping)知道了目標(biāo)的IP地址，亦或是攻擊者在查詢到IP地址后很長一段時間才開始攻擊，這樣我們就無法從DNS請求的時間段上來判斷攻擊者(或他們的本地服務(wù)器)。lDNS對不同的域名都有一個卻省的存活時間，因此攻擊者可以使用存儲在DNS緩存中的信息來解析域名。為了更好做出詳細(xì)的解析記錄，您可以把DNS卻省的TTL時間縮小，但這樣會導(dǎo)致DNS更多的去查詢所以會加重網(wǎng)絡(luò)帶寬的使用。在許多情況下，只要您擁有足夠的磁盤空間，記錄所有的DNS請求并不是一種有害的做法。在BIND8.2中

20、做記錄的話，可以在named.conf中假如下面的幾行：loggingchannelrequestlogfile"dns.log"categoryqueriesrequestlog;使用ngrep來處理tfn2k攻擊根據(jù)使用DNS來跟蹤tfn2k駐留程序的原理，現(xiàn)在已經(jīng)出現(xiàn)了稱為ngrep的實用工具。經(jīng)過修改的ngrep(參見附錄)可以監(jiān)聽大約五種類型的tfn2k拒絕服務(wù)攻擊(targa3,SYNflood,UDPflood,ICMPflood和smurf),它還有一個循環(huán)使用的緩存用來記錄DNS和ICMP請求。如果ngrep發(fā)覺有攻擊行為的話，它會將其緩存中的內(nèi)容打印出來

21、并繼續(xù)記錄ICMP回應(yīng)請求。假如攻擊者通過ping目標(biāo)主機的手段來挪定攻擊目標(biāo)的話，在攻擊過程中或之后記錄ICMP的回應(yīng)請求是一種捕獲粗心的攻擊者的方法。由于攻擊者還很可能使用其他的服務(wù)來核實其攻擊的效果(例如web),所以對其他的標(biāo)準(zhǔn)服務(wù)也應(yīng)當(dāng)有盡量詳細(xì)的日志記錄。還應(yīng)當(dāng)注意，ngrep采用的是監(jiān)聽網(wǎng)絡(luò)的手段，因此，ngrep無法在交換式的環(huán)境中使用。但是經(jīng)過修改的ngrep可以不必和你的DNS在同一個網(wǎng)段中，但是他必須位于一個可以監(jiān)聽到所有DNS請求的位置。經(jīng)過修改的ngrep也不關(guān)心目標(biāo)地址，您可以把它放置在DMZ網(wǎng)段，使它能夠檢查橫貫該網(wǎng)絡(luò)的tfn2k攻擊。從理論上講，它也可以很好的檢

22、測出對外的tfn2k攻擊。運行ngrep,您將看到：rootlughnasadngrep#./ngrepNgrepwithTFNdetectionmodificationsbywiretrip/WatchingDNSserver:interface:eth0(/)從這里開始ngrep將監(jiān)聽tfn2k攻擊，如果檢測到攻擊，ngrep將在屏幕上打?。篠unJan917:30:012000ATFN2KUDPattackhasbeendetected!Last(5000)DNSrequests:«listofIPsthatmadeDNSr

23、equests,uptoDNS_REQUEST_MAXlength»Last(1000)ICMPechorequests(pings):«listofIPsthatmadeICMPechorequests,uptoICMP_REQUEST_MAXlength»IncomingrealtimeICMPechorequests(pings):«allICMPechorequestssincetheattackwasdetected»以上的列表并不是唯一的，可以對它進(jìn)行調(diào)整讓他不僅顯示是誰請求，而且請求多少次，頻率為多少等等。在ICMPflood事件

24、中，ICMP回應(yīng)請求的報告中將不包括做為tfn2kflood一部分的ICMP包。Ngrep還可以報告檢測出來的除smurf之外的攻擊類型(TARGA,UDP,SYN,ICMP等)?；旌鲜降墓粼谌笔∏闆r下表現(xiàn)為ICMP攻擊，除非你屏蔽了向內(nèi)的ICMP回應(yīng)請求，這樣它就表現(xiàn)為UDP或SYN攻擊。這些攻擊的結(jié)果都是基本類似的。附錄-Ngrep.cwithtfn2kdetection以下的代碼在使用前應(yīng)當(dāng)更改一些參數(shù)。#defineDNS_REQUEST_MAX5000#defineICMP_REQUEST_MAX1000通知ngrep最大的請求跟蹤數(shù)(在檢測攻擊之前)。傳輸較為繁忙的網(wǎng)站應(yīng)當(dāng)增加這

25、一數(shù)值(網(wǎng)絡(luò)流量較為繁忙的網(wǎng)站DNS的請求數(shù)最好在10,000,而ICMP請求為2000-3000)#defineFLOOD_THRESHOLD20用在10秒中內(nèi)有多少同一類型的攻擊包來確認(rèn)為真正的攻擊。數(shù)目設(shè)計的越大，程序報受攻擊的可能性就越小。假如您老是收到錯誤的警報，那么您應(yīng)當(dāng)增加一下這個數(shù)值。#defineDNS_SERVER_IP""Ngrep通過監(jiān)視DNS服務(wù)器的53端口的UDP包來跟蹤向內(nèi)的DNS請求(只有UDP)。因此，ngrep需要知道您的DNS服務(wù)器的IP地址。我們的設(shè)備可能會有多個DNS服務(wù)器，但我們認(rèn)為對一臺DNS服務(wù)器的支持足以證明

26、這項技術(shù)的能力。#defineTTL_THRESHOLD150tfn2kSYNflood攻擊使用的TTL值通常在200-255的范圍內(nèi)。估計到攻擊者與目標(biāo)主機之間不止50跳，因此我們可以只查找TTL時間高于150的包。假如您相信攻擊者在50跳左右，那么您可以對TTL的限制進(jìn)行一下更改。編譯更改過的ngrep編譯和安裝都非常簡單。您僅需要使用以下之一來取代ngrep.c文件。處于方便起見，我們可以詳細(xì)說明。這段代碼只是在RedHat6.1和Mandrake6.5Linux上測試過。首先您需要在然后在ftp:/ftp.ee.lbl.goV/libpcap.tar.Z下載libpcap我們使用的是0

27、.40版。把文件放在臨時文件夾里并解包，tarxvzflibpcap.tar.Z然后進(jìn)行編譯cdlibpcap-0.4;./configure;make;makeinstall;makeinstall-incl假如您遇到了困難，可以參見在libpcap-0.4目錄里的README或INSTALL文件。根據(jù)我們實驗的經(jīng)驗，如果/usr/local/include和/usr/local/include/net目錄在linux系統(tǒng)中不存在的話，安裝會失敗。加入您在安裝時遇到了pcap.h或bpf.h的錯誤時你可以運行mkdir/usr/local/include;mkdir/usr/local/include/net然后重新運行'makeinstall-i