پیکربندی Auditd در لینوکس: مانیتورینگ رویدادهای امنیتی و لاگ تغییرات فایل‌ها روی سرور اختصاصی و VPS

لاگ‌های پیش‌فرض لینوکس (syslog، journald) می‌گویند یک سرویس چه کرد، نه اینکه کدام کاربر، با کدام پردازه، چه فایلی را باز یا تغییر داد. وقتی سروری به خطر بیفتد، همین جای خالی باعث می‌شود نتوانید بفهمید مهاجم از کجا وارد شده و چه کاری انجام داده است.

Auditd زیرسیستم رسمی کرنل لینوکس برای ثبت رویدادهای امنیتی در همین سطح است: چه کسی چه فایلی را خواند یا نوشت، کدام فرآیند execve اجرا کرد، و چه کسی تلاش کرد سطح دسترسی خودش را بالا ببرد. در این مقاله پیکربندی auditd روی سرور اختصاصی و VPS لینوکسی را از نصب تا نوشتن قانون‌های file-watch و syscall و خوانش لاگ‌ها با ausearch قدم‌به‌قدم بررسی می‌کنیم.

Auditd چیست و چرا با syslog فرق دارد

Auditd یک دیمون سطح کاربر است که با زیرسیستم audit کرنل (kauditd) صحبت می‌کند. هر قانونی که تعریف کنید مستقیماً در کرنل فعال می‌شود؛ یعنی حتی اگر یک پردازه مخرب بخواهد لاگ خودش را دستکاری کند، نمی‌تواند رویدادی را که کرنل همان لحظه ثبت کرده پاک کند — مگر اینکه دسترسی روت کامل داشته باشد و دیمون را هم متوقف کند.

تفاوت اصلی با syslog/journald در سطح رصد است:

ویژگی	auditd	syslog / journald
منبع رویداد	مستقیماً از کرنل (syscall و فایل)	فقط چیزی که خود اپلیکیشن لاگ می‌کند
دقت هویت کاربر	UID، AUID (کاربر لاگین اصلی)، PID، فرمان کامل	معمولاً فقط نام سرویس
ردیابی فایل حساس	قانون -w روی هر مسیر دلخواه	وابسته به اینکه برنامه خودش لاگ بزند
ردیابی syscall (مثل setuid)	بله، مستقیم از کرنل	خیر
قابل دستکاری توسط کاربر عادی	خیر (نیاز به CAP_AUDIT_CONTROL)	بله، بسیاری از لاگ‌ها قابل حذفند

برای کارهایی مثل الزامات PCI-DSS، ISO 27001 یا بررسی حادثهٔ امنیتی (Incident Response)، همین سطح جزئیات است که auditd را از ابزارهای لاگ معمولی جدا می‌کند.

auditd کاری متفاوت از مانیتورینگ عملکرد سرور با Prometheus و Grafana انجام می‌دهد: آن ابزارها CPU، RAM و I/O را رصد می‌کنند، auditd رویدادهای امنیتی در سطح کاربر و فایل را ثبت می‌کند.

نصب Auditd روی توزیع‌های رایج

روی سرورهای مبتنی بر Debian/Ubuntu:

sudo apt update
sudo apt install -y auditd audispd-plugins
sudo systemctl enable --now auditd

روی RHEL/CentOS/Rocky Linux، auditd معمولاً از قبل نصب است؛ اگر نبود:

sudo dnf install -y audit audit-libs
sudo systemctl enable --now auditd

برای اطمینان از اینکه دیمون در حال اجراست:

sudo systemctl status auditd
sudo auditctl -s

خروجی auditctl -s وضعیت فعلی (enabled، pid، rate limit و تعداد قوانین بارگذاری‌شده) را نشان می‌دهد. اگر enabled برابر صفر بود، یعنی قانونی بارگذاری نشده یا دیمون به درستی بالا نیامده است.

فایل‌های پیکربندی اصلی

دو فایل محور کار با auditd هستند:

