• در دنیای امنیت لینوکس، یک باور اشتباه وجود دارد که مهاجم برای نفوذ حتماً باید از بدافزارهای پیچیده استفاده کند. اما واقعیت میدانی نشان می‌دهد که بسیاری از حملات با اجرای چند دستور ساده در محیط 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 روی Kali Linux

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

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

    نصب auditd

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

    فعال‌سازی سرویس auditd

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

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

    تست صحت عملکرد و مسیر لاگ‌ها

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    ابزار کنترل (auditctl)

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

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

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

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

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

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

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

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

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

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

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

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

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

    جمع‌بندی

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

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

    سوالات متداول

    آیا استفاده از auditd باعث کاهش سرعت و کارایی (Performance) سرور می‌شود؟

    از آنجایی که auditd در سطح هسته (Kernel) فعالیت می‌کند، بار پردازشی کمی دارد. اما اگر قوانین بسیار زیادی تعریف کنید (مثلاً مانیتور کردن تمام فایل‌های سیستم)، ممکن است فشار روی CPU افزایش یابد. پیشنهاد می‌شود قوانین را فقط برای فایل‌ها و دایرکتوری‌های حساس بنویسید تا بالانس میان امنیت و کارایی حفظ شود.

    تفاوت اصلی auditd با ابزارهایی مثل Fail2Ban چیست؟

    Fail2Ban یک ابزار واکنشی (Reactive) است که بر اساس لاگ‌ها، دسترسی‌ها را مسدود می‌کند. اما auditd یک ابزار نظارتی و جرم‌شناسی (Forensic) است که تمام جزئیاتِ “چه کسی، چه کاری را انجام داد” را ثبت می‌کند. در واقع auditd داده‌های لازم برای تحلیل‌های عمیق‌تر در SOC را فراهم می‌آورد.

    چگونه می‌توان لاگ‌های auditd را در برابر حذف شدن توسط مهاجم محافظت کرد؟

    یکی از بهترین روش‌ها، ارسال هم‌زمان لاگ‌ها به یک سرور مرکزی (Remote Logging) مانند SIEM یا یک Log Server مجزا است. همچنین می‌توانید با تنظیم پاراگراف‌های پیکربندی در auditd.conf و قفل کردن قوانین با سوئیچ -e 2 (تغییرناپذیر کردن قوانین تا بوت بعدی)، امنیت سیستم لاگ‌گیری را بالا ببرید.

    چرا بعد از ریستارت سیستم، قوانینی که با auditctl نوشته‌ام پاک می‌شوند؟

    دستوراتی که با auditctl در ترمینال وارد می‌کنید، موقتی هستند و در حافظه RAM ذخیره می‌شوند. برای دائمی کردن قوانین، باید آن‌ها را در فایل پیکربندی /etc/audit/rules.d/audit.rules (یا در برخی توزیع‌ها /etc/audit/audit.rules) وارد کنید.

    آیا auditd می‌تواند آرگومان‌های مخفی دستورات (مانند پسوردها) را هم ثبت کند؟

    بله، این ابزار تمام آرگومان‌های ورودی را ثبت می‌کند. به همین دلیل باید در سطح دسترسی به فایل‌های لاگ (/var/log/audit/audit.log) بسیار حساس باشید، زیرا ممکن است اطلاعات حساسی که کاربران در ترمینال وارد کرده‌اند (مثل پسورد در برخی دستورات خاص) در این لاگ‌ها قابل مشاهده باشد.

    میانگین امتیازات ۵ از ۵
    از مجموع ۱ رای