3.4.3　資源耗盡型攻擊

同為虛擬化技術，容器與虛擬機既存在相似之處，也有顯著不同。在資源限制方面，無論使用VMware、Virtual Box還是QEMU，我們都需要為即將創建的虛擬機設定明確的CPU、內存及硬盤資源閾值。在虛擬機內部的進程看來，它真的處于一臺被設定好的獨立計算機之中；然而，容器運行時默認情況下并未對容器內進程在資源使用上做任何限制，以Pod為基本單位的容器編排管理系統在默認情況下同樣未對用戶創建的Pod做任何CPU、內存使用限制。

缺乏限制使得云原生環境面臨資源耗盡型攻擊的風險。攻擊者可能通過在一個容器內發起拒絕服務來占用大量宿主機資源，從而影響到宿主機自身或宿主機上其他容器的正常運行。注意，這里我們討論的是默認配置下的資源限制缺失，從而導致容器的隔離性在一定程度上失效（影響到容器外系統或服務的正常運行），而非針對某容器本身的拒絕服務攻擊。

常見容易受影響的資源如下：

1）計算資源：CPU、內存等。

2）存儲資源：本地硬盤等。

3）軟件資源：內核維護的數據結構等。

4）通信資源：網絡帶寬等。

接下來我們分別討論這些資源在云原生環境下的耗盡風險[1]。其中，網絡帶寬與計算機所處的網絡環境有關，本書不做討論。

1.CPU資源耗盡

毫無疑問，CPU資源大量消耗會對計算機的正常運行產生影響。在缺少限制的情況下，一個容器幾乎能夠使用宿主機上的所有算力。

下面，我們借助壓力測試工具stress測試一下，同時使用htop工具來監測宿主機CPU使用情況。

首先，在宿主機上開啟htop監控（圖3-23下方），然后在宿主機上運行一個容器（圖3-23上方左側終端），接著再測量創建一個容器并執行uname -a命令所需的時間（圖3-23上方右側終端）。可見從執行到命令結束約為0.7s。

圖3-23　正常情況下創建容器并執行命令的場景

現在，我們模擬大量占用CPU算力的場景，在第一次創建的容器中使用stress工具運行大量sqrt()計算任務（圖3-24上方左側終端），執行如下命令：

---

stress -c 1000

---

圖3-24　大量消耗CPU資源時創建容器并執行命令的場景

htop（圖3-24下方）顯示此時宿主機上兩個CPU核心使用率均為100%。這時候，我們再次測量創建一個容器并執行uname -a命令所需的時間（圖3-24上方右側終端），發現命令所需時間已經變成了約1.2s，與上次實驗相比增長了約70%。

由此可見，在沒有限制的情況下，惡意容器能夠通過CPU算力耗盡的方式影響宿主機及其他容器的正常運行。

2.內存資源耗盡

內存耗盡的表現也非常明顯：應用交互及時性會降低，服務響應時間會延長。在缺少限制的情況下，一個容器幾乎能夠占用宿主機上的所有內存。

下面，我們借助壓力測試工具stress測試一下，同時使用htop工具來監測宿主機內存使用量。

首先，在宿主機上開啟htop監控（圖3-25下方），然后在宿主機上運行一個容器（圖3-25上方左側終端），接著再測量創建一個容器并執行uname -a命令所需的時間（圖3-25上方右側終端）。可見從執行到命令結束約為0.9s。

現在，我們模擬內存耗盡的場景，在第一次創建的容器中使用stress工具申請大量內存空間（圖3-26上方左側終端），執行如下命令：

---

stress --vm-bytes 3300m --vm-keep -m 3

---

htop（圖3-26下方）顯示此時宿主機上內存占用已經接近容量，約為7.48G。這時候，我們再次測量創建一個容器并執行uname -a命令所需的時間（圖3-26上方右側終端），發現命令所需時間已經變成了約12s，與上次實驗相比增長了約12倍。

圖3-25　正常情況下創建容器并執行命令的場景

圖3-26　大量消耗內存資源時創建容器并執行命令的場景

由此可見，在沒有限制的情況下，一個容器能夠通過內存耗盡的方式影響宿主機及其他容器的正常運行。

3.進程表耗盡

事實上，除了硬件資源外，操作系統還會提供很多軟件資源，進程表就是其中之一。我們以經典的進程表耗盡案例——Fork炸彈——來分析這類軟件資源無限制可能導致的問題。操作系統中一切行為都是以進程方式執行的。為了管理這些進程，操作系統內核維護了一張進程表[2]，表空間是有限的，一旦飽和，系統就無法再運行任何新程序，除非表中有進程終止。

Fork炸彈，顧名思義，就是借助fork系統調用不斷創建新進程，使進程表飽和，最終系統無法正常運行。能夠實現上述功能的代碼非常多，其中最經典的還是Bash版本：

---

:() { :|:& };:

---

上述代碼看起來古怪，其實很簡單，就是以無限遞歸的形式不斷創建新進程。盡管只有一行代碼，在Bash中執行后，如果沒有其他限制，操作系統就會慢慢失去響應。這里我們不再解釋代碼原理，感興趣的讀者可以參考相關資料[3]。我們關心的是，它能否在容器內部運行？

我們做一個小實驗。圖3-27展示了三個終端：上方終端中，我們在虛擬機內創建了一個容器，然后執行Fork炸彈代碼，下方左側終端事先列出了虛擬機IP地址，下方右側終端則在Fork炸彈執行幾分鐘后，嘗試使用SSH遠程登錄到虛擬機，可以發現，虛擬機已經失去響應了。

圖3-27　運行Fork炸彈后嘗試使用SSH連接目標主機

在虛擬機失去響應后，我們從圖3-28中虛擬機的啟動窗口中可以看到內核打印的日志。

圖3-28　虛擬機日志

日志顯示內核在嘗試殺掉進程。這說明，在沒有相關限制的情況下，容器內的Fork炸彈能夠影響宿主機正常運行。

4.存儲資源耗盡

除了運行時的資源外，相對靜態的存儲資源也可能被耗盡。所有虛擬化技術都必須依托實體，容器也不例外。歸根結底，容器內存儲的數據、文件的實際存儲位置還是在實體機上。如果容器內新增了一個1GB的文件，不考慮NFS等情況，那么宿主機上的磁盤空間也應該相應減少1GB。如果容器沒有存儲空間限制，容器內的攻擊者理論上能夠耗盡宿主機的存儲資源。

首先，我們在宿主機上使用df命令查看一下可用空間（圖3-29上方終端），結果為9.4GB。

圖3-29　查看宿主機的存儲空間

然后，我們在容器中使用fallocate命令創建一個9.4GB的文件（圖3-30下方終端）后，宿主機上的磁盤使用率為100%，可用空間為0。此時，如果宿主機需要增加一個大小為1GB的重要文件（圖3-30上方終端），就會因為空間不足而失敗。

圖3-30　在容器中創建一個超大文件

[1] 本小節的隨書代碼倉庫路徑：https://github.com/brant-ruan/cloud-native-security-book/tree/main/code/0304-運行時攻擊/03-資源耗盡型攻擊。

[2] https://zh.wikipedia.org/zh-cn/ 行程控制表。

[3] https://en.wikipedia.org/wiki/Fork_bomb。