واتس اپ و بله 09902857290

فراخوان همکاری شرکت‌ها در جذب و استخدام دانشجویان آکادمی روزبه

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

با توجه به کیفیت آموزشی دوره‌ها، رویکرد کاربردی و ارتباط آموزش‌ها با نیازهای واقعی صنعت، انتظار داریم فارغ‌التحصیلان برتر آکادمی روزبه بتوانند به نیروهایی توانمند و مؤثر، به‌ویژه در حوزه‌های SOC، Blue Team و امنیت سایبری تبدیل شوند.

🌸اما هدف این طرح صرفاً تأمین نیروی انسانی شرکت هامون نیست.

✅️ما علاقه‌مندیم سایر شرکت‌های فعال در صنعت امنیت سایبری نیز بتوانند از این ظرفیت استفاده کنند. از این رو، از شرکت‌های همکار، ارائه‌دهندگان خدمات امنیت، مراکز SOC و سازمان‌هایی که نیازمند جذب نیروی متخصص هستند دعوت می‌کنیم نیازهای استخدامی و تخصص‌های موردنظر خود را از هم‌اکنون به آکادمی روزبه اعلام کنند.

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

این همکاری می‌تواند یک مسیر دوطرفه ایجاد کند: دانشجویان با چشم‌انداز روشن‌تری وارد مسیر آموزش و اشتغال شوند و شرکت‌ها نیز به مجموعه‌ای از نیروهای آموزش‌دیده و ارزیابی‌شده دسترسی پیدا کنند.

از شرکت‌های فعال در حوزه SOC و امنیت سایبری دعوت می‌کنیم به این فراخوان بپیوندند و نیازهای استخدامی خود را اعلام کنند.

آموزش باکیفیت، شناسایی استعدادها و اتصال آنها به صنعت؛ مسیری که می‌تواند هم برای دانشجو و هم برای کارفرما ارزش‌آفرین باشد.

واتس اپ و بله 09902857290

چرا Zeek برای مهندسی کشف ضروری است؟

یکی از مهم‌ترین اصول در Detection Engineering این است که پیش از نوشتن هر Rule از خود بپرسیم: Telemetry این رفتار کجاست؟ در بسیاری از حملات، پاسخ این سؤال در Network Telemetry قرار دارد و Zeek یکی از قدرتمندترین ابزارها برای تولید چنین داده‌ای است.

ابزار Zeek را نباید صرفاً یک IDS دانست. وظیفه مهم آن تبدیل ترافیک شبکه به مجموعه‌ای از داده‌های ساخت‌یافته و قابل تحلیل است. لاگ‌هایی مانند "conn.log"، "dns.log"، "http.log"، "ssl.log" و "files.log" به Detection Engineer اجازه می‌دهند رفتار ارتباطات شبکه را بدون وابستگی کامل به Payload مشاهده کند.

برای مثال، در کشف C2 Beaconing می‌توان تناوب ارتباطات، مقصد، مدت Session و حجم داده را بررسی کرد. در DNS Tunneling نیز طول Query، تعداد Subdomainها، Frequency و الگوهای غیرعادی DNS می‌توانند Telemetry لازم برای Detection را فراهم کنند.

تفاوت مهم Zeek با IDSهای Signature-based نیز همین‌جاست: سؤال اصلی فقط این نیست که «آیا ترافیک با یک Signature تطبیق دارد؟» بلکه این است که «در شبکه چه رفتاری اتفاق افتاده است؟»

در دنیای تجاری، Corelight نزدیک‌ترین گزینه به این فلسفه است. محصولاتی مانند ExtraHop و Vectra AI نیز بخشی از این نیاز را در قالب NDR پوشش می‌دهند.

یک Detection خوب از Rule شروع نمی‌شود؛ از شناخت رفتار مهاجم و پیدا کردن Telemetry مناسب آغاز می‌شود.

**دوره مهندسی کشف آکادمی روزبه

چطور در دوره SOC T1 می‌آموزیم؟

مثال : WMI چیست و چه مساله ای ما با او داریم


پروتکل WMI یا Windows Management Instrumentation را می‌توان زبان مشترک مدیریت ویندوز دانست.

پروتکل WMI به برنامه‌ها، مدیران شبکه و اسکریپت‌ها اجازه می‌دهد از ویندوز اطلاعات بگیرند یا برخی کارها را از راه دور و محلی انجام دهند؛ مثلاً:

چه پردازش‌هایی در حال اجرا هستند؟

سیستم چه IP و مقدار RAM دارد؟

چه سرویس‌هایی فعال‌اند؟

آیا می‌توان یک سرویس را متوقف کرد؟

آیا می‌توان برنامه‌ای را روی سیستم دیگری اجرا کرد؟


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

