Soc Root

🔴 تو چالش اخر بعضی وقت‌ها همه‌چی درسته:

✅ Sysmon نصبه
✅ Splunk Forwarder نصبه
✅ تنظیمات هم به‌درستی انجام شده

اما هیچ لاگی به SIEM ارسال نمی‌شه — حتی لاگ‌های Sysmon!

در این شرایط معمولاً مشکل از دسترسی نداشتن Splunk Forwarder به کانال لاگ‌ها هست.

برای رفعش، کافیه روی همون سروری که Splunk Forwarder نصب شده (در مسیر زیر) دستورات زیر رو در CMD با دسترسی Administrator اجرا کنید:

📂 مسیر:

C:\Program Files\SplunkUniversalForwarder\bin>

🧰 دستورات رفع مشکل:

wevtutil sl Microsoft-Windows-Sysmon/Operational /ca:"O:BAG:SYD:(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x1;;;BO)(A;;0x1;;;SO)(A;;0x7;;;S-1-5-80-0)"

sc config splunkforwarder obj= "NT SERVICE\SplunkForwarder" type= own

net stop splunkforwarder

net start splunkforwarder

🟢 توضیح کوتاه دستورات:

wevtutil sl → سطح دسترسی کانال لاگ Sysmon رو تنظیم می‌کنه تا سرویس Splunk Forwarder بتونه اون لاگ‌ها رو بخونه.

sc config → مشخص می‌کنه سرویس Splunk Forwarder با دسترسی سرویس خودش اجرا بشه.

net stop/start → سرویس رو ریستارت می‌کنه تا تنظیمات جدید اعمال بشن.

و تمام ✅
بعد از اجرای این دستورات، لاگ‌های Sysmon باید بدون مشکل به Splunk ارسال بشن.


@Socroot

قطعا با کد زدن اسمبلی میتونید از ماتریکس خارج بشید .

🔴 بریم سراغ چالش ۲

وقتی دارایی‌های زیادی در شبکه دارید — مثل کلاینت‌ها، سرورها، سوییچ‌ها و غیره — طبیعیه که حجم زیادی لاگ تولید می‌شه.
فرض کنید SIEM ما Splunk باشه.

قالب پیاده‌سازی Splunk معمولاً اینطوریه:

▫️چندین Indexer داریم که لاگ‌ها رو ذخیره می‌کنن.

▫️یک Search Head روی Indexerها جستجو انجام می‌ده و خروجی نهایی رو نمایش می‌ده.

⚠️ حجم زیاد لاگ می‌تونه باعث سنگین شدن سرور Indexer و کند شدن جستجوها بشه.
راه معمول حل این مشکل: به جای ۱ یا ۲ Indexer، چند Indexer تعریف کنیم (مثلاً ۵ تا) تا ترافیک لاگ‌ها بین Indexerها تقسیم بشه و Splunk عملکرد بهتری داشته باشه.

@Socroot

حرفی ؟
انتقادی ؟
پیشنهادی ؟

▫️ در پست قبل گفتیم که یکی از چالش‌های اصلی در ارسال لاگ به SIEM، هماهنگ نبودن زمان بین سرورها و ایندکسرها است.
سناریویی که من باهاش مواجه شدم اینطوری بود 👇

فرض کنید برای Splunk چندین Indexer داریم تا حجم بالای لاگ‌ها رو بینشون تقسیم کنیم.
یک Search Head هم مشخص کردیم تا وقتی جستجو انجام می‌دیم، از بین ایندکسرها داده‌ها رو بخونه و نتیجه نهایی رو نمایش بده.

اما این وسط یه نکته خیلی مهم وجود داره:
اگر زمان بین ایندکسرها که هر کدوم روی یک سرور مجزا هستن هماهنگ (Sync) نباشه، چه اتفاقی می‌افته؟

🔹 ترتیب زمانی لاگ‌ها به‌هم می‌ریزه.
🔹 ممکنه به‌دلیل اختلاف زمان، صف‌های پردازشی و تأخیر در ایندکس‌شدن داده‌ها ایجاد بشه.

