Visual Studio শুধু VPN-এ ধীর? CRL ও OCSP পরীক্ষা করুন
WDAC নীতি কার্যকর থাকলে একটি ধীর লঞ্চ টানেল নয়, বরং প্রত্যাহার জিজ্ঞাসা হতে পারে। নীতি শিথিল করার আগে প্রমাণ করুন কোন ধাপটি আটকে দিচ্ছে।
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 নিয়ম পুরোনো করে রাখে।