[[283112]]

1、iptables簡介

1.1 iptables概述

在介紹OpenStack安全組前先簡單介紹下iptables，其實iptables只是一個用戶空間的程序，真正干活的其實是Linux內核netfilter，通過iptables創建新規則，其實就是在netfilter中插入一個hook，從而實現修改數據包、控制數據包流向等，對iptables使用方法不熟悉的可以參考圖文并茂理解iptables[1].

簡單地說，iptables就是通過一系列規則條件匹配執行指定的動作，因此一條規則就是由條件+動作構成，條件比如源IP地址、四層協議、端口等，動作如拒絕、通過、丟棄、修改包等，動作通常通過-j參數指定。

比如拒絕192.168.1.2訪問目標22端口，只需要添加如下iptables規則：

 

如上：

• -t指定表(table)，如果把所有的規則混放在一起肯定會特別亂，因此iptables根據功能劃分為不同的表，過濾包的放在filter表，做NAT的放nat表等，還有raw表、mangle表、security表，共5個表。如果不指定該參數，默認會選中filter表。
• -I表示insert操作，在最前面插入這條規則，相對應的還有-A參數，表示從末尾追加規則，-I、-A還可以在后面指定索引位置，將規則插入到指定的位置。
• INPUT表示鏈名稱，鏈可以看做是一個鏈表，鏈表元素為規則。iptables一共可操縱5條鏈，分別為PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTING。需要注意的是，所有的表都是共享這5條鏈的，當然并不是所有的表都同時需要這5條鏈，比如filter表就沒有PREROUTING、POSTROUTING。如果多個table都在如上鏈上插入了規則，則根據raw -> mangle -> nat -> filter的順序執行。
• -s、-p、--dport都是條件，多個條件是與的關系，即只有滿足指定的所有條件才能匹配該規則，如上-s指定了源地址IP為192.168.1.2，-p指定了協議為TCP，--dport指定了端口22，即只有源地址訪問目標的22 TCP端口才能匹配這條規則。
• -j指定了行為，當然官方的叫法是目標(target)，這里DROP表示丟棄包。

1.2 iptables匹配條件

除了以上的-s、-p、--dport等參數作為匹配條件外，iptables還支持如-d匹配目標IP地址，-i、-o分別指定從哪個網卡進入的以及從哪個網卡出去的。當然這些匹配條件還不夠，甚至都不支持匹配MAC地址。iptables為了滿足不同的需求，通過擴展模塊支持更多的匹配條件，主要分為如下兩類：

• 功能加強型：比如前面的--dport參數只能匹配單個port或者連續的port，如果需要匹配多個不連續的port，則不得不通過添加多條規則實現。mulport擴展模塊允許同時指定多個port，通過逗號分隔。再比如ip-range模塊，支持指定ip地址段。
• 新功能：比如mac模塊支持匹配源MAC地址。time模塊支持通過時間段作為匹配條件，比如實現每天0點到8點不允許外部SSH。

不同的擴展模塊支持不同的參數，比如mac模塊，支持--mac-source參數。

使用擴展模塊必須通過-m參數加載，之前我一直以為-m是--module的縮寫，看iptables的man手冊才發現其實是--match的縮寫，不過我們只需要知道是加載擴展模塊的功能就可以了。

比如我們不允許MAC地址為FA:16:3E:A0:59:BA通過，通過如下規則配置：

 

iptables的擴展模塊非常多，具體可以通過man iptables-extensions命令查看，不過OpenStack安全組用到的并不多:

