معهد ماساتشوستس للتكنولوجيا. محاضرة رقم 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 سنتحدث اليوم عن أمان الشبكة ، على وجه الخصوص ، سنناقش مقالًا بقلم ستيفن بيلوفين بعنوان "نظرة إلى الوراء على" مشكلات الأمان في TCP / IP Protocol Suite ". كان هذا الرجل يعمل لدى AT&T ويعمل الآن في كولومبيا. الأمر المثير للاهتمام في هذا العمل هو أنه قديم نسبيًا - إنه يزيد عن 10 سنوات ، وفي الواقع ، هذه تعليقات على مقال صدر قبل عقد من الزمان في عام 1989.
يسأل الكثير منكم يا رفاق لماذا ندرس هذا إذا تم حل العديد من المشاكل الموضحة هناك في إصدارات اليوم من بروتوكول TCP.
صحيح أن بعض المشاكل التي وصفها ستيفن قد تم حلها منذ ذلك الحين ، ولا يزال بعضها مشاكل. مع أخذ ذلك في الاعتبار ، سنقوم بفرزها ونرى ما سيحدث. قد تتساءل لماذا لم يحل الناس كل هذه المشاكل في المقام الأول عند تصميم برنامج التعاون الفني؟ ماذا كانوا يفكرون فقط؟
وهذا في الواقع غير واضح. ما رأيك؟ لماذا لم يكن بروتوكول TCP يتمتع بالأمن اللازم ، مع مراعاة كل هذه الاعتبارات؟ اي اقتراحات؟
الطالب: في ذلك الوقت ، كان الإنترنت مكانًا أكثر سذاجة.
الأستاذ: نعم ، لقد كان حرفياً اقتباسًا من مقالة هذا الرجل. نعم ، في ذلك الوقت بشكل عام ... أعتقد أنه تم تطوير مجموعة من بروتوكولات الإنترنت قبل حوالي 40 عامًا. كانت المتطلبات مختلفة تمامًا. كان من الضروري فقط توصيل مجموعة من المواقع الساذجة نسبيًا التي تعرف بعضها البعض بالاسم بشبكة مشتركة.
أعتقد أن هذا يحدث غالبًا في أي نظام يصبح ناجحًا - فهو يحتاج إلى تغييرات. اعتاد أن يكون بروتوكول لعدد قليل من المواقع ، والآن هذا البروتوكول يغطي العالم كله. ولم تعد تعرف باسم جميع الأشخاص المتصلين بالإنترنت. لا يمكنك الاتصال بهم إذا قاموا بشيء سيئ ، وما إلى ذلك.
لذلك ، أعتقد أن هذه القصة هي نفسها بالنسبة للعديد من البروتوكولات التي ندرسها. والكثير منكم يسألون سؤالاً ، "ماذا كان يفكر هؤلاء الرجال؟ هذا معيب للغاية! " لكن في الواقع ، صمموا نظامًا مختلفًا تمامًا ، وقاموا ببساطة بتكييفه مع الاحتياجات الحديثة.
الشيء نفسه ، والإنترنت ، كما نظرنا خلال الأسبوعين الماضيين ، تم تصميمهما لغرض مختلف تمامًا. لكنها توسعت ، وكان لدينا مخاوف جديدة حول كيفية تكييف هذا البروتوكول مع المتطلبات الحديثة.
هناك شيء آخر حدث فجأة ، وهو أنه كان على الناس المبالغة في تقدير خطورة المشكلة الأمنية. كان من المعتاد أنك لم تفهم كل الأشياء التي يجب أن تقلق بشأنها ، لأنك لم تكن تعرف ما كان المهاجم قادرًا على فعله بنظامك.
أعتقد أنه لهذا السبب جزئياً ، سيكون من المثير للاهتمام رؤية ما حدث لأمن TCP ، وما الخطأ الذي حدث ، وكيف يمكننا إصلاحه ، وما إلى ذلك. نتيجة لذلك ، يجب أن نكتشف أنواع المشاكل التي يجب تجنبها عند تطوير بروتوكولاتنا ، وكذلك ما يشكل التفكير السليم في الهجمات من هذا النوع. كيف تعرف ما يستطيع المهاجم القيام به في البروتوكول الخاص بك عندما تقوم بتطويره فقط لتجنب المزالق المماثلة؟
حسنًا ، دعنا نترك الديباجة جانبًا ونتحدث عن هذه المقالة.
فكيف نفكر في أمن الشبكات؟ أعتقد أننا يمكن أن نبدأ بالمبدأ الأول ومحاولة معرفة ما هو نموذج التهديد لدينا. إذن ما الذي يمكن أن يفعله المهاجم على شبكتنا؟
ربما لديه القدرة على اعتراض الحزم ، وربما يكون قادرًا على تعديلها. وبالتالي ، إذا كنت ترسل حزمة عبر الشبكة ، فمن المنطقي أن نفترض أن شخصًا سيئًا سيرى حزمتك ويكون قادرًا على تغييرها قبل وصولها إلى وجهتها. قد يكون بإمكانه أيضًا إسقاطه واستخدام القدرة على إدخال حزم مخصصة ذات محتوى عشوائي لم ترسله مطلقًا.
ولكن الأكثر خطورة هو احتمال تدخل الأشرار في بروتوكولاتك الموضحة في المقالة. يمتلك المهاجم حاسوبه الخاص الذي يسيطر عليه بالكامل. حتى إذا كانت جميع أجهزة الكمبيوتر التي تثق بها تتصرف بشكل صحيح ، فإن الشخص السيئ الذي لديه جهاز كمبيوتر خاص به يمكنه التدخل في البروتوكول أو النظام الخاص بك.
لذلك إذا كان لديك بروتوكول توجيه يتضمن الكثير من الأشخاص يتحدثون مع بعضهم البعض ، وربما يكون بعض القياس غير عملي لإبقاء الأشرار في الخارج. إذا كان بروتوكول التوجيه يعمل مع 10 مشاركين ، فربما يمكنك الاتصال بهم جميعًا ثم قول ، "حسنًا ، نعم ، يا رفاق ، أعرفكم جميعًا."
ولكن على نطاق الإنترنت اليوم ، من المستحيل معرفة من يستخدم أعضاء الشبكة الآخرين هذا البروتوكول مباشرة. لذلك ، على الأرجح ، سيشارك بعض الأشرار في البروتوكولات أو الأنظمة الموزعة. لذلك ، من المهم تصميم أنظمة موزعة يمكنها ، مع ذلك ، أن تفعل شيئًا معقولًا مع ذلك.
حسنا ، ما هي الآثار المترتبة على كل هذا؟ أعتقد أننا سنراجع القائمة. يسهل اعتراض الحزم المعترضة ، ولا يمكنك إرسال أي بيانات مهمة عبر الشبكة إذا كنت تتوقع أن يعترضها الشرير ، أو على الأقل لا ترسلها في نص عادي. ربما يجب عليك تشفير بياناتك.
يبدو من السهل نسبيًا الفهم ، على الرغم من أنك لا تزال بحاجة إلى وضع ذلك في الاعتبار عند تطوير البروتوكولات. يؤدي إدخال أو حقن الحزم إلى مجموعة أوسع من المشاكل المثيرة للاهتمام ، والتي تمت مناقشتها في هذه المقالة. على وجه الخصوص ، يمكن للمهاجمين حقن حزم يمكنها انتحال هوية حزم من أي مرسل آخر. نظرًا لأن مسار إرسال البيانات يعتمد على استخدام IP ، فإن الحزمة نفسها لها رأس يشير إلى عنوان IP المصدر للحزمة وعنوان IP الوجهة. ومع ذلك ، لا أحد يتحقق من صحة المصدر بالضرورة. هناك بعض التصفية في هذه الأيام ، لكنها ليست مثالية ويصعب الاعتماد عليها.
لذلك ، في التقريب الأول ، يمكن للمهاجم إدخال أي عنوان IP بالداخل كمصدر وإرساله إلى الوجهة الصحيحة. من المثير للاهتمام معرفة ما يمكن أن يفعله المهاجم بالقدرة على إرسال حزم عشوائية.
في الأسابيع السابقة ، نظرنا في مشكلات تجاوز سعة المخزن المؤقت من حيث أمان الويب. درسنا كيف يمكن للمهاجم استخدام خطأ في التنفيذ مثل تجاوزات المخزن المؤقت. من المثير للاهتمام أن كاتب هذه المقالة لم يكن مهتمًا حقًا بأخطاء التنفيذ ؛ فهو أكثر اهتمامًا بأخطاء البروتوكول.
ما الذي يميز هذا الأمر؟ لماذا لم ينتبه إلى أخطاء التنفيذ ، رغم أننا أمضينا عدة أسابيع لفحصها؟ لماذا يهم؟
الطالب: لأننا يجب أن نستبعد هذه الأخطاء عند كتابة البروتوكول.
البروفيسور: نعم ، هذا في الواقع فشل كبير بسبب خطأ في تصميم البروتوكول لأنه من الصعب تغييره. لذلك إذا كان لديك خطأ في التنفيذ ولديك memcpy أو نسخة مطبوعة لم تتحقق من نطاق الذاكرة ، فلا يمكنك ملاحظة هذا الخطأ. ولكن إذا كان لديك فحص نطاق وما زال يعمل ، فيمكن تجنب تجاوزات المخزن المؤقت ، لذلك هذا رائع.
ولكن إذا كان لديك نوع من الخطأ في مواصفات البروتوكول ، في كيفية عمل البروتوكول ، فإن تصحيح مثل هذا الخطأ سيتطلب إصلاح البروتوكول بالكامل ، مما يعني التأثير المحتمل على جميع الأنظمة التي تتحدث هذا البروتوكول. لذلك إذا وجدنا نوعًا من المشاكل في بروتوكول TCP ، فمن المحتمل أن يكون مدمرًا تمامًا. لأنه سيتعين على كل جهاز يستخدم TCP إجراء تغييرات ، نظرًا لأنه من الصعب جدًا جعل بروتوكول معدل متوافقًا مع الجهاز القديم.
كانت أخطاء بروتوكول TCP التي كان ستيفن قلقًا بشأنها أساسية ، لذا قرر التحدث عنها. في المثال الأول ، ينظر في كيفية عمل أرقام TCP SN.
الطالب: هذا موضوع بعيد قليلاً ، لكني أشعر بالفضول فقط. افترض أنك وجدت خطأ في TCP. كيف تجري تغييرات عليه؟ كيف تخبر جميع أجهزة الكمبيوتر في العالم أن هذا يحتاج إلى التغيير؟
الأستاذ : نعم ، أعتقد أن هذه مشكلة كبيرة. ماذا تفعل إذا وجدت خطأ في TCP؟ حسنًا ، ليس من الواضح ما يجب فعله. أعتقد أن المؤلف هنا يكافح مع هذا. إذا كان بإمكانك إعادة تصميم TCP ، فمن السهل نسبيًا إصلاح العديد من هذه الأخطاء إذا كنت تعرف مسبقًا ما الذي تبحث عنه.
ولكن نظرًا لأن بروتوكول TCP يصعب إصلاحه أو تغييره ، يحدث ما يلي في النهاية: يحاول المطورون العثور على إعدادات متوافقة مع الإصدارات السابقة والتي تتيح لك استخدام التطبيقات القديمة بالاقتران مع التنفيذ الجديد ، أو إضافة بعض الحقول الإضافية التي تجعل الاتصال أكثر أمانًا إلى حد ما.
لكن هذه مشكلة كبيرة. إذا كانت هذه مشكلة أمنية متجذرة بعمق في TCP ، فسوف تصبح مشكلة كبيرة للجميع ، لأنه من الصعب جدًا حتى التبديل ببساطة إلى إصدار TCP ، بافتراض n plus 1.
يمكن اعتبار IPv6 كمثال على أن هذا لا يحدث ، ونحن نعلم أن هذه المشكلة ستنشأ لمدة 15 عامًا أو 20 عامًا أخرى. IPv6 موجود منذ أكثر من 10 سنوات ، ولكن من الصعب إقناع الناس بالابتعاد عن IPv4. يبدو أن IPv4 كافٍ لهم ، ويبدو أنه يعمل ، ويعتقدون أن التحول إلى بروتوكول إنترنت جديد سيكون مكلفًا للغاية. يقولون: "لا أحد يتحدث IPv6 بعد الآن ، فلماذا أبدأ بالحديث عن هذا البروتوكول الغريب الذي لا يوجد أحد للتحدث معه؟" على أي حال ، هذا نوع من الحركة إلى الأمام ، لكنني أعتقد أنه سيستغرق الكثير من الوقت. سيكون هناك بالفعل بعض الدوافع للهجرة ، والتوافق مع الإصدارات السابقة في هذه الحالة يساعد كثيرًا.
يحتوي IPv6 على العديد من خيارات التوافق مع الإصدارات السابقة ، على سبيل المثال ، يمكنك التحدث إلى مضيف IPv4 باستخدام IPv6. لذلك ، يحاول المطورون تصميم كل هذا الدعم ، ولكن لا يزال من الصعب إقناع الأشخاص بالترقية.
لذلك ، بالنظر إلى أرقام تسلسل TCP ، سننظر بالفعل في مشكلتين تتعلقان بكيفية عمل مصافحة TCP. لذلك دعونا نقضي بعض الوقت في النظر في كيفية تأسيس اتصال TCP في البداية.
يتم إرسال ثلاث حزم لإنشاء اتصال TCP جديد. يقوم عميلنا بإنشاء حزمة للاتصال بالخادم ، والتي تنص على أنه هنا عنوان IP الخاص بالعميل ، فأرسله إلى الخادم. في نفس الوقت ، هناك بنية رأس حزمة تتكون من مناطق مختلفة ، ولكننا مهتمون بمساحة الرقم التسلسلي. هنا سيكون لدينا علامة SYN تقول: "أريد مزامنة الحالة وإنشاء اتصال جديد" ، ويتضمن الرقم التسلسلي لعميل SNc.
وبعد ذلك ، عندما يتلقى الخادم هذه الحزمة ، يقول: "يريد العميل الاتصال بي ، لذا سأعيد الحزمة إلى هذا العنوان ، بغض النظر عمن يقول أنه يحاول الاتصال بي". وبالتالي ، سيرسل الخادم الحزمة إلى العميل ، حيث يتضمن رقم تسلسل تزامن خادم SNs الخاص به ورقم تأكيد عميل ACK (SNc). وأخيرًا ، في الحزمة الثالثة ، يستجيب العميل للخادم ، ويؤكد التزامن ويرسل رقم تأكيد خادم ACK (SNs) إلى الخادم. الآن يمكن للعميل بدء إرسال البيانات.
وبالتالي ، من أجل إرسال البيانات ، في بداية الاتصال ، يجب على العميل تضمين بعض البيانات في الحزمة وإرفاق الرقم التسلسلي لعميل SNc للإشارة إلى أن هذه بيانات عميل شرعية بالفعل. يشير ، على سبيل المثال ، إلى أن هذه ليست بعض البيانات من الرسائل اللاحقة التي وصلت للتو الآن ، لأن الخادم فات بعض الأجزاء الأولية من البيانات.
وبالتالي ، كقاعدة عامة ، تم تصميم جميع هذه الأرقام التسلسلية لتوفير تسليم الحزم. إذا قام العميل بإرسال حزمتين ، الحزمة التي تحتوي على رقم تسلسل البداية هي أول قطعة من البيانات ، فإن رقم التسلسل التالي هو الجزء التالي من البيانات. كما أنه مفيد في توفير بعض متطلبات الأمان.
قبل ذلك ، أعطيت مثالاً على أن هذه المتطلبات تتغير. لذلك ، لم يكن أحد يعتقد في البداية أنه يجب أن يوفر TCP أي ميزات أمان. ولكن بعد ذلك بدأ TCP في استخدام التطبيقات ، وبدا أنهم يعتمدون على اتصالات TCP هذه ، معتقدين أنه لا يمكن كسرها من قبل أي مهاجم أو أن المهاجم لم يتمكن من حقن البيانات الضارة في اتصال TCP الحالي. كما لو فجأة ، بدأت هذه الآلية ، التي كانت مخصصة في الأصل لطلب الحزم ، في ضمان بعض مظاهر الأمان لهذه الاتصالات.
لذلك ، في هذه الحالة ، أفترض أن المشكلة تتعلق بما قد يقترحه الخادم فيما يتعلق باتصال TCP هذا. نموذجياً ، يفترض الخادم - ضمنياً ، كما يمكنك أن تتخيل - أن هذا الاتصال تم تأسيسه مع العميل المطلوب على عنوان IP هذا C ، ومن الطبيعي أن يعتقد ذلك. ولكن هل هناك أي سبب لمثل هذا الافتراض؟ إذا تلقى الخادم رسالة تحتوي على بعض البيانات حول اتصال العميل بالخادم ، ولديه رقم تسلسلي C ، فلماذا يستنتج الخادم أن العميل الحقيقي أرسل هذه البيانات؟
الطالب: من الصعب تخمين الرقم التسلسلي.
البروفيسور: حسنًا ، هذا نوع من الشيء الضمني ، مما يعني أنه يجب أن يكون هناك رقم تسلسل صحيح لـ SNc. ولكي يتم إنشاء هذا الاتصال ، يجب أن يكون لدى العميل رقم تسلسلي مؤكد لخادم SNs ، ويتم إرسال الرقم التسلسلي للخادم بواسطة الخادم إلى عنوان IP الخاص بالعميل فقط.
الطالب: كم عدد البتات المتاحة لرقم التسلسل؟
البروفيسور: رقم تسلسل TCP بطول 32 بت ، وعلى الرغم من أن هذا ليس رقمًا عشوائيًا ، إلا أنه ليس من السهل تخمينه ، فقد يستغرق الكثير من عرض النطاق الترددي.
الطالب: هل الرقم التسلسلي أعلى من الرقم التسلسلي الأولي؟
الأستاذ: نعم ، من حيث المبدأ ، هذه الأشياء تتزايد. لذلك ، في كل مرة ترسل فيها SYN ، تعتبر 1 بايت أكثر من رقم التسلسل الخاص بك. بمعنى ، إذا كان لدينا في الوسيطة الأولى الوسيطة (SNc) ، ففي الرابع سيكون هناك بالفعل (SNc + 1) ، ثم يستمر الترقيم من هنا. وبالتالي ، إذا قمت بنقل 5 بايت ، فستكون القيمة التالية (SNc) +6. تحسب ببساطة وحدات البايت التي ترسلها ، مع كل SYN يحسب 1 بايت. توصي مواصفات TCP باختيار هذه الأرقام التسلسلية بحيث تحدث الزيادة في بعض السرعة الثابتة تقريبًا. اقترحت وثائق العمل الأولية لبروتوكول RFC أن تقوم بزيادة هذه الأشياء بحوالي 250.000 وحدة بالإضافة إلى 250.000 في الثانية.
السبب في أن هذا لم يكن عشوائيًا تمامًا هو أن أرقام التسلسل هذه تُستخدم بالفعل لمنع الحزم من الفشل في التدخل أو لمزج الحزم من الاتصالات السابقة مع الاتصالات الجديدة. في كل مرة تقوم فيها بإنشاء اتصال جديد ، تختار رقمًا تسلسليًا عشوائيًا تمامًا. في الوقت نفسه ، هناك بعض الاحتمالات أنه إذا قمت بتثبيت سلسلة من الاتصالات مرارًا وتكرارًا ، فإن حزمة من الاتصال السابق سيكون لها رقم تسلسل مشابه تمامًا لرقم التسلسل لاتصالك الجديد وبالتالي سيتم قبوله من قبل الخادم كجزء صالح من البيانات الخاصة بالاتصال الجديد.
هذا ما كان يقلق مطورو TCP بشدة - هذه الحزم غير المرتبة أو الحزم المتأخرة. ونتيجة لذلك ، أرادوا حقًا أن تكون أرقام التسلسل هذه سلسلة زمنية رتيبة إلى حد ما حتى بين المركبات.
إذا قمت بفتح اتصال واحد ، فيمكن أن يكون له نفس المصدر والوجهة وأرقام المنافذ وعناوين IP وما إلى ذلك. ولكن منذ أن قمت بتأسيس هذا الاتصال الآن ، وليس في وقت سابق ، آمل ألا تتزامن الحزم من الرسائل المرسلة سابقًا مع أرقام التسلسل التي لدي لاتصالي الجديد. لذلك كانت هذه آلية لمنع الخلط بين الاتصالات المتكررة.
الطالب: إذا كنت لا تعرف بالضبط ما هي خطوة تسلسل الحزمة ، فكيف تعرف أن الحزمة التي تتلقاها هي الحزمة التالية وليست جزءًا من الحزمة السابقة التي ...
البروفيسور: كقاعدة عامة ، تتذكر آخر حزمة تم استلامها. ورقم التسلسل التالي هو بالضبط الحزمة التالية في التسلسل. لذا ، على سبيل المثال ، يعرف الخادم أنني رأيت جزءًا من بيانات التاريخ (SNc +1) بالضبط ، ثم ستكون الحزمة التالية SYN (SNc +1) ، لأن الحزمة السابقة في بداية الاتصال كانت SYN (SNc).
الطالب: إذن ، تقول أنك عندما تقوم بتعيين الرقم التسلسلي ، حتى بعد ذلك ...
الأستاذ: حسنًا ، بالطبع ، يتم تحديد هذه الأرقام التسلسلية ، في البداية ، عند تثبيتها ، وفقًا لبعض الخطط. سنتحدث عن هذه الخطة. قد تعتقد أنها عشوائية ، ولكن بمرور الوقت يجب أن تمثل بعض التدفق المتسلسل للتغييرات في أرقام التسلسل الأولي للاتصال.
ولكن في اتصال واحد ، ينتهي كل شيء بمجرد إنشائه - يتم إصلاح الأرقام التسلسلية. وهم يقومون فقط بوضع علامة على هذا الاتصال أثناء إرسال البيانات فوقه.
كانت هناك خطط اقترحت إدارة هذه الأرقام التسلسلية. , . , , , .
, - , 250000. , , , 64k 128k, . , – , SYN .
, 64 . , .
, . , , , , IP-.
, , , , , . , , .
, ? , , , — SNc. , , - , , , .
, . ACK (SNs).
- .
SNs , , , IP- C.
, . , : , , , data (SNc +1).
(SNs). ?
: , ?
: . , , , , . , , , , .
: , , ?
: . , ?
, . , , 32 , , .
, .
: , , , . …
: , TCP .
: , .
: , .
: , , .
: , , , . , , 1000 , 2 32 .
, - , , . . , .
: - , ?
: , . , , IP-, ?
: ?
: — ? , . ?
: , , , , - .
: , , , , , . IP-, TCP , , , .
TCP , - , , , C RST (SN…), , .
- , , C , .
, C , . , S , : «, , , ».
, , , , , C .
, «» C , . , «» C , . , TCP.
: , . , SYN , .
: , , . , , , , NAT, . , NAT RST , . , , , , , Comcast , RST .
: ?
: , , TCP. , . , , , . /, .
, data (SNc +1). , IP- , : « », , S.
SYN (SNs) (SNs) , . — , IP-, . , SNS SNS .
25:50
دورة معهد ماساتشوستس للتكنولوجيا "أمن أنظمة الكمبيوتر". 12: « », 2.
, . ? ? ,
30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps ,
.
Dell R730xd 2 ? فقط لدينا
2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV من 249 دولارًا في هولندا والولايات المتحدة! . c Dell R730xd 5-2650 v4 9000 ?