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 ನಿಯಮವನ್ನು ಹಳೆಯದಾಗಿ ಬಿಡುತ್ತದೆ.