Soc Root

ولادت با سعادت حضرت فاطمه زهرا(س) روز مادر و زن مبارک باد🌷🌹 @Socroot

احتمالاً شنیدید وقتی یه فایل مشکوک پیدا می‌کنیم، میگیم: "بفرستش Sandbox ببینیم چیکار می‌کنه." اما دقیقاً یعنی چی؟ 🔹 این Sandbox یه محیط ایزوله و کنترل‌شده هستش ، جایی که ما فایل‌های مشکوک (مثل exe، اسکریپت، سند آلوده و …) رو اجرا می‌کنیم بدون اینکه خطری برای سیستم واقعی داشته باشه. 🔹 هدفش چیه؟

دیدن رفتار واقعی فایل. مثلاً: آیا فایل سعی می‌کنه به اینترنت وصل بشه؟ آیا کلید رجیستری می‌سازه؟ پروسس جدید ایجاد می‌کنه؟ فایل مشکوک می‌نویسه؟ رمزگذاری انجام می‌ده؟ به C2 وصل می‌شه؟

⚠️ چرا این مهمه؟ چون خیلی از بدافزارها تو ظاهر سالم هستن؛ ولی وقتی اجرا بشن، دست به خرابکاری می‌زنن. پس Sandbox کمک می‌کنه بدون ریسک، رفتار فایل رو آنالیز کنیم. 🔹 چندتا Sandbox معروف:

Any.Run Hybrid Analysis Joe Sandbox Cuckoo Sandbox (نسخه اوپن‌سورس)

 @Socroot

#خارج_از_امنیت هر خطایی تو ویندوز دیدی 90% مواقع اینجا راه حلش هست . windowsreport.com @Socroot

🔹 مانیتورینگ تو SOC یعنی چی؟ توی SOC، “مانیتورینگ” فقط نگاه کردن به لاگ‌ها نیست؛ یعنی فهمیدنِ رفتار شبکه و اینکه بتونی سریع تشخیص بدی «چی طبیعی هست و چی نیست». من چند جا دیدم که فکر می‌کردن مانیتورینگ یعنی فقط SIEM باز باشه و هشدارها رو نگاه کنن… اما واقعاً اینطوری نیست. 🔸 مانیتورینگ واقعی یعنی:

✔️ جمع‌آوری لاگ‌ها از تمام دارایی‌ها (سرور، کلاینت، فایروال، AD، EDR و…) ✔️ تحلیل Real-Time اتفاقاتی که داره می‌افته ✔️ تشخیص رفتار غیرعادی قبل از اینکه تبدیل به Incident بشه ✔️ بفهمی Attack Chain داره شکل می‌گیره یا نه ✔️ ارتباط بین لاگ‌ها ✔️ نوشتن Rule و Use Case ✔️ بررسی هشدارهای EDR/XDR ✔️ تحلیل ترافیک شبکه (NTA/NDR)

🔹 ابزارهایی که معمولاً برای مانیتورینگ استفاده میشه:

SIEM (Splunk, QRadar, Elastic, Wazuh) EDR (Defender, SentinelOne, CrowdStrike) XDR/NDR (Microsoft XDR, Palo Alto Cortex, Darktrace) Traffic Analyzer (Wireshark، NetFlow) Dashboardها و Alertهای سفارشی

 🔻 چرا مانیتورینگ مهمه؟ چون ۹۰٪ حملات، قبل از اینکه خرابکاری اصلی انجام بشه ردپا دارن. همین ردپاها تو لاگ‌ها و رفتار کاربر/شبکه دیده میشه. توی SOC دقیقاً باید همین‌ها رو شکار کرد. 📌 نتیجه: مانیتورینگ یعنی دید داشتن و درک کردن اتفاقات. اگر مانیتورینگ درست نباشه، SIEM و EDR وجود خارجی ندارن… فقط ظاهر دارن. @Socroot

میگن امروز ، روز دانشجو هستش روزتون مبارک ❤️

