Visual Studio איטי רק ב-VPN? בדקו CRL ו-OCSP

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

מדדו את האחזור, לא את ההפעלה

מדיניות WDAC, שנפרסת כקובץ SiPolicy.p7b חתום, קובעת אילו תמונות רשאיות לרוץ במחשב. שלמות הקוד מאמתת את שרשרת החתימות של תמונה לפני ההרצה, ואימות זה עשוי לכלול שאלת ביטול. התשובה תלויה בנקודת ההפצה של CRL או במשיב OCSP שהתעודה מציינת בתוכה.

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

כל תמונה חתומה יכולה לעורר קריאת רשת

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

certutil -verify -urlfetch C:\Tools\Contoso.Editor.dll
nslookup ocsp.contoso.example
Test-NetConnection ocsp.contoso.example -Port 80

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

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

צמצמו את ההשהיה בלי להסיר את הבקרה

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

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

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

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

Get-WinEvent -LogName Microsoft-Windows-CodeIntegrity/Operational -MaxEvents 40 |
  Where-Object { $_.TimeCreated -gt (Get-Date).AddMinutes(-10) }
Get-ChildItem C:\Windows\System32\CodeIntegrity\CiPolicies\Active
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

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