معهد ماساتشوستس للتكنولوجيا. محاضرة رقم 6.858. "أمن أنظمة الكمبيوتر." نيكولاي زيلدوفيتش ، جيمس ميكنز. 2014 سنة
أمان أنظمة الكمبيوتر هي دورة حول تطوير وتنفيذ أنظمة الكمبيوتر الآمنة. تغطي المحاضرات نماذج التهديد ، والهجمات التي تهدد الأمن ، وتقنيات الأمان بناءً على العمل العلمي الحديث. تشمل الموضوعات أمان نظام التشغيل (OS) ، والميزات ، وإدارة تدفق المعلومات ، وأمان اللغة ، وبروتوكولات الشبكة ، وأمان الأجهزة ، وأمان تطبيقات الويب.
المحاضرة 1: "مقدمة: نماذج التهديد"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 2: "السيطرة على هجمات القراصنة"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 3: "تجاوزات العازلة: المآثر والحماية"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 4: "فصل الامتيازات"
الجزء 1 /
الجزء 2 /
الجزء 3 لذا ، فإن رسمنا يصور "عمل فني" ، حاول مبدعوها حمايته من التهديدات. في حالتهم ، أعتقد أنهم كانوا قلقين للغاية ، لأنه من خلال إنشاء
موقع المواعدة
okcupid.com ، أرادوا حقًا التأكد من أن سمعة مستخدمي الموقع لن تتأثر بالكشف عن البيانات الشخصية. من محادثة مع أحد مطوري الموقع الذين كتبوا المقالة حول هذا ، من المعروف أنهم لم يتعرضوا للخطر بالفعل. على الأقل ، لم يحدث تسرب للبيانات بسبب استخدام بنية
OKWS وجزئياً بسبب مراقبة النشاط الضار.
سبب عدم تقسيم الأشخاص لتطبيقاتهم إلى مكونات أصغر هو أن هذه العملية تستغرق بعض الجهد. من الضروري تحديد جميع أجزاء الكود ، وتحديد الواجهات الواضحة بينها ، وتحديد البيانات التي يجب على كل مكون الوصول إليها. إذا قررت تنفيذ وظيفة جديدة ، فسيتعين عليك تغيير البيانات التي يمكن لكل مكون من مكونات البرنامج الوصول إليها ، ومنحها امتيازات جديدة أو تحديد بعضها ، وما إلى ذلك. لذا فهذه عملية تستغرق وقتًا طويلاً.

دعنا نحاول فهم كيفية تصميم خادم الويب ، وربما تكون إحدى الطرق للقيام بذلك هي تتبع كيفية معالجة طلب http بواسطة خادم
OKWS . لذا ، على غرار ما هو موضح في الشكل السابق ، لدينا متصفح ويب يريد الانتقال إلى
okcupid.com . تخيل مطورو مشروع الموقع أنه سيكون لديهم مجموعة من الأجهزة ، ولكننا سننظر فقط في واجهة الموقع حيث ستعمل
OKWS ، وجهاز آخر في الخلفية سيخزن قاعدة البيانات. يستخدم هذا الجهاز الثاني
MySQL لأنه برنامج جيد للعديد من المهام. إنهم يريدون حماية هذه البيانات حقًا لأنه من الصعب حقًا الوصول إلى قرص
خام أو قاعدة بيانات تحتوي على مخططات بيانات خام أولية.
لذا ، كيف يعمل الطلب ، كيف تتم معالجة الطلب بواسطة خادم
OKWS ؟ أولاً ، يصل ومعالجته بعملية تسمى
okd لمرسل
OKWS . يتحقق من أنه يسأل عن هذا الطلب ، ثم يقوم بأمرين. نظرًا لأنك قد تحتاج إلى تسجيل هذا الطلب أولاً ، فإنه يعيد توجيهه إلى مكون يسمى
oklogd ، وبعد ذلك ستحتاج إلى إنشاء بعض القوالب ، وقد يكون من الضروري إنشائها حتى قبل وصول الطلب. ويقوم
بعمل مكون آخر يسمى
pubd .

