Firewall
Firewall to avoid network information infrastructure from the necessary facilities of a complex network security attacks. Efficient firewall more in need of real-time tracking and from all types of network connections between different network devices, or "stateful firewall." For the actual physical network hardware infrastructure need a firewall for virtual network devices, openstack also need the same firewall in such a cloud platform for network protection.
In Openstack, the firewall from the "Security Group" and "FWaas" the two service components. Security Group which provide access control to the VM network communication port level. And Fwaas vrouter runs on the boundary of the subnets subnet control flow L3 and L4. In short, "Security Group" protect the port, "FWaas" protection subnet.
Under the Openstack "Security Group" not only protects tenants VM, so avoid the influence of worthless data stream, while also limiting the tenant VM, avoid initiate ARP spoofing, DHCP spoofing and other insecure network behavior. The actual location of the bottom, "Security Group" and can be achieved by iptables ovs flow table in two ways. This article will focus on security groups (Security Group) based OVS flow table implementation.
OVS Conntrack Overview
Stateless firewall can only be filtered through the static network tuples, blocking, release data packets. Here tuple comprises a static network IP address, port, network protocol. Stateless firewalls do not care what state the current network connection. Compared to stateless firewalls, stateful firewall adds identification of a current network connection status, using a static network synchronization ancestral data packet filtering, blocking, release. Increased identification of system resources consumed to some extent, but more stringent rules but to better protect network more secure.
Identifying a network connection state is usually achieved by the CT module (connection tracker). In the linux kernel, CT is performed by the conntrack. OVS 2.5 starting from the start to support the conntrack, and reflects the recognition processing associated with the state of CT in openflow. Openstack start from the M version, use the new features of the OVS to achieve "stateful firewall" in the "Security Group" function.
CT function provided from OVS schematic view of 2, with respect to the original process flow table, adds nothing to submit connectionless packet into the CT module, connection state flag, a query for a subsequent flow connection state table, the data packet match specified treatment process.
Figure 3 lists the openflow relevant fields in the new CT OVS achieved. (With deletion, only include fields used when analyzing subsequent flow table)
It is important to explain here rel, inv, zone = value (ct_zone) these three projects.
rel, namely related. Here is an example of a typical description of the related data packets. When a VM A ping external IP address B, issuing a ICMP Echo Request packet, when the Request packet arrives at a router, the router determines the external IP address is not reachable, a loopback ICMP Network Unreachable messages. Then the ICMP Network Unreachable packet with ICMP Echo Request packet is the existence of a previously issued related relationships. Because for ICMP Echo Request packets, only the ICMP Echo Reply message is the presence of reply (rpl) relationship with it.
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 规则数量庞大的情况下，性能消耗则更加明显。
