专家视角 Openstack 网络虚拟化安全分析战略研究部刘文懋关键词 :Openstack 网络虚拟化安全摘要 : 越来越多的数据中心和大企业开始采用虚拟化的私有云解决方案, 网络虚拟化的安全越来越受到重视, 本文以 Openstack 为例探讨了在实现网络虚拟化时采用的安全机制引言着云计

Size: px

Start display at page:

Download "专家视角 Openstack 网络虚拟化安全分析战略研究部刘文懋关键词 :Openstack 网络虚拟化安全摘要 : 越来越多的数据中心和大企业开始采用虚拟化的私有云解决方案, 网络虚拟化的安全越来越受到重视, 本文以 Openstack 为例探讨了在实现网络虚拟化时采用的安全机制引言着云计"

诊阳古
5 years ago
Views:

Openstack 网络虚拟化安全分析战略研究部刘文懋关键词 :Openstack 网络虚拟化安全摘要 : 越来越多的数据中心和大企业开始采用虚拟化的私有云解决方案, 网络虚拟化的安全越来越受到重视, 本文以 Openstack 为例探讨了在实现网络虚拟化时采用的安全机制引言着云计算的落地, 越来越多的开源设施虚拟化系统 (IaaS, 随 Infrastructure as a

1 Openstack 网络虚拟化安全分析战略研究部刘文懋关键词 :Openstack 网络虚拟化安全摘要 : 越来越多的数据中心和大企业开始采用虚拟化的私有云解决方案, 网络虚拟化的安全越来越受到重视, 本文以 Openstack 为例探讨了在实现网络虚拟化时采用的安全机制引言着云计算的落地, 越来越多的开源设施虚拟化系统 (IaaS, 随 Infrastructure as a Service) 被采纳并被部署到生产环境中, 如图 1 所示其中 Openstack 近年来最为流行 [1], 原因在于其具有开放的接口和灵活的架构, 特别是互联网企业和新型的云计算中心, 通过二次开发定制化模块的方式, 部署了满足其业务需求的 Openstack 系统, 目前已有一些超过 1k 物理节点的应用案例因此 Openstack 的安全防护, 特别是网络方面的安全机制, 对于服务提供商租户和安全厂商都尤为重要一 Openstack 简介 Openstack 包括计算虚拟化 (Nova 模块 ) 存储虚拟化 (Swift 图 1 各类开源 IaaS 系统的社区参与人数比较 Glance 和 Cinder 模块 ) 和网络虚拟化 (Neutron 模块 ) 三大部分, 24

它利用现有开源的计算网络和存储工具, 构建了图 2 中面向服务的设施虚拟化解决方案通俗来说,Openstack 借助了已有的开源工具, 驱动异构的物理资源, 并提供集中管理和协同各类资源的能力如网络虚拟化组件 Neutron 使用 Open vswitch(ovs) 实现虚拟机间的互联, 使用 IPTABLES 实现访问控制, 使用 Linux kernel namespace

2 它利用现有开源的计算网络和存储工具, 构建了图 2 中面向服务的设施虚拟化解决方案通俗来说,Openstack 借助了已有的开源工具, 驱动异构的物理资源, 并提供集中管理和协同各类资源的能力如网络虚拟化组件 Neutron 使用 Open vswitch(ovs) 实现虚拟机间的互联, 使用 IPTABLES 实现访问控制, 使用 Linux kernel namespace 实现网络空间隔离, 使用 vlan 实现网络隔离, 诸如此类在初始几个版本中,Openstack 的网络模块集成在计算模块 Nova 模块中, 在 Grizzly 版本后分离为独立的网络虚拟化模块 Quantum, 随之在下一个版本 Havana 中被改名为 Neutron 可见网络虚拟化功能越来越受到社区重视, 越来越多的网络功能得以以服务的形式交付, 如负载均衡服务防火墙服务和 VPN 服务等, Neutron 自身的安全机制和安全问题因此日益受到人们的重视, 本文主要探讨 Neutron 中当前的一些安全机制二虚拟网络的隔离和 VM 间的访问控制机制 ( 一 ) 防伪造地址在公有云中, 租户可以租用虚拟机发动 DDoS 攻击或 ARP 欺骗等, 这些攻击都是通过伪造源 MAC 或 IP 地址实现的其特点是攻击者从虚拟化系统内部发起, 攻击目标可能是公网主机, 或者是内网的主机对于前者的防御比较容易, 只需要在物理网络边界就可以部署安全设施进行检测和清洗 ; 但是后者的攻击流量大部分存在于虚拟网络和虚拟网络设备中, 物理的安全设备无法观测或理解物理网络中的流量, 无法进行有效的防护, 所以对于始于内部的 DoS 攻击, 应该在虚拟化环境中检测并抵御较传统数据中心而言, IaaS 系统的优势在于其知晓 VM 的真实 IP 和 MAC, 所以可以直接在 L2 防火墙上对数据包进行过滤,Havana 版已经引入了这部分特性, 可抵御虚假源地址的攻击以一台 VM(IP 为 ,MAC 为 fa:16:3e:34:c8:f8) 为例, Neutron 为其连接 OVS 分配了 ID 为 368d35e1-4db7-405f-af26-1f2b6f224bd8 的端口那么在其所在的计算节点上查看 Neutron 中基于 IPTABLES 的过滤方案, 运行 iptables -L -nvx 可以发现下面项 : Chain neutron-openvswi-s368d35e1-4 (1 references) pkts bytes target prot opt in out source destination RETURN all * * /0 MAC FA:16:3E:34:C8:F8 图 2 Openstack 的整体结构图 0 0 DROP all * * / /0 25

3 此处允许真实 IP 和 MAC 的数据包经过, 对其他数据包抛弃此外,Nova 也引入了基于 EBTABLES 的过滤方案, 运行 ebtables -t nat -L 可以发现下面项 : Bridge chain: libvirt-i-tap368d35e1-4d, entries: 6, policy: -j I-tap368d35e1-4d-mac -p IPv4 -j I-tap368d35e1-4d-ipv4-ip -p IPv4 -j I-tap368d35e1-4d-ipv4 -p ARP -j I-tap368d35e1-4d-arp-mac -p ARP -j I-tap368d35e1-4d-arp-ip Bridge chain: I-tap368d35e1-4d-mac, entries: 2, policy: -s fa:16:3e:34:c8:f8 -j RETURN Bridge chain: I-tap368d35e1-4d-ipv4-ip, entries: 3, policy: -p IPv4 ip-src ip-proto udp -j RETURN -p IPv4 ip-src j RETURN Bridge chain: I-tap368d35e1-4d-arp-mac, entries: 2, policy: -p ARP arp-mac-src fa:16:3e:34:c8:f8 -j RETURN Bridge chain: I-tap368d35e1-4d-arp-ip, entries: 2, policy: -p ARP arp-ip-src j RETURN 可见 Openstack 确实将 VM 的 MAC 和 IP 进行了过滤, 防止虚假源的数据包经过需注意的是, 虽然这种防护可以抵御伪造源地址的攻击, 但是无法抵御使用真实源地址的 DoS 攻击, 遇到这种情况, 还是采用 ceilometer 或是 SDN 的流检测的方式较好 ( 二 ) 虚拟网络隔离 Neutron 中的网络隔离是使用 vlan 实现的, 每个租户的 VM 会连接到 OVS 的某个端口, 那么该端口被打上一个 Tag, 所有流出该端口的数据包都会加上与 Tag 一致的 vlan 值, 所以同一个物理节点中, 同一个网络的数据包中所含的 vlan 是相同的, 但不同网络的数据包则有不同的 vlan 值, 从而网络间是彼此隔离的当一个网络可能分布在不同物理节点上时, 由于 Openstack 的 OVS Tag 不是全局的, 即同一个网络在不同物理节点中有不同的 vlan 值, 所以当数据在不同物理节点中传输时, 需要对这些同属一个网络的不同节点上的 vlan 进行映射如图 3 展示了使用 GRE 隧道连接的场景,VM1 VM2 和 VM3 同属网络 Net1,VM4 属于网络 Net2,Net1 在两个节点中的 OVS Tag 值分别为 1 和 3 那么当数据到达第一个节点的 GRE 隧道入口时,Neutron 将 vlan 映射为 GRE 隧道的 key, 当数据到达另一个节点的隧道出口时,vlan 又被还原为该节点中 Net1 对应的 Tag=3, 这样不同网络在多个物理节点 26

上也是隔离的图 3 GRE 隧道连接的不同物理节点的网络隔离需要注意的是, 当 Openstack 与 SDN 结合时, 通过 vlan 标记不同网络可能无法做到简单的网络隔离因为首先 OVS 加入 SDN 后发送的 Packet_In 不包含 vlan 值,SDN 控制器不了解 Openstack 中的网络隔离情况, 当多租户网络重叠的情况可能会出现路由错误的问题 ; 其次 SDN

安全组主要位于虚拟机与虚拟交换机之间的连接, 用于控制内部网络中虚拟机的访问, 特别是同一内网中的虚拟机间的通信, 如图 5 所示安全组的底层驱动通常为 IPTABLES 规则, 但图 4 Neutron 的访问控制机制在当前的 Linux 系统下, 虚拟交换机 OVS 与 IPTABLES 的规则尚不兼容, 所以 IPTABLES 策略不能在 VM 到 OVS 的路径上生效于是

4 上也是隔离的图 3 GRE 隧道连接的不同物理节点的网络隔离需要注意的是, 当 Openstack 与 SDN 结合时, 通过 vlan 标记不同网络可能无法做到简单的网络隔离因为首先 OVS 加入 SDN 后发送的 Packet_In 不包含 vlan 值,SDN 控制器不了解 Openstack 中的网络隔离情况, 当多租户网络重叠的情况可能会出现路由错误的问题 ; 其次 SDN 控制器控制了全部的二层转发过程, 所以 SDN 控制器必须获取 Openstack 中的网络隔离策略, 对含不同网络的数据包进行合理路由决策 ( 三 )VM 访问控制 Neutron 中的 VM 访问控制包括两个部分 : 二层的安全组 (Security Group,SG) 和防火墙即服务 (Firewall as a Service, FWaaS), 如图 4 所示 [2] 其中, 安全组主要位于虚拟机与虚拟交换机之间的连接, 用于控制内部网络中虚拟机的访问, 特别是同一内网中的虚拟机间的通信, 如图 5 所示安全组的底层驱动通常为 IPTABLES 规则, 但图 4 Neutron 的访问控制机制在当前的 Linux 系统下, 虚拟交换机 OVS 与 IPTABLES 的规则尚不兼容, 所以 IPTABLES 策略不能在 VM 到 OVS 的路径上生效于是 Openstack 在设计时做了一个临时解决办法, 即在 VM 与 OVS 之间加了一个 Linux bridge, 通过 veth 对将两者相连, 所有的 IPTABLES 规则在 Linux bridge 生效, 从而完成 VM 出入口的访问控制 Neutron 的三层访问控制主要是由 FWaaS 实现, 底层驱动也是 IPTABLES 那么安全组和 FWaaS 的区别主要在哪里呢? 第一, 两者的逻辑结构是不同的, 如图 6 所示, 安全组的主要规则在 security group rules 中,FWaaS 的规则主要在 firewall rules 中 ; 第二, 安全组是面向交换机端口的, 而 FWaaS 是面向路由器的 ; 最后, 安全组不能表达下一代防火墙应有的应用特性, 例如安全组不支持提供商发布一系列规则, 租户选择对其启用的特性, 此外, 安全组没有涉及很多边界防火墙服务提供的更丰富的管理应用方面的需 27

求特性因而安全厂商可将原有的硬件防火墙进行一定改造, 就可以 FWaaS 的方式提供防火墙服务 (a) 安全组的数据结构图 5 Neutron 的二层防火墙控制示意图 Neutron

R 相连, 内网存在 DHCP 服务那么在 Neutron 的网络节点上存在三个网络服务, 分别是 A 和 B 内部的 DHCP 服务和连接路由器 R, 于是对应了三个命名空间, 即 A B 的

一个命名空间内的数据对其他命名空间是隔离的, 但可通过网卡连接到网桥 br-int 上进行通信可见整个三层网络的转发是通过命名空间 (b) FWaaS 的数据结构图 6 安全组和 FWaaS

5 求特性因而安全厂商可将原有的硬件防火墙进行一定改造, 就可以 FWaaS 的方式提供防火墙服务 (a) 安全组的数据结构图 5 Neutron 的二层防火墙控制示意图 Neutron 中一种租户和网络隔离的方法是通过命名空间 (namespace) 实现的, 图 7 展现了这种方法下的 FWaaS 部署情况假定存在租户的两个虚拟内网 A B 和一个虚拟外网 C, 通过路由器 R 相连, 内网存在 DHCP 服务那么在 Neutron 的网络节点上存在三个网络服务, 分别是 A 和 B 内部的 DHCP 服务和连接路由器 R, 于是对应了三个命名空间, 即 A B 的 DHCP 服务器所在的 qrouter-bbbb 和 qdhcp-cccc 以及 R 所在的 qrouter-bbbb, 以 tap qr 和 qg 开头的均为这些服务器的网卡一个命名空间内的数据对其他命名空间是隔离的, 但可通过网卡连接到网桥 br-int 上进行通信可见整个三层网络的转发是通过命名空间 (b) FWaaS 的数据结构图 6 安全组和 FWaaS 的数据结构 qrouter-bbbb 实现的, 所以 FWaaS 应该在网卡 qr-yyy 和 qr-zzz 上生效, 所有经过路由器的数据包均接受 FWaaS 的访问规则检查介绍完 Neutron 访问控制的逻辑结构 28

后, 读者不妨通过 IPTABLES 自行验证一下, 安全组的策略可以在相应的计算节点运行 IPTABLES 查看,FWaaS 可在网络节点的相应命名空间中用 IPTABLES 查看其中 neutron-openvswi- 开头的服务会通过虚拟设备交付 [3], 所以需要在 Openstack 和 SDN 结合的企业私有云环境中研究快速交付用户可编程的软件定义安全解决方案规则为

6 后, 读者不妨通过 IPTABLES 自行验证一下, 安全组的策略可以在相应的计算节点运行 IPTABLES 查看,FWaaS 可在网络节点的相应命名空间中用 IPTABLES 查看其中 neutron-openvswi- 开头的服务会通过虚拟设备交付 [3], 所以需要在 Openstack 和 SDN 结合的企业私有云环境中研究快速交付用户可编程的软件定义安全解决方案规则为 Neutron 下发的, 而 nova-compute 开头的则是 Nova 下发的三 Openstack 网络安全的产品传统的安全厂商在 IaaS 系统中面临巨大的挑战, 特别是如何将自有的产品部署在虚拟化环境中 Neutron 提供的 FWaaS 就是一种很好的解决办法, 即厂商可以先将自己的产品形态虚拟化, 然后将流量牵引到虚拟安全设备, 实现安全防护山石网科和 varmour 都发布了支持 Neutron 的 FwaaS : 前者的虚拟防火墙当前支持源地址转换目的地址转换服务器负载均衡基于应用的访问控制拒绝服务攻击防护会话限制等网络安全特性 ; varmour 替换了 Neutron L3 Agent, 支持 NAT, 使用 REST 调用 varmour 的防火墙, 并扩展了原有的 neutron FWaaS 驱动, 底层支持 varmour 的防火墙, 提供了全方位的访问控制防护四结论网络虚拟化安全还有很多工作需要完成, 例如 Neutron 与 SDN 控制器整合后的访问集中管理 ; 此外现有的工作还有大量需要改进之处, 如 FWaaS 当前还有很多限制 ( 一租户一 FW) 越来越多的安全企业开始将安全产品兼容网络虚拟化和 SDN 场景, Garnter 预测截止 2014 年,TOP 10 网络安全厂商中的 9 家会支持 OpenFlow ; 截止 2015 年,40% 的企业安全数据中心网络和安全图 7 Neutron 三层防火墙的实现示意图参考文献 [1] CY13-Q4 OpenStack, OpenNebula,Eucalyptus, CloudStack 社区活跃度比较 [2] OpenStack Configuration Reference - Havana, docs.openstack.org/havana/config-reference/content/under_ the_hood_openvswitch.html,2013 [3] Garnter, The Impact of Software-Defined Data Centers on Information Security, impact-softwaredefined-data-centers-information,

MASQUERADE # iptables -t nat -A POSTROUTING -s / o eth0 -j # sysctl net.ipv4.ip_forward=1 # iptables -P FORWARD DROP #

MASQUERADE # iptables -t nat -A POSTROUTING -s / o eth0 -j # sysctl net.ipv4.ip_forward=1 # iptables -P FORWARD DROP # iptables 默认安全规则脚本一 #nat 路由器 ( 一 ) 允许路由 # iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT ( 二 ) DNAT 与端口转发 1 启用 DNAT 转发 # iptables -t nat -A PREROUTING -p tcp -d 192.168.102.37 dprot 422 -j DNAT to-destination