لاگ امنیتی لینوکس؛ تاریخچهٔ مفید با سقف مصرف دیسک

شواهد موردنیاز را مشخص کنید

این راهنما برای میزبان لینوکس دارای systemd-journald است. از سؤال حادثه شروع کنید: آیا می‌توانید ورود ناموفق، راه‌اندازی سرویس و خطای غیرمنتظره را بازسازی کنید؟ جدول پیشنهادی ما سرویس، مسئول بازبینی، مجوز دسترسی و بازهٔ لازم بررسی را مشخص می‌کند. لاگ ممکن است نام حساب یا جزئیات برنامه داشته باشد؛ دسترسی بازبین را متناسب نگه دارید.

تاریخچه و مصرف دیسک را ببینید

مرجع journalctl بررسی تاریخچه و فضای ذخیره را توضیح می‌دهد. فرمان‌ها دادهٔ موجود را می‌خوانند؛ ssh.service را با نام واقعی سرویس توزیع خود عوض کنید:

sudo journalctl --disk-usage
sudo journalctl --list-boots
sudo journalctl -u ssh.service --since "24 hours ago" --no-pager

وجود بوت‌های قبلی و رویداد احراز هویت مورد انتظار را بررسی کنید. نبود رویداد شاید یعنی در جای دیگری ثبت شده، نه اینکه هرگز اتفاق نیفتاده است. خط زمانی بررسی را از منطقهٔ زمانی نمایش محلی دستگاه جدا نگه دارید.

ماندگاری و بودجهٔ فضا را انتخاب کنید

مستندات سرویس journal ذخیرهٔ موقت /run را از تاریخچهٔ ماندگار /var/log/journal جدا می‌کند. پس از بررسی نسخهٔ نصب‌شده و فضای آزاد، فایل محلی مانند /etc/systemd/journald.conf.d/60-retention.conf می‌تواند شامل این نمونه باشد:

[Journal]
Storage=persistent
SystemMaxUse=500M
SystemKeepFree=1G

این اعداد نمونه‌اند و تعداد روز تضمین‌شده نمی‌دهند. مرجع پیکربندی تعامل حدها و دلیل تفاوت اندازهٔ واقعی با هدف را توضیح می‌دهد. حجم رویداد را تخمین بزنید و مقدار متناسب با میزبان را انتخاب کنید.

تغییر را با بررسی اعمال کنید

تنظیم قبلی را ذخیره کنید. در فرصت نگهداری توافق‌شده، سرویس journal را با عملیات restart مستند، نه توقف و شروع جدا، دوباره راه بیندازید و سپس داده را به ذخیرهٔ ماندگار flush کنید. سلامت سرویس، رکورد تازه و مصرف دیسک را بررسی کنید. صرفاً برای این آموزش سرور واقعی را ریبوت نکنید؛ پس از راه‌اندازی برنامه‌ریزی‌شدهٔ بعدی، دسترسی بوت قبل را بسنجید.

نگهداری عادی را از حفظ شواهد جدا کنید

محدودیت فضا در نهایت تاریخچهٔ قدیمی را حذف می‌کند. هنگام بررسی حادثه، پیش از پاک‌سازی، شواهد مرتبط را در مقصد محافظت‌شده حفظ کنید. با دیدن افزایش مصرف فوراً فرمان vacuum نزنید. نیاز به جمع‌آوری بیرونی را جدا تعیین کنید؛ لاگ محلی به‌تنهایی شاید از نابودی میزبان یا نفوذ به مدیر جان سالم نبرد. این کار را با تمرین بازیابی و بررسی مصرف‌کنندهٔ لاگ SSH تکمیل کنید و نتیجه را ثبت کنید.