پاک شدن Log به معنی پاک شدن Evidence نیست


یکی از تکنیک‌های رایج مهاجمان پس از نفوذ به سیستم‌های Linux، پاک کردن Logها برای از بین بردن ردپا است.
برای مثال، مهاجم ممکن است پس از ورود از طریق SSH فایل /var/log/auth.log را حذف یا خالی کند و تصور کند شواهد ورود او از بین رفته است.

اما در سیستم‌های مبتنی بر systemd، تحلیلگر فارنزیک نباید Investigation را در همین نقطه متوقف کند. سرویس systemd-journald می‌تواند همان فعالیت‌ها را در Journal خود ثبت کرده باشد.
برای مثال، می‌توان فعالیت‌های مرتبط با sshd را با دستور زیر بررسی کرد:
journalctl _COMM=sshd
همچنین با since-- می‌توان محدوده زمانی Investigation را مشخص کرد. حتی journalctl --file امکان تحلیل فایل Journal استخراج‌شده از یک سیستم یا Disk Image دیگر را فراهم می‌کند.

البته باقی‌ماندن این شواهد قطعی نیست. journald ممکن است به‌صورت Persistent در /var/log/journal یا به‌صورت Volatile در /run/log/journal کار کند؛ حالت Volatile با Reboot از بین می‌رود.

درس مهم برای Incident Response این است:
هر رویداد ممکن است در چند Evidence Source ردپا داشته باشد.

مهاجم شاید auth.log را پاک کند، اما هنوز ممکن است شواهدی در journald، auditd، SIEM، EDR، Firewall یا سایر منابع مرکزی باقی مانده باشد.

کار تحلیلگر فارنزیک، شناختن شواهدی است که مهاجم فراموش کرده پاک کند.

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

🌼جناب مهندس کیانوش حبیبی
Kianoush Habibi Sesari
مدیر MSSP شرکت هامون
مدیر سابق SOC کاریزما

🌸برای آشنایی با نحوه تدریس ایشان به ویدئو های دوره CIS Controls در آپارات آکادمی روزبه مراجعه نمایید

ثبت نام از طریق واتس اپ و بله 09902857290

🌹آینده شما در امنیت سایبری از قدمهای امروز شما رقم می‌خورد

🟢با آکادمی روزبه کیفیت آموزش را معنا میکنیم

درمورد OEM و Supply chain که در جلسات CISSP صحبت شد

در ارزیابی Technology Supply Chain Risk، دانستن کشور سازنده محصول تنها نقطه شروع است، نه پایان تحلیل ریسک. یک تجهیز ممکن است با برند یک شرکت معتبر عرضه شود، اما سخت‌افزار آن توسط OEM دیگری تولید شده، Firmware آن توسط پیمانکار ثالث توسعه یافته یا برخی ماژول‌های ارتباطی آن از زنجیره‌ای کاملاً متفاوت تأمین شده باشند.

بنابراین سازمان پیش از ورود تجهیزات حساس به زیرساخت باید بپرسد: OEM واقعی چه کسی است؟ مالک و توسعه‌دهنده Firmware کیست؟ Firmware چگونه Sign و Update می‌شود؟ آیا Secure Boot فعال است؟ چه ماژول‌های Wi-Fi، Bluetooth، Cellular یا Management Interface در تجهیز وجود دارد؟

حتی مهم‌تر، باید بررسی شود آیا دستگاه می‌تواند خارج از مسیرهای ارتباطی تعریف‌شده در معماری سازمان، یک Out-of-Band Communication Channel ایجاد کند.

اصل مهم این است که Vendor Trust جایگزین Technical Verification نیست. امنیت زنجیره تأمین زمانی واقعی می‌شود که منشأ، Firmware، اجزا، مسیرهای ارتباطی و مکانیزم‌های به‌روزرسانی محصول مستقل از ادعاهای Vendor بررسی شوند.

https://news.risky.biz/risky-bulletin-slovakia-finds-russian-backdoor-in-traffic-speed-cameras/

واتس اپ و بله 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 فراهم می‌سازد.

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


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