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 規則數量龐大的狀況下，性能消耗則更加明顯。