پس WMI ذاتاً بدافزار نیست؛ یک ابزار مدیریتی قدرتمند است که استفاده غیرعادی از آن باید پایش شود.

تشبیه ساده: WMI مثل میز اطلاعات و کنترل ویندوز است؛ سؤال می‌پرسید، اطلاعات می‌گیرید و اگر مجوز داشته باشید، دستور هم اجرا می‌کنید.

مثال تاریخی


حمله Olympic Destroyer در المپیک زمستانی ۲۰۱۸

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

حالا چطور سوء استفاده رو کشف کنیم ؟👇👇

🚀برای کشف سوءاستفاده از WMI، مهم‌ترین نکته دیدن زنجیره رفتار است، نه صرفاً مشاهده wmiprvse.exe؛ چون این پردازش کاملاً قانونی است.


WMI Activity Log
5857–5861

مشاهده عملیات، Providerها و Subscriptionهای WMI


Windows Security
4688
ایجاد پردازش و Command Line


Sysmon
1
مشاهده درخت پردازش


Sysmon
19, 20, 21
کشف ماندگاری از طریق WMI Subscription


Authentication
4624, 4625, 4648, 4672
ورود شبکه‌ای و استفاده از اعتبارنامه


Network
RPC 135، پورت‌های Dynamic RPC و گاهی SMB 445
شناسایی ارتباط WMI از راه دور


PowerShell
4103, 4104
مشاهده اسکریپت یا فرمان PowerShell اجراشده


File/Share
Sysmon 11 و Security 5140/5145
مشاهده انتقال یا ایجاد Payload


👌لاگ اختصاصی WMI باید از مسیر زیر جمع‌آوری شود:
Microsoft-Windows-WMI-Activity/Operational


⛱یعنی WmiPrvSE.exe که معمولاً پردازش‌های مشکوکی ایجاد نمی‌کند، ناگهان والد برنامه‌هایی مانند موارد زیر شود:
cmd.exe
powershell.exe
rundll32.exe
regsvr32.exe
certutil.exe
mshta.exe
wscript.exe
cscript.exe


🎇سناریوی همبستگی پیشنهادی

اگر این رویدادها نزدیک به هم دیده شدند، احتمال حرکت جانبی با WMI افزایش می‌یابد:
اتصال یک سیستم غیرمدیریتی به مقصد روی پورت 135
ثبت 4624 با Logon Type 3 روی مقصد
ایجاد پردازش با والد wmiprvse.exe
اجرای cmd.exe یا powershell.exe
ایجاد فایل، برقراری ارتباط خارجی یا اجرای Payload



🕹کشف ماندگاری WMI

مهاجم می‌تواند WMI را طوری تنظیم کند که مثلاً هنگام روشن‌شدن سیستم یا وقوع یک رویداد، Payload اجرا شود. برای کشف آن، این سه رویداد Sysmon بسیار مهم‌اند:

Event ID 19:
ایجاد WMI Event Filter؛ تعیین می‌کند چه زمانی اجرا شود.
Event ID 20:
ایجاد Event Consumer؛ تعیین می‌کند چه چیزی اجرا شود.
Event ID 21:
اتصال Filter به Consumer


🚦 انجام کارگاه و آزمایش و تحلیل لاگ در اسپلانک

اگر از این نحوه ارائه لذت بردید ، تقریبا با همین منوال و انجام آزمایش ، مطالب به نحو مطلوبی در دوره SOC T1 به شما آموزش داده خواهد شد

پنج شنبه این هفته شروع دوره
آنلاین سراسر ایران
با ۲۰ درصد تخفیف شرکت هامون
و امکان استخدام در هامون و شرکتهای دیگر

⛵️واتس اپ و بله 09902857290

چرا SOC as a Service راهکار مناسبی برای ایران است؟

افزایش حملات سایبری، کمبود نیروی متخصص و هزینه بالای ایجاد مرکز عملیات امنیت اختصاصی، بسیاری از سازمان‌های ایرانی را با یک مسئله جدی روبه‌رو کرده است: چگونه می‌توان امنیت مستمر داشت، بدون آنکه یک SOC کامل و پرهزینه ایجاد کرد؟ پاسخ می‌تواند استفاده از خدمات‌ سرویسی SOC یا SOC as a Service باشد.

راه‌اندازی SOC شبانه‌روزی به تحلیل‌گران لایه یک، متخصصان لایه دو و سه، مهندسان کشف، کارشناسان پاسخ به رخداد، زیرساخت فنی و فرایندهای بالغ نیاز دارد. تأمین و نگهداری این مجموعه برای بسیاری از سازمان‌ها دشوار است. SOC as a Service با اشتراک‌گذاری منابع تخصصی میان چند مشتری، هزینه را کاهش داده و دسترسی به دانش و تجربه متنوع را امکان‌پذیر می‌کند.

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

