wireshark分析中间人攻击失败的原因

       在Kali平台上用ettercap做中间人欺骗时，发现arp欺骗后，受害者的机器无法打开网页。停止arp欺骗后，受害者又能正常上网。起初我怀疑我没有正确设置ettercap，于是我又换成cain&abel，得到同样的结果。我猜想应该是路由器(Netgear-R800P)的防火墙在作祟。于是，我换了一个低配的路由器(MERCURY MW300)，同样的操作步骤下，ettercap和cain&abel实施arp欺骗后都可以让受害者的机器继续上网。

        原本到此就结束了，不过我比较好奇为什么Arp欺骗失败了？为此我用wireshark抓包分析了一番：

先介绍一下环境：受害者：IP 192.168.1.2/Mac e4:70:b8:c1:8a:63；中间人：IP 192.168.1.3/Mac 60:57:18:2f:c4:3e；Netgear路由器：IP 192.168.1.1/Mac a0:40:a0:83:44:2f。为了便于观察，还需要对wireshark进行设置，添加"Time since first frame in this TCP stream"列，并对该列进行排序(具体步骤参考链接)。

下图是进行Arp欺骗前，在受害者主机上捕获到的访问Netgear路由管理页面的数据包。虽然图中没有显示所有数据包，但是根据握手/挥手包，可以确定受害者成功访问了路由管理页面。

开启Arp欺骗后，重复上述过程，得到下图：

啊，真是满目疮痍！不少乱序,重传,最后受害者还重置了链接。

       起初，我以为RST包是路由器防火墙发起的。但是wireshark显示该数据包的源头是受害者，目的地是路由器，也就是说是受害者主动reset链接。但是，受害者的浏览器基于什么原因reset链接目前还是不清楚，还得往下分析。不过目前看来在受害者机器上可能无法发掘出有用的信息了，因此，我把重点转移到分析路由器的数据包上(由于开启了双向Arp欺骗，在中间人的机器上可以收到受害者和路由器的通信，所以，我并没有用端口镜像的方法分析路由器数据流)。

下图是路由器上的数据包：

感觉除了满目疮痍，其通信量好像比在受害者机器上捕获的数量多很多。这很正常，毕竟受害者要先通过路由把数据传给中间人，然后再由中间人把同样的数据传给路由。以最后两个RST包为例，初看以为是受害者发送了2次RST包----wireshark都是从192.168.1.2发出的----但回忆之前在受害者机器上捕获的数据包，受害者只发送一次RST包，因此，可以大胆的断言其中一个是由中间人发送的。而且根据时间先后关系，可以断定302#包是受害者原始发送的，而303#包是中间人转发的。下面我来验证这个断言：

#302数据包的链路层的源MAC/目的MAC显示从受害者到中间人。

#303数据包的链路层的源MAC/目的MAC显示从中间人到路由器。看来前面猜想的没错，先记下，后面马上会用上。

        接着，我们来仔细看下Packet List面板中的信息。其中不少包后面跟着类似[TCP Dup ACK 25#N]的摘要信息。[TCP dup ack M#N]中M表示丢失的包的序号，N表示第几次丢失。这么说#25包发生了多次丢失。我们回头看看#25包是啥：

恩，从受害者发送给中间人的TCP握手包！这个包丢失了，浏览器虽然努力尝试重新建立链接，但是一直被防火墙阻挡了，所以TCP链接一直没有成功建立，最后浏览器也放弃了尝试，导致受害者机器不能上网！怪不得了。另外，结合前面说到的Arp欺骗的猜测，再仔细看"Packet List"里的包，在TCP握手阶段，受害者的Sync包和路由器的Sync/Ack包都是成对出现的，唯独受害者的Ack只出现一次，这对于定位问题有点帮助~