مقاله 05 / امنیت زیرساخت
امنیت سرور اوبونتو؛ چک‌لیست سخت‌سازی بدون قطع دسترسی
مشخصات پیشنهادی انتشار
- عنوان سئو
- امنیت سرور اوبونتو؛ چک‌لیست سخت‌سازی | نگهبان وب
- توضیح متا
- امنیت سرور اوبونتو را با دسترسی محدود، SSH، پورت‌های ضروری، به‌روزرسانی و مدیریت رازها تقویت کنید؛ همراه با چک‌لیست بررسی و روش بازگشت.
- مسیر پیشنهادی
- /blog/ubuntu-server-hardening
- عبارت اصلی
- امنیت سرور اوبونتو
- تصویر
- ubuntu-server-hardening.webp
- یادداشت انتشار
- تصویر را در CMS بارگذاری و تاریخ واقعی انتشار و URL تصویر را ثبت کنید.
سخت‌سازی سرور اوبونتو مجموعه‌ای از تصمیم‌های به‌هم‌پیوسته درباره دسترسی، سرویس‌های در معرض اینترنت، به‌روزرسانی و بازیابی است. نصب یک ابزار یا تغییر پورت SSH به‌تنهایی امنیت ایجاد نمی‌کند. باید بدانید چه کسی به چه چیزی دسترسی دارد و اگر تغییری اشتباه شد، چگونه برمی‌گردید.
اولویت این راهنما سرورهای تحت مالکیت یا مدیریت مجاز شماست. پیش از تغییر تنظیمات ورود یا firewall، دسترسی جایگزین از کنسول ارائه‌دهنده و امکان بازیابی را بررسی کنید. این احتیاط بخشی از اجرای درست تغییر است، چون قطع شدن دسترسی مدیر خود می‌تواند به اختلال تبدیل شود.
سیستم‌عامل، سرویس‌های فعال، دامنه‌ها، حساب‌ها، کلیدهای SSH و یکپارچگی‌های CI/CD را فهرست کنید. برای هر دسترسی، مالک و کاربرد بنویسید. حسابی که معلوم نیست متعلق به چه کسی است یا چرا لازم است، نیازمند بررسی است.
خروجی این مرحله باید یک نقشه قابل استفاده باشد، نه صرفاً فهرست ابزارها. مثلاً مشخص شود runner انتشار با چه هویتی وصل می‌شود و آیا می‌تواند دیتابیس را حذف کند. محدود کردن دسترسی باید براساس کار واقعی صورت بگیرد تا فرایندهای ضروری را نشکند.
ورود SSH را مرحله‌ای اصلاح کنید
برای مدیران حساب شخصی و دسترسی متناسب تعریف کنید. احراز هویت کلیدی را راه‌اندازی و در یک نشست جدید آزمایش کنید؛ نشست فعلی را تا پایان بررسی باز نگه دارید. سپس درباره محدودیت ورود مستقیم root و روش‌های احراز هویت تصمیم بگیرید.
اوبونتو از فایل اصلی تنظیمات و فایل‌های تکمیلی استفاده می‌کند؛ ترتیب خواندن آن‌ها مهم است. پیش از اعمال تغییر، پیکربندی مؤثر و صحت نحوی را بررسی کنید. فرمان‌های زیر فقط بررسی انجام می‌دهند:
sudo sshd -t
sudo sshd -Tخروجی فرمان دوم همه شرایط مخصوص هر کاربر و آدرس را لزوماً بازنمایی نمی‌کند؛ پیکربندی دارای Match نیاز به بررسی سناریوی مربوط دارد. تغییر پورت می‌تواند نویز اسکن‌های معمول را کم کند، اما جای کلید امن، کنترل دسترسی و وصله امنیتی را نمی‌گیرد.
فقط پورت‌های موردنیاز را در دسترس بگذارید
ابتدا سرویس‌های در حال گوش دادن را ببینید و آن‌ها را با معماری مقایسه کنید. دیتابیس، پنل مدیریت و exporterهای مانیتورینگ الزاماً نباید از اینترنت عمومی قابل دسترسی باشند. محدودیت‌ها را در لایه میزبان و در صورت نیاز در firewall ابری بررسی کنید.
در سرور دارای Docker، انتشار پورت کانتینر و قواعد شبکه نیازمند توجه مستقل است. تصور نکنید صرف فعال بودن UFW به معنی بسته بودن تمام پورت‌های منتشرشده است. نتیجه را از یک مبدأ مجاز بیرونی و شبکه داخلی آزمایش کنید و مسیرهای لازم برنامه را ثبت کنید.
به‌روزرسانی با برنامه انجام شود
فهرست بسته‌ها و نسخه‌های پشتیبانی‌شده را نگه دارید. برای تغییرات مهم، پنجره اجرا، آزمون سلامت و راه برگشت تعریف کنید. خودکار کردن وصله‌ها می‌تواند مفید باشد، اما باید معلوم باشد کدام تغییرها خودکارند و چه زمانی نیاز به reboot وجود دارد.
پشتیبانی سیستم‌عامل فقط بخشی از موضوع است. وابستگی برنامه، image کانتینر و افزونه‌ها نیز به چرخه به‌روزرسانی نیاز دارند. اسکن آسیب‌پذیری برای اولویت‌بندی کمک می‌کند؛ عدد خروجی اسکن به‌تنهایی نشان نمی‌دهد یک ضعف در معماری شما قابل بهره‌برداری است یا اصلاح شده است.
secrets را از کد و لاگ جدا کنید
رمز، توکن و کلید خصوصی را در مخزن یا پیام تیکت قرار ندهید. دسترسی هر سرویس را به نیاز خودش محدود کنید و راه لغو و چرخش کلید را مستند کنید. هنگام خروج یک همکار، فقط حساب پنل را نبندید؛ کلیدهای سرور و مسیرهای انتشار او را هم بازبینی کنید.
اگر رازی قبلاً منتشر شده است، حذف آن از آخرین نسخه فایل کافی نیست. باید اعتبار آن لغو یا تعویض شود و محل‌های احتمالی استفاده بررسی شوند. برای نگهداری امن اطلاعات می‌توان از امکانات مدیریت راز متناسب با اندازه تیم استفاده کرد؛ پیچیدگی ابزار باید قابل نگهداری بماند.
بکاپ و ثبت رخداد را کنار امنیت قرار دهید
پیشگیری کامل تضمین‌پذیر نیست، بنابراین بازیابی بخشی از طراحی امنیت است. نسخه مستقل و آزموده‌شده نگه دارید و دسترسی حذف بکاپ را محدود کنید. لاگ‌های ضروری را با دوره نگهداری مناسب ثبت کنید، بدون آنکه داده حساس غیرضروری ذخیره شود.
خدمت سخت‌سازی زیرساخت باید خروجی مشخص داشته باشد: یافته، اولویت، تغییر اجراشده و روش تأیید. گزارش «همه‌چیز امن شد» معیار تحویل مناسبی نیست. برای بخش بازیابی نیز راهنمای بکاپ را ببینید.
پرسش‌های رایج
آیا Fail2ban جای firewall را می‌گیرد؟
خیر. نقش آن با محدود کردن سطح دسترسی شبکه متفاوت است. تنظیم هر دو باید با نیاز و لاگ‌های سرویس هماهنگ باشد.
آیا بعد از اسکن بدون یافته، سرور کاملاً امن است؟
خیر. اسکن فقط بخش مشخصی از سطح بررسی را پوشش می‌دهد. دسترسی‌ها، منطق برنامه و روند تغییرات نیز اهمیت دارند.
برای بررسی وضعیت فعلی، درخواست ارزیابی امنیت سرور ثبت کنید و سیستم‌عامل، سرویس‌ها و دامنه بررسی را بنویسید.