البته SOC as a Service نباید به فروش SIEM و مشاهده هشدار محدود شود؛ موفقیت آن به مهندسی کشف، پایش منابع داده، مدیریت رخداد، پاسخ‌گویی سریع، گزارش مدیریتی و SLA قابل‌اندازه‌گیری وابسته است.

اگر چه آنچه بسیار مانع پیاده سازی این مدل است ، عدم اعتماد سازمانها و نظر حاکمیت بر مخالفت است ، لیکن نظر بنده بر آن است که در شرایط اقتصادی / خصمانه امروزه ،این مدل از لحاظ امنیت و ROI، بهترین راهکار سازمانی است.

#هامون
#MSSP #SOC_as_a_Service
#مرکز_عملیات_امنیت #soc

Haumoun

تربیت متخصص SOC هامون در دوره SOC T1

وقتی سیستم قربانی به دروازه ورود مهاجم تبدیل می‌شود

در بسیاری از حملات، نفوذ به یک سیستم پایان عملیات نیست؛ بلکه آغاز مرحله حرکت جانبی (Lateral Movement) است. مهاجم پس از تسلط بر یک میزبان، ممکن است روی آن یک SOCKS Proxy راه‌اندازی کند. این سیستم آلوده حالا به واسطه‌ای میان مهاجم و شبکه داخلی تبدیل می‌شود و امکان دسترسی به سرورها و سرویس‌هایی را فراهم می‌کند که مستقیماً از اینترنت قابل مشاهده نیستند.

مهاجم با عبور دادن ابزارهای خود از این پراکسی می‌تواند سرویس‌های داخلی را شناسایی کند، پورت‌ها را اسکن کند، به سامانه‌های مدیریتی متصل شود و حملاتی مانند سرقت اعتبارنامه، سوءاستفاده از آسیب‌پذیری‌ها و دسترسی به فایل‌سرورها را انجام دهد. در این وضعیت، لاگ مقصد معمولاً IP سیستم آلوده را ثبت می‌کند، نه IP واقعی مهاجم؛ بنابراین فعالیت او ممکن است شبیه ارتباط عادی میان دو میزبان داخلی دیده شود.

برای کشف این رفتار، تیم SOC باید به نشانه‌هایی مانند ایجاد پورت شنونده غیرعادی، اجرای ابزارهای tunneling، ارتباطات خروجی طولانی‌مدت، اتصال ناگهانی یک Workstation به چندین سرور داخلی و افزایش اسکن یا خطاهای احراز هویت توجه کند. هم‌بستگی تله‌متری‌های Process، Network، Firewall، EDR و Identity در اینجا حیاتی است.

نکته اصلی این است: وقتی یک سیستم داخلی به SOCKS Proxy تبدیل می‌شود، مهاجم دیگر پشت دیوار شبکه نیست؛ او از داخل شبکه و با هویت یک میزبان قابل‌اعتماد حرکت می‌کند.

#آکادمی_روزبه
مرکز تخصصی آموزش تیم آبی

نشانه‌های یک کرنل آلوده؛ وقتی سیستم‌عامل دیگر شاهد قابل‌اعتمادی نیست

آلودگی Kernel یکی از خطرناک‌ترین وضعیت‌های امنیتی است؛ زیرا بدافزار در سطحی فعالیت می‌کند که وظیفه مدیریت حافظه، پردازش‌ها، فایل‌ها، شبکه و تجهیزات را بر عهده دارد. Kernel Rootkit یا Driver مخرب می‌تواند اطلاعاتی را که سیستم‌عامل به ابزارهای امنیتی نشان می‌دهد، دست‌کاری کند. به همین دلیل، ممکن است آنتی‌ویروس و حتی مدیر سیستم تصور کنند همه‌چیز عادی است.

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

بارگذاری Driver یا Kernel Module ناشناخته، فاقد امضای معتبر یا متعلق به مسیر غیرمعمول نیز اهمیت زیادی دارد. تغییر ناگهانی فهرست Driverها، غیرفعال‌شدن قابلیت‌های امنیتی، توقف EDR، ایجاد خطا در Agentها یا جلوگیری از جمع‌آوری تله‌متری باید بررسی شود.

وCrashهای غیرعادی، Blue Screen، Kernel Panic، افزایش مصرف CPU، نشت حافظه، اختلال در عملکرد شبکه و کاهش شدید کارایی نیز ممکن است ناشی از Driver مخرب یا ناسازگار باشند؛ هرچند این علائم به‌تنهایی آلودگی را اثبات نمی‌کنند.

