توسط آیا میزبانی VPS امن است؟ بررسی امنیت سرور مجازی
میزبانی VPS با جداسازی در سطح هایپروایزر امنیت بالایی دارد اما خطر اصلی پیکربندی شماست. با رعایت امنیت SSH و بهروزرسانی بستهها از نفوذ به سرور جلوگیری کنید.
آیا میزبانی VPS امن است؟ پاسخ کوتاه
بله. میزبانی VPS برای کاری که اکثر افراد به خاطر آن اقدام به خرید میکنند امن است و نسبت به میزبانی اشتراکی (shared hosting) یک پیشرفت واقعی محسوب میشود. یک VPS (سرور مجازی خصوصی) یک ماشین مجازی با هسته (kernel)، حافظه، دیسک و حسابهای کاربری اختصاصی خود است و هایپروایزری که آن را اجرا میکند، سایر مشتریان را از دسترسی به هر چهار مورد مذکور باز میدارد. شخصی که سرور مجاور شما را روی همان سختافزار فیزیکی اجاره کرده است، نمیتواند فایلهای شما را بخواند، پردازشهای شما را لیست کند، به سرور شما وارد شود یا ترافیک شبکه شما را ببیند.
پاسخ صادقانه دو بخش دارد. ارائهدهنده، مالک سختافزار و هایپروایزر است. شما مالک همه چیز در داخل ماشین مجازی خود هستید و تقریباً تمام حوادث واقعی از همینجا شروع میشوند. سرورها معمولاً از طریق یک پورت باز، رمز عبور ضعیف SSH، بستهای که بهروزرسانی نشده یا یک راز (secret) موجود در فایلی که منتشر شده است، مورد نفوذ قرار میگیرند. نفوذ به سرورها از طریق هایپروایزر بسیار نادر است.
هایپروایزر دقیقاً چه چیزی را جداسازی میکند
هایپروایزر نرمافزاری است که ماشینهای مجازی را روی یک میزبان فیزیکی اجرا میکند. در یک VPS مبتنی بر KVM (که مخفف kernel based virtual machine است و استاندارد میزبانهای لینوکسی محسوب میشود)، سرور شما یک ماشین مجازی کامل است. این سرور هسته (kernel) اختصاصی خود را بوت میکند. میزبان، یک محدوده ثابت از حافظه فیزیکی را به آن اختصاص میدهد و واحد مدیریت حافظه پردازنده، هرگونه دسترسی به خارج از این محدوده را مسدود میکند؛ بنابراین کدی که در یک ماشین مجازی دیگر اجرا میشود، به هیچ وجه نمیتواند RAM شما را آدرسدهی کند. هیچ سیستم فایل مشترک یا جدول کاربری مشترکی وجود ندارد، بنابراین مجوزهای فایل در سرور همسایه، هیچ تأثیری بر سرور شما ندارند.
هاستینگ اشتراکی به شکل متفاوتی عمل میکند. بسیاری از سایتها در یک سیستمعامل واحد، تحت یک وبسرور و یک نصب PHP، به عنوان حسابهای کاربری معمولی زندگی میکنند. تنها مرز موجود، مجوزهای فایل است. یک اشتباه در مجوزها یا یک افزونه آسیبپذیر که با کاربری با دسترسی بیش از حد اجرا میشود، میتواند به فایلهای حساب کاربری دیگر دسترسی پیدا کند. این همان شکافی است که مهاجرت از هاستینگ اشتراکی به VPS آن را میبندد.
بررسی کنید چه چیزی خریداری میکنید، زیرا هر طرحی که به عنوان VPS فروخته میشود، لزوماً یک ماشین مجازی نیست. طرحهای مبتنی بر کانتینر (مانند OpenVZ، LXC، Virtuozzo) هسته میزبان را به اشتراک میگذارند و مشتریان را به جای مجازیسازی سختافزاری، با استفاده از namespaces و cgroups از هم جدا میکنند. این مرز ضعیفتری است، زیرا یک باگ هسته در میزبان، یک باگ هسته در سرور شما نیز محسوب میشود. همچنین در این طرحها نمیتوانید ماژولهای هسته را بارگذاری کنید که باعث محدودیت در اجرای برخی نرمافزارها میشود. KVM گزینه امنتر و استانداردتری است. پیش از پرداخت هزینه، بپرسید که کدام نوع را دریافت میکنید.
همسایه پرسر و صدا چه بلایی سر شما میآورد
اشتراک یک میزبان فیزیکی، سرعت شما را کاهش میدهد و سرعت تنها چیزی است که تحت تأثیر قرار میگیرد. مهمانهای روی یک ماشین، CPU فیزیکی و دیسکها را به اشتراک میگذارند. وقتی CPU مشغول کار دیگری است، CPU مجازی شما منتظر میماند و لینوکس این انتظار را به عنوان steal time گزارش میکند: فیلد %st در top و vmstat. اگر steal time برای ساعتها بالای چند درصد باقی بماند، یعنی میزبان بیش از حد ظرفیت (oversubscribed) است. این به معنای آن نیست که کسی در حال خواندن دادههای شماست. راهحل، تغییر پلن یا تغییر ارائهدهنده است و شما میتوانید پیش از تصمیمگیری، CPU و دیسکی که واقعاً دریافت کردهاید را اندازهگیری کنید.
یک اثر متقابل بین مشتریان وجود دارد که دانستن آن مفید است و یک حفره امنیتی محسوب نمیشود. اگر از VPS خود ایمیل ارسال میکنید، آدرس IP شما در محدودهای قرار دارد که سایر مشتریان نیز از آن استفاده میکنند. همسایهای که اسپم ارسال میکند میتواند بخشی از آن محدوده را در لیست سیاه (blocklist) قرار دهد؛ بنابراین ایمیلهای شما به دلیلی که خودتان مسبب آن نبودهاید، به پوشه اسپم میروند. ارائهدهندگانی که با سوءاستفاده برخورد میکنند، محدودههای تمیزتری دارند. اگر ایمیل برای شما اهمیت دارد، در این مورد پرسوجو کنید.
آنچه یک همسایه متخاصم نمیتواند انجام دهد و موارد نادری که میتواند
مشتری دیگری که روی همان میزبان (host) قرار دارد، هیچ راه دسترسی به فایلهای شما ندارد. آنها نمیتوانند پردازشهای شما را ببینند، دیسک شما را mount کنند یا یک shell روی سرور شما باز کنند، زیرا هیچکدام از این موارد در داخل ماشین مجازی آنها وجود ندارد. یک استثنا ارزش ذکر کردن دارد: شبکه خصوصی ارائهدهنده (provider private network) را به عنوان شبکهای در نظر بگیرید که با غریبهها به اشتراک میگذارید و به جای فرض کردن نامرئی بودن ترافیک، آنچه را که از آن عبور میکند رمزنگاری کنید.
فرار از هایپروایزر (Hypervisor escape) واقعی است. یک باگ در لایه مجازیسازی میتواند به کد داخل یک guest اجازه دهد به host دسترسی پیدا کند و از host به تمام guestهای دیگر روی آن برسد. این باگها کشف، با یک شناسه CVE (آسیبپذیریها و مواجهههای رایج) منتشر و وصله میشوند؛ ارائهدهندگان خدمات میزبانی نیز آنها را بهسرعت وصله میکنند، زیرا کل کسبوکار آنها بر پایه آن لایه استوار است. استفاده از چنین باگی نیازمند یک اکسپلویت فعال برای نسخه خاصی از هایپروایزر است که هزینه بسیار بالایی برای صرف کردن روی یک اکانت میزبانی کوچک دارد.
کانالهای جانبی بین guestها (Cross guest side channels) نیز واقعی هستند. اینها خانواده Spectre و Meltdown هستند که از کشهای مشترک پردازنده برای استنتاج مقادیر کمی از دادهها در آن سوی مرزهای امنیتی سوءاستفاده میکنند. بهروزرسانیهای میکروکد و هسته (kernel) این موارد را کاهش میدهند و نرخ نشت داده در پژوهشهای منتشرشده بسیار ناچیز است. موارد منتشرشده بیشتر نمایشهای تحقیقاتی هستند تا حملات گسترده. ریسک صفر نیست، اما بههیچوجه در صدر فهرست مواردی که به شما آسیب میرسانند قرار ندارد.
جایی که وظیفه ارائهدهنده پایان مییابد و وظیفه شما آغاز میشود
ارائهدهنده مسئول ساختمان، سختافزار میزبان، هایپروایزر و هسته میزبان، شبکه فیزیکی و پنل کنترلی است که میتواند سرور شما را روشن، خاموش، بازسازی یا از آن snapshot تهیه کند. اگر هر یک از این موارد دچار مشکل شود، رفع آن بر عهده آنهاست.
شما مسئول همه چیز از سیستمعامل به بالا هستید. این یعنی بستههایی که نصب میکنید، پورتهایی که باز میگذارید، حسابها و کلیدهایی که اجازه ورود دارند، بهروزرسانیهایی که اعمال میکنید، نسخههای پشتیبان و کد برنامه خودتان. اکثر طرحهای VPS مدیریتنشده (unmanaged) هستند؛ این یعنی هیچکس سرور شما را وصله (patch) نمیکند و هیچ تیکت پشتیبانی این کار را برای شما انجام نخواهد داد. مطالعه تفاوت سرویسهای مدیریتشده و مدیریتنشده پیش از خرید ارزشمند است، زیرا تعیین میکند چه بخشی از این فهرست بر عهده شماست.
یک بخش از مسئولیت شما بهراحتی فراموش میشود: خودِ پنل کنترل میزبانی. هر کسی که به آن حساب دسترسی داشته باشد، میتواند سرور شما را بازسازی کند یا دیسک شما را به یک سیستم نجات (rescue system) متصل کند، بدون اینکه نیازی به دانستن رمز عبور از داخل سرور داشته باشد. احراز هویت دو مرحلهای (2FA) را در حساب میزبانی فعال کنید و از آن رمز عبور در هیچ جای دیگری استفاده نکنید.
آیا ارائهدهندهٔ خدمات میزبانی میتواند دادههای شما را ببیند؟
بله، در اصل اینطور است و این محدودیت صادقانهٔ چیزی است که یک VPS در اختیار شما میگذارد. ایمیج دیسک شما روی فضای ذخیرهسازی ارائهدهنده قرار دارد. کنسول آنها دسترسی در سطح صفحهٔ نمایش به ماشین مجازی شما فراهم میکند. حالت Rescue میتواند سیستمعامل دیگری را بوت کند در حالی که دیسک شما به آن متصل است. یک VPS شما را در برابر سایر مشتریان محافظت میکند، اما ارائهدهنده خارج از این تعهد باقی میماند.
اگر دادههایی دارید که باید برای میزبان غیرقابلخواندن باقی بمانند، آنها را پیش از نوشتن در برنامهٔ خود رمزنگاری کنید. رمزنگاری کامل دیسک (Full disk encryption) در داخل سیستمعامل مهمان، در برابر کپیشدن ایمیج در حالت سکون (at rest) کمک میکند، اما کلید رمزنگاری باید در حین اجرای سرور در حافظه باقی بماند، بنابراین این کار ارائهدهنده را از دایرهٔ دسترسی خارج نمیکند. همین سطح از اعتماد در مورد یک سرور اختصاصی که بهتنهایی اجاره میکنید نیز صدق میکند، با این تفاوت که یک لایهٔ اشتراکی کمتر وجود دارد.
چه چیزی واقعاً باعث نفوذ به یک VPS میشود
سرویسی که روی تمام اینترفیسها گوش میدهد. دیتابیسها، کشها، صفهای پیام و پنلهای مدیریتی اغلب بهصورت پیشفرض روی 0.0.0.0 تنظیم میشوند؛ این یعنی روی تمام اینترفیسهای شبکه، از جمله اینترفیس عمومی. اسکنهای اینترنتی بهصورت مداوم و خودکار انجام میشوند، بنابراین یک IP جدید تنها چند دقیقه پس از آنلاین شدن، اولین درخواستهای ناخواسته را دریافت میکند. Redis بدون رمز عبور، یک نود Elasticsearch بدون احراز هویت، Docker API باز روی پورت 2375 و پنلهای مدیریتی که هنوز از نام کاربری و رمز عبور پیشفرض استفاده میکنند، همگی از این طریق توسط اسکنرهایی پیدا میشوند که حتی نمیدانند شما چه کسی هستید. اگر سرویس فقط به ماشین محلی نیاز دارد، آن را روی 127.0.0.1 تنظیم کنید و بقیه دسترسیها را در فایروال مسدود کنید.
Docker که فایروال شما را دور میزند. انتشار پورت یک کانتینر، قوانین NAT (ترجمه آدرس شبکه) ایجاد میکند که پیش از قوانین ufw (فایروال ساده) ارزیابی میشوند. بنابراین یک کانتینر میتواند از طریق اینترنت در دسترس باشد، در حالی که ufw status نشان میدهد آن پورت مسدود است. این موضوع برای کسانی که تمام مراحل دیگر را بهدرستی انجام دادهاند، مشکلساز میشود. مطالعه دلیل نادیده گرفتن ufw توسط پورتهای Docker پیش از انتشار پورت کانتینر توصیه میشود.
SSH با رمز عبور فعال. اگر /var/log/auth.log را در هر سرور عمومی بخوانید، خطوطی مانند Failed password for root from 203.0.113.10 port 54312 ssh2 را میبینید که شبانهروز هزاران بار تکرار میشوند. رباتها با استفاده از نامهای کاربری و رمزهای عبور رایج تلاش میکنند وارد شوند. ورود با رمز عبور به همراه یک حساب root که اجازه ورود دارد، تمام چیزی است که یک مهاجم نیاز دارد. استفاده از کلید (Key) و غیرفعال کردن ورود کاربر root، این ترافیک را به نویز بیاهمیتی تبدیل میکند که میتوانید آن را نادیده بگیرید.
استفاده از یک کلید خصوصی در همه جا. کپی کردن یک کلید واحد روی تمام لپتاپها و سرورها به این معناست که با سرقت یک لپتاپ، همه چیز باز میشود. کلیدهای SSH منقضی نمیشوند، بنابراین کلیدی که دو سال پیش به یک پیمانکار دادهاید، هنوز کار میکند. یک کلید برای هر شخص و هر ماشین هزینهای ندارد و دسترسی یک کلید سرقتشده را محدود میکند.
بستههایی که بهروزرسانی نشدهاند. یک CVE منتشرشده علیه وبسرور یا فریمورک برنامهنویسی شما، مجموعهای از دستورالعملهای عمومی برای نفوذ است و اسکنرها ظرف چند روز شروع به تست آن میکنند. بهروزرسانیهای امنیتی ارزانترین دفاع موجود هستند و میتوانند بهصورت خودکار اجرا شوند: به بهروزرسانیهای امنیتی خودکار در Ubuntu مراجعه کنید.
نشت اسرار (Secrets). رمزهای عبور دیتابیس و کلیدهای API در فایلهای .env قرار دارند و این فایلها ممکن است در یک مخزن عمومی commit شوند یا توسط وبسروری که به دایرکتوری اشتباه اشاره میکند، سرو شوند. هر چیزی که در context یک دستیار کدنویسی هوش مصنوعی قرار میگیرد نیز ممکن است در لاگها نشت کند که موضوعی جداگانه است: دور نگه داشتن اسرار از دسترس هوش مصنوعی.
اجرای همه چیز با دسترسی root. وقتی برنامه شما با دسترسی root اجرا میشود، یک باگ در آن میتواند کل ماشین را در اختیار مهاجم قرار دهد، زیرا هیچ مرز داخلی در سرور برای جلوگیری از گسترش نفوذ وجود ندارد.
سهم شما از مسئولیت
هیچکدام از موارد زیر مربوط به وظایف هایپروایزر نیست. تمام این مسئولیتها در سمت شما قرار دارد و تعیینکننده امنیت VPS شماست.
- ساعت اول را بهدرستی سپری کنید: ده دقیقه اول در یک VPS جدید شامل ایجاد کاربر غیر root و تنظیم فایروال است.
- دسترسی از راه دور را محدود کنید: ایمنسازی SSH روی VPS.
- پورتهایی که استفاده نمیکنید را ببندید: اصول اولیه فایروال ufw.
- به هر سرویس فقط دسترسیهای مورد نیازش را بدهید: کاربران با حداقل دسترسی روی VPS.
- حملات brute force برای ورود را کند کنید: استفاده از fail2ban در Ubuntu 24.04.
- از بکآپهایی نگهداری کنید که حداقل یکبار آنها را بازیابی کردهاید: بکآپگیری با restic برای VPS.
سهم ارائهدهنده خدمات تا زمانی که سرور شما بوت میشود، انجام شده است. سهم شما در روز اول حدود یک ساعت و پس از آن ماهانه چند دقیقه زمان میبرد. اگر هنوز در حال مقایسه گزینهها هستید، VPS واقعاً چیست مبانی زیربنایی تمام این موارد را پوشش میدهد.
FAQ
آیا مشتری دیگری روی همان سرور فیزیکی میتواند فایلهای من را بخواند؟
خیر، در یک KVM VPS این اتفاق نمیافتد. سرور شما یک ماشین مجازی با هسته (kernel) و دیسک مجازی اختصاصی خود است، بهعلاوه بخشی از حافظه فیزیکی که میزبان به آن اختصاص میدهد و پردازنده هرگونه دسترسی خارج از آن محدوده را مسدود میکند. هیچ فایلسیستم مشترکی بین مهمانها وجود ندارد، بنابراین مجوزهای فایل در سرور یک همسایه، هیچ معنایی در سرور شما ندارند. پلنهای مبتنی بر کانتینر مانند OpenVZ و LXC از هسته میزبان بهصورت مشترک استفاده میکنند و مرز ضعیفتری دارند، بنابراین بررسی کنید که چه نوع سرویسی خریداری میکنید.
آیا یک VPS امنتر از هاست اشتراکی است؟
از نظر ایزولهسازی، بله. در هاست اشتراکی، سایتهای بسیاری درون یک سیستمعامل اجرا میشوند و تنها مرز موجود، مجوزهای فایل است؛ بنابراین یک اشتباه در حساب کاربری دیگر گاهی میتواند فایلها را در معرض دید قرار دهد. در یک VPS، مرز یک ماشین مجازی است. تفاوت در اینجاست که هاست اشتراکی توسط میزبان وصله (patch) میشود، در حالی که یک VPS مدیریتنشده توسط شما وصله میشود. یک VPS تنها در صورتی امنتر است که شما واقعاً بهروزرسانیها را اعمال کنید و پورتها را ببندید.
آیا ارائهدهنده هاستینگ من میتواند دادههایم را بخواند؟
در اصل بله، و هیچ محصول VPS این موضوع را تغییر نمیدهد. ایمیج دیسک روی سختافزار ارائهدهنده ذخیره میشود، کنسول دسترسی در سطح صفحه نمایش به ماشین در حال اجرا میدهد و حالت rescue میتواند سیستم متفاوتی را با دیسک متصلشده به شما بوت کند. اگر قرار است برخی دادهها برای میزبان غیرقابل خواندن باقی بمانند، آنها را پیش از نوشتن در برنامه خود رمزنگاری کنید. رمزنگاری دیسک در داخل مهمان نیز کلید را هنگام اجرای سرور در حافظه نگه میدارد، بنابراین ارائهدهنده را از دایره اعتماد حذف نمیکند.
رایجترین روش برای نفوذ به یک VPS چیست؟
با اختلاف زیاد، یک سرویس در معرض دید یا ورود ضعیف SSH. اسکنرهای خودکار بهطور مداوم تمام آدرسهای IP عمومی را بررسی میکنند، بنابراین یک دیتابیس که به 0.0.0.0 متصل شده و رمز عبور ندارد، یا یک پنل مدیریتی که با اعتبارنامههای پیشفرض رها شده، در عرض چند دقیقه پیدا میشود، نه چند ماه. /var/log/auth.log روی هر سرور عمومی بخش SSH آن را نشان میدهد: خطوط تکراری Failed password for root از آدرسهایی در سراسر جهان. فرار از هایپروایزر (Hypervisor escape) وجود دارد، اما آنها کارهای تحقیقاتی هستند که اهداف با ارزش بالا را نشانه میگیرند، نه علت نفوذهای معمولی.