معهد ماساتشوستس للتكنولوجيا. محاضرة رقم 6.858. "أمن أنظمة الكمبيوتر." نيكولاي زيلدوفيتش ، جيمس ميكنز. 2014 سنة
أمان أنظمة الكمبيوتر هي دورة حول تطوير وتنفيذ أنظمة الكمبيوتر الآمنة. تغطي المحاضرات نماذج التهديد ، والهجمات التي تهدد الأمن ، وتقنيات الأمان بناءً على العمل العلمي الحديث. تشمل الموضوعات أمان نظام التشغيل (OS) ، والميزات ، وإدارة تدفق المعلومات ، وأمان اللغة ، وبروتوكولات الشبكة ، وأمان الأجهزة ، وأمان تطبيقات الويب.
المحاضرة 1: "مقدمة: نماذج التهديد"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 2: "السيطرة على هجمات القراصنة"
الجزء 1 /
الجزء 2 /
الجزء 3 جيمس ميكنز: من المحاضرة السابقة ، تعلمنا كل شيء عن هجمات تجاوز سعة المخزن المؤقت ، وسنواصل اليوم مناقشة بعض طرق شن هذه الهجمات. الفكرة الأساسية وراء هجوم تجاوز سعة المخزن المؤقت هي كما يلي.
بادئ ذي بدء ، ألاحظ أن هذه الهجمات تؤثر على العديد من الظروف المختلفة. الظرف الأول الذي يستخدمونه هو أن برامج النظام مكتوبة غالبًا في C.
أعني ببرامج النظام قواعد البيانات والمجمعين وخوادم الشبكة وما شابه ذلك. يمكنك أن تتذكر شيئًا مثل shell الأمر المفضل لديك. كل هذا "البرنامج" مكتوب عادة في C. لماذا في C؟ لأنه ، أولاً ، إنه أسرع ، وثانيًا ، يعتبر C مُجمّعًا عالي المستوى يناسب احتياجات مجموعة متنوعة من الأنظمة الأساسية للأجهزة. لذلك ، تتم كتابة جميع الأنظمة الهامة بلغة البرمجة منخفضة المستوى هذه. تكمن المشكلة في البرنامج المكتوب بلغة C في أنه يستخدم عناوين ذاكرة أولية حقًا وليس لديه أي أدوات أو وحدات برامج لفحصها. في بعض الحالات ، يمكن أن يؤدي هذا إلى عواقب وخيمة.
لماذا لا يوجد فحص فهرس مصفوفة في C ، أي عدم التحقق من الحدود؟ سبب واحد هو أن الأجهزة لا. والناس الذين يكتبون في لغة C يريدون عادة أسرع سرعة ممكنة لتنفيذ البرنامج. سبب آخر هو أنه في لغة C ، كما نناقش لاحقًا ، يكون من الصعب جدًا تحديد دلالات مؤشر المؤشر وإلى أي مدى يجب أن يعمل. لذلك ، في بعض الحالات سيكون من الصعب للغاية أتمتة عمليات البرمجيات في C.
دعونا نناقش بعض التقنيات التي تحاول بالفعل إنشاء نوع من إدارة الذاكرة التلقائية. ولكن ، كما سنرى ، لا يوجد أي من هذه الطرق "مضاد للرصاص" تمامًا.
بالإضافة إلى ذلك ، تستخدم هجمات تجاوز سعة المخزن المؤقت x86 المعرفة بالعمارة ، على سبيل المثال ، في أي اتجاه ينمو المكدس. ما هو اصطلاح الاستدعاء للوظائف؟ عند الوصول إلى الدالة C ، كيف يبدو المكدس؟ وعندما تحدد كائنًا في كومة الذاكرة المؤقتة ، كيف تبدو هذه الهياكل المحددة الرئيسية؟
دعونا نلقي نظرة على مثال بسيط. هذا مشابه جدًا لما رأيته في المحاضرة الأخيرة. لذا ، لدينا هنا طلب قراءة قياسي ، ثم نحصل على مخزن مؤقت ، هنا ، ثم يأتي
int ionical
int ، متبوعًا بالأمر get المشهور. وأدناه لدينا أشياء ضرورية أخرى.
لذا ، كما ناقشنا في المحاضرة الأسبوع الماضي ، هذه مشكلة ، أليس كذلك؟ لأن هذا
يحصل عملية لا يتحقق من حدود المخزن المؤقت. إذا قام المستخدم بملء المخزن المؤقت بالبيانات واستخدمنا هذه الوظيفة غير الآمنة هنا ، فيمكننا بالفعل تجاوز المخزن المؤقت. يمكننا إعادة كتابة محتويات المكدس بالكامل. دعني أذكرك كيف يبدو.
في الجزء السفلي يوجد المصفوفة "i". يوجد مخزن مؤقت فوقه ، ولديه العنوان الأول في الأسفل ، وآخر العنوان في الأعلى. على أي حال ، فوق المخزن المؤقت لدينا القيمة المحفوظة لمؤشر الفجوة - القيمة المحفوظة EBP. أعلاه هو عنوان الإرجاع للدالة ، وحتى أعلى بعض الأشياء من الإطار السابق.
ولا تنس أنه هنا في الأسفل ، على يسار "i" ، لدينا مؤشر مكدس ESP الذي يدخل هناك ، ويأتي مؤشر فاصل جديد في قسم EBP المحفوظ. يتضمن عنوان الإرجاع ESP ، ويتضمن باقي الإطار السابق نقطة فاصل.
دعني أذكرك بأن الطريقة التي يفيض بها المكدس هي تراكم البيانات إلى أعلى ، في اتجاه هذا السهم إلى اليمين. عندما تبدأ عملية الحصول ، نبدأ في كتابة وحدات البايت في المخزن المؤقت ، في النهاية ، ستبدأ في الكتابة فوق كل شيء موجود في اتجاه التيار. في الأساس ، يجب أن يبدو كل شيء مألوفًا لك.
ماذا يفعل المهاجم للاستفادة من هذا؟ بشكل أساسي ، فإنه يدخل في تسلسل طويل من البيانات. لذلك ، فإن الفكرة الرئيسية هي أنه يمكن استخدام مثل هذه التقنية للهجوم.
وإذا تم التقاط عنوان الإرجاع بواسطة المهاجم ، فيمكنه تحديد المكان الذي ستقفز فيه الوظيفة بعد تجاوز الحد. أي أن الشيء الوحيد الذي يمكن أن يفعله المخترق هو اعتراض عنوان الإرجاع والقفز في أي مكان يريده. يقوم المهاجمون في الغالب بتشغيل التعليمات البرمجية بامتيازات للتحكم في عملية الاعتراض.
لذلك ، إذا كانت هذه العملية ذات أولوية عالية ، على سبيل المثال ، فقد تم تشغيلها كجذر أو مشرف ، بغض النظر عما نسميه المستخدم الخارق لنظام التشغيل المفضل لديك ، الآن هذا البرنامج ، الذي يتحكم به مهاجم ، يمكنه القيام بكل ما يريده باستخدام امتيازات هذه الأولوية. وبالتالي ، يمكن للمتسلل قراءة الملفات أو إرسال رسائل غير مرغوب فيها في حالة تلف خادم البريد. يمكن أن تهزم جدران الحماية ، لأن فكرة جدار الحماية هي وجود آلات "جيدة" خلفها ، وآلات "سيئة" خارجها. عادةً ، "تثق" أجهزة الكمبيوتر الموجودة داخل جدار الحماية في بعضها البعض ، وإذا تمكنت من اختراق جهاز كمبيوتر واحد على الأقل داخل شبكة محمية بجدار حماية ، فسيكون ذلك رائعًا. لأنه الآن يمكنك ببساطة تخطي العديد من عمليات التحقق التي تجريها أجهزة الكمبيوتر هذه عادةً فيما يتعلق بالآلات "الغريبة" ، لأنها ستعتبرك شخصًا موثوقًا به.
هناك شيء يجب أن تفكر فيه وتفكر فيه كطالب:
"رائع ، أظهروا لنا كيفية تجاوز المخزن المؤقت ، ولكن لماذا لا يمكن لنظام التشغيل إيقاف هذا؟ ألا تتصرف كشخص مثل حراس المجرة ، الذي يحمي الخير من الأشياء الشريرة التي تحدث في الجوار؟ "
من المهم ملاحظة أن نظام التشغيل لا يراقبك باستمرار. ويلاحظ الجهاز أنه يستخرج التعليمات ويفك تشفيرها ويقوم بالكثير من الأمور المماثلة. ولكن في التقريب الأول ، ماذا يفعل نظام التشغيل؟ يقوم بشكل أساسي بإعداد جداول الصفحات التي تسمح للتطبيق بالعمل ، وإذا طلبت من نظام التشغيل ، على سبيل المثال ، إرسال حزمة شبكة ، أو إذا كنت تريد تقديم نوع من طلب IPC ، أو أشياء مماثلة ، فستتحول إلى نظام التشغيل للحصول على المساعدة. لكن نظام التشغيل لا يتبع كل التعليمات التي ينفذها تطبيقك. بمعنى آخر ، عند امتلاء هذا المخزن المؤقت ، لا يراقب نظام التشغيل على الإطلاق كيفية استخدام ذاكرة هذا المكدس. كل مساحة العنوان هذه ملك لك ، كمبادر للعملية ، وهذا لا ينطبق على نظام التشغيل. يمكنك القيام بكل ما تريد مع هذا ، ولا يمكن لنظام التشغيل مساعدتك في المشاكل.
سنناقش لاحقًا بعض الأشياء التي يمكن أن يقوم بها نظام التشغيل فيما يتعلق بالأجهزة من أجل الدفاع عن نفسه ضد هذا النوع من الهجمات. دعني أذكرك مرة أخرى - في الواقع ، فقط الأجهزة تراقب ما تفعله وتتفاعل معه. وبالتالي ، يمكنك الاستفادة من بعض أنواع الحماية الخاصة ، وسنناقش هذا الأمر أكثر.
هذه هي الطريقة التي يبدو بها تجاوز سعة المخزن المؤقت. كيف سنصلح كل هذه الأشياء؟
تتمثل إحدى طرق منع تجاوزات المخزن المؤقت في تجنب الأخطاء في رمز C. ببساطة ، وهذا نهج بناء ، لأنه إذا لم يكن هناك أخطاء في برنامجك ، فلن يتمكن المهاجم من استخدامها. ومع ذلك ، فإن قول هذا أسهل من فعله. هناك بعض الأشياء البسيطة للغاية التي يمكن للمبرمجين القيام بها لتوفير "النظافة" الأمنية. على سبيل المثال ، ميزات مثل get ، والتي نعرف الآن أنها يمكن أن تسمى "go-tos" أو "التقاط نظام التشغيل" ، وهو خرق أمني.
لذلك ، عندما تقوم بتجميع التعليمات البرمجية الخاصة بك باستخدام مترجم حديث مثل GCC أو Visual Studio ، فإنها ستشير إلى عيوب هذه الوظائف. سيقولون: "مرحبًا ، أنت تستخدم شيئًا خطيرًا ، فكر بشكل أفضل في استخدام وظيفة الأدوات أو الوظائف الأخرى التي يمكنها تتبع الامتثال للحدود حقًا" هذه واحدة من الأشياء البسيطة التي يمكن للمبرمجين القيام بها.
ولكن لاحظ أن العديد من التطبيقات تتعامل بالفعل مع المخازن المؤقتة دون اللجوء إلى جميع هذه الوظائف. هذا أمر شائع جدًا في خوادم الشبكة التي تحدد إجراءات التحليل الخاصة بها ، ثم تأكد من استرداد البيانات من المخزن المؤقت بالطريقة التي تريدها. وبالتالي ، بمجرد قصر نفسك على اختيار وظائف الأمر الصحيحة ، لن يكون من الممكن حل المشكلة تمامًا.
ظرف آخر يجعل هذا النهج للمشكلة أكثر صعوبة هو أنه ليس من الواضح دائمًا أن المشكلة ناتجة عن خطأ في برنامج مكتوب في C. إذا كنت قد عملت في أي وقت مضى على برنامج واسع النطاق تم كتابته في C ، فأنت تعرف ، كما يحدث مع معرفات الدوال التي لها 18 نجمة فوق مؤشر الفراغ *. أعتقد أن زيوس فقط يعرف ما يمكن أن يعنيه هذا ، أليس كذلك؟ مع لغات مثل C ، حتى المبرمج قد يجد صعوبة بالغة في فهم ما إذا كان هناك خطأ أم لا.
بشكل عام ، سيكون أحد المواضيع الرئيسية لمحاضراتنا هو أن اللغة C هي نتاج الشيطان. ونحن نستخدمها فقط لأننا نريد دائمًا أن نكون أسرع من أي شخص آخر ، أليس كذلك؟ ولكن نظرًا لأن الأجهزة تصبح أسرع وأسرع ، فإننا نستخدم لغات أكثر تقدمًا لكتابة رمز نظام ضخم. ومع ذلك ، ليس من المنطقي دائمًا كتابة رمز C الخاص بك ، حتى إذا كنت تعتقد أنه سيكون أسرع. سنناقش هذه المسألة في وقت لاحق.
لذا ، فإن النهج الأول لحل المشكلة هو تجنب الأخطاء في رمز برنامج C ، والثاني هو إنشاء أدوات تساعد المبرمجين في العثور على مثل هذه الأخطاء. مثال على هذه الأداة هو تحليل التعليمات البرمجية الثابتة. سنتحدث لاحقًا عن ذلك بالتفصيل ، والآن سأقول أن التحليل الثابت هو طريقة لتحليل الكود المصدري لبرنامجك قبل أن يبدأ حتى ، ويساعد على اكتشاف المشاكل المحتملة.
تخيل أن لديك مثل هذه الوظيفة ، دعنا نسميها
باطلة foo (int ، * p) ، تحتوي على بيانات عدد صحيح ومؤشر. دعنا نقول أنه يعلن قيمة إزاحة عدد صحيح عدد
إيقاف التشغيل . تقوم هذه الوظيفة بتعريف مؤشر آخر وإضافة إزاحة إليه:
int * z = p + off . حتى الآن ، عند كتابة دالة ، يمكن أن يخبرنا تحليل الشفرة الثابتة أن متغير الإزاحة هذا لم تتم تهيئته.
وبالتالي ، من خلال تحليل البرنامج ، من الممكن الإجابة على السؤال عما إذا كانت وظيفتنا ستعمل بشكل صحيح. وفي هذا المثال ، من السهل جدًا رؤية الإجابة "لا ، لن يحدث ذلك" لأنه لا توجد تهيئة أوفست. التحليل الثابت هو برنامج ، وبينما تستخدم المترجم الشائع لبناء التعليمات البرمجية الخاصة بك ، سيخبرك: "مرحبًا يا صديقي ، هذا الشيء لم تتم تهيئته. هل أنت متأكد أنك تريد أن تفعل ذلك بالضبط؟ " هذا هو أحد أبسط الأمثلة على استخدام التحليل الثابت.
يعتبر مثال آخر الحالة عندما يكون لدينا فرع من دالة ، أي تنفيذها في حالة معينة.
لذا ، إذا كانت الإزاحة أكبر من 8 ،
إذا (إيقاف> 8) ، فهذا يؤدي إلى استدعاء بعض
شريط الوظائف
(إيقاف) . لذلك ، يخبرنا هذا الشرط ما هي قيمة الإزاحة. حتى مع تجاهل حقيقة أن الإزاحة لم تتم تهيئتها ، أثناء تحليل هذا الفرع من الوظيفة ، ما زلنا نجد أنها يمكن أن تكون أكبر من 8. لذلك ، عندما نبدأ في إجراء تحليل ثابت للشريط ، نتعلم أن الإزاحة يمكن أن تأخذ قيمًا معينة فقط. ألاحظ مرة أخرى أن هذه مقدمة سطحية للغاية للتحليل الثابت ، سننظر لاحقًا في هذه الأداة بمزيد من التفاصيل. لكن هذا المثال يوضح كيف يمكنك اكتشاف بعض أنواع الأخطاء حتى بدون تنفيذ التعليمات البرمجية.
لذا ، هناك شيء آخر قد تفكر فيه هو أنه يفعل نفس الشيء مثل التحليل الثابت. هذا تلاعب بالبرامج. فكرته هي أنك تأخذ جميع الوظائف في رمز البرنامج الخاص بك ثم تدخل قيمًا عشوائية فيها. وبالتالي ، تتداخل جميع الخيارات المتعلقة بقيم وتنسيقات التعليمات البرمجية الخاصة بك. أي أن Fuzzing هي أداة للبحث تلقائيًا عن الثغرات الأمنية عن طريق إرسال بيانات غير صالحة أو بيانات بتنسيق خاطئ إلى إدخال البرنامج. على سبيل المثال ، أدخل القيم 2 و 4 و 8 و 15 في اختبار الوحدة وستحصل على رسالة تفيد بأن الرقم 15 ربما يكون غير صحيح ، نظرًا لأن جميع الأرقام زوجية ، لكنها غريبة.
في الواقع ، تحتاج إلى إلقاء نظرة على عدد فروع البرنامج ككل التي تؤثر على رمز الاختبار الخاص بك ، لأن هذه هي الأماكن التي يتم فيها إخفاء "الأخطاء". لا يفكر المبرمجون في مثل هذه "الزوايا والشقوق" ونتيجة لذلك يجتازون بعض اختبارات الوحدة ، يمكنك قول معظم هذه الاختبارات. ومع ذلك ، فإنهم لا يفحصون جميع "الزوايا والشقوق" في البرنامج ، وهنا يمكن أن يساعد التحليل الثابت. مرة أخرى ، استخدام أشياء مثل مفهوم التقييد. على سبيل المثال ، في قسم برنامجنا ، يعد هذا شرطًا لتفرع دالة تحدد إزاحة أكثر من ثمانية. وهكذا ، يمكننا معرفة أن هذا الإزاحة ثابت. وإذا استخدمنا إنشاء التضمين التلقائي لبيانات الإدخال بناءً على هذا التقييد ، فيمكننا التأكد من أن إحدى قيم الإدخال للإزاحة ستكون أقل من 8 ، وواحدة ستكون 8 ، وواحدة أكثر من 8. هل هذا واضح؟
هذه هي الفكرة الرئيسية وراء مفهوم إنشاء أدوات لمساعدة المبرمجين في العثور على الأخطاء. حتى التحليل الجزئي للكود يمكن أن يكون مفيدًا جدًا عند العمل مع لغة C. العديد من الأدوات التي سننظر إليها والتي تعمل على منع تجاوزات المخزن المؤقت أو التحقق من تهيئة المتغيرات غير قادرة على اكتشاف جميع مشاكل رمز البرنامج. ولكن يمكن أن تكون ذات فائدة عملية في تحسين أمن هذه البرامج. عيب هذه الأدوات أنها ليست كاملة. التقدم المستقبلي ليس التقدم الكامل. لذلك ، تحتاج إلى استكشاف مشكلة الحماية ضد برمجيات إكسبلويت بفعالية في البرامج المكتوبة بلغة C وفي برامج أخرى. لقد درسنا نهجين لحل مشكلة حماية تجاوز سعة المخزن المؤقت ، ولكن هناك طرق أخرى.
لذا ، فإن النهج الثالث هو استخدام لغة آمنة للذاكرة ، أو لغة تضمن سلامة الذاكرة. تتضمن هذه اللغات Python و Java و c #. لا أريد أن أضع بيرل على قدم المساواة معهم ، لأنه يستخدم من قبل "الأشرار". بهذه الطريقة يمكنك استخدام لغة آمنة للذاكرة ، ويبدو أن هذا هو الشيء الأكثر وضوحًا الذي يمكنك القيام به. لقد شرحت لك للتو أن C بشكل أساسي عبارة عن برنامج تشفير تجميع عالي المستوى ، ولكنه يوفر مؤشرات أولية وأشياء أخرى غير مرغوب فيها ، فلماذا لا تستخدم فقط إحدى لغات البرمجة عالية المستوى؟
هناك عدة أسباب لذلك. أولاً ، في هذه اللغات ، هناك العديد من عناصر التعليمات البرمجية الموروثة من C. كل شيء على ما يرام إذا بدأت مشروعًا جديدًا واستخدمت إحدى اللغات عالية المستوى التي تضمن سلامة الذاكرة له. ولكن ماذا لو تم إعطاؤك ملفًا ثنائيًا كبيرًا أو توزيعًا كبيرًا للمصدر تمت كتابته في C وتمت صيانته لمدة 10-15 عامًا ، كان هذا مشروعًا للأجيال ، أعني أنه حتى أطفالنا سيواصلون العمل عليه ؟؟؟ في هذه الحالة ، لن تتمكن من القول: "أنا أعيد كتابتها كلها في C # وأغير العالم!".
والمشكلة ليست فقط في لغة C ، فهناك أنظمة يجب أن تخاف منها أكثر ، لأنها تستخدم رموز Fortran و COBOL ، أشياء من الحرب الأهلية. لماذا يحدث هذا؟ لأنه ، كمهندسين ، نريد أن نفكر أنه يمكننا فقط بناء كل شيء بأنفسنا ، وسيكون رائعًا ، سيكون كما أريد ، وسأطلق على متغيراتي ما أريد.
لكن هذا لا يحدث في العالم الحقيقي. أنت تظهر في العمل ، ولديك هذا النظام الموجود بالفعل ، وتنظر إلى أساس الكود وتفكر لماذا لا تفعل ما هو مطلوب؟ ثم يقولون لك: "اسمع ، سنفعل كل ما تريد ، ولكن فقط في الإصدار الثاني من البرنامج ، والآن عليك أن تفعل ما يتعين علينا أن نعمل ، لأنه بخلاف ذلك سيستعيد العملاء أموالهم".
لذا ، كيف نتعامل مع المشكلة الضخمة المتمثلة في الاستخدام الجبري للرمز القديم؟ كما تعلم ، فإن إحدى مزايا الأنظمة ذات التعريف الخاطئ للحدود هي أنها تعمل بشكل مثالي مع هذا الرمز القديم. هذا هو أحد الأسباب التي تجعلك لا تستطيع التخلص من مشكلة تجاوز سعة المخزن المؤقت بمجرد التبديل إلى اللغات التي توفر استخدامًا آمنًا للذاكرة.
ماذا لو احتجنا إلى وصول منخفض المستوى للأجهزة؟ على سبيل المثال ، لتحديث برامج التشغيل وأشياء أخرى.
لذلك ، تنشأ مشكلة أخرى إذا كنت بحاجة إلى وصول منخفض المستوى إلى المعدات ، والذي يحدث عند كتابة برامج التشغيل لبعض الأجهزة. في هذه الحالة ، تحتاج حقًا إلى المزايا التي يمنحها C ، على سبيل المثال ، القدرة على النظر إلى السجلات وعناصر الوظيفة المماثلة.
علاوة على ذلك ، تنشأ الحاجة إلى استخدام C عندما تهتم بأداء النظام.
عادة ما يقولون أنه إذا كنت بحاجة إلى الأداء ، فاكتب في C ، وإلا فسيعمل كل شيء ببطء شديد. ومع ذلك ، الآن هذه المشكلة ليست حادة للغاية ، لأن الناس لديهم مترجمون مع عمليات تحسين قوية. بالإضافة إلى ذلك ، هناك أشياء تقلل بالفعل من تكلفة استخدام هذه اللغات الآمنة للذاكرة. سأخبرك باختصار ما هو JIT. دعنا نفكر في ما هو Java أو Java Script. هذه لغة عالية المستوى ، كثيفة ديناميكيًا ، مع تحكم آلي و "أشياء" أخرى جيدة. عندما ظهرت هذه اللغات لأول مرة ، تم تفسيرها دائمًا. من خلال التفسير ، أعني أنهم لم ينفذوا في البداية تعليمات x86 الأولية., , -. , , JVM, - Java. , - . , - JVM , . , , . . , , .
, , 86. JIT- , . JIT- , .
, JavaScript , , «» 32- , . JIT-, «» . , , JIT-, , , .
«» , asm.js – JavaScript, , , . , , , JavaScript , . JavaScript, JavaScript, C ++.
, -, IO. . , , , , . «» , .
. , - . , C C++, , . Python, , , . . .
, , , .
, . , . , . , «» , . , C C++, .
, ? , , ? ?
. , – . , - , . , . , -, , . IP , , . , - . , , . , , «» .
, , , , , , . , - , . , , , . , , , , , , .
, . stack canaries, « », , . « » , , , . , , .
. , « », . , , «».
28:30
:
دورة معهد ماساتشوستس للتكنولوجيا "أمن أنظمة الكمبيوتر". 2: « », 2.
شكرا لك على البقاء معنا. هل تحب مقالاتنا؟ هل تريد رؤية مواد أكثر إثارة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية به لأصدقائك ،
خصم 30 ٪ لمستخدمي Habr على نظير فريد من خوادم مستوى الدخول التي اخترعناها لك: الحقيقة الكاملة حول VPS (KVM) E5-2650 v4 (6 نوى) 10GB DDR4 240GB SSD 1Gbps من 20 $ أو كيفية تقسيم الخادم؟ (تتوفر الخيارات مع RAID1 و RAID10 ، حتى 24 مركزًا وحتى 40 جيجابايت DDR4).
ديل R730xd أرخص مرتين؟ فقط لدينا
2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV من 249 دولارًا في هولندا والولايات المتحدة! اقرأ عن
كيفية بناء مبنى البنية التحتية الطبقة باستخدام خوادم Dell R730xd E5-2650 v4 بتكلفة 9000 يورو مقابل سنت واحد؟