arpd故障一则

2011-07-24 16:17:23

上次说在xen下nmap使用raw socket的结果很难让人理解，后来发现是arpd的问题= = 具体情况是除非使nmap用connect()进行扫描，否则nmap一概认为honeyd模拟出来的机器不在线。可是ping等其他程序都是可以正常访问的。用tcpdump抓了下:

22:18:05.280070 arp who-has 10.60.60.119 (Broadcast) tell 10.60.60.223
22:18:05.280238 arp reply 10.60.60.119 is-at 00:23:ae:ab:87:8a (oui Unknown)
22:18:05.383803 arp who-has 10.60.60.119 (Broadcast) tell 10.60.60.223
22:18:05.383963 arp reply 10.60.60.119 is-at 00:23:ae:ab:87:8a (oui Unknown)

发现arpd的确是回复了自己的mac ，而且arp看了下 mac确实存在 也是正确的值。

但是为啥nmap就不继续任何操作了呢？

后来在国外一论坛的帮助下发现了原因：

原来arpd的回复是广播即目标地址是全1：一般程序只要能够取得mac就会继续，而nmap则必须检测到返回给自己的arp reply才认为对方在线。作为一个honeypot ，与其他系统实例有如此明显的差异确实也是十分不应该的（我用的是很早很早的早期版本），国外论坛给出的patch：

--- arpd.c.orig 2003-02-09 05:20:40.000000000 +0100
+++ arpd.c      2009-11-17 15:07:04.416660034 +0100
@@ -360,7 +360,7 @@
        ethip = (struct arp_ethip *)(arp + 1);

        addr_pack(&src.arp_ha, ADDR_TYPE_ETH, ETH_ADDR_BITS,
-           ETH_ADDR_BROADCAST, ETH_ADDR_LEN);
+           ethip->ar_sha, ETH_ADDR_LEN);
        addr_pack(&src.arp_pa, ADDR_TYPE_IP, IP_ADDR_BITS,
            ethip->ar_spa, IP_ADDR_LEN);

又及：今天测试了下farpd也有这种问题。

nmap这种测试方法在某种特定情况下会吃亏：试想某台机器，除了网关外其他ip的arp request均不响应（为了防止arp欺骗etc）这时黑客所取得权限的同网段机器正好需要与该机器通信，所以只能静态绑定了目标机器的mac，此时这个黑客应该是走运占了便宜的，但是如果不用sT进行扫描的话，nmap会认为该机器不在线，所以这个黑客很可能会因此而丢掉一块肥肉。

Mea.ningful .Me

[ points ]

[ leaves ]

[

redpill

]

[ about ]

arpd故障一则