معهد ماساتشوستس للتكنولوجيا. محاضرة رقم 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 الطالب: ربما لا يزال لديك مشكلة تضارب في المصالح لأنه يمكنك استخدام 32 بت لعناوين الأقران ولديك العديد من المنافذ لكل منها. ربما لديك تضارب في أرقام التسلسل لجميع هذه الاتصالات التي تحصل عليها؟
البروفيسور: اتضح أن أرقام التسلسل هذه خاصة بعنوان IP ورقم المنفذ لزوج المصدر / الوجهة. لذلك إذا كانت هذه منافذ مختلفة ، فإنها لا تتداخل مع بعضها البعض على الإطلاق. على وجه التحديد ، تحتوي المنافذ على أرقام تسلسلية أقل.
الطالب: إذا كانت الأرقام التسلسلية عالمية ، فهل يمكن للمهاجم الدخول في الاتصال بين العملاء الآخرين؟
الأستاذ: نعم ، هذه نقطة جيدة. في الواقع ، إذا زاد الخادم من الرقم التسلسلي ، على سبيل المثال ، بمقدار 64 كيلو بايت لكل اتصال ، فإنك تتصل بالخادم ، ثم يتصل به 5 أشخاص آخرين ، ويمكنك هنا تنظيم هجوم. إلى حد ما ، أنت على حق ، إنه أمر مزعج قليلاً. من ناحية أخرى ، ربما يمكنك القيام بذلك بحيث يتم تسليم حزمة من السطر الأخير من S-> A مباشرة قبل تلك الحزمة في السطر الأول من C-> S. إذا قمت بإرسال الحزم الخاصة بك واحدة تلو الأخرى ، فهناك احتمال كبير بأن يصلوا على الخادم واحدًا تلو الآخر أيضًا.
سيتلقى الخادم S-> A ويستجيب برقم التسلسل (SNs). سيكون مختلفًا عن (SN) في السطر الثاني ، ولكن مع الرقم التسلسلي الذي يليه مباشرة. وبعد ذلك ستعرف بالضبط رقم التسلسل (SNs) الذي يجب تضمينه في الحزمة الثالثة من التسلسل.
لذلك ، أعتقد أن هذه ليست طريقة موثوقة للغاية للاتصال بالخادم ، فهي تستند إلى الافتراضات. ولكن إذا رتبت حزمك بعناية بالطريقة الصحيحة ، يمكنك بسهولة تخمين التسلسل. أو ربما ستحاول عدة مرات وستكون محظوظًا.
الطالب: حتى إذا تم إنشاء الأرقام عن طريق الصدفة ، فأنت بحاجة إلى تخمين واحد من 4 مليار رقم ممكن. هذا ليس كثيرًا ، أليس كذلك؟ أعتقد أنه في غضون عام ستتمكن من اقتحام هذه الشبكة.
الأستاذ: نعم ، أنت محق تماما. يجب ألا تعتمد كثيرًا على بروتوكول TCP من حيث الأمان. لأنك على حق ، إنها 4 مليار تخمين فقط. وربما يمكنك إرسال الكثير من الحزم خلال النهار إذا كان لديك اتصال سريع إلى حد معقول.
إذن لدينا هنا نوع من الجدل المثير للاهتمام حول عدم موثوقية TCP ، لأن لدينا 32 بت فقط. لا يمكننا تأمينه بأي شكل من الأشكال. لكن أعتقد أن العديد من التطبيقات التي تعتمد على هذا البروتوكول بشكل كافٍ لا تفكر في الأمن على الإطلاق ، ويصبح هذا مشكلة حقًا.
لكنك على حق تماما. من الناحية العملية ، تريد استخدام نوع من التشفير بالإضافة إلى الحصول على ضمانات أكثر جدية بعدم قيام أحد بتزييف بياناتك ، نظرًا لأنك تستخدم مفاتيح تشفير أطول من 32 بت. في معظم الحالات ، لا يزال هذا فعالًا في منع العبث باتصال TCP.
دعنا نرى الآن لماذا يكون الأمر سيئًا إذا كان بإمكان الأشخاص تزييف اتصالات TCP من عناوين عشوائية؟
أحد الأسباب التي تجعل هذا سيئًا هو أنه يمكن أن يؤثر على التفويض بناءً على عنوان IP عندما يتحقق الخادم من العنوان الذي جاء منه الطلب. إذا قرر الخادم ما إذا كان سيسمح بالاتصال أو يرفضه بناءً على عنوان IP ، فمن المحتمل أن يمثل ذلك مشكلة لمهاجم قام بتزوير الاتصال من عنوان مصدر عشوائي.
لذا ، أحد الأمثلة حيث كانت هذه مشكلة ، اليوم تم حل هذه المشكلة بشكل أساسي ، وهو استخدام مجموعة من أوامر r ، مثل rlogin. كان من المعتاد أنه يمكنك تشغيل شيء مثل rlogin لجهاز كمبيوتر ، على سبيل المثال ، athena.dialup.mit.edu. وإذا كان اتصالك يأتي من مضيف MIT ، فسوف ينجح أمر rlogin هذا إذا قلت: "نعم ، أنا مستخدم Alice على هذا الكمبيوتر ، دعني أسجل الدخول كمستخدم Alice على كمبيوتر آخر." وسيتم السماح بهذه العملية ، نظرًا لأن جميع أجهزة الكمبيوتر الموجودة على شبكة mit.edu جديرة بالثقة لتقديم مثل هذه العبارات.
يجب أن أقول أن الاتصال الهاتفي لم يكن لديه هذه المشكلة. استخدم هذا المركب سيربيروس من البداية. لكن الأنظمة الأخرى ، بالطبع ، واجهت مثل هذه المشاكل. وهذا مثال على استخدام عنوان IP في آلية مصادقة الاتصال عندما يتحقق النظام لمعرفة ما إذا كان العميل الذي يتصل بالخادم جدير بالثقة. لذا فإن ما كان يمثل مشكلة لم يعد مشكلة. لكن الاعتماد على الملكية الفكرية لا يزال يبدو خطة سيئة.
الآن لم يعد rlogin قيد الاستخدام ، تم استبداله مؤخرًا بقشرة SSH الآمنة ، وهو بروتوكول طبقة شبكة ممتاز. من ناحية أخرى ، هناك العديد من الأمثلة الأخرى للبروتوكولات التي تعتمد على التفويض المستند إلى عنوان IP. واحد منهم هو SMTP. عند إرسال بريد إلكتروني ، فإنك تستخدم SMTP للتحدث مع بعض خادم البريد من أجل إرسال الرسائل. لمنع الرسائل غير المرغوب فيها ، تقبل العديد من خوادم SMTP الرسائل الواردة فقط من عنوان IP مصدر معين. على سبيل المثال ، يقبل خادم بريد Comcast البريد من عناوين Comcast IP فقط. وينطبق الشيء نفسه على خوادم بريد MIT - فلن يقبلوا سوى البريد من عناوين MIT IP. ولكن كان لدينا خادم واحد على الأقل لم يعمل كما ينبغي ، باستخدام مصادقة IP.
كل شيء هنا ليس بهذا السوء. في أسوأ الحالات ، سترسل بعض الرسائل غير المرغوب فيها عبر خادم البريد. لذلك ربما يكون هذا هو السبب في أنهم لا يزالون يستخدمون rlogin ، في حين أن الأشياء التي تسمح لك بتسجيل الدخول إلى حساب عشوائي قد توقفت عن استخدام المصادقة المستندة إلى IP.
فلماذا تعتبر آلية المصادقة هذه خطة سيئة؟ وافتراض ، افترض أن بعض الخوادم المستخدمة روغلين. ماذا ستفعل للهجوم؟ ما السيء يمكن أن يحدث؟
الطالب: يمكن للمهاجم ببساطة الدخول إلى جهاز الكمبيوتر الخاص بك ، وتزييف مستخدم يدخل إلى الشبكة باستخدام اسم المستخدم الخاص بك ، والوصول إلى الشبكة.
البروفيسور: نعم ، بشكل أساسي مهاجم يستولي على جهاز كمبيوتر. يقوم بتجميع البيانات التي تبدو وكأنها مجموعة صالحة من أوامر rlogin التي تقول ، "تسجيل الدخول باسم هذا المستخدم وتنفيذ هذا الأمر في shell Unix الخاص بي."
تقوم بتجميع بيانات البيانات هذه (SNc + 1) ، وتقوم بتثبيت الهجوم بالكامل وإرسال هذه البيانات كما لو كان مستخدم شرعي يتفاعل مع عميل rlogin ، وبعد ذلك يمكنك المتابعة.
حسنًا ، هذا أحد أسباب عدم رغبتك في تخمين أرقام تسلسل TCP. مشكلة أخرى هي هذه الهجمات إعادة تعيين إعادة الهجوم. بنفس الطريقة التي يمكننا من خلالها إرسال حزمة SYN ، إذا كنا نعرف الرقم التسلسلي لشخص ما ، فيمكننا إرسال حزمة إعادة تعيين بنفس الطريقة.
ذكرنا لفترة وجيزة عميلًا قانونيًا يرسل حزمة إعادة تعيين اتصال وهمية أنشأها مهاجم. يمكن للمهاجم أيضًا محاولة إرسال حزم تجاهل للاتصال الحالي إذا كان يعرف بطريقة أو بأخرى أن رقم التسلسل الخاص بك موجود في هذا الاتصال. في الواقع ، ليس من الواضح حجم هذه المشكلة.
على مستوى ما ، يجب أن تفترض أن جميع اتصالات TCP الخاصة بك يمكن أن تنقطع في أي حال وفي أي وقت ، أي أنها لا تبدو موثوقة لشبكتك. لذلك ، ربما يجب أن تتوقع قطع الاتصال.
في حالة "تحدث" أجهزة التوجيه مع بعضها البعض ، يكون هذا الافتراض مهمًا بشكل خاص. إذا كان لديك العديد من أجهزة التوجيه التي تتواصل مع بعضها البعض باستخدام بعض بروتوكولات التوجيه ، فهناك بعض الاتصالات المادية بينهما. ولكن علاوة على هذه الاتصالات الفعلية ، فإنها تتواصل عبر بروتوكول شبكة يعمل عبر TCP. في الواقع ، في كل من هذه الاتصالات الفعلية التي تستخدمها أجهزة التوجيه لتبادل معلومات التوجيه ، يتم بدء جلسة TCP. يتم استخدام بروتوكول BGP هنا ، والذي سنتحدث عنه لاحقًا.
يستخدم بروتوكول BGP هذا حقيقة أنه إذا كان اتصال TCP على قيد الحياة ، فإن الاتصال الفعلي يكون أيضًا على قيد الحياة. لذلك إذا انقطع اتصال TCP ، يعتقد جهاز التوجيه أن الاتصال مقطوع ويبدأ في إعادة حساب جميع جداول التوجيه الخاصة به.
لذلك ، إذا أراد الخصم ترتيب نوع من هجوم رفض خدمة DoS ، فيمكنه محاولة تخمين الأرقام التسلسلية لأجهزة التوجيه هذه وإسقاط هذه الجلسات. إذا تم إيقاف جلسة TCP بين جهازي التوجيه ، فسيعتبر كلا جهازي التوجيه أن هذا الاتصال قد مات ويجب أن يعيدوا حساب كل جداول التوجيه ، مما سيؤدي إلى تغيير المسارات. بعد ذلك ، يمكن للمهاجم إعادة تعيين اتصال آخر ، وهكذا.
وبالتالي ، يعد هذا هجومًا مزعجًا إلى حد ما ، وليس لأنه ينتهك سر شخص آخر وما إلى ذلك ، على الأقل ليس بشكل مباشر ، ولكن لأنه يتسبب في الكثير من مشاكل الوصول لمستخدمي النظام الآخرين.
الطالب: إذا كنت مهاجمًا وترغب في تنظيم هجوم مستهدف ضد مستخدم معين ، فهل يمكنك الاستمرار في إرسال الطلبات للاتصال بالخادم نيابة عن عنوان IP الخاص به وإجباره على إعادة تعيين الاتصال بالخادم؟
البروفيسور: لنفترض أنني أستخدم Gmail وتريد منعني من تلقي أي معلومات من Gmail ، لذا أرسل حزمًا إلى جهازي ، وتظاهر أنها تأتي من خادم Gmail. في هذه الحالة ، يجب عليك تخمين أرقام منفذ المصدر والوجهة الصحيحة.
ربما يكون رقم منفذ الوجهة 443 لأنني أستخدم HTTPS. لكن رقم المنفذ المصدر سيكون شيئًا عشوائيًا 16 بت. بالإضافة إلى ذلك ، ستختلف الأرقام التسلسلية. لذلك ، إذا لم تخمن رقم التسلسل الموجود في نافذة TCP الخاصة بي والذي يبلغ عشرات الكيلوبايت ، فلن تنجح.
لذا عليك أن تخمن كمية لا بأس بها من الأشياء. لا يوجد وصول أوراكل هنا. لا يمكنك فقط أن تطلب من الخادم الرقم التسلسلي لهذا الرجل. هذا هو السبب في أن هذا لن يعمل.
لذلك ، تم إصلاح العديد من هذه المشكلات ، بما في ذلك هذا الشيء المستند إلى RST ، خاصةً لأجهزة توجيه BGP. في الواقع كان هناك حلان مضحكان. يظهر شيء واحد حقًا كيف يمكنك استغلال الأشياء الموجودة أو استخدامها لإصلاح مشاكل معينة. يستخدم الخاصية التي تتصل بها أجهزة التوجيه هذه فقط مع بعضها البعض ، وليس مع أي شخص آخر على الشبكة. ونتيجة لذلك ، إذا لم تصل الحزمة من جهاز توجيه موجود على الطرف الآخر من الاتصال ، فسيتم تجاهل هذه الحزمة.
يعد التنفيذ الناجح لمطوري هذه البروتوكولات منطقة رائعة في الحزمة تسمى "العمر" أو TTL. هذا حقل 8 بت يتم إنقاصه بواسطة كل جهاز توجيه للتأكد من أن الحزم لا تنتهي في حلقة لا نهائية. الحد الأقصى لقيمة TTL هو 255 والمزيد من الانخفاضات.
فماذا أفعل هذه البروتوكولات الذكية؟ يتخلصون من أي حزمة بقيمة TTL لا تساوي 255. لأنه إذا كانت الحزمة تحتوي على قيمة 255 ، فلا يمكن أن تأتي إلا من جهاز توجيه على الجانب الآخر من هذا الاتصال. وإذا حاول الخصم إدخال أي حزمة أخرى في اتصال BGP الحالي ، فسيكون له قيمة TTL أقل من 255 ، لأن هذه القيمة سيتم تخفيضها بواسطة أجهزة التوجيه الأخرى الموجودة على طول مسار التوجيه ، بما في ذلك جهاز التوجيه هذا. لذلك ، سيتم رفض هذه الحزمة ببساطة من قبل المستلم.
هذا مثال على مزيج ذكي من التقنيات المتوافقة مع السابقة التي تحل هذه المشكلة المحددة للغاية.
الطالب: ألا يرسل جهاز التوجيه السفلي الأيمن شيئًا ما بامتداد TTL 255؟
البروفيسور: هذا موجه مادي. وهو يعلم أن هذه اتصالات منفصلة ، لذلك ينظر إلى كل من TTL ومن أين جاءت الحزمة. لذلك إذا كانت الحزمة تأتي من جهاز التوجيه العلوي الأيسر ، فلن تقبلها لاتصال TCP بينها وجهاز التوجيه العلوي الأيمن.
بالنسبة للجزء الأكبر ، تثق أجهزة التوجيه هذه في جيرانها المباشرين ، ويمكن التحكم في هذه العملية باستخدام آلية التوجيه متعدد المسارات Auto Pan.
إصلاحات أخرى لـ BGP هي تنفيذ شكل من أشكال رأس المصادقة ، بما في ذلك رأس مصادقة MD5. ولكن في الواقع ، ركز المطورون على هذا التطبيق المعين ، والذي يعد هجوم إعادة الضبط أمرًا بالغ الأهمية.
هذه المشكلة مستمرة اليوم. إذا كان هناك أي اتصال طويل المدى وأريد مقاطعته ، فيجب علي فقط إرسال عدد كبير من حزم RST ، ما يقرب من مئات الآلاف ، ولكن ربما ليس 4 مليارات. لأن الخوادم في الواقع عرضة إلى حد ما لرقم التسلسل الذي تقبله لإعادة التعيين.
يمكن أن تكون أي حزمة في نافذة معينة. في هذه الحالة ، يمكن للمهاجم قطع هذا الاتصال دون بذل الكثير من الجهد. لا تزال هذه مشكلة لا يوجد لها حل جيد حقًا.
وآخر شيء سيئ يمكن أن يحدث بسبب إمكانية التنبؤ بأرقام التسلسل هو حقن البيانات في الاتصالات الحالية. افترض أن لدينا بروتوكولًا افتراضيًا مشابهًا لـ rlogin ، والذي لا يقوم بالفعل بإجراء المصادقة المستندة إلى IP ، لذا يجب عليك إدخال كلمة المرور الخاصة بك لتسجيل الدخول.
تكمن المشكلة في أنه بمجرد إدخال كلمة المرور الخاصة بك ، ربما يتم إنشاء اتصال TCP الخاص بك ويمكنه قبول بيانات عشوائية. لذا يحتاج المهاجم إلى الانتظار حتى يقوم أحدكم بتسجيل الدخول إلى الكمبيوتر بإدخال كلمة المرور الخاصة بك.
لا يعرف المهاجم ما هي كلمة المرور ، ولكن بمجرد إنشاء اتصال TCP ، سيحاول على الفور تخمين الرقم التسلسلي وإدخال بعض البيانات في اتصالك الحالي. لذلك ، إذا تمكنت من تخمين رقمك التسلسلي بشكل صحيح ، فإن هذا سيسمح لي بالتظاهر بأنه ليس أنا ، ولكنك أدخلت أمرًا ما بعد أن تتم مصادقته بكلمة مرور بشكل صحيح.
يشير كل هذا إلى سبب عدم رغبتك حقًا في الاعتماد على أرقام تسلسل 32 بت هذه بمعنى الأمان. ولكن دعونا نرى ما تفعله مكدسات TCP الحديثة بالفعل لتخفيف هذه المشكلة. أحد المقاربات التي سنغطيها في المحاضرتين التاليتين هو تطبيق درجة من الأمان على مستوى التطبيق. في هذا المستوى ، سنستخدم التشفير لمصادقة الرسائل وتشفيرها وتوقيعها والتحقق منها دون تدخل TCP بشكل كبير.
تساعد بعض التطبيقات الموجودة أيضًا على حل المشكلات الأمنية ، أو على الأقل تجعل الأمر أكثر صعوبة بالنسبة للمهاجم لاستغلال هذه المشاكل. وضع الناس هذا موضع التنفيذ اليوم ، على سبيل المثال ، على Linux و Windows ، مع الحفاظ على أرقام تسلسل أولية مختلفة لكل زوج مصدر / وجهة.
وبالتالي ، لا تزال معظم تطبيقات TCP SYN تحسب رقم تسلسل ISN الأولي بنفس الطريقة التي فعلناها من قبل. إذا هذا أسلوب ISN قديم ، دعنا نقول ذلك. ولإنشاء رقم تسلسلي فعليًا لأي اتصال معين ، نضيف إلى هذا النموذج القديم ISN إزاحة عشوائية 32 بت. أي أننا نضيف إليها وظيفة - شيء مثل وظيفة التجزئة أو SHA-1 ، أو شيء أفضل.
تتضمن هذه الميزة عنوان IP المصدر ورقم منفذ المصدر وعنوان IP الوجهة ورقم منفذ الوجهة وبعض المفتاح السري الذي يعرفه الخادم فقط. وبالتالي ، فإننا نخلق فرصة جيدة لأي اتصال معين لتحديد عنوان IP والمنفذ لزوج المصدر / الوجهة ، مع الحفاظ على جميع الخصائص الجيدة لخوارزمية تعيين رقم تسلسل النمط القديم.
ولكن إذا كان لديك اتصالات من مجموعات مختلفة من المصدر / الوجهة ، فلا يوجد شيء يسمح لك بمعرفة القيمة الدقيقة للرقم التسلسلي لمجموعة أخرى من الاتصالات. في الواقع ، عليك أن تخمن هذا المفتاح لحساب هذه القيمة.
آمل أن تقوم نواة نظام تشغيل الخادم بتخزين هذا المفتاح في مكان ما في ذاكرته ولا يعطيه لأي شخص. هذه هي الطريقة التي تحل بها معظم حزم TCP اليوم هذه المشكلة المحددة في مجال أرقام تسلسل 32 بت الشائعة. هذا ليس رائعًا جدًا ، لكنه يعمل.
الطالب: هل يمكنك تكرار ذلك مرة أخرى؟ حول تفرد المفتاح ...
الأستاذ: عندما يتم تشغيل الجهاز الخاص بي ، أو عند تشغيل أي جهاز ، فإنه يولد مفتاحًا عشوائيًا. في كل مرة تقوم بإعادة تحميله ، يقوم بإنشاء مفتاح جديد. وهذا يعني أنه في كل مرة تتغير فيها الأرقام التسلسلية لزوج مصدر / وجهة معين بنفس تردد الإزاحة. وبالتالي ، يتم تحديد معلمات الوظيفة لزوج مصدر / وجهة معين. لذلك تتبع التسلسل عندما تتطور الأرقام وفقًا لأرقام التسلسل الأولية للمركبات الجديدة ، وتتغير وفقًا لخوارزمية معينة. وبالتالي ، يتم توفير الحماية ضد حقن الحزم القديمة من التوصيلات السابقة في التوصيلات الجديدة ، بالإضافة إلى الحماية من إعادة تعيين الحزم.
الشيء الوحيد الذي نحتاج إليه لهذا الرقم التسلسلي للعينة القديمة هو اختيار الخوارزمية لمنع مشاكل هذه الحزم المكررة. اعتبرنا سابقًا أنه إذا حصلت على رقم تسلسلي لاتصال واحد A: A -> S: SYN (...) ، بعد ذلك يمكنك استنتاج حول الرقم التسلسلي لاتصال ACK (SNs).
, 32- , F. , , .
: ?
: , . F, , F , , , .
: , …
: , F - -, . -, , . , , , , . , F .
, TCP, . , , - .
, . , TCP , DNS, . , DNS UDP – . UDP — , , . UDP . , , , . , , . DNS-. DNS?
, DNS- C: C53 -> S53 mit.edu, 53.
S: S53 -> C53 IP-, – .
, , , , . , mit.edu, .
, DNS- . IP-, , . IP- mit.edu IP-. , , , , . , .
, , . IP-. , , DNS- . , , IP- mit.edu.
: , , ?
: , . , , . DNS-, , . 2 . — , 16 . , 16 . ID, 16 , .
, , 32 . , , , , .
, , .
, DNS DNS . , , DNS . , DNS SEC, . , , , DNS- . , , .
origin. DNS , IP-, : „, “. , , , , , , . , , ?
, – DNS- , . , , . -, DNS-, . , DNS SEC, , , DNS- . DNS- , , , – , .
DNS SEC , NSEC. , . , NSEC , foo.mit.edu, goo.mit.edu, , .
, , , , , , „, “.
. , foo.mit.edu -> goo.mit.edu — >…. : » , , gooa.mit.edu". , , .
, DNS . NSEC3, – - , - .
52:00
دورة معهد ماساتشوستس للتكنولوجيا "أمن أنظمة الكمبيوتر". 12: « », 3.
شكرا لك على البقاء معنا. هل تحب مقالاتنا؟ هل تريد رؤية مواد أكثر إثارة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية به لأصدقائك ،
خصم 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 يورو مقابل سنت واحد؟