אזור הניהול של SaaS מאחורי ה-VPN: לאיזו כתובת כדאי לסמוך?
המקור רואה את כתובת היציאה של שער ה-VPN שלך, לא את כתובת המנהרה של המחשב הנייד. סמוך רק על כותרת פרוקסי מוגדרת, ואז גדור כל פעולת ניהול.
דפי SaaS ציבוריים יכולים להישאר פתוחים לכולם בעוד שפעולות הניהול שמאחוריהם דוחות כל מי שמחוץ ל-VPN. המנגנון שמאפשר זאת אינו תפריט נסתר ואינו דף התחברות נפרד; זו בדיקה של נתיב הרשת שהעביר את הבקשה. אם הראיות לכתובת שגויות, הבדיקה או נועלת מנהלים אמיתיים בחוץ או מכניסה כל מי שיודע להקליד כותרת. התחל במה שהמקור באמת מקבל.
מה המקור באמת מקבל אחרי המנהרה
כאשר דפדפן מגיע לאתר הציבורי דרך VPN שגם נושא תעבורת אינטרנט, השער מתרגם את החיבור לפני שהוא יוצא. ה-SaaS רואה את כתובת היציאה הציבורית של השער, בדרך כלל כתובת אחת או טווח קטן, ו לעולם אינו רואה את כתובת המנהרה של המחשב הנייד. לכן הוספת 10.90.0.42 לרשימת ההיתר נכשלת, ולכן הוספת כל RFC 1918 נכשלת בקול רם עוד יותר: השנייה מכניסה כל רשת פרטית שיכולה להגיע אליך. הכתובת היחידה ששווה התניה היא זו שהארגון שלך באמת מחזיק ביציאה.
curl -s https://ifconfig.me
dig +short admin.example.com
מינהור מפוצל שובר את ההנחה הזו בשקט. אם ה-VPN נושא רק נתיבי משרד פרטיים, הבקשה לשם המארח הניהולי הציבורי יוצאת דרך ספק האינטרנט המקומי והמקור רואה כתובת מגורים. סמל VPN מחובר אינו מוכיח דבר על היעד המסוים הזה, לכן בדוק את היעד ולא את המנהרה.
עצור ותקן את הניתוב לפני שתכתוב מדיניות כלשהי אם כתובת היציאה משתנה לפי משתמש. תנאי שמתאים רק לחלק מהמנהלים גרוע מאין תנאי, כי הוא מסתיר את הבעיה עד לתקרית.
סמוך רק על הפרוקסי שמשכתב את הכתובת
רוב האתרים הציבוריים נמצאים מאחורי CDN או פרוקסי הפוך, כך שכתובת ה-socket של המקור שייכת לחזית הזו ולא למבקר. החזית בדרך כלל מעבירה את הכתובת המקורית בכותרת, ו הכותרת הזו נשלטת בידי תוקף אלא אם המקור מקבל אותה רק מפרוקסים מוכרים. הגדר את רשימת המקורות המהימנים במפורש והפוך את המקור לבלתי נגיש מכל מקום אחר. בלי החצי השני הזה, תוקף עוקף את הפרוקסי ושולח את הכותרת ישירות.
set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
curl -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin
אותו היגיון חל על פרוטוקול PROXY: הוא מהימן רק כאשר המאזין כבול לממשק שהפרוקסי יכול להגיע אליו ושום דבר אחר לא יכול. הקשר כתובת חסר חייב להכשיל את הבדיקה המוגנת ולא ליפול להיתר ברירת מחדל. כותרת חסרה אינה ראיה לנתיב מהימן.
צרף את התנאי לכל פעולה מוגנת
שים את הבדיקה בגבול ההרשאה שכל פעולה מוגנת עוברת דרכו, לא בדף שמצייר את התפריט. קבוצות נתיבים, middleware או שכבת מדיניות כולם עובדים; עותק לכל מטפל לא, כי המטפל שמישהו יוסיף ברבעון הבא לא יהיה לו אותו.
user = requireAuthenticatedSession()
requirePermission(user, "admin")
requireVpnEgress(verifiedClientAddress(request))
performProtectedOperation(user, request)
אותו גבול חייב לכסות את ה-JSON API, את הייצוא, את כתובות ההורדה החתומות ואת לחיצת היד של WebSocket, משום שאף אחד מהם אינו צריך שדף ה-HTML ייבקש קודם. קישור הורדה שנוצר בזמן שה-VPN היה פעיל נשאר תקף אחר כך אלא אם נקודת ההורדה בודקת שוב. הפעלות ארוכות טווח זקוקות גם לכלל הערכה מחדש, אחרת בקשה מאומתת אחת הופכת לפטור קבוע. דחייה כברירת מחדל היא ההגדרה היחידה ששורדת תחלופת עובדים.
מטמונים משותפים הם הדרך האחרת לעקוף את הבדיקה. מטמון שכבר מחזיק תגובה מוגנת יכול להגיש אותה בלי לפנות למקור, לכן סמן תגובות ניהול כפרטיות והרחק אותן מאחסון משותף. אם מטמון חייב להגיש אותן, בדיקת הגישה חייבת לרוץ לפני ההגשה, ובדרך כלל זה אומר שהוא כלל לא יכול להיות מטמון משותף.
בדוק את העקיפות שזה עתה סגרת
תרגל את המטריצה ולא את המסלול המאושר: מנהל דרך ה-VPN, אותו מנהל בלעדיו, מי שאינו מנהל דרכו, וכותרת כתובת מזויפת. הוסף בקשה ישירה למקור ובקשה עם תגובה ממטמון, כי אלה השניים שמדלגים לגמרי על החזית.
curl -sI https://admin.example.com/export.csv
curl -s -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin
curl -s https://admin.example.com/api/me -o /dev/null -w '%{http_code}\n'
כל בקשה צריכה להחזיר את הסטטוס שהמדיניות מבטיחה, והיומן צריך לתעד איזו ראיה לכתובת שימשה. כסה IPv6 בנפרד, כי מקור דו-ערוצי עשוי לראות משפחת מקור שונה מזו שבדקת. שמור על פעולות לקוח רגילות פועלות מחוץ ל-VPN, אחרת השינוי יבוטל בפעם הראשונה שלקוח יתלונן. כתוב את התוצאה הצפויה לכל שורה לפני שאתה מריץ אותה, כדי שמעבר מפתיע יהיה גלוי.
כתובת היציאה מוכיחה נתיב רשת מותר, לא אדם ולא התקן מנוהל. שמור אותה כתנאי אחד לצד אימות והרשאה, ואזור הניהול נשאר צר בלי להפוך את כל המוצר לשירות המיועד רק ל-VPN. ההפרדה הזו היא התכנון, לא מגבלה שלו.