اولین بار که یک VPS (Virtual Private Server) برای یک مشتری راه‌اندازی کردم، رفتم سراغ نصب پنل و وردپرس؛ فرض بدیهی‌ام این بود که خود سرور، امن است. سه هفته بعد، سرور توسط حمله SSH (Secure Shell) به‌طور کامل آلوده شده بود و باید از صفر بازسازی می‌شد. از آن روز، در همه پروژه‌های VPS، چهار ساعت اول را به امنیت اختصاص می‌دهم، قبل از اینکه هیچ نرم‌افزاری نصب شود. این تفاوت، تفاوت میان سروری است که می‌توانید سال‌ها روی آن کار کنید و سروری که هر چند ماه باید از صفر بازسازی شود. امنیت VPS با امنیت هاست اشتراکی متفاوت است؛ چون تمام لایه‌ها در دستان خودتان است و مسئولیت هم به همان اندازه بزرگ‌تر. در این نوشته، همان ترتیب سخت‌سازی را که در پروژه‌های واقعی اجرا می‌کنم، قدم‌به‌قدم می‌گویم.

چرا امنیت VPS متفاوت از هاست اشتراکی است

در هاست اشتراکی، لایه‌های پایین امنیت — سیستم‌عامل، فایروال، پچ امنیتی و ایزوله‌سازی — در دست شرکت هاستینگ است و شما فقط روی فایل‌های سایت مسئولید. در VPS (سرور مجازی)، تمام این لایه‌ها به دست خودتان می‌آید. این یعنی هم کنترل کامل دارید و هم مسئولیت کامل. سه نتیجه عملی:

  • شما مسئول پچ امنیتی هسته سیستم‌عامل و سرویس‌ها هستید.
  • شما مسئول پیکربندی فایروال، SSH و دسترسی‌های شبکه هستید.
  • شما مسئول مانیتورینگ و بکاپ هستید؛ کسی به‌جای شما این کارها را نمی‌کند.

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

لایه اول: سخت‌سازی SSH

SSH (Secure Shell) دروازه اصلی ورود به سرور است و بیشترین حمله‌های خودکار روی همین پورت انجام می‌شود. سه کار پایه:

  1. تغییر پورت SSH از ۲۲ به یک پورت غیررایج. این تغییر امنیت را به‌تنهایی تضمین نمی‌کند اما نویز حملات خودکار را به‌شدت کم می‌کند. ربات‌های جاروکننده سراسری معمولاً فقط پورت ۲۲ را تست می‌کنند.
  2. ورود با کلید SSH به‌جای رمز عبور. کلید عمومی/خصوصی امنیت را چند برابر می‌کند و امکان حمله Brute Force (حمله جستجوی فراگیر) را از بین می‌برد. کلید خصوصی را روی دستگاه شخصی نگه دارید، نه روی سرور.
  3. غیرفعال کردن ورود مستقیم روت. حتی اگر با کلید وارد می‌شوید، ورود مستقیم روت را خاموش کنید و از یک کاربر عادی با sudo استفاده کنید. اگر مهاجمی کلید یک کاربر عادی را بدزدد، همچنان نمی‌تواند بدون رمز sudo کار کند.

پس از این سه، فایل /etc/ssh/sshd_config را بازبینی کنید و مطمئن شوید PermitRootLogin no، PasswordAuthentication no و PubkeyAuthentication yes تنظیم شده‌اند. این تنظیمات را پس از اعمال، با یک session فعال دیگر تست کنید تا از قطع‌نشدن دسترسی مطمئن شوید. حذف سریع دسترسی و بدون پشتوانه، همان بلایی است که در پروژه‌های تازه‌کار زیاد دیده‌ام.

اولین باری که سروری را با کلید SSH محافظت کردم، تعداد تلاش‌های ناموفق ورود از چند هزار در روز به صفر رسید. بیشتر حمله‌ها حتی به درِ سرور نمی‌رسند اگر ورودی اصلی محافظت‌شده باشد.

لایه دوم: فایروال و مدیریت پورت‌ها

قاعده اصلی فایروال در VPS: هر پورتی که استفاده نمی‌شود، بسته بماند. مسیر عملی:

  • نصب و فعال‌سازی UFW (Uncomplicated Firewall) یا firewalld.
  • اجازه دادن فقط به پورت‌های ضروری: SSH (پورت سفارشی)، ۸۰ و ۴۴۳ برای HTTP/HTTPS.
  • بستن مستقیم دیتابیس و Redis به بیرون؛ دسترسی فقط از localhost.
  • بستن پورت پنل‌های مدیریتی مثل phpMyAdmin یا Webmin به بیرون، مگر با IP سفیدلیست.

