בסטיון SSH או גישה ישירה דרך VPN: איזו מדיניות חלה?

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

בדקו מה הבסטיון באמת שולט בו

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

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

בדקו אם היעד מבחין בין המסלולים

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

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

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

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

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

בדקו היכן המדיניות באמת נאכפת

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

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

ssh -G app01.lab.internal | grep -iE '^(hostname|port|proxyjump|proxycommand)'

אמתו בניסיון ישיר במכוון

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

nc -vz -w 3 10.20.30.41 22
ssh -J bastion.lab.internal app01.lab.internal true

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