Event Log ویندوز: کدام رویدادها واقعاً مهم‌اند

یک ویندوز سرور معمولی در روز ده‌ها هزار رویداد ثبت می‌کند. روی Domain Controller یا سرور RDP پرترافیک، این عدد به صدها هزار می‌رسد. اکثر قریب به اتفاقشان بی‌اهمیت‌اند: ورود موفق سرویس‌ها، تغییر وضعیت عادی سرویس‌ها، هشدارهای بی‌ضرری که از روز نصب تکرار می‌شوند. چالش Event Log کمبود داده نیست؛ پیدا کردن آن چند ده رویدادی است که واقعاً چیزی می‌گویند.

این مقاله فهرست کوتاه‌شدهٔ همان رویدادهاست، بر اساس آنچه در سال‌ها بررسی حادثه و راه‌اندازی پایش واقعاً به کارم آمده، با دستورهایی برای جستجوی سریعشان. چارچوب کلی پایش ویندوز سرور را در راهنمای جامع پایش و نگهداری ویندوز سرور نوشته‌ام؛ اینجا فقط Event Log.

ساختار Event Log در یک نگاه

هر رویداد چند فیلد کلیدی دارد: لاگ (System، Security، Application یا یکی از لاگ‌های Applications and Services)، منبع (Provider؛ مثلاً Service Control Manager)، شناسه (Event ID)، سطح (Critical، Error، Warning، Information، و در لاگ Security: Audit Success و Audit Failure)، زمان، و داده‌های رویداد (EventData) که جزئیات اصلی در آن است.

یک نکتهٔ مهم که خیلی‌ها را گمراه می‌کند: شناسهٔ رویداد به‌تنهایی یکتا نیست؛ ترکیب منبع و شناسه یکتاست. شناسهٔ 7 از منبع disk معنای کاملاً متفاوتی با شناسهٔ 7 از یک منبع دیگر دارد. در جستجوها و قانون‌های هشدار، همیشه منبع را هم مشخص کنید.

# All logs that currently have events, biggest first
Get-WinEvent -ListLog * -ErrorAction SilentlyContinue |
  Where-Object RecordCount -gt 0 |
  Sort-Object FileSize -Descending |
  Select-Object LogName, RecordCount, @{n='SizeMB';e={[math]::Round($_.FileSize/1MB,1)}}, MaximumSizeInBytes -First 15

لاگ System: سلامت سیستم‌عامل و سخت‌افزار

رویداد 1074 ارزش ویژه‌ای در عیب‌یابی دارد چون نام پروسس، حساب کاربر و دلیل ریبوت را ثبت می‌کند. برای ساختن تاریخچهٔ ریبوت‌ها:

Get-WinEvent -FilterHashtable @{LogName='System'; Id=41,1074,6008; StartTime=(Get-Date).AddDays(-30)} |
  Select-Object TimeCreated, Id, @{n='Msg';e={$_.Message.Split("`n")[0]}} |
  Format-Table -AutoSize -Wrap

لاگ Security: چه کسی، کِی، از کجا

لاگ Security فقط چیزهایی را ثبت می‌کند که سیاست ممیزی (audit policy) روشن کرده باشد. پیش از هر کاری وضعیت را با auditpol /get /category:* ببینید. مهم‌ترین رویدادها:

Logon Type: کلید فهم 4624 و 4625

یک 4625 به‌تنهایی کم می‌گوید؛ فیلد Logon Type و آی‌پی مبدأ (IpAddress) داستان را کامل می‌کنند. رایج‌ترین انواع: ۲ ورود محلی پشت کنسول، ۳ ورود شبکه‌ای (دسترسی به اشتراک فایل، بیشتر ورودهای سرویس‌ها)، ۴ batch (Scheduled Task)، ۵ سرویس، ۷ باز کردن قفل صفحه، ۱۰ RemoteInteractive یعنی RDP، و ۱۱ ورود با credential کش‌شده. موج 4625 با Logon Type 3 یا 10 از آی‌پی‌های بیرونی، امضای حملهٔ حدس رمز است. فیلد Status و SubStatus هم دلیل شکست را می‌گوید؛ مثلاً 0xC000006A رمز اشتباه برای حساب موجود و 0xC0000064 نام کاربری ناموجود. اگر بیشتر تلاش‌ها روی نام‌های ناموجود است، مهاجم دارد فهرستی از نام‌های رایج را امتحان می‌کند.