• comment：給規則添加注釋。
• tcp/udp/icmp：沒錯，這些也屬于擴展模塊，iptables基本模塊中甚至連指定端口的功能都沒有。
• set:匹配ipset，當ip在ipset集合中即滿足條件。
• mac：前面說了，支持匹配MAC地址。
• state: 這個模塊非常有用，舉個簡單的例子，假設服務器A(192.168.0.1)配置的iptables規則為入訪全不通，即INPUT鏈全DROP，出訪全通，即OUTPUT鏈全ACCEPT。另外一臺服務器B(192.168.0.2)和A在同一個二層網絡，則顯然B ping不通A，問題是A能ping通B嗎?有人肯定會說，A既然出訪全是通的，那肯定能ping通B了。事實上，A根本ping不通B，因為A的包有去無回，即A的ICMP包確實能到B，但B的回包卻被A的INPUT DROP了，因此A根本接收不到reply包。那怎么解決呢?把B加到A的白名單列表中顯然破壞了我們原有的初衷。通過state模塊可以完美解決這個問題，指定state為ESTABLISHED能夠匹配已經建立連接的包，注意這里的已建立連接并不是說TCP連接，而是更廣泛的連接含義，比如udp、icmp，簡單理解就是匹配回包。因此解決如上問題只需要添加-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT規則即可。
• physdev: 這個模塊相對內置的-i、-o參數功能更強大。假如我們創建了一個linux bridge br0，br0上掛了很多虛擬網卡tap設備。我們通過-i指定br0則不管從哪個虛擬網卡進來的都會匹配，做不了精確匹配到底是從哪個虛擬網卡進來的。而physdev模塊則非常強大，通過physdev-in參數指定從哪個接口進來的，通過--physdev-out參數指定從哪個接口出去的。

1.3 iptables執行動作

前面提到iptables通過-j指定執行的動作(target)，iptables常見的target如下:

• ACCEPT:接收包，直接放行，不需要在匹配該鏈上的其他規則，注意是該鏈，其他鏈的還是需要匹配的，即只是說明通了一關，后面幾關能不能通過還不好說。
• DROP:直接丟棄包，包都丟了，當然也不需要在匹配其他任何規則了。
• REJECT:拒絕包。這個和DROP有什么區別呢?DROP是直接丟棄包，不做任何響應，客戶端會一直在傻傻地等直到超時。而REJECT會響應拒絕消息，客戶端能收到拒絕包并作出反應，不需要一直盲等。
• LOG:僅僅記錄下日志。

當然還有實現NAT的SNAT、MASQUERADE、DNAT，因為安全組實現涉及不到，因此不做詳細介紹，另外還有RETURN以及指向另一個鏈的動作，等后面介紹了子鏈再討論。

動作通常都是短路的，也就是說一旦匹配規則并執行動作，就不會繼續往后去匹配該鏈的其他規則了，當然這并不是絕對的，比如LOG動作就是例外，執行該動作后會繼續匹配下一條規則。

1.4 iptables鏈

前面提到iptables一共有5條鏈，并且鏈可以認為是一個單向鏈表，問題來了，當接收到一個新包，到底是如何匹配規則的。這里我直接引用圖文并茂理解iptables的圖[1]:

 

(1) 數據包首先到達PREROUTING鏈，然后按照raw、mangle、nat的順序匹配執行定義在PREROUTING的規則。

(2) 接下來經過路由判斷，如果包是發給自己的則流向INPUT鏈，然后由INPUT鏈發給用戶空間進程處理。如果不是發給自己的包，則流向FORWARD表，同樣按照raw -> mangle -> nat -> filter表依次匹配執行鏈上的規則。

(3) 同理，ONPUT鏈、POSTROUTING鏈，包流向方向，直接看圖，非常清晰，這里不再贅述。

前面提到每條鏈上都可以插入規則，需要注意的是這些規則是有順序的，iptables每次匹配時都是從第一條規則開始匹配，依次匹配下一條，一旦匹配其中一條規則，則執行對應的動作。

肯定有人會疑問，如果這條鏈上的規則都不匹配該怎么辦，答案是取決于該鏈的默認策略(policy)。如果該策略是DROP，則最后沒有匹配的包都將丟棄，即該鏈時白名單列表。如果默認策略是ACCEPT，則最后沒有匹配的包都會通過,即該鏈時黑名單列表。當然通常policy都設置為ACCEPT，因為配置為DROP太危險了，比如清空規則立馬就相當于全不通了，如果你通過SSH連接的服務器，則立即中斷連接了，不得不通過vnc或者帶外console連接重置，所以不建議修改policy。

通過如下命令查看filter表各個鏈的默認策略:

 

