به یک قسمت دیگه از پادکست ما خوش اومدید. امروز قراره بریم سراغ یکی از اصلی‌ترین ابزارهای هر مرکز عملیات امنیت، یعنی سیستم SIEM. می‌خوایم با هم سفری داشته باشیم به قلب معماری SIEM، اجزای اون رو کالبدشکافی کنیم و با روش‌های مختلف جمع‌آوری لاگ آشنا بشیم. این دانش، چه برای یک تحلیلگر تازه‌کار و چه برای یک معمار امنیت باتجربه، کاملاً حیاتیه.

اما SIEM دقیقاً چیه؟ شاید اسم‌های تجاری مختلفی به گوشتون خورده باشه، ولی در اصل، SIEM یک سیستم پیچیده با اجزای مختلفه. برای اینکه این مفهوم رو بهتر درک کنیم، بیایید از یک تشبیه جالب استفاده کنیم: پختن کلوچه.

وقتی می‌خواید کلوچه بپزید، به مواد اولیه مختلفی مثل آرد، شکر، تخم‌مرغ و کره نیاز دارید. یک سیستم SIEM هم دقیقاً همین‌طوره. اجزای مختلفی مثل جمع‌کننده لاگ، تجمیع‌کننده، کارگزار (Broker) و موتور هشدار داره. نکته کلیدی اینجاست: همون‌طور که برای داشتن یک کلوچه خوشمزه باید مقدار هر ماده اولیه دقیق و به اندازه باشه، در یک معماری SIEM هم همه اجزا باید در جای درست و با ظرفیت مناسب خودشون قرار بگیرن تا کل سیستم در تعادل و هماهنگی کار کنه. اگه یکی از این مواد کم یا زیاد بشه، نتیجه نهایی مطلوب نخواهد بود.

پس بیایید با هم وارد آشپزخانه SIEM بشیم و ببینیم هر کدوم از این «مواد اولیه» چه نقشی در پختن این کلوچه امنیتی دارن.

درک معماری یک سیستم SIEM و شناخت اجزای مختلفش، اولین قدم برای طراحی یک سیستم کارآمد و پایداره. وقتی بدونیم هر قطعه از این پازل چه کاری انجام می‌ده، می‌تونیم سیستمی بسازیم که نه تنها تهدیدات رو شناسایی کنه، بلکه در برابر حجم بالای داده‌ها و نوسانات شبکه هم مقاوم باشه. یک معماری SIEM استاندارد از شش جزء اصلی تشکیل شده:

حالا که با اجزای اصلی آشنا شدیم، بیایید بریم سراغ بنیادی‌ترین عنصر این سیستم، یعنی خودِ «لاگ»، و ببینیم واقعاً چه چیزی رو می‌شه یک لاگ نامید.

وقتی کلمه «لاگ» رو می‌شنویم، معمولاً یک خط متنی با فرمت مشخص توی ذهنمون میاد. اما این تصور خیلی محدودکننده‌ است. برای یک تحلیلگر امنیت، هر رکورد سیستماتیک از یک رویداد می‌تونه یک لاگ ارزشمند باشه.

دیکشنری آکسفورد «لاگ» رو این‌جوری تعریف می‌کنه: «یک رکورد منظم یا سیستماتیک از حوادث یا مشاهدات». این تعریف خیلی گسترده است و دست ما رو کاملاً باز می‌ذاره.

بیایید به یک مثال کلاسیک از لاگ auth.log در لینوکس نگاه کنیم: Sep 7 21:34:23 siem su[2735]: pam_unix(su:session): session opened for user jhenderson by jhenderson(uid=1000)

این لاگ سنتی، اجزای کاملاً مشخصی داره:

تا اینجا همه چیز ساده به نظر می‌رسه. اما حالا یک چالش جدید: فرض کنید فایلی به نام running_processes.txt داریم که با یک اسکریپت PowerShell ایجاد شده و حاوی هش MD5 تمام فرآیندهای در حال اجرای یک سیستمه. محتوای اون چیزی شبیه به اینه:

Algorithm,Hash,Path MD5,C5B8D263A1E134E4F076542F2D78C9DC,C:\Program Files\...\AcroRd32.exe MD5,8F311A272AAE611BFFAAC88CC0CA3F43,C:\Program Files\...\chrome.exe

این فایل نه زمان داره و نه نام سیستم. آیا می‌تونیم اون رو یک «لاگ» در نظر بگیریم؟

پاسخ بله است، و نه تنها یک لاگ، بلکه یک لاگ بسیار ارزشمند! ما می‌تونیم موقع جمع‌آوری این فایل، اطلاعات زمینه‌ای مثل زمان جمع‌آوری و نام سیستم رو بهش اضافه کنیم. با ارسال دوره‌ای این فایل به SIEM، می‌تونیم یک خط پایه (Baseline) از فرآیندهای مجاز بسازیم و هرگونه انحراف از اون رو به عنوان یک تهدید بالقوه شناسایی کنیم.

این مثال به ما نشون می‌ده که باید نگاهمون رو به مفهوم لاگ گسترش بدیم. حالا که می‌دونیم چه چیزهایی می‌تونن لاگ باشن، بیایید ببینیم چطور می‌تونیم اون‌ها رو جمع‌آوری کنیم.

جمع‌آوری لاگ در نگاه اول ممکنه ساده به نظر برسه، اما در واقع نیازمند برنامه‌ریزی دقیقیه. چیزی که من بارها در عمل دیدم اینه که انتخاب روش نادرست می‌تونه منجر به از دست رفتن لاگ‌های حیاتی، ایجاد اختلال در شبکه یا مشکلات عملکردی روی سیستم‌های میزبان بشه. به طور کلی، ما با چند روش اصلی روبرو هستیم: استفاده از ایجنت، روش بدون ایجنت (Agentless)، پروتکل Syslog، استفاده از API و در نهایت، اسکریپت‌های سفارشی.

ایجنت‌های مدرن جمع‌آوری لاگ، ابزارهای فوق‌العاده قدرتمندی هستن که قابلیت‌هاشون خیلی فراتر از ارسال ساده لاگه. این ایجنت‌ها بسیاری از وظایفی که قبلاً بر عهده تجمیع‌کننده بود رو به مبدأ، یعنی همون سیستم تولیدکننده لاگ، منتقل می‌کنن. برخی از مهم‌ترین ویژگی‌هاشون این‌ها هستن:

البته باید توجه داشت که فعال‌سازی برخی از این ویژگی‌ها، مثل رمزنگاری، می‌تونه بار پردازشی (CPU) روی سیستم میزبان رو افزایش بده و نیازمند تست و ارزیابی دقیق در محیط شماست.

پروتکل Syslog احتمالاً رایج‌ترین پروتکل برای انتقال لاگ در شبکه است. این پروتکل از دهه ۱۹۸۰ وجود داشته و استانداردهای رسمی اون در RFC 5424 و RFC 3164 تعریف شدن. تقریباً تمام تجهیزات شبکه‌ای مثل روترها، سوئیچ‌ها، فایروال‌ها و همچنین سیستم‌عامل‌های مبتنی بر یونیکس (لینوکس و مک) به صورت بومی از Syslog پشتیبانی می‌کنن.

پس Syslog همه جا هست. یک استاندارد جهانیه. این یعنی بی‌نقصه، درسته؟ خب… نه دقیقاً.

ساختار یک پیام Syslog شامل چند فیلد اصلیه. برای اینکه ساده‌تر درکش کنیم، این‌طوری بهش نگاه کنید: به Facility فکر کنید که داره به ما می‌گه کدوم دپارتمان توی سیستم‌عامل داره حرف می‌زنه—آیا کرنله، سیستم ایمیله، یا بخش امنیتی کاربر؟ و Severity هم اینه که اون دپارتمان چقدر داره بلند فریاد می‌زنه—آیا فقط یک زمزمه در حد «دیباگ» هست یا یک فریاد تمام‌عیار «اضطراری»؟

با وجود گستردگی استفاده، Syslog با دو چالش بزرگ روبروست:

برخلاف Syslog که مبتنی بر متنه، لاگ‌های ویندوز در یک فرمت باینری اختصاصی ذخیره می‌شن که زیربنای اون XML هست. فرمت جدید که با پسوند EVTX شناخته می‌شه، می‌تونه تا ۳۲ کیلوبایت داده رو در خودش جا بده.

این ساختاریافتگی XML یک مزیت فوق‌العاده‌ است. چون هر قطعه از اطلاعات در یک فیلد مشخص و با نام مشخص قرار گرفته، استخراج خودکار فیلدها خیلی ساده می‌شه. برای مثال، یک لاگ Process Create (ایجاد فرآیند) که در نگاه اول یک متن طولانی به نظر می‌رسه، در واقع یک ساختار XML با ده‌ها فیلد مشخص مثل ProcessId، Image، CommandLine و ParentProcessId هست.

و اینجا تفاوت مشخص می‌شه: یک ایجنت مدرن؟ می‌تونه هزاران فیلد مختلف رو استخراج کنه. یک ایجنت سنتی؟ شانس بیارید اگه صد تا فیلد بهتون بده. تفاوت در سطح دیدی که به دست میارید، عظیمه.

اما چالش اصلی اینجاست. یادتونه گفتیم پیام‌های Syslog اغلب به یک کیلوبایت محدود هستن؟ و یک لاگ پرجزئیات ویندوز می‌تونه بیش از ۳۰ کیلوبایت باشه؟ می‌بینید که این دو اساساً با هم نمی‌خونن. مثل اینه که بخواید یک هندوانه رو از شیار صندوق پست رد کنید. دقیقاً به همین دلیله که ارسال رویدادهای خام ویندوز از طریق یک ایجنت ساده مبتنی بر Syslog اغلب منجر به لاگ‌های تکه تکه شده و بی‌فایده می‌شه.

برای حل چالش جمع‌آوری لاگ‌های ویندوز، مایکروسافت یک راه‌حل داخلی و رایگان به نام Windows Event Forwarding یا WEF ارائه می‌ده. WEF در واقع یک ایجنت داخلیه که نیازی به نصب نرم‌افزار جدید نداره و به صورت متمرکز از طریق Group Policy یا GPO مدیریت می‌شه و همراه با آپدیت‌های ویندوز، به‌روزرسانی می‌شه.

ویژگی‌های کلیدی WEF عبارتند از:

این سیستم برای کار کردن به سرویس Windows Remote Management یا WinRM و باز بودن پورت TCP 5985 نیاز داره.

حالا یک سناریوی رایج رو در نظر بگیرید: تیم امنیت شما به لاگ‌های غنی ویندوز نیاز داره، و تیم سرور حاضر نیست یک ایجنت سوم دیگه روی سیستم‌هاش نصب کنه. اینجاست که WEF تبدیل به راه‌حل دیپلماتیک شما می‌شه. چون از اجزای داخلی خود ویندوز استفاده می‌کنه، تیم سرور رو راضی نگه می‌داره و یک نقطه جمع‌آوری مرکزی به نام Windows Event Collector یا WEC در اختیارتون می‌ذاره که می‌تونید با یک ایجنت قدرتمند، تمام لاگ‌ها رو فقط از همون یک نقطه به SIEM اصلی ارسال کنید. این یک مصالحه استراتژیک برای انجام کاره.

انتخاب ایجنت مناسب یکی از مهم‌ترین تصمیمات در طراحی معماری SIEM هست. بیایید سه رویکرد اصلی رو مقایسه کنیم: ایجنت‌های استاندارد SIEM، ایجنت‌های متن‌باز و روش جمع‌آوری بدون ایجنت.

ایجنت‌های استاندارد SIEM: اکثر فروشنده‌های SIEM، ایجنت‌های مخصوص خودشون رو ارائه می‌دن (مثل Universal Forwarder برای Splunk).

