"מאחורי הקלעים" של אבטחת שרתים

הנה סיטואציה שמתרחשת אחת לכמה זמן: לקוח פוטנציאלי (בין אם זו חברה גדולה שמעוניינת לאבטח את השרתים שלה או חברה יותר קטנה שמעוניינת להוציא Appliance או בחברות שעוברות לענן ציבורי/פרטי) פונה אליי ומעוניין ב"אבטחת שרת". חלקם מתארים את זה בדיוק כמו שכתבתי וחלקם מעוניינים באבטחה שתעמוד בפני כלים שהם ישתמשו לאתר חורים ופריצות.

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

על מנת לאבטח שרת, צריך ללכת לפי סטנדרט מסוים. הסטנדרט הידוע והמקובל ביותר הוא סטנדרט CIS (למעוניינים לקבל יותר פרטים, הנה פוסט שכתבתי בעבר בנושא כאן בבלוג). סטנדרט זה מתעדכן כל הזמן ונוספים אליו הפצות לינוקס שונות ומערכות הפעלה אחרות ובנוסף גם אפליקציות שונות. לכל הפצה יש קובץ PDF עם מאות עמודים המחולקים לסעיפים, תת-סעיפים, תת-תת-תת-סעיפים וכו'. חלק מהדברים שכתובים הם בגדר "חובה" וחלק מהדברים הם בגדר המלצה, לפי רמות שונות.

רבים נוטים לחשוב כי מדובר בד"כ באיזה שהוא סקריפט או אפליקציה שמקימים אותה על שרת, היא עושה שינויים, קצת עושים בדיקות וזהו – עניין של יום יומיים עבודה ונגמר העניין.

אז זהו, שזה הפוך.

טכנית, אין לי בעיה להכין Image של הפצת לינוקס שהלקוח רוצה עם כל ההקשחות. הבעיה היא שברגע שהמפתחים ואנשי הסיסטם יתחילו להשתמש ב-Image הזה, סביר להניח שאף אחד שם לא ירצה להשתמש בה. הדברים הרבה יותר מדי נעולים, הביצועים יורדים, המון קבצי Log שלאף אחד אין מושג מה לעשות איתם בחברה ובקיצור – תוך זמן קצר מישהו בחברה ישנה את ה-Image כדי שיתאים לצרכי החברה. אחרי הכל, אין כמו הטיעון "השרת עובד בחצי מהמהירות הרגילה שלו" כדי לשכנע את ההנהלה/IT לשנות דברים.

לכן, הקשחות בד"כ נעשות עם עבודה צמודה למחלקת אבטחת המידע, ומחלקת אבטחת המידע חייבת להפגין גמישות בנקודות שונות על מנת שיהיה אפשר להשתמש במערכת מוקשחת. גם הצד שמבצע את ההקשחה צריך לגלות גמישות ויצירתיות בפתרונות דברים שאבטחת המידע תתעקש עליהם, וכל התהליך הזה – לוקח זמן (סתם לדוגמא: סטנדרט  CIS לאובונטו 14 מכיל יותר מ-500 עמודים!).

אחרי שעוברים את המשוכה הזו, צריכים להחליט את מה מקשיחים. התשובה לשאלה כזו בד"כ תיענה ב-"את הכל", וכאן מתחילה בעיה. בחברה קטנה עם 4-5 מכונות לינוקס העניין פשוט וקל, אותו דבר בייצור Appliance, אבל כשיש לחברה מאות או אלפי מכונות VM שמריצות לינוקס, הבעיה הרבה יותר מורכבת: לכל גירסת הפצת לינוקס יש לממש את סטנדרט ה-CIS שלה ברובו מחדש, כך שמדובר פה על השקעה שיכולה לקחת מספר חודשים. הסטנדרט שונה בין CentOS לבין SuSE לבין אובונטו ורק חלק קטן מהסטנדרטים חופף בין ההפצות. כמובן שאם כל המכונות שלכם מריצים את אותה הפצת לינוקס ואותה גירסה – אז חייכם דבש 🙂

כאן הנקודה שהחברה תצטרך להחליט אם להשקיע במספר הקשחות, או שלהתחיל פרויקט מעבר מהפצות לינוקס ישנות להפצת לינוקס אחת עדכנית. זו החלטה שאינה קלה מכיוון שהיא מצריכה התעסקות עם מערכות Legacy שלא תמיד קיימות להפצות לינוקס עדכניות ויכול להיות שיש גרסאות עדכניות של אפליקציות להפצה עדכנית אולם אם התוכנה מסחרית, יכול להיות שהחברה תצטרך לרכוש שדרוג, כך שאלו החלטות שההנהלה וה-IT צריכים לקחת בחשבון (וכמובן את כל עניין ההגירה).

