人们对 MPLS 技术的安全性存在几个误解。最大的误解是:基于 IP 的 MPLS 不安全。事实上,为增强安全性, MPLS 为本地 IP 网络增加了很多功能,包括路径隔离、数据隔离、分组过滤和网络隐藏机制等。
另一个误解是,服务供应商客户相互之间可以侵入到对方的 VPN 中。事实上,这是根本不可能的,因为不同客户的 MPLS VPN 是完全隔离的。第三个误解是, MPLS VPN 容易遭受外部 DoS 攻击。这也是不对的。纯 MPLS VPN 网络是非常安全的。如果供应商边缘路由器只提供 VPN 接入,同时提供互联网接入的 MPLS 核心也可以有效防止 DoS 攻击。
另一个常见问题是,即使为 VPN 服务使用了专用的供应商边缘路由器,也容易遭受 DoS 攻击。虽然理论上正确,但实际使用中从未遇到这个问题,因为在使用中很容易发现并断开与入侵者的连接。
不需要修改地址
管理式 VPN 服务不需要对企业的内部网、台式机或服务器作较大的改动。多数企业都采用了专用 IP 定址计划。基于成本和安全原因,企业希望在移植到管理式 IP VPN 服务的共享网络环境时沿用原来的计划。 MPLS 允许不同的 VPN 使用相同的地址空间( RFC1918 )。由于为每条 IPv4 路径添加了 64 位路径标识符,因此,即使是共用地址,在 MPLS 核心中也是唯一的。每个 VPN 客户和 MPLS 核心本身都可以完全独立地使用整个 IPv4 地址空间。
路由和数据分离
MPLS 通过两种方式实现路由分离。第一种方式是将每个 VPN 分配到虚拟路由和转发( VRF )实例。供应商边缘路由器上的每个 VRF 只保留某个 VPN 的路径,保留时可以使用静态配置的路径,也可以使用供应商边缘与客户机边缘路由器之间运行的路由协议。第二种方式是为多协议边缘网关协议( BGP )添加唯一 VPN 标识符,例如路径辨别符。多协议 BGP 在相关的供应商边缘路由器之间交换 VPN 路径,并将路由信息保存在 VPN 专用的 VRF 中。对于每个 VPN 来讲, MPLS 网络上的路由是相互分离的。

图 1 为抵御 VPN 中的 DoS 攻击,提高安全性,企业可以像帧中继或 ATM 那样,为供应商边缘提供独立的 VPN 和互联网接入。