اینجاست که با مفهومی به نام “?Where Is the Filter (WTF)” یا «فیلتر کجاست؟» مواجه می‌شیم. فروشنده‌ها به شما می‌گن که فیلترینگ در مبدأ، بار پردازشی زیادی به سیستم تحمیل می‌کنه و به همین دلیل این قابلیت رو در ایجنت‌هاشون قرار نمی‌دن. اما بذارید بهتون بگم واقعیت ماجرا چیه. این مثل اینه که دستور پخت کلوچه به شما بگه تمام مواد اولیه رو—با پوست تخم‌مرغ و کیسه آرد و همه چیز—بریزید توی مخلوط‌کن مرکزی و اونجا جداشون کنید. این کار بی‌نهایت ناکارآمده و کلی کثیف‌کاری به بار میاره. شما می‌خواید مواد اولیه رو در مبدأ فیلتر کنید.

فیلترهای ساده، مثلاً فیلتر کردن لاگ‌ها بر اساس یک Event ID خاص، تأثیر عملکردی ناچیزی دارن، اما در عوض می‌تونن تا ۹۰ درصد از حجم لاگ‌های ارسالی رو کاهش بدن! و این کاهش ۹۰ درصدی فقط یک برد فنی نیست. این مستقیماً به معنی کاهش هزینه‌های لایسنس SIEM، نیاز کمتر به فضای ذخیره‌سازی، و فشار کمتر روی شبکه شماست. فیلتر نکردن در مبدأ، به معنی واقعی کلمه، سوزاندن پوله.

ایجنت‌های متن‌باز: این ایجنت‌ها جایگزین‌های بسیار قدرتمندی هستن. جالبه بدونید که خیلی از اون‌ها از نظر قابلیت‌ها، حتی از نمونه‌های تجاری هم غنی‌ترن و برای سازمان‌هایی که نگران پشتیبانی هستن، نسخه‌های تجاری (Enterprise) با قرارداد پشتیبانی ارائه می‌دن. یک مثال برجسته، ایجنت NXLog هست. این ایجنت در دو نسخه رایگان (Community) و تجاری (Enterprise) عرضه می‌شه، روی پلتفرم‌های مختلفی از جمله ویندوز، لینوکس و اندروید کار می‌کنه و لیست بلندبالایی از ویژگی‌های پیشرفته رو حتی در نسخه رایگان خودش ارائه می‌ده.

جمع‌آوری بدون ایجنت (Agentless Log Collection): در این روش، یک سرور مرکزی از راه دور و از طریق پروتکل‌هایی مثل Windows Management Instrumentation یا WMI (برای ویندوز) یا Secure Shell یا SSH (برای لینوکس) به سیستم‌ها وصل می‌شه و لاگ‌ها رو جمع‌آوری می‌کنه.

ببینید، اگه در مورد سطح دید و پایداری سیستم‌تون جدی هستید، توصیه من اینه که همیشه برای یک رویکرد مبتنی بر ایجنت تلاش کنید. روش بدون ایجنت یک راه‌حل سریعه، اما ایجنت‌ها راه‌حل بلندمدت و حرفه‌ای هستن. اجازه ندید کسی به شما بگه این دو روش معادل هم هستن.

گاهی اوقات، به خصوص برای سیستم‌های ابری یا برنامه‌های ثالث که لاگ‌های خودشون رو از طریق API ارائه می‌دن، اسکریپت‌نویسی تنها راه‌حل ممکنه. می‌شه اسکریپت‌هایی نوشت که به صورت دوره‌ای به این APIها وصل بشن، لاگ‌ها رو دریافت کنن و به SIEM بفرستن.

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

 خب، در این قسمت با هم سفری به دنیای پیچیده اما جذاب معماری SIEM و روش‌های جمع‌آوری لاگ داشتیم. دیدیم که راه‌های مختلفی برای این کار وجود داره:

نکته کلیدی که باید به خاطر بسپاریم اینه که یک استراتژی قدرتمند و مؤثر برای جمع‌آوری لاگ، به ندرت فقط به یک روش متکیه. یک طراحی خوب، ترکیبی هوشمندانه از چندین روش مختلف هست که بر اساس نیازها، محدودیت‌ها و سیاست‌های هر سازمان انتخاب می‌شه.

امیدوارم این بحث برای شما مفید بوده باشه. از اینکه تا پایان این قسمت با ما همراه بودید، سپاسگزارم. تا قسمت بعدی، امن بمونید.