מכאן אנו מגיעים לאתגר חדש שארגונים רבים לא תמיד לוקחים בחשבון: נניח ששכרת את שרותיי, ביצעתי לכם את העבודה, כל הגורמים בחברה מרוצים, החשבוניות שולמו וכל אחד ממשיך בדרכו. יש לכם בחברה אפילו מערכת שמטמיעה עדכוני אבטחה גם ל-Windows וגם ללינוקס. אז אתם "מכוסים", לא?

זהו, שלא ממש..

אחת הבעיות המרכזיות כשזה מגיע לאבטחת שרתים, היא בעיית חורי אבטחה שמתגלים כמעט כל יום. העדכונים לחורי האבטחה מגיעים רק לאחר מספר ימים (במקרה הטוב) או כמה שבועות (במקרה הפחות טוב) או אפילו חודשים (אהלן מיקרוסופט!). מה עושים עד אז? בד"כ יצרניות ההפצה יתנו הוראות מניעה זמניות כיצד לפתור לבינתיים את הבעיה. העניין הוא שההוראות מגיעות באנגלית ואולי עם דוגמא לסקריפט BASH או Python. איך בדיוק תפיץ את זה למאות שרתים? אתה כמובן יכול לבנות חבילה (RPM או DEB), להוסיף ל-REPO מקומי ולהפיץ זאת דרך תוכנת העדכונים שלכם, אבל תצטרכו איכשהו לעשות לתיקון הזמני Roll Back וזה לא ממש קל, במיוחד אם חור האבטחה נוגע לאפליקציה שיש לה המון תלויות ואז מדובר במתכון בטוח לכאב ראש פר שרת.

לכן – אחד הדברים שחייבים להכניס לפני או במקביל להקשחת שרתים – זה פתרון אוטומציה, בין אם מדובר ב-Chef/Puppet או Ansible (הפייבוריט שלי). כך כשמתגלה חור אבטחה ויש הוראות מניעה, ניתן לבנות קומפוננטה קטנה שתרוץ עם מערכת האוטומציה ותתקן זמנית את הדברים ולאחר מכן לפני התקנת העדכון הרשמי, יבוצע Roll Back של אותה קומפוננטה ואז יכנס התיקון הרשמי כחבילה רשמית מיצרן ההפצה.

עוד נקודה אחת הקשורה להקשחת שרתים (נקודה שלא קל לי לאמר אותה הואיל והיא כמו חיתוך הענף שעליו אני יושב, אך אני מעדיף להיות כן ולאמר את האמת) – בעיית ה-Appliances. חברות רבות מעדיפות לרכוש פתרונות תוכנה כקופסאות פיזיות או Appliance וירטואלי. אחרי הכל, בשביל הקופסאות האלו אינך צריך איש לינוקס, הכל נעשה דרך דפדפן והחיים די קלים, לא? הצרה היא שבמקרים רבים העדכונים לקופסאות ול-Appliances הללו ניתנים במשך עד שנתיים שלוש ואחרי זה מומלץ שתקנה גירסה משודרגת. לא קנית? נשארת עם מכונה שאבטחת המידע עליה לוקה בחסר כי היצרן אינו מוציא עדכונים. לכן אני ממליץ – ראית Appliance שאתם רוצים? בקשו מהחברה את הפתרון להתקנה על לינוקס שאתם תקימו בתשתית שלכם.

לסיכום: הקשחת שרתים אינו דבר קל, הוא ארוך, מחייב עירוב גורמים נוספים בחברה (מנהלי צוותי פיתוח, אבטחת מידע, הנהלה וכו'). יש לשקול מעבר להפצת לינוקס אחידה ובהזדמנות זו להיפטר מהפצות ישנות "מתות". צריך לעשות את העבודה בשיתוף פעולה, להמתין לפידבק ואם דברים אינם מתאימים לסטנדרט – אז לשנותם. הקשחת שרתים זה דבר טוב אך החלק החשוב שצריך להיות צמוד אליה זה פתרון אוטומציה, לא רק להפצת עדכונים אלא גם לשינויים ספציפיים שצריכים לעשות במכונה מכל מיני סיבות.

Comments

comments

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *