תחום אימות ה-VPN: איזה מרחב שמות של חשבונות מנצח?

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

מה התחום בורר

שער מקבל שם משתמש וחייב להחליט היכן לבדוק אותו. התחום הוא החלק בשם הזה, או המאפיין שלצידו, שבוחר את מסד הנתונים: ספרייה, מאגר RADIUS או קובץ חשבונות מקומי. שירות NPS של מיקרוסופט קורא לזה שם תחום ומנתב באמצעותו בקשות חיבור, בעוד שמזהה הגישה לרשת מסוג EAP נושא את אותו רעיון כסיומת אחרי סימן ה-@ ב-RFC 7542. שניהם בוררים, ואף אחד מהם אינו קובע אם פרטי הגישה טובים.

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

תחביר התחום תלוי בפריסה. יש שירותים שרוצים שם ללא סיומת בתוספת מאפיין, אחרים רוצים user@domain, ומעטים מצפים לצורה עם לוכסן אחורי שרוב המדריכים אינם מזכירים.

השתמשו בצורה שהקצה האחורי מצפה לה

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

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

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

עקבו אחר הבקשה דרך הפרוקסי

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

grep -n -A4 '^realm' /etc/freeradius/3.0/proxy.conf
radtest '[email protected]' 'wrong-password' 10.20.30.10 0 testing123
journalctl -u freeradius --since '-10 min' | grep -iE 'realm|stripped'

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

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

תעדו את הניסיון בלי להדליף אותו

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

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