אזהרת AnyConnect על שרת לא מהימן: לקבל או לייבא?

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

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

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

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

קראו את התעודה לפני שאתם עונים לתיבה

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

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

דעו מה כל תשובה כותבת למאגר האמון

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

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

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

כתבו את התשובות בסדר שבו הלקוח שואל

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

connect vpn2.example.net
y
n
GROUP
LOGIN
PASSWORD

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

הסירו את החריגות שמאריכות ימים יותר מהשער שלהן

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

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