✅ راه‌حل:
منطقی‌ترین کار اینه که همه ایندکسرها رو با یک NTP Server هماهنگ کنیم.
برای این کار روی هر سرور (با دسترسی Administrator) دستورهای زیر رو به‌ترتیب اجرا کنید:

w32tm /config /manualpeerlist:"NTP_SERVER_IP" /syncfromflags:manual /reliable:YES /update

net stop w32time

net start w32time

w32tm /resync

بعد از حدود ۵۰ ثانیه، برای اطمینان از همگام‌سازی زمان، وضعیت رو بررسی کنید:

w32tm /query /status

🔴 در خروجی باید IP مربوط به NTP Server رو مشاهده کنید.
با همین تنظیم ساده، از بروز خطاهای مربوط به اختلاف زمان بین ایندکسرها در Splunk جلوگیری می‌کنید.

@Socroot

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

فرض کنیم SIEM ما Splunk هست.
برای اینکه لاگ‌ها از سرورها یا کلاینت‌ها به Splunk برسن، باید روی اون سیستم‌ها Splunk Universal Forwarder نصب بشه تا وظیفه ارسال لاگ‌ها رو انجام بده.

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

1️⃣ هماهنگ نبودن زمان (Time Sync) بین Indexer‌های Splunk
2️⃣ حجم بالای لاگ‌ها که باعث سنگین شدن سرور Splunk میشه
3️⃣ نداشتن دسترسی Splunk Forwarder به مسیر یا کانال لاگ مورد نظر (مثلاً لاگ‌های Event Viewer یا Sysmon)

📌 نکته:
منظورم از “ارسال لاگ” فقط مربوط به Sysmon یا Event Viewer نیست — منظور کل فرایند جمع‌آوری و ارسال لاگ‌هاست.
بعدها خودمون می‌تونیم مشخص کنیم که چه نوع لاگ‌هایی ارسال بشن.

در پست بعدی باهم راه‌حل‌های هرکدوم از این چالش‌ها رو بررسی می‌کنیم. ⚙️


@Socroot

در ادامه SANS 401 یه مبحث خیلی مهم داریم به اسم Network Design که موضوعات زیادی رو پوشش میده.
منم سعی می‌کنم قدم‌به‌قدم براتون توضیحش بدم.

🔸️ اول بریم سراغ فایروال‌هایی که در لبه یا همون Edge Network ما قرار دارن.
یه قانون مهم در طراحی این بخش وجود داره به اسم Redundancy (افزونگی).
یعنی از یه تجهیز، مثل فایروال، دوتا داشته باشیم تا اگه یکی از کار افتاد، اون یکی ادامه بده و سرویس قطع نشه.
پس همیشه بهتره در لبه شبکه از دو فایروال استفاده کنیم تا پایداری شبکه تضمین بشه.

🔹 یه نکته مهم درباره فایروال‌ها اینه که معمولاً روی اون‌ها یا کنار اون‌ها Sensorهایی قرار میدن که ترافیک ورودی از بیرون شبکه رو بررسی می‌کنن تا اگه پکتی مخرب یا مشکوک بود، شناسایی یا مسدودش کنن.

اگر این بررسی فقط در حد هشدار باشه، اسمش میشه IDS (Intrusion Detection System)،
اما اگه به‌صورت فعال (Active) جلوی حمله رو بگیره، بهش می‌گن IPS (Intrusion Prevention System).

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


@Socroot

عینک core


@Socroot

ولی بخواییم تخصصی به ماجرا نگاه کنیم اگه indexer ها تایمشون فرق داشته باشه :

ترتیب لاگ‌ها به هم می‌ریزه و تحلیل دقیق رخدادها سخت می‌شه و همچنین تحلیل حملات و پیدا کردن مسیر نفوذ (Forensics) تقریبا غیرممکن می‌شه .

@Socroot

یه نصیحت بشنویم :

اگر میخوایید سر sync شدن زمان indexer های Splunk با هم گریتون نگیره، حتما یه NTP server بیارید بالا که همه indexer ها تایمشون رو با اون ست کنن 😂

