چک‌لیست اولیه امن‌سازی سرور Linux

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

۱. نقش و سطح دسترسی سرور را مشخص کنید

پیش از تغییر تنظیمات، معلوم کنید سرور چه خدمتی ارائه می‌دهد، چه کسانی مالک آن هستند و از کدام شبکه‌ها باید قابل دسترس باشد. سرور وب عمومی، پایگاه داده داخلی و ماشین مانیتورینگ مدل تهدید یکسانی ندارند.

فهرست حداقلی شامل این موارد است:

• سرویس‌های موردنیاز و پورت‌های ضروری؛
• کاربران انسانی و حساب‌های سرویس؛
• وابستگی‌ها مانند پایگاه داده، DNS یا ذخیره‌سازی؛
• سطح حساسیت داده؛
• هدف زمانی بازیابی و محل Backup.

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

۲. به‌روزرسانی و منبع بسته‌ها

سیستم‌عامل و بسته‌ها را از مخزن معتبر دریافت کنید. Repositoryهای آزمایشی یا اسکریپت‌های نصب ناشناس می‌توانند زنجیره تأمین را ضعیف کنند. به‌روزرسانی امنیتی باید برنامه مشخص داشته باشد، اما روی سرویس حیاتی ابتدا در محیط آزمایش یا بازه نگهداری کنترل‌شده اجرا شود.

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

۳. دسترسی SSH را محدود کنید

ورود مستقیم root را غیرفعال و برای مدیریت از حساب‌های نام‌دار با sudo استفاده کنید. کلید SSH نسبت به رمز عبور مقاومت بیشتری در برابر حدس‌زدن دارد، به‌شرط آنکه کلید خصوصی به‌درستی محافظت شود.

موارد پایه:

• PermitRootLogin no؛
• غیرفعال‌کردن Password Authentication پس از اطمینان از دسترسی کلیدی؛
• محدودکردن کاربران یا گروه‌های مجاز؛
• محدودکردن مبدأ دسترسی مدیریتی در Firewall؛
• ثبت و بازبینی تلاش‌های ورود ناموفق.

تغییر پورت SSH به‌تنهایی کنترل امنیتی محسوب نمی‌شود؛ فقط ممکن است بخشی از نویز اسکن خودکار را کم کند.

۴. Firewall را با سیاست حداقل دسترسی تنظیم کنید

سیاست ورودی پیش‌فرض باید Deny باشد و فقط پورت‌های لازم باز شوند. اگر پایگاه داده فقط توسط Application Server مصرف می‌شود، نباید از کل شبکه یا اینترنت قابل دسترس باشد. محدودیت مبدأ اغلب به‌اندازه محدودیت پورت اهمیت دارد.

قوانین Firewall را مستند کنید: هر Rule باید مالک، دلیل و تاریخ بازبینی داشته باشد. Rule موقتی بدون تاریخ پایان معمولاً دائمی می‌شود.

۵. حساب‌ها و مجوز فایل‌ها را بازبینی کنید

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

SUID/SGIDهای غیرمنتظره، فایل‌های بدون مالک و مسیرهای قابل‌نوشتن عمومی را نیز در بازبینی دوره‌ای قرار دهید.

۶. ثبت رخداد و مانیتورینگ را قبل از حادثه آماده کنید

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

حداقل این رویدادها را قابل مشاهده کنید:

• ورود موفق و ناموفق؛
• استفاده از sudo و تغییر حساب‌ها؛
• توقف سرویس‌های اصلی؛
• تغییرات مهم تنظیمات؛
• پرشدن دیسک و خطاهای فایل‌سیستم؛
• تغییر وضعیت Firewall یا سرویس SSH.

۷. Backup را با Restore بسنجید

وجود فایل Backup کافی نیست. بازیابی باید آزمایش شود و مشخص باشد چه کسی، در چه زمانی و روی چه زیرساختی آن را انجام می‌دهد. کلیدهای رمزنگاری و تنظیمات سرویس‌ها نیز بخشی از برنامه بازیابی هستند.

نسخه پشتیبان متصل و همیشه در دسترس همان سطح ریسک سرور اصلی را دارد. جداسازی، کنترل دسترسی و در صورت نیاز نسخه خارج از سایت را در نظر بگیرید.

۸. یک Baseline قابل تکرار بسازید

پس از تأیید تنظیمات، آن‌ها را مستند و تا حد ممکن با ابزار مدیریت پیکربندی قابل تکرار کنید. Baseline باید نسخه سیستم‌عامل، سرویس‌های مجاز، قوانین Firewall، تنظیمات SSH، حساب‌های مدیریتی و کنترل‌های مانیتورینگ را پوشش دهد.

امن‌سازی یک فعالیت یک‌باره نیست. تغییر نقش سرور، نصب سرویس جدید یا انتشار آسیب‌پذیری مهم می‌تواند Baseline را نیازمند بازبینی کند. هدف این است که وضعیت امن، قابل توضیح و قابل بازیابی باشد؛ نه اینکه مجموعه‌ای از تنظیمات نامعلوم صرفاً روی یک سرور اجرا شده باشد.