auth-nocache עם קובץ אישורים: עוזר או מזיק?

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

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

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

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

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

מה auth-nocache באמת משליך

בהתחברות אינטראקטיבית, --auth-nocache מסיר את העותק השמור מהזיכרון לאחר שנעשה בו שימוש. המחיר הוא בקשה חדשה בכל מרווח של משא ומתן חוזר, כי הסבב הבא אינו יכול לעשות שימוש חוזר במה שהושלך.

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

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

איפה נשברת הדרך המבוססת קובץ

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

stat -c '%a %U:%G' /etc/openvpn/client.creds
ps -o user:12,args -C openvpn | head

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

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

המקרה שכן רוצה את האפשרות

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

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

שמרו את שתי הסיבות בנפרד בהערות הפרופיל, אחרת המנהל הבא יניח שהאפשרות שם מהסיבה שהוא היה בוחר.

ההשוואה בהחלטה אחת

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

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

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