امن‌سازی اولیه VPS: راهنمای 10 دقیقه‌ای برای شروع

ده دقیقه نخست، امنیت سرور شما را تعیین می‌کند

یک VPS کاملاً جدید امن نیست. از لحظه‌ای که سرور دارای IP عمومی می‌شود، اسکنرها برای ورود به آن تلاش می‌کنند و image پیش‌فرض، هدفی بزرگ در اختیار آن‌ها قرار می‌دهد: دسترسی root اغلب باز است، استفاده از رمز عبور معمولاً مجاز است، فایروالی وجود ندارد و هیچ‌گونه زمان‌بندی برای اعمال وصله‌های امنیتی (patch) تنظیم نشده است. خبر خوب این است که بستن تمام این حفره‌ها حدود ده دقیقه زمان می‌برد و تنها به چند دستور نیاز دارد. این همان runbook است که من روی هر سرور جدید، پیش از قرار دادن هرگونه سرویس روی آن، اجرا می‌کنم.

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

دقیقه 1: به‌روزرسانی همه‌چیز

با استفاده از مشخصات ارائه‌شده توسط سرویس‌دهنده، با کاربر root وارد شوید و پیش از هر اقدام دیگری، سیستم را به‌طور کامل به‌روزرسانی کنید:

apt update && apt upgrade -y

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

دقیقه 2: ایجاد یک کاربر عادی با دسترسی sudo

به کار کردن با حساب root ادامه ندهید. یک کاربر برای خود بسازید و به آن دسترسی sudo بدهید:

adduser matt
usermod -aG sudo matt

از این مرحله به بعد، با این کاربر وارد شوید و برای وظایف مدیریتی از sudo استفاده کنید. اجرای مداوم دستورات با حساب root به این معناست که هر اشتباه و هر نفوذ امنیتی با دسترسی نامحدود انجام می‌شود؛ دقیقاً همان چیزی که اجرا با کاربر فاقد دسترسی ویژه برای جلوگیری از آن طراحی شده است.

دقیقه 4: تنظیم کلیدهای SSH

رمزهای عبور حدس زده می‌شوند، اما کلیدها خیر. روی لپ‌تاپ خود، اگر هنوز کلیدی ندارید، یکی بسازید:

ssh-keygen -t ed25519

سپس نیمه عمومی آن را به سرور کپی کنید:

ssh-copy-id matt@YOUR_SERVER

ssh-copy-id نیاز دارد که ورود با رمز عبور برای کاربر جدید فعال باشد؛ اگر قبلاً غیرفعال شده است، محتویات ~/.ssh/authorized_keys مربوط به root را در /home/matt/.ssh/authorized_keys (که مالک آن matt است) کپی کنید، یا کلید عمومی خود را به‌صورت دستی در آن فایل قرار دهید.

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

خارج شوید و دوباره به‌عنوان matt با استفاده از کلید وارد شوید، و پیش از رفتن به مرحله بعد، از صحت عملکرد آن اطمینان حاصل کنید. محدود کردن SSH پیش از آنکه بتوانید با کلید وارد شوید، همان دلیلی است که باعث می‌شود کاربران دسترسی خود را قطع کنند. اگر آن ورود با خطای Permission denied (publickey) مواجه شد، همین حالا آن را برطرف کنید و به سراغ رمز عبور نروید، زیرا آن پیام شامل پنج خطای مختلف است و خروجی ssh -v به شما می‌گوید که دقیقاً با کدام‌یک از آن‌ها مواجه هستید.

دقیقه 6: غیرفعال‌سازی ورود root و رمز عبور

