הגבלת התחברויות OpenVPN לקבוצה אחת באמצעות מדיניות PAM

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

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

למה שירות PAM נפרד

התוסף auth-pam מקבל שם שירות כארגומנט שלו. השם הזה בוחר קובץ תחת /etc/pam.d, והמחסנית בקובץ הזה היא מה שרץ בזמן התחברות VPN. אם תעבירו את אותו שם שהתחברות ברמת המערכת משתמשת בו, תירשו כל החלטה במחסנית הזו, כולל כאלה שנוספו מאוחר יותר מסיבות לא קשורות.

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

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

כתיבת כלל הקבוצה

בדיקת הזכאות שייכת לשלב החשבון, אחרי שהפרט אומת. כלל כמו account required pam_succeed_if.so user ingroup vpnusers מאפשר לעיבוד להמשיך רק כשהמשתמש המאומת הוא חבר בקבוצה הזו.

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

אל תוסיפו use_uid מתוך הרגל. בלעדיו המודול מעריך את המשתמש שמאומת; איתו המודול מעריך את החשבון שתחתיו רץ תהליך OpenVPN, שהוא בדרך כלל root או חשבון שירות ולכן לא האדם שמתחבר.

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

מלכודות סדר וזהות

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

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

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

בדיקת חברים, חיצוניים וסיסמאות שגויות

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

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

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

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