防火墻

防火墻是避免網(wǎng)絡(luò)信息基礎(chǔ)設(shè)施免受復(fù)雜網(wǎng)絡(luò)環(huán)境中安全攻擊的必要設(shè)施仓洼。高效的防火墻則更需要實(shí)時(shí)跟蹤來往于不同網(wǎng)絡(luò)設(shè)備間的各類網(wǎng)絡(luò)連接介陶，即“有狀態(tài)防火墻”。對(duì)于實(shí)際的硬件物理網(wǎng)絡(luò)基礎(chǔ)設(shè)施需要防火墻色建，對(duì)于虛擬網(wǎng)絡(luò)設(shè)備哺呜，openstack在這樣的云平臺(tái)亦需要同樣的防火墻進(jìn)行網(wǎng)絡(luò)保護(hù)。

在Openstack中箕戳，防火墻由“Security Group”和“FWaas”兩大服務(wù)組成某残。其中Security Group在port級(jí)別提供對(duì)VM網(wǎng)絡(luò)通信的訪問控制国撵。而Fwaas則運(yùn)行在vrouter上在subnet的邊界控制子網(wǎng)間的L3和L4流量。簡(jiǎn)而言之玻墅，“Security Group”保護(hù)port介牙，“FWaas”保護(hù)subnet。

圖1

Openstack下的“Security Group”不僅保護(hù)租戶VM澳厢，使其避免受到無價(jià)值數(shù)據(jù)流的影響环础，同時(shí)還限制租戶VM，避免其主動(dòng)發(fā)起ARP spoofing剩拢，DHCP spoofing等不安全網(wǎng)絡(luò)行為线得。實(shí)際定位到底層，“Security Group”可以通過iptables和ovs 流表兩種方式實(shí)現(xiàn)徐伐。本文將重點(diǎn)講述基于OVS 流表實(shí)現(xiàn)的安全組（Security Group）贯钩。

以下內(nèi)容基于Pike版Openstack

OVS Conntrack 概述

無狀態(tài)的防火墻只能通過靜態(tài)的網(wǎng)絡(luò)元組來過濾，阻攔呵晨，放行數(shù)據(jù)報(bào)文魏保。這里的靜態(tài)網(wǎng)絡(luò)元組包括IP地址，端口摸屠，網(wǎng)絡(luò)協(xié)議谓罗。無狀態(tài)防火墻并不關(guān)心當(dāng)前網(wǎng)絡(luò)連接處于何種狀態(tài)。相較于無狀態(tài)防火墻季二，有狀態(tài)防火墻增加了對(duì)當(dāng)前網(wǎng)絡(luò)連接狀態(tài)的識(shí)別檩咱，同步使用靜態(tài)的網(wǎng)絡(luò)元祖對(duì)數(shù)據(jù)報(bào)文進(jìn)行過濾，阻攔胯舷，放行刻蚯。增加的識(shí)別標(biāo)志在一定程度上消耗系統(tǒng)資源，但更加嚴(yán)格的規(guī)則卻更能保障網(wǎng)絡(luò)更加安全桑嘶。

網(wǎng)絡(luò)連接狀態(tài)的識(shí)別通常是由CT模塊（connection tracker）實(shí)現(xiàn)的炊汹。在linux內(nèi)核中，CT是由conntrack實(shí)現(xiàn)逃顶。從OVS 2.5起讨便，開始支持conntrack，并在openflow中體現(xiàn)相關(guān)CT狀態(tài)的識(shí)別與處理以政。Openstack則從M版開始霸褒，使用OVS的新特性，來實(shí)現(xiàn)“有狀態(tài)防火墻”中的“Security Group”功能盈蛮。

從OVS提供的CT功能簡(jiǎn)圖2來看废菱，相對(duì)于原有流表處理，無非增加了提交連接數(shù)據(jù)包進(jìn)入CT模塊，標(biāo)記連接狀態(tài)殊轴，用于后續(xù)流表查詢連接狀態(tài)衰倦，匹配數(shù)據(jù)報(bào)文進(jìn)行指定處理的過程。

圖2

圖3列舉了OVS實(shí)現(xiàn)的openflow 中新增的CT相關(guān)字段梳凛。（有刪減耿币，僅列舉了后續(xù)流表分析時(shí)用到的字段）

圖3

這里需要重點(diǎn)解釋下rel，inv韧拒，zone=value（ct_zone）這三條項(xiàng)目淹接。

rel，即related叛溢。這里舉個(gè)典型的例子描述下related數(shù)據(jù)包塑悼。當(dāng)VM A ping 某外網(wǎng)IP地址B，發(fā)出一個(gè)ICMP Echo Request報(bào)文楷掉，當(dāng)該Request報(bào)文到達(dá)路由器時(shí)厢蒜，路由器判定外網(wǎng)IP地址不可達(dá)，回送一個(gè)ICMP Network Unreachable報(bào)文烹植。那么這個(gè)ICMP Network Unreachable報(bào)文與先前發(fā)出的ICMP Echo Request報(bào)文就是存在related關(guān)系斑鸦。因?yàn)閷?duì)于ICMP Echo Request報(bào)文而言，只有ICMP Echo Reply報(bào)文是與它存在reply（rpl）關(guān)系的草雕。