如果一條鏈規則特別多且復雜，管理起來非常麻煩，因此很有必要對鏈根據功能分組。iptables通過自定義鏈實現。用戶可以通過iptables -N name創建一個新鏈，然后和內置鏈一樣可以往新鏈中添加規則。但是需要注意的是，自定義鏈不能獨立存在，必須掛在內置5條鏈下面，即必須是內置鏈的子鏈。

前面1.3節提了下-j可以指定一條新鏈，這里的新鏈即子鏈，即iptables是通過-j把子鏈掛到某個規則下面。比如創建一個允許SSH訪問的白名單列表，可以創建一個新的子鏈，SSH相關的策略都放在這個新鏈中:

 

以上第二條命令表示將所有訪問本機端口22的包都放到SSH_Access_List這條子鏈上處理，然后這條子鏈上添加了許多白名單規則，由于進到這個子鏈的一定是目標22端口的，因此規則無需要在指定--dport參數，最后一個DROP表示不在白名單列表中的包直接丟掉。

需要注意的是白名單規則中的動作不是ACCEPT而是RETURN，這兩者有什么區別呢?ACCEPT表示允許包直接通過INPUT，不需要再匹配INPUT的其他規則。而RETURN則表示只是不需要再匹配該子鏈下的后面規則，但需要返回到該子鏈的母鏈的規則或者子鏈繼續匹配，能不能通過INPUT關卡取決于后面的規則。

另外需要注意的是，前面提到內置的5條鏈可以配置policy，當所有規則都不匹配時，使用policy對包進行處置。但是，自定義鏈是不支持policy的，更確切的說，不支持設置policy，因為自定義鏈的policy只能是RETURN，即如果子鏈的規則都不匹配，則一定會返回到母鏈中繼續匹配。

1.5 iptables總結

本小節簡單介紹了iptables的功能和用法，總結如下：

1、iptables通過規則匹配決定包的去向，規則由匹配條件+動作構成，規則通過-I、-A插入。

2、五鏈五表，五鏈為PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTING，五表為raw、mangle、nat、filter、security。鏈、表、規則都是有順序的。

3、當鏈中的所有規則都不匹配時，iptables會根據鏈設置的默認策略policy處理包，通過policy設置為ACCEPT，不建議配置為DROP。

4、可以創建子鏈掛在內置鏈中，子鏈的policy為RETURN，不支持配置。

5、匹配條件包括基本匹配條件以及擴展模塊提供的擴展匹配條件，擴展匹配條件通過-m參數加載，需要記住的擴展模塊為comment、tcp、udp、icmp、mac、state、physdev、set。

6、常見的iptables動作(target)為ACCEPT、DROP、RETURN、LOG以及跳轉到子鏈。

2、OpenStack安全組簡介

2.1 Neutron安全組 VS Nova安全組

OpenStack安全組最開始是通過Nova管理及配置的，引入Neutron后，新OpenStack安全組則是通過Neutron管理，并且關聯的對象也不是虛擬機，而是port。我們在頁面上把虛擬機加到某個安全組，其實是把虛擬機的port關聯到安全組中。

由于歷史的原因，可能還有些版本的Nova依然保留著對安全組規則的操作API，不過不建議使用，建議通過Neutron進行安全組規則管理。

2.2 security group VS firewall

很多剛開始接觸OpenStack的用戶分不清楚安全組(security group)和防火墻(firewall)的區別，因為二者都是做網絡訪問控制的，并且社區都是基于iptables實現的。其實二者的區別還是比較大的:

