03
יול
13

שיטות אימות ב – NAC

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

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

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

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

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

חתימת מערכת הפעלה (OS): כיוון שלכל רכיב יש חתימת OS, ניתן לבדוק האם הרכיב המתחבר לרשת הינו בעל מערכת הפעלה מורשית. כמובן שזו בדיקה חלשה משתי סיבות: גם למחשב אורח יכולה להיות חתימה זהה למחשבים הארגוניים, יחסית קל לזייף OS Fingerprint ולהתחזות לרכיב רשת מורשה לחיבור.

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

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

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

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

מודעות פרסומת

1 Response to “שיטות אימות ב – NAC”


  1. 1 zeev
    14/11/2017 ב- 11:53

    בהמשך לפוסט בנודע להזדהות אימות רכיבים ללא OS או שלא בדומיין ושימוש בפרוקטוקולים מוצפנים יותר ,

    לדעתי נדרש להתייחס לעובדות הבאות, במיוחד בייחס לאימות ע"י רכיבים ללא התקנת סוכנים או ליכולת המימוש ב 802.1X

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

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

    תמיכה בפרוטוקול HTTPS ע"י רכיבי הקצה – היא גרסה מאובטחת יותר לשירותי גישה WEB לרכיבי התקשורת שמטרתה להצפין את התעבורה אך לא לספק שירותי אימות חד ערכי אל הרשת .

    לסיכום בכל שלושת השיטות:

    1. או הנתונים או התעבורה מוצפנים ומונעים MITM ( אם חולשות כאלו ואחרים )
    2. הם פרוטוקוליי תקשורת ולא פרוטוקול הזדהות
    3. לכל תוקף פוטנציאלי המתממשק למתגי הקצה ברשת במקום הרכיב הקיים , יש את היכולת להתחקות מחד גיסא , ולחשוף את השאילתות המגיעות מהשרת ב CLEAR TEXT מאידך גיסא.
    4. מטרתם להגן יותר על רכיב התקשורת ולא על בקרת הגישה לרשת
    5. שימוש בפרוטוקול אלו לטובת תשאול רכיב הקצה , מאפשר ווידוי ברמה יותר טובה מ MAC \ NIC VENDOR , ע"מ לשים את הרכיב בקטגוריה אליה הוא משתייך ברמת מערכת ה NAC , אך עדיין בעל חולשות חשיפה הדורשות בקרות מפצות .
    6. כל רכיבי התקשורת שאינם מתבוססים על חתימה דיגיטאלית על הרכיב , לא יכולים לקבל הרשאות גישה וחוקה כמו תחנת עבודה המשויכת לדומיין ודורשים בקרות מפצות מורכבות או מורכבות פחות .
    7. כל רכיבי ה IOT מוגדרים כרכיבים שאינם בעליי יכולת ניהול ואינם מאפשרים התקנות סוכנים מקומיים כגון EPS \ Verdasys \ AV \ וכדו' המסכנים את רשת לאומי .

    אשמח לקבל את דעתכם מקצועית


להשאיר תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת /  לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת /  לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת /  לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת /  לשנות )

w

מתחבר ל-%s


יולי 2013
א ב ג ד ה ו ש
« מאי   אוג »
 123456
78910111213
14151617181920
21222324252627
28293031  
מודעות פרסומת

%d בלוגרים אהבו את זה: