لینوکس ۳۰۳؛ شب ۲۳: auditd؛ چه کسی قفسه را عوض کرد؟
فهرست نوشته
فایل پیکربندی تغییر کرده است. timestamp می‌گوید چه زمانی، ولی چه کسی و از کدام نشست؟ با Linux Audit رد رویداد را ثبت می‌کنیم و تفاوت uid با هویت ورود را می‌خوانیم.
این جلسه بخشی از دورهٔ لینوکس ۳۰۳ در ۴۰ شب است.
محیط تمرین: Ubuntu 24.04 روی VM x86_64؛ auditd؛ sudo؛ پوشهٔ اختصاصی /srv/lpic303-audit.
جایگاه در دوره: هدف‌های 332.2 آزمون 303-300.
log برنامه و audit یک مأموریت ندارند#
برنامه ممکن است فقط خطای خودش را ثبت کند. Linux Audit از رویدادهای مرتبط در کرنل و فضای کاربر استفاده می‌کند. یک رخداد می‌تواند چند رکورد داشته باشد: SYSCALL، PATH و CWD با شناسهٔ رخداد مشترک به هم مربوط‌اند. بریدن فقط یک خط ممکن است زمینه را از بین ببرد.
sudo systemctl start auditd
sudo auditctl -s
sudo auditctl -l
sudo install -d -m 755 /srv/lpic303-audit
printf 'version=1\n' | sudo tee /srv/lpic303-audit/catalog.conf >/dev/null
در auditctl -s وضعیت enabled، PID daemon، backlog و lost را ثبت کن. اگر حالت immutable از قبل فعال است، rule را نمی‌توان بی‌وقفه تغییر داد؛ روی سیستم واقعی برای آن reboot نکن، Clone آموزشی را آماده کن.
یک rule کوچک و یک تغییر معلوم#
sudo auditctl -a always,exit -F arch=b64 \
-F path=/srv/lpic303-audit/catalog.conf -F perm=wa -k lpic303_catalog
printf 'version=2\n' | sudo tee /srv/lpic303-audit/catalog.conf >/dev/null
sudo ausearch -k lpic303_catalog -ts recent -i
sudo aureport --file --summary
معماری b64 در این تمرین x86_64 است؛ پوشش برنامه‌های ۳۲ بیتی در سیستم دارای آن‌ها rule متناظر می‌خواهد. wa نوشتن و تغییر attribute را انتخاب می‌کند. -k برچسب جست‌وجو است، نه رمز یا کلید رمزنگاری.
انتظار داریم مسیر فایل و موفقیت عملیات نوشتن دیده شود. uid و euid هویت زمان عملیات را می‌گویند؛ auid به هویت ورود مربوط است و می‌تواند نشست کاربر را حتی پس از sudo دنبال کند. مقدار unset یا محیط container را با حساب انسانی اشتباه نگیر.
ماندگاری و هزینه#
برای یک ماشین اختصاصی، rule بازبینی‌شده می‌تواند در /etc/audit/rules.d/lpic303.rules ذخیره و با augenrules --load بارگذاری شود؛ بعد از بارگذاری، auditctl -l را بررسی کن. روش قدیمی -w path -p wa را در جزوه و آزمون می‌بینی، اما ruleهای syscall با فیلتر محدود برای طراحی تازه مناسب‌ترند.
auditd.conf باید گردش فایل log، ظرفیت دیسک و رفتار پرشدن را مشخص کند. ثبت تمام syscallها، شاهد خوب را در حجم بی‌استفاده گم می‌کند. pam_tty_audit.so می‌تواند ورودی terminal را ثبت کند؛ اطلاعات حساس را وارد دامنهٔ ثبت می‌کند و نباید بی‌تحلیل برای همهٔ کاربران فعال شود.
برگشت و خودآزمایی#
برای حذف فقط rule تمرین، همان فرمان اضافه‌کردن را با -d always,exit و دقیقاً همان فیلترها اجرا کن. auditctl -D تمام ruleها را حذف می‌کند و راه برگشت این تمرین نیست.
یک تغییر با user معمولی و یکی با sudo انجام بده؛ auid و euid را مقایسه کن. اگر lost افزایش یافت، آیا می‌توانی ادعا کنی تمام رویدادها ثبت شده‌اند؟ نه؛ ظرفیت و نقص شواهد بخشی از گزارش‌اند.