معهد ماساتشوستس للتكنولوجيا. محاضرة رقم 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المحاضرة 10: "التنفيذ الرمزي"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 11: "لغة برمجة Ur / Web"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 12: أمن الشبكات
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 13: "بروتوكولات الشبكة"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 14: "SSL و HTTPS"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 15: "البرامج الطبية"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 16: "هجمات القناة الجانبية"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 17: "مصادقة المستخدم"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 18: "التصفح الخاص للإنترنت"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 19: "الشبكات المجهولة"
الجزء 1 /
الجزء 2 /
الجزء 3 دعونا نلقي نظرة فاحصة على كيفية عمل البروتوكول. لأنه سيكون من العار قراءة مقالة محاضرة وعدم الحديث عن الأشياء التي تلفت الانتباه إليها. أريد أن أعتذر مرة أخرى لتقنيتي للرسم على السبورة ، بعد كل شيء ، معظم الوقت الذي أمضيه على الطاولة ، وأكتب على الكمبيوتر.
هذه تقنية غريبة. حتى هنا مكرر. وهنا أليس. هنا مكرر آخر وهنا بوب. تريد أليس الآن التحدث مع بوب ، لذا فإن أول ما تفعله هو إنشاء سلسلة من خلال أجهزة إعادة الإرسال هذه إلى بوب. لنفترض أنها اختارت هذين المكررين ، R1 و R2. تقوم Alice أولاً بإنشاء ارتباط TLS بـ R1 ، لنفترض أن لديها بالفعل رابط TLS إلى R2. ثم ، أولاً ، تقوم Alice بإجراء مصادقة أحادية الاتجاه ومطابقة أحادية الاتجاه للمفاتيح المجهولة.
كان بروتوكول Tor القديم يسمى TAP - Tor Authentication Protocol ، ويسمى البروتوكول الجديد NTor. كلاهما لديه دليل على السلامة. هذا دليل صحيح ، على الرغم من ارتكاب أخطاء في وصفها.
بعد المصادقة ، تختار أليس معرف دائرة معرف القناة ، على سبيل المثال 3 ، وتوجه المكرر بإنشاء القناة "3" - إنشاء "3" ، ويخبرها أن القناة تم إنشاؤها - تم إنشاؤها. تشارك أليس والتتابع الآن المفتاح المتماثل السري S1. وكلاهما يخزنها بمؤشر "3" ، وهو رابط لهذه القناة.
يمكن لـ Alice الآن استخدام هذا المفتاح لإرسال رسائل R1. وتقول إنه في "الترويكا" ، هذا هو معرف القناة ، الذي تمت مناقشته في مقالة المحاضرة ، يتم إرسال خلية موسعة ذات محتوى إلى التتابع.
تحتوي الخلية الموسعة بشكل أساسي على النصف الأول من مصافحة المصافحة. ولكن هذه المرة لا يتم تشفيرها باستخدام المفتاح العام R1 ، ولكن يتم تشفيرها باستخدام المفتاح العام R2. يشير هذا إلى أن الرسالة يتم إرسالها إلى R2. وبالتالي ، يعرف R1 أنه من الضروري فتح قناة جديدة إلى R2 ، ويبلغ ذلك إلى ترحيل R2 برسالة الإنشاء (....) ، حيث يتم وضع نفس نصف المصافحة التي جاءت من أليس بين قوسين. من خلال القيام بذلك ، تقوم R1 بإنشاء معرف الدائرة الخاص بها ، حيث تحدد معرفات القنوات القنوات الأخرى في اتصال TLS الثاني هذا. علاوة على ذلك ، لا تعرف Alice معرفات القنوات التي لا تزال تستخدم هنا ، لأن هذه "مسألة شخصية" لـ R1 و R2.
لذا يمكن للترحيل أن يختار ، على سبيل المثال ، المعرف 95. في الواقع ، هذا غير مرجح ، لأن رقم القناة يتم اختياره عشوائيًا من 4 بايت من المساحة ، لكنني لا أريد كتابة جميع أرقام 32 بت اليوم.
بعد ذلك ، يجيب R2 عن أول ترحيل "تم إنشاؤه" ، وتعود R1 إلى خلية خلية ممتدة مشفرة باستخدام مفتاح S1. الآن ، تشارك أليس وتتابع R2 مشاركة S2 ويمكن لـ Alice إرسال رسائل ، يتم تشفيرها أولاً باستخدام S2 ، ثم مع S1. ترسل مثل هذه الرسالة ، R1 يزيل تشفير S1 ويعيد توجيهه أكثر.
يعرف المكرر الأول أنه يجب إرسال رسائل القناة 3 إلى المكرر الثاني على القناة 95. بعد تلقي هذه الرسالة ، يرى المكرر الثاني أن القناة S2 تتوافق مع مفتاح S2 ، وبمساعدتها فك تشفير هذه الرسالة: "أوه ، تقول اتصال مفتوح مع بوب"! بعد قراءة هذا ، يفتح ترحيل R2 اتصال TCP مع Bob ويبلغ Alice بذلك باستخدام نفس عملية تمرير الرسائل العكسية.
بعد كل هذا ، تقول أليس: "رائع ، ثم أخبر بوب بشيء مثل http: 1.0get /index.html" ، ثم تستمر الحياة.
دعونا نرى ما فاتني في مقال المحاضرة ... لذلك ... هذا ، وهذا ، وهذا. حسنًا ، ما الذي ننقله بالفعل؟ تدعي بعض الحلول في هذا المجال أنه من الضروري نقل حزم IP ذهابًا وإيابًا ، أي أن هذا المخطط يجب أن يكون ببساطة طريقة لإرسال حزم IP. إحدى المشاكل هي أننا نريد دعم أكبر عدد ممكن من المستخدمين ، مما يعني أنه يجب علينا العمل على جميع أنواع أنظمة التشغيل.
لكن مكدسات TCP لأنظمة التشغيل المختلفة تعمل بشكل مختلف. إذا كنت قد استخدمت Nmap أو نوعًا من أداة تحليل حركة مرور الشبكة ، يمكنك بسهولة تمييز Windows TCP من FreeBSD TCP أو TCP Linux. يمكنك حتى التمييز بين الإصدارات المختلفة. علاوة على ذلك ، إذا كان بإمكانك إرسال حزم IP الأولية إلى مضيف محدد ، فيمكنك إثارة ردود تستند جزئيًا على ما يفعله المضيف.
لذلك إذا قمت بإعادة توجيه حزم IP ذهابًا وإيابًا ، فأنت بحاجة إلى تطبيع IP. نظرًا لأن أي شيء أصغر من حزمة IP الكاملة لن يتمكن من العمل على التطبيع ، فأنت لا تأتي للقيام بذلك.
بدلاً من ذلك ، نختار أسهل طريقة - نحن نقبل ببساطة كل المحتوى من تدفقات TCP ، بافتراض أنه موثوق به وكل شيء على ما يرام. يحلل البرنامج جميع البيانات التي ترسلها Alice ، ويوافق على قبول اتصالات TCP القادمة من تطبيقاتها ، ويقوم ببساطة بترحيل المحتويات دون القيام بأي شيء معقد على مستوى الشبكة.
يمكنك محاولة زيادة الإنتاجية باستخدام وسائل أخرى موصوفة في مواد المحاضرة. لكني وصفت مخططًا يمكن تنفيذه بالفعل ، لأنه عند إنشاء Tor ، أولينا اهتمامًا أكبر لفئات الأمان والمترجمين أكثر من فئات الشبكة. لدينا الآن متخصصون في الشبكة ، ولكن في 2003-2004 عانينا من نقص في هؤلاء.
يبدو أن بروتوكول TCP هو مستوى مناسب وصحيح للغاية. تستخدم البروتوكولات عالية المستوى التي تمت مناقشتها في بعض المشاريع الأصلية خوادم وكيلة منفصلة على جانب أليس لـ HTTP و FTP وتبدو فكرة سيئة. هذا لأن أي بروتوكول يجب أن يكون لديه تشفير من البداية إلى النهاية طوال اتصال Alice-Bob ، وإذا كنا محظوظين ، فسيكون بمقدور Alice إنشاء اتصال TLS بين R2 و Bob ، والذي يتميز بميزات السلامة والأمان.
ولكن إذا كانت هذه هي الحالة ، فإن أي تحويلات إخفاء الهوية التي تريد تطبيقها على البيانات المشفرة يجب أن تحدث في التطبيق الذي تستخدمه Alice قبل إنشاء اتصال TLS بالكامل. ولكن هذا غير ممكن باستخدام خادم وكيل ، لذلك فإن TCP أكثر ملاءمة لنا.
سألني شخص ما ، أين هو دليلنا على الأمن؟ لدينا أدلة أمنية للعديد من طرق التشفير التي نستخدمها ، وهي إصدارات قياسية من المستندات. بشكل عام ، بالنسبة للبروتوكول ، هناك دليل على أمن جوانب معينة من توجيه البصل. لكن النماذج التي يجب عليهم استخدامها لإثبات أن هذا يوفر عدم الكشف عن الهوية يجب أن تستند إلى هذه الخصائص الغريبة للكون ، وخصائص الشبكة أو قدرات المهاجم التي لا يمكنها سوى تلبية لجان البرمجة التي تجلس في بعض المؤتمرات النظرية.
باختصار ، يجب أن تثبت خصائص عدم الكشف عن الهوية هذه أن المهاجم الذي يمكنه رؤية حجم وتوقيت البيانات في قسم Alice-R1 لن يكون قادرًا على التعرف عليها ، مع ملاحظة وحدات بايت الإخراج فقط في قسم R2-Bob. لكن هذه ليست نتيجة مرضية. دعنا نقول فقط - ما هي الضمانات الأمنية التي تريدها من نظام لا تعرف كيفية بنائه؟ حسنًا ، يجب أن أكون حذرًا في مثل هذه العبارات ... تذكر أن هناك أنظمة بضمانات قوية لإخفاء الهوية ، وأنت تعرف كيفية إنشاء مثل هذه الأنظمة ، ولكنك لن ترغب أبدًا في استخدامها. على سبيل المثال ، شبكة DC-Net الكلاسيكية ، التي توفر إخفاء الهوية المضمون ، باستثناء أنه يمكن لأي مشارك إغلاق الشبكة بالكامل بمجرد التوقف عن المشاركة فيها. بالإضافة إلى ذلك ، لا يتوسع هذا النظام.
ولكن بالنسبة للأشياء التي تم إنشاؤها في عصرنا ، فإن خصائص إخفاء الهوية أكثر احتمالية ، وليست مضمونة بشكل قاطع. لذا بدلاً من السؤال عما إذا كان هذا النظام يضمن أمان Alice ، سيكون من الجدير التساؤل عن مقدار حركة المرور التي يمكن أن ترسلها أليس بأمان إذا كانت ترغب في الحصول على فرصة بنسبة 99٪ لعدم ارتباط نشاط الشبكة هذا بنشاطها؟
السؤال الأول الذي طرحناه على أنفسنا عندما بدأنا في إنشاء Tor هو ، من سيدير كل هذه الأشياء؟ لم نكن نعرف ما إذا كان نظامنا "سيقف على قدميه" حقًا ، لذا كان الخيار الوحيد هو محاولة معرفة ما جاء به.
كان لدينا ما يكفي من المتطوعين. أراد عدد لا بأس به من المنظمات غير الربحية تقديم التبرعات واستخدامها لشراء عرض النطاق الترددي وإطلاق مواقع Tor. شاركت بعض الجامعات والعديد من الشركات الخاصة في المشروع ، الذي قررت أجهزته الأمنية أنه سيكون من الممتع إطلاق خادم Tor الخاص بهم.
في هذه الحالة ، نشأت مشاكل قانونية ، ولكن مرة أخرى ، لست محاميًا ولا يمكنني تقديم تقييم قانوني لهذه الأشياء. ومع ذلك ، سألني خمسة أشخاص مختلفين عن شرعية نظامنا. بقدر ما أستطيع أن أقول ، على الأقل في الولايات المتحدة الأمريكية ، لا توجد عقبات قانونية أمام بدء تشغيل خادم Tor. ويبدو لي أن حالة مماثلة تحدث في معظم الدول الأوروبية. في البلدان ذات حرية الإنترنت الأقل ، يكون Tor أكثر تقييدًا.
لا تكمن المشكلة في مدى قانونية أو عدم قانونية استخدام نظام Tor ، ولكن يمكن لأي شخص أن يفعل شيئًا غير قانوني أو غير مرغوب فيه مع خادم Tor الخاص بي. على سبيل المثال ، هل سيفصلني مزود الخدمة الخاص بي عن الشبكة إذا قدمت جهاز الكمبيوتر الخاص بي كعقدة Tor ، فهل تعتقد وكالات تطبيق القانون أنني أستخدم خادم Tor فقط ، أو أنهم سيأتون ويأخذون جهاز الكمبيوتر الخاص بي للتأكد من ذلك.
في مثل هذه الحالة ، أنصحك بعدم تشغيل خادم Tor من غرفة النوم الخاصة بك ، أو بالأحرى ، عدم استخدام جهاز الكمبيوتر الخاص بك لبث كمية كبيرة من حركة مرور الإخراج ، على افتراض أن هذا يسمح بسياسة الشبكة. بصراحة ، ليس لدي أي فكرة عن ماهية هذه السياسة الآن لأنها تغيرت كثيرًا منذ أيام طلابي. ولكن على أي حال ، يمكن أن تؤدي حركة المرور الصادرة الكبيرة من جهاز الكمبيوتر الخاص بك في بيت الشباب إلى مشاكل. ومع ذلك ، بدء مكرر دون إصدار حركة المرور إلى الإنترنت سيكون أقل إشكالية. ولكن إذا كان مزودك يسمح لك بالتصرف بهذه الطريقة ، فهذا شيء معقول.
سألني شخص ما ماذا لو كان المستخدمون لا يثقون في موقع معين؟ هذا ينقلنا إلى الموضوع التالي. يستخدم عملاء الشبكة البرنامج وفقًا لتقديرهم ، ولا يمكنك منعهم من استخدام بعض البرامج وإلزامهم باستخدام برامج أخرى. لكن تذكر أن إخفاء الهوية يحب الصحبة. إذا استخدمت ثلاث عقد ، فأنت تستخدم ثلاث عقد أخرى ، وأنت ثلاث عقد أخرى ، فلن تختلط حركة المرور لدينا على الإطلاق.
طالما نفصل بين أجزاء الشبكة التي نستخدمها ، فإننا نتميز بسهولة عن بعضنا البعض. الآن ، إذا قمت ببساطة باستبعاد عقد أو عقدين ، وقمت ببساطة باستبعاد عقد أو عقدتين ، فلن يكون هذا تقسيمًا كبيرًا للشبكة إلى أجزاء وسيعقد تعقيد تحديدنا. ولكن سيكون من الأفضل للجميع استخدام نفس العقد قدر الإمكان. كيف نحقق ذلك؟
لذا ، في الإصدار الأول من Tor ، أزلنا للتو قائمة بجميع العقد للمستخدمين ، كان هناك حوالي 6 منها ، عملت ثلاث منها على كمبيوتر واحد في مختبر علوم الكمبيوتر Tech Square. لكن هذه لم تكن فكرة جيدة ، لأن عدد العقد يزداد وينقص ، وتتغير العقد نفسها ، ولن ترغب في إصدار نسخة جديدة من البرنامج في كل مرة ينضم فيها شخص ما إلى الشبكة.
ولكن يمكنك التأكد من أن كل عقدة تحتوي على قائمة بجميع العقد الأخرى المتصلة بها ، وأنهم "سيعلنون" بعضهم البعض. بعد ذلك ، عندما يتصل العميل بالشبكة ، يحتاج فقط إلى معرفة عقدة واحدة ، ثم يقول: "مرحبًا ، من هناك على الشبكة"؟
في الواقع ، العديد من الناس لديهم مشاريع مبنية على هذا المبدأ. تعمل العديد من مشاريع عدم الكشف عن هوية الأقران المبكرة بهذه الطريقة. لكن هذه فكرة رهيبة. لأنه إذا اتصلت بعُقدة واحدة وسألت من هو متصل بالإنترنت وتثق في الشخص الذي يجيب ، يمكنني أن أجيبك: "أنا متصل بالإنترنت ، وصديقي موجود هنا عبر الإنترنت ، وصديقي متصل أيضًا بالإنترنت ، والمزيد لا أحد متصل! " بمعنى ، يمكنني أن أخبرك بأي عدد من العقد المزيفة التي أديرها والتي تعترض كل حركة المرور الخاصة بك. هذا ما يسمى هجوم التقاط rw ، أو هجوم اعتراض على العقدة المصدر.
لذلك من المحتمل أنه إذا كان لدينا دليل واحد فقط يديره طرف موثوق به ، فهذا ليس جيدًا ، لذلك دعونا نفترض أن لدينا العديد من الأطراف الموثوقة. يذهب العملاء إلى هذه الأطراف الموثوقة ، ويتلقون من كل قائمة قائمة بجميع العقد ويدمجونها في قائمة مشتركة واحدة من عقد الشبكة.
هذا ليس جيدًا لأننا انقسمنا مرة أخرى إلى مجموعات شبكة محددة. إذا قمت بتحديد هذه العقد الثلاث ، وقمت بتحديد ثلاث عقد أخرى ، فسوف نستخدم مجموعات مختلفة من العقد ، وهذا ليس جيدًا. بالإضافة إلى ذلك ، إذا استخدمت قائمة العقد التي تم تمريرها إلي ، فيمكن لأي طرف موثوق أن يمنعني من استخدام عقدة لا تعجبها ، ببساطة عدم تحديدها في القائمة. إذا استخدمت قائمة مدمجة ، فيمكن لشخص ما أن يغمرني بـ 20 ألف خادم مزيف ، مشيرًا إليهم في القائمة. يمكنني التصويت على استبعادهم وحل مشكلتين أخريين بطريقة ما ، لكنني سأظل منفصلاً عن كل من يستخدم أطرافًا موثوقة مختلفة.
يمكننا إنشاء DHT سحري ، أو جدول تجزئة موزعة ، وهو نوع من البنية السحرية الموزعة التي تمر عبر جميع العقد. أقول "السحر" لأنه على الرغم من وجود مشروعات في هذا المجال ، وبعضها أفضل من البعض الآخر ، إلا أنه ليس لدى أي منها حاليًا دليل قوي على الأمن. صعب جدًا بحيث يمكنني القول بثقة أنه آمن حقًا.
لذا ، ها هو الحل الذي توصلنا إليه نتيجة لذلك. تحتوي شبكتنا على العديد من السلطات الموثوقة ، التي تديرها جهات موثوقة ، والتي تجمع قوائم العقد التي تصوت كل ساعة على العقد التي يمكن أن تعمل على الشبكة ويمكنها التصويت لاستبعاد العقد المشبوهة. كلهم يعملون على نفس / 16 ، التي تفعل مثل هذه الأشياء الغريبة مع حركة المرور ، وتشكل إجماعًا يعتمد على حساب نتيجة التصويت.
ولا يستخدم العملاء العقدة إذا لم يتم توقيعها بعدد كافٍ من "الأصوات" للأطراف الموثوق بها.
هذه ليست النسخة النهائية من المشروع ، لكنها أفضل ما تمكنا من التوصل إليه حتى الآن. بالمناسبة ، كل ما تحتاجه لتوزيعه بين العملاء هو قائمة بجميع المفاتيح العامة المعتمدة وقائمة ببعض الأماكن لتلقي الدلائل. تريد من جميع العقد تخزين هذه الدلائل مؤقتًا ، لأنه إذا لم تقم بذلك ، سيصبح حمل الشبكة خطيرًا وسوف ينخفض عرض النطاق الترددي للشبكة بشكل كبير.
أعتزم تخطي السؤال التالي والانتقال مباشرة إلى كيفية اختيار العملاء للمسارات التي يجب عليهم توجيهها عبر الشبكة. أود أن أتحدث عن مشاكل استخدام وإنشاء تطبيقات لا تخون نفسها. أود أن أتحدث عن انتهاكات الشبكة ، والخدمات الخفية وكيفية عملها ، والحديث عن مقاومة الرقابة ، وأود أيضًا التحدث عن الهجمات والحماية. ولكن لم يتبق لدينا سوى 35 دقيقة ، لذا لا يمكنني التحدث عن كل ما أريده. أطلب منك التصويت على المواضيع التي تعتبرها الأكثر أهمية للمناقشة.
إذا كنت تعتقد أن أحد أهم الموضوعات هو اختيار المسارات والعقد ، فيرجى رفع يدك. إذا كان أحد أهم الموضوعات هو مشاكل التطبيق وكيفية التأكد من أن التطبيقات لا تنتهك هويتك ، يرجى رفع يدك. إذا كانت إساءة الاستخدام من أهم المشكلات وكيف يمكن منعها ، فالرجاء رفع يدك. لذا ، أرى أن هذا الموضوع شائع ، وقم بتمييزه.
إذا كان من المهم بالنسبة لك كيف تعمل الخدمات المخفية وكيف يمكن جعلها تعمل بشكل أفضل ، فالرجاء رفع يدك. , , . , . , ? , . ?
, . , , . , , — .
, . , IP-, , . , Whole stack, -, , Tor.
«» -, , , , , , , , .
, : , , , . , -, . , . , . . , .
, . , , – , -, . , BitTorrent, Gnutella . , , , .
, , , 80 443. , 80. IRC- - IRC. -, , , , .
, , - 80 443, , , . , Tor. - , . , , .
, - IRC- IP-.
, My Little Pony, IRC-, , , , – . , IP-, , IP- . Tor .
IP- ? , IP ? رقم , IP, . , IP-, .
IP- , , , , , , Tor -.
. - «» ? , IP, , IP IP-. , , IP-.
, , , , . – « ». , , , , , IRC – , , , .
, . , . , , , - IP, .
- . , 2013 , « 2» , Silk Road. « 2» , Tor, , , .
, - , OPSEC – . , , . Tor , .
, , , , , « ». : «, , . , , . , , — ». , , .
54:00
معهد ماساتشوستس للتكنولوجيا بالطبع "أمن أنظمة الكمبيوتر". 19: « », 3 ( Tor).
شكرا لك على البقاء معنا. هل تحب مقالاتنا؟ تريد أن ترى المزيد من المواد المثيرة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية به لأصدقائك ،
خصم 30٪ لمستخدمي Habr على تناظرية فريدة من خوادم الدخول التي اخترعناها لك: الحقيقة الكاملة حول VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1 جيجابت في الثانية من 20 $ أو كيفية تقسيم الخادم؟ (تتوفر خيارات مع RAID1 و RAID10 ، ما يصل إلى 24 مركزًا وما يصل إلى 40 جيجابايت من ذاكرة DDR4).
VPS (KVM) E5-2650 v4 (6 نوى) 10GB DDR4 240GB SSD 1Gbps حتى يناير مجانًا عند الدفع لمدة ستة أشهر ، يمكنك الطلب هنا .ديل R730xd 2 مرات أرخص؟ لدينا فقط
2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD بسرعة 1 جيجابت في الثانية 100 TV من 249 دولارًا في هولندا والولايات المتحدة الأمريكية! اقرأ عن
كيفية بناء البنية التحتية فئة باستخدام خوادم V4 R730xd E5-2650d تكلف 9000 يورو عن بنس واحد؟