استطلاع نطاقات DNSSEC: فحص NSEC وكسر تجزئة NSEC3 بـ GPU ودفاع NSEC5

أضافت الامتدادات الأمنية لنظام أسماء النطاقات (DNSSEC) سلامة التشفير وتوثيق المصدر لبروتوكول التسمية الذي افتقر أساساً إلى آليات الحماية. ومن خلال إرفاق التوقيعات الرقمية (RRSIG) بمجموعات سجلات الموارد، تضمن الامتدادات قيام المحللات الموثقة باكتشاف أي تلاعب بالبيانات أو تسميم لذاكرة التخزين المؤقت أثناء انتقال الحزم.

ومع ذلك، أدى تصميم التوثيق التشفيري للردود السلبية—أي إثبات أن النطاق المطلوب غير موجود (NXDOMAIN) أو أن نوع السجل المحدد غير مسجل (NODATA)—إلى معضلة هيكلية كبرى. فلحماية المفاتيح السرية لتوقيع النطاق (ZSK) من خطر الاختراق على الخوادم الموثوقة، فرضت المعايير الأولى التوقيع غير المتصل. يوقع مدير النطاق الملف كاملاً على نظام معزول تماماً، ثم ينشر التوقيعات الثابتة على الخوادم العامة.

جعل هذا النموذج التشغيلي التوقيع الفوري للطلبات غير الموجودة مستحيلاً دون وضع المفاتيح الخاصة على خوادم متصلة بالإنترنت. ولإثبات عدم الوجود بصورة ثابتة، طورت هيئة IETF سجل الأمان التالي (NSEC) في معيار RFC 4034. ورغم دقة بنيته الرياضية، فتح NSEC قناة تسريب جانبية تُعرف باسم استطلاع نطاقات DNSSEC (Zone Walking)، مما يتيح للمهاجمين رسم المخطط الهيكلي لشبكة المؤسسة خلال دقائق معدودة.

معضلة الإنكار الموثق: لماذا تكشف الردود السلبية بنية خوادم DNS

في نظام DNS التقليدي غير المشفر، يرسل الخادم الموثوق ببساطة علامة ترويسة تحمل رمز الرد 3 (NXDOMAIN) عند تعذر العثور على الاسم. لكن المحللات التكرارية المقيدة بالتحقق تتطلب دليلاً رياضياً قاطعاً يضمن أن المهاجم لم يختلق رداً سلبياً لحرمان المستخدم من خدمة نظامية.

يتطلب التوقيع الفوري لكل رد سلبي الاحتفاظ بمفتاح ZSK قيد التشغيل المباشر عبر خوادم الحافة. وفي فجر تطبيق DNSSEC، رفض مهندسو الأمان هذا الطرح لتفادي مخاطر سرقة المفاتيح من الخوادم الموزعة. ونتيجة لذلك، اعتمد معيار RFC 4034 على إثبات المجالات الموقعة مسبقاً.

بدلاً من تأكيد عدم وجود الاسم المستفسر عنه بعينه، يقدم الخادم إقراراً موقعاً يثبت أنه لا يوجد أي سجل مسجل بين اسمين متعارف عليهما A وB مرتبين هجائياً. ورغم أن هذا المجال الرياضي يثبت عدم الوجود، فإنه يكشف علناً الاسمين الحقيقيين المحيطين بالنطاق للطرف المستفسر.

تشريح معيار RFC 4034: كيف تشكل سجلات NSEC قائمة متسلسلة غير مقصودة

يحقق سجل NSEC الإنكار الموثق عبر الإشارة المباشرة إلى الاسم المعياري التالي في ملف النطاق. وتتألف حمولة السجل من حقلين جوهريين: اسم النطاق التالي (Next Domain Name) وخريطة بتية للأنواع (Type Bit Maps) تسرد أصناف السجلات المفعلة لدى ذلك المالك.

;; مثال على الترتيب المعياري داخل ملف نطاق مؤسسي
alpha.example.com.     3600 IN NSEC  billing.example.com.   A RRSIG NSEC
billing.example.com.   3600 IN NSEC  db-cluster.example.com. A RRSIG NSEC
db-cluster.example.com. 3600 IN NSEC  example.com.           A RRSIG NSEC

تشكل هذه السجلات قائمة متسلسلة دائرية مغلقة. ويدور السجل الأخير في الترتيب الهجائي ليشير مجدداً إلى قمة النطاق (example.com.). وبذلك تصبح جميع الأسماء الداخلية مرتبطة ضمن حلقة قطعية ومكشوفة.

