سخت‌سازی سرور یعنی چه و شامل چه کارهایی است؟
سخت‌سازی یعنی هر چیزی که لازم نیست، خاموش یا محدود شود. هرچه سطح در معرض دید کمتر باشد، احتمال سوءاستفاده کمتر است.
کارهای پایه
- غیرفعال‌کردن سرویس‌ها و پورت‌هایی که استفاده نمی‌شوند.
- محدودکردن دسترسی SSH: کلید به‌جای رمز، و محدودیت روی نشانی‌های مجاز.
- حذف حساب‌های کاربری بلااستفاده و اعمال اصل کمترین دسترسی.
- تنظیم فایروال طوری که فقط ترافیک لازم عبور کند.
- به‌روز نگه‌داشتن بسته‌های سیستم‌عامل و سرویس‌ها.
- جداکردن سرویس‌ها تا دسترسی به یکی به معنی دسترسی به همه نباشد.
اگر از این فهرست فقط وقت یکی را داری، SSH را بردار. بیشتر تلاش‌های خودکاری که روی یک سرور تازه می‌بینی، آزمودن رمز روی همین در است.
SSH، با جزئیات
این تنها جایی است که چند تنظیم کوچک، بیشترین تفاوت را می‌سازد:
- ورود با رمز را ببند و فقط کلید بپذیر. رمز قابل حدس‌زدن است؛ کلید عملاً نه.
- ورود مستقیم با کاربر root را ببند. یک کاربر عادی بساز که با sudo کار کند، تا هر اقدام مدیریتی ردی از خود بگذارد.
- اگر می‌توانی، دسترسی SSH را به نشانی‌های مشخص محدود کن — دفتر، VPN یا یک سرور واسط.
- تعداد تلاش‌های ناموفق را محدود کن تا آزمودن پیاپی رمز، خودبه‌خود متوقف شود.
یک لایه بالاتر از پایه
| اقدام | چه چیزی را کم می‌کند |
|---|---|
| به‌روزرسانی امنیتی خودکار | فاصلهٔ بین انتشار یک آسیب‌پذیری و وصله‌شدن سرور تو. بیشتر نفوذها از آسیب‌پذیری تازه نیست، از وصله‌نشدهٔ قدیمی است. |
| کاربر جداگانه برای هر سرویس | اگر یکی از سرویس‌ها در اختیار مهاجم قرار بگیرد، دسترسی‌اش به همان سرویس محدود می‌ماند نه کل سرور. |
| بستن پورت پایگاه داده به بیرون | پایگاه داده معمولاً لازم نیست از اینترنت در دسترس باشد. اگر اپلیکیشن روی همان سرور است، فقط روی لوکال‌هاست گوش بدهد. |
| محدودکردن دسترسی پنل مدیریتی | هر رابط وب مدیریتی یک در ورودی است. اگر کنترل‌پنل داری، دسترسی به آن را به نشانی‌های مشخص محدود کن. |
| نگه‌داشتن لاگ بیرون از سرور | مهاجمی که دسترسی می‌گیرد، لاگ محلی را پاک می‌کند. لاگی که جای دیگری کپی شده، تنها چیزی است که بعداً می‌گوید چه شد. |
اشتباه‌های رایج
- خاموش‌کردن SELinux یا AppArmor برای اینکه «یک چیزی کار نمی‌کرد». این یک لایهٔ کامل را برمی‌دارد تا یک مشکل موقت حل شود، و تقریباً هیچ‌وقت برنمی‌گردد.
- باز کردن یک پورت برای عیب‌یابی و فراموش‌کردن بستنش.
- اجرای اپلیکیشن با کاربر root چون «ساده‌تر است».
- دادن دسترسی کامل پایگاه داده به کاربر اپلیکیشن، وقتی خواندن و نوشتن روی چند جدول کافی است.
- استفادهٔ دوباره از یک کلید SSH روی همهٔ سرورها و همهٔ لپ‌تاپ‌ها.
از کجا بفهمی واقعاً انجام شده؟
سخت‌سازی روی کاغذ با سخت‌سازی روی سرور یکی نیست. چند بررسی ساده که جواب واقعی می‌دهند:
- از بیرون سرور، پورت‌های بازش را اسکن کن. هر پورتی که نمی‌توانی توضیح بدهی چرا باز است، باید بسته شود.
- فهرست سرویس‌های در حال اجرا را بخوان و هر کدام را با یک جمله توجیه کن.
- فهرست کاربران دارای sudo را ببین. هر اسمی که نمی‌شناسی یا دیگر در تیم نیست، حذف شود.
- تاریخ آخرین به‌روزرسانی بسته‌ها را نگاه کن. اگر ماه‌هاست تکان نخورده، بقیهٔ فهرست اهمیتی ندارد.
چرا یک کار یک‌باره نیست؟
سروری که امروز سخت‌سازی شده، شش ماه بعد لزوماً امن نیست. آسیب‌پذیری‌های جدید منتشر می‌شوند، سرویس‌های جدید نصب می‌شوند و تنظیمات در طول زمان تغییر می‌کنند.
به همین دلیل سخت‌سازی باید بازهٔ بازبینی داشته باشد: بررسی دوره‌ای پورت‌های باز، بازبینی قواعد فایروال و اعمال منظم به‌روزرسانی‌ها. بازبینی فصلی برای بیشتر سرورها کافی است، به شرطی که واقعاً در تقویم کسی باشد.
مطالب مرتبط
این مطلب بخشی از راهنمای مدیریت سرور است.