وأخيرًا ، هناك خدمة محددة يتم إرسال هذا الطلب إليها ، لذلك في
okd يوجد جدول لمجموعة الخدمات التي يدعمها. من المفترض أن يأتي هذا الطلب إلى إحدى هذه الخدمات ، لذلك بعد مراجعة
okd سيعيد توجيه هذا الطلب إلى عملية خدمة
svc محددة. ستقوم هذه الخدمة بالضبط بما يتطلبه الطلب ، على سبيل المثال ، الاشتراك في النشرة الإخبارية ، أو تجعل من الممكن عرض دليل مستخدمي
ocupid ، باستخدام قاعدة البيانات ، إلخ.
ولهذا ، ربما تحتاج إلى الخدمة لترك معلومات التطبيق في
سجل مكون
oklogd . وفي نهاية اليوم ، عليه أن "يتحدث" إلى قاعدة البيانات. قام منشئو الموقع بتنفيذ عملية "الاتصال" هذه بشكل مختلف قليلاً عما يحدث عادة في
Apache ، حيث يمكنك ببساطة التواصل مع قاعدة البيانات وإصدار استعلامات
SQL التعسفية. لقد توصلوا إلى هذا المفهوم الخاص
بوكيل قاعدة البيانات ،
dbproxy ، الموجود أمام
قاعدة بيانات MySQL ويقبل الطلبات من خدمة
svc لتنفيذها. أعتقد أن هذا التوضيح يوضح بشكل أساسي كيفية عمل
OKWS .

هناك مكون آخر يبدأ كل هذا ، ويسمى
okld ، وهو مسؤول عن بدء جميع العمليات في واجهة خادم الويب هذا. آمل أن تبدو بعض هذه الأشياء مألوفة لك ، لأن هذه هي بالضبط الهندسة المعمارية التي تم التفكير فيها في المختبر. يبدو أنه تصميم جيد. لم يكن لديك
pubd و
logd و
dbproxy في LR ، ولكن كان لديك
okd و
svc . هل لديك أسئلة حول
OKWS ؟
الجمهور: هل فهمنا بشكل صحيح أن
dbproxy لا يقبل استعلامات SQL ، ولكن نوعًا مختلفًا من الاستعلام؟
الأستاذ: نعم صحيح! كيف تبدو هذه الواجهة؟ لا يصفون ذلك بتفصيل كبير ، ولكن هناك شيء واحد يمكنك القيام به مع هذا
dbproxy هو تخزين الكثير من الحجج لقوالب استعلام
SQL . على سبيل المثال ، يمكن أن يكون نموذج استعلام بحث لأصدقائك ، وتحديدهم حسب
المعرّف .

افترض أن هناك قالبًا مثل "حدد
معرف ^ من قائمة أصدقائك ، حيث
^ معرف ="٪ S " . افترض أنك تريد العثور على
Alice بين أصدقائك وإرسال طلب
S ، حيث تكون الحجة
" Alice " . دع تطبيقنا ، المتاح في الواجهة ، يعرف أن
dbproxy جاهز لتنفيذ ثلاثة أنواع من الطلبات نيابة عنه. إذا كنت ترغب في تنفيذ الاستعلام رقم 1 ، وكانت وسيطته
"Alice" ، فإنه يمنحك الوصول إلى قاعدة البيانات.
الجمهور: هل يمكن لمستخدم خارجي على مستوى متصفح الويب إرسال مثل هذا الطلب إلى قاعدة البيانات أم أنه ينطبق فقط على المستخدمين الداخليين للشبكة؟
الأستاذ: نعم ، ربما. فكيف يعمل؟ في الواقع ، من الغريب أن قاعدة البيانات هذه موجودة على جهاز منفصل ، لأنه يمكنك فقط الاتصال
بقاعدة بيانات
OKWS أو بخادم
MySQL ؟ إذن ما الذي يمنع هذا؟
الجمهور: جدار الحماية؟
الأستاذ: نعم ، ربما على مستوى ما. لا يصف المطورون هذا الأمر بتفاصيل أكثر من اللازم ، ولكن ربما توجد بعض الشبكة الداخلية على الجهاز الثاني ، وهناك تبديل بين الواجهة وقاعدة البيانات التي لا يمكن الوصول إليها من العالم الخارجي. في الواقع ، كلا الجهازين على نفس الشبكة ، ولكن هناك جدار حماية
Fw لديه قواعد معينة. ربما هي أنه يمكنك فقط الاتصال بكمبيوتر الواجهة هذا من خلال المنفذ 80 ، ولكن ليس مباشرةً بالخادم الداخلي. هذا هو أحد خيارات الحماية.

