Openstack Neutron ： 安全
| 目錄 |
| ????- iptable：起源 ????????- tables ????????- chains ????????- rules ????????- 方向 ????- Security group 安全組： ????- Firewall 防火墻： - 更高的安全 ????- 無處安放的安全 ????- 公共安全 |
?
當業務從傳統環境遷移到云上之后，安全問題變得更為復雜了。Neutron包含了2大安全組件：安全組（security group）、防火墻（firewall）。安全組解決的是虛擬機東西向的訪問控制問題，而防火墻解決的則是南北向的訪問控制問題。
?
兩者都只解決了網絡層和傳輸層的訪問控制，更高層級的安全功能，則留待更為專業的安全廠商解決，如：Palo Alto、Checkpoint、F5 等等。在這一點上 Openstack 和 VMware 等各個云平臺的做法可以說是非常的一致。各個傳統的安全廠家也紛紛轉型推出云上的安全解決方案。
?
iptable：起源
安全組、防火墻的功能都依賴于iptables實現。Iptables 很早就已經集成到了Linux 的內核中，它由轉發表 和 規則鏈 組成，通過表和鏈的組合，能適應各種場景下的安全需求功能。
tables
iprable默認包含了表，每個表都有不同的用途，比如 Filter 表用來過濾數據包，發往主機內部的包，和發往主機外部的包都由 filter 表中相應規則鏈來處理。主機中默認的表有：
- Raw：數據包最先經過的表，一般用來配置需要繞過iptable處理的流量。在安全組和防火墻功能中都沒有使用到該表。
- Filter ：默認用于過濾數據包的表。neutron安全組和防火墻都是通過該表的不同鏈來實現的。
- NAT：看名字就知道，用于網絡地址轉換。
- Mangle： 可以修改數據包的特定字段，常用來標記流量（如用來實現策略路由功能），也沒有被安全組或防火墻使用。
?
?
?
?
http://cn.linux.vbird.org/linux_server/0250simple_firewall.php
查看filter表內的轉發規則
?
chains
鏈這個概念指的是一組規則，這些規則會在不同的場景下生效。默認有5種規則鏈，規則鏈內部的規則詳細地定義了數據包的處理方式（轉發或丟棄等等）。一旦開啟iptables后，所有進出接口的數據包都需要經過至少一條規則鏈。規則允許數據包從一個規則鏈跳轉到另一條規則鏈。如果跳轉后沒有匹配上任何規則，數據包將回到跳轉之前的位置，并繼續向下匹配規則。
- Prerouting：跟名字一樣，在數據包執行路由的策略之前會進入該規則鏈。除了Filter以外，其他表都有用到該策略鏈。比如NAT，在數據包路由之前修改數據包的源地址或目的地址。
- Input：所有發往本地主機的數據包（即目的地址是本地的地址）都會經該規則鏈處理。Mangle 和 Filter 中都有用到。
- Forward：所有目的地址非本機的數據包都用到該規則鏈。Mangle 和 Filter都有用到。
- Output：由本地主機發往外部的數據包都使用該規則鏈。Raw、Filter、NAT、Mangle都有用到。
- Postrouting：所有完成了路由選擇的數據包都將通過該規則鏈。安全組的功能沒有使用到這個規則鏈，但浮動ip則有使用。Mangle和NAT表有使用。
?
Chain 的應用流程可以用上圖來囊括，所有進入主機的數據包都要先經過prerouting鏈，raw、mangle、nat表中都有prerouting鏈，所以數據包要依次匹配 raw——>mangle——>nat 三個表中prerouting鏈的規則。隨后主機將進行路由選擇，如果是數據包的目的是主機自己，那么接下來則由input 鏈來處理，此時是數據包是經過 mangle——>filter表的，然后數據包被拆包并發往本地的進程。
而從本地發出的流量，經過路由選擇后進入output鏈，分別經過raw—mangle—nat—filter表后交給postrouting。
如果數據不是發往本地的，則是經過prerouting，forward，postrouting3個規則鏈。
?
rules
可以看到表格內的規則被組織成不同的鏈，默認的規則鏈會在不同的場景下生效，一個規則鏈內通常包含多條規則，規則的語法與我們常用的ACL語法類似，同樣是對數據包頭的字段進行匹配，包括常用的數據包的5元組：
- 協議< -p protocol>：需要匹配的數據包的協議，例如ICMP、TCP、UDP等
- 源地址< -s source ip address>：數據包頭的源地址
- 目的地址<-d destination ip address>：包頭的目的地址
- 源端口< -sport source port>：包頭的源端口
- 目的端口<-dport? destination port>：包頭的目的端口
- 入接口<-i interface>：數據包進入主機的接口（需要在input鏈中使用）
- 出接口<-o interface>：數據包出主機的接口（注意，當使用該項來匹配數據包時，只有在主機執行了路由選擇之后的output鏈中才能生效，表 raw、mangle、output、filter中都有）
- （除此之外還可以通過各種插件來匹配更多的字段）
?
安全Rule匹配和動作示例
而一旦規則中的條件匹配到數據包后，數據包就會執行規則配置的動作。每個規則支持的動作包括：
- Accept ：接受
- Drop：丟棄
- Reject：丟棄。與drop不同的是，reject會向數據包的源地址返回一個錯誤信息
- Log ：記錄數據包的細節信息
- DNAT：重寫數據包的目的地址
- SNAT：重寫數據包的源地址
- RETURN：將數據包返回給跳轉前的規則
有經驗的人一眼就能看出 accept、drop、reject、log這些不都是一般防火墻上常見的操作么，是的，防火墻主要用的Filter表中的規則主要就是記錄的數據包的丟棄、轉發等操作。
?
方向
Neutron正是應用了iptable不同的表和鏈實現了安全組和防火墻的功能。
?
?
這樣配置規則時就很清晰了，當要對發往本地主機內部的流量進行控制時，則需要在filter表 的input 鏈內設置訪問控制規則。
而當主機作為路由器，在不同的網段之間進行數據轉發時，則需要在filter表的forward鏈內設置訪問控制規則。
這樣就清晰了，無論是經由主機轉發（充當路由器）、或者是發往本主機、以及本主機發出去的流量，都有特定的表和規則鏈進行處理。而且iptable是支持狀態的，即由內部向外部發起的會話而產生的回包，防火墻是能記錄并放行的。也正是借用了iptable的功能Neutron才得以實現NAT、浮動IP、安全組、防火墻等等的功能，可以說iptables占據了Neutron的半壁江山。
?
更多iptables的介紹可以參考鳥哥的 http://cn.linux.vbird.org/linux_server/0250simple_firewall.php
?
Security group 安全組：
安全組的核心就是上面提到iptables了。而且因為安全組是直接關聯的虛擬機的端口，所有進出虛擬機網卡的流量都要經過iptables處理。這樣vpc內部虛擬機與虛擬機之間東西向的流量也能通過安全組管理起來，所以安全組也已經成了所有云服務的標配了。
?
?
而一個安全組指的是采用同一套訪問控制規則的一個或多個虛擬機。這些虛擬機都向外提供相同的服務，訪問群體也相同，例如：一組向外提供web服務的虛擬機，同樣開放80端口，允許其他網段的訪問。用戶配置的安全組策略，最終會通過neutron自動映射到虛擬機所在的計算節點內的 iptables 規則上。
?
?
因為安全組是直接關聯的虛擬機接口，所以的當虛擬機在集群中遷移時，通過安全組配置的規則也會隨之遷移到新的宿主機。
?
?
?
安全組策略的創建
?
在之前講二層的博客中有提到，正因為通過 iptables 實現的安全組需要經過主機的ip協議棧，而ovs的流表轉發模式不支持，而且ovs流表不支持記錄連接狀態，所以類似NAT、狀態防火墻等功能均無法實現，導致ovs的二層環境下要在ovs和虛擬機之間額外添加一個Linuxbridge 來實現安全組的功能。
但是ovs還是有一個原生的防火墻驅動，通過流表而不是 iptable 的方式來實現安全組的功能。這要求宿主的 linux 系統內核版本為 4.3及更高，并支持conntrack。也就是使用conntrack來記錄會話的狀態信息，以實現狀態防火墻功能。但是該實現方式在實現環境中使用得較少。
可通過修改ovs節點上 openvswitch_agent.ini 文件中的以下參數來開啟。
[securitygroup]
firewall_driver = openvswitch
開啟后對于用戶來說沒有明顯的不同，neutron提供的是與 iptables 相同的API。但是實現方式已經從iptables/netfilter 換成了ovs流表。虛擬機發出的包依舊由 br-int進行處理，但是全部會由conntrack來記錄會話的狀態。
?
Firewall 防火墻：
Neutron中的防火墻和安全組一樣，是通過iptables系列工具來實現的。不同的是防火墻與虛擬路由器關聯，所有流經路由器的流量都會經過防火墻的過濾。包括南北向流量和用戶不同vpc之間的流量。
?
防火墻規則也同樣支持網絡的五元組。
firewall-rule-create [--tenant-id 租戶] [--name 名稱] [--description 描述] [--shared] [--source-ip-address 源地址] [--destination-ip-address 目的地址] [--source-port 源端口] [--destination-port 目的端口] [--enabled 是否啟用該規則] --protocol {tcp,udp,icmp,any 協議} --action {allow,deny 動作}
?
?
防火墻策略的創建
?
跟負載均衡一樣，防火墻在 openstack 的 Newton 版本中也迎來了 FWaaS v2。在v2 中防火墻的概念變成了防火墻組。防火墻組由入策略和出策略組成。并且不是再是在整個路由器級別生效，而是可以將防火墻關聯到特定的路由器端口。這樣可以對不同的接口（子網）設置不同的防火墻規則，使用起來更加方便。官方對比圖如下：
?
相比 LBaaS v2帶來的巨大變化，FWaaS v2只能算得上是一次功能的優化，使得防火墻能夠為每個子網提供更細粒度的訪問控制。后續二層的防火墻的更新也會給防火墻帶來更強的生命力，整體算是一次不大不小的進步。
?
更高的安全
無處安放的安全
openstack和能為用戶提供的安全特性非常有限，僅能實現基礎的訪問控制，這肯定不夠，所以這到了傳統安全企業的發揮空間。所以在討論云上的安全時，更多的應該討論安全企業們在云上的解決方案。水平有限不再展開，不過還是有幾個有意思的變化值得梳理一下：
首先就是云供應商和安全企業的關系：
無論是原來的網絡供應商還是服務器供應商、亦或是軟件供應商，安全的供應商都很少跟他們有過交集，大家相安無事好多年，各自歲月靜好。較為松散的業務結構，使得各種設備能夠很好地塞到用戶的數據中心，但是這種情況已經完全被打破，云已經吞噬掉用戶的網絡、服務器、存儲、管理平臺等占據了數據中心的核心位置，所有其他數據容災、備份、網絡管理、網絡安全、業務安全廠商突然發現自己與用戶之間多了一層隔膜。至于大的云供應商在努力向客戶證明自己的一體化方案已經足夠完善，同時也支持第三方的服務。當然這種支持從來就是有限度的，出于利益的角度，或者出于控制力的角度。而小的云供應商們則在抱團以提升競爭力，云供應山和安全供應商都在努力向用戶證明自己平臺的開放兼容性，處于相互利用的情況。而且大家都知道這種合作關系太不牢靠，一旦有任何一方開始涉足對方的領域，那么這層薄薄的關系就變得岌岌可危。這其中占主動的已經是云供應商。果然還是誰更靠近用戶，誰就更有話語權。
目前私有云市場還處于混戰的階段，沒有誰能號令四方，這種情況也許還要持續一段時間。私有云暫時還無法完全吞下用戶的數據中心，安全廠家們終將走上一條共同的道路，實現在方案層面而非產品層面上實現與私有云們的共存，以至于不讓私有云過于牽制自身發展，又不用過多地去適配各種云廠家?；蛟S網絡資源池/安全資源池是個出路。
?
然后就是用戶與安全企業的關系
關鍵字是統一，當用戶發現計算、存儲、網絡資源都可以在一個平臺里隨意管理、使用的時候，開始嘗到了統一管理的甜頭，這是以前網管、運維系統多少年想做都沒做成的事情，所以說進步靠的不是廠家之間的合作，而是代替。
而現在，用戶強調統一管理比以前多得多得多。但凡涉及到基礎IT資源，都想實現在一個平臺內的統一管理?；A架構即是云，云即是統一平臺。用戶對于各種廠家統一的期盼，就是能夠和云平臺進行適當的融合，減少管理復雜性。
?
公共安全
雖然AWS一直以來的口號都是由用戶和AWS共擔責任，但是類似AWS和阿里云這樣的大型公有云已經在越來越多地染指高級的安全服務，對應的安全產品也越來越齊全，用戶已經可以使用公有云服務商的安全產品搭建較為完善的安全防護體系。而與之對應的是，公有云上各種安全合作伙伴的產品購買量實在稀少。大量安全產品購買量維持在個位數。
?
這種情況非常常見，各安全企業在公有云上基本在賠本賺吆喝。
?
一來是因為公有云徹底改變了安全行業，最傳統的4層防火墻、DDOS設備、堡壘機。他們要么弱化成云上的一個服務，要么已經不適用。特別在PaaS化后，甚至SaaS化后，云租戶需要承擔的安全建設責任越來越少。安全廠家的主戰場已經完全轉移到了私有云和混合云上。誰轉型更快、誰的產品更好誰將重洗企業安全市場。
二，傳統廠家的安全設備在公有云上的使用體驗太差，因為網絡結構、底層架構變化的原因，傳統安全設備在云上的部署過程繁瑣，而且許多傳統網絡中的功能不再適用。安全廠家們急匆匆搬上云的各種安全服務無論在UI亦或功能上都沒能為云用戶做出足夠多的優化，導致用戶體驗極差。而各種云們天生集成的各種安全服務，在這種情況下優勢明顯。
?
所以我依舊認為公有云最終將成長為巨無霸型的IT服務商，巨大的用戶量足以支撐公有云將各種常用的IT產品全部包含在其產品體系內，其產品體系將越來越龐大。公有云企業吞噬掉的的不僅僅是傳統IT硬件的市場份額，還包括部分軟件和服務的市場空間。
所以當我們說IT總市場在不斷增長，但是這其中有相當大一部分將被公有云蠶食，公有云在IT建設中的比重將越來越高，中小IT企業的存活堪憂。也許用不到10年，到那時公有云或許已經不能叫公有“云”了。當未來云計算公司真的變成自來水公司后，IT將變成什么樣子？眼鏡、手表會不會納入到云計算的平臺？是否會有新的計算平臺出現，又引領一波自建的浪潮？運維這一職業是否變成開發語言的package？也許唯一能夠肯定的是，現在我們耳熟能詳的業務都會“消失”，人們不再提起它，但是IT行業將變得更具活力。到那個時候 Nicholas G. Carr 應該再寫一篇 “Cloud Doesn't Matter”。
扯得有點遠，但是只有放開腦洞暢想一下未來，才能更好地看清現在。
?
neutron的vpn沒啥可講的，所以就看一看sd-wan吧。
?
轉載于:https://www.cnblogs.com/pmyewei/p/7609259.html
總結
以上是生活随笔為你收集整理的Openstack Neutron ： 安全的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： linux下安装Mysql（干货！！！）
- 下一篇： 梦到牛蛙是什么征兆