معهد ماساتشوستس للتكنولوجيا. محاضرة رقم 6.858. "أمن أنظمة الكمبيوتر." نيكولاي زيلدوفيتش ، جيمس ميكنز. 2014 سنة
أمان أنظمة الكمبيوتر هي دورة حول تطوير وتنفيذ أنظمة الكمبيوتر الآمنة. تغطي المحاضرات نماذج التهديد ، والهجمات التي تهدد الأمن ، وتقنيات الأمان بناءً على العمل العلمي الحديث. تشمل الموضوعات أمان نظام التشغيل (OS) ، والميزات ، وإدارة تدفق المعلومات ، وأمان اللغة ، وبروتوكولات الشبكة ، وأمان الأجهزة ، وأمان تطبيقات الويب.
المحاضرة 1: "مقدمة: نماذج التهديد"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 2: "السيطرة على هجمات القراصنة"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 3: "تجاوزات العازلة: المآثر والحماية"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 4: "فصل الامتيازات"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 5: "من أين تأتي أنظمة الأمن؟"
الجزء 1 /
الجزء 2المحاضرة 6: "الفرص"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 7: "وضع حماية العميل الأصلي"
الجزء 1 /
الجزء 2 /
الجزء 3 الجمهور: لماذا يجب أن يبدأ نطاق سعة ذاكرة نطاق العنوان من نقطة الصفر؟
الأستاذ: لأنه من حيث الأداء ، يكون استخدام القفزة الهدف أكثر كفاءة إذا كنت تعلم أن العنوان الصحيح هو مجموعة مستمرة من العناوين بدءًا من الصفر. لأنه بعد ذلك يمكنك القيام بذلك باستخدام قناع
AND واحد ، حيث تكون جميع البتات العالية واحدة فقط زوج من البتات المنخفضة هو صفر.
الجمهور: اعتقدت أن القناع
AND كان من المفترض أن يوفر المحاذاة.
البروفيسور: حسنًا ، القناع يوفر محاذاة ، ولكن لماذا يبدأ من الصفر؟ أعتقد أنهم يعتمدون على
الأجهزة المجزأة. لذلك ، يمكنهم استخدامها لتحريك المنطقة لأعلى ، من حيث المساحة الخطية. أو ربما يتعلق الأمر فقط بكيفية "رؤية" التطبيق لهذا النطاق. في الواقع ، يمكنك وضعه في تعويضات مختلفة في مساحة العنوان الافتراضية الخاصة بك. سيسمح لك هذا بتنفيذ حيل معينة مع أجهزة مقسمة لتشغيل وحدات متعددة في نفس مساحة العنوان.
الحضور: ربما لأنهم يريدون "التقاط" نقطة استقبال المؤشر الفارغ؟
الأستاذ: نعم ، لأنهم يريدون التقاط جميع نقاط الاستقبال. ولكن لديك طريقة للقيام بذلك. لأن المؤشر الفارغ يشير إلى المقطع الذي يتم الوصول إليه. وإذا قمت بنقل المقطع ، يمكنك عرض صفحة صفرية غير مستخدمة في بداية كل جزء. لذلك سيساعد هذا في صنع بعض الوحدات.
أعتقد أن أحد أسباب هذا القرار - لبدء النطاق من 0 - يرجع إلى رغبتهم في نقل برنامجهم إلى منصة
x64 ، التي لديها تصميم مختلف قليلاً. لكن مقالهم لا يقول هذا. في تصميم 64 بت ، تخلصت المعدات نفسها من بعض أجهزة التجزئة ، والتي اعتمدوا عليها لأسباب الكفاءة ، لذلك كان عليهم توفير نهج موجه نحو البرامج. ومع ذلك ، بالنسبة إلى
الإصدار x32 ، لا يزال هذا ليس سببًا جيدًا لبدء المساحة من نقطة الصفر.
لذا ، نواصل السؤال الرئيسي - ماذا نريد أن نضمن من وجهة نظر أمنية. دعونا نقترب من هذه المسألة "بسذاجة" إلى حد ما ونرى كيف يمكننا تدمير كل شيء ، ثم محاولة إصلاحه.
أعتقد أن الخطة الساذجة هي البحث عن التعليمات المحظورة بمجرد مسح الملف التنفيذي من البداية إلى النهاية. فكيف يمكنك اكتشاف هذه التعليمات؟ يمكنك ببساطة أخذ كود البرنامج ووضعه في سطر عملاق من صفر إلى 256 ميجابايت ، اعتمادًا على حجم التعليمات البرمجية الخاصة بك ، ثم بدء البحث.
قد يحتوي هذا السطر أولاً على وحدة تعليمات
NOP ، ثم وحدة تعليمات
ADD ،
NOT ،
JUMP ، وما إلى ذلك. ما عليك سوى البحث ، وإذا وجدت تعليمات سيئة ، فقل أنها وحدة سيئة وتخلص منها. وإذا كنت لا ترى أي استدعاء للنظام لهذه التعليمات ، فيمكنك تمكين تشغيل هذه الوحدة والقيام بكل شيء في نطاق 0-256. هل تعتقد أن هذا سيعمل أم لا؟ ما الذي يقلقهم؟ لماذا هو صعب جدا؟
الجمهور: هل هم قلقون من حجم التعليمات؟
الأستاذ: نعم ، الحقيقة هي أن منصة
x86 لها تعليمات متغيرة الطول. هذا يعني أن الحجم الدقيق للإرشادات يعتمد على البايتات القليلة الأولى من هذا الإرشاد. في الواقع ، يمكنك إلقاء نظرة على البايت الأول لتقول أن التعليمات ستكون أكبر بكثير ، وبعد ذلك قد تضطر إلى النظر في بضعة بايتات أخرى ، ثم تقرر الحجم الذي تحتاجه. تحتوي بعض البنى مثل
Spark و
ARM و
MIPS على تعليمات أكثر طولًا. يحتوي
ARM على أطوال تعليمات - 2 أو 4 بايت. ولكن على النظام الأساسي
x86 ، يمكن أن يكون طول التعليمات 1 و 5 و 10 بايت ، وإذا حاولت ، يمكنك حتى الحصول على تعليمات طويلة إلى حد ما من 15 بايت. ومع ذلك ، هذه تعليمات معقدة.
نتيجة لذلك ، قد تظهر مشكلة. إذا قمت بمسح هذا السطر من التعليمات البرمجية بشكل خطي ، فسيكون كل شيء على ما يرام. ولكن ربما في وقت التشغيل ، ستذهب إلى منتصف نوع من التعليمات ، على سبيل المثال ،
لا .
من الممكن أن تكون هذه تعليمات متعددة البايت ، وإذا قمت بتفسيرها بدءًا من البايت الثاني ، فستبدو مختلفة تمامًا.
مثال آخر سنلعب فيه مع المجمع. لنفترض أن لدينا تعليمات
25 CD 80 00 00 . بعد النظر في البايت الثاني ، سوف تفسره على أنه تعليمات من خمسة بايت ، أي أنه يجب عليك النظر إلى 5 بايت إلى الأمام ورؤية أنه متبوعًا بإرشادات
AND٪ EAX ، 0x00 00 80 قرص مضغوط ، بدءًا من عامل التشغيل
AND لسجل
EAX مع بعض ثوابت محددة ، على سبيل المثال ،
00 00 80 CD . هذه إحدى الإرشادات الآمنة التي يجب على
العميل الأصلي السماح بها ببساطة من خلال القاعدة الأولى للتحقق من التعليمات الثنائية. ولكن إذا قررت
وحدة المعالجة المركزية ، أثناء تنفيذ البرنامج ، أنه يجب أن تبدأ في تنفيذ التعليمات البرمجية من
القرص المضغوط ، فسأضع علامة على هذا المكان من التعليمات بسهم ، فإن التعليمات
٪ EAX ، 0x00 00 80 CD ، والتي هي في الواقع تعليمات من 4 بايت ، تعني تنفيذ
INT 0x80 دولارًا ، وهي طريقة لإجراء مكالمة نظام على
Linux .
لذا إذا فاتتك هذه الحقيقة ، فدع الوحدة غير الموثوق بها "تقفز" إلى النواة وإجراء مكالمات النظام ، أي افعل ما تريد منعه. كيف يمكننا تجنب ذلك؟
ربما يجب أن نحاول النظر إلى إزاحة كل بايت. لأن x86 يمكن أن يبدأ فقط تفسير التعليمات في حدود البايت ، وليس بت. وبالتالي ، عليك أن تنظر في إزاحة كل بايت لمعرفة أين يبدأ التعليمات. هل تعتقد أن هذه خطة مجدية؟
الجمهور: أعتقد أنه إذا كان شخص ما يستخدم بالفعل
و ، فلن يقفز المعالج إلى هذا المكان ، ولكنه ببساطة يسمح بتشغيل البرنامج.
الأستاذ: نعم ، لأنه في الأساس ليس عرضة لإيجابيات كاذبة. الآن ، إذا كنت تريده حقًا ، يمكنك تغيير الرمز قليلاً لتجنبه بطريقة أو بأخرى. إذا كنت تعرف بالضبط ما يبحث عنه جهاز الاختبار ، فمن المحتمل أن تغير هذه التعليمات. ربما عن طريق إعداد
AND أولاً لإرشادات واحدة ، ثم استخدم القناع على آخر. ولكن من الأسهل تجنب هذه الترتيبات المشبوهة للبايت ، على الرغم من أن هذا يبدو غير مريح إلى حد ما.
من الممكن أن تحتوي الهندسة على تغيير مترجم. في الأساس ، لديهم نوع من المكونات يحتاج بالفعل إلى ترجمة التعليمات البرمجية بشكل صحيح. لا يمكنك فقط "خلع"
GCC وترجمة التعليمات البرمجية لـ
Native Client . لذلك في الأساس هذا ممكن. ولكن على الأرجح ، يعتقدون فقط أنه يسبب الكثير من المتاعب ، ولن يكون حلاً موثوقًا أو عالي الأداء ، وما إلى ذلك. بالإضافة إلى ذلك ، هناك العديد من تعليمات
x86 المحظورة ، أو التي يجب اعتبارها غير آمنة ، وبالتالي يجب حظرها. ولكن بالنسبة للجزء الأكبر فهي بحجم بايت واحد ، لذا من الصعب العثور عليها أو تصفيتها.
لذلك ، إذا لم يتمكنوا من جمع وتصنيف التعليمات غير الآمنة والأمل في الأفضل ، فإنهم بحاجة إلى استخدام خطة مختلفة من أجل تفكيكها بطريقة موثوقة. إذن ، ما الذي يفعله
Native Client للتأكد من أنه لا "يتعثر" في هذا الترميز المتغير الطول؟
بمعنى ما ، إذا قمنا بالفعل بمسح الملف القابل للتنفيذ من اليسار إلى اليمين وبحثنا عن جميع الرموز غير الصحيحة المحتملة ، وإذا كانت هذه هي الطريقة التي يعمل بها الرمز ، فنحن في حالة جيدة. حتى إذا كانت هناك بعض التعليمات الغريبة وبعض التحيز ، فإن المعالج لن يستمر في "القفز" هناك ، فسيقوم بتنفيذ البرنامج بنفس الترتيب الذي يتم فيه مسح التعليمات ، أي من اليسار إلى اليمين.
وبالتالي ، تنشأ مشكلة التفكيك الموثوق به نظرًا لوجود "قفزات" في مكان ما من التطبيق. قد يفشل المعالج إذا قام "بقفزة" إلى بعض التعليمات البرمجية التي لم يلاحظها عند المسح من اليسار إلى اليمين. لذا فهذه مشكلة تفكيك موثوق به حتى الآن قيد التطوير. والخطة الرئيسية هي التحقق من أين تؤدي كل "القفزات". في الواقع ، إنها بسيطة للغاية على مستوى ما. هناك مجموعة من القواعد التي سنأخذها بعين الاعتبار في ثانية ، ولكن الخطة التقريبية هي أنه إذا رأيت تعليمات "القفز" ، فأنت بحاجة إلى التأكد من أن الغرض من "القفز" قد لوحظ في وقت سابق. للقيام بذلك ، في الواقع ، يكفي المسح من اليسار إلى اليمين ، أي الإجراء الذي وصفناه في نهجنا الساذج للمشكلة.
في هذه الحالة ، إذا رأيت أي تعليمات "انتقال" والعنوان الذي تشير إليه هذه التعليمات ، فيجب عليك التأكد من أن هذا هو نفس العنوان الذي رأيته بالفعل أثناء التفكيك من اليسار إلى اليمين.
إذا تم العثور على تعليمة قفزة لبايت القرص المضغوط هذا ، فيجب أن نضع علامة على هذه القفزة على أنها غير صالحة لأننا لم نشاهد التعليمات التي تبدأ في بايت القرص المضغوط ، لكننا رأينا تعليمات أخرى تبدأ بالرقم 25. ولكن إذا كانت جميع تعليمات القفزة أمر بالذهاب إلى بداية التعليمات ، في هذه الحالة إلى 25 ، ثم كل شيء على ما يرام لدينا. هل هذا واضح؟
المشكلة الوحيدة هي أنه لا يمكنك التحقق من أهداف كل قفزة في البرنامج ، لأنه قد تكون هناك قفزات غير مباشرة. على سبيل المثال ، في
x86 ، قد يكون لديك شيء مثل القفز إلى قيمة سجل
EAX هذا. هذا أمر رائع لتنفيذ مؤشرات الوظيفة.
أي أن مؤشر الوظيفة موجود في مكان ما في الذاكرة ، يمكنك الاحتفاظ به في سجل ما ، ثم الانتقال إلى أي عنوان في سجل الحركة.
فكيف يتعامل هؤلاء مع القفزات غير المباشرة؟ لأنه في الواقع ، ليس لدي أي فكرة عما إذا كان هذا سيكون "قفزة" لبايت
القرص المضغوط أو البايت 25. ماذا يفعلون في هذه الحالة؟
الجمهور: استخدام الأدوات؟
الأستاذ: نعم ، الأجهزة هي خدعتهم الرئيسية. لذلك ، كلما رأوا أن المترجم مستعد لأداء الجيل ، فهذا دليل على أن هذه القفزة لن تسبب مشاكل. للقيام بذلك ، يحتاجون إلى التأكد من تنفيذ جميع القفزات بتعدد 32 بايت. كيف يفعلون ذلك؟ يغيرون كل تعليمات القفز إلى ما يسمونه "تعليمات زائفة". هذه هي نفس التعليمات ، ولكنها مسبقة ، والتي تمسح البتات المنخفضة الخمسة في سجل
EAX . حقيقة أن التعليمات تزيل 5 بتات منخفضة تعني أنها تتسبب في أن تكون القيمة المعطاة من مضاعفات 32 ، من اثنين إلى خمسة ، ثم يتم تنفيذ قفزة في هذه القيمة بالفعل.
إذا نظرت إلى هذا أثناء التحقق ، فتأكد من أن هذا "الزوج" التعليمي سوف "يقفز" فقط مع تعدد 32 بايت. وبعد ذلك ، من أجل التأكد من عدم وجود إمكانية "القفز" في بعض التعليمات الغريبة ، يمكنك تطبيق قاعدة إضافية. وهو يتألف من حقيقة أنه أثناء التفكيك ، عندما تنظر إلى التعليمات الخاصة بك من اليسار إلى اليمين ، فإنك تتأكد من أن بداية كل تعليمة صالحة ستكون أيضًا مضاعفات 32 بايت.
وبالتالي ، بالإضافة إلى مجموعة الأدوات هذه ، يمكنك التحقق من أن كل رمز من مضاعفات 32 هو التعليمات الصحيحة. بواسطة تعليمات صالحة ، أعني تعليمات مفككة من اليسار إلى اليمين.
الجمهور: لماذا تم اختيار الرقم 32؟
الأستاذ: نعم ، لماذا اختاروا 32 بدلا من 1000 أو 5؟ لماذا 5 سيئ؟
الجمهور: لأن الرقم يجب أن يكون قوة 2.
الأستاذ: نعم ، هذا هو السبب. لأنه بخلاف ذلك ، سيتطلب ضمان استخدام شيء ما من مضاعفات 5 تعليمات إضافية تؤدي إلى النفقات العامة. ماذا عن ثمانية؟ هل ثمانية عدد جيد بما فيه الكفاية؟
الجمهور: قد يكون لديك تعليمات أطول من ثمانية بت.
الأستاذ: نعم ، قد يكون هذا لأطول تعليمات مسموح بها على منصة x86. إذا كان لدينا تعليمات من 10 بايت ، ويجب أن يكون كل شيء من مضاعفات 8 ، فلن نتمكن من إدراجه في أي مكان. لذا يجب أن يكون الطول كافياً لجميع الحالات ، لأن أكبر تعليمة رأيتها كانت بطول 15 بايت. حتى 32 بايت كافية.
إذا كنت ترغب في تكييف التعليمات لإدخال أو الخروج من بيئة خدمة العملية ، فقد تحتاج إلى قدر غير عادي من التعليمات البرمجية في فتحة واحدة 32 بايت. على سبيل المثال ، 31 بايت ، لأن 1 بايت يحتوي على تعليمات. هل يجب أن تكون أكبر بكثير؟ هل يجب أن نجعل هذا يساوي 1024 بايت على سبيل المثال؟ إذا كان لديك العديد من المؤشرات الوظيفية أو العديد من القفزات غير المباشرة ، في كل مرة تريد إنشاء مكان حيث ستقفز ، يجب عليك مواصلته إلى الحد التالي ، بغض النظر عن قيمته. حتى مع 32 بت حجمها طبيعي جدا. في أسوأ السيناريوهات ، ستفقد 31 بايت فقط إذا كنت بحاجة للوصول بسرعة إلى الحد التالي. ولكن إذا كان لديك حجم مضاعف 1024 بايت ، فهناك إمكانية لإضاعة كيلوبايت كامل من الذاكرة عبثا لقفز غير مباشر. إذا كان لديك وظائف قصيرة أو العديد من المؤشرات الوظيفية ، فإن مثل هذا الحجم الكبير لتعدد طول "القفزة" سيؤدي إلى إهدار كبير للذاكرة.
لا أعتقد أن الرقم 32 يمثل حجر عثرة أمام
Native Client . يمكن أن تعمل بعض الكتل مع تعدد 16 بت ، حوالي 64 أو 128 بت ، لا يهم. بدت لهم 32 بت فقط القيمة المثلى والمقبولة.
لذا ، دعونا نضع خطة للتفكيك الموثوق به. نتيجة لذلك ، يجب أن يكون المترجم حذرا قليلا عند تجميع
كود C أو
C ++ في ثنائي
Native Client وملاحظة القواعد التالية.
لذلك ، كلما كان لديه قفزة ، كما هو موضح في السطر العلوي ، يجب عليه إضافة هذه التعليمات الإضافية الواردة في السطرين السفليين. وبغض النظر عن حقيقة أنه ينشئ وظيفة سيقوم "بالقفز إليها" ، فإن تعليماتنا ستقفز كما تشير الإضافة
و $ 0xffffffe0 ،٪ eax . ولا يمكن أن تكمله بالأصفار فقط ، لأن كل هذا يجب أن يحتوي على الرموز الصحيحة. وبالتالي ، فإن الإضافة ضرورية للتأكد من صحة كل تعليمات ممكنة. ولحسن الحظ ، على منصة
x86 ، لا يتم وصف وظيفة
noop واحدة بايت واحد ، أو على الأقل لا يوجد بايت واحد
noop 1 في الحجم. وبالتالي ، يمكنك دائمًا إضافة أشياء إلى قيمة الثابت.
فماذا يضمن لنا ذلك؟ دعونا نتأكد من أننا نرى دائمًا ما يحدث في مصطلحات التعليمات التي سيتم اتباعها. إليك ما تقدمه لنا هذه القاعدة - التأكيد على أن مكالمة النظام لن تتم عن طريق الصدفة. هذا ينطبق على القفزات ، ولكن ماذا عن العوائد؟ كيف يتعاملون مع العائدات؟ هل يمكننا
العودة إلى وظيفة في
Native Client ؟ ماذا يحدث إذا قمت بتشغيل الرمز الساخن؟
الجمهور: يمكنه تجاوز المكدس.
الأستاذ: صحيح أنه ينبثق بشكل غير متوقع على المكدس. ولكن الحقيقة هي أن المكدس المستخدم بواسطة وحدات
Native Client يحتوي بالفعل على بعض البيانات في الداخل. وبالتالي ، عند التعامل مع
Native Client ، لا داعي للقلق بشأن تجاوز سعة المكدس.
الجمهور: انتظر ، ولكن يمكنك وضع أي شيء على المكدس. وعندما تأخذ قفزة غير مباشرة.
الأستاذ: هذا صحيح. يبدو العائد تقريبًا مثل قفزة غير مباشرة من مكان ما في الذاكرة ، والذي يقع في الجزء العلوي من المكدس. لذلك ، أعتقد أن الشيء الوحيد الذي يمكنهم القيام به لوظيفة
العودة هو تعيين البادئة بنفس الطريقة كما في الاختيار السابق. وتتحقق هذه البادئة من ما ينبثق في أعلى المكدس. أنت تتحقق مما إذا كان هذا صحيحًا ، وعندما تكتب أو تستخدم عامل التشغيل
AND ، فإنك تتحقق مما يوجد في أعلى المكدس. يبدو هذا غير موثوق به بعض الشيء بسبب التغيير المستمر للبيانات. لأنه ، على سبيل المثال ، إذا نظرت إلى الجزء العلوي من المكدس وتأكدت من أن كل شيء على ما يرام هناك ، ثم قمت بكتابة شيء ما ، فقد يقوم دفق البيانات في نفس الوحدة النمطية بتعديل شيء في الجزء العلوي من المكدس ، وبعد ذلك ستشير إلى العنصر الخاطئ العنوان
الجمهور: هل هذا لا ينطبق على القفز بنفس القدر؟
الأستاذ: نعم ، فماذا يحدث هناك بقفزة؟ هل يمكن لظروف عرقنا إبطال هذا الاختبار بطريقة أو بأخرى؟
الجمهور: ولكن هل الكود غير قابل للكتابة؟
الأستاذ: نعم ، لا يمكن كتابة الرمز ، هذا صحيح. لذلك ، لا يمكنك تعديل AND. ولكن ألا يمكن لبعض التيار الآخر تغيير الغرض من القفزة بين هذين التوجيهين؟
الجمهور: هذا في السجل ، لذلك ...
الأستاذ: نعم ، هذا شيء رائع. لأنه إذا قام الدفق بتعديل شيء ما في الذاكرة أو في ما يتم تحميله من
EAX (في حد ذاته ، يمكنك القيام بذلك قبل التنزيل) ، في هذه الحالة سيكون
EAX في حالة سيئة ، ولكن بعد ذلك سوف يمحو البتات السيئة. أو يمكنه تغيير الذاكرة بعد ذلك ، عندما يكون المؤشر بالفعل في
EAX ، لذلك لا يهم أنه يغير موقع الذاكرة التي تم تحميل سجل
EAX منها .
في الواقع ، لا تشارك مؤشرات الترابط مجموعات التسجيل. لذلك ، إذا قام مؤشر ترابط آخر بتغيير سجل
EAX ، فلن يؤثر ذلك على سجل
EAX لمؤشر الترابط هذا. لذلك ، لا يمكن لمؤشرات الترابط الأخرى إبطال هذا التسلسل من التعليمات.
هناك سؤال آخر مثير للاهتمام. هل يمكننا الالتفاف على هذا
و ؟ يمكنني القفز أينما أريد في أي مكان في مساحة العنوان هذه. ,
AND .
, , , , ,
AND . .
jmp , .
, , - , 1237. , 32.
Native Client , , , . , , 1237 ?
-
EAX , , , , . , ? ?
: NaCl , .
: , .
x86 , ,
NaCl , 2 . , , : «, , !»,
25 CD 80 00 00 . . ,
x86 .
,
Native Client . , , , ,
NaCl . , .
: , , . , . , , , , .
: , . , . , , ,
EAX . , - .
EAX ,
EBX . , .
EAX EBX AND . , ,
EAX , . , -
64 .
Jmp *% eax AND .
, , , , .
Intel , , , , . , , .
AND ,
EAX , «» .
, , . , . , , , . , , , .
, ,
C1 C7 .
C1 , , . , «» . , , . , , - . , .
2 , 0
64 . , , . , , .
3 , , , . , , .
4 ,
hlt .
halt ? ,
C4 . , , - , .
, , ? , , - .
, , , , . , , , , . .
55:20
:
دورة معهد ماساتشوستس للتكنولوجيا "أمن أنظمة الكمبيوتر". 7: « Native Client», 3.
, . ? ? ,
30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).
3 Dell R630 —
2 Intel Deca-Core Xeon E5-2630 v4 / 128GB DDR4 / 41TB HDD 2240GB SSD / 1Gbps 10 TB — $99,33 , ,
هنا .ديل R730xd أرخص مرتين؟ فقط لدينا 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV من 249 دولارًا في هولندا والولايات المتحدة! اقرأ عن كيفية بناء مبنى البنية التحتية الطبقة باستخدام خوادم Dell R730xd E5-2650 v4 بتكلفة 9000 يورو مقابل سنت واحد؟