مسیر پیاده‌سازی UFW و firewalld در فایروال نرم‌افزاری روی سرور آمده است. در پروژه‌های واقعی، دیده‌ام که یک سرور به‌ظاهر سالم، پورت MySQL را به بیرون باز گذاشته بود و به‌طور مستمر تلاش‌های ورود از سراسر دنیا دریافت می‌کرد. بستن همان یک پورت، حجم لاگ‌ها را به یک‌دهم رساند. برای لایه بالاتر، ترکیب فایروال درون‌سروری با یک فایروال ابری یا CDN امنیتی مثل Cloudflare هم پیشنهاد می‌شود؛ مقایسه در فایروال ابری و سنتی.

لایه سوم: مدیریت کاربران و دسترسی‌ها

قاعده کم‌ترین دسترسی (Principle of Least Privilege) در سرور یعنی هر کاربر فقط همان دسترسی‌ای را داشته باشد که برای کارش لازم است. سه کار در این لایه:

  • کاربر عادی برای کارهای روزمره: با sudo، نه ورود مستقیم روت.
  • کاربر اختصاصی برای هر سرویس: مثلاً www-data برای وب، mysql برای دیتابیس. هر سرویس نباید با کاربر مشترک اجرا شود.
  • حذف کاربران و کلیدهای SSH بی‌استفاده: هر سه ماه یک بار لیست کاربران و کلیدهای SSH را بازبینی کنید. کارمند قدیمی که رفته، کلید SSH او باید حذف شده باشد.

برای مدیریت رمز عبور سرور، از یک مدیر رمز عبور تیمی استفاده کنید. اصول در مدیریت امن رمز عبور آمده است. موردی که در پروژه‌ها زیاد دیده‌ام: کلید SSH یک توسعه‌دهنده قبلی که سال‌ها پیش از تیم جدا شده، همچنان در فایل authorized_keys مانده بود.

لایه چهارم: به‌روزرسانی و پچ امنیتی

VPS دست‌نخورده، به‌مرور آسیب‌پذیر می‌شود چون حفره‌های امنیتی در هسته لینوکس و سرویس‌ها کشف و منتشر می‌شوند. سه اقدام:

  • به‌روزرسانی خودکار امنیتی: ابزارهایی مثل unattended-upgrades در اوبونتو یا dnf-automatic در سرورهای فدرا و خانواده RHEL.
  • بازبینی ماهانه: لیست پکیج‌های نصب‌شده را مرور کنید و پکیج‌های بی‌مصرف را حذف کنید.
  • اعلان‌های امنیتی: در توزیع خودتان، عضویت در لیست‌های اعلان امنیتی را فعال کنید تا از آسیب‌پذیری‌های بحرانی سریع باخبر شوید.

تجربه واقعی: در پروژه‌ای که سرور به‌روزرسانی خودکار نداشت، حفره‌ای در یک پکیج جانبی، پس از شش ماه از سروری که از بیرون کاملاً سالم به‌نظر می‌رسید، به مهاجم اجازه ورود داد. اگر unattended-upgrades فعال بود، این حفره در همان هفته بسته می‌شد.

لایه پنجم: ایزوله‌سازی سرویس‌ها

VPS معمولاً میزبان چند سرویس است: وب‌سرور، دیتابیس، Redis، فایل‌سرور. اگر یکی از آن‌ها به‌دست مهاجم بیفتد، ایزوله‌سازی مانع گسترش حمله به بقیه می‌شود. سه کار در این لایه:

  • Docker یا container جدا برای هر سرویس: هر سرویس در محیط جداگانه‌اش اجرا شود. مزایایش در بررسی Docker آمده.
  • دسترسی‌های محدود: سرویس دیتابیس نباید کل فایل‌سیستم را ببیند؛ فقط مسیر داده‌اش را.
  • حذف سرویس‌های بی‌استفاده: اگر روی سرور FTP یا Telnet استفاده نمی‌کنید، غیرفعالشان کنید.

مفهوم دقیق ایزوله‌سازی مرتبط با مفهوم container و virtualization است که در VM و نقش آن در مجازی‌سازی سرور و تفاوت VPS و سرور اختصاصی آمده است.

لایه ششم: مانیتورینگ و لاگ

بدون مانیتورینگ، شما فقط بعد از حادثه متوجه می‌شوید. سه لایه مانیتورینگ در VPS:

  • لاگ SSH: فایل /var/log/auth.log و ابزارهایی مثل fail2ban که تلاش‌های ناموفق را شناسایی و IPهای مشکوک را مسدود می‌کنند.
  • مانیتورینگ منابع: ابزارهایی مثل Netdata، Glances یا حتی دستورات ساده top و vmstat. پیک‌های غیرعادی CPU یا RAM، نشانه اول حمله cryptominer یا مشابهش هستند.
  • مانیتورینگ آپ‌تایم: سرویس‌های بیرونی مثل UptimeRobot که در صورت قطع سرور، به شما هشدار می‌دهند.

