这样的分析之下，如果攻击者没有办法嗅探你的网络数据或者没有自己的服务器，是不是就是说你就远离DNS劫持技术了？
答案是，完全不是这样。
我之前提到过，DNS协议是用UDP回复，UDP是非连接状态的协议，是没有像TCP三次握手的过程的。所以，这也就使得可以非常容易地用你选的任意IP发送UDP包。所以为什么攻击者在可以从任意DNS服务器发送伪造包的情况下要辛辛苦苦地架设起自己地DNS服务器呢？他可以直接询问受害者的DNS服务器解析www.google.com，然后立即发送含伪造IP的包给www.google.com的域名服务器。

好，这样时间刚好，这样是可行的，所以问题就只有受害者的DNS服务器将要向ns.google.com发送一次请求来得到www.google.com的IP，同时有一个请求的ID号。所以又一次的，攻击者就必须发送65535个含ns.google.com的伪造包来做为受害者域名服务器的源地址。至少有一个包是吻合的。所以看来这个可能会成功。
下面就是最有趣的部分了……如果攻击者向受害者的DNS服务器发送了100份请求来解析www.google.com会发生什么呢？那么ns.victim.com也将会向ns.google.com发送100份请求，那然后如果我们发送100个从ns.google.com到ns.victim.com的伪造回复会怎样呢？如果你已经理解了刚刚提到的生日悖论原理，你就应该懂得相比之下冲撞（猜对）的概率已经有了可观的提高。

除此之外，还有个必须注意的小细节——源端口！
试想，ns.victim.com将要向ns.google.com发送请求，UDP头就应该像这样：
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的源端口作为目标端口发送伪造的DNS回复，包的内容就像：

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
所以如果我们没有嗅探又要怎样猜测源端口呢？“不幸”的是，对大多数DNS服务器来说，源端口是不会为每个客户端而改变的，因此攻击者可以很简单地通过看 ns.victim.com的目前源端口来得到。比方说，如果他有一个域名服务器，他只要请求DNS查找他的域的一个站名，得到的返回查询包就会包含现在在的被ns.victim.com用来发送DNS请求的源端口。

好，现在我知道如何得到源端口了，你可能会对攻击的成功率好奇。这也是我正要讲的。我们的C代码也有所改动：

#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之类的加密技术，所以即使被攻击，难度也会加大

上一页  [1] [2] [3]