# Failed logons in the last 24h: source IP, target account, logon type
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]@{ Ip=$d.IpAddress; User=$d.TargetUserName; Type=$d.LogonType; Sub=$d.SubStatus }
  } | Group-Object Ip, Type | Sort-Object Count -Descending | Select-Object Count, Name -First 15

برای جستجوی دقیق‌تر بدون حلقه روی همهٔ رویدادها، XPath سریع‌تر است؛ فیلتر در خود سرویس Event Log اجرا می‌شود:

# RDP logons (type 10) in the last hour, filtered server-side
$xp = "*[System[(EventID=4624) and TimeCreated[timediff(@SystemTime) <= 3600000]]] and *[EventData[Data[@Name='LogonType']='10']]"
Get-WinEvent -LogName Security -FilterXPath $xp | Select-Object TimeCreated, Message -First 20

# The same idea from cmd with wevtutil
wevtutil qe Security /q:"*[System[(EventID=1102)]]" /c:5 /rd:true /f:text

لاگ Application و لاگ‌های نقش‌ها

لاگ Application پرنویزترین لاگ است، ولی چند رویداد آن ارزش پایش دارند: 1000 از منبع Application Error (crash یک برنامه، با نام فایل اجرایی و ماژول مقصر)، 1002 از Application Hang (برنامه از پاسخ افتاد)، و 1026 از ⁦.NET⁩ Runtime (استثنای مدیریت‌نشده در برنامهٔ ⁦.NET⁩ که معمولاً جزئیات کامل خطا را دارد). crashهای تکراری یک سرویس اپلیکیشن، اغلب پیش از قطعی کامل دیده می‌شوند.

از لاگ‌های Applications and Services، این‌ها را بشناسید:

• Microsoft-Windows-Windows Defender/Operational: رویداد 1116 (تهدید تشخیص داده شد)، 1117 (اقدام روی تهدید انجام شد)، 5001 (حفاظت بلادرنگ خاموش شد) و 5007 (پیکربندی تغییر کرد، از جمله افزودن استثنا).
• Microsoft-Windows-TerminalServices-LocalSessionManager/Operational: نشست‌های RDP، با آی‌پی مبدأ.
• Microsoft-Windows-TaskScheduler/Operational: اجرا و شکست Scheduled Taskها؛ بکاپ شبانه‌ای که شکست خورده اینجاست.
• روی DC: Directory Service و DFS Replication برای مشکلات تکرار.

اندازه و نگه‌داری لاگ

بسیاری از بررسی‌های حادثه که در آن‌ها بوده‌ام، با این جمله به بن‌بست خوردند: «لاگ امنیتی فقط دو روز گذشته را دارد». اندازهٔ پیش‌فرض لاگ‌ها برای سرورهای پرکار کوچک است و وقتی پر می‌شوند، قدیمی‌ترین رویدادها بازنویسی می‌شوند.

wevtutil gl Security
wevtutil sl Security /ms:1073741824
wevtutil sl "Microsoft-Windows-Windows Defender/Operational" /ms:104857600

در دامین این اندازه‌ها را با GPO (Computer Configuration ← Policies ← Administrative Templates ← Windows Components ← Event Log Service) تنظیم کنید تا روی همهٔ سرورها یکسان باشد. حتی لاگ بزرگ هم روی خود سرور است و مهاجمی که ادمین شده می‌تواند پاکش کند (رویداد 1102 دقیقاً همین را ثبت می‌کند). برای نگه‌داری مطمئن، رویدادهای مهم باید به جای دیگری هم فرستاده شوند: Windows Event Forwarding داخلی ویندوز، یک SIEM، یا سامانهٔ مرکزی لاگ. اگر تیم شما لاگ اپلیکیشن‌های بک‌اند را هم متمرکز می‌کند، LogMug برای همین ساخته شده است.

