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

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

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 و در دسترس بودن کلید بازیابی، همکاری دیتاسنتر یا ارائه دهنده هاست، حجم دیسک ها و کاربرد گزارش است. گزارشی که برای پیگیری حقوقی تهیه می شود، مستندسازی دقیق تری از زنجیره نگهداری شواهد می خواهد.