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 ล้าสมัย