جرم شناسی دیجیتال (فارنزیک) و بررسی حادثه امنیتی

راهنمای جرم شناسی دیجیتال

Incident Response Steps: جرم شناسی دیجیتال کجای کار است؟

مدل رایج NIST SP 800-61 پاسخ به حادثه را چهار مرحله می داند: آمادگی؛ تشخیص و تحلیل؛ مهار، پاکسازی و بازیابی؛ و فعالیت های پس از حادثه. جرم شناسی دیجیتال بیشتر در مرحله تحلیل است، اما روی همه مراحل بعدی اثر می گذارد، چون تا دامنه نفوذ معلوم نباشد، مهار و پاکسازی ناقص می ماند.

ترتیب کارها هم به همین دلیل مهم است. شواهد فرار مثل محتوای حافظه، اتصال های شبکه باز و فرایندهای در حال اجرا با خاموش شدن سیستم از بین می روند و باید پیش از image دیسک جمع شوند. اگر سرور پیش از تماس نصب مجدد شده باشد، بعضی پرسش ها بی پاسخ می ماند.

بررسی لاگ های ویندوز: کدام رویدادها مهم اند؟

در لاگ Security، رویداد 4624 ورود موفق و 4625 ورود ناموفق است و Logon Type، مثلاً 10 برای RDP، مسیر ورود را نشان می دهد. رویداد 4672 ورود با دسترسی ویژه، 4720 ساخته شدن حساب کاربری و 4698 ساخته شدن scheduled task را ثبت می کند. رویداد 1102 یعنی لاگ Security پاک شده است.

در لاگ System، رویداد 7045 نصب سرویس جدید را نشان می دهد که ابزارهایی مثل PsExec به جا می گذارند. لاگ TerminalServices-RemoteConnectionManager اتصال های RDP را با رویداد 1149 ثبت می کند و رویداد 4104 در لاگ PowerShell، اگر Script Block Logging فعال باشد، متن اسکریپت های اجراشده را نگه می دارد. در لینوکس، auth.log یا secure، خروجی last و lastb و تاریخچه shell کاربران نقطه شروع هستند.

چرا لاگ های سرور هک شده اغلب کافی نیستند؟

در بسیاری از بررسی ها، لاگی که باید جواب را بدهد وجود ندارد. لاگ Security ویندوز به طور پیش فرض کوچک است و روی سرور پرکار در چند روز بازنویسی می شود. ثبت ساخته شدن فرایندها (رویداد 4688) و Script Block Logging به طور پیش فرض خاموش اند، و وقتی ساعت سرورها با هم نمی خواند، ساختن خط زمانی سخت می شود.

راه حلش آمادگی پیش از حادثه است: بزرگ تر کردن لاگ ها، فعال کردن audit policy مناسب، نصب Sysmon، ارسال لاگ ها به سروری جداگانه که مهاجم نتواند پاکشان کند، و هم سان کردن ساعت همه سیستم ها. با این تنظیمات، خط زمانی حادثه بعدی بر پایه شواهد ساخته می شود.

بررسی جرم شناسی دیجیتال تا کجا پیش می رود؟

تعداد سیستم های درگیر مهم است، و دست نخورده بودن شواهد از آن هم مهم تر. سیستمی که هنوز روشن است و حافظه اش را می شود برداشت، به پرسش های بیشتری جواب می دهد تا سروری که بعد از حادثه ریستور یا نصب مجدد شده است.

مدت نگهداری لاگ ها و وجود لاگ مرکزی هم اثر دارد، همین طور رمزنگاری دیسک با BitLocker یا LUKS و در دسترس بودن کلید بازیابی، همکاری دیتاسنتر یا ارائه دهنده هاست و حجم دیسک ها. کاربرد گزارش هم مهم است: گزارشی که برای پیگیری حقوقی تهیه می شود، مستندسازی دقیق تری از زنجیره نگهداری شواهد می خواهد.