Visual Studio pomalé jen přes VPN? Zkontrolujte CRL a OCSP
Když je vynucena zásada WDAC, jedno pomalé spuštění může být dotaz na odvolání, a ne tunel. Dokažte, který krok blokuje, než zásadu uvolníte.
Visual Studio se doma spouští normálně, pak se stejný notebook připojí ke korporátnímu tunelu a každé spuštění půl minuty visí na úvodní obrazovce. Odeberte zásadu a zpoždění zmizí s ní; odeberte tunel a stane se totéž. Obě pozorování jsou správná, a proto se obě komponenty navzájem obviňují. Rozhodující otázka je, zda dotaz na odvolání certifikátu čeká na cestu, kterou poskytuje jen tunel, nebo zda žádnou nenachází.
Měřte načtení, ne spuštění
Zásada WDAC, nasazená jako podepsaný SiPolicy.p7b, rozhoduje, které obrazy se smějí na počítači spustit. Integrita kódu ověřuje řetězec podpisů obrazu před spuštěním a toto ověření může zahrnovat dotaz na odvolání. Odpověď závisí na distribučním bodu CRL nebo na respondéru OCSP, který certifikát uvádí uvnitř sebe.
Jsou to běžné síťové požadavky, takže jejich cena závisí na tom, kde respondér sídlí. Když je dostupný jen přes tunel, nebo jeho jméno se překládá jen přes DNS server za tunelem, ověření čeká, až bude tunel připraven. Visual Studio při spuštění načítá velké množství podepsaných sestavení a rozšíření a malé zpoždění na obraz se stává viditelným zaseknutím. Nic není poškozeno a zásada se chová přesně tak, jak je nakonfigurována, a proto se zdá, že odstranění zásady problém opraví.
Každý podepsaný obraz může vyvolat síťové volání
Začněte s podepsaným binárním souborem, který už je na disku, a požádejte platformu, aby ho ověřila se stejným chováním načítání, jaké používá spuštění. Spusťte příkaz jednou na tunelu a jednou mimo něj, pak porovnejte řádky načítání místo konečného verdiktu.
certutil -verify -urlfetch C:\Tools\Contoso.Editor.dll
nslookup ocsp.contoso.example
Test-NetConnection ocsp.contoso.example -Port 80
Výstup vypisuje řetězec, adresy CRL a OCSP a to, zda každé načtení uspělo. Respondér, který na tunelu vyprší a mimo něj odpovídá, je důkaz, který potřebujete, a váží mnohem víc než dojem z pomalosti. Pokud načtení uspěje pomalu, poznamenejte adresu, aby další krok mohl tento hostitel otestovat přímo.
Přeložte jméno hostitele respondéru a otestujte dostupnost mimo aplikaci, protože jméno, které se nepřeloží, nikdy nespraví nastavení klienta. Operační protokol CodeIntegrity dodává druhou polovinu důkazu a spojuje událost ověření s časovým razítkem pomalého spuštění.
Zkraťte zpoždění, aniž byste odebrali kontrolu
Vypnutí zásady nebo přepnutí do režimu auditu zpoždění odstraní a odebere kontrolu, kterou organizace nasadila, takže to považujte za špatnou opravu. Užší možnosti jsou změna směrování, aby byl respondér dostupný přes tunel, výjimka v rozděleném tunelu pro hostitele respondéru, oprava DNS, když se jméno přeloží na nedostupnou adresu, nebo podporovaná kešovací proxy pro data o odvolání. Každá má jiného vlastníka: tým PKI vlastní dostupnost respondéru, síťový tým vlastní rozdělení tunelu a tým koncových bodů vlastní zásadu.
Vyloučení každého hostitele odvolání z tunelu není automaticky bezpečné, protože interní respondér může být interní záměrně. Potvrďte vyloučení s týmem, který provozuje PKI, než napíšete pravidlo, které tiše posílá kontroly certifikátů na veřejný internet. Změna provedená bez tohoto potvrzení je ta, která se při příští obnově zásady vrátí.
Po změně ověřte studený start
Změřte studený start v obou stavech a čísla si ponechte, protože teplý start po uložení sestavení do keše téměř nic nedokazuje. Zopakujte spuštění z nové relace, aby se cesta načítání rozšíření znovu procvičila.
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
Opravená konfigurace stále kontaktuje respondér nebo používá kešovací cestu, kterou váš tým PKI schválil, a protokol ukazuje, že ověření končí, místo aby vypršelo. Potvrďte, že nově podepsaná aplikace se stále spouští, protože zásada, která povoluje vše, není úspěšná oprava. Zkontrolujte také složku aktivní zásady a stav vynucení, aby bylo známo, že zásada, kterou ladíte, je ta, která běží. Udržujte řetězec certifikátů, adresu respondéru a časy spuštění ve stejném tiketu, protože obnova obvykle přesune respondér a nechá pravidlo výjimky nebo DNS zastaralé.