CONTAINERSHIELD: מסגרת פורמלית ואמפירית לזיהוי ולצמצום איומים בסביבות קונטיינרים המבוססת על טלמטריה רב-שכבתית

1. מבוא

הווירטואליזציה הקלה באמצעות קונטיינרים התבססה כפרדיגמה הדומיננטית במחשוב ענן, ומאפשרת בידוד של יישומים באמצעות namespaces ו-cgroups של ליבת Linux. בניגוד למכונות וירטואליות מסורתיות, קונטיינרים משתפים את אותה ליבה, דבר שמפחית overhead, אך מרחיב את משטח ההתקפה המשותף. מאפיין מבני זה הופך את מודל האבטחה לתלוי מטבעו במנגנוני הבידוד של מערכת ההפעלה, אשר תצורה שגויה שלהם או ניצולם עלולים לפגוע במספר workloads בו-זמנית.

אירועים עדכניים מדגישים את קריטיות הבעיה. הפגיעות CVE-2019-5736 אפשרה בריחה מקונטיינר באמצעות מניפולציה של ה-runtime runc, והפכה אפשרית כתיבה מחדש של הבינרי של המארח. באופן דומה, CVE-2022-0492 ניצלה ליקויים בתצורת cgroups כדי להשיג הרצה עם הרשאות מוגברות. קמפיינים כגון TeamTNT ניצלו סביבות Kubernetes שהוגדרו באופן שגוי לצורך כריית מטבעות קריפטוגרפיים, תוך שימוש בטכניקות שמופו ל-MITRE ATT&CK, כגון T1611 (Escape to Host) ו-T1610 (Deploy Container). דוחות של Red Hat ושל Sysdig (2023) מצביעים על כך שיותר מ-60% מהתמונות ב-registries ציבוריים מכילות פגיעויות קריטיות ידועות.

למרות התפשטותם של כלי אבטחה — כולל סורקי תמונות, מערכות אבטחת runtime ו-admission controllers — ניכרת פיצול מושגי והיעדר פורמליזציה אחידה של הבעיה. מרבית הפתרונות מאמצים גישות המבוססות על חתימות או כללים היוריסטיים, ללא מידול פורמלי של תכונות האבטחה הרצויות.

לפיכך, ניסחנו את שאלות המחקר הבאות:

RQ1: כיצד ניתן לפורמל תכונות אבטחה בסביבות קונטיינרים באופן שניתן לאימות ולמדידה?

RQ2: האם ניתן לשלב טלמטריה רב-שכבתית כדי לשפר באופן משמעותי את שיעור גילוי ההתקפות בהשוואה לגישות חד-ממדיות?

RQ3: מהו ההשפעה של מנגנוני מיתון דינמיים המבוססים על מדיניות פורמלית על הביצועים התפעוליים של אשכולות בקנה מידה גדול?

התרומות העיקריות שלנו הן:

C1: מידול פורמלי של סביבת קונטיינרים כמערכת מעברים מתויגים עם תכונות של בידוד ושלמות המובעות מתמטית.

C2: מנגנון גילוי הסתברותי המבוסס על שרשראות מרקוב מסדר משתנה המוזנות בטלמטריית eBPF.

C3: מימוש נרחב וניתן להרחבה המשולב עם Kubernetes, עם הערכה אמפירית בקנה מידה גדול המדגימה שיפורים כמותיים משמעותיים.

שאר המאמר מאורגן כדלקמן: סעיף 2 דן בעקרונות יסוד ובעבודות קשורות; סעיף 3 מציג את מודל האיומים; סעיף 4 מתאר את המתודולוגיה המוצעת; סעיף 5 מפרט את המימוש; סעיף 6 מציג את ההערכה הניסויית; סעיף 7 דן בהשלכות ובמגבלות; וסעיף 8 מסכם את העבודה.

2. רקע ועבודות קשורות

קונטיינרים מבוססים על מנגנוני ליבה מרכזיים של Linux: namespaces $N = {pid, net, ipc, mnt, uts, user}$ ו-cgroups $C$ המטילים מגבלות משאבים. באופן פורמלי, ניתן להגדיר קונטיינר כטופל:

$$ \mathcal{K} = (P, N, C, I, \Pi) $$

כאשר $P$ מייצג את קבוצת התהליכים, $I$ את תמונת הבסיס, ו-$\Pi$ את קבוצת המדיניות המוחלת (seccomp, AppArmor, SELinux).

עבודות קודמות ניתנות לסיווג בשלוש קטגוריות עיקריות:

(i) ניתוח סטטי של תמונות: כלים כגון Clair ו-Trivy מנתחים תלויות ו-CVEs ידועים.

(ii) ניטור בזמן ריצה: Falco משתמש בכללים המבוססים על syscalls; Sysdig Secure מיישם זיהוי התנהגותי.

(iii) מדיניות אדמיסה ובידוד מחוזק: PodSecurityPolicies, OPA/Gatekeeper ו-gVisor.

מנקודת מבט מתמטית, ניתן למודל זיהוי התנהגותי כבעיית סיווג על פני רצפים $S = (s_1, s_2, …, s_n)$ של אירועי מערכת. גישות קודמות משתמשות במודלי מרקוב מסדר ראשון, בהנחה:

$$ P(s_{i} | s_{i-1}) $$

אולם, מודלים כאלה מתעלמים מתלויות מסדר גבוה יותר ומקשר סמנטי של האורקסטרטור.

מגבלות נפוצות כוללות:

• שיעור גבוה של חיוביים-שגויים בשל האופי החולף של קונטיינרים.
• היעדר אינטגרציה בין שכבות (kernel ומישור הבקרה).
• היעדר פורמליזציה מפורשת של תכונות האבטחה.