@Socroot

⚙️ قابلیت مفید در فایروال FortiGate — Record in CLI در بخش Automation

در فایروال FortiGate، وقتی می‌خوای یه Automation Script بسازی، یه گزینه به اسم “Record in CLI” وجود داره.
کارش خیلی کاربردیه: هر دستوری که در CLI اجرا می‌کنی ضبط میشه و در نهایت به‌عنوان اسکریپت اجرایی همون Automation ذخیره میشه.

🔹 چرا مفیده؟

سریع و راحت: به‌جای نوشتن دستی اسکریپت، فقط دستوراتت رو اجرا کن تا خودش ضبطشون کنه.

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

کاربردی برای کارهای تکراری: می‌تونی این اسکریپت‌ها رو بعداً با Trigger یا زمان‌بندی خاص اجرا کنی.

@Socroot

امان از روزی که اینو یادت بره 😁💔

wr

@Socroot

کافیه فقط یه پست غیر تخصصی بفرستم تا ری‌اکشن بزنید . حداقل روی پست های تخصصی هم کمی سرمایه گذاری کنید که حس ناکافی بودن بهم دست نده 😂🙌🏻

🔹️ حالا IOC یعنی چی ؟

به عبارت ساده، یه علامت یا شواهده که نشون میده سیستم قبلاً یا هم‌اکنون مورد حمله قرار گرفته.

مثال:

▫️ تغییر کلید رجیستری مشکوک (مثل پورت RDP)
▫️ فایل یا پروسه مخرب
▫️ اتصال به IP یا دامنه مخرب

📌 اطلاعاتی که از IOC به دست میاد کمک می‌کنه تیم امنیت سریع‌تر حمله‌ها رو تشخیص بده و واکنش نشون بده.

@Socroot

بذارم برای کی؟ برا وارث؟

@Socroot

🔹️ حالا اصلا چرا باید لاگ همچین موردی رو بگیریم ؟!
تغییر پورت پیش‌فرض RDP (3389) معمولاً توسط ادمین انجام نمی‌شه بدون دلیل مستند.
اما مهاجم بعد از دسترسی اولیه (مثلاً از طریق RDP Brute Force ) ممکنه پورت رو عوض کنه تا:

۱ - دسترسی خودش رو مخفی کنه
۲ - فایروال‌ها رو دور بزنه
۳ - اتصال RDP خودش رو حفظ کنه حتی اگر پورت 3389 بلاک بشه.

پس تغییر این کلید رجیستری یه Indicator of Compromise (IoC) محسوب میشه.


@Socroot

🔹️ بریم که ادامه مبحث Sysmon رو داشته باشیم .
این‌بار می‌خوایم ببینیم چطور می‌تونیم تغییر پورت RDP روی سرور رو با Sysmon تشخیص بدیم.
برای این کار باید داخل فایل sysmonconfig.xml یک رول اضافه کنیم که تغییرات رجیستری مربوط به پورت RDP رو ثبت کنه. مسیر رجیستری مربوطه معمولاً اینه:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber

📌 دلیل انتخاب این مسیر:

این کلید رجیستری تعیین می‌کنه که RDP روی کدوم پورت کار می‌کنه.
تغییر این کلید یعنی پورت پیش‌فرض RDP (TCP 3389) تغییر کرده.

برای اینکه Sysmon این تغییر رو لاگ کنه، کافیه یه رول توی بخش RegistryEvent کانفیگ اضافه کنیم :

<RegistryEvent onmatch="include">
  <TargetObject condition="contains">\WinStations\RDP-Tcp\PortNumber</TargetObject>
</RegistryEvent>

⚠️ نکته مهم :
باید بعد از اضافه کردن رول، کانفیگ Sysmon رو آپدیت کنیم تا تغییرات اعمال بشه:

sysmon.exe -c sysmonconfig.xml

@Socroot

یه مدتی نبودم پیامی نگرفتم .
فهمیدم چه پیام بزرگی گرفتم 🫥