آخر ، على الأرجح ، هو أنه عند الاتصال
بوكيل قاعدة بيانات
dbproxy هذا ، تحتاج إلى توفير رمز تشفير 20 بايت أو مفتاح ، وإذا لم تقدمه ،
فسوف يرفض
dbproxy اتصالك. لذا ، القاعدة هي أنك تفتح اتصال TCP ، وترسل 20 بايت ، وإذا كانت خاطئة ، فسيتم إغلاق الاتصال. هذا ، على ما أعتقد ، هو معنى هذا التصميم للنظام.
لذا ، دعنا نحاول معرفة كيف يتم عزل هذه العمليات المختلفة هنا. كيف يمكنك التأكد من أن كل هذه المكونات لا تطغى على بعضها البعض؟
الجمهور: حقوق الجذر المختلفة ومعرفات المستخدم المختلفة؟
البروفيسور: نعم ، يعمل كل من هذه المكونات تقريبًا
كمرجع مختلف ، لذلك هنا ، في وصف النظام ، هناك جدول كامل يصف كل مكون حيث يعمل وبأي شيء. لذا يمكننا أن نكتب أن
okd لها
uid الخاص بها ،
pubd لها
uid الخاصة بها و
oklogd لها
uid الخاص بها.
يعمل
Okld كجذر ، وهو غير ناجح إلى حد ما ، ولكن ربما هذه ليست مشكلة كبيرة. ثم هناك مجموعة كاملة من معرفات المستخدم المعينة ديناميكيًا لكل خدمة ، على سبيل المثال ID 51001 ، إلخ.

