VPN לא מהימן הוא שלושה גבולות נפרדים, לא אחד

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

המיתוס: בקרה אחת מכסה את כל הסיכון

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

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

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

למה העמית המרוחק באמת יכול להגיע

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

ss -tulpn
sudo nft list ruleset
ip -br addr

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

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

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

מה המפעיל שבנתיב יכול לראות

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

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

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

מה מותר ללקוח המקומי לשנות

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

getcap /usr/sbin/openvpn
systemd-analyze security vpn-client.service
ip netns list

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

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

רשמו איזה גבול קיבלתם

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

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

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