معهد ماساتشوستس للتكنولوجيا. محاضرة رقم 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 الطالب: هل يوجد أي نوع من التوقيع لنطاقات المستوى الأعلى غير الموجودة؟
الأستاذ: أعتقد أن هناك. مجال النقطة هو مجرد مجال آخر ، وينفذ نفس الآلية. لذا يستخدم نطاقا "dot" و "dot.kom" في الوقت الحاضر DNS SEC ، وهناك كل هذه السجلات التي تقول ، على سبيل المثال ، إن .in هو اسم المجال الموجود ، واسم "dot" موجود أيضًا ، وليس هناك شيء بينهما. لذلك في نطاقات المستوى الأعلى ، كل هذه الأشياء موجودة.
الطالب: إلى جانب خطر هجمات DoS ، لماذا نهتم كثيرًا بتكرار أسماء النطاقات داخل mit.edu؟
الأستاذ: لا أعرف بالتأكيد. على أي حال ، لدى AFS ملف نصي يسرد جميع أسماء نطاقات MIT هذه. ولكن أعتقد أنه بشكل عام ، تشعر بعض الشركات بالحرج قليلاً في هذا المعنى ، لأنها غالبًا ما يكون لها أسماء داخلية موجودة في DNS ولا يمكن إعطاؤها للأجانب. أعتقد أنه في الواقع ، هذه منطقة غامضة لم يتم إضفاء الطابع الرسمي عليها مطلقًا ولا تشرح بالضبط ما يضمنه مستخدمو DNS. عادة ما يفترض الناس أنه في حالة وجود اسم سري ، فلن يتم الكشف عنه في حالة DNS.
أعتقد أن هذا مكان آخر حيث لا يحتوي هذا النظام على مواصفات واضحة من حيث ما يجب أو لا ينبغي أن يقدم.
الطالب: هل من الممكن تحديد فترة صلاحية التوقيع بإبرازه بطريقة ما؟
البروفيسور: هذه الأشياء لها تاريخ انتهاء ، على سبيل المثال ، يمكنك التوقيع على أن مجموعة الأسماء هذه صالحة لمدة أسبوع ، وبعد ذلك يمكن للعملاء ، إذا كان لديهم ساعة متزامنة ، رفض الرسائل القديمة الموقعة.
لذا ، يمكننا أن نفترض أننا ناقشنا الهجمات عن طريق تخمين أرقام تسلسل TCP SYN. هناك مشكلة أخرى مثيرة للاهتمام تتعلق بـ TCP وهي هجوم DDoS ، الذي يستغل حقيقة أن الخادم في حالة ما. إذا نظرت إلى هذه المصافحة التي تم رسمها على السبورة سابقًا ، فسترى أنه عندما يقوم العميل بإنشاء اتصال بالخادم ، يجب أن يتذكر الخادم الرقم التسلسلي لعميل SNc. وبالتالي ، يجب أن يدعم الخادم بعض بنية البيانات في كتلة منفصلة ، مما يدل على استخدام رقم التسلسل لهذا الاتصال.
هذا هو نوع من الجدول حيث يتم تخزين رقم تسلسل SN وأن اتصال خادم العميل لديه رقم تسلسل SNc. السبب الذي يجعل الخادم يحتفظ بهذا الجدول هو أن الخادم يحتاج إلى معرفة الرقم الذي يجب أن يأخذه رقم تسلسل SNc الصحيح لاحقًا ، على سبيل المثال ، SNc + 1. بالإضافة إلى ذلك ، يحتاج الخادم أيضًا إلى تخزين أرقام SN ، والتي تعد أكثر أهمية ، حيث أنها توضح للخادم أن الاتصال تم تأسيسه مع "الشخص المناسب".
المشكلة هي أن هذا الجدول ليس له حدود حقيقية. بهذه الطريقة ، يمكنك الحصول على حزم من بعض الأجهزة دون حتى معرفة من الذي يرسلها. يمكنك فقط الحصول على حزمة تشبه C-> S مع عنوان مصدر يدعي أنه C. لقبول هذا الاتصال المحتمل من عنوان IP هذا ، يجب عليك إنشاء إدخال في الجدول. علاوة على ذلك ، توجد هذه السجلات لفترة طويلة ، ربما ، لأن شخصًا ما يقيم اتصالًا معك من مكان بعيد جدًا وفي نفس الوقت يتم فقد العديد من الحزم. في أسوأ الحالات ، قد يستغرق الأمر ، على سبيل المثال ، دقيقة حتى ينتهي شخص ما من مصافحة TCP. لذلك يجب عليك إبقاء هذه الحالة على مكدس TCP لفترة طويلة نسبيًا ، ولا توجد طريقة لتخمين ما إذا كانت صالحة أم لا.
وبالتالي ، فإن هجوم DoS الأكثر شيوعًا ضد معظم مكدسات TCP التي توصل إليها الناس هو الإرسال البسيط لعدد كبير من الحزم. إذا كنت مهاجمًا ، فأنا فقط أرسل عددًا كبيرًا من حزم SYN إلى خادم معين وأؤدي إلى تجاوز هذا الجدول.
تكمن المشكلة في أن المهاجم ، في أحسن الأحوال ، يستخدم ببساطة عنوان IP المصدر نفسه. في هذه الحالة ، يمكنك القول ببساطة أنه يُسمح لكل عميل بإدخالين فقط ، أو شيء من هذا القبيل. وبعد ذلك ، يمكن للمهاجم استخدام 2 إدخالين كحد أقصى في الجدول.
المشكلة ، بالطبع ، هي أن المهاجم يمكنه تزوير عناوين IP للعملاء وجعلها تبدو عشوائية. ثم سيكون من الصعب للغاية على الخادم أن يميز من يحاول إنشاء اتصال معه - مهاجم أو عميل لم يسمع به الخادم من قبل.
لذلك إذا نظرت إلى بعض المواقع التي يجب أن تقبل الاتصالات من أي مكان في العالم ، فستكون هذه مشكلة كبيرة. لأنك إما ترفض الوصول إلى الجميع ، أو يجب أن تكون قادرًا على تخزين الحالة لمعظم محاولات الاتصال المزيفة.
لذا فهذه مشكلة لكل من بروتوكول TCP ومعظم البروتوكولات التي تسمح بنوع من بدء الاتصال ، حيث يجب على الخادم حفظ الحالة. ولكن هناك بعض الإصلاحات التي تم تنفيذها في برنامج TCP والتي سنتحدث عنها في ثانية ، وستحاول معالجة هذه المشكلة ، والتي تسمى SYN Flooding in TCP.
بشكل عام ، هذه مشكلة يجب أن تكون على دراية بها ومحاولة تجنبها في أي بروتوكول تقوم بتطويره. يجب عليك تحديد أن الخادم لا يجب أن يحفظ الحالة حتى يتمكن من المصادقة والتعرف على العميل. لأنه فقط بعد مصادقة العميل ، يمكن اتخاذ قرار ما إذا كان مسموحًا له بالاتصال ، على سبيل المثال ، مرة واحدة فقط ، وفي هذه الحالة لا يحتاج الخادم إلى حفظ الحالة لهذا الاتصال.
المشكلة هي أنك تضمن الحفاظ على الدولة حتى قبل أن تعرف من يتصل بك. دعونا نرى كيف يمكننا مواجهة هجوم الفيضانات SYN Flooding ، وهو أن الخادم يتراكم كثيرًا من الحالة.
يمكنك تغيير TCP مرة أخرى ، على سبيل المثال ، إصلاحه بسهولة مع التشفير أو أي شيء آخر ، أو تغيير ما هو المسؤول عن حفظ بعض الحالات. لكن الحقيقة هي أننا بحاجة إلى استخدام TCP كما هو. هل يمكننا حل هذه المشكلة دون تعديل بروتوكول TCP الحالي؟
هذا ، مرة أخرى ، تمرين في محاولة معرفة الحيل التي يمكننا القيام بها بالضبط ، أو بالأحرى ، أي الافتراضات التي يمكننا تركها بمفردنا وما زلنا نلتزم بتنسيق رأس TCP الحالي عند العمل معهم.
والحيلة هي إيجاد طريقة ذكية لإنشاء خادم عديم الحالة ، بحيث لا تضطر إلى تخزين هذا الجدول في الذاكرة. يمكن القيام بذلك عن طريق اختيار SN بدقة ، أي بدلاً من الصيغة التي أخذناها في الاعتبار سابقًا وحيث اضطررنا إلى إضافة هذه الوظيفة ، سنختار الأرقام التسلسلية بطريقة مختلفة تمامًا. سأعطيك الصيغة الدقيقة ، وبعد ذلك سنتحدث عن سبب كونها مثيرة للاهتمام حقًا وما هي الخصائص الجيدة التي تمتلكها.
إذا اكتشف الخادم أنه يتعرض لهجوم من هذا النوع ، فإنه ينتقل إلى الوضع الذي يحدد فيه SNs باستخدام الصيغة بنفس الوظيفة F التي اعتبرناها من قبل.
تحتوي هذه الوظيفة على عنوان IP المصدر وعنوان IP الوجهة ونفس الأشياء التي كانت موجودة من قبل - منفذ المصدر ومنفذ الوجهة والطابع الزمني والمفتاح. وسنقوم بدمج هذه الوظيفة مع طابع زمني ، بدلاً من "الحبيبات الخشنة" ، بحجم بضع دقائق. هناك فصل بين هذين الجزأين من الرأس - الوظيفة والطابع الزمني ، الذي لا يحتاج إلى الكثير من البتات. لقد نسيت كيف يعمل هذا البروتوكول بالضبط على جهاز كمبيوتر حقيقي ، ولكن يمكنك أن تتخيل أن الطابع الزمني يأخذ 8 بت ، وبقية صيغة الرقم التسلسلي هي 24 بت.
فلماذا هذه خطة جيدة؟ ما الذي يحدث هنا؟ لماذا هذه الصيغة الغريبة مطلوبة؟ يجب أن تتذكر ما حاولنا الحصول عليه من الأرقام التسلسلية. يحدث شيئين هنا.
الأول هو الحماية ضد الحزم المكررة. بقيت على اللوحة دائرة بها هذا الرقم التسلسلي القديم الطراز ، والذي نضيف إليه وظيفة لمنع تكرار الحزم من الاتصالات السابقة.
اتضح أن الأشخاص لم يتمكنوا من إيجاد طريقة أفضل لحماية أنفسهم من الهجمات مثل SYN Flooding ، باستثناء استخدام خطة العمل هذه ، والتي تعمل بشكل جيد في بعض المواقف. كانت خطة واحدة ، لكن خطة أخرى كانت وظيفة ذات طابع زمني حيث تخلينا عن هذا المكون من النمط القديم. بدلاً من ذلك ، سنركز على التأكد من أنه إذا زودنا شخص ما برقم تسلسل ACK هذا (SN) ردًا على الحزمة ، فسيكون هذا الشخص هو العميل "الصحيح".
تتذكر أنه من أجل منع هجمات خداع IP ، فإننا نعتمد نوعًا ما على هذه القيمة (SN). بعد كل شيء ، إذا أرسل الخادم قيمة SNs إلى العميل في الخطوة الثانية ، فإننا نتوقع أن هذا العميل فقط سيكون قادرًا على إرسال قيمة SNs المصححة في الخطوة الثالثة ، وإكمال الاتصال.
هذا هو السبب في أنه كان عليك تخزين هذا الرقم التسلسلي في جدول ، لأنه بخلاف ذلك ، كيف يمكنك معرفة ما إذا كانت هذه إجابة حقيقية أم مزيفة؟ سبب استخدام هذه الوظيفة F هو أنه لا يمكننا الآن حفظ هذا الجدول في الذاكرة.
بدلاً من ذلك ، عندما تظهر محاولة الاتصال ، والتي تظهر في الخطوة الأولى ، في الخطوة الثانية ، نحسب SNs باستخدام هذه الصيغة ونرسلها ببساطة إلى العميل الذي يريد الاتصال بنا ، ثم ننسى هذا الاتصال.
بعد ذلك ، عندما تصل الحزمة الثالثة وتتوافق قيمتها (SN) مع ما نتوقع رؤيته ، فهذا يعني أن شخصًا ما تلقى إجابتنا في الخطوة الثانية وأرسلها إلينا أخيرًا. أخيرًا ، بعد هذه الخطوة الثالثة ، يمكننا وضع السجل الفعلي لاتصال TCP هذا في الذاكرة. هذه طريقة لتأجيل استمرار الخادم حتى يرسل العميل القيمة الدقيقة للرقم التسلسلي. يجعل بناء مثل هذا البناء من الممكن التحقق من أن العميل أرسل الخادم بالضبط الإجابة المتوقعة منه ، وليس بعض القيمة التعسفية.
الطالب: هل تستمر SNc لفترة محدودة فقط؟
الأستاذ: نعم ، الخادم لا يخزن قيمة SNc بشكل دائم ، وهذا ليس جيدًا جدًا. لم أظهر هذا في الرسم التخطيطي ، ولكن هنا في نهاية السطر الثالث يوجد حقل يوضح أن هذه الحزمة لا تحتوي على بيانات ، ولكنها تتضمن رقم تسلسل SNc فقط لأنها تحتوي على هذا الحقل.
وبالتالي ، يمكن للخادم استعادة قيمة SNc ، لأن العميل سيدرجها في هذه الحزمة على أي حال. في السابق ، لم يكن الأمر مهمًا ، ولكنه الآن كما لو كان ذا صلة. لن نتحقق من أي شيء هنا ، ولكن وجود مثل هذا المجال في حد ذاته أمر جيد. ومع ذلك ، فإن لها بعض النتائج المحزنة. على سبيل المثال ، إذا كنت تستخدم بعض الأشياء المعقدة التي يمكن إساءة استخدامها هنا. ولكن هذا ليس سيئًا مثل ذاكرة الخادم الزائدة مع طلبات العملاء.
لأن الشيء الوحيد الذي يقلقنا هو الإفراج عن تخزين هذا الجدول والثقة في أن الاتصالات يتم إنشاؤها مع عملاء حقيقيين. وإذا أقام هذا العميل مليون اتصال معي ، فسوف أتوقف عن قبول الطلبات منه ، الأمر بسيط للغاية. تكمن المشكلة في صعوبة التمييز بين العناوين المزيفة وعناوين العملاء الحقيقية.
الطالب: هل أحتاج إلى الحفاظ على طابع زمني؟
البروفيسور: نعم هناك شيء ذكي! عندما نحصل على قيمة SNs في الخطوة الثالثة ، نحتاج إلى معرفة كيفية حساب بيانات الإدخال لهذه الوظيفة F للتحقق من صحة هذه القيمة. لذلك ، نأخذ الطابع الزمني الموجود في نهاية العبوة ونستخدمه للحساب داخل الوظيفة. كل شيء آخر يمكننا استعادته. نحن نعرف من أرسل لنا للتو الخطوة الثالثة والحزمة ، لدينا كل هذه الحقول ومفتاحنا ، الذي ، مرة أخرى ، لا يزال سريًا ، والطابع الزمني من آخر 8 بتات من التسلسل. في هذه الحالة ، قد يحدث أننا نستبعد الطوابع الزمنية القديمة جدًا عن طريق حظر الاتصالات القديمة.
الطالب: أعتقد أنك تستخدم هذا عندما تتعرض للهجوم ، فقط لأنك تفقد 8 بت من الأمان ، أو لسبب آخر؟
البروفيسور: نعم ، هذه ليست جيدة جدا ، ولها العديد من الخصائص السيئة. بطريقة ما ، نحن نفقد حقًا 8 أجزاء من الأمان. لأن الجزء الذي لا جدال فيه الآن هو فقط 24 بت بدلاً من 32.
مشكلة أخرى هي ما يحدث إذا فقدت حزم معينة؟ في TCP ، من المقبول عمومًا أنه في حالة فقدان الحزمة الثالثة ، فقد يكون العميل في انتظار عدم وجود شيء. أو ، معذرة ، ربما يكون البروتوكول الذي يتم تشغيله فوق اتصال TCP هذا هو بروتوكول يفترض أن الخادم ينوي في البداية أن يقول شيئًا ، لذلك أتصل به وأستمع فقط إلى الإجابة. وفي SMTP ، على سبيل المثال ، يجب أن يرسل لي الخادم شيئًا مثل التحية عبر البروتوكول. لنفترض أنني اتصل بخادم SMTP ، وأرسل الحزمة الثالثة ، أعتقد أنني فعلت كل شيء وانتظر حتى يجيبني الخادم ، على سبيل المثال:
"مرحبًا ، هذا خادم SMTP ، من فضلك أرسل لي بريدك الإلكتروني!"
لذا ، قد تفقد هذه الحزمة الثالثة. في برنامج TCP الحقيقي ، يتذكر الخادم أنه في الخطوة الثانية استجاب للعميل ، ولكنه لم يتلق حزمة استجابة ثالثة منه. لذلك ، سيرسل الخادم العميل مرة أخرى حزمة ثانية لإعادة تشغيل الحزمة الثالثة. بالطبع ، إذا لم يقم الخادم بتخزين أي حالة ، فلن يكون لديه أي فكرة عما يجب إرساله. وهذا يجعل إقامة اتصال أمرًا معقدًا إلى حد ما ، لأن كلا الجانبين يتوقعان خطوة متبادلة من بعضهما البعض. لا يعرف الخادم حتى أن العميل ينتظر استجابة منه ، والعميل ينتظر استجابة الخادم ، على الرغم من أنه لن يجيب لأنه لا يخزن الحالة. لذلك ، هذا سبب آخر لعدم استخدام الوضع الإنتاجي للخادم باستمرار.
الطالب: قد تتعرض أيضًا لفقدان البيانات إذا قمت بإنشاء اتصالين قصير الأجل للغاية من مضيف واحد تلو الآخر مباشرة.
الأستاذ: نعم بالطبع. شيء آخر هو أننا رفضنا استخدام هذا النمط القديم من رقم تسلسل ISN ، مما زاد من استقلالية هذه الاتصالات المتعددة في وقت قصير عن بعضها البعض. أعتقد أن هناك عددًا من التنازلات هنا ، لقد تحدثنا للتو عن ثلاثة منها ، لذا هناك بضعة أسباب أخرى للقلق.
إذا تمكنا من تطوير بروتوكول من الصفر ، والسعي لتحقيق الأفضل ، فيمكننا فقط الحصول على حجم 64 بت منفصل جيد للدالة F وحجم 64 بت للطابع الزمني ، وبعد ذلك يمكننا استخدامه باستمرار ، دون التخلي كل هذه الأشياء اللطيفة.
الطالب: هل يجب أن تكون الشبكات SN في الخطوتين الثانية والثالثة هي نفسها؟
البروفيسور: بالطبع ، لأنه بخلاف ذلك لن يتمكن الخادم من استنتاج أن هذا العميل قد تلقى الحزمة الخاصة بنا. إذا لم يقم الخادم بالتحقق من أن SNs لها نفس المعنى كما كان من قبل ، فقد يكون الأمر أسوأ من ذلك - لأنني قد أزيف اتصالاً من عنوان IP عشوائي في الخطوة الأولى ، ثم أحصل على هذه الإجابة في الخطوة الثانية. أو لن أحصل على هذه الإجابة لأنها موجهة إلى عنوان IP مختلف. ثم في الخطوة الثالثة أقوم بإنشاء اتصال من عنوان IP آخر. في هذه الحالة ، سيدعم الخادم الاتصال الذي تم إنشاؤه ، وانتظرني لإرسال البيانات ، وما إلى ذلك.
الطالب: لكن الطابع الزمني سيكون مختلفًا ، أليس كذلك؟ كيف يمكن للخادم إعادة سرد ذلك باستخدام طابع زمني جديد إذا لم يخزن الحالة؟
البروفيسور: كما قلت ، هذه الطوابع الزمنية "حبيبات خشنة" ويتم تصنيفها في دقائق. إذا اتصلت في نفس اللحظة ، فكل شيء على ما يرام ، إذا اتصلت على حدود الدقيقة - فهذا سيئ جدًا.
مشكلة أخرى في هذه الدائرة هي أنها غير كاملة في نواح كثيرة. لكن معظم أنظمة العمل ، بما في ذلك Linux ، لديها طرق لاكتشاف عدد كبير جدًا من الإدخالات في هذا الجدول. وعندما يحدث خطر التدفق الزائد ، يتحول النظام إلى مخطط آخر.
الطالب: إذا كان المهاجم يتحكم في عدد كبير من عناوين IP ويفعل ما قلته ، حتى إذا قمت بالتبديل ...
الأستاذ: نعم ، لا يمكنك فعل الكثير. كان السبب وراء اهتمامنا بهذا المخطط هو أننا أردنا التصفية أو التمييز بطريقة ما بين المهاجمين و "الأشخاص الطيبين". إذا كان لدى المهاجم المزيد من عناوين IP ويتحكم فقط في عدد من الأجهزة أكثر من الأشخاص الطيبين ، فيمكنه الاتصال بخادمنا أو طلب صفحات ويب متعددة أو البقاء على اتصال.
ومن ثم سيكون من الصعب للغاية على الخادم تحديد ما إذا كانت الطلبات يتم تلقيها من عملاء شرعيين أم أنه مجرد مهاجم يربط موارد الخادم. لذلك أنت على حق تماما. يعمل هذا المخطط فقط إذا كان لدى المهاجم عدد صغير من عناوين IP ويريد تحقيق تأثير.
وهذا مدعاة للقلق ، لأن بعض المهاجمين يتحكمون اليوم في عدد كبير من أجهزة الكمبيوتر المخترقة من قبل المستخدمين العاديين. هذا يسمح لهم بإنشاء DoS مع أسطول من الآلات الموجودة في جميع أنحاء العالم ، ومن الصعب للغاية الدفاع ضدها.
أريد أن أذكر شيئًا آخر مثيرًا للاهتمام - إن رفض خدمة DoS أمر سيئ في حد ذاته ، ولكنه أسوأ عندما تساهم البروتوكولات نفسها في مثل هذا الهجوم. يعرف المهاجم عن هذا ويهاجم في المقام الأول أنظمة بروتوكولات مثل DNS. يتضمن بروتوكول DNS عميلاً يرسل طلبًا إلى الخادم ، ويرسل الخادم استجابة إلى العميل. وفي كثير من الحالات ، يكون حجم الاستجابة بالبايت أكبر بكثير من حجم الطلب.
سألت عن خادم mit.edu. , , mit.edu — , mit.edu, , DNS SEC, .
100 , — 1000 . , «» - . , DNS- . 100 - DNS-, , , 1000 .
, . , TCP SYN Flooding, DNS- , . , , « ».
DNS. . , DNS-. , . .
: DNS- …
: , DNS- , - .
: , ?
: , DNS-, . DNS-, . 10 DNS-, , , , , . . , , DNS-, .
, DNS , , , . , .
, , , – , , , . , , . .
DNS- , . , , .
, : «, , »! , , DNS- .
, . - -, . DoS , . , , , , .
, , . , , , .
, , . .
, DHCP, . , , IP-. , , MIT DHCP, , , , IP-, , DNS-, , .
, DHCP DHCP-, , DHCP-. , , . , DHCP IP-, : «, DNS- »! DNS .
, . , BGP, IP-, . , , BGP, : «, IP-!», : „, , “.
, , , IP- . IP- , , IP- . IP- , . , . , , , IP-. , , .
DNS SEC. , , DNS, , . , , , , DNS SEC.
, , , . : , , , , , DoS — . .
لذلك ، يجب أن تسعى جاهدًا لتجنب أشياء مثل هجمات SYN Flooding وهجمات RST التي تسمح لك بفصل مستخدم شبكة تعسفي. هذه أشياء ضارة حقًا على مستوى منخفض ويصعب إصلاحها على مستوى عال. ولكن إلى حد ما ضمان سلامة وسرية البيانات باستخدام التشفير. سنتحدث عن كيفية القيام بذلك في المحاضرة القادمة عن سيربيروس.النسخة الكاملة من الدورة متاحة هنا .شكرا لك على البقاء معنا. هل تحب مقالاتنا؟ هل تريد رؤية مواد أكثر إثارة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية به لأصدقائك ،
خصم 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 يورو مقابل سنت واحد؟