تغییر در System Call Table، Hookشدن توابع Kernel، دست‌کاری Interruptها، تغییر Bootloader، Secure Boot یا فایل‌های حیاتی سیستم نیز از نشانه‌های فنی جدی‌تر محسوب می‌شوند. در لینوکس باید Moduleهای بارگذاری‌شده، پیام‌های Kernel، Audit Logs و تفاوت میان اطلاعات "/proc" و داده‌های خام بررسی شوند. در ویندوز نیز رویدادهای نصب و بارگذاری Driver، وضعیت Code Integrity و تغییرات سرویس‌های Kernel اهمیت دارند.

در چنین شرایطی نباید فقط به اطلاعات همان سیستم اعتماد کرد. تحلیلگر SOC باید تله‌متری Endpoint را با Firewall، DNS، NetFlow، SIEM و داده‌های شبکه مقایسه کند. تهیه Memory Image، بررسی آفلاین دیسک و مقایسه فایل‌های سیستمی با نسخه سالم می‌تواند شواهد قابل‌اعتمادتری فراهم کند.

نکته کلیدی این است: وقتی Kernel آلوده باشد، سیستم ممکن است درباره وضعیت خودش دروغ بگوید. بنابراین کشف مؤثر به مشاهده از بیرون، هم‌بستگی چند منبع مستقل و تحلیل حافظه نیاز دارد.

چرا سازمان‌ها به Zeek نیاز دارند؟

فایروال، آنتی‌ویروس و EDR هرکدام بخشی از واقعیت امنیتی سازمان را نشان می‌دهند؛ اما برای فهمیدن آنچه واقعاً در شبکه رخ می‌دهد، به دیدی عمیق‌تر نیاز داریم. Zeek یک ابزار تحلیل ترافیک شبکه است که بسته‌ها را صرفاً ذخیره نمی‌کند، بلکه آن‌ها را به رویدادها و لاگ‌های ساختاریافته و قابل‌تحلیل تبدیل می‌سازد.

زیک می‌تواند اطلاعات ارزشمندی درباره ارتباطات، درخواست‌های DNS، نشست‌های HTTP، ویژگی‌های TLS، گواهی‌های دیجیتال، فایل‌های منتقل‌شده و رفتار پروتکل‌هایی مانند SSH ارائه کند. این جزئیات به تحلیل‌گر SOC کمک می‌کند تا ارتباطات مشکوک، الگوهای Beaconing، تونل‌سازی DNS، استفاده غیرعادی از پروتکل‌ها و ارتباط با زیرساخت مهاجمان را سریع‌تر شناسایی کند.

اهمیت Zeek زمانی بیشتر می‌شود که مهاجم بتواند از کنترل‌های نقطه پایانی عبور کند، EDR را غیرفعال سازد یا از تجهیزات مدیریت‌نشده استفاده کند. در چنین شرایطی، ردپای شبکه‌ای مهاجم همچنان ممکن است قابل مشاهده باشد.

البته Zeek جایگزین NetFlow، IDS یا EDR نیست؛ بلکه Context لازم برای تکمیل هشدارهای آن‌ها را فراهم می‌کند. ترکیب داده‌های Zeek با SIEM، اطلاعات تهدید و لاگ‌های هویتی، امکان بازسازی زنجیره حمله و طراحی Detectionهای رفتاری دقیق‌تر را فراهم می‌سازد.

به زبان ساده، Zeek به SOC کمک می‌کند فقط «ارتباط» را نبیند، بلکه «معنای ارتباط» را نیز درک کند.

#واژه_روز

واژه Blast Radius
تلفظ تقریبی: «بِلَست رِیدیِس».

✨️از کجا آمده است؟
این اصطلاح در اصل از حوزه نظامی و مواد منفجره آمده و به معنی شعاع یا محدوده‌ای است که بر اثر انفجار آسیب می‌بیند.

در فناوری اطلاعات و امنیت سایبری، این مفهوم به‌صورت استعاری استفاده می‌شود.

✅️در امنیت سایبری چه معنایی دارد؟
واژه Blast Radius یعنی دامنه خسارتی که پس از نفوذ به یک نقطه می‌تواند گسترش پیدا کند.


🌼برای مثال، مهاجم حساب یک کارمند را تصاحب می‌کند:

اگر حساب فقط به یک سامانه محدود دسترسی داشته باشد، Blast Radius کوچک است.
اگر همان حساب مدیر دامنه باشد و به سرورها، پایگاه‌های داده و نسخه‌های پشتیبان دسترسی داشته باشد، Blast Radius بسیار بزرگ است.

#آکادمی_روزبه #هامون

