3、拒絕服務攻擊的發展

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

　　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 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來跟蹤匿名攻擊

　　也許大家仍舊保存著僥幸心理，認為這些互連網上給我們帶來無數麻煩DoS漏洞或許隨著路由器包過濾，網絡協議升級到IPv6或者隨時的遠程響應等手段變得越來越不重要。但從一個具有責任感的網管的觀點來看，我們的目標并不是僅僅阻止拒絕服務攻擊，而是要追究到攻擊的發起原因及操作者。

　　當網絡中有人使用假冒了源地址的工具（如tfn2k）時，我們雖然沒有現成的工具來確認它的合法性，但我們可以通過使用DNS來對其進行分析：

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

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

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

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

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

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

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