لاگ ممیزی چیست و چگونه آن را دست‌نخورده نگه داریم؟

لاگ ممیزی چیست و چرا به آن نیاز دارید؟

لاگ ممیزی (Audit Log) رکوردی از رویدادهای مهم در سرور، پایگاه داده یا برنامه است که به شما نشان می‌دهد چه کسی، چه زمانی، از کجا و چه کاری انجام داده است. این لاگ‌ها با لاگ‌های معمولی سیستم (مثل syslog) تفاوت دارند؛ چون به‌صورت هدفمند برای پاسخ به سه سؤال طراحی می‌شوند: «آیا اتفاق بدی افتاده؟»، «چه کسی مقصر است؟» و «چطور باید جلوی تکرار آن را بگیرم؟».

بسیاری از مدیران سرور فقط به لاگ‌های خطا نگاه می‌کنند و فکر می‌کنند امنیت شان برقرار است. اما در یک حمله واقعی، مهاجم معمولاً ابتدا لاگ‌ها را پاک می‌کند تا ردپایی باقی نماند. اگر لاگ ممیزی شما روی همان سرور و با دسترسی root ذخیره شده باشد، عملاً بی‌فایده است. در این مقاله یاد می‌گیرید که چه رویدادهایی را ثبت کنید، لاگ‌ها را کجا نگه دارید و چطور مطمئن شوید کسی نمی‌تواند آن‌ها را تغییر دهد.

چه رویدادهایی را در لاگ ممیزی ثبت کنیم؟

ثبت همه‌چیز باعث می‌شود لاگ‌ها آن‌قدر حجیم شوند که نتوانید رویداد مهم را پیدا کنید. قانون طلایی این است: هر چیزی که برای بازسازی یک حادثه لازم است را ثبت کنید، نه بیشتر. در ادامه فهرستی از رویدادهای ضروری آمده است.

رویدادهای احراز هویت و دسترسی

• ورود موفق و ناموفق به سیستم (SSH، کنسول، پنل مدیریت)
• تغییر رمز عبور توسط کاربر یا مدیر
• ایجاد، حذف یا تغییر دسترسی کاربران و گروه‌ها
• استفاده از sudo یا su برای ارتقای سطح دسترسی
• اتصال به پایگاه داده با حساب‌های پرریسک (مثل root دیتابیس)

مثال: در لینوکس، دستور زیر را برای ثبت همه دستورات sudo در فایل جداگانه فعال کنید:

# /etc/sudoers.d/audit
Defaults logfile=/var/log/sudo-audit.log
Defaults log_input, log_output

با این تنظیم، هر دستوری که با sudo اجرا شود، همراه با خروجی آن ثبت می‌شود. این کار در تشخیص سوءاستفاده از دسترسی مدیریتی بسیار مؤثر است.

تغییرات پیکربندی و فایل‌های حیاتی

• تغییر در فایل‌های /etc/passwd، /etc/shadow و /etc/ssh/sshd_config
• نصب یا حذف بسته‌های نرم‌افزاری
• تغییر قوانین فایروال (iptables، nftables، ufw)
• تغییر در cron jobs یا systemd timers

برای رصد تغییرات فایل‌های حساس، از ابزار auditd استفاده کنید:

auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config_change
auditctl -w /etc/passwd -p wa -k user_db_change

پارامتر -p wa یعنی ثبت رویدادهای write و attribute change. برچسب -k هم به شما اجازه می‌دهد رویدادها را با ausearch -k sshd_config_change جستجو کنید.

رویدادهای شبکه و سرویس‌ها

• باز شدن پورت‌های جدید روی سرور
• اتصال‌های غیرعادی به پورت‌های حساس (مثل 3306 برای MySQL)
• راه‌اندازی یا متوقف شدن سرویس‌های حیاتی (nginx، apache، mysql)
• تلاش برای اتصال به آدرس‌های IP مشکوک (مثل شبکه‌های Tor یا IP های تحریمی)

برای ثبت اتصال‌های جدید، می‌توانید از ss به همراه cron استفاده کنید، اما روش حرفه‌ای‌تر استفاده از auditd برای رصد سوکت‌هاست:

auditctl -a always,exit -F arch=b64 -S bind -S connect -k network_connections

چطور لاگ ممیزی را دست‌نخورده نگه داریم؟

ثبت رویدادها فقط نیمی از کار است. اگر مهاجم بتواند لاگ‌ها را پاک کند، انگار هیچ اتفاقی نیفتاده است. در ادامه سه لایه محافظتی را توضیح می‌دهیم.

۱. ذخیره‌سازی خارج از سرور (Centralized Logging)

هرگز لاگ ممیزی را فقط روی همان سروری که رویدادها در آن رخ می‌دهند ذخیره نکنید. مهاجمی که root گرفته، می‌تواند rm -rf /var/log را اجرا کند و همه چیز را پاک کند. راه‌حل استاندارد، ارسال لاگ‌ها به یک سرور متمرکز است.

ساده‌ترین روش استفاده از rsyslog است. روی سرور متمرکز (مثلاً با IP 192.168.1.10)، خط زیر را به /etc/rsyslog.conf اضافه کنید:

# روی سرور متمرکز
module(load="imtcp")
input(type="imtcp" port="514")
$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogs

و روی سرورهای کلاینت:

# روی سرور کلاینت
*.* @@192.168.1.10:514

نکته مهم: سرور متمرکز باید دسترسی SSH را فقط از IP های مشخص بپذیرد و خودش هم لاگ‌هایش را به جای دیگری ارسال کند تا زنجیره امنیت قطع نشود.

۲. امضای دیجیتال و جلوگیری از تغییر (WORM Storage)

