למה עריכת קובץ .ovpn לא יכולה להפעיל MFA בשרת

אתם מוסיפים auth-user-pass לפרופיל, מתחברים מחדש, והלקוח מבקש שם משתמש וסיסמה. נראה ש-MFA פעיל. אחר כך אתם מקלידים קוד מהחשבון הלא נכון, או קוד שפג תוקפו לפני עשר דקות, והמנהרה בכל זאת עולה. זה הסימפטום: הלקוח השתנה, השרת לא. סיסמה חד-פעמית היא גורם רק כאשר מאמת בשרת מחליט אם היא תקפה לזהות שתובעת אותה.

הבקשה מוכיחה רק שהלקוח ביקש, לא יותר

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

גם התקנת אפליקציית אימות בטלפון לא יוצרת את הקשר הזה. פרויקט Google Authenticator PAM הוא רכיב אימות OTP שיכול לשבת מאחורי OpenVPN; הוא לא דרך להדביק התחברות לחשבון Google על פרופיל מיובא.

רישום הוא החלק שפרופיל לא יכול לעשות

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

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

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

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

קראו את ערימת PAM כדי לראות מה באמת נדרש

שורה כמו account required pam_permit.so לא מיישמת זכאות חשבון ולא מוסיפה גורם. היא מתירה את שלב ניהול החשבונות הזה ב-PAM, וזו אמירה על שלב ולא על המשתמשים שלכם.

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

התאימו את האינטראקציה של הלקוח לעיצוב של השרת

auth-user-pass

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

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

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

התחברויות חוזרות, אסימונים והבדיקה שמכריעה

תכננו מה קורה אחרי ההתחברות המוצלחת הראשונה. קוד שהתקבל קודם עשוי להיות שפג תוקפו או להידחות כשידור חוזר באימות הבא. auth-nocache שולט בשימור פרטי ההתחברות ואינו מתקין MFA, ו-reneg-sec 0 אינו הגדרה של תמיכה ב-TOTP, לא משנה באיזו תדירות הוא מופיע בשרשורי פורום.

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

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