وبالتالي ، هذا يضمن أن كل خدمة لا يمكن أن تتداخل مع عمليات الخدمات الأخرى.
يستخدم Chroot أيضًا على نطاق واسع هنا ، لذا فإن بعض هذه المكونات لها حقوق
chroot في أدلة منفصلة. على سبيل المثال ، تم منح
okd و
svc حقوق
chroot الشائعة في بعض الدلائل. لماذا تعتقد أن هذين المكونين لهما منفصل وغير مشترك مع مكونات
chroot الأخرى؟
الجمهور: لأن
okd ليس لها امتيازات الجذر.
البروفيسور: نعم ، ولكن لماذا لا يضعون
pubd و
oklogd والجميع في نفس
الغرفة ؟
الجمهور: هل من الممكن أنه إذا كانت الخدمات بحاجة إلى مشاركة الكثير من البيانات ، فهل يجب عزلها عن بعضها البعض؟
الأستاذ: ربما. أعتقد أنه يجب عليهم مشاركة بعض البيانات ، ولكن هذه البيانات ليست في الملفات ، يتم نقلها من خلال مآخذ من
okd إلى الخدمات. ولكن في الواقع ، لا يخزن أي من هذه المكونات أي شيء مثير للاهتمام في نظام الملفات.
لذلك ، لا يوجد شيء مثير للاهتمام في دليل
chroot ، وأعتقد أن الرجال من
OKWS قرروا ببساطة تقليل النفقات غير المنتجة لـ
chroot ، مثل الحاجة إلى إنشاء نسخة من الدليل. ربما أرادوا أيضًا التخلص من بعض النفقات الإدارية لكل أمر
chroot . ولكن نظرًا لعدم وجود ملفات حقيقية هنا ، فإن كل شيء في محله.
السبب الذي دفع هؤلاء الأشخاص إلى تعيين
جذور مختلفة لمكونات البيئة هو بسبب بعض الأشياء المثيرة للاهتمام. قد تكون هناك قوالب ، ولكن هنا ، ربما ، هناك ملف سجل ، لذلك لن يرغبوا في قراءة ملف السجل عن طريق الخطأ ، وما شابه.
الجمهور: هل تحتوي هذه الخدمات على ملفات ، على سبيل المثال ، مثل
aspx ؟
البروفيسور: كما وصفوا في المقالة ، فإن الخدمة عبارة عن
C ++ ثنائية مجمعة واحدة ، لذلك في الواقع لا توجد ملفات إضافية.
هناك قوالب ، لكنها تنتقل حقًا من خلال هذه الآلية الغريبة: لدى
pubd قوالب في
دليلها ،
وتعرضها في بعض أجهزة ما قبل الكمبيوتر ، ونموذج المنزل في
okd ، وتوفر
okd بالفعل قوالب لجميع الخدمات من خلال مكالمات
RPC . وبالتالي ، فإنهم يجلسون في الذاكرة ، ولكنهم في الواقع لا يمكن الوصول إليهم مباشرة من خلال نظام الملفات. هذا تصميم بجنون العظمة إلى حد ما عندما لا أستطيع حتى قراءة النماذج.
إذن ، ما الفائدة من فصل كل هذه المكونات؟ لماذا نحتاج إلى
oklogd منفصل؟
الجمهور: للقضاء على إمكانية الكتابة فوق المجلة أو قصها؟
البروفيسور: نعم ، لذلك نريد حقًا التأكد من أنه إذا حدث خطأ ما ، فلن تتلف المجلة على الأقل. وبالتالي ، هناك ملف سجل منفصل قابل للكتابة بواسطة هذا
المعرف ، ويتم إرسال جميع رسائل السجل ك
RPC لخدمة السجل هذه. وحتى إذا تم
إتلاف كل شيء آخر ، حسناً ، باستثناء
okld ، فإن المجلة ستبقى سالماً.
الجمهور: ماذا لو وجدت عن طريق الخطأ طريقة لقراءة المجلة ولا ترى ما فعله الآخرون بها؟
البروفيسور: لا ، أعتقد أنه إذا قمت "باختراق" بعض الخدمات أو
الحانة أو أي شيء آخر ، فيمكنك كتابة أي شيء في المجلة. لذلك ، من
المنطقي إنشاء
إدخال منفصل لـ
oklogd . في الواقع ، إن
oklogd عملية منفصلة ، ولا يتم تحديثها فقط من خلال إرفاق الملفات كملف
إلحاق فقط . وبالتالي ، لا يمكن لـ
oklogd إضافة بعض المعلومات الإضافية إلى كل إدخال سجل ، لأنه إذا كان نظام التشغيل يدعم ملف
الإلحاق فقط ، فلن تعرف أن شخصًا ما كتب إلى الملف عند حدوث ذلك. بينما يضع
oklogd طابعًا زمنيًا لكل رسالة ويسمح لك بمعرفة الخدمة التي قامت بالتسجيل أو جاءت من
okd . لذلك ، تحصل بالفعل على معلومات إضافية في ملف السجل هذا لأنه خدمة منفصلة.
وما معنى الانفصال
الجيد ولماذا يجب أن يعمل مع حقوق الجذر؟ أعتقد أن هناك عدة أسباب لذلك.
الجمهور: إذا كنت لا تريد أن يتصرف أي شخص آخر بامتيازات الجذر ، فيجب تفويض وظيفة مصادقة المستخدم
المناسبة .
الأستاذ: نعم. يجب أن يقوم شخص ما بتكوين هذا الشيء بالكامل
uid chroot ، وتحتاج إلى
الجذر لـ
Unix ، لذلك يوفر
okld هذا. هذا أحد الأسباب. هل من شيء آخر؟
الجمهور: تعريف المنفذ 80؟
الأستاذ: نعم بالطبع! عليك ربط الاستماع إلى المنفذ 80 ، وهو أمر
جيد ويوفر أي شيء آخر؟
الجمهور: يكمل فتح ملف سجل
oklogd لأننا لا نريد ترك
oklogd مفتوحًا لمنع الوصول إلى ملف السجل.
الأستاذ: ربما. لكنني لا أعرف ما إذا كان المطورين قد فعلوا ذلك حقًا لأنهم لم ينظروا إلى شفرة المصدر الخاصة بهم. هل تعتقد أن
okld يفتح ملف السجل ويمرر عليه
oklogd ؟ ربما.
الجمهور: لأنه بخلاف ذلك ، يمكن للمهاجم الذي
اخترق oklogd محو السجل بالكامل.
الأستاذ: نعم ، هذا صحيح. ربما تريد فتحه في وضع
الإلحاق ثم تمريره على
oklogd ، ثم لديك المزيد من ضمانات الأمان للسجل. هذا شيء لا يمكنك القيام به بدون امتيازات الجذر.
لذا ، كان لدينا سؤال حول الواجب المنزلي ، ماذا سيحدث عندما يتم "تسريب" الرمز المميز المكون من 20 بايت للوصول إلى قاعدة البيانات. ما الضرر الذي يمكن أن يسببه هذا؟ هل يجب أن نقلق بشأن هذا؟
الجمهور: في هذه الحالة ، يمكن للمهاجم التحكم في خدمة معينة.
الأستاذ: نعم ، لأنك الآن قادر على الاتصال والحصول على جميع قوالب الاستعلام. في الواقع يبدو بسيطا جدا. ربما ستحتاج إلى اختراق أحد هذه المكونات لتتمكن من الاتصال بقاعدة بيانات الخادم أولاً. لذلك أعتقد أنه إذا كان لديك هذا الرمز المميز ويمكنك اختراق أحد هذه المكونات الموضحة في الشكل ، فيمكنك استخدام جميع هذه الاستعلامات.
الآن دعونا نرى كيف يمكن تحسين تصميم
OKWS هذا؟ على سبيل المثال ، قد يكون من الممكن تخصيص وحدة
uid منفصلة لكل مستخدم ، بالإضافة إلى تخصيص
uid منفصل لكل خدمة. هنا ، لكل خدمة ، على سبيل المثال ، الأخبار ، أو البحث عن أصدقاء ، أو إنشاء حساب ،
معرف مستخدم منفصل ، ولكن لا
يتم تمثيل كل مستخدم
OKWS على أنه
Unix uid . في الواقع لا يوجد
معرف مستخدم هنا ، فقط
معرّفات الخدمة موجودة هنا. هل تعتقد أنك بحاجة إلى
معرّف فريد لكل عميل
OKWS ؟
الجمهور: في هذه الحالة ، يتبين أنه إذا قام أحد المستخدمين "باختراق" الخدمة ، فسيتمكن من الوصول إلى جميع بيانات المستخدمين الآخرين لهذا الخادم.
الأستاذ: نعم هذا صحيح!
الجمهور: ولكن إذا كان لديك بالفعل خدمة منفصلة و
dbproxy منفصل لكل مستخدم ، فسيكون من المستحيل الوصول إلى بيانات الآخرين.
البروفيسور: نعم ولكن هل يمكن أن يكون هذا نموذج أقوى؟ أعتقد أن مطوري
OKWS لا يتخذون مثل هذه الخطوة لسببين. الأول هو الأداء. إذا كان لديك بضعة ملايين من مستخدمي موقع
okcupid ، وعدة ملايين من العمليات الجارية وملايين من
dbproxie ، عندها تكون النفقات العامة على الأداء ممكنة. وهذا لن يسمح بتحقيق نفس الأداء الذي
توفره بنية
OKWS الحالية.
الجمهور: يقول وصف
OKWS أن أداء هذا النظام أفضل من الأنظمة الأخرى. كيف تحقق ذلك؟
البروفيسور: أعتقد أن هذا يرجع جزئيًا إلى أنهم قاموا بضبط تصميمهم وفقًا لعبء عمل معين ، بالإضافة إلى أنهم كتبوا كل هذا في
C ++ . البديل هو كتابة بعض الأشياء في
PHP ، ثم من المرجح أن تحقق فوائد على هذه الجبهة.
بالإضافة إلى ذلك ، ليس لديهم العديد من الميزات الموجودة في
Apache . لديها تصميم للأغراض العامة ، لذلك لديها العديد من عمليات العمل ، وإعادة تحميلها من وقت لآخر. هناك العديد من اتصالات
TTP التي تضمن مدة عملية الاتصال وتحافظ على نشاطها. كما أنه يزيد من عدد العمليات التي تعمل على النظام.
تم جعل
Apache أكثر عالمية ويمكنه القيام بكل ما تريد الحصول عليه من خادم الإنترنت ،
ويركز الرجال من
OKWS بشكل أكبر على حل مشاكل معينة.
ولكن أعتقد أن هناك خوادم ويب أخرى هذه
الأيام يمكن أن تتطابق على الأرجح مع أداء
OKWS . على سبيل المثال ،
Nginx هو خادم ويب محسن للغاية يمكنك تشغيله هذه الأيام. إذا كنت تريد تطبيقات عالية الأداء من جانب الخادم ، فربما تريد أن تكون العملية الطويلة مشابهة جدًا لخدمة
OKWS . ولكي يكون لديه آلية لواجهة بوابة
CGI الشائعة السريعة لتوصيل برنامج خارجي بخادم ويب ، أو نوع من البروتوكول يمكن استخدامه على جانب الخادم لتنفيذ ذلك حتى في
Apache أو
Nginx . لذلك ، أعتقد أن العديد من هذه الأفكار ليست حصرية لـ
OKWS ، يمكن تنفيذها في خوادم الويب الأخرى. إنهم ببساطة يظهرون أن تحسين الأمن لا يمنع استخدام هذه "الحيل". أعتقد أنهم بدأوا بمخطط مشابه لـ
Apache ، لكنهم اعتقدوا أنه لن يكون آمنًا بما فيه الكفاية.
لذلك أعتقد أن أحد أسباب عدم رغبة منشئي
OKWS في تقديم امتيازات منفصلة للمستخدمين هو تدهور محتمل في الأداء.

