چکلیست اولیه سختسازی سرور لینوکسی
چکلیستی کاربردی برای شروع سختسازی سرور لینوکسی با تمرکز بر SSH، فایروال، SELinux، دسترسیها، لاگ، بروزرسانی و پایش.
سختسازی سرور لینوکسی یک اقدام یکمرحلهای یا صرفاً تغییر پورت SSH نیست. سختسازی درست یعنی کاهش سطح حمله، کنترل دسترسیها، محدودسازی سرویسهای غیرضروری، فعالسازی لاگ و پایش، و آمادهسازی سرور برای نگهداری امن در طول زمان.
این چکلیست برای شروع ارزیابی و سختسازی اولیه سرورهای لینوکسی تهیه شده است و میتواند برای سرورهای وب، سرورهای زیرساختی، سرورهای مانیتورینگ، سرورهای دیتابیس و سرویسهای داخلی سازمان مورد استفاده قرار گیرد.
۱. شناسایی نقش سرور و سطح Exposure
قبل از هر تغییر امنیتی، باید مشخص شود سرور چه نقشی دارد و از کجا قابل دسترسی است. سروری که مستقیماً از اینترنت در دسترس است، نیازمند کنترلهای سختگیرانهتری نسبت به یک سرور داخلی است.
- نقش سرور مشخص شود: Web، Database، Mail، Monitoring، Backup یا سرویس داخلی.
- پورتهای باز و سرویسهای فعال بررسی شوند.
- مسیرهای دسترسی مدیریتی مشخص شود.
- دسترسی مستقیم اینترنتی فقط در صورت نیاز واقعی مجاز باشد.
- سرورهای حساس پشت Firewall، Reverse Proxy یا شبکه مدیریتی قرار گیرند.
۲. مدیریت بروزرسانیها و بستههای نصبشده
بروزرسانی سیستمعامل و بستهها یکی از پایهایترین کنترلهای امنیتی است. با این حال، در محیط سازمانی باید بروزرسانیها کنترلشده، زمانبندیشده و قابل بازگشت باشند.
- Repositoryهای غیرضروری یا نامعتبر حذف شوند.
- بستههای غیرضروری از سرور پاک شوند.
- سیاست بروزرسانی امنیتی تعریف شود.
- قبل از بروزرسانی سرویسهای حساس، Snapshot یا Backup تهیه شود.
- نسخه کرنل، سرویسها و بستههای حیاتی مستند شود.
۳. سختسازی SSH
SSH معمولاً یکی از مهمترین مسیرهای مدیریت سرور است و ضعف در تنظیمات آن میتواند ریسک بزرگی ایجاد کند. هدف، حذف دسترسیهای غیرضروری و محدودسازی ورود مدیریتی است.
- ورود مستقیم Root غیرفعال شود.
- احراز هویت مبتنی بر کلید برای کاربران مدیریتی فعال شود.
- تعداد تلاش ناموفق ورود محدود شود.
- کاربران مجاز برای SSH مشخص و محدود شوند.
- در صورت نیاز، دسترسی SSH فقط از IPهای مدیریتی مجاز شود.
- Fail2ban یا مکانیزم مشابه برای کنترل Brute Force فعال شود.
۴. فایروال و کنترل پورتها
اصل پایه در فایروال سرور این است که فقط پورتهای موردنیاز سرویس فعال باشند و سایر دسترسیها بسته بمانند. فایروال باید با نقش سرور و معماری شبکه هماهنگ باشد.
- فقط پورتهای ضروری باز باشند.
- پورتهای مدیریتی از شبکه یا IP مشخص محدود شوند.
- Ruleهای فایروال مستند شوند.
- دسترسی بین سرورها بر اساس نیاز واقعی تعریف شود.
- تغییرات فایروال قبل و بعد از اجرا تست شوند.
۵. کنترل کاربران، دسترسیها و Sudo
مدیریت کاربران یکی از نقاط کلیدی سختسازی است. حسابهای اضافه، دسترسیهای بیش از حد و نبود سیاست مشخص برای Sudo میتواند امنیت سرور را تضعیف کند.
- کاربران غیرضروری حذف یا غیرفعال شوند.
- برای هر مدیر، حساب کاربری جداگانه تعریف شود.
- دسترسی Sudo فقط به کاربران لازم داده شود.
- استفاده از حسابهای مشترک مدیریتی محدود شود.
- دسترسی فایلها و دایرکتوریهای حساس بازبینی شود.
۶. SELinux و کنترلهای امنیتی سیستمعامل
در توزیعهایی مانند AlmaLinux و RHEL، فعال بودن SELinux میتواند لایه دفاعی مهمی ایجاد کند. غیرفعال کردن SELinux برای حل سریع مشکلات، معمولاً تصمیم مناسبی برای محیطهای حساس نیست.
- وضعیت SELinux بررسی و ترجیحاً در حالت Enforcing نگه داشته شود.
- Context فایلها و سرویسها اصلاح شود، نه اینکه SELinux غیرفعال شود.
- Audit Logهای مرتبط با SELinux بررسی شوند.
- Exceptionها مستند و محدود باشند.
۷. لاگ، پایش و هشدار
سروری که لاگ و پایش مناسبی ندارد، حتی اگر سختسازی شده باشد، در زمان رخداد دید کافی در اختیار تیم فنی قرار نمیدهد. لاگ و مانیتورینگ باید از ابتدا بخشی از طراحی امنیتی باشند.
- لاگ سرویسهای حیاتی فعال و قابل بررسی باشد.
- لاگهای امنیتی مانند SSH، Firewall و SELinux جمعآوری شوند.
- برای سرویسهای مهم، مانیتورینگ و هشدار تعریف شود.
- وضعیت Disk، CPU، RAM، سرویسها و Certificateها پایش شود.
- در صورت امکان، لاگها به سرور مرکزی Log Management ارسال شوند.
۸. Backup و قابلیت بازیابی
امنیت بدون Backup قابل اتکا ناقص است. هدف Backup فقط داشتن یک نسخه از داده نیست؛ بلکه باید بازیابی نیز تست شده باشد.
- از تنظیمات، دادهها و فایلهای حیاتی Backup تهیه شود.
- Backupها از خود سرور جدا نگهداری شوند.
- دسترسی به Backup محدود و کنترلشده باشد.
- فرآیند Restore بهصورت دورهای تست شود.
- نسخههای Backup و زمان نگهداری آنها مشخص باشد.
۹. مستندسازی تغییرات
یکی از تفاوتهای کار حرفهای با تغییرات مقطعی، مستندسازی است. هر تغییر امنیتی باید قابل پیگیری، قابل بازبینی و قابل انتقال به تیم پشتیبانی باشد.
- وضعیت اولیه سرور قبل از سختسازی ثبت شود.
- تغییرات انجامشده و دلیل هر تغییر مستند شود.
- پورتها، سرویسها، کاربران و Ruleها ثبت شوند.
- سناریوی Rollback برای تغییرات حساس مشخص شود.
- چکلیست نهایی تحویل یا نگهداری تهیه شود.
جمعبندی
سختسازی سرور لینوکسی یک فرآیند مستمر است، نه یک اقدام یکباره. ترکیب تنظیمات امن، کنترل دسترسی، فایروال، SELinux، لاگ، مانیتورینگ، Backup و مستندسازی میتواند ریسکهای عملیاتی و امنیتی سرور را بهصورت قابل توجه کاهش دهد.
NexusGuard در پروژههای سختسازی، ابتدا وضعیت موجود را بررسی میکند، سپس اصلاحات را بر اساس نقش سرور، حساسیت سرویس و معماری شبکه بهصورت مرحلهای اجرا و مستند میکند.