مسیر کلی این لایه در مانیتورینگ عملکرد سرور و مقایسه ابزارهای مانیتورینگ سرور آمده است. یک نکته ظریف: لاگ‌ها فقط برای بعد از حادثه نیستند؛ اگر هفتگی مرور شوند، می‌توانند نشانه حمله را قبل از وقوع کامل نشان بدهند. در یکی از پروژه‌ها، همین مرور هفتگی، حمله‌ای در مرحله پایلوت را کشف کرد.

لایه هفتم: بکاپ و بازیابی

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

  • بکاپ بیرون از سرور: بکاپ روی همان VPS، بکاپ نیست. باید در محل متفاوت باشد: object storage، سرور دوم یا سرویس ابری.
  • بکاپ کامل و بکاپ داده: هم snapshot کل سرور برای بازیابی سریع، هم بکاپ دیتابیس و فایل‌های حیاتی برای بازیابی انتخابی.
  • آزمایش بازیابی دوره‌ای: بکاپی که بازیابی‌اش آزمایش نشده، فقط فرض امنیت است. حداقل فصل یک بار، بازیابی را روی محیط آزمایشی تمرین کنید.

مسیر کامل بکاپ در پشتیبان‌گیری از سایت چیست و بکاپ وردپرس و بکاپ از سرور آمده است.

بکاپ، بیمه‌نامه‌ای است که فقط پس از حادثه ارزشش معلوم می‌شود. تا آن روز، سرمایه‌گذاری بی‌سروصدا و ضروری است.

پاسخ به پرسش‌های پرتکرار درباره امنیت VPS

آیا VPS از هاست اشتراکی ناامن‌تر است؟ در حالت پیش‌فرض بله، چون مسئولیت بیشتری روی شماست. اما اگر لایه‌های بالا را اجرا کنید، VPS امن‌تر از هاست اشتراکی می‌شود چون کنترل و انعطاف کاملی دارید. تفاوت در سطح تنظیمات است، نه ذات ابزار.

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

چرا بعد از مدتی، سرور من مورد حمله قرار می‌گیرد؟ دو دلیل شایع: نبود فایروال یا به‌روزرسانی ناکافی. در تجربه واقعی، بیشتر حملات موفق روی VPS از پورت SSH باز و بدون محافظت یا از نسخه آسیب‌پذیر سرویس‌های جانبی می‌آید.

آیا استفاده از Cloudflare روی VPS امنیت را تقویت می‌کند؟ بله، در لایه شبکه. Cloudflare می‌تواند حملات DDoS را قبل از رسیدن به سرور شما دفع کند و IP واقعی سرور را پنهان نگه دارد. اما جایگزین سخت‌سازی داخلی نیست. ترکیب هر دو، بهترین نتیجه را می‌دهد؛ مسیرش در بررسی Cloudflare.

آیا برای یک VPS کوچک، این همه لایه لازم است؟ سه لایه اول — SSH، فایروال، کاربران — برای همه VPSها ضروری است. بقیه لایه‌ها بسته به حجم پروژه، می‌تواند در فازهای بعدی اضافه شود. اما لایه اول و دوم، بدون بحث حجم، از روز اول.

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

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

اگر بخواهم همه هفت لایه را در یک جمله خلاصه کنم: امنیت VPS یعنی کاهش سطح حمله، محدودسازی ورودی‌ها و آماده بودن برای لحظه‌ای که لایه‌ای از کار می‌افتد. ترتیب پیشنهادی این است: SSH، فایروال، کاربران، به‌روزرسانی — این چهار مورد از روز اول. سپس بسته به حجم پروژه، ایزوله‌سازی، مانیتورینگ و بکاپ را اضافه کنید. یک عادت شخصی که به‌شدت در تجربه‌ام اثرگذار بوده: هر سه ماه یک بار، یک بازبینی ۳۰ دقیقه‌ای روی سرور انجام می‌دهم — کاربران و کلیدهای SSH، پورت‌های باز، پکیج‌های بی‌مصرف، آخرین بکاپ و آخرین به‌روزرسانی. اگر امروز فقط یک کار می‌کنید، ورود مستقیم روت را غیرفعال و ورود با کلید SSH را جایگزین کنید؛ همین یک تغییر ساده، بیشترین سهم را در کاهش حمله‌های موفق روی VPS داشته — در تجربه من بیش از هر ابزار امنیتی دیگر. اگر تجربه‌ای از مدیریت سرور یا حادثه امنیتی روی VPS دارید، در دیدگاه بنویسید؛ این روایت‌ها، تصویر عملی امنیت سرور را روشن‌تر از هر توصیه انتزاعی می‌کنند. 🔐