ارسال لاگ به سرور دیگر، مهاجم را متوقف نمی‌کند؛ چون اگر به آن سرور هم دسترسی پیدا کند، می‌تواند لاگ‌ها را تغییر دهد. راه‌حل قوی‌تر، استفاده از ذخیره‌سازی WORM (Write Once Read Many) است. در این روش، فایل لاگ فقط یک‌بار نوشته می‌شود و هیچ‌کس (حتی root) نمی‌تواند آن را تغییر دهد.

در لینوکس، می‌توانید از ویژگی chattr +a استفاده کنید که فقط اجازه append می‌دهد:

chattr +a /var/log/audit/audit.log

اما این روش هم کامل نیست؛ چون مهاجم می‌تواند فایل را حذف کند و دوباره بسازد. برای محافظت کامل، باید فایل را روی یک پارتیشن جدا با گزینه mount -o remount,ro قرار دهید یا از ابزارهایی مثل auditd با قابلیت max_log_file_action = keep_logs استفاده کنید.

روش حرفه‌ای‌تر، ارسال لاگ‌ها به یک سرویس ابری با قابلیت Object Lock است. سرویس‌هایی مثل S3 Object Lock یا Azure Immutable Blob Storage اجازه می‌دهند مدت زمان قفل (مثلاً ۱ سال) تعیین کنید. در این مدت، هیچ‌کس نمی‌تواند لاگ‌ها را حذف یا تغییر دهد. اگر از زیرساخت ابری استفاده می‌کنید، این گزینه را حتماً بررسی کنید.

۳. چرخش و نگهداری بلندمدت لاگ‌ها

لاگ ممیزی باید حداقل به اندازه دوره بازبینی امنیتی شما نگهداری شود. استانداردهای رایج مثل PCI-DSS به ۱ سال نگهداری و ۳ ماه دسترسی آنلاین نیاز دارند. برای چرخش خودکار لاگ‌ها از logrotate استفاده کنید:

# /etc/logrotate.d/audit
/var/log/audit/audit.log {
    weekly
    rotate 52
    compress
    delaycompress
    notifempty
    missingok
}

این تنظیم، لاگ‌ها را هفتگی می‌چرخاند و ۵۲ نسخه (یک سال) نگه می‌دارد. فایل‌های فشرده‌شده را هم می‌توانید به سرور متمرکز منتقل کنید.

اشتباهات رایج در نگهداری لاگ ممیزی

در ادامه چند اشتباه متداول را مرور می‌کنیم که معمولاً امنیت لاگ‌ها را از بین می‌برد.

اشتباه ۱: ذخیره لاگ‌ها روی همان پارتیشن سیستم

اگر /var/log روی پارتیشن root باشد، پر شدن دیسک می‌تواند کل سیستم را از کار بیندازد. مهاجم هم می‌تواند با پر کردن عمدی دیسک، سرویس‌ها را مختل کند. راه‌حل: پارتیشن جداگانه برای /var/log در نظر بگیرید و حجم آن را مانیتور کنید.

اشتباه ۲: ثبت نکردن تلاش‌های ناموفق

بسیاری از مدیران فقط رویدادهای موفق را ثبت می‌کنند. اما تلاش‌های ناموفق (مثل ورود با رمز اشتباه) نشانه‌های اولیه حمله brute-force هستند. در auditd، مطمئن شوید که رویدادهای USER_LOGIN با نتیجه failed هم ثبت می‌شوند:

auditctl -a always,exit -F arch=b64 -S execve -F success!=1 -k failed_commands

اشتباه ۳: نادیده گرفتن زمان‌بندی (Timestamp)

اگر ساعت سرور دقیق نباشد، بازسازی توالی رویدادها در یک حمله غیرممکن می‌شود. حتماً NTP را فعال کنید و از همگام‌سازی ساعت با یک منبع معتبر مطمئن شوید:

timedatectl set-ntp true
timedatectl status

چطور لاگ ممیزی را در پاسخ به حادثه استفاده کنیم؟

وقتی حادثه‌ای رخ می‌دهد، اولین کار این است که لاگ‌ها را قبل از هر اقدامی کپی کنید. اگر سرور را ریبوت کنید یا سرویس‌ها را متوقف کنید، ممکن است شواهد از بین بروند. مراحل پیشنهادی:

1. تصویربرداری از دیسک یا کپی از فایل‌های لاگ روی رسانه جداگانه
2. جستجوی رویدادهای مرتبط با حساب کاربری مهاجم: ausearch -ua username
3. بررسی اتصال‌های شبکه در زمان حادثه: ausearch -k network_connections -ts recent
4. مقایسه لاگ‌های سرور متمرکز با لاگ‌های محلی برای تشخیص دستکاری

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

ابزارهای کمکی برای مدیریت لاگ ممیزی

برای حجم بالای لاگ‌ها، ابزارهای زیر را در نظر بگیرید:

• auditd: ابزار استاندارد لینوکس برای ممیزی امنیتی
• rsyslog یا syslog-ng: برای انتقال متمرکز لاگ‌ها
• SIEM (مثل Wazuh یا Elastic Stack): برای تحلیل خودکار و هشداردهی
• logrotate: برای مدیریت حجم و چرخش فایل‌ها

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

جمع‌بندی

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

از همین امروز شروع کنید: ابتدا لیست رویدادهای حیاتی سرورتان را مشخص کنید، سپس ارسال لاگ به یک سرور متمرکز را راه‌اندازی کنید و در نهایت یک برنامه چرخش و نگهداری بلندمدت تنظیم کنید. این سه قدم ساده، امنیت شما را به شکل چشمگیری افزایش می‌دهد.