• security group主要是做主機防護的，換句話說安全組是和虛擬機的port相關聯，安全組是針對每一個port做網絡訪問控制，所以它更像是一個主機防火墻。而firewall是針對一個VPC網絡的，它針對的是整個VPC的網絡控制，通常是在路由做策略。因此security group在計算節點的tap設備上做，而firewall在網絡節點的router上做。
• 相對于傳統網絡模型，security group其實就是類似于操作系統內部自己配置的防火墻，而firewall則是旁掛在路由器用于控制整個局域網網絡流量的防火墻。
• security group定義的是允許通過的規則集合，即規則的動作就是ACCEPT。換句話說定義的是白名單規則，因此如果虛擬機關聯的是一個空規則安全組，則虛擬機既出不去也進不來。并且由于都是白名單規則，因此安全組規則順序是無所謂的，而且一個虛擬機port可以同時關聯多個安全組，此時相當于規則集合的并集。而firewall規則是有動作的(allow,deny,reject)，由于規則既可以是ACCEPT，也可以是DROP，因此先后順序則非常重要，一個包的命運，不僅取決于規則，還取決于規則的優先級順序。
• 前面說到security group針對的是虛擬機port，因為虛擬機的IP是已知條件，定義規則時不需要指定虛擬機IP，比如定義入訪規則時，只需要定義源IP、目標端口、協議，不需要定義目標IP。而防火墻針對的是整個二層網絡，一個二層網絡肯定會有很多虛擬機，因此規則需要同時定義源IP、源端口、目標IP、目標端口、協議。之前有人問我一個問題，多個虛擬機關聯到了一個安全組，想針對這幾個虛擬機做網絡訪問控制，源IP是192.168.4.5，但我只想開通到兩個虛擬機的80端口訪問，問我怎么做?我說實現不了，因為關聯在同一個安全組的虛擬機網絡訪問策略是必須是一樣的，你沒法指定目標IP，如果虛擬機有不同的訪問需求，只能通過關聯不同的安全組實現。
• security group通常用于實現東西向流量控制實現微分段策略，而firewall則通常用于實現南北向流量控制。

2.3 安全組用法介紹

前面介紹了安全組，安全組其實就是一個集合，需要把安全組規則放到這個集合才有意義。

Neutron通過security-group-create子命令創建安全組，參數只有一個name，即安全組名稱:

 

不過Neutron創建的新安全組并不是一個空規則安全組，而是會自動添加兩條默認規則:

 

即禁止所有的流量訪問，允許所有的流量出去。

創建了安全組后，就可以往安全組里面加規則了。Neutron通過security-group-rule-create子命令創建，涉及的參數如下：

• --direction: 該規則是出訪(egress)還是入訪(ingress)。
• --ethertype: 以太網類型，ipv4或者ipv6。
• --protocol: 協議類型，tcp/udp/icmp等。不指定該參數則表示任意協議。
• --port-range-min、--port-range-max端口范圍，如果只有一個端口，則兩個參數填一樣即可，端口范圍為1~65535。
• --remote-ip-prefix，如果是入訪則指的是源IP地址段，如果是出訪則指的是目標IP段，通過CIDR格式定義，如果只指定一個IP，通過x.x.x.x/32指定，如果是任意IP，則通過0.0.0.0/0指定。
• --remote-group-id: 除了通過ip段指定規則，OpenStack還支持通過安全組作為匹配條件，比如允許關聯了xyz安全組的所有虛擬機訪問22端口。

創建一條安全組規則，只允許192.168.4.5訪問虛擬機SSH 22端口：

 

需要注意的是創建安全組和安全組規則只是一個邏輯操作，并不會創建任何iptables規則，只有當安全組被關聯到port時才會真正創建對應的iptables規則。

關聯安全組通過Neutron的port-update命令，比如要把虛擬機uuid為38147993-08f3-4798-a9ab-380805776a40添加到該安全組:

 

安全組命令操作參數較多，相對復雜，可以通過Dashboard圖形界面操作，如圖：

 

具體操作這里不多介紹。

3、安全組實現原理分析

3.1 虛擬機網絡流向路徑

Linux網絡虛擬化支持linux bridge以及openvswitch(簡稱OVS)，OpenStack Neutron ml2驅動二者都支持，目前大多數使用的是OVS。

不過早期的iptables不支持OVS bridge以及port，因此為了實現安全組，虛擬機的tap設備并不是直接連接到OVS bridge上，而是中間加了一個Linux bridge，通過veth pair連接Linux bridge以及OVS bridege，這樣就可以在Linux bridge上添加iptables規則實現安全組功能了。

目前大多數的OpenStack環境還遵循如上規則，簡化的虛擬機流量路徑如下：

 

其中X、Y、Z為虛擬機port UUID前11位。

3.2 安全組規則掛在iptables哪條鏈?