اکنون که کلید شما کار می‌کند، دو درگاهی که اسکنرها از آن استفاده می‌کنند را ببندید. از یک فایل drop-in استفاده کنید تا ارتقای بسته‌ها آن را بازنویسی نکند. نام آن را 00- بگذارید تا پیش از هر فایل دیگری در آن دایرکتوری مرتب شود. ایمیج‌های ابری Ubuntu فایل 60-cloudimg-settings.conf را با PasswordAuthentication no ارائه می‌دهند، اما اگر ارائه‌دهنده شما ssh_pwauth را در cloud-init تنظیم کرده باشد، cloud-init فایل 50-cloud-init.conf را می‌نویسد که عمداً پیش از فایل ایمیج مرتب می‌شود و می‌تواند رمزهای عبور را دوباره فعال کند. سرویس sshd اولین مقداری را که می‌خواند نگه می‌دارد، بنابراین فایلی که بعداً مرتب شود، بی‌سروصدا نادیده گرفته می‌شود:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

سپس SSH را reload کنید:

sudo systemctl restart ssh

سپس تنظیماتی را که sshd واقعاً استفاده می‌کند بررسی کنید تا یک فایل drop-in که نادیده گرفته شده، شما را به اشتباه نیندازد:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

با غیرفعال شدن رمزهای عبور و ورود root، ترافیک مداوم brute-force علیه سرور شما عملاً بی‌نتیجه خواهد بود. راهکار کامل، شامل تغییر اختیاری پورت، در سخت‌سازی SSH روی VPS آمده است.

دقیقه 8: فعال‌سازی فایروال

سیاست پیش‌فرض را روی مسدودسازی تمام ترافیک ورودی (Default-deny) قرار دهید و سپس فقط موارد ضروری را مجاز کنید. پیش از فعال‌سازی، دسترسی SSH را مجاز کنید، در غیر این صورت ارتباط خود را قطع خواهید کرد:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

برای هر سرویسی که واقعاً اجرا می‌کنید، مانند 80/tcp و 443/tcp برای وب‌سایت، قوانین allow را اضافه کنید. اگر پس از این مرحله، نشست SSH جدیدی برقرار نشد، پیش از هر تغییری پیام خطا را بخوانید، زیرا رد شدن اتصال به این معناست که sshd پاسخ داده و timeout معمولاً به این معناست که فایروال بسته را مسدود کرده است. اطمینان حاصل کنید که هر دو پروتکل IPv4 و IPv6 تحت پوشش هستند، زیرا فایروالی که فقط IPv4 را فیلتر می‌کند، سمت IPv6 را کاملاً باز می‌گذارد. راهنمای کامل در مبانی فایروال روی VPS موجود است. این دستورات ufw برای Ubuntu یا Debian فرض شده‌اند؛ در سیستم‌های Rocky یا AlmaLinux هدفِ Default-deny یکسان است اما ابزار مورد استفاده firewalld است، بنابراین نسخهٔ firewalld این مرحله را دنبال کنید.

دقیقه 10: کند کردن اسکنرها با Fail2ban

در نهایت، Fail2ban را اضافه کنید تا آدرس‌هایی که پورت‌های شما را هدف حملات مکرر قرار می‌دهند، مسدود شوند:

sudo apt install -y fail2ban

در Ubuntu 24.04، نصب پیش‌فرض، SSH را از همان لحظه بوت اول محافظت می‌کند. با توجه به اینکه استفاده از کلیدها (keys) از قبل الزامی شده است، این ابزار به عنوان یک لایه حفاظتی پشتیبان عمل می‌کند که نویز لاگ‌ها را کاهش داده و متخلفان تکراری را مسدود می‌کند، نه اینکه دفاع اصلی شما باشد.

چک‌لیست شما

این یک runbook است. از تولیدکننده زیر استفاده کنید تا هر کنترل را علامت بزنید و یک چک‌لیست شخصی‌سازی‌شده تهیه کنید که می‌توانید آن را همراه سرور نگهداری کنید؛ این چک‌لیست شامل دستور دقیق برای هر مرحله است:

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

