看到efnet出的假phrack62上谈到了honeynpot的识别,想起以前也搜集过类似的资料。
整理了一下，就是这个tips。由于我接触的honeypot类型不是很多，这篇文章里边大部分
都是关于Virtual Honeypot的，有遗漏或者错误的地方请朋友们指正。

看到efnet出的假phrack62上谈到了honeynpot的识别,想起以前也搜集过类似的资料。
整理了一下，就是这个tips。由于我接触的honeypot类型不是很多，这篇文章里边大部分
都是关于Virtual Honeypot的，有遗漏或者错误的地方请朋友们指正。

-- [ 1.可以接触honeypot的级别

area52[1]中曾经提到过一些权限等级划分。没有必要搞那么复杂，这里按照容易程度
排列，就是简单的三种:
a.可以接触honeypot本地资源(一般意味着成功获得权限)
b.与honeypot在同一物理子网内
c.只能通过网络访问honeypot提供的服务
下边提到的技巧标题中会注明适用类别(a,b,c表示)。

-- [ 2.检查MAC地址 (a,b或者windows下的c)

VMWare公司注册的MAC地址范围在[3]中可以找到。
00-05-69-xx-xx-xx
00-0C-29-xx-xx-xx
00-50-56-xx-xx-xx

a时用ifconfig
b下用ping ipaddr;arp -a查看
windows下的c使用nbtstat -A查看(现在好多ISP都把SMB相关的几个端口都关掉了)

VMWare也可以指定MAC,所以上边的方法只适用于默认安装的VMWARE。UML没有注册OUI,
MAC是随便指定的的。所以不能检查UML。至于非Virtual Honeynet情况下，本来就是真实
的网卡。这个也不适用。

-- [ 3. HostOS与GuestOS的保留通讯手段 (a)

honeypot邮件列表上[2]提到过一些探测VMWare的方法。效果最明显的就是[5]中提到
的VMWare Backdoor I/O Port。100%命中，这个可不是改VMWare配置文件可以去掉的。

另外运行在VMWare(windows下)的Linux的IDT入口地址不正确，Linux下的kernel
space是0xc0000000以上的，这个是在试验[6]中的程序时后发现的。后来看到alert7[7]
已经发现了这个问题。不知道思路源头是否相同？

UML中没有采用这种设置I/O端口通讯的方式，而是使用驱动做到这一点。网卡使用
TUN/TAP,文件系统使用ubd。TUN/TAP一般内核都支持，查了一下UML的实现，ubd是UML
独特使用的(难道叫UML Block Device?)。如果系统中有/dev/ubd/的目录,或者
/dev/ubd0类似的块设备文件。那么肯定就是UML了。

-- [ 4. 硬件设备检查 (a)

[2]中提到可以用检查BIOS的方式来检查VMWare，这个我没有试过，而且VMWare的
BIOS升级还比较快，单纯的靠版本号之类的信息很难检查出来。

什么样的硬件信息能检查出来了。呵呵，正好PCI设备上的Vendor信息是全球唯一的。
sourceforge上的pciids项目[8]整理了这个列表。Vendor字段为0x15ad和0xfffe的是
VMWare Inc.注册了。Linux下边可以很方便的用lspci命令列出所有的PCI设备。遗憾的是
UML下边没有把PCI信息导出到/proc/bus/pci，所以lspci也不能用。可能和UML对PCI设备
进行了特殊的处理了的原因。

VMWARE下的网卡都是PCNET32,如果是模块,lsmod可以看到，不是的话lspci可以看到，
也可以作为一个参考。

-- [ 5. honeyd的MAC地址 (b)

honeyd[9]做honeypot比较强悍，但是有一个缺点就是虚拟出来的OS的MAC地址全部
都是一样的。这个和arpd工作模式有一定关系。装honeyd的时候因为这个原因，还不能
在局域网内测试。因为MAC一样，运行honeyd的主机也会接受处理这个报文，搞得乱七
八糟的。

-- [ 6.应用层程序识别 (a,b,c)

一般的honeypot上边跑得OS包括应用程序都是真实的，所以这种方法并不适用。但是
有一个例外就是honeyd,honeyd只是模拟某一个OS的TCP/IP协议栈以及之上的应用程序。
以80端口上的IIS为例，根据[10]中的方法使用OPTIONS * HTTP/1.1对honeyd测试是不支
持的。所以一旦扫描到IIS的一些漏洞，千万要确定一下是不是真的是honeyd上的IIS模拟
器(说起来还是偶像之一,web hacking先驱RFP的人写的)。:),思路大致是这样，其他这种
问题还有很多。其实就像nmap识别OS的原理一样，大家的实现不一样。找到不一样的地方
作为特征值就可以了。

这里闲扯一个问题，和识别无关的。honeyd的DoS,honeyd里边有个pop3.sh,这个脚本
写的有些问题，在默认安装的情况会引起DoS。telnet连到相应的端口，随便敲两个回车。
然后Ctrl+]断开连接，pop3.sh的写日志部分由于没有判断连接是否，一个死循环，不停的
往硬盘上写东西直到塞满硬盘。

-- [ 7.Bridge模式与Route模式 (c)

相比之下，Route模式靠经验来得比较合适。比如像下边这样一个traceroute的结果:
traceroute to xx.xx.64.228 (xx.xx.64.228), 64 hops max, 40 byte packets
1 gate (xx.xx.76.254) 1 ms 0 ms 0 ms
2 xx.xx.96.138 (xx.xx.96.138) 1 ms 1 ms 1 ms
3 xx.xx.64.226 (xx.xx.64.226) 2 ms 1 ms 1 ms
4 xx.xx.64.228 (xx.xx.64.228) 1 ms 1 ms 1 ms

一般来说按照子网划分的原则，最后一跳的网关一般都是像254,129之类的形式(当然
，也有很多例外)。像上边这种情况的路由就有点奇怪，一般部署honeynet都是连续的IP。
如果发现目标机器的IP与上一跳的IP比较临近，那么就可能有点问题了。

Bridge模式下不好弄，一个鬼子说,bridge模式下的服务器会响应局域网内的arp。搞了
半天我也没有明白这句话对我有什么帮助。

-- [ 8.突破Data Control

看来这个大家都能想到，呵呵。这里就不多说了，看efnet的phrack62吧。

-- [ 感谢

dudu,jameszhang提供搞honeynet的设备;happywu在我没有UML的情况下飞速提供给我
一个进行一些东西的验证。

-- [ 参考

[1] PROJECT AREA52
http://www.phrack.org/phrack/56/p56-0x06

[2] 4tphi: Detecting VMWare
http://www.securityfocus.com/archive/119/298954
http://www.securityfocus.com/archive/119/298956
http://www.securityfocus.com/archive/119/299222

[3] IEEE OUI and Company_id Assignments
http://standards.ieee.org/regauth/oui/index.shtml
http://standards.ieee.org/regauth/oui/oui.txt

[4] Maintaining and Changing the MAC Address of a Virtual Machine
http://www.vmware.com/support/ws4/doc/network_macaddr_ws.html

[5] VMware's back
http://chitchat.at.infoseek.co.jp/vmware/

[6] Linux on-the-fly kernel patching without LKM
http://www.phrack.org/phrack/58/p58-0x07

[7] 写了个检查操作系统是否跑在VMware下的小程序
http://elfhack.whitecell.org/mydocs/checkVM.c

[8] The Linux PCI ID Repository
http://pciids.sourceforge.net/

[9] Honeyd - Network Rhapsody for You
http://www.citi.umich.edu/u/provos/honeyd/
http://www.honeyd.org/

[10] Identifying Web Servers
http://www.blackhat.com/presentations/bh-asia-02/bh-asia-02-grossman.pdf