اگر یک VPS لینوکسی را بدون سختسازی اولیه وارد اینترنت کنید، معمولاً در همان ساعات اول با اسکن پورت، تلاش برای ورود به SSH، درخواستهای خودکار و رباتهای جستوجوی سرویسهای آسیبپذیر روبهرو میشوید. امنسازی VPS لینوکس یعنی سطح حمله را کم کنید، دسترسیها را محدود کنید، وصلههای امنیتی را سریع نصب کنید و برای تشخیص رفتار غیرعادی، لاگ و مانیتورینگ داشته باشید.
امنسازی VPS لینوکس دقیقاً یعنی چه؟
Hardening یا سختسازی سرور مجموعهای از تغییرات فنی و عملیاتی است که احتمال نفوذ، سوءاستفاده از سرویسها و ماندگاری مهاجم را کاهش میدهد. هدف این نیست که یک سرور «غیرقابل هک» بسازیم؛ هدف این است که سطح حمله کوچک شود، کنترلهای دفاعی لایهای شوند و در صورت رخداد، تشخیص و بازیابی سریعتر باشد.
این راهنما برای Ubuntu، Debian و بیشتر VPSهای لینوکسی قابل استفاده است. در Rocky Linux، AlmaLinux و RHEL بعضی ابزارها و نام سرویسها فرق میکنند، اما اصول همان است.
۱) سیستمعامل و پکیجها را قبل از هر چیز بهروز کنید
اولین قدم، نصب وصلههای امنیتی است. روی Ubuntu/Debian:
sudo apt update
sudo apt upgrade -y
sudo rebootاگر Kernel یا کتابخانههای مهم بهروزرسانی شدهاند، ریبوت را عقب نیندازید. برای سرورهایی که نیاز به uptime بالا دارند، مقاله Live Kernel Patching و کاهش Downtime را هم ببینید.
۲) یک کاربر مدیریتی جدا بسازید و استفاده روزمره از root را کنار بگذارید
کارکردن مستقیم با root ریسک خطای انسانی و سوءاستفاده از اعتبارنامهها را بالا میبرد. یک کاربر معمولی بسازید و فقط در مواقع نیاز از sudo استفاده کنید:
sudo adduser adminuser
sudo usermod -aG sudo adminuserبعد از اطمینان از ورود کاربر جدید، ورود مستقیم root را در SSH محدود کنید.
۳) SSH را با کلید امن کنید، نه رمز عبور
کلید SSH نسبت به پسورد مقاومتر است و ریسک brute-force را بهشدت کاهش میدهد. روی سیستم شخصی:
ssh-keygen -t ed25519 -a 100
ssh-copy-id adminuser@SERVER_IPسپس در /etc/ssh/sshd_config یا فایلهای sshd_config.d این گزینهها را بازبینی کنید:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3قبل از بستن سشن فعلی، در یک ترمینال دیگر ورود با کلید را تست کنید تا خودتان را از سرور قفل نکنید. مستندات رسمی Ubuntu نیز OpenSSH Server و مدیریت کلیدها را بهعنوان پایه دسترسی امن توضیح میدهد.
۴) تغییر پورت SSH را «لایه امنیتی» بدانید، نه راهحل اصلی
تغییر پورت پیشفرض 22 میتواند حجم اسکنهای بیهدف را کم کند، اما بهتنهایی امنیت واقعی ایجاد نمیکند. اگر پورت را عوض میکنید، ابتدا Rule فایروال را اضافه کنید و بعد SSH را ریستارت کنید. امنیت اصلی باید روی کلید SSH، غیرفعالکردن رمز، محدودکردن کاربران و کنترل نرخ تلاشهای ورود بنا شود.
۵) فایروال را با سیاست Deny by Default فعال کنید
روی Ubuntu، UFW رابط سادهای برای Netfilter است. ابتدا فقط سرویسهایی را باز کنید که واقعاً نیاز دارید:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verboseاگر SSH روی پورت دیگری است، همان پورت را باز کنید. مستندات رسمی Ubuntu توصیه میکند فایروال را بهعنوان کنترل ورودی شبکه فعال و قواعد را حداقلی نگه دارید.
۶) Fail2Ban را برای تلاشهای تکراری ورود فعال کنید
Fail2Ban لاگ سرویسها را بررسی میکند و IPهایی که رفتار تکراری مشکوک دارند موقتاً مسدود میکند:
sudo apt install fail2ban -y
sudo systemctl enable --now fail2banبهتر است تنظیمات را در /etc/fail2ban/jail.local یا فایلهای jail.d انجام دهید تا با بروزرسانی پکیج از بین نروند. Jail مربوط به SSH را فعال و پارامترهای maxretry، findtime و bantime را متناسب با سرور تنظیم کنید.
۷) بروزرسانی امنیتی خودکار را تنظیم کنید
روی Ubuntu/Debian میتوانید از unattended-upgrades استفاده کنید تا وصلههای امنیتی مهم با تأخیر کمتری نصب شوند:
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgradesبرای سرورهای حساس، نصب خودکار را همراه با مانیتورینگ و پنجره نگهداری تنظیم کنید؛ چون بعضی آپدیتها ممکن است نیاز به restart سرویس یا reboot داشته باشند.
۸) سرویسها و پورتهای غیرضروری را حذف یا غیرفعال کنید
هر سرویس فعال یک سطح حمله اضافه است. ابتدا سرویسهای در حال اجرا و پورتهای Listen را ببینید:
sudo systemctl --type=service --state=running
sudo ss -tulpnهر سرویسی که نیاز ندارید را disable کنید. سرویسهای دیتابیس مثل MySQL/PostgreSQL را نیز بدون نیاز عمومی روی تمام Interfaceها Bind نکنید.
۹) دسترسی فایلها، مالکیت و SUID/SGID را بازبینی کنید
مجوزهای بیشازحد باز مثل 777 در مسیرهای حساس خطرناکاند. فایلهای SUID/SGID را دورهای بررسی کنید:
sudo find / -xdev -perm /6000 -type f 2>/dev/nullبرای سرویسهای وب، اصل حداقل دسترسی را رعایت کنید؛ وبسرور نباید به مسیرهایی که نیاز ندارد دسترسی نوشتن داشته باشد.
۱۰) SELinux یا AppArmor را خاموش نکنید؛ درست پیکربندی کنید
در RHEL/Rocky/AlmaLinux، SELinux یک لایه Mandatory Access Control قدرتمند است. در Ubuntu معمولاً AppArmor فعال است. خاموشکردن این لایهها برای «حل سریع مشکل» سطح دفاع را کم میکند. اگر از RHEL استفاده میکنید، مقاله نقش SELinux در امنیت سیستمعاملهای سازمانی را بخوانید.
۱۱) تنظیمات Kernel و شبکه را بر اساس نقش سرور سختسازی کنید
همه sysctlها برای همه سرورها مناسب نیستند، اما مواردی مثل Source Routing، ICMP Redirect و برخی تنظیمات شبکه باید متناسب با نقش سرور بازبینی شوند. تغییرات را کورکورانه کپی نکنید؛ ابتدا مستندات توزیع و سرویسها را بررسی کنید. برای مطالعه عمیقتر، مقاله روشهای Kernel Hardening برای افزایش امنیت مفید است.
۱۲) لاگ و مانیتورینگ را قبل از رخداد فعال کنید
بدون لاگ، تشخیص نفوذ سخت میشود. حداقل این موارد را مانیتور کنید:
- ورودهای موفق و ناموفق SSH
- مصرف CPU، RAM و Disk
- تغییر ناگهانی تعداد Connectionها
- خطاهای وبسرور و دیتابیس
- فعالشدن سرویسهای جدید
- تغییر فایلهای حساس
برای مشاهده لاگ SSH در سیستمهای systemd میتوانید از journalctl -u ssh استفاده کنید. اگر با systemd کار میکنید، مقاله systemd Timer چیست؟ هم برای زمانبندی کنترلها و کارهای نگهداری مفید است.
۱۳) بکاپ خارج از VPS داشته باشید و بازیابی را تست کنید
Snapshot بهتنهایی بکاپ کامل نیست. بکاپ باید نسخه مستقل، ترجیحاً خارج از همان VPS و دیتاسنتر، و دارای چرخه نگهداری مشخص باشد. حداقل یک بار Restore واقعی انجام دهید تا مطمئن شوید بکاپ فقط «وجود» ندارد، بلکه قابل بازیابی است.
۱۴) اگر Docker دارید، کانتینر را معادل Sandbox کامل فرض نکنید
Container امنیت را خودکار حل نمیکند. imageها را از منابع معتبر بگیرید، سرویسها را با root اجرا نکنید، Secretها را داخل Image قرار ندهید، پورتهای غیرضروری را Publish نکنید و imageها را مرتب بهروزرسانی کنید. برای ساختار عملی استکها، مقاله Docker Compose چیست؟ را ببینید.
۱۵) برای Deploy خودکار، کلید و Secret جدا بسازید
اگر CI/CD دارید، کلید Deploy را از کلید شخصی مدیر سرور جدا کنید، دسترسی آن را محدود کنید و Secretها را داخل Repository قرار ندهید. در راهنمای استقرار خودکار روی VPS با GitHub Actions و SSH این سناریو را مرحلهبهمرحله توضیح دادهایم.
چکلیست نهایی امنسازی VPS لینوکس
| کنترل | وضعیت پیشنهادی |
|---|---|
| ورود root با SSH | غیرفعال |
| PasswordAuthentication | غیرفعال، بعد از تست کلید |
| Firewall | Deny by default، فقط پورتهای لازم |
| Fail2Ban | فعال برای سرویسهای حساس |
| Security Updates | منظم یا خودکار با مانیتورینگ |
| سرویسهای غیرضروری | غیرفعال/حذف |
| SELinux/AppArmor | فعال و پیکربندیشده |
| Monitoring | CPU/RAM/Disk/Network/Login |
| Backup | خارج از VPS + تست Restore |
امنسازی VPS برای چه کسانی حیاتیتر است؟
اگر روی VPS فروشگاه اینترنتی، API، پنل مشتریان، VPN سازمانی، دیتابیس، سرویس CI/CD یا پروژه SaaS دارید، سختسازی باید بخشی از فرایند راهاندازی باشد؛ نه کاری که بعد از اولین حمله انجام شود. هرچه سرویس عمومیتر و حساستر باشد، اهمیت مانیتورینگ، بکاپ، جداسازی دسترسیها و بروزرسانی سریع بیشتر میشود.
جمعبندی
امنسازی VPS لینوکس یک تنظیم واحد نیست. بهترین نتیجه زمانی بهدست میآید که چند کنترل ساده اما مداوم کنار هم باشند: دسترسی SSH امن، فایروال، Fail2Ban، بروزرسانی، حداقلسازی سرویسها، کنترل دسترسی، لاگ، مانیتورینگ و بکاپ. اگر تازه VPS گرفتهاید، این ۱۵ مرحله را بهعنوان چکلیست روز اول اجرا کنید و بعد آن را به برنامه نگهداری ماهانه تبدیل کنید.
اگر برای پروژه خود به منابع اختصاصی و کنترل کامل روی سیستمعامل نیاز دارید، میتوانید پلنهای سرور مجازی وانسرور را بررسی کنید.
سوالات متداول
آیا تغییر پورت SSH بهتنهایی سرور را امن میکند؟
خیر. این کار فقط بخشی از اسکنهای خودکار را کم میکند. امنیت واقعی باید بر کلید SSH، غیرفعالکردن پسورد، محدودکردن کاربران، فایروال و کنترل تلاشهای ورود تکیه کند.
آیا Fail2Ban جای فایروال را میگیرد؟
خیر. فایروال تعیین میکند چه ترافیکی اجازه ورود دارد؛ Fail2Ban بر اساس لاگ، رفتار تکراری مشکوک را شناسایی و IP را موقتاً مسدود میکند. این دو مکمل یکدیگرند.
آیا UFW برای همه VPSها کافی است؟
برای بسیاری از VPSهای Ubuntu ساده و مناسب است، اما محیطهای پیچیده ممکن است به nftables، firewalld یا سیاستهای شبکه در سطح Cloud نیاز داشته باشند.
هر چند وقت یک بار باید سرور را بروزرسانی کنیم؟
وصلههای امنیتی مهم باید با کمترین تأخیر منطقی نصب شوند. برای سرورهای Production، بروزرسانی را با بکاپ، تست و پنجره نگهداری ترکیب کنید.
آیا Snapshot همان Backup است؟
نه همیشه. Snapshot معمولاً وابسته به همان زیرساخت است. برای بازیابی واقعی بهتر است بکاپ مستقل و خارج از همان VPS داشته باشید.