‌🔹این SIEM چیه و چرا انقدر مهمه؟ ‌اگه بخوام خیلی ساده بگم، ‌SIEM مغز SOC هست. ‌تمام لاگ‌ها از کلاینت‌ها، سرورها، فایروال‌ها، AD، امنیتی‌ها و… جمع میشه، آنالیز میشه، و هر رفتار مشکوکی سریع به تیم امنیت هشدار داده میشه. ‌🔸 چندتا از معروف‌ترین SIEM ها:

‌1️⃣ Splunk Enterprise Security ‌شاهکار سرعت و دقت. خیلی‌ها توی سازمان‌های بزرگ ازش استفاده می‌کنن. ‌2️⃣ Microsoft Sentinel ‌نسخه ابری مایکروسافت؛ مخصوص کسایی که زیرساختشون بیشتر روی Azure هست. ‌3️⃣ IBM QRadar ‌پایدار و قدیمی. برای محیط‌های بسیار بزرگ عالیه. ‌4️⃣ Elastic SIEM (ELK) ‌اوپن‌سورس، منعطف و مناسب تیم‌هایی که کد‌محور کار می‌کنن. ‌5️⃣ ArcSight ‌یكی از قدیمی‌ترین‌ها؛ هنوز هم تو خیلی سازمان‌ها فعاله

‌🔸 حالا SIEM به درد چی می‌خوره؟

▫️‌جمع‌آوری لاگ ▫️‌تشخیص تهدید ▫️‌ساختن داشبوردهای امنیتی ▫️‌هوشمندسازی آلارم‌ها ▫️‌کمک به Incident Response

 ‌در کل… ‌اگر می‌خواید دید کامل به شبکه داشته باشید، بدون SIEM اصلاً ممکن نیست. @Socroot

🔴 یه جایی من دیدم سامانه DLP رو خیلی تمیز پیاده‌سازی کرده بودن. قشنگ هر چیزی که از سازمان می‌خواست خارج بشه — چه فایل، چه ایمیل، چه حتی کپی–پیست ساده — همه رو کنترل می‌کرد. مثلاً اگه کاربر می‌خواست یه فایل حاوی اطلاعات حساس رو ببره روی فلش، یا توی ایمیل ضمیمه کنه… همون لحظه سیستم چک می‌کرد و یا اجازه نمی‌داد یا برای تیم امنیت آلارم می‌فرستاد. بدون اینکه کاربر حتی حس کنه پشت‌صحنه چه اتفاقی داره می‌افته. 🛡️ سامانه DLP چیه و چیکار می‌کنه؟

سامانه DLP یا Data Loss Prevention کاری می‌کنه که اطلاعات حساس سازمان بدون اجازه از محیط خارج نشه. سیستم معمولاً این چند تا چیز رو پایش می‌کنه: محتوای فایل‌ها (Content Inspection) رفتار کاربر در لحظه (User Action Monitoring) مقصد داده (ایمیل، وب، فلش، پرینت و...) الگوریتم‌های تشخیص حساسیت (Regex، Fingerprint، Dictionary و...) ⚙️ چرا مهمه؟ چون بخش زیادی از نشت اطلاعات، از داخل سازمان و توسط کاربرا اتفاق می‌افته — معمولاً هم غیرعمدی!

🔹️ حالا DLP چه کمکی می‌کنه :

🔸️ جلوی خروج ناخواسته یا عمدی دیتا گرفته بشه 🔸️ لاگ کامل از رفتار کاربران داشته باشید 🔸️ سیاست‌های امنیتی بر اساس نوع اطلاعات enforce بشن 🔸️ در صورت تخلف، سریع تیم امنیت آگاه بشه

@Socroot

دوستان عزیز اگه پروژه هارو در این حد هم امنیتش رعایت بشه دیگه از نفوذ جلوگیری میشه 😁😁 @Socroot

🔍 اگر با تجهیزات Fortinet کار می‌کنید، این سایت رو حتماً بشناسید سایتی که می‌خوام معرفی کنم FortiGuard PSIRT هست؛ جایی که خود Fortinet تمام آسیب‌پذیری‌های محصولاتش رو به‌صورت رسمی اعلام می‌کنه. 🔴 اینجا می‌تونید ببینید:

چه محصولی آسیب‌پذیر شده سطح ریسک چقدره (Critical / High / …) چه نسخه‌هایی مشکل دارن کدوم نسخه‌ها Patch شدن

⚠️ نکته مهم: حتماً این صفحه رو هر چند وقت یک‌بار چک کنید. اگر دیدید فایروال یا هر تجهیز Fortinet شما داخل لیست آسیب‌پذیرهاست، حتماً نسخه دستگاه رو آپدیت کنید تا ریسک حمله رو بیارید پایین.

🔗 لینک سایت : fortiguard.fortinet.com/psirt

@Socroot

🔴 اگه یه فایل، لینک یا حتی یه دامنه داری و شک داری که ممکنه ویروس یا بدافزار باشه، VirusTotal همون سایتیه که باید بری سراغش. 🔹️ کاری که انجام میده خیلی ساده‌ست:

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

چرا مهمه؟ چون همیشه نمی‌تونیم به یه آنتی‌ویروس اکتفا کنیم. VirusTotal یه جور چک دوباره‌ست که با چندین موتور امنیتی انجام میشه.

ایده‌آل برای: برنامه‌نویس‌ها کاربرای عادی که می‌خوان مطمئن شن لینک مشکوک نیست ادمین‌های شبکه

⚠️ در یک جمله: قبل از باز کردن هر فایل ناشناس، یه سر به VirusTotal بزن. ضرر نداره! 🔗 Virus Total 👈🏻 @Socroot

🔹️ اگر از FortiWeb استفاده می‌کنید، حتماً هر ۲ هفته یک‌بار آپدیتش کنید. منظورم فقط آپدیت نرم‌افزاری نیست؛ Signature‌های FortiWeb باید مرتب به‌روز بشن تا بتونه حملات جدید رو تشخیص بده. و Signature های قدیمی یعنی احتمال عبور حملات جدید، مخصوصاً حملات وب مثل: SQLi، XSS، LFI/RFI، Bot Attack و…

🔴 پس یک Reminder برای خودتون بذارید: هر ۱۴ روز → آپدیت Signatureهای FortiWeb

 امنیت وابسته به همین ریزکاری‌هاست 🔐 @Socroot

با توجه به نتیجه‌ی این نظرسنجی می‌خوام یک‌بار دیگه هدف کانال رو براتون توضیح بدم.

🔴 کانال Soc Root یک کانال تخصصی در حوزه‌ی SOC (مرکز عملیات امنیت) هست. اینجا جاییه که من تجربیات، نکات عملی و دانش فنی خودم در زمینه‌ی SOC رو با شما به اشتراک می‌ذارم؛ از مشکلات واقعی محیط‌های سازمانی گرفته تا سناریوهای کاربردی و نکات ریز اما مهم. ▫️ البته بین این مطالب تخصصی، اگر موضوعی پایه‌ای وجود داره که نیاز دارید بهتر درک کنید، حتما بهم بگید. در حد توانم آموزش همون مبحث رو به‌صورت ساده و کاربردی داخل کانال قرار می‌دم تا مسیر یادگیریتون کامل‌تر بشه.

اگر پیشنهادی دارید از طریق پیام های مستقیم بهم بگید 🫡 @Socroot

⚠️ نکته مهم درباره نصب و کانفیگ Sysmon روی ویندوز سرورها اگر می‌خواید Sysmon رو روی سرورهای ویندوز نصب و کانفیگ کنید، حواستون باشه: ویندوز سرور 2016 و بالاتر → نسخه و قالب فایل کانفیگ یکسانه. ویندوز سرور 2012 و پایین‌تر → نسخه و نحوه نوشتن فایل کانفیگ متفاوته. پس قبل از نصب، حتماً نسخه سیستم‌عامل سرور رو بررسی کنید تا فایل کانفیگ مناسب رو استفاده کنید. @Socroot

🔴 تو چالش اخر بعضی وقت‌ها همه‌چی درسته: ✅ 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