ممکنه یه روز (یا یه شب) به خودتون بیایید و ببینید کل شبکه یا بخشی از شبکه کار افتاده، یا با یه پیغام تهدید آمیز مواجه بشید که مقدار زیادی داده از شبکه دزدیده شده یا بدتر از اون، تو اخبار متوجه بشید که داده‌های سازمانتون منتشر شده. معمولا در این مواقع با خودمون میگیم که خیلی دیر شده و کاری نمیشه کرد. آماده میشید استعفای خودتون رو بنویسید یا از هوش مصنوعی می‌پرسید الان چه جوابی باید به مدیرم بدم تا تقصیرها رو گردن شما نندازه! اما باید گفت می‌تونید خسارات کمتری رو تجربه کنید اگه…
بسیاری از حملات سایبری زمانی کشف میشوند که کار از کار گذشته است. ممکن است پیش از وقوع حادثه مهاجم هفته‌ها، ماه‌ها یا حتی سال‌ها در شبکه حضور داشته، اطلاعات را جمع‌آوری کرده، سطح دسترسی خود را افزایش داده و در نهایت ردپای خود را پاک کرده است. در چنین شرایطی اولین سؤالی که (عموما همراه با گیجی) مطرح میشود این است: چه اتفاقی افتاده است؟
پاسخ به این سوال را در بیشتر موارد میتوان لاگ‌ها (Logs) پیدا کرد.
در دنیای امنیت سایبری، لاگ‌ها صرفاً فایل‌هایی برای ثبت خطا یا فعالیت‌های روزمره نیستند؛ بلکه مهم‌ترین منبع حقیقت (Source of Truth) برای تحلیل رخدادهای امنیتی به حساب می آیند. اگر شبکه را به یک ساختمان بزرگ تشبیه کنیم، لاگ‌ها همان دوربین‌های مداربسته، دفتر ثبت ورود و خروج و گزارش نگهبانان هستند. بدون آن‌ها، حتی اگر بهترین تجهیزات امنیتی را در اختیار داشته باشید و پشت آن ها خبره ترین کارشناسان امنیت شبکه را قرار داده باشید، هنگام وقوع یک حادثه تقریباً هیچ تصویری از آنچه رخ داده است نخواهید داشت.
لاگ چیست؟ ساختار یک لاگ چگونه است؟
اما لاگ (Log) چیست؟ لاگ رکوردی از یک رویداد است که در یک سیستم ثبت میشود. این رویداد می‌تواند مربوط به سیستم‌عامل، یک نرم‌افزار، پایگاه داده، تجهیزات شبکه یا سرویس‌های ابری باشد. به طور کلی هر جزئی از شبکه (در صورتی که کمپانی تولید کننده طراحی کرده باشد) می تواند لاگ تولید کند.
یک لاگ معمولاً شامل اطلاعاتی مانند موارد زیر است:
- زمان دقیق وقوع (Timestamp)
- منبع ایجادکننده رویداد
- نوع یا سطح رویداد (Severity)
- شناسه رویداد
- شرح رویداد
- اطلاعات تکمیلی مرتبط
همانطور که بالاتر گفته شد هر جزئی در شکبه می تواند لاگ تولید کند پس طبیعی است که هریک از این اجزا لاگ مرتبط با کاربرد خود، و متناسب با رویدادی که رخ داده است محتوی متفاوتی داشته باشد. به عنوان مثال لاگی که یک Web Server تولید می کند شامل IP مبدا و مقصد، آدرس درخواست داده شده و پاسخ سرور به این درخواست است، در حالی که لاگی که توسط یک سوئیچ در شبکه تولید میشود شامل روشن یا خاموش شدن پورت سوئیچ یا اتصال به کنسول مدیریت آن باشد.
نگاه ما در امنیت به لاگ به چشم قابلیت بازسازی یک حادثه، یا مشاهده رفتار مخرب قبل از این که حادثه ای اتفاق بیوفتد است. هرچه بتوانیم مسیر وقوع یک حمله را دقیق‌تر بازسازی کنیم، شانس بیشتری برای مهار و جلوگیری از تکرار آن خواهید داشت.
لاگ؛ اولین شاهد و آخرین مدرک
تقریباً تمام فرآیندهای پاسخ به حادثه (Incident Response) به لاگ‌ها وابسته هستند و بدون آن باید خود را برای دریافت ضربه بعدی از مهاجمین سایبری آماده کنیم.
یک تیم امنیت با استفاده از لاگ‌ها می‌تواند:
- رفتارهای مشکوک را شناسایی کند (Detection)
- مسیر نفوذ مهاجم را تحلیل کند (Investigation)
- دامنه آلودگی را مشخص کند (Containment)
- علت اصلی حادثه را پیدا کند (Root Cause Analysis)
- مستندات لازم برای تحلیل‌های بعدی یا الزامات قانونی را تهیه کند (Forensics)
به همین دلیل گفته میشود:
لاگ‌ها اولین شاهد یک حمله و آخرین مدرک آن هستند.
اما برای دید بهتر به شبکه و شناسایی حملات باید از همه چیز لاگ بگیریم؟
آیا باید همه چیز را لاگ کنیم؟
یکی از رایج‌ترین اشتباهات در طراحی سیستم‌های لاگ‌گیری این است که تصور کنیم هرچه اطلاعات بیشتری ثبت کنیم، امنیت بیشتری خواهیم داشت. غافل از این که این رویکر معمولا نتیجه عکس داردو
ثبت بی‌هدف و حریصانه تمام رویدادها باعث میشود:
- حجم بسیار زیادی داده تولید شود. که برای آن نیاز به فضای ذخیره سازی و پهنای باند بیشتری هستیم.
- تحلیل رخدادهای امنیتی دشوارتر شود زیرا نظم دادن به حجم بالای لاگ پیچیده تر شده و در نتیجه رویدادهای مهم در میان سیلی از لاگ های کم اهمیت گم میشوند.
هدف از Logging، ثبت داده‌های ارزشمند است، نه تولید بیشترین حجم ممکن از اطلاعات.
پس لازم است به این نکته اشاره کنم که: در امنیت، کیفیت لاگ‌ها هست که اهمیت دارد نه تعداد یا مدت نگهداری بالای آن ها.
چه رویدادهایی ارزش امنیتی بیشتری دارند؟
اگر هدف، کشف حملات و تحلیل رخدادهای امنیتی باشد، برخی از رویدادها اهمیت بسیار بیشتری نسبت به بقیه دارند. مهم‌ترین آن‌ها عبارت‌اند از:
- ورود موفق و ناموفق کاربران (احتمال Credential Attack)
- تلاش‌های مکرر برای احراز هویت (احتمال Brute Force)
- ایجاد، حذف یا غیرفعال شدن حساب‌های کاربری (احتمال Account Manipulation )
- تغییر سطح دسترسی کاربران (احتمال Privilege Escalation)
- تغییرات در سیاست‌های امنیتی و تنظیمات سیستم (احتمال Defense Evasion)
- نصب یا حذف سرویس‌ها (احتمال Service Execution)
- اجرای فایل‌ها و فرآیندهای مشکوک (احتمال Malware Execution)
- دسترسی به فایل‌های حساس (احتمال Data Discovery یا Data Exfiltration)
- تغییر قوانین فایروال (احتمال Defense Evasion)
- تغییرات در رجیستری ویندوز یا فایل‌های حیاتی لینوکس (احتمال Defense Evasion)
- برقراری ارتباطات شبکه غیرمعمول (احتمال ارتباط با C2)
این رویدادها معمولاً اولین نشانه‌های یک حمله یا سوءاستفاده هستند که راهنمای ما به عنوان یک کارشناس امنیت شبکه در رهگیری و تشخیص یک حمله سایبری هستند.
سطوح مختلف لاگ
تقریباً تمام سیستم‌های مدرن، رویدادها را بر اساس میزان اهمیت دسته‌بندی میکنند. این دسته بندی‌ها به خوبی نشان می‌دهد توجه ما باید به کدام بخش از لاگ ها معطوف باشد و حالا که می دانیم نیازی به ذخیره تمام لاگ ها نداریم، میتوانیم تشخیص دهیم کدام بخش از لاگ ها مورد نیاز ما هستند.
رایج‌ترین سطوح عبارت‌اند از:
- Critical / Emergency: خرابی‌های بحرانی که عملکرد سیستم را مختل میکنند.
- Error: خطاهایی که باعث شکست یک عملیات شده‌اند.
- Warning: رویدادهایی که هنوز خطا نیستند اما میتوانند نشانه یک مشکل باشند.
- Information (Info): فعالیت‌های عادی سیستم.
- Debug: اطلاعات دقیق برای عیب‌یابی.
- Trace: جزئی‌ترین سطح ثبت رویدادها که معمولاً فقط هنگام تحلیل مشکلات پیچیده فعال میشود.
در برخی موارد (مانند سیستم عامل ویندوز) سطح Security داریم که مستقیما لاگ هایی که مربوط به امینت هستند را شامل می شود.
توجه به این نکته دارای اهمیت است که بداینم هدف ما از لاگ گیری چیست؟ به عنوان مثال اگر هدف تنها مختص به Debug یک اپلیکیشن توسط تیم توسعه دهنده است، اصلا نیازی به جمع آوری لاگ Security نیست. اما از آنجایی که نگاه ما به لاگ با عینک امنیتی است، توجه ما به لاگ هایی است که به برپایی امنیت کمک میکنند.
یک لاگ خوب چه ویژگی‌هایی دارد؟
ثبت یک پیام مانند «Error!» تقریباً هیچ ارزشی برای تیم امنیت ندارد.
یک لاگ مناسب باید بتواند بدون نیاز به حدس و گمان، شرایط وقوع یک رویداد را توضیح دهد.
بهتر است هر لاگ (منظورم لاگ مطلوب یک کارشناس امنیت شبکه) با توجه به منبعی که لاگ را تولید میکند شامل اطلاعاتی مانند موارد زیر باشد:
- زمان دقیق (حتی تا میلی ثانیه)
- نام سرویس یا سیستم تولیدکننده
- شناسه کاربر یا سرویس
- آدرس IP مبدأ
- نتیجه عملیات (Success یا Failure)
- دلیل خطا
- شناسه یکتای درخواست (Correlation ID یا Trace ID)
وجود زمان یا Timestamp در لاگ تقریبا از ضروریات هر لاگی است. در صورتی زمان لاگ ها دقیق باشد و سیستم هایی که تولید کننده لاگ هستند همه از زمان پیروی کنند (پیشنهاد ما استفاده از یک NTP Server واحد) و البته که از همه اجزایی که نیاز داریم لاگ دریافت کرده باشیم، میتوانیم یک TimeLine از حمله را که از نقطه آغاز تا نقطه پایان را نمایش دهد.
مهاجمان از لاگ‌ها متنفرند
یکی از اولین اقدام‌های مهاجم پس از به دست گرفتن دسترسی مدیریتی، حذف یا دستکاری لاگ‌ها است (خبر خوب این که ما میتوانیم در بعضی موارد متوجه حذف لاگ شویم، خبر بد این که فقط میتوانیم متوجه حذف لاگ شویم!)
به همین دلیل، در معماری‌های امنیتی توصیه میشود:
- لاگ‌ها روی همان سروری که سرویس اجرا میشود نگهداری نشوند. پیشنهاد میشود لاگ ها به سرورهای Log Collector یا SIEM ارسال شوند تا در صورت حذف یا تغییر در لاگ، نسخه اصلی آن حفظ شود.
- این ارسال به صورت آنلاین و لحظه ای انجام شود.
- امکان حذف یا تغییر آن‌ها تا حد امکان محدود شود.
- در صورت امکان از فضای ذخیره‌سازی تغییرناپذیر (Immutable Storage) استفاده شود.
حالا با این توضیحات میدانیم که اگر مهاجم بتواند لاگ‌ها را حذف کند، عملاً بخش مهمی از شواهد حادثه هم از بین خواهد رفت.
از لاگ تا SIEM
همانطور که بالاتر گفته شد، در سازمان‌های بزرگ لاگ‌ها صرفاً ذخیره نمی‌شوند؛ بلکه وارد سامانه‌های مدیریت اطلاعات و رخدادهای امنیتی (SIEM) میشوند.
SIEM ها ابزارهایی هستند که علاوه بر ذخیره لاگ در آن، میتوانند میان لاگ های مختلف ارتباط برقرار کنند. به عبارت دیگر SIEM ابزار ما برای بررسی لاگ هستند. از آنجایی که در هدف از این مقاله معرفی این ابزار دوست داشتنی نیست، بیشتر از این به آن نمیپردازیم.
فرض کنید در فاصله چند دقیقه، رویدادهای زیر ثبت شوند:
- چندین تلاش ناموفق برای ورود
- اجرای PowerShell روی یک سرور
- ایجاد یک حساب کاربری جدید
- برقراری ارتباط با یک IP ناشناس
هرکدام از این رویدادها به‌تنهایی ممکن است عادی به نظر برسند ، اما یک سامانه SIEM با کنار هم قرار دادن آن‌ها می‌تواند وقوع یک حمله را تشخیص دهد و پیش از گسترش آن به تیم امنیت هشدار دهد. به عبارت دیگر با کنار هم قرار دادن لاگ ها، میتوانیم تصویر کلی از حمله را ترسیم کنیم.
پس ارزش واقعی لاگ‌ها زمانی مشخص میشود که بتوان میان آن‌ها ارتباط برقرار کرد.
جمع‌بندی
در امنیت سایبری، حقیقت همیشه در لاگ‌ها پنهان است. به جرئت میتوان گفت بدون لاگ، هیچ تصویری برای دفاع سایبری نمیتوان متصور شد.
هر تصمیمی که امروز درباره لاگ‌گیری می‌گیرید، کیفیت تحلیل شما در زمان وقوع یک حادثه یا در حالتی بهتر قبل از وقوع حادثه را تعیین میکند. اگر لاگ مناسبی نداشته باشید، حتی بهترین تیم امنیت نیز نمی‌تواند با اطمینان بگوید مهاجم از کجا وارد شده، چه اقداماتی انجام داده و چه اطلاعاتی را در اختیار گرفته است.
لاگ‌گیری تنها ثبت چند خط متن در یک فایل نیست؛ بلکه یکی از مهم‌ترین لایه‌های دفاعی هر زیرساخت است. ثبت هوشمندانه رویدادها، نگهداری امن آن‌ها، جلوگیری از دستکاری، و تحلیل صحیح لاگ‌ها، تفاوت میان یک حادثه قابل مدیریت و یک بحران غیرقابل کنترل را رقم می‌زند.
در نهایت، یک اصل را همیشه به خاطر داشته باشید:
سیستمی که به‌درستی لاگ‌گیری نمی‌شود، در زمان وقوع یک حمله، تقریباً هیچ سپری برای دفاع از خود در برابر حملات بعدی نخواهد داشت.