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

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

הדבר הראשון שצריך להבין לגבי ההקשחות זה שתלויות חיצוניות לא תמיד עוזרות או לא עוזרות הרבה. ה-Firewall שיש בחברה לדוגמא כמעט ולא רלוונטי לנושא. כן, הוא יכול לזהות שכתובת IP מסויימת מנסה להיכנס, דרך פורט מסוים, אבל ה-Firewall לא יודע ולא יכול לדעת אם הפורץ הצליח להיכנס, ואם הצליח, באיזה קבצים הוא נגע. בלינוקס יש דבר שנקרא access time לדוגמא שיכול לאמר איזה משתמש נגע באיזה קובץ ומתי, אבל אם הפורץ כבר יצא והמשתמש הלגטימי (עם אותו username) נכנס ועבר על הקבצים, אז הרבה פעולות פורנזיות לא יעזרו הרבה לדעת מי נכנס ובמה הוא נגע (מה עוד שבימינו פורצים רציניים משתמשים ב-VPN ושלל טריקים נוספים להחביא את זהותם כך שמאוד קשה לדעת מי בדיוק נכנס). ישנם כלים אחרים שעובדים עם חתימות שונות כדי לזהות כניסות דרך שיטות ידועות וזה עוזר, אבל שוב – לא תמיד זה יעזור ותיכף ארחיב על כך.

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

אחת העבודות היותר מורכבות לפני שמגיעים למימוש CIS Benchmark היא עניין החבילות תוכנה שמותקנות על השרת. התקנת גירסת CentOS 7 לדוגמא בתצורה מינימלית מתקינה בסביבות 300+ חבילות. זה שאני יכול לבטל שרותים זה נחמד, אבל פורץ רציני יכול להפעיל את השרותים מחדש ברגע שהוא נכנס, ולכן העבודה הראשונית היא "כיסוח" של החבילות המותקנות שאין צורך בהן ובמקרים מסויימים קימפול מחדש של חבילות מסויימות ויצירת חבילות חדשות יותר מצומצמות על מנת להקטין כמה שיותר את וקטור התקיפה, ביטול גישת אינטרנט להתקנת חבילות ועוד ועוד. רק לאחר מכן אפשר לעבור לשלב מימוש ה-CIS Benchmark.

עוד נקודה שרבים שוכחים היא פורטים 80 ו/או 443. בד"כ הם פתוחים לעולם, וכאן גם מתרכזת בעיה רצינית: קיימים לא מעט סקריפטים שיתנו מעין shell גם אם ל-user שמריץ את שרת ה-web אין בכלל גישת shell מכיוון שלמודולים שרצים תחת אותו שרת web יש אפשרות לבצע דברים שונים הקשורים ל-shell. דוגמא נפוצה עם PHP היא p0wny@shell ומשם אפשר לבצע נזקים רבים, ולכן צריך לקחת בחשבון מה רץ בשרת ה-web ומה רץ "מאחורה", והכי חשוב – בדיקת ההזנה של המידע המגיע מהאינטרנט אל שרת האפליקציות לדוגמא (זהו החלק שקשור לצוות הפיתוח או מי שמריץ pen-testing).

עוד נקודה חשובה היא היכולת לזהות פורנזית אם מישהו פרץ – במה הוא נוגע. נכון, סביר להניח שחברה רצינית תכניס פתרון IPS/IDS כלשהו, אבל פתרון כזה אינו מסייע אם הפורץ הצליח להיכנס ולפתרון ה-IDS/IPS אין מושג ירוק מה הפורץ עושה בשרת עצמו. אפשר כמובן לגלות עם ה-IPS/IDS אם הוא מעלה/מוריד קבצים לשרת שהוא פרץ, אבל מה אם הפורץ מחליט למחוק קבצים? לשם כך יש צורך בפתרון שהוא בעצם Host IDS (כלומר: HIDS) שיודע לזהות את הדברים ולרשום במה הוא נגע, איזה process הוא הפעיל ועוד ועוד. שילוב פתרון כזה אפשרי אבל מצד שני יכול גם להאיט את ביצועי השרת ולכן אם הלקוח רוצה בפתרון כזה, יש להיערך לכך מבחינת שרתים שנותנים שרות, היכן יאוחסן המידע מהניטור ועוד ועוד.

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

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

