概述：什么是DNS欺騙？
DNS欺騙是一門改變DNS原始指向IP的藝術。為了更好的理解，讓我們先來看一個例子。如果你想用瀏覽器去google搜索一些信息，毫無疑問的你會在地址欄里輸入
www.google.com
事實上，有兩種方法可以實現(xiàn)DNS劫持攻擊。讓我們來看看第一種，“DNS ID欺騙”技術。
A)DNS 高速緩沖存儲器麻痹（DNS Cache Poisoning）
可以想象，DNS服務器不可能將所有現(xiàn)存的域名或IP地址存儲在本身的存儲空間里。這就是為什么DNS服務器有一個高速緩沖存儲器（cache），它使得服務器可以存儲DNS記錄一一段時間。
事實上，一臺DNS服務器只會記錄本身所屬域中的授權的主機，如果它想要知道其它的，在自身域以外主機的信息，就必須向信息持有者（另一臺DNS服務器）發(fā)送請求，同時，為了不每次都發(fā)送請求，這臺DNS服務器會將另一臺DNS服務器返回的信息又記錄下來。
那么現(xiàn)在，我們就來看看是怎么麻痹DNS的緩存的。
攻擊者有自己的域（attacker.net）和一個已被攻陷的DNS服務器（ns.attacker.net）。注意！我說的是被攻陷的DNS服務器，因為攻擊者已經自定義了他自己的DNS服務器的記錄，比如，記錄可以是
www.google.com=81.81.81.81
1)攻擊者向你的DNS服務器發(fā)送請求查詢
www.attacker.net
2)你的DNS服務器不知道這臺主機的IP地址，因為他不屬于本身域，所有你的DNS服務器就會問此主機的所屬域的DNS服務器。
3)這時被黑DNS服務器就會回復你的DNS服務器，在此同時它也會給出它所有的記錄（包括連接
www.google.com
的記錄）
注意，這個過程叫做zone transfer.
按此在新窗口打開圖片
4)這是你的DNS服務器還沒有被麻痹。攻擊者得到了自己的IP地址，但是他的目標不是得到自己網絡服務器的地址，而是逼迫zone transfer進行以使你的DNS服務器麻痹直到其緩存不會被清楚或更新。
按此在新窗口打開圖片
5)現(xiàn)在如果你再問你的DNS服務器關于
www.google.com
的IP地址，它會告訴你172.50.50.50，這也正是攻擊者的服務器所在！現(xiàn)在，攻擊者就能為所欲為，例如掛馬什么的……當然這也對google造成了相當?shù)膿p失！
B)DNS ID欺騙（DNS ID Spoofing）
我們可以看到，當主機X要與主機Y聯(lián)系是需要近來的IP地址。然而在絕大多數(shù)情況下，X只有Y的名字，這樣，DNS協(xié)議就是來解決名字到IP地址的問題的。
因此，X就會向它所在域的DNS服務器詢問Y的IP地址。其間，主機X分配一個隨即數(shù)，這個數(shù)也將會出現(xiàn)在從DNS服務器返回的信息里。當X收到回復后，X會對比兩個數(shù)字，如果一致，則收到信息被視為有效。
那這樣一個模型是否安全呢？并非十分安全。任何人都可以組織一次攻擊來獲得這個ID。舉例說如果你用LAN，別人就可以利用嗅探器捕獲你的請求ID，然后根據(jù)這個ID偽造一個回復信息……但是信息里含有攻擊者所選的IP地址。然后，不加識別的，X會吧攻擊者提供的IP地址當作Y的。
順便提一句，DNS協(xié)議的提出請求是依賴于UDP的（只有在zone transfer時才用TCP），這也就意味著發(fā)送一個偽造的包是極其簡單的，因為沒有SYN/ACK號（不像TCP，UDP沒有提供一個小型防IP欺騙的防護）
按此在新窗口打開圖片
按此在新窗口打開圖片
但是，這樣的攻擊是被局限的。在我以上的例子中，攻擊者用嗅探器攔獲ID，回復構造過的包給受害主機。
換句話說，即使攻擊者攔截了請求，數(shù)據(jù)包還是會傳去DNS服務器，而DNS服務器也照樣會回復（除非攻擊者攔截并阻止對網關的請求或實施arp緩存麻痹才可能在轉換網絡中攻擊）。
這就意味著攻擊者必須在真DNS服務器前回復，即為了攻擊成功，攻擊者必須和被攻擊者同一個LAN，只有這樣他才可以獲得快速的ping并且捕獲對方的數(shù)據(jù)包。
實踐舉例（僅作測試目的）
看怎么劫持我們本地網絡連接：
1、麻痹被攻擊者的arp緩存（具體的工具和說明可以在
http://www.arp-sk.org
上找到）
2、此時，目標主機的出口數(shù)據(jù)包將會重定向到你的主機上，但是還必須轉發(fā)給真正的網關。我們可以用類似Winroute Pro的工具來實現(xiàn)。
3、為了實施DNS ID欺騙我們用valgasu開發(fā)的工具
WinDNSSpoof
（在使用這個工具前請先安裝Winpcap，見
http://winpcap.polito.it
）
命令行下輸入類似的命令：
wds -n
www.google.com
-i 123.123.123.123 -g 00-C0-26-DD-59-CF –v
這個命令會使目標主機的
www.google.com
Copy code
#define POSSIBILITIES 365.0
void main (void)
{
float chances;
int i, j;
for (i = 1; i
沒法編譯的朋友可以看下面的結果：
People
2
9
16
23
30
37
44
65
79
Chances
0.0027
0.0946
0.2836
0.5073
0.7063
0.8487
0.9329
0.9977
0.9999
沒法編譯的朋友可以看下面的結果：
生日悖論普遍的應用于檢測哈希函數(shù):N-位長度的哈希表可能發(fā)生碰撞測試次數(shù)不是2N次而是只有2N/2次。這一結論被應用到破解密碼學散列函數(shù)的生日攻擊中
生日問題所隱含的理論已經在[Schnabel 1938]名字叫做capture-recapture的統(tǒng)計試驗得到應用，來估計湖里魚的數(shù)量。
好，下面我們還是回到我的攻擊測試上來，在上述的最為普遍的DNS欺騙攻擊中，是在竊聽（嗅探）網絡以便得到來自X的ID號碼，然后回復以相同的ID只是含有攻擊者提供的IP。
就像我之前說的，這種攻擊需要嗅探網絡中的X生成的DNS數(shù)據(jù)。那這是不是意味著攻擊者不能不用嗅探器實施攻擊呢？
試著“猜猜”ID怎么樣？
為什么不呢，但是ID號是用兩字節(jié)構成的，這意味著有65535個可能的值！也就是說攻擊者如果想要成功攻擊的話，他要構造出65535個不同ID號的偽造回復，這樣里面至少有且僅有一個包是可用的。
如果這樣的攻擊的話，我們需要相當好的帶寬，而且最重要的是我們不知道何時發(fā)送偽造的回復。他就必須先知道對方有個請求，然后緊接著及時地（在真的來自DNS服務器的回復之前）發(fā)送回復。
讓我們來從另一個角度看問題，我們知道是有可能性去直接麻痹DNS服務器的?；貞浺幌拢粽呤窍隓NS服務器詢問解析
www.attacker.net
，多虧有從ns.attacker.net來的惡意記錄zone transfer，攻擊者才可以麻痹DNS服務器的高速緩存器。值得重提的是，這種攻擊的局限在于攻擊者必須在運行自己帶有惡意記錄的DNS服務器。
這樣的分析之下，如果攻擊者沒有辦法嗅探你的網絡數(shù)據(jù)或者沒有自己的服務器，是不是就是說你就遠離DNS劫持技術了？
答案是，完全不是這樣。
我之前提到過，DNS協(xié)議是用UDP回復，UDP是非連接狀態(tài)的協(xié)議，是沒有像TCP三次握手的過程的。所以，這也就使得可以非常容易地用你選的任意IP發(fā)送UDP包。所以為什么攻擊者在可以從任意DNS服務器發(fā)送偽造包的情況下要辛辛苦苦地架設起自己地DNS服務器呢？他可以直接詢問受害者的DNS服務器解析
www.google.com
，然后立即發(fā)送含偽造IP的包給
www.google.com
的域名服務器。
好，這樣時間剛好，這樣是可行的，所以問題就只有受害者的DNS服務器將要向ns.google.com發(fā)送一次請求來得到
www.google.com
的IP，同時有一個請求的ID號。所以又一次的，攻擊者就必須發(fā)送65535個含ns.google.com的偽造包來做為受害者域名服務器的源地址。至少有一個包是吻合的。所以看來這個可能會成功。
下面就是最有趣的部分了……如果攻擊者向受害者的DNS服務器發(fā)送了100份請求來解析
www.google.com
會發(fā)生什么呢？那么ns.victim.com也將會向ns.google.com發(fā)送100份請求，那然后如果我們發(fā)送100個從 ns.google.com到ns.victim.com的偽造回復會怎樣呢？如果你已經理解了剛剛提到的生日悖論原理，你就應該懂得相比之下沖撞（猜對）的概率已經有了可觀的提高。
按此在新窗口打開圖片
按此在新窗口打開圖片
除此之外，還有個必須注意的小細節(jié)——源端口！
試想，ns.victim.com將要向ns.google.com發(fā)送請求，UDP頭就應該像這樣：
Copy code
Source address : ns.victim.com
Destination address : ns.google.com
Source port : 1256 (choosed randomly and > 1024)
Destination port : 53 (DNS port)
Data : What is the IP of www.google.com?
很明顯，攻擊者必須ns.victim.com的源端口作為目標端口發(fā)送偽造的DNS回復，包的內容就像：
Copy code
Source address : ns.google.com
Destination address : ns.victim.com
Source port : 53
Destination port : 1256
Data : The IP of www.google.com is 81.81.81.81
所以如果我們沒有嗅探又要怎樣猜測源端口呢？“不幸”的是，對大多數(shù)DNS服務器來說，源端口是不會為每個客戶端而改變的，因此攻擊者可以很簡單地通過看 ns.victim.com的目前源端口來得到。比方說，如果他有一個域名服務器，他只要請求DNS查找他的域的一個站名，得到的返回查詢包就會包含現(xiàn)在在的被ns.victim.com用來發(fā)送DNS請求的源端口。
好，現(xiàn)在我知道如何得到源端口了，你可能會對攻擊的成功率好奇。這也是我正要講的。我們的C代碼也有所改動：
Copy code
#define POSSIBILITIES 65535.0
void main (void)
{
float chances;
int i, j;
for (i = 0; i
結果如下：
Queries
50
100
150
200
250
300
350
400
500
550
650
750
Chances
0.0185
0.0728
0.1569
0.2621
0.3785
0.4961
0.6069
0.7048
0.8517
0.9008
0.9604
0.9865
我們可以看到，650個構造回復有0.960411的概率成功，近乎100％！
欲知更多詳細信息，我建議閱讀以下文章：
http://www.kb.cert.org/vuls/id/457875
http://www.securityfocus.com/guest/17905
D)總結
在這篇文章里，我用
www.google.com
做例子，并不是因為我真的對其的重定向攻擊感興趣。這個問題在你訪問你的銀行賬戶，在線購書網站甚至是網頁電子郵件時尤為重要。
而對于網站管理者來說，可行的防范措施有：
對高速緩存器加以限制，保證不保留額外的記錄。
不要用或依賴DNS構架安全體系。
使用SSL之類的加密技術，所以即使被攻擊，難度也會加大。