الترتيب المعياري لأسماء النطاقات وآليات استطلاع المناطق التقليدية

تستغل أدوات الفحص هذا الترابط عبر استعلامات تكرارية قياسية وبسيطة:

1. الاستعلام التمهيدي: يرسل برنامج الفحص طلباً لسجل A يسبق قمة النطاق هجائياً مباشرة، مثل 0.example.com.
2. استخلاص المجال: يرد الخادم برمز NXDOMAIN مرفقاً بسجل NSEC يمتد من القمة حتى أول سجل: example.com. NSEC admin.example.com.
3. التقدم في السلسلة: يدون الماسح الاسم المكتشف admin.example.com ويبني على الفور الاستعلام التالي: admin0.example.com.
4. التكرار التتابعي: يزود الخادم الماسح بالمجال اللاحق: admin.example.com NSEC api-gateway.example.com.
5. إتمام الدورة: تتكرر الخطوات حتى يشير السجل مجدداً إلى example.com.، مما يؤكد سحب قائمة الأسماء بنسبة 100%.

حصر النطاقات الفرعية: رسم خريطة سطح الهجوم للمؤسسات في دقائق

تتجاوز تقنية Zone Walking عقبات الرصد الاستخباري التقليدية. فالوسائل المعتادة تعتمد على التخمين بالقواميس وسجلات شفافية الشهادات ومحركات البحث، وهي أدوات تعجز غالباً عن كشف الخوادم الحساسة.

باستخدام أدوات مفتوحة المصدر مثل ldns-walk ضد نطاق محمي بـ RFC 4034، يحصل مختبرو الاختراق والمهاجمون على دليل غير خاضع للحجب يضم قواعد البيانات ولوحات التحكم وعناقيد التطوير وبوابات الشبكات الخاصة. تفضح هذه البيانات اصطلاحات التسمية والعتاد البرمجي، ممهدة السبيل لاختراقات مركزة.

تسوية معيار RFC 5155: إثبات عدم الوجود المجزأ عبر سجلات NSEC3

استجابة لمطالب الخصوصية الملحة، اعتمدت هيئة IETF عام 2008 معيار RFC 5155 المسمى NSEC3 (إثبات عدم الوجود المجزأ والموثق في DNSSEC).

صُمم NSEC3 لتقديم الإنكار الموثق مع إخفاء الأسماء النصية الصريحة. فبدلاً من ترتيب السلاسل النصية أبجدياً، يجزئ NSEC3 كل اسم عبر خوارزمية SHA-1 مع إضافة ملح (salt) تشفيري اختياري وتكرار العملية لمرات عديدة.

;; صيغة سجل NSEC3: [خوارزمية التجزئة] [الأعلام] [التكرار] [الملح] [التجزئة التالية] [الأنواع]
2T8A7...example.com. 3600 IN NSEC3 1 0 10 A1B2C3D4 7K9P2... A RRSIG

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

كسر حماية NSEC3: هجمات القواميس المسرعة ببطاقات GPU وأداة Hashcat

رغم أن NSEC3 منع استخراج الأسماء لحظياً بواسطة ldns-walk، فإنه نقل الثغرة نحو التشفير غير المتصل. فالسلسلة المجزأة تظل قابلة للجمع بالكامل عبر استفسارات متتابعة لتحصيل حلقة التجزئات المستهدفة.

وبعد تجميع البيانات، ينقل المهاجم عملياته إلى المعالجة غير المتصلة. ولأن NSEC3 يعتمد خوارزمية SHA-1 بملح ثابت، تتحول المهمة لهجوم قواميس تقليدي:

الاسم المقترح ("vpn") -> الملح ("A1B2C3D4") -> تجزئة SHA-1 المتكررة -> المطابقة مع الحلقة

تستطيع وحدات معالجة الرسوميات الحديثة (GPU) تنفيذ مليارات عمليات SHA-1 في الثانية الواحدة. وتتضمن برمجيات مثل Hashcat وحدات تسريع مدمجة (Mode 8300: DNSSEC NSEC3) مخصصة لهذا النمط.

تؤكد التجارب الميدانية أن هجمات القواميس ضد حلقات NSEC3 تنجح في استعادة 65% إلى 85% من أسماء النطاقات خلال ساعات، نظراً لاعتماد الهياكل المؤسسية على بادئات تقليدية متوقعة (mail وvpn وapi وauth وjira وdev).

