מתקין פורטל VPN: חבילה, פרופיל או בנייה מחדש?

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

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

מה נקודת ההורדה באמת מחזירה

רוב הפורטלים מוסרים בקשת הורדה למטפל קטן שמעביר בזרם קובץ שמור או מרכיב קובץ תוך כדי, ואז קובע שם קובץ וסוג תוכן לפני שהתגובה יוצאת. מה שמגיע הוא מיכל: MSI, PKG, DEB או RPM, או עטיפה שמחלצת את עצמה סביב אחד מהם. בפנים יושב הקובץ הבינארי של הלקוח, ושום דבר בשם הקובץ לא אומר באופן מהימן אם הקובץ הבינארי הגיע מהספק או מצינור בנייה פנימי. קובץ בשם client-setup.exe מתעד החלטת שמות, לא עובדת מקור.

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

היכן הפרופיל נכנס ללקוח

הגדרות מלאות מראש נוסעות בדרך כלל כקובץ נפרד שהמתקין מעתיק לנתיב לכל משתמש או לכל מחשב: פרופיל JSON או XML ב-Windows, פרופיל תצורה ב-macOS, שבר תחת /etc ב-Linux. הערכים בקובץ הזה — שמות מארח של השער, עוגני אמון, לפעמים חומר רישום — הופכים לברירות המחדל של הלקוח בהפעלה הראשונה. לכן הורדה אחת יכולה לשאת סודות כמו גם קוד.

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

מה שרשרת החתימה אינה מוכיחה

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

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

אמתו את הארטיפקט לפני שמישהו מריץ אותו

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

# Windows PowerShell
Get-AuthenticodeSignature .\client-setup.exe | Format-List Status, SignerCertificate, TimeStamperCertificate

# macOS
pkgutil --check-signature ./Client.pkg
codesign -dv --verbose=4 /Applications/Client.app

# Debian/Ubuntu
dpkg-deb -I ./client_amd64.deb
sha256sum ./client_amd64.deb

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

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

קביעת הבעלות לפני הפריסה

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

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