השאלה שכל ארגון שואל תמיד…למה צריך NAC – Network Access Control ?
עד לא מזמן , בכל ארגון היה קורה האירוע הבא..
אנשי מכירות ממוצרים שונים מגיעים לפגישה להצגת מוצר כלשהו, שולפים את המחשב הנייד שלהם עם כבל רשת, מחברים את הכבל לנקודת הרשת ויוצאים לאינטרנט. במקרה כזה הארגון חשוף להידבקות מסוס טרויאני או כל ווירוס אחר.
במקרה אחר, חיבור מחשב אורח עשוי לספק גישה לא מורשית למידע ארגוני ולהוביל לזליגת מידע רגיש.
למרות שכיום התופעה הזאת פחות נפוצה כיוון שאנשי מכירות יכולים להתחבר לרשת דרך הסלולר, עדיין יש צורך בכלי בקרת גישה לרשת.
מזה שנים רבות קיים תקן IETF לבקרת חיבור מחשבים לרשת – לתקן קוראים 802.1x , לתקן ישנה הרחבה (EAP) המאפשרת זיהוי מחשב לא רק עפ”י כתובת MAC אלא גם על סמך תעודות דיגיטליות באופן המקשה מאוד על עקיפת הפתרון ע”י זיוף כתובת MAC . להלן איור המתאר את הפתרון על רגל אחת.
החסרון של פתרון זה שהוא מתאים רק לרכיבי מחשוב המסוגלים לשמור תעודות דיגיטליות. כמו כן, מבחינת שרידות הפתרון אינו מאוד יציב ומידי פעם נוצרות תקלות המשביתות משתמשים. הפתרון הזה הוא אכן פתרון “זול לעניים” .
למרות שפתרון (Network Access Control) NAC נחשב פחות חזק מפתרון EAP הוא מספק, כאמור, פתרון להתקנים שונים (כגון מדפסות, בקרי כניסה) שפתרון EAP לא תומך בהם. מוצרי NAC מתקדמים מספקים כיום הגנה בפני מספר סיכונים:
1. התחברות לא מורשית של אורח לרשת החברה
2. חיבור מחשב ארגוני (או מחשב אורח מורשה לחיבור) לרשת כאשר המחשב אינו עומד במדיניות האבטחה ומסכן את הרשת (כגון אנטי וירוס לא מותקן)
3. חיבור מחשב מורשה כאשר התקנים מסוימים פתוחים כגון USB או WiFi
4. שליחת התראות ל – SIEM או במייל( כאשר מחשב שאינו מורשה מחובר לרשת)
אז הצגתי את הגורמים המניעים ארגונים להכניס מערכת לבקרת גישה לרשת . בכוונתי להציג אתגרים בהטמעת מערכת כזו, שכן עד שלא חווים פרויקט כזה, לא מבינים עד כמה ההיערכות מראש חשובה. אף איש מכירות (וגם לא רוב היועצים) יכין את מנהל אבטחת המידע (וגם את אנשי התשתיות) לאתגרים האלה. להיפך, הם ימכרו לכם “הגדרת מערכת בתוך שבועיים”.
אך לפני שאני מפרט את האתגרים, אציג בקצרה כיצד מערכות Network Access Control מאמתות רכיבים ומאפשרות להם להתחבר לרשת. זה לא יהיה הסבר מלא על הטכנולוגיה. יש מספיק חומרים על כך באינטרנט.
מערכות NAC יכולות לזהות ולאמת רכיבים המנסים להתחבר לרשת במספר שיטות. לאחר אימות הרכיב, המערכות יחליטו איזה סוג גישה לרשת הן מאפשרות. שתי הגישות הנפוצות הינן גישה רגילה ומלאה לרשת (כמו כל מחשב ארגוני) או ‘העברת’ הרכיב ל – VLAN מוגבל (“אורחים”) עד לתיקון פרמטרים מסוימים. כעת נבחן מספר שיטות אימות של הרכיבים (לא פירטתי את כולן כיוון שזה משתנה מיצרן ליצרן).
1. רכיב המוגדר ב – AD הרוב המוחלט של מחשבי קצה ושרתים ארגוניים, מוגדרים כחברים ב – AD לכן, בדיקת האימות העיקרית תוודא שהרכיב הנבדק אכן חבר בדומיין. הרי לא סביר להניח שמחשב זר יהיה חבר בדומיין (אלא אם כן מסיבות היסטוריות הוא חובר בעבר).
2. ‘סיסמא’ ב – SNMP ברכיב רשת שאינו מנוהל, ניתן להגדיר Community String הידוע רק למנהל הרשת ובכך לאמת שהרכיב הינו ארגוני, ע”י תשאולו בפרוטוקול SNMP . חשוב לעשות שימוש בגרסה SNMP גירסה 3 שמצפינה את הסיסמא בתווך התקשורת כדי שלא ניתן יהיה ליירט אותה ע”י כלי האזנה (Sniffer) חשוב לדעת שגורם זר המנחש את הסיסמא יוכל להתחזות לרכיב רשת מורשה.
3. חתימת מערכת הפעלה (OS) כיוון שלכל רכיב יש חתימת OS . ניתן לבדוק האם הרכיב המתחבר לרשת הינו בעל מערכת הפעלה מורשית. כמובן שזו בדיקה חלשה משתי סיבות: גם למחשב אורח יכולה להיות חתימה זהה למחשבים הארגוניים, יחסית קל לזייף OS Fingerprint ולהתחזות לרכיב רשת מורשה לחיבור.
4. פורטים בשימוש: בקר תקשורת כלשהו ידבר בד”כ בפורט אחד ספציפי או בטווח קטן של פורטים. במקרה כזה, אפשר לזהות רכיב על סמך פורטים פתוחים (בלבד) ובכך להניח שמדובר ברכיב מורשה. זו שיטה טובה גם למנוע מחשב מתחזה מלתקשר בתוך הרשת בפורטים המאפשרים לו גישה מלאה למשאבי רשת.
5. תוכנות מותקנות: ניתן לבדוק האם תוכנה מסוימת ורצוייה מותקנת על רכיב. התוכנה יכולה להיות יישום ארגוני שלא יימצא על מחשבים אורחים ואפילו לא על מחשבים של פורצים (אלא אם כן הם אספו מידע מראש).
6. כתובות MAC כמובן שניתן להשתמש, במקרים מסויימים, בשיטה מאוד לא בטוחה, אך נפוצה, של זיהוי כתובת MAC של הרכיב בכדי להניח שמדובר ברכיב מורשה.
מומלץ מאוד לשלב בין מספר שיטות אימות. בפרט כאשר רכיב אינו חבר בדומיין. אך גם כאשר רכיב שייך לדומיין, כדאי להוסיף בדיקות נוספות כדי לחזק את האימות. כעת נותר להבין מדוע בכל זאת לא מעט פרויקטים של הטמעת NAC נכשלים או מתעכבים מאוד בהטמעתן.
הטמעת מערכת NAC נחשבת מורכבת ולוקחת זמן רב. כבר ציינתי בעבר שהתקנות הבזק שאנשי המכירות מצד הספקים מציעים, טובות רק למצגות. בפרויקט NAC זה נכון על אחת כמה וכמה. אל תתנו לאף אחד למכור לכם הטמעה מהירה. הגורמים העיקריים לכך אינם נובעים מהמערכת שתבחרו, אלא דווקא מרכיבי הרשת שלכם. הצגתי כאן פרטים על שיטות אימות של רכיבי רשת ועל הצורך בפתרון NAC . הקושי העיקרי בהטמעת מערכת כזו נובע משיטת האימות של הציוד הרב והמגוון המותקן ברשתות שלנו. השורות הבאות יפרטו בקצרה מספר סיבות עיקריות לכך.
ניהול רכיבים ב – AD לכאורה אין קל מזה. כל המחשבים מנוהלים ב – AD, לא? זהו, שלא. אתם לא יודעים כמה מחשבים (תחנות קצה ושרתים) אינם מנוהלים בדומיין עד שאתם מגיעים לפרויקט כזה. הקושי כאן הוא לא לאתר אותם, כי זה מערכת NAC מקטלגת בקלות. הקושי הוא לאתר פיזית את תחנות הקצה (בהנחה שיש לכם סניפים מרוחקים והרבה שטח משרדי) והקושי הוא למצוא את המשאבים הנדרשים (טכנאים וזמן) לדאוג להכנסתם לדומיין והחלת ה – GPO עליהם. זה משאב שלא מתכננים מראש מחוסר ידיעה.
אימות מבוסס SNMP/SSH: אתם תרצו לאמת ציוד שאינו מנוהל בדומיין, ע”י מנגנון אחר כגון SNMP או SSH ,הבעיה היא שתגלו שחלק מרכיבי הרשת (מדפסות מרכזיות, ציוד תקשורת ישן ועוד) אינו תומך בגרסה מאובטחת SNMP v3 אלא בגרסה ישנה יותר, לא מאובטחת. לפעמים שדרוג Firmware יעזור ולפעמים רק החלפת רכיבים בחדשים.
ציוד תקשורת חלש: בארגונים עם רשת מורכבת (או מספר רשתות) יציעו לכם לאכוף חסימה על רשתות וסגמנטים ע”י Port Mirroring בציוד תקשורת. בלא מעט מקרים, אנשי התקשורת יסרבו לחבר התקני האזנה (Mirroring) מחשש לפגיעה קשה בביצועי ציוד התקשורת.
כוח אדם מיומן: אחד המשאבים החסרים בהרבה ארגונים זה אנשי תקשורת וסיסטם מיומנים שילוו את הפרויקט לכל אורכו (לפעמים במשך שנה). הספק המטמיע מביא את המהנדס שלו לצורך התקנת המערכת, אך מצד הארגון חסרים המשאבים לטיפול ברכיבי הרשת.