根據前面的基礎，不難猜出安全組的iptables規則肯定是在filter表實現的，filter表只涉及INPUT、FORWARD、OUTPUT三條鏈，iptables規則流向圖可以簡化為：

 

做過主機防火墻的可能第一直覺會認為安全組規則會掛在INPUT以及OUTPUT鏈上，但根據上面的流程圖，如果包不是發給自己的，根本到不了INPUT以及OUTPUT，因此顯然在INPUT、OUTPUT根本實現不了安全組規則，因此安全組的iptables規則肯定是在FORWARD鏈上實現的，也就是說計算節點不處理虛擬機的包(發給自己的包除外)，只負責轉發包。

3.3 安全組規則定義

為了便于后面的測試，我提前創建了一臺虛擬機int32bit-server-1，IP為192.168.100.10/24，port UUID為3b90700f-1b33-4495-9d64-b41d7dceebd5，并添加到了之前創建的int32bit-test-secgroup-1安全組。

我們先導出本計算節點的所有tap設備對應Neutron的port，該腳本在github int32bit/OpenStack_Scripts可以下載:

 

根據前面的分析，虛擬機安全組是定義在filter表的FORWARD鏈上的，我們查看該鏈的規則:

 

FORWARD鏈先跳到neutron-filter-top子鏈上，neutron-filter-top鏈會又跳到neutron-openvswi-local，而neutron-openvswi-local鏈是空鏈，因此會返回到母鏈FORWARD上，因此這里第一條規則其實沒啥用。

返回到FORWARD鏈后繼續匹配第2條規則，跳轉到了neutron-openvswi-FORWARD，我們查看該鏈的規則:

 

該鏈上一共有4條規則，第1、2臺規則對應的tap設備分別為dhcp以及router_interface端口，即允許DHCP以及網關的port通過。

而tap3b90700f-1b顯然是虛擬機port對應的tap設備(名稱為tap+portUUID前11位)，第3、4規則表明無論是從這個tap設備進的還是出的包都進入子鏈neutron-openvswi-sg-chain處理。

我們繼續查看neutron-openvswi-sg-chain查看鏈:

 

從規則我們可以看出：

• --physdev-out表示從tap3b90700f-1b出來發往虛擬機的包，通過子鏈neutron-openvswi-i3b90700f-1處理，即虛擬機入訪流量。
• --physdev-in表示從虛擬機出來進入tap3b90700f-1b的包，通過子鏈neutron-openvswi-o3b90700f-1處理，即虛擬機出訪流量。

顯然neutron-openvswi-i3b90700f-1和neutron-openvswi-o3b90700f-1分別對應安全組的入訪規則和出訪規則，即虛擬機的入訪規則鏈為neutron-openvswi-i + port前綴，虛擬機的出訪規則鏈為neutron-openvswi-i + port前綴。

3.4 安全組入訪規則

由3.3我們了解到，安全組入訪規則鏈為neutron-openvswi-i3b90700f-1，我們查看該鏈規則:

 

一共有6條規則：

• 第1條規則我們在前面已經介紹過，應該很熟悉了，主要用于放行回包。
• 第2、3條規則主要用于放行dhcp廣播包。
• 第4條即我們前面添加的安全組規則。
• 第5條規則丟棄無用包。
• 第6條用來處理所有規則都不匹配的包，跳轉到neutron-openvswi-sg-fallback鏈，而該鏈其實只有一條規則，即DROP ALL。因此不匹配安全組規則的包都會直接丟棄。

安全組入訪規則中第1、2、3、5、6都是固定的，當有新的安全組策略時就往第4條規則后面追加。

3.5 安全組出訪規則

由3.3我們了解到，安全組入訪規則鏈為neutron-openvswi-o3b90700f-1，我們查看該鏈規則:

 

一共有8條規則:

• 第1、3條規則用于放行虛擬機DHCP client廣播包。
• 第2條規則，放到第4章再介紹。
• 第4條規則用于阻止DHCP欺騙，避免用戶在虛擬機內部自己啟一個DHCP Server影響Neutron的DHCP Server。
• 第5條規則不再解釋。
• 第6條規則是我們的安全組規則，因為我們的安全組出訪是ANY，因此所有包都放行。
• 第7條規則丟棄無用包。
• 第8條規則用來處理所有規則都不匹配的包，跳轉到neutron-openvswi-sg-fallback鏈，而該鏈其實只有一條規則，即DROP ALL。因此不匹配安全組規則的包都會直接丟棄。

3.6 安全組使用安全組作為匹配條件

前面2.3節提到，安全組不僅支持通過IP地址段作為源或者目標的匹配條件，還支持通過指定另一個安全組，這種情況怎么處理呢。

為了測試我把創建了一個新的安全組int32bit-test-secgroup-2以及新的虛擬機int32bit-server-2(192.168.100.7)，并且int32bit-server-2關聯了安全組int32bit-test-secgroup-2。

同時在int32bit-test-secgroup-1上增加一條入訪規則，允許關聯int32bit-test-secgroup-2的虛擬機訪問8080端口:

 

我們查看虛擬機入訪規則鏈neutron-openvswi-i3b90700f-1:

 

我們發現插入了一條新的規則，編號為4。該規則使用了set擴展模塊，前面介紹過set是用來匹配ipset的，后面的參數NIPv4fc83d82a-5b5d-4c90-80b0-為ipset名，顯然是由NIPv4+安全組UUID前綴組成。

我們查看該ipset：

 

可見192.168.100.7在ipset集合中。

因此OpenStack安全組使用安全組作為匹配條件時是通過ipset實現的，每個安全組會對應創建一個ipset集合，關聯的虛擬機IP會放到這個集合中，iptables通過ipset匹配實現了安全組匹配功能。

4、安全組anti snoop功能

前面3.5節提到第2條規則，所有的包都會先進入neutron-openvswi-s3b90700f-1子鏈處理，這個鏈是干什么的呢?

我們首先查看下里面的規則:

 

這條鏈的處理邏輯很簡單，只放行IP是192.168.100.10并且MAC地址是FA:16:3E:A0:59:BA的包通過。這其實是Neutron默認開啟的反欺騙anti snoop功能，只有IP和MAC地址匹配Neutron port分配的才能通過。換句話說，你起了個虛擬機IP為192.168.3.1，然后自己手動把網卡的IP篡改為192.168.3.2，肯定是不允許通過的。

但是呢，我們業務又往往有virtual ip的需求，最常見的如haproxy、pacemaker的vip。OpenStack考慮了這種需求，支持用戶添加白名單列表，通過port的allowed address pairs配置。

比如我有兩個虛擬機，IP分別為192.168.0.10、192.168.0.11，申請了一個port 192.168.0.100作為這個兩個虛擬機的vip，可以通過Neutron更新port信息實現:

 

添加后我們再查看下neutron-openvswi-s3b90700f-1鏈規則:

 

可見在最前面添加了一條規則允許IP為192.168.0.100的包通過，此時在虛擬機192.168.0.10上把IP改為192.168.0.100也可以ping通了。

5、虛擬機訪問宿主機怎么辦?

我們已經知道，安全組是在filter表的FORWARD鏈上實現的，但如果虛擬機的包是去往宿主機時，由于內核判斷目標地址就是自己，因此不會流到FORWARD鏈而是發往INPUT鏈，那這樣豈不就是繞過安全組規則了嗎?

 

解決辦法很簡單，只需要把neutron-openvswi-o3b90700f-1再掛到INPUT鏈就可以了。

我們查看INPUT鏈規則:

 

即:

 

有人可能會問，那宿主機發往虛擬機的包會出現問題嗎?需要在OUTPUT鏈上添加規則嗎?答案是不需要，因為從OUTPUT直接出去，當作正常流程走就可以了。

6、總結

本文首先簡單介紹了下iptables，然后介紹OpenStack安全組，最后詳細分析了安全組的實現原理。

另外寫了一個腳本可以快速導出虛擬機的iptables規則，需要在計算節點上運行:

 付廣平，任職某銀行云技術管理中心，負責云計算相關技術研究。畢業于北京郵電大學，從2013開始從事OpenStack相關工作，參與了OpenStack Nova、Cinder、Oslo等項目社區開發。