DHCP协议的详细信息在RFC 2131中描述的很清楚，在此不赘述！
这里主要讲一下前些日子发现的一些有意思的现象，RFC 2131中规定，DHCPREQUEST报文的重传机制采用的是通常提到的backoff策略，但是奇怪的是DHCPDICOVER报文的重传机制似乎并没有提到，这似乎就直接导致以下一些现象：
我查询了一些资料，主要是来自Google的，MicroSoft的一些产品重传DHCPDISCOVER报文之间的delay为1s 9s 11s 13s，如果这四次均没有DHCPOFFER返回，那么过5 min以后再根据用户的选择采取相应的措施，当然这是MicroSoft产品的做法；其他有的产品，重传DHCPDISCOVER报文之间的delay是uniform的，我见到的是1 min左右……
因为RFC 2131没有规定DHCPDISCOVER的重传机制，OK，那作为实现该协议栈的程序员可以自己来决策，因为很多协议中均采用一些backoff算法，那如果是我去做这件事，那我就会选择backoff的重传机制。但是，我也可以不选择这样做，这完全取决于我。
这样一来，就比较有意思了，同是DHCP Service，但行为却有些出入。这在平时当然不会有什么问题，但如果现在有个版本的Server上run的某个Service报出某某漏洞，然后某个hacker想remote attack这个版本的Server,那hacker首先得知道我要attack的机器上安装的是不是这个版本的Server，再假设说这个版本的Server和其他版本的Server，在DHCP的实现上有很大的不同，OK，那hacker可以根据这个Server DHCP的响应方式来推测要attack的机器上装的是否就是预期中的Server。
上面讲的attack可行吗？当然可行。因为之前已经有前辈统计过Windows,Linux不同版本之间协议栈实现的不同，以此来推测Remote access的Server是什么版本的Server。这个trick还有个专门的名词叫“fingerprinting”，非常形象！这种技术在hacker入侵的前奏中通常会用到！
可以看到，一个很detail的东西，不会为大多数人注意，导致了Information leakage！
所以说，“不可随处小便”，不好意思，说错了，应该是“小处不可随便”！
阅读(817) | 评论(0) | 转发(0) |
