هل استضافة VPS آمنة؟ مخاطر الإعداد الذي تتحكم فيه

هل استضافة VPS آمنة؟ الإجابة المختصرة

نعم. استضافة VPS آمنة للعمل الذي يستأجرها معظم الأشخاص من أجله، وهي تحسّن فعلي مقارنةً بالاستضافة المشتركة. إن VPS (خادم خاص افتراضي) هو آلة افتراضية لها kernel خاص بها، وذاكرة خاصة بها، وقرص خاص بها، وحسابات مستخدمين خاصة بها. ويعزل hypervisor الذي يشغّلها العملاء الآخرين عن هذه الموارد الأربعة. ولا يستطيع الشخص الذي يستأجر الخادم المجاور لخادمك على الجهاز الفعلي نفسه قراءة ملفاتك، أو عرض عملياتك، أو تسجيل الدخول إلى خادمك، أو رؤية حركة مرور شبكتك.

للإجابة الصريحة جانبان. يملك مزوّد الخدمة العتاد وhypervisor. وأنت تملك كل ما يوجد داخل آلتك الافتراضية، ومن هنا تبدأ تقريباً كل حادثة فعلية. تتعرض الخوادم للاختراق بسبب منفذ مفتوح، أو كلمة مرور SSH ضعيفة، أو حزمة لم يحدّثها أحد، أو سر موجود في ملف نُشر. ونادراً جداً ما يحدث الاختراق عبر hypervisor.

ما الذي يعزله الـhypervisor فعلياً

الـhypervisor هو البرنامج الذي يشغّل الأجهزة الافتراضية على مضيف فعلي واحد. في VPS يعمل بـKVM ‏(KVM تعني kernel based virtual machine، وهي التقنية القياسية على مضيفي Linux)، يكون خادمك جهازاً افتراضياً كاملاً. ويُقلع باستخدام kernel خاص به. يخصص المضيف له نطاقاً ثابتاً من الذاكرة الفعلية، وترفض وحدة إدارة ذاكرة المعالج أي وصول خارج هذا النطاق. لذلك لا يمكن للتعليمات البرمجية التي تعمل في guest آخر الوصول إلى ذاكرتك العشوائية مطلقاً. لا يوجد نظام ملفات مشترك ولا جدول مستخدمين مشترك، لذلك لا تؤثر أذونات الملفات على خادم مجاور في خادمك.

تعمل الاستضافة المشتركة بطريقة مختلفة. توجد مواقع كثيرة داخل نظام تشغيل واحد، وتحت web server واحد ونسخة PHP واحدة، على شكل حسابات مستخدمين عادية. ويكون الحد الفاصل الوحيد هو أذونات الملفات. لذلك يمكن لخطأ في الأذونات، أو لإضافة ضعيفة تعمل كمستخدم يملك صلاحية قراءة عدد كبير من الملفات، الوصول إلى ملفات حساب آخر. هذه هي الفجوة التي يغلقها الانتقال من الاستضافة المشتركة إلى VPS.

تحقق مما تشتريه، لأن بعض الخطط التي تُباع على أنها VPS ليست أجهزة افتراضية. تشارك الخطط القائمة على الحاويات (OpenVZ وLXC وVirtuozzo) kernel الخاص بالمضيف، وتعزل العملاء باستخدام namespaces وcgroups بدلاً من المحاكاة الافتراضية العتادية. وهذا حد فاصل أضعف، لأن وجود خلل في kernel على المضيف يعني وجود خلل في kernel على خادمك أيضاً. ولا يمكنك كذلك تحميل kernel modules على هذه الخطط، ما يمنع تشغيل بعض البرامج. يُعد KVM الخيار الافتراضي الأكثر أماناً. اسأل عن التقنية التي ستحصل عليها قبل الدفع.

ما الذي يمكن أن يسببه لك الجار المزعج

تكلفك مشاركة خادم فعلي جزءاً من السرعة، وهذا هو كل ما تكلفك إياه. تشترك الأجهزة الافتراضية على الجهاز نفسه في المعالج الفعلي والأقراص. عندما يكون المعالج مشغولاً بمعالجة أعمال عميل آخر، تنتظر وحدة المعالجة الافتراضية الخاصة بك، ويعرض Linux مدة هذا الانتظار باسم steal time: الحقل %st في top وvmstat. إذا بقيت steal time أعلى من بضعة بالمئة لساعات، فهذا يعني أن الخادم الفعلي يعاني من تحميل زائد. لا يعني ذلك أن أحداً يقرأ بياناتك. الحل هو اختيار خطة أخرى أو مزود آخر، ويمكنك قياس المعالج والقرص اللذين حصلت عليهما فعلياً قبل اتخاذ القرار.

هناك تأثير واحد بين العملاء يستحق معرفته، لكنه ليس ثغرة أمنية. إذا أرسلت البريد الإلكتروني من VPS، فسيكون عنوان IP الخاص بك ضمن نطاق يستخدمه عملاء آخرون أيضاً. قد يؤدي عميل مجاور يرسل رسائل مزعجة إلى إدراج جزء من ذلك النطاق في قائمة حظر، فتصل رسائلك إلى مجلدات البريد العشوائي لسبب لم تتسبب فيه. يحافظ المزودون الذين يراقبون إساءة الاستخدام على نطاقات أنظف. اسأل عن ذلك إذا كان البريد الإلكتروني مهماً لك.

ما الذي لا يستطيع الجار الخبيث فعله، والحالة النادرة التي يستطيع فيها ذلك

لا يملك عميل على الخادم نفسه مساراً إلى ملفاتك. ولا يستطيع رؤية عملياتك، أو تركيب قرصك، أو فتح shell على خادمك، لأن أياً من هذه الأشياء لا يوجد داخل جهازه الافتراضي. توجد استثناءات واحدة تجدر الإشارة إليها: تعامل مع أي شبكة خاصة يوفّرها المزوّد على أنها شبكة تشاركها مع غرباء، وشفّر البيانات التي تعبرها بدلاً من افتراض أنها غير مرئية.

تجاوزات طبقة Hypervisor حقيقية. يمكن لخلل في طبقة المحاكاة الافتراضية أن يتيح للتعليمات البرمجية داخل جهاز ضيف الوصول إلى المضيف، ثم الوصول من المضيف إلى كل جهاز ضيف عليه. تُكتشف هذه الأخطاء وتُنشر مع معرّف CVE ‏(Common Vulnerabilities and Exposures)، ثم تُرقّع. يسرّع مزوّدو الاستضافة ترقيعها لأن أعمالهم بالكامل تعتمد على هذه الطبقة. ويتطلب استغلال أحدها وجود exploit يعمل مع إصدار محدد من Hypervisor، وهذا مورد مكلف لا يُنفق عادةً على حساب استضافة صغير.

القنوات الجانبية بين الأجهزة الضيفة حقيقية أيضاً. وهي تنتمي إلى عائلة Spectre وMeltdown، وتستغل ذاكرات المعالج المخبئية المشتركة لاستنتاج كميات صغيرة من البيانات عبر حد فاصل. تحدّثات microcode وkernel تخفف هذه المخاطر، ومعدلات التسريب في الأبحاث المنشورة ضئيلة. والحالات المنشورة عبارة عن عروض بحثية، وليست هجمات واسعة النطاق. الخطر ليس صفراً. لكنه ببساطة لا يقترب من صدارة قائمة الأشياء التي ستلحق بك الضرر.

أين تنتهي مسؤولية مزود الخدمة وتبدأ مسؤوليتك

يتولى مزود الخدمة مسؤولية المبنى، وعتاد الخادم المضيف، والـhypervisor ونواة الخادم المضيف، والشبكة الفعلية، ولوحة التحكم التي يمكنها بدء خادمك وإيقافه وإعادة بنائه وإنشاء snapshot له. إذا تعطل أي من ذلك، فعلى مزود الخدمة إصلاح العطل.

أنت مسؤول عن كل شيء بدءاً من نظام التشغيل وما فوقه. يشمل ذلك الحزم التي تثبتها، والمنافذ التي تتركها مفتوحة، والحسابات والمفاتيح التي يمكنها تسجيل الدخول، والتحديثات التي تطبقها، ونسخك الاحتياطية، وتعليمة التطبيق البرمجية الخاصة بك. معظم خطط VPS غير مُدارة، وهذا يعني أن لا أحد يثبّت التحديثات الأمنية لخادمك نيابةً عنك، ولن تنفذها تذكرة دعم. تستحق الاختلافات بين الخدمات المُدارة وغير المُدارة القراءة قبل الشراء، لأنها تحدد مقدار هذه المسؤوليات الذي يقع عليك.

هناك جزء من مسؤوليتك يسهل نسيانه: لوحة التحكم الخاصة بالاستضافة نفسها. يستطيع أي شخص يملك بيانات تسجيل الدخول إليها إعادة بناء خادمك أو إرفاق قرصك بنظام إنقاذ، من دون معرفة أي كلمة مرور داخل الخادم. فعّل المصادقة الثنائية (2FA) في حساب الاستضافة، ولا تعِد استخدام كلمة المرور تلك في أي مكان آخر.

هل يستطيع مزود الاستضافة رؤية بياناتك؟

نعم، من حيث المبدأ. وهذا هو الحد الفعلي الصريح لما يقدمه VPS. توجد صورة القرص لديك على مساحة التخزين التابعة للمزود. وتمنحك وحدة التحكم الخاصة به وصولاً على مستوى الشاشة إلى جهازك الافتراضي. ويمكن لوضع الإنقاذ إقلاع نظام مختلف مع إرفاق قرصك به. يحميك VPS من العملاء الآخرين، لكن المزود خارج نطاق هذا الالتزام.

