包,宣称网关192.168.1.33的mac地址是自己!此时,我们在a机上看看arp表的内容,
C:>arp -a
Interface: 192.168.1.37
Internet Address Physical Address Type
192.168.1.33 08-00-20-c8-fe-15 dynamic
哈!a机的arp表已经改变了,网关的mac地址被更新为了 b机的mac地址,这样,当有数据包发送时,a机理所当然的会发到它arp表中网关对应的mac地址08-00-20-c8-fe-15,然而这个地方的b机正在等待着,悄然无声的冒充网关收发着a机的数据包。
有一点要说明的是,为了让a机能正常使用网络,b机还必须打开数据转发,
linux中可以使用sysctl -w net.ipv4.ip_forward = 1
bsd系统可以使用sysctl -w net.inet.ip.forwarding =1
solaris系统可以使用ndd -set /dev/ip ip_forwarding 1
除了这样打开内核的支持外,也可以选用外部的fragrouter等转发软件,如此,就能确保a机正常工作了。
此外,ettercap的作者指出,内核为2.4.x的linux系统在arp实现中,考虑到了arp欺骗,不会接受未经请求的arp回应,因此直接向这种系统发送arp reply也是无效的,不过,有意思的是虽然它不会接受未经请求的arp reply,但是只要接收到arp的request,它就会更新自己的arp缓存,;),如此就好办了,发送一个伪造的arp request即可!不过,作者在自己实验时没有发现这个问题,作者内核为2.4.7的系统接受了直接的arp reply,并更新了自己的arp表。
如果一切配置正常的话,被重定向的a机是不会有什么明显的感觉的,网络照常是通畅的,只是在后台数据都绕了一个小圈子,不是直接到网关,而是先经由b机,再由b机转发到网关,因为数据包都经过了b机,那么在b机上起一个