فخ حجب الخدمة الحسابي: لماذا تؤدي التكرارات المرتفعة إلى شلل المحللات

لعرقلة جهود الكسر عبر معالجات GPU، رفع مديرو النطاقات في السابق قيمة المعامل iterations في RFC 5155 إلى 500 أو 1000 أو 2500 دورة تجزئة.

أحدث هذا التدبير خللاً جسيماً، إذ أسفر عن ثغرة حجب خدمة (DoS) غير متكافئة استهدفت المحللات التكرارية:

• عدم التكافؤ: يحسب الخادم الموثوق قيم NSEC3 مرة واحدة فقط أثناء توقيع النطاق محلياً.
• عبء المحلل: يفرض كل استعلام زائف عن اسم غير موجود على المحلل التكراري إعادة حساب دورات SHA-1 كاملة للتحقق من مصداقية الإثبات.
• تضخيم استنزاف المعالج: يؤدي تدفق استعلامات NXDOMAIN المفتعلة نحو المحلل إلى استنزاف 100% من قدرات المعالج المركزي في عمليات حسابية عقيمة.

تتعرض المحللات لاختناق خيوط المعالجة وارتفاع زمن الاستجابة إلى ما يزيد عن 1500 مللي ثانية، مما يعطل تصفح المستخدمين الشرعيين.

التحصين الحديث وفق معيار RFC 9276: إزالة الملح وضبط التكرارات إلى الصفر

للقضاء على مخاطر حجب الخدمة الحسابي وتبديد وهم الحماية المضلل، أصدرت هيئة IETF وثيقة RFC 9276 (إرشادات ضبط معايير NSEC3).

وضعت الوثيقة ضوابط صارمة ومشروطة لمديري النطاقات:

1. ضبط التكرارات عند الصفر حتماً: لا تقدم التكرارات الإضافية حماية تذكر أمام مصفوفات GPU وتكبد المحللات جهداً باهظاً، ولذا يلزم ضبط iterations = 0.
2. إلغاء الملح تماماً: لا يحمي الملح المتغير الكلمات القاموسية من التخمين، كما يبطل ذاكرة التخزين المؤقت للمحللات عند تحديث الملفات. ويوصى بترك الملح فارغاً (يُرمز له بـ -).
3. فرض قيود التحقق لدى المحللات: تطبق المحللات الحديثة سقوفاً حاسمة؛ فإذا تجاوز السجل القادم من الخادم الحدود المسموحة، يعامله المحلل كنطاق غير آمن أو يعيد الرمز SERVFAIL حفاظاً على موارده.

;; الإعداد المعاصر الموصى به لسجلات NSEC3 (متوافق مع RFC 9276)
;; الخوارزمية = 1 (SHA-1)، الأعلام = 0، التكرار = 0، الملح = -
U5G9E...example.com. 3600 IN NSEC3 1 0 0 - 8F3K2... A RRSIG

الخطوة التشفيرية التالية: بروتوكول NSEC5 والدوال العشوائية القابلة للتحقق

نظراً لعجز NSEC3 عن مجابهة الكسر خارج الشبكة، طور باحثو التشفير وهيئة IETF بروتوكول NSEC5 (الإنكار الموثق في DNSSEC بواسطة الدوال العشوائية القابلة للتحقق — VRF).

يعالج NSEC5 ثغرة استطلاع النطاقات عبر توظيف بنية التشفير اللامتناظر لدوال VRF:

• يمتلك الخادم الموثوق المفتاح السري للدالة (sk_vrf).
• يحمل المحلل المفتاح العام للمطابقة والتحقق (pk_vrf).
• لحساب تجزئة أي اسم نطاق، يلزم حيازة المفتاح السري sk_vrf.
• للتأكد من صحة التجزئة الصادرة، يكفي استخدام المفتاح العام pk_vrf.

وبما أن المهاجم لا يملك المفتاح السري، يستحيل عليه احتساب التجزئات محلياً، مما يجهض هجمات القواميس عبر بطاقات GPU بصورة رياضية قطعية.

التوقيع الفوري مقابل التوقيع غير المتصل: منهج الأكاذيب البيضاء

