ייצוא NFS הנעול לכתובת VPN: מה הוא אינו מוכיח
כלל ייצוא בודק מאין הגיע החבילה; AUTH_SYS מצהיר על UID מקומי ו-Kerberos מאמת משתמש. החליטו מה שירות הקבצים שלכם צריך.
מארח מייצא תיקייה לכתובת VPN, ההרכבה מצליחה, והתכנון נרשם כמאומת. מה שהכלל הזה באמת מגביל הוא מאין נראה שהחבילות מגיעות. אם האדם שמפעיל את פעולת הקובץ הוא אכן מי שהוא מתיימר להיות תלוי בטעם האבטחה של NFS, וברוב הייצואים מהסוג הזה איש לא שינה אותו מברירת המחדל.
שלוש זהויות יכולות להופיע בבקשה אחת
עמית ה-VPN נושא זהות רשומה כגון תעודת לקוח או מפתח עמית. חבילת ה-IP הפנימית נושאת כתובת מקור. פעולת הקובץ נושאת את אישורי המשתמש שמנגנון ה-NFS שלה מספק. תכנון שמתייחס לכתובת כאל תחליף לשלושתם הניח בשקט בדיוק את החלק שהיה צריך לאמת.
| Identity | What it proves | What it does not |
|---|---|---|
| VPN peer | Which peer was accepted by the tunnel | Which user runs on that machine |
| Inner source address | Where the packet appears to originate | That only the intended client can use it |
| NFS credential | What the file service believes about the caller | Anything, if the flavour only asserts local IDs |
כתיבת שלוש השורות האלה היא כל התרגיל. רוב הוויכוח אם ייצוא בטוח קורס ברגע שברור באיזו שורה חיה כל בקרה.
בעלות על הכתובת היא פרט מימוש
שער יכול להקצות כתובת מנהרה לעמית מאושר, או להרשות עבורו תת-רשת מנותבת. אם המימוש לאחר מכן דוחה חבילה שמקורה הפנימי שייך ללקוח אחר היא תכונה של אותו מימוש, וכדאי לבדוק אותה ולא להניח אותה.
קוד השרת במרחב המשתמש של Community המסורתי OpenVPN יכול, למשל, לדחות מקור המשויך ללקוח אחר לפני שהחבילה נמסרת דרך התקן TUN. זו בדיקת בעלות על כתובת בעלת ערך אמיתי, והיא עדיין אינה אימות משתמש NFS, משום שהיא אינה אומרת דבר על איזה חשבון מבצע את הפעולה.
תרגום מקור שוחק גם את זה. שער NAT יכול להציג כל לקוח ככתובת אחת, ואז כלל ייצוא אינו יכול להבחין בין האנשים שמאחוריה. הדיוק הנראה של הכלל הופך אז לבדיה שהתרשים מתחזק. אם הייצוא חשוב, החזיקו את הכתובון מפורש במקום לתת למתרגם להחליט מי נחשב למי.
קראו את טעם האבטחה לפני שאתם סומכים על הייצוא
ההנחיה של Red Hat ל-NFS מפרידה בין sec=sys, שמשתמש ב-UID וב-GID מקומיים של UNIX דרך AUTH_SYS, לבין מצבי Kerberos. krb5 מוסיף אימות משתמש, krb5i מוסיף הגנת שלמות, ו-krb5p מוסיף הגנת פרטיות לתעבורה.
אישורי AUTH_SYS מכילים שדות כמו ה-UID של הקורא ומזהי קבוצה, ו-RFC 5531 מזהיר במפורש שטעם זה אינו מספק אבטחה בעצמו ותלוי בהגנה חיצונית. הרצתו בתוך VPN מספקת הגנה לתעבורה ואינה משנה דבר בטענה שבתוך החבילה.
exportfs -v
showmount -e nfs.example.internalקראו את הטעם בפלט הזה לפני שאתם קוראים את רשימת הלקוחות. ייצוא שנראה מוגבל עשוי להיות מוגבל רק לפי כתובת בעוד כל קורא עדיין מצהיר על כל UID שירצה.
בחרו את המודל ואז שמרו על ההרשאות
בחרו את מודל האימות של שירות הקבצים המתאים ללקוחות שאתם באמת מנהלים. Kerberos דורש זהות ופריסת שירות מאחוריו, ולכן שינוי אפשרות הרכבה אחת אינו הגירה ופשוט ייכשל עד שיהיו קיימים תחום Kerberos, הפרינסיפלים וה-keytabs.
בשני המודלים, שמרו על הרשאות הייצוא ועל הרשאת מערכת הקבצים שמגבילות מה הפרינסיפל המאומת רשאי לעשות. אימות אומר לכם מי שואל; הרשאה מחליטה אם התשובה צריכה להיות כן. מיזוג השניים להגדרה אחת הוא הדרך שבה הגירה בסופו של דבר מעניקה יותר ממה שהתצורה הישנה העניקה.
השתמשו בכלל הכתובת למטרתו האמיתית
הגבלת השירות לנתיב ולמקורות המאושרים עדיין שווה, כולל מדיניות הקלט של המארח כאשר נקודת הקצה של ה-VPN ושרת ה-NFS חולקים מכונה. כללים שמעבירים תעבורה אינם שולטים בבקשות המופנות אל שירות שרץ באופן מקומי על אותו מארח. הפער הזה מסביר מספר מפתיע של ייצואים שהיו אמורים להיות פרטיים. בדקו את מדיניות הקלט המקומית במפורש במקום להניח שכללי המנהרה מכסים אותה.
בדקו שממשק אחר או שער עם תרגום מקור אינו יכול לספק את הכלל באופן בלתי צפוי, והתייחסו לכך כסיבה לקבוע מקור ולא כטענה שזיוף כתובת מבטיח הרכבה עובדת.
הריצו שלושה מקרי קבלה ולא אחד. התחילו בלקוח מאושר שפועל כמשתמש מאושר, חזרו אחר כך מעמית שמעולם לא אושר, ואז נסו משהו שהמשתמש המאושר עדיין אינו רשאי לעשות. שאלו לאחר מכן מה משתנה אם לקוח מורשה נפגע, משום שאימות תעבורה אינו הופך כל תהליך באותה מכונה לאמין. תעודה גנובה וחשבון מקומי סקרן הם בעיות שונות עם בקרות שונות.