IPv6时代会有“ARP”攻击吗？

作者 | 2010-02-01 17:52 | 类型 专题分析, 网络安全, 行业动感 | 17条用户评论 »

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




ARP攻击，欺骗，病毒，木马等等风风火火了一段时间(现在可能仍然火着)，也有很多高人撰写了攻击方式和防范技术等奇淫巧计众多文章，多数网络设备厂商也提供了缓解和应对之策。读者可能会有疑问，ARP中的种种问题在IPv6中是否会存在呢？

首先还是简要描述一下ARP问题的根源，这个我想大家已有共识：ARP协议基于的假设是网络设备都是善意的，也就是说ARP没有安全认证等机制。这一点决定了很容易被攻击欺骗。对此笔者也很疑惑，不少网络协议，在制定之初安全问题确实考虑不多，但是随着后期使用，依据现实环境中遇到的问题，IETF往往会给出安全扩展。例如IPSec，DNSSEC，SSL， BGP Security等等。但是对于ARP如此基础且恐龙级的协议，IETF似乎无动于衷。唯一可以想到的理由大概就是IETF关注于IP之上的东东，对于数据链路层相关的ARP不care（链路层相关标准，一般由IEEE主刀）。

ARP攻击无论表现形式以及目的有多少种，其结果

1. 针对Host来说，污染ARP邻居映射关系。

2. 针对网络设备来说，污染FDB表。

言归正传，我们看看IPv6的情况。IPv6中对应于ARP功能的协议称为ND，即邻居发现协议。ARP有的地址解析功能，ND依葫芦画瓢也有（本质一样，协议实现有差别）。其中一个显著的不同就是ND封装在ICMPv6中，而ICMPv6是封装在IPv6报文中的，因此同以太网彻底决裂，想要做什么东东也不需要IEEE同意了。

ND协议设计同ARP有类似弱点（虽然协议将安全寄希望于IPSec，但是没有给出部署指导，也没听说有人这么干）。如果没有安全扩展必然重蹈ARP的覆辙，ND木马，ND病毒的出现时迟早的事情。

ARP中的防范措施，基本上对于ND也是可行的，例如静态地址映射等，但都是些权宜之计，彻底解决问题还要有协议安全措施。

好在IETF的专家意识到了这个问题的严重性，撰写了RFC3756用于分析ND协议弱点。之后据此开发了RFC3971,3972 — SEND(Secure ND)协议原本。该协议是如此这般……实现的，我就不抄书了。其中最令笔者佩服的是所谓的CGA地址的生成，利用IPv6地址空间长这一特性，在自动生成地址的同时，将实际的签名信息也保存在了生成的IPv6地址内部。通过这种方式使得源地址的拥有权声明是可验证的。说实话，笔者佩服的四脚朝天。当然还有其他一些机制（完整性防护、anti-replay等等）用以彻底解决所有安全问题。总之解决了ND安全问题。

现在大家对于IPv6地址解析攻击的担心应该减轻了不少吧。其实放心的还是有点早，如果现阶段大家都走IPv6网络，且SEND没有普及，则ND木马还是有机可乘的。例如据笔者所知，目前为止Win7尚不支持SEND。所以会不会有ND木马，现在还不好说，这个要视IPv6发展情形而定。

另外：山石科技有一篇白皮书—《Hillstone ARP防护StoneOS保护MAC地址与ARP协议》，其中的ARP Client防护措施应该应该同SEND类似是解决ARP问题的根本之道，其本质上应该是为IPv4 ARP做了类似SEND协议的安全补丁，只不过属于私有协议解决方案，无法形成RFC，因此OS不支持，需要安装山石的客户端才能实现。（另外，山石的白皮书中提到，系统是基于PKI的，这个有些重量级了），SEND实现的轻量级一些。（笔者对山石工程师及客户之所急做了这么多ARP防护工作表示敬意）。

(3个打分， 平均：5.00 / 5)

工具箱
本文链接 | | 打印此页 | 17条用户评论 »

雁过留声

