
يُنتج هذا المشروع ملفات منطقة DNS مع معاملات NSEC3 مخصصة لإعادة إنتاج وتقييم الهجمات في CVE-2023-50868.
يقوم هذا المشروع بإنشاء ملفات منطقة DNS مع معاملات NSEC3 مخصصة لإعادة إنتاج وتقييم الهجمات في CVE-2023-50868.
Python3 (تم اختباره على Python3.10)
مكتبات Python المثبتة:
lib: أدوات Python المساعدة، بما في ذلك:
keys.py: دوال تغليف لتحميل/تخزين المفاتيح في الملفاتnsec.py: تنفيذ تجزئات NSEC الخاصة بـ DNSSECdnssec.py: دوال معدلة/مرقعة من مكتبة dnspython مع دعم NSEC3config.py: أدوات تحميل التكوينkeys: ملفات PEM تحتوي على مفاتيح منشأة مسبقًا (تم إنشاؤها باستخدام )gen_keys.pyzones: ملفات المنطقة (تم إنشاؤها باستخدام gen_zones.py)config.json: مثال للتكوينقم بتكوين مناطق NSEC3 التي يجب إنشاؤها عن طريق تعديل config.json (انظر التكوين)
إنشاء المفاتيح:
$ ./gen_keys.py
لكل منطقة، يتم إنشاء مفتاح KSK ومفتاح ZSK. يتم إعادة استخدام المفاتيح عند تغيير التكوين طالما بقيت أسماء المناطق دون تغيير في التكوين.
إنشاء ملفات المنطقة:
$ ./gen_zones.py -c
الخيار -c يتيح تصدير ملفات التكوين (حاليًا فقط لـ BIND9)
استخدم --help للمزيد من الخيارات.
يتكون هيكل التكوين من عنصرين:
default: المعاملات الافتراضية للمناطق (غير مدعومة بالكامل حتى الآن)zones: قائمة بجميع المناطق المراد تصديرهاتحتوي المنطقة على:
name (مطلوب): الاسم المستخدم عند الإشارة إلى المنطقة واسم الملف أثناء التصديرorigin (مطلوب): اسم نطاق أصل المنطقة الأساسيparent: اسم المنطقة الأم (وليس الأصل)، الذي تُضاف إليه سجلات NS و A و DS و NSEC3PARAM لهذه المنطقةkeysize (مطلوب): حجم مفتاح RSA (فقط RSA حتى الآن)nsec3: معاملات NSEC3:
iterations: القيمة الافتراضية 0salt: القيمة الافتراضية ''algorithm: قيمة عددية، حاليًا فقط SHA-1 (1) مدعومtight: قيمة منطقية خاصة تتحكم في إضافة سجلات NSEC3 بعد الأصل مباشرة وقبل وبعد *.origin. على سبيل المثال، إذا كان لـ *.origin سجل NSEC3 هو 1d..ua.origin.، فسيتم إضافة السجلات لـ 1d..u0.origin. و 1d..ub.origin. إلى ملف المنطقة أيضًا. وهذا يضمن أن كل إثبات NXDOMAIN على نطاق فرعي للأصل (مثل a.origin.) يتطلب ثلاثة سجلات NSEC3، حيث أن سجلات NSEC3 التي تغطي الأصل والبطاقة الجامدة لها نطاق صغير جدًا إلى next_hashns: خادم (خوادم) الأسماء لهذه المنطقة. قيمة واحدة أو قائمة من:
ns: اسم نطاق خادم الأسماء، القيمة الافتراضية ns1.originip: نطاق Ipv4 (IPv6 غير مدعوم حاليًا)، القيمة الافتراضية 172.0.0.1soa: بيانات SOA RDATArrsets: قائمة بمجموعات RR إضافية، تُعطى كقائمة خماسية [اسم النطاق, ttl, class, type, rdata] حيث تُعطى جميع القيم (باستثناء ttl اختياريًا) كسلاسل نصيةلإعادة إنتاج هجوم NSEC3، يوضح هذا القسم إعدادًا مخصصًا محتملًا يتكون من خادم أسماء DNS ومحلل ضحية. قبل المتابعة، تأكد من أن بيئة النظام تحتوي على جدار ناري مهيأ بشكل كافٍ حتى لا يتم كشف الخوادم العامة لملفات المنطقة الهجومية.
تثبيت خادم الأسماء NSD (الإصدار الحالي)
انتقل إلى موقع NLNetlabs (https://nsd.docs.nlnetlabs.nl/en/latest/installation.html) للحصول على تعليمات التثبيت.
يُنصح بنشر خادم الأسماء إما في جهاز افتراضي أو حاوية. كنقطة بداية، يوجد ملف Dockerfile صغير في docker/nsd.
قم ببناء الحاوية باستخدام docker build -t <tag> <path_to_dockerfile>، على سبيل المثال:
cd docker/nsd && docker build -t nsd .
قم بتشغيل الحاوية باستخدام docker run -it --name <name> nsd bash لفتح وحدة تحكم في الحاوية.
بعد ذلك، يجب تكوين خادم الأسماء لاستضافة ملفات المنطقة الهجومية.
يتطلب ذلك تكوينًا صحيحًا لملفات المنطقة المراد إنشاؤها (الأهم من ذلك، يجب أن يتطابق عنوان IP المعطى في سجلات NS مع عنوان IP الخاص بالحاوية).
إذا لم يتم تكوين شبكة، يمكن عرض عنوان IP الخاص بالحاوية باستخدام:
docker container inspect <name> | grep IPAddress
قم بإنشاء المناطق مع إخراج التكوين (./gen_zones.py -c، انظر أعلاه) وانسخ مجلد إخراج المناطق من دليل المستودع إلى حاوية docker:
docker cp ./zones <name>:/etc/nsd
في وحدة تحكم الحاوية، يجب تعديل تهيئة NSD /etc/nsd/nsd.conf في الحاوية بإضافة الأسطر التالية:
verify:
enable: no
remote-control:
control-enable: no
include: "/etc/nsd/zones/nsd.conf"
أخيرًا، قم بتشغيل NSD من شل الحاوية بالأمر
/usr/sbin/nsd -d -c /etc/nsd/nsd.conf
قم بتمكين إخراج السجلات باستخدام الخيار -V 4.
الآن، إذا لم تحدث أي مشكلات، يجب أن يكون خادم الأسماء الموثوق قيد التشغيل. يمكنك التحقق من ذلك عن طريق إجراء استعلام لأحد نطاقات المناطق من النظام المضيف باستخدام dig:
dig @<ip-addr-of-nsd-container> <domain>
تثبيت محلل. في هذا العرض التوضيحي، نعرض نهجًا محتملاً لـ Unbound 1.17.1.
يمكن العثور على ملف Dockerfile رسمي هنا: https://github.com/NLnetLabs/pythonunbound
قمنا بتضمين نسخة معدلة من هذا الملف في docker/unbound مع إصدار محدث من Ubuntu ومهيأ مسبقًا لـ Unbound 1.17.1.
استنسخ المستودع، وانتقل إلى دليله وقم ببناء حاوية Unbound:
docker build -t <tag> .
قم بتشغيل الحاوية باستخدام:
docker run --name <name> -it <tag> bash
بعد ذلك، يجب تكوين Unbound بحيث يمكنه تحديد موقع خادم الأسماء NSD الموثوق.
يتم ذلك عن طريق تعديل ملف unbound.conf في دليل عمل الحاوية.
لهذا، تأكد من إزالة إدخال server.module-config من التكوين.
لتمكين التحقق من صحة DNSSEC، يجب تكوين سجلات DNSKEY لمنطقة المهاجم الأم يدويًا. يجب أن يكون هذا نفس المفتاح الذي تم استخدامه لإنشاء التوقيعات، على سبيل المثال:
server:
chroot: ""
do-ip6: no
trust-anchor: "attack.er. DNSKEY 257 3 7 AwEAAdqDN3rJYlmGP3jJs5lCZq5NYrCn pCVlV0ko17JnbfYfLCroEF4reO/Xy0MK C9AVvSRTk83MHDuzMYXogm7m/gcn3Mh0 MwB2InP8jkPw5not+TMH/Wrbs31xkT2n RIBJJ+1lPF+e2AvwWvgREcEVTRbdhIqQ iM1StWXoTVudry4V"
علاوة على ذلك، يجب تكوين منطقة جذعية (stub-zone) لتمكين محلل Unbound من العثور على خادم الأسماء NSD الموثوق.
يتم ذلك عن طريق إضافة ما يلي إلى ملف unbound.conf:
stub-zone:
name: "attack.er."
stub-prime: yes
stub-addr: <ip-addr-of-nsd-container>
إذا واجهت أي مشكلات مع هذا الدليل، فلا تتردد في الاتصال بنا للحصول على مزيد من الإرشادات.
قم بتشغيل Unbound في الحاوية باستخدام:
unbound -vvv (استخدم -dd لمنع التشغيل كخلفية)
يجب أن تكون الآن قادرًا على الاستعلام عن Unbound باستخدام dig وملاحظة وقت الاستجابة:
dig @127.0.0.1 attack.er