ابزار Auditd؛ ابزار ممیزی امنیتی در لینوکس

ابزار Auditd سرویس اصلی ممیزی امنیتی در لینوکس است که رویدادها را از Linux Audit Framework در سطح Kernel دریافت و ثبت می‌کند. این ابزار کمک می‌کند مشخص شود چه کاربری، در چه زمانی، با کدام پردازش و شناسه کاربری، چه عملی را روی کدام منبع انجام داده است.

با تعریف قواعد ممیزی می‌توان اجرای برنامه‌ها و فراخوانی‌های سیستمی مانند execve، تغییر فایل‌های حساس، اصلاح مجوزها، دسترسی‌های ناموفق، تغییر حساب‌های کاربری و فعالیت کاربران ممتاز را رصد کرد. رویدادها معمولاً در فایل /var/log/audit/audit.log ذخیره می‌شوند.

ابزار auditctl برای مشاهده و اعمال موقت قواعد به‌کار می‌رود؛ اما قواعد پایدار معمولاً در مسیر /etc/audit/rules.d/ تعریف و هنگام راه‌اندازی بارگذاری می‌شوند. همچنین ausearch برای جست‌وجوی رخدادها و aureport برای تهیه گزارش‌های خلاصه کاربرد دارد.

برای نمونه، نظارت بر /etc/passwd می‌تواند تغییر حساب‌های کاربری را آشکار کند. البته یک رخداد ممکن است در چند رکورد مانند SYSCALL، EXECVE، PATH و CWD ثبت شود که با شناسه مشترک به یکدیگر مرتبط‌اند.

قواعد بیش‌ازحد گسترده، حجم لاگ و سربار سیستم را افزایش می‌دهند؛ بنابراین باید مبتنی بر ریسک طراحی شوند. محافظت از لاگ‌ها، کنترل توقف سرویس، مدیریت فضای ذخیره‌سازی و ارسال رویدادها به SIEM نیز ضروری است. ارزش فارنزیکی Auditd مستقیماً به کیفیت قواعدی وابسته است که پیش از وقوع حادثه فعال شده‌اند.

#Auditd #LinuxAudit #LinuxSecurity #LinuxForensics #DigitalForensics #DFIR #IncidentResponse #SecurityMonitoring #SIEM #SOC #CyberSecurity #ThreatDetection #فارنزیک_دیجیتال #فارنزیک_لینوکس #امنیت_لینوکس #ممیزی_امنیتی #پاسخگویی_به_حادثه #مرکز_عملیات_امنیت #مهندسی_کشف #امنیت_سایبری

چرا ممکن است از Auditd ناامید شویم؟

ابزار Auditd یکی از مهم‌ترین ابزارهای ممیزی امنیتی در لینوکس است؛ اما اگر با انتظار یک EDR کامل یا نسخه لینوکسی Sysmon به سراغ آن برویم، احتمالاً ناامید خواهیم شد.

نخستین محدودیت Auditd این است که فقط رویدادهایی را ثبت می‌کند که از قبل برای آن‌ها Rule مناسبی تعریف شده باشد. اگر پس از وقوع حادثه متوجه شویم اجرای فرمان‌ها، تغییر یک فایل یا فعالیت خاصی زیر نظر نبوده است، Auditd نمی‌تواند گذشته ثبت‌نشده را بازسازی کند.

مشکل دیگر، حجم و پیچیدگی داده‌هاست. فعال‌کردن قواعد گسترده، به‌ویژه برای System Callها، می‌تواند میلیون‌ها رویداد ایجاد کند. از طرف دیگر، یک فعالیت ساده ممکن است در چند رکورد مانند SYSCALL، EXECVE، PATH و CWD پراکنده شود. تبدیل این اطلاعات خام به یک روایت قابل‌فهم، به Parsing، Normalization و Correlation نیاز دارد.

پرشدن Backlog، کمبود فضای دیسک یا تنظیمات نامناسب Log Rotation نیز ممکن است باعث ازدست‌رفتن رویدادها شود. مهاجمی که به سطح Root دست یافته است نیز احتمالاً تلاش می‌کند سرویس را متوقف، Rules را تغییر یا لاگ‌ها را پاک کند.

ابزار Auditd ابزار کشف تهدید آماده‌ای نیست؛ بلکه یک منبع تله‌متری و ممیزی Kernelمحور است. ارزش واقعی آن زمانی آشکار می‌شود که قواعد مبتنی بر ریسک، پایش سلامت، Immutable Rules، ذخیره‌سازی امن و ارسال متمرکز رویدادها به SIEM در کنار آن قرار گیرد. بنابراین ناامیدی از Auditd معمولاً از ضعف ابزار ناشی نمی‌شود؛ بلکه نتیجه انتظار نادرست یا طراحی ناکافی است.