• /etc/audit/auditd.conf — تنظیمات خود دیمون (محل ذخیرهٔ لاگ، حداکثر حجم، رفتار هنگام پر شدن دیسک).
• /etc/audit/rules.d/*.rules — قانون‌های audit که با augenrules کامپایل و در /etc/audit/audit.rules نهایی می‌شوند.

چند تنظیم مهم در auditd.conf که روی VPS و سرور اختصاصی باید حتماً بررسی شود:

log_file = /var/log/audit/audit.log
max_log_file = 50
num_logs = 10
max_log_file_action = ROTATE
space_left_action = EMAIL
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND

روی VPS با دیسک محدود، max_log_file و num_logs را متناسب با فضای واقعی تنظیم کنید؛ در غیر این صورت لاگ‌های audit می‌توانند دیسک را پر کنند. disk_full_action=SUSPEND باعث می‌شود در صورت پر شدن دیسک، سیستم خاموش نشود (رفتار پیش‌فرض سخت‌گیرانه‌تر HALT است که برای محیط عملیاتی معمولاً مناسب نیست، مگر در سرورهایی با الزام سخت‌گیرانهٔ compliance).

پس از هر تغییر در فایل‌های .rules، باید قوانین را بازسازی و بارگذاری کنید:

sudo augenrules --load
sudo systemctl restart auditd

نوشتن قانون‌های File-Watch برای فایل‌های حساس

قانون‌های -w مشخص می‌کنند کرنل روی کدام فایل یا دایرکتوری نظارت کند. ساختار کلی:

-w <مسیر> -p <permissions> -k <key>

permissions می‌تواند ترکیبی از r (خواندن)، w (نوشتن)، x (اجرا) و a (تغییر attribute) باشد. key یک برچسب دلخواه است که بعداً با ausearch -k فیلتر می‌کنید.

نمونه‌ای از قانون‌هایی که روی هر سرور لینوکسی باید باشند (در /etc/audit/rules.d/hardening.rules):

-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/sudoers -p wa -k privilege_escalation
-w /etc/sudoers.d/ -p wa -k privilege_escalation
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /etc/crontab -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

قانون sshd_config فقط تغییر فایل تنظیمات را می‌بیند؛ برای سخت‌سازی خود دسترسی SSH (کلید به‌جای رمز عبور، fail2ban و تنظیمات sshd_config) به امن‌سازی دسترسی SSH به سرور لینوکس مراجعه کنید.

این قانون‌ها فقط وقتی رویداد ثبت می‌کنند که فایل نوشته (w) یا attribute آن تغییر کند (a)؛ خواندن صرف این فایل‌ها لاگ تولید نمی‌کند، چیزی که معمولاً برای کاهش حجم لاگ ترجیح داده می‌شود. اگر نیاز به رصد خواندن هم دارید (مثلاً دسترسی غیرمجاز به کلید خصوصی)، r را هم اضافه کنید:

-w /etc/ssl/private/ -p rwa -k tls_keys

قانون‌های Syscall برای شناسایی Privilege Escalation

قانون‌های -a به سطح سیستم‌کال می‌روند و قدرت واقعی auditd را نشان می‌دهند. ساختار کلی:

-a always,exit -F arch=b64 -S <syscall> -F <فیلتر> -k <key>

برای شناسایی تلاش برای تغییر UID/GID (نشانهٔ کلاسیک privilege escalation):

-a always,exit -F arch=b64 -S setuid -S setgid -S setreuid -S setregid -k privilege_escalation
-a always,exit -F arch=b32 -S setuid -S setgid -S setreuid -S setregid -k privilege_escalation

هر دو معماری (b64 و b32) باید جدا تعریف شوند، چون روی سیستم‌های ۶۴ بیتی باینری‌های ۳۲ بیتی هم می‌توانند اجرا شوند و شماره‌ی syscall بین دو معماری متفاوت است.

برای ثبت هر فرمانی که با sudo اجرا می‌شود (با دقت در حد خود فرمان، نه فقط نام باینری):

-a always,exit -F arch=b64 -S execve -F path=/usr/bin/sudo -k sudo_usage
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/su -k sudo_usage

برای شناسایی تغییر مستقیم ownership یا permission فایل‌ها توسط هر کاربری غیر از root:

-a always,exit -F arch=b64 -S chmod -S fchmod -S chown -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_mod

فیلتر auid>=1000 باعث می‌شود رویدادهای مربوط به کاربران سیستمی (UID زیر ۱۰۰۰) نادیده گرفته شوند و حجم لاگ معقول بماند؛ auid!=4294967295 هم رویدادهایی را که AUID تنظیم نشده (مثل پردازه‌های اولیهٔ بوت) حذف می‌کند.

در انتهای فایل قوانین، یک قانون مهم برای سخت‌سازی:

-e 2

این خط auditd را در حالت immutable می‌گذارد؛ یعنی بعد از بوت، حتی روت هم نمی‌تواند قانون‌ها را تا ریبوت بعدی تغییر دهد یا حذف کند — فقط از طریق تغییر فایل و ریبوت امکان‌پذیر است. روی سروری که نگرانی اصلی‌تان یک مهاجم با دسترسی موقت روت است، این خط همان چیزی است که جلوی خاموش‌کردن audit را می‌گیرد.

خوانش لاگ‌ها با ausearch و aureport

لاگ خام /var/log/audit/audit.log قابل خوانش مستقیم است اما برای جستجو بهتر است از ausearch استفاده کنید.

جستجوی همهٔ رویدادهای یک کلید مشخص در یک بازهٔ زمانی:

sudo ausearch -k privilege_escalation --start today

جستجوی رویدادهای مربوط به یک کاربر خاص:

sudo ausearch -ua 1001 --start recent

تبدیل خروجی خام به شکل قابل‌خوانش‌تر با تفسیر مقادیر عددی (UID → نام کاربر، syscall → نام):

sudo ausearch -k identity -i

برای گزارش خلاصه‌شده به‌جای رویداد خام، aureport مناسب‌تر است:

sudo aureport -au --summary        # خلاصهٔ ورود/خروج کاربران
sudo aureport -f --summary         # خلاصهٔ تغییرات فایل

در یک بررسی واقعی حادثه، روتین معمول این است: ابتدا با aureport -au بازهٔ زمانی ورود مشکوک را پیدا کنید، سپس با ausearch -ts <زمان> -te <زمان> همهٔ رویدادهای همان بازه را بیرون بکشید و با کلیدهای تعریف‌شده (identity، privilege_escalation، sudo_usage) فیلتر کنید.

نکات عملکرد و نگهداری روی VPS و سرور اختصاصی

قانون‌های زیاد syscall روی سروری با I/O محدود (بیشتر پلن‌های VPS ورودی) می‌توانند overhead قابل‌توجهی ایجاد کنند، چون هر فراخوانی syscall باید از فیلترهای audit عبور کند. چند نکتهٔ عملی:

• فقط syscall‌هایی را رصد کنید که واقعاً به سناریوی تهدید شما مربوط است؛ رصد کورکورانهٔ همهٔ syscallها (-a always,exit -S all) روی یک VPS معمولی قابل استفاده نیست.
• از فیلتر -F auid>=1000 برای حذف نویز پردازه‌های سیستمی استفاده کنید.
• فضای /var/log/audit را جدا از پارتیشن اصلی در نظر بگیرید تا رشد لاگ روی سرویس‌های دیگر اثر نگذارد؛ روی سرور اختصاصی که دیسک NVMe اختصاصی دارید این کار ساده‌تر از VPS با دیسک مشترک است.
• خروجی auditd را با rsyslog یا یک agent (مثل Wazuh یا یک شیپر Elastic) به یک سیستم متمرکز ارسال کنید؛ نگه‌داشتن تنها نسخهٔ لوکال لاگ روی همان سروری که ممکن است به خطر بیفتد، ریسک از بین رفتن مدرک را بالا می‌برد. راه‌اندازی سیستم لاگ متمرکز با Grafana Loki و Alloy یک مسیر عملی برای همین کار است.
• کار auditd با کار فایروال فرق دارد: فایروال از ورود ترافیک ناخواسته جلوگیری می‌کند، auditd آنچه را که از پشت فایروال رد شده ثبت می‌کند. برای تنظیم خود فایروال به راه‌اندازی فایروال nftables روی سرور لینوکس نگاه کنید.

جمع‌بندی

پیکربندی auditd سه بخش دارد که باید با هم کار کنند: تنظیمات دیمون در auditd.conf برای رفتار درست هنگام پر شدن دیسک، قانون‌های -w برای رصد فایل‌های حساس مثل /etc/passwd و /etc/sudoers، و قانون‌های -a روی سطح syscall برای گرفتن تلاش‌های تغییر UID و privilege escalation. بدون این لایه، لاگ‌های پیش‌فرض لینوکس جواب سوال «دقیقاً چه کسی این کار را کرد» را نمی‌دهند. auditd بخشی از یک استراتژی بزرگ‌تر سخت‌سازی سرور است؛ برای دیدن بقیهٔ لایه‌ها افزایش امنیت سرور لینوکس را ببینید.

اگر این قانون‌ها را روی زیرساختی با دیسک و I/O محدود پیاده کنید، همان overhead قانون‌های syscall زودتر حس می‌شود. روی سرویس سرور ابری آریانت با دیسک NVMe اختصاصی و شبکهٔ پایدار، همین قانون‌های auditd را می‌توانید بدون نگرانی از افت کارایی روی دیسک‌های اشتراکی اجرا کنید؛ برای حجم‌های بالاتر یا الزامات سخت‌گیرانهٔ compliance، سرور اختصاصی گزینهٔ مناسب‌تری است.