مؤتمر DEFCON 19. ثلاثة أجيال من هجمات حجب الخدمة (التي تنطوي على الجمهور كضحايا). الجزء 1ولكن الأسوأ من ذلك ... لقد حاولت تطوير مشروع لطلابي ، واتضح أنه مضحك ، ولكن المشكلة كانت أنه من المستحيل رؤية عناوين "القتلى" ، لأن هذا هو ما تحتاجه لرؤية تكوين IP. لكن إذا نفذت الهجوم سريعًا حقًا ، فسيستجيب النظام على الفور ولن يرى أحد ما حدث له.
لقد قمت بذلك حتى تتمكن من رؤية الشبكة بالكامل ، وجميع عناوين صفحة الشبكة هذه بصفحة. يمكن جعل هذه القائمة أكبر ، حيث تمت إضافة 5 عناوين IP في الثانية إليها. عندما بدأت هذا المشروع لأول مرة ، بدا لي أنه لم يحدث شيء ، لأن جهاز Windows لم يتفاعل مطلقًا مع ما حدث.
لن يكون الطلاب مهتمين ، لأنهم لن يتعلموا أي شيء إذا لم يتمكنوا من رؤية الضرر الناجم عن الهجوم. اعتقدت "حسنًا ، هذا مشروع سيئ ، ماذا علي أن أفعل؟" ، لكن بعد ذلك بزغ فجرًا - هذا الشيء يقتل وحدة تحكم بالمجال وخادم بريد وكل ذلك ، إنه سيء جدًا. هذا أمر سيء للغاية لدرجة أنني لا أستطيع أن أخبر طلابي به على الإطلاق ، من الأفضل أن أخبر Microsoft به بهدوء!
لذا فقد أرسلت تغريدة بأن Windows 7 يحتوي على ثغرة أمنية خطيرة ، ومع ذلك ، فهي ليست مفاجئة على الإطلاق. قلت إنه فيما يتعلق بهذا ، أحتاج إلى جهات اتصال من خدمة أمان Windows ، وساعدني الأشخاص على Twitter في العثور على الأشخاص المناسبين في Microsoft. بعد يومين ، تلقيت ردًا رسميًا من Microsoft ، حيث تم الإبلاغ عن أن مارك هيوز أخبرهم بذلك منذ عام. ولكن هذا ليس مهمًا ، لأنهم لا يعتزمون إجراء تصحيحات على الإصدارات الحالية من Windows ، ولأن Vista و Windows 7 و Windows Server 2003 و Windows Server 2008 و Windows XP يموتون تدريجياً ويتوقفون عن دعمهم. بدلاً من ذلك ، سيقومون بإصلاح مشكلة عدم الحصانة هذه في نظامي التشغيل Windows 8 أو Windows 9 إذا لم يأتوا بعد بشيء ما.
اعتقدت - حسنًا ، إذا كنت ستتصرف بهذه الطريقة ، فسأخبر العالم بأسره بهذا الأمر ، وسأطلب من طلابي اختبار هذا المشروع كواجب منزلي ، وحذرهم من استخدامه في شبكة معزولة ، وإلا يمكنك قتل جميع أجهزة الكمبيوتر في الكلية ، بما في ذلك خوادمنا. لقد فعلوا ذلك بالضبط ، لذلك ما زلت أدرس هناك ، بدلاً من الوقوف في الشارع مع القدح من أجل الصدقات.
في أي حال ، هذا هجوم قوي للغاية ، وأود أن أتحدث قليلاً عن كيف يمكنك الدفاع ضده. لكن قبل أن أبدأ ، سأسلم هذا الأمر إلى ماثيو ، والشيء الوحيد الذي أريده هو أن تختبر الآن تأثير هذا الهجوم على نفسك.
جميع أجهزة وأجهزة الكمبيوتر التي تعمل بنظام Windows والتي تحتوي على أحد إصدارات Free BSD Unix عرضة لهجوم RA Flood ، ولكن الأجهزة التي تعمل بنظام التشغيل MAC OS و Open BSD معرضة للخطر. إذا نظرت إلى تكوين جهاز MacBook الخاص بي ، فسترى أنه مضيف أيضًا وقد انضم إلى بعض الشبكات الموجودة هنا ، سترى هنا شبكة inet6 بعنوان يبدأ من عام 2001.
لقد كان متصلاً ببعض هذه الشبكات عديمة الفائدة ، ولكن ليس لجميع الشبكات. أعتقد أنه يمكن أن يكون شبكات DefCon. ولكن على أي حال ، ترى أن "MacBook" الخاص بي متصل لبعض الوقت بالشبكات العشرة الأولى التي تم العثور عليها ولم يعد ينتبه إلى RA. هذا دفاع جيد جدًا ، وأعتقد أن Microsoft كان يجب أن تأتي من Windows أيضًا ، لكنهم غير مهتمين برأيي. أصدرت شركة Cisco تصحيحًا مصممًا لحماية معداتها من الهجمات من هذا النوع ، ولم يقم Juniper بذلك.
لذلك إذا كان لديك أجهزة للاختبار ، فسيقوم Ryan بإعداد شبكته المعزولة وقتل شخص ما هناك. إذا كنت ترغب في المشاركة في هذا ، يمكنك الانضمام إلى شبكة SSID المسماة "لا تستخدم" ، والتي تستخدم تشفير WPA2 ، لذلك تحتاج إلى إدخال كلمة المرور "لا تستخدم". إذا انضممت إلى هذه الشبكة ، سيرى ريان عدد الأشخاص الموجودين على الشبكة ويقتلك. هذا القتل مثير للاهتمام للغاية ، لأنه يساعد على معرفة الأجهزة الأخرى المعرضة للخطر ، باستثناء Windows و BSD المجانية.
قال بعض الأشخاص إنهم سيحضرون أجهزة مثيرة للاهتمام هنا ، وأود أن أعرف عنها ، لذا سأطلب منك بعد العرض التوضيحي الذهاب إلى غرفة الأسئلة والأجوبة والتحدث عنها. ثم يمكننا إبلاغ الشركة المصنعة لتشجيعه على إصدار تصحيح للكشف عن ضعف جهازه. أعتقد أن الكثير من الناس عرضة لهجمات من هذا النوع ، ولكن لا يعرفون ذلك.
سأعطي الكلمة الآن لماتي لتخبر قصة LulzSec ، وبعد ذلك سأواصل الحديث عن الدفاع ، إذا كان لدينا وقت. الآن ، سوف أغلق جميع النوافذ لمسح سطح المكتب. أنا آسف ، اسم الشبكة هو "عدم الاتصال" وكلمة المرور هي أيضًا "عدم الاتصال"!
ماثيو برنس: سام هو الشخص الوحيد الذي أعرفه والذي يمكنه تنفيذ هجوم من نوع DDoS بمثل هذا السحر. اسمي ماثيو برنس ، أعرف سام ، كلانا يعيش في سان فرانسيسكو وكلاهما مشارك في قصة LulzSec.
لذلك ، سوف أخبركم قصة حول جرهم إلى هذا ، وعن بعض هجمات DDoS التي لاحظناها لمدة 23 يومًا ، وما الذي فعلناه لمنعهم.
في 2 يونيو 2011 ، في حوالي الساعة 4:54 مساءً بتوقيت جرينتش ، أعلنت LulzSec على حساب Twitter الخاص بها أنها قد أنشأت صفحة Lulz Security على موقع
lulzsecurity.com . الأمر المثير للدهشة هو أن هذه الصفحة كانت بلا اتصال لمدة 15 دقيقة بسبب هجوم قوي على DDoS. لا أعرف تفاصيل هذا الهجوم بالذات ، لأننا لم نشارك بعد في هذا الهجوم.
بعد حوالي ساعة من نشر المنشور الخاص بإنشاء الصفحة ، قام LulzSec بتغريده بأنه قادر على حل مشكلة رفض الخدمة. الشيء الوحيد الذي تغير خلال هذا الوقت ، كما أبلغت لاحقًا ، هو أنهم اشتركوا في خدمة CloudFlare لدينا قبل 9 دقائق من هذه الرسالة. نحن نجعل مواقع الويب أسرع ونحميها من بعض أنواع الهجمات ، لكننا لا نعتبر أنفسنا خدمة لمنع هجمات DDoS ، لذلك فوجئ البعض منا بهذا القانون LulzSec.
كانت المفاجأة الكبرى الأخرى هي أنه بعد ساعة من ذلك ، نشر المتسللون رسالة موجهة إليّ والتي اعترفوا فيها بحبهم لـ CloudFlare وسألوا عما إذا كان يمكنهم الاعتماد على حساب ممتاز مجاني في مقابل رم.
لم يكن لدي أي فكرة عمن كان هؤلاء LulzSec في ذلك الوقت ، لذلك كتبت رسالة على Twitter ، والتي قالها المحامي الخاص بي لحذفها: "هذا يعتمد على مدى جودة الروم". يجب أن أقول على الفور أنهم لم يرسلوا إلينا مطلقًا ، ولم نوفر لهم مطلقًا حسابًا احترافيًا. لكن CloudFlare هي خدمة مجانية ، كل يوم لدينا الآلاف من المواقع المسجلة ، وعادة لا نواجه مشاكل معهم.
لذلك ، على مدار الـ 23 يومًا التالية ، دمر هؤلاء الرجال الفوضى بطرق متنوعة. أخيرًا ، في 25 يونيو ، قاموا بنشر تغريدة تمثل نهاية الهجوم.
كان من المثير للاهتمام أن CloudFlare يعمل كوكيل عكسي ، لذلك فإن كل حركة المرور التي ذهبت إلى Lulz Security ذهبت أولاً عبر شبكتنا ، والتي لها تأثيران مهمان. الأول - أي شخص قام بمهاجمة Lulz Security هاجمنا ، والثاني - بفضلنا ، Lulz Security يمكن أن يخفي موقع مصدر الهجوم ، أي المكان الذي توجد به استضافة الموقع بالفعل. هذه هي الآثار الجانبية لهندسة نظامنا ، لكن المتسللين استخدموها لصالحهم.
اتصل بي سام منذ فترة وقال إنه سيتحدث عن DDoS. تحدثنا عن تجربتنا وتساءل عما إذا كان بإمكاني مشاركة بعض المعلومات حول هذا الأمر. لدينا مستشار قانوني ، نحن شركة حقيقية لها سياسة الخصوصية الخاصة بنا ، وحتى إذا كنت مدرجًا في القائمة الدولية المطلوبة لجرائم الإنترنت ، فنحن نحاول احترام خصوصيتك. لذلك ، كتبت خطابًا إلى LulzSec وأرسلته إلى عنوان البريد الإلكتروني المشار إليه في حسابي.
أخبرتهم أنني دعيت إلى DefCon كمتحدث ، لذلك تحدثت عن الهجمات على CloudFlare المتعلقة بأنشطة مجتمعهم. لقد كتبت أن بعض المعلومات التي أرغب في توصيلها أثناء العرض التقديمي محمية بموجب سياسة الخصوصية الخاصة بنا ، لذلك أطلب من LulzSec الموافقة على الكشف عنها. بعد 11 يومًا ، أجابني شخص يدعى جاك سبارو بالنص: "لديك موافقتك".
وهنا أنا ، للحديث عن بعض الأشياء التي لم أستطع التحدث عنها دون هذا الإذن. يمكنني أن أتحدث عن تأثيرهم علينا ، لكنني لن أخبركم عن المضيفين الذين اعتادوا على مهاجمتهم أو عناوين IP الحقيقية.
اسمحوا لي أن أخبركم قليلاً عما حدث في هذه الأيام الـ 23 وأعرض تحليلًا لحركة المرور الفعلية إلى موقع Lulz Security خلال هذا الوقت.
خلال هذا الوقت ، تم إجراء أكثر من 18 مليون مشاهدة للصفحة عندما زار الأشخاص هذا الموقع. يمكنك أن ترى أنه منذ بداية الهجوم تقريبًا من 22 يونيو وحتى 5 يوليو ، لوحظت ذروة حركة المرور العادية ، ثم توقف الموقع عن العمل ، على الرغم من أنه لا يزال يستخدم CloudFlare. إذا حاولت زيارة هذا الموقع اليوم ، فستشاهد فقط صفحة تكوين Apache هناك ، ولا أعرف ما الذي يخططون للقيام به بعد ذلك.
من المثير للاهتمام أن ننظر إلى حركة المرور التي أدت إلى سقوط الموقع.
أود أن أقول إن كل حركة المرور إلى الذروة في المنتصف هي مجرد ضوضاء خلفية طبيعية ، حيث لم يكن هناك شيء مميز ولم ينبئ أي شيء بما سأظهره على الشريحة في بضع ثوانٍ. في الواقع ، كانت الأسابيع الثلاثة التي استخدم خلالها LulzSec خدمة CloudFlare هادئة إلى حد ما فيما يتعلق بهجمات DoS. هذا غريب لأن الكثير من الناس قالوا إنهم هاجموا LulzSec في ذلك الوقت.
سبب الذروة في منتصف المخطط بضع أحداث واضحة للغاية ، والتي سأناقشها لاحقًا. سنتحدث أيضًا عن أنواع الهجمات التي استخدمت ضد LulzSec وما فعلناه لحماية أنفسنا.
حدث مثير للاهتمام بشكل خاص في 25 يونيو. كان مرتبطا جيستر. لم أكن أعرف من كان ، لذلك زودني سام ببعض المواد عنه.
يبدو أن Jester قضى الكثير من الوقت في معرفة موقع LulzSec على الويب ونشر بفخر عناوين IP الخاصة بمواردها على
صفحته : www.lulzsecurity.com: 204.197.240.133 و lulzsecurity.com: 111.90.139.55.
أعرف ما هو المضيف لموقع LulzSec في 25 يونيو ، وأستطيع أن أقول لك إن هذه العناوين لا علاقة لها بها. خلال هذه الأيام الـ 23 ، استخدموا 7 مضيفين مختلفين ، في البداية كان المضيف يقع في مونتريال ، كندا. لبعض الوقت ، في أوائل يونيو ، تم استخدام الاستضافة الماليزية بعنوان IP الخاص بـ 111.90.139.55. معظم المضيفين الذين يستخدمونهم كانوا موجودين في الولايات المتحدة ، بما في ذلك مضيف كبير متخصص في التخفيف من آثار هجمات حجب الخدمة ، وفي النهاية تحولوا إلى الاستضافة الألمانية ، حيث يوجد الموقع اليوم.
ومن المثير للاهتمام ، أن الكثير من الناس ادعوا أنهم هم الذين أسقطوا موقع LulzSec ونشروا الصور ذات الصلة على الإنترنت. في الواقع ، يوضح هذا ببساطة الخدمة التي نقدمها في CloudFlare - إذا تم قطع اتصال خادم الجهة الخلفية ، نعرض نسخته المخزنة مؤقتًا ، كما يتضح من الشريط البرتقالي في أعلى الصفحة. يخبر المستخدم أنه يتصفح ذاكرة التخزين المؤقت ، تمامًا كما هو الحال مع ذاكرة التخزين المؤقت للصفحة على Google.
أعتقد أنه عندما ادعى الأشخاص أنهم أسقطوا موقع LulzSec ، فإن ما حدث حقًا هو أن اللاعبين من LulzSec تم طردهم ببساطة من مضيفيهم. لذلك ، لمدة 36 ساعة قصيرة ، أشاروا فعليًا إلى عنوان IP غير الصحيح 2.2.2.2 كعنوان لهم ، لأنه لا يوجد مضيف أو خادم ويب نشط تحت هذا العنوان. أعتقد أنهم اختاروا عنوان IP عشوائيًا حتى يتمكن نظامنا من "دفعهم" باستمرار عبر الإنترنت ، لأن إصدار ذاكرة التخزين المؤقت موجود لفترة محدودة من الوقت حتى تنتهي صلاحيته. في هذه المرحلة ، عادوا لفترة وجيزة إلى المضيف وأشاروا إلى عنوان مزيف لمجرد ظهوره في ذاكرة التخزين المؤقت الخاصة بنا.
لا أعرف شخصًا واحدًا من شأنه أن يشير إلى أن موقع LulzSec يعمل دون اتصال بالإنترنت لفترة قصيرة على الأقل ، على الرغم من أن العديد من الأشخاص حاولوا إخراجه من وضع الاتصال بالإنترنت. في الواقع ، في الوقت نفسه ، كانت LulzSec هي التي أسقطت مواقع لأشخاص آخرين ، على سبيل المثال ، موقع CIA على الويب ، وكان من المثير للاهتمام مراقبة هذه الهجمات. تسرد الشريحة الهجمات التي لاحظناها بالضبط.
لقد فوجئنا للغاية و "وضع الجميع على آذان" حرفيًا خلال هجوم DDoS ، الذي حاول إسقاط الموقع لمدة ثلاثة أسابيع ، حيث لاحظنا عادة الهجمات التي استمرت لفترة أقصر بكثير من الوقت. ليس من الخطر بمكان إغواء المتسللين الذين يرعون على موقع تويتر بقدر ما يستهجنون المافيا الإلكترونية الصينية أو أوروبا الشرقية أو الأشخاص الذين يشاركون في الابتزاز عبر الإنترنت ، لأنهم الأشخاص القادرون على شن هجمات قوية على DDoS. نعم ، هؤلاء الرجال أذكياء بدرجة كافية ، لكن لا تزال مثل هذه الهجمات غير مستوية.
لقد لاحظنا العديد من الهجمات غير الضارة نسبيًا على مستوى OSI 7 باستخدام أدوات مثل Slowloris. لكن خادم الويب الداخلي الخاص بـ CloudFlare مصمم خصيصًا ليس فقط "لقتل" الهجمات إلى المستوى السابع ، ولكن أيضًا لإصلاح جميع عناوين IP التي حدثت منها هذه الهجمات. أقصد ، في الواقع ، أننا سعداء فقط عندما يهاجم المتسللون المستوى السابع لدينا ، لأن هجمات DDoS في المستوى 3 أو 4 تسبب لنا المزيد من المتاعب.
في هذه الحالة ، نخفف من عواقبها ، حيث نستخدم شبكة Anycast. هذا يعني أن لدينا مجموعة من الأجهزة ، ومئات ومئات أجهزة الكمبيوتر التي تعمل في 14 مركز بيانات مختلف حول العالم وترتبط بنفس عنوان IP.
يتيح لك ذلك "رش" DoS الموزعة - الهجوم أو الهجوم بكمية كبيرة من حركة المرور على سطح شبكة كبير ، مما يجعل من الصعب للغاية استخدام مثل هذه الهجمات ضدنا.
جلبت الكثير من المتاعب لنا هجمات من نوع مختلف. تم إنتاج الأول باستخدام شيء يشبه شبكة كبيرة جدًا بها كمية هائلة من حركة المرور أرسلها المهاجمون إلينا مباشرةً. كانت هذه الشبكة موجودة جغرافيا بالقرب من مركز البيانات الخاص بنا في سان خوسيه ، واستخدموا جميع النطاق الترددي تقريبًا. اضطررنا إلى نقل عملائنا إلى مراكز بيانات أخرى أقل نشاطًا ، لذلك لم يؤثر ذلك عليهم. لكن مركز البيانات في سان خوسيه في ذلك الوقت كان قادرًا فقط على خدمة Lulz Security ، مع الاستمرار في الاحتفاظ بها على الإنترنت.
هجوم أكثر إثارة للاهتمام ، والذي هدد معظم الناس على اتصال معنا ، استخدم جوجل "عاكس" لحركة المرور. نلتزم بقواعد محددة تتعلق بعناوين IP الخاصة بـ Google للتأكد من أننا لا نمنع مطلقًا حركة المرور المشروعة القادمة إلينا من هناك. اكتشف شخص ذكي حقًا أنك إذا أرسلت الكثير من طلبات SYN إلى Google برؤوس وهمية تشير إلى عنوان IP الخاص بنا ، فستقوم Google بإعادتها إلينا. كان حل هذه المشكلة بسيطًا جدًا ولم يستغرق سوى بضع دقائق - فقد حظرنا ACKs التي لم يتم إرفاق SYNs بها ، ثم اتصلنا بأصدقائنا على Google وقلنا إنهم لن يتلقوا أي حركة مرور من هذه المصادر ، لذلك فقط استخدم جدار حماية ضدهم . لقد كان هجومًا ذكيًا بالفعل أخذ في الاعتبار طبيعة بنيتنا التحتية واستفاد من ميزات عملها.
استند الهجوم الأخير ، الذي تسبب في الكثير من المتاعب ، إلى حقيقة أن شخصًا ما قام بمسح دقيق لعناوين عناوين IP الخاصة بنا واكتشف واجهات جهاز التوجيه هناك التي كانت عرضة لتأثيرات خارجية. باستخدام هذا ، شن أحد المهاجمين هجومًا من نوع القاموس وقام بتعطيل العديد من أجهزة التوجيه الخاصة بنا ، بعد أن نجح في تجاوز Anycast.
تبين أن حل المشكلة مرة أخرى بسيط للغاية - فقد حظرنا عناوين IP الموجودة خارج شبكتنا ، لكن الهجوم تسبب لنا في أضرار ، لأنه لعدة دقائق تم إيقاف أجهزة التوجيه الخاصة بنا دون اتصال بالإنترنت.
كما تعلمون ، عندما قارنت أكبر الهجمات التي شهدناها ، شاهدتها حتى عندما تلقى عميلنا رسالة بريد إلكتروني تحتوي على النص: "مرحبًا ، نحن وكالة حكومية صينية اكتشفت أن شخصًا ما على الشبكة سوف يهاجمك "وإذا أرسلت لنا 10،000 دولار ، فمن المحتمل أن نتمكن من حل هذه المشكلة." من الواضح أن هذه ليست وكالة ، لكنهم قادرون حقًا على حل هذه المشكلة ، لأنهم هم أنفسهم الذين ينشئونها. ومع ذلك ، كان هناك عدد قليل نسبيا من هذه الهجمات.
سأتحدث عن بعض الأشياء الأكثر إثارة للاهتمام. تتزامن الزيادة السريعة على خلفية حركة المرور العادية في الخلفية مع بيان LulzSec بأنها تحطمت خوادم Minecraft. بعد انتهاء الهجوم ، انخفضت حركة المرور قليلاً.
بدأ مشجعو Minecraft في مكتبنا في نقاش كبير حول ما إذا كان يجب على LulzSec ألا يغادر شبكتنا بعد ذلك ، لأنهم قد تسببوا في الكثير من الضرر وبشكل عام ، هذا ليس جيدًا على الإطلاق. لذلك يمكنك تعلم درس مفاده أنه إذا كنت ستنظم هجومًا على DDoS ضد شخص ما ، فمن الأفضل عدم لمس Minecraft.
لدي القليل من المعلومات حول من هم هؤلاء الأشخاص في Lulz Security حقًا ، فهي بالنسبة إلينا واحدة من أسماء المستخدمين الذين ينشئون حسابات على Cloudflare. إنه يشبه إلى حد كبير اسم الشخص الذي ألقي القبض عليه ، ولا أعرف ما إذا كان هذا مجرد صدفة أو ما إذا كان هؤلاء الأشخاص قد أسقطوا هذه المواقع بالفعل. لم نلاحظ مثل هذا النشاط الكبير وراءهم لنقل مضيفيهم ، علاوة على ذلك ، فإن موقعهم قد توقف الآن.
ومع ذلك ، كان من المثير للاهتمام أن نلاحظ كيف حاول العالم كله "قتلهم" لمدة 23 يومًا ، وبقدر ما يكون الأمر كذلك ، فقد ساعدناهم على البقاء واقفين على قدميه. شكرا لدعوتي هنا!
سام بون: شكرًا ، ماثيو ، على قرارك بالحضور. الآن سأعود إلى العرض التقديمي. لقد سمعت الكثير من الحديث عن كيف أن الهجوم أسهل من الدفاع ، لذلك سأريك هجومًا سيشمل كل شيء. , , Microsoft , . . , RA Flood.
, IPv6, , , . Router Discovery , , IPv6, , , .
RA Windows, . , . Cisco RA Guard, Windows, . , Cisco . RA Guard , RA-, .
, : , . — , — , .
, , . , Mod Security, , DDoS 7- . , — IP- , , Tor , .
, Akamai, , . Load Balancer, , , . , , 4 , .
. , - HT More , DNS- C&C , . , . Flood- , Anonymous Low Orbit Ion Canon.
CloudFlare, , — , , , , . , , , . , CloudFlare, .
, . , , , . , – , , . , , .
, , ? - ? - ? ? , , . , . , !
شكرا لك على البقاء معنا. هل تحب مقالاتنا؟ تريد أن ترى المزيد من المواد المثيرة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية به لأصدقائك ،
خصم 30٪ لمستخدمي Habr على تناظرية فريدة من خوادم الدخول التي اخترعناها لك: الحقيقة الكاملة حول VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 20 $ أو كيفية تقسيم الخادم؟ (تتوفر خيارات مع RAID1 و RAID10 ، ما يصل إلى 24 مركزًا وما يصل إلى 40 جيجابايت من ذاكرة DDR4).
ديل R730xd 2 مرات أرخص؟ فقط لدينا
2 من Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6 جيجا هرتز 14 جيجا بايت 64 جيجا بايت DDR4 4 × 960 جيجا بايت SSD 1 جيجابت في الثانية 100 TV من 199 دولار في هولندا! Dell R420 - 2x E5-2430 سعة 2 جيجا هرتز 6 جيجا بايت 128 جيجا بايت ذاكرة DDR3 2x960GB SSD بسرعة 1 جيجابت في الثانية 100 تيرابايت - من 99 دولارًا! اقرأ عن
كيفية بناء البنية التحتية فئة باستخدام خوادم V4 R730xd E5-2650d تكلف 9000 يورو عن بنس واحد؟