#Auditd #LinuxAudit #LinuxSecurity #LinuxLogging #SecurityMonitoring #ThreatDetection #DetectionEngineering #DigitalForensics #LinuxForensics #IncidentResponse #DFIR #SIEM #SOC #CyberSecurity #امنیت_لینوکس #ممیزی_امنیتی #فارنزیک_لینوکس #مهندسی_کشف #پایش_امنیتی #پاسخگویی_به_حادثه #امنیت_سایبری

آیا مهاجم دارای دسترسی Root می‌تواند Immutable Rules را تغییر دهد؟

یکی از قابلیت‌های مهم Auditd در لینوکس، قفل‌کردن تنظیمات ممیزی با دستور -e 2 است. پس از فعال‌شدن این وضعیت، قوانین Audit موجود در Kernel به حالت Immutable درمی‌آیند؛ یعنی تا زمان راه‌اندازی مجدد سیستم، حتی کاربر root نیز نمی‌تواند از طریق روش‌های معمول Rule جدیدی اضافه کند، قوانین موجود را حذف کند یا Audit را غیرفعال سازد.

در این وضعیت، فرمان‌هایی مانند auditctl -D یا auditctl -e 0 توسط Kernel رد می‌شوند. این قابلیت مانع مهمی در برابر مهاجمی است که پس از دسترسی ممتاز، قصد دارد ثبت فعالیت‌های خود را متوقف کند. بااین‌حال، Immutable Rules به معنی مصونیت کامل Auditd در برابر مهاجم Root نیست.

مهاجم همچنان ممکن است فایل‌های موجود در /etc/audit/rules.d/ را تغییر دهد تا پس از Reboot، قوانین ضعیف‌تر یا ناقصی بارگذاری شوند. او همچنین می‌تواند تنظیمات Boot را هدف قرار دهد، فضای دیسک را پر کند، به Audit Backlog فشار وارد سازد یا فایل‌های لاگ محلی را حذف کند. در صورت تسلط بر Kernel یا Boot Chain نیز امکان دورزدن کنترل‌های ممیزی افزایش می‌یابد.

بنابراین Immutable Rules صرفاً پیکربندی فعال Audit در Kernel را طی Boot جاری قفل می‌کنند؛ نه اینکه تمام اجزای ثبت و نگهداری شواهد را غیرقابل‌دست‌کاری سازند.

برای ایجاد دفاع مؤثر، باید این قابلیت با ارسال فوری لاگ‌ها به SIEM یا سامانه راه دور، Secure Boot، حفاظت از Bootloader، کنترل دسترسی Root، پایش تغییر فایل‌های Audit و هشدار درباره Reboot، توقف سرویس، پرشدن Backlog و Lost Events ترکیب شود. Immutable Rules یک لایه دفاعی ارزشمند است، نه راهکاری مستقل و شکست‌ناپذیر.

**فشار به Audit Backlog یعنی رویدادهای ممیزی با سرعتی بیشتر از توان پردازش Auditd تولید شوند و صف موقت آن در Kernel پر شود.

#Auditd #ImmutableRules #LinuxAudit #LinuxSecurity #LinuxForensics #DigitalForensics #DFIR #IncidentResponse #SecurityMonitoring #DetectionEngineering #SIEM #SOC #CyberSecurity #امنیت_لینوکس #ممیزی_امنیتی #فارنزیک_لینوکس #مهندسی_کشف #پاسخگویی_به_حادثه #امنیت_سایبری

راهکار DNS Sinkholing چگونه سیستم آلوده را شناسایی می‌کند؟

قابلیت DNS Sinkholing در فایروال‌های Palo Alto برای شناسایی میزبان‌هایی به‌کار می‌رود که قصد ارتباط با دامنه‌های مخرب یا سرورهای فرماندهی و کنترل را دارند. در شبکه‌هایی که کلاینت‌ها از DNS Server داخلی استفاده می‌کنند، فایروال ممکن است فقط آدرس سرور DNS را در لاگ مشاهده کند و نتواند درخواست را به سیستم آلوده نسبت دهد.

با فعال‌شدن DNS Sinkholing، فایروال درخواست مربوط به دامنه مخرب را تشخیص می‌دهد و به‌جای آدرس واقعی آن، یک IP کنترل‌شده به نام Sinkhole IP به کلاینت بازمی‌گرداند. بدافزار سپس تلاش می‌کند به این IP متصل شود. این اتصال در Traffic Log با آدرس واقعی کلاینت ثبت می‌شود و تیم SOC می‌تواند میزبان آلوده را شناسایی کند.