اشتباه‌های رایج

پیش از فهرست اشتباه‌ها، یک نمونهٔ کوتاه از اینکه این رویدادها در کنار هم چطور داستان می‌سازند. فرض کنید صبح شنبه سرویس اپلیکیشن روی یک سرور متوقف است. خط زمانی از Event Log، به ترتیب: پنجشنبه ساعت ۲۳:۱۰، صدها 4625 با Logon Type 10 از یک آی‌پی خارجی؛ ساعت ۲۳:۴۲، یک 4624 موفق با همان آی‌پی و Logon Type 10 روی حساب «backup»؛ ساعت ۲۳:۵۰، رویداد 7045 برای سرویسی با نام بی‌معنا و مسیر فایل در C:\Users\Public؛ جمعه ساعت ۰۱:۱۵، رویداد 5001 از Defender (حفاظت بلادرنگ خاموش شد)؛ ساعت ۰۱:۲۰، رویداد 1102. اینکه سرویس اپلیکیشن متوقف است، کوچک‌ترین مشکل این سرور است. هر کدام از این پنج رویداد، اگر هشدار داشت، این خط زمانی را پنجشنبه شب قطع می‌کرد. نکتهٔ دیگر: رویداد 1102 خودش آخرین رویداد لاگ پیش از پاک شدن نیست، اولین رویداد لاگ تازه است؛ پس اگر رویدادهای قبل از آن را به جای دیگری نفرستاده باشید، از دست رفته‌اند.

• جستجو با Where-Object روی کل لاگ. Get-WinEvent -LogName Security | Where-Object Id -eq 4625 روی لاگ چندگیگابایتی دقیقه‌ها طول می‌کشد و حافظه می‌خورد. همیشه FilterHashtable یا FilterXPath.
• هشدار روی هر Error. بسیاری از Errorهای لاگ System و Application بی‌خطرند و از روز نصب تکرار می‌شوند. هشدار را روی فهرست مشخص بگذارید، نه روی سطح.
• فرض اینکه ممیزی روشن است. 4688 و بسیاری از رویدادهای مدیریت حساب به‌طور پیش‌فرض یا خاموش‌اند یا ناقص.
• شناسه بدون منبع. قانونی که روی «Event ID 7» تعریف شود، رویدادهای بی‌ربط منابع دیگر را هم می‌گیرد.
• نادیده گرفتن ساعت. وقتی رویدادهای چند سرور را مقایسه می‌کنید، اختلاف ساعت سرورها کل خط زمانی را به هم می‌ریزد. همگامی ساعت پیش‌نیاز بررسی حادثه است.

اگر بخواهم کل این مقاله را در چند رویداد خلاصه کنم، برای هر سرور ویندوزی دست‌کم این‌ها باید هشدار داشته باشند: 4625 انبوه با آی‌پی مبدأ، 4720 و 4732 و 4728، 1102، 7045، توقف غیرمنتظرهٔ سرویس‌های اصلی (7031 و 7034)، 41 و 6008، و 1116 از Defender. این همان هستهٔ رویدادهایی است که در راهنمای امنیت سرور و راهنمای محافظت در برابر باج‌افزار هم به آن‌ها رسیدم. ServerMug بیشتر این‌ها را مستقیم از Event Log هر سرور می‌خواند و برای ورودهای ناموفق، آی‌پی‌های مبدأ و حساب‌های هدف را هم در هشدار می‌آورد؛ فهرست دقیقش در مرجع چک‌ها، سنجه‌ها و رویدادها است.

منابع و مطالعهٔ بیشتر

• رویدادهایی که باید پایش شوند (Microsoft Learn) — فهرست رسمی شناسه‌های امنیتی با سطح اهمیت پیشنهادی مایکروسافت.
• رویداد 4625: ورود ناموفق — همهٔ فیلدها، Logon Typeها و کدهای Status و SubStatus.
• مستندات Get-WinEvent — فیلتر با FilterHashtable، FilterXPath و FilterXml.
• مستندات wevtutil — پرس‌وجو، تنظیم اندازه، خروجی گرفتن و پاک کردن لاگ‌ها از خط فرمان.