3月 252013
 

一次 ARP 欺骗病毒实战

下午一点钟左右,有”同学”报告公司网络开始变慢,马上查看 Cacti 的监控情况, 发现公司总带宽还并没有跑满,但可以看到相应的有一段比较长的时间维持在高峰状态, 而不是象正常情况下不断有起伏。

如图: arp deception [linux系统管理]  Security 流量控制 一次 ARP 欺骗病毒实战

然后查看 iptraf,看能不能找到相应的 MAC 地址,结果发现有一个 MAC 地址几乎占据 了全部的流量,而其他 MAC 则几乎完全没有流量,于是用 arp 命令查看:

  sh# arp | grep -i '00:e0:4c:00:32:f9'
  arp
  Address                  HWtype  HWaddress           Flags Mask            Iface
  192.168.0.149            ether   00:E0:4C:00:32:F9   C                     eth0
  192.168.0.121            ether   00:E0:4C:00:32:F9   C                     eth0
  192.168.0.198            ether   00:E0:4C:00:32:F9   C                     eth0
  192.168.0.150            ether   00:E0:4C:00:32:F9   C                     eth0
  192.168.0.152            ether   00:E0:4C:00:32:F9   C                     eth0
  192.168.0.153            ether   00:16:17:10:23:3C   C                     eth0
  192.168.0.254            ether   00:E0:4C:00:32:F9   C                     eth0
  192.168.0.178            ether   00:E0:4C:00:32:F9   C                     eth0
  192.168.0.24             ether   00:E0:4C:00:32:F9   C                     eth0
  218.80.208.65            ether   00:04:80:9B:FB:00   C                     eth1
  218.80.208.90            ether   00:50:8B:B3:9F:4B   C                     eth1
  192.168.0.20             ether   00:E0:4C:00:32:F9   C                     eth0
  192.168.0.154            ether   00:E0:4C:00:32:F9   C                     eth0
  192.168.0.119            ether   00:E0:4C:00:32:F9   C                     eth0
  192.168.0.233            ether   00:E0:4C:00:32:F9   C                     eth0
  192.168.0.161            ether   00:E0:4C:00:32:F9   C                     eth0
  192.168.0.144            ether   00:E0:4C:00:32:F9   C                     eth0
  192.168.0.221            ether   00:E0:4C:00:32:F9   C                     eth0
  192.168.0.35             ether   00:E0:4C:00:32:F9   C                     eth0

可以看到,所有的内网地址都映射到了同一个 MAC 地址,我们遭遇了 ARP 欺骗。

接着,有人报告说官方网站出现了病毒,因为之前遇到过路由中病毒而导致在出入的报文 中被插入病毒的情况,结合这里的 ARP 欺骗,可以肯定这里是由于中毒而导致 ARP 欺骗 以及页面被插入病毒的情况。

… ARP 及 ARP 欺骗的原理 …

在内网的一台普通主机上运行:

  C:Documents and Settingssysadm> arp -a

若干次,可以发现网关 192.168.0.1 的 MAC 地址始终在变化,并且都不是其真实的 MAC 地址;在网关上运行 arping 到一个普通的工作机:

  sh# arping 192.168.0.125
  ARPING 192.168.0.125 from 192.168.0.1 eth0
  Unicast reply from 192.168.0.125 [00:E0:4D:06:5C:C4]  0.700ms
  Unicast reply from 192.168.0.125 [00:E0:4D:06:5C:C4]  0.677ms
  Unicast reply from 192.168.0.125 [00:E0:4C:00:32:F9]  837.700ms
  Unicast reply from 192.168.0.125 [00:E0:4C:00:32:F9]  826.677ms
  ......

 

根据 ARP 欺骗的基本原理,可以肯定这里病毒对网关和内网的其他所有主机都进行了 欺骗,从而使所有的报文都要经过它进行转发,成为了一个欺骗性的路由,通常 PC 机的 性能和网络带宽都很小,而且这里又绕了一个圈,从上面的 arping 的结果来看,返回 时间值很大,所以,虽然公司总带宽没达到瓶颈,但大家都感到网络速度变慢了,而且 这里面可能存在窥探密码等敏感信息的可能。

因为现在所有的 MAC 信息都被欺骗,所以但凭现在简单的网络软硬件设施是无法定位有 问题的那台主机的。从软件资源的角度来看,如果拥有一个 IDS,例如 snort,也许可以 解决这个问题,但实际的情况我目前不是太清楚;从硬件资源来看,如果交换机是可网管 的,那么也许可以查看交换机上各个物理端口的报文和流量情况作出判断。

现在的情况,只能利用物理方法,即逐一拔除网线的办法来解决,同时,需要利用一些 工具来进行判断,例如上面的 arp -a 或 arping,或者专门的嗅探器,如 ethereal 或 winshark 等。

可以从最上层的交换机开始做。对前者,当拔除部分线路时(通常可以使用二分法),在 路由器上使用 arping 某一台连接着的主机,可以判断问题是出在哪一半的线路上,或者 连接一个笔记本到交换机上来做这个事情,可以用 arp -a 或 arping gateway。

对后者,可以打开嗅探器,然后看 ARP 包的数量是不是异常的多,也可以判断出问题是 在哪一步分的线路上。

然后逐级查找下一级的交换机。

当然,如果布线和标签等硬件管理措施不是很到位,那么这件事情也不是那么轻松,但总 的来说,是一个在资源比较匮乏的情况下相对比较快捷点的办法。

参考: 交换网络中的嗅探和 ARP 欺骗

今天早上再次遇到了 ,昨天的线路已经找到,并且已经将其网线从交换机 上拔除,所以应该是有新的机器中毒了。那么是否应该象昨天那样采用物理拔除法呢?

在作出决定之前,应该先判断病毒的表征,因为很可能不是同一种病毒。在昨天的例子 中,用于欺骗的 ARP 实际上并不是一个原来已经存在的 ARP 地址,而今天的情况是, 这个 ARP 地址可以找到实际的对应 IP(使用工具如 nbtscan),并且因为之前已经 建立公司每个员工和相应的 MAC 地址的对应表,也是可以找到相应的记录,所以这 是一种不同的病毒。那么断开这台主机的网络连接,进行相应的杀毒处理。

nbtscan 可以从这里下载: nbtscan 可以使用命令:nbtscan -m 192.168.0.0/24来查找 IP 和 MAC 的对应表,因为此时 ARP 欺骗已经发生,所以无法直接使用 arp 命令。这个命令似乎在 Windows 下运行 得到的结果比 Linux 下更准确。另一个可选的办法是使用 arping 在一个 shell script 的循环中ping 整个网段的所有主机(1~255),使用arping -c1,这样可以得到正确的 IP 和 MAC 地址的对应表,不过因为是顺序执行,所以速度较慢,可以考虑使用多进程 等。

Posted by

 回复

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>