راهکار DNS Sinkholing بدافزار را حذف نمی‌کند؛ اما ارتباط آن با مقصد واقعی را مختل کرده و یک سرنخ ارزشمند برای تحلیل، هم‌بستگی رویدادها، قرنطینه میزبان و Incident Response فراهم می‌سازد.

از دیگر مزایای این راهکار چه میدانید ؟


منبع : درس سنز ۵۳۰
تدریس این درس فقط بصورت سازمانی امکان پذیر است.
#آکادمی_روزبه #شرکت_هامون

جدید ترین نوشته استاد روزبه در سایت ویرگول


نقش SBOM و استانداردهای CycloneDX و SPDX در امنیت زنجیره تأمین نرم‌افزار

نرم‌افزارهای امروزی از کتابخانه‌های متن‌باز، بسته‌های تجاری، کانتینرها و سرویس‌های متعددی تشکیل می‌شوند؛ بنابراین شناسایی اجزای آن‌ها برای مدیریت امنیت زنجیره تأمین ضروری است. SBOM یا «صورت‌مواد نرم‌افزار» سندی ساخت‌یافته و ماشین‌خوان است که نام، نسخه، تأمین‌کننده، مجوز، هش و وابستگی‌های مستقیم و انتقالی مؤلفه‌های یک محصول را ثبت می‌کند. با انتشار یک آسیب‌پذیری جدید، سازمان می‌تواند با جست‌وجوی SBOM، محصولات تحت‌تأثیر را سریع‌تر شناسایی و اولویت‌بندی کند. CycloneDX و SPDX دو استاندارد مهم این حوزه‌اند. CycloneDX با ریشه OWASP، بر امنیت، DevSecOps، مدیریت وابستگی‌ها و VEX تمرکز بیشتری دارد؛ درحالی‌که SPDX با حمایت Linux Foundation، در مدیریت مجوزها، مالکیت فکری و انطباق حقوقی سابقه‌ای قوی دارد. بااین‌حال، هر دو استاندارد اکنون کاربردهای گسترده‌ای در زنجیره تأمین دارند. SBOM جایگزین اسکن آسیب‌پذیری نیست، بلکه موجودی لازم برای تحلیل را فراهم می‌کند. ارزش واقعی آن زمانی ایجاد می‌شود که به‌صورت خودکار در CI/CD تولید، امضا، به‌روزرسانی و با SOC، مدیریت آسیب‌پذیری، CMDB و فرایند ارزیابی تأمین‌کنندگان یکپارچه شود.

✨️مقاله کامل را در لینک زیر در ویرگول بخوانید.

https://vrgl.ir/b9tPn

✅️ دوره 82 ام از CISSP در دیماه
واتس اپ 09902857290


#SBOM
#SoftwareBillOfMaterials
#CycloneDX
#SPDX
#SoftwareSupplyChain
#SupplyChainSecurity
#امنیت_زنجیره_تأمین
#امنیت_نرم‌افزار
#DevSecOps
#SOC
#مدیریت_آسیب‌پذیری
#VulnerabilityManagement
#VEX
#OpenSourceSecurity
#CISSP
#امنیت_سایبری
#آکادمی_روزبه

https://virgool.io/@roozbehnoroozi/sbom-%D9%88-%D8%A7%D8%B3%D8%AA%D8%A7%D9%86%D8%AF%D8%A7%D8%B1%D8%AF%D9%87%D8%A7%DB%8C-cyclonedx-%D9%88-spdx-%D8%B4%D9%86%D8%A7%D8%B3%D9%86%D8%A7%D9%85%D9%87-%D8%A7%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%A7%D9%85%D9%86%DB%8C%D8%AA-%D8%B2%D9%86%D8%AC%DB%8C%D8%B1%D9%87-%D8%AA%D8%A3%D9%85%DB%8C%D9%86-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-twqqlyh3idyn

آشنایی با واژه

کلمه Dedication را می‌توان «تعهد عمیق و پایدار به یک هدف» ترجمه کرد؛ یعنی انسان حتی وقتی هیجان اولیه از بین رفته، نتیجه هنوز دیده نمی‌شود یا مسیر دشوار شده است، همچنان به انجام کارهای ضروری ادامه دهد.

فرد متعهد نمی‌گوید: «اگر انگیزه داشتم، کار می‌کنم.»
می‌گوید: «چون این هدف برایم مهم است، امروز سهم خودم را انجام می‌دهم.»

کلمه Dedication با علاقه متفاوت است. علاقه شروع‌کننده است، اما تعهد ادامه‌دهنده. بسیاری از افراد به موفقیت علاقه دارند، ولی حاضر نیستند بهای آن را با تمرین منظم، اصلاح اشتباهات، تحمل شکست و صبر طولانی بپردازند.

