وقتی سیستم قربانی به دروازه ورود مهاجم تبدیل میشود
در بسیاری از حملات، نفوذ به یک سیستم پایان عملیات نیست؛ بلکه آغاز مرحله حرکت جانبی (Lateral Movement) است. مهاجم پس از تسلط بر یک میزبان، ممکن است روی آن یک SOCKS Proxy راه‌اندازی کند. این سیستم آلوده حالا به واسطه‌ای میان مهاجم و شبکه داخلی تبدیل میشود و امکان دسترسی به سرورها و سرویس‌هایی را فراهم می‌کند که مستقیماً از اینترنت قابل مشاهده نیستند.
مهاجم با عبور دادن ابزارهای خود از این پراکسی می‌تواند سرویس‌های داخلی را شناسایی کند، پورت‌ها را اسکن کند، به سامانه‌های مدیریتی متصل شود و حملاتی مانند سرقت اعتبارنامه، سوءاستفاده از آسیب‌پذیری‌ها و دسترسی به فایل‌سرورها را انجام دهد. در این وضعیت، لاگ مقصد معمولاً IP سیستم آلوده را ثبت می‌کند، نه IP واقعی مهاجم؛ بنابراین فعالیت او ممکن است شبیه ارتباط عادی میان دو میزبان داخلی دیده شود.
برای کشف این رفتار، تیم SOC باید به نشانه‌هایی مانند ایجاد پورت شنونده غیرعادی، اجرای ابزارهای tunneling، ارتباطات خروجی طولانی‌مدت، اتصال ناگهانی یک Workstation به چندین سرور داخلی و افزایش اسکن یا خطاهای احراز هویت توجه کند. هم‌بستگی تله‌متری‌های Process، Network، Firewall، EDR و Identity در اینجا حیاتی است.
نکته اصلی این است: وقتی یک سیستم داخلی به SOCKS Proxy تبدیل میشود، مهاجم دیگر پشت دیوار شبکه نیست؛ او از داخل شبکه و با هویت یک میزبان قابل‌اعتماد حرکت می‌کند.
#آکادمی_روزبه
مرکز تخصصی آموزش تیم آبی
در بسیاری از حملات، نفوذ به یک سیستم پایان عملیات نیست؛ بلکه آغاز مرحله حرکت جانبی (Lateral Movement) است. مهاجم پس از تسلط بر یک میزبان، ممکن است روی آن یک SOCKS Proxy راه‌اندازی کند. این سیستم آلوده حالا به واسطه‌ای میان مهاجم و شبکه داخلی تبدیل میشود و امکان دسترسی به سرورها و سرویس‌هایی را فراهم می‌کند که مستقیماً از اینترنت قابل مشاهده نیستند.
مهاجم با عبور دادن ابزارهای خود از این پراکسی می‌تواند سرویس‌های داخلی را شناسایی کند، پورت‌ها را اسکن کند، به سامانه‌های مدیریتی متصل شود و حملاتی مانند سرقت اعتبارنامه، سوءاستفاده از آسیب‌پذیری‌ها و دسترسی به فایل‌سرورها را انجام دهد. در این وضعیت، لاگ مقصد معمولاً IP سیستم آلوده را ثبت می‌کند، نه IP واقعی مهاجم؛ بنابراین فعالیت او ممکن است شبیه ارتباط عادی میان دو میزبان داخلی دیده شود.
برای کشف این رفتار، تیم SOC باید به نشانه‌هایی مانند ایجاد پورت شنونده غیرعادی، اجرای ابزارهای tunneling، ارتباطات خروجی طولانی‌مدت، اتصال ناگهانی یک Workstation به چندین سرور داخلی و افزایش اسکن یا خطاهای احراز هویت توجه کند. هم‌بستگی تله‌متری‌های Process، Network، Firewall، EDR و Identity در اینجا حیاتی است.
نکته اصلی این است: وقتی یک سیستم داخلی به SOCKS Proxy تبدیل میشود، مهاجم دیگر پشت دیوار شبکه نیست؛ او از داخل شبکه و با هویت یک میزبان قابل‌اعتماد حرکت می‌کند.
#آکادمی_روزبه
مرکز تخصصی آموزش تیم آبی
❤3
نشانه‌های یک کرنل آلوده؛ وقتی سیستم‌عامل دیگر شاهد قابل‌اعتمادی نیست
آلودگی 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 آلوده باشد، سیستم ممکن است درباره وضعیت خودش دروغ بگوید. بنابراین کشف مؤثر به مشاهده از بیرون، هم‌بستگی چند منبع مستقل و تحلیل حافظه نیاز دارد.
آلودگی 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 آلوده باشد، سیستم ممکن است درباره وضعیت خودش دروغ بگوید. بنابراین کشف مؤثر به مشاهده از بیرون، هم‌بستگی چند منبع مستقل و تحلیل حافظه نیاز دارد.
❤4
چرا سازمانها به Zeek نیاز دارند؟
فایروال، آنتی‌ویروس و EDR هرکدام بخشی از واقعیت امنیتی سازمان را نشان می‌دهند؛ اما برای فهمیدن آنچه واقعاً در شبکه رخ می‌دهد، به دیدی عمیق‌تر نیاز داریم. Zeek یک ابزار تحلیل ترافیک شبکه است که بسته‌ها را صرفاً ذخیره نمی‌کند، بلکه آن‌ها را به رویدادها و لاگ‌های ساختاریافته و قابل‌تحلیل تبدیل می‌سازد.
زیک می‌تواند اطلاعات ارزشمندی درباره ارتباطات، درخواست‌های DNS، نشست‌های HTTP، ویژگی‌های TLS، گواهی‌های دیجیتال، فایل‌های منتقل‌شده و رفتار پروتکل‌هایی مانند SSH ارائه کند. این جزئیات به تحلیلگر SOC کمک می‌کند تا ارتباطات مشکوک، الگوهای Beaconing، تونل‌سازی DNS، استفاده غیرعادی از پروتکل‌ها و ارتباط با زیرساخت مهاجمان را سریع‌تر شناسایی کند.
اهمیت Zeek زمانی بیشتر میشود که مهاجم بتواند از کنترل‌های نقطه پایانی عبور کند، EDR را غیرفعال سازد یا از تجهیزات مدیریت‌نشده استفاده کند. در چنین شرایطی، ردپای شبکه‌ای مهاجم همچنان ممکن است قابل مشاهده باشد.
البته Zeek جایگزین NetFlow، IDS یا EDR نیست؛ بلکه Context لازم برای تکمیل هشدارهای آن‌ها را فراهم می‌کند. ترکیب داده‌های Zeek با SIEM، اطلاعات تهدید و لاگ‌های هویتی، امکان بازسازی زنجیره حمله و طراحی Detectionهای رفتاری دقیق‌تر را فراهم می‌سازد.
به زبان ساده، Zeek به SOC کمک می‌کند فقط «ارتباط» را نبیند، بلکه «معنای ارتباط» را نیز درک کند.
فایروال، آنتی‌ویروس و EDR هرکدام بخشی از واقعیت امنیتی سازمان را نشان می‌دهند؛ اما برای فهمیدن آنچه واقعاً در شبکه رخ می‌دهد، به دیدی عمیق‌تر نیاز داریم. Zeek یک ابزار تحلیل ترافیک شبکه است که بسته‌ها را صرفاً ذخیره نمی‌کند، بلکه آن‌ها را به رویدادها و لاگ‌های ساختاریافته و قابل‌تحلیل تبدیل می‌سازد.
زیک می‌تواند اطلاعات ارزشمندی درباره ارتباطات، درخواست‌های DNS، نشست‌های HTTP، ویژگی‌های TLS، گواهی‌های دیجیتال، فایل‌های منتقل‌شده و رفتار پروتکل‌هایی مانند SSH ارائه کند. این جزئیات به تحلیلگر SOC کمک می‌کند تا ارتباطات مشکوک، الگوهای Beaconing، تونل‌سازی DNS، استفاده غیرعادی از پروتکل‌ها و ارتباط با زیرساخت مهاجمان را سریع‌تر شناسایی کند.
اهمیت Zeek زمانی بیشتر میشود که مهاجم بتواند از کنترل‌های نقطه پایانی عبور کند، EDR را غیرفعال سازد یا از تجهیزات مدیریت‌نشده استفاده کند. در چنین شرایطی، ردپای شبکه‌ای مهاجم همچنان ممکن است قابل مشاهده باشد.
البته Zeek جایگزین NetFlow، IDS یا EDR نیست؛ بلکه Context لازم برای تکمیل هشدارهای آن‌ها را فراهم می‌کند. ترکیب داده‌های Zeek با SIEM، اطلاعات تهدید و لاگ‌های هویتی، امکان بازسازی زنجیره حمله و طراحی Detectionهای رفتاری دقیق‌تر را فراهم می‌سازد.
به زبان ساده، Zeek به SOC کمک می‌کند فقط «ارتباط» را نبیند، بلکه «معنای ارتباط» را نیز درک کند.
👌4🔥2❤1
#واژه_روز
واژه Blast Radius
تلفظ تقریبی: «بِلَست رِیدیِس».
✨️از کجا آمده است؟
این اصطلاح در اصل از حوزه نظامی و مواد منفجره آمده و به معنی شعاع یا محدوده‌ای است که بر اثر انفجار آسیب می‌بیند.
در فناوری اطلاعات و امنیت سایبری، این مفهوم به‌صورت استعاری استفاده میشود.
✅️در امنیت سایبری چه معنایی دارد؟
واژه Blast Radius یعنی دامنه خسارتی که پس از نفوذ به یک نقطه می‌تواند گسترش پیدا کند.
🌼برای مثال، مهاجم حساب یک کارمند را تصاحب می‌کند:
اگر حساب فقط به یک سامانه محدود دسترسی داشته باشد، Blast Radius کوچک است.
اگر همان حساب مدیر دامنه باشد و به سرورها، پایگاه‌های داده و نسخه‌های پشتیبان دسترسی داشته باشد، Blast Radius بسیار بزرگ است.
#آکادمی_روزبه #هامون
واژه Blast Radius
تلفظ تقریبی: «بِلَست رِیدیِس».
✨️از کجا آمده است؟
این اصطلاح در اصل از حوزه نظامی و مواد منفجره آمده و به معنی شعاع یا محدوده‌ای است که بر اثر انفجار آسیب می‌بیند.
در فناوری اطلاعات و امنیت سایبری، این مفهوم به‌صورت استعاری استفاده میشود.
✅️در امنیت سایبری چه معنایی دارد؟
واژه Blast Radius یعنی دامنه خسارتی که پس از نفوذ به یک نقطه می‌تواند گسترش پیدا کند.
🌼برای مثال، مهاجم حساب یک کارمند را تصاحب می‌کند:
اگر حساب فقط به یک سامانه محدود دسترسی داشته باشد، Blast Radius کوچک است.
اگر همان حساب مدیر دامنه باشد و به سرورها، پایگاه‌های داده و نسخه‌های پشتیبان دسترسی داشته باشد، Blast Radius بسیار بزرگ است.
#آکادمی_روزبه #هامون
🔥4❤1👏1
ابزار 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 سرویس اصلی ممیزی امنیتی در لینوکس است که رویدادها را از 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 #فارنزیک_دیجیتال #فارنزیک_لینوکس #امنیت_لینوکس #ممیزی_امنیتی #پاسخگویی_به_حادثه #مرکز_عملیات_امنیت #مهندسی_کشف #امنیت_سایبری
🔥6❤1👏1
آکادمی آموزش روزبه 📚
ابزار Auditd؛ ابزار ممیزی امنیتی در لینوکس ابزار Auditd سرویس اصلی ممیزی امنیتی در لینوکس است که رویدادها را از Linux Audit Framework در سطح Kernel دریافت و ثبت می‌کند. این ابزار کمک می‌کند مشخص شود چه کاربری، در چه زمانی، با کدام پردازش و شناسه کاربری، چه…
چرا ممکن است از 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 #امنیت_لینوکس #ممیزی_امنیتی #فارنزیک_لینوکس #مهندسی_کشف #پایش_امنیتی #پاسخگویی_به_حادثه #امنیت_سایبری
ابزار 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 #امنیت_لینوکس #ممیزی_امنیتی #فارنزیک_لینوکس #مهندسی_کشف #پایش_امنیتی #پاسخگویی_به_حادثه #امنیت_سایبری
🔥6❤1👏1
آکادمی آموزش روزبه 📚
چرا ممکن است از Auditd ناامید شویم؟ ابزار Auditd یکی از مهم‌ترین ابزارهای ممیزی امنیتی در لینوکس است؛ اما اگر با انتظار یک EDR کامل یا نسخه لینوکسی Sysmon به سراغ آن برویم، احتمالاً ناامید خواهیم شد. نخستین محدودیت Auditd این است که فقط رویدادهایی را ثبت…
آیا مهاجم دارای دسترسی 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 #امنیت_لینوکس #ممیزی_امنیتی #فارنزیک_لینوکس #مهندسی_کشف #پاسخگویی_به_حادثه #امنیت_سایبری
یکی از قابلیت‌های مهم 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 #امنیت_لینوکس #ممیزی_امنیتی #فارنزیک_لینوکس #مهندسی_کشف #پاسخگویی_به_حادثه #امنیت_سایبری
🔥5❤3👏1
راهکار DNS Sinkholing چگونه سیستم آلوده را شناسایی می‌کند؟
قابلیت DNS Sinkholing در فایروال‌های Palo Alto برای شناسایی میزبان‌هایی به‌کار می‌رود که قصد ارتباط با دامنه‌های مخرب یا سرورهای فرماندهی و کنترل را دارند. در شبکه‌هایی که کلاینت‌ها از DNS Server داخلی استفاده می‌کنند، فایروال ممکن است فقط آدرس سرور DNS را در لاگ مشاهده کند و نتواند درخواست را به سیستم آلوده نسبت دهد.
با فعال‌شدن DNS Sinkholing، فایروال درخواست مربوط به دامنه مخرب را تشخیص می‌دهد و به‌جای آدرس واقعی آن، یک IP کنترل‌شده به نام Sinkhole IP به کلاینت بازمی‌گرداند. بدافزار سپس تلاش می‌کند به این IP متصل شود. این اتصال در Traffic Log با آدرس واقعی کلاینت ثبت میشود و تیم SOC می‌تواند میزبان آلوده را شناسایی کند.
راهکار DNS Sinkholing بدافزار را حذف نمی‌کند؛ اما ارتباط آن با مقصد واقعی را مختل کرده و یک سرنخ ارزشمند برای تحلیل، هم‌بستگی رویدادها، قرنطینه میزبان و Incident Response فراهم می‌سازد.
از دیگر مزایای این راهکار چه میدانید ؟
منبع : درس سنز ۵۳۰
تدریس این درس فقط بصورت سازمانی امکان پذیر است.
#آکادمی_روزبه #شرکت_هامون
قابلیت DNS Sinkholing در فایروال‌های Palo Alto برای شناسایی میزبان‌هایی به‌کار می‌رود که قصد ارتباط با دامنه‌های مخرب یا سرورهای فرماندهی و کنترل را دارند. در شبکه‌هایی که کلاینت‌ها از DNS Server داخلی استفاده می‌کنند، فایروال ممکن است فقط آدرس سرور DNS را در لاگ مشاهده کند و نتواند درخواست را به سیستم آلوده نسبت دهد.
با فعال‌شدن DNS Sinkholing، فایروال درخواست مربوط به دامنه مخرب را تشخیص می‌دهد و به‌جای آدرس واقعی آن، یک IP کنترل‌شده به نام Sinkhole IP به کلاینت بازمی‌گرداند. بدافزار سپس تلاش می‌کند به این IP متصل شود. این اتصال در Traffic Log با آدرس واقعی کلاینت ثبت میشود و تیم SOC می‌تواند میزبان آلوده را شناسایی کند.
راهکار DNS Sinkholing بدافزار را حذف نمی‌کند؛ اما ارتباط آن با مقصد واقعی را مختل کرده و یک سرنخ ارزشمند برای تحلیل، هم‌بستگی رویدادها، قرنطینه میزبان و Incident Response فراهم می‌سازد.
از دیگر مزایای این راهکار چه میدانید ؟
منبع : درس سنز ۵۳۰
تدریس این درس فقط بصورت سازمانی امکان پذیر است.
#آکادمی_روزبه #شرکت_هامون
🔥7👏3👍1
جدید ترین نوشته استاد روزبه در سایت ویرگول
نقش 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
نقش 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
ویرگول
SBOM و استانداردهای CycloneDX و SPDX؛ شناسنامه‌ای برای امنیت زنجیره تأمین نرم‌افزار - ویرگول
مقدمهنرم‌افزارهای امروزی معمولاً به‌طور کامل در داخل یک سازمان تولید نمی‌شوند. حتی یک برنامه نسبتاً ساده ممکن است از ده‌ها یا صدها کتابخان…
🏆4🔥2
آشنایی با واژه
کلمه Dedication را می‌توان «تعهد عمیق و پایدار به یک هدف» ترجمه کرد؛ یعنی انسان حتی وقتی هیجان اولیه از بین رفته، نتیجه هنوز دیده نمی‌شود یا مسیر دشوار شده است، همچنان به انجام کارهای ضروری ادامه دهد.
فرد متعهد نمی‌گوید: «اگر انگیزه داشتم، کار می‌کنم.»
می‌گوید: «چون این هدف برایم مهم است، امروز سهم خودم را انجام می‌دهم.»
کلمه Dedication با علاقه متفاوت است. علاقه شروع‌کننده است، اما تعهد ادامه‌دهنده. بسیاری از افراد به موفقیت علاقه دارند، ولی حاضر نیستند بهای آن را با تمرین منظم، اصلاح اشتباهات، تحمل شکست و صبر طولانی بپردازند.
نمونه‌هایی از تاریخ
توماس ادیسون پس از آزمایش‌های ناموفق فراوان برای ساخت لامپ عملی، شکست‌ها را صرفاً تجربه‌هایی می‌دانست که روش‌های نامناسب را آشکار می‌کنند. اهمیت کار او فقط در استعدادش نبود؛ در توانایی ادامه‌دادن، ثبت نتایج و اصلاح مداوم آزمایش‌ها بود.
ماری کوری سال‌ها در شرایط سخت آزمایشگاهی روی مواد پرتوزا کار کرد. او نخستین زنی شد که جایزه نوبل گرفت و تنها فردی است که در دو رشته علمی متفاوت، فیزیک و شیمی، نوبل دریافت کرده است. این موفقیت حاصل کنجکاوی لحظه‌ای نبود؛ نتیجه سال‌ها کار دشوار و پیوسته بود.
لودویگ فان بتهوون با وجود کاهش شدید شنوایی و سپس ناشنوایی، آهنگ‌سازی را کنار نگذاشت. برخی از مهم‌ترین آثار او در دوره‌ای نوشته شدند که تقریباً قادر به شنیدن نبود. تعهد او به هنر، فراتر از محدودیت جسمانی‌اش عمل کرد.
نلسون ماندلا ۲۷ سال زندان را تحمل کرد، اما هدف خود برای پایان‌دادن به آپارتاید را رها نکرد. آنچه او را ماندگار کرد، فقط مقاومت نبود؛ توانایی حفظ هدف، کنترل خشم و تبدیل رنج شخصی به یک حرکت سیاسی سازنده بود.
برای استخدام و حقوق مکفی ، باید تعهد به هدف داشته باشید
کلمه Dedication را می‌توان «تعهد عمیق و پایدار به یک هدف» ترجمه کرد؛ یعنی انسان حتی وقتی هیجان اولیه از بین رفته، نتیجه هنوز دیده نمی‌شود یا مسیر دشوار شده است، همچنان به انجام کارهای ضروری ادامه دهد.
فرد متعهد نمی‌گوید: «اگر انگیزه داشتم، کار می‌کنم.»
می‌گوید: «چون این هدف برایم مهم است، امروز سهم خودم را انجام می‌دهم.»
کلمه Dedication با علاقه متفاوت است. علاقه شروع‌کننده است، اما تعهد ادامه‌دهنده. بسیاری از افراد به موفقیت علاقه دارند، ولی حاضر نیستند بهای آن را با تمرین منظم، اصلاح اشتباهات، تحمل شکست و صبر طولانی بپردازند.
نمونه‌هایی از تاریخ
توماس ادیسون پس از آزمایش‌های ناموفق فراوان برای ساخت لامپ عملی، شکست‌ها را صرفاً تجربه‌هایی می‌دانست که روش‌های نامناسب را آشکار می‌کنند. اهمیت کار او فقط در استعدادش نبود؛ در توانایی ادامه‌دادن، ثبت نتایج و اصلاح مداوم آزمایش‌ها بود.
ماری کوری سال‌ها در شرایط سخت آزمایشگاهی روی مواد پرتوزا کار کرد. او نخستین زنی شد که جایزه نوبل گرفت و تنها فردی است که در دو رشته علمی متفاوت، فیزیک و شیمی، نوبل دریافت کرده است. این موفقیت حاصل کنجکاوی لحظه‌ای نبود؛ نتیجه سال‌ها کار دشوار و پیوسته بود.
لودویگ فان بتهوون با وجود کاهش شدید شنوایی و سپس ناشنوایی، آهنگ‌سازی را کنار نگذاشت. برخی از مهم‌ترین آثار او در دوره‌ای نوشته شدند که تقریباً قادر به شنیدن نبود. تعهد او به هنر، فراتر از محدودیت جسمانی‌اش عمل کرد.
نلسون ماندلا ۲۷ سال زندان را تحمل کرد، اما هدف خود برای پایان‌دادن به آپارتاید را رها نکرد. آنچه او را ماندگار کرد، فقط مقاومت نبود؛ توانایی حفظ هدف، کنترل خشم و تبدیل رنج شخصی به یک حرکت سیاسی سازنده بود.
برای استخدام و حقوق مکفی ، باید تعهد به هدف داشته باشید
❤8🙏4
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 تبدیل میشود.
ادامه دارد ....👇👇
مقاله اول: Kubernetes چیست و چرا به آن نیاز داریم؟
برای شناخت CiliumHound ابتدا باید Kubernetes را بشناسیم. امروزه بسیاری از نرم‌افزارها به‌جای یک برنامه بزرگ، از اجزای کوچک‌تری به نام Microservice ساخته می‌شوند. برای مثال، یک فروشگاه اینترنتی ممکن است سرویس‌هایی جداگانه برای ورود کاربران، محصولات، پرداخت و ارسال سفارش داشته باشد.
هر سرویس معمولاً داخل یک Container اجرا میشود. اما وقتی تعداد Containerها به صدها یا هزاران مورد برسد، مدیریت آن‌ها دشوار خواهد شد. Kubernetes سامانه‌ای است که استقرار، اجرا، مقیاس‌دهی و بازیابی خودکار این Containerها را مدیریت می‌کند.
کوچک‌ترین واحد اجرایی در Kubernetes معمولاً Pod نام دارد. یک یا چند Pod می‌توانند یک برنامه را ارائه کنند. Podها روی ماشین‌هایی به نام Node اجرا می‌شوند و مجموعه Nodeها یک Cluster را تشکیل می‌دهد. Service نیز یک آدرس نسبتاً ثابت برای دسترسی به گروهی از Podها فراهم می‌کند.
این Kubernetes می‌تواند در صورت ازکارافتادن یک Pod، نمونه دیگری ایجاد کند یا هنگام افزایش درخواست‌ها تعداد Podها را بالا ببرد. این قابلیت‌ها دسترس‌پذیری و مقیاس‌پذیری را افزایش می‌دهند.
بااین‌حال، Kubernetes فقط یک بستر اجرایی نیست؛ بلکه محیطی پویا با ارتباطات فراوان است. Podها دائماً ایجاد، حذف و جابه‌جا می‌شوند. بنابراین کنترل اینکه هر Pod با چه بخش‌هایی ارتباط دارد، به یکی از مهم‌ترین مسائل امنیتی Kubernetes تبدیل میشود.
ادامه دارد ....👇👇
🔥4❤2👏2
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 کافی نیست؛ باید اثر نهایی همه سیاست‌ها را نیز مشاهده و ارزیابی کنیم.
ادامه دارد ....👇👇
در 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 کافی نیست؛ باید اثر نهایی همه سیاست‌ها را نیز مشاهده و ارزیابی کنیم.
ادامه دارد ....👇👇
❤3🔥3
3️⃣مقاله سوم: Cilium چگونه ارتباطات Kubernetes را کنترل می‌کند؟
این Kubernetes برای مدیریت ارتباطات شبکه‌ای به یک افزونه شبکه یا CNI نیاز دارد. Cilium یکی از پیشرفته‌ترین راهکارهای این حوزه است که با استفاده از فناوری eBPF، ارتباطات میان Podها، Nodeها و سرویس‌ها را کنترل و مشاهده می‌کند.
وCilium می‌تواند Network Policyهای استاندارد Kubernetes و سیاست‌های پیشرفته‌تری مانند CiliumNetworkPolicy را اجرا کند. این سیاست‌ها تعیین می‌کنند چه مبدأیی اجازه دارد به چه مقصدی، روی کدام Port و Protocol متصل شود. در موارد پیشرفته‌تر، کنترل ارتباطات تا لایه کاربرد و پروتکل‌هایی مانند HTTP و DNS نیز امکان‌پذیر است.
وCilium معمولاً Podها را براساس Label و Security Identity شناسایی می‌کند. برای مثال، به‌جای وابستگی به IP متغیر یک Pod، می‌توان گفت هر Pod دارای Label برابر "frontend" فقط به Podهای "api" دسترسی داشته باشد.
این انعطاف بسیار ارزشمند است، اما پیچیدگی نیز ایجاد می‌کند. ممکن است یک Policy دسترسی را محدود و Policy دیگری همان ارتباط را از مسیر متفاوتی مجاز کند. همچنین تغییر Label یا اضافه‌شدن یک Workload جدید می‌تواند نتیجه نهایی را تغییر دهد.
ابزار Hubble در اکوسیستم Cilium نشان می‌دهد چه ترافیکی واقعاً میان اجزای Cluster ردوبدل شده است. بااین‌حال، مشاهده ترافیک گذشته همیشه پاسخ نمی‌دهد که براساس Policyها چه ارتباطاتی بالقوه مجازند. برای پاسخ به این سؤال باید روابط مجاز را مانند یک نقشه جامع تحلیل کنیم؛ نیازی که زمینه استفاده از CiliumHound را ایجاد می‌کند.
ادامه دارد ....👇👇
این Kubernetes برای مدیریت ارتباطات شبکه‌ای به یک افزونه شبکه یا CNI نیاز دارد. Cilium یکی از پیشرفته‌ترین راهکارهای این حوزه است که با استفاده از فناوری eBPF، ارتباطات میان Podها، Nodeها و سرویس‌ها را کنترل و مشاهده می‌کند.
وCilium می‌تواند Network Policyهای استاندارد Kubernetes و سیاست‌های پیشرفته‌تری مانند CiliumNetworkPolicy را اجرا کند. این سیاست‌ها تعیین می‌کنند چه مبدأیی اجازه دارد به چه مقصدی، روی کدام Port و Protocol متصل شود. در موارد پیشرفته‌تر، کنترل ارتباطات تا لایه کاربرد و پروتکل‌هایی مانند HTTP و DNS نیز امکان‌پذیر است.
وCilium معمولاً Podها را براساس Label و Security Identity شناسایی می‌کند. برای مثال، به‌جای وابستگی به IP متغیر یک Pod، می‌توان گفت هر Pod دارای Label برابر "frontend" فقط به Podهای "api" دسترسی داشته باشد.
این انعطاف بسیار ارزشمند است، اما پیچیدگی نیز ایجاد می‌کند. ممکن است یک Policy دسترسی را محدود و Policy دیگری همان ارتباط را از مسیر متفاوتی مجاز کند. همچنین تغییر Label یا اضافه‌شدن یک Workload جدید می‌تواند نتیجه نهایی را تغییر دهد.
ابزار Hubble در اکوسیستم Cilium نشان می‌دهد چه ترافیکی واقعاً میان اجزای Cluster ردوبدل شده است. بااین‌حال، مشاهده ترافیک گذشته همیشه پاسخ نمی‌دهد که براساس Policyها چه ارتباطاتی بالقوه مجازند. برای پاسخ به این سؤال باید روابط مجاز را مانند یک نقشه جامع تحلیل کنیم؛ نیازی که زمینه استفاده از CiliumHound را ایجاد می‌کند.
ادامه دارد ....👇👇
🔥5❤1
4️⃣مقاله چهارم و پایان : CiliumHound چگونه مسیرهای حمله را آشکار می‌کند؟
در یک Cluster بزرگ، بررسی دستی فایل‌های Network Policy نمی‌تواند به‌سادگی نشان دهد که پس از تسخیر یک Pod چه مسیرهایی در اختیار مهاجم قرار می‌گیرد.
این CiliumHound اطلاعات Kubernetes و سیاست‌های شبکه Cilium را جمع‌آوری و در قالب BloodHound OpenGraph نمایش می‌دهد. در این گراف، اجزایی مانند Workloadها و Namespaceها به‌صورت Node و دسترسی‌های میان آن‌ها به‌صورت Edge دیده می‌شوند.
فرض کنید Web Pod اجازه ارتباط با API Pod را دارد و API نیز می‌تواند به Database و Admin Service متصل شود. مهاجمی که Web Pod را تصرف کرده است، شاید مستقیماً به پایگاه‌داده دسترسی نداشته باشد؛ اما گراف مسیر زیر را آشکار می‌کند:
Web Pod → API Pod → Database
این زنجیره یک Attack Path است. CiliumHound کمک می‌کند سیاست‌های بیش‌ازحد باز، ارتباطات ناخواسته میان Namespaceها و مسیرهای احتمالی حرکت جانبی شناسایی شوند.
تفاوت مهم آن با Hubble این است که Hubble ترافیک مشاهده‌شده را نمایش می‌دهد، اما CiliumHound روی مسیرهایی تمرکز دارد که براساس Policyها امکان‌پذیرند؛ حتی اگر هنوز استفاده نشده باشند.
این CiliumHound جلوی حمله را نمی‌گیرد؛ بلکه نشان می‌دهد طراحی Microsegmentation کجا ممکن است برای مهاجم یک مسیر پنهان ساخته باشد.
#Kubernetes #KubernetesSecurity #Cilium #CiliumHound #BloodHound #OpenGraph #NetworkPolicy #Microsegmentation #eBPF #ContainerSecurity #CloudNativeSecurity #AttackPath #LateralMovement #ZeroTrust #DevSecOps #CyberSecurity #امنیت_کوبرنتیز #امنیت_کانتینر #ریزتقسیم‌بندی #مسیر_حمله #حرکت_جانبی #امنیت_ابری #امنیت_سایبری #مهندسی_کشف
در یک Cluster بزرگ، بررسی دستی فایل‌های Network Policy نمی‌تواند به‌سادگی نشان دهد که پس از تسخیر یک Pod چه مسیرهایی در اختیار مهاجم قرار می‌گیرد.
این CiliumHound اطلاعات Kubernetes و سیاست‌های شبکه Cilium را جمع‌آوری و در قالب BloodHound OpenGraph نمایش می‌دهد. در این گراف، اجزایی مانند Workloadها و Namespaceها به‌صورت Node و دسترسی‌های میان آن‌ها به‌صورت Edge دیده می‌شوند.
فرض کنید Web Pod اجازه ارتباط با API Pod را دارد و API نیز می‌تواند به Database و Admin Service متصل شود. مهاجمی که Web Pod را تصرف کرده است، شاید مستقیماً به پایگاه‌داده دسترسی نداشته باشد؛ اما گراف مسیر زیر را آشکار می‌کند:
Web Pod → API Pod → Database
این زنجیره یک Attack Path است. CiliumHound کمک می‌کند سیاست‌های بیش‌ازحد باز، ارتباطات ناخواسته میان Namespaceها و مسیرهای احتمالی حرکت جانبی شناسایی شوند.
تفاوت مهم آن با Hubble این است که Hubble ترافیک مشاهده‌شده را نمایش می‌دهد، اما CiliumHound روی مسیرهایی تمرکز دارد که براساس Policyها امکان‌پذیرند؛ حتی اگر هنوز استفاده نشده باشند.
این CiliumHound جلوی حمله را نمی‌گیرد؛ بلکه نشان می‌دهد طراحی Microsegmentation کجا ممکن است برای مهاجم یک مسیر پنهان ساخته باشد.
#Kubernetes #KubernetesSecurity #Cilium #CiliumHound #BloodHound #OpenGraph #NetworkPolicy #Microsegmentation #eBPF #ContainerSecurity #CloudNativeSecurity #AttackPath #LateralMovement #ZeroTrust #DevSecOps #CyberSecurity #امنیت_کوبرنتیز #امنیت_کانتینر #ریزتقسیم‌بندی #مسیر_حمله #حرکت_جانبی #امنیت_ابری #امنیت_سایبری #مهندسی_کشف
🔥4❤1
آنچه که بعنوان MZ در امنیت گفته میشود چیست و چرا در تحلیل بدافزار اهمیت دارد؟
عبارت "MZ" دو بایت ابتدایی بسیاری از فایل‌های اجرایی ویندوز است و در مبنای هگزادسیمال به‌صورت "4D 5A" نمایش داده میشود. این حروف از نام Mark Zbikowski، یکی از مهندسان مایکروسافت و طراح قالب اجرایی DOS، گرفته شده‌اند.
فایل‌های اجرایی با ساختار PE، مانند فایل‌های "EXE"، "DLL"، "SYS" و برخی "SCR"ها، معمولاً با امضای MZ آغاز می‌شوند. بخش ابتدایی فایل، "DOS Header" نام دارد. درون این Header، فیلدی به نام "e_lfanew" وجود دارد که محل قرارگیری امضای "PE" و ساختار اصلی فایل اجرایی ویندوز را مشخص می‌کند.
اهمیت MZ زمانی آشکار میشود که مهاجم پسوند واقعی فایل را پنهان کرده باشد. برای مثال ممکن است فایلی با نام "update.dat"، "invoice.jpg" یا "document.pdf" دریافت شود، اما بررسی محتوای آن نشان دهد که دو بایت ابتدایی فایل "MZ" است. این وضعیت نشان می‌دهد فایل احتمالاً یک برنامه اجرایی ویندوز است، نه تصویر یا سند معمولی.
در تحلیل PCAP می‌توان فایل منتقل‌شده را از جریان HTTP یا SMB استخراج و Header آن را بررسی کرد. بااین‌حال، مشاهده MZ به‌تنهایی اثبات بدافزاربودن فایل نیست؛ زیرا برنامه‌های سالم ویندوز نیز همین امضا را دارند. تحلیلگر باید Hash، امضای دیجیتال، Importها، رشته‌ها، رفتار اجرایی و نتایج Sandbox را نیز بررسی کند.
#MZ #PEFile #PortableExecutable #MalwareAnalysis #DigitalForensics #MemoryForensics #NetworkForensics #PCAP #Wireshark #ThreatHunting #IncidentResponse #ReverseEngineering #SOC #CyberSecurity #تحلیل_بدافزار #فارنزیک_دیجیتال #تحلیل_ترافیک #امنیت_سایبری #مرکز_عملیات_امنیت #آکادمی_روزبه
عبارت "MZ" دو بایت ابتدایی بسیاری از فایل‌های اجرایی ویندوز است و در مبنای هگزادسیمال به‌صورت "4D 5A" نمایش داده میشود. این حروف از نام Mark Zbikowski، یکی از مهندسان مایکروسافت و طراح قالب اجرایی DOS، گرفته شده‌اند.
فایل‌های اجرایی با ساختار PE، مانند فایل‌های "EXE"، "DLL"، "SYS" و برخی "SCR"ها، معمولاً با امضای MZ آغاز می‌شوند. بخش ابتدایی فایل، "DOS Header" نام دارد. درون این Header، فیلدی به نام "e_lfanew" وجود دارد که محل قرارگیری امضای "PE" و ساختار اصلی فایل اجرایی ویندوز را مشخص می‌کند.
اهمیت MZ زمانی آشکار میشود که مهاجم پسوند واقعی فایل را پنهان کرده باشد. برای مثال ممکن است فایلی با نام "update.dat"، "invoice.jpg" یا "document.pdf" دریافت شود، اما بررسی محتوای آن نشان دهد که دو بایت ابتدایی فایل "MZ" است. این وضعیت نشان می‌دهد فایل احتمالاً یک برنامه اجرایی ویندوز است، نه تصویر یا سند معمولی.
در تحلیل PCAP می‌توان فایل منتقل‌شده را از جریان HTTP یا SMB استخراج و Header آن را بررسی کرد. بااین‌حال، مشاهده MZ به‌تنهایی اثبات بدافزاربودن فایل نیست؛ زیرا برنامه‌های سالم ویندوز نیز همین امضا را دارند. تحلیلگر باید Hash، امضای دیجیتال، Importها، رشته‌ها، رفتار اجرایی و نتایج Sandbox را نیز بررسی کند.
#MZ #PEFile #PortableExecutable #MalwareAnalysis #DigitalForensics #MemoryForensics #NetworkForensics #PCAP #Wireshark #ThreatHunting #IncidentResponse #ReverseEngineering #SOC #CyberSecurity #تحلیل_بدافزار #فارنزیک_دیجیتال #تحلیل_ترافیک #امنیت_سایبری #مرکز_عملیات_امنیت #آکادمی_روزبه
❤4💯2
یادگیری چه زمانی عمیق میشود؟
یادگیری زمانی عمیق میشود که اطلاعات را فقط «بخوانیم» یا «بشنویم»، بلکه بتوانیم آن را توضیح دهیم، اجرا کنیم، نقد کنیم و در موقعیتی تازه به کار ببریم.
برای عمیق‌کردن یادگیری، این چرخه بسیار مؤثر است:
1. فهم مفهومی
بعد از مطالعه بپرسید: «این موضوع چرا وجود دارد و چه مسئله‌ای را حل می‌کند؟» برای مثال در DevSecOps، فقط ابزارهای SAST را حفظ نکنید؛ بفهمید چرا کشف ضعف در ابتدای توسعه کم‌هزینه‌تر است.
2. بازگویی بدون منبع
کتاب را ببندید و مطلب را با زبان ساده توضیح دهید. اگر نتوانستید آن را برای فردی مبتدی تشریح کنید، هنوز کاملاً نفهمیده‌اید.
3. بازیابی فعال
به‌جای چند بار خواندن، از خودتان سؤال بپرسید. آزمون، فلش‌کارت و سناریوهای CISSP دقیقاً به همین دلیل از مرور منفعل مؤثرترند.
4. تمرین عملی
مفهوم باید به تجربه تبدیل شود. در آموزش SOC، دانشجو باید PCAP تحلیل کند، Alert بسازد، Logها را Correlate کند و درباره Incident تصمیم بگیرد.
5. تحلیل خطا
فقط پاسخ درست را بررسی نکنید؛ بنویسید چرا پاسخ شما اشتباه بود: ضعف دانش، برداشت نادرست، عجله یا ناتوانی در تحلیل سناریو؟
6. اتصال مفاهیم
مطالب جدید را به دانش قبلی متصل کنید. مثلاً رابطه میان Credential Access، حرکت جانبی، Logهای ویندوز و Detection Engineering را در قالب یک Attack Chain ببینید.
7. مرور فاصله‌دار
مرور را در فاصله‌های یک روز، یک هفته و یک ماه انجام دهید. یادگیری فشرده ممکن است برای امتحان کافی باشد، اما یادگیری پایدار نیازمند بازگشت هدفمند است.
یادگیری زمانی عمیق میشود که اطلاعات را فقط «بخوانیم» یا «بشنویم»، بلکه بتوانیم آن را توضیح دهیم، اجرا کنیم، نقد کنیم و در موقعیتی تازه به کار ببریم.
برای عمیق‌کردن یادگیری، این چرخه بسیار مؤثر است:
1. فهم مفهومی
بعد از مطالعه بپرسید: «این موضوع چرا وجود دارد و چه مسئله‌ای را حل می‌کند؟» برای مثال در DevSecOps، فقط ابزارهای SAST را حفظ نکنید؛ بفهمید چرا کشف ضعف در ابتدای توسعه کم‌هزینه‌تر است.
2. بازگویی بدون منبع
کتاب را ببندید و مطلب را با زبان ساده توضیح دهید. اگر نتوانستید آن را برای فردی مبتدی تشریح کنید، هنوز کاملاً نفهمیده‌اید.
3. بازیابی فعال
به‌جای چند بار خواندن، از خودتان سؤال بپرسید. آزمون، فلش‌کارت و سناریوهای CISSP دقیقاً به همین دلیل از مرور منفعل مؤثرترند.
4. تمرین عملی
مفهوم باید به تجربه تبدیل شود. در آموزش SOC، دانشجو باید PCAP تحلیل کند، Alert بسازد، Logها را Correlate کند و درباره Incident تصمیم بگیرد.
5. تحلیل خطا
فقط پاسخ درست را بررسی نکنید؛ بنویسید چرا پاسخ شما اشتباه بود: ضعف دانش، برداشت نادرست، عجله یا ناتوانی در تحلیل سناریو؟
6. اتصال مفاهیم
مطالب جدید را به دانش قبلی متصل کنید. مثلاً رابطه میان Credential Access، حرکت جانبی، Logهای ویندوز و Detection Engineering را در قالب یک Attack Chain ببینید.
7. مرور فاصله‌دار
مرور را در فاصله‌های یک روز، یک هفته و یک ماه انجام دهید. یادگیری فشرده ممکن است برای امتحان کافی باشد، اما یادگیری پایدار نیازمند بازگشت هدفمند است.
🙏5🔥2
مقوله DevSecOps؛ امنیت به‌عنوان بخشی از فرایند توسعه
بحث DevSecOps رویکردی است که امنیت را از یک کنترل نهایی، به مسئولیتی مشترک در سراسر چرخه توسعه نرم‌افزار تبدیل می‌کند. در روش سنتی، تیم امنیت معمولاً پس از تکمیل محصول وارد عمل میشود؛ زمانی که اصلاح آسیب‌پذیری‌ها پرهزینه، دشوار و گاهی غیرممکن است. در DevSecOps، کنترل‌های امنیتی از مرحله طراحی و کدنویسی آغاز می‌شوند و تا استقرار و بهره‌برداری ادامه می‌یابند.
در این رویکرد، Pipeline می‌تواند به‌صورت خودکار کد، کتابخانه‌ها، Container Image، تنظیمات زیرساخت و Secretها را ارزیابی کند. ابزارهایی مانند SAST، DAST، SCA، IaC Scanning و Secret Scanning به شناسایی زودهنگام ضعف‌ها کمک می‌کنند؛ اما DevSecOps صرفاً مجموعه‌ای از ابزارها نیست. فرهنگ همکاری میان توسعه‌دهندگان، تیم عملیات و متخصصان امنیت، هسته اصلی آن را تشکیل می‌دهد.
یکی از نقاط حساس، اجرای کد متعلق به Pull Requestهای تأییدنشده است. چنین کدی نباید در محیطی اجرا شود که به Token، Cloud Credential، Registry یا Runnerهای عملیاتی دسترسی دارد. تفکیک Pipelineهای غیرقابل‌اعتماد، اعمال Least Privilege، استفاده از Runnerهای موقت و فعال‌سازی Approval پیش از Deployment از کنترل‌های ضروری هستند.
هدف DevSecOps متوقف‌کردن توسعه نیست؛ بلکه تولید نرم‌افزار امن‌تر با سرعتی پایدار است. امنیت زمانی مؤثر خواهد بود که در معماری، کد، Pipeline و عملیات روزانه حضور داشته باشد، نه اینکه فقط پیش از انتشار بررسی شود.
#DevSecOps #DevOps #CyberSecurity #ApplicationSecurity #SecureCoding #SoftwareSecurity #CICD #SecurityAutomation #ShiftLeftSecurity #CloudSecurity #PipelineSecurity #SupplyChainSecurity #SAST #DAST #SCA #امنیت_سایبری #امنیت_نرم_افزار #توسعه_امن #مهندسی_امنیت #آکادمی_روزبه
بحث DevSecOps رویکردی است که امنیت را از یک کنترل نهایی، به مسئولیتی مشترک در سراسر چرخه توسعه نرم‌افزار تبدیل می‌کند. در روش سنتی، تیم امنیت معمولاً پس از تکمیل محصول وارد عمل میشود؛ زمانی که اصلاح آسیب‌پذیری‌ها پرهزینه، دشوار و گاهی غیرممکن است. در DevSecOps، کنترل‌های امنیتی از مرحله طراحی و کدنویسی آغاز می‌شوند و تا استقرار و بهره‌برداری ادامه می‌یابند.
در این رویکرد، Pipeline می‌تواند به‌صورت خودکار کد، کتابخانه‌ها، Container Image، تنظیمات زیرساخت و Secretها را ارزیابی کند. ابزارهایی مانند SAST، DAST، SCA، IaC Scanning و Secret Scanning به شناسایی زودهنگام ضعف‌ها کمک می‌کنند؛ اما DevSecOps صرفاً مجموعه‌ای از ابزارها نیست. فرهنگ همکاری میان توسعه‌دهندگان، تیم عملیات و متخصصان امنیت، هسته اصلی آن را تشکیل می‌دهد.
یکی از نقاط حساس، اجرای کد متعلق به Pull Requestهای تأییدنشده است. چنین کدی نباید در محیطی اجرا شود که به Token، Cloud Credential، Registry یا Runnerهای عملیاتی دسترسی دارد. تفکیک Pipelineهای غیرقابل‌اعتماد، اعمال Least Privilege، استفاده از Runnerهای موقت و فعال‌سازی Approval پیش از Deployment از کنترل‌های ضروری هستند.
هدف DevSecOps متوقف‌کردن توسعه نیست؛ بلکه تولید نرم‌افزار امن‌تر با سرعتی پایدار است. امنیت زمانی مؤثر خواهد بود که در معماری، کد، Pipeline و عملیات روزانه حضور داشته باشد، نه اینکه فقط پیش از انتشار بررسی شود.
#DevSecOps #DevOps #CyberSecurity #ApplicationSecurity #SecureCoding #SoftwareSecurity #CICD #SecurityAutomation #ShiftLeftSecurity #CloudSecurity #PipelineSecurity #SupplyChainSecurity #SAST #DAST #SCA #امنیت_سایبری #امنیت_نرم_افزار #توسعه_امن #مهندسی_امنیت #آکادمی_روزبه
🔥4❤1
مقابله با شکستن پسورد به کمک ریاضیات
توابع مشتق‌گیری کلید کُند (Slow KDFs)
توابع مشتق‌گیری کلید کُند مانند Argon2id، bcrypt و PBKDF2، الگوریتم‌هایی هستند که عمداً با تحمیل بار محاسباتی و زمان‌بر بودن طراحی شده‌اند تا سرعت پردازش را مهار کنند. برخلاف توابع هش معمولی که بسیار سریع‌اند، KDFها با استفاده از هزاران چرخه تکرار (Iterations) و در نمونه‌های مدرن نظیر Argon2 با درگیر کردن حجم مشخصی از حافظه رم (Memory-Hardness)، هزینه محاسبات را به شدت بالا می‌برند.
این ویژگی کُندی کنترل‌شده، حملات Brute-Force را تقریبا خنثی کرده و استفاده از پردازنده‌های گرافیکی (GPU) یا تجهیزات اختصاصی (ASIC) برای شکستن انبوه پسوردها را غیراقتصادی می‌سازد.
#زیبایی_ریاضی
#آکادمی_روزبه
دوره 82 ام CISSP از دیماه
فرصت استفاده از 30 درصد تخفیف تا ۱۵ مهر
09902857290
توابع مشتق‌گیری کلید کُند (Slow KDFs)
توابع مشتق‌گیری کلید کُند مانند Argon2id، bcrypt و PBKDF2، الگوریتم‌هایی هستند که عمداً با تحمیل بار محاسباتی و زمان‌بر بودن طراحی شده‌اند تا سرعت پردازش را مهار کنند. برخلاف توابع هش معمولی که بسیار سریع‌اند، KDFها با استفاده از هزاران چرخه تکرار (Iterations) و در نمونه‌های مدرن نظیر Argon2 با درگیر کردن حجم مشخصی از حافظه رم (Memory-Hardness)، هزینه محاسبات را به شدت بالا می‌برند.
این ویژگی کُندی کنترل‌شده، حملات Brute-Force را تقریبا خنثی کرده و استفاده از پردازنده‌های گرافیکی (GPU) یا تجهیزات اختصاصی (ASIC) برای شکستن انبوه پسوردها را غیراقتصادی می‌سازد.
#زیبایی_ریاضی
#آکادمی_روزبه
دوره 82 ام CISSP از دیماه
فرصت استفاده از 30 درصد تخفیف تا ۱۵ مهر
09902857290
🔥4👍2
شماره تماس برای دریافت مشاوره فنی سازمانها در حوزه امنیت سایبری با استاد روزبه CTO شرکت هامون
09902857290
لطفا پیام دهید با شما تماس گرفته خواهد شد 🙏
09902857290
لطفا پیام دهید با شما تماس گرفته خواهد شد 🙏
🔥2🙏2❤1
آکادمی آموزش روزبه 📚 pinned «شماره تماس برای دریافت مشاوره فنی سازمانها در حوزه امنیت سایبری با استاد روزبه CTO شرکت هامون 09902857290 لطفا پیام دهید با شما تماس گرفته خواهد شد 🙏»
آیا مشاهده Sysmon Event ID 8 به‌تنهایی اثبات Process Injection است؟
خیر. مشاهده Sysmon Event ID 8 (CreateRemoteThread) نشانه‌ای مهم از رفتار مرتبط با Process Injection است، اما به‌تنهایی نمی‌تواند اثبات کند که تزریق مخرب رخ داده است.
رویداد Event ID 8 زمانی ایجاد میشود که یک Process، Thread جدیدی را در فضای Process دیگری ایجاد کند. این تکنیک می‌تواند توسط بدافزارها برای اجرای کد در بستر پردازشی دیگر استفاده شود، اما برخی نرم‌افزارهای قانونی نیز ممکن است رفتار مشابهی داشته باشند. بنابراین در SOC باید آن را یک Signal بدانیم، نه یک Verdict.
نبودن Event ID 10 (Process Access) نیز الزاماً Event 8 را بی‌اعتبار نمی‌کند. Event ID 10 وابسته به پیکربندی Sysmon و Filtering است و ممکن است دسترسی موردنظر ثبت نشده یا توسط Ruleهای پیکربندی حذف شده باشد. همچنین تله‌متری امنیتی همیشه تصویر کاملی از تمام مراحل یک رفتار ارائه نمی‌دهد.
تحلیلگر بهتر است به جای جست‌وجوی یک Event خاص، زنجیره شواهد را بررسی کند. برای مثال:
اگر Event 10 وجود ندارد، باید سایر شواهد Event 8 بررسی شوند:
بنابراین Event ID 8 بدون Event ID 10 همچنان می‌تواند یک سرنخ بسیار مهم برای Process Injection باشد، اما نتیجه‌گیری نهایی باید بر اساس Context و Correlation انجام شود.
این دقیقاً یکی از اصول مهم Detection Engineering است:
یک Event به ما می‌گوید «چه اتفاقی افتاده»؛ اما مجموعه‌ای از Eventها و Context به ما کمک می‌کند بفهمیم «چرا اتفاق افتاده و آیا مخرب بوده است».
دوره SOC آکادمی روزبه و شرکت هامون
خیر. مشاهده Sysmon Event ID 8 (CreateRemoteThread) نشانه‌ای مهم از رفتار مرتبط با Process Injection است، اما به‌تنهایی نمی‌تواند اثبات کند که تزریق مخرب رخ داده است.
رویداد Event ID 8 زمانی ایجاد میشود که یک Process، Thread جدیدی را در فضای Process دیگری ایجاد کند. این تکنیک می‌تواند توسط بدافزارها برای اجرای کد در بستر پردازشی دیگر استفاده شود، اما برخی نرم‌افزارهای قانونی نیز ممکن است رفتار مشابهی داشته باشند. بنابراین در SOC باید آن را یک Signal بدانیم، نه یک Verdict.
نبودن Event ID 10 (Process Access) نیز الزاماً Event 8 را بی‌اعتبار نمی‌کند. Event ID 10 وابسته به پیکربندی Sysmon و Filtering است و ممکن است دسترسی موردنظر ثبت نشده یا توسط Ruleهای پیکربندی حذف شده باشد. همچنین تله‌متری امنیتی همیشه تصویر کاملی از تمام مراحل یک رفتار ارائه نمی‌دهد.
تحلیلگر بهتر است به جای جست‌وجوی یک Event خاص، زنجیره شواهد را بررسی کند. برای مثال:
Event 1 → Event 10 → Event 8 → Network Activityاگر Event 10 وجود ندارد، باید سایر شواهد Event 8 بررسی شوند:
SourceImage و TargetImage چه هستند؟ آیا Source Process از مسیر مشکوکی مانند Temp اجرا شده؟ StartAddress به کجا اشاره می‌کند؟ آیا StartModule یا StartFunction ناشناخته است؟ پس از ایجاد Thread، آیا Target Process رفتار شبکه‌ای یا فایل‌سیستمی غیرعادی نشان داده است؟بنابراین Event ID 8 بدون Event ID 10 همچنان می‌تواند یک سرنخ بسیار مهم برای Process Injection باشد، اما نتیجه‌گیری نهایی باید بر اساس Context و Correlation انجام شود.
این دقیقاً یکی از اصول مهم Detection Engineering است:
یک Event به ما می‌گوید «چه اتفاقی افتاده»؛ اما مجموعه‌ای از Eventها و Context به ما کمک می‌کند بفهمیم «چرا اتفاق افتاده و آیا مخرب بوده است».
دوره SOC آکادمی روزبه و شرکت هامون
❤6💯1