הפרידו בין הכניסות של פורטל ה-Wi-Fi לכניסות ה-VPN
שתי מערכות שונות מבקשות מכם להתחבר: ה-Wi-Fi של המקום ושער ה-VPN שלכם. הן נראות אותו דבר על המסך ומאשרות דברים שונים לגמרי. שאלו בכל חלון: מי באמת יכול לאמת את הסוד הזה?
שתי מערכות שונות מבקשות מכם להתחבר לפני שתגיעו למשהו שימושי ברשת ציבורית: ה-Wi-Fi של המקום ושער ה-VPN שלכם. הן נראות אותו דבר על המסך ומאשרות דברים שונים לגמרי. הפורטל מחליט אם המכשיר הזה רשאי להשתמש ברשת המקומית; ה-VPN מחליט אם אתם רשאים להגיע לרשת פרטית במקום אחר. אני מחזיק אותן בנפרד בכך שאני שואל בכל חלון שאלה אחת: מי באמת יכול לאמת את הסוד הזה? מה שלפניכם הוא רשימת הבדיקה שאני מריץ בבתי מלון, בשדות תעופה ובמרכזי כנסים, כולל הנקודות שבהן אני מפסיק להקליד.
שייכו כל התחברות לשירות שבודק אותה
חיבור מלון אחד יכול לכלול ארבע בדיקות נפרדות, ורק חלקן מבקשות קלט מכם. סדרו אותן קודם, כי המסך ממעט לומר לאיזה שלב הן שייכות.
| Stage | Who checks it | What you give it | What it proves |
|---|---|---|---|
| Wi-Fi association | The access point | WPA2 passphrase or 802.1X credentials | That the device may join this SSID |
| Portal authorization | The venue or its portal provider | Room number, booking name, voucher, email or access code | That a guest may use local access |
| VPN authentication | Your gateway or identity provider | Client certificate, password, one-time code or SSO approval | That the user or device may enter the private network |
| Application login | Each internal service | That service's own account | That you may use that service |
רשתות 802.1X, הנפוצות במשרדים ובאוניברסיטאות, מטשטשות את שתי השורות הראשונות. שם ההתחברות ל-Wi-Fi היא עצמה בדיקת זהות מול שרת RADIUS, והלקוח יכול להציג זהות ניתוב בעוד החשבון האמיתי נוסע בתוך ההחלפה המוצפנת. גם אז הבדיקה עוסקת בהצטרפות לרשת; היא אינה מאשרת את המנהרה, ושער ה-VPN אינו מקבל אותה כהוכחה לשום דבר.
הסדר חשוב יותר מהתוויות. פורטלים לכודים קיימים מפני שאפשר להעניק גישה לאחר ההתחברות, ולכן מקום יכול להעביר את העמוד לספק מתמחה. RFC 8952 של IETF מתייחס לפורטל כרכיב בפני עצמו, ולכן דומיין לא מוכר הוא סיבה לבדוק, לא הוכחת הונאה בפני עצמה. השוו את הדומיין להוראות הכתובות של המקום, ואת השדות לטבלה.
בדקו מה מותר לפורטל לבקש
שדות הפורטל עוסקים בזכאות, לא בזהות: מספר חדר, שם משפחה מההזמנה, קוד שובר, הקוד המודפס על שרוול המפתח, דואר אלקטרוני לכרטיס זמני, קבלת התנאים. המקום כבר יודע מי הזמין את החדר, ולכן הוא יכול להתאים את העובדות האלה בלי ללמוד משהו שיאפשר לו לפעול כמוכם במקום אחר.
כל דבר מעבר לרשימה הזו ראוי להפסקה. עמוד נקודת גישה אינו יכול לאמת את סיסמת התחום שלכם, וגם אינו יכול לאמת את הקוד החד-פעמי שלכם ל-VPN, קוד שחזור או מפתח פרטי, ואין לו סיבה לרצות אותם. היוצא מן הכלל הלגיטימי היחיד הוא רשת שמנוהלת על ידי ארגון: SSID אורחים במשרד או Wi-Fi של כנס יכולים להעביר אתכם לספק הזהות שאתם כבר משתמשים בו לעבודה. עדיין אפשר להבחין: מארח ההתחברות הוא היומיומי שלכם, מסך ההסכמה נוקב בשם השוכר שלכם, והזרימה נפתחת בכרטיסיית דפדפן גלויה.
דואר אלקטרוני שיווקי הוא דבר נפרד: כינוי נסיעות ממלא את השדה בלי למסור את זהות העבודה שלכם.
בדקו שלקוח ה-VPN רוצה את האישורים שלו עצמו
הלקוח מבקש בדיוק את מה שהפרופיל שלו מוגדר להשתמש בו, ולכן החלון הצפוי הוא תכונה של הפרופיל ולא של הרשת שאתם נמצאים בה במקרה. פרופילי תעודה מציגים בדרך כלל בחירת פרופיל ואז מתחברים בשקט. פרופילי שם משתמש וסיסמה מבקשים את שניהם, לעתים קרובות עם קוד חד-פעמי. פרופילי SSO פותחים את הדפדפן שלכם לספק הזהות וחוזרים עם אסימון. WireGuard שונה שוב: הוא מאמת התקנים במפתח ציבורי ואין לו התחברות משתמש, ולכן חלון שמציע שם משתמש וסיסמה של WireGuard אינו מתאר את WireGuard.
קראו את הפרופיל לפני הנסיעה. ב-OpenVPN, auth-user-pass אומר לכם שצפויה בקשת סיסמה, ואילו cert, key או pkcs12 אומרים שתעודה אמורה לעשות את העבודה. אם פרופיל שמתחבר בדרך כלל בלי בקשה מבקש לפתע סיסמה, חשדו בפרופיל שלא הצליח לטעון את התעודה שלו או נפל לשיטה אחרת. בקשה אינה הזמנה להקליד את סיסמת העבודה שלכם בכל חלון שהופיע.
שום לקוח VPN לגיטימי אינו מבקש את מספר החדר, את שובר הפורטל או את מילת הסיסמה של ה-Wi-Fi כקלט לאימות. כשזה קורה, או שהלקוח אינו מה שהוא מתיימר להיות, או שפורטל לכוד מיירט תעבורה לפני שהמנהרה נוצרת ואתם קוראים עמוד HTML מעוצב להיראות כמו התחברות.
עצרו בחמישה התנאים האלה
אלה הנקודות שבהן אני עוצר במקום להמשיך עם עקיפה סבירה. כל אחת זולה לבדיקה ויקרה לטעות.
- מופיעה אזהרת תעודה או TLS בפורטל או בעמוד ה-SSO. אל תעברו עליה בקליק כדי להגיע לרשת.
- העמוד מבקש סוד שרק שער ה-VPN או ספק הזהות יכולים לאמת: סיסמת תחום, קוד חד-פעמי, קוד שחזור, מפתח פרטי.
- הדומיין אינו תואם להוראות המודפסות של המקום או למארח ההתחברות שהארגון שלכם מתעד לשירותים שלו.
- מבקשים מכם להתקין תעודת שורש, פרופיל תצורה או יישום עזר שאינו מגיע מניהול ההתקנים שלכם.
- מגיע אישור MFA שלא התחלתם, או שלקוח ה-VPN מבקש אישורי מלון.
החלופה אינה סיסמה אחרת. השתמשו בנקודת גישה מהטלפון, שאלו בקבלה את שם הרשת המדויק ואת שיטת הגישה, ודווחו על העמוד למי שמפעיל את הרשת או לתמיכת ה-IT שלכם. שום דבר מזה אינו מחייב לבדוק אישור מול עמוד שאינכם יכולים לייחס.
יחסו כשל לשלב הנכון
לאחר ששני השלבים עברו, כשלים עדיין קורים, והשגיאה בדרך כלל נוקבת בשלב אם קוראים אותה לפי הסדר: הצטרפות, הקצאת כתובת, אישור פורטל, הקמת מנהרה, ואז המשאב הפנימי. החלפת סיסמת VPN מפני שקוד פורטל פג תוקף מבזבזת זמן ומשאירה את הבעיה האמיתית במקומה.
כמה בדיקות מפרידות בין השלבים. לאחר ההתחברות לפורטל, בקשו עמוד HTTPS ציבורי רגיל. אם הפורטל חוזר במקומו, האישור מעולם לא הושלם בשכבה הזו. אם לקוח ה-VPN מדווח שאינו מגיע לשער, הבעיה נמצאת מתחת למנהרה: הפעלת הפורטל, פתרון שמות או רשת שחוסמת את הפורט. אם המנהרה עולה ושם מארח פנימי אחד נכשל, פתרון שמות או מדיניות בתוך הרשת הפרטית הם החשוד הסביר יותר.
הפעלות פורטל גם פגות באופן בלתי תלוי במנהרה. כשהמקום מבטל גישה, חיבור VPN מבוסס נופל אף שהאישורים שלו מעולם לא היו שגויים. אשרו מחדש את הפורטל, ואז חברו מחדש את ה-VPN ותנו לו לנהל משא ומתן מחדש. סיבוב סיסמת ה-VPN אז אינו מתקן דבר ועלול לנעול אתכם בחוץ.
תנו כל סוד רק למערכת שיכולה לאמת אותו, והתייחסו לבקשה שלא מתאימה לטבלה כאל תמרור עצור ולא כאל שלב לעקוף. אם שני השלבים עוברים והמנהרה עדיין מסרבת, תפסו את שגיאת הלקוח המדויקת לפני שתשנו אישור כלשהו.