هنگامی که موارد ضروری برقرار شدند، به‌روزرسانی‌های امنیتی خودکار در Ubuntu سرور را بدون نیاز به ورود مجدد شما، به‌روز نگه می‌دارند. هر سرویسی که پس از آن اضافه می‌کنید، نیاز به بررسی امنیتی جداگانه دارد و نقاط ضعف تغییر می‌کنند: با داشتن یک vault رمز عبور self-hosted، سرور هرگز رمزها را به صورت متن ساده (plaintext) ذخیره نمی‌کند، بنابراین خطرات واقعی Vaultwarden شامل توکن مدیریت و فایل پشتیبان است.

FAQ

در یک VPS جدید ابتدا چه کاری باید انجام دهم؟

سیستم را با apt update && apt upgrade -y به‌روزرسانی کنید، سپس یک کاربر معمولی با دسترسی sudo بسازید و دیگر با کاربر root کار نکنید. پس از آن، کلیدهای SSH را تنظیم کنید، ورود کاربر root و احراز هویت با رمز عبور را غیرفعال کنید، یک فایروال با سیاست پیش‌فرض deny فعال کنید و Fail2ban را نصب نمایید. انجام این مراحل به همین ترتیب باعث می‌شود هر گام بدون خطر مسدود شدن دسترسی شما به سرور انجام شود.

چگونه هنگام ایمن‌سازی SSH از مسدود شدن دسترسی خود جلوگیری کنم؟

پیش از غیرفعال کردن رمز عبور یا کاربر root، ورود با کلید SSH را تنظیم و تست کنید. از سیستم خارج شوید و دوباره با کلید وارد شوید تا از صحت عملکرد آن مطمئن شوید؛ تنها پس از آن PasswordAuthentication و PermitRootLogin را غیرفعال کنید. هنگام فعال‌سازی فایروال، پیش از اجرای ufw enable، پورت 22 را باز بگذارید. اگر دسترسی شما مسدود شد، کنسول وب ارائه‌دهنده سرور به شما امکان می‌دهد بدون نیاز به SSH دوباره وارد شوید.

آیا واقعاً به همه این موارد در یک سرور کوچک نیاز دارم؟

بله، زیرا اسکنرها اهمیتی نمی‌دهند که سرور شما چقدر کوچک است. آن‌ها تمام IPهای عمومی را به یک شکل بررسی می‌کنند. کل این دستورالعمل حدود 10 دقیقه زمان می‌برد و مسیرهای نفوذ آسان را از بین می‌برد: عدم ورود با root، عدم امکان حدس رمز عبور، عدم دسترسی عمومی به سرویس‌های ناخواسته و وصله شدن خودکار باگ‌های شناخته‌شده.

مهم‌ترین گام کدام است؟

استفاده از SSH فقط با کلید و غیرفعال کردن ورود کاربر root. اکثر حملات به یک VPS تازه، حدس خودکار رمز عبور برای کاربر root است و غیرفعال کردن هر دو مورد، این دسته از حملات را به‌طور کامل غیرممکن می‌کند. فایروال و Fail2ban نیز سطح دسترسی را محدود کرده و سرعت هرگونه تلاش باقی‌مانده را کاهش می‌دهند.

چگونه تأیید کنم که سرور واقعاً ایمن شده است؟

پیش از اعتماد به وضعیت سرور، این سه مورد را به‌صورت دستی بررسی کنید. دستور sudo ss -tlnp را اجرا کنید و مطمئن شوید فقط پورت‌هایی که قصد باز کردن آن‌ها را داشته‌اید روی آدرس عمومی در حال گوش دادن هستند و هیچ سرویس 0.0.0.0 یا [::] که فراموش کرده‌اید فعال نیست. دستور sudo ufw status verbose را اجرا کنید و تأیید کنید که سیاست پیش‌فرض ورودی (incoming policy) روی deny تنظیم شده و هر دو قانون ساده و (v6) وجود دارند. همیشه پیش از بستن نشست اول SSH، یک نشست دوم باز کنید تا اشتباه در پیکربندی SSH باعث قطع دسترسی شما به سرور نشود. اگر هر سه مورد درست به نظر می‌رسند، اصول اولیه رعایت شده است.