容器化技術的興起改變了軟體佈署和管理的方式，但也帶來了新的安全挑戰。本文深入研究了 Docker 容器和傳統虛擬機器在面對常見安全漏洞時的表現差異，並探討如何強化容器環境的安全性。實驗評估了 DirtyCow、Shellshock 和 Heartbleed 等漏洞在兩種環境下的影響，發現容器的輕量級特性和隔離機制在某些情況下能提供更佳的防禦效果。然而，容器的最小化組態也可能導致漏洞利用程式編譯的困難。根據實驗結果，本文提出了使用唯讀容器、設定 AppArmor 策略以及例項隔離等最佳實務建議，以降低容器化應用程式遭受攻擊的風險。
[BSH+15] Baumgärtner, L., Strack, C., Hoßbach, B., Seidemann, M., Seeger, B., & Freisleben, B. (2015). Complex event processing for reactive security monitoring in virtualized computer systems. In Proceedings of the 9th ACM International Conference on Distributed Event-Based Systems, DEBS ‘15 (pp. 22–33). New York, NY, USA: ACM.
[BSJ07] Buyens, K., Scandariato, R., & Joosen, W. (2007, July). Process activities supporting security principles. In 31st Annual International Computer Software and Applications Conference (COMPSAC 2007) (Vol. 2, pp. 281–292).
[CS14] Codenomicon & Google Security. (2014). Heartbleed bug. Retrieved 2017-05-13, from http://heartbleed.com/
[DA99] Dierks, T., & Allen, C. (1999, January). RFC 2246 - The TLS Protocol Version 1.0. Retrieved 2017-05-15, from https://tools.ietf.org/html/rfc2246
[DFB12] Dowland, P., Furnell, S., & Botha, R. (2012). Proceedings of the Ninth International Network Conference (INC 2012). Plymouth University.
[DO14] Digital Ocean, LLC. (2014, May). 5 common server setups for your web application. Retrieved 2016-10-30, from https://www.digitalocean.com/community/tutorials/5-common-server-setups-for-your-web-application
[Doc16a] Docker, Inc. (2016). Dockerizing an SSH service. Retrieved 2016-11-01, from https://docs.docker.com/engine/examples/running_ssh_service/
[Doc16b] Docker, Inc. (2016). What is Docker?. Retrieved 2016-11-04, from https://www.docker.com/what-docker
[FKK11] Freier, A., Karlton, P., & Kocher, P. (2011, August). RFC 6101 - The Secure Sockets Layer (SSL) Protocol Version 3.0. Retrieved 2017-05-15, from https://tools.ietf.org/html/rfc6101
[KW00] Kamp, P.-H., & Watson, R. N. M. (2000). Jails: Confining the omnipotent root. In Proceedings of the 2nd International SANE Conference (Vol. 43, p. 116).
[LIJM+10] Labovitz, C., Iekel-Johnson, S., McPherson, D., Oberheide, J., & Jahanian, F. (2010, August). Internet inter-domain traffic. SIGCOMM Comput. Commun. Rev., 40(4), 75–86.
[Lin17] Linux man-pages project. (2017, May). namespaces(7) - Linux manual page. Retrieved 2017-06-12, from http://man7.org/linux/man-pages/man7/namespaces.7.html
[Mas17] Massachusetts Institute of Technology. (2017, June). Software patching. Retrieved 2017-06-05, from https://ist.mit.edu/security/patches
[NAMG09] Nussbaum, L., Anhalt, F., Mornard, O., & Gelas, J.-P. (2009, July). Linux-based virtualization for HPC clusters. In Montreal Linux Symposium, Montreal, Canada.
[Ope17] OpenSSL Software Foundation. (2017). /index.html. Retrieved 2017-06-12, from https://www.openssl.org/
[PFH03] Provos, N., Friedl, M., & Honeyman, P. (2003). Preventing privilege escalation. In Proceedings of the 12th USENIX Security Symposium, Washington, D.C., USA, August 4-8, 2003. USENIX Association.
[Pro17] OWASP Foundation. (2017, June). OWASP Top 10 - 2017 RC1: The top 10 most critical web application security risks. Retrieved from https://github.com/OWASP/Top10/raw/master/2017/OWASP%20Top%2010%20-%202017%20RC1-English.pdf
[RKNA14] Reshetova, E., Karhunen, J., Nyman, T., & Asokan, N. (2014). Security of OS-level virtualization technologies: Technical report. CoRR, abs/1407.4245.
[SGI+99] Spinellis, D., Gritzalis, S., Iliadis, J., Gritzalis, D., & Katsikas, S. (1999). Trusted third party services for deploying secure telemedical applications over the WWW. Computers & Security, 18(7), 627–639.
[SMP11] Schreuders, Z. C., McGill, T., & Payne, C. (2011, September). Empowering end users to confine their own applications: The results of a usability study comparing SELinux, AppArmor, and FBAC-LSM. ACM Trans. Inf. Syst. Secur., 14(2), 19:1–19:28.
[Sta02] Stallings, W. (2002). Cryptography and Network Security: Principles and Practice (3rd ed.). Pearson Education.
[STW12] Seggelmann, R., Tuexen, M., & Williams, M. (2012). RFC 6520 - Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension.
實驗評估與討論
在本文的最後一章中，將總結研究發現，並對結果進行觀察和評述。同時，也會評估用於調查安全漏洞的方法和結果。根據第4章的實驗結果，將提出一些最佳實踐建議，並對進一步的分析提供建議。最後，本論文將以對易受攻擊的應用程式在不同基礎設施中佈署的影響進行進一步研究和探討的建議作為結尾。
結果討論
作為對第4章實驗的跟進，本章將對實驗結果進行評估。值得注意的是，在4.1.2節中描述的虛擬機器環境與4.1.1節中的Docker環境之間存在明顯的差異。討論將根據這些差異以及與應用程式、Linux或安全性相關的檔案或原則進行。
Dirtycow漏洞
透過評估Dirtycow實驗（4.2.1節）的結果，發現容器環境與根據虛擬機器的環境在Dirtycow漏洞利用方面沒有顯著差異。在Docker環境中，實際執行和成功提升許可權較為困難，但正如6.1節所討論的，透過其他方式完成編譯並非難事，這也可能是實際攻擊者所採用的方法。
更值得關注的是防止Dirtycow攻擊和組態系統以避免發生競爭條件的方法。使用AppArmor並為應用程式組態許可權；應用程式組態檔案決定了環境在系統中允許讀取、寫入和執行的內容。透過利用Docker的容器級別AppArmor實作，可以將這些限制應用於整個容器，而不僅僅是單個應用程式（見4.2.1節）。將策略應用於容器環境和單個應用程式之間的區別在於，除非攻擊者或漏洞利用使應用程式本身執行漏洞利用，否則單個應用程式策略可能無法防止攻擊，而容器策略則可以。
其他可能的解決方案包括為系統中的所有可執行檔設定預設的AppArmor組態檔案；這可能是與平台無關的解決方案。然而，預設規則集的缺點是，任何無法遵循約束且需要其他許可權的應用程式都需要適當的AppArmor策略。此外，如Dirtycow結果部分（4.2.1節）所示和解釋的那樣，整個虛擬例項當機了，應用程式停止了功能。這種當機並非理想結果，但防止攻擊者獲得對環境的完全控制往往被視為更可取的選擇，無論是從損害程度還是經濟角度來看。
Shellshock漏洞
Shellshock漏洞的結果與Dirtycow類別似，也是一種許可權提升漏洞。然而，與Dirtycow不同的是，Shellshock依賴於將惡意程式碼注入環境變數，然後由應用程式執行注入的變數。根據注入的程式碼和實作方式的不同，注入可能會導致系統中的許可權提升。
避免使用只讀許可權的容器環境是一種可能的解決方案，可以防止對容器環境進行永久更改。然而，只讀解決方案存在侷限性，首先是無寫入策略嚴格限制了應用程式的使用場景。為了在一定程度上避免無寫入限制，可以將需要寫入許可權的服務隔離並提取到具有足夠許可權的單獨容器中。這種分離是一種繞過限制的方法，但需要單獨組態和符合案例條件的容器組合結構。
Heartbleed漏洞
防止Heartbleed漏洞被證明是一項艱難的任務（見4.2.4節）。使用AppArmor（見3.1.4節）、Seccomp（見3.1.4節）和SELinux（在3.1.4節中）等工具，可以輕易防止應用程式直接從記憶體中讀取。然而，Heartbleed漏洞的問題不在於OpenSSL應用程式進行了未經授權的記憶體讀取。每個由OpenSSL透過心跳協定發出的讀取請求都允許攻擊者請求比預期更大的記憶體段。結果是，攻擊者在成功攻擊後能夠讀取與OpenSSL應用程式相關的額外記憶體，因為請求的記憶體邊界缺乏驗證。然而，這些變數具有最大長度限制，並且作業系統對應用程式記憶體空間有明確的區分和隔離。
因此，Heartbleed漏洞僅限於OpenSSL記憶體，但這可能足以進一步危及伺服器。由於OpenSSL是一種流行的金鑰處理應用程式，因此透過Heartbleed可能獲得系統中的所有OpenSSL金鑰，從而可能使攻擊者獲得對系統和相關機器的完全控制。
Fork-bomb攻擊
正如4.2.5節中的列表4.26所示，Docker容器在日誌執行時啟動了三個程式。在4.2.5節中解釋的透過Docker的執行引數設定的PID約束限制了容器例項產生超過給定數量的程式。透過日誌執行和日誌操作之間的等待，這個數字在3到4之間浮動。Fork-bomb執行後立即產生了200個程式。日誌顯示，從01:41:23到01:41:39之間存在一個間隙，這是由列表4.26中的PID限制引起的。Fork-bomb佔用了所有可用的PID，因此停止了日誌功能的運作，並在Fork-bomb被中斷後還原了功能。
然而，在沒有資源限制的情況下進行相同的分析嘗試都未能成功。對這些失敗嘗試的一種可能解釋是…
程式碼範例與解析
# 限制Docker容器內的程式數量
docker run --pid-limit 100 mycontainer
內容解密：
此命令用於限制Docker容器內的程式數量。透過指定--pid-limit引數，可以控制容器內允許的最大程式數。在這個例子中，最大程式數被限制為100。這種限制可以有效防止Fork-bomb型別的攻擊，因為它限制了攻擊者能夠建立的最大程式數量，從而避免了系統資源被耗盡。
圖表示例
圖表翻譯： 此圖表展示了Fork-bomb攻擊的基本流程。首先，攻擊者啟動一個Docker容器，並設定PID限制。然後，攻擊者執行Fork-bomb，試圖佔用所有可用的PID。當Fork-bomb超出設定的PID限制時，系統資源耗盡，從而導致系統當機或變得不穩定。透過設定適當的PID限制，可以有效防止Fork-bomb型別的攻擊。
方法論與觀察的反思
在測試過程中，保持每個漏洞之間清晰可辨別的界限被證明既是優勢也是劣勢。最突出的優勢是測試了不同型別的漏洞，這些漏洞影響了基礎設施環境中整個價值鏈中的元件，從而使得結論的得出更具背景依據。
這種多樣性帶來的缺點包括了操作和每個環境的實作都需要執行每個漏洞。需要在每個漏洞之間從頭開始組態或進行大量的重新組態，這導致了花費大量時間熟悉兩個環境中的各種技術堆積疊層次。
在實驗階段，編譯和組態漏洞利用是一個困難的步驟。一個值得注意的耗時過程是在 Docker 容器中編譯 Dirtycow。容器環境是根據每個應用的最低需求建立的，並且主要根據預設的安全性原則，如第 3.1.4 節所述。因此，一般來說，容器不一定包含編譯 Dirtycow 所需的函式庫和二進位檔案。
內容解密：
這段描述了在容器環境中編譯 Dirtycow 漏洞利用的挑戰。主要問題在於容器環境通常是最小化組態，不包含編譯所需的工具和函式庫。解決方案是預先編譯好所需的漏洞利用程式，或是收集所需的資訊以滿足系統需求來編譯原始碼。
建議
本論文的安全性分析旨在探索和測試兩種不同的虛擬化技術如何處理與廣泛使用的應用程式相關的安全事件，但不一定有直接的結論。相反，在整個論文中發現了一些有趣的發現，並提出了改善安全性的措施。本文提出的建議尤其與根據 Docker 的容器解決方案相關，但如第 5.1.1 節所示，也與根據 Hypervisor 的虛擬機器以及第 2.2.5 節中提到的一些替代方案有關。
– 唯讀容器：在成功攻擊的情況下，將容器設為唯讀可以防止攻擊者對系統進行永久性更改。如 Shellshock 3.2.4 和 Dirtycow 3.2.3 所示，一些漏洞利用需要寫入許可權才能正常運作。
– 應用程式組態檔：預設的 AppArmor 組態檔阻止了 Dirtycow 漏洞利用。這表明進一步改善可以防止系統重新啟動。
– 例項隔離：評估基礎設施中佈署的各種應用程式，並確定哪些應用程式之間可能具有較少的隔離度，而哪些應用程式可能對隔離有更嚴格的要求，可以簡化管理並可能影響經濟方面。
內容解密：
上述建議提供了改善容器安全性的具體措施，包括使用唯讀容器、應用程式組態檔和例項隔離等方法，以減少攻擊成功的風險和影響。
未來工作
在本論文提交截止日期前幾天，公佈了一個新的與許可權提升相關的漏洞，CVE-2017-1000367。這個漏洞是 Linux 核心功能 sudo 中的一個可利用的競爭條件。sudo 是一個允許使用者以比初始請求使用者更高的許可權執行命令的工具。這一漏洞的基礎是一個競爭條件，擁有 sudo 存取權的使用者可以提升其許可權以獲得完全的 root 存取權，無論最初被授予的 sudo 許可權是什麼。
內容解密：
此段描述了一個新的許可權提升漏洞（CVE-2017-1000367），該漏洞涉及 Linux 核心功能 sudo 中的競爭條件。這個漏洞允許具有 sudo 許可權的使用者獲得 root 許可權。研究這個漏洞對容器化環境的影響將會很有意義，尤其是當 SELinux 被組態為與 sudo 介面時。
進一步的工作可以涉及更好地控制和理解應用程式如何與其環境互動。多項研究已經進行，以預測應用程式的異常行為，其中包括 Baumgärtner 等人的論文，他們提出使用機器學習對虛擬化環境進行反應式安全監控。將本論文中提出的安全措施與 Baumgärtner 的論文中的分析結合起來，可能可以透過預測分析來停止未知的方法來利用應用程式或環境。
圖表翻譯：
此圖示呈現了本論文的研究結論與未來工作的關係圖，顯示了不同虛擬化技術下安全事件處理的比較，以及未來可能的研究方向。
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title 容器與虛擬機器安全漏洞分析
package "Docker 架構" {
actor "開發者" as dev
package "Docker Engine" {
component [Docker Daemon] as daemon
component [Docker CLI] as cli
component [REST API] as api
}
package "容器運行時" {
component [containerd] as containerd
component [runc] as runc
}
package "儲存" {
database [Images] as images
database [Volumes] as volumes
database [Networks] as networks
}
cloud "Registry" as registry
}
dev --> cli : 命令操作
cli --> api : API 呼叫
api --> daemon : 處理請求
daemon --> containerd : 容器管理
containerd --> runc : 執行容器
daemon --> images : 映像檔管理
daemon --> registry : 拉取/推送
daemon --> volumes : 資料持久化
daemon --> networks : 網路配置
@enduml圖表翻譯： 此圖示呈現了本論文的研究結論與未來工作的關係圖。其中結論部分引出了未來工作的方向，包括對新發現漏洞（CVE-2017-1000367）的分析，以及應用程式行為預測和反應式安全監控的研究。這張圖展示了研究的不同階段和方向之間的邏輯關係。
