2月技术周 | OVS实现安全组，你须要知道这些！

防火墙

防火墙是避免网络信息基础设施免受复杂网络环境中安全***的必要设施。高效的防火墙则更须要实时跟踪来往于不一样网络设备间的各种网络链接，即“有状态防火墙”。对于实际的硬件物理网络基础设施须要防火墙，对于虚拟网络设备，openstack在这样的云平台亦须要一样的防火墙进行网络保护。

在Openstack中，防火墙由“Security Group”和“FWaas”两大服务组成。其中Security Group在port级别提供对VM网络通讯的访问控制。而Fwaas则运行在vrouter上在subnet的边界控制子网间的L3和L4流量。简而言之，“Security Group”保护port，“FWaas”保护subnet。

Openstack下的“Security Group”不只保护租户VM，使其避免受到无价值数据流的影响，同时还限制租户VM，避免其主动发起ARP spoofing，DHCP spoofing等不安全网络行为。实际定位到底层，“Security Group”能够经过iptables和ovs 流表两种方式实现。本文将重点讲述基于OVS 流表实现的安全组（Security Group）。

OVS Conntrack 概述

无状态的防火墙只能经过静态的网络元组来过滤，阻拦，放行数据报文。这里的静态网络元组包括IP地址，端口，网络协议。无状态防火墙并不关心当前网络链接处于何种状态。相较于无状态防火墙，有状态防火墙增长了对当前网络链接状态的识别，同步使用静态的网络元祖对数据报文进行过滤，阻拦，放行。增长的识别标志在必定程度上消耗系统资源，但更加严格的规则却更能保障网络更加安全。

网络链接状态的识别一般是由CT模块（connection tracker）实现的。在linux内核中，CT是由conntrack实现。从OVS 2.5起，开始支持conntrack，并在openflow中体现相关CT状态的识别与处理。Openstack则从M版开始，使用OVS的新特性，来实现“有状态防火墙”中的“Security Group”功能。

从OVS提供的CT功能简图2来看，相对于原有流表处理，无非增长了提交链接数据包进入CT模块，标记链接状态，用于后续流表查询链接状态，匹配数据报文进行指定处理的过程。

图3列举了OVS实现的openflow 中新增的CT相关字段。（有删减，仅列举了后续流表分析时用到的字段）

这里须要重点解释下rel，inv，zone=value（ct_zone）这三条项目。

rel，即related。这里举个典型的例子描述下related数据包。当VM A ping 某外网IP地址B，发出一个ICMP Echo Request报文，当该Request报文到达路由器时，路由器断定外网IP地址不可达，回送一个ICMP Network Unreachable报文。那么这个ICMP Network Unreachable报文与先前发出的ICMP Echo Request报文就是存在related关系。由于对于ICMP Echo Request报文而言，只有ICMP Echo Reply报文是与它存在reply（rpl）关系的。

inv，即invalid。若是存在下述几种状况：linux内核中L3/L4协议处理程序不可用或者未加载；nf_conntrack_ipv4或nf_conntrack_ipv6模块没有加载；L3/L4协议断定数据包非法；数据包自己报文长度与协议自己不匹配，那么该数据包将被置位inv。例：UDP奇数字节报文，被某型网卡驱动末位padding 0，但未增长IP头部内长度信息，也未增长UDP头部内长度信息，致使该报文在OVS CT中断定inv，最终drop致使通讯与预期不符。

经过查询系统链接跟踪条目，如图4所示，可知协议类型，源IP，目的IP，源端口，目的端口这5项元组共同构成了识别一条链接跟踪的索引。在openstack环境中，会有必定几率存在不一样项目下的VM，使用相同网段的子网IP，且刚好被调度到同一台宿主机。在极其偶然的状况下这两台VM刚好使用一样的协议，一样的源端口去访问同一个目的IP的同一个目的端口。若是不加任何隔离处理必将致使链接跟踪条目的重叠冲突。

zone=value(ct_zone)，很好的处理了这种冲突。zone能够称之为隔离链接跟踪条目的namespace。不一样zone中的链接跟踪条目即便协议类型，源IP，目的IP，源端口，目的端口彻底一致，也不会存在冲突。在Security Group的OVS驱动中，每条链接在提交至CT模块时，zone均被指定为该网络链接所处network在本节点上local vlan tag。（此处network为neutron下的network模型）

安全组相关特性

当一个port不添加任何安全组信息时，只有匹配该port的ARP报文，DHCP报文，和已创建的链接才会被初始化时下发的流表规则放行。固然，关闭port的port_security_enabled属性能够屏蔽anti ARP spoofing和anti DHCP spoofing流表规则的下发。Neutron中的一些特殊类型port，例如DHCP port，gateway port等被认为是security port，天然也是关闭port_security_enabled属性。若是须要在port上容许其余自定义的IP,MAC网络包的流通，也能够经过port的allowed_address_pairs添加相应信息。被添加的IP,MAC会在下发安全组规则时做为可信任的地址信息被填入流表。

当安全组A的一条ingress规则经过remote group id指向了安全组B，那么表明着全部经过安全组B的流量才能匹配这条ingress规则。也即意味着只有绑定了绑定了安全组B的port发出的流量才能匹配这条ingress规则。

OVS安全组流表分析

以“目的IP192.168.0.0/24目标端口22协议TCP出向放行”，“任意IP目标端口80协议TCP入向放行”两条安全组规则为例，分析流量具体通过的流表，以下图5所示。

OVS与iptables对比

不使用OVS状况下，Linux内核的链接跟踪模块仅限于IP协议层（L3）的Linux内核防火墙（iptables）使用。而实际VM流量从tap口流出时已是L2层报文。所以额外添加了一层Linux bridge，配合ebtables，处理原有L2层报文后上送至iptables，从而在iptables中执行链接跟踪，全部Security Group规则也被转换成具体的iptables规则，配合链接状态，实现状态防火墙的功能。通过筛选处理后的报文再经过veth从Linux bridge流向br-int，执行外部交换与路由。

对比OVS与iptables实现的状态防火墙，多一层虚拟网络设备就多一次处理，这里必然致使多一重性能损耗。如图7所示，在Security Group 规则数量庞大的状况下，性能消耗则更加明显。