יותר ויותר חברות כיום מבינות את היתרונות הגלומים בקונטיינרים מבחינת scaling, צריכת זיכרון, ניהול הקונטיינרים ועוד. אולם, כמו עם כל טכנולוגיה חדשה, תמיד יהיו גורמים המעוניינים להשתמש בטכנולוגיה למטרות נזקים, הונאה וניצול משאבים. המשמעות היא שאנשי אבטחת מידע רבים יהיו מעוניינים (ובצדק) לדעת כיצד להתגונן נגד איומים פוטנציאליים כאלו.
רבים ירוצו כמובן לכלים המסחריים שמציעים שירותי סריקה ואזהרה נגד קונטיינרים זדוניים או קוד זדוני שרץ בקונטיינר, אבל זה לא תמיד מספיק.
אז מה הבעיה?
הבעיה עם כל הפתרונות הללו היא שהם מבוססים על כל מיני חתימות, זיהויי שינויים וכו', כמו אנטי וירוסים אחרים, וזה לא תמיד עוזר. כיום, לא קשה לכל מיני פורצים לבנות קונטיינרים נגועים בסקריפטים משלהם המקודדים (נניח בבסיס 64) שלא יזוהו על ידי אותם כלים אוטומטיים, וכאן כדאי אולי להיזכר במתודות של איך בנויה הפצת לינוקס ולהשתמש במתודות אלו.
הפצת לינוקס כמו רד-האט, CentOS, SuSE, אורקל לינוקס, דביאן, אובונטו וכו', נבנית בכל פעם מאפס על ידי הידור קוד של חבילות שונות עד שנבנית הפצה בסיסית לחלוטין.
להפצה הזו המערכת תעשה Boot, ומשם היא תמשיך להדר את הקוד של כל החבילות שונות (ברד-האט, או כל הפצה מבוססת RPM יש חבילות מיוחדות שנקראות SRPM, שמכילות קוד מקור + טלאים וסקריפטים כדי לקמפל אותה). ההפצה כוללת חבילות שונות מבחוץ שעברו בדיקת קוד בתוך יצרן ההפצה, וברוב המקרים גם שינויים על מנת לרוץ על אותה הפצת לינוקס ספציפית.
כשזה מגיע לעדכונים, יש הרבה אתרים שונים שהם בעצם אתרי "מראה" של אתר יצרן ההפצה – המכילים את העדכונים. כל חבילות העדכונים חתומות בחתימה חזקה על ידי יצרן ההפצה (או יצרן ה-Repository) ואתרי המראה אינם כוללים את החלק הפרטי של המפתח. אם מישהו פורץ לאתר מראה או לאתר יצרן ההפצה וינסה להחליף חבילות קיימות בחבילות נגועות, כל מי שינסה להתקין את החבילות הנגועות פשוט לא יצליח, הואיל והמערכת תעצור את ההתקנה ותוציא פלט שגיאה שהמפתח הציבורי המוזכר בחבילה אינו תואם למפתח של ה-REPO. במקרים ויצרן ההפצה חושד שהמפתח נגנב, הוא מייצר מפתח חדש, חותם מחדש על החבילות שקיימות באתר,מפיץ אותו ומודיע ללקוחותיו על כך (הכנסת המפתח החדש היא קלה, ובדרך כלל מדובר בפקודה אחת).
בחברות גדולות (כמו בנקים וכו') בדרך כלל לא פותחים את חומת האש להורדת חבילות מיצרן ההפצה באופן ישיר, אלא משתמשים בתוכנת-אמצע (Middleware) כמו Red Hat Satellite,בכדי להתקין את ההפצות ועדכונים על שרתים ומחשבים נוספים. ברוב המקומות האחרים שאינם עובדים ישירות מול רד-האט או עובדים עם הפצות אחרות, יש כלי חינמי אחר, ובקוד פתוח כמו SpaceWalk המאפשר להפיץ פנימית בשרתי החברה (ובחשבון הפרטי בענן הציבורי של החברה) עדכוני תוכנה בצורה מאובטחת ומוצפנת (אפשר לשלב בתוך הכלי גם את ה-CA של החברה).
ובחזרה לקונטיינרים
אחד היתרונות בבניית קונטיינר, הוא שהפורמט לבנייתו (Dockerfile) קל להבנה ולשימוש. במקרים רבים, אנחנו יכולים להשתמש ב-Dockerfile בדיוק בכדי להגן על עצמנו מקונטיינרים זדוניים.
אז איך נוכל להגן על הקונטיינרים שלנו? די פשוט. כמעט בכל קונטיינר שמופיע ב-Repository ציבורי (כמו Docker Hub) אנחנו נמצא קישור ל-Github שמכיל את קוד ה-Dockerfile. נוריד את קבצי ה-Dockerfile וקבצים אחרים מה-git (פקודת git checkout) ואז נבנה את הקונטיינר מחדש. היתרון הגדול בבניית הקונטיינר מחדש הוא שחבילות רבות מקבלות עדכוני אבטחה, וקונטיינרים הזמינים ב-repo ציבורי לא תמיד מעודכנים. כך נוכל לבנות אותם עם הגרסאות המעודכנות ועם תיקוני האבטחה. דבר חשוב נוסף - החבילות מגיעות ממקום ידוע (אם משתמשים ב-spacewalk – אז הם מגיעים משרת פנימי בחברה שהוריד את החבילות ממקור בטוח), ואפשר כמובן לאחסן את אותם קונטיינרים ב-Registry פרטי פנימי (הנה הוראות איך להקים אחד באובונטו).
במקרים מסויימים, ה-Dockerfile כולל פקודת COPY וקבצי המקור אינם נמצאים ב-repo באותו git. התייחסו במשנה זהירות לקונטיינרים מסוג זה. במקרים כאלו אם אתם ממש צריכים את הקונטיינר הספציפי, אולי כדאי להריץ עליו סריקה עם אחד הכלים שהזכרנו לעיל.
לסיכום
בלא מעט מקרים, מאוד מפתה לחסוך עבודה רבה בהתקנה של אפליקציה/פלטפורמה – ורבים נוטים פשוט לבצע docker pull ולמשוך קונטיינר שכבר כולל את ההתקנות וההגדרות.
אמנם זה יכול להיות רעיון טוב בתיאוריה, אבל חשוב לזכור שיש קונטיינרים "תמימים" עם קוד זדוני שיכולים לגרום נזק או "לשתות" משאבים לצרכי כריית מטבעות או גניבת מידע. לכן, אני ממליץ לבנות אותם מחדש ובמקרה הצורך להשתמש בכלי סריקה טוב.
מאת: חץ בן חמו, יועץ ומומחה בנושאי ענן, וירטואליזציה, לינוקס, אחסון ועוד
רוצים להתעדכן בתכנים נוספים בנושאי ארכיטקטורת ענן? הצטרפו לפורום המקצועי של IsraelClouds בתחום > להרשמה
יותר ויותר חברות כיום מבינות את היתרונות הגלומים בקונטיינרים מבחינת scaling, צריכת זיכרון, ניהול הקונטיינרים ועוד. אולם, כמו עם כל טכנולוגיה חדשה, תמיד יהיו גורמים המעוניינים להשתמש בטכנולוגיה למטרות נזקים, הונאה וניצול משאבים. המשמעות היא שאנשי אבטחת מידע רבים יהיו מעוניינים (ובצדק) לדעת כיצד להתגונן נגד איומים פוטנציאליים כאלו.
רבים ירוצו כמובן לכלים המסחריים שמציעים שירותי סריקה ואזהרה נגד קונטיינרים זדוניים או קוד זדוני שרץ בקונטיינר, אבל זה לא תמיד מספיק.
אז מה הבעיה?
הבעיה עם כל הפתרונות הללו היא שהם מבוססים על כל מיני חתימות, זיהויי שינויים וכו', כמו אנטי וירוסים אחרים, וזה לא תמיד עוזר. כיום, לא קשה לכל מיני פורצים לבנות קונטיינרים נגועים בסקריפטים משלהם המקודדים (נניח בבסיס 64) שלא יזוהו על ידי אותם כלים אוטומטיים, וכאן כדאי אולי להיזכר במתודות של איך בנויה הפצת לינוקס ולהשתמש במתודות אלו.
הפצת לינוקס כמו רד-האט, CentOS, SuSE, אורקל לינוקס, דביאן, אובונטו וכו', נבנית בכל פעם מאפס על ידי הידור קוד של חבילות שונות עד שנבנית הפצה בסיסית לחלוטין.
להפצה הזו המערכת תעשה Boot, ומשם היא תמשיך להדר את הקוד של כל החבילות שונות (ברד-האט, או כל הפצה מבוססת RPM יש חבילות מיוחדות שנקראות SRPM, שמכילות קוד מקור + טלאים וסקריפטים כדי לקמפל אותה). ההפצה כוללת חבילות שונות מבחוץ שעברו בדיקת קוד בתוך יצרן ההפצה, וברוב המקרים גם שינויים על מנת לרוץ על אותה הפצת לינוקס ספציפית.
כשזה מגיע לעדכונים, יש הרבה אתרים שונים שהם בעצם אתרי "מראה" של אתר יצרן ההפצה – המכילים את העדכונים. כל חבילות העדכונים חתומות בחתימה חזקה על ידי יצרן ההפצה (או יצרן ה-Repository) ואתרי המראה אינם כוללים את החלק הפרטי של המפתח. אם מישהו פורץ לאתר מראה או לאתר יצרן ההפצה וינסה להחליף חבילות קיימות בחבילות נגועות, כל מי שינסה להתקין את החבילות הנגועות פשוט לא יצליח, הואיל והמערכת תעצור את ההתקנה ותוציא פלט שגיאה שהמפתח הציבורי המוזכר בחבילה אינו תואם למפתח של ה-REPO. במקרים ויצרן ההפצה חושד שהמפתח נגנב, הוא מייצר מפתח חדש, חותם מחדש על החבילות שקיימות באתר,מפיץ אותו ומודיע ללקוחותיו על כך (הכנסת המפתח החדש היא קלה, ובדרך כלל מדובר בפקודה אחת).
בחברות גדולות (כמו בנקים וכו') בדרך כלל לא פותחים את חומת האש להורדת חבילות מיצרן ההפצה באופן ישיר, אלא משתמשים בתוכנת-אמצע (Middleware) כמו Red Hat Satellite,בכדי להתקין את ההפצות ועדכונים על שרתים ומחשבים נוספים. ברוב המקומות האחרים שאינם עובדים ישירות מול רד-האט או עובדים עם הפצות אחרות, יש כלי חינמי אחר, ובקוד פתוח כמו SpaceWalk המאפשר להפיץ פנימית בשרתי החברה (ובחשבון הפרטי בענן הציבורי של החברה) עדכוני תוכנה בצורה מאובטחת ומוצפנת (אפשר לשלב בתוך הכלי גם את ה-CA של החברה).
ובחזרה לקונטיינרים
אחד היתרונות בבניית קונטיינר, הוא שהפורמט לבנייתו (Dockerfile) קל להבנה ולשימוש. במקרים רבים, אנחנו יכולים להשתמש ב-Dockerfile בדיוק בכדי להגן על עצמנו מקונטיינרים זדוניים.
אז איך נוכל להגן על הקונטיינרים שלנו? די פשוט. כמעט בכל קונטיינר שמופיע ב-Repository ציבורי (כמו Docker Hub) אנחנו נמצא קישור ל-Github שמכיל את קוד ה-Dockerfile. נוריד את קבצי ה-Dockerfile וקבצים אחרים מה-git (פקודת git checkout) ואז נבנה את הקונטיינר מחדש. היתרון הגדול בבניית הקונטיינר מחדש הוא שחבילות רבות מקבלות עדכוני אבטחה, וקונטיינרים הזמינים ב-repo ציבורי לא תמיד מעודכנים. כך נוכל לבנות אותם עם הגרסאות המעודכנות ועם תיקוני האבטחה. דבר חשוב נוסף - החבילות מגיעות ממקום ידוע (אם משתמשים ב-spacewalk – אז הם מגיעים משרת פנימי בחברה שהוריד את החבילות ממקור בטוח), ואפשר כמובן לאחסן את אותם קונטיינרים ב-Registry פרטי פנימי (הנה הוראות איך להקים אחד באובונטו).
במקרים מסויימים, ה-Dockerfile כולל פקודת COPY וקבצי המקור אינם נמצאים ב-repo באותו git. התייחסו במשנה זהירות לקונטיינרים מסוג זה. במקרים כאלו אם אתם ממש צריכים את הקונטיינר הספציפי, אולי כדאי להריץ עליו סריקה עם אחד הכלים שהזכרנו לעיל.
לסיכום
בלא מעט מקרים, מאוד מפתה לחסוך עבודה רבה בהתקנה של אפליקציה/פלטפורמה – ורבים נוטים פשוט לבצע docker pull ולמשוך קונטיינר שכבר כולל את ההתקנות וההגדרות.
אמנם זה יכול להיות רעיון טוב בתיאוריה, אבל חשוב לזכור שיש קונטיינרים "תמימים" עם קוד זדוני שיכולים לגרום נזק או "לשתות" משאבים לצרכי כריית מטבעות או גניבת מידע. לכן, אני ממליץ לבנות אותם מחדש ובמקרה הצורך להשתמש בכלי סריקה טוב.
מאת: חץ בן חמו, יועץ ומומחה בנושאי ענן, וירטואליזציה, לינוקס, אחסון ועוד
רוצים להתעדכן בתכנים נוספים בנושאי ארכיטקטורת ענן? הצטרפו לפורום המקצועי של IsraelClouds בתחום > להרשמה
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר