در دنیای امنیت لینوکس، یک باور اشتباه وجود دارد که مهاجم برای نفوذ حتماً باید از بدافزارهای پیچیده استفاده کند. اما واقعیت میدانی نشان می‌دهد که بسیاری از حملات با اجرای چند دستور ساده در محیط Bash آغاز می‌شوند. مهاجمان با استفاده از ابزارهای بومی، اقدام به شناسایی سیستم و ایجاد ماندگاری (Persistence) می‌کنند؛ دقیقاً به همین دلیل است که مانیتورینگ رفتار دستورات به یکی از حیاتی‌ترین وظایف تیم‌های SOC تبدیل شده است.

در رویکردهای سنتی (Signature-based Detection)، تمرکز بر فایل‌های مخرب بود، اما در حملات مدرن، از ابزارهای قانونی مثل curl ،chmod یا base64 استفاده می‌شود. در این مقاله، ما از روش‌های قدیمی عبور کرده و به سراغ تشخیص رفتارمحور (Behavior-Based Detection) می‌رویم و یاد می‌گیریم که چطور با استفاده از ابزار قدرتمند auditd، نه تنها اجرای فایل‌ها، بلکه لایه‌های زیرین رفتاری سیستم را مانیتور کنیم.

آنچه در این مقاله بررسی خواهیم کرد:

  • تحلیل نقش استراتژیک auditd در مانیتورینگ امنیتی.

  • پیاده‌سازی و پیکربندی عملیاتی auditd در محیط Kali Linux.

  • تدوین قوانین (Rules) کاربردی برای شکار رفتارهای مشکوک در Bash.

تحلیل ساختار auditd و ضرورت آن در SOC

در ابتدا باید به این پرسش پاسخ دهیم که auditd چیست و چرا در مراکز عملیات امنیت (SOC) جایگاهی استراتژیک دارد؟ ابزار auditd یا همان Linux Audit Daemon، زیرسیستمی است که برای ثبت وقایع امنیتی در سطح هسته (Kernel) طراحی شده است. برخلاف ابزارهای لاگ‌گیری معمولی، این سرویس به مدیران سیستم و تحلیلگران امنیتی اجازه می‌دهد تا تمامی رویدادهای حساس را با جزئیات بسیار بالا و در سطح فراخوان‌های سیستمی (System Calls) مانیتور کنند.

در محیط‌های SOC، اولویت ما فراتر از جمع‌آوری ساده‌ی لاگ است؛ ما بر تشخیص ناهنجاری و پاسخ به حوادث (Incident Response) تمرکز داریم. قدرت auditd دقیقاً در همین نقاط نمایان می‌شود:

  • رویکرد رفتارمحور: به جای تمرکز بر فایل، بر الگوهای رفتاری سیستم متمرکز است.

  • نظارت بر ابزارهای قانونی: اجرای دستورات مجاز اما مشکوک را با دقت ثبت می‌کند.

  • تسهیل Threat Hunting: داده‌های لازم برای رهگیری تهدیدات پنهان را فراهم می‌آورد.

  • قانون‌گذاری سفارشی: امکان تعریف Ruleهای دقیق بر اساس سیاست‌های امنیتی سازمان را فراهم می‌کند.

 

تفاوت auditd با syslog و journalctl

بسیاری از متخصصان تصور می‌کنند که برای مانیتورینگ امنیتی، لاگ‌های syslog کفایت می‌کند. اما برای درک بهتر تفاوت فاحش این ابزارها، نگاهی به جدول زیر بیندازید:

ویژگی auditd

syslog / journalctl
ثبت syscall ✅ پشتیبانی کامل در سطح کرنل ❌عدم دسترسی
ثبت آرگومان دستورات ✅ ثبت دقیق پارامترهای اجرایی ❌ثبت محدود و سطحی
Rule-based detection ✅ قابلیت تعریف قوانین داینامیک ❌ساختار ایستا (Static)
کاربرد در SOC ✅ ابزار پایه برای SIEM و EDR ⚠️ ابزار مانیتورینگ عمومی

به طور خلاصه، در حالی که syslog برای خطایابی (Troubleshooting) و نظارت عمومی مناسب است، auditd به عنوان یک ابزار تراز اول در تحلیل‌های جرم‌شناسی دیجیتال و مانیتورینگِ امنیت‌محور شناخته می‌شود.

نصب و فعال‌سازی auditd روی Kali Linux

بررسی نصب بودن auditd

برای شروع کار با auditd، ابتدا باید از نصب و فعال بودن سرویس آن بر روی سیستم مطمئن بشیم. اگرچه بسیاری از توزیع‌های امنیتی مثل Kali Linux ممکن است این ابزار را به صورت پیش‌فرض داشته باشند، اما بررسی وضعیت آن اولین قدم در چک‌لیست امنیتی ماست.
در ترمینال Kali دستور auditctl -sرا اجرا می‌کنیم. اگر auditd نصب و فعال باشد، خروجی‌ای مشابه وضعیت audit subsystem نمایش داده می‌شود در غیر این صورت خروجی مشابه زیر خواهد بود.

چک کردن نصب بودن auditdنصب auditd

برای نصب می‌توانید در ادامه خروجی بالا حرف Y را وارد کنید تا فرایند نصب به صورت خودکار انجام شود. در غیر این صورت می‌توانید از دستور زیر استفاده کنید:

دستور نصب auditd روی لینوکسفعال‌سازی سرویس auditd

پس از اتمام نصب، نوبت به فعال‌سازی دائم سرویس می‌رسد. برای اینکه مطمئن شویم auditd در هر بار بوت شدن سیستم به صورت خودکار اجرا می‌شود، دستورات زیر را با دسترسی root وارد می‌کنیم:

فعال کردن سرویس auditd روی لینوکس

برای تایید نهایی، وضعیت سرویس را چک کنید. خروجی باید وضعیت active (running) را نشان دهد:

چک فعال بودن سرویس auditdتست صحت عملکرد و مسیر لاگ‌ها

برای اطمینان از اینکه دیمون (Daemon) به درستی در حال شنودِ رویدادهاست، یک بار دیگر وضعیت کلی را چک می‌کنیم، در این مرحله باید اطلاعاتی درباره وضعیت audit framework نمایش داده شود:

تست کار کردن auditdاین خروجی نشان می‌دهد که auditd آماده دریافت Ruleها و ثبت رویدادهای امنیتی است.

محل ذخیره لاگ‌های auditd

به‌صورت پیش‌فرض، لاگ‌های auditd در مسیر زیر ذخیره می‌شوند و این همان مسیری است که باید در ابزارهای SIEM (مثل ELK یا Splunk) برای تحلیل لاگ‌ها معرفی شود:

مسیر ذخیره لاگ های auditd در لینوکس

ابزارهای مدیریت و تحلیل در سیستم Auditd

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

ساختار لاگ‌های auditd

هر رویداد در auditd ممکن است شامل چندین رکورد باشد که در کنار هم یک Event کامل را تشکیل می‌دهند. این رکوردها اطلاعاتی مانند:

  • زمان دقیق رخداد

  • نوع رویداد (SYSCALL، EXECVE، PATH و …)

  • شناسه پردازش (PID)

  • شناسه کاربر (UID)

  • مسیر فایل اجرایی

  • آرگومان‌های دستور

را در خود دارند.

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

دستور مشاهده نمونه لاگ auditdابزار کنترل (auditctl)

این ابزار قلب تپنده مدیریت قوانین است. با auditctl می‌توانیم در لحظه قوانینی را به هسته لینوکس تزریق کنیم یا قوانین فعلی را بازبینی کنیم.

برای مشاهده وضعیت کلی auditd از دستور زیر استفاده می‌کنیم:

مشاهده کلی وضعیتاین خروجی نشان می‌دهد که audit فعال است و آماده دریافت Ruleهای امنیتی می‌باشد.

ابزار جستجو و فیلترینگ (ausearch)

جستجوی دستی در فایل لاگ عملاً غیرممکن است. ausearch به مااجازه می‌دهد بر اساس پارامترهای مختلف (مثل زمان، نام کاربر، یا کلید اختصاصی قوانین) در لاگ‌ها کوئری بزنیم. مثلاً برای مشاهده تمامی رویدادهای ثبت شده امروز می‌توانیم از دستور زیر استفاده کنیم:

مشاهده رویدادهای امروز auditd

تدوین قوانین امنیتی (Rules) برای شکار تهدیدات در Bash

در این بخش، سه قانون عملیاتی را تعریف می‌کنیم که به طور مستقیم برای شناسایی رفتارهای مخرب در Bash طراحی شده‌اند.

مانیتورینگ اجرای فایل از دایرکتوری‌های موقت (/tmp)

یکی از تکنیک‌های رایج مهاجمان، دانلود و اجرای اسکریپت‌های مخرب در مسیر /tmp است، چرا که این مسیر معمولاً دسترسی نوشتن برای همه کاربران را دارد. در مثال زیر ابتدا یک قانون تعریف کرده و سپس از دستور auditctl -l برای مشاهده قوانین اضافه شده استفاده می‎‌کنیم. قانون ایجاد شده می‌گوید هر زمان فایلی از مسیر /tmp اجرا شد، آن را با برچسب exec_from_tmp ثبت کن. من خودم وقتی اولین بار این Rule را تست کردم، فکر می‌کردم سیستم سنگین می‌شود، اما در واقعیت متوجه شدم که تاثیرش روی CPU کالی لینوکس زیر ۱ درصد بود.

دستور مانیتور اجرای فایل از مسیر /tmp

  • -a always,exit: ثبت رویداد بلافاصله پس از پایان اجرای دستور.
  • -F dir=/tmp: تمرکز بر کل محتویات دایرکتوری موقت.
  • -F perm=x: فقط رویدادهای مربوط به «اجرا» (Execute) ثبت شوند، نه خواندن و نوشتن ساده.
  • -k exec_from_tmp: اختصاص یک کلید (Key) برای جستجوی سریع در آینده.

نظارت بر ابزارهای انتقال فایل (curl و wget)

دانلود فایل از اینترنت، به‌خصوص در سرورهای لینوکسی، می‌تواند نشانه دریافت payload یا ابزار مخرب باشد در نتیجه باید نظارت برای آن صورت بگیرد.

مانیتور استفاده از ابزارهای دانلود (curl و wget)

  • -F path=/usr/bin/curl:این فیلتر مشخص می‌کند فقط اجرای این باینری خاص مانیتور شود.

یعنی فقط زمانی لاگ ثبت می‌شود که دقیقاً /usr/bin/curl اجرا شود و نه فایل‌های دیگر با نام مشابه.

  • keyها (curl_exec و wget_exec): کمک می‌کنند بعدها بفهمیم دانلود با curl بوده یا wget تا بتوانیم alert جداگانه تعریف کنیم.

شناسایی تلاش برای مخفی‌سازی (Base64 Obfuscation)

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

مانیتور اجرای base64

جمع‌بندی

در این مقاله، از لزوم تغییر دیدگاه از «فایل‌محور» به «رفتارمحور» صحبت کردیم و یاد گرفتیم چطور با پیاده‌سازی auditd در کالی لینوکس، یک لایه نظارتی قدرتمند ایجاد کنیم. فراموش نکنید که قوانینِ وارد شده با دستور auditctl موقتی هستند و با ریستارت سیستم پاک می‌شوند.

پیشنهاد می‌کنم در ادامه به دنبال یادگیری پیاده‌سازی و ایجاد قوانین اما به‌صورت دائمی و پایدار در سیستم و تنظیم سطح حساسیت قوانین بر اساس نیاز محیط بروید.