發信人: glees (我心底的中國), 信區: Network 
標  題: ◆ 拒絕服務攻擊原理及解決方法(轉載) 
發信站: 哈工大紫丁香 (2001年10月01日10:19:28 星期一), 轉信 
  
【 以下文字轉載自 Hacker 討論區 】 
【 原文由 glees 所發表 】 
◆ 拒絕服務攻擊原理及解決方法 
  
出處：NCOD全球華人信息安全及黑客技術交流同盟 
  
日期：2000-9-19    翻譯：廣州寒路 8/28/2000 
  
  
Internet給全世界的人們帶來了無限的生機，真正實現了無國界的全球村。但是還有很 
多困繞我們的因素，象IP地址的短缺，大量帶寬的損耗，以及政府規章的限制和編程技 
術的不足。現在，由于多年來網絡系統累積下了無數的漏洞，我們將面臨著更大的威脅 
，網絡中潛伏的好事者將會以此作為缺口來對系統進行攻擊，我們也不得不為以前的疏 
忽付出更大的努力。雖然大多的網絡系統產品都標榜著安全的旗號，但就我們現在的網 
絡協議和殘缺的技術來看，危險無處不在。 
拒絕服務攻擊是一種遍布全球的系統漏洞，黑客們正醉心于對它的研究，而無數的網絡 
用戶將成為這種攻擊的受害者。Tribe Flood Network, tfn2k, smurf, targa…還有許 
多的程序都在被不斷的開發出來。這些程序想瘟疫一樣在網絡中散布開來，使得我們的 
村落更為薄弱，我們不得不找出一套簡單易用的安全解決方案來應付黑暗中的攻擊。 
在這篇文章中我們將會提供： 
· 對當今網絡中的拒絕服務攻擊的討論。 
· 安全環境中的一些非技術性因素以及我們必須克服的一些障礙問題。 
· 如何認清產品推銷商所提供的一些謊言。 
在我們正式步入對這些問題的技術性討論之前，讓我們先從現實的生活中的實際角度來 
看一下這些困繞我們的問題。 
當前的技術概況 
在我們進入更為詳細的解決方案之前，讓我們首先對問題做一下更深入的了解。 
與安全相關的這些小問題如果詳細來講的話都能成為一個大的章節，但限于篇幅的原因 
，我們只能先作一下大體的了解。 
· 軟件弱點是包含在操作系統或應用程序中與安全相關的系統缺陷，這些缺陷大多是由 
于錯誤的程序編制，粗心的源代碼審核，無心的副效應或一些不適當的綁定所造成的。 
根據錯誤信息所帶來的對系統無限制或者未經許可的訪問程度，這些漏洞可以被分為不 
同的等級。 
· 典型的拒絕服務攻擊有如下兩種形式：資源耗盡和資源過載。當一個對資源的合理請 
求大大超過資源的支付能力時就會造成拒絕服務攻擊（例如，對已經滿載的Web服務器進 
行過多的請求。）拒絕服務攻擊還有可能是由于軟件的弱點或者對程序的錯誤配置造成 
的。區分惡意的拒絕服務攻擊和非惡意的服務超載依賴于請求發起者對資源的請求是否 
過份，從而使得其他的用戶無法享用該服務資源。 
· 錯誤配置也會成為系統的安全隱患。這些錯誤配置通常發生在硬件裝置，系統或者應 
用程序中。如果對網絡中的路由器，防火墻，交換機以及其他網絡連接設備都進行正確 
的配置會減小這些錯誤發生的可能性。如果發現了這種漏洞應當請教專業的技術人員來 
修理這些問題。 
如果換個角度，也可以說是如下原因造成的： 
· 錯誤配置。錯誤配置大多是由于一些沒經驗的，無責任員工或者錯誤的理論所導致的 
。開發商一般會通過對您進行簡單的詢問來提取一些主要的配置信息，然后在由經過專 
業培訓并相當內行的專業人士來解決問題。 
· 軟件弱點。由于使用的軟件幾乎完全依賴于開發商，所以對于由軟件引起的漏洞只能 
依靠打補丁，安裝hot fixes和Service packs來彌補。當某個應用程序被發現有漏洞存 
在，開發商會立即發布一個更新的版本來修正這個漏洞。 
· 拒絕服務攻擊。拒絕服務攻擊大多是由于錯誤配置或者軟件弱點導致的。某些DoS攻 
擊是由于開發協議固有的缺陷導致的，某些DoS攻擊可以通過簡單的補丁來解決，還有一 
些導致攻擊的系統缺陷很難被彌補。最后，還有一些非惡意的拒絕服務攻擊的情況，這 
些情況一般是由于帶寬或者資源過載產生瓶頸導致的，對于這種問題沒有一個固定的解 
決方案。 
深入DoS 
DoS的攻擊方式有很多種。最基本的DoS攻擊就是利用合理的服務請求來占用過多的服務 
資源，致使服務超載，無法響應其他的請求。這些服務資源包括網絡帶寬，文件系統空 
間容量，開放的進程或者向內的連接。這種攻擊會導致資源的匱乏，無論計算機的處理 
速度多么快，內存容量多么大，互連網的速度多么快都無法避免這種攻擊帶來的后果。 
因為任何事都有一個極限，所以，總能找到一個方法使請求的值大于該極限值，因此就 
會使所提供的服務資源匱乏，象是無法滿足需求。千萬不要自認為自己擁有了足夠寬的 
帶寬就會有一個高效率的網站，拒絕服務攻擊會使所有的資源變得非常渺小。 
傳統上，攻擊者所面臨的主要問題是網絡帶寬，由較小的網絡規模和較慢的網絡速度， 
無法使攻擊者發出過多的請求，然而，類似"the ping of death"的攻擊類型緊需要很少 
量的包就可以摧毀一個沒有打過補丁的UNIX系統。當然，多數的DoS攻擊還是需要相當大 
的帶寬的，但是高帶寬是大公司所擁有的，而以個人為主的黑客很難享用。為了克服這 
個缺點，惡意的攻擊者開發了分布式的攻擊。這樣，攻擊者就可以利用工具集合許多的 
網絡帶寬來對同一個目標發送大量的請求。 
以下的兩種情況最容易導致拒絕服務攻擊： 
· 由于程序員對程序錯誤的編制，導致系統不停的建立進程，最終耗盡資源，只能重新 
啟動機器。不同的系統平臺都會采取某些方法可以防止一些特殊的用戶來占用過多的系 
統資源，我們也建議盡量采用資源管理的方式來減輕這種安全威脅。 
· 還有一種情況是由磁盤存儲空間引起的。假如一個用戶有權利存儲大量的文件的話， 
他就有可能只為系統留下很小的空間用來存儲日志文件等系統信息。這是一種不良的操 
作習慣，會給系統帶來隱患。這種情況下應該對系統配額作出考慮。 
從安全的角度來看，本地的拒絕服務攻擊可以比較容易的追蹤并消除。而我們這篇文章 
主要是針對于網絡環境下的DoS攻擊。下面我們大體討論一下較為常見的基于網絡的拒絕 
服務攻擊： 
· Smurf (directed broadcast)。廣播信息可以通過一定的手段（通過廣播地址或其他 
機制）發送到整個網絡中的機器。當某臺機器使用廣播地址發送一個ICMP echo請求包時 
（例如PING），一些系統會回應一個ICMP echo回應包，也就是說，發送一個包會收到許 
多的響應包。Smurf攻擊就是使用這個原理來進行的，當然，它還需要一個假冒的源地址 
。也就是說在網絡中發送源地址為要攻擊主機的地址，目的地址為廣播地址的包，會使 
許多的系統響應發送大量的信息給被攻擊主機（因為他的地址被攻擊者假冒了）。使用 
網絡發送一個包而引出大量回應的方式也被叫做"放大器"，這些smurf放大器可以在www 
.netscan.org網站上獲得，一些無能的且不負責任的網站仍有很多的這種漏洞。 
· SYN flooding 一臺機器在網絡中通訊時首先需要建立TCP握手，標準的TCP握手需要 
三次包交換來建立。一臺服務器一旦接收到客戶機的SYN包后必須回應一個SYN/ACK包， 
然后等待該客戶機回應給它一個ACK包來確認，才真正建立連接。然而，如果只發送初始 
化的SYN包，而不發送確認服務器的ACK包會導致服務器一直等待ACK包。由于服務器在有 
限的時間內只能響應有限數量的連接，這就會導致服務器一直等待回應而無法響應其他 
機器進行的連接請求。 
· Slashdot effect 這種攻擊手法使web服務器或其他類型的服務器由于大量的網絡傳 
輸而過載，一般這些網絡流量是針對某一個頁面或一個鏈接而產生的。當然這種現象也 
會在訪問量較大的網站上正常發生，但我們一定要把這些正常現象和拒絕服務攻擊區分 
開來。如果您的服務器突然變得擁擠不堪，甚至無法響應再多的請求時，您應當仔細檢 
查一下這個資源匱乏的現象，確認在10000次點擊里全都是合法用戶進行的，還是由500 
0個合法用戶和一個點擊了5000次的攻擊者進行的。 
拒絕服務一般都是由過載導致的，而過載一般是因為請求到達了極限。 
拒絕服務攻擊的發展 
由于我們防范手段的加強，拒絕服務攻擊手法也在不斷的發展。 
Tribe Flood Network (tfn) 和tfn2k引入了一個新概念：分布式。這些程序可以使得分 
散在互連網各處的機器共同完成對一臺主機攻擊的操作，從而使主機看起來好象是遭到 
了不同位置的許多主機的攻擊。這些分散的機器由幾臺主控制機操作進行多種類型的攻 
擊，如UDP flood, SYN flood等。 
操作系統和網絡設備的缺陷在不斷地被發現并被黑客所利用來進行惡意的攻擊。如果我 
們清楚的認識到了這一點，我們應當使用下面的兩步來盡量阻止網絡攻擊保護我們的網 
絡： 
A）盡可能的修正已經發現的問題和系統漏洞。 
B）識別，跟蹤或禁止這些令人討厭的機器或網絡對我們的訪問。 
我們先來討論一下B），在B）中我們面臨的主要問題是如何識別那些惡意攻擊的主機， 
特別是使用拒絕服務攻擊的機器。因為這些機器隱藏了他們自己的地址，而冒用被攻擊 
者的地址。攻擊者使用了數以千記的惡意偽造包來使我們的主機受到攻擊。"tfn2k"的原 
理就象上面講的這么簡單，而他只不過又提供了一個形象的界面。假如您遭到了分布式 
的拒絕服務攻擊，實在是很難處理。 
解決此類問題的一些專業手段----包過濾及其他的路由設置 
有一些簡單的手法來防止拒絕服務式的攻擊。最為常用的一種當然是時刻關注安全信息 
以期待最好的方法出現。管理員應當訂閱安全信息報告，實時的關注所有安全問題的發 
展。：） 
第二步是應用包過濾的技術，主要是過濾對外開放的端口。這些手段主要是防止假冒地 
址的攻擊，使得外部機器無法假冒內部機器的地址來對內部機器發動攻擊。 
我們可以使用Cisco IOS來檢查路由器的詳細設置，當然，它也不僅限于Cisco的設備， 
但由于現在Cisco設備在網絡中占有了越來越多的市場份額（83%），所以我們還是以它 
為例子，假如還有人有其他的例子，我們也非常高興你能提出您的寶貴信息。 
登陸到將要配置的路由器上，在配置訪問控制列表之前先初始化一遍： 
c3600(config)#access-list 100 permit ip 207.22.212.0 0.0.0.255 any 
c3600(config)#access-list 100 deny ip any any 
然后我們假設在路由器的S0口上進行ACL的設置，我們進入S0口，并進入配置狀態： 
c3600(config)#int ser 0 
c3600(config-if)#ip access-group 100 out 
通過顯示access-list來確認訪問權限已經生效： 
c3600#sho access-lists 100 
Extended IP access list 100 
permit ip 207.22.212.0 0.0.0.255 any (5 matches) 
deny ip any any (25202 matches) 
對于應該使用向內的包過濾還是使用向外的包過濾一直存在著爭論。RFC 2267建議在全 
球范圍的互連網上使用向內過濾的機制，但是這樣會帶來很多的麻煩，在中等級別的路 
由器上使用訪問控制列表不會帶來太大的麻煩，但是已經滿載的骨干路由器上會受到明 
顯的威脅。 
另一方面，ISP如果使用向外的包過濾措施會把過載的流量轉移到一些不太忙的設備上。 
 ISP也不關心消費者是否在他們的邊界路由器上使用這種技術。當然，這種過濾技術也 