על הקשחות תחנות עבודה/דסקטופ ושרתים

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

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

אבל חשוב להבין כמה נקודות (ואני מדבר הפעם על Windows, בלינוקס החיים קצת יותר קלים):

  • אנשים מסתכלים על המאמרים של מיקרוסופט וחושבים שעניין האבטחה זה כמו שמיקרוסופט מפרסמת – 3-5 עמודים בלינקים שונים ואפשר לסמן ✔ על הנושא. זהו, שזה לא. אבטחת מידע רצינית בין אם זה על דסקטופ או שרת היא הרבה יותר מורכבת ואתם מוזמנים להעיף מבט על ה-CIS Benchmark שנחשב ה-דבר בהקשחה. על Windows 10 בלבד מדובר על 942 עמודים. Windows Server 2012 R2? זה 732 עמודים. (ועם CIS זה הולך לפי ניקוד לגבי השינויים שעושים, כל דבר מקבל ניקוד שונה)
  • אין "הקשחה אחידה". איש אבטחת המידע רוצה את מקסימום האבטחה, איש ה-IT רוצה פחות כדי שהוא אשכרה יוכל לעבוד בצורה נוחה, ולכן זה יקח לא מעט זמן לעבור על הנקודות ולבצע את הדברים.
  • "חיתוך פינות" – הנה משהו שאני שומע שוב ושוב מלקוחות פוטנציאליים: "כבר עשית את רוב העבודה ללקוחות קודמים, תביא את זה, נעשה תיאומים ונגמור עניין". הבעיה – עדיין לא פגשתי לקוח שמוכן שקוד או סקריפטים שכתבתי עבורו – יעברו הלאה ללקוחות אחרים, גם אם מדובר בדברים שכתבתי בביתי עם ה-LAB שלי. לקוחות רוצים משהו פשוט: שילמנו? זה נשאר אצלנו וזה לא עובר לאף לקוח, אז צריך לכתוב מחדש דברים שוב ושוב.
  • אוטומציה – האם אפשר לעשות את הדברים בצורה אוטומטית פחות או יותר? (להריץ אוטומציה בלי הגדרות פר שרת ששונים מאחד לשני יוביל להשבתה של המערכות שלכם. ראיתי כבר מישהו שניסה זאת פעם) – בהחלט, אבל זה דורש עבודה של 2-3 חודשים של כתיבה ומימוש כל הסעיפים והגדרת קובץ שבו יהיה אפשר לבחור מה יהיה enabled ומה יהיה Disabled, וכן, אני מדבר על אוטומציה ל-Windows עם דברים כמו Ansible.זו עבודה שאינה קלה שמצריכה המון snapshots הואיל וכל מימוש סעיף ובחינתו מצריך snapshot ו-rollback לאחר הבדיקה.
  • תחנות עבודה / דסקטופ – אפשר גם לעשות שם אוטומציה בנוגע להקשחה אולם עדיף לעשות Image מאסטר ולשכפל בין התחנות, תוך יצירת שינויים בהתאם לתפקיד התחנה/דסקטופ.
  • רגולציה / Conformance tests – יש הבדל ענק בין חברה לייבוא שימורים לבין חברת ביטוח או בנק שרוצים הקשחות. במקרים של הגופים הגדולים, חוץ ממחלקת אבטחת מידע צריך לערב את המחלקה שאחרית על מימוש רגולציות ו-Conformance tests (ראיתי מקרה שעבודה ענקית של הקשחה בוטלה ברגע האחרון לפני מימוש רק כי לא עירבו את המחלקה הזו. עבודה עבורי של חצי שנה נעלמה במחי מייל אחד מאותה מחלקה).
  • שילוב הקשחה של Windows ו-Linux. רעיון נחמד, לא ניתן לביצוע מכיוון שמדובר במערכות לגמרי שונות שמצריכות סקריפטים שונים לחלוטין.

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