الخلاصة

  • يخفف RRL الردود المتشابهة المتكررة من خادم DNS موثوق عندما يمكن أن تحول الاستعلامات المزيفة الخادم إلى مضخّم لهجوم انعكاسي.
  • كان دور Paul Vixie مهماً لكنه لم يكن فردياً: توثق ISC جلسات دفاعية شارك فيها، وتسجل تذكرة تطوير BIND اسم Vixie وVernon Schryver معاً.
  • يجمع النظام فئات الردود ونطاقات عناوين العملاء. إنه يضبط حركة المرور، لا يثبت الهوية أو ينسب الهجوم أو يحكم على النية.

حين يتحول الرد إلى حمولة للهجوم

في هجوم انعكاسي عبر DNS، يُرسل الاستعلام إلى خادم موثوق مع تزوير عنوان المصدر ليبدو عنوان الضحية. عندئذ يصل رد الخادم إلى الضحية. وإذا كان الرد أكبر بكثير من الاستعلام، يكون المهاجم قد استعان بالخادم لإرسال حجم يفوق ما أرسله بنفسه.

تقدم شرائح ISC لعام 2014 مثالاً ملموساً: استعلام ANY حجمه 36 بايت عن isc.org قد ينتج رداً حجمه 3,576 بايت. يوضح المثال جاذبية الانعكاس، لكنه ليس نسبة تضخيم عامة لكل حركة DNS. يتوقف الحجم على الاستعلام وبيانات المنطقة وDNSSEC والنقل والرد الفعلي. السؤال التشغيلي أضيق: كم رداً متشابهاً ينبغي لخادم موثوق أن يواصل إرساله حين تتكرر استعلامات متشابهة؟

تقول ISC إن جلسات استراتيجية دفاعية داخلها مع Paul Vixie قادت إلى RRL. وتسمي تذكرة تطوير BIND Vixie وVernon Schryver صاحبي التصحيح الخاص بـBIND 9. تسند السجلات العلنية الدور المحوري لVixie، لا رواية المخترع المنفرد. فقد تحول تحدٍ تشغيلي إلى آلية برمجية عبر عمل جماعي ثم استمر ضبطها.

يضع ملف Paul Vixie في قاعة مشاهير الإنترنت هذه الحلقة ضمن مسار مهني أوسع في DNS. فقد بدأ صيانة BIND 4 في شركة Digital Equipment Corporation عام 1988، ثم أصبح المؤلف الرئيسي والمهندس التقني لـBIND 8. وأسّس أيضاً MAPS وPAIX وInternet Software Consortium، ونال الدكتوراه من Keio University عن عمل يتصل بـDNS وDNSSEC. تبين هذه المحطات نطاق عمله، لكنها لا تلغي الإسهام المشترك في تصحيح RRL الذي يسمي Schryver أيضاً.

أضاف BIND 9.9.4 النظام كميزة بناء اختيارية. وتذكر صفحة ISC بعنوان BIND 9.10 Significant Changes أن RRL أُدرج لاحقاً ضمن إعداد البناء الافتراضي. يثبت ذلك توفر الميزة في BIND، ولا يثبت أن كل مشغل خادم موثوق فعّلها أو أن منتجات DNS الأخرى تتصرف بالطريقة نفسها.

الجرافة تحسب التشابه لا الهوية

يشرح دليل BIND 9.20.29 الحالي جرافات رموز أو أرصدة تُنشأ بحسب الردود المتشابهة وعملاء DNS. يستهلك كل رد رصيداً ويُعاد شحنه بالمعدل المهيأ خلال نافذة زمنية. يستطيع المشغل تقييد فئات مثل الردود غير الفارغة، وNODATA، وNXDOMAIN، والإحالات، والأخطاء أو جميع ردود UDP. وعند تجاوز الحد يمكن لـBIND إسقاط بعض الردود أو تغييرها.

تخفي كلمة «عميل» قراراً سياسياً. تجمع الإعدادات الافتراضية الموثقة حالياً في BIND عناوين IPv4 ضمن /24 وعناوين IPv6 ضمن /56؛ أي إن عناوين الكتلة الواحدة تُحسب معاً. وقد يخدم محلل أو شركة أو جامعة أو مزود اتصال مستخدمين لا علاقة بينهم خلف البادئة نفسها. وإذا استنفد أحدهم رصيد المجموعة، قد يتلقى مستخدم آخر في النطاق ذاته رداً متأخراً أو مبتوراً أو لا يتلقى رداً.

لا يعني ذلك أن التجميع حسب البادئة خطأ دائماً. يمكن التحايل على حد لكل عنوان بتوزيع الاستعلامات بين عناوين كثيرة، وعلى الخادم توزيع قدرته المحدودة على الإرسال أثناء الهجوم. لكن حجم البادئة وفئة الرد والمعدل إعدادات لها كلفة على الإتاحة. إنها سياسة تشغيل ينبغي إعلانها، لا قياس محايد لهوية العميل «الحقيقية».

تظهر مفاضلة إعداد slip في BIND بوضوح. عند القيمة الافتراضية الموثقة slip=2، يتلقى كل طلب ثانٍ خاضع للتحديد ولا يحمل ملف تعريف ارتباط صالحاً للخادم رداً أصغر: BADCOOKIE إذا قدم العميل ملف ارتباط، وإلا يضع BIND علامة الاقتطاع ليدفع المحلل إلى إعادة المحاولة عبر TCP. لا يمكن اقتطاع بعض الأخطاء، فتُمرر بالمعدل الذي يحدده slip. أما slip=1 فيرسل ردوداً مبتورة لكل الطلبات المحدودة، مقدماً سلامة الرد وتسليمه على أقصى خفض للانعكاس؛ وslip=0 يسقط كل رد تجاوز الحد. مسار إعادة المحاولة جزء من تصميم الدفاع نفسه.

دور الخدمة يحدد نطاق التطبيق

توصي ISC باستخدام RRL على الخوادم الموثوقة، وتحذر من أن تطبيقه على الخوادم التكرارية قد يؤدي إلى إيجابيات كاذبة ويبطئ العملاء الذين يكررون الاستعلام عن الأسماء نفسها. إغلاق التكرار المفتوح أولى من الاعتماد على RRL. تختلف كلفة الأداة نفسها بين خدمة DNS موثوقة عامة ومحلل يخدم المستخدمين النهائيين.

يتيح BIND وضع log-only لمعاينة الحدود المقترحة قبل فرضها، مع عدادات مثل RateDropped وQryDropped وRateSlipped وRespTruncated. تصف هذه العدادات أثر الآلية المهيأة، لكنها لا تكشف هوية المهاجم. قد يكون عنوان المصدر المرصود مزيفاً، ولا تشكل العضوية في جرافة واحدة دليلاً على الإسناد.

تقدم ملاحظة Heng Lu رقم 65 هنا عدسة تحريرية فقط: سلوك النظام أثناء التشغيل هو ما يكشف ما تتحكم به البرمجية فعلاً. ليست الملاحظة دليلاً تاريخياً عن Vixie ولا مصدراً تقنياً عن RRL. ما ينبغي فحصه هو نسخة BIND المشغلة وإعدادها وعدّاداتها وكيفية إعادة العملاء للمحاولة، لا مجرد وجود توجيه في وثيقة.

الخلاصة التي تسندها الأدلة محدودة. يستطيع RRL خفض مساهمة خادم موثوق في إرسال ردود متشابهة تستخدم في الانعكاس. وقد يجمع مستخدمين شرعيين في مجموعة واحدة ويفرض مفاضلة بين التسليم والكبح. لا يصادق على الاستعلامات، ولا يحدد الدافع، ولا يقيس مدى التبني، ولا يضمن اختفاء الحركة الانعكاسية عن الضحية. والأدق فهم إسهام Vixie بوصفه مشاركة في تحويل دفاع تشغيلي إلى آلية قابلة للضبط يمكن للمشغلين فحص حدودها.

المصادر