إذا كانت لديك بيانات يجب أن تظل غير قابلة للقراءة من جانب المضيف، فشفّرها داخل تطبيقك قبل كتابتها. تساعد التشفيرة الكاملة للقرص داخل النظام الضيف في مواجهة نسخ صورة القرص وهي غير قيد الاستخدام، لكن المفتاح يجب أن يبقى في الذاكرة أثناء تشغيل الخادم، ولذلك لا تستبعد المزود من المعادلة. وينطبق مستوى الثقة نفسه على خادم مخصص تستأجره بمفردك، مع طبقة مشتركة واحدة أقل.

ما الذي يؤدي فعلياً إلى اختراق VPS

خدمة تستمع على كل الواجهات. غالباً ما تربط قواعد البيانات وذاكرات التخزين المؤقت وقوائم انتظار الرسائل ولوحات الإدارة نفسها بالعنوان 0.0.0.0 افتراضياً، ما يعني كل واجهة شبكة، بما فيها الواجهة العامة. المسح على مستوى الإنترنت مستمر ومؤتمت، لذلك يتلقى عنوان IP جديد أول فحص غير مطلوب خلال دقائق من اتصاله بالإنترنت. تُكتشف بهذه الطريقة خدمات Redis التي لا تستخدم كلمة مرور، وعقد Elasticsearch غير الموثقة، وواجهة Docker API المفتوحة على المنفذ 2375، ولوحة الإدارة التي ما زالت تستخدم بيانات تسجيل الدخول الافتراضية، وذلك بواسطة ماسح لا يعرف شيئاً عن هويتك. اربط الخدمة بالعنوان 127.0.0.1 عندما تحتاج إليها الآلة المحلية فقط، واحظر بقية الاتصالات في جدار الحماية.

تجاوز Docker لجدار الحماية. يؤدي نشر منفذ حاوية إلى كتابة قواعد ترجمة عناوين الشبكة (NAT)، وتُقيَّم هذه القواعد قبل قواعد ufw (جدار الحماية غير المعقد)، لذلك يمكن الوصول إلى الحاوية من الإنترنت بينما ufw status يقول إن ذلك المنفذ محظور. يفاجئ هذا الأمر من نفّذ كل شيء آخر بطريقة صحيحة. من المفيد قراءة سبب تجاهل منفذ Docker لقواعد ufw قبل نشر منفذ حاوية.

تفعيل كلمات المرور في SSH. اقرأ /var/log/auth.log على أي خادم عام، وستجد أسطراً مثل Failed password for root from 203.0.113.10 port 54312 ssh2، بالآلاف، ليلاً ونهاراً. تجرّب الروبوتات أسماء المستخدمين الشائعة وكلمات المرور الشائعة. يكفي المهاجم أن يكون تسجيل الدخول بكلمة مرور مفعّلاً، وأن يقبل حساب root عمليات تسجيل الدخول. يؤدي السماح بالمفاتيح فقط، مع تعطيل تسجيل دخول root، إلى تحويل هذه الاتصالات إلى ضوضاء يمكنك تجاهلها.

استخدام مفتاح خاص واحد في كل مكان. يعني نسخ مفتاح واحد إلى كل حاسوب محمول وكل خادم أن حاسوباً محمولاً مسروقاً واحداً يفتح الوصول إلى كل شيء. كما أن مفاتيح SSH لا تنتهي صلاحيتها، لذلك يظل المفتاح الذي مُنح لمتعاقد قبل عامين صالحاً حتى اليوم. لا تكلّفك ممارسة مفتاح واحد لكل شخص ولكل آلة شيئاً، وتحدّ من نطاق ما يمكن لمفتاح مسروق واحد الوصول إليه.

حزم لم يحدّثها أحد. يُعدّ CVE منشور ضد خادم الويب أو إطار عمل التطبيق مجموعة تعليمات متاحة للعامة، وتبدأ أدوات المسح في اختبار وجوده خلال أيام. تُعدّ التحديثات الأمنية أرخص وسيلة دفاع متاحة، ويمكن تشغيلها تلقائياً: راجع التحديثات الأمنية التلقائية على Ubuntu.

سرّ متسرّب. توجد كلمات مرور قواعد البيانات ومفاتيح API في ملفات .env، ثم تُضاف هذه الملفات إلى مستودع عام، أو يخدمها خادم ويب موجه إلى المجلد الخطأ. كما يمكن لأي شيء تلصقه في سياق وكيل برمجة يعمل بالذكاء الاصطناعي أن ينتهي به الأمر في سجل، وهذا موضوع مستقل: إبقاء الأسرار بعيدة عن نطاق وصول الوكيل.

