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

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

שני חיבורים, שתי החלטות אמון

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

לכן הכשל שקט ולא רועש. שער שלעולם אינו בודק את תעודת המדריך עדיין מאמת משתמשים כראוי; הוא רק מאמת אותם דרך ערוץ שלא אימת.

StartTLS ו-LDAPS, נבחרים בכוונה

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

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

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

איזה מאגר אמון קורא לקוח ה-LDAP?

ספריית הלקוח של OpenLDAP קוראת את תצורת האמון שלה, בין אם מקובץ המערכת ובין אם מהגדרה ייחודית לתוסף. הנחיית ה-CA של ה-VPN חלה על עמיתי VPN ואינה הוכחה שספריית ה-LDAP קוראת את אותו קובץ. השתמשו בשם המארח של המדריך שהתעודה מכסה באמת, בתוספת שרשרת ההנפקה שהספרייה סומכת עליה. ב-Active Directory, פרסו תעודת שירות מדריך עם שימוש נכון באימות שרת במקום להסיק משם תצוגה.

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

חשבון ה-bind נשאר בעיה נפרדת

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

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

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

מאמרים קשורים