inv巷屿，即invalid。如果存在下述幾種情況：linux內(nèi)核中L3/L4協(xié)議處理程序不可用或者未加載墩虹；nf_conntrack_ipv4或nf_conntrack_ipv6模塊沒有加載嘱巾；L3/L4協(xié)議判定數(shù)據(jù)包非法；數(shù)據(jù)包本身報(bào)文長(zhǎng)度與協(xié)議本身不匹配诫钓，那么該數(shù)據(jù)包將被置位inv旬昭。例：UDP奇數(shù)字節(jié)報(bào)文，被某型網(wǎng)卡驅(qū)動(dòng)末位padding 0菌湃，但未增加IP頭部?jī)?nèi)長(zhǎng)度信息问拘，也未增加UDP頭部?jī)?nèi)長(zhǎng)度信息，導(dǎo)致該報(bào)文在OVS CT中判定inv惧所，最終drop導(dǎo)致通信與預(yù)期不符场梆。

通過查詢系統(tǒng)連接跟蹤條目，如圖4所示纯路，可知協(xié)議類型，源IP寞忿，目的IP驰唬，源端口，目的端口這5項(xiàng)元組共同構(gòu)成了識(shí)別一條連接跟蹤的索引。在openstack環(huán)境中叫编，會(huì)有一定概率存在不同項(xiàng)目下的VM辖佣，使用相同網(wǎng)段的子網(wǎng)IP，且恰好被調(diào)度到同一臺(tái)宿主機(jī)搓逾。在極其偶然的情況下這兩臺(tái)VM恰好使用同樣的協(xié)議卷谈，同樣的源端口去訪問同一個(gè)目的IP的同一個(gè)目的端口。如果不加任何隔離處理必將導(dǎo)致連接跟蹤條目的重疊沖突霞篡。

圖4

zone=value(ct_zone)世蔗，很好的處理了這種沖突。zone可以稱之為隔離連接跟蹤條目的namespace朗兵。不同zone中的連接跟蹤條目即使協(xié)議類型污淋，源IP，目的IP余掖，源端口寸爆，目的端口完全一致，也不會(huì)存在沖突盐欺。在Security Group的OVS驅(qū)動(dòng)中赁豆，每條連接在提交至CT模塊時(shí)，zone均被指定為該網(wǎng)絡(luò)連接所處network在本節(jié)點(diǎn)上local vlan tag冗美。（此處network為neutron下的network模型）

安全組相關(guān)特性

當(dāng)一個(gè)port不添加任何安全組信息時(shí)魔种，只有匹配該port的ARP報(bào)文，DHCP報(bào)文墩衙，和已建立的連接才會(huì)被初始化時(shí)下發(fā)的流表規(guī)則放行务嫡。當(dāng)然，關(guān)閉port的port_security_enabled屬性可以屏蔽anti ARP spoofing和anti DHCP spoofing流表規(guī)則的下發(fā)漆改。Neutron中的一些特殊類型port心铃，例如DHCP port，gateway port等被認(rèn)為是security port挫剑，自然也是關(guān)閉port_security_enabled屬性去扣。如果需要在port上允許其他自定義的IP,MAC網(wǎng)絡(luò)包的流通，也可以通過port的allowed_address_pairs添加相應(yīng)信息樊破。被添加的IP,MAC會(huì)在下發(fā)安全組規(guī)則時(shí)作為可信任的地址信息被填入流表愉棱。

當(dāng)安全組A的一條ingress規(guī)則通過remote group id指向了安全組B，那么代表著所有通過安全組B的流量才能匹配這條ingress規(guī)則哲戚。也即意味著只有綁定了綁定了安全組B的port發(fā)出的流量才能匹配這條ingress規(guī)則奔滑。

OVS安全組流表分析

以“目的IP192.168.0.0/24目標(biāo)端口22協(xié)議TCP出向放行”，“任意IP目標(biāo)端口80協(xié)議TCP入向放行”兩條安全組規(guī)則為例顺少，分析流量具體經(jīng)過的流表朋其，如下圖5所示王浴。

圖5

OVS與iptables對(duì)比

不使用OVS情況下，Linux內(nèi)核的連接跟蹤模塊僅限于IP協(xié)議層（L3）的Linux內(nèi)核防火墻（iptables）使用梅猿。而實(shí)際VM流量從tap口流出時(shí)已經(jīng)是L2層報(bào)文氓辣。因此額外添加了一層Linux bridge，配合ebtables袱蚓，處理原有L2層報(bào)文后上送至iptables钞啸，從而在iptables中執(zhí)行連接跟蹤，所有Security Group規(guī)則也被轉(zhuǎn)換成具體的iptables規(guī)則喇潘，配合連接狀態(tài)体斩，實(shí)現(xiàn)狀態(tài)防火墻的功能。經(jīng)過篩選處理后的報(bào)文再通過veth從Linux bridge流向br-int响蓉，執(zhí)行外部交換與路由硕勿。

圖6

對(duì)比OVS與iptables實(shí)現(xiàn)的狀態(tài)防火墻，多一層虛擬網(wǎng)絡(luò)設(shè)備就多一次處理枫甲，這里必然導(dǎo)致多一重性能損耗源武。如圖7所示，在Security Group 規(guī)則數(shù)量龐大的情況下想幻，性能消耗則更加明顯粱栖。

圖7

參考鏈接

1.http://www.openvswitch.org/support/dist-docs/ovs-ofctl.8.txt
2.http://www.openvswitch.org//support/dist-docs/ovs-fields.7.txt
3.http://docs.openvswitch.org/en/latest/tutorials/ovs-conntrack/
4.https://redhatstackblog.redhat.com/2016/07/22/how-connection-tracking-in-open-vswitch-helps-openstack-performance/
5.http://www.openvswitch.org/support/ovscon2014/17/1030-conntrack_nat.pdf
6. https://docs.openstack.org/neutron/pike/contributor/internals/openvswitch_firewall.html
7. https://zhuanlan.zhihu.com/p/25089778