تصویر کلی
Linux Audit می‌تواند syscall، file watch و رخدادهای هویتی را برای بررسی امنیتی ثبت کند.
برای فهم این موضوع بهتر است اجزا را به‌عنوان یک مسیر ببینیم، نه مجموعه‌ای از گزینه‌های مستقل. در Production معمولاً مشکل زمانی شکل می‌گیرد که تنظیم روی دیسک، وضعیت Runtime و فرض تیم درباره رفتار سیستم با هم یکی نیستند. به همین دلیل مشاهده وضعیت مؤثر، Log و Metric باید کنار Configuration بررسی شود.
اجزای اصلی و مرز مسئولیت
Ruleها باید براساس هدف و threat model انتخاب شوند؛ audit همه‌چیز بدون اولویت‌بندی می‌تواند حجم و هزینه تحلیل را بالا ببرد.
در طراحی عملی، برای هر جزء یک سؤال روشن بنویسید: چه ورودی می‌گیرد، چه خروجی تولید می‌کند، چه Stateای نگه می‌دارد و در خرابی چه کسی مسئول Recovery است. این مدل ساده کمک می‌کند خطاهای شبکه، هویت، ذخیره‌سازی یا Replication به‌اشتباه به جزء دیگری نسبت داده نشوند.
خطاهای رایج
برای incident response، clock sync، retention و correlation با journald و application log به اندازه خود audit rule اهمیت دارند.
خطای دیگر، فعال‌کردن قابلیت پیشرفته بدون تعریف معیار موفقیت است. قبل از تغییر، Baseline بگیرید؛ بعد از تغییر همان Signalها را مقایسه کنید. اگر سیستم توزیع‌شده است، Failure Modeهای قطع شبکه، Restart، Lag، Timeout و از دست‌رفتن Dependency را نیز آزمایش کنید.
چک‌لیست عملی
- نسخه و Configuration مؤثر را ثبت کنید، نه فقط فایل مورد انتظار را.
- مسیر داده و کنترل را جدا رسم کنید.
- Health، Latency، Error Rate و ظرفیت را قبل و بعد از تغییر مقایسه کنید.
- برای تغییرات Stateful، Backup/Restore یا Rollback واقعی را آزمایش کنید.
- دسترسی مدیریتی را حداقل کنید و Log تصمیم‌ها را نگه دارید.
- مستندات همان نسخه محصول را مرجع نهایی قرار دهید.
تمرین IROSG
یک محیط کوچک آزمایشی بسازید و فقط یک Failure را تزریق کنید؛ مثلاً قطع Upstream، حذف یک Replica، خطای DNS یا تغییر Route. قبل از آزمایش بنویسید انتظار دارید کدام Metric و Log تغییر کند. بعد نتیجه واقعی را با انتظار مقایسه کنید. این تمرین معمولاً سریع‌تر از حفظ‌کردن Optionها، مدل ذهنی سیستم را اصلاح می‌کند.
مرجع
این راهنما بر پایه مستندات رسمی Red Hat نوشته شده و مثال‌های عملی تحریریه برای آموزش دفاعی و عملیاتی هستند.
از سؤال امنیتی به rule برسید
Linux Audit زمانی مفید است که بدانید چه پرسشی باید بعداً پاسخ داده شود. برای نمونه، «چه حسابی تنظیم احراز هویت را تغییر داد؟» از «همه چیز را ثبت کن» عملی‌تر است. سؤال اول مسیر، نوع عملیات و هویت مورد نیاز را مشخص می‌کند؛ سؤال دوم ممکن است حجم بزرگی از داده کم‌فایده بسازد. ابتدا دارایی‌های حساس و تغییرهای مهم را فهرست کنید، سپس برای هر کدام شواهد لازم را تعریف کنید. این روش انتخاب rule را به نیاز بررسی حادثه وصل می‌کند.
Audit از سازوکار kernel برای تولید رخداد استفاده می‌کند و auditd در دریافت و نگهداری آن نقش دارد. این مسیر با log برنامه متفاوت است؛ برنامه ممکن است عملیاتی را ثبت نکند ولی رخداد سیستم قابل مشاهده باشد. در مقابل، Audit معمولاً معنای کسب‌وکاری کامل یک درخواست را نمی‌داند. برای فهم اینکه تغییر فایل مربوط به کدام سفارش یا کاربر وب بوده، باید داده برنامه را نیز با زمان و شناسه مناسب پیوند دهید. هیچ‌کدام به تنهایی تمام داستان را نمی‌گویند.
یک event ممکن است چند record داشته باشد
در خروجی خام، یک عمل می‌تواند به رکوردهای مختلفی مانند syscall، مسیر و اطلاعات فرایند تبدیل شود. شناسه رخداد و زمان کمک می‌کنند این رکوردها به هم وصل شوند. شمردن هر خط به عنوان یک حادثه مستقل، تعداد و معنا را مخدوش می‌کند. هنگام جست‌وجو، همه رکوردهای متعلق به event را کنار هم ببینید. ممکن است نام فایل در یک رکورد و نتیجه موفق یا ناموفق در رکورد دیگری باشد.
نام syscall یا عدد آن بدون معماری قابل تفسیر دقیق نیست. در میزبان‌هایی که برنامه‌های با ABI متفاوت اجرا می‌شوند، rule باید معماری مورد نظر را آگاهانه پوشش دهد. کپی کردن یک rule از سیستم دیگر بدون بررسی این نکته ممکن است شکاف ایجاد کند. همچنین مسیر نسبی، directory کاری و عملیات روی descriptor می‌توانند تفسیر نام فایل را پیچیده کنند. برای نتیجه‌گیری، رکوردهای همراه و زمینه فرایند را نیز بخوانید.
هویت ورود با هویت مؤثر فرق دارد
UID، EUID و AUID پرسش‌های متفاوتی درباره هویت را پاسخ می‌دهند. حسابی که کاربر با آن وارد شده ممکن است پس از استفاده از sudo به هویت مؤثر دیگری تبدیل شود. برای نسبت دادن فعالیت به نشست اولیه، اطلاعات audit login identity اهمیت دارد؛ برای فهم مجوز اجرای عمل، هویت مؤثر مهم است. فقط دیدن root در یک رکورد همیشه مشخص نمی‌کند کدام کاربر انسانی آغازگر بوده است. البته سرویس‌های بدون نشست انسانی ممکن است مقدار متفاوت یا تنظیم‌نشده داشته باشند و باید جدا تحلیل شوند.
در آزمایش، با یک حساب معمولی وارد شوید و یک تغییر مجاز از مسیر sudo روی فایل آزمایشی انجام دهید. سپس رخداد را بخوانید و هویت ورود، هویت مؤثر، برنامه اجراشده و نتیجه را مشخص کنید. این تمرین ساده به تیم کمک می‌کند تفاوت فیلدها را قبل از حادثه بفهمد. از فایل‌های واقعی احراز هویت برای تمرین تغییر استفاده نکنید؛ هدف یادگیری معناست و یک فایل اختصاصی همان مشاهده را با ریسک کمتر فراهم می‌کند.
rule موقت و پایدار
تغییرهای اعمال‌شده با ابزار runtime لزوماً پس از reboot باقی نمی‌مانند. برای سیاست پایدار باید فایل‌های مربوط و روش بارگذاری توزیع را به کار ببرید. بعد از بارگذاری، فهرست ruleهای فعال را بررسی کنید؛ وجود متن در فایل ثابت نمی‌کند kernel آن را پذیرفته است. ترتیب ruleها و قواعد حذف یا استثنا نیز اهمیت دارند. یک rule گسترده در جای نامناسب می‌تواند نتیجه مورد انتظار rule دیگر را تغییر دهد.
برای هر مجموعه rule یک key قابل فهم در نظر بگیرید تا جست‌وجوی بعدی بر اساس هدف کنترل انجام شود. نامی مثل تغییر تنظیم ورود از نام مبهم test مفیدتر است. با این حال key فقط برچسب جست‌وجو است و صحت شرط را تضمین نمی‌کند. پس از تغییر، یک عملیات مجاز و یک عملیات ناموفق کنترل‌شده اجرا کنید و هر دو را مطابق انتظار بررسی کنید. اگر rule فقط موفقیت را ثبت می‌کند، باید این انتخاب آگاهانه باشد، نه نتیجه فراموشی شرط.
محدود کردن هزینه بدون از دست دادن شواهد
ثبت همه syscallهای همه فرایندها می‌تواند پرهزینه و پرنویز باشد. شرط‌های مرتبط با معماری، هویت، مسیر و نوع عملیات به محدود کردن دامنه کمک می‌کنند، اما نباید آن‌قدر تنگ باشند که راه‌های مهم تغییر را نبینند. برای نمونه، تغییر فایل فقط نوشتن مستقیم نیست؛ جایگزینی از طریق rename یا ایجاد فایل تازه نیز ممکن است در گردش کار واقعی رخ دهد. آزمون باید همان روش‌های مورد استفاده برنامه و ابزار مدیریتی را پوشش دهد.
حجم رخداد را در بار عادی و زمان عملیات سنگین اندازه بگیرید. ابزار مدیریت بسته، استقرار و پشتیبان‌گیری ممکن است ناگهان تعداد زیادی رخداد تولید کنند. ظرفیت صف و فضای log باید با این الگوها سازگار باشد. اگر رخداد از دست می‌رود، فقط پایین آوردن حساسیت ruleها راه‌حل نیست؛ مسیر مصرف، دیسک و انتقال نیز باید بررسی شود. شمارنده‌های از دست رفتن رخداد را بخشی از پایش سلامت خود Audit بدانید.
پر شدن دیسک یک تصمیم امنیتی است
رفتار هنگام کمبود فضا یا خطای نوشتن باید از قبل تعیین شود. ادامه سرویس بدون ثبت شواهد و توقف شدید سامانه هر دو پیامد دارند. انتخاب مناسب به حساسیت میزبان و نیاز دسترس‌پذیری وابسته است و باید به تأیید مالک سامانه برسد. تنظیمی که در آزمایشگاه مناسب است ممکن است روی سرویس حیاتی باعث قطعی غیرمنتظره شود. آستانه هشدار باید فرصت اقدام بدهد و مسیر پاک‌سازی یا انتقال کنترل‌شده از قبل مشخص باشد.
Log rotation را با حذف بی‌ردیابی یکی نگیرید. دوره نگهداری، مقصد آرشیو و کنترل دسترسی باید روشن باشند. فایل Audit می‌تواند نام کاربر، مسیر فایل و جزئیات فرمان داشته باشد؛ بنابراین خود آن داده حساس است. ارسال به مقصد مرکزی به حفظ شواهد در برابر خرابی میزبان کمک می‌کند، ولی نیازمند حفاظت مسیر و دسترسی مقصد است. در بررسی حادثه، نسخه اصلی را حفظ و تحلیل را روی کپی انجام دهید تا زنجیره شواهد مخدوش نشود.
جست‌وجو با ausearch و تفسیر محتاطانه
جست‌وجو را با بازه زمانی، key یا شناسه رخداد محدود کنید و سپس رکوردهای مرتبط را بخوانید. خروجی تفسیرشده برای انسان مفید است، اما نسخه خام را نیز نگه دارید؛ تفسیر نام‌ها ممکن است به وضعیت فعلی نگاشت حساب‌ها وابسته باشد. اگر پس از حادثه نام حساب یا فایل عوض شده، متن خواناتر همیشه تنها مرجع مناسب نیست. زمان سیستم، منطقه زمانی و اختلاف ساعت با سامانه‌های دیگر را در timeline لحاظ کنید.
نبود رخداد به تنهایی ثابت نمی‌کند عملی انجام نشده است. شاید rule در آن زمان فعال نبوده، رخداد حذف شده یا مسیر دیگری استفاده شده باشد. بنابراین برای ادعای منفی باید سلامت ثبت، دوره نگهداری و پوشش rule را نیز بررسی کنید. این اصل در پاسخ به سؤال مدیریتی مهم است: به جای گفتن «قطعاً هیچ تغییری نبوده»، می‌توان دقیق گفت در دامنه و بازه ثبت‌شده چه چیزی مشاهده شده و چه محدودیتی وجود دارد.
کنترل تغییر و حالت غیرقابل تغییر
برخی تنظیمات می‌توانند تغییر ruleها را تا راه‌اندازی بعدی محدود کنند. چنین حالتی برای حفاظت سیاست مفید است، اما باید پس از آزمون کامل فعال شود. اگر rule اشتباه یا بسیار پرحجم باشد، اصلاح آن در زمان اجرا ممکن است دیگر ساده نباشد. پنجره تغییر و مسیر بازیابی باید با نیاز عملیاتی هماهنگ باشند. فعال کردن سخت‌گیرانه‌ترین حالت بدون تمرین، الزاماً امنیت مؤثر بیشتری ایجاد نمی‌کند.
در پایان استقرار، reboot کنترل‌شده انجام دهید و نشان دهید ruleهای مورد انتظار دوباره فعال شده‌اند. سپس تغییر آزمایشی را تکرار و جست‌وجوی رخداد را به همکار دیگری واگذار کنید. اگر او بتواند عامل، زمان، هدف و نتیجه عمل را از شواهد استخراج کند، کنترل به هدف خود نزدیک شده است. معیار موفقیت تعداد ruleها یا حجم log نیست؛ توان پاسخ دقیق به پرسش امنیتی با هزینه قابل مدیریت است.