图 2 企业可以从客户与供应商边缘之间的一条链路分出多条帧中继逻辑链路,以便控制成本,并将互联网接入服务分开。
MPLS VPN 通过 IP VPN 转发表的分离而实现第三层数据分离。服务供应商核心内的转发基于标记。 MPLS 将设置供应商边缘路由器开始和结束的标记交换路径( LSP )。分组只能通过与该 VPN 相关的供应商边缘路由器接口进入 VPN ,而且由接口确定路由器应该使用哪个转发表。这种地址计划、路径和数据的分离能够帮助 MPLS VPN 实现与帧中继或 ATM VPN 相当的安全性。
隐藏核心
将 MPLS 核心网络对外隐藏起来,能够增加攻击的难度。 MPLS 隐藏核心的方法是对分组进行过滤,以及不在边缘以外显示网络信息。分组过滤能防止向外暴露 VPN 客户的内部网络信息或 MPLS 核心。由于只有供应商边缘路由器包含 VPN 专用信息,因而并不需要显示内部网络拓扑信息。服务供应商只需按照供应商边缘和客户边缘之间的动态路由协议的要求,显示供应商边缘路由器的地址即可。
在动态提供路径的情况下,如果客户 VPN 必须向 MPLS 网络公开其路径,也不会降低网络安全性,因为核心只了解网络路径,而不了解具体主机的路径。由于供应商网络不向第三方或互联网显示地址信息,因此, MPLS VPN 环境完全能够阻挡住攻击者发动的攻击。在提供共享互联网接入的 VPN 服务中,服务供应商可以利用网络地址转换( NAT )宣布路径。即使使用这种方法,向互联网公开的信息量也不会高于典型的互联网接入服务。
阻挡攻击
为防止路由器遭受攻击,服务供应商将对分组进行过滤,并隐藏地址。访问控制列表( ACL )只包含从客户边缘路由器到路由协议端口的接入。外部黑客的惯用方法是,先穿过 MPLS 核心,然后直接攻击供应商边缘路由器,或者攻击 MPLS 信令机制,最终攻入第 3 层 VPN 。对路由器进行适当的配置可以同时防止这两种攻击。
虽然设备地址不对外公开,但内部黑客可以猜测。 MPLS 地址分离机制认为向内传输的分组属于 VPN 客户的地址空间,由于逻辑上不可见,因而黑客不可能通过地址猜测攻入核心路由器。
通过路由配置,服务供应商可以防止黑客直接攻击供应商边缘路由器上的已知对等接口。静态路由是最安全的方法。在这种情况下,供应商边缘路由器将拒绝动态路由请求。静态路由指向供应商边缘路由器的 IP 地址,或者客户边缘路由器的接口。当路由指向接口时,客户边缘路由器不需要知道核心网络中的任何 IP 地址,甚至不需要知道供应商边缘路由器的地址。
客户与供应商边缘路由器之间的动态路由链路属于薄弱环节,因为每台客户边缘路由器都需要知道路由器 ID 或供应商边缘路由器的对等 IP 地址。思科建议通过以下方式保护这种连接:
请参考“对基于 MPLS 的 IP VPN 安全性的分析:与帧中继和 ATM 等传统 L2VPNS 的比较及部署指南”一文,网址为: cisco.com/packet/164_5b1 。
MICHAEL BEHRINGER 是思科的高级咨询工程师,常住在尼斯,主要负责解决服务供应商的安全问题,例如 MPLS 安全和防 DoS 攻击。他是 IETF 的成员之一,邮箱地址为: mbehring@cisco.com 。
STEPHEN WONG 已经在服务供应商和网络行业中耕耘了 20 余年,在思科担任过与服务供应商营销有关的许多职位,包括 MPLS 、 IPSec 、第 2 层和第 3 层 VPN 服务等。他的电子邮箱地址为: stepwong@cisco.com 。
- 如果可能,在客户和供应商边缘路由器之间使用 BGP ,这样能够为应用提供非常先进的安全功能。 BGP 可能通过很多方法添加功能,例如前缀过滤和衰减等。
- 利用 ACL ,只限从客户边缘路由器接入路由协议的端口。
- 为路由协议配置第五消息摘要( MD-5 )认证,防止欺诈。
- 配置每个 VFR 可接受的最大路径数量。
防止欺诈,建立加密通信
欺诈攻击指试图修改路由信息,或者接入认证序列,然后利用这些信息实现非法接入。尽管 VPN 客户可以在 MPLS 环境中执行 IP 源地址欺诈,但 VPN 之间以及 VPN 与核心之间的严格分离使之无法利用这种方法攻击 VPN 或核心。同样,标记欺诈也是徒劳的,因为供应商边缘路由器能够自动丢弃从客户处收到的标记分组。
企业可以通过适当配置的 MPLS 核心发送加密流量,这样既符合法规要求,又能增强数据的安全性。加密在客户边缘路由器之间操作。 MPLS 和 IP Security ( IPSec )加密可以组合使用,如果分组负载对服务供应商网络透明,还可以使用专用或应用级加密方法。
提供方式
建立网络与供应商边缘之间的连接时,企业需要在安全性与成本之间进行权衡。无论在哪种情况下,供应商都可以全面控制 VPN 隔离。供应商边缘将客户边缘视作不可信的,只接受来自客户边缘的纯 IP 分组。在多数部署中,服务供应商通过同一个核心提供 VPN 和互联网接入服务,如果服务供应商采用了思科推荐的相应安全措施,就可以达到可以接受的安全水平。在多数 MPLS VPN 部署中, VPN 服务都可以通过同一个核心提供互联网接入。相反,对于帧中继和 ATM 核心,由于需要用两个独立的基础设施提供两种服务,因而提高了成本。
最安全、最昂贵的部署方式是像帧中继或 ATM 那样,将一个站点的 VPN 与互联网接入完全隔离开(见第 21 页的图 1 )。但客户需要购买两台边缘路由器和两条 WAN 接入线路,并通过独立的边缘路由器进入供应商网络。这种方式能够有效防止通过互联网连接发动的任何 DoS 攻击。
另一种部署方案是在供应商边缘同时提供 VPN 和互联网接入服务。客户也需要购买两台边缘路由器和两条接入线路,但它们插入的是同一台供应商边缘路由器的两个独立 VRF 接口。这种方案的成本低于全面隔离,但同样能有效防止对 VPN 发动的 DoS 攻击。
第三种方案是,企业使用一条接入线路提供两种服务,以降低 WAN 线路成本。这种方式对 DoS 攻击的抵抗力较差,因为基础设施需要同时支持两种服务。但是,实际风险要远远低于理论风险,因为服务供应商可以通过客户边缘和供应商边缘路由器的正确配置控制接入。在典型的单线路方案中,将一条帧中继接入线路分成两条逻辑链路,并在客户和供应商边缘路由器上使用独立的子接口(见图 2 )。互联网流量将被交换到互联网客户边缘路由器。客户边缘 VPN 路由器通过 VPN 逻辑接口保持 VPN 流量的分离。由于互联网流量被交换到互联网客户边缘路由器上,因而永远都看不到互联网流量。
向服务供应商咨询
企业可以通过以下问题评估服务供应商 MPLS VPN 产品的安全性:
互联网与 VPN 接入是通过同一个核心网络提供的吗?纯 VPN 服务是最安全的,但对多数企业而言,共享核心网络的安全性已经足够。
您是为互联网和 VPN 服务分别提供供应商边缘路由器吗?混合型供应商边缘路由器遭受 DoS 攻击的风险稍高。但是,无论供应商边缘路由器属于共享路由器,还是与互联网接入服务分开,黑客都不能侵入隔开的 VPN 。
您是怎样保护核心的?为保护 MPLS 网络,使其 VPN 服务能够像帧中继或 ATM 那么安全, Cisco Powered Network 供应商借鉴了思科非常好的安全实践经验。
转载地址:http://www.netsp.com.cn/Article/netsafe/VPN/200609/20060913210736.html