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網站上獲得，一些無能...芏嗟惱庵致 礎?/a>
﹒ SYN flooding 一台機器在網絡中通訊時首先需要建立TCP握手，標準的TCP握手需要三次包交換來建立。一台服務器一旦接收到客戶機的SYN包後必須回應一個SYN/ACK包，然後等待該客戶機回應給它一個ACK包來確認，才真正建立連接。然而，如果只發送初始化的SYN包，而不發送確認服務器的ACK包會導致服務器一直等待ACK包。由於服務器在有限的時間內只能響應有限數量的連接，這就會導致服務器一直等待回應而無法響應其他機器進行的連接請求。
﹒ Slashdot effect 這種攻擊手法使web服務器或其他類型的服務器由於大量的網絡傳輸而過載，一般這些網絡流量是針對某一個頁面或一個鏈接而產生的。當然這種現象也會在訪問量較大的網站上正常發生，但我們一定要把這些正常現象和拒絕服務攻擊區分開來。如果您的服務器突然變得擁擠不堪，甚至無法響應再多的請求時，您應當仔細檢查一下這個資源匱乏的現象，確認在10000次點擊裡全都是合法用戶進行的，還是由5000個合法用戶和一個點擊了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)
對於應該使用向內的包過濾還是使用向外的包過濾一貝嬖謐耪虌蛂ΟFC 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 time) % 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，他必須首先發?..用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 flood, UDP flood, ICMP flood 和 smurf)，它還有一個循環使用的緩存用來記錄DNS和ICMP請求。如果ngrep發覺有攻擊行為的話，它會將其緩存中的內容打印出來並繼續記錄ICMP回應請求。假如攻擊者通過ping目標主機的手段來鉚定攻擊目標的話，在攻擊過程中或之後記錄ICMP的回應請求是一種捕獲粗心的攻擊者的方法。由於攻擊者還很可能使用其他的服務來核實其攻擊的效果（例如web），所以對其他的標準服務也應當有盡量詳細的日志記錄。
還應當注意，ngrep採用的是監聽網絡的手段，因此，ngrep無法在交換式的環境中使用。但是經過修改的ngrep可以不必和你的DNS在同一個網段中，但是他必須位於一個可以監聽到所有DNS請求的位置。經過修改的ngrep也不關心目標地址，您可以把它放置在DMZ網段，使它能夠檢查橫貫該網絡的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秒中內有多少同一類型的攻擊包來確認為真正的攻擊。數目設計的越大，程序報受攻擊的可能性就越小。假如您老是收到錯誤的警報，那麼您應當增加一下這個數值。
#define DNS_SERVER_IP "10.0.0.8"
Ngrep通過監視DNS服務器的53端口的UDP包來跟蹤向內的DNS請求（只有UDP）。因此，ngrep需要知道您的DNS服務器的IP地址。
我們的設備可能會有多個DNS服務器，但我們認為對一台DNS服務器的支持足以証明這項技術的能力。
#define TTL_THRESHOLD 150
tfn2k SYN flood 攻擊使用的 TTL值通常在200-255的范圍內。估計到攻擊者與目標主機之間不止50跳，因此我們可以只查找TTL時間高於150的包。假如您相信攻擊者在50跳左右，那麼您可以對TTL的限制進行一下更改。
編譯更改過的 ngrep
編譯和安裝都非常簡單。您僅需要使用以下之一來取代ngrep.c 文件。處於方便起見，我們可以詳細說明。
這段代碼只是在RedHat 6.1 和Mandrake 6.5 Linux上測試過。
首先您需要在
http://www.packetfactory.net/ngrep/ 下載ngrep，我們測試的是1.35版。
然後在
ftp://ftp.ee.lbl.gov/libpcap.tar.Z下載libpcap 我們使用的是 0.40版。
把文件放在臨時文件夾裡並解包，
tar xvzf libpcap.tar.Z
然後進行編譯
cd libpcap-0.4; ./configure; make; make install; make install-incl
假如您遇到了困難，可以參見在libpcap-0.4目錄裡的README或INSTALL文件。根據我們實驗的經驗，如果/usr/local/include 和/usr/local/include/net目錄在linux系統中不存在的話，安裝會失敗。加入您在安裝時遇到了pcap.h 或 bpf.h的錯誤時你可以運行
mkdir /usr/local/include; mkdir /usr/local/include/net然後重新運行'make install-incl'。然後我們需要編譯ngrep (使用我們修改過的版本)。首先解包
tar xvzf ngrep-1.35.tar.gz
然後進行配置
cd ngrep; ./configure
然後把ngrep.c復制到ngrep目錄裡。你可以覆蓋也可以備份原始的ngrep.c文件。在這裡，您應當回顧在修改過的ngrep.c裡的配置，至少您應當把DNS_SERVER_IP更改為您所使用的DNS的地址。更改完畢後你就可以運行'make'，這樣就建立了ngrep應用程序。
Modified ngrep.c source code
/* this code is available for download from
http://www.wiretrip.net/na/ngrep.c */
/*
* $Id: ngrep.c,v 1.35 1999/10/13 16:44:16 jpr5 Exp $
*
*/
/* TFN detection code added by Rain Forest Puppy /
rfp@wiretrip.net
and Night Axis /
na@wiretrip.net */
/********* TFN detection defines *******************************/
/* how many DNS and ICMP requests to track */
#define DNS_REQUEST_MAX 5000
#define ICMP_REQUEST_MAX 1000
/* flood threshold is matches per 10 seconds */
#define FLOOD_THRESHOLD 20
/* IP of your DNS server */
#define DNS_SERVER_IP "10.9.100.8"
/* TFN syn uses ttl between 200-255. Assuming less than 50 hops,
flag stuff with ttl > TTL_THRESHOLD (other critera are used
as well) */
#define TTL_THRESHOLD 150
/**************************************************************/
#include
#include
#include
#ifdef LINUX
#include
#endif
#if defined(BSD)