3、拒絕服務(wù)攻擊的發(fā)展

　　由于我們防范手段的加強，拒絕服務(wù)攻擊手法也在不斷的發(fā)展。

　　Tribe Flood Network (tfn) 和tfn2k引入了一個新概念：分布式。這些程序可以使得分散在互連網(wǎng)各處的機器共同完成對一臺主機攻擊的操作，從而使主機看起來好象是遭到了不同位置的許多主機的攻擊。這些分散的機器由幾臺主控制機操作進(jìn)行多種類型的攻擊，如UDP flood, SYN flood等。

　　操作系統(tǒng)和網(wǎng)絡(luò)設(shè)備的缺陷在不斷地被發(fā)現(xiàn)并被黑客所利用來進(jìn)行惡意的攻擊。如果我們清楚的認(rèn)識到了這一點，我們應(yīng)當(dāng)使用下面的兩步來盡量阻止網(wǎng)絡(luò)攻擊保護(hù)我們的網(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)然是時刻關(guān)注安全信息以期待最好的方法出現(xiàn)。管理員應(yīng)當(dāng)訂閱安全信息報告，實時的關(guān)注所有安全問題的發(fā)展。：）

　　第二步是應(yīng)用包過濾的技術(shù)，主要是過濾對外開放的端口。這些手段主要是防止假冒地址的攻擊，使得外部機器無法假冒內(nèi)部機器的地址來對內(nèi)部機器發(fā)動攻擊。

　　我們可以使用Cisco IOS來檢查路由器的詳細(xì)設(shè)置，當(dāng)然，它也不僅限于Cisco的設(shè)備，但由于現(xiàn)在Cisco設(shè)備在網(wǎng)絡(luò)中占有了越來越多的市場份額（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
然后我們假設(shè)在路由器的S0口上進(jìn)行ACL的設(shè)置，我們進(jìn)入S0口，并進(jìn)入配置狀態(tài)：
c3600(config)#int ser 0
c3600(config-if)#ip access-group 100 out
通過顯示access-list來確認(rèn)訪問權(quán)限已經(jīng)生效：
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)

　　對于應(yīng)該使用向內(nèi)的包過濾還是使用向外的包過濾一直存在著爭論。RFC 2267建議在全球范圍的互連網(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確實會降低路由器的性能并加重CPU的負(fù)載，但這是微乎其微的。我們曾經(jīng)在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%

　　使用的路由器配置如下：

　　2 Cisco 3640 (64MB RAM, R4700 processor, IOS v12.0.5T)
　　2 Cisco 2600 (128MB RAM, MPC860 processor, IOS v12.0.5T)

　　由表我們可以看出，在使用ACL前后對路由器性能的影響并不是很大。

　　4、使用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)成的工具來確認(rèn)它的合法性，但我們可以通過使用DNS來對其進(jìn)行分析：

　　假如攻擊者選定了目標(biāo)www.technotronic.com，他必須首先發(fā)送一個DNS請求來解析這個域名，通常那些攻擊工具工具會自己執(zhí)行這一步，調(diào)用gethostbyname()函數(shù)或者相應(yīng)的應(yīng)用程序接口，也就是說，在攻擊事件發(fā)生前的DNS請求會提供給我們一個相關(guān)列表，我們可以利用它來定位攻擊者。

　　使用現(xiàn)成工具或者手工讀取DNS請求日志，來讀取DNS可疑的請求列表都是切實可行的，然而，它有三個主要的缺點：

　　1) 攻擊者一般會以本地的DNS為出發(fā)點來對地址進(jìn)行解析查詢，因此我們查到的DNS請求的發(fā)起者有可能不是攻擊者本身，而是他所請求的本地DNS服務(wù)器。盡管這樣，如果攻擊者隱藏在一個擁有本地DNS的組織內(nèi)，我們就可以把該組織作為查詢的起點。

　　2) 攻擊者有可能已經(jīng)知道攻擊目標(biāo)的IP地址，或者通過其他手段（host, ping）知道了目標(biāo)的IP地址，亦或是攻擊者在查詢到IP地址后很長一段時間才開始攻擊，這樣我們就無法從DNS請求的時間段上來判斷攻擊者（或他們的本地服務(wù)器）。

　　3) DNS對不同的域名都有一個卻省的存活時間，因此攻擊者可以使用存儲在DNS緩存中的信息來解析域名。為了更好做出詳細(xì)的解析記錄，您可以把DNS卻省的TTL時間縮小，但這樣會導(dǎo)致DNS更多的去查詢所以會加重網(wǎng)絡(luò)帶寬的使用。

　　在許多情況下，只要您擁有足夠的磁盤空間，記錄所有的DNS請求并不是一種有害的做法。在BIND8.2中做記錄的話，可以在named.conf中假如下面的幾行：

logging {
channel requestlog { file "dns.log"； }；
category queries { requestlog； }；
}；