SDN資安議題探討 Part 2

SDN資安議題探討 Part 2

Q1：未採用TLS加密OpenFlow的資安風險為何？
A1：缺少了TLS作為Switch與Controller間的加密協定，將會導致駭客有機可乘滲透OpenFlow網路而無法輕易查覺。當然對一完全獨立封閉的SDN網路，基本上此議題不大，但若網路結構較複雜，如有遠端Switch處於較不易監控之地或是跨區收容在其它ISP網路中，皆會有傳輸安全的疑慮，如遭受中間不當的攔截竊聽。
無論是用什麼方法，一旦駭客可以放置設備在Controller及Switch的中間時，駭客即可以新增/修改/刪除原始的過濾及路由條件，亦可控制SDN完成所要達成的效果，尤其之前所提用In-band方式較易招受攻擊，因為駭客可控制了網路處理邏輯大腦的部份，因為對任何支援OpenFlow的Switch控制方式皆相同，降低了駭客入侵的門檻，此型攻擊較傳統網路造成更大的影響，同時此攻擊行為也不容易被偵察到。例如駭客可命令Switch複製一份訊務資料至外部的伺服器，即極有可能造成敏感性的資料外洩。
如果Switch處於之前所提的Listener Mode，駭客甚至不用中間攔截竊聽，只要經由簡易的網路掃描，先找出此類的Switch後進行連接，控制完成後可以作為一個代理伺服器，甚至作為日後其它攻擊的跳板。

Q2：如何確保OpenFlow的過濾條件没有遭受外力竄改？
A2：目前最好的方法就是定期導出及檢核Controller及Switch的過濾條件(Flow Table)內容，當被控制的Switch數量變多時，將可能會造成計算比對上較大的負擔。一種較經濟快速的方式即是利用雜湊驗算(Checksum)方式檢查相關過濾條件是否有遭受非預期的竄改，此量測資料亦可放置在Switch送回Controller的Kepp-alive訊息當中。

Q3：目前在Controller上最大的資安議題為何？
A3：Controller扮演了SDN的中樞大腦控制的角色，也最容易成為駭客攻擊的主要目標，而最常見的攻擊手法則為DoS(Denial of Service)。雖然可以用多台Controller緩解DoS的攻擊流量，若設計不良仍會成大災難。
Switch收到一個網路封包，無論是所提的預先設定(Proactive)或因應設定(Reactive)的方式進行過濾，若没有符合的過濾條件時，Switch會回應送端一個table-miss的訊息。若是在Proactive時，此類行為對Controller並不會造成影響，但在Reactive時，Controller則會忙於應付這些詢問，當量大時則會造成Controller的處理負擔，進而使的Controller無法對正常詢問回應。
要解決此類問題，需要避免Controller MAC被假冒，並且需要限制到不明主機的流量及過濾規則的發佈流量，因此Controller的設計需要與一般高可靠度網路元件一樣，要能提供ARP毒害保護、DHCP偵查功能、廣播(Broadcast)/多點傳送(Multicast)的流量限制及單一埠可學習到MAC地址總量限制等基本資安的內建機能。

Q4：SDN的應用程式層的資安問題影響為何？
A4：SDN所帶來最大的好處即是可讓各家軟體開發商研發各式不同的的網路過濾程式，但若此程式本身的原始碼並没有在安全上考慮的很周詳時，會容易招致外部駭客入侵，控制及竄改其程式內容，進而影響整個SDN網路運作。所以除了上層應用程式開發者應注意程式碼的安全外，Controller也應對其程式作一個隔離沙箱測試，以確保上線後的安全無虞。

Q5：SDN網路資安防護基本建議作法為何？
A5：

實踐TLS加密協定在Switch與Controller之間，可加上驗證碼自動產生及如SSH所作的只有在第一次作驗證碼交換使用，在安全與實施便利上取得平衡
Switch與Controller之間的鏈路應該是封閉獨立運作的，最好還要加上實體安全的監控
對於DOS的攻擊，對於Switch與Controller之間流量的限制是必要的
對於上層應用程式開發時資安規範的要求亦是相同重要的，最好能對所遞交的程式在正式上線前能作一個沙箱測試

標籤 : Phitech, 資安, 懇懋科技