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

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

הדבר הראשון שצריך להבין לגבי הקשחות, הוא שתלויות חיצוניות לא תמיד עוזרות (או לא עוזרות בצורה משמעותית). ה- 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 כי ספק הענן לא מגן על שום דבר שיש לכם בענן. אלמנט חשוב נוסף הוא שמירה על שיתוף פעולה פורה בין מי שאחראי על תהליך ההקשחה לבין הצוותים השונים - על זה דברים יפלו או יקומו.

‍