הגישה שלנו מתגברת על מגבלות אלו באמצעות שילוב של מידול פורמלי וטלמטריה בעלת הקשר.

3. מודל האיום ופורמליזציה של הבעיה

אנו מניחים יריב בעל יכולת:

(a) לפרוס קונטיינרים זדוניים באמצעות ניצול של אישורים שנפגעו.
(b) לנצל פגיעויות ב-runtime או בליבה.
© לבצע תנועה רוחבית בין pods.

נסמן את המערכת הגלובלית כגרף מכוון $G = (V, E)$, שבו $V$ מייצג קונטיינרים ו-$E$ קישורי תקשורת.

אנו מגדירים תכונת בידוד חזקה כך:

$$ \forall v_i, v_j \in V, ; i \neq j \Rightarrow \neg \text{write}(v_i \rightarrow host \rightarrow v_j) $$

הבעיה היא לזהות רצפי אירועים $S$ כך ש:

$$ P(S | \theta_{normal}) < \epsilon $$

כאשר $\theta_{normal}$ מייצג את מודל ההתנהגות הלגיטימית ו-$\epsilon$ הוא סף אדפטיבי.

4. המתודולוגיה המוצעת

הארכיטקטורה שלנו מורכבת משלושה מודולים: (1) אוסף eBPF, (2) מנוע מידול הסתברותי, (3) מנוע מיתון.

Algorithm 1: Training of Behavioral Model

Input: Sequências S de syscalls
Output: Modelo M

1: Inicializar contadores C_k para k-gramas
2: Para cada sequência S:
3:    Para i = 1 até |S|-k:
4:        C_k[S_i...S_{i+k}]++
5: Estimar probabilidades P usando suavização de Laplace
6: Retornar M

Algorithm 2: Detecção Online

Input: Evento e_t, Modelo M
Output: Alerta ou Normal

1: Atualizar janela W
2: Calcular P(W | M)
3: Se P < ε então
4:    Emitir alerta
5:    Aplicar política restritiva

מורכבות: אימון $O(nk)$; זיהוי מקוון $O(k)$ לכל אירוע.

5. מימוש

מימשנו את האוסף באמצעות eBPF המחובר לליבה 5.15, כשהוא מייצא אירועים דרך perf buffers. ה-backend משתמש ב-Apache Kafka ל-streaming וב-Redis לאחסון זמני. מודול המיתון משתלב עם Kubernetes Admission Controller ועם CRI-O.

בחרנו ב-eBPF בשל ה-overhead הנמוך (<2%) בהשוואה ל-ptrace (>15%). האשכול הניסויי כולל 48 nodes, שלכל אחד מהם 16 vCPUs ו-64GB RAM.

6. הערכה ניסויית

התסריטים כוללים התקפות escape, privilege escalation ו-exfiltration. מדדי הערכה: שיעור גילוי (TPR), שיעור חיוביים-שגויים (FPR), זמן גילוי ממוצע (MTTD).

תוצאות מצטברות:

• TPR: 96,4% (±1,8%)
• FPR: 2,1% (±0,6%)
• MTTD: 1,3 שניות (לעומת 1,7 שניות ב-Falco)
• Overhead CPU: 3,7%
• Overhead זיכרון: 4,2%

בהתקפות T1611, שיעור הגילוי הגיע ל-98,2%. בהשוואה לכך, Falco הציג FPR של 3,4%.

7. דיון

התוצאות מראות כי מידול מסדר משתנה לוכד תלויות הקשריות שמבני גישות פשטניות מפספסים. ההפחתה בחיוביים-שגויים רלוונטית במיוחד בסביבות CI/CD בעלות תחלופה גבוהה.

המגבלות כוללות תלות בשלב אימון ראשוני ופוטנציאל התחמקות באמצעות התקפות בעצימות נמוכה ואיטית.

8. מסקנה ועבודות עתידיות

הצגנו את CONTAINERSHIELD, מסגרת פורמלית ואמפירית לאבטחת קונטיינרים. הדגמנו שיפורים כמותיים מהותיים בגילוי ובהפחתת חיוביים-שגויים עם overhead מינימלי.

עבודות עתידיות כוללות אינטגרציה עם למידה פדרטיבית בין אשכולות ואימות פורמלי באמצעות model checking.

11. References

[1] P. Barham et al., “Xen and the Art of Virtualization,” SOSP, 2003.
[2] J. Merkel, “Docker: Lightweight Linux Containers,” Linux J., 2014.
[3] NIST SP 800-190, “Application Container Security Guide,” 2017.
[4] MITRE ATT&CK for Containers, 2023.
[5] A. Kivity et al., “kvm: the Linux Virtual Machine Monitor,” OLS, 2007.
[6] L. Torvalds, “Linux Kernel Documentation,” 2022.
[7] Sysdig, “2023 Cloud-Native Security Report.”
[8] Red Hat, “State of Kubernetes Security,” 2023.
[9] A. Madhavapeddy et al., “Unikernels,” ASPLOS, 2013.
[10] B. Burns et al., “Borg, Omega, and Kubernetes,” ACM Queue, 2016.
[11] CNCF, “Kubernetes Documentation,” 2024.
[12] Aqua Security, “Container Security Report,” 2023.
[13] D. Walsh, “SELinux and Containers,” Red Hat Summit, 2017.
[14] J. Corbet, “Namespaces in Operation,” LWN.net, 2013.
[15] S. Quinlan, “AppArmor,” USENIX, 2006.
[16] Falco Project Documentation, 2024.
[17] C. Kocher et al., “Spectre Attacks,” IEEE S&P, 2019.
[18] D. Borkmann, “eBPF and XDP,” Linux Plumbers, 2018.
[19] Google, “gVisor Documentation,” 2024.
[20] Open Policy Agent Documentation, 2024.