并不是萬無一失的，這依賴于管理人員采用的過濾機制。 
我們經常會聽到設備銷售或集成商這樣的推脫之詞，他們總是說使用ACL會導致路由器和 
網絡性能的下降。ACL確實會降低路由器的性能并加重CPU的負載，但這是微乎其微的。 
我們曾經在Cisco 2600 和3600系列路由器上作過實驗： 
以下是不使用和使用ACL時的對照表： 
Test Speed w/o ACL (Mbps) w/ ACL (Mbps) w/o ACL (total time) w/ ACL (total t 
ime) % change 
Cisco 2600 100Mbps -》 100 Mbps File transfers 36.17 Mbps 35.46 Mbps 88.5 90 
.2 2.50% 
Cisco 3600 10Mbps -》 10Mbps File transfers 7.95 Mbps 8.0Mbps 397 395 0.30% 
使用的路由器配置如下： 
· Cisco 3640 (64MB RAM, R4700 processor, IOS v12.0.5T) 
· Cisco 2600 (128MB RAM, MPC860 processor, IOS v12.0.5T) 
由表我們可以看出，在使用ACL前后對路由器性能的影響并不是很大。 
使用DNS來跟蹤匿名攻擊 
也許大家仍舊保存著僥幸心理，認為這些互連網上給我們帶來無數麻煩DoS漏洞或許隨著 
路由器包過濾，網絡協議升級到IPv6或者隨時的遠程響應等手段變得越來越不重要。但 
從一個具有責任感的網管的觀點來看，我們的目標并不是僅僅阻止拒絕服務攻擊，而是 
要追究到攻擊的發起原因及操作者。 
當網絡中有人使用假冒了源地址的工具（如tfn2k）時，我們雖然沒有現成的工具來確認 
它的合法性，但我們可以通過使用DNS來對其進行分析： 
假如攻擊者選定了目標www.technotronic.com，他必須首先發送一個DNS請求來解析這個 
域名，通常那些攻擊工具工具會自己執行這一步，調用gethostbyname()函數或者相應的 
應用程序接口，也就是說，在攻擊事件發生前的DNS請求會提供給我們一個相關列表，我 
們可以利用它來定位攻擊者。 
使用現成工具或者手工讀取DNS請求日志，來讀取DNS可疑的請求列表都是切實可行的， 
然而，它有三個主要的缺點： 
l 攻擊者一般會以本地的DNS為出發點來對地址進行解析查詢，因此我們查到的DNS請求 
的發起者有可能不是攻擊者本身，而是他所請求的本地DNS服務器。盡管這樣，如果攻擊 
者隱藏在一個擁有本地DNS的組織內，我們就可以把該組織作為查詢的起點。 
l 攻擊者有可能已經知道攻擊目標的IP地址，或者通過其他手段（host, ping）知道了 
目標的IP地址，亦或是攻擊者在查詢到IP地址后很長一段時間才開始攻擊，這樣我們就 
無法從DNS請求的時間段上來判斷攻擊者（或他們的本地服務器）。 
l DNS對不同的域名都有一個卻省的存活時間，因此攻擊者可以使用存儲在DNS緩存中的 
信息來解析域名。為了更好做出詳細的解析記錄，您可以把DNS卻省的TTL時間縮小，但 
這樣會導致DNS更多的去查詢所以會加重網絡帶寬的使用。 
在許多情況下，只要您擁有足夠的磁盤空間，記錄所有的DNS請求并不是一種有害的做法 
。在BIND8.2中做記錄的話，可以在named.conf中假如下面的幾行： 
logging { 
channel requestlog { file "dns.log"; }; 
category queries { requestlog; }; 
}; 
使用 ngrep來處理tfn2k 攻擊 
根據使用DNS來跟蹤tfn2k駐留程序的原理，現在已經出現了稱為ngrep的實用工具。經過 
修改的ngrep（參見附錄）可以監聽大約五種類型的tfn2k拒絕服務攻擊(targa3, SYN f 
lood, UDP flood, ICMP flood 和 smurf)，它還有一個循環使用的緩存用來記錄DNS和 
ICMP請求。如果ngrep發覺有攻擊行為的話，它會將其緩存中的內容打印出來并繼續記錄 
ICMP回應請求。假如攻擊者通過ping目標主機的手段來鉚定攻擊目標的話，在攻擊過程 
中或之后記錄ICMP的回應請求是一種捕獲粗心的攻擊者的方法。由于攻擊者還很可能使 
用其他的服務來核實其攻擊的效果（例如web），所以對其他的標準服務也應當有盡量詳 
細的日志記錄。 
還應當注意，ngrep采用的是監聽網絡的手段，因此，ngrep無法在交換式的環境中使用 
。但是經過修改的ngrep可以不必和你的DNS在同一個網段中，但是他必須位于一個可以 
監聽到所有DNS請求的位置。經過修改的ngrep也不關心目標地址，您可以把它放置在DM 
Z網段，使它能夠檢查橫貫該網絡的tfn2k攻擊。從理論上講，它也可以很好的檢測出對 
外的tfn2k攻擊。 
運行 ngrep, 您將看到： 
[root@lughnasad ngrep]# ./ngrep 
Ngrep with TFN detection modifications by wiretrip / www.wiretrip.net 
Watching DNS server: 10.0.0.8 
interface: eth0 (10.0.0.0/255.255.0.0) 
從這里開始ngrep將監聽tfn2k攻擊，如果檢測到攻擊, ngrep將在屏幕上打印： 
Sun Jan 9 17:30:01 2000 
A TFN2K UDP attack has been detected! 
Last (5000) DNS requests: 
《list of IPs that made DNS requests, up to DNS_REQUEST_MAX length》 
Last (1000) ICMP echo requests (pings): 
《list of IPs that made ICMP echo requests, up to ICMP_REQUEST_MAX length》 
Incoming realtime ICMP echo requests (pings): 
《all ICMP echo requests since the attack was detected》 
以上的列表并不是唯一的，可以對它進行調整讓他不僅顯示是誰請求，而且請求多少次 
，頻率為多少等等。在ICMP flood事件中，ICMP回應請求的報告中將不包括做為tfn2k 
flood一部分的ICMP包。Ngrep還可以報告檢測出來的除smurf之外的攻擊類型（TARGA, 
UDP, SYN, ICMP等）。混合式的攻擊在缺省情況下表現為ICMP攻擊，除非你屏蔽了向內 
的ICMP回應請求，這樣它就表現為UDP或SYN攻擊。這些攻擊的結果都是基本類似的。 
附錄- Ngrep.c with tfn2k detection 
以下的代碼在使用前應當更改一些參數。 
#define DNS_REQUEST_MAX 5000 
#define ICMP_REQUEST_MAX 1000 
通知ngrep最大的請求跟蹤數（在檢測攻擊之前）。傳輸較為繁忙的網站應當增加這一數 
值（網絡流量較為繁忙的網站DNS的請求數最好在10，000，而ICMP請求為2000-3000） 
#define FLOOD_THRESHOLD 20 
用在10秒中內有多少同一類型的攻擊包來確認為真正的攻擊。數目設計的越大，程序報 
受攻擊的可能性就越小。假如您老是收到錯誤的警報，那么您應當增加一下這個數值。