سبب آخر هو أن نموذج التطبيق الكامل "يدور" حول خدمة تحاول الوصول إلى بيانات كل مستخدم ، مثل العثور على أصدقاء في
okcupid أو شخص يمكنك دعوته في موعد. ونتيجة لذلك ، فإن هذا النموذج لعزل المستخدم ليس له معنى كبير ، لأنه في نهاية المطاف ، يجب أن تكون هناك خدمة ترسل طلبًا لها ، وسوف تبحث في جميع البيانات الأخرى للعثور على تطابق لطلبك. لذلك حتى إذا كان لديك معرفات مستخدم أو بعض الآليات لعزلها ، فلا يزال عليك فتح الوصول إلى الخدمة لكل مستخدم.
بالنسبة للخدمات الأخرى ، مثل
Gmail أو
Dropbox ، والتي تركز بشكل أكبر على مستخدم معين ولا توفر إمكانية مفتوحة لمشاركة ملفاتهم ، يمكن أن يوفر عزل المستخدمين المزيد من المزايا. على سبيل المثال ، على خادم
Dropbox يوجد
معرف مستخدم لكل عميل
Dropbox . وإذا كانت هناك عملية تعمل من أجلك وعملية تجري لصالح شخص آخر ، فحتى باستخدام برمجية إكسبلويت ضارة ، فلن تتمكن من الحصول على معلومات الآخرين.
الآن دعونا نرى ما إذا كانت
OKWS تمكنت
حقًا من تحسين الأمان في نموذج الخادم هذا. لتقييم الأمان ، تحتاج إلى النظر في كل مكون من مكونات النظام وتحديد نوع الهجمات التي يمكن أن تضر به.
لنبدأ مع
okd . يمكن مهاجمتها بالطلبات عبر المتصفح ، على سبيل المثال ، مما يؤدي إلى تجاوز سعة المخزن المؤقت. c++, , - ,
okd . ?
: ?
: , , . ?
: , .
: , . , , ,
http , , , . , .
: ?
: , . , , , , ,
match.com . , ,
OkCupid . , - ? ?
: , ,
okd . , ?
: . ,
okd .
: , ?
: ! , , , , , . , , , , . , , . «»
okd , , , .
: DOS-?
: , , , «» «» , DOS- - .
: okd , , …
: , . , ,
okd ,
okd , .
okd , . ,
okd , , , , .
: .
: , . ,
okd . ,
oklogd ? ?
: .
: , , , ?
pubd , , , - .
: , , «»
oklogd .
: , . , ,
append-only , .
: , …
: , , . .
svc ? , , . , ,
okd oklogd . , , .
svc - -, , , . , , , .
okld ? , root. ? , .
dbproxy .
okld ? «»? ?
: , - ?
: , . , , . , , - , , , - . - . root- .
: -, , -
dbproxy .
: !
: , , ,
RPC , , , , , ! .
: , .
dbproxy ? , . , «» ,
dbproxy - .
: ,
svc …
: ,
svc , !
: , , !
: , ,
«» , …
: dbproxy .
: . ,
dbproxy , .
, , . , . , . , , , , .
.
, . ? ? ,
30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).
Dell R730xd 2 ? 2 Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 $249 ! كيفية بناء البنية التحتية للمبنى. الطبقة باستخدام خوادم Dell R730xd E5-2650 v4 بتكلفة 9000 يورو مقابل سنت واحد؟