如今越來越多的企業開始考慮部署軟件定義網絡(SDN),但是安全問題成為了他們的最大顧慮。企業希望了解SDN產品是如何確保他們的應用、數據和基礎設施免受攻擊的。在引入SDN時必須要制定出能夠確保控制層流量安全的新策略。本文將評估對SDN系統的攻擊途徑,分享一些能夠確保具有SDN功能的虛擬網絡基礎設施安全的方法。此外,本文還將就一些被認為能夠保證SDN部署安全的方法進行探討。
一、SDN 攻擊途徑多多
SDN是一種連網方式,為了支持虛擬化其將控制層從轉發層中分離出來。SDN是網絡虛擬化的一個新范式。大部分SDN架構模型都有三個層:底層是具有SDN功能的網絡設備,中間層是SDN控制器,上層包括請求或配置SDN的應用與服務。雖然許多SDN系統相對較新,并且仍然沒有走出早期部署者的小圈子,但是可能肯定的是,隨著技術的不斷成熟,SDN將會被廣泛部署,并將成為攻擊者的目標。
我們預測了幾種對SDN系統的攻擊途徑。SDN的安全顧慮主要集中在對不同SDN架構層的攻擊。讓我們看一下每一層可能會發生的攻擊。下圖展示了一個典型的SDN架構和攻擊者可能的方向。
二、對數據層(平面)的攻擊
攻擊者可能會將攻擊目標鎖定為網絡中的網元。理論上,攻擊者能夠非法獲取對網絡的物理或虛擬訪問權,或是威脅到已與SDN連接的主機,然后發動攻擊破壞網元的穩定性。這種攻擊類似于拒絕服務(DoS)攻擊,或是一種企圖攻擊網元的模糊攻擊。
目前控制器與網元之間的通信使用了大量的南向API(應用程序編程接口)和通信協議。SDN南向通信可能會用到OpenFlow (OF)、Open vSwitch 數據庫管理協議 (OVSDB)、路徑計算單元通信協議 (PCEP)、路由系統接口(I2RS)、 BGP-LS、OpenStack Neutron、開放管理基礎設施(OMI)、Puppet、Chef、Diameter、Radius、NETCONF、可擴展消息處理現場協議(XMPP)、定位/標識分離協議(LISP)、簡單網絡管理協議(SNMP)、CLI、嵌入式事件管理器(EEM)、 思科onePK、應用中心基礎設施(ACI)、Opflex等協議。這些協議各自都有著一些確保與網絡單元通信安全的方法法。盡管如此,許多協議都非常新,部署者們可能并沒有以最安全的方式設置它們。
攻擊者可以利用這些協議嘗試著將一些新流實例化至設備的流表中。攻擊者會企圖偽造一些新流,以讓不應當通過網絡的流量被允許通過。盡管流量定向負責指導流量通過防火墻,但如果攻擊者能夠創建一個可繞開流量定向的流,那么攻擊者無疑將獲勝。如果攻擊者能夠控制流量轉向自己設定的方向,那么他們可能會嘗試利用這一功能對流量進行嗅探,然后發動“中間人(MITM)”攻擊。
此外,攻擊者還可以對流進行竊聽,查找到哪些流正在被使用,哪些流量被允許通過網絡。同時他們會嘗試竊聽網元與控制器之間的南向通信。這些信息對于重播攻擊或是偵察都非常有用。
許多SDN系統被部署在數據中心內,而數據中心則通常使用數據中心互聯協議(DCI)。這些協議包括使用基本路由封裝的網絡虛擬化(NVGRE)、無狀態傳輸通道(STT)、虛擬可擴展局域網(VXLAN)、思科OTV、二層多路徑(L2MP)、基于TRILL的協議(如思科FabricPath、瞻博QFabric、博科VCS Fabric)、最短路徑橋接(SPB)等協議。這些協議有的缺乏身份認證,有的沒有采用加密技術,因而無法保證數據包內容的安全。此外一些新協議由于協議設計或是廠商和客戶在部署協議時的方式不當等問題導致存在弱點。攻擊者可以自己偽造流量,并讓它們通過DCI連接或是對DCI連接發動DoS攻擊。
三、對控制器層的攻擊
SDN控制器肯定是攻擊的目標。攻擊者會出于多種目的對SDN控制器進行攻擊。他們可能會通過偽造發往網絡設備的北向API信息或是南向信息從而實例化新的流。如果攻擊者能夠成功偽造來自合法控制器的流,那么將能夠隨心所欲地讓流量通過SDN,并可能繞開為確保安全所制定的策略。
攻擊者可能會嘗試對控制器發動DoS攻擊,或是使用其他方法使控制器發生故障。此外,攻擊者還會嘗試對控制器發動一些資源消耗型攻擊,以癱瘓控制器,讓控制器反應遲鈍并降低它們發送和接收數據包的速度。
很多時候,SDN控制器是運行在在某種Linux操作系統上的。如果SDN控制器是在通用操作系統上運行,那么該操作系統的弱點就是控制器的弱點。通常控制器使用的都是默認密碼,且沒有對安全設置進行配置,SDN工程師往往只讓這些控制器能工作就行,由于擔心搞壞它們,SDN工程師往往不愿意去碰它們,這會導致最終產品很脆弱。
最后,如果攻擊者創建了自己的控制器,并讓單元信任那些來自“流氓”控制器的流,那么情況將非常糟糕。攻擊者隨后可以在網元的流表中創建條目,如此一來SDN工程師將無法在控制器中發現這些流。如此一來,攻擊者將會徹底控制網絡。
四、對SDN 層的攻擊
對北向協議進行攻擊可能也是一條途徑。目前SDN控制器也在使用許多北向API。北向API通常使用Python、Java、C、REST、XML、JSON等語言。如果攻擊者能夠利用北向API的弱點,那么他們將可通過控制器控制整個SDN網絡。如果控制器對北向API缺乏安全防護措施,那么攻擊者則可創建他們自己的SDN策略,并從而獲得SDN環境的控制權。
很多時候,REST API使用的都是默認密碼,這個細節至關重要。如果SDN部署沒有修改默認密碼,那么攻擊者則能夠創建針對控制器管理接口的數據包,隨后可以查詢到SDN環境的配置并修改成自己的配置。
五、如何提升SDN系統的安全性?
隨著SDN的部署,確保控制平面流量的安全性需要新的做法。在傳統的IP網絡中,控制平面的安全是以路由協議安全措施的形式得以保證的,這包括使用針對EIGRP、IS-IS或OSPFv2的 MD5(信息摘要算法5)加密技術,或針對OSPFv3的IPsec AH,或針對MP-BGP的GTSM/ACL/密碼。然而一些人甚至DPI沒有使用這些針對傳統IP網絡的簡單技術。如果他們在部署SDN時依然以同樣的態度漠視安全,那么無疑會讓機構暴露在攻擊危險之中。下面讓我們來看下如何通過強化上述三個層面的安全來確保整個SDN系統的安全。
六、確保數據平面安全
典型的SDN系統通常使用的是x86處理器和TLS(前身為SSL)保護控制平面安全。這些使用已久的HTTP會話易于遭受危及數據平面安全的攻擊。機構應當使用TLS來認證和加密網絡設備端與控制器之間的流量。使用TLS可幫助驗證控制器和網絡設備/ SDN端,防止竊聽和偽造南向通信。
根據所使用南向協議的不同類型,確保南向通信的安全有許多種選擇。一些協議可像之前所說的那樣應用到TLS對話。一些協議可使用共享密鑰和/或隨機密碼阻止重播攻擊。SNMPv3協議遠勝SNMPv2c, SSH遠勝于Telnet。一些專有南向協議可能有著自己的方法阻止攻擊者的竊聽和偽造行為。
同樣,根據所使用的數據中心互聯(DCI)協議,認證隧道端點和保護隧道流量安全方面也有著不同的配置選項。密碼/共享密鑰同樣是一種選擇。盡管如此,部分DCI協議可能沒有任何安全選項。
有的機構可能會認為專用網絡具有一些與生俱來的安全特性。但是隨著機構將虛擬網絡和SDN擴展至云服務和遠程數據中心上,對物理路徑進行驗證可能并非易事。當機構用戶控制著物理訪問權時,阻止未經授權的訪問更為容易,但是隨著網絡的虛擬化,實際的物理路徑正變得越來越模糊,使得保護自己無法看見的東西的安全變得非常困難。
七、確保控制器層安全
控制器是一個關鍵的攻擊目標,因此必須要強化其安全。提升控制器和網元的安全通常需要強化主機操作系統的安全性。所有關于提升面向公公共Linux服務器安全性的最佳實踐都非常適用。此外,機構仍然需要嚴密監視其控制器,防范任何可疑行為。
機構還需要阻止對SDN控制網絡的非授權訪問。SDN系統應當考慮到安全配置,并驗證訪問控制器的管理員。對于控制器管理員來說,基于角色的訪問控制(RBAC)策略可能是必須的。記錄和檢查跟蹤對于查找由管理員或攻擊者所做出的非授權修改非常有用。
如果出現了針對控制器的DoS攻擊,高可用性(HA)控制器架構可有效應對這類攻擊。使用冗余控制器的SDN可承受一個控制器的損失并繼續工作。這相當于提升了攻擊者對系統中所有控制器發動DoS攻擊的門檻。雖然這種攻擊是無法隱藏的,但是我們無法察覺攻擊者的下一個目標。
八、確保SDN層安全
另一個保護措施是使用針對控制流量的帶外(OOB)網絡。在數據中心內創建一個OOB網絡比在整個企業廣域網中創建一個OOB網絡要容易且成本較低。使用北向和南向通信專用OOB網絡可幫助確保控制器管理協議的安全。
使用TLS或SSH等方式確保北向通信和控制器管理的安全被認為是最佳實踐。來自應用的通信以及由控制器發起的請求服務或數據服務應當通過認證和加密方式確保安全。
針對所有請求SDN資源的北向應用的安全代碼也應當是一個最佳實踐。安全代碼實踐不僅有利用確保面向公眾的互聯網應用安全,而且還適用于北向SDN連接。
部分SDN系統能夠檢驗網絡設備表單中的流是否違反控制器策略。這類檢查(類似FlowChecker)能夠幫助識別出正常流與攻擊流之間的差別。
九、結束語
我們僅能夠預測哪些攻擊者可能會將SDN變為攻擊目標。部署、協議、控制器軟件都是新的,以往對SDN發動的攻擊也還不為人知。根據SDN架構,我們能夠預測出攻擊者可能會發動進攻的地方。如果我們站在攻擊者的角度考慮問題,我們應該能夠找到SDN網絡的弱點,并可提前提升其安全性。
在SDN部署項目之前,用戶應當在早期設計階段就考慮如何確保系統安全。不要將安全問題留到最后收尾階段再著手解決,否則可能會追悔莫及。