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 नियम पुरानो छोड्छ।