تشغيل كل شيء بصفة root. عندما يعمل تطبيقك بصفة root، فإن خطأ واحداً فيه يمنحه السيطرة على الآلة بأكملها، لأنه لم يعد هناك حد داخل الخادم يمنعه من الانتشار.

النصف الذي يقع عليك

لا شيء مما يلي من مهام الـhypervisor. كل ذلك يقع ضمن مسؤوليتك، وهي المسؤولية التي تحدد ما إذا كان VPS آمناً.

• نفّذ إجراءات الساعة الأولى بشكل صحيح: يشرح أول عشر دقائق على VPS جديد كيفية إنشاء مستخدم غير root وإعداد جدار ناري.
• أمِّن الوصول عن بُعد: تقوية SSH على VPS.
• أغلق المنافذ التي لا تستخدمها: أساسيات جدار ufw الناري.
• امنح كل خدمة صلاحيات الوصول التي تحتاج إليها فقط: مستخدمو أقلّ الصلاحيات على VPS.
• أبطئ محاولات تسجيل الدخول بالقوة الغاشمة: إعداد fail2ban على Ubuntu 24.04.
• احتفظ بنسخة احتياطية استعدتَ منها مرة واحدة على الأقل: نسخ احتياطية باستخدام restic لـVPS.

يكون جانب مزود الخدمة منجزاً بالفعل عند إقلاع الخادم. أما جانبك فيستغرق نحو ساعة في اليوم الأول، وبضع دقائق شهرياً بعد ذلك. إذا كنت لا تزال تقارن الخيارات، فيشرح ما هو VPS فعلياً الأساس الذي تقوم عليه كل هذه الإجراءات.

FAQ

هل يستطيع عميل آخر على الخادم الفعلي نفسه قراءة ملفاتي؟

لا، ليس على VPS يعمل بتقنية KVM. خادمك آلة افتراضية لها kernel خاص بها وقرص افتراضي خاص بها، إضافة إلى منطقة من الذاكرة الفعلية يخصصها لها المضيف. ويمنع المعالج أي وصول خارج هذه المنطقة. لا يوجد نظام ملفات مشترك بين الضيوف، لذلك لا تكون لصلاحيات الملفات داخل خادم مجاور أي دلالة داخل خادمك. أما الخطط القائمة على الحاويات مثل OpenVZ وLXC فتشترك في kernel المضيف وتوفر عزلاً أضعف، لذلك تحقّق من النوع الذي تشتريه.

هل VPS أكثر أماناً من الاستضافة المشتركة؟

نعم، من ناحية العزل. في الاستضافة المشتركة، تعمل مواقع كثيرة داخل نظام تشغيل واحد، ويكون الحد الفاصل الوحيد هو صلاحيات الملفات. لذلك قد يكشف خطأ في حساب آخر الملفات أحياناً. أما في VPS، فالحد الفاصل هو آلة افتراضية. والمقابل هو أن المضيف يثبّت التحديثات في الاستضافة المشتركة، بينما تثبّتها أنت في VPS غير المُدار. يكون VPS أكثر أماناً فقط إذا ثبّت التحديثات فعلياً وأغلقت المنافذ.

هل يستطيع مزود الاستضافة قراءة بياناتي؟

نعم، من حيث المبدأ، ولا يغيّر أي منتج VPS هذه الحقيقة. تُخزَّن صورة القرص على أجهزة المزود، وتوفر وحدة التحكم وصولاً على مستوى الشاشة إلى الآلة قيد التشغيل، كما يمكن لوضع الإنقاذ إقلاع نظام مختلف مع إرفاق قرصك به. إذا كانت بعض البيانات يجب أن تبقى غير قابلة للقراءة بالنسبة إلى المضيف، فشفّرها داخل تطبيقك قبل كتابتها. تبقى مفتاح التشفير داخل الذاكرة أثناء تشغيل الخادم حتى عند استخدام تشفير القرص داخل الضيف، لذلك لا يزيل ذلك المزود من دائرة الثقة.

ما الطريقة الأكثر شيوعاً لاختراق VPS؟

خدمة مكشوفة أو تسجيل دخول SSH ضعيف، وبفارق كبير. تفحص الماسحات الآلية كل عنوان IP عاماً باستمرار، لذلك يُكتشف اتصال قاعدة بيانات مربوط بـ0.0.0.0 من دون كلمة مرور، أو لوحة إدارة تُركت ببيانات الاعتماد الافتراضية، خلال دقائق لا أشهر. يوضح /var/log/auth.log على أي خادم عام جانب SSH من المشكلة: أسطر Failed password for root متكررة من عناوين في أنحاء العالم. توجد أساليب لتجاوز عزل hypervisor، لكنها أعمال بحثية متقدمة تستهدف أهدافاً عالية القيمة، وليست سبب الاختراقات العادية.