防火墻是避免網絡信息基礎設施免受復雜網絡環境中安全***的必要設施。高效的防火墻則更需要實時跟蹤來往於不同網絡設備間的各類網絡連接，即“有狀態防火墻”。對於實際的硬件物理網絡基礎設施需要防火墻，對於虛擬網絡設備，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 規則數量龐大的情況下，性能消耗則更加明顯。

2月技術周 | OVS實現安全組，你需要知道這些！