“IPv6时代会有“ARP”攻击吗？”有17个回复

  1. 大荣 于 2010-02-01 7:30 下午

    http://papa.cnw.com.cn/ItemDetail.php?ID=42 我在这个测试报告里谈了思科的解决方案，貌似应该是这个报告。

  2. 子曦 于 2010-02-01 9:27 下午

    大荣,我注册不了，SQL Error, 不能下载”思科Catalyst 3750E交换机首家评测”。那里可以download?

  3. 杰克 于 2010-02-01 10:12 下午

    应该是这个了：
    通常三层交换机和路由器在三层转发中只看数据包的目的IP 地址，而不关心数据包的源IP 地址情况。这
    就给很多黑客和恶意软件以空间和漏洞，他们可以通过仿冒IP 地址进行攻击，比如黑客使用计算机本工作
    再192.168.1.0/24 网段，他可以仿冒任意其他网段的主机乃至是一个Loop back 地址对目的主机进行
    攻击，在经过三层交换机和路由器的几跳，而网络管理员很难发现攻击源。再比如黑客可以仿冒其他网段
    的一个真实主机地址B，向其他的主机发出请求或者Ping 操作，从而引发对该主机的DDoS 攻击。防范
    类似攻击Catalyst 3750-E 可以利用IP Source Guard 和DHCP Snooping 来防范直连主机的地址更
    改仿冒工作，另外还可以通过设定ACL，过滤主机源地址的方法防范仿冒，当然后者的灵活性和可扩展性
    不强，在大型网络上难以实施。但是假如网络中的接入交换机不都支持IP Source Guard 和DHCP
    Snooping 等功能，经过几次三层转发或者路由接入到网络中，就需要有三层交换机支持反向路径检查功
    能——uRPF，防范类似的攻击行为。这样的功能以前只在高端交换机和路由器上才能硬件支持，现在像
    Catalyst 3750-E 这样的固定配置交换机也支持了这一功能。使用uRPF，另一个好处是在实现安全功能
    的同时，不用占用宝贵的ACL 资源。 uRPF 是根据FIB 表检查IP 包的源IP 地址是否属于其进入的接口，
    确定数据包的源IP 是否非法的，例如：在路由网络中假如A 网段的路由没有通过同一交换机的B 端口宣
    告过来，而是通过同一交换机的C 端口宣告过来，当用户伪造的A 网段数据从B 端口进入，会被交换机丢
    弃。使用uRPF 不用手工指定哪个端口哪些源地址可以通过，而是根据路由表的变化动态地实现，降低了
    配置的难度，在大型路由转发网络中具有很高的灵活性和可扩展性。我们在测试中验证了该功能。在未启
    用uRPF 情况下，我们从属于102.1.1.0/24 网段的端口，发送源地址为192.168.1.3 的数据包，目的
    地址为101.1.1.2/24 的数据，属于101.1.1.0/24 的端口可以接收到流量。当启用uRPF 之后，原地址
    为192.168.1.3 的数据包被过滤掉了。

  4. 子曦 于 2010-02-01 10:58 下午

    Ok, 原来你说的是uRPF (RFC 3704).

  5. 杰克 于 2010-02-01 11:43 下午

    4楼，这是我说的，等荣总确认才算。

  6. tree 于 2010-02-02 12:31 上午

    我亲自接触过的URPF倒不是遇到了安全问题，而是遇到了互联互通问题。

    运营商在网络边缘部署URPF已经比较常见，这给不少网络部署带来困难。比如某个企业有联通、电信两条线路，都被部署了URPF，
    1. 假设该企业主链路为电信
    2. 当互联网上某个PC访问该企业联通地址
    3. 那么回复数据包根据路由选择主链路电信
    4. 由于源地址是联通地址，就被电信的URPF给干掉，访问失败。

    有的厂家通过直接修改转发行为的方式解决这个问题，路由器通常的解决方法是在出口部署策略路由，源地址是联通的统统从联通线路出去，源地址是电信的则走电信线路。

    当时还专门为我们公司的东西写一篇案例。
    http://kms.h3c.com/kms/repository/20182.kmspage

    但是总觉得这种方案下要用这种方式来实现有点傻，配置工作量大，客户也难理解。不知道大家有什么更好的方法没有？

  7. 杰克 于 2010-02-02 12:47 上午

    运营商都比较猥琐。
    urpf在转发设备上解决问题，本文看上去的着力点似乎在host上。uprf对于网络攻击有一定的防御能力，但是对于arp来说，似乎分量重了点。

  8. 子曦 于 2010-02-02 1:10 上午

    How about loose mode uRPF?

  9. tree 于 2010-02-02 1:37 上午

    国内运营商分配给客户通常是1个线路+1个地址，所以通常严格模式居多，松散模式少，大部分人都用不起多条链路。

  10. 杰克 于 2010-02-02 1:43 上午

    目前用loose mode的多，还是strict mode的多？
    用loose mode的话，感觉urpf就是一个鸡肋了。

  11. appleleaf 于 2010-02-02 6:01 下午

    看来大家都是搞数通的，不知道urpf的性能影响怎么样了，enable之后，转发是否还下降50%？

  12. wddlsz 于 2010-02-03 4:19 上午

    http://www.networkworld.com/news/2010/012710-comcast-ipv6-trials.html?fsrc=netflash-rss

  13. wddlsz 于 2010-02-03 4:20 上午

    晕，回错地方了

  14. atst 于 2010-02-03 8:49 下午

    to aapleleaf:一般基于芯片的转发，RPF不会降低性能，主要是增加一条rpf entry.

  15. appleleaf 于 2010-02-03 9:03 下午

    谢谢atst，这里是urpf，要对于源地址重新差一遍路由，我的很多年前的经验是，转发效率降低50%。

  16. 黑猫 于 2010-02-04 2:20 上午

    取决于lookup芯片是否为urpf预留了能力，某些产品做到了不下降，如juniper的一款产品。

  17. tree 于 2010-02-04 2:59 上午

    很多时候可以直接用防火墙规则替代uRPF，效果是一样的。