نمونه‌هایی از تاریخ

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

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

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

نلسون ماندلا ۲۷ سال زندان را تحمل کرد، اما هدف خود برای پایان‌دادن به آپارتاید را رها نکرد. آنچه او را ماندگار کرد، فقط مقاومت نبود؛ توانایی حفظ هدف، کنترل خشم و تبدیل رنج شخصی به یک حرکت سیاسی سازنده بود.

برای استخدام و حقوق مکفی ، باید تعهد به هدف داشته باشید

1⃣سلسله مقالات کوبرنتیز تا CiliumHound

مقاله اول: Kubernetes چیست و چرا به آن نیاز داریم؟

برای شناخت CiliumHound ابتدا باید Kubernetes را بشناسیم. امروزه بسیاری از نرم‌افزارها به‌جای یک برنامه بزرگ، از اجزای کوچک‌تری به نام Microservice ساخته می‌شوند. برای مثال، یک فروشگاه اینترنتی ممکن است سرویس‌هایی جداگانه برای ورود کاربران، محصولات، پرداخت و ارسال سفارش داشته باشد.

هر سرویس معمولاً داخل یک Container اجرا می‌شود. اما وقتی تعداد Containerها به صدها یا هزاران مورد برسد، مدیریت آن‌ها دشوار خواهد شد. Kubernetes سامانه‌ای است که استقرار، اجرا، مقیاس‌دهی و بازیابی خودکار این Containerها را مدیریت می‌کند.

کوچک‌ترین واحد اجرایی در Kubernetes معمولاً Pod نام دارد. یک یا چند Pod می‌توانند یک برنامه را ارائه کنند. Podها روی ماشین‌هایی به نام Node اجرا می‌شوند و مجموعه Nodeها یک Cluster را تشکیل می‌دهد. Service نیز یک آدرس نسبتاً ثابت برای دسترسی به گروهی از Podها فراهم می‌کند.

این Kubernetes می‌تواند در صورت ازکارافتادن یک Pod، نمونه دیگری ایجاد کند یا هنگام افزایش درخواست‌ها تعداد Podها را بالا ببرد. این قابلیت‌ها دسترس‌پذیری و مقیاس‌پذیری را افزایش می‌دهند.

بااین‌حال، Kubernetes فقط یک بستر اجرایی نیست؛ بلکه محیطی پویا با ارتباطات فراوان است. Podها دائماً ایجاد، حذف و جابه‌جا می‌شوند. بنابراین کنترل اینکه هر Pod با چه بخش‌هایی ارتباط دارد، به یکی از مهم‌ترین مسائل امنیتی Kubernetes تبدیل می‌شود.


ادامه دارد ....👇👇

2⃣مقاله دوم: ارتباط Podها و خطر حرکت جانبی در Kubernetes

در Kubernetes، اجزای مختلف یک برنامه باید با یکدیگر ارتباط داشته باشند. برای مثال، Web Pod درخواست کاربر را دریافت می‌کند، آن را به API Pod می‌فرستد و API نیز برای بازیابی اطلاعات به Database Pod متصل می‌شود.

این ارتباطات برای عملکرد برنامه ضروری‌اند؛ اما اگر کنترل نشوند، مسیر حمله ایجاد می‌کنند. فرض کنید Web Pod دارای آسیب‌پذیری باشد و مهاجم کنترل آن را به دست آورد. اگر محدودیت شبکه‌ای مناسبی وجود نداشته باشد، مهاجم می‌تواند از همان Pod به پایگاه‌داده، پنل مدیریتی یا دیگر سرویس‌های داخلی متصل شود. این جابه‌جایی از نقطه اولیه نفوذ به بخش‌های دیگر، Lateral Movement نام دارد.

برای جلوگیری از این وضعیت، Kubernetes مفهومی به نام Network Policy دارد. این سیاست مشخص می‌کند کدام Pod اجازه دارد با چه مقصدی و روی چه Port یا Protocol ارتباط برقرار کند.

مثلاً می‌توان تعیین کرد Web Pod فقط به API و API فقط به Database دسترسی داشته باشد. همچنین می‌توان ارتباط مستقیم Web با Database را مسدود کرد.

مسئله این است که در یک Cluster واقعی صدها Pod، ده‌ها Namespace و تعداد زیادی Policy وجود دارد. در چنین محیطی، حتی اگر همه‌چیز روی کاغذ امن به نظر برسد، ترکیب چند مجوز کوچک ممکن است یک مسیر خطرناک بسازد. بنابراین صرفاً داشتن Network Policy کافی نیست؛ باید اثر نهایی همه سیاست‌ها را نیز مشاهده و ارزیابی کنیم.


ادامه دارد ....👇👇