Windows নিরাপত্তা অডিট পলিসি ও ইভেন্ট লগ তদন্তের বাস্তব প্রয়োগ — 4625 পড়তে পারে এমন তথ্য-ব্যবস্থা দল
· Go Komura · Windows, নিরাপত্তা, ইভেন্ট লগ, Audit Policy, লগ নকশা, PowerShell, তথ্য ব্যবস্থা
«গত রাত থেকে এক অ্যাকাউন্ট বারবার লকআউট হচ্ছে। কারণ খুঁজে দিন।» «প্রস্থানকারী কর্মীর অ্যাকাউন্টে কেউ সাইন-ইন চেষ্টা করছে কি না দেখতে চাই।» «এই সার্ভারে কখন কে কী চালিয়েছে বলা যায়?» — ছোট ও মাঝারি ব্যবসার তথ্য-ব্যবস্থা কর্মী, বা গ্রাহকের কাছে সিস্টেম দিয়েছেন এমন ডেভেলপার একদিন হঠাৎ এই অনুরোধ পান। আর ভরসা হয়ে ওঠে Windows-এর Security ইভেন্ট লগ।
কিন্তু ইভেন্ট ভিউয়ার খুললে দুটো বাস্তবতা অপেক্ষা করে। চাওয়া ইভেন্ট রেকর্ডই হয়নি (অডিট পলিসি চালু নেই), অথবা বিপুল ইভেন্টে চাপা পড়ে পড়া যায় না (শব্দে ফুলে গেছে)। নিরাপত্তা অডিট «চালু করলে রেকর্ড হয়», কিন্তু কী কতদূর রেকর্ড করবেন নকশা না করলে কাজের বেলায় কাজে লাগে না।
flowchart TB
accTitle: ইভেন্ট ভিউয়ারে অপেক্ষমাণ দুই বাস্তবতা
accDescr: ইভেন্ট ভিউয়ার খুললে অডিট পলিসি চালু নেই বলে চাওয়া ইভেন্ট রেকর্ড হয়নি, নয়তো শব্দে ফুলে গিয়ে বিপুল ইভেন্টে চাপা পড়ে পড়া যায় না — এই দুই বাস্তবতা থাকে, তাই কী কতদূর রেকর্ড করবেন তার নকশা দরকার
open["ইভেন্ট ভিউয়ার খোলা"] --> real{"অপেক্ষমাণ বাস্তবতা?"}
real -->|রেকর্ড হয়নি| none["চাওয়া ইভেন্ট অনথিভুক্ত"]
real -->|চাপা পড়েছে| noise["বিপুল ইভেন্টে পড়া যায় না"]
none -.-> cause1["অডিট পলিসি নিষ্ক্রিয়"]
noise -.-> cause2["শব্দে ফুলে গেছে"]
none --> design["কী কতদূর রেকর্ড করবেন নকশা করুন"]
noise --> design
চিত্র 1: «রেকর্ড হয়নি» না «চাপা পড়ে পড়া যায় না»। দুটোরই কারণ রেকর্ডের পরিসর নকশা না করা।
এই নিবন্ধ অডিট পলিসির কৌশল (মৌলিক ও বিস্তারিত দুই ধারা), ছোট-মাঝারি পরিবেশে ন্যূনতম চালু সাবক্যাটাগরি, 4624/4625/4740/4688-এর মতো নিয়মিত ইভেন্ট ID পড়া, Security লগের ধারণক্ষমতা নকশা, আর PowerShell দিয়ে খোঁজার উপায় আগস্ট 2026-এর প্রাথমিক সূত্রে সাজায়। এই সাইটে আগে আসা NTLM অডিট, SMB সাইনিং, BitLocker ও ফায়ারওয়াল নিবন্ধগুলো যদি «প্রতিরক্ষা শক্ত করা» হয়, এই নিবন্ধ «পরে কী ঘটেছিল নিশ্চিত করা যায় এমন অবস্থা গড়া» — সেগুলোকে এক সূত্রে বাঁধা পরের কিস্তি।
1. আগে সিদ্ধান্ত
- অডিট পলিসিতে «মৌলিক» ও «বিস্তারিত (Advanced Audit Policy)» দুই ধারা আছে, মেশাবেন না। দুটো একসঙ্গে ব্যবহার করলে অডিট ফল অপ্রত্যাশিত অবস্থায় পড়ে বলে Microsoft স্পষ্ট লিখেছে। বিস্তারিত দিকে (৪০-এর বেশি সাবক্যাটাগরি) একীভূত করুন।1
- বর্তমান অবস্থা
auditpol /get /category:*দিয়ে দেখুন। GPO না লোকাল যেখান থেকেই আসুক, এখন কার্যকর অডিট সেটিং তালিকা হয়।2 - «সব চালু» করবেন না। বিপুল ইভেন্ট জন্মায় এমন সাবক্যাটাগরি চালু করলে জরুরি ইভেন্ট শব্দে চাপা পড়ে, কর্মক্ষমতাও ক্ষতিগ্রস্ত হয়। Microsoft-এর বেসলাইন সুপারিশ থেকে শুরু করে শুধু যা দরকার তা যোগ করুন।34
- সাইন-ইন সফল 4624, ব্যর্থ 4625। 4624 লগঅন টাইপ দিয়ে (2 = Interactive, 3 = Network, 10 = RemoteInteractive ইত্যাদি) «কী ধরনের সাইন-ইন» আলাদা করে পড়ুন।5
- 4625-এ Status/Sub Status কোডে ব্যর্থতার কারণ বোঝা যায়। নিয়মিতগুলো 0xC0000064 = অস্তিত্বহীন ব্যবহারকারী নাম, 0xC000006A = ভুল পাসওয়ার্ড, 0xC0000072 = নিষ্ক্রিয় অ্যাকাউন্ট, 0xC0000234 = লকআউট চলছে।6
- ইভেন্ট কোন মেশিনে রেকর্ড হয় তা স্থির। 4624/4625 প্রবেশ করা দিকের মেশিনে, শংসাপত্র যাচাই (4776) ও Kerberos প্রাক-প্রমাণীকরণ ব্যর্থতা (4771) ডোমেইন কন্ট্রোলারে। ভুল মেশিন দেখলে «লগ নেই» ভুল নির্ণয় হয়।678
- Security লগের অর্ধেক পাত্রের নকশা (সর্বোচ্চ আকার ও ধরে রাখা)। ধরে রাখা ওভাররাইট মোড হলে পুরনো ইভেন্ট থেকে মুছে যায়।
Get-WinEvent -ListLog Securityদিয়ে সর্বোচ্চ আকার ও সংখ্যা দেখে, দরকারি ধরে রাখার দিন থেকে উল্টো হিসেবে বাড়ান।910 - প্রক্রিয়া তৈরি (4688)-এর কমান্ড-লাইন রেকর্ড শক্তিশালী, কিন্তু গোপন তথ্য লগে সাধারণ লেখায় ওঠার ঝুঁকির বিনিময়ে। চালু করার আগে স্ক্রিপ্টগুলো পরীক্ষা করুন।1112
2. অডিট পলিসির ভিত্তি — «মৌলিক» ও «বিস্তারিত» মেশাবেন না
Windows অডিট পলিসি দুই ধারা।1
- মৌলিক অডিট পলিসি: «লোকাল পলিসি > Audit Policy»-এর নয়টি ক্যাটাগরি সেটিং। Windows Vista-এর আগে থেকে থাকা পুরনো ধারা।
- বিস্তারিত অডিট পলিসি (Advanced Audit Policy Configuration): «Security Settings > Advanced Audit Policy Configuration»-এর ৪০-এর বেশি সাবক্যাটাগরি সেটিং। মৌলিক এক ক্যাটাগরিকে কয়েক সাবক্যাটাগরিতে ভাঙা; যেমন মৌলিক «Audit account logon events» একটার বিপরীতে বিস্তারিত দিকে চার সাবক্যাটাগরি। মৌলিক দিকে এক ক্যাটাগরি চালু করা মানে সংশ্লিষ্ট সাবক্যাটাগরি সব চালু করা, আগ্রহ নেই এমন ইভেন্টও বিপুল রেকর্ড হয়।1
জরুরি কথা, এই দুই ধারা সামঞ্জস্যপূর্ণ নয়। Microsoft স্পষ্ট বলে: «মৌলিক ও বিস্তারিত দুটোই ব্যবহার করবেন না। অডিট ফল অপ্রত্যাশিত অবস্থায় পড়ে।» Group Policy দিয়ে বিস্তারিত অডিট পলিসি প্রয়োগ করলে সেই কম্পিউটারের বিদ্যমান অডিট সেটিং আগে খালি হয়ে বিস্তারিত দিকের সেটিং বসে, তারপর শুধু বিস্তারিত দিকেই নিশ্চিত নিয়ন্ত্রণ যায়। বিস্তারিত দিক ব্যবহারের পরিবেশে সিকিউরিটি অপশন «Audit: Force audit policy subcategory settings to override audit policy category settings» চালু রাখুন, যাতে মৌলিক সেটিং ওভাররাইট না করে (স্ট্যান্ডঅ্যালোন মেশিনে ডিফল্টে চালু)।14
flowchart TB
accTitle: মৌলিক ও বিস্তারিত অডিট পলিসির সম্পর্ক
accDescr: মৌলিক অডিট পলিসি ও বিস্তারিত অডিট পলিসি সামঞ্জস্যপূর্ণ নয়, দুটো একসঙ্গে ব্যবহার করলে অডিট ফল অপ্রত্যাশিত অবস্থায় পড়ে, তাই বিস্তারিত দিকে একীভূত করে সাবক্যাটাগরি সেটিং জোর করে চালু করে মৌলিক দিকের ওভাররাইট আটকান
basic["মৌলিক অডিট পলিসি (৯ ক্যাটাগরি)"] --> both{"দুটোই ব্যবহার?"}
adv["বিস্তারিত অডিট পলিসি (৪০+ সাবক্যাটাগরি)"] --> both
both -->|হ্যাঁ| bad["অডিট ফল অপ্রত্যাশিত অবস্থায়"]
both -->|না| unify["বিস্তারিত দিকে একীভূত"]
unify --> force["সাবক্যাটাগরি সেটিং জোর করে চালু"]
force -.-> guard["মৌলিক সেটিংয়ের ওভাররাইট আটকান"]
চিত্র 2: দুই ধারা সামঞ্জস্যপূর্ণ নয়। বিস্তারিত দিকে একীভূত করুন, আর «জোর করুন» সেটিং দিয়ে মৌলিক দিকের ওভাররাইট আটকান।
বর্তমান অবস্থা এক কমান্ড। প্রশাসকের কমান্ড প্রম্পটে চালান।2
rem এখন কার্যকর অডিট সেটিং উপশ্রেণি অনুযায়ী তালিকা
auditpol /get /category:*
rem পরিবর্তনের আগে ব্যাকআপ (CSV) ও পুনরুদ্ধার
auditpol /backup /file:C:\logs\auditpol-backup.csv
auditpol /restore /file:C:\logs\auditpol-backup.csv
auditpol-এর আউটপুট GPO থেকে এসেছে না লোকাল সেটিং থেকে এসেছে তা নির্বিশেষে «ফল হিসেবে কার্যকর পলিসি»। GPO দিয়ে পাঠানো সেটিং প্রতিফলিত হচ্ছে না মনে হলে মিলিয়ে দেখতেও কাজে লাগে। অডিট সেটিং নিজে বদলালে ইভেন্ট 4719 রেকর্ড হয়, তাই «কখন যেন অডিট বন্ধ হয়ে গিয়েছিল» পরেও ধরা যায়।12
flowchart TB
accTitle: auditpol যা দেখায় তা ফলের পলিসি
accDescr: auditpol-এর আউটপুট GPO থেকে এসেছে না লোকাল সেটিং থেকে এসেছে তা নির্বিশেষে ফল হিসেবে কার্যকর অডিট পলিসি, GPO সেটিং প্রতিফলিত না হলে মিলিয়ে দেখতে কাজে লাগে, আর অডিট সেটিং নিজে বদলালে ইভেন্ট 4719-এ পরে ধরা যায়
gpo["GPO দিয়ে পাঠানো সেটিং"] --> eff["ফল হিসেবে কার্যকর পলিসি"]
local["লোকাল সেটিং"] --> eff
eff --> get["auditpol /get দিয়ে তালিকা"]
get -.-> diff["GPO অপ্রতিফলিত হলে মিলাতে কাজে লাগে"]
change["অডিট সেটিং নিজে বদলানো"] -.-> e4719["4719 রেকর্ড হয়, পরে ধরা যায়"]
চিত্র 3: auditpol উৎস নির্বিশেষে «কার্যকর সেটিং» ফেরায়। অডিট সেটিংয়ের বদল নিজে 4719-এ থাকে।
3. ন্যূনতম চালু সাবক্যাটাগরির সিদ্ধান্ত সারণি
«নিরাপদে সব চালু» খারাপ পথ হওয়ার কারণ স্পষ্ট। যেমন বিশেষাধিকার ব্যবহারের সাবক্যাটাগরি সফল পর্যন্ত অডিট করলে ইভেন্টের পরিমাণ এত বাড়ে যে নিরাপত্তা লগে অন্য এন্ট্রি খোঁজা কঠিন হয়, কর্মক্ষমতাও ক্ষতিগ্রস্ত হতে পারে বলে Microsoft সতর্ক করে।4 লগের পাত্র (ধারা 5) সীমিত, তাই শব্দ রেকর্ড করতে থাকলে সত্যি দরকারি ইভেন্টের ধরে রাখার দিন কমে। অডিট নকশা মানে «কী রেকর্ড করবেন না» স্থির করা।
flowchart TB
accTitle: সব চালু করা কেন খারাপ পথ
accDescr: সব সাবক্যাটাগরি চালু করলে বিপুল ইভেন্ট জন্মায়, জরুরি ইভেন্ট শব্দে চাপা পড়ে কর্মক্ষমতাও ক্ষতিগ্রস্ত হয়, আর সীমিত লগ পাত্রে প্রয়োজনীয় ইভেন্টের ধরে রাখার দিনও কমে
all["সব সাবক্যাটাগরি চালু"] --> flood["বিপুল ইভেন্ট জন্মায়"]
flood --> noise["জরুরি ইভেন্ট চাপা পড়ে"]
flood --> perf["কর্মক্ষমতার প্রভাব"]
flood --> keep["ধরে রাখার দিন কমে"]
noise --> lesson["কী রেকর্ড করবেন না তাই অডিট নকশা"]
perf --> lesson
keep --> lesson
চিত্র 4: «সব চালু» জরুরি ইভেন্ট চাপা দেয়। কী রেকর্ড করবেন না স্থির করাই অডিট নকশা।
Microsoft ওয়ার্কস্টেশন/সার্ভার ভেদে বেসলাইন সুপারিশ ও শক্তিশালী সুপারিশ প্রকাশ করে, এটাই শুরুর বিন্দু।3 তার উপর ছোট-মাঝারি পরিবেশের «ঘটনার বেলায় ন্যূনতম এগুলো পড়তে চাই» দৃষ্টিতে সাজানো পরের সারণি।
| সাবক্যাটাগরি (ক্যাটাগরি) | প্রধান ইভেন্ট ID | কী বোঝা যায় | ছোট-মাঝারি পরিবেশে সুপারিশ |
|---|---|---|---|
| Logon (Logon/Logoff) | 4624 / 4625 | সাইন-ইন সফল/ব্যর্থ, লগঅন টাইপ, উৎস | সফল + ব্যর্থ। Windows 10 1809 থেকে ডিফল্টেই সফল ও ব্যর্থ চালু3 |
| Special Logon (একই) | 4672 / 4964 | প্রশাসক বিশেষাধিকারসহ সাইন-ইন ঘটা | সফল |
| Account Lockout (একই) | 4625 | লকআউট চলাকালীন অ্যাকাউন্টে লগঅন ব্যর্থতা | ব্যর্থ (4625 ব্যর্থতা ইভেন্ট; এই সাবক্যাটাগরিতে সফল ইভেন্ট নেই)13 |
| User Account Management (Account Management) | 4720 / 4726 / 4738 / 4740 | অ্যাকাউন্ট তৈরি, মুছে ফেলা, বদল, লকআউট | সফল + ব্যর্থ |
| Security Group Management (একই) | 4728 / 4732 / 4756 (যোগ), 4729 / 4733 / 4757 (সরানো) | প্রশাসক গ্রুপ ইত্যাদিতে সদস্য যোগ/সরানো (গ্লোবাল/লোকাল/ইউনিভার্সাল) | সফল (এই সাবক্যাটাগরিতে ব্যর্থতা ইভেন্ট নেই)14 |
| Credential Validation (Account Logon) | 4776 | NTLM প্রমাণীকরণের সফল/ব্যর্থ। ডোমেইন অ্যাকাউন্ট DC দিকে রেকর্ড7 | সফল + ব্যর্থ |
| Kerberos Authentication Service (একই, শুধু DC) | 4768 / 4771 | TGT ইস্যু ও প্রাক-প্রমাণীকরণ ব্যর্থতা (ভুল পাসওয়ার্ড ইত্যাদি)8 | DC-তে সফল + ব্যর্থ |
| Process Creation (Detailed Tracking) | 4688 | কে, কোন প্যারেন্ট প্রক্রিয়া থেকে, কী চালিয়েছে | সফল। কমান্ড-লাইন রেকর্ড ধারা 7-এর সতর্কতা পড়ে তারপর |
| Other Object Access Events (Object Access) | 4698 | শিডিউল করা টাস্ক তৈরি (আক্রমণের স্থায়িত্বের নিয়মিত উপায়)15 | সফল চালু করার কথা ভাবুন |
| Audit Policy Change (Policy Change) | 4719 | অডিট সেটিং নিজে বদলানো | সফল + ব্যর্থ |
উল্টোদিকে, ফাইল সিস্টেম ও রেজিস্ট্রির অবজেক্ট অ্যাক্সেস অডিট, বিশেষাধিকার ব্যবহার, প্যাকেট ফিল্টার ধরন (5152 ইত্যাদি) ডিফল্টে ছুঁয়ে না দেখাই নিরাপদ। এগুলো লক্ষ্য সঙ্কুচিত SACL সেটিং বা কাটাকুটির সীমিত সময়েই কাজে লাগে; সবসময় পুরোদমে চালু রাখলে লগ খেয়ে ফেলে।4
flowchart TB
accTitle: বিপুল-ইভেন্ট সাবক্যাটাগরির ব্যবহার
accDescr: ফাইল সিস্টেম ও রেজিস্ট্রির অবজেক্ট অ্যাক্সেস অডিট, বিশেষাধিকার ব্যবহার, প্যাকেট ফিল্টার ধরন সবসময় পুরোদমে চালু রাখলে লগ খেয়ে ফেলে, তাই লক্ষ্য সঙ্কুচিত SACL সেটিং বা কাটাকুটির সীমিত সময়েই কাজে লাগে
heavy["বিপুল-ইভেন্ট সাবক্যাটাগরি"] --> use{"কীভাবে চালু করবেন?"}
heavy -.-> ex1["অবজেক্ট অ্যাক্সেস অডিট"]
heavy -.-> ex2["বিশেষাধিকার ব্যবহার ও প্যাকেট ফিল্টার"]
use -->|সবসময় পুরোদমে| eat["লগ খেয়ে ফেলে"]
use -->|লক্ষ্য সঙ্কুচিত SACL| ok1["কাজে লাগে"]
use -->|কাটাকুটির সীমিত সময়| ok2["কাজে লাগে"]
চিত্র 5: অবজেক্ট অ্যাক্সেস ও বিশেষাধিকার ব্যবহার সবসময় পুরোদমে চালাবেন না। লক্ষ্য ও সময় সঙ্কুচিত করলেই কাজে লাগে।
4. নিয়মিত ইভেন্ট ID পড়ার উপায়
4.1. 4624 — সফল সাইন-ইন লগঅন টাইপ দিয়ে আলাদা করে পড়ুন
4624 «An account was successfully logged on», লগঅন সেশন তৈরি হওয়া মেশিনে (প্রবেশ করা দিকে) রেকর্ড হয়।5 বিপুল রেকর্ড হওয়া ইভেন্ট, তাই পড়ার সময় আগে লগঅন টাইপ দিয়ে সাজান।5
| লগঅন টাইপ | নাম | বাস্তবে অর্থ |
|---|---|---|
| 2 | Interactive | সেই PC-র কনসোলে সাইন-ইন |
| 3 | Network | নেটওয়ার্ক দিয়ে প্রবেশ (শেয়ার ফোল্ডার, ব্যবস্থাপনা টুল ইত্যাদি)। মেশিনপ্রতি হয়, সবচেয়ে বেশি |
| 4 | Batch | ব্যাচ চালানো (শিডিউল করা টাস্ক ইত্যাদি) |
| 5 | Service | সার্ভিস চালু (Service Control Manager) |
| 7 | Unlock | স্ক্রিন আনলক |
| 8 | NetworkCleartext | পাসওয়ার্ড সাধারণ লেখায় প্রমাণীকরণ প্যাকেজে যাওয়া নেটওয়ার্ক লগঅন |
| 9 | NewCredentials | অন্য শংসাপত্রে টোকেন নকল (runas /netonly-এর সমতুল্য) |
| 10 | RemoteInteractive | রিমোট ডেস্কটপ |
| 11 | CachedInteractive | ক্যাশ করা শংসাপত্রে সাইন-ইন (DC-তে পৌঁছানো যায় না) |
একসঙ্গে দেখার ফিল্ড «New Logon»-এর অ্যাকাউন্ট নাম, «Network Information»-এর উৎস ঠিকানা, «Authentication Package» (NTLM না Kerberos), আর «Elevated Token» (প্রশাসক বিশেষাধিকার সেশন কি না)। শুধু প্রশাসক বিশেষাধিকারের সাইন-ইন ধরতে চাইলে একই লগঅন ID-তে রেকর্ড হওয়া 4672 (Special privileges assigned to new logon)ও কাজে লাগে।5
flowchart TB
accTitle: 4624 আলাদা করে পড়ার ধাপ
accDescr: বিপুল পরিমাণে রেকর্ড হওয়া 4624 আগে লগঅন টাইপ দিয়ে সাজান, অ্যাকাউন্ট নাম ও উৎস, প্রমাণীকরণ প্যাকেজ, উন্নীত টোকেন দেখুন, আর প্রশাসক বিশেষাধিকারের সাইন-ইন একই লগঅন ID-র 4672-এর সাথে মিলান
ev["4624 সাইন-ইন সফল"] --> type["লগঅন টাইপ দিয়ে সাজান"]
type --> fields["প্রধান ফিল্ড দেখুন"]
fields -.-> f1["অ্যাকাউন্ট নাম ও উৎস"]
fields -.-> f2["প্রমাণীকরণ প্যাকেজ"]
fields -.-> f3["উন্নীত টোকেন"]
fields --> admin["প্রশাসক বিশেষাধিকার অনুসরণ"]
admin -.-> e4672["একই লগঅন ID-র 4672"]
চিত্র 6: 4624 লগঅন টাইপ দিয়ে সাজিয়ে তারপর ফিল্ড পড়ুন। বিশেষাধিকার সাইন-ইন 4672-এর সাথে মিলান।
4.2. 4625 — ব্যর্থতার কারণ Status/Sub Status কোডে নিশ্চিত করুন
4625 «An account failed to log on», লগঅন চেষ্টা হওয়া মেশিনে রেকর্ড হয়।6 «Failure Reason» ঘরের বাক্যের চেয়ে Status/Sub Status-এর হেক্স কোডে পড়াই নিশ্চিত। নিয়মিতগুলো নিচের মতো।6
- 0xC0000064: অস্তিত্বহীন ব্যবহারকারী নাম। অল্প সময়ে ধারাবাহিক হলে অ্যাকাউন্ট গণনা আক্রমণের ইঙ্গিত
- 0xC000006A: ভুল পাসওয়ার্ড। নির্দিষ্ট অ্যাকাউন্টে ধারাবাহিক হলে পাসওয়ার্ড অনুমান আক্রমণের ইঙ্গিত
- 0xC000006D: ব্যবহারকারী নাম বা প্রমাণীকরণ তথ্য অবৈধ
- 0xC000006F: অনুমোদিত লগঅন সময়ের বাইরে
- 0xC0000070: অনুমোদিত নয় এমন ওয়ার্কস্টেশন থেকে
- 0xC0000072: প্রশাসক নিষ্ক্রিয় করেছেন এমন অ্যাকাউন্ট (প্রস্থানকারী কর্মীর অ্যাকাউন্টে চেষ্টা এখানে আসে)
- 0xC000015B: এই মেশিনে চাওয়া লগঅন টাইপ অনুমোদিত নয়
- 0xC0000193: মেয়াদোত্তীর্ণ অ্যাকাউন্ট
- 0xC0000234: লকআউট চলছে
«কে, কোথা থেকে, কেন ব্যর্থ» লক্ষ্য অ্যাকাউন্ট + উৎস (ওয়ার্কস্টেশন নাম / IP ঠিকানা) + এই কোড — এই তিন-বিন্দু সেটে নিশ্চিত হয়। ধারা 6-এ এই তিনটি একসঙ্গে বের করার PowerShell আছে।
flowchart TB
accTitle: 4625-এর ব্যর্থতার কারণ নিশ্চিত করার ধারা
accDescr: 4625-এর ব্যর্থতার কারণ Status/Sub Status-এর হেক্স কোডে নিশ্চিত হয়, কোডের ধরন থেকে আক্রমণের ইঙ্গিত পড়ে, তারপর লক্ষ্য অ্যাকাউন্ট ও উৎস মিলিয়ে তিন-বিন্দু সেটে চিহ্নিত হয়
ev["4625 সাইন-ইন ব্যর্থ"] --> code["Sub Status কোড দেখুন"]
code --> sign{"কোডের ধরন কী?"}
sign -->|0xC0000064 ধারাবাহিক| enum["অ্যাকাউন্ট গণনার ইঙ্গিত"]
sign -->|0xC000006A ধারাবাহিক| guess["পাসওয়ার্ড অনুমানের ইঙ্গিত"]
sign -->|0xC0000072| disabled["প্রস্থানকারী অ্যাকাউন্টে চেষ্টা"]
enum --> triple["তিন-বিন্দু সেটে নিশ্চিত"]
guess --> triple
disabled --> triple
triple -.-> t1["লক্ষ্য অ্যাকাউন্ট+উৎস+কোড"]
চিত্র 7: ব্যর্থতার কারণ কোডে নিশ্চিত করুন, লক্ষ্য অ্যাকাউন্ট ও উৎস মিলিয়ে তিন-বিন্দু সেটে পড়ুন।
4.3. 4740 — লকআউটের উৎস «Caller Computer Name»
4740 «A user account was locked out» (সাবক্যাটাগরি User Account Management)। এই ইভেন্টের মূল ফিল্ড «Caller Computer Name», যেখানে লকআউটের ট্রিগার হওয়া লগঅন চেষ্টা কোন কম্পিউটার থেকে এসেছিল রেকর্ড থাকে।16 এখান থেকে উৎস টার্মিনাল চিহ্নিত করে সেই টার্মিনালে থাকা পুরনো শংসাপত্র খুঁজে দেখা নিয়মিত পথ। কারণ প্রায়ই পাসওয়ার্ড বদলের পরেও পুরনো শংসাপত্র ব্যবহার করে চলা কিছু (সংরক্ষিত শংসাপত্র, বিচ্ছিন্ন থাকা RDP সেশন, পুরনো পাসওয়ার্ডের সার্ভিস বা টাস্ক)।
flowchart TB
accTitle: অ্যাকাউন্ট লকআউট তদন্তের নিয়মিত পথ
accDescr: 4740-এর কলার কম্পিউটার নাম দিয়ে উৎস টার্মিনাল চিহ্নিত করুন, সেই টার্মিনালে থাকা সংরক্ষিত শংসাপত্র, বিচ্ছিন্ন RDP সেশন, পুরনো পাসওয়ার্ডের সার্ভিস ও টাস্ক খুঁজে দেখুন
ev["4740 লকআউট ঘটেছে"] --> caller["কলার কম্পিউটার নাম দেখুন"]
caller --> src["উৎস টার্মিনাল চিহ্নিত করুন"]
src --> sweep["পুরনো শংসাপত্র খুঁজে দেখুন"]
sweep -.-> c1["সংরক্ষিত শংসাপত্র"]
sweep -.-> c2["বিচ্ছিন্ন থাকা RDP সেশন"]
sweep -.-> c3["পুরনো পাসওয়ার্ডের সার্ভিস ও টাস্ক"]
চিত্র 8: 4740-এর «Caller Computer Name» থেকে উৎস চিহ্নিত করুন, সেই টার্মিনালের পুরনো শংসাপত্র খুঁজে দেখুন।
একটা সতর্কতা আছে। 4625 রেকর্ড হয় লগঅন চেষ্টা গ্রহণকারী দিকের কম্পিউটারে। উৎস টার্মিনাল থেকে ফাইল সার্ভার ইত্যাদিতে নেটওয়ার্ক লগঅন কারণ হলে উৎস টার্মিনালের নিজের Security লগে 4625 থাকে না; গন্তব্য সার্ভারের 4625, আর ডোমেইন অ্যাকাউন্ট হলে DC দিকের 4776 (NTLM)/4771 (Kerberos প্রাক-প্রমাণীকরণ ব্যর্থতা)-এ চিহ্ন থাকে।78 «উৎস টার্মিনালের লগে কিছু নেই» হলে গ্রহণকারী দিক দেখতে যান।
flowchart TB
accTitle: ব্যর্থতার চিহ্ন যে মেশিনে থাকে
accDescr: নেটওয়ার্ক লগঅনের ব্যর্থতা উৎস টার্মিনালে নিজে থাকে না, লগঅন চেষ্টা গ্রহণ করা গন্তব্য সার্ভারের 4625-এ রেকর্ড হয়, ডোমেইন অ্যাকাউন্ট হলে DC দিকের 4776 বা 4771-এও চিহ্ন থাকে
src["উৎস টার্মিনাল (নিজের কাছে 4625 থাকে না)"] -->|নেটওয়ার্ক লগঅন| target["গন্তব্য সার্ভার"]
target -.-> e4625["4625 রেকর্ড হয়"]
src -->|ডোমেইন অ্যাকাউন্টের প্রমাণীকরণ| dc["ডোমেইন কন্ট্রোলার"]
dc -.-> e4776["4776 (NTLM)/4771 (Kerberos)"]
চিত্র 9: 4625 গ্রহণকারী দিকে থাকে। উৎস টার্মিনালে কিছু না থাকলে গন্তব্য সার্ভার ও DC দিক দেখুন।
4.4. 4720 পরিবার — অ্যাকাউন্ট তৈরি, বদল ও গ্রুপে যোগ
অ্যাকাউন্ট ব্যবস্থাপনার ইভেন্ট সংখ্যা পাশাপাশি: 4720 (ব্যবহারকারী অ্যাকাউন্ট তৈরি)17, 4726 (মুছে ফেলা), 4738 (বদল), আর গ্রুপ দিকে সদস্য যোগ/সরানো। গ্রুপ সদস্যপদ বদলে গ্রুপের ধরন অনুযায়ী ইভেন্ট ID আলাদা — সেটা মনে রাখুন। লোকাল গ্রুপ 4732/4733, গ্লোবাল গ্রুপ 4728/4729, ইউনিভার্সাল গ্রুপ 4756/4757।14 Domain Admins গ্লোবাল গ্রুপ, তাই সেখানে যোগ 4728-এ রেকর্ড হয় — শুধু 4732 অ্যালার্ট করলে সবচেয়ে চাওয়া ঘটনাই ছাড়িয়ে যায়। দৈনন্দিনে হেল্পডেস্ক কাজের রেকর্ড, কিন্তু «সাধারণ ব্যবহারকারী হঠাৎ প্রশাসক গ্রুপে যোগ হয়েছে» বা «কেউ চেনে না এমন অ্যাকাউন্ট তৈরি হয়েছে» একবার হলেও তদন্তের বিষয়। Microsoft নিজেও বিশেষাধিকার গ্রুপে অপ্রত্যাশিত সদস্য যোগকে একক অ্যালার্টের উদাহরণ দেয়।3
flowchart TB
accTitle: গ্রুপের ধরন ও সদস্য যোগ ইভেন্ট
accDescr: গ্রুপে সদস্য যোগ গ্রুপের ধরন অনুযায়ী ইভেন্ট ID আলাদা হয়, লোকাল 4732, গ্লোবাল 4728, ইউনিভার্সাল 4756-এ রেকর্ড হয়, তাই গ্লোবাল গ্রুপ Domain Admins-এ যোগ 4728 দেখুন
add["গ্রুপে সদস্য যোগ"] --> kind{"গ্রুপের ধরন কী?"}
kind -->|লোকাল| lg["4732-এ রেকর্ড"]
kind -->|গ্লোবাল| gg["4728-এ রেকর্ড"]
kind -->|ইউনিভার্সাল| ug["4756-এ রেকর্ড"]
gg -.-> da["Domain Admins-এ যোগ এখানে"]
lg -.-> miss["শুধু 4732 নজরদারি ছাড়িয়ে যায়"]
চিত্র 10: সদস্য যোগের ইভেন্ট ID গ্রুপের ধরনে ভাগ হয়। Domain Admins-এ যোগ 4728।
4.5. 4688 — প্রক্রিয়া তৈরি। কমান্ড-লাইন রেকর্ড আলাদা সুইচ
4688 «A new process has been created», প্রক্রিয়া তৈরির প্রতিবার তৈরি করা অ্যাকাউন্ট, নতুন প্রক্রিয়ার এক্সিকিউটেবল পাথ, প্যারেন্ট প্রক্রিয়া, টোকেন উন্নয়ন টাইপ রেকর্ড হয়।11 «এই সার্ভারে কে কী চালিয়েছে»-এর জবাব দেয়, তদন্তমূল্য বেশি ইভেন্ট।
তবে ডিফল্টে কমান্ড-লাইন আর্গুমেন্ট রেকর্ড হয় না। «Include command line in process creation events» Group Policy (Administrative Templates > System > Audit Process Creation) আলাদা চালু করলেই 4688-এর «Process Command Line» ফিল্ডে আর্গুমেন্ট বসে।1112 powershell -EncodedCommand ...-এর মতো সন্দেহজনক চালু ধরতে বাস্তবে অপরিহার্য, কিন্তু ধারা 7-এর গোপন তথ্য মেশার ঝুঁকি বুঝে তারপর চালু করুন।
flowchart TB
accTitle: 4688 ও কমান্ড-লাইন রেকর্ডের সম্পর্ক
accDescr: প্রক্রিয়া তৈরির অডিট চালু করলে 4688-এ অ্যাকাউন্ট, এক্সিকিউটেবল পাথ ও প্যারেন্ট প্রক্রিয়া রেকর্ড হয়, কিন্তু কমান্ড-লাইন আর্গুমেন্ট আলাদা Group Policy চালু করলেই রেকর্ড হয়, আর গোপন তথ্য সাধারণ লেখায় ওঠার ঝুঁকি থাকে
audit["প্রক্রিয়া তৈরির অডিট চালু"] --> ev["4688 রেকর্ড হয়"]
ev -.-> base["অ্যাকাউন্ট, পাথ, প্যারেন্ট প্রক্রিয়া"]
ev --> args{"আর্গুমেন্টও দেখতে চান?"}
args -->|ডিফল্ট রাখলে| none["কমান্ড লাইন খালি"]
args -->|GPO অতিরিক্ত চালু| cmd["আর্গুমেন্ট রেকর্ড হয়"]
cmd -.-> risk["গোপন তথ্য সাধারণ লেখায় ওঠার ঝুঁকি"]
চিত্র 11: 4688-এর কমান্ড-লাইন রেকর্ড আলাদা সুইচ। চালু করার আগে গোপন তথ্য মেশার ঝুঁকি পরীক্ষা আগে।
4.6. 4698 — শিডিউল করা টাস্ক তৈরি
4698 «A scheduled task was created», টাস্ক নাম ও টাস্ক সংজ্ঞার পুরো XML (চালানো কমান্ডসহ) রেকর্ড হয়। ম্যালওয়্যার রিবুটের পরেও বেঁচে থাকতে টাস্ক নিবন্ধনকে নিয়মিত উপায় করে, তাই Microsoft টাস্ক তৈরির ইভেন্ট নজরদারি সুপারিশ করে।15 ব্যবসায় টাস্ক বেশি ব্যবহারের পরিবেশেও তৈরি নিত্যনৈমিত্তিক নয়, তাই শব্দ তুলনামূলক কম।
flowchart TB
accTitle: টাস্ক নিবন্ধন দিয়ে স্থায়িত্ব ও 4698
accDescr: ম্যালওয়্যার রিবুটের পরেও বেঁচে থাকতে শিডিউল করা টাস্ক নিবন্ধনকে নিয়মিত উপায় করে, তাই টাস্ক তৈরির 4698 নজরদারি করলে চালানো কমান্ডসহ টাস্ক সংজ্ঞা পর্যন্ত ধরা যায়
mal["ম্যালওয়্যারের স্থায়িত্ব"] --> task["টাস্ক নিবন্ধন করে বেঁচে থাকা"]
task --> ev["4698 রেকর্ড হয়"]
ev -.-> xml["চালানো কমান্ডসহ পুরো XML"]
ev --> watch["টাস্ক তৈরির নজরদারিতে শনাক্ত"]
watch -.-> low["তৈরি নিত্যনৈমিত্তিক নয়, শব্দ কম"]
চিত্র 12: স্থায়িত্বের নিয়মিত উপায় টাস্ক নিবন্ধন 4698-এ থাকে। সংজ্ঞার পুরো XML থেকে চালানো কমান্ড পর্যন্ত ধরা যায়।
আর একটা মনে রাখার বিষয় 1102 «The audit log was cleared»। Security লগ ক্লিয়ার করলে অবশ্যই এই ইভেন্ট থাকে, তাই «লগ খালি হয়ে গেছে» দেখলে দুর্ঘটনা না অপারেশন আলাদা করা যায়।18
flowchart TB
accTitle: 1102 দিয়ে লগ মুছে ফেলার কাটাকুটি
accDescr: Security লগ ক্লিয়ার করলে অবশ্যই 1102 থাকে, তাই লগ খালি হয়ে গেলে 1102 আছে কি না দেখে মুছে ফেলার অপারেশন ছিল না দুর্ঘটনা তা আলাদা করা যায়
empty["লগ খালি হয়ে গেছে"] --> rule["ক্লিয়ার অবশ্যই 1102 রাখে"]
rule --> check{"1102 আছে?"}
check -->|আছে| op["মুছে ফেলার অপারেশন হয়েছিল"]
check -->|নেই| acc["দুর্ঘটনার সম্ভাবনা সন্দেহ করুন"]
চিত্র 13: Security লগ ক্লিয়ার করলে অবশ্যই 1102 থাকে। খালি লগে 1102 আছে কি না দিয়ে দুর্ঘটনা না অপারেশন কাটাকুটি করুন।
5. লগের পাত্রের নকশা — সর্বোচ্চ আকার ও ধরে রাখা
অডিট পলিসি বাড়ানোর আগে গ্রহণপাত্র দেখুন। Security লগে সর্বোচ্চ আকার ও ধরে রাখার মোড আছে, ওভাররাইট মোডে (নিয়মিত কনফিগারেশন) সর্বোচ্চ আকারে পৌঁছালে নতুন ইভেন্ট প্রাচীনতম ইভেন্ট ওভাররাইট করে। উল্টো ধরে রাখার মোডে (ওভাররাইট না করা) লগ ভরে গেলে নতুন ইভেন্টই বাতিল হয়।10 দুটো আচরণই «দেখতে গিয়ে লগ নেই»-এর কারণ, তাই বর্তমান অবস্থা আগে জানা।
# Security লগের পাত্র দেখুন: ধরে রাখার মোড, সর্বোচ্চ আকার, বর্তমান সংখ্যা
Get-WinEvent -ListLog Security |
Select-Object LogName, LogMode, MaximumSizeInBytes, RecordCount
# এখন সত্যি কত দিন আছে (সবচেয়ে পুরনো ইভেন্টের সময়)
Get-WinEvent -LogName Security -Oldest -MaxEvents 1 |
Select-Object TimeCreated
Get-WinEvent -ListLog লগের কনফিগারেশন ও সংখ্যা একসঙ্গে ফেরায়।9 «প্রাচীনতম ইভেন্টের সময়» ও এখনকার ফারাকই প্রকৃত ধরে রাখার দিন; নিজের চাহিদা (ঘটনা তদন্তে পেছনে যেতে চাওয়া দিন) না মিললে সর্বোচ্চ আকার বাড়ান। সেটিং wevtutil sl Security /ms:<byte count> অথবা Group Policy দিয়ে পাঠানো যায়।10
flowchart TB
accTitle: ধরে রাখার দিন থেকে উল্টো হিসেবে ধারণক্ষমতা নকশা
accDescr: Get-WinEvent-এর ListLog দিয়ে কনফিগারেশন ও সংখ্যা দেখুন, প্রাচীনতম ইভেন্টের সময় থেকে প্রকৃত ধরে রাখার দিন বের করুন, ঘটনা তদন্তে পেছনে যেতে চাওয়া দিন না হলে সর্বোচ্চ আকার বাড়ান
check["ListLog দিয়ে কনফিগ ও সংখ্যা দেখুন"] --> oldest["প্রাচীনতম ইভেন্টের সময় দেখুন"]
oldest --> days["প্রকৃত ধরে রাখার দিন হিসাব"]
days --> enough{"চাহিদা মেটে?"}
enough -->|মেটে| keep["বর্তমান আকার রাখুন"]
enough -->|মেটে না| grow["সর্বোচ্চ আকার বাড়ান"]
grow -.-> how["wevtutil sl বা GPO দিয়ে সেট"]
চিত্র 14: এখন কত দিন আছে তা দেখে, পেছনে যেতে চাওয়া দিন থেকে উল্টো হিসেবে সর্বোচ্চ আকার স্থির করুন।
সিকিউরিটি অপশনে আরও আছে «Audit: Shut down system immediately if unable to log security audits» (তথাকথিত CrashOnAuditFail)। চালু থাকতে অডিট রেকর্ড করা না গেলে STOP ত্রুটি C0000244-এ সিস্টেম থেমে যায়। অডিট চিহ্ন একেবারে হারানো যায় না এমন প্রমাণীকরণ চাহিদার সেটিং, ডিফল্ট নিষ্ক্রিয়। আক্রমণকারী বিপুল ইভেন্ট জন্মিয়ে ইচ্ছে করে সার্ভার থামাতে পারে — DoS-এ গড়াতে পারে — বলে Microsoft নিজেই সতর্ক করে, সাধারণ ছোট-মাঝারি পরিবেশে সহজে চালু করার জিনিস নয়।19
flowchart TB
accTitle: লগ ভরে গেলে আচরণ
accDescr: ধরে রাখার কনফিগারেশন ওভাররাইট মোড ও ওভাররাইট না করার মোড দুই রকম, ওভাররাইট না করার মোডে অডিট রেকর্ড করা না গেলে আলাদা সেটিং CrashOnAuditFail চালু থাকলে STOP ত্রুটি C0000244-এ সিস্টেম থেমে যায়
full["Security লগ সর্বোচ্চ আকারে পৌঁছেছে"] --> mode{"ধরে রাখার কনফিগ কী?"}
mode -->|ওভাররাইট মোড| ow["প্রাচীনতম ইভেন্ট ওভাররাইট হয়"]
mode -->|ওভাররাইট না করা| drop["নতুন ইভেন্ট বাতিল হয়"]
ow -.-> lost["দুটোই দেখতে গিয়ে লগ নেই-এর কারণ"]
drop -.-> lost
drop --> caf{"CrashOnAuditFailও চালু?"}
caf -->|হ্যাঁ| crash["STOP ত্রুটি C0000244-এ থামা"]
চিত্র 15: ধরে রাখার কনফিগ ওভাররাইট না বাতিল দুই রকম। CrashOnAuditFail আলাদা সেটিং, রেকর্ড না গেলে থামিয়ে দেয়।
6. খোঁজার বাস্তব কাজ — ফিল্টার, Get-WinEvent, রপ্তানি
6.1. ইভেন্ট ভিউয়ারে সঙ্কুচিত করা
একবারের তদন্তে ইভেন্ট ভিউয়ারই যথেষ্ট। Security লগ খুলে «Filter Current Log» দিয়ে ইভেন্ট ID (যেমন 4625) ও সময়সীমা দিন। বারবার দেখা শর্ত «Custom View»-এ সেভ রাখলে পরেরবার এক ক্লিক। ইভেন্ট ID ছাড়া নির্দিষ্ট অ্যাকাউন্ট ইত্যাদি দিয়ে সঙ্কুচিত করতে চাইলে ফিল্টার ডায়ালগের XML ট্যাবে XPath কুয়েরি সরাসরি সম্পাদনা করা যায়।
6.2. Get-WinEvent দিয়ে নিষ্কাশন
সংখ্যা বেশি তদন্ত, একাধিক শর্ত, নিয়মিত চালানো — এগুলোতে PowerShell-এর Get-WinEvent-এ যান। মূল কথা ফিল্টার সার্ভার দিকে চালানো -FilterHashtable ব্যবহার করা।9
flowchart TB
accTitle: তদন্ত উপায়ের ব্যবহার ভাগ
accDescr: একবারের তদন্ত ইভেন্ট ভিউয়ারের ফিল্টারেই হয়, বারবার দেখা শর্ত কাস্টম ভিউতে সেভ করুন, সংখ্যা বেশি বা একাধিক শর্ত বা নিয়মিত চালানো হলে Get-WinEvent-এ যান
q{"কী ধরনের তদন্ত?"}
q -->|একবারের| viewer["ইভেন্ট ভিউয়ারে সঙ্কুচিত করুন"]
q -->|বারবার দেখা শর্ত| view["কাস্টম ভিউতে সেভ"]
q -->|বিপুল, একাধিক শর্ত, নিয়মিত| ps["Get-WinEvent-এ যান"]
ps -.-> hash["FilterHashtable দিয়ে সঙ্কুচিত"]
চিত্র 16: একবারের তদন্ত ইভেন্ট ভিউয়ার, বারবার দেখলে কাস্টম ভিউ, সংখ্যা বেশি হলে Get-WinEvent।
# গত ২৪ ঘণ্টার সাইন-ইন ব্যর্থতা (4625)
Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = 4625
StartTime = (Get-Date).AddDays(-1)
}
# «কে, কোথা থেকে, কেন» টেবিলে গড়ুন
Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = 4625
StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
$x = [xml]$_.ToXml()
$d = @{}
$x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
[pscustomobject]@{
Time = $_.TimeCreated
Account = "$($d.TargetDomainName)\$($d.TargetUserName)"
LogonType = $d.LogonType
Source = "$($d.WorkstationName) $($d.IpAddress)"
Status = $d.Status
SubStatus = $d.SubStatus
}
} | Group-Object Account, Status, SubStatus, Source |
Sort-Object Count -Descending |
Format-Table Count, Name -AutoSize
ইভেন্টের XML রূপ থেকে EventData টেনে নেওয়ার এই ছাঁচ একটা থাকলে 4624 বা 4688-এও একই ধরনে পুনর্ব্যবহার করা যায়। Get-WinEvent-এর সঙ্কুচিতকরণ নকশা (FilterHashtable ও XPath-এর ব্যবহার ভাগ, ধীর কুয়েরি সারানো) «Get-WinEvent দিয়ে ইভেন্ট লগ বাস্তবে খোঁজা — সঙ্কুচিতকরণের গতি তদন্তের সময় স্থির করে»-এ বিস্তারে আছে।
flowchart TB
accTitle: EventData টেনে টেবিল করার ছাঁচ
accDescr: Get-WinEvent দিয়ে আনা ইভেন্ট XML রূপে বদলে EventData-এর প্রতিটি ফিল্ড টেনে টেবিলে সাজানো এই ছাঁচ 4625-এ সীমাবদ্ধ নয়, 4624 বা 4688-এও একই ধরনে পুনর্ব্যবহার করা যায়
get["Get-WinEvent দিয়ে আনুন"] --> xml["ইভেন্ট XML রূপে বদলান"]
xml --> pull["EventData টেনে নিন"]
pull --> shape["টেবিলে সাজিয়ে গণনা"]
shape -.-> reuse["4624 বা 4688-এও একই ধরন"]
চিত্র 17: XML রূপ থেকে EventData টেনে টেবিল করার ছাঁচ ইভেন্ট ID বদলালেও পুনর্ব্যবহার করা যায়।
6.3. wevtutil দিয়ে রপ্তানি
তদন্তের লক্ষ্য মেশিনের লগ ওভাররাইটে মুছে যাওয়ার আগে আগে রপ্তানি করে সুরক্ষিত করা নীতি।10
rem পুরো Security লগ evtx হিসেবে সংরক্ষণ
wevtutil epl Security C:\logs\security-20260801.evtx
rem কেবল 4625 XPath দিয়ে সংকীর্ণ করে রপ্তানি
wevtutil epl Security C:\logs\security-4625.evtx /q:"*[System[(EventID=4625)]]"
রপ্তানি করা .evtx অন্য মেশিনে Get-WinEvent -Path C:\logs\security-20260801.evtx দিয়ে একইভাবে বিশ্লেষণ করা যায়।9 সংরক্ষণ করে তারপর বিশ্লেষণের অভ্যাস ক্র্যাশ তদন্তে «আগে ডাম্প সুরক্ষিত করুন»-এর একই চিন্তা (দেখুন «Windows ক্র্যাশ ডাম্প সংগ্রহের ভূমিকা - WER/ProcDump/WinDbg»)।
flowchart TB
accTitle: সংরক্ষণ করে তারপর বিশ্লেষণের ধারা
accDescr: তদন্তের লক্ষ্য মেশিনের Security লগ wevtutil epl দিয়ে evtx ফাইলে রপ্তানি করে সুরক্ষিত করুন, অন্য মেশিনে Get-WinEvent-এর Path নির্দেশে একইভাবে বিশ্লেষণ করুন
target["তদন্তের লক্ষ্য মেশিন"] --> export["wevtutil epl দিয়ে evtx-এ সংরক্ষণ"]
export --> copy["অন্য মেশিনে নিয়ে যান"]
copy --> analyze["Get-WinEvent -Path দিয়ে বিশ্লেষণ"]
export -.-> note["ওভাররাইটে মুছে যাওয়ার আগে সুরক্ষিত করুন"]
চিত্র 18: আগে সংরক্ষণ, তারপর বিশ্লেষণ। evtx-এ রাখলে অন্য মেশিনে একইভাবে খোঁজা যায়।
7. ফাঁদ — মাঠে সহজে পায়ে পড়ে এমন চারটি
(1) 4688-এর কমান্ড লাইনে গোপন তথ্য ওঠে। কমান্ড-লাইন রেকর্ড চালু করলে প্রতিটি প্রক্রিয়ার আর্গুমেন্ট Security লগে সাধারণ লেখায় বসে। Microsoft স্পষ্ট লিখেছে «নিরাপত্তা ইভেন্ট পড়ার অধিকার আছে এমন সব ব্যবহারকারী প্রতিটি সফল প্রক্রিয়ার কমান্ড-লাইন আর্গুমেন্ট পড়তে পারে। আর্গুমেন্টে পাসওয়ার্ডের মতো গোপন বা ব্যক্তিগত তথ্য থাকতে পারে।»12 myapp.exe /user:admin /password:P@ssw0rd-এর মতো চালু করা ব্যবসায়িক অ্যাপ বা স্ক্রিপ্ট একটাও থাকলে তা লগ দেখতে পারে এমন সবার কাছে গোপন তথ্য প্রকাশ। চালু করার আগে গোপন তথ্য আর্গুমেন্টে পাঠানো জায়গা খুঁজে সারুন। লগ সংরক্ষণ ও ফরওয়ার্ড গন্তব্যেও একই গোপনীয়তার স্তর দরকার।
flowchart TB
accTitle: কমান্ড-লাইন রেকর্ড চালু করার ক্রম
accDescr: 4688-এর কমান্ড-লাইন রেকর্ড চালু করার আগে গোপন তথ্য আর্গুমেন্টে পাঠানো ব্যবসায়িক অ্যাপ ও স্ক্রিপ্ট খুঁজে বের করুন, সেই জায়গা সেরে তারপর চালু করুন, আর লগ সংরক্ষণ ও ফরওয়ার্ড গন্তব্যেও একই গোপনীয়তার স্তর চান
audit["গোপন তথ্য আর্গুমেন্ট পাঠানো খুঁজুন"] --> found{"মিল আছে?"}
found -->|আছে| fix["পাঠানো জায়গা সারুন"]
found -->|নেই| on["কমান্ড-লাইন রেকর্ড চালু করুন"]
fix --> on
on -.-> dest["সংরক্ষণ ও ফরওয়ার্ড গন্তব্যেও একই স্তর"]
চিত্র 19: কমান্ড-লাইন রেকর্ড «খুঁজে সেরে তারপর চালু»। ক্রম উল্টো হলে গোপন তথ্য প্রকাশ হয়।
(2) লগ ভরে গেলে কী হয় না জেনে চালানো। ওভাররাইট মোডে পুরনো চিহ্ন চুপচাপ মুছে যায়, ওভাররাইট না করার সেটিংয়ে নতুন ইভেন্ট বাতিল হয়, CrashOnAuditFail চালু থাকলে পুরো সিস্টেম থেমে যায় (ধারা 5)।1019 কোন আচরণ বেছে নিয়েছেন তা জানা, আর «মুছে যাওয়ার আগে সংগ্রহ»-এর ব্যবস্থা (নিয়মিত রপ্তানি বা লগ সংগ্রহের ভিত্তি) রাখাই মূল পথ।
(3) ডোমেইন কন্ট্রোলার ও টার্মিনালে দেখার লগ আলাদা। 4624/4625 রেকর্ড হয় প্রবেশ করা মেশিনে।56 অন্যদিকে ডোমেইন অ্যাকাউন্টের শংসাপত্র যাচাই (NTLM-এর 4776) রেকর্ড হয় শংসাপত্রের উপর কর্তৃত্ব আছে এমন মেশিনে — ডোমেইন অ্যাকাউন্ট হলে DC-তে7 — আর Kerberos প্রাক-প্রমাণীকরণ ব্যর্থতা (4771) রেকর্ড হয় শুধু DC-তে।8 «ফাইল সার্ভারে 4625 নেই = আক্রমণ হয়নি» নয়; DC দিকের 4776/4771 মিলিয়ে তবেই পুরো ছবি। কোন প্রমাণীকরণ প্রোটোকল কীভাবে চলে «চিত্রে NTLM ও Kerberos — প্রমাণীকরণ কেন NTLM-এ নেমে যায়» দেখুন।
(4) ঘড়ি সিঙ্ক সরলে মিলানো যায় না। একাধিক মেশিনের লগ পাশাপাশি রেখে «এই 4740-এর ঠিক আগে কোন টার্মিনালে 4625 এসেছিল» ধরার কাজ প্রতিটি মেশিনের ঘড়ি মিলে থাকা পূর্বশর্ত। ডোমেইন পরিবেশে Kerberos নিজেই ঘড়ির ফারাকে উর্ধ্বসীমা (ডিফল্ট ৫ মিনিট) দেয়, ছাড়ালে প্রমাণীকরণ নিজেই ব্যর্থ হতে শুরু করে।20 তদন্তের দৃষ্টিতে ৫ মিনিট তো বটেই, কয়েক সেকেন্ডের ফারাকও আগে-পরের সম্পর্ক ভুল পড়ায়, তাই w32time-এর সিঙ্ক অবস্থা তদন্ত ধাপের একেবারে শুরুতে রাখুন। আর ইভেন্টের রেকর্ড সময় UTC-তে সংরক্ষিত, প্রদর্শন দেখার মেশিনের টাইমজোন অনুযায়ী, তাই বিদেশি শাখা বা UTC সেট সার্ভার থেকে আনা evtx পড়ার সময় টাইমজোন বদলানো ভুলবেন না।
flowchart TB
accTitle: ঘড়ি সিঙ্ক ও মিলিয়ে তদন্তের পূর্বশর্ত
accDescr: একাধিক মেশিনের লগ সময়ক্রমে মিলানো তদন্ত প্রতিটি মেশিনের ঘড়ি মিলে থাকা পূর্বশর্ত, কয়েক সেকেন্ডের ফারাকও আগে-পরের সম্পর্ক ভুল পড়ায়, ডিফল্ট ৫ মিনিট ছাড়ালে Kerberos প্রমাণীকরণ নিজেই ব্যর্থ হয়, তাই w32time সিঙ্ক নিশ্চিতকরণ তদন্ত ধাপের শুরুতে রাখুন
merge["একাধিক মেশিনের লগ মিলান"] --> pre["ঘড়ি মিলে থাকা পূর্বশর্ত"]
pre --> skew{"ঘড়ির ফারাক কী?"}
skew -->|মিলেছে| ok["সময়ক্রমে ধরা যায়"]
skew -->|কয়েক সেকেন্ডের ফারাক| misread["আগে-পরের সম্পর্ক ভুল পড়া"]
skew -->|ডিফল্ট ৫ মিনিট ছাড়ালে| kerb["Kerberos প্রমাণীকরণ ব্যর্থ"]
pre -.-> first["w32time নিশ্চিতকরণ ধাপের শুরুতে"]
চিত্র 20: একাধিক মেশিন মিলানো ঘড়ি মেলানো পূর্বশর্ত। কয়েক সেকেন্ডের ফারাকও আগে-পরের সম্পর্ক ভুল পড়ায়।
8. সারাংশ
- অডিট পলিসিতে «মৌলিক» ও «বিস্তারিত» দুই ধারা, মেশালে অপ্রত্যাশিত ফল। বিস্তারিত দিকে একীভূত করে
auditpol /get /category:*দিয়ে বর্তমান অবস্থা দেখে তারপর নকশা করুন। - «সব চালু» শব্দ ও ফুলে যাওয়া দিয়ে তদন্ত মেরে ফেলে। Microsoft-এর বেসলাইন সুপারিশ থেকে শুরু করে লগঅন, অ্যাকাউন্ট ব্যবস্থাপনা ও প্রক্রিয়া তৈরি কেন্দ্র করে ধারা 3-এর সিদ্ধান্ত সারণি দিয়ে এগোবেন।
- 4624 লগঅন টাইপ, 4625 Status/Sub Status কোড, 4740 Caller Computer Name, 4688 প্যারেন্ট প্রক্রিয়া ও কমান্ড লাইন — প্রতি ইভেন্টে «এখানে দেখুন» বলে একটা জায়গা আছে।
- লগের পাত্র (সর্বোচ্চ আকার ও ধরে রাখার মোড) অডিট নকশার অর্ধেক। এখন কত দিন আছে দেখে চাহিদা থেকে উল্টো হিসেবে আকার স্থির করুন, মুছে যাওয়ার আগে রপ্তানি বা জমা করুন।
- 4688-এর কমান্ড-লাইন রেকর্ড গোপন তথ্য মেশার ঝুঁকি পরীক্ষা করে তারপর। মেশিনে মেশিনে রেকর্ডের জায়গার ফারাক ও ঘড়ি সিঙ্ক মিলিয়ে তদন্তের পূর্বশর্ত।
- তদন্ত ইভেন্ট ভিউয়ারের ফিল্টার দিয়ে শুরু, বারবার হলে
Get-WinEvent -FilterHashtable, সংরক্ষণwevtutil epl। «আগে সংরক্ষণ, তারপর বিশ্লেষণ» ক্রম ভাঙবেন না।
সম্পর্কিত নিবন্ধ
- Get-WinEvent দিয়ে ইভেন্ট লগ বাস্তবে খোঁজা — সঙ্কুচিতকরণের গতি তদন্তের সময় স্থির করে
- NTLM অবলুপ্তিতে ব্যবসায়িক অ্যাপ কি থেমে যাবে? — অডিট লগ নেওয়ার উপায় ও নির্ভরতা সরানোর ক্রম
- চিত্রে NTLM ও Kerberos — প্রমাণীকরণ কেন NTLM-এ নেমে যায়
- SMB সাইনিং ও LDAP চ্যানেল বাইন্ডিং — NTLM প্রতিরক্ষার «বাকি অর্ধেক» বাস্তবে বন্ধ করা
- Windows ইভেন্ট লগ ও ETW-এর ভূমিকা — ব্যবসায়িক অ্যাপের লগ OS-এর স্ট্যান্ডার্ড ব্যবস্থায় তোলা
- Windows ক্র্যাশ ডাম্প সংগ্রহের ভূমিকা - WER/ProcDump/WinDbg
সম্পর্কিত পরামর্শ ক্ষেত্র
KomuraSoft LLC Windows অডিট পলিসি ও লগ নকশার পরামর্শ, ইভেন্ট লগ থেকে «কখন, কে, কী করেছে» তদন্ত, আর ব্যবসায়িক অ্যাপের প্রমাণীকরণ ও অডিট ঘিরে সমস্যার মূল কারণ বিশ্লেষণ সামলায়। «লগ দেখে দিন বলা হয়েছে, কিন্তু কোথা থেকে শুরু করব» সেই পর্যায় থেকে শুরু করলেই হয়।
তথ্যসূত্র
-
Microsoft Learn, Advanced security auditing FAQ. মৌলিক অডিট পলিসি (লোকাল পলিসির অধীনে নয়টি সেটিং) ও বিস্তারিত অডিট পলিসির পার্থক্য; মৌলিক এক ক্যাটাগরি চালু করা সংশ্লিষ্ট সাবক্যাটাগরি সব চালু করার সমতুল্য; দুই ধারা সামঞ্জস্যপূর্ণ নয়, একসঙ্গে ব্যবহার করলে অডিট ফল অপ্রত্যাশিত অবস্থায় পড়ে তাই মেশানো যাবে না; Group Policy দিয়ে বিস্তারিত দিক প্রয়োগ করলে বিদ্যমান অডিট সেটিং খালি হয়; «Audit: Force audit policy subcategory settings to override audit policy category settings» চালু রাখা উচিত; আর ইভেন্টের পরিমাণ কমাতে গুরুত্বপূর্ণ রিসোর্স, কাজ ও ব্যবহারকারী চিহ্নিত করে সঙ্কুচিত করা — এসব বিষয়ে। ↩ ↩2 ↩3 ↩4
-
Microsoft Learn, auditpol.
auditpolকমান্ড সিস্টেম অডিট পলিসি প্রদর্শন (/get), সেট (/set), CSV-তে ব্যাকআপ (/backup), পুনরুদ্ধার (/restore) ও খালি (/clear) করতে পারে সে বিষয়ে। ↩ ↩2 -
Microsoft Learn, System Audit Policy recommendations. ওয়ার্কস্টেশন/সার্ভার ভেদে Windows ডিফল্ট মান, বেসলাইন সুপারিশ ও শক্তিশালী সুপারিশের সারণি; সুপারিশ শুধু শুরুর বিন্দু, প্রতিষ্ঠান নিজের হুমকি ও ঝুঁকি সহনশীলতা অনুযায়ী বিবেচনা ও পরীক্ষা করবে; Logon সাবক্যাটাগরি Windows 10 1809 থেকে সফল ও ব্যর্থ দুটোই ডিফল্টে চালু; সার্ভারের পাশাপাশি ওয়ার্কস্টেশন নজরদারিও জরুরি; বিশেষাধিকার গ্রুপে অপ্রত্যাশিত সদস্য যোগের মতো একক অ্যালার্টের ইভেন্টের উদাহরণ; আর ব্যর্থ লগঅনের হঠাৎ বৃদ্ধি বেসলাইন তুলনায় শনাক্ত করার চিন্তা — এসব বিষয়ে। ↩ ↩2 ↩3 ↩4
-
Microsoft Learn, Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings. ৪০-এর বেশি অডিট সাবক্যাটাগরিতে সূক্ষ্ম ব্যবস্থাপনা যায়; এই সেটিং চালু রাখাই সেরা অনুশীলন, ক্লায়েন্ট, মেম্বার সার্ভার ও DC-তে ডিফল্ট Enabled; আর বিশেষাধিকার ব্যবহার সাবক্যাটাগরি পুরো চালু করার মতো বিপুল ইভেন্ট জন্মানো সেটিং নিরাপত্তা লগে অন্য এন্ট্রি খুঁজে পাওয়া কঠিন করে ও কর্মক্ষমতায় বড় প্রভাব ফেলতে পারে বলে সতর্কতা — এসব বিষয়ে। ↩ ↩2 ↩3 ↩4
-
Microsoft Learn, 4624(S): An account was successfully logged on. 4624 লগঅন সেশন তৈরির সময় প্রবেশ করা দিকের কম্পিউটারে রেকর্ড হয়; লগঅন টাইপের তালিকা (2 = Interactive, 3 = Network, 4 = Batch, 5 = Service, 7 = Unlock, 8 = NetworkCleartext, 9 = NewCredentials, 10 = RemoteInteractive, 11 = CachedInteractive); Elevated Token ফ্ল্যাগ; Authentication Package (NTLM/Kerberos/Negotiate) ও NTLM-এর Package Name (NTLM V1/V2/LM); আর লগঅন ID দিয়ে 4672 ইত্যাদির সাথে মিলানো — এসব বিষয়ে। ↩ ↩2 ↩3 ↩4 ↩5
-
Microsoft Learn, 4625(F): An account failed to log on. 4625 লগঅন চেষ্টা হওয়া কম্পিউটারে (ব্যবহারকারীর টার্মিনালে চেষ্টা হলে সেই টার্মিনালে) রেকর্ড হয়; সাবক্যাটাগরি Account Lockout ও Logon; Status/Sub Status কোডের অর্থ (0xC0000064 = ভুল ব্যবহারকারী নাম, 0xC000006A = ভুল পাসওয়ার্ড, 0xC000006D = ব্যবহারকারী নাম বা প্রমাণীকরণ তথ্য অবৈধ, 0xC000006F = অনুমোদিত সময়ের বাইরে, 0xC0000070 = অনুমোদিত নয় ওয়ার্কস্টেশন, 0xC0000072 = নিষ্ক্রিয় অ্যাকাউন্ট, 0xC000015B = লগঅন টাইপ অনুমোদিত নয়, 0xC0000193 = মেয়াদোত্তীর্ণ অ্যাকাউন্ট, 0xC0000234 = লকআউট); আর ধারাবাহিক 0xC0000064 অ্যাকাউন্ট গণনা আক্রমণের ইঙ্গিত হতে পারে — এসব বিষয়ে। ↩ ↩2 ↩3 ↩4 ↩5
-
Microsoft Learn, 4776(S, F): The computer attempted to validate the credentials for an account. 4776 NTLM প্রমাণীকরণে শংসাপত্র যাচাইয়ের প্রতিবার রেকর্ড হয়; রেকর্ড হয় শুধু শংসাপত্রের উপর কর্তৃত্ব আছে এমন কম্পিউটারে — ডোমেইন অ্যাকাউন্ট হলে ডোমেইন কন্ট্রোলার, লোকাল অ্যাকাউন্ট হলে লোকাল কম্পিউটার; আর সফল ও ব্যর্থ দুটোই রেকর্ড হয় — এসব বিষয়ে। ↩ ↩2 ↩3 ↩4
-
Microsoft Learn, 4771(F): Kerberos pre-authentication failed. 4771 KDC-এর Kerberos TGT ইস্যু ব্যর্থতার (ভুল পাসওয়ার্ড, মেয়াদোত্তীর্ণ ইত্যাদি) প্রতিবার রেকর্ড হয়; এই ইভেন্ট শুধু ডোমেইন কন্ট্রোলারে জন্মায় — এসব বিষয়ে। ↩ ↩2 ↩3 ↩4
-
Microsoft Learn, Get-WinEvent (Microsoft.PowerShell.Diagnostics). -ListLog দিয়ে লগ কনফিগারেশন (LogMode, MaximumSizeInBytes, RecordCount) আনা; -FilterHashtable দিয়ে LogName, Id, StartTime ইত্যাদির হ্যাশটেবিল নির্দেশে দক্ষ ফিল্টারিং; -Path দিয়ে সেভ করা .evtx ফাইল পড়া; আর -Oldest / -MaxEvents দিয়ে পুরনো-আগে ও সংখ্যা নির্দেশে আনা — এসব বিষয়ে। ↩ ↩2 ↩3 ↩4
-
Microsoft Learn, wevtutil. set-log (sl) দিয়ে সর্বোচ্চ আকার (/ms) ও ধরে রাখার মোড (/rt) সেট; ধরে রাখার মোড true হলে লগ ভরে গেলে বিদ্যমান ইভেন্ট থাকে ও নতুন ইভেন্ট বাতিল হয়, false হলে নতুন ইভেন্ট প্রাচীনতম ইভেন্ট ওভাররাইট করে; export-log (epl) দিয়ে ইভেন্ট লগ ফাইলে রপ্তানি ও /q অপশনে XPath কুয়েরি দিয়ে সঙ্কুচিতকরণ; আর query-events (qe) দিয়ে কুয়েরি চালানো — এসব বিষয়ে। ↩ ↩2 ↩3 ↩4 ↩5
-
Microsoft Learn, 4688(S): A new process has been created. 4688 নতুন প্রক্রিয়া শুরুর প্রতিবার রেকর্ড হয়; তৈরির অ্যাকাউন্ট, নতুন প্রক্রিয়ার এক্সিকিউটেবল পাথ, তৈরির (প্যারেন্ট) প্রক্রিয়া নাম ও টোকেন উন্নয়ন টাইপ থাকে; আর Process Command Line ফিল্ড ডিফল্টে খালি, «Include command line in process creation events» Group Policy চালু করলেই রেকর্ড হয় — এসব বিষয়ে। ↩ ↩2 ↩3
-
Microsoft Learn, Command line process auditing. কমান্ড-লাইন রেকর্ডে বিস্তারিত অডিট পলিসির প্রক্রিয়া তৈরির অডিট ও «Include command line in process creation events» (Administrative Templates > System > Audit Process Creation, ডিফল্ট Not Configured) দুটোই দরকার; চালু করলে প্রতিটি প্রক্রিয়ার কমান্ড-লাইন তথ্য নিরাপত্তা ইভেন্ট লগে সাধারণ লেখায় রেকর্ড হয়, পড়ার অধিকার আছে এমন সবাই পাসওয়ার্ডের মতো গোপন তথ্য থাকতে পারে এমন আর্গুমেন্ট পড়তে পারে বলে সতর্কতা; আর বিস্তারিত অডিট পলিসি মৌলিক সেটিংয়ে ওভাররাইট হলে ইভেন্ট 4719 রেকর্ড হয়, «জোর করুন» সেটিং সেটা আটকায় — এসব বিষয়ে। ↩ ↩2 ↩3 ↩4
-
Microsoft Learn, Audit Account Lockout. Account Lockout সাবক্যাটাগরি লকআউট চলাকালীন অ্যাকাউন্টে লগঅন ব্যর্থতা অডিট করে; জন্মানো ইভেন্ট 4625(F); এই সাবক্যাটাগরিতে সফল ইভেন্ট নেই তাই সফল অডিট চালু করার অর্থ নেই; আর সব কম্পিউটার ধরনে ব্যর্থতার অডিট সুপারিশকৃত — এসব বিষয়ে। ↩
-
Microsoft Learn, Audit Security Group Management. সিকিউরিটি গ্রুপ তৈরি, বদল, মুছে ফেলা ও সদস্য যোগ/সরানো অডিট করা সাবক্যাটাগরি; সদস্য যোগ/সরানোর ইভেন্ট ID গ্রুপের ধরনে ভাগ — লোকাল 4732/4733, গ্লোবাল 4728/4729, ইউনিভার্সাল 4756/4757; 4728-এর মতো ডোমেইন গ্রুপের নিবেদিত ইভেন্ট আছে; আর এই সাবক্যাটাগরিতে ব্যর্থতা ইভেন্ট নেই তাই সব কম্পিউটার ধরনে সফল অডিট সুপারিশকৃত — এসব বিষয়ে। ↩ ↩2
-
Microsoft Learn, 4698(S): A scheduled task was created. 4698 শিডিউল করা টাস্ক তৈরির প্রতিবার রেকর্ড হয়; সাবক্যাটাগরি Other Object Access Events; টাস্ক নাম ও চালানো কমান্ডসহ টাস্ক সংজ্ঞার পুরো XML রেকর্ড হয়; আর ম্যালওয়্যার রিবুটের পর স্থায়িত্বে টাস্ক নিয়মিত ব্যবহার করে তাই বিশেষ করে গুরুত্বপূর্ণ মেশিনে টাস্ক তৈরির ইভেন্ট নজরদারি সুপারিশকৃত — এসব বিষয়ে। ↩ ↩2
-
Microsoft Learn, 4740(S): A user account was locked out. 4740 প্রতিটি ব্যবহারকারী অ্যাকাউন্ট লকআউটে রেকর্ড হয়; সাবক্যাটাগরি User Account Management; আর Caller Computer Name ফিল্ডে লকআউট ঘটানো লগঅন চেষ্টার উৎস কম্পিউটারের নাম রেকর্ড থাকে — এসব বিষয়ে। ↩
-
Microsoft Learn, 4720(S): A user account was created. 4720 নতুন ব্যবহারকারী অবজেক্ট তৈরির প্রতিবার ডোমেইন কন্ট্রোলার, মেম্বার সার্ভার ও ওয়ার্কস্টেশনে রেকর্ড হয়; সাবক্যাটাগরি User Account Management — এসব বিষয়ে। ↩
-
Microsoft Learn, 1102(S): The audit log was cleared. ইভেন্ট 1102 Windows নিরাপত্তা অডিট লগ মুছে ফেলার প্রতিবার রেকর্ড হয় সে বিষয়ে। ↩
-
Microsoft Learn, Audit: Shut down system immediately if unable to log security audits. এই সেটিং চালু থাকতে নিরাপত্তা অডিট রেকর্ড করা না গেলে STOP বার্তা C0000244 {Audit Failed}-এ সিস্টেম থেমে যায়; ডিফল্ট Disabled; বিপুল নিরাপত্তা ইভেন্ট ইচ্ছে করে জন্মিয়ে শাটডাউন জোর করা DoS-এ গড়াতে পারে; আর হঠাৎ থেমে অ্যাপ্লিকেশন ডেটা ব্যবহারযোগ্য না থাকার ঝুঁকি — এসব বিষয়ে। ↩ ↩2
-
Microsoft Learn, Maximum tolerance for computer clock synchronization. Kerberos v5 রিপ্লে আক্রমণ ঠেকাতে টাইমস্ট্যাম্প ব্যবহার করে, তাই ক্লায়েন্ট ও ডোমেইন কন্ট্রোলারের ঘড়ির ফারাকে সর্বোচ্চ সহনশীলতা (ডিফল্ট ও সুপারিশ দুটোই ৫ মিনিট) সেট থাকে, ছাড়ালে টাইমস্ট্যাম্প আর সত্য বলে গণ্য হয় না — এসব বিষয়ে। ↩
সম্পর্কিত নিবন্ধ
কাছাকাছি বিষয়ে গভীরে যেতে একই ট্যাগযুক্ত সাম্প্রতিক নিবন্ধ।
Group Policy (GPO)-এর বাস্তব নির্দেশিকা — কীভাবে কাজ করে, প্রয়োগ নিশ্চিত, এবং Intune-এর সাথে বাছাই
«GPO দিয়ে বিতরণ» মানে না বুঝেই AD পরিবেশ সামলাচ্ছেন? এই নিবন্ধ Group Policy-এর ব্যবস্থা, LSDOU প্রয়োগ ক্রম, gpupdate ও gpresult দিয়ে প...
Windows ভার্চুয়ালাইজেশনের গভীরতা (পর্ব ২) — কার্নেলও দেখতে পায় না এমন মেমরি: VBS, HVCI ও Credential Guard কীভাবে কাজ করে
সামঞ্জস্যপূর্ণ হার্ডওয়্যারে ক্লিন ইনস্টলে VBS ডিফল্টে চালু থাকে এবং হাইপারভাইজার ও SLAT দিয়ে কার্নেলের চেয়ে শক্তিশালী আইসোলেশন তৈরি কর...
নেমড পাইপ ব্যবহারিকভাবে — ডিজাইন থেকে নিরাপত্তা পর্যন্ত Windows-এর মানক IPC
Windows-এর মানক আন্তঃপ্রক্রিয়া যোগাযোগ নেমড পাইপের ব্যবহারিক গাইড। প্রাথমিক উৎস থেকে এই নিবন্ধ বাইট ও মেসেজ মোডের পছন্দ, একাধিক ক্লায়েন...
Group Policy থেকে Intune — ছোট ও মাঝারি ব্যবসার জন্য ডিভাইস-ব্যবস্থাপনা মাইগ্রেশন নির্দেশিকা
AD সার্ভার বদলাতে এলে Group Policy-তে থাকবেন না Entra ID প্লাস Intune-এ যাবেন? এই নিবন্ধ ছোট ও মাঝারি ব্যবসার জন্য দুইয়ের প্রয়োগের পার্...
Windows সার্ভিস অ্যাকাউন্ট বেছে নেওয়া — LocalSystem, ভার্চুয়াল অ্যাকাউন্ট ও gMSA
এখনও Windows সার্ভিস LocalSystem-এ চালাচ্ছেন? এই নিবন্ধ LocalService, NetworkService, ভার্চুয়াল অ্যাকাউন্ট, ডোমেন ব্যবহারকারী ও gMSA-এর ...
সম্পর্কিত বিষয়
এই পৃষ্ঠাগুলো বিষয়টিকে সেবা ও সিদ্ধান্তের বৃহত্তর প্রেক্ষাপটে স্থাপন করে।
Windows-এর প্রযুক্তিগত বিষয়
Windows ডেভেলপমেন্ট, বাগ তদন্ত ও বিদ্যমান সম্পদ ব্যবহারের প্রবেশদ্বার।
এই বিষয়ের সাথে সম্পর্কিত সেবা
নিবন্ধটি নিচের সেবাগুলোর সাথে সরাসরি সম্পর্কিত।
Windows অ্যাপ ডেভেলপমেন্ট
ব্যবসায়িক অ্যাপ, ডিভাইস ইন্টিগ্রেশন ও যোগাযোগ টুল, চাহিদা থেকে ডেভেলপমেন্ট পর্যন্ত।
প্রায়শ জিজ্ঞাসিত প্রশ্ন
এই নিবন্ধের বিষয়ে পরামর্শে প্রায়ই আসা প্রশ্ন।
- অডিট পলিসি কিছুই সেট করিনি, তবু Security লগে 4624 ও 4625 আসছে কেন?
- কারণ Windows-এ ডিফল্টে চালু অডিট সাবক্যাটাগরি আছে। যেমন «লগঅন» সাবক্যাটাগরি Windows 10 ভার্সন 1809 থেকে সফল ও ব্যর্থ দুটোই ডিফল্টে চালু, তাই নিজে কিছু না সেট করলেও 4624 (সফল) ও 4625 (ব্যর্থ) রেকর্ড হয়। তবে ডিফল্ট রাখলে শংসাপত্র যাচাই (4776) বা প্রক্রিয়া তৈরি (4688) — তদন্তে যে ইভেন্টগুলো আসলে চাই — অনেকগুলোই রেকর্ড হয় না। নিজের পরিবেশে কী চালু তা `auditpol /get /category:*` দিয়ে দেখা যায়। তারপর যা কম, বিস্তারিত অডিট পলিসি দিকে স্পষ্ট করে চালু করাই বাস্তব ছাঁচ।
- সাইন-ইন ব্যর্থতা খুঁজতে চাই, কিন্তু লক্ষ্য সার্ভারের Security লগে 4625 পাই না। কোথায় দেখব?
- আগে নীতিটি নিশ্চিত করুন: 4625 রেকর্ড হয় «যে কম্পিউটারে লগঅন চেষ্টা হয়েছিল» সেখানে। ব্যবহারকারীর টার্মিনালে সাইন-ইন ব্যর্থ হলে টার্মিনালে, ফাইল সার্ভারে প্রবেশ ব্যর্থ হলে ফাইল সার্ভারে। তারপর `auditpol /get /category:*` দিয়ে «লগঅন» সাবক্যাটাগরির ব্যর্থতার অডিট চালু কি না দেখুন। ডোমেইন অ্যাকাউন্টে প্রায়ই ডোমেইন কন্ট্রোলার দিকের শংসাপত্র যাচাই (4776) বা Kerberos প্রাক-প্রমাণীকরণ ব্যর্থতা (4771)-এ চিহ্ন থাকে, আর কোন টার্মিনাল তা ধরা না গেলে DC দিক থেকে খোঁজাই দ্রুত পথ। তবু না পেলে লগ ওভাররাইটে পুরনো অংশ মুছে গেছে কি না (লগের সর্বোচ্চ আকার ও প্রাচীনতম ইভেন্টের সময়) দেখুন।
- প্রক্রিয়া তৈরি (4688)-এর কমান্ড-লাইন রেকর্ড চালু করা উচিত?
- তদন্তমূল্য খুব বেশি, কিন্তু ঝুঁকি বুঝে তারপর চালু করার সেটিং। চালু করলে প্রতিটি প্রক্রিয়ার কমান্ড-লাইন আর্গুমেন্ট Security লগে সাধারণ লেখায় রেকর্ড হয়। কমান্ড লাইনে পাসওয়ার্ড বা API কী পাঠায় এমন স্ক্রিপ্ট বা ব্যবসায়িক অ্যাপ একটাও থাকলে সেই গোপন তথ্য Security লগ পড়তে পারে এমন সবার চোখে পড়ে। Microsoft নিজেই এই সতর্কতা লিখে রেখেছে। আগে নিজের স্ক্রিপ্টগুলো গোপন তথ্য কমান্ড-লাইন আর্গুমেন্টে পাঠায় কি না খুঁজুন, পাঠালে সেই জায়গা সেরে তারপর চালু করুন — এই ক্রমই সুপারিশ।
- Security লগের সর্বোচ্চ আকার কত হওয়া উচিত?
- «হাতে কত দিন রাখতে চাই» থেকে উল্টো হিসাবই সঠিক পথ, সর্বজনীন সংখ্যা নেই। বর্তমান সেটিং ও বাস্তব আচরণ `Get-WinEvent -ListLog Security` দিয়ে দেখা যায়, প্রাচীনতম ইভেন্টের সময় ও এখনকার সময়ের ফারাকই «এখন আসলে কত দিন আছে»। অডিট সাবক্যাটাগরি বাড়ালে ইভেন্টের পরিমাণও বাড়ে, তাই সেটিং বদলানোর পর এই প্রকৃত ধরে রাখার দিন অবশ্যই আবার দেখুন। ঘটনা মোকাবিলায় কয়েক সপ্তাহ থেকে কয়েক মাস আগের লগ দরকার হওয়া অস্বাভাবিক নয়, তাই ওভাররাইটে মুছে যাওয়ার আগে নিয়মিত রপ্তানি করুন, অথবা লগ সংগ্রহের ব্যবস্থায় অন্য মেশিনে জমা রাখুন।
- অ্যাকাউন্ট লকআউট (4740)-এর কারণ কীভাবে খুঁজব?
- প্রথম সূত্র 4740 ইভেন্টের «Caller Computer Name» ফিল্ড। এখানে লকআউটের ট্রিগার হওয়া ব্যর্থ লগঅনের উৎস কম্পিউটার রেকর্ড থাকে। তবে ব্যর্থতার রেকর্ড নিজে (4625) উৎসে নয়, লগঅন চেষ্টা গ্রহণকারী দিকে থাকে — সেটা মনে রাখুন। নেটওয়ার্ক লগঅন থেকে এলে গন্তব্য সার্ভারের 4625, ডোমেইন অ্যাকাউন্ট হলে ডোমেইন কন্ট্রোলারের 4776/4771 সময়ক্রমে ধরুন। তারপর উৎস হিসেবে চিহ্নিত টার্মিনালে পাসওয়ার্ড বদলের পরেও পুরনো শংসাপত্র ধরে রাখা কিছু — সংরক্ষিত শংসাপত্র, বিচ্ছিন্ন থাকা রিমোট ডেস্কটপ সেশন, পুরনো পাসওয়ার্ডে সেট সার্ভিস বা শিডিউল করা টাস্ক — খুঁজে দেখুন। লকআউট বারবার হলে ঘড়ি সিঙ্ক সরতেও দেখুন।