Cilium是如何防止常規網路攻擊的?

賣行家的小報紙發表於2020-11-13

最近一個影響許多Kubernetes CNI元件的漏洞被發現,這個漏洞通過讓攻擊pod傳送假冒的IPv6 *“Router Advertisement”*資料包給主機工作節點,導致該節點將所有的IPv6網路流量路由到攻擊pod(即“中間人攻擊”)。幸運的是,對於Cilium的使用者,由於Cilium提供了許多內建預設的安全特性,其生產環境並沒有受到該漏洞的影響。在這篇博文中,我們將討論Cilium的預設特性是如何自動地防護常見型別的網路攻擊的。在我們深入之前,先看看有關IPv4和IPv6的基礎知識,以及它們是如何和漏洞聯絡起來的。

IPv4和IPv6基礎

在IPv4中,當一個機器連到網路上,它能通過DHCP獲取到網路配置資訊(包括路由資訊)。這個機器首先傳送一個DHCPDISCOVER廣播資料包到網路上的所有使用者,正常的話,只有DHCP伺服器返回一個DHCPOFFER資料包。然而,網路上的任何裝置都能夠被設定為監聽DHCPDISCOVER資料包並返回一個應答資料包,這意味著存在一個競態條件(決定客戶端信任哪個DHCP伺服器)。

類似於DHCP,網路中的一個IPv6主機能夠通過NDP(Neighbor Discovery Protocol)機制獲取到其路由和鄰居節點的資訊。一臺機器能夠向本地節點傳送Router Solicitation資料包獲取本地路由資訊,或者路由主動傳送一個Router Advertisement資料包到本地主機表示自己是IPv6流量的路由裝置。這個Router Advertisement傳送到一個特殊的IPv6地址(ff02::1)從而廣播到所有節點,因而同一網路上的所有節點都能夠接收到並信任這個資料包。在IPv6中有一些需要注意的改進,特別是link-local地址(用於領域發現協議和無狀態自動配置程式中鏈路本地上節點之間的通訊。使用鏈路本地地址作為源或目的地址的資料包不會被轉發到其他鏈路上)的使用能夠確保Router Advertisement資料包不會被路由到其他的鏈路並且只對本地節點可見。

link-local addresses: These addresses refer only to a particular physical link and are used for addressing on a single link for purposees such as automatic addresss configuration and neighbor discovery protocol. Link-local addresses can be used to reach the neighboring nodes attached to the same link. The nodes do not need a globally unique address to communicate. Routers will not forward datagram using link-local addresses. IPv6 routers must not forward packets that have link-local source or destination addresses to the other links. All IPv6 enabled interfaces have a link-local unicast address.

漏洞

通過傳送欺詐性的router advertisements資料包,惡意的容器能夠重新配置主機從而主機上的所有IPv6流量重定向到被攻擊者控制的容器。

所有的支援IPv6的介面都有一個fe80::/10的網路地址,這意味著攻擊pod能夠使用自己的link-local地址作為Router Advertisement資料包的源IP地址。CAP_NET_RAW許可權能允許kubernetes中的pod傳送帶有任意源IP地址和埠的資料包,可以通過kubectl exec命令檢視是否具有該許可權:kubectl exec -it ubuntu-pod -- capsh --print | grep cap_net_raw. 攻擊pod通過傳送Router Advertisement資料包到節點,使得節點將該pod看作路由並將部分或者所有的IPv6的流量直接傳送到攻擊pod中。

Cilium是如何防護的

Cilium有一些內建的和預設開啟的安全特性從而提供對於上述漏洞的防護。

過濾ipv6資料包

在Cilium中設定enable-ipv6:false並且通過cilium monitor -t drop命令驗證IPv6流量被Cilium Agent pod所丟棄。

IP欺詐防護

從上面可以看到,如果我們顯式的禁用IPv6的流量,可以防護該漏洞,但是對於偽造的資料包呢,Cilium又是如何防護的呢?Cilium通過IP Address Management(IPAM)防止源IP地址偽造。

實踐驗證

偽造源IP地址

建立三個pod:

image-20201112165349724

這3個pod是連通的,從centostest可以ping通centostest1,我們使用scapy工具來測試一下:

image-20201112165722869

在centostest(IP地址為: 10.0.0.215)這個pod容器中執行scapy,傳送一個源IP地址為自己,目的IP地址為centostest1(IP: 10.0.0.18)的正常ICMP請求資料包,可以看到收到了ICMP響應報文。

在centostest1中用tcpdump能夠監聽到的正常網路流量如下所示:

image-20201112170152721

接下來在centostest中傳送包含偽造的源IP地址的ICMP請求報文(目的地址仍為centostest1的IP地址),偽造的源IP地址是centostest2的IP地址,可以看到此時沒有響應:

image-20201112170605328

在centostest1上面也沒有監聽到ICMP請求資料包:

image-20201112170709854

因此,Cilium能夠防護IP地址偽造攻擊

ARP中間人攻擊防範

ARP欺騙是非常常用的一種攻擊手段,也成為ARP快取投毒,一般用在中間人攻擊裡面,將攻擊方偽造成閘道器(即閘道器的IP地址對應攻擊方的MAC地址)。攻擊步驟包括:

  • 先獲取被攻擊主機的MAC地址和閘道器的MAC地址;
  • 欺騙受害主機,使其認為自己是閘道器;
  • 欺騙閘道器,使其認為自己是受害主機;

在我們的攻擊實驗中,讓centostest pod作為中間人監聽centostest1與centostest2兩個pod 的通訊流量。結合上述攻擊步驟,首先是讓centostest pod獲取到centostest1與centostest2的MAC地址,如下是執行的結果。

image-20201113110505125

可以看到,ARP請求返回的MAC地址都是62:db:0a:14:8d:4e,這個MAC地址是centostest這個pod的主機側虛擬網路卡的MAC地址,可以看到,arp請求經過了Cilium BPF程式的特殊處理,直接返回pod主機側虛擬網路卡的MAC地址,而不能正確獲取到正確的MAC地址,因此Cilium能夠防範ARP中間人攻擊

相關文章