يتمثل أحد البدائل التشغيلية المطبقة لدى شبكات توزيع المحتوى الكبرى في سجلات NSEC ذات التغطية الدنيا (Minimal Covering NSEC)، وتعرف تقنياً بالأكاذيب البيضاء (RFC 4470 وRFC 7129).

لا يعرض الخادم هنا قوائم مسجلة، بل يصيغ الرد لحظياً عند أطراف الشبكة:

1. عند استلام استفسار عن charlie.example.com غير الموجود، يولد الخادم فوراً سجل NSEC يغطي النطاق (charlie\000.example.com NSEC charlie\001.example.com).
2. يثبت هذا السجل عدم وجود الطلب الفعلي دون كشف أي من النطاقات المجاورة الحقيقية.
3. تتطلب هذه المعمارية توفير مفاتيح التوقيع عند نقاط التواجد (PoP)، وهو ما تؤمنه وحدات الأمان العتادية (HSM) الحديثة بامتياز.

الضمانات الرياضية للخصوصية من خلال تقييم دوال VRF غير المتماثلة

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

يتحول استطلاع النطاق بذلك من سحب صامت وسري لقواعد البيانات إلى نشاط مسح شبكي مكشوف وسهل التعطيل.

بنية نظام DNS التكراري في RiceGuard: إحباط عمليات استطلاع النطاقات

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

طورت شبكة RiceGuard بالطبقة الثالثة آليات هندسية متقدمة لإحباط محاولات استكشاف DNS:

• تقليل استعلامات النطاق (RFC 7816): تستبعد محللات RiceGuard المقاطع الإضافية من أسماء النطاقات، ولا ترسل للخوادم العلوية سوى المقطع المعني بالخطوة الراهنة.
• تخزين الاستجابات السلبية: يحتفظ المحلل بذاكرة مؤقتة لردود NXDOMAIN (وفق RFC 2308) لمعالجة الطلبات المتكررة محلياً وحماية البنية العلوية.
• الحد من التكرارات غير الآمنة: تطبق RiceGuard إرشادات RFC 9276 فتهمل سجلات NSEC3 المثقلة بتكرارات غير طبيعية، لدرء هجمات حجب الخدمة الحسابية.
• منع تسرب حركة DNS: تعبر كافة الطلبات عبر أنفاق WireGuard الموثقة وصولاً إلى محللات خاصة تعزل عناوين IP الحقيقية. ويمكن فحص جودة الاتصال عبر أداة /what-is-my-ip.

تتوافر تطبيقات الخدمة للمستخدمين الساعين لحماية شبكاتهم عبر الرابط /download. ويمكن الاطلاع على تفاصيل تشفير حركة النطاقات في المقال /news/dnssec-vs-encrypted-dns-authenticity-privacy-architecture، ومطالعة تدابير إحباط قياس الفوارق الزمنية في /news/dns-cache-snooping-non-recursive-query-timing-defense.

التدقيق العملي وسبل الدفاع: رصد محاولات استطلاع النطاق وضبط المحللات

يتعين على مسؤولي الشبكات تدقيق النطاقات العامة للتثبت من عدم تسريب معلومات البنية التحتية عبر سجلات NSEC القديمة، وتطبيق سياسات توقيع معتمدة.

يمكن فحص تعرض النطاق لثغرة RFC 4034 بالأمر dig +dnssec example.com NSEC أو بالفحص الآلي عبر ldns-walk @ns1.example.com example.com. وفي حال ظهور أسماء متسلسلة، تتأكد ضرورة الانتقال إلى NSEC3 المطابق لـ RFC 9276.

في خادم BIND 9، تضبط السياسة ضمن ملف named.conf:

dnssec-policy "hardened-nsec3" {
    keys {
        ksk lifetime 365d algorithm ecdsap256sha256;
        zsk lifetime 60d algorithm ecdsap256sha256;
    };
    nsec3param {
        iterations 0;
        optout no;
        salt-length 0;
    };
};

أما في Knot DNS (knot.conf)، فتحدد القيم nsec3-iterations: 0 وnsec3-salt-length: 0 داخل قسم policy. وعند التحقق بالأمر dig +dnssec +multiline nonexistent.example.com A، يجب أن يظهر السجل NSEC3 بعدد تكرارات 0 وملح فارغ -. إن إنهاء دورات التكرار العقيمة بالتوازي مع استخدام محللات قوية يمنع تسريب تفاصيل